Chris Ball | 1 Apr 03:12 2012

Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support

Hi Kukjin,

On Wed, Mar 28 2012, Kukjin Kim wrote:
>>> As a result I'm dropping this tree -- and all of the patches that I
>>> have on top of it -- from mmc-next so that I can get a pull request
>>> out.  This means that I'm dropping:
>>
> Hmm, I think, if you're ok, you can send a second pull request to
> Linus for it and actually, it is in linux-next for a long time via mmc
> and samsung tree.
>
> Note, please don't rebase it because its resolution for conflicts is
> in linux-next and I think Linus will use it when happens
> conflicts...Or I can provide new tree on top of latest mainline. But
> I'm not sure about latter.

I can't send the tree as it is to Linus now, because Arnd has asked us
to hold off on these device tree bindings and work with the unified
bindings he's proposing instead.  (Rebasing to drop that patch will
introduce new conflicts.)

I'm going to send Mark Brown's two patches to Linus now, even though it
will cause a conflict in -next.  The rest (other than the device tree
bindings) are mergable after -rc1, because they're fixes, so we'll
eventually get everything except DT in to 3.4.  I think you should
just drop this patchset from your tree in linux-next entirely now.

Thanks,

- Chris.
(Continue reading)

Shawn Guo | 1 Apr 08:41 2012

Re: [PATCH v2] video: s3c-fb: Add device tree support

On Fri, Mar 30, 2012 at 09:25:14PM +0530, Rabin Vincent wrote:
> On Fri, Mar 30, 2012 at 11:23, Thomas Abraham
<thomas.abraham@...> wrote:
> > +    - samsung,fimd-display: The fimd controller is interfaced with the a
> > +      display device such as a lcd panel. This property should specify the
> > +      phandle of the display device node. For a display device node that
> > +      represents a RGB type display interface, it is expected to specify the
> > +      video interface timing using the following properties.
> > +
> > +      - lcd-htiming: Specifies the horizontal timing for the overlay. The
> > +        horizontal timing includes four parameters in the following order.
> > +
> > +        - horizontal back porch (in number of lcd clocks)
> > +        - horizontal front porch (in number of lcd clocks)
> > +        - hsync pulse width (in number of lcd clocks)
> > +        - Display panels X resolution.
> > +
> > +      - lcd-vtiming: Specifies the vertical timing for the overlay. The
> > +        vertical timing includes four parameters in the following order.
> > +
> > +        - vertical back porch (in number of lcd lines)
> > +        - vertical front porch (in number of lcd lines)
> > +        - vsync pulse width (in number of lcd clocks)
> > +        - Y resolution.
> 
> In this old thread, it was suggested to use a raw EDID block to supply
> timings, and since then a couple of drivers in mainline (sm501fb and
> fsl-diu) are doing it that way:
> 
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080683.html
(Continue reading)

Mark Brown | 1 Apr 13:29 2012

Re: [PATCH v3 6/6] mmc: sdhci-s3c: Add device tree support

On Fri, Mar 30, 2012 at 06:45:07PM +0000, Arnd Bergmann wrote:
> On Friday 30 March 2012, Stephen Warren wrote:

> > > +- cd-inverted: when present, polarity on the wp gpio line is inverted
> > > +- wp-inverted: when present, polarity on the wp gpio line is inverted

> > I'm not sure about those two: Some of the GPIO bindings have flags in
> > the GPIO specifier (Tegra, ARM PL061, gpio.txt mentions the possibility
> > of polarity being in the specifier), and bit 0 of the flags is used to
> > indicate inversion. I think that either we should rely on GPIO
> > specifiers having such flags and remove these xxx-inverted properties
> > from the MMC binding, or remove that flag bit from the GPIO bindings.

> Maybe the GPIO maintainer can comment on this. My understanding is
> that not all gpio controllers support this in their bindings. If they
> do, I agree that we can remove the extra properties here.

Surely it'd be better to fix this at the GPIO controller end rather than
having a patchwork of approaches?
Saugata Das | 2 Apr 09:49 2012

Re: [PATCH V2] mmc: core: Add host capability check for power class

On 28 March 2012 16:39, Subhash Jadavani <subhashj <at> codeaurora.org> wrote:
>
>
>> -----Original Message-----
>> From: linux-mmc-owner <at> vger.kernel.org [mailto:linux-mmc-
>> owner <at> vger.kernel.org] On Behalf Of Saugata Das
>> Sent: Thursday, December 15, 2011 6:35 PM
>> To: Girish K S
>> Cc: linux-mmc <at> vger.kernel.org; patches <at> linaro.org; linux-samsung-
>> soc <at> vger.kernel.org; subhashj <at> codeaurora.org; Chris Ball
>> Subject: Re: [PATCH V2] mmc: core: Add host capability check for power
> class
>>
>> On 15 December 2011 16:22, Girish K S <girish.shivananjappa <at> linaro.org>
>> wrote:
>> > On 15 December 2011 15:34, Saugata Das <saugata.das <at> linaro.org> wrote:
>> >> On 15 December 2011 09:28, Girish K S <girish.shivananjappa <at> linaro.org>
>> wrote:
>> >>> This patch adds a check whether the host supports maximum current
>> >>> value obtained from the device's extended csd register for a
>> >>> selected interface voltage and frequency.
>> >>>
>> >>> cc: Chris Ball <cjb <at> laptop.org>
>> >>> Signed-off-by: Girish K S <girish.shivananjappa <at> linaro.org>
>> >>> ---
>> >>> Changes in v2:
>> >>>        deleted a unnecessary if else condition identified by subhash
>> >>> J Changes in v1:
>> >>>       reduced the number of comparisons as per Hein's suggestion
>> >>>
(Continue reading)

Subhash Jadavani | 2 Apr 12:54 2012

RE: [PATCH V2] mmc: core: Add host capability check for power class


> -----Original Message-----
> From: Saugata Das [mailto:saugata.das <at> linaro.org]
> Sent: Monday, April 02, 2012 1:20 PM
> To: Subhash Jadavani
> Cc: Girish K S; linux-mmc <at> vger.kernel.org; patches <at> linaro.org; linux-
> samsung-soc <at> vger.kernel.org; Chris Ball
> Subject: Re: [PATCH V2] mmc: core: Add host capability check for power
class
> 
> On 28 March 2012 16:39, Subhash Jadavani <subhashj <at> codeaurora.org>
> wrote:
> >
> >
> >> -----Original Message-----
> >> From: linux-mmc-owner <at> vger.kernel.org [mailto:linux-mmc-
> >> owner <at> vger.kernel.org] On Behalf Of Saugata Das
> >> Sent: Thursday, December 15, 2011 6:35 PM
> >> To: Girish K S
> >> Cc: linux-mmc <at> vger.kernel.org; patches <at> linaro.org; linux-samsung-
> >> soc <at> vger.kernel.org; subhashj <at> codeaurora.org; Chris Ball
> >> Subject: Re: [PATCH V2] mmc: core: Add host capability check for
> >> power
> > class
> >>
> >> On 15 December 2011 16:22, Girish K S
> >> <girish.shivananjappa <at> linaro.org>
> >> wrote:
> >> > On 15 December 2011 15:34, Saugata Das <saugata.das <at> linaro.org>
> wrote:
(Continue reading)

Mark Brown | 2 Apr 13:35 2012

[PATCH] ARM: S3C64XX: Hook up new style regulator-regulator supplies on Cragganmore

The regulator API now allows supplies used by regulators to be specified
as normal supplies - provide the hookup for that mechanism on Cragganmore.

Signed-off-by: Mark Brown <broonie <at> opensource.wolfsonmicro.com>
---
 arch/arm/mach-s3c64xx/mach-crag6410.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 02fd009..4ee0249 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
 <at>  <at>  -306,6 +306,24  <at>  <at>  static struct regulator_consumer_supply wallvdd_consumers[] = {
 	REGULATOR_SUPPLY("SPKVDD2", "1-001a"),
 	REGULATOR_SUPPLY("SPKVDDL", "1-001a"),
 	REGULATOR_SUPPLY("SPKVDDR", "1-001a"),
+
+	REGULATOR_SUPPLY("DC1VDD", "0-0034"),
+	REGULATOR_SUPPLY("DC2VDD", "0-0034"),
+	REGULATOR_SUPPLY("DC3VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO1VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO2VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO4VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO5VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO6VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO7VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO8VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO9VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO10VDD", "0-0034"),
+	REGULATOR_SUPPLY("LDO11VDD", "0-0034"),
(Continue reading)

Il Han | 2 Apr 13:55 2012
Picon

[PATCH] mach-exynos: fix ISO C90 warning.

ISO C90 forbids mixed declarations and code.
Fix it.

Signed-off-by: Il Han <corone.il.han <at> gmail.com>
---
 arch/arm/mach-exynos/common.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index e6cc50e..8614aab 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
 <at>  <at>  -583,10 +583,11  <at>  <at>  core_initcall(exynos_core_init);
 #ifdef CONFIG_CACHE_L2X0
 static int __init exynos4_l2x0_cache_init(void)
 {
+	int ret;
+
 	if (soc_is_exynos5250())
 		return 0;

-	int ret;
 	ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
 	if (!ret) {
 		l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
--

-- 
1.7.4.1

Kukjin Kim | 2 Apr 20:57 2012

Re: [PATCH] mach-exynos: fix ISO C90 warning.

Il Han wrote:
> ISO C90 forbids mixed declarations and code.
> Fix it.
> 
> Signed-off-by: Il Han<corone.il.han <at> gmail.com>
> ---
>   arch/arm/mach-exynos/common.c |    3 ++-
>   1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index e6cc50e..8614aab 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
>  <at>  <at>  -583,10 +583,11  <at>  <at>  core_initcall(exynos_core_init);
>   #ifdef CONFIG_CACHE_L2X0
>   static int __init exynos4_l2x0_cache_init(void)
>   {
> +	int ret;
> +
>   	if (soc_is_exynos5250())
>   		return 0;
> 
> -	int ret;
>   	ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
>   	if (!ret) {
>   		l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);

Yeah, seems happened wehn merge confilcts resolved.

OK, will apply and if possible, please use following subject form in
(Continue reading)

Kukjin Kim | 2 Apr 21:05 2012

Re: [PATCH] ARM: S3C64XX: Hook up new style regulator-regulator supplies on Cragganmore

Mark Brown wrote:
> The regulator API now allows supplies used by regulators to be specified
> as normal supplies - provide the hookup for that mechanism on Cragganmore.
> 
> Signed-off-by: Mark Brown<broonie <at> opensource.wolfsonmicro.com>
> ---
>   arch/arm/mach-s3c64xx/mach-crag6410.c |   18 ++++++++++++++++++
>   1 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c
> index 02fd009..4ee0249 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
>  <at>  <at>  -306,6 +306,24  <at>  <at>  static struct regulator_consumer_supply wallvdd_consumers[] = {
>   	REGULATOR_SUPPLY("SPKVDD2", "1-001a"),
>   	REGULATOR_SUPPLY("SPKVDDL", "1-001a"),
>   	REGULATOR_SUPPLY("SPKVDDR", "1-001a"),
> +
> +	REGULATOR_SUPPLY("DC1VDD", "0-0034"),
> +	REGULATOR_SUPPLY("DC2VDD", "0-0034"),
> +	REGULATOR_SUPPLY("DC3VDD", "0-0034"),
> +	REGULATOR_SUPPLY("LDO1VDD", "0-0034"),
> +	REGULATOR_SUPPLY("LDO2VDD", "0-0034"),
> +	REGULATOR_SUPPLY("LDO4VDD", "0-0034"),
> +	REGULATOR_SUPPLY("LDO5VDD", "0-0034"),
> +	REGULATOR_SUPPLY("LDO6VDD", "0-0034"),
> +	REGULATOR_SUPPLY("LDO7VDD", "0-0034"),
> +	REGULATOR_SUPPLY("LDO8VDD", "0-0034"),
> +	REGULATOR_SUPPLY("LDO9VDD", "0-0034"),
> +	REGULATOR_SUPPLY("LDO10VDD", "0-0034"),
(Continue reading)

Kukjin Kim | 2 Apr 21:08 2012

Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support

Chris Ball wrote:
> Hi Kukjin,
>
Hi,

Sorry for late response.

[...]

>
> I can't send the tree as it is to Linus now, because Arnd has asked us
> to hold off on these device tree bindings and work with the unified
> bindings he's proposing instead.  (Rebasing to drop that patch will
> introduce new conflicts.)
>
OK, I see.

> I'm going to send Mark Brown's two patches to Linus now, even though it
> will cause a conflict in -next.  The rest (other than the device tree
> bindings) are mergable after -rc1, because they're fixes, so we'll
> eventually get everything except DT in to 3.4.  I think you should
> just drop this patchset from your tree in linux-next entirely now.
>
Yep, I dropped it in my -next.

Thanks.

Best regards,
Kgene.
--
(Continue reading)


Gmane