Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

[Jingoo Han]

On Thursday, April 24, 2014 3:40 PM, Vivek Gautam wrote:
> On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han  wrote:
> > On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
> >> On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
> >> > On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
> >> > >
> >> > > Facilitate getting required 3.3V and 1.0V VDD supply for
> >> > > OHCI controller on Exynos.
> >> > >
> >> > > With patches for regulators' nodes merged in 3.15:
> >> > > c8c253f ARM: dts: Add regulator entries to smdk5420
> >> > > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> >> > >
> >> > > certain perripherals will now need to ensure that,
> >> > > they request VDD regulators in their drivers, and enable
> >> > > them so as to make them working.
> >> > >
> >> > > Signed-off-by: Vivek Gautam 
> >> > > Cc: Jingoo Han 
> >> > > ---
> >> > >
> >> > > Based on 'usb-next' branch of Greg's usb tree.
> >> > >
> >> > >  drivers/usb/host/ohci-exynos.c |   47
> >> > > 
> >> > >  1 file changed, 47 insertions(+)
> >> > >
> >> > > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
> >> > > exynos.c
> >> > > index 68588d8..e2e72a8 100644
> >> > > --- a/drivers/usb/host/ohci-exynos.c
> >> > > +++ b/drivers/usb/host/ohci-exynos.c
> 
> [snip]
> 
> >> > > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
> >> > > *pdev)
> >> > >   exynos_ohci->otg = phy->otg;
> >> > >   }
> >> > >
> >> > > + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> >> > > + if (IS_ERR(exynos_ohci->vdd33)) {
> >> > > + err = PTR_ERR(exynos_ohci->vdd33);
> >> > > + goto fail_regulator1;
> >> > > + }
> >> > > + err = regulator_enable(exynos_ohci->vdd33);
> >> > > + if (err) {
> >> > > + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> >> > > + goto fail_regulator1;
> >> > > + }
> >> > > +
> >> > > + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> >> > > + if (IS_ERR(exynos_ohci->vdd10)) {
> >> > > + err = PTR_ERR(exynos_ohci->vdd10);
> >> > > + goto fail_regulator2;
> >> > > + }
> >> > > + err = regulator_enable(exynos_ohci->vdd10);
> >> > > + if (err) {
> >> > > + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> >> > > + goto fail_regulator2;
> >> > > + }
> >> > > +
> >> >
> >> > Do we need to skip regulator settings together with PHY configuration
> >> > in case of exynos5440?
> >>
> >> Oh, right. In the case of exynos5440, regulator settings is not
> >> necessary. Vivek, would you fix it in order skip regulator settings
> >> in exynos5440? It also applies to ehci-exynos.
> >
> > Sorry, in the case of exynos5440, this patch already skips
> > regulator settings.
> >
> > In the case of exynos5440, there is no need to set PHY setting
> > and regulator setting.
> 
> Right, in case of exynos5440, we are skipping PHY setting and regulator 
> setting.
> Actually i had missed taking into account 5440, so just curious. Do we
> really not need a regulator
> settings for Exynos5440 ?

To be more specific, there is no regulator on ssdk5440 board
which is the Exynos5440-based board.

Best regards,
Jingoo Han

> > How about making regulator setting "optional"?
> > Then, regulator setting can be done, only when regulator
> > is supported.
> 
> True, so with Exynos5440 not needing the regulator, we should make the
> regulator settings optional.

[.]

> Thanks for the suggestion.
> I will make the required changes, and post the patchset again.

OK, I see.
Thank you for accepting my suggestion.

Best regards,
Jingoo Han

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: S3C24XX: remove SAMSUNG_CLOCK remnants after ccf conversion

[Heiko Stübner]

This finally removes all remaining SAMSUNG_CLOCK conditional code
from s3c24xx architectures.

Signed-off-by: Heiko Stuebner 
---
This is of course meant to go on top of the s3c2410 ccf conversion

 arch/arm/mach-s3c24xx/Kconfig |  5 -
 arch/arm/mach-s3c24xx/common.c| 17 -
 arch/arm/mach-s3c24xx/cpufreq-utils.c |  6 --
 arch/arm/mach-s3c24xx/mach-anubis.c   | 27 ---
 arch/arm/mach-s3c24xx/mach-bast.c | 27 ---
 arch/arm/mach-s3c24xx/mach-osiris.c   | 27 ---
 arch/arm/mach-s3c24xx/mach-rx1950.c   | 14 --
 arch/arm/mach-s3c24xx/mach-vr1000.c   | 27 ---
 arch/arm/mach-s3c24xx/pm.c| 12 
 9 files changed, 162 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 77b0fb5..4500802 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -265,7 +265,6 @@ config ARCH_BAST
select ISA
select MACH_BAST_IDE
select S3C2410_IOTIMING if ARM_S3C2410_CPUFREQ
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
@@ -347,7 +346,6 @@ config MACH_TCT_HAMMER
 config MACH_VR1000
bool "Thorcom VR1000"
select MACH_BAST_IDE
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
@@ -533,7 +531,6 @@ config MACH_ANUBIS
bool "Simtec Electronics ANUBIS"
select HAVE_PATA_PLATFORM
select S3C2440_XTAL_1200
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_USB_HOST
@@ -574,7 +571,6 @@ config MACH_OSIRIS
bool "Simtec IM2440D20 (OSIRIS) module"
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_1200
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_NAND
@@ -646,7 +642,6 @@ config MACH_RX1950
select PM_H1940 if PM
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_16934400
-   select S3C24XX_DCLK if SAMSUNG_CLOCK
select S3C24XX_COMMON_DCLK if COMMON_CLK
select S3C24XX_PWM
select S3C_DEV_NAND
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 600a1be..c0763b8 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -307,23 +307,6 @@ struct s3c24xx_uart_resources s3c2410_uart_resources[] 
__initdata = {
},
 };
 
-/* initialise all the clocks */
-
-#ifdef CONFIG_SAMSUNG_CLOCK
-void __init_or_cpufreq s3c24xx_setup_clocks(unsigned long fclk,
-  unsigned long hclk,
-  unsigned long pclk)
-{
-   clk_upll.rate = s3c24xx_get_pll(__raw_readl(S3C2410_UPLLCON),
-   clk_xtal.rate);
-
-   clk_mpll.rate = fclk;
-   clk_h.rate = hclk;
-   clk_p.rate = pclk;
-   clk_f.rate = fclk;
-}
-#endif
-
 #if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2412) || \
defined(CONFIG_CPU_S3C2440) || defined(CONFIG_CPU_S3C2442)
 static struct resource s3c2410_dma_resource[] = {
diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c 
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index c1b7508..d4d9514 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
@@ -61,12 +61,6 @@ void s3c2410_cpufreq_setrefresh(struct s3c_cpufreq_config 
*cfg)
  */
 void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
 {
-#ifdef CONFIG_SAMSUNG_CLOCK
-   __raw_writel(cfg->pll.driver_data, S3C2410_MPLLCON);
-#endif
-
-#ifdef CONFIG_COMMON_CLK
if (!IS_ERR(cfg->mpll))
clk_set_rate(cfg->mpll, cfg->pll.frequency);
-#endif
 }
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c 
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 7a0d83b..e053581 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -364,16 +364,6 @@ static struct platform_device *anubis_devices[] __initdata 
= {
&anubis_device_sm501,
 };
 
-#ifdef CONFIG_SAMSUNG_CLOCK
-static struct clk *anubis_clocks[] __initdata = {
-   &s3c24xx_dclk0,
-   &s3c24xx_dclk1,
-   &s3c24xx_clkout0,
-   &s3c24xx_clkout1,
-   &s3c24xx_uclk,
-};
-#endif
-
 /* I2C devices. */
 
 static struct i2c_board_info anubis_i2c_devs[] __initdata = {
@@ -396,23 +386,6 @@ static struct s3c24xx_audio_simtec_pdata __initdata 
anubis_audio = {
 
 static void __init anubis_map_io(void)
 {
-#ifdef CONFIG_SAMSUNG_CLOCK
-   /* initialise the clocks */
-
-   s3c24xx_dclk0.parent = &clk_upll;
-   s3c24xx

Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

[Vivek Gautam]

Hi Jingoo,


On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han  wrote:
> On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
>> On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
>> > On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
>> > >
>> > > Facilitate getting required 3.3V and 1.0V VDD supply for
>> > > OHCI controller on Exynos.
>> > >
>> > > With patches for regulators' nodes merged in 3.15:
>> > > c8c253f ARM: dts: Add regulator entries to smdk5420
>> > > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
>> > >
>> > > certain perripherals will now need to ensure that,
>> > > they request VDD regulators in their drivers, and enable
>> > > them so as to make them working.
>> > >
>> > > Signed-off-by: Vivek Gautam 
>> > > Cc: Jingoo Han 
>> > > ---
>> > >
>> > > Based on 'usb-next' branch of Greg's usb tree.
>> > >
>> > >  drivers/usb/host/ohci-exynos.c |   47
>> > > 
>> > >  1 file changed, 47 insertions(+)
>> > >
>> > > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
>> > > exynos.c
>> > > index 68588d8..e2e72a8 100644
>> > > --- a/drivers/usb/host/ohci-exynos.c
>> > > +++ b/drivers/usb/host/ohci-exynos.c

[snip]

>> > > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
>> > > *pdev)
>> > >   exynos_ohci->otg = phy->otg;
>> > >   }
>> > >
>> > > + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
>> > > + if (IS_ERR(exynos_ohci->vdd33)) {
>> > > + err = PTR_ERR(exynos_ohci->vdd33);
>> > > + goto fail_regulator1;
>> > > + }
>> > > + err = regulator_enable(exynos_ohci->vdd33);
>> > > + if (err) {
>> > > + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
>> > > + goto fail_regulator1;
>> > > + }
>> > > +
>> > > + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
>> > > + if (IS_ERR(exynos_ohci->vdd10)) {
>> > > + err = PTR_ERR(exynos_ohci->vdd10);
>> > > + goto fail_regulator2;
>> > > + }
>> > > + err = regulator_enable(exynos_ohci->vdd10);
>> > > + if (err) {
>> > > + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
>> > > + goto fail_regulator2;
>> > > + }
>> > > +
>> >
>> > Do we need to skip regulator settings together with PHY configuration
>> > in case of exynos5440?
>>
>> Oh, right. In the case of exynos5440, regulator settings is not
>> necessary. Vivek, would you fix it in order skip regulator settings
>> in exynos5440? It also applies to ehci-exynos.
>
> Sorry, in the case of exynos5440, this patch already skips
> regulator settings.
>
> In the case of exynos5440, there is no need to set PHY setting
> and regulator setting.

Right, in case of exynos5440, we are skipping PHY setting and regulator setting.
Actually i had missed taking into account 5440, so just curious. Do we
really not need a regulator
settings for Exynos5440 ?

>
> How about making regulator setting "optional"?
> Then, regulator setting can be done, only when regulator
> is supported.

True, so with Exynos5440 not needing the regulator, we should make the
regulator settings optional.

>
> exynos_ohci_probe()
> exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> if (IS_ERR(exynos_ohci->vdd33)) {
> dev_err(&pdev->dev, "Failed to get VDD33 supply\n");
> } else {
> err = regulator_enable(exynos_ohci->vdd33);
> if (err) {
> dev_err(&pdev->dev, "Failed to enable VDD33 
> supply\n");
> goto fail_regulator1;
> }
> }
>
> exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> if (IS_ERR(exynos_ohci->vdd10)) {
> dev_err(&pdev->dev, "Failed to get VDD10 supply\n");
> } else {
> err = regulator_enable(exynos_ohci->vdd10);
> if (err) {
> dev_err(&pdev->dev, "Failed to enable VDD10 
> supply\n");
> goto fail_regulator2;
> }
> }
>
> In this case, suspend/resume can be fixed as below.
>
> exynos_ohci_suspend()
> if (exynos_ohci->vdd10)
> regulator_disable(exynos_ohci->vdd10);
> if (exynos_ohci->vdd33)
> regulator_disable(exynos_ohci->vdd33);
>
> exynos_ohci_resume()
>
> if (exynos_ohci->vdd33) {
> ret = regulator_enable(exynos_ohci->vdd33);
> if (ret) {
> dev_err(dev, "Failed to enable VDD33 supply\n");
> return ret;
> }
> }
> if (exynos_ohci->vdd10) {
> ret = regulator_enable(exynos_ohci->vdd10);
> if (ret) {
> dev_err(dev, "Failed to enable VDD10 supply\n");
> return ret;
> }
> }

Thanks for the suggestion.
I will make the required changes, and post the patchset 

Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

[Vivek Gautam]

Hi,


On Thu, Apr 24, 2014 at 6:08 AM, Anton Tikhomirov
 wrote:
> Hi,
>
>> Hi,
>>
>> > -Original Message-
>> > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>> > ow...@vger.kernel.org] On Behalf Of Vivek Gautam
>> > Sent: Monday, April 21, 2014 9:17 PM
>> >
>> > Facilitate getting required 3.3V and 1.0V VDD supply for
>> > OHCI controller on Exynos.
>> >
>> > With patches for regulators' nodes merged in 3.15:
>> > c8c253f ARM: dts: Add regulator entries to smdk5420
>> > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
>> >
>> > certain perripherals will now need to ensure that,
>> > they request VDD regulators in their drivers, and enable
>> > them so as to make them working.
>> >
>> > Signed-off-by: Vivek Gautam 
>> > Cc: Jingoo Han 
>> > ---
>> >
>> > Based on 'usb-next' branch of Greg's usb tree.
>> >
>> >  drivers/usb/host/ohci-exynos.c |   47
>> > 
>> >  1 file changed, 47 insertions(+)
>> >
>> > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
>> > exynos.c
>> > index 68588d8..e2e72a8 100644
>> > --- a/drivers/usb/host/ohci-exynos.c
>> > +++ b/drivers/usb/host/ohci-exynos.c

[snip]

>> >  static void exynos_ohci_phy_enable(struct platform_device *pdev)
>> > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct
>> platform_device
>> > *pdev)
>> > exynos_ohci->otg = phy->otg;
>> > }
>> >
>> > +   exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
>> > +   if (IS_ERR(exynos_ohci->vdd33)) {
>> > +   err = PTR_ERR(exynos_ohci->vdd33);
>> > +   goto fail_regulator1;
>> > +   }
>> > +   err = regulator_enable(exynos_ohci->vdd33);
>> > +   if (err) {
>> > +   dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
>> > +   goto fail_regulator1;
>> > +   }
>> > +
>> > +   exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
>> > +   if (IS_ERR(exynos_ohci->vdd10)) {
>> > +   err = PTR_ERR(exynos_ohci->vdd10);
>> > +   goto fail_regulator2;
>> > +   }
>> > +   err = regulator_enable(exynos_ohci->vdd10);
>> > +   if (err) {
>> > +   dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
>> > +   goto fail_regulator2;
>> > +   }
>> > +
>>
>> Do we need to skip regulator settings together with PHY configuration
>> in case of exynos5440?
>>
>> >  skip_phy:
>> > exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
>> >

[snip]

>> > @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
>> > struct usb_hcd *hcd = dev_get_drvdata(dev);
>> > struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
>> > struct platform_device *pdev= to_platform_device(dev);
>> > +   int ret;
>> > +
>> > +   ret = regulator_enable(exynos_ohci->vdd33);
>> > +   if (ret) {
>> > +   dev_err(dev, "Failed to enable VDD33 supply\n");
>> > +   return ret;
>>
>> Not sure, but shall we continue resuming and do everything
>> we can in case of error? At least it will avoid
>> WARN_ON(clk->enable_count == 0) on next system suspend.

True, i will modify it.
>
> On the other hand, if power is not applied to the controller,
> register access in ohci_resume() may lead to undefined behavior.
> What's your opinion?

AFA i think, it is obvious that the regulators would not work without
a VDD supply.
So the question is, do we have VDD LDOs available on all Exynos
systems for usb ?
>From the schemata of Exynos5250 and Exynos5420 boards, i can see the
required VDD LDOs
for USB. Unfortunately at present i don't have a Exynos4* schemata.

If regulator is not a mandatory, then we can make it option similar to
what Jingoo has also suggested
in subsequent mail.

[snip]


-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] Add sound card node Snow/Peach-pit board

[Tushar Behera]

Related sound card driver has been posted here.
1. [PATCH V2] ASoC: SAMSUNG: Add sound card driver for Snow board
https://lkml.org/lkml/2014/4/23/184

Patch 2 is dependent on Arun's following patch.
2. [PATCH v2] ARM: dts: Add peach-pit board support
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29189.html

Tushar Behera (2):
  ARM: dts: Add sound node for Snow board
  ARM: dts: Add sound node for Peach-pit board

 arch/arm/boot/dts/exynos5250-snow.dts  |   32 
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   31 +++
 2 files changed, 63 insertions(+)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] thermal: samsung: Only update available threshold limits

[Amit Kachhap]

On 4/14/14, Tushar Behera  wrote:
> Currently the threshold limits are updated in 2 stages, once for all
> software trigger levels and again for hardware trip point.
I guess the first stage is bootloader as could not find this in this file.
Anyways the changes looks fine to me.

Acked-by: Amit Daniel Kachhap 

>
> While updating the software trigger levels, it overwrites the threshold
> limit for hardware trip point thereby forcing the Exynos core to issue
> an emergency shutdown.
>
> Updating only the required fields in threshold register fixes this issue.
>
> Signed-off-by: Tushar Behera 
> ---
> Based on v3.15-rc1.
>
>  drivers/thermal/samsung/exynos_tmu.c |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 0d96a51..ffccc89 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -225,6 +225,8 @@ skip_calib_data:
>   trigger_levs++;
>   }
>
> + rising_threshold = readl(data->base + reg->threshold_th0);
> +
>   if (data->soc == SOC_ARCH_EXYNOS4210) {
>   /* Write temperature code for threshold */
>   threshold_code = temp_to_code(data, pdata->threshold);
> @@ -249,6 +251,7 @@ skip_calib_data:
>   ret = threshold_code;
>   goto out;
>   }
> + rising_threshold &= ~(0xff << 8 * i);
>   rising_threshold |= threshold_code << 8 * i;
>   if (pdata->threshold_falling) {
>   threshold_code = temp_to_code(data,
> @@ -281,6 +284,7 @@ skip_calib_data:
>   }
>   if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
>   /* 1-4 level to be assigned in th0 reg */
> + rising_threshold &= ~(0xff << 8 * i);
>   rising_threshold |= threshold_code << 8 * i;
>   writel(rising_threshold,
>   data->base + reg->threshold_th0);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ARM: dts: Add sound node for Peach-pit board

[Tushar Behera]

The audio setup on Peach-pit board is similar to Snow board, hence the
sound-card driver used on Snow board can be reused on Peach-pit board.

Peach-pit board uses MAX98090 audio codec.

Signed-off-by: Tushar Behera 
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   31 
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index fbb0469..1043bd3 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -37,6 +37,13 @@
};
 
pinctrl@1340 {
+   max98090_irq: max98090-irq {
+   samsung,pins = "gpx0-2";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
tpm_irq: tpm-irq {
samsung,pins = "gpx1-0";
samsung,pin-function = <0>;
@@ -143,6 +150,19 @@
};
};
 
+   i2c@12CD {
+   status = "okay";
+
+   max98090: codec@10 {
+   compatible = "maxim,max98090";
+   reg = <0x10>;
+   interrupts = <2 0>;
+   interrupt-parent = <&gpx0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&max98090_irq>;
+   };
+   };
+
spi@12d3 {
status = "okay";
samsung,spi-src-clk = <0>;
@@ -179,4 +199,15 @@
watchdog@101D {
timeout-sec = <32>;
};
+
+   i2s0: i2s@0383 {
+   status = "okay";
+   };
+
+   sound {
+   compatible = "google,snow-audio-max98090";
+
+   samsung,i2s-controller = <&i2s0>;
+   samsung,audio-codec = <&max98090>;
+   };
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ARM: dts: Add sound node for Snow board

[Tushar Behera]

The audio codec on Snow board, MAX98095 is connected on I2C7 bus.
Also it requires the GPX1-7 line to be pulled up.

Updated Snow DTS file to incorporate above changes and added a
sound node to instantiate the I2S-based sound card.

Signed-off-by: Tushar Behera 
---
 arch/arm/boot/dts/exynos5250-snow.dts |   32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1bc9b50..f63df3c 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -196,6 +196,38 @@
};
};
 
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   max98095-en-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpx1 7 0>;
+   enable-active-high;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   };
+
+   i2c@12CD {
+   max98095: codec@11 {
+   compatible = "maxim,max98095";
+   reg = <0x11>;
+   };
+   };
+
+   i2s0: i2s@0383 {
+   status = "okay";
+   };
+
+   sound {
+   compatible = "google,snow-audio-max98095";
+
+   samsung,i2s-controller = <&i2s0>;
+   samsung,audio-codec = <&max98095>;
+   };
+
usb@1211 {
samsung,vbus-gpio = <&gpx1 1 0>;
};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: dts: Add peach-pit board support

[Tushar Behera]

On 04/24/2014 09:47 AM, Arun Kumar K wrote:
> Adds the google peach-pit board dts file which uses
> exynos5420 SoC.
> 
> Signed-off-by: Arun Kumar K 
> Signed-off-by: Doug Anderson 

Looks good.

Reviewed-by: Tushar Behera 

> ---
> Changes from v1
> ---
> - Addressed review comments from Doug, Sachin & Tushar
> - Removed adc and lid-switch nodes
> ---
>  arch/arm/boot/dts/Makefile |1 +
>  arch/arm/boot/dts/exynos5420-peach-pit.dts |  182 
> 
>  2 files changed, 183 insertions(+)
>  create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 35c146f..3220e29 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
>   exynos5250-smdk5250.dtb \
>   exynos5250-snow.dtb \
>   exynos5420-arndale-octa.dtb \
> + exynos5420-peach-pit.dtb \
>   exynos5420-smdk5420.dtb \
>   exynos5440-sd5v1.dtb \
>   exynos5440-ssdk5440.dtb
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> new file mode 100644
> index 000..fbb0469
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -0,0 +1,182 @@
> +/*
> + * Google Peach Pit Rev 6+ board device tree source
> + *
> + * Copyright (c) 2014 Google, Inc
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +#include 
> +#include 
> +#include "exynos5420.dtsi"
> +
> +/ {
> + model = "Google Peach Pit Rev 6+";
> +
> + compatible = "google,pit-rev16",
> + "google,pit-rev15", "google,pit-rev14",
> + "google,pit-rev13", "google,pit-rev12",
> + "google,pit-rev11", "google,pit-rev10",
> + "google,pit-rev9", "google,pit-rev8",
> + "google,pit-rev7", "google,pit-rev6",
> + "google,pit", "google,peach","samsung,exynos5420",
> + "samsung,exynos5";
> +
> + memory {
> + reg = <0x2000 0x8000>;
> + };
> +
> + fixed-rate-clocks {
> + oscclk {
> + compatible = "samsung,exynos5420-oscclk";
> + clock-frequency = <2400>;
> + };
> + };
> +
> + pinctrl@1340 {
> + tpm_irq: tpm-irq {
> + samsung,pins = "gpx1-0";
> + samsung,pin-function = <0>;
> + samsung,pin-pud = <0>;
> + samsung,pin-drv = <0>;
> + };
> +
> + power_key_irq: power-key-irq {
> + samsung,pins = "gpx1-2";
> + samsung,pin-function = <0>;
> + samsung,pin-pud = <0>;
> + samsung,pin-drv = <0>;
> + };
> + };
> +
> + pinctrl@1401 {
> + spi_flash_cs: spi-flash-cs {
> + samsung,pins = "gpa2-5";
> + samsung,pin-function = <1>;
> + samsung,pin-pud = <0>;
> + samsung,pin-drv = <3>;
> + };
> +
> + backlight_pwm: backlight-pwm {
> + samsung,pins = "gpb2-0";
> + samsung,pin-function = <2>;
> + samsung,pin-pud = <0>;
> + samsung,pin-drv = <0>;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&power_key_irq>;
> +
> + power {
> + label = "Power";
> + gpios = <&gpx1 2 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + gpio-key,wakeup;
> + };
> + };
> +
> + rtc@101E {
> + status = "okay";
> + };
> +
> + serial@12C3 {
> + status = "okay";
> + };
> +
> + mmc@1220 {
> + status = "okay";
> + num-slots = <1>;
> + broken-cd;
> + caps2-mmc-hs200-1_8v;
> + supports-highspeed;
> + non-removable;
> + card-detect-delay = <200>;
> + clock-frequency = <4>;
> + samsung,dw-mshc-ciu-div = <3>;
> + samsung,dw-mshc-sdr-timing = <0 4>;
> + samsung,dw-mshc-ddr-timing = <0 2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
> +
> + slot@0 {
> + reg = <0>;
> + bus-width = <8>;
> + };
> + };
> +
> + mmc@1222 {
> + status = "okay";
> + num-slots = <1>;
> + supports-highspeed;
> +   

[PATCH v2] ARM: dts: Add peach-pit board support

[Arun Kumar K]

Adds the google peach-pit board dts file which uses
exynos5420 SoC.

Signed-off-by: Arun Kumar K 
Signed-off-by: Doug Anderson 
---
Changes from v1
---
- Addressed review comments from Doug, Sachin & Tushar
- Removed adc and lid-switch nodes
---
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts |  182 
 2 files changed, 183 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..3220e29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
+   exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..fbb0469
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,182 @@
+/*
+ * Google Peach Pit Rev 6+ board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include "exynos5420.dtsi"
+
+/ {
+   model = "Google Peach Pit Rev 6+";
+
+   compatible = "google,pit-rev16",
+   "google,pit-rev15", "google,pit-rev14",
+   "google,pit-rev13", "google,pit-rev12",
+   "google,pit-rev11", "google,pit-rev10",
+   "google,pit-rev9", "google,pit-rev8",
+   "google,pit-rev7", "google,pit-rev6",
+   "google,pit", "google,peach","samsung,exynos5420",
+   "samsung,exynos5";
+
+   memory {
+   reg = <0x2000 0x8000>;
+   };
+
+   fixed-rate-clocks {
+   oscclk {
+   compatible = "samsung,exynos5420-oscclk";
+   clock-frequency = <2400>;
+   };
+   };
+
+   pinctrl@1340 {
+   tpm_irq: tpm-irq {
+   samsung,pins = "gpx1-0";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   power_key_irq: power-key-irq {
+   samsung,pins = "gpx1-2";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+   };
+
+   pinctrl@1401 {
+   spi_flash_cs: spi-flash-cs {
+   samsung,pins = "gpa2-5";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <3>;
+   };
+
+   backlight_pwm: backlight-pwm {
+   samsung,pins = "gpb2-0";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&power_key_irq>;
+
+   power {
+   label = "Power";
+   gpios = <&gpx1 2 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   gpio-key,wakeup;
+   };
+   };
+
+   rtc@101E {
+   status = "okay";
+   };
+
+   serial@12C3 {
+   status = "okay";
+   };
+
+   mmc@1220 {
+   status = "okay";
+   num-slots = <1>;
+   broken-cd;
+   caps2-mmc-hs200-1_8v;
+   supports-highspeed;
+   non-removable;
+   card-detect-delay = <200>;
+   clock-frequency = <4>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <0 4>;
+   samsung,dw-mshc-ddr-timing = <0 2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
+
+   slot@0 {
+   reg = <0>;
+   bus-width = <8>;
+   };
+   };
+
+   mmc@1222 {
+   status = "okay";
+   num-slots = <1>;
+   supports-highspeed;
+   card-detect-delay = <200>;
+   clock-frequency = <4>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <2 3>;
+   samsung,dw-ms

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

Hi Andrzej,

Thank you for kind comments.

On 04/23/2014 07:16 PM, Andrzej Hajda wrote:

Hi YoungJun,


On 04/21/2014 02:28 PM, YoungJun Cho wrote:

This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.

Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU timings relevant properties from FIMD DT
   (commented by Laurent Pinchart, Andrzej Hajda)

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
  drivers/gpu/drm/panel/Kconfig |7 +
  drivers/gpu/drm/panel/Makefile|1 +
  drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 +
  3 files changed, 577 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..be1392e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS

+config DRM_PANEL_S6E3FA0
+   tristate "S6E3FA0 DSI command mode panel"
+   depends on DRM && DRM_PANEL
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
  endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
  obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
  obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c 
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 000..1282678
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
+/*
+ * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+
+#include 
+#include 



#include  should be enough.


Ok, I'll check.





+#include 
+
+#include 
+#include 
+#include 
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+struct s6e3fa0 {
+   struct device   *dev;
+   struct drm_panelpanel;
+
+   struct regulator_bulk_data  supplies[2];
+   struct gpio_desc*reset_gpio;
+   struct gpio_desc*det_gpio;
+   struct gpio_desc*te_gpio;
+   struct videomodevm;
+   struct drm_panel_cpu_timingscpu_timings;
+
+   unsigned intpower_on_delay;
+   unsigned intreset_delay;
+   unsigned intinit_delay;
+   unsigned intwidth_mm;
+   unsigned intheight_mm;
+
+   unsigned char   id;
+   unsigned char   vddm;
+   unsigned intbrightness;
+};
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
+
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+   {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+   {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+   {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+   {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+   {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+   {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+   {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
+   {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+   {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+   {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
+   {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+   {0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+   {0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+   {0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+   {0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x49, 0x03}, {0x4a, 0x02},
+   {0x4b, 0x01}, {0x4c, 0x40}, {0x4d, 0x41}, {0x4e, 0x42}, {0x4f, 0x43},
+   {0x50, 0x44}, {0x51, 0x45}, {0x52, 0x46}, {0x53, 0x47}, {0x54, 0x48},
+   {0x55, 0x49}, {0x56, 0x4a}, {0x57, 0x4b}, {0x58, 0x4c}, {0x59, 0x4d},
+   {0x5a, 0x4e}, {0x5b, 0x4f}, {0x5c, 0x50}, {0x5d, 0x51}, {0x5e, 0x52},
+   {0x5f, 0x53}, {0x60, 0x54}, {0x61, 0x55}, {0x62, 0x56}, {0x63, 0x57},
+   {0x64, 0x5

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

Hi Andrzej,

On 04/23/2014 10:33 PM, Andrzej Hajda wrote:

On 04/23/2014 02:55 PM, Laurent Pinchart wrote:

Hi Andrzej,

On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote:

On 04/23/2014 01:34 PM, Laurent Pinchart wrote:

On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:

On 04/21/2014 02:28 PM, YoungJun Cho wrote:

This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu timings.

Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent
Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT

   (commeted by Laurent Pinchart, Andrzej Hajda)

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---

  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63
  +++

1 file changed, 63 insertions(+)

  create mode 100644
  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>

diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
mode 100644
index 000..9eeb38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,63 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+  - compatible: "samsung,s6e3fa0"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpio: a GPIO spec for the reset pin
+  - det-gpio: a GPIO spec for the OLED detection pin
+  - te-gpio: a GPIO spec for the TE pin
+  - display-timings: timings for the connected panel as described by
[1]

Which properties of display-timings are relevant for CPU mode?
I guess width and height. Anything more?


+  - cpu-timings: CPU interface timings for the connected panel, and it
contains
+following optional properties.
+  - cs-setup: clock cycles for the active period of address
signal
+enable until chip select is enable in CPU interface
+  - wr-setup: clock cycles for the active period of CS signal
enable
+until write signal is enable in CPU interface
+  - wr-act: clock cycles for the active period of CS enable in
CPU
+interface

What about calling this property wr-active ? I had called this wr-cycle in
a previous implementation, that could be an option as well.


+  - wr-hold: clock cycles for the active period of CS disable
until
+write signal is disable in CPU interface

cpu-timings name does not sound to be related to display.
I wonder if it would not be better to merge cpu-timings into
display-timings but this will require more discussion I guess.

The panel has a memory-like interface with chip select, read/write and
access strobe, address (1 bit) and data signals. The interface is defined
in the MIPI DBI specification (a quick search turned up
http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might
be direct PDF downloads available), even if some panels implement a
similar interface that predates MIPI DBI (with names such as i80 or
SYS-80 probably due to the similarities with the 8051 external bus).

The cpu-timings properties describe the read and write access timings for
those signals, unrelated to the display video timings. I thus believe that
they should be separate from the display timings. We will probably need to
add properties for the read signal as well, but that can be done later.

cpu-timings suggests these timings are for CPU, but they are for display
panel in CPU mode.
I though rather about something like display-cpu-timings or i80-timings,
just to avoid confusion.

mipi-dbi-timings maybe ?


It looks OK.


Isn't it too generic? I prefer cpu-mode-timings.



I guess only hactive, and vactive props of display-timings are used,
maybe some flags?
I wonder if it would not be better to drop display-timings node
and place all props into mipi-dbi-timings or mipi-dbi-settings node.
Or rather all timings props should be put into port/endpoint node with
or without
any container node.


The current 'display-timings' is for video mode interface,
but cpu mode interface requires it.

If we use mipi-dbi-timings, we should change previous video mode
relevant ones at all.

Thank you.
Best regards YJ



Regards
Andrzej




If you want to stay with separate node please consider to make it
optional as whole node or make some properties required. Making node
required with all sub-properties optional is weird.
By the way I hope all timings properties are generic for CPU mode,
if not they should be prefixed by vendor or model.

The timings description should be pretty generic I believe, especially
given that the interface is standardized by the MIPI alliance. Could you
have a quick look at the spec and share your opinion ?


+
+Optional pro

Re: [PATCH] thermal: samsung: Only update available threshold limits

[Tushar Behera]

On 04/14/2014 11:08 AM, Tushar Behera wrote:
> Currently the threshold limits are updated in 2 stages, once for all
> software trigger levels and again for hardware trip point.
> 
> While updating the software trigger levels, it overwrites the threshold
> limit for hardware trip point thereby forcing the Exynos core to issue
> an emergency shutdown.
> 
> Updating only the required fields in threshold register fixes this issue.
> 
> Signed-off-by: Tushar Behera 
> ---
> Based on v3.15-rc1.
> 
>  drivers/thermal/samsung/exynos_tmu.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 0d96a51..ffccc89 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -225,6 +225,8 @@ skip_calib_data:
>   trigger_levs++;
>   }
>  
> + rising_threshold = readl(data->base + reg->threshold_th0);
> +
>   if (data->soc == SOC_ARCH_EXYNOS4210) {
>   /* Write temperature code for threshold */
>   threshold_code = temp_to_code(data, pdata->threshold);
> @@ -249,6 +251,7 @@ skip_calib_data:
>   ret = threshold_code;
>   goto out;
>   }
> + rising_threshold &= ~(0xff << 8 * i);
>   rising_threshold |= threshold_code << 8 * i;
>   if (pdata->threshold_falling) {
>   threshold_code = temp_to_code(data,
> @@ -281,6 +284,7 @@ skip_calib_data:
>   }
>   if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
>   /* 1-4 level to be assigned in th0 reg */
> + rising_threshold &= ~(0xff << 8 * i);
>   rising_threshold |= threshold_code << 8 * i;
>   writel(rising_threshold,
>   data->base + reg->threshold_th0);
> 

Adding Amit to get Samsung specific review.

-- 
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

Hi Laurent,

Thank you for comments.

On 04/23/2014 08:34 PM, Laurent Pinchart wrote:

Hi Andrzej,

On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:

On 04/21/2014 02:28 PM, YoungJun Cho wrote:

This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu timings.

Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT

   (commeted by Laurent Pinchart, Andrzej Hajda)

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---

  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 +++
1 file changed, 63 insertions(+)
  create mode 100644
  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
mode 100644
index 000..9eeb38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,63 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+  - compatible: "samsung,s6e3fa0"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpio: a GPIO spec for the reset pin
+  - det-gpio: a GPIO spec for the OLED detection pin
+  - te-gpio: a GPIO spec for the TE pin
+  - display-timings: timings for the connected panel as described by [1]


Which properties of display-timings are relevant for CPU mode?
I guess width and height. Anything more?


+  - cpu-timings: CPU interface timings for the connected panel, and it
contains
+following optional properties.
+  - cs-setup: clock cycles for the active period of address
signal
+enable until chip select is enable in CPU interface
+  - wr-setup: clock cycles for the active period of CS signal
enable
+until write signal is enable in CPU interface
+  - wr-act: clock cycles for the active period of CS enable in
CPU
+interface


What about calling this property wr-active ? I had called this wr-cycle in a
previous implementation, that could be an option as well.


Okay, I'll use wr-active. It's better.




+  - wr-hold: clock cycles for the active period of CS disable
until
+write signal is disable in CPU interface


cpu-timings name does not sound to be related to display.
I wonder if it would not be better to merge cpu-timings into
display-timings but this will require more discussion I guess.


The panel has a memory-like interface with chip select, read/write and access
strobe, address (1 bit) and data signals. The interface is defined in the MIPI
DBI specification (a quick search turned up
http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be
direct PDF downloads available), even if some panels implement a similar
interface that predates MIPI DBI (with names such as i80 or SYS-80 probably
due to the similarities with the 8051 external bus).

The cpu-timings properties describe the read and write access timings for
those signals, unrelated to the display video timings. I thus believe that
they should be separate from the display timings. We will probably need to add
properties for the read signal as well, but that can be done later.


Yes, as I wrote another thread before, this cpu interface timings is
additional one. The video timings is required also.

Thank you.
Best regards YJ




If you want to stay with separate node please consider to make it
optional as whole node or make some properties required. Making node
required with all sub-properties optional is weird.
By the way I hope all timings properties are generic for CPU mode,
if not they should be prefixed by vendor or model.


The timings description should be pretty generic I believe, especially given
that the interface is standardized by the MIPI alliance. Could you have a
quick look at the spec and share your opinion ?


+
+Optional properties:
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   panel@0 {
+   compatible = "samsung,s6e3fa0";
+   reg = <0>;
+   vdd3-supply = <&vcclcd_reg>;
+   vci-supply = <&vlcd_reg>;
+   reset-gpio = <&gpy7 4 0>;
+   det-gpio = <&gpg0 6 0>;
+   te-gpio = <&gpd1 7 0>;
+
+   display-timings {
+   timing0: timing-0 {
+   clock-frequency = <0>;
+  

Re: [PATCH 06/10] ARM: EXYNOS: Add support for mapping PMU base address via DT

[Pankaj Dubey]

Hi Vikas,

On 04/23/2014 10:02 PM, Vikas Sajjan wrote:

Hi,

On Wed, Apr 2, 2014 at 1:20 PM, Pankaj Dubey  wrote:

From: Young-Gun Jang 

Add support for mapping Exynos Power Management Unit (PMU) base address
from device tree. Code will use existing samsung pmu binding information.
This patch also adds "get_exynos_pmubase" a helper function to return mapped 
base
address to various other files under "mach-exynos".

Signed-off-by: Young-Gun Jang 
Signed-off-by: Pankaj Dubey 
---
  arch/arm/mach-exynos/common.h |2 ++
  arch/arm/mach-exynos/exynos.c |   44 +
  2 files changed, 46 insertions(+)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index ff28334..9a55cf6 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -61,4 +61,6 @@ struct exynos_pmu_conf {

  extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);

+extern void __iomem *get_exynos_pmubase(void);
+
  #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index a5e1349..a5127fb 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -35,6 +35,8 @@
  #define L2_AUX_VAL 0x7C470001
  #define L2_AUX_MASK 0xC200

+static void __iomem *exynos_pmu_base __initdata;

Are you sure you want to keep exynos_pmu_base in .init section.
I am seeing a crash in platform_do_lowpower()
I think you should remove __initdata.


Thanks for review and testing.
You are right we do not need __initdata here.
I will take care of this in V2.


+
  static struct map_desc exynos4_iodesc[] __initdata = {
 {
 .virtual= (unsigned long)S3C_VA_SYS,
@@ -245,6 +247,47 @@ void __init exynos_init_late(void)
 exynos_pm_init();
  }

+static char const *exynos_dt_pmu_match[] __initconst = {
+   "samsung,exynos4210-pmu",
+   "samsung,exynos4212-pmu",
+   "samsung,exynos4412-pmu",
+   "samsung,exynos5250-pmu",
+   NULL
+};
+
+static int __init exynos_fdt_map_pmu(unsigned long node,
+   const char *uname, int depth, void *data)
+{
+   struct map_desc iodesc;
+   __be32 *reg;
+   unsigned long len;
+
+   if (of_flat_dt_match(node, exynos_dt_pmu_match)) {
+   phys_addr_t phys_addr;
+   reg = of_get_flat_dt_prop(node, "reg", &len);
+   if (reg == NULL || len != (sizeof(unsigned long) * 2))
+   return 0;
+
+   phys_addr = be32_to_cpu(reg[0]);
+   iodesc.pfn = __phys_to_pfn(phys_addr);
+   iodesc.length = be32_to_cpu(reg[1]) - 1;
+   iodesc.virtual = (unsigned long)S5P_VA_PMU;
+   iodesc.type = MT_DEVICE;
+   iotable_init(&iodesc, 1);
+
+   exynos_pmu_base = ioremap(phys_addr, be32_to_cpu(reg[1]));
+   if (WARN_ON(!exynos_pmu_base))
+   return -EFAULT;
+   }
+
+   return 0;
+}
+
+inline void __iomem *get_exynos_pmubase()
+{
+   return exynos_pmu_base;
+}
+
  static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
 int depth, void *data)
  {
@@ -301,6 +344,7 @@ void __init exynos_init_io(void)
 debug_ll_io_init();

 of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
+   of_scan_flat_dt(exynos_fdt_map_pmu, NULL);

 /* detect cpu id and rev. */
 s5p_init_cpu(S5P_VA_CHIPID);
--
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



--
Best Regards,
Pankaj Dubey

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

Hi Andrzej,

Thank you for comments.

On 04/23/2014 06:02 PM, Andrzej Hajda wrote:

On 04/21/2014 02:28 PM, YoungJun Cho wrote:

This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu timings.

Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT
   (commeted by Laurent Pinchart, Andrzej Hajda)

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 
  1 file changed, 63 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt

diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt 
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 000..9eeb38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,63 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+  - compatible: "samsung,s6e3fa0"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpio: a GPIO spec for the reset pin
+  - det-gpio: a GPIO spec for the OLED detection pin
+  - te-gpio: a GPIO spec for the TE pin
+  - display-timings: timings for the connected panel as described by [1]


Which properties of display-timings are relevant for CPU mode?
I guess width and height. Anything more?


The CPU interface panel also requires hfront-porch, hback-porch,
hsync-len, vfront-porch, vback-porch and vsync-len.




+  - cpu-timings: CPU interface timings for the connected panel, and it contains
+following optional properties.
+  - cs-setup: clock cycles for the active period of address signal
+enable until chip select is enable in CPU interface
+  - wr-setup: clock cycles for the active period of CS signal enable
+until write signal is enable in CPU interface
+  - wr-act: clock cycles for the active period of CS enable in CPU
+interface
+  - wr-hold: clock cycles for the active period of CS disable until
+write signal is disable in CPU interface


cpu-timings name does not sound to be related to display.
I wonder if it would not be better to merge cpu-timings into
display-timings but this will require more discussion I guess.

If you want to stay with separate node please consider to make it
optional as whole node or make some properties required. Making node
required with all sub-properties optional is weird.


Yes, I'll fix.

Thank you.
Best regards YJ


By the way I hope all timings properties are generic for CPU mode,
if not they should be prefixed by vendor or model.

Regards
Andrzej


+
+Optional properties:
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   panel@0 {
+   compatible = "samsung,s6e3fa0";
+   reg = <0>;
+   vdd3-supply = <&vcclcd_reg>;
+   vci-supply = <&vlcd_reg>;
+   reset-gpio = <&gpy7 4 0>;
+   det-gpio = <&gpg0 6 0>;
+   te-gpio = <&gpd1 7 0>;
+
+   display-timings {
+   timing0: timing-0 {
+   clock-frequency = <0>;
+   hactive = <1080>;
+   vactive = <1920>;
+   hfront-porch = <2>;
+   hback-porch = <2>;
+   hsync-len = <1>;
+   vfront-porch = <1>;
+   vback-porch = <4>;
+   vsync-len = <1>;
+   };
+   };
+
+   cpu-timings {
+   cs-setup = <0>;
+   wr-setup = <0>;
+   wr-act = <1>;
+   wr-hold = <0>;
+   };
+   };






--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

[Jingoo Han]

On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
> On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
> > On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
> > >
> > > Facilitate getting required 3.3V and 1.0V VDD supply for
> > > OHCI controller on Exynos.
> > >
> > > With patches for regulators' nodes merged in 3.15:
> > > c8c253f ARM: dts: Add regulator entries to smdk5420
> > > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> > >
> > > certain perripherals will now need to ensure that,
> > > they request VDD regulators in their drivers, and enable
> > > them so as to make them working.
> > >
> > > Signed-off-by: Vivek Gautam 
> > > Cc: Jingoo Han 
> > > ---
> > >
> > > Based on 'usb-next' branch of Greg's usb tree.
> > >
> > >  drivers/usb/host/ohci-exynos.c |   47
> > > 
> > >  1 file changed, 47 insertions(+)
> > >
> > > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
> > > exynos.c
> > > index 68588d8..e2e72a8 100644
> > > --- a/drivers/usb/host/ohci-exynos.c
> > > +++ b/drivers/usb/host/ohci-exynos.c
> > > @@ -18,6 +18,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
> > >   struct clk *clk;
> > >   struct usb_phy *phy;
> > >   struct usb_otg *otg;
> > > + struct regulator *vdd33;
> > > + struct regulator *vdd10;
> > >  };
> > >
> > >  static void exynos_ohci_phy_enable(struct platform_device *pdev)
> > > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
> > > *pdev)
> > >   exynos_ohci->otg = phy->otg;
> > >   }
> > >
> > > + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> > > + if (IS_ERR(exynos_ohci->vdd33)) {
> > > + err = PTR_ERR(exynos_ohci->vdd33);
> > > + goto fail_regulator1;
> > > + }
> > > + err = regulator_enable(exynos_ohci->vdd33);
> > > + if (err) {
> > > + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> > > + goto fail_regulator1;
> > > + }
> > > +
> > > + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> > > + if (IS_ERR(exynos_ohci->vdd10)) {
> > > + err = PTR_ERR(exynos_ohci->vdd10);
> > > + goto fail_regulator2;
> > > + }
> > > + err = regulator_enable(exynos_ohci->vdd10);
> > > + if (err) {
> > > + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> > > + goto fail_regulator2;
> > > + }
> > > +
> >
> > Do we need to skip regulator settings together with PHY configuration
> > in case of exynos5440?
> 
> Oh, right. In the case of exynos5440, regulator settings is not
> necessary. Vivek, would you fix it in order skip regulator settings
> in exynos5440? It also applies to ehci-exynos.

Sorry, in the case of exynos5440, this patch already skips
regulator settings.

In the case of exynos5440, there is no need to set PHY setting
and regulator setting.

How about making regulator setting "optional"?
Then, regulator setting can be done, only when regulator
is supported.

exynos_ohci_probe()
exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
if (IS_ERR(exynos_ohci->vdd33)) {
dev_err(&pdev->dev, "Failed to get VDD33 supply\n");
} else {
err = regulator_enable(exynos_ohci->vdd33);
if (err) {
dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
goto fail_regulator1;
}
}

exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
if (IS_ERR(exynos_ohci->vdd10)) {
dev_err(&pdev->dev, "Failed to get VDD10 supply\n");
} else {
err = regulator_enable(exynos_ohci->vdd10);
if (err) {
dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
goto fail_regulator2;
}
}

In this case, suspend/resume can be fixed as below.

exynos_ohci_suspend()
if (exynos_ohci->vdd10)
regulator_disable(exynos_ohci->vdd10);
if (exynos_ohci->vdd33)
regulator_disable(exynos_ohci->vdd33);

exynos_ohci_resume()

if (exynos_ohci->vdd33) {
ret = regulator_enable(exynos_ohci->vdd33);
if (ret) {
dev_err(dev, "Failed to enable VDD33 supply\n");
return ret;
}
}
if (exynos_ohci->vdd10) {
ret = regulator_enable(exynos_ohci->vdd10);
if (ret) {
dev_err(dev, "Failed to enable VDD10 supply\n");
return ret;
}
}

Best regards,
Jingoo Han

> 
> >
> > >  skip_phy:
> > >   exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
> > >
> > > @@ -154,6 +179,10 @@ fail_add_hcd:
> > >  fail_io:
> > >   clk_disable_unprepare(exynos_o

Re: [RFC v2 PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420

[YoungJun Cho]

Hi Andrzej,

Thank you for comments.

On 04/23/2014 05:29 PM, Andrzej Hajda wrote:

On 04/21/2014 02:28 PM, YoungJun Cho wrote:

The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.

In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  101 ---
  1 file changed, 80 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 179f2fa..fcd577f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@

  #include 
  #include 
+#include 
  #include 
  #include 

@@ -54,9 +55,12 @@

  /* FIFO memory AC characteristic register */
  #define DSIM_PLLCTRL_REG  0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG0x50/* PLL timer register */
  #define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */
  #define DSIM_PHYACCHR1_REG0x58/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG   0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG0x68
+#define DSIM_PHYTIMING2_REG0x6c

  /* DSIM_STATUS */
  #define DSIM_STOP_STATE_DAT(x)(((x) & 0xf) << 0)
@@ -233,6 +237,12 @@ struct exynos_dsi_transfer {
  #define DSIM_STATE_INITIALIZEDBIT(1)
  #define DSIM_STATE_CMD_LPMBIT(2)

+struct exynos_dsi_driver_data {
+   unsigned int plltmr_reg;
+
+   unsigned int has_freqband:1;
+};
+
  struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
@@ -262,11 +272,39 @@ struct exynos_dsi {

spinlock_t transfer_lock; /* protects transfer_list */
struct list_head transfer_list;
+
+   struct exynos_dsi_driver_data *driver_data;
  };

  #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
  #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)

+static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
+   .plltmr_reg = 0x50,
+   .has_freqband = 1,
+};
+
+static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
+   .plltmr_reg = 0x58,
+};
+
+static struct of_device_id exynos_dsi_of_match[] = {
+   { .compatible = "samsung,exynos4210-mipi-dsi",
+ .data = &exynos4_dsi_driver_data },
+   { .compatible = "samsung,exynos5420-mipi-dsi",
+ .data = &exynos5_dsi_driver_data },
+   { }
+};


I wonder if it wouldn't be better to use "samsung,exynos5410-mipi-dsi"
compatible and distinguish 5410 and 5420 by DSIM_VERSION register.



That's because I have only Exynos5420 SoC based target,
so made DT for that and tested it only.

But it seems to be no problem to use exynos5410 compatible at least
for the dsi device :).

I'll try.




+
+static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
+   struct platform_device *pdev)
+{
+   const struct of_device_id *of_id =
+   of_match_device(exynos_dsi_of_match, &pdev->dev);
+
+   return (struct exynos_dsi_driver_data *)of_id->data;
+}
+
  static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
  {
if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
@@ -340,14 +378,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct 
exynos_dsi *dsi,
  static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
unsigned long freq)
  {
-   static const unsigned long freq_bands[] = {
-   100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
-   270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
-   510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
-   770 * MHZ, 870 * MHZ, 950 * MHZ,
-   };
+   struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
unsigned long fin, fout;
-   int timeout, band;
+   int timeout;
u8 p, s;
u16 m;
u32 reg;
@@ -368,18 +401,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi 
*dsi,
"failed to find PLL PMS for requested frequency\n");
return -EFAULT;
}
+   dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);

-   for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
-   if (fout < freq_bands[band])
-   break;
+   writel(500, dsi->reg_base + driver_data->plltmr_reg);
+
+   reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+
+   if (driver_data->has_freqband) {
+   static const unsigned long freq_bands[] = {
+   100 *

Re: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[YoungJun Cho]

Hi Andrzej,

Thank you for the comments.

On 04/23/2014 04:37 PM, Andrzej Hajda wrote:

On 04/23/2014 05:45 AM, YoungJun Cho wrote:

Hi again Andrzej,

On 04/23/2014 10:01 AM, YoungJun Cho wrote:

Hi Andrzej

Thank you for comments.

On 04/22/2014 09:15 PM, Andrzej Hajda wrote:

Hi YoungJun,

On 04/21/2014 02:28 PM, YoungJun Cho wrote:

Some phy control registers are not kept after software reset.
So this patch makes the clocks containing phy control to be set
after software reset.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
   drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 956e5f3..2cf1f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void
*dev_id)

   static int exynos_dsi_init(struct exynos_dsi *dsi)
   {
-exynos_dsi_enable_clock(dsi);
   exynos_dsi_reset(dsi);
   enable_irq(dsi->irq);
   exynos_dsi_wait_for_reset(dsi);
+exynos_dsi_enable_clock(dsi);
   exynos_dsi_init_link(dsi);

   return 0;


I have commented it in the previous version of the patchset. I repeat it
again.
This is a regression, on exynos4210-trats I have 'timeout waiting for
reset' message after dpms off, on.


I'm really sorry for that. I misunderstood last time.

I think the original codes were correct, because the reset timeout would
be occurred without clock activation.


This is not true.



I'll check and fix again.
(By the way, why am I ok?)


I have not verified with exynos4210-trats board yet(I have to get it),
but reset timeout is occured in exynos_dsi_wait_for_reset()
with &dsi->completed and that is completed by exynos_dsi_irq().

And the regulators and clocks are enabled by exynos_dsi_poweron(),
NOT by exynos_dsi_enable_clock().

So I think the reset timeout is not related with this patch.



As far as I remember there were at least two issues with init sequence:
- spurious irq storm after power on and before reset,
- irq reset timeouts after reset and without enabled clock.

The current sequence is a result of tests on live hw (documentation were
not helpful in this case). I think it could be improved little bit more
by moving exynos_dsi_enable_clock just after enable_irq this will
eliminate possible timeout when RST_RELEASE irq is signaled but irq is
still disabled. The sequence should look like below:

exynos_dsi_reset(dsi);
enable_irq(dsi->irq);
exynos_dsi_enable_clock(dsi);
exynos_dsi_wait_for_reset(dsi);
exynos_dsi_init_link(dsi);

And PHY related configuration could be put somewhere after
exynos_dsi_wait_for_reset.

I have tested this sequence on trats, it seems to be OK.


It also works well in Exynos5420 target.

I think it would be better to remove this patch and implement new PHY
control functions with this modification.

Thank you.
Best regards YJ



Regards
Andrzej




Anyway I need more investigation.

Thank you.
Best regards YJ





I will comment your previous answer here to make the discussion easier:

As I mentioned in description, it came from phy control registers.
Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.

So this patch is required for Exynos5 SoCs.


In the moment this patch is applied exynos_dsi_set_pll do not touch phy
registers you have mentioned.
Your change would be more clear if it will be merged together with the
patch adding PHYCTRL settings.

Anyway, solution is simple - please set PHY registers after reset and
configure clocks before reset to avoid
reset timeouts, is there any reason to not do it this way?


The only reason is that the PHY control is related with PLL control and
that was in exynos_dsi_enable_clock() call path.
So I just wanted to keep current sequence.

If there is no way to use previous one, I'll consider your approach.

Thank you.
Best regards YJ



Regards
Andrzej



___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel








--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

[Anton Tikhomirov]

Hi,

> Hi,
> 
> > -Original Message-
> > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> > ow...@vger.kernel.org] On Behalf Of Vivek Gautam
> > Sent: Monday, April 21, 2014 9:17 PM
> >
> > Facilitate getting required 3.3V and 1.0V VDD supply for
> > OHCI controller on Exynos.
> >
> > With patches for regulators' nodes merged in 3.15:
> > c8c253f ARM: dts: Add regulator entries to smdk5420
> > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> >
> > certain perripherals will now need to ensure that,
> > they request VDD regulators in their drivers, and enable
> > them so as to make them working.
> >
> > Signed-off-by: Vivek Gautam 
> > Cc: Jingoo Han 
> > ---
> >
> > Based on 'usb-next' branch of Greg's usb tree.
> >
> >  drivers/usb/host/ohci-exynos.c |   47
> > 
> >  1 file changed, 47 insertions(+)
> >
> > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
> > exynos.c
> > index 68588d8..e2e72a8 100644
> > --- a/drivers/usb/host/ohci-exynos.c
> > +++ b/drivers/usb/host/ohci-exynos.c
> > @@ -18,6 +18,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
> > struct clk *clk;
> > struct usb_phy *phy;
> > struct usb_otg *otg;
> > +   struct regulator *vdd33;
> > +   struct regulator *vdd10;
> >  };
> >
> >  static void exynos_ohci_phy_enable(struct platform_device *pdev)
> > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct
> platform_device
> > *pdev)
> > exynos_ohci->otg = phy->otg;
> > }
> >
> > +   exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> > +   if (IS_ERR(exynos_ohci->vdd33)) {
> > +   err = PTR_ERR(exynos_ohci->vdd33);
> > +   goto fail_regulator1;
> > +   }
> > +   err = regulator_enable(exynos_ohci->vdd33);
> > +   if (err) {
> > +   dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> > +   goto fail_regulator1;
> > +   }
> > +
> > +   exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> > +   if (IS_ERR(exynos_ohci->vdd10)) {
> > +   err = PTR_ERR(exynos_ohci->vdd10);
> > +   goto fail_regulator2;
> > +   }
> > +   err = regulator_enable(exynos_ohci->vdd10);
> > +   if (err) {
> > +   dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> > +   goto fail_regulator2;
> > +   }
> > +
> 
> Do we need to skip regulator settings together with PHY configuration
> in case of exynos5440?
> 
> >  skip_phy:
> > exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
> >
> > @@ -154,6 +179,10 @@ fail_add_hcd:
> >  fail_io:
> > clk_disable_unprepare(exynos_ohci->clk);
> >  fail_clk:
> > +   regulator_disable(exynos_ohci->vdd10);
> > +fail_regulator2:
> > +   regulator_disable(exynos_ohci->vdd33);
> > +fail_regulator1:
> > usb_put_hcd(hcd);
> > return err;
> >  }
> > @@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
> > platform_device *pdev)
> >
> > clk_disable_unprepare(exynos_ohci->clk);
> >
> > +   regulator_disable(exynos_ohci->vdd10);
> > +   regulator_disable(exynos_ohci->vdd33);
> > +
> > usb_put_hcd(hcd);
> >
> > return 0;
> > @@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
> >
> > clk_disable_unprepare(exynos_ohci->clk);
> >
> > +   regulator_disable(exynos_ohci->vdd10);
> > +   regulator_disable(exynos_ohci->vdd33);
> > +
> > spin_unlock_irqrestore(&ohci->lock, flags);
> >
> > return 0;
> > @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
> > struct usb_hcd *hcd = dev_get_drvdata(dev);
> > struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
> > struct platform_device *pdev= to_platform_device(dev);
> > +   int ret;
> > +
> > +   ret = regulator_enable(exynos_ohci->vdd33);
> > +   if (ret) {
> > +   dev_err(dev, "Failed to enable VDD33 supply\n");
> > +   return ret;
> 
> Not sure, but shall we continue resuming and do everything
> we can in case of error? At least it will avoid
> WARN_ON(clk->enable_count == 0) on next system suspend.

On the other hand, if power is not applied to the controller,
register access in ohci_resume() may lead to undefined behavior.
What's your opinion?

> 
> > +   }
> > +   ret = regulator_enable(exynos_ohci->vdd10);
> > +   if (ret) {
> > +   dev_err(dev, "Failed to enable VDD10 supply\n");
> > +   return ret;
> > +   }
> >
> > clk_prepare_enable(exynos_ohci->clk);
> >
> > --
> 
> Thanks

Thanks

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

[Jingoo Han]

On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
> On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
> >
> > Facilitate getting required 3.3V and 1.0V VDD supply for
> > OHCI controller on Exynos.
> >
> > With patches for regulators' nodes merged in 3.15:
> > c8c253f ARM: dts: Add regulator entries to smdk5420
> > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> >
> > certain perripherals will now need to ensure that,
> > they request VDD regulators in their drivers, and enable
> > them so as to make them working.
> >
> > Signed-off-by: Vivek Gautam 
> > Cc: Jingoo Han 
> > ---
> >
> > Based on 'usb-next' branch of Greg's usb tree.
> >
> >  drivers/usb/host/ohci-exynos.c |   47
> > 
> >  1 file changed, 47 insertions(+)
> >
> > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
> > exynos.c
> > index 68588d8..e2e72a8 100644
> > --- a/drivers/usb/host/ohci-exynos.c
> > +++ b/drivers/usb/host/ohci-exynos.c
> > @@ -18,6 +18,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
> > struct clk *clk;
> > struct usb_phy *phy;
> > struct usb_otg *otg;
> > +   struct regulator *vdd33;
> > +   struct regulator *vdd10;
> >  };
> >
> >  static void exynos_ohci_phy_enable(struct platform_device *pdev)
> > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
> > *pdev)
> > exynos_ohci->otg = phy->otg;
> > }
> >
> > +   exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> > +   if (IS_ERR(exynos_ohci->vdd33)) {
> > +   err = PTR_ERR(exynos_ohci->vdd33);
> > +   goto fail_regulator1;
> > +   }
> > +   err = regulator_enable(exynos_ohci->vdd33);
> > +   if (err) {
> > +   dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> > +   goto fail_regulator1;
> > +   }
> > +
> > +   exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> > +   if (IS_ERR(exynos_ohci->vdd10)) {
> > +   err = PTR_ERR(exynos_ohci->vdd10);
> > +   goto fail_regulator2;
> > +   }
> > +   err = regulator_enable(exynos_ohci->vdd10);
> > +   if (err) {
> > +   dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> > +   goto fail_regulator2;
> > +   }
> > +
> 
> Do we need to skip regulator settings together with PHY configuration
> in case of exynos5440?

Oh, right. In the case of exynos5440, regulator settings is not 
necessary. Vivek, would you fix it in order skip regulator settings
in exynos5440? It also applies to ehci-exynos.

Best regards,
Jingoo Han

> 
> >  skip_phy:
> > exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
> >
> > @@ -154,6 +179,10 @@ fail_add_hcd:
> >  fail_io:
> > clk_disable_unprepare(exynos_ohci->clk);
> >  fail_clk:
> > +   regulator_disable(exynos_ohci->vdd10);
> > +fail_regulator2:
> > +   regulator_disable(exynos_ohci->vdd33);
> > +fail_regulator1:
> > usb_put_hcd(hcd);
> > return err;
> >  }
> > @@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
> > platform_device *pdev)
> >
> > clk_disable_unprepare(exynos_ohci->clk);
> >
> > +   regulator_disable(exynos_ohci->vdd10);
> > +   regulator_disable(exynos_ohci->vdd33);
> > +
> > usb_put_hcd(hcd);
> >
> > return 0;
> > @@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
> >
> > clk_disable_unprepare(exynos_ohci->clk);
> >
> > +   regulator_disable(exynos_ohci->vdd10);
> > +   regulator_disable(exynos_ohci->vdd33);
> > +
> > spin_unlock_irqrestore(&ohci->lock, flags);
> >
> > return 0;
> > @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
> > struct usb_hcd *hcd = dev_get_drvdata(dev);
> > struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
> > struct platform_device *pdev= to_platform_device(dev);
> > +   int ret;
> > +
> > +   ret = regulator_enable(exynos_ohci->vdd33);
> > +   if (ret) {
> > +   dev_err(dev, "Failed to enable VDD33 supply\n");
> > +   return ret;
> 
> Not sure, but shall we continue resuming and do everything
> we can in case of error? At least it will avoid
> WARN_ON(clk->enable_count == 0) on next system suspend.
> 
> > +   }
> > +   ret = regulator_enable(exynos_ohci->vdd10);
> > +   if (ret) {
> > +   dev_err(dev, "Failed to enable VDD10 supply\n");
> > +   return ret;
> > +   }
> >
> > clk_prepare_enable(exynos_ohci->clk);
> >
> > --
> 
> Thanks

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

[Anton Tikhomirov]

Hi,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Vivek Gautam
> Sent: Monday, April 21, 2014 9:17 PM
> 
> Facilitate getting required 3.3V and 1.0V VDD supply for
> OHCI controller on Exynos.
> 
> With patches for regulators' nodes merged in 3.15:
> c8c253f ARM: dts: Add regulator entries to smdk5420
> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> 
> certain perripherals will now need to ensure that,
> they request VDD regulators in their drivers, and enable
> them so as to make them working.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 
> ---
> 
> Based on 'usb-next' branch of Greg's usb tree.
> 
>  drivers/usb/host/ohci-exynos.c |   47
> 
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
> exynos.c
> index 68588d8..e2e72a8 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
>   struct clk *clk;
>   struct usb_phy *phy;
>   struct usb_otg *otg;
> + struct regulator *vdd33;
> + struct regulator *vdd10;
>  };
> 
>  static void exynos_ohci_phy_enable(struct platform_device *pdev)
> @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
> *pdev)
>   exynos_ohci->otg = phy->otg;
>   }
> 
> + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> + if (IS_ERR(exynos_ohci->vdd33)) {
> + err = PTR_ERR(exynos_ohci->vdd33);
> + goto fail_regulator1;
> + }
> + err = regulator_enable(exynos_ohci->vdd33);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> + goto fail_regulator1;
> + }
> +
> + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> + if (IS_ERR(exynos_ohci->vdd10)) {
> + err = PTR_ERR(exynos_ohci->vdd10);
> + goto fail_regulator2;
> + }
> + err = regulator_enable(exynos_ohci->vdd10);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> + goto fail_regulator2;
> + }
> +

Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?

>  skip_phy:
>   exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
> 
> @@ -154,6 +179,10 @@ fail_add_hcd:
>  fail_io:
>   clk_disable_unprepare(exynos_ohci->clk);
>  fail_clk:
> + regulator_disable(exynos_ohci->vdd10);
> +fail_regulator2:
> + regulator_disable(exynos_ohci->vdd33);
> +fail_regulator1:
>   usb_put_hcd(hcd);
>   return err;
>  }
> @@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
> platform_device *pdev)
> 
>   clk_disable_unprepare(exynos_ohci->clk);
> 
> + regulator_disable(exynos_ohci->vdd10);
> + regulator_disable(exynos_ohci->vdd33);
> +
>   usb_put_hcd(hcd);
> 
>   return 0;
> @@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
> 
>   clk_disable_unprepare(exynos_ohci->clk);
> 
> + regulator_disable(exynos_ohci->vdd10);
> + regulator_disable(exynos_ohci->vdd33);
> +
>   spin_unlock_irqrestore(&ohci->lock, flags);
> 
>   return 0;
> @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
>   struct usb_hcd *hcd = dev_get_drvdata(dev);
>   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
>   struct platform_device *pdev= to_platform_device(dev);
> + int ret;
> +
> + ret = regulator_enable(exynos_ohci->vdd33);
> + if (ret) {
> + dev_err(dev, "Failed to enable VDD33 supply\n");
> + return ret;

Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk->enable_count == 0) on next system suspend.

> + }
> + ret = regulator_enable(exynos_ohci->vdd10);
> + if (ret) {
> + dev_err(dev, "Failed to enable VDD10 supply\n");
> + return ret;
> + }
> 
>   clk_prepare_enable(exynos_ohci->clk);
> 
> --

Thanks

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2.1 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf

[Heiko Stübner]

The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.

Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.

The s3c cpufreq driver does already aquire the mpll, so simply add a reference
to struct s3c_cpufreq_config to let set_fvco access it.

While struct clk is opaque the differenciation between samsung clock and
common clock is kept, as the samsung-clock mpll clk does not implement a
real set_rate.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/mach-s3c24xx/cpufreq-utils.c  | 8 
 arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 1 +
 drivers/cpufreq/s3c24xx-cpufreq.c  | 1 +
 3 files changed, 10 insertions(+)

diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c 
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..c1b7508 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -60,5 +61,12 @@ void s3c2410_cpufreq_setrefresh(struct s3c_cpufreq_config 
*cfg)
  */
 void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
 {
+#ifdef CONFIG_SAMSUNG_CLOCK
__raw_writel(cfg->pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+   if (!IS_ERR(cfg->mpll))
+   clk_set_rate(cfg->mpll, cfg->pll.frequency);
+#endif
 }
diff --git a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h 
b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
index 7231c8e..72d4178 100644
--- a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
+++ b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
@@ -119,6 +119,7 @@ struct s3c_plltab {
 struct s3c_cpufreq_config {
struct s3c_freq freq;
struct s3c_freq max;
+   struct clk  *mpll;
struct cpufreq_frequency_table pll;
struct s3c_clkdivs  divs;
struct s3c_cpufreq_info *info;  /* for core, not drivers */
diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c 
b/drivers/cpufreq/s3c24xx-cpufreq.c
index be1b2b5..227ebf7 100644
--- a/drivers/cpufreq/s3c24xx-cpufreq.c
+++ b/drivers/cpufreq/s3c24xx-cpufreq.c
@@ -141,6 +141,7 @@ static int s3c_cpufreq_calcdivs(struct s3c_cpufreq_config 
*cfg)
 
 static void s3c_cpufreq_setfvco(struct s3c_cpufreq_config *cfg)
 {
+   cfg->mpll = _clk_mpll;
(cfg->info->set_fvco)(cfg);
 }
 
-- 
1.9.0


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf

[Heiko Stübner]

Am Mittwoch, 23. April 2014, 22:55:51 schrieb Tomasz Figa:
> Hi,
> 
> On 23.04.2014 22:42, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 04/23/2014 11:34 PM, Heiko Stübner wrote:
> >> The s3c24xx cpufreq driver needs to change the mpll speed and was doing
> >> this by writing raw values from a translation table into the MPLLCON
> >> register.
> >> 
> >> Change this to use a regular clk_set_rate call when using the common
> >> clock framework and only write the raw value in the samsung_clock case.
> >> 
> >> To not needing to create additional infrastructure for this, the mpll
> >> clock
> >> is requested at the first call to s3c2410_set_fvco().
> >> 
> >> Signed-off-by: Heiko Stuebner 
> >> ---
> >> 
> >>   arch/arm/mach-s3c24xx/cpufreq-utils.c | 14 ++
> >>   1 file changed, 14 insertions(+)
> >> 
> >> diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c
> >> b/arch/arm/mach-s3c24xx/cpufreq-utils.c
> >> index 2a0aa56..d5e797b 100644
> >> --- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
> >> +++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
> > 
> > [...]
> > 
> >> @@ -60,5 +61,18 @@ void s3c2410_cpufreq_setrefresh(struct
> >> s3c_cpufreq_config *cfg)
> >> 
> >>*/
> >>   
> >>   void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
> >>   {
> >> 
> >> +#ifdef CONFIG_SAMSUNG_CLOCK
> >> 
> >>   __raw_writel(cfg->pll.driver_data, S3C2410_MPLLCON);
> >> 
> >> +#endif
> >> +
> >> +#ifdef CONFIG_COMMON_CLK
> >> +static struct clk *mpll;
> >> +
> >> +if (!mpll)
> >> 
> > You are testing uninitialized variable. This check wouldn't make
> > 
> > much sense even if the variable was initialized.
> 
> I should probably add that NULL is considered a valid clock handle by
> Common Clock Framework.
> 
> If there is really no way to pass the clock to this function then
> probably a global variable initialized by some code running earlier than
> this function could be called would be a better choice.

*grrr* :-) ... ok I'll try to find another way (again) to do this


> Anyway, Heiko, thanks for working on this. I'll try to review rest of
> the series soon. (I'm attending the ELC next week, though, so I'm not
> sure if I find some time then, though.)

Just as a reminder, there isn't this much to still review, as you 
Acked/Reviewed most of the series in v1 and only this patch as well as 2 and 5 
still need a review/ack - and the only changes are fixes for your comments ;-)


Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf

[Sergei Shtylyov]

On 04/24/2014 12:42 AM, Sergei Shtylyov wrote:


The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.



Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.



To not needing to create additional infrastructure for this, the mpll clock
is requested at the first call to s3c2410_set_fvco().



Signed-off-by: Heiko Stuebner 
---
  arch/arm/mach-s3c24xx/cpufreq-utils.c | 14 ++
  1 file changed, 14 insertions(+)



diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..d5e797b 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c

[...]

@@ -60,5 +61,18 @@ void s3c2410_cpufreq_setrefresh(struct s3c_cpufreq_config
*cfg)
   */
  void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
  {
+#ifdef CONFIG_SAMSUNG_CLOCK
  __raw_writel(cfg->pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+static struct clk *mpll;
+
+if (!mpll)



You are testing uninitialized variable. This check wouldn't make much
sense even if the variable was initialized.


   Oops, I didn't notice *static*... :-> The code makes more sense now.


+mpll = clk_get(NULL, "mpll")
+if (IS_ERR(mpll))
+return;
+
+clk_set_rate(mpll, cfg->pll.frequency);
+#endif
  }


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf

[Tomasz Figa]

Hi,

On 23.04.2014 22:42, Sergei Shtylyov wrote:

Hello.

On 04/23/2014 11:34 PM, Heiko Stübner wrote:


The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.



Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.



To not needing to create additional infrastructure for this, the mpll
clock
is requested at the first call to s3c2410_set_fvco().



Signed-off-by: Heiko Stuebner 
---
  arch/arm/mach-s3c24xx/cpufreq-utils.c | 14 ++
  1 file changed, 14 insertions(+)



diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..d5e797b 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c

[...]

@@ -60,5 +61,18 @@ void s3c2410_cpufreq_setrefresh(struct
s3c_cpufreq_config *cfg)
   */
  void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
  {
+#ifdef CONFIG_SAMSUNG_CLOCK
  __raw_writel(cfg->pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+static struct clk *mpll;
+
+if (!mpll)


You are testing uninitialized variable. This check wouldn't make
much sense even if the variable was initialized.


I should probably add that NULL is considered a valid clock handle by 
Common Clock Framework.


If there is really no way to pass the clock to this function then 
probably a global variable initialized by some code running earlier than 
this function could be called would be a better choice.


Anyway, Heiko, thanks for working on this. I'll try to review rest of 
the series soon. (I'm attending the ELC next week, though, so I'm not 
sure if I find some time then, though.)


Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf

[Sergei Shtylyov]

Hello.

On 04/23/2014 11:34 PM, Heiko Stübner wrote:


The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.



Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.



To not needing to create additional infrastructure for this, the mpll clock
is requested at the first call to s3c2410_set_fvco().



Signed-off-by: Heiko Stuebner 
---
  arch/arm/mach-s3c24xx/cpufreq-utils.c | 14 ++
  1 file changed, 14 insertions(+)



diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c 
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..d5e797b 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c

[...]

@@ -60,5 +61,18 @@ void s3c2410_cpufreq_setrefresh(struct s3c_cpufreq_config 
*cfg)
   */
  void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
  {
+#ifdef CONFIG_SAMSUNG_CLOCK
__raw_writel(cfg->pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+   static struct clk *mpll;
+
+   if (!mpll)


   You are testing uninitialized variable. This check wouldn't make much 
sense even if the variable was initialized.



+   mpll = clk_get(NULL, "mpll")
+   if (IS_ERR(mpll))
+   return;
+
+   clk_set_rate(mpll, cfg->pll.frequency);
+#endif
  }


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2.1 9/9] ARM: S3C24XX: remove legacy clock code

[Heiko Stübner]

With the move to the common clock framework completed for s3c2410, s3c2440
and s3c2442, the legacy clock code for these machines can go away too.

This also includes the legacy dclk code, as all legacy users are converted.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Tomasz Figa 
---
adapted to apply against v3.16-next/clk-s3c24xx

 arch/arm/mach-s3c24xx/Kconfig   |  11 -
 arch/arm/mach-s3c24xx/Makefile  |   2 -
 arch/arm/mach-s3c24xx/clock-dclk.c  | 195 
 arch/arm/mach-s3c24xx/clock-s3c2410.c   | 284 
 arch/arm/mach-s3c24xx/clock-s3c2440.c   | 217 --
 arch/arm/mach-s3c24xx/clock-s3c244x.c   | 141 
 arch/arm/mach-s3c24xx/common.h  |   2 -
 arch/arm/mach-s3c24xx/include/mach/regs-clock.h |  18 --
 arch/arm/mach-s3c24xx/include/mach/regs-gpio.h  |   3 -
 arch/arm/mach-s3c24xx/pm.c  |  12 -
 arch/arm/mach-s3c24xx/s3c2410.c |  62 --
 arch/arm/mach-s3c24xx/s3c2442.c | 112 --
 arch/arm/mach-s3c24xx/s3c244x.c |  63 --
 13 files changed, 1122 deletions(-)
 delete mode 100644 arch/arm/mach-s3c24xx/clock-dclk.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2410.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2440.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c244x.c

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 7b99740..77b0fb5 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -110,17 +110,6 @@ config CPU_S3C2443
 
 # common code
 
-config S3C2410_CLOCK
-   bool
-   help
- Clock code for the S3C2410, and similar processors which
- is currently includes the S3C2410, S3C2440, S3C2442.
-
-config S3C24XX_DCLK
-   bool
-   help
- Clock code for supporting DCLK/CLKOUT on S3C24XX architectures
-
 config S3C24XX_SMDK
bool
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 9010eba..2235d0d 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -44,10 +44,8 @@ obj-$(CONFIG_PM) += pm.o irq-pm.o sleep.o
 
 # common code
 
-obj-$(CONFIG_S3C24XX_DCLK) += clock-dclk.o
 obj-$(CONFIG_S3C24XX_DMA)  += dma.o
 
-obj-$(CONFIG_S3C2410_CLOCK)+= clock-s3c2410.o
 obj-$(CONFIG_S3C2410_CPUFREQ_UTILS) += cpufreq-utils.o
 
 obj-$(CONFIG_S3C2410_IOTIMING) += iotiming-s3c2410.o
diff --git a/arch/arm/mach-s3c24xx/clock-dclk.c 
b/arch/arm/mach-s3c24xx/clock-dclk.c
deleted file mode 100644
index 1edd9b2..000
--- a/arch/arm/mach-s3c24xx/clock-dclk.c
+++ /dev/null
@@ -1,195 +0,0 @@
-/*
- * Copyright (c) 2004-2008 Simtec Electronics
- * Ben Dooks 
- * http://armlinux.simtec.co.uk/
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * S3C24XX - definitions for DCLK and CLKOUT registers
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include 
-#include 
-
-/* clocks that could be registered by external code */
-
-static int s3c24xx_dclk_enable(struct clk *clk, int enable)
-{
-   unsigned long dclkcon = __raw_readl(S3C24XX_DCLKCON);
-
-   if (enable)
-   dclkcon |= clk->ctrlbit;
-   else
-   dclkcon &= ~clk->ctrlbit;
-
-   __raw_writel(dclkcon, S3C24XX_DCLKCON);
-
-   return 0;
-}
-
-static int s3c24xx_dclk_setparent(struct clk *clk, struct clk *parent)
-{
-   unsigned long dclkcon;
-   unsigned int uclk;
-
-   if (parent == &clk_upll)
-   uclk = 1;
-   else if (parent == &clk_p)
-   uclk = 0;
-   else
-   return -EINVAL;
-
-   clk->parent = parent;
-
-   dclkcon = __raw_readl(S3C24XX_DCLKCON);
-
-   if (clk->ctrlbit == S3C2410_DCLKCON_DCLK0EN) {
-   if (uclk)
-   dclkcon |= S3C2410_DCLKCON_DCLK0_UCLK;
-   else
-   dclkcon &= ~S3C2410_DCLKCON_DCLK0_UCLK;
-   } else {
-   if (uclk)
-   dclkcon |= S3C2410_DCLKCON_DCLK1_UCLK;
-   else
-   dclkcon &= ~S3C2410_DCLKCON_DCLK1_UCLK;
-   }
-
-   __raw_writel(dclkcon, S3C24XX_DCLKCON);
-
-   return 0;
-}
-static unsigned long s3c24xx_calc_div(struct clk *clk, unsigned long rate)
-{
-   unsigned long div;
-
-   if ((rate == 0) || !clk->parent)
-   return 0;
-
-   div = clk_get_rate(clk->parent) / rate;
-   if (div < 2)
-   div = 2;
-   else if (div > 16)
-   div = 16;
-
-   return div;
-}
-
-static unsigned long s3c24xx_round_dclk_rate(struct clk *clk,
-   unsigned long rate)
-{
-   unsigned long div = s3c24xx_calc_div(clk, rate);
-
-   if (div == 0)

[PATCH v2.1 8/9] ARM: S3C24XX: convert s3c2410 to common clock framework

[Heiko Stübner]

Convert the machines using the s3c2410 to use the new driver based
on the common clock framework instead of the legacy Samsung clock driver.

As with the s3c244x, machines using the clkout output will need a fixup
from someone with the hardware.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Tomasz Figa 
---
adapted to apply against v3.16-next/clk-s3c24xx

 arch/arm/mach-s3c24xx/Kconfig   |  4 ++--
 arch/arm/mach-s3c24xx/common.c  |  2 --
 arch/arm/mach-s3c24xx/mach-amlm5900.c   |  9 +++--
 arch/arm/mach-s3c24xx/mach-bast.c   | 10 +++---
 arch/arm/mach-s3c24xx/mach-h1940.c  | 10 +++---
 arch/arm/mach-s3c24xx/mach-n30.c| 12 
 arch/arm/mach-s3c24xx/mach-nexcoder.c   |  7 +--
 arch/arm/mach-s3c24xx/mach-otom.c   | 10 +++---
 arch/arm/mach-s3c24xx/mach-qt2410.c |  9 +++--
 arch/arm/mach-s3c24xx/mach-smdk2410.c   |  9 +++--
 arch/arm/mach-s3c24xx/mach-tct_hammer.c |  9 +++--
 arch/arm/mach-s3c24xx/mach-vr1000.c | 10 +++---
 12 files changed, 67 insertions(+), 34 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 96d1e54..57ebb13 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -37,10 +37,10 @@ comment "S3C24XX SoCs"
 config CPU_S3C2410
bool "SAMSUNG S3C2410"
default y
-   depends on SAMSUNG_CLOCK
+   select COMMON_CLK
select CPU_ARM920T
select CPU_LLSERIAL_S3C2410
-   select S3C2410_CLOCK
+   select S3C2410_COMMON_CLK
select S3C2410_DMA if S3C24XX_DMA
select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
select S3C2410_PM if PM
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index def8627..a7b1269 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -74,7 +74,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x3241,
.idmask = 0x,
.map_io = s3c2410_map_io,
-   .init_clocks= s3c2410_init_clocks,
.init_uarts = s3c2410_init_uarts,
.init   = s3c2410_init,
.name   = name_s3c2410
@@ -83,7 +82,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32410002,
.idmask = 0x,
.map_io = s3c2410_map_io,
-   .init_clocks= s3c2410_init_clocks,
.init_uarts = s3c2410_init_uarts,
.init   = s3c2410a_init,
.name   = name_s3c2410a
diff --git a/arch/arm/mach-s3c24xx/mach-amlm5900.c 
b/arch/arm/mach-s3c24xx/mach-amlm5900.c
index 284ea1f..0e175e0 100644
--- a/arch/arm/mach-s3c24xx/mach-amlm5900.c
+++ b/arch/arm/mach-s3c24xx/mach-amlm5900.c
@@ -161,11 +161,16 @@ static struct platform_device *amlm5900_devices[] 
__initdata = {
 static void __init amlm5900_map_io(void)
 {
s3c24xx_init_io(amlm5900_iodesc, ARRAY_SIZE(amlm5900_iodesc));
-   s3c24xx_init_clocks(0);
s3c24xx_init_uarts(amlm5900_uartcfgs, ARRAY_SIZE(amlm5900_uartcfgs));
samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 }
 
+static void __init amlm5900_init_time(void)
+{
+   s3c2410_init_clocks(1200);
+   samsung_timer_init();
+}
+
 #ifdef CONFIG_FB_S3C2410
 static struct s3c2410fb_display __initdata amlm5900_lcd_info = {
.width  = 160,
@@ -241,6 +246,6 @@ MACHINE_START(AML_M5900, "AML_M5900")
.map_io = amlm5900_map_io,
.init_irq   = s3c2410_init_irq,
.init_machine   = amlm5900_init,
-   .init_time  = samsung_timer_init,
+   .init_time  = amlm5900_init_time,
.restart= s3c2410_restart,
 MACHINE_END
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c 
b/arch/arm/mach-s3c24xx/mach-bast.c
index 13e078c..ab075a6 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -50,7 +50,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -581,11 +580,16 @@ static void __init bast_map_io(void)
s3c_hwmon_set_platdata(&bast_hwmon_info);
 
s3c24xx_init_io(bast_iodesc, ARRAY_SIZE(bast_iodesc));
-   s3c24xx_init_clocks(0);
s3c24xx_init_uarts(bast_uartcfgs, ARRAY_SIZE(bast_uartcfgs));
samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 }
 
+static void __init bast_init_time(void)
+{
+   s3c2410_init_clocks(1200);
+   samsung_timer_init();
+}
+
 static void __init bast_init(void)
 {
register_syscore_ops(&bast_pm_syscore_ops);
@@ -613,6 +617,6 @@ MACHINE_START(BAST, "Simtec-BAST")
.map_io = bast_map_io,
.init_irq   = s3c2410_init_irq,
.init_machine   = bast_init,
-   .init_time  = samsung_timer_init,
+   .init_time  = bast_init_time,
.restart= s3c2410_restart,

[PATCH v2.1 3/9] ARM: S3C24XX: enable usage of common dclk if common clock framework is enabled

[Heiko Stübner]

Add platform device and select the correct implementation automatically
depending on wether the old samsung_clock or the common clock framework
is enabled.

This is only done for machines already using the old dclk implementation,
as everybody else should move to use dt anyway.

The machine-specific settings for the external clocks will have to be set
by somebody with knowledge about the specific hardware.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Tomasz Figa 
---
adapted to apply against v3.16-next/clk-s3c24xx

 arch/arm/mach-s3c24xx/Kconfig   | 22 +-
 arch/arm/mach-s3c24xx/common.c  | 14 ++
 arch/arm/mach-s3c24xx/common.h  |  2 ++
 arch/arm/mach-s3c24xx/mach-anubis.c |  5 +
 arch/arm/mach-s3c24xx/mach-bast.c   |  5 +
 arch/arm/mach-s3c24xx/mach-osiris.c |  5 +
 arch/arm/mach-s3c24xx/mach-rx1950.c |  5 +
 arch/arm/mach-s3c24xx/mach-vr1000.c |  5 +
 arch/arm/mach-s3c24xx/s3c244x.c |  2 ++
 9 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index d067f76..6036e77 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -18,6 +18,13 @@ config PLAT_S3C24XX
help
  Base platform code for any Samsung S3C24XX device
 
+config S3C2410_COMMON_DCLK
+   bool
+   select REGMAP_MMIO
+   help
+ Temporary symbol to build the dclk driver based on the common clock
+ framework.
+
 menu "SAMSUNG S3C24XX SoCs Support"
 
 comment "S3C24XX SoCs"
@@ -264,7 +271,8 @@ config ARCH_BAST
select ISA
select MACH_BAST_IDE
select S3C2410_IOTIMING if ARM_S3C2410_CPUFREQ
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
select S3C24XX_SIMTEC_USB
@@ -345,7 +353,8 @@ config MACH_TCT_HAMMER
 config MACH_VR1000
bool "Thorcom VR1000"
select MACH_BAST_IDE
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
select S3C24XX_SIMTEC_USB
@@ -530,7 +539,8 @@ config MACH_ANUBIS
bool "Simtec Electronics ANUBIS"
select HAVE_PATA_PLATFORM
select S3C2440_XTAL_1200
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_USB_HOST
help
@@ -571,7 +581,8 @@ config MACH_OSIRIS
bool "Simtec IM2440D20 (OSIRIS) module"
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_1200
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_NAND
select S3C_DEV_USB_HOST
@@ -643,7 +654,8 @@ config MACH_RX1950
select PM_H1940 if PM
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_16934400
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C24XX_COMMON_DCLK if COMMON_CLK
select S3C24XX_PWM
select S3C_DEV_NAND
help
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 92a1e3a..8e930e0 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -554,3 +554,17 @@ void __init s3c2443_init_clocks(int xtal)
s3c2443_common_clk_init(NULL, xtal, 1, S3C24XX_VA_CLKPWR);
 }
 #endif
+
+#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2440) || \
+   defined(CONFIG_CPU_S3C2442)
+static struct resource s3c2410_dclk_resource[] = {
+   [0] = DEFINE_RES_MEM(0x5684, 0x4),
+};
+
+struct platform_device s3c2410_device_dclk = {
+   .name   = "s3c2410-dclk",
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(s3c2410_dclk_resource),
+   .resource   = s3c2410_dclk_resource,
+};
+#endif
diff --git a/arch/arm/mach-s3c24xx/common.h b/arch/arm/mach-s3c24xx/common.h
index 3fade6d..50504c7 100644
--- a/arch/arm/mach-s3c24xx/common.h
+++ b/arch/arm/mach-s3c24xx/common.h
@@ -114,6 +114,8 @@ extern struct platform_device s3c2412_device_dma;
 extern struct platform_device s3c2440_device_dma;
 extern struct platform_device s3c2443_device_dma;
 
+extern struct platform_device s3c2410_device_dclk;
+
 #ifdef CONFIG_S3C2412_COMMON_CLK
 void __init s3c2412_common_clk_init(struct device_node *np, unsigned long 
xti_f,
unsigned long ext_f, void __iomem *reg_base);
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c 
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 2a16f8f..6a1a781 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -352,6 +352,7 @@ static st

[PATCH v2 9/9] ARM: S3C24XX: remove legacy clock code

[Heiko Stübner]

With the move to the common clock framework completed for s3c2410, s3c2440
and s3c2442, the legacy clock code for these machines can go away too.

This also includes the legacy dclk code, as all legacy users are converted.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Tomasz Figa 
---
 arch/arm/mach-s3c24xx/Kconfig   |  11 -
 arch/arm/mach-s3c24xx/Makefile  |   2 -
 arch/arm/mach-s3c24xx/clock-dclk.c  | 195 
 arch/arm/mach-s3c24xx/clock-s3c2410.c   | 285 
 arch/arm/mach-s3c24xx/clock-s3c2440.c   | 217 --
 arch/arm/mach-s3c24xx/clock-s3c244x.c   | 141 
 arch/arm/mach-s3c24xx/common.h  |   2 -
 arch/arm/mach-s3c24xx/include/mach/regs-clock.h |  18 --
 arch/arm/mach-s3c24xx/include/mach/regs-gpio.h  |   3 -
 arch/arm/mach-s3c24xx/pm.c  |  12 -
 arch/arm/mach-s3c24xx/s3c2410.c |  62 --
 arch/arm/mach-s3c24xx/s3c2442.c | 112 --
 arch/arm/mach-s3c24xx/s3c244x.c |  63 --
 13 files changed, 1123 deletions(-)
 delete mode 100644 arch/arm/mach-s3c24xx/clock-dclk.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2410.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2440.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c244x.c

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 57ebb13..02b1adf 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -110,17 +110,6 @@ config CPU_S3C2443
 
 # common code
 
-config S3C2410_CLOCK
-   bool
-   help
- Clock code for the S3C2410, and similar processors which
- is currently includes the S3C2410, S3C2440, S3C2442.
-
-config S3C24XX_DCLK
-   bool
-   help
- Clock code for supporting DCLK/CLKOUT on S3C24XX architectures
-
 config S3C24XX_SMDK
bool
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 9010eba..2235d0d 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -44,10 +44,8 @@ obj-$(CONFIG_PM) += pm.o irq-pm.o sleep.o
 
 # common code
 
-obj-$(CONFIG_S3C24XX_DCLK) += clock-dclk.o
 obj-$(CONFIG_S3C24XX_DMA)  += dma.o
 
-obj-$(CONFIG_S3C2410_CLOCK)+= clock-s3c2410.o
 obj-$(CONFIG_S3C2410_CPUFREQ_UTILS) += cpufreq-utils.o
 
 obj-$(CONFIG_S3C2410_IOTIMING) += iotiming-s3c2410.o
diff --git a/arch/arm/mach-s3c24xx/clock-dclk.c 
b/arch/arm/mach-s3c24xx/clock-dclk.c
deleted file mode 100644
index 1edd9b2..000
--- a/arch/arm/mach-s3c24xx/clock-dclk.c
+++ /dev/null
@@ -1,195 +0,0 @@
-/*
- * Copyright (c) 2004-2008 Simtec Electronics
- * Ben Dooks 
- * http://armlinux.simtec.co.uk/
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * S3C24XX - definitions for DCLK and CLKOUT registers
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include 
-#include 
-
-/* clocks that could be registered by external code */
-
-static int s3c24xx_dclk_enable(struct clk *clk, int enable)
-{
-   unsigned long dclkcon = __raw_readl(S3C24XX_DCLKCON);
-
-   if (enable)
-   dclkcon |= clk->ctrlbit;
-   else
-   dclkcon &= ~clk->ctrlbit;
-
-   __raw_writel(dclkcon, S3C24XX_DCLKCON);
-
-   return 0;
-}
-
-static int s3c24xx_dclk_setparent(struct clk *clk, struct clk *parent)
-{
-   unsigned long dclkcon;
-   unsigned int uclk;
-
-   if (parent == &clk_upll)
-   uclk = 1;
-   else if (parent == &clk_p)
-   uclk = 0;
-   else
-   return -EINVAL;
-
-   clk->parent = parent;
-
-   dclkcon = __raw_readl(S3C24XX_DCLKCON);
-
-   if (clk->ctrlbit == S3C2410_DCLKCON_DCLK0EN) {
-   if (uclk)
-   dclkcon |= S3C2410_DCLKCON_DCLK0_UCLK;
-   else
-   dclkcon &= ~S3C2410_DCLKCON_DCLK0_UCLK;
-   } else {
-   if (uclk)
-   dclkcon |= S3C2410_DCLKCON_DCLK1_UCLK;
-   else
-   dclkcon &= ~S3C2410_DCLKCON_DCLK1_UCLK;
-   }
-
-   __raw_writel(dclkcon, S3C24XX_DCLKCON);
-
-   return 0;
-}
-static unsigned long s3c24xx_calc_div(struct clk *clk, unsigned long rate)
-{
-   unsigned long div;
-
-   if ((rate == 0) || !clk->parent)
-   return 0;
-
-   div = clk_get_rate(clk->parent) / rate;
-   if (div < 2)
-   div = 2;
-   else if (div > 16)
-   div = 16;
-
-   return div;
-}
-
-static unsigned long s3c24xx_round_dclk_rate(struct clk *clk,
-   unsigned long rate)
-{
-   unsigned long div = s3c24xx_calc_div(clk, rate);
-
-   if (div == 0)
-   return 0;
-
-   return clk_g

[PATCH v2 8/9] ARM: S3C24XX: convert s3c2410 to common clock framework

[Heiko Stübner]

Convert the machines using the s3c2410 to use the new driver based
on the common clock framework instead of the legacy Samsung clock driver.

As with the s3c244x, machines using the clkout output will need a fixup
from someone with the hardware.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Tomasz Figa 
---
 arch/arm/mach-s3c24xx/Kconfig   |  4 ++--
 arch/arm/mach-s3c24xx/common.c  |  2 --
 arch/arm/mach-s3c24xx/mach-amlm5900.c   |  9 +++--
 arch/arm/mach-s3c24xx/mach-bast.c   | 10 +++---
 arch/arm/mach-s3c24xx/mach-h1940.c  | 10 +++---
 arch/arm/mach-s3c24xx/mach-n30.c| 12 
 arch/arm/mach-s3c24xx/mach-nexcoder.c   |  7 +--
 arch/arm/mach-s3c24xx/mach-otom.c   | 10 +++---
 arch/arm/mach-s3c24xx/mach-qt2410.c |  9 +++--
 arch/arm/mach-s3c24xx/mach-smdk2410.c   |  9 +++--
 arch/arm/mach-s3c24xx/mach-tct_hammer.c |  9 +++--
 arch/arm/mach-s3c24xx/mach-vr1000.c | 10 +++---
 12 files changed, 67 insertions(+), 34 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 96d1e54..57ebb13 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -37,10 +37,10 @@ comment "S3C24XX SoCs"
 config CPU_S3C2410
bool "SAMSUNG S3C2410"
default y
-   depends on SAMSUNG_CLOCK
+   select COMMON_CLK
select CPU_ARM920T
select CPU_LLSERIAL_S3C2410
-   select S3C2410_CLOCK
+   select S3C2410_COMMON_CLK
select S3C2410_DMA if S3C24XX_DMA
select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
select S3C2410_PM if PM
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index def8627..a7b1269 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -74,7 +74,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x3241,
.idmask = 0x,
.map_io = s3c2410_map_io,
-   .init_clocks= s3c2410_init_clocks,
.init_uarts = s3c2410_init_uarts,
.init   = s3c2410_init,
.name   = name_s3c2410
@@ -83,7 +82,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32410002,
.idmask = 0x,
.map_io = s3c2410_map_io,
-   .init_clocks= s3c2410_init_clocks,
.init_uarts = s3c2410_init_uarts,
.init   = s3c2410a_init,
.name   = name_s3c2410a
diff --git a/arch/arm/mach-s3c24xx/mach-amlm5900.c 
b/arch/arm/mach-s3c24xx/mach-amlm5900.c
index 284ea1f..0e175e0 100644
--- a/arch/arm/mach-s3c24xx/mach-amlm5900.c
+++ b/arch/arm/mach-s3c24xx/mach-amlm5900.c
@@ -161,11 +161,16 @@ static struct platform_device *amlm5900_devices[] 
__initdata = {
 static void __init amlm5900_map_io(void)
 {
s3c24xx_init_io(amlm5900_iodesc, ARRAY_SIZE(amlm5900_iodesc));
-   s3c24xx_init_clocks(0);
s3c24xx_init_uarts(amlm5900_uartcfgs, ARRAY_SIZE(amlm5900_uartcfgs));
samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 }
 
+static void __init amlm5900_init_time(void)
+{
+   s3c2410_init_clocks(1200);
+   samsung_timer_init();
+}
+
 #ifdef CONFIG_FB_S3C2410
 static struct s3c2410fb_display __initdata amlm5900_lcd_info = {
.width  = 160,
@@ -241,6 +246,6 @@ MACHINE_START(AML_M5900, "AML_M5900")
.map_io = amlm5900_map_io,
.init_irq   = s3c2410_init_irq,
.init_machine   = amlm5900_init,
-   .init_time  = samsung_timer_init,
+   .init_time  = amlm5900_init_time,
.restart= s3c2410_restart,
 MACHINE_END
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c 
b/arch/arm/mach-s3c24xx/mach-bast.c
index 13e078c..ab075a6 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -50,7 +50,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -581,11 +580,16 @@ static void __init bast_map_io(void)
s3c_hwmon_set_platdata(&bast_hwmon_info);
 
s3c24xx_init_io(bast_iodesc, ARRAY_SIZE(bast_iodesc));
-   s3c24xx_init_clocks(0);
s3c24xx_init_uarts(bast_uartcfgs, ARRAY_SIZE(bast_uartcfgs));
samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 }
 
+static void __init bast_init_time(void)
+{
+   s3c2410_init_clocks(1200);
+   samsung_timer_init();
+}
+
 static void __init bast_init(void)
 {
register_syscore_ops(&bast_pm_syscore_ops);
@@ -613,6 +617,6 @@ MACHINE_START(BAST, "Simtec-BAST")
.map_io = bast_map_io,
.init_irq   = s3c2410_init_irq,
.init_machine   = bast_init,
-   .init_time  = samsung_timer_init,
+   .init_time  = bast_init_time,
.restart= s3c2410_restart,
 MACHINE_END
diff --git a/arch/arm/mach-s3c24xx/m

[PATCH v2 7/9] ARM: S3C24XX: convert s3c2440 and s3c2442 to common clock framework

[Heiko Stübner]

Convert all machines using these cpus to use the ccf clock driver
instead of the legacy Samsung clock implementation.

Some of the more esotheric machines will probably need a fixup, as they
do strange things to the clkout outputs, that I did not really understand
nor have the hardware to check.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Tomasz Figa 
---
 arch/arm/mach-s3c24xx/Kconfig  |  8 
 arch/arm/mach-s3c24xx/Makefile |  4 ++--
 arch/arm/mach-s3c24xx/common.c |  4 
 arch/arm/mach-s3c24xx/mach-anubis.c| 10 +++---
 arch/arm/mach-s3c24xx/mach-at2440evb.c | 10 +++---
 arch/arm/mach-s3c24xx/mach-gta02.c |  8 ++--
 arch/arm/mach-s3c24xx/mach-mini2440.c  | 10 +++---
 arch/arm/mach-s3c24xx/mach-nexcoder.c  | 15 ---
 arch/arm/mach-s3c24xx/mach-osiris.c| 10 +++---
 arch/arm/mach-s3c24xx/mach-rx1950.c| 10 +++---
 arch/arm/mach-s3c24xx/mach-rx3715.c| 10 +++---
 arch/arm/mach-s3c24xx/mach-smdk2440.c  | 10 +++---
 12 files changed, 73 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index daab788..96d1e54 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -73,10 +73,10 @@ config CPU_S3C2416
 
 config CPU_S3C2440
bool "SAMSUNG S3C2440"
-   depends on SAMSUNG_CLOCK
+   select COMMON_CLK
select CPU_ARM920T
select CPU_LLSERIAL_S3C2440
-   select S3C2410_CLOCK
+   select S3C2410_COMMON_CLK
select S3C2410_PM if PM
select S3C2440_DMA if S3C24XX_DMA
help
@@ -84,10 +84,10 @@ config CPU_S3C2440
 
 config CPU_S3C2442
bool "SAMSUNG S3C2442"
-   depends on SAMSUNG_CLOCK
+   select COMMON_CLK
select CPU_ARM920T
select CPU_LLSERIAL_S3C2440
-   select S3C2410_CLOCK
+   select S3C2410_COMMON_CLK
select S3C2410_DMA if S3C24XX_DMA
select S3C2410_PM if PM
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index f254797..9010eba 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -29,9 +29,9 @@ obj-$(CONFIG_S3C2412_PM_SLEEP)+= sleep-s3c2412.o
 obj-$(CONFIG_CPU_S3C2416)  += s3c2416.o
 obj-$(CONFIG_S3C2416_PM)   += pm-s3c2416.o
 
-obj-$(CONFIG_CPU_S3C2440)  += s3c2440.o clock-s3c2440.o
+obj-$(CONFIG_CPU_S3C2440)  += s3c2440.o
 obj-$(CONFIG_CPU_S3C2442)  += s3c2442.o
-obj-$(CONFIG_CPU_S3C244X)  += s3c244x.o clock-s3c244x.o
+obj-$(CONFIG_CPU_S3C244X)  += s3c244x.o
 obj-$(CONFIG_S3C2440_DMA)  += dma-s3c2440.o
 obj-$(CONFIG_S3C2440_PLL_1200) += pll-s3c2440-1200.o
 obj-$(CONFIG_S3C2440_PLL_16934400) += pll-s3c2440-16934400.o
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 5307bb7..def8627 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -92,7 +92,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x3244,
.idmask = 0x,
.map_io = s3c2440_map_io,
-   .init_clocks= s3c244x_init_clocks,
.init_uarts = s3c244x_init_uarts,
.init   = s3c2440_init,
.name   = name_s3c2440
@@ -101,7 +100,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32440001,
.idmask = 0x,
.map_io = s3c2440_map_io,
-   .init_clocks= s3c244x_init_clocks,
.init_uarts = s3c244x_init_uarts,
.init   = s3c2440_init,
.name   = name_s3c2440a
@@ -110,7 +108,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32440aaa,
.idmask = 0x,
.map_io = s3c2442_map_io,
-   .init_clocks= s3c244x_init_clocks,
.init_uarts = s3c244x_init_uarts,
.init   = s3c2442_init,
.name   = name_s3c2442
@@ -119,7 +116,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32440aab,
.idmask = 0x,
.map_io = s3c2442_map_io,
-   .init_clocks= s3c244x_init_clocks,
.init_uarts = s3c244x_init_uarts,
.init   = s3c2442_init,
.name   = name_s3c2442b
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c 
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 6a1a781..6b4f188 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -46,7 +46,6 @@
 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -415,7 +414,6 @@ static void __init anubis_map_io(void)
 #endif
 
s3c24xx_init_io(anubis_iodesc, ARRAY_SIZE(

[PATCH v2 6/9] ARM: S3C24XX: add platform code for conversion to the common clock framework

[Heiko Stübner]

This adds the necessary init functions to init the clocks from the common
clock framework and necessary CONFIG_SAMSUNG_CLOCK ifdefs around the legacy
clock code.

This also includes empty stubs for the *_setup_clocks functions that are
called from the cpufreq driver on resume.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Tomasz Figa 
---
 arch/arm/mach-s3c24xx/Kconfig   |  5 +
 arch/arm/mach-s3c24xx/common.c  | 25 +
 arch/arm/mach-s3c24xx/common.h  |  7 +++
 arch/arm/mach-s3c24xx/s3c2410.c |  6 ++
 arch/arm/mach-s3c24xx/s3c2442.c |  3 ++-
 arch/arm/mach-s3c24xx/s3c244x.c |  6 ++
 6 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 6036e77..daab788 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -18,6 +18,11 @@ config PLAT_S3C24XX
help
  Base platform code for any Samsung S3C24XX device
 
+config S3C2410_COMMON_CLK
+   bool
+   help
+ Build the s3c2410 clock driver based on the common clock framework.
+
 config S3C2410_COMMON_DCLK
bool
select REGMAP_MMIO
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 8e930e0..5307bb7 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "common.h"
 
@@ -534,6 +535,14 @@ struct platform_device s3c2443_device_dma = {
 };
 #endif
 
+#if defined(CONFIG_COMMON_CLK) && defined(CONFIG_CPU_S3C2410)
+void __init s3c2410_init_clocks(int xtal)
+{
+   s3c2410_common_clk_init(NULL, xtal, 0, S3C24XX_VA_CLKPWR);
+   samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
+}
+#endif
+
 #ifdef CONFIG_CPU_S3C2412
 void __init s3c2412_init_clocks(int xtal)
 {
@@ -548,6 +557,22 @@ void __init s3c2416_init_clocks(int xtal)
 }
 #endif
 
+#if defined(CONFIG_COMMON_CLK) && defined(CONFIG_CPU_S3C2440)
+void __init s3c2440_init_clocks(int xtal)
+{
+   s3c2410_common_clk_init(NULL, xtal, 1, S3C24XX_VA_CLKPWR);
+   samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
+}
+#endif
+
+#if defined(CONFIG_COMMON_CLK) && defined(CONFIG_CPU_S3C2442)
+void __init s3c2442_init_clocks(int xtal)
+{
+   s3c2410_common_clk_init(NULL, xtal, 2, S3C24XX_VA_CLKPWR);
+   samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
+}
+#endif
+
 #ifdef CONFIG_CPU_S3C2443
 void __init s3c2443_init_clocks(int xtal)
 {
diff --git a/arch/arm/mach-s3c24xx/common.h b/arch/arm/mach-s3c24xx/common.h
index 50504c7..2d65541 100644
--- a/arch/arm/mach-s3c24xx/common.h
+++ b/arch/arm/mach-s3c24xx/common.h
@@ -77,6 +77,7 @@ extern void s3c244x_restart(enum reboot_mode mode, const char 
*cmd);
 #ifdef CONFIG_CPU_S3C2440
 extern  int s3c2440_init(void);
 extern void s3c2440_map_io(void);
+extern void s3c2440_init_clocks(int xtal);
 extern void s3c2440_init_irq(void);
 #else
 #define s3c2440_init NULL
@@ -86,6 +87,7 @@ extern void s3c2440_init_irq(void);
 #ifdef CONFIG_CPU_S3C2442
 extern  int s3c2442_init(void);
 extern void s3c2442_map_io(void);
+extern void s3c2442_init_clocks(int xtal);
 extern void s3c2442_init_irq(void);
 #else
 #define s3c2442_init NULL
@@ -116,6 +118,11 @@ extern struct platform_device s3c2443_device_dma;
 
 extern struct platform_device s3c2410_device_dclk;
 
+#ifdef CONFIG_S3C2410_COMMON_CLK
+void __init s3c2410_common_clk_init(struct device_node *np, unsigned long 
xti_f,
+   int current_soc,
+   void __iomem *reg_base);
+#endif
 #ifdef CONFIG_S3C2412_COMMON_CLK
 void __init s3c2412_common_clk_init(struct device_node *np, unsigned long 
xti_f,
unsigned long ext_f, void __iomem *reg_base);
diff --git a/arch/arm/mach-s3c24xx/s3c2410.c b/arch/arm/mach-s3c24xx/s3c2410.c
index ffb92cbc..a1ce4b0 100644
--- a/arch/arm/mach-s3c24xx/s3c2410.c
+++ b/arch/arm/mach-s3c24xx/s3c2410.c
@@ -83,6 +83,7 @@ void __init s3c2410_map_io(void)
iotable_init(s3c2410_iodesc, ARRAY_SIZE(s3c2410_iodesc));
 }
 
+#ifdef CONFIG_SAMSUNG_CLOCK
 void __init_or_cpufreq s3c2410_setup_clocks(void)
 {
struct clk *xtal_clk;
@@ -142,6 +143,11 @@ void __init s3c2410_init_clocks(int xtal)
clkdev_add_table(s3c2410_clk_lookup, ARRAY_SIZE(s3c2410_clk_lookup));
samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
 }
+#else
+void __init_or_cpufreq s3c2410_setup_clocks(void)
+{
+}
+#endif
 
 struct bus_type s3c2410_subsys = {
.name = "s3c2410-core",
diff --git a/arch/arm/mach-s3c24xx/s3c2442.c b/arch/arm/mach-s3c24xx/s3c2442.c
index 2c8adc0..564c6503 100644
--- a/arch/arm/mach-s3c24xx/s3c2442.c
+++ b/arch/arm/mach-s3c24xx/s3c2442.c
@@ -53,6 +53,7 @@
 
 #include "common.h"
 
+#ifdef CONFIG_SAMSUNG_CLOCK
 /* S3C2442 extended clock support */
 
 static unsigned long s3c2442_camif_upll_round(struct clk *clk,
@@ -162,7 +163,7 @@ static __init int s3c2442_clk_init(void)
 }
 
 arch_initcall(s3c2442_clk_init);
-
+#end

[PATCH v2 5/9] clk: samsung: add clock controller driver for s3c2410, s3c2440 and s3c2442

[Heiko Stübner]

This driver can handle the clock controllers of the socs mentioned above,
as they share a common clock tree with only small differences.

The clock structure is built according to the manuals of the included
SoCs and might include changes in comparison to the previous clock
structure.

As pll-rate-tables only the 12mhz variants are currently included.
The original code was wrongly checking for 169mhz xti values [a 0 to much
at the end], so the original 16mhz pll table would have never been
included and its values are so obscure that I have no possibility to
at least check their sane-ness. When using the formula from the manual
the resulting frequency is near the table value but still slightly off.

Signed-off-by: Heiko Stuebner 
Acked-by: Mike Turquette 
---
 drivers/clk/samsung/Makefile|   1 +
 drivers/clk/samsung/clk-s3c2410.c   | 477 
 include/dt-bindings/clock/s3c2410.h |  62 +
 3 files changed, 540 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-s3c2410.c
 create mode 100644 include/dt-bindings/clock/s3c2410.h

diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 9892de4..2cb62f8 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5440)   += clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-audss.o
+obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o
 obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
 obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
 obj-$(CONFIG_S3C2443_COMMON_CLK)+= clk-s3c2443.o
diff --git a/drivers/clk/samsung/clk-s3c2410.c 
b/drivers/clk/samsung/clk-s3c2410.c
new file mode 100644
index 000..7b41821
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c2410.c
@@ -0,0 +1,477 @@
+/*
+ * Copyright (c) 2013 Heiko Stuebner 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for S3C2410 and following SoCs.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk.h"
+#include "clk-pll.h"
+
+#define LOCKTIME   0x00
+#define MPLLCON0x04
+#define UPLLCON0x08
+#define CLKCON 0x0c
+#define CLKSLOW0x10
+#define CLKDIVN0x14
+#define CAMDIVN0x18
+
+/* the soc types */
+enum supported_socs {
+   S3C2410,
+   S3C2440,
+   S3C2442,
+};
+
+/* list of PLLs to be registered */
+enum s3c2410_plls {
+   mpll, upll,
+};
+
+static void __iomem *reg_base;
+
+#ifdef CONFIG_PM_SLEEP
+static struct samsung_clk_reg_dump *s3c2410_save;
+
+/*
+ * list of controller registers to be saved and restored during a
+ * suspend/resume cycle.
+ */
+static unsigned long s3c2410_clk_regs[] __initdata = {
+   LOCKTIME,
+   MPLLCON,
+   UPLLCON,
+   CLKCON,
+   CLKSLOW,
+   CLKDIVN,
+   CAMDIVN,
+};
+
+static int s3c2410_clk_suspend(void)
+{
+   samsung_clk_save(reg_base, s3c2410_save,
+   ARRAY_SIZE(s3c2410_clk_regs));
+
+   return 0;
+}
+
+static void s3c2410_clk_resume(void)
+{
+   samsung_clk_restore(reg_base, s3c2410_save,
+   ARRAY_SIZE(s3c2410_clk_regs));
+}
+
+static struct syscore_ops s3c2410_clk_syscore_ops = {
+   .suspend = s3c2410_clk_suspend,
+   .resume = s3c2410_clk_resume,
+};
+
+static void s3c2410_clk_sleep_init(void)
+{
+   s3c2410_save = samsung_clk_alloc_reg_dump(s3c2410_clk_regs,
+   ARRAY_SIZE(s3c2410_clk_regs));
+   if (!s3c2410_save) {
+   pr_warn("%s: failed to allocate sleep save data, no sleep 
support!\n",
+   __func__);
+   return;
+   }
+
+   register_syscore_ops(&s3c2410_clk_syscore_ops);
+   return;
+}
+#else
+static void s3c2410_clk_sleep_init(void) {}
+#endif
+
+PNAME(fclk_p) = { "mpll", "div_slow" };
+
+struct samsung_mux_clock s3c2410_common_muxes[] __initdata = {
+   MUX(FCLK, "fclk", fclk_p, CLKSLOW, 4, 1),
+};
+
+static struct clk_div_table divslow_d[] = {
+   { .val = 0, .div = 1 },
+   { .val = 1, .div = 2 },
+   { .val = 2, .div = 4 },
+   { .val = 3, .div = 6 },
+   { .val = 4, .div = 8 },
+   { .val = 5, .div = 10 },
+   { .val = 6, .div = 12 },
+   { .val = 7, .div = 14 },
+   { /* sentinel */ },
+};
+
+struct samsung_div_clock s3c2410_common_dividers[] __initdata = {
+   DIV_T(0, "div_slow", "xti", CLKSLOW, 0, 3, divslow_d),
+   DIV(PCLK, "pclk", "hclk", CLKDIVN, 0, 1),
+};
+
+struct samsung_gate_clock s3c2410_common_gates[] __initdata = {
+   GATE(PCLK_SPI, "spi", "pclk", CLKCON, 18, 0, 0),
+   GATE(PCLK_I2S, "i2s", "pclk", 

[PATCH v2 4/9] dt-bindings: add documentation for s3c2410 clock controller

[Heiko Stübner]

Describe the clock controller of s3c2410, s3c2440 and s3c2442.

Signed-off-by: Heiko Stuebner 
Acked-by: Tomasz Figa 
---
 .../bindings/clock/samsung,s3c2410-clock.txt   | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt 
b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
new file mode 100644
index 000..0b64ad8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
@@ -0,0 +1,50 @@
+* Samsung S3C2410 Clock Controller
+
+The S3C2410 clock controller generates and supplies clock to various 
controllers
+within the SoC. The clock binding described here is applicable to the s3c2410,
+s3c2440 and s3c2442 SoCs in the s3c24x family.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "samsung,s3c2410-clock" - controller compatible with S3C2410 SoC.
+  - "samsung,s3c2440-clock" - controller compatible with S3C2440 SoC.
+  - "samsung,s3c2442-clock" - controller compatible with S3C2442 SoC.
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular SoC.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c2410-clock.h header and can be used in device
+tree sources.
+
+External clocks:
+
+The xti clock used as input for the plls is generated outside the SoC. It is
+expected that is are defined using standard clock bindings with a
+clock-output-names value of "xti".
+
+Example: Clock controller node:
+
+   clocks: clock-controller@4c00 {
+   compatible = "samsung,s3c2410-clock";
+   reg = <0x4c00 0x20>;
+   #clock-cells = <1>;
+   };
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller (refer to the standard clock bindings for information about
+  "clocks" and "clock-names" properties):
+
+   serial@50004000 {
+   compatible = "samsung,s3c2440-uart";
+   reg = <0x50004000 0x4000>;
+   interrupts = <1 23 3 4>, <1 23 4 4>;
+   clock-names = "uart", "clk_uart_baud2";
+   clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>;
+   status = "disabled";
+   };
-- 
1.9.0


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/9] ARM: S3C24XX: enable usage of common dclk if common clock framework is enabled

[Heiko Stübner]

Add platform device and select the correct implementation automatically
depending on wether the old samsung_clock or the common clock framework
is enabled.

This is only done for machines already using the old dclk implementation,
as everybody else should move to use dt anyway.

The machine-specific settings for the external clocks will have to be set
by somebody with knowledge about the specific hardware.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Tomasz Figa 
---
 arch/arm/mach-s3c24xx/Kconfig   | 22 +-
 arch/arm/mach-s3c24xx/common.c  | 14 ++
 arch/arm/mach-s3c24xx/common.h  |  2 ++
 arch/arm/mach-s3c24xx/mach-anubis.c |  5 +
 arch/arm/mach-s3c24xx/mach-bast.c   |  5 +
 arch/arm/mach-s3c24xx/mach-osiris.c |  5 +
 arch/arm/mach-s3c24xx/mach-rx1950.c |  5 +
 arch/arm/mach-s3c24xx/mach-vr1000.c |  5 +
 arch/arm/mach-s3c24xx/s3c244x.c |  2 ++
 9 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index d067f76..6036e77 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -18,6 +18,13 @@ config PLAT_S3C24XX
help
  Base platform code for any Samsung S3C24XX device
 
+config S3C2410_COMMON_DCLK
+   bool
+   select REGMAP_MMIO
+   help
+ Temporary symbol to build the dclk driver based on the common clock
+ framework.
+
 menu "SAMSUNG S3C24XX SoCs Support"
 
 comment "S3C24XX SoCs"
@@ -264,7 +271,8 @@ config ARCH_BAST
select ISA
select MACH_BAST_IDE
select S3C2410_IOTIMING if ARM_S3C2410_CPUFREQ
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
select S3C24XX_SIMTEC_USB
@@ -345,7 +353,8 @@ config MACH_TCT_HAMMER
 config MACH_VR1000
bool "Thorcom VR1000"
select MACH_BAST_IDE
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
select S3C24XX_SIMTEC_USB
@@ -530,7 +539,8 @@ config MACH_ANUBIS
bool "Simtec Electronics ANUBIS"
select HAVE_PATA_PLATFORM
select S3C2440_XTAL_1200
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_GPIO_EXTRA64
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_USB_HOST
@@ -571,7 +581,8 @@ config MACH_OSIRIS
bool "Simtec IM2440D20 (OSIRIS) module"
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_1200
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_GPIO_EXTRA128
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_NAND
@@ -643,7 +654,8 @@ config MACH_RX1950
select PM_H1940 if PM
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_16934400
-   select S3C24XX_DCLK
+   select S3C24XX_DCLK if SAMSUNG_CLOCK
+   select S3C24XX_COMMON_DCLK if COMMON_CLK
select S3C24XX_PWM
select S3C_DEV_NAND
help
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 92a1e3a..8e930e0 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -554,3 +554,17 @@ void __init s3c2443_init_clocks(int xtal)
s3c2443_common_clk_init(NULL, xtal, 1, S3C24XX_VA_CLKPWR);
 }
 #endif
+
+#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2440) || \
+   defined(CONFIG_CPU_S3C2442)
+static struct resource s3c2410_dclk_resource[] = {
+   [0] = DEFINE_RES_MEM(0x5684, 0x4),
+};
+
+struct platform_device s3c2410_device_dclk = {
+   .name   = "s3c2410-dclk",
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(s3c2410_dclk_resource),
+   .resource   = s3c2410_dclk_resource,
+};
+#endif
diff --git a/arch/arm/mach-s3c24xx/common.h b/arch/arm/mach-s3c24xx/common.h
index 3fade6d..50504c7 100644
--- a/arch/arm/mach-s3c24xx/common.h
+++ b/arch/arm/mach-s3c24xx/common.h
@@ -114,6 +114,8 @@ extern struct platform_device s3c2412_device_dma;
 extern struct platform_device s3c2440_device_dma;
 extern struct platform_device s3c2443_device_dma;
 
+extern struct platform_device s3c2410_device_dclk;
+
 #ifdef CONFIG_S3C2412_COMMON_CLK
 void __init s3c2412_common_clk_init(struct device_node *np, unsigned long 
xti_f,
unsigned long ext_f, void __iomem *reg_base);
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c 
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 2a16f8f..6a1a781 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -352,6 +352,7 @@ static struct platform_device 

[PATCH v2 2/9] clk: samsung: add clock driver for external clock outputs

[Heiko Stübner]

This adds a driver for controlling the external clock outputs of
s3c24xx architectures including the dclk muxes and dividers.

The driver at the moment only supports the legacy non-dt boards using these
clock outputs. The clock-output control itself is part of the system-controller
mainly controlled by the pinctrl drivers. So it should most likely be
integrated there for dt platforms.

Signed-off-by: Heiko Stuebner 
Acked-by: Mike Turquette 
---
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-s3c2410-dclk.c | 440 +
 2 files changed, 441 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-s3c2410-dclk.c

diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 77313e2..9892de4 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5440)   += clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-audss.o
+obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
 obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
 obj-$(CONFIG_S3C2443_COMMON_CLK)+= clk-s3c2443.o
 obj-$(CONFIG_ARCH_S3C64XX) += clk-s3c64xx.o
diff --git a/drivers/clk/samsung/clk-s3c2410-dclk.c 
b/drivers/clk/samsung/clk-s3c2410-dclk.c
new file mode 100644
index 000..8d8dff0
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c2410-dclk.c
@@ -0,0 +1,440 @@
+/*
+ * Copyright (c) 2013 Heiko Stuebner 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for s3c24xx external clock output.
+ */
+
+#include 
+#include 
+#include "clk.h"
+
+/* legacy access to misccr, until dt conversion is finished */
+#include 
+#include 
+
+#define MUX_DCLK0  0
+#define MUX_DCLK1  1
+#define DIV_DCLK0  2
+#define DIV_DCLK1  3
+#define GATE_DCLK0 4
+#define GATE_DCLK1 5
+#define MUX_CLKOUT06
+#define MUX_CLKOUT17
+#define DCLK_MAX_CLKS  (MUX_CLKOUT1 + 1)
+
+enum supported_socs {
+   S3C2410,
+   S3C2412,
+   S3C2440,
+   S3C2443,
+};
+
+struct s3c24xx_dclk_drv_data {
+   const char **clkout0_parent_names;
+   int clkout0_num_parents;
+   const char **clkout1_parent_names;
+   int clkout1_num_parents;
+   const char **mux_parent_names;
+   int mux_num_parents;
+};
+
+/*
+ * Clock for output-parent selection in misccr
+ */
+
+struct s3c24xx_clkout {
+   struct clk_hw   hw;
+   u32 mask;
+   u8  shift;
+};
+
+#define to_s3c24xx_clkout(_hw) container_of(_hw, struct s3c24xx_clkout, hw)
+
+static u8 s3c24xx_clkout_get_parent(struct clk_hw *hw)
+{
+   struct s3c24xx_clkout *clkout = to_s3c24xx_clkout(hw);
+   int num_parents = __clk_get_num_parents(hw->clk);
+   u32 val;
+
+   val = readl_relaxed(S3C24XX_MISCCR) >> clkout->shift;
+   val >>= clkout->shift;
+   val &= clkout->mask;
+
+   if (val >= num_parents)
+   return -EINVAL;
+
+   return val;
+}
+
+static int s3c24xx_clkout_set_parent(struct clk_hw *hw, u8 index)
+{
+   struct s3c24xx_clkout *clkout = to_s3c24xx_clkout(hw);
+   int ret = 0;
+
+   s3c2410_modify_misccr((clkout->mask << clkout->shift),
+ (index << clkout->shift));
+
+   return ret;
+}
+
+const struct clk_ops s3c24xx_clkout_ops = {
+   .get_parent = s3c24xx_clkout_get_parent,
+   .set_parent = s3c24xx_clkout_set_parent,
+   .determine_rate = __clk_mux_determine_rate,
+};
+
+struct clk *s3c24xx_register_clkout(struct device *dev, const char *name,
+   const char **parent_names, u8 num_parents,
+   u8 shift, u32 mask)
+{
+   struct s3c24xx_clkout *clkout;
+   struct clk *clk;
+   struct clk_init_data init;
+
+   /* allocate the clkout */
+   clkout = kzalloc(sizeof(*clkout), GFP_KERNEL);
+   if (!clkout)
+   return ERR_PTR(-ENOMEM);
+
+   init.name = name;
+   init.ops = &s3c24xx_clkout_ops;
+   init.flags = CLK_IS_BASIC;
+   init.parent_names = parent_names;
+   init.num_parents = num_parents;
+
+   clkout->shift = shift;
+   clkout->mask = mask;
+   clkout->hw.init = &init;
+
+   clk = clk_register(dev, &clkout->hw);
+
+   return clk;
+}
+
+/*
+ * dclk and clkout init
+ */
+
+struct s3c24xx_dclk {
+   struct device *dev;
+   void __iomem *base;
+   struct clk_onecell_data clk_data;
+   struct notifier_block dclk0_div_change_nb;
+   struct notifier_block dclk1_div_change_nb;
+   spinlock_t dclk_lock;
+   unsigned long reg_save;
+};
+
+#define to_s3c24xx_dclk0(x) \
+   container_of(x, struct s3c24xx_dclk, dclk0_div_change_nb)
+
+#define to_s3c24xx_dclk1(x) \
+ 

[PATCH v2 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf

[Heiko Stübner]

The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.

Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.

To not needing to create additional infrastructure for this, the mpll clock
is requested at the first call to s3c2410_set_fvco().

Signed-off-by: Heiko Stuebner 
---
 arch/arm/mach-s3c24xx/cpufreq-utils.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c 
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..d5e797b 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -60,5 +61,18 @@ void s3c2410_cpufreq_setrefresh(struct s3c_cpufreq_config 
*cfg)
  */
 void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
 {
+#ifdef CONFIG_SAMSUNG_CLOCK
__raw_writel(cfg->pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+   static struct clk *mpll;
+
+   if (!mpll)
+   mpll = clk_get(NULL, "mpll")
+   if (IS_ERR(mpll))
+   return;
+
+   clk_set_rate(mpll, cfg->pll.frequency);
+#endif
 }
-- 
1.9.0


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/9] ARM: S3C24XX: convert s3c2410, s3c2440 s3c2442 to common clock framework

[Heiko Stübner]

At least, here is v2 of the common clock conversion of s3c2410 - s3c2442.
If suitable this will finish the conversion of s3c24xx arches.

Tested on an Openmoko Neo Freerunner (GTA02).

It is meant to go on top of the s3c2412 ccf conversion already in
linux-samsung.

changes since v1:
- add already received Acks and Reviews
- remove patches that were already part of the s3c2412 submission
- implement suggestions from Tomasz Figa:
- in cpufreq-utils only request mpll clock the first time
- in dclk driver
  - use variant list to describe SoC differences
  - do not provide a dt binding at this time, as the dclk
parts should probably be part of the pinctrl driver
In any case this can be solved when the first dt platform needs
support for the external clock outputs
- in clk-s3c2410
  - fix sentinels
  - rename dt-bindings header
  - don't export XTI clock id


Heiko Stuebner (9):
  ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when
using ccf
  clk: samsung: add clock driver for external clock outputs
  ARM: S3C24XX: enable usage of common dclk if common clock framework is
enabled
  dt-bindings: add documentation for s3c2410 clock controller
  clk: samsung: add clock controller driver for s3c2410, s3c2440 and
s3c2442
  ARM: S3C24XX: add platform code for conversion to the common clock
framework
  ARM: S3C24XX: convert s3c2440 and s3c2442 to common clock framework
  ARM: S3C24XX: convert s3c2410 to common clock framework
  ARM: S3C24XX: remove legacy clock code

 .../bindings/clock/samsung,s3c2410-clock.txt   |  50 +++
 arch/arm/mach-s3c24xx/Kconfig  |  50 ++-
 arch/arm/mach-s3c24xx/Makefile |   6 +-
 arch/arm/mach-s3c24xx/clock-dclk.c | 195 -
 arch/arm/mach-s3c24xx/clock-s3c2410.c  | 285 
 arch/arm/mach-s3c24xx/clock-s3c2440.c  | 217 --
 arch/arm/mach-s3c24xx/clock-s3c244x.c  | 141 --
 arch/arm/mach-s3c24xx/common.c |  45 +-
 arch/arm/mach-s3c24xx/common.h |  11 +-
 arch/arm/mach-s3c24xx/cpufreq-utils.c  |  14 +
 arch/arm/mach-s3c24xx/include/mach/regs-clock.h|  18 -
 arch/arm/mach-s3c24xx/include/mach/regs-gpio.h |   3 -
 arch/arm/mach-s3c24xx/mach-amlm5900.c  |   9 +-
 arch/arm/mach-s3c24xx/mach-anubis.c|  15 +-
 arch/arm/mach-s3c24xx/mach-at2440evb.c |  10 +-
 arch/arm/mach-s3c24xx/mach-bast.c  |  15 +-
 arch/arm/mach-s3c24xx/mach-gta02.c |   8 +-
 arch/arm/mach-s3c24xx/mach-h1940.c |  10 +-
 arch/arm/mach-s3c24xx/mach-mini2440.c  |  10 +-
 arch/arm/mach-s3c24xx/mach-n30.c   |  12 +-
 arch/arm/mach-s3c24xx/mach-nexcoder.c  |  10 +-
 arch/arm/mach-s3c24xx/mach-osiris.c|  15 +-
 arch/arm/mach-s3c24xx/mach-otom.c  |  10 +-
 arch/arm/mach-s3c24xx/mach-qt2410.c|   9 +-
 arch/arm/mach-s3c24xx/mach-rx1950.c|  15 +-
 arch/arm/mach-s3c24xx/mach-rx3715.c|  10 +-
 arch/arm/mach-s3c24xx/mach-smdk2410.c  |   9 +-
 arch/arm/mach-s3c24xx/mach-smdk2440.c  |  10 +-
 arch/arm/mach-s3c24xx/mach-tct_hammer.c|   9 +-
 arch/arm/mach-s3c24xx/mach-vr1000.c|  15 +-
 arch/arm/mach-s3c24xx/pm.c |  12 -
 arch/arm/mach-s3c24xx/s3c2410.c|  56 ---
 arch/arm/mach-s3c24xx/s3c2442.c| 111 -
 arch/arm/mach-s3c24xx/s3c244x.c|  59 +--
 drivers/clk/samsung/Makefile   |   2 +
 drivers/clk/samsung/clk-s3c2410-dclk.c | 440 +++
 drivers/clk/samsung/clk-s3c2410.c  | 477 +
 include/dt-bindings/clock/s3c2410.h|  62 +++
 38 files changed, 1276 insertions(+), 1179 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
 delete mode 100644 arch/arm/mach-s3c24xx/clock-dclk.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2410.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2440.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c244x.c
 create mode 100644 drivers/clk/samsung/clk-s3c2410-dclk.c
 create mode 100644 drivers/clk/samsung/clk-s3c2410.c
 create mode 100644 include/dt-bindings/clock/s3c2410.h

-- 
1.9.0


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

[Ajay kumar]

Thierry,

On Wed, Apr 23, 2014 at 1:12 PM, Thierry Reding
 wrote:
> On Wed, Apr 23, 2014 at 09:29:15AM +0200, Daniel Vetter wrote:
>> On Tue, Apr 22, 2014 at 08:06:19PM +0530, Ajay kumar wrote:
>> > Hi Thierry,
>> >
>> >
>> > On Tue, Apr 22, 2014 at 1:49 PM, Thierry Reding 
>> > wrote:
>> > > On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote:
>> > >> Most of the panels need an init sequence as mentioned below:
>> > >>   -- poweron LCD unit/LCD_EN
>> > >>   -- start video data
>> > >>   -- poweron LED unit/BL_EN
>> > >> And, a de-init sequence as mentioned below:
>> > >>   -- poweroff LED unit/BL_EN
>> > >>   -- stop video data
>> > >>   -- poweroff LCD unit/LCD_EN
>> > >> With existing callbacks for drm panel, we cannot accomodate such panels,
>> > >> since only two callbacks, i.e "panel_enable" and panel_disable are
>> > supported.
>> > >>
>> > >> This patch adds:
>> > >>   -- "pre_enable" callback which can be called before
>> > >>   the actual video data is on, and then call the "enable"
>> > >>   callback after the video data is available.
>> > >>
>> > >>   -- "post_disable" callback which can be called after
>> > >>   the video data is off, and use "disable" callback
>> > >>   to do something before switching off the video data.
>> > >>
>> > >> Now, we can easily map the above scenario as shown below:
>> > >>   poweron LCD unit/LCD_EN = "pre_enable" callback
>> > >>   poweron LED unit/BL_EN = "enable" callback
>> > >>   poweroff LED unit/BL_EN = "disable" callback
>> > >>   poweroff LCD unit/LCD_EN = "post_disable" callback
>> > >
>> > > I don't like this. What happens when the next panel comes around that
>> > > has a yet slightly different requirement? Will we introduce a new
>> > > pre_pre_enable() and post_post_disable() function then?
>> > >
>> > As I have already explained, these 2 callbacks are sufficient enough to
>> > take care
>> > the power up/down sequence for LVDS and eDP panels. And, definitely having
>> > just 2 callbacks "enable" and "disable" is not at all sufficient.
>> >
>> > I initially thought of using panel_simple_enable from panel-simple driver.
>> > But it doesn't go well with case wherein there are 2 regulators(one for LCD
>> > and one for LED)
>> > a BL_EN signal etc. And, often(Believe me, I have referred to both eDP
>> > panel datasheets
>> > and LVDS panel datasheets) proper powerup sequence for such panels is as
>> > mentioned below:
>> >
>> > powerup:
>> > -- power up the supply (LCD_VCC).
>> > -- start video data.
>> > -- enable backlight.
>> >
>> > powerdown
>> > -- disable backlight.
>> > -- stop video data.
>> > -- power off the supply (LCD VCC)
>> >
>> > For the above cases, if I have to somehow fit in all the required settings,
>> > it breaks the sequence and I end up getting glitches during bootup/DPMS.
>> >
>> > Also, when the drm_bridge can support pre_enable and post_disable, why not
>> > drm_panel provide that both should work in tandem?
>>
>> Imo this makes sense, especially if we go through with the idea talked
>> about yesterday of creating a drm_bridge to wrap-up a drm_panel with
>> sufficient isolation between all components.
>
> I'm not at all comfortable with these. The names are totally confusing.
> Next somebody will need to do something after the panel has been enabled
> and we'll have to introduce .post_enable() and .pre_disable() functions.
> And worse, what if somebody needs something to be done between
> .pre_enable() and .enable()? .post_pre_enable()? Where does it end?
>
> According to the above description the only reason why we need this is
> to avoid visible glitches when the panel is already on, but the video
> stream hasn't started yet. If that's the only reason why we need this,
> then perhaps adding a way for a panel to expose the associated backlight
> would be better?
Actually, we need not expose the entire backlight device.
AFAIK, the glitch is caused when you enable BL_EN before
there is valid video data. So, one way to mask off the glitch is to
follow this sequence:
-- power up the panel.
-- start video data, (start PWM here or)
-- (start PWM here), enable backlight

The problem is that the above scenario cannot be mapped to panel-simple driver.
IMO, panel_simple should provide enable/disable controls both for LCD
and backlight.
something like panel_simple_lcd_enable/panel_simple_led_enable, and
panel_simple_lcd_disable/panel_simple_led_disable.

Then we can call panel_simple_lcd_enable before video stream is present,
And call panel_simple_led_enable after the video stream is present.
In that way we can accomodate majority of LVDS and eDP panels inside
panel_simple driver without having to worry about the glitch :)

Thanks and regards,
Ajay Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

[Ajay kumar]

Daniel,

On Wed, Apr 23, 2014 at 12:59 PM, Daniel Vetter  wrote:
> On Tue, Apr 22, 2014 at 08:06:19PM +0530, Ajay kumar wrote:
>> Hi Thierry,
>>
>>
>> On Tue, Apr 22, 2014 at 1:49 PM, Thierry Reding 
>> wrote:
>> > On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote:
>> >> Most of the panels need an init sequence as mentioned below:
>> >>   -- poweron LCD unit/LCD_EN
>> >>   -- start video data
>> >>   -- poweron LED unit/BL_EN
>> >> And, a de-init sequence as mentioned below:
>> >>   -- poweroff LED unit/BL_EN
>> >>   -- stop video data
>> >>   -- poweroff LCD unit/LCD_EN
>> >> With existing callbacks for drm panel, we cannot accomodate such panels,
>> >> since only two callbacks, i.e "panel_enable" and panel_disable are
>> supported.
>> >>
>> >> This patch adds:
>> >>   -- "pre_enable" callback which can be called before
>> >>   the actual video data is on, and then call the "enable"
>> >>   callback after the video data is available.
>> >>
>> >>   -- "post_disable" callback which can be called after
>> >>   the video data is off, and use "disable" callback
>> >>   to do something before switching off the video data.
>> >>
>> >> Now, we can easily map the above scenario as shown below:
>> >>   poweron LCD unit/LCD_EN = "pre_enable" callback
>> >>   poweron LED unit/BL_EN = "enable" callback
>> >>   poweroff LED unit/BL_EN = "disable" callback
>> >>   poweroff LCD unit/LCD_EN = "post_disable" callback
>> >
>> > I don't like this. What happens when the next panel comes around that
>> > has a yet slightly different requirement? Will we introduce a new
>> > pre_pre_enable() and post_post_disable() function then?
>> >
>> As I have already explained, these 2 callbacks are sufficient enough to
>> take care
>> the power up/down sequence for LVDS and eDP panels. And, definitely having
>> just 2 callbacks "enable" and "disable" is not at all sufficient.
>>
>> I initially thought of using panel_simple_enable from panel-simple driver.
>> But it doesn't go well with case wherein there are 2 regulators(one for LCD
>> and one for LED)
>> a BL_EN signal etc. And, often(Believe me, I have referred to both eDP
>> panel datasheets
>> and LVDS panel datasheets) proper powerup sequence for such panels is as
>> mentioned below:
>>
>> powerup:
>> -- power up the supply (LCD_VCC).
>> -- start video data.
>> -- enable backlight.
>>
>> powerdown
>> -- disable backlight.
>> -- stop video data.
>> -- power off the supply (LCD VCC)
>>
>> For the above cases, if I have to somehow fit in all the required settings,
>> it breaks the sequence and I end up getting glitches during bootup/DPMS.
>>
>> Also, when the drm_bridge can support pre_enable and post_disable, why not
>> drm_panel provide that both should work in tandem?
>
> Imo this makes sense, especially if we go through with the idea talked
> about yesterday of creating a drm_bridge to wrap-up a drm_panel with
> sufficient isolation between all components.
> -Daniel

Actually, I tried implementing this for ptn3460. But, it breaks the working.
As explained in the other patch(reply for Rob), we cannot truly ISOLATE
the panel controls from bridge controls and keep them as seperate.
They should be kept together, in the individual bridge chip drivers,
so that the bridge chip driver can decide which panel control to call
at what point.

So, I think combining bridge chip and panel controls was really a bad idea.
I will implement the basic panel controls required by the bridge
as optional bridge properties via DT. By that way, at least the driver
remains robust.


Thanks and regards,
Ajay Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

[Ajay kumar]

Sorry for the previous reply,

Here goes the full explaination:

> Rob,
>
> On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark  wrote:
>> So what about, rather than adding drm_panel support to each bridge
>> individually, we introduce a drm_panel_bridge (with a form of
>> chaining).. ie:
>>
>>   struct drm_panel_bridge {
>> struct drm_bridge base;
>> struct drm_panel *panel;
>> struct drm_bridge *bridge; /* optional */
>>   };
>>
>>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>>   {
>> struct drm_panel_bridge *pb = to_panel_bridge(bridge);
>> if (pb->bridge)
>>   pb->bridge->funcs->enable(pb->bridge);
>> pb->panel->funcs->enable(pb->panel);
>>   }
>>
We cannot call them like this from crtc helpers in the order you mentioned,
since each individual bridge chip expects the panel controls at
different places.
I mean,
-- sometimes panel controls needs to be done before bridge
controls(ptn3460: before RST_N and PD_N)
-- sometimes in between the bridge controls (ps8622: one panel control
before SLP_N and one after SLP_N)
-- sometimes panel controls needs to be done after bridge controls.

So, putting these drm_panel controls inside individual bridge drivers will work,
but keeping them in crtc_helpers might break stuff.

Thanks and regards,
Ajay Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

[Ajay kumar]

Rob,

On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark  wrote:
> So what about, rather than adding drm_panel support to each bridge
> individually, we introduce a drm_panel_bridge (with a form of
> chaining).. ie:
>
>   struct drm_panel_bridge {
> struct drm_bridge base;
> struct drm_panel *panel;
> struct drm_bridge *bridge; /* optional */
>   };
>
>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>   {
> struct drm_panel_bridge *pb = to_panel_bridge(bridge);
> if (pb->bridge)
>   pb->bridge->funcs->enable(pb->bridge);
> pb->panel->funcs->enable(pb->panel);
>   }
>
We cannot call them like this from crtc helpers in the order you mentioned,
since each individual bridge chip expects the panel controls at
different places.
I mean,
sometimes panel controls needs to be done before bridge controls,
> ... and so on.
>
> If you don't need a real bridge, just create one of these w/
> pb->bridge==NULL, otherwise create it as a wrapper for your real
> bridge.
>
> BR,
> -R
>
> On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar  wrote:
>> attach ptn3460 connector to drm_panel and support drm_panel routines,
>> if a valid drm_panel object is passed to ptn3460_init.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>> Changes since V1:
>> Address few coding style comments from Jingoo Han
>>
>>  drivers/gpu/drm/bridge/Kconfig  |1 +
>>  drivers/gpu/drm/bridge/ptn3460.c|   20 +++-
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   16 
>>  include/drm/bridge/ptn3460.h|6 --
>>  4 files changed, 36 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 884923f..3bc6845 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -2,4 +2,5 @@ config DRM_PTN3460
>> tristate "PTN3460 DP/LVDS bridge"
>> depends on DRM
>> select DRM_KMS_HELPER
>> +   select DRM_PANEL
>> ---help---
>> diff --git a/drivers/gpu/drm/bridge/ptn3460.c 
>> b/drivers/gpu/drm/bridge/ptn3460.c
>> index f1d2afc..3920202 100644
>> --- a/drivers/gpu/drm/bridge/ptn3460.c
>> +++ b/drivers/gpu/drm/bridge/ptn3460.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include "drmP.h"
>>  #include "drm_edid.h"
>> @@ -38,6 +39,7 @@ struct ptn3460_bridge {
>> struct i2c_client *client;
>> struct drm_encoder *encoder;
>> struct drm_bridge *bridge;
>> +   struct drm_panel *panel;
>> struct edid *edid;
>> int gpio_pd_n;
>> int gpio_rst_n;
>> @@ -126,6 +128,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
>> gpio_set_value(ptn_bridge->gpio_rst_n, 1);
>> }
>>
>> +   drm_panel_pre_enable(ptn_bridge->panel);
>> +
>> /*
>>  * There's a bug in the PTN chip where it falsely asserts hotplug 
>> before
>>  * it is fully functional. We're forced to wait for the maximum 
>> start up
>> @@ -142,6 +146,10 @@ static void ptn3460_pre_enable(struct drm_bridge 
>> *bridge)
>>
>>  static void ptn3460_enable(struct drm_bridge *bridge)
>>  {
>> +   struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
>> +
>> +   if (ptn_bridge->enabled)
>> +   drm_panel_enable(ptn_bridge->panel);
>>  }
>>
>>  static void ptn3460_disable(struct drm_bridge *bridge)
>> @@ -153,6 +161,9 @@ static void ptn3460_disable(struct drm_bridge *bridge)
>>
>> ptn_bridge->enabled = false;
>>
>> +   drm_panel_disable(ptn_bridge->panel);
>> +   drm_panel_post_disable(ptn_bridge->panel);
>> +
>> if (gpio_is_valid(ptn_bridge->gpio_rst_n))
>> gpio_set_value(ptn_bridge->gpio_rst_n, 1);
>>
>> @@ -198,6 +209,7 @@ int ptn3460_get_modes(struct drm_connector *connector)
>>
>> power_off = !ptn_bridge->enabled;
>> ptn3460_pre_enable(ptn_bridge->bridge);
>> +   ptn3460_enable(ptn_bridge->bridge);
>>
>> edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
>> if (!edid) {
>> @@ -265,7 +277,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
>>  };
>>
>>  int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
>> -   struct i2c_client *client, struct device_node *node)
>> +   struct i2c_client *client, struct device_node *node,
>> +   struct drm_panel *panel)
>>  {
>> int ret;
>> struct drm_bridge *bridge;
>> @@ -324,6 +337,11 @@ int ptn3460_init(struct drm_device *dev, struct 
>> drm_encoder *encoder,
>> goto err;
>> }
>>
>> +   if (panel) {
>> +   ptn_bridge->panel = panel;
>> +   drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
>> +   }
>> +
>> bridge->driver_private = ptn_bridge;
>> encoder->bridge = bridge;
>> ptn_bridge->connector.polled = DRM_CONNECTOR_POLL_HPD;
>> diff --git a/drivers/gpu/drm/exynos/e

Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

[Russell King - ARM Linux]

On Wed, Apr 23, 2014 at 05:43:28PM +0100, Russell King - ARM Linux wrote:
> So, maybe you would like to finally address *my* point about TDA998x
> and your solution in a way that provides a satisfactory answer.  *Show*
> how it can be done, or *outline* how it can be done.

Let me be absolutely clear *why* I'm very interested in this - and that
is because I'm presently converting TDA998x and Armada DRM to use the
component helpers.  If your solution is better, then I'd want to convert
to that instead, and let's retire the component helpers.

At the moment, my belief is that your solution is *very* substandard and
suboptimal precisely for the reasons I've outlined, especially when it
comes to sharing a component between several drivers.

So, if you *really* care, you'll stop fobbing me off on this point and
provide some real technical input how you'd see your solution being used
in exactly the scenario that I've been outlining several times in this
thread.

For example, you could show what kind of modifications you expect would
be required to the _existing_ TDA998x driver to allow it to participate
as a device declared in DT as an entirely separate entity, probed via the
standard I2C probing methods, and then hook itself into the appropriate
DRM driver.  Remembering, of course, that the TDA998x device is used by
more than _just_ Armada DRM.

I don't care if you show it via pseudo-code or by real patch.  I just
want to know _how_ your solution could be used.  And I won't want some
silly remark like "trivially" or "I've already answered that."  I want
_you_ to _show_ _how_ it can be done.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/3] ARM: exynos: Move to generic power domain bindings

[Tomasz Figa]

This patch moves Exynos power domain code to use the new generic power
domain look-up framework introduced by previous patch, allowing the new
code to be compiled with CONFIG_ARCH_EXYNOS selected as well.

Signed-off-by: Tomasz Figa 
---
 .../bindings/arm/exynos/power_domain.txt   | 12 ++--
 arch/arm/mach-exynos/pm_domains.c  | 81 +-
 kernel/power/Kconfig   |  2 +-
 3 files changed, 7 insertions(+), 88 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 5216b41..60f26a8 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -8,6 +8,8 @@ Required Properties:
 * samsung,exynos4210-pd - for exynos4210 type power domain.
 - reg: physical base address of the controller and length of memory mapped
 region.
+- #power-domain-cells: number of cells in power domain specifier;
+must be 0.
 
 Node of a device using power domains must have a samsung,power-domain property
 defined with a phandle to respective power domain.
@@ -17,12 +19,8 @@ Example:
lcd0: power-domain-lcd0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x10>;
+   #power-domain-cells = <0>;
};
 
-Example of the node using power domain:
-
-   node {
-   /* ... */
-   samsung,power-domain = <&lcd0>;
-   /* ... */
-   };
+See Documentation/devicetree/bindings/power/power_domain.txt for description
+of consumer-side bindings.
diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index fe6570e..9cad3c6 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -73,89 +73,14 @@ static int exynos_pd_power_off(struct generic_pm_domain 
*domain)
return exynos_pd_power(domain, false);
 }
 
-static void exynos_add_device_to_domain(struct exynos_pm_domain *pd,
-struct device *dev)
-{
-   int ret;
-
-   dev_dbg(dev, "adding to power domain %s\n", pd->pd.name);
-
-   while (1) {
-   ret = pm_genpd_add_device(&pd->pd, dev);
-   if (ret != -EAGAIN)
-   break;
-   cond_resched();
-   }
-
-   pm_genpd_dev_need_restore(dev, true);
-}
-
-static void exynos_remove_device_from_domain(struct device *dev)
-{
-   struct generic_pm_domain *genpd = dev_to_genpd(dev);
-   int ret;
-
-   dev_dbg(dev, "removing from power domain %s\n", genpd->name);
-
-   while (1) {
-   ret = pm_genpd_remove_device(genpd, dev);
-   if (ret != -EAGAIN)
-   break;
-   cond_resched();
-   }
-}
-
-static void exynos_read_domain_from_dt(struct device *dev)
-{
-   struct platform_device *pd_pdev;
-   struct exynos_pm_domain *pd;
-   struct device_node *node;
-
-   node = of_parse_phandle(dev->of_node, "samsung,power-domain", 0);
-   if (!node)
-   return;
-   pd_pdev = of_find_device_by_node(node);
-   if (!pd_pdev)
-   return;
-   pd = platform_get_drvdata(pd_pdev);
-   exynos_add_device_to_domain(pd, dev);
-}
-
-static int exynos_pm_notifier_call(struct notifier_block *nb,
-   unsigned long event, void *data)
-{
-   struct device *dev = data;
-
-   switch (event) {
-   case BUS_NOTIFY_BIND_DRIVER:
-   if (dev->of_node)
-   exynos_read_domain_from_dt(dev);
-
-   break;
-
-   case BUS_NOTIFY_UNBOUND_DRIVER:
-   exynos_remove_device_from_domain(dev);
-
-   break;
-   }
-   return NOTIFY_DONE;
-}
-
-static struct notifier_block platform_nb = {
-   .notifier_call = exynos_pm_notifier_call,
-};
-
 static __init int exynos4_pm_init_power_domain(void)
 {
-   struct platform_device *pdev;
struct device_node *np;
 
for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
struct exynos_pm_domain *pd;
int on;
 
-   pdev = of_find_device_by_node(np);
-
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
if (!pd) {
pr_err("%s: failed to allocate memory for domain\n",
@@ -168,17 +93,13 @@ static __init int exynos4_pm_init_power_domain(void)
pd->base = of_iomap(np, 0);
pd->pd.power_off = exynos_pd_power_off;
pd->pd.power_on = exynos_pd_power_on;
-   pd->pd.of_node = np;
-
-   platform_set_drvdata(pdev, pd);
 
on = __raw_readl(pd->base + 0x4) & S5P_INT_LOCAL_PWR_EN;
 
pm_genpd_init(&pd->pd, NULL, !on);
+   of_genpd_add_provider(np, of_genpd_xlate_simple, &pd->pd);

[PATCH v3 1/3] base: power: Add generic OF-based power domain look-up

[Tomasz Figa]

This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.

Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.

Signed-off-by: Tomasz Figa 
Reviewed-by: Mark Brown 
Reviewed-by: Kevin Hilman 
Reviewed-by: Philipp Zabel 
[on i.MX6 GK802]
Tested-by: Philipp Zabel 
---
 .../devicetree/bindings/power/power_domain.txt |  51 
 drivers/base/power/domain.c| 283 +
 include/linux/pm_domain.h  |  46 
 kernel/power/Kconfig   |   4 +
 4 files changed, 384 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt 
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+   Typically 0 for nodes representing a single power domain and 1 for nodes
+   providing multiple power domains (e.g. power controllers), but can be
+   any value as specified by device tree binding documentation of particular
+   provider.
+
+Example:
+
+   power: power-controller@1234 {
+   compatible = "foo,power-controller";
+   reg = <0x1234 0x1000>;
+   #power-domain-cells = <1>;
+   };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+  of power controller specified by phandle.
+
+Example:
+
+   leaky-device@1235 {
+   compatible = "foo,i-leak-current";
+   reg = <0x1235 0x1000>;
+   power-domain = <&power 0>;
+   };
+
+The node above defines a typical power domain consumer device, which is located
+inside power domain with index 0 of power controller represented by node with
+label "power".
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index ae098a2..7677744 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2189,3 +2190,285 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(&genpd->gpd_list_node, &gpd_list);
mutex_unlock(&gpd_list_lock);
 }
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+/*
+ * Device Tree based power domain providers.
+ *
+ * The code below implements generic device tree based power domain providers
+ * that bind device tree nodes with generic power domains registered in the
+ * system.
+ *
+ * Any driver that registers generic power domains and need to support binding
+ * of devices to these domains is supposed to register a power domain provider,
+ * which maps a power domain specifier retrieved from device tree to a power
+ * domain.
+ *
+ * Two simple mapping functions have been provided for convenience:
+ *  - of_genpd_xlate_simple() for 1:1 device tree node to domain mapping,
+ *  - of_genpd_xlate_onecell() for mapping of multiple domains per node
+ *by index.
+ */
+
+/**
+ * struct of_genpd_provider - Power domain provider registration structure
+ * @link: Entry in global list of domain providers
+ * @node: Pointer to device tree node of domain provider
+ * @xlate: Provider-specific xlate callback mapping a set of specifier cells
+ * into a power domain.
+ * @data: context pointer to be passed into @xlate callback
+ */
+struct of_genpd_provider {
+   struct list_head link;
+
+   struct device_node *node;
+   genpd_xlate_t xlate;
+   void *data;
+

[PATCH v3 2/3] drivercore: Bind/unbind power domain on probe/remove

[Tomasz Figa]

On a number of platforms, devices are part of controllable power
domains, which need to be enabled before such devices can be accessed
and may be powered down when the device is idle to save some power.
This means that on systems that support power domain control using
generic power domains subsystem, it is necessary to add device to its
power domain before binding a driver to it and remove it from its power
domain after its driver is unbound to make sure that an unused device
does not affect power domain state.

Since this is not limited to particular busses and specific
archs/platforms, it is more convenient to do the above directly in
driver core, just as done with pinctrl default configuration. This patch
adds necessary code to really_probe() and __device_release_driver() to
achieve this and maintain consistent stack-like ordering of operations
happening when binding and unbinding a driver.

Signed-off-by: Tomasz Figa 
Reviewed-by: Stephen Boyd 
Reviewed-by: Philipp Zabel 
[on i.MX6 GK802]
Tested-by: Philipp Zabel 
Reviewed-by: Mark Brown 
Reviewed-by: Ulf Hansson 
---
 drivers/base/dd.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8986b9f..7501c42 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -273,6 +274,11 @@ static int really_probe(struct device *dev, struct 
device_driver *drv)
 
dev->driver = drv;
 
+   /* If using genpd, bind power domain now before probing */
+   ret = genpd_bind_domain(dev);
+   if (ret)
+   goto probe_failed;
+
/* If using pinctrl, bind pins now before probing */
ret = pinctrl_bind_pins(dev);
if (ret)
@@ -303,6 +309,7 @@ static int really_probe(struct device *dev, struct 
device_driver *drv)
 probe_failed:
devres_release_all(dev);
driver_sysfs_remove(dev);
+   genpd_unbind_domain(dev);
dev->driver = NULL;
dev_set_drvdata(dev, NULL);
 
@@ -513,7 +520,7 @@ static void __device_release_driver(struct device *dev)
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
 BUS_NOTIFY_UNBOUND_DRIVER,
 dev);
-
+   genpd_unbind_domain(dev);
}
 }
 
-- 
1.9.2

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/3] Generic Device Tree based power domain look-up

[Tomasz Figa]

Up till now there was no single generic method to bind devices to their
power domains using Device Tree. Each platform has been doing this using
its own way, example of which are Exynos power domain bindings [1] and
look-up code [2].

This series is intended to change this and provide generic DT bindings for
power domain specification and generic code performing look-up of power
domains and binding them to devices.

First two patches are the most important part of this series, as they
introduce $subject. Patch 3 converts mach-exynos to use the new generic
method. Further patches are adding one more user of the new code,
mach-s3c64xx, with first 3 patches (4-6) required to clean-up its power
domain driver a bit and last 3 patches (9-11) adding display support for
Mini6410 board, including a node for display controller (FIMD) which is
a power domain consumer.

The design of DT bindings and provider code is heavily inspired by
implementation of clock providers in Common Clock Framework, while
the code binding devices to power domains by my Exynos power domain
implementation (now removed by this series ;)).

Successfully tested on Exynos4210-based Trats and Exynos4412-based Trats2
boards using MFC, 

[1] Documentation/devicetree/bindings/arm/exynos/power_domain.txt
[2] arch/arm/mach-exynos/pm_domains.c

Changes since v2:
(http://thread.gmane.org/gmane.linux.kernel/1658926)
 - rebased onto current Rafael's linux-pm bleeding-edge branch,
 - dropped patches for s3c64xx for now. I will send them in separate series,
 - do not call pm_genpd_dev_need_restore(true) in genpd_bind_domain(),
 - fixed various stylistic issues reported in review comments.

Changes since v1 (RFC):
[https://lkml.org/lkml/2014/1/11/141]
 - rebased onto current Rafael's linux-pm bleeding-edge branch,
 - reordered the patches a bit (to have the generic ones first),
 - dropped renaming of S3C64xx power domains (as suggested by Mark Brown),
 - added support for deferred probing (as suggested by Stephen Boyd),
 - fixed several minor issues pointed by Stephen Boyd,
 - replaced notifiers with direct hooks in driver core to make power domain
   support independent from specific bus type and allow error handling.

Tomasz Figa (3):
  base: power: Add generic OF-based power domain look-up
  drivercore: Bind/unbind power domain on probe/remove
  ARM: exynos: Move to generic power domain bindings

 .../bindings/arm/exynos/power_domain.txt   |  12 +-
 .../devicetree/bindings/power/power_domain.txt |  51 
 arch/arm/mach-exynos/pm_domains.c  |  81 +-
 drivers/base/dd.c  |   9 +-
 drivers/base/power/domain.c| 283 +
 include/linux/pm_domain.h  |  46 
 kernel/power/Kconfig   |   4 +
 7 files changed, 398 insertions(+), 88 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt

-- 
1.9.2

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

[Russell King - ARM Linux]

On Wed, Apr 23, 2014 at 05:04:46PM +0200, Andrzej Hajda wrote:
> On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote:
> > Yes, I know that you're desperate to play that down, but you can't get
> 
> Not true. I only try to find the best solution and the approach with
> multiple re-probing just to avoid potential bugs in drivers does not
> look to me correct.
> 
> > away from this fact: your approach _forces_ a split up of the
> > initialisation into dependent two stages and that fact _alone_ adds
> > additional complexity, and along with that additional complexity comes
> > more opportunity for bugs. 
> 
> This sound so funny, just look at componentize patches - every patch
> adds two stage initialization for every component and the master,
> with forced unwinding and two levels of devres management.

*Sigh*.  Why am I bothering discussing this with you.

*NO* it does not, for the VERY SIMPLE reason that NOTHING is done before
the BIND.  NO structures are allocated.  NOTHING is setup.  The *only*
thing that is done is the driver registers with the component helper.

That's not two stage initialisation.  That's *single* stage.

> 'My approach' adds only one call to probe and one call to remove of
> components, and very simple and straightforward interface to the master.

You're talking utter garbage there.

> 'My approach' is very standard - during probe driver probes hardware,
> and registers interfaces which can be used by other drivers, for example
> by drm master. The only addition is reporting its readiness. Comparing to
> 'your approach' it is bloody simple.

More unbelievable crap.

> >  Also with that additional complexity comes
> > the need to perform more tests to find those bugs, and given that most
> > people just say "okay, it boots and seems to work, that's good enough
> > for me" there is a high possibility that these kinds of bugs will take
> > a long time to find.
> 
> Volume of changes for each component and drm device management
> dispersed on all components makes your argument very valid for
> component subsystem.
> 
> Btw have you observed component framework when one of the components
> during bind returns -EPROBE_DEFER ? In my tests it resulted in
> deferred probing of master and unbind/bind of other components.
> So lets say you have N components and the last component will be deferred
> K times, it results in:
> - K times deferring of the last component and the master,
> - (N - 1) * K - unbinds and binds of other components.

True, and you can't get away from that with proper behaviour.

> >> As I wrote already, this framework was proposed for drivers which
> >> are tied together anyway, and this is case of many drivers, not
> >> only exynos.
> > Please name them.

You ignored this.  Therefore, I assume that you *can't* name them because
there *aren't* any.  I called your bluff, I win.

> > At the moment, I don't see a justification for your "simplified"
> > and restrictive solution, which if used will lock drivers into that
> > simplisitic method, and which can't ever be extended without lots of
> > ifdeffery to having other components (such as TDA998x) attached.
> >
> > My objections are entirely based on where imx-drm and armada DRM are
> > going, neither of which could ever use your implementation.
> >
> > Before you say that it isn't meant to deal with stuff like the TDA998x,
> > take a moment to think about this - the Dove video subsystem was
> > designed to support OLPC.  It was primerly designed to drive a LCD
> > screen plus an on-board VGA DAC.  Everything for that is on-SoC.  With
> > that, the hardware is well known, and your solution could be used.
> >
> > However, then SolidRun came along and dropped a TDA998x on the LCD output
> > pins.  Suddenly, things aren't that simple, and your solution falls
> > apart, because it can't cope with a generic component that has no knowledge
> > of the rest of its "master".
> >
> > This kind of scenario can happen /any/ time, and any time it does happen,
> > your simple solution falls apart.
> 
> I think I have answered you two or three times that it is not a problem
> to remove
> 'glued drivers' restriction. I desperately try to avoid accusing you for
> 'desperately
> playing down' on this subject, so I will not comment this anymore.

Right, so what I draw from this is that *you* again refuse to answer this
point because despite your assertions that your solution can do it, you
have no clue as to *how* it can be done.  I've looked at your solution
with respect to this, and I *can't* see how it can be done either.  That's
why I've been asking *you* the question, so that *you* can provide some
technical input to it.

> On the other hand you have not answered quite important question - how
> do you plan to componentize drivers shared by different drms when
> one of drms is not componentized???

Read this, from a message I sent at the beginning of February:
| Here's my changes to the TDA998x driver to add support for the component
| h

Re: [PATCH] mmc: dw_mmc: Don't print data errors

[Doug Anderson]

Seungwon / Ulf,

On Wed, Apr 23, 2014 at 1:17 AM, Ulf Hansson  wrote:
> On 23 April 2014 01:51, Doug Anderson  wrote:
>> Data errors are completely expected during tuning.  Printing them out
>> is confusing people looking at the kernel logs.  They see things like:
>>
>>  [3.613296] dwmmc_exynos 1220.dwmmc0: data error, status 0x0088
>>
>> ...and they think something is wrong with their hardware.
>>
>> Remove the printouts.  We'll leave it up to a higher level to report
>> about errors.
>>
>> Signed-off-by: Doug Anderson 
>> ---
>>  drivers/mmc/host/dw_mmc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index cced599..4c8d423 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1248,7 +1248,7 @@ static int dw_mci_data_complete(struct dw_mci *host, 
>> struct mmc_data *data)
>> data->error = -EIO;
>> }
>>
>> -   dev_err(host->dev, "data error, status 0x%08x\n", status);
>> +   dev_dbg(host->dev, "data error, status 0x%08x\n", status);
>>
>
> The "status" here could be useful information about the status
> register, which is not considered while printing errors by the "higher
> levels". An option could be to print the error, but not when you
> perform tuning.
>
> No big deal though, just a thought.

Right, I could potentially put the driver into "tuning" mode and then
suppress the errors during that time.  If you request it I will do
that.

I will also note that there are many other error conditions in the
driver that don't have such printouts.  I think the general philosophy
of this driver is not to print them...

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch v2 2/4] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420

[Lorenzo Pieralisi]

On Wed, Apr 23, 2014 at 10:25:52AM +0100, Chander Kashyap wrote:
> Add "samsung,exynos5420" compatible string to initialize generic
> big-little cpuidle driver for Exynos5420.
> 
> Signed-off-by: Chander Kashyap 
> Signed-off-by: Chander Kashyap 
> Acked-by: Daniel Lezcano 
> ---
>  drivers/cpuidle/cpuidle-big_little.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpuidle/cpuidle-big_little.c 
> b/drivers/cpuidle/cpuidle-big_little.c
> index b45fc62..d0fac53 100644
> --- a/drivers/cpuidle/cpuidle-big_little.c
> +++ b/drivers/cpuidle/cpuidle-big_little.c
> @@ -170,7 +170,8 @@ static int __init bl_idle_init(void)
>   /*
>* Initialize the driver just for a compliant set of machines
>*/
> - if (!of_machine_is_compatible("arm,vexpress,v2p-ca15_a7"))
> + if (!of_machine_is_compatible("arm,vexpress,v2p-ca15_a7") &&
> + (!of_machine_is_compatible("samsung,exynos5420")))
>   return -ENODEV;

We should handle the string matching differently, we can't keep adding
comparisons.

Daniel raised the point already: what about the idle tables (data and
number of states ?). TC2 has just a cluster state, and specific
latencies, which are highly unlikely to be correct for this platform.

Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/7] Add cros_ec changes for newer boards

[Stephen Warren]

On 04/23/2014 06:32 AM, Lee Jones wrote:
> On Tue, 22 Apr 2014, Doug Anderson wrote:
> 
>> This series adds the most critical cros_ec changes for newer boards
>> using cros_ec.  Specifically:
>> * Fixes timing/locking issues with the previously upstreamed (but
>>   never used upstream) cros_ec_spi driver.
>> * Updates the cros_ec header file to the latest version which allows
>>   us to use newer EC features like i2c tunneling.
>> * Adds an i2c tunnel driver to allow communication to the EC's i2c
>>   devices.
>>
>> This _doesn't_ get the EC driver fully up to speed with what's in the
>> current Chromium OS trees.  There are a whole slew of cleanup patches
>> there, an addition of an LPC transport mode, and exports of functions
>> to userspace.  Once these patches land and we have functionality we
>> can continue to pick more cleanup patches.
...
> Need to wait for the ARM, DT and I2C guys to review, at which point
> I'll be happy to take in and supply a branch for them to pull from if
> required. If there are no _true_ dependencies and the MFD changes can
> be added independently without fear of build breakages, let me know
> and I'll apply them separately.

I believe there aren't direct dependencies between the patches. So, the
MFD patches can be applied to the MFD tree and the DT patch applied to
the Tegra tree. I'm simply waiting for the MFD patches to be applied
before applying the DT patch so that I know the DT binding definition is
fully accepted before applying a patch that uses it.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 6/7] arm64: mm: Implement 4 levels of translation tables

[Steve Capper]

On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
> This patch implements 4 levels of translation tables since 3 levels
> of page tables with 4KB pages cannot support 40-bit physical address
> space described in [1] due to the following issue.
> 
> It is a restriction that kernel logical memory map with 4KB + 3 levels
> (0xffc0-0x) cannot cover RAM region from
> 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
> mapping for this region in map_mem function since __phys_to_virt for
> this region reaches to address overflow.
> 
> If SoC design follows the document, [1], over 32GB RAM would be placed
> from 544GB. Even 64GB system is supposed to use the region from 544GB
> to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
> of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
> 
> However, it is recommended 4 levels of page table should be only enabled
> if memory map is too sparse or there is about 512GB RAM.

Hello Jungseok,
A few comments can be found inline...

> 
> References
> --
> [1]: Principles of ARM Memory Maps, White Paper, Issue C
> 
> Signed-off-by: Jungseok Lee 
> Reviewed-by: Sungjinn Chung 
> ---
>  arch/arm64/Kconfig |7 +
>  arch/arm64/include/asm/memblock.h  |6 +
>  arch/arm64/include/asm/page.h  |4 ++-
>  arch/arm64/include/asm/pgalloc.h   |   20 +++
>  arch/arm64/include/asm/pgtable-hwdef.h |6 +++--
>  arch/arm64/include/asm/pgtable.h   |   44 
> ++--
>  arch/arm64/include/asm/tlb.h   |8 ++
>  arch/arm64/kernel/head.S   |   40 -
>  arch/arm64/kernel/traps.c  |5 
>  arch/arm64/mm/fault.c  |1 +
>  arch/arm64/mm/mmu.c|   16 +---
>  11 files changed, 136 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 431acbc..7f5270b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -184,12 +184,19 @@ config ARM64_3_LEVELS
>   help
> This feature enables 3 levels of translation tables.
>  
> +config ARM64_4_LEVELS
> + bool "4 level"
> + depends on ARM64_4K_PAGES
> + help
> +   This feature enables 4 levels of translation tables.
> +
>  endchoice
>  
>  config ARM64_VA_BITS
>   int "Virtual address space size"
>   range 39 39 if ARM64_4K_PAGES && ARM64_3_LEVELS
>   range 42 42 if ARM64_64K_PAGES && ARM64_2_LEVELS
> + range 48 48 if ARM64_4K_PAGES && ARM64_4_LEVELS
>   help
> This feature is determined by a combination of page size and
> level of translation tables.
> diff --git a/arch/arm64/include/asm/memblock.h 
> b/arch/arm64/include/asm/memblock.h
> index 6afeed2..e4ac8bf 100644
> --- a/arch/arm64/include/asm/memblock.h
> +++ b/arch/arm64/include/asm/memblock.h
> @@ -16,6 +16,12 @@
>  #ifndef __ASM_MEMBLOCK_H
>  #define __ASM_MEMBLOCK_H
>  
> +#ifndef CONFIG_ARM64_4_LEVELS
> +#define MEMBLOCK_INITIAL_LIMIT   PGDIR_SIZE
> +#else
> +#define MEMBLOCK_INITIAL_LIMIT   PUD_SIZE
> +#endif
> +
>  extern void arm64_memblock_init(void);
>  
>  #endif
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 268e53d..83b5289 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -35,8 +35,10 @@
>  
>  #ifdef CONFIG_ARM64_2_LEVELS
>  #include 
> -#else
> +#elif defined(CONFIG_ARM64_3_LEVELS)
>  #include 
> +#else
> +#include 
>  #endif
>  
>  extern void __cpu_clear_user_page(void *p, unsigned long user);
> diff --git a/arch/arm64/include/asm/pgalloc.h 
> b/arch/arm64/include/asm/pgalloc.h
> index 4829837..8d745fa 100644
> --- a/arch/arm64/include/asm/pgalloc.h
> +++ b/arch/arm64/include/asm/pgalloc.h
> @@ -26,6 +26,26 @@
>  
>  #define check_pgt_cache()do { } while (0)
>  
> +#ifdef CONFIG_ARM64_4_LEVELS
> +
> +static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
> +{
> + return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
> +}
> +
> +static inline void pud_free(struct mm_struct *mm, pud_t *pud)
> +{
> + BUG_ON((unsigned long)pud & (PAGE_SIZE-1));
> + free_page((unsigned long)pud);
> +}
> +
> +static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
> +{
> + set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
> +}
> +
> +#endif  /* CONFIG_ARM64_4_LEVELS */
> +
>  #ifndef CONFIG_ARM64_2_LEVELS
>  
>  static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
> b/arch/arm64/include/asm/pgtable-hwdef.h
> index 9cd86c6..ba30053 100644
> --- a/arch/arm64/include/asm/pgtable-hwdef.h
> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> @@ -18,8 +18,10 @@
>  
>  #ifdef CONFIG_ARM64_2_LEVELS
>  #include 
> -#else
> +#elif defined(CONFIG_ARM64_3_LEVELS)
>  #include

Re: [Patch v2 4/4] mcpm: exynos: populate suspend and powered_up callbacks

[Lorenzo Pieralisi]

[added Nico in CC]

On Wed, Apr 23, 2014 at 10:25:54AM +0100, Chander Kashyap wrote:
> In order to support cpuidle through mcpm, suspend and powered-up
> callbacks are required in mcpm platform code.
> Hence populate the same callbacks.
> 
> Signed-off-by: Chander Kashyap 
> Signed-off-by: Chander Kashyap 
> ---
> changes in v2:
>   1. Fixed typo: enynos_pmu_cpunr to exynos_pmu_cpunr
> 
>  arch/arm/mach-exynos/mcpm-exynos.c |   53 
> 
>  1 file changed, 53 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
> b/arch/arm/mach-exynos/mcpm-exynos.c
> index 6c74c82..d53f597 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -272,10 +272,63 @@ static int exynos_power_down_finish(unsigned int cpu, 
> unsigned int cluster)
>   return 0; /* success: the CPU is halted */
>  }
>  
> +static void enable_coherency(void)
> +{
> + unsigned long v, u;
> +
> + asm volatile(
> + "mrcp15, 0, %0, c1, c0, 1\n"
> + "orr%0, %0, %2\n"
> + "ldr%1, [%3]\n"
> + "and%1, %1, #0\n"
> + "orr%0, %0, %1\n"
> + "mcrp15, 0, %0, c1, c0, 1\n"
> + : "=&r" (v), "=&r" (u)
> + : "Ir" (0x40), "Ir" (S5P_INFORM0)
> + : "cc");
> +}
> +
> +void exynos_powered_up(void)
> +{
> + unsigned int mpidr, cpu, cluster;
> +
> + mpidr = read_cpuid_mpidr();
> + cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> + cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +
> + arch_spin_lock(&exynos_mcpm_lock);
> + if (cpu_use_count[cpu][cluster] == 0)
> + cpu_use_count[cpu][cluster] = 1;
> + arch_spin_unlock(&exynos_mcpm_lock);
> +}
> +
> +static void exynos_suspend(u64 residency)
> +{
> + unsigned int mpidr, cpunr;
> +
> + mpidr = read_cpuid_mpidr();
> + cpunr = exynos_pmu_cpunr(mpidr);
> +
> + __raw_writel(virt_to_phys(mcpm_entry_point), REG_ENTRY_ADDR);
> +
> + exynos_power_down();
> +
> + /*
> +  * Execution reaches here only if cpu did not power down.
> +  * Hence roll back the changes done in exynos_power_down function.
> + */
> + __raw_writel(EXYNOS_CORE_LOCAL_PWR_EN,
> + EXYNOS_ARM_CORE_CONFIGURATION(cpunr));
> + set_cr(get_cr() | CR_C);
> + enable_coherency();

This is wrong:

1) MCPM would eventually reboot the CPU in question if the suspend call
   returns (and restore SCTLR and ACTLR in cpu_resume), so there is 0 point
   in doing that here.
2) The core would have executed out of coherency for a "while" so the
   tlbs could be stale and you do not invalidate them. But given (1), (2)
   becomes just informational. The register write must be executed
   though (I guess...). Now, on restoring the SMP bit in cpu_resume
   (errata 799270) I need to verify this is safe and get back to you.

Cheers,
Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v3 3/5] mfd: tps65090: Stop caching most registers

[Doug Anderson]

Lee,

On Wed, Apr 23, 2014 at 3:55 AM, Lee Jones  wrote:
>> > Nearly all of the registers in tps65090 combine control bits and
>> > status bits.  Turn off caching of all registers except the select few
>> > that can be cached.
>>
>> Lee, I don't mind if I apply this and send a pull request to you or I
>> pull a tag from you with this in - what's easiest for you?
>
> I'm happy to do it.
>
> Doug,
>   Can you send the patch-set again with all of the *-bys and ensure
>   I'm on TO or CC please?

It looks as if you've already applied 1, 3, and 4.  I've sent up 2 and
5 again with collected tags.

https://patchwork.kernel.org/patch/4042761/
https://patchwork.kernel.org/patch/4042751/

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq

[Doug Anderson]

On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller).  The AP
is allowed to mess with FETs but the EC is in charge of charge control.

The tps65090 interupt line is routed to both the AP and the EC, which
can cause quite a headache.  Having two people adjusting masks and
acking interrupts is a recipe for disaster.

In the shipping kernel we had a hack to have the AP pay attention to
the IRQ but not to ack it.  It also wasn't supposed to configure the
IRQ in any way.  That hack allowed us to detect when the device was
charging without messing with the EC's state.

The current tps65090 infrastructure makes the above difficult, and it
was a bit of a hack to begin with.  Rather than uglify the driver to
support it, just extend the driver's existing notion of "no irq" to
the charger.  This makes the charger code poll every 2 seconds for AC
detect, which is sufficient.

For proper functioning, requires (mfd: tps65090: Don't tell child
devices we have an IRQ if we don't).  If we don't have that patch
we'll simply fail to probe on devices without an interrupt (just like
we did before this patch).

Signed-off-by: Doug Anderson 
---
Changes in v3: None
Changes in v2:
- Split noirq (polling mode) changes into MFD and charger

 drivers/power/tps65090-charger.c | 76 +++-
 1 file changed, 59 insertions(+), 17 deletions(-)

diff --git a/drivers/power/tps65090-charger.c b/drivers/power/tps65090-charger.c
index 8fc9d6d..cc26c12 100644
--- a/drivers/power/tps65090-charger.c
+++ b/drivers/power/tps65090-charger.c
@@ -17,9 +17,11 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,11 +45,15 @@
 #define TPS65090_VACG  BIT(1)
 #define TPS65090_NOITERM   BIT(5)
 
+#define POLL_INTERVAL  (HZ * 2)/* Used when no irq */
+
 struct tps65090_charger {
struct  device  *dev;
int ac_online;
int prev_ac_online;
int irq;
+   struct task_struct  *poll_task;
+   boolpassive_mode;
struct power_supply ac;
struct tps65090_platform_data *pdata;
 };
@@ -60,6 +66,9 @@ static int tps65090_low_chrg_current(struct tps65090_charger 
*charger)
 {
int ret;
 
+   if (charger->passive_mode)
+   return 0;
+
ret = tps65090_write(charger->dev->parent, TPS65090_REG_CG_CTRL5,
TPS65090_NOITERM);
if (ret < 0) {
@@ -75,6 +84,9 @@ static int tps65090_enable_charging(struct tps65090_charger 
*charger)
int ret;
uint8_t ctrl0 = 0;
 
+   if (charger->passive_mode)
+   return 0;
+
ret = tps65090_read(charger->dev->parent, TPS65090_REG_CG_CTRL0,
&ctrl0);
if (ret < 0) {
@@ -98,6 +110,9 @@ static int tps65090_config_charger(struct tps65090_charger 
*charger)
uint8_t intrmask = 0;
int ret;
 
+   if (charger->passive_mode)
+   return 0;
+
if (charger->pdata->enable_low_current_chrg) {
ret = tps65090_low_chrg_current(charger);
if (ret < 0) {
@@ -175,10 +190,14 @@ static irqreturn_t tps65090_charger_isr(int irq, void 
*dev_id)
}
 
/* Clear interrupts. */
-   ret = tps65090_write(charger->dev->parent, TPS65090_REG_INTR_STS, 0x00);
-   if (ret < 0) {
-   dev_err(charger->dev, "%s(): Error in writing reg 0x%x\n",
+   if (!charger->passive_mode) {
+   ret = tps65090_write(charger->dev->parent,
+TPS65090_REG_INTR_STS, 0x00);
+   if (ret < 0) {
+   dev_err(charger->dev,
+   "%s(): Error in writing reg 0x%x\n",
__func__, TPS65090_REG_INTR_STS);
+   }
}
 
if (charger->prev_ac_online != charger->ac_online)
@@ -209,6 +228,18 @@ static struct tps65090_platform_data *
 
 }
 
+static int tps65090_charger_poll_task(void *data)
+{
+   set_freezable();
+
+   while (!kthread_should_stop()) {
+   schedule_timeout_interruptible(POLL_INTERVAL);
+   try_to_freeze();
+   tps65090_charger_isr(-1, data);
+   }
+   return 0;
+}
+
 static int tps65090_charger_probe(struct platform_device *pdev)
 {
struct tps65090_charger *cdata;
@@ -255,22 +286,10 @@ static int tps65090_charger_probe(struct platform_device 
*pdev)
}
 
irq = platform_get_irq(pdev, 0);
-   if (irq <= 0) {
-   dev_warn(&pdev->dev, "Unable to get charger irq = %d\n", irq);
-   ret = irq;
-   goto fail_unregister_supply;
-   }
-
+   if (irq < 0)
+   irq = NO_IRQ;
cdata->irq = irq;
 
-   ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
-   tps65090_charger_isr, 0, 

[RESEND PATCH v3 5/5] regulator: tps65090: Make FETs more reliable by adding retries

[Doug Anderson]

An issue was discovered with tps65090 where sometimes the FETs
wouldn't actually turn on when requested (they would report
overcurrent).  The most problematic FET was the one used for the LCD
backlight on the Samsung ARM Chromebook (FET1).  Problems were
especially prevalent when the device was plugged in to AC power (when
the backlight voltage was higher).

Mitigate the problem by adding retries on the enables of the FETs,
which works around the problem fairly effectively.

Signed-off-by: Doug Anderson 
Signed-off-by: Simon Glass 
Signed-off-by: Michael Spang 
Signed-off-by: Sean Paul 
Reviewed-by: Simon Glass 
---
Changes in v3:
- Fixed kernel-doc notation for return

Changes in v2:
- Separated the overcurrent and retries changes into two patches.
- No longer open code fet_is_enabled().
- Fixed tps6090 typo.
- For loop => "while true".
- Removed a set of braces.

 drivers/regulator/tps65090-regulator.c | 155 +
 1 file changed, 140 insertions(+), 15 deletions(-)

diff --git a/drivers/regulator/tps65090-regulator.c 
b/drivers/regulator/tps65090-regulator.c
index ca04e9f..2057e2e 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -17,6 +17,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,7 +29,13 @@
 #include 
 #include 
 
+#define MAX_CTRL_READ_TRIES5
+#define MAX_FET_ENABLE_TRIES   1000
+
+#define CTRL_EN_BIT0 /* Regulator enable bit, active high */
 #define CTRL_WT_BIT2 /* Regulator wait time 0 bit */
+#define CTRL_PG_BIT4 /* Regulator power good bit, 1=good */
+#define CTRL_TO_BIT7 /* Regulator timeout bit, 1=wait */
 
 #define MAX_OVERCURRENT_WAIT   3 /* Overcurrent wait must be <= this */
 
@@ -80,40 +87,158 @@ static int tps65090_reg_set_overcurrent_wait(struct 
tps65090_regulator *ri,
return ret;
 }
 
-static struct regulator_ops tps65090_reg_contol_ops = {
+/**
+ * tps65090_try_enable_fet - Try to enable a FET
+ *
+ * @rdev:  Regulator device
+ *
+ * Return: 0 if ok, -ENOTRECOVERABLE if the FET power good bit did not get
+ * set, or some other -ve value if another error occurred (e.g. i2c error)
+ */
+static int tps65090_try_enable_fet(struct regulator_dev *rdev)
+{
+   unsigned int control;
+   int ret, i;
+
+   ret = regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
+rdev->desc->enable_mask,
+rdev->desc->enable_mask);
+   if (ret < 0) {
+   dev_err(&rdev->dev, "Error in updating reg %#x\n",
+   rdev->desc->enable_reg);
+   return ret;
+   }
+
+   for (i = 0; i < MAX_CTRL_READ_TRIES; i++) {
+   ret = regmap_read(rdev->regmap, rdev->desc->enable_reg,
+ &control);
+   if (ret < 0)
+   return ret;
+
+   if (!(control & BIT(CTRL_TO_BIT)))
+   break;
+
+   usleep_range(1000, 1500);
+   }
+   if (!(control & BIT(CTRL_PG_BIT)))
+   return -ENOTRECOVERABLE;
+
+   return 0;
+}
+
+/**
+ * tps65090_fet_enable - Enable a FET, trying a few times if it fails
+ *
+ * Some versions of the tps65090 have issues when turning on the FETs.
+ * This function goes through several steps to ensure the best chance of the
+ * FET going on.  Specifically:
+ * - We'll make sure that we bump the "overcurrent wait" to the maximum, which
+ *   increases the chances that we'll turn on properly.
+ * - We'll retry turning the FET on multiple times (turning off in between).
+ *
+ * @rdev:  Regulator device
+ *
+ * Return: 0 if ok, non-zero if it fails.
+ */
+static int tps65090_fet_enable(struct regulator_dev *rdev)
+{
+   int ret, tries;
+
+   /*
+* Try enabling multiple times until we succeed since sometimes the
+* first try times out.
+*/
+   tries = 0;
+   while (true) {
+   ret = tps65090_try_enable_fet(rdev);
+   if (!ret)
+   break;
+   if (ret != -ENOTRECOVERABLE || tries == MAX_FET_ENABLE_TRIES)
+   goto err;
+
+   /* Try turning the FET off (and then on again) */
+   ret = regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
+rdev->desc->enable_mask, 0);
+   if (ret)
+   goto err;
+
+   tries++;
+   }
+
+   if (tries)
+   dev_warn(&rdev->dev, "reg %#x enable ok after %d tries\n",
+rdev->desc->enable_reg, tries);
+
+   return 0;
+err:
+   dev_warn(&rdev->dev, "reg %#x enable failed\n", rdev->desc->enable_reg);
+   WARN_ON(1);
+
+   return ret;
+}
+
+static struct regulator_ops tps65090_reg_control_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_di

Re: [PATCH v3 4/5] regulator: tps65090: Allow setting the overcurrent wait time

[Doug Anderson]

Lee,

On Wed, Apr 23, 2014 at 4:51 AM, Lee Jones  wrote:
>> The tps65090 regulator allows you to specify how long you want it to
>> wait before detecting an overcurrent condition.  Allow specifying that
>> through the device tree (or through platform data).
>>
>> Signed-off-by: Doug Anderson 
>> Signed-off-by: Simon Glass 
>> Signed-off-by: Michael Spang 
>> Signed-off-by: Sean Paul 
>> ---
>> Changes in v3:
>> - Fixed kernel-doc notation for return
>>
>> Changes in v2:
>> - Separated the overcurrent and retries changes into two patches.
>> - Now set overcurrent at probe time since it doesn't change.
>>
>>  .../devicetree/bindings/regulator/tps65090.txt |  4 ++
>>  drivers/regulator/tps65090-regulator.c | 56 
>> ++
>>  include/linux/mfd/tps65090.h   |  5 ++
>>  3 files changed, 65 insertions(+)
>
> Applied, thanks.

U, Mark said that he had already applied this patch to his tree (I
mentioned it in my recent summary and you can see it in this thread
too).  I don't see it on git.kernel.org though


I'm worried this will cause a merge conflict if you both apply it.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch v2 0/4] add cpuidle support for Exynos5420

[Kukjin Kim]

On 04/23/14 19:18, Rafael J. Wysocki wrote:

On Wednesday, April 23, 2014 02:55:50 PM Chander Kashyap wrote:

Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores.

This patchset adds cpuidle support for Exynos5420 SoC based on
generic big.little cpuidle driver.

Tested on SMDK5420.

This patch set depends on:
1. [PATCH 0/5] MCPM backend for Exynos5420
   http://www.spinics.net/lists/arm-kernel/msg321666.html

2. [PATCH v4] arm: exynos: generalize power register address calculation
   http://www.spinics.net/lists/arm-kernel/msg324024.html

Changelog is in respective patches.
Chander Kashyap (4):
   cpuidle: config: Add SOC_EXYNOS5420 entry to select
 cpuidle-big-little driver
   driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
   exynos: cpuidle: do not allow cpuidle registration for Exynos5420
   mcpm: exynos: populate suspend and powered_up callbacks

  arch/arm/mach-exynos/cpuidle.c   |3 ++
  arch/arm/mach-exynos/mcpm-exynos.c   |   53 ++
  drivers/cpuidle/Kconfig.arm  |2 +-
  drivers/cpuidle/cpuidle-big_little.c |3 +-
  4 files changed, 59 insertions(+), 2 deletions(-)


I'm assuming that the Exynos maintainers will take care of this, correct?



Yeah, I will if you have any objection :-)

BTW, I need to look at the dependent patches.

- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] dts: exynos5250: Add required VDD regulator supplies for usb

[Vivek Gautam]

Add required VDD 3.3V and VDD 1.0V regulator supplies to usb nodes.

Signed-off-by: Vivek Gautam 
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index a794a70..2f183b8 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -363,8 +363,20 @@
samsung,audio-codec = <&wm8994>;
};
 
+   usb@1200 {
+   vdd33-supply = <&ldo12_reg>;
+   vdd10-supply = <&ldo15_reg>;
+   };
+
usb@1211 {
samsung,vbus-gpio = <&gpx2 6 0>;
+   vdd33-supply = <&ldo12_reg>;
+   vdd10-supply = <&ldo15_reg>;
+   };
+
+   usb@1212 {
+   vdd33-supply = <&ldo12_reg>;
+   vdd10-supply = <&ldo15_reg>;
};
 
dp-controller@145B {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] dts: exynos5: Add required VDD supplies for USB

[Vivek Gautam]

Based on for-next branch of Kgene's linux-samsung tree, with
following patch series:
[PATCH 0/9] Enable USB 3.0 support on Exynos5 systems
https://lkml.org/lkml/2014/4/23/389

These are device tree patches corresponding to the usb driver patch-series:
[PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
[PATCH 2/3] usb: ehci-exynos: Make provision for vdd regulators
[PATCH 3/3] usb: dwc3-exynos: Make provision for vdd regulators

Vivek Gautam (3):
  dts: exynos5250: Add required VDD regulator supplies for usb
  dts: exynos5250-snow: Add required VDD regulator supplies for usb
  dts: exynos5420-smdk5420: Add required VDD regulator supplies for usb

 arch/arm/boot/dts/exynos5250-smdk5250.dts |   12 
 arch/arm/boot/dts/exynos5250-snow.dts |   12 
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   20 
 3 files changed, 44 insertions(+)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] dts: exynos5250-snow: Add required VDD regulator supplies for usb

[Vivek Gautam]

Add required VDD 3.3V and VDD 1.0V regulator supplies to usb nodes.

Signed-off-by: Vivek Gautam 
---
 arch/arm/boot/dts/exynos5250-snow.dts |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index fd9b3b3..21d1f31 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -214,12 +214,24 @@
enable-active-high;
};
 
+   usb@1200 {
+   vdd33-supply = <&ldo12_reg>;
+   vdd10-supply = <&ldo15_reg>;
+   };
+
phy@1210 {
vbus-supply = <&usb3_vbus_reg>;
};
 
usb@1211 {
samsung,vbus-gpio = <&gpx1 1 0>;
+   vdd33-supply = <&ldo12_reg>;
+   vdd10-supply = <&ldo15_reg>;
+   };
+
+   usb@1212 {
+   vdd33-supply = <&ldo12_reg>;
+   vdd10-supply = <&ldo15_reg>;
};
 
fixed-rate-clocks {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] dts: exynos5420-smdk5420: Add required VDD regulator supplies for usb

[Vivek Gautam]

Add required VDD 3.3V and VDD 1.0V regulator supplies to usb nodes.

Signed-off-by: Vivek Gautam 
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 96d99e1..323ce00 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -185,10 +185,30 @@
enable-active-high;
};
 
+   usb@1200 {
+   vdd33-supply = <&ldo9_reg>;
+   vdd10-supply = <&ldo11_reg>;
+   };
+
phy@1210 {
vbus-supply = <&usb300_vbus_reg>;
};
 
+   usb@1211 {
+   vdd33-supply = <&ldo9_reg>;
+   vdd10-supply = <&ldo11_reg>;
+   };
+
+   usb@1212 {
+   vdd33-supply = <&ldo9_reg>;
+   vdd10-supply = <&ldo11_reg>;
+   };
+
+   usb@1240 {
+   vdd33-supply = <&ldo9_reg>;
+   vdd10-supply = <&ldo11_reg>;
+   };
+
phy@1250 {
vbus-supply = <&usb301_vbus_reg>;
};
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

[Andrzej Hajda]

On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote:
> On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote:
>> On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
>>> On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
 Separation of the interfaces exposed by the device from the device itself
 seems to me a good thing. I would even consider it as a biggest
 advantage of this solution :)

 The problem of re-initialization does not seems to be relevant here, it
 is classic
 problem of coding correctness nothing more, it can appear here and in
 many different
 places.
>>> It may be a problem of coding correctless, but it's also a maintainability
>>> problem too - it makes it _much_ more difficult to ensure that everything
>>> is correct.
>> But forcibly re-initializing all component devices instead of fixing bugs
>> in specific drivers seems to be 'absolutely absurd' as classic says.
> They're *unnecessary* bugs that wouldn't even exist if it weren't for
> the forced-splitup of the initialisation into two separate parts that
> your approach mandates.
>
> Yes, I know that you're desperate to play that down, but you can't get

Not true. I only try to find the best solution and the approach with
multiple re-probing just to avoid potential bugs in drivers does not
look to me correct.

> away from this fact: your approach _forces_ a split up of the
> initialisation into dependent two stages and that fact _alone_ adds
> additional complexity, and along with that additional complexity comes
> more opportunity for bugs. 

This sound so funny, just look at componentize patches - every patch
adds two stage initialization for every component and the master,
with forced unwinding and two levels of devres management.

'My approach' adds only one call to probe and one call to remove of
components,
and very simple and straightforward interface to the master.

'My approach' is very standard - during probe driver probes hardware,
and registers interfaces which can be used by other drivers, for example
by drm master. The only addition is reporting its readiness. Comparing to
'your approach' it is bloody simple.


>  Also with that additional complexity comes
> the need to perform more tests to find those bugs, and given that most
> people just say "okay, it boots and seems to work, that's good enough
> for me" there is a high possibility that these kinds of bugs will take
> a long time to find.

Volume of changes for each component and drm device management
dispersed on all components makes your argument very valid for
component subsystem.

Btw have you observed component framework when one of the components
during bind returns -EPROBE_DEFER ? In my tests it resulted in
deferred probing of master and unbind/bind of other components.
So lets say you have N components and the last component will be deferred
K times, it results in:
- K times deferring of the last component and the master,
- (N - 1) * K - unbinds and binds of other components.


>
>> As I wrote already, this framework was proposed for drivers which
>> are tied together anyway, and this is case of many drivers, not
>> only exynos.
> Please name them.
>
>> Standalone drivers were not at my sight but I have also described in
>> other mail how the framework can be 'improved' to support standalone
>> drivers also.
> At the moment, I don't see a justification for your "simplified"
> and restrictive solution, which if used will lock drivers into that
> simplisitic method, and which can't ever be extended without lots of
> ifdeffery to having other components (such as TDA998x) attached.
>
> My objections are entirely based on where imx-drm and armada DRM are
> going, neither of which could ever use your implementation.
>
> Before you say that it isn't meant to deal with stuff like the TDA998x,
> take a moment to think about this - the Dove video subsystem was
> designed to support OLPC.  It was primerly designed to drive a LCD
> screen plus an on-board VGA DAC.  Everything for that is on-SoC.  With
> that, the hardware is well known, and your solution could be used.
>
> However, then SolidRun came along and dropped a TDA998x on the LCD output
> pins.  Suddenly, things aren't that simple, and your solution falls
> apart, because it can't cope with a generic component that has no knowledge
> of the rest of its "master".
>
> This kind of scenario can happen /any/ time, and any time it does happen,
> your simple solution falls apart.

I think I have answered you two or three times that it is not a problem
to remove
'glued drivers' restriction. I desperately try to avoid accusing you for
'desperately
playing down' on this subject, so I will not comment this anymore.

On the other hand you have not answered quite important question - how
do you plan to componentize drivers shared by different drms when
one of drms is not componentized???


Regards
Andrzej

--
To unsubscribe from this list: send the line "unsubscrib

[PATCH v5 3/9] dt: exynos5250: Enable support for generic USB DRD phy

[Vivek Gautam]

Add device tree node for new usbdrd-phy driver, which
is based on generic phy framework.

Signed-off-by: Vivek Gautam 
Reviewed-by: Tomasz Figa 
---
 arch/arm/boot/dts/exynos5250.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..d4254c0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -551,6 +551,16 @@
};
};
 
+   usbdrd_phy: phy@1210 {
+   compatible = "samsung,exynos5250-usbdrd-phy";
+   reg = <0x1210 0x100>;
+   clocks = <&clock CLK_USB3>, <&clock CLK_FIN_PLL>;
+   clock-names = "phy", "ref";
+   samsung,pmu-syscon = <&pmu_system_controller>;
+   samsung,pmu-offset = <0x704>;
+   #phy-cells = <1>;
+   };
+
usb@1211 {
compatible = "samsung,exynos4210-ehci";
reg = <0x1211 0x100>;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/9] dt: exynos5420: Enable support for USB 3.0 PHY controller

[Vivek Gautam]

Add device tree nodes for USB 3.0 PHY present alongwith
USB 3.0 controller Exynos 5420 SoC. This phy driver is
based on generic phy framework.

Signed-off-by: Vivek Gautam 
Reviewed-by: Tomasz Figa 
---
 arch/arm/boot/dts/exynos5420.dtsi |   20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..f69745f 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -732,4 +732,24 @@
clock-names = "secss";
samsung,power-domain = <&g2d_pd>;
};
+
+   usbdrd_phy0: phy@1210 {
+   compatible = "samsung,exynos5420-usbdrd-phy";
+   reg = <0x1210 0x100>;
+   clocks = <&clock CLK_USBD300>, <&clock CLK_SCLK_USBPHY300>;
+   clock-names = "phy", "ref";
+   samsung,pmu-syscon = <&pmu_system_controller>;
+   samsung,pmu-offset = <0x704>;
+   #phy-cells = <1>;
+   };
+
+   usbdrd_phy1: phy@1250 {
+   compatible = "samsung,exynos5420-usbdrd-phy";
+   reg = <0x1250 0x100>;
+   clocks = <&clock CLK_USBD301>, <&clock CLK_SCLK_USBPHY301>;
+   clock-names = "phy", "ref";
+   samsung,pmu-syscon = <&pmu_system_controller>;
+   samsung,pmu-offset = <0x708>;
+   #phy-cells = <1>;
+   };
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/9] dt: exynos5420: Enable support for DWC3 controller

[Vivek Gautam]

Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.

Signed-off-by: Vivek Gautam 
Reviewed-by: Tomasz Figa 
---
 arch/arm/boot/dts/exynos5420.dtsi |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index f69745f..e808d1b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -733,6 +733,23 @@
samsung,power-domain = <&g2d_pd>;
};
 
+   usb@1200 {
+   compatible = "samsung,exynos5250-dwusb3";
+   clocks = <&clock CLK_USBD300>;
+   clock-names = "usbdrd30";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   dwc3 {
+   compatible = "synopsys,dwc3";
+   reg = <0x1200 0x1>;
+   interrupts = <0 72 0>;
+   phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>;
+   phy-names = "usb2-phy", "usb3-phy";
+   };
+   };
+
usbdrd_phy0: phy@1210 {
compatible = "samsung,exynos5420-usbdrd-phy";
reg = <0x1210 0x100>;
@@ -743,6 +760,23 @@
#phy-cells = <1>;
};
 
+   usb@1240 {
+   compatible = "samsung,exynos5250-dwusb3";
+   clocks = <&clock CLK_USBD301>;
+   clock-names = "usbdrd30";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   dwc3 {
+   compatible = "synopsys,dwc3";
+   reg = <0x1240 0x1>;
+   interrupts = <0 73 0>;
+   phys = <&usbdrd_phy1 0>, <&usbdrd_phy1 1>;
+   phy-names = "usb2-phy", "usb3-phy";
+   };
+   };
+
usbdrd_phy1: phy@1250 {
compatible = "samsung,exynos5420-usbdrd-phy";
reg = <0x1250 0x100>;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/9] dts: exynos5250: Update DWC3 usb controller to use new phy driver

[Vivek Gautam]

Removing the dt node for older usb3 phy driver from Exynos5250
device tree and updating the dt node for DWC3 controller to
use new phy driver based on generic phy framework.

Signed-off-by: Vivek Gautam 
Reviewed-by: Tomasz Figa 
---
 arch/arm/boot/dts/exynos5250.dtsi |   17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index d4254c0..d7c65e6 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -533,21 +533,8 @@
compatible = "synopsys,dwc3";
reg = <0x1200 0x1>;
interrupts = <0 72 0>;
-   usb-phy = <&usb2_phy &usb3_phy>;
-   };
-   };
-
-   usb3_phy: usbphy@1210 {
-   compatible = "samsung,exynos5250-usb3phy";
-   reg = <0x1210 0x100>;
-   clocks = <&clock CLK_FIN_PLL>, <&clock CLK_USB3>;
-   clock-names = "ext_xtal", "usbdrd30";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   usbphy-sys {
-   reg = <0x10040704 0x8>;
+   phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>;
+   phy-names = "usb2-phy", "usb3-phy";
};
};
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/9] dts: exynos5250-snow: Add Vbus regulator for USB 3.0

[Vivek Gautam]

Add required fixed-regulator for VBUS supply for USB 3.0
controller phy.

Signed-off-by: Vivek Gautam 
---

This is first version of the patch for VBUS support for USB3DRD phy.
v5 is just and indicative of the patch-series.

 arch/arm/boot/dts/exynos5250-snow.dts |   22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1ce1088..fd9b3b3 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -37,6 +37,13 @@
sd3_bus4: sd3-bus-width4 {
samsung,pin-drv = <0>;
};
+
+   usb3_vbus_en: usb3-vbus-en {
+   samsung,pins = "gpx2-7";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
};
 
gpio-keys {
@@ -196,6 +203,21 @@
};
};
 
+   usb3_vbus_reg: regulator-usb3 {
+   compatible = "regulator-fixed";
+   regulator-name = "P5.0V_USB3CON";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpx2 7 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb3_vbus_en>;
+   enable-active-high;
+   };
+
+   phy@1210 {
+   vbus-supply = <&usb3_vbus_reg>;
+   };
+
usb@1211 {
samsung,vbus-gpio = <&gpx1 1 0>;
};
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/9] dts: exynos5420-peach-pit: Add Vbus regulator for USB 3.0

[Vivek Gautam]

Add required fixed-regulator for VBUS supply for USB 3.0
controller phy.

Signed-off-by: Vivek Gautam 
---

This is first version of the patch for VBUS support for USB3DRD phy.
v5 is just and indicative of the patch-series.

 arch/arm/boot/dts/exynos5420-peach-pit.dts |   44 
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 4d61a5e..45c0fef 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -70,6 +70,20 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+   usb300_vbus_en: usb300-vbus-en {
+   samsung,pins = "gph0-0";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   usb301_vbus_en: usb301-vbus-en {
+   samsung,pins = "gph0-1";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
};
 
gpio-keys {
@@ -103,6 +117,36 @@
status = "okay";
};
 
+   usb300_vbus_reg: regulator-usb300 {
+   compatible = "regulator-fixed";
+   regulator-name = "P5.0V_USB3CON0";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gph0 0 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb300_vbus_en>;
+   enable-active-high;
+   };
+
+   usb301_vbus_reg: regulator-usb301 {
+   compatible = "regulator-fixed";
+   regulator-name = "P5.0V_USB3CON1";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gph0 1 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb301_vbus_en>;
+   enable-active-high;
+   };
+
+   phy@1210 {
+   vbus-supply = <&usb300_vbus_reg>;
+   };
+
+   phy@1250 {
+   vbus-supply = <&usb301_vbus_reg>;
+   };
+
mmc@1220 {
status = "okay";
num-slots = <1>;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 7/9] dts: exynos5420-smdk5420: Add Vbus regulator for USB 3.0

[Vivek Gautam]

Add required fixed-regulator for VBUS supply for USB 3.0
controller phy.

Signed-off-by: Vivek Gautam 
---

This is first version of the patch for VBUS support for USB3DRD phy.
v5 is just and indicative of the patch-series.

 arch/arm/boot/dts/exynos5420-smdk5420.dts |   46 +
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6910485..96d99e1 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -147,6 +147,52 @@
pinctrl-0 = <&hdmi_hpd_irq>;
};
 
+   pinctrl@1400 {
+   usb300_vbus_en: usb300-vbus-en {
+   samsung,pins = "gpg0-5";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   usb301_vbus_en: usb301-vbus-en {
+   samsung,pins = "gpg1-4";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+   };
+
+   usb300_vbus_reg: regulator-usb300 {
+   compatible = "regulator-fixed";
+   regulator-name = "VBUS0";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpg0 5 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb300_vbus_en>;
+   enable-active-high;
+   };
+
+   usb301_vbus_reg: regulator-usb301 {
+   compatible = "regulator-fixed";
+   regulator-name = "VBUS1";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpg1 4 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb301_vbus_en>;
+   enable-active-high;
+   };
+
+   phy@1210 {
+   vbus-supply = <&usb300_vbus_reg>;
+   };
+
+   phy@1250 {
+   vbus-supply = <&usb301_vbus_reg>;
+   };
+
i2c_2: i2c@12C8 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 9/9] ARM: exynos_defconfig: Remove SAMSUNG_USB3PHY config

[Vivek Gautam]

After removing the phy-samsung-usb3 driver, this config
should be removed.

Signed-off-by: Vivek Gautam 
---
 arch/arm/configs/exynos_defconfig |1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 4ce7b70..22cfc75 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -99,7 +99,6 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_PHY=y
 CONFIG_SAMSUNG_USB2PHY=y
-CONFIG_SAMSUNG_USB3PHY=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_S3C=y
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 8/9] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver

[Vivek Gautam]

Removing this older USB 3.0 DRD controller PHY driver, since
a new driver based on generic phy framework is now available.

Signed-off-by: Vivek Gautam 
Reviewed-by: Tomasz Figa 
---

This is reworked version for the patch :
[PATCH V4 5/5] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
https://lkml.org/lkml/2014/4/8/231

Changes from V4:
 - Removed phy-samsung-usb3.c references in the Makefile and Kconfig.

 drivers/usb/phy/Kconfig|8 -
 drivers/usb/phy/Makefile   |1 -
 drivers/usb/phy/phy-samsung-usb.h  |   80 -
 drivers/usb/phy/phy-samsung-usb3.c |  350 
 4 files changed, 439 deletions(-)
 delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 416e0c8..45c10f2 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -103,14 +103,6 @@ config SAMSUNG_USB2PHY
  Enable this to support Samsung USB 2.0 (High Speed) PHY controller
  driver for Samsung SoCs.
 
-config SAMSUNG_USB3PHY
-   tristate "Samsung USB 3.0 PHY controller Driver"
-   select SAMSUNG_USBPHY
-   select USB_PHY
-   help
- Enable this to support Samsung USB 3.0 (Super Speed) phy controller
- for samsung SoCs.
-
 config TWL6030_USB
tristate "TWL6030 USB Transceiver Driver"
depends on TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index f8fa719..d836ef0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -18,7 +18,6 @@ obj-$(CONFIG_AM335X_PHY_USB)  += phy-am335x.o
 obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
 obj-$(CONFIG_SAMSUNG_USBPHY)   += phy-samsung-usb.o
 obj-$(CONFIG_SAMSUNG_USB2PHY)  += phy-samsung-usb2.o
-obj-$(CONFIG_SAMSUNG_USB3PHY)  += phy-samsung-usb3.o
 obj-$(CONFIG_TWL6030_USB)  += phy-twl6030-usb.o
 obj-$(CONFIG_USB_EHCI_TEGRA)   += phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
diff --git a/drivers/usb/phy/phy-samsung-usb.h 
b/drivers/usb/phy/phy-samsung-usb.h
index 68771bf..dd2a0b5 100644
--- a/drivers/usb/phy/phy-samsung-usb.h
+++ b/drivers/usb/phy/phy-samsung-usb.h
@@ -155,86 +155,6 @@
 
 #define EXYNOS5_PHY_OTG_TUNE   (0x40)
 
-/* EXYNOS5: USB 3.0 DRD */
-#define EXYNOS5_DRD_LINKSYSTEM (0x04)
-
-#define LINKSYSTEM_FLADJ_MASK  (0x3f << 1)
-#define LINKSYSTEM_FLADJ(_x)   ((_x) << 1)
-#define LINKSYSTEM_XHCI_VERSION_CONTROL(0x1 << 27)
-
-#define EXYNOS5_DRD_PHYUTMI(0x08)
-
-#define PHYUTMI_OTGDISABLE (0x1 << 6)
-#define PHYUTMI_FORCESUSPEND   (0x1 << 1)
-#define PHYUTMI_FORCESLEEP (0x1 << 0)
-
-#define EXYNOS5_DRD_PHYPIPE(0x0c)
-
-#define EXYNOS5_DRD_PHYCLKRST  (0x10)
-
-#define PHYCLKRST_SSC_REFCLKSEL_MASK   (0xff << 23)
-#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) << 23)
-
-#define PHYCLKRST_SSC_RANGE_MASK   (0x03 << 21)
-#define PHYCLKRST_SSC_RANGE(_x)((_x) << 21)
-
-#define PHYCLKRST_SSC_EN   (0x1 << 20)
-#define PHYCLKRST_REF_SSP_EN   (0x1 << 19)
-#define PHYCLKRST_REF_CLKDIV2  (0x1 << 18)
-
-#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF   (0x19 << 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF  (0x02 << 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 << 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d << 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11)
-
-#define PHYCLKRST_FSEL_MASK(0x3f << 5)
-#define PHYCLKRST_FSEL(_x) ((_x) << 5)
-#define PHYCLKRST_FSEL_PAD_100MHZ  (0x27 << 5)
-#define PHYCLKRST_FSEL_PAD_24MHZ   (0x2a << 5)
-#define PHYCLKRST_FSEL_PAD_20MHZ   (0x31 << 5)
-#define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5)
-
-#define PHYCLKRST_RETENABLEN   (0x1 << 4)
-
-#define PHYCLKRST_REFCLKSEL_MASK   (0x03 << 2)
-#define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2)
-#define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2)
-
-#define PHYCLKRST_PORTRESET(0x1 << 1)
-#define PHYCLKRST_COMMONONN(0x1 << 0)
-
-#define EXYNOS5_DRD_PHYREG0(0x14)
-#define EXYNOS5_DRD_PHYREG1(0x18)
-
-#define EXYNOS5_DRD_PHYPARAM0  (0x1c)
-
-#define PHYPARAM0_REF_USE_PAD  (0x1 << 31)
-#define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f << 26)
-#define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
-
-#define EXYNOS5_DRD_PHYPARAM1  (0x20)
-
-#define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f << 0)
-#defi

[PATCH 0/9] Enable USB 3.0 support on Exynos5 systems

[Vivek Gautam]

Based on 'for-next' branch of Kgene's linux-samsung tree.
Tested with phy-driver[1] patches and peach-pit dts[2].

This is the DT split part of the patch-series[3].

Patches:  usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
  ARM: exynos_defconfig: Remove SAMSUNG_USB3PHY config
are removing the older phy-samsung-usb3 driver. Have included this driver patch
in this series since we are moving the device tree of DWC3 controller to new
phy driver, so we wouldn't be needing this older driver anymore.

[1]: [PATCH v6 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
 http://www.spinics.net/lists/linux-usb/msg106185.html
 [PATCH v6 2/2] phy: exynos5-usbdrd: Add facility for VBUS supply
 http://www.spinics.net/lists/linux-usb/msg106184.html

[2]: [PATCH] ARM: dts: Add peach-pit board support
 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg28846.html

[3]: [PATCH V4 0/5] Add Exynos5 USB 3.0 phy driver based on generic PHY 
framework
 https://lkml.org/lkml/2014/4/8/247

Vivek Gautam (9):
  dt: exynos5420: Enable support for USB 3.0 PHY controller
  dt: exynos5420: Enable support for DWC3 controller
  dt: exynos5250: Enable support for generic USB DRD phy
  dts: exynos5250: Update DWC3 usb controller to use new phy driver
  dts: exynos5250-snow: Add Vbus regulator for USB 3.0
  dts: exynos5420-peach-pit: Add Vbus regulator for USB 3.0
  dts: exynos5420-smdk5420: Add Vbus regulator for USB 3.0
  usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
  ARM: exynos_defconfig: Remove SAMSUNG_USB3PHY config

 arch/arm/boot/dts/exynos5250-snow.dts  |   22 ++
 arch/arm/boot/dts/exynos5250.dtsi  |   21 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   44 
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   46 
 arch/arm/boot/dts/exynos5420.dtsi  |   54 +
 arch/arm/configs/exynos_defconfig  |1 -
 drivers/usb/phy/Kconfig|8 -
 drivers/usb/phy/Makefile   |1 -
 drivers/usb/phy/phy-samsung-usb.h  |   80 ---
 drivers/usb/phy/phy-samsung-usb3.c |  350 
 10 files changed, 175 insertions(+), 452 deletions(-)
 delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH resend] mfd/rtc: s5m: Do not allocate RTC I2C dummy and regmap for unsupported chipsets

[Lee Jones]

> The rtc-s5m driver does not support all of S2M and S5M chipsets
> supported by main MFD sec-core driver. For such chipsets unsupported by
> rtc-s5m, the MFD sec-core driver initialized regmap with default config.
> This config in such cases wouldn't work at all.
> 
> The main MFD sec-core driver shouldn't initialize regmap for child
> drivers which is not used by them and even not valid.
> 
> Move the allocation of RTC I2C dummy device and initialization of RTC
> regmap from main MFD sec-core driver to the rtc-s5m driver. The rtc-s5m
> driver will use proper regmap config for supported devices.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/mfd/sec-core.c   | 53 +---
>  drivers/rtc/rtc-s5m.c| 75 
> +---
>  include/linux/mfd/samsung/core.h |  3 --
>  3 files changed, 71 insertions(+), 60 deletions(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] drm: Introduce drm_fb_helper_prepare()

[Thierry Reding]

On Wed, Apr 23, 2014 at 09:35:48AM +0200, Daniel Vetter wrote:
> On Wed, Apr 23, 2014 at 09:14:41AM +0200, Thierry Reding wrote:
> > On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
> > [...]
> > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > > b/drivers/gpu/drm/drm_fb_helper.c
> > [...]
> > > > @@ -502,6 +503,33 @@ static void drm_fb_helper_crtc_free(struct 
> > > > drm_fb_helper *helper)
> > > >  }
> > > >  
> > > >  /**
> > > > + * drm_fb_helper_prepare - setup a drm_fb_helper structure
> > > > + * @dev: DRM device
> > > > + * @helper: driver-allocated fbdev helper structure to set up
> > > > + * @funcs: pointer to structure of functions associate with this helper
> > > > + *
> > > > + * Sets up the bare minimum to make the framebuffer helper usable. 
> > > > This is
> > > > + * useful to implement race-free initialization of the polling 
> > > > helpers. In
> > > > + * that case a typical sequence would be:
> > > > + *
> > > > + *   - call drm_fb_helper_prepare()
> > > > + *   - set dev->mode_config.funcs
> > > 
> > > This step is done in drm_fb_helper_prepare already.
> > 
> > drm_fb_helper_prepare() sets fb_helper->funcs. dev->mode_config.funcs
> > needs to be set because it gets called by drm_kms_helper_hotplug_event()
> > which in turn is called by output_poll_execute(), which can be called at
> > any point after drm_kms_helper_poll_init(). It could be scheduled
> > immediately by drm_kms_helper_poll_enable().
> > 
> > I wonder if perhaps we should be wrapping that into a function as well.
> > Currently this is only documented in code by the drivers that call this.
> > But since it's only a single step it doesn't seem worth it. Perhaps if
> > we rolled the min/max_width/height into that function as well it would
> > be more worth it? That could be difficult to do since a couple of
> > drivers need to set those depending on the chipset generation.
> 
> Oh I've misread this step for the fb_helper->funcs assignment. Makes sense
> and I don't think we need to augment your kerneldoc more to explain this.
> 
> > > > + *   - perform driver-specific setup
> 
> Hm, maybe clarify this as "initialize modeset objects like crtcs, encoders
> and connectors"? Since that's the important part we need to get done here.
> 
> > > > + *   - call drm_kms_helper_poll_init()
> > > 
> > > Maybe mention that after this you can start to handle hpd events using the
> > > probe helpers?
> > 
> > Isn't that somewhat implied already? The poll helpers call directly the
> > dev->mode_config.funcs->output_poll_changed() function, which has
> > already been set up earlier.
> 
> I've more meant that after this it's save for drivers to enable hpd
> interrupts and start to process them. I.e.
> 
>   - enable interrupts and start processing hpd events
> 
> as an additional step to make it really cleear how it all fits together.
> Otherwise driver authors are left wondering wtf this isn't just one
> function call to do it all for them ;-)
> 
> > > > + *   - call drm_fb_helper_init()
> > > > + *   - call drm_fb_helper_single_add_all_connectors()
> > > > + *   - call drm_fb_helper_initial_config()
> > > 
> > > Does this list look sane in the generated DocBook? Afaik kerneldoc
> > > unfortunately lacks any form of markup, at least afaik :(
> > 
> > I must admit I didn't check. I'll make sure I do that before sending out
> > the next version.
> 
> If it looks ugly I'm ok as-is, just wondered. Kerneldoc is a bit
> simplistic ime.

In the second version I just sent out I ended up moving the description
of this sequence into the fbdev helper section rather than keeping it in
the description of the drm_fb_helper_prepare() function, since the new
function is really just a part of the whole sequence, so it seemed to
fit more nicely. And I've dropped the list formatting and turned it into
prose instead.

Thierry


pgpeZGgpUcAm7.pgp
Description: PGP signature

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Andrzej Hajda]

On 04/23/2014 02:55 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote:
>> On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
>>> On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
 On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings and cpu timings.
>
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat)
> Changelog v3:
> - Removes optional delay, size properties (commented by Laurent
> Pinchart)
> - Adds OLED detection, TE gpio properties
> Changelog v4:
> - Moves CPU timings relevant properties from FIMD DT
>
>   (commeted by Laurent Pinchart, Andrzej Hajda)
>
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>
>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63
>  +++
>
> 1 file changed, 63 insertions(+)
>
>  create mode 100644
>  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>
>
> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
> mode 100644
> index 000..9eeb38b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> @@ -0,0 +1,63 @@
> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> +
> +Required properties:
> +  - compatible: "samsung,s6e3fa0"
> +  - reg: the virtual channel number of a DSI peripheral
> +  - vdd3-supply: core voltage supply
> +  - vci-supply: voltage supply for analog circuits
> +  - reset-gpio: a GPIO spec for the reset pin
> +  - det-gpio: a GPIO spec for the OLED detection pin
> +  - te-gpio: a GPIO spec for the TE pin
> +  - display-timings: timings for the connected panel as described by
> [1]
 Which properties of display-timings are relevant for CPU mode?
 I guess width and height. Anything more?

> +  - cpu-timings: CPU interface timings for the connected panel, and it
> contains
> +following optional properties.
> +  - cs-setup: clock cycles for the active period of address
> signal
> +enable until chip select is enable in CPU interface
> +  - wr-setup: clock cycles for the active period of CS signal
> enable
> +until write signal is enable in CPU interface
> +  - wr-act: clock cycles for the active period of CS enable in
> CPU
> +interface
>>> What about calling this property wr-active ? I had called this wr-cycle in
>>> a previous implementation, that could be an option as well.
>>>
> +  - wr-hold: clock cycles for the active period of CS disable
> until
> +write signal is disable in CPU interface
 cpu-timings name does not sound to be related to display.
 I wonder if it would not be better to merge cpu-timings into
 display-timings but this will require more discussion I guess.
>>> The panel has a memory-like interface with chip select, read/write and
>>> access strobe, address (1 bit) and data signals. The interface is defined
>>> in the MIPI DBI specification (a quick search turned up
>>> http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might
>>> be direct PDF downloads available), even if some panels implement a
>>> similar interface that predates MIPI DBI (with names such as i80 or
>>> SYS-80 probably due to the similarities with the 8051 external bus).
>>>
>>> The cpu-timings properties describe the read and write access timings for
>>> those signals, unrelated to the display video timings. I thus believe that
>>> they should be separate from the display timings. We will probably need to
>>> add properties for the read signal as well, but that can be done later.
>> cpu-timings suggests these timings are for CPU, but they are for display
>> panel in CPU mode.
>> I though rather about something like display-cpu-timings or i80-timings,
>> just to avoid confusion.
> mipi-dbi-timings maybe ?

It looks OK.

I guess only hactive, and vactive props of display-timings are used,
maybe some flags?
I wonder if it would not be better to drop display-timings node
and place all props into mipi-dbi-timings or mipi-dbi-settings node.
Or rather all timings props should be put into port/endpoint node with
or without
any container node.

Regards
Andrzej

>
 If you want to stay with separate node please consider to make it
 optional as whole node or make some properties required. Making node
 required with all sub-properties optional is weird.
 By the way I hope all timings properties are generic for CPU mode,
 if not they should be prefixed by vendor or model.
>>> The timings description should be pretty generic I believe,

Re: [PATCH 06/10] ARM: EXYNOS: Add support for mapping PMU base address via DT

[Vikas Sajjan]

Hi,

On Wed, Apr 2, 2014 at 1:20 PM, Pankaj Dubey  wrote:
> From: Young-Gun Jang 
>
> Add support for mapping Exynos Power Management Unit (PMU) base address
> from device tree. Code will use existing samsung pmu binding information.
> This patch also adds "get_exynos_pmubase" a helper function to return mapped 
> base
> address to various other files under "mach-exynos".
>
> Signed-off-by: Young-Gun Jang 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/mach-exynos/common.h |2 ++
>  arch/arm/mach-exynos/exynos.c |   44 
> +
>  2 files changed, 46 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index ff28334..9a55cf6 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -61,4 +61,6 @@ struct exynos_pmu_conf {
>
>  extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
>
> +extern void __iomem *get_exynos_pmubase(void);
> +
>  #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index a5e1349..a5127fb 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -35,6 +35,8 @@
>  #define L2_AUX_VAL 0x7C470001
>  #define L2_AUX_MASK 0xC200
>
> +static void __iomem *exynos_pmu_base __initdata;

Are you sure you want to keep exynos_pmu_base in .init section.
I am seeing a crash in platform_do_lowpower()
I think you should remove __initdata.

> +
>  static struct map_desc exynos4_iodesc[] __initdata = {
> {
> .virtual= (unsigned long)S3C_VA_SYS,
> @@ -245,6 +247,47 @@ void __init exynos_init_late(void)
> exynos_pm_init();
>  }
>
> +static char const *exynos_dt_pmu_match[] __initconst = {
> +   "samsung,exynos4210-pmu",
> +   "samsung,exynos4212-pmu",
> +   "samsung,exynos4412-pmu",
> +   "samsung,exynos5250-pmu",
> +   NULL
> +};
> +
> +static int __init exynos_fdt_map_pmu(unsigned long node,
> +   const char *uname, int depth, void *data)
> +{
> +   struct map_desc iodesc;
> +   __be32 *reg;
> +   unsigned long len;
> +
> +   if (of_flat_dt_match(node, exynos_dt_pmu_match)) {
> +   phys_addr_t phys_addr;
> +   reg = of_get_flat_dt_prop(node, "reg", &len);
> +   if (reg == NULL || len != (sizeof(unsigned long) * 2))
> +   return 0;
> +
> +   phys_addr = be32_to_cpu(reg[0]);
> +   iodesc.pfn = __phys_to_pfn(phys_addr);
> +   iodesc.length = be32_to_cpu(reg[1]) - 1;
> +   iodesc.virtual = (unsigned long)S5P_VA_PMU;
> +   iodesc.type = MT_DEVICE;
> +   iotable_init(&iodesc, 1);
> +
> +   exynos_pmu_base = ioremap(phys_addr, be32_to_cpu(reg[1]));
> +   if (WARN_ON(!exynos_pmu_base))
> +   return -EFAULT;
> +   }
> +
> +   return 0;
> +}
> +
> +inline void __iomem *get_exynos_pmubase()
> +{
> +   return exynos_pmu_base;
> +}
> +
>  static int __init exynos_fdt_map_chipid(unsigned long node, const char 
> *uname,
> int depth, void *data)
>  {
> @@ -301,6 +344,7 @@ void __init exynos_init_io(void)
> debug_ll_io_init();
>
> of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
> +   of_scan_flat_dt(exynos_fdt_map_pmu, NULL);
>
> /* detect cpu id and rev. */
> s5p_init_cpu(S5P_VA_CHIPID);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Add MFCv8 support

[Arun Kumar K]

This patchset adds MFCv8 support to the s5p-mfc driver.
MFCv8 has the same operation sequence as that of v6+, but
there is some shuffling of the registers happened. So to
re-use the exisiting code, register access uses context
variables instead of macros.
The patchset modifies opr_v6 file to use register variables
and is tested on mfc v6, v7 and v8 based boards.

The patchset is based on the following set of patches
posted for MFC which are currently under review:

[media] s5p-mfc: Add support for resolution change event
v4l: Add resolution change event.
[media] s5p-mfc: Don't allocate codec buffers on STREAMON.
[media] s5p-mfc: Extract open/close MFC instance commands.
[media] s5p-mfc: Fixes for decode REQBUFS.
[media] s5p-mfc: Copy timestamps only when a frame is produced.
[media] s5p-mfc: add init buffer cmd to MFCV6
[media] s5p-mfc: Don't try to resubmit VP8 bitstream buffer for decode.
[media] s5p-mfc: Add a control for IVF format for VP8 encoder

Arun Kumar K (1):
  [media] s5p-mfc: Rename IS_MFCV7 macro

Kiran AVND (2):
  [media] s5p-mfc: Add variants to access mfc registers
  [media] s5p-mfc: Core support to add v8 decoder

 .../devicetree/bindings/media/s5p-mfc.txt  |3 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v8.h   |   93 +++
 drivers/media/platform/s5p-mfc/s5p_mfc.c   |   31 +
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h|7 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |4 +
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   |2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.c   |6 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h   |  254 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c|  792 +---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|7 +-
 10 files changed, 926 insertions(+), 273 deletions(-)
 create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v8.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] [media] s5p-mfc: Rename IS_MFCV7 macro

[Arun Kumar K]

With the inclusion of MFCv8 which reuses the v7 code,
the macro IS_MFCV7 is modified to IS_MFCV7_PLUS.

Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   14 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index f0e63f5..d64b680 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -703,7 +703,7 @@ void set_work_bit_irqsave(struct s5p_mfc_ctx *ctx);
(dev->variant->port_num ? 1 : 0) : 0) : 0)
 #define IS_TWOPORT(dev)(dev->variant->port_num == 2 ? 1 : 0)
 #define IS_MFCV6_PLUS(dev) (dev->variant->version >= 0x60 ? 1 : 0)
-#define IS_MFCV7(dev)  (dev->variant->version >= 0x70 ? 1 : 0)
+#define IS_MFCV7_PLUS(dev) (dev->variant->version >= 0x70 ? 1 : 0)
 #define IS_MFCV8(dev)  (dev->variant->version >= 0x80 ? 1 : 0)
 
 #endif /* S5P_MFC_COMMON_H_ */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index f8c7053..a9a23e1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1045,7 +1045,7 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
return -EINVAL;
}
 
-   if (!IS_MFCV7(dev) && (fmt->fourcc == V4L2_PIX_FMT_VP8)) {
+   if (!IS_MFCV7_PLUS(dev) && (fmt->fourcc == V4L2_PIX_FMT_VP8)) {
mfc_err("VP8 is supported only in MFC v7\n");
return -EINVAL;
}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 4324f2e..d0705b1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -120,7 +120,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
s5p_mfc_ctx *ctx)
(ctx->mv_count * ctx->mv_size);
break;
case S5P_MFC_CODEC_MPEG4_DEC:
-   if (IS_MFCV7(dev)) {
+   if (IS_MFCV7_PLUS(dev)) {
ctx->scratch_buf_size =
S5P_FIMV_SCRATCH_BUF_SIZE_MPEG4_DEC_V7(
mb_width,
@@ -373,7 +373,7 @@ static void s5p_mfc_enc_calc_src_size_v6(struct s5p_mfc_ctx 
*ctx)
ctx->chroma_size = ALIGN((mb_width * mb_height) * 128, 256);
 
/* MFCv7 needs pad bytes for Luma and Chroma */
-   if (IS_MFCV7(ctx->dev)) {
+   if (IS_MFCV7_PLUS(ctx->dev)) {
ctx->luma_size += MFC_LUMA_PAD_BYTES_V7;
ctx->chroma_size += MFC_CHROMA_PAD_BYTES_V7;
}
@@ -1312,7 +1312,7 @@ static bool s5p_mfc_is_v6_new(struct s5p_mfc_dev *dev)
unsigned long cur_fw, v6_new_fw;
unsigned int y, m, d;
 
-   if (IS_MFCV7(dev))
+   if (IS_MFCV7_PLUS(dev))
return false;
 
y = bcd2bin((dev->ver >> 16) & 0xFF) + 2000;
@@ -1357,7 +1357,7 @@ static int s5p_mfc_init_decode_v6(struct s5p_mfc_ctx *ctx)
WRITEL(ctx->display_delay, mfc_regs->d_display_delay);
}
 
-   if (IS_MFCV7(dev) || s5p_mfc_is_v6_new(dev)) {
+   if (IS_MFCV7_PLUS(dev) || s5p_mfc_is_v6_new(dev)) {
WRITEL(reg, mfc_regs->d_dec_options);
reg = 0;
}
@@ -1372,7 +1372,7 @@ static int s5p_mfc_init_decode_v6(struct s5p_mfc_ctx *ctx)
if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_NV12MT_16X16)
reg |= (0x1 << S5P_FIMV_D_OPT_TILE_MODE_SHIFT_V6);
 
-   if (IS_MFCV7(dev) || s5p_mfc_is_v6_new(dev))
+   if (IS_MFCV7_PLUS(dev) || s5p_mfc_is_v6_new(dev))
WRITEL(reg, mfc_regs->d_init_buffer_options);
else
WRITEL(reg, mfc_regs->d_dec_options);
@@ -1460,7 +1460,7 @@ static int s5p_mfc_init_encode_v6(struct s5p_mfc_ctx *ctx)
}
 
/* Set stride lengths for v7 & above */
-   if (IS_MFCV7(dev)) {
+   if (IS_MFCV7_PLUS(dev)) {
WRITEL(ctx->img_width, mfc_regs->e_source_first_plane_stride);
WRITEL(ctx->img_width, mfc_regs->e_source_second_plane_stride);
}
@@ -2202,7 +2202,7 @@ const struct s5p_mfc_regs 
*s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev)
R(e_h264_frame_packing_sei_info,
S5P_FIMV_E_H264_FRAME_PACKING_SEI_INFO_V6);
 
-   if (!IS_MFCV7(dev))
+   if (!IS_MFCV7_PLUS(dev))
goto done;
 
/* Initialize registers used in MFC v7+ */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  ht

[PATCH 2/3] [media] s5p-mfc: Core support to add v8 decoder

[Arun Kumar K]

From: Kiran AVND 

This patch adds variant data and core support for
V8 decoder. This patch also adds the register definition
file for new firmware version v8 for MFC.

Signed-off-by: Kiran AVND 
Signed-off-by: Pawel Osciak 
Signed-off-by: Arun Kumar K 
---
 .../devicetree/bindings/media/s5p-mfc.txt  |3 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v8.h   |   93 
 drivers/media/platform/s5p-mfc/s5p_mfc.c   |   30 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h|4 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |4 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c|   85 --
 6 files changed, 209 insertions(+), 10 deletions(-)
 create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v8.h

diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index f418168..3e3c5f3 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -10,7 +10,8 @@ Required properties:
   - compatible : value should be either one among the following
(a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
(b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
-   (b) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
+   (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
+   (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
 
   - reg : Physical base address of the IP registers and length of memory
  mapped region.
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
new file mode 100644
index 000..747907c
--- /dev/null
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
@@ -0,0 +1,93 @@
+/*
+ * Register definition file for Samsung MFC V8.x Interface (FIMV) driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _REGS_MFC_V8_H
+#define _REGS_MFC_V8_H
+
+#include "regs-mfc-v7.h"
+
+/* Additional registers for v8 */
+#define S5P_FIMV_D_MVC_NUM_VIEWS_V80xf104
+#define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8 0xf144
+#define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V80xf148
+#define S5P_FIMV_D_MV_BUFFER_SIZE_V8   0xf150
+
+#define S5P_FIMV_D_FIRST_PLANE_DPB_STRIDE_SIZE_V8  0xf138
+#define S5P_FIMV_D_SECOND_PLANE_DPB_STRIDE_SIZE_V8 0xf13c
+
+#define S5P_FIMV_D_FIRST_PLANE_DPB_V8  0xf160
+#define S5P_FIMV_D_SECOND_PLANE_DPB_V8 0xf260
+#define S5P_FIMV_D_MV_BUFFER_V80xf460
+
+#define S5P_FIMV_D_NUM_MV_V8   0xf134
+#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V8  0xf154
+
+#define S5P_FIMV_D_SCRATCH_BUFFER_ADDR_V8  0xf560
+#define S5P_FIMV_D_SCRATCH_BUFFER_SIZE_V8  0xf564
+
+#define S5P_FIMV_D_CPB_BUFFER_ADDR_V8  0xf5b0
+#define S5P_FIMV_D_CPB_BUFFER_SIZE_V8  0xf5b4
+#define S5P_FIMV_D_AVAILABLE_DPB_FLAG_LOWER_V8 0xf5bc
+#define S5P_FIMV_D_CPB_BUFFER_OFFSET_V80xf5c0
+#define S5P_FIMV_D_SLICE_IF_ENABLE_V8  0xf5c4
+#define S5P_FIMV_D_STREAM_DATA_SIZE_V8 0xf5d0
+
+/* Display information register */
+#define S5P_FIMV_D_DISPLAY_FRAME_WIDTH_V8  0xf600
+#define S5P_FIMV_D_DISPLAY_FRAME_HEIGHT_V8 0xf604
+
+/* Display status */
+#define S5P_FIMV_D_DISPLAY_STATUS_V8   0xf608
+
+#define S5P_FIMV_D_DISPLAY_FIRST_PLANE_ADDR_V8 0xf60c
+#define S5P_FIMV_D_DISPLAY_SECOND_PLANE_ADDR_V80xf610
+
+#define S5P_FIMV_D_DISPLAY_FRAME_TYPE_V8   0xf618
+#define S5P_FIMV_D_DISPLAY_CROP_INFO1_V8   0xf61c
+#define S5P_FIMV_D_DISPLAY_CROP_INFO2_V8   0xf620
+#define S5P_FIMV_D_DISPLAY_PICTURE_PROFILE_V8  0xf624
+
+/* Decoded picture information register */
+#define S5P_FIMV_D_DECODED_STATUS_V8   0xf644
+#define S5P_FIMV_D_DECODED_FIRST_PLANE_ADDR_V8 0xf648
+#define S5P_FIMV_D_DECODED_SECOND_PLANE_ADDR_V80xf64c
+#define S5P_FIMV_D_DECODED_THIRD_PLANE_ADDR_V8 0xf650
+#define S5P_FIMV_D_DECODED_FRAME_TYPE_V8   0xf654
+#define S5P_FIMV_D_DECODED_NAL_SIZE_V8  0xf664
+
+/* Returned value register for specific setting */
+#define S5P_FIMV_D_RET_PICTURE_TAG_TOP_V8  0xf674
+#define S5P_FIMV_D_RET_PICTURE_TAG_BOT_V8  0xf678
+#define S5P_FIMV_D_MVC_VIEW_ID_V8  0xf6d8
+
+/* SEI related information */
+#define S5P_FIMV_D_FRAME_PACK_SEI_AVAIL_V8 0xf6dc
+
+/* MFCv8 Context buffer sizes */
+#define MFC_CTX_BUF_SIZE_V8(30 * SZ_1K)/*  30KB */
+#define MFC_H264_DEC_CTX_BUF_SIZE_V8   (2 * SZ_1M) /*  2MB */
+#define MFC_OTHER_DEC_CTX_BUF_SIZE_V8  (20 * SZ_1K)/*  20KB */
+
+/* Buffer size defines */
+#define S5P_FIMV_SCRATCH_BUF_SIZE_H264_DEC_V8(w, h)(((w) * 704) + 2176)
+

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Laurent Pinchart]

Hi Andrzej,

On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote:
> On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
> > On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
> >> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> >>> This patch adds DT bindings for s6e3fa0 panel.
> >>> The bindings describes panel resources, display timings and cpu timings.
> >>> 
> >>> Changelog v2:
> >>> - Adds unit address (commented by Sachin Kamat)
> >>> Changelog v3:
> >>> - Removes optional delay, size properties (commented by Laurent
> >>> Pinchart)
> >>> - Adds OLED detection, TE gpio properties
> >>> Changelog v4:
> >>> - Moves CPU timings relevant properties from FIMD DT
> >>> 
> >>>   (commeted by Laurent Pinchart, Andrzej Hajda)
> >>> 
> >>> Signed-off-by: YoungJun Cho 
> >>> Acked-by: Inki Dae 
> >>> Acked-by: Kyungmin Park 
> >>> ---
> >>> 
> >>>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63
> >>>  +++
> >>> 
> >>> 1 file changed, 63 insertions(+)
> >>> 
> >>>  create mode 100644
> >>>  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>
> >>> 
> >>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >>> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
> >>> mode 100644
> >>> index 000..9eeb38b
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >>> @@ -0,0 +1,63 @@
> >>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> >>> +
> >>> +Required properties:
> >>> +  - compatible: "samsung,s6e3fa0"
> >>> +  - reg: the virtual channel number of a DSI peripheral
> >>> +  - vdd3-supply: core voltage supply
> >>> +  - vci-supply: voltage supply for analog circuits
> >>> +  - reset-gpio: a GPIO spec for the reset pin
> >>> +  - det-gpio: a GPIO spec for the OLED detection pin
> >>> +  - te-gpio: a GPIO spec for the TE pin
> >>> +  - display-timings: timings for the connected panel as described by
> >>> [1]
> >> 
> >> Which properties of display-timings are relevant for CPU mode?
> >> I guess width and height. Anything more?
> >> 
> >>> +  - cpu-timings: CPU interface timings for the connected panel, and it
> >>> contains
> >>> +following optional properties.
> >>> +  - cs-setup: clock cycles for the active period of address
> >>> signal
> >>> +enable until chip select is enable in CPU interface
> >>> +  - wr-setup: clock cycles for the active period of CS signal
> >>> enable
> >>> +until write signal is enable in CPU interface
> >>> +  - wr-act: clock cycles for the active period of CS enable in
> >>> CPU
> >>> +interface
> > 
> > What about calling this property wr-active ? I had called this wr-cycle in
> > a previous implementation, that could be an option as well.
> > 
> >>> +  - wr-hold: clock cycles for the active period of CS disable
> >>> until
> >>> +write signal is disable in CPU interface
> >> 
> >> cpu-timings name does not sound to be related to display.
> >> I wonder if it would not be better to merge cpu-timings into
> >> display-timings but this will require more discussion I guess.
> > 
> > The panel has a memory-like interface with chip select, read/write and
> > access strobe, address (1 bit) and data signals. The interface is defined
> > in the MIPI DBI specification (a quick search turned up
> > http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might
> > be direct PDF downloads available), even if some panels implement a
> > similar interface that predates MIPI DBI (with names such as i80 or
> > SYS-80 probably due to the similarities with the 8051 external bus).
> > 
> > The cpu-timings properties describe the read and write access timings for
> > those signals, unrelated to the display video timings. I thus believe that
> > they should be separate from the display timings. We will probably need to
> > add properties for the read signal as well, but that can be done later.
>
> cpu-timings suggests these timings are for CPU, but they are for display
> panel in CPU mode.
> I though rather about something like display-cpu-timings or i80-timings,
> just to avoid confusion.

mipi-dbi-timings maybe ?

> >> If you want to stay with separate node please consider to make it
> >> optional as whole node or make some properties required. Making node
> >> required with all sub-properties optional is weird.
> >> By the way I hope all timings properties are generic for CPU mode,
> >> if not they should be prefixed by vendor or model.
> > 
> > The timings description should be pretty generic I believe, especially
> > given that the interface is standardized by the MIPI alliance. Could you
> > have a quick look at the spec and share your opinion ?
> > 
> >>> +
> >>> +Optional properties:
> >>> +
> >>> +The device node can contain one 'port' child node with one child
> >>> +'endpoint' node, according to the bindings defined in [2]. This
> >>> +node should describe panel's 

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Andrzej Hajda]

On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>> This patch adds DT bindings for s6e3fa0 panel.
>>> The bindings describes panel resources, display timings and cpu timings.
>>>
>>> Changelog v2:
>>> - Adds unit address (commented by Sachin Kamat)
>>> Changelog v3:
>>> - Removes optional delay, size properties (commented by Laurent Pinchart)
>>> - Adds OLED detection, TE gpio properties
>>> Changelog v4:
>>> - Moves CPU timings relevant properties from FIMD DT
>>>
>>>   (commeted by Laurent Pinchart, Andrzej Hajda)
>>>
>>> Signed-off-by: YoungJun Cho 
>>> Acked-by: Inki Dae 
>>> Acked-by: Kyungmin Park 
>>> ---
>>>
>>>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 +++
>>> 1 file changed, 63 insertions(+)
>>>  create mode 100644
>>>  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt> 
>>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
>>> mode 100644
>>> index 000..9eeb38b
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>> @@ -0,0 +1,63 @@
>>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
>>> +
>>> +Required properties:
>>> +  - compatible: "samsung,s6e3fa0"
>>> +  - reg: the virtual channel number of a DSI peripheral
>>> +  - vdd3-supply: core voltage supply
>>> +  - vci-supply: voltage supply for analog circuits
>>> +  - reset-gpio: a GPIO spec for the reset pin
>>> +  - det-gpio: a GPIO spec for the OLED detection pin
>>> +  - te-gpio: a GPIO spec for the TE pin
>>> +  - display-timings: timings for the connected panel as described by [1]
>> Which properties of display-timings are relevant for CPU mode?
>> I guess width and height. Anything more?
>>
>>> +  - cpu-timings: CPU interface timings for the connected panel, and it
>>> contains
>>> +following optional properties.
>>> +  - cs-setup: clock cycles for the active period of address
>>> signal
>>> +enable until chip select is enable in CPU interface
>>> +  - wr-setup: clock cycles for the active period of CS signal
>>> enable
>>> +until write signal is enable in CPU interface
>>> +  - wr-act: clock cycles for the active period of CS enable in
>>> CPU
>>> +interface
> What about calling this property wr-active ? I had called this wr-cycle in a 
> previous implementation, that could be an option as well.
>
>>> +  - wr-hold: clock cycles for the active period of CS disable
>>> until
>>> +write signal is disable in CPU interface
>> cpu-timings name does not sound to be related to display.
>> I wonder if it would not be better to merge cpu-timings into
>> display-timings but this will require more discussion I guess.
> The panel has a memory-like interface with chip select, read/write and access 
> strobe, address (1 bit) and data signals. The interface is defined in the 
> MIPI 
> DBI specification (a quick search turned up 
> http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be 
> direct PDF downloads available), even if some panels implement a similar 
> interface that predates MIPI DBI (with names such as i80 or SYS-80 probably 
> due to the similarities with the 8051 external bus).
>
> The cpu-timings properties describe the read and write access timings for 
> those signals, unrelated to the display video timings. I thus believe that 
> they should be separate from the display timings. We will probably need to 
> add 
> properties for the read signal as well, but that can be done later.

cpu-timings suggests these timings are for CPU, but they are for display
panel in CPU mode.
I though rather about something like display-cpu-timings or i80-timings,
just to avoid confusion.

Regards
Andrzej

>> If you want to stay with separate node please consider to make it
>> optional as whole node or make some properties required. Making node
>> required with all sub-properties optional is weird.
>> By the way I hope all timings properties are generic for CPU mode,
>> if not they should be prefixed by vendor or model.
> The timings description should be pretty generic I believe, especially given 
> that the interface is standardized by the MIPI alliance. Could you have a 
> quick look at the spec and share your opinion ?
>
>>> +
>>> +Optional properties:
>>> +
>>> +The device node can contain one 'port' child node with one child
>>> +'endpoint' node, according to the bindings defined in [2]. This
>>> +node should describe panel's video bus.
>>> +
>>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
>>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> +   panel@0 {
>>> +   compatible = "samsung,s6e3fa0";
>>> +   reg = <0>;
>>> +   vdd3-supply = <&vcclcd_r

Re: [PATCH v2 2/7] mfd: cros_ec: spi: Add mutex to cros_ec_spi

[Lee Jones]

On Tue, 22 Apr 2014, Doug Anderson wrote:

> The main transfer function for cros_ec_spi can be called by more than
> one client at a time.  Make sure that those clients don't stomp on
> each other by locking the bus for the duration of the transfer
> function.
> 
> Signed-off-by: Doug Anderson 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v2: None
> 
>  drivers/mfd/cros_ec_spi.c | 26 +-
>  1 file changed, 21 insertions(+), 5 deletions(-)

Waiting for other subsystems to Ack, so for now:
  Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] usb: ehci-exynos: Make provision for vdd regulators

[Jingoo Han]

On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
> 
> Facilitate getting required 3.3V and 1.0V VDD supply for
> EHCI controller on Exynos.
> 
> With patches for regulators' nodes merged in 3.15:
> c8c253f ARM: dts: Add regulator entries to smdk5420
> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> 
> certain perripherals will now need to ensure that,
> they request VDD regulators in their drivers, and enable
> them so as to make them working.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
> Based on 'usb-next' branch of Greg's usb tree.
> 
>  drivers/usb/host/ehci-exynos.c |   47 
> 
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index d1d8c47..a3ca8cc 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -46,6 +47,8 @@ struct exynos_ehci_hcd {
>   struct clk *clk;
>   struct usb_phy *phy;
>   struct usb_otg *otg;
> + struct regulator *vdd33;
> + struct regulator *vdd10;
>  };
> 
>  #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd 
> *)(hcd_to_ehci(hcd)->priv)
> @@ -112,6 +115,28 @@ static int exynos_ehci_probe(struct platform_device 
> *pdev)
>   exynos_ehci->otg = phy->otg;
>   }
> 
> + exynos_ehci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> + if (IS_ERR(exynos_ehci->vdd33)) {
> + err = PTR_ERR(exynos_ehci->vdd33);
> + goto fail_regulator1;
> + }
> + err = regulator_enable(exynos_ehci->vdd33);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> + goto fail_regulator1;
> + }
> +
> + exynos_ehci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> + if (IS_ERR(exynos_ehci->vdd10)) {
> + err = PTR_ERR(exynos_ehci->vdd10);
> + goto fail_regulator2;
> + }
> + err = regulator_enable(exynos_ehci->vdd10);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> + goto fail_regulator2;
> + }
> +
>  skip_phy:
> 
>   exynos_ehci->clk = devm_clk_get(&pdev->dev, "usbhost");
> @@ -178,6 +203,10 @@ fail_add_hcd:
>  fail_io:
>   clk_disable_unprepare(exynos_ehci->clk);
>  fail_clk:
> + regulator_disable(exynos_ehci->vdd10);
> +fail_regulator2:
> + regulator_disable(exynos_ehci->vdd33);
> +fail_regulator1:
>   usb_put_hcd(hcd);
>   return err;
>  }
> @@ -197,6 +226,9 @@ static int exynos_ehci_remove(struct platform_device 
> *pdev)
> 
>   clk_disable_unprepare(exynos_ehci->clk);
> 
> + regulator_disable(exynos_ehci->vdd10);
> + regulator_disable(exynos_ehci->vdd33);
> +
>   usb_put_hcd(hcd);
> 
>   return 0;
> @@ -221,6 +253,9 @@ static int exynos_ehci_suspend(struct device *dev)
> 
>   clk_disable_unprepare(exynos_ehci->clk);
> 
> + regulator_disable(exynos_ehci->vdd10);
> + regulator_disable(exynos_ehci->vdd33);
> +
>   return rc;
>  }
> 
> @@ -228,6 +263,18 @@ static int exynos_ehci_resume(struct device *dev)
>  {
>   struct usb_hcd *hcd = dev_get_drvdata(dev);
>   struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
> + int ret;
> +
> + ret = regulator_enable(exynos_ehci->vdd33);
> + if (ret) {
> + dev_err(dev, "Failed to enable VDD33 supply\n");
> + return ret;
> + }
> + ret = regulator_enable(exynos_ehci->vdd10);
> + if (ret) {
> + dev_err(dev, "Failed to enable VDD10 supply\n");
> + return ret;
> + }
> 
>   clk_prepare_enable(exynos_ehci->clk);
> 
> --
> 1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/7] mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable

[Lee Jones]

On Tue, 22 Apr 2014, Doug Anderson wrote:

> The cros_ec_spi transfer had two problems with its timeout code:
> 
> 1. It looked at the timeout even in the case that it found valid data.
> 2. If the cros_ec_spi code got switched out for a while, it's possible
>it could get a timeout after a single loop.  Let's be paranoid and
>make sure we do one last transfer after the timeout expires.
> 
> Signed-off-by: Doug Anderson 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v2: None
> 
>  drivers/mfd/cros_ec_spi.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)

Waiting for other subsystems to Ack, so for now:
  Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

[Jingoo Han]

On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
> 
> Facilitate getting required 3.3V and 1.0V VDD supply for
> OHCI controller on Exynos.
> 
> With patches for regulators' nodes merged in 3.15:
> c8c253f ARM: dts: Add regulator entries to smdk5420
> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> 
> certain perripherals will now need to ensure that,
> they request VDD regulators in their drivers, and enable
> them so as to make them working.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
> Based on 'usb-next' branch of Greg's usb tree.
> 
>  drivers/usb/host/ohci-exynos.c |   47 
> 
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index 68588d8..e2e72a8 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
>   struct clk *clk;
>   struct usb_phy *phy;
>   struct usb_otg *otg;
> + struct regulator *vdd33;
> + struct regulator *vdd10;
>  };
> 
>  static void exynos_ohci_phy_enable(struct platform_device *pdev)
> @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device *pdev)
>   exynos_ohci->otg = phy->otg;
>   }
> 
> + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> + if (IS_ERR(exynos_ohci->vdd33)) {
> + err = PTR_ERR(exynos_ohci->vdd33);
> + goto fail_regulator1;
> + }
> + err = regulator_enable(exynos_ohci->vdd33);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> + goto fail_regulator1;
> + }
> +
> + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> + if (IS_ERR(exynos_ohci->vdd10)) {
> + err = PTR_ERR(exynos_ohci->vdd10);
> + goto fail_regulator2;
> + }
> + err = regulator_enable(exynos_ohci->vdd10);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> + goto fail_regulator2;
> + }
> +
>  skip_phy:
>   exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
> 
> @@ -154,6 +179,10 @@ fail_add_hcd:
>  fail_io:
>   clk_disable_unprepare(exynos_ohci->clk);
>  fail_clk:
> + regulator_disable(exynos_ohci->vdd10);
> +fail_regulator2:
> + regulator_disable(exynos_ohci->vdd33);
> +fail_regulator1:
>   usb_put_hcd(hcd);
>   return err;
>  }
> @@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct platform_device 
> *pdev)
> 
>   clk_disable_unprepare(exynos_ohci->clk);
> 
> + regulator_disable(exynos_ohci->vdd10);
> + regulator_disable(exynos_ohci->vdd33);
> +
>   usb_put_hcd(hcd);
> 
>   return 0;
> @@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
> 
>   clk_disable_unprepare(exynos_ohci->clk);
> 
> + regulator_disable(exynos_ohci->vdd10);
> + regulator_disable(exynos_ohci->vdd33);
> +
>   spin_unlock_irqrestore(&ohci->lock, flags);
> 
>   return 0;
> @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
>   struct usb_hcd *hcd = dev_get_drvdata(dev);
>   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
>   struct platform_device *pdev= to_platform_device(dev);
> + int ret;
> +
> + ret = regulator_enable(exynos_ohci->vdd33);
> + if (ret) {
> + dev_err(dev, "Failed to enable VDD33 supply\n");
> + return ret;
> + }
> + ret = regulator_enable(exynos_ohci->vdd10);
> + if (ret) {
> + dev_err(dev, "Failed to enable VDD10 supply\n");
> + return ret;
> + }
> 
>   clk_prepare_enable(exynos_ohci->clk);
> 
> --
> 1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

[Lee Jones]

On Tue, 22 Apr 2014, Doug Anderson wrote:

> From: Bill Richardson 
> 
> This just updates include/linux/mfd/cros_ec_commands.h to match the
> latest EC version (which is the One True Source for such things).  See
> 
> 
> [dianders: took today's ToT version from the Chromium OS EC; deleted
> references to cros_ec_dev and cros_ec_lpc since those aren't upstream
> yet]
> 
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v2: None
> 
>  drivers/mfd/cros_ec.c|2 +-
>  include/linux/mfd/cros_ec.h  |4 +-
>  include/linux/mfd/cros_ec_commands.h | 1128 
> +++---
>  3 files changed, 1059 insertions(+), 75 deletions(-)

Waiting for other subsystems to Ack, so for now:
  Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/7] i2c: ChromeOS EC tunnel driver

[Lee Jones]

On Tue, 22 Apr 2014, Doug Anderson wrote:

> On ARM Chromebooks we have a few devices that are accessed by both the
> AP (the main "Application Processor") and the EC (the Embedded
> Controller).  These are:
> * The battery (sbs-battery).
> * The power management unit tps65090.
> 
> On the original Samsung ARM Chromebook these devices were on an I2C
> bus that was shared between the AP and the EC and arbitrated using
> some extranal GPIOs (see i2c-arb-gpio-challenge).
> 
> The original arbitration scheme worked well enough but had some
> downsides:
> * It was nonstandard (not using standard I2C multimaster)
> * It only worked if the EC-AP communication was I2C
> * It was relatively hard to debug problems (hard to tell if i2c issues
>   were caused by the EC, the AP, or some device on the bus).
> 
> On the HP Chromebook 11 the design was changed to:
> * The AP/EC comms were still i2c, but the battery/tps65090 were no
>   longer on the bus used for AP/EC communication.  The battery was
>   exposed to the AP through a limited i2c tunnel and tps65090 was
>   exposed to the AP through a custom Linux driver.
> 
> On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
> * The AP/EC comms are now using SPI for faster speeds.
> * The EC's i2c bus is exposed to the AP through a full i2c tunnel.
> 
> The upstream "tegra124-venice2" uses the same scheme as the Samsung
> ARM Chromebook 2, though it has a different set of components on the
> other side of the bus.
> 
> This driver supports the scheme used by the Samsung ARM Chromebook 2.
> Future patches to this driver could add support for the battery tunnel
> on the HP Chromebook 11 (and perhaps could even be used to access
> tps65090 on the HP Chromebook 11 instead of using a special driver,
> but I haven't researched that enough).
> 
> Signed-off-by: Vincent Palatin 
> Signed-off-by: Simon Glass 
> Signed-off-by: Doug Anderson 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v2:
> - Update tunnel binding as per swarren
> 
>  .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt |  39 +++
>  drivers/i2c/busses/Kconfig |   9 +
>  drivers/i2c/busses/Makefile|   1 +
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c| 304 
> +
>  drivers/mfd/cros_ec.c  |   5 +

For the MFD changes:
  Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/7] mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms

[Lee Jones]

On Tue, 22 Apr 2014, Doug Anderson wrote:

> We're adding i2c tunneling to the list of things that goes over
> cros_ec.  i2c tunneling can be slooow, so increase our deadline to
> 100ms to account for that.
> 
> Signed-off-by: Doug Anderson 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v2: None
> 
>  drivers/mfd/cros_ec_spi.c | 24 
>  1 file changed, 16 insertions(+), 8 deletions(-)

Waiting for other subsystems to Ack, so for now:
  Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/7] mfd: cros_ec: spi: calculate delay between transfers correctly

[Lee Jones]

> From: David Hendricks 
> 
> To avoid spamming the EC we calculate the time between the previous
> transfer and the current transfer and force a delay if the time delta
> is too small.
> 
> However, a small miscalculation causes the delay period to be
> far too short. Most noticably this impacts commands with a long
> turnaround time such as EC firmware reads and writes.
> 
> Signed-off-by: David Hendricks 
> Signed-off-by: Doug Anderson 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v2: None
> 
>  drivers/mfd/cros_ec_spi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Waiting for other subsystems to Ack, so for now:
  Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/7] Add cros_ec changes for newer boards

[Lee Jones]

On Tue, 22 Apr 2014, Doug Anderson wrote:

> This series adds the most critical cros_ec changes for newer boards
> using cros_ec.  Specifically:
> * Fixes timing/locking issues with the previously upstreamed (but
>   never used upstream) cros_ec_spi driver.
> * Updates the cros_ec header file to the latest version which allows
>   us to use newer EC features like i2c tunneling.
> * Adds an i2c tunnel driver to allow communication to the EC's i2c
>   devices.
> 
> This _doesn't_ get the EC driver fully up to speed with what's in the
> current Chromium OS trees.  There are a whole slew of cleanup patches
> there, an addition of an LPC transport mode, and exports of functions
> to userspace.  Once these patches land and we have functionality we
> can continue to pick more cleanup patches.
> 
> Changes in v2:
> - Update tunnel binding as per swarren
> - Removed i2c20 alias for i2c tunnel
> 
> Bill Richardson (1):
>   mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
> 
> David Hendricks (1):
>   mfd: cros_ec: spi: calculate delay between transfers correctly
> 
> Doug Anderson (5):
>   mfd: cros_ec: spi: Add mutex to cros_ec_spi
>   mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
>   mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
>   i2c: ChromeOS EC tunnel driver
>   ARM: tegra: Add the EC i2c tunnel to tegra124-venice2
> 
>  .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt |   39 +
>  arch/arm/boot/dts/tegra124-venice2.dts |   26 +
>  drivers/i2c/busses/Kconfig |9 +
>  drivers/i2c/busses/Makefile|1 +
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c|  304 ++
>  drivers/mfd/cros_ec.c  |7 +-
>  drivers/mfd/cros_ec_spi.c  |   67 +-
>  include/linux/mfd/cros_ec.h|4 +-
>  include/linux/mfd/cros_ec_commands.h   | 1128 
> ++--
>  9 files changed, 1493 insertions(+), 92 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
>  create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c

Need to wait for the ARM, DT and I2C guys to review, at which point
I'll be happy to take in and supply a branch for them to pull from if
required. If there are no _true_ dependencies and the MFD changes can
be added independently without fear of build breakages, let me know
and I'll apply them separately.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd regulators

[Jingoo Han]

On Wednesday, April 23, 2014 8:06 PM, Vivek Gautam wrote:
> On Wednesday, April 23, 2014 7:58 PM, Anton Tikhomirov wrote:
> > On Wednesday, April 23, 2014 6:52 PM, Vivek Gautam wrote:
> >> On Wednesday, April 23, 2014 6:27 PM, Anton Tikhomirov wrote:
> >> > On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
> >> >>
> >> >> Facilitate getting required 3.3V and 1.0V VDD supply for
> >> >> DWC3 controller on Exynos.
> >> >>
> >> >> With patches for regulators' nodes merged in 3.15:
> >> >> c8c253f ARM: dts: Add regulator entries to smdk5420
> >> >> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> >> >>
> >> >> certain perripherals will now need to ensure that,
> >> >> they request VDD regulators in their drivers, and enable
> >> >> them so as to make them working.
> >> >>
> >> >> Signed-off-by: Vivek Gautam 
> >> >> Cc: Anton Tikhomirov 
> >> >> ---
> >> >>
> >> >> Based on 'usb-next' branch of Greg's USB tree.
> >> >> Also cleanly applies on 'next' branch of Balbi's USB tree.
> >> >>
> >> >>  drivers/usb/dwc3/dwc3-exynos.c |   51
> >> >> ++--
> >> >>  1 file changed, 49 insertions(+), 2 deletions(-)
> >> >>
> >> >> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
> >> >> exynos.c
> >> >> index 28c8ad7..c9d9102 100644
> >> >> --- a/drivers/usb/dwc3/dwc3-exynos.c
> >> >> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> >> >> @@ -27,6 +27,7 @@
> >> >>  #include 
> >> >>  #include 
> >> >>  #include 
> >> >> +#include 
> >> >>
> >> >>  struct dwc3_exynos {
> >> >>   struct platform_device  *usb2_phy;
> >> >> @@ -34,6 +35,8 @@ struct dwc3_exynos {
> >> >>   struct device   *dev;
> >> >>
> >> >>   struct clk  *clk;
> >> >> + struct regulator*vdd33;
> >> >> + struct regulator*vdd10;
> >> >>  };
> >> >>
> >> >>  static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
> >> >> @@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
> >> >> platform_device *pdev)
> >> >>
> >> >>   clk_prepare_enable(exynos->clk);
> >> >>
> >> >> + exynos->vdd33 = devm_regulator_get(dev, "vdd33");
> >> >> + if (IS_ERR(exynos->vdd33)) {
> >> >> + ret = PTR_ERR(exynos->vdd33);
> >> >> + goto err2;
> >> >
> >> > Is regulator property mandatory for dwc3-exynos? If it is not
> >> > and device tree doesn't provide it, dwc3-exynos driver probe
> >> shouldn't
> >> > fail here.
> >>
> >> These are the VDD regulators (from PMIC ldo supplies), in absence of
> >> which the controller will not be powered up.
> >> So doesn't it make sense to stop the probe when these are not supplied
> >> by device tree ?
> >
> > Agree. Just curious, is there special reason for this change except making
> > things right?
> 
> Yea, actually after the patch (which got merged in 3.15 rc1)
> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> 
> the USB stops working, and that's because the regulators related to
> usb are not turned on by default (ldo12 and ldo15 to be specific).
> So we need to enable those regulators, which ofcourse the driver
> should be doing, if i am not wrong.
> Similar is the reason for EHCI, and OHCI exynos patches in this series.

Oh, I see. Thank you for your explanation.

> 
> I shall be sending the dt patch for this soon.

OK, I will wait for your patch.

Best regards,
Jingoo Han

> 
> 
> --
> Best Regards
> Vivek Gautam
> Samsung R&D Institute, Bangalore
> India


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 resend] clk: s2mps11: Add support for S2MPS14 clocks

[Krzysztof Kozlowski]

Hi,

Mike, can you apply this patch? Actually you acked it already [1] but I
forgot to put it in the commit message.

The patch wasn't applied in that time because of multiple concurrent
changes in sec-core drivers.

[1]http://thread.gmane.org/gmane.linux.kernel.samsung-soc/28039/focus=310279

Best regards,
Krzysztof



On pon, 2014-04-14 at 09:55 +0200, Krzysztof Kozlowski wrote:
> This patch adds support for S2MPS14 PMIC clocks (BT and AP) to the
> s2mps11 clock driver.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Cc: Kyungmin Park 
> Reviewed-by: Yadwinder Singh Brar 
> Reviewed-by: Tomasz Figa 
> ---
>  drivers/clk/Kconfig   |  8 +++
>  drivers/clk/clk-s2mps11.c | 61 
> +++
>  2 files changed, 50 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 6f56d3a4f010..8f9ce8ba036d 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -65,12 +65,12 @@ config COMMON_CLK_SI570
> clock generators.
>  
>  config COMMON_CLK_S2MPS11
> - tristate "Clock driver for S2MPS11/S5M8767 MFD"
> + tristate "Clock driver for S2MPS1X/S5M8767 MFD"
>   depends on MFD_SEC_CORE
>   ---help---
> -   This driver supports S2MPS11/S5M8767 crystal oscillator clock. These
> -   multi-function devices have 3 fixed-rate oscillators, clocked at
> -   32KHz each.
> +   This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
> +   clock. These multi-function devices have two (S2MPS14) or three
> +   (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
>  
>  config CLK_TWL6040
>   tristate "External McPDM functional clock from twl6040"
> diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
> index f2f62a1bf61a..b78eafeab038 100644
> --- a/drivers/clk/clk-s2mps11.c
> +++ b/drivers/clk/clk-s2mps11.c
> @@ -1,7 +1,7 @@
>  /*
>   * clk-s2mps11.c - Clock driver for S2MPS11.
>   *
> - * Copyright (C) 2013 Samsung Electornics
> + * Copyright (C) 2013,2014 Samsung Electornics
>   *
>   * This program is free software; you can redistribute  it and/or modify it
>   * under  the terms of  the GNU General  Public License as published by the
> @@ -13,10 +13,6 @@
>   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>   * GNU General Public License for more details.
>   *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> - *
>   */
>  
>  #include 
> @@ -27,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -125,7 +122,21 @@ static struct clk_init_data 
> s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
>   },
>  };
>  
> -static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev)
> +static struct clk_init_data s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
> + [S2MPS11_CLK_AP] = {
> + .name = "s2mps14_ap",
> + .ops = &s2mps11_clk_ops,
> + .flags = CLK_IS_ROOT,
> + },
> + [S2MPS11_CLK_BT] = {
> + .name = "s2mps14_bt",
> + .ops = &s2mps11_clk_ops,
> + .flags = CLK_IS_ROOT,
> + },
> +};
> +
> +static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
> + struct clk_init_data *clks_init)
>  {
>   struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
>   struct device_node *clk_np;
> @@ -145,9 +156,12 @@ static struct device_node *s2mps11_clk_parse_dt(struct 
> platform_device *pdev)
>   if (!clk_table)
>   return ERR_PTR(-ENOMEM);
>  
> - for (i = 0; i < S2MPS11_CLKS_NUM; i++)
> + for (i = 0; i < S2MPS11_CLKS_NUM; i++) {
> + if (!clks_init[i].name)
> + continue; /* Skip clocks not present in some devices */
>   of_property_read_string_index(clk_np, "clock-output-names", i,
> - &s2mps11_clks_init[i].name);
> + &clks_init[i].name);
> + }
>  
>   return clk_np;
>  }
> @@ -158,6 +172,7 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
>   struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
>   struct device_node *clk_np = NULL;
>   unsigned int s2mps11_reg;
> + struct clk_init_data *clks_init;
>   int i, ret = 0;
>   u32 val;
>  
> @@ -168,25 +183,33 @@ static int s2mps11_clk_probe(struct platform_device 
> *pdev)
>  
>   s2mps11_clk = s2mps11_clks;
>  
> - clk_np = s2mps11_clk_parse_dt(pdev);
> - if (IS_ERR(clk_np))
> - return PTR_ERR(clk_np);
> -
>   switch(platform_get_device_id(pdev)->driver_data) {
>   case S2MPS11X:
>   s2mps11_reg = S2MPS11_REG_RTC_CTRL;
> + clks_init = s2mps11_clks_init;
> + break;
> + case S2MPS14X:
> + s2mps11_reg = S2MPS14_REG_RTC

Re: [PATCH v3 4/5] regulator: tps65090: Allow setting the overcurrent wait time

[Lee Jones]

> The tps65090 regulator allows you to specify how long you want it to
> wait before detecting an overcurrent condition.  Allow specifying that
> through the device tree (or through platform data).
> 
> Signed-off-by: Doug Anderson 
> Signed-off-by: Simon Glass 
> Signed-off-by: Michael Spang 
> Signed-off-by: Sean Paul 
> ---
> Changes in v3:
> - Fixed kernel-doc notation for return
> 
> Changes in v2:
> - Separated the overcurrent and retries changes into two patches.
> - Now set overcurrent at probe time since it doesn't change.
> 
>  .../devicetree/bindings/regulator/tps65090.txt |  4 ++
>  drivers/regulator/tps65090-regulator.c | 56 
> ++
>  include/linux/mfd/tps65090.h   |  5 ++
>  3 files changed, 65 insertions(+)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] mfd: tps65090: Stop caching most registers

[Lee Jones]

> Nearly all of the registers in tps65090 combine control bits and
> status bits.  Turn off caching of all registers except the select few
> that can be cached.
> 
> In order to avoid adding more duplicate #defines, we also move some
> register offset definitions to the mfd driver (and resolve
> inconsistent names).
> 
> Signed-off-by: Doug Anderson 
> ---
> Changes in v3: None
> Changes in v2:
> - Leave cache on for the registers that can be cached.
> - Move register offsets to mfd header file.
> 
>  drivers/mfd/tps65090.c   | 27 ++-
>  drivers/power/tps65090-charger.c | 11 ---
>  include/linux/mfd/tps65090.h | 14 ++
>  3 files changed, 28 insertions(+), 24 deletions(-)

Applied now, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/5] mfd: tps65090: Don't tell child devices we have an IRQ if we don't

[Lee Jones]

> If we weren't given an interrupt we shouldn't tell child devices (like
> the tps65090 charger) that they have an interrupt.  This is needed so
> that we can support polling mode in the tps65090 charger driver.
> 
> See also (charger: tps65090: Allow charger module to be used when no
> irq).
> 
> Signed-off-by: Doug Anderson 
> Acked-by: Lee Jones 
> ---
> Changes in v3: None
> Changes in v2:
> - Split noirq (polling mode) changes into MFD and charger
> 
>  drivers/mfd/tps65090.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Laurent Pinchart]

Hi Andrzej,

On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> > This patch adds DT bindings for s6e3fa0 panel.
> > The bindings describes panel resources, display timings and cpu timings.
> > 
> > Changelog v2:
> > - Adds unit address (commented by Sachin Kamat)
> > Changelog v3:
> > - Removes optional delay, size properties (commented by Laurent Pinchart)
> > - Adds OLED detection, TE gpio properties
> > Changelog v4:
> > - Moves CPU timings relevant properties from FIMD DT
> > 
> >   (commeted by Laurent Pinchart, Andrzej Hajda)
> > 
> > Signed-off-by: YoungJun Cho 
> > Acked-by: Inki Dae 
> > Acked-by: Kyungmin Park 
> > ---
> > 
> >  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 +++
> > 1 file changed, 63 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt> 
> > diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> > b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
> > mode 100644
> > index 000..9eeb38b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> > @@ -0,0 +1,63 @@
> > +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> > +
> > +Required properties:
> > +  - compatible: "samsung,s6e3fa0"
> > +  - reg: the virtual channel number of a DSI peripheral
> > +  - vdd3-supply: core voltage supply
> > +  - vci-supply: voltage supply for analog circuits
> > +  - reset-gpio: a GPIO spec for the reset pin
> > +  - det-gpio: a GPIO spec for the OLED detection pin
> > +  - te-gpio: a GPIO spec for the TE pin
> > +  - display-timings: timings for the connected panel as described by [1]
> 
> Which properties of display-timings are relevant for CPU mode?
> I guess width and height. Anything more?
> 
> > +  - cpu-timings: CPU interface timings for the connected panel, and it
> > contains
> > +following optional properties.
> > +  - cs-setup: clock cycles for the active period of address
> > signal
> > +enable until chip select is enable in CPU interface
> > +  - wr-setup: clock cycles for the active period of CS signal
> > enable
> > +until write signal is enable in CPU interface
> > +  - wr-act: clock cycles for the active period of CS enable in
> > CPU
> > +interface

What about calling this property wr-active ? I had called this wr-cycle in a 
previous implementation, that could be an option as well.

> > +  - wr-hold: clock cycles for the active period of CS disable
> > until
> > +write signal is disable in CPU interface
> 
> cpu-timings name does not sound to be related to display.
> I wonder if it would not be better to merge cpu-timings into
> display-timings but this will require more discussion I guess.

The panel has a memory-like interface with chip select, read/write and access 
strobe, address (1 bit) and data signals. The interface is defined in the MIPI 
DBI specification (a quick search turned up 
http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be 
direct PDF downloads available), even if some panels implement a similar 
interface that predates MIPI DBI (with names such as i80 or SYS-80 probably 
due to the similarities with the 8051 external bus).

The cpu-timings properties describe the read and write access timings for 
those signals, unrelated to the display video timings. I thus believe that 
they should be separate from the display timings. We will probably need to add 
properties for the read signal as well, but that can be done later.

> If you want to stay with separate node please consider to make it
> optional as whole node or make some properties required. Making node
> required with all sub-properties optional is weird.
> By the way I hope all timings properties are generic for CPU mode,
> if not they should be prefixed by vendor or model.

The timings description should be pretty generic I believe, especially given 
that the interface is standardized by the MIPI alliance. Could you have a 
quick look at the spec and share your opinion ?

> > +
> > +Optional properties:
> > +
> > +The device node can contain one 'port' child node with one child
> > +'endpoint' node, according to the bindings defined in [2]. This
> > +node should describe panel's video bus.
> > +
> > +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> > +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> > +
> > +Example:
> > +
> > +   panel@0 {
> > +   compatible = "samsung,s6e3fa0";
> > +   reg = <0>;
> > +   vdd3-supply = <&vcclcd_reg>;
> > +   vci-supply = <&vlcd_reg>;
> > +   reset-gpio = <&gpy7 4 0>;
> > +   det-gpio = <&gpg0 6 0>;
> > +   te-gpio = <&gpd1 7 0>;
> > +
> > +   display-timings {
> > +   timing0: timing-0 {
> > +   clock-frequency 

Re: [PATCH] ASoC: SAMSUNG: Don't clear clock setting during i2s_startup

[Mark Brown]

On Wed, Apr 23, 2014 at 01:34:24PM +0530, Tushar Behera wrote:
> In exiting kernel, if DAIFMT flags are set in dai_link and I2S is
> set to run in master mode, the I2S clocks are not getting configured
> resulting in no output.

Applied, thanks.


signature.asc
Description: Digital signature