Re: [PATCH v11 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420

[Amit Kucheria]

Hi Thomas,

On Mon, Oct 20, 2014 at 5:11 PM, Thomas Abraham  wrote:
> The new CPU clock type allows the use of generic CPUfreq drivers. So for
> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
> which did not have CPUfreq driver support, enable the use of generic
> CPUfreq driver.
>
> Suggested-by: Tomasz Figa 
> Cc: Kukjin Kim 
> Signed-off-by: Thomas Abraham 
> Reviewed-by: Tomasz Figa 
> Tested-by: Javier Martinez Canillas 
> Tested-by: Chander Kashyap 
> ---
>  arch/arm/mach-exynos/exynos.c |   24 +++-
>  1 files changed, 23 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index 6b283eb..a1be294 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -282,6 +282,28 @@ static void __init exynos_init_irq(void)
> exynos_map_pmu();
>  }
>
> +static const struct of_device_id exynos_cpufreq_matches[] = {
> +   { .compatible = "samsung,exynos5420", .data = "arm-bL-cpufreq-dt" },

While you're at it, can you add this to so we don't have to patch
kernels for the Chromebook2 and Odroid-XU3?

  { .compatible = "samsung,exynos5422", .data = "arm-bL-cpufreq-dt" },
  { .compatible = "samsung,exynos5800", .data = "arm-bL-cpufreq-dt" },


> +   { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
> +   { .compatible = "samsung,exynos4210", .data = "cpufreq-dt" },
> +   { .compatible = "samsung,exynos5440", .data = "exynos5440-cpufreq" },
> +   { /* sentinel */ }
--
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: [PATCHv2 0/2] ARM: dts: Fix the number of DMA channels for Exynos3250/4

[Chanwoo Choi]

Dear Kukjin,

Please ignore this patchset because this patchset are wrong.

Best Regards,
Chanwoo Choi

On 11/12/2014 11:50 AM, Chanwoo Choi wrote:
> This patch fix minor issuse to correct the number of DMA channels for
> Exynos3250 and Exynos4 series. The PL330 DMA of Exynos3250/Exynos4 support
> 16 channels simultaneously but, PL330 DMA driver don't use 'dma-channels'
> property directly. This patchset fix the correct information
> of Exynos3250/Exynos4's PL330 DMA simply.
> 
> Changes from v1:
> - Fix the nubmer for DMA channesl for Exynos4415
> 
> Chanwoo Choi (2):
>   ARM: dts: Fix the number of DMA channels for Exynos3250
>   ARM: dts: Fix the number of DMA channels for Exynos4
> 
>  arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
>  arch/arm/boot/dts/exynos4.dtsi| 4 ++--
>  arch/arm/boot/dts/exynos4415.dtsi | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 

--
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/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

[Jingoo Han]

On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
> 
> DP PHY now require pmu-system-controller to handle PMU register
> to control PHY's power isolation. Adding the same to dp-phy
> node.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
> Changes from V1:
>  - none.
> 
>  arch/arm/boot/dts/exynos5250.dtsi |2 +-
>  arch/arm/boot/dts/exynos5420.dtsi |4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 012b021..69f5eb0 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -732,7 +732,7 @@
> 
>   dp_phy: video-phy@10040720 {
>   compatible = "samsung,exynos5250-dp-video-phy";
> - reg = <0x10040720 4>;
> + samsung,pmu-syscon = <&pmu_system_controller>;
>   #phy-cells = <0>;
>   };
> 
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 8617a03..1353a09 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -503,8 +503,8 @@
>   };
> 
>   dp_phy: video-phy@10040728 {
> - compatible = "samsung,exynos5250-dp-video-phy";
> - reg = <0x10040728 4>;
> + compatible = "samsung,exynos5420-dp-video-phy";
> + samsung,pmu-syscon = <&pmu_system_controller>;
>   #phy-cells = <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

Re: [PATCH v2 1/2] drm/exynos: dp: Remove support for unused dptx-phy

[Jingoo Han]

On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
> 
> Now that we have moved to generic phy based bindings,
> we don't need to have any code related to older dptx-phy.
> Nobody is using this dptx-phy anymore, so removing the
> same.

Right, older dptx-phy was replaced long time ago.
However, it was not removed for DT compatibility.
I think that now these old DT properties can be removed.

I added some comments below.

> 
> Signed-off-by: Vivek Gautam 
> Cc: Inki Dae 
> Cc: Jingoo Han 
> ---
> 
> Changes from V1:
>  - Reworked error handling in exynos_dp_dt_parse_phydata() as commented
>by Inki.
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   67 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 -
>  2 files changed, 17 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index cd50ece..206163b 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1052,28 +1052,14 @@ static int exynos_dp_create_connector(struct 
> exynos_drm_display *display,
> 
>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>  {
> - if (dp->phy) {
> + if (dp->phy)
>   phy_power_on(dp->phy);
> - } else if (dp->phy_addr) {
> - u32 reg;
> -
> - reg = __raw_readl(dp->phy_addr);
> - reg |= dp->enable_mask;
> - __raw_writel(reg, dp->phy_addr);
> - }
>  }
> 
>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>  {
> - if (dp->phy) {
> + if (dp->phy)
>   phy_power_off(dp->phy);
> - } else if (dp->phy_addr) {
> - u32 reg;
> -
> - reg = __raw_readl(dp->phy_addr);
> - reg &= ~(dp->enable_mask);
> - __raw_writel(reg, dp->phy_addr);
> - }
>  }
> 
>  static void exynos_dp_poweron(struct exynos_drm_display *display)
> @@ -1212,40 +1198,13 @@ static struct video_info 
> *exynos_dp_dt_parse_pdata(struct device *dev)
> 
>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>  {
> - struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> - u32 phy_base;
> - int ret = 0;
> -
> - dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> - if (!dp_phy_node) {
> - dp->phy = devm_phy_get(dp->dev, "dp");
> - return PTR_ERR_OR_ZERO(dp->phy);
> - }
> -
> - if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
> - dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> - ret = -EINVAL;
> - goto err;
> - }
> -
> - if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> - &dp->enable_mask)) {
> - dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> - ret = -EINVAL;
> - goto err;
> - }
> -
> - dp->phy_addr = ioremap(phy_base, SZ_4);
> - if (!dp->phy_addr) {
> - dev_err(dp->dev, "failed to ioremap dp-phy\n");
> - ret = -ENOMEM;
> - goto err;
> + dp->phy = devm_phy_get(dp->dev, "dp");
> + if (IS_ERR(dp->phy)) {
> + dev_err(dp->dev, "no DP phy configured\n");
> + return PTR_ERR(dp->phy);
>   }
> 
> -err:
> - of_node_put(dp_phy_node);
> -
> - return ret;
> + return 0;
>  }
> 
>  static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
> @@ -1278,8 +1237,16 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>   return PTR_ERR(dp->video_info);
> 
>   ret = exynos_dp_dt_parse_phydata(dp);

In your patch, exynos_dp_dt_parse_phydata() calls only devm_phy_get().
Then, how about calling devm_phy_get() directly and removing
exynos_dp_dt_parse_phydata()? It looks simpler.

Best regards,
Jingoo Han

> - if (ret)
> - return ret;
> + if (ret) {
> + /*
> +  * phy itself is not enabled, so we can move forward
> +  * assigning NULL to phy pointer.
> +  */
> + if (ret == -ENOSYS || ret == -ENODEV)
> + dp->phy = NULL;
> + else
> + return ret;
> + }
> 
>   if (!dp->panel) {
>   ret = exynos_dp_dt_parse_panel(dp);
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
> b/drivers/gpu/drm/exynos/exynos_dp_core.h
> index a1aee69..6426201 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
> @@ -153,8 +153,6 @@ struct exynos_dp_device {
>   struct clk  *clock;
>   unsigned intirq;
>   void __iomem*reg_base;
> - void __iomem*phy_addr;
> - unsigned intenable_mask;
> 
>   struct video_info   *video_info;
>   struct link_train   link_train;
> --
> 1.7.10.4

--
To unsubscribe from 

Re: [PATCH] mmc: dw_mmc: exynos: Add support for exynos7

[Jaehoon Chung]

Hi, Alim.

I have also tested this patch with my board.
It's working fine. Looks good to me.

Dear, Ulf.

Could you merge this patch at your repository?

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

On 11/11/2014 11:14 PM, Alim Akhtar wrote:
> Hi Jaehoon,
> As 64bit dependent patch for dw_mmc is already merged.
> Do you have any comments on this patch?
> 
> This patch still apply cleanly on ulf's next and v3.18-rc4 kernel.
> 
> Regards,
> Alim
> 
> On Tue, Oct 21, 2014 at 1:50 PM, Vivek Gautam  
> wrote:
>> On Tue, Oct 21, 2014 at 1:47 PM, Vivek Gautam  
>> wrote:
>>
>> Corrected Tomasz's mail id, as the earlier samsung one is not valid now.
>> Also giving a Tested-by
>>
>>> On Mon, Sep 1, 2014 at 11:14 AM, Abhilash Kesavan
>>>  wrote:
 Hi Jaehoon,

 +Prabu Thangamuthu

 On Fri, Aug 29, 2014 at 4:14 PM, Jaehoon Chung  
 wrote:
> Hi, Abhilash.
>
> On 08/28/2014 10:18 PM, Yuvaraj Kumar C D wrote:
>> From: Abhilash Kesavan 
>>
>> The Exynos7 has a DWMMC controller (v2.70a) which is different from
>> prior versions. This patch adds new compatible strings for exynos7.
>> This patch also fixes the CLKSEL register offset on exynos7.
>
> If support the 64bit, dw-mmc.c need to modify.(according to v2.70, some 
> offset is changed for 64-bit address)
> But i didn't see any patches at mailing.
> Do you have the plan which send patch of dw-mmc.c?

 We are using a rebased version of
 http://www.spinics.net/lists/linux-mmc/msg21742.html to handle the
 dwmmc side changes. We should have mentioned this dependency as the
 patch is required for proper functioning of dwmmc on Exynos7.
 Stress tests are on-going with that patch and once it looks good, we
 will post our results so that the original patch may be taken forward.

 Regards,
 Abhilash
>
> Best Regards,
> Jaehoon Chung
>>
>> Signed-off-by: Abhilash Kesavan 
>> Signed-off-by: Yuvaraj Kumar C D 
>> ---
>>>
>>> I have tested this patch following set of patches:
>>>
>>> On Exynos7 support side:
>>> 1) dts, kbuild: Implement support for dtb vendor subdirs" patchset
>>> http://comments.gmane.org/gmane.linux.kbuild.devel/12131
>>> 2) arch: arm64: Enable support for Samsung Exynos7 SoC  (V5)
>>> http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
>>> 3) Serial clean-up patches for Exynos7
>>> http://www.spinics.net/lists/arm-kernel/msg367348.html
>>> http://www.spinics.net/lists/arm-kernel/msg367349.html
>>> 4) Add initial support for pinctrl on Exynos7  (V5)
>>> http://www.spinics.net/lists/linux-samsung-soc/msg37708.html
>>>
>>> On MMC side:
>>> 1) mmc: dw_mmc: Add IDMAC 64-bit address mode support  (V7)
>>> https://lkml.org/lkml/2014/10/20/58
>>> 2) mmc: dw_mmc: Reset DMA before enabling IDMAC  (V2)
>>> http://www.gossamer-threads.com/lists/linux/kernel/2028229
>>>
>>> eMMC and SD are running fine on Exynos7.
>>
>> Tested-by: Vivek Gautam 
>>
>>>
>>> If this change looks good, then we can take it in.
>>>
>>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |4 +
>>  drivers/mmc/host/dw_mmc-exynos.c   |   91 
>> +---
>>  2 files changed, 82 insertions(+), 13 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
>> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> index 6cd3525..ee4fc05 100644
>> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> @@ -18,6 +18,10 @@ Required Properties:
>> specific extensions.
>>   - "samsung,exynos5420-dw-mshc": for controllers with Samsung 
>> Exynos5420
>> specific extensions.
>> + - "samsung,exynos7-dw-mshc": for controllers with Samsung Exynos7
>> +   specific extensions.
>> + - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung 
>> Exynos7
>> +   specific extensions having an SMU.
>>
>>  * samsung,dw-mshc-ciu-div: Specifies the divider value for the card 
>> interface
>>unit (ciu) clock. This property is applicable only for Exynos5 SoC's 
>> and
>> diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
>> b/drivers/mmc/host/dw_mmc-exynos.c
>> index 0fbc53a..509365c 100644
>> --- a/drivers/mmc/host/dw_mmc-exynos.c
>> +++ b/drivers/mmc/host/dw_mmc-exynos.c
>> @@ -25,6 +25,7 @@
>>  #define NUM_PINS(x)  (x + 2)
>>
>>  #define SDMMC_CLKSEL 0x09C
>> +#define SDMMC_CLKSEL64   0x0A8
>>  #define SDMMC_CLKSEL_CCLK_SAMPLE(x)  (((x) & 7) << 0)
>>  #define SDMMC_CLKSEL_CCLK_DRIVE(x)   (((x) & 7) << 16)
>>  #define SDMMC_CLKSEL_CCLK_DIVIDER(x) (((x) & 7) << 24)
>> @@ -65,6 +66,8 @@ enum dw_mci_exynos_type {
>>   DW_MCI_TYPE_EXYNOS5250,
>>   DW_MCI_TYPE_EXYNOS5420,
>

[PATCHv2 0/2] ARM: dts: Fix the number of DMA channels for Exynos3250/4

[Chanwoo Choi]

This patch fix minor issuse to correct the number of DMA channels for
Exynos3250 and Exynos4 series. The PL330 DMA of Exynos3250/Exynos4 support
16 channels simultaneously but, PL330 DMA driver don't use 'dma-channels'
property directly. This patchset fix the correct information
of Exynos3250/Exynos4's PL330 DMA simply.

Changes from v1:
- Fix the nubmer for DMA channesl for Exynos4415

Chanwoo Choi (2):
  ARM: dts: Fix the number of DMA channels for Exynos3250
  ARM: dts: Fix the number of DMA channels for Exynos4

 arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
 arch/arm/boot/dts/exynos4.dtsi| 4 ++--
 arch/arm/boot/dts/exynos4415.dtsi | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

-- 
1.8.5.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

[PATCHv2 1/2] ARM: dts: Fix the number of DMA channels for Exynos3250

[Chanwoo Choi]

This patch fix the numer for DMA channels for Exynos3250 because DMA controller
of Exynos3250 can support 16 channels simultaneously.

Signed-off-by: Chanwoo Choi 
---
 arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 242ddda..5c14e3e 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -292,7 +292,7 @@
clocks = <&cmu CLK_PDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16>;
#dma-requests = <32>;
};
 
@@ -303,7 +303,7 @@
clocks = <&cmu CLK_PDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16;
#dma-requests = <32>;
};
};
-- 
1.8.5.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

[PATCHv2 2/2] ARM: dts: Fix the number of DMA channels for Exynos4

[Chanwoo Choi]

This patch fix the numer for DMA channels for Exynos4210/Exynos4212/Exynos4412
/Exynos4415 because DMA controller of Exynos4 series can support 16 channels
simultaneously.

Signed-off-by: Chanwoo Choi 
---
 arch/arm/boot/dts/exynos4.dtsi| 4 ++--
 arch/arm/boot/dts/exynos4415.dtsi | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e0278ec..3b2c3dd 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -606,7 +606,7 @@
clocks = <&clock CLK_PDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16>;
#dma-requests = <32>;
};
 
@@ -617,7 +617,7 @@
clocks = <&clock CLK_PDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16>;
#dma-requests = <32>;
};
 
diff --git a/arch/arm/boot/dts/exynos4415.dtsi 
b/arch/arm/boot/dts/exynos4415.dtsi
index c1c9b37..a097332 100644
--- a/arch/arm/boot/dts/exynos4415.dtsi
+++ b/arch/arm/boot/dts/exynos4415.dtsi
@@ -348,7 +348,7 @@
clocks = <&cmu CLK_PDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16>;
#dma-requests = <32>;
};
 
@@ -359,7 +359,7 @@
clocks = <&cmu CLK_PDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16>;
#dma-requests = <32>;
};
};
-- 
1.8.5.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 2/2] ARM: dts: Fix the number of DMA channels for Exynos4

[Chanwoo Choi]

This patch fix the numer for DMA channels for Exynos4210/Exynos4212/Exynos4412
because DMA controller of Exynos4 series can support 16 channels simultaneously.

Signed-off-by: Chanwoo Choi 
---
 arch/arm/boot/dts/exynos4.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e0278ec..3b2c3dd 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -606,7 +606,7 @@
clocks = <&clock CLK_PDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16>;
#dma-requests = <32>;
};
 
@@ -617,7 +617,7 @@
clocks = <&clock CLK_PDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16>;
#dma-requests = <32>;
};
 
-- 
1.8.5.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: Fix the number of DMA channels for Exynos3250

[Chanwoo Choi]

This patch fix the numer for DMA channels for Exynos3250 because DMA controller
of Exynos3250 can support 16 channels simultaneously.

Signed-off-by: Chanwoo Choi 
---
 arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 242ddda..5c14e3e 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -292,7 +292,7 @@
clocks = <&cmu CLK_PDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16>;
#dma-requests = <32>;
};
 
@@ -303,7 +303,7 @@
clocks = <&cmu CLK_PDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
-   #dma-channels = <8>;
+   #dma-channels = <16;
#dma-requests = <32>;
};
};
-- 
1.8.5.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 0/2] ARM: dts: Fix the number of DMA channels for Exynos3250/4

[Chanwoo Choi]

This patch fix minor issuse to correct the number of DMA channels for
Exynos3250 and Exynos4 series. The PL330 DMA of Exynos3250/Exynos4 support
16 channels simultaneously but, PL330 DMA driver don't use 'dma-channels'
property directly. This patchset fix the correct information
of Exynos3250/Exynos4's PL330 DMA simply.

Chanwoo Choi (2):
  ARM: dts: Fix the number of DMA channels for Exynos3250
  ARM: dts: Fix the number of DMA channels for Exynos4

 arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
 arch/arm/boot/dts/exynos4.dtsi| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
1.8.5.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: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on arndale platform

[Ben Hutchings]

On Tue, 2014-11-04 at 20:09 +, Charles Keepax wrote:
> On Tue, Nov 04, 2014 at 11:23:06AM +0100, Stam, Michel [FINT] wrote:
> > Hello Riku,
> > 
> > >Fixing a bug (ethtool support) must not cause breakage elsewhere (in
> > this case on arndale). This is now a regression of functionality from
> > 3.17.
> > >
> > >I think it would better to revert the change now and with less hurry
> > introduce a ethtool fix that doesn't break arndale.
> > 
> > I don't fully agree here; 
> > I would like to point out that this commit is a revert itself. Fixing
> > the armdale will then cause breakage in other implementations, such as
> > ours. Blankly reverting breaks other peoples' implementations.
> > 
> > The PHY reset is the thing that breaks ethtool support, so any fix that
> > appeases all would have to take existing PHY state into account. 
[...]
> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -299,6 +299,7 @@ static int ax88772_reset(struct usbnet *dev)
>  {
> struct asix_data *data = (struct asix_data *)&dev->data;
> int ret, embd_phy;
> +   int reg;
> u16 rx_ctl;
> 
> ret = asix_write_gpio(dev,
> @@ -359,8 +360,10 @@ static int ax88772_reset(struct usbnet *dev)
> msleep(150);
> 
> asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR, BMCR_RESET);
> -   asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
> -   ADVERTISE_ALL | ADVERTISE_CSMA);
> +   reg = asix_mdio_read(dev->net, dev->mii.phy_id, MII_ADVERTISE);
> +   if (!reg)
> +   reg = ADVERTISE_ALL | ADVERTISE_CSMA;
> +   asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE, reg);
[...]

Why is there no sleep after setting the RESET bit?  Doesn't that make
the following register writes unreliable?

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner


signature.asc
Description: This is a digitally signed message part

Re: Samsung/S3C6410/Mini6410: how to handle NAND's "clock off"

[Uwe Kleine-König]

On Tue, Nov 11, 2014 at 07:10:33PM +0100, Juergen Borleis wrote:
> Hi,
> 
> the S3C2410 NAND driver [1] can still be used for NANDs attached to an S3C6410
> SoC. But this driver has a "nice" feature called "clock off" to save some
> power while not in use. I tried it here on my Mini6410 platform and it freezes
> the system.
> 
> The clock tree is somehow:
> 
> [...]
>   hclk  44   13300  0 0
>  hclk_mfc   00   13300  0 0
>  hclk_mem0  22   13300  0 0
> mem0_srom   00   13300  0 0
> mem0_nfcon  11   13300  0 0
> mem0_onenand0   00   13300  0 0
> mem0_onenand1   00   13300  0 0
> mem0_cfcon  00   13300  0 0
> [...]
> 
> On the Mini6410 the "mem0_nfcon" clock is the only single user of the
> "hclk_mem0". And this clock is required to keep the access to the external
> network device enabled. When the NAND driver disables its clock "mem0_nfcon",
> the "hclk_mem0" gets also disabled because there is no consumer anymore. The
> next time the network driver tries to access its device, the SoC freezes.
Sounds like the network driver should hold a reference to hclk_mem0. I
assume the system uses a device tree? This is the dm9000 driver? It
doesn't seem to use clk stuff, but it should be possible to add an
optional clk entry.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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

Samsung/S3C6410/Mini6410: how to handle NAND's "clock off"

[Juergen Borleis]

Hi,

the S3C2410 NAND driver [1] can still be used for NANDs attached to an S3C6410
SoC. But this driver has a "nice" feature called "clock off" to save some
power while not in use. I tried it here on my Mini6410 platform and it freezes
the system.

The clock tree is somehow:

[...]
  hclk  44   13300  0 0
 hclk_mfc   00   13300  0 0
 hclk_mem0  22   13300  0 0
mem0_srom   00   13300  0 0
mem0_nfcon  11   13300  0 0
mem0_onenand0   00   13300  0 0
mem0_onenand1   00   13300  0 0
mem0_cfcon  00   13300  0 0
[...]

On the Mini6410 the "mem0_nfcon" clock is the only single user of the
"hclk_mem0". And this clock is required to keep the access to the external
network device enabled. When the NAND driver disables its clock "mem0_nfcon",
the "hclk_mem0" gets also disabled because there is no consumer anymore. The
next time the network driver tries to access its device, the SoC freezes.

How to prevent this? Can we keep the "hclk_mem0" enabled without an active
consumer? Or do we need a dummy consumer? Or do we need to request for
"hclk_mem0" when at least one external device is attached? Or should we remove
the "clock stop" feature for at least the S3C6410 SoC?

With the patch below I was able to reproduce the behavior:

Author: Juergen Borleis 
Date:   Mon Nov 10 23:35:06 2014 +0100

ARM/S3C6410/NAND: add clock alias to keep an old driver alive

This change enables the existing S3c2410.c driver for the S3C6410.

But keep in mind to disable the CONFIG_MTD_NAND_S3C2410_CLKSTOP when using
this driver!

Why? The access to external devices depends on a running "hclk_mem0" clock.
As the NAND controller was the only single user of it, it disables it, when
it disables its owm clock to save power. This locks the system. m(

Signed-off-by: Juergen Borleis 

diff --git a/drivers/clk/samsung/clk-s3c64xx.c 
b/drivers/clk/samsung/clk-s3c64xx.c
index 0f590e5..f7d2d57 100644
--- a/drivers/clk/samsung/clk-s3c64xx.c
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -404,6 +404,7 @@ static struct samsung_clock_alias s3c64xx_clock_aliases[] = 
{
ALIAS(PCLK_IIS0, "samsung-i2s.0", "iis"),
ALIAS(PCLK_AC97, "samsung-ac97", "ac97"),
ALIAS(PCLK_TSADC, "s3c64xx-adc", "adc"),
+   ALIAS(MEM0_NFCON, NULL, "nand"),
ALIAS(PCLK_KEYPAD, "samsung-keypad", "keypad"),
ALIAS(PCLK_PCM1, "samsung-pcm.1", "pcm"),
ALIAS(PCLK_PCM0, "samsung-pcm.0", "pcm"),

jbe

[1] drivers/mtd/nand/s3c2410.c
--
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 PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

Hi Inki,

On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae  wrote:
>
> Hi,
>
> Fortunately, I could get the user manual for Exynos7420. Below are my
> comments.
>
> Thanks,
> Inki Dae
>
> On 2014년 10월 23일 01:34, Ajay kumar wrote:
>> On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae  wrote:
>>>
>>> Thanks for contribution.
>>>
>>> It seems reasonable that you separate device drivers into FIMD and DECON
>>> because many registers of them have many different offsets and fields.
>>> However, there may be a good solution that we can combine common sets of
>>> these drivers later.
>> Yes, this is the main reason behind sending this as RFC patch.
>> I want to know what's the best way to do this.
>> FIMD, 5433 DECON and Exynos7 DECON - all are different.
>> Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer).
>> So, even I am not sure how the driver layouts should be!
>
> Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my
> understanding, Exynos7 doesn't mean one real SoC.
We shall use Exynos7 as per the discussion.

>>
>>> Below are my comments.
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>> On 2014년 10월 10일 21:48, Ajay Kumar wrote:
 This series is based on exynos-drm-next branch of Inki Dae's tree at:
 git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

 DECON(Display and Enhancement Controller) is the new IP
 in exynos7 SOC for generating video signals using pixel data.
>>>
>>> DECON was used since Exynos5430. And is Exynos5433 different from
>>> Exynos7? If so, could I get the Exynos7 user manual (TRM) for review?
>> Yes, Exynos5433 DECON is very much different than Exynos7 DECON.
>
> Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead.
Again, we shall use Exynos7.

>> I will see how manual can be arranged.
>>

 DECON driver can be used to drive 2 different interfaces on Exynos7:
 DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)

 The existing FIMD driver code was used as a template to create
 DECON driver. Only DECON-INT is supported as of now, and
 DECON-EXT support will be added later.

 Signed-off-by: Akshu Agrawal 
 Signed-off-by: Ajay Kumar 
 ---
  .../devicetree/bindings/video/exynos-decon.txt |   68 ++
  drivers/gpu/drm/exynos/Kconfig |   11 +-
  drivers/gpu/drm/exynos/Makefile|1 +
  drivers/gpu/drm/exynos/exynos_drm_decon.c  | 1086
>>> 
  drivers/gpu/drm/exynos/exynos_drm_drv.c|   17 +-
  drivers/gpu/drm/exynos/exynos_drm_drv.h|   11 +
  include/video/samsung_decon.h  |  346 +++
  7 files changed, 1537 insertions(+), 3 deletions(-)
  create mode 100644
>>> Documentation/devicetree/bindings/video/exynos-decon.txt
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
  create mode 100644 include/video/samsung_decon.h

 diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt
>>> b/Documentation/devicetree/bindings/video/exynos-decon.txt
 new file mode 100644
 index 000..e865650
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
 @@ -0,0 +1,68 @@
 +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
 +
 +DECON (Display and Enhancement Controller) is the Display Controller
>>> for the
 +Exynos7 series of SoCs which transfers the image data from a video memory
 +buffer to an external LCD interface.
 +
 +Required properties:
 +- compatible: value should be "samsung,exynos7-decon";
>>>
>>> If exynos5433 was just renamed to exynos7 then, it should be one of the
>>> following:
>>> (a) "samsung,exynos5430-decon" for Display and enhancement 
>>> controller
>>> IP for Exynos5430
>>> (b) "samsung,exynos7" for Display and enhancement controller IP for 
>>> Exynos7
>>>
>>> Or,
>>> (a) "samsung,exynos5430-decon" for Display and enhancement 
>>> controller
>>> IP for Exynos5430
>>>
>>> (b) "samsung,exynos5433-decon" for Display and enhancement 
>>> controller
>>> IP for Exynos5433
>>> (c) "samsung,exynos7" for Display and enhancement controller IP for 
>>> Exynos7
>> Eventually, we will end up here.
>>
>>>
 +
 +- reg: physical base address and length of the DECON registers set.
 +
 +- interrupt-parent: should be the phandle of the decon controller's
 + parent interrupt controller.
 +
 +- interrupts: should contain a list of all DECON IP block interrupts
>>> in the
 +  order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt 
 specifier
 +  format depends on the interrupt controller used.
 +
 +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
 + "lcd_sys", in the same order as they were listed in the interrupts
 +property.
 +
 +- pinctrl-0: pin control group to 

Re: [PATCH v7 0/7] Enable support for Samsung Exynos7 SoC

[Abhilash Kesavan]

Hello Olof and Arnd,

On Sun, Nov 9, 2014 at 9:50 AM, Abhilash Kesavan  wrote:
> These were originally part of 2 patchsets[1][2] adding support for Exynos7.
>  The clock and pinctrl patches are going through the respective maintainer's
> tree; hence the remaining dt related patches have been consolidated and are
> being posted here as a separate series.
>
> This patchset has build dependencies on the following patches:
> a] "[GIT PULL] Samsung clock changes for 3.19" - specifically the clock dt
>bindings header.
>http://comments.gmane.org/gmane.linux.kernel.samsung-soc/39142
> b] "tty: serial: samsung: Clean-up selection of number of available UARTs"
>http://www.spinics.net/lists/linux-samsung-soc/msg37418.html
> c] "dts, kbuild: Implement support for dtb vendor subdirs"(merged in 
> linux-next)
>https://lkml.org/lkml/2014/10/21/654
>
> [1] arch: arm64: Enable support for Samsung Exynos7 SoC
> http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
> [2] Add clock and DT support for a few IPs on Exynos7
> http://www.spinics.net/lists/linux-samsung-soc/msg37973.html
>
> Changes since v6:
> - Fixed the platform ordering (exynos before thunder) in Kconfig file.
> - Fixed the ordering of reg and enable-method properties in cpu node
> as per Lorenzo Pieralisi's comment.


Do you have any comments on this patchset ?

Regards,
Abhilash
>
> Abhilash Kesavan (2):
>   arm64: dts: Add PMU DT node for exynos7 SoC
>   arm64: dts: Add nodes for mmc, i2c, rtc, watchdog, adc on Exynos7
>
> Alim Akhtar (2):
>   arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support
>   arm64: Enable Exynos7 SOC in the defconfig
>
> Naveen Krishna Ch (2):
>   arm64: dts: Add initial device tree support for EXYNOS7
>   arm64: dts: Add initial pinctrl support to EXYNOS7
>
> Pankaj Dubey (1):
>   arm64: dts: add  symlink
>
>  .../devicetree/bindings/arm/samsung/pmu.txt|   1 +
>  arch/arm64/Kconfig |  17 +
>  arch/arm64/boot/dts/Makefile   |   1 +
>  arch/arm64/boot/dts/exynos/Makefile|   5 +
>  arch/arm64/boot/dts/exynos/exynos7-espresso.dts|  84 +++
>  arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi| 588 
> +
>  arch/arm64/boot/dts/exynos/exynos7.dtsi| 530 +++
>  arch/arm64/boot/dts/include/dt-bindings|   1 +
>  arch/arm64/configs/defconfig   |   4 +
>  9 files changed, 1231 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/exynos/Makefile
>  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi
>  create mode 12 arch/arm64/boot/dts/include/dt-bindings
>
> --
> 2.1.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] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hi Greg,

On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan
 wrote:
> Hi Tomasz,
>
> On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa  wrote:
>> Hi Abhilash,
>>
>> The patch itself seems fine, but I wonder if those config options aren't
>> really just leftovers from the past and couldn't be completely removed.
>>
>> On 29.09.2014 07:16, Abhilash Kesavan wrote:
>>> From: Pankaj Dubey 
>>>
>>> Exynos7 has a similar serial controller to that present in older Samsung
>>> SoCs. To re-use the existing serial driver on Exynos7 we need to have
>>> SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
>>> possible because these symbols are dependent on PLAT_SAMSUNG which is
>>> not present for the ARMv8 based exynos7.
>>>
>>> Change the dependency of these symbols from PLAT_SAMSUNG to the serial
>>> driver thus making it available on exynos7. As the existing platform
>>> specific code making use of these symbols is related to uart driver this
>>> change in dependency should not cause any issues.
>>>
>>> Signed-off-by: Pankaj Dubey 
>>> Signed-off-by: Naveen Krishna Chatradhi 
>>> Signed-off-by: Abhilash Kesavan 
>>> Cc: Greg Kroah-Hartman 
>>> ---
>>> Build tested with s3c6400_defconfig, exynos_defconfig and arm64's defconfig
>>> with and without the serial driver enabled.
>>>
>>>  drivers/tty/serial/Kconfig |4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>>> index 81f6ee7..e6c0bcb 100644
>>> --- a/drivers/tty/serial/Kconfig
>>> +++ b/drivers/tty/serial/Kconfig
>>> @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
>>>
>>>  config SERIAL_SAMSUNG_UARTS_4
>>>   bool
>>> - depends on PLAT_SAMSUNG
>>> + depends on SERIAL_SAMSUNG
>>>   default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || 
>>> CPU_S3C2442)
>>>   help
>>> Internal node for the common case of 4 Samsung compatible UARTs
>>
>> The only place where this symbol is used is below.
>>
>>>
>>>  config SERIAL_SAMSUNG_UARTS
>>>   int
>>> - depends on PLAT_SAMSUNG
>>> + depends on SERIAL_SAMSUNG
>>>   default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
>>>   default 3
>>>   help
>>>
>>
>> With this symbol the situation isn't that easy, but still should be
>> manageable.
>>
>> Looking at the serial-samsung driver, all occurrences of
>> CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally
>> defined number equal to the maximum value - in this case 4.
>>
>> There are also two places in arch/arm where this symbol is used:
>>
>> 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial
>> ports which need suspend/resume handling. Since on s3c64xx the number is
>> always 4, it can be simply defined locally as a constant.
>>
>> 2) In arch/arm/plat-samsung/init.c it is used to determine size of a
>> static array of UART ports and to check whether the UART driver is
>> enabled. In former case I believe it should be safe to hardcode it to 4
>> as well, in latter CONFIG_SERIAL_SAMSUNG can be used.
>
> I will post patches removing these two symbols.

I posted a couple of patches handling Tomasz' comments but Kukjin
prefers the approach in this patch (Discussion here:
http://www.spinics.net/lists/linux-samsung-soc/msg38742.html).
Can you please review the patch.

Regards,
Abhilash
>
> Regards,
> Abhilash
>>
>> Best regards,
>> Tomasz
>> --
>> 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

Re: [PATCH] mmc: dw_mmc: exynos: Add support for exynos7

[Alim Akhtar]

Hi Jaehoon,
As 64bit dependent patch for dw_mmc is already merged.
Do you have any comments on this patch?

This patch still apply cleanly on ulf's next and v3.18-rc4 kernel.

Regards,
Alim

On Tue, Oct 21, 2014 at 1:50 PM, Vivek Gautam  wrote:
> On Tue, Oct 21, 2014 at 1:47 PM, Vivek Gautam  
> wrote:
>
> Corrected Tomasz's mail id, as the earlier samsung one is not valid now.
> Also giving a Tested-by
>
>> On Mon, Sep 1, 2014 at 11:14 AM, Abhilash Kesavan
>>  wrote:
>>> Hi Jaehoon,
>>>
>>> +Prabu Thangamuthu
>>>
>>> On Fri, Aug 29, 2014 at 4:14 PM, Jaehoon Chung  
>>> wrote:
 Hi, Abhilash.

 On 08/28/2014 10:18 PM, Yuvaraj Kumar C D wrote:
> From: Abhilash Kesavan 
>
> The Exynos7 has a DWMMC controller (v2.70a) which is different from
> prior versions. This patch adds new compatible strings for exynos7.
> This patch also fixes the CLKSEL register offset on exynos7.

 If support the 64bit, dw-mmc.c need to modify.(according to v2.70, some 
 offset is changed for 64-bit address)
 But i didn't see any patches at mailing.
 Do you have the plan which send patch of dw-mmc.c?
>>>
>>> We are using a rebased version of
>>> http://www.spinics.net/lists/linux-mmc/msg21742.html to handle the
>>> dwmmc side changes. We should have mentioned this dependency as the
>>> patch is required for proper functioning of dwmmc on Exynos7.
>>> Stress tests are on-going with that patch and once it looks good, we
>>> will post our results so that the original patch may be taken forward.
>>>
>>> Regards,
>>> Abhilash

 Best Regards,
 Jaehoon Chung
>
> Signed-off-by: Abhilash Kesavan 
> Signed-off-by: Yuvaraj Kumar C D 
> ---
>>
>> I have tested this patch following set of patches:
>>
>> On Exynos7 support side:
>> 1) dts, kbuild: Implement support for dtb vendor subdirs" patchset
>> http://comments.gmane.org/gmane.linux.kbuild.devel/12131
>> 2) arch: arm64: Enable support for Samsung Exynos7 SoC  (V5)
>> http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
>> 3) Serial clean-up patches for Exynos7
>> http://www.spinics.net/lists/arm-kernel/msg367348.html
>> http://www.spinics.net/lists/arm-kernel/msg367349.html
>> 4) Add initial support for pinctrl on Exynos7  (V5)
>> http://www.spinics.net/lists/linux-samsung-soc/msg37708.html
>>
>> On MMC side:
>> 1) mmc: dw_mmc: Add IDMAC 64-bit address mode support  (V7)
>> https://lkml.org/lkml/2014/10/20/58
>> 2) mmc: dw_mmc: Reset DMA before enabling IDMAC  (V2)
>> http://www.gossamer-threads.com/lists/linux/kernel/2028229
>>
>> eMMC and SD are running fine on Exynos7.
>
> Tested-by: Vivek Gautam 
>
>>
>> If this change looks good, then we can take it in.
>>
>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |4 +
>  drivers/mmc/host/dw_mmc-exynos.c   |   91 
> +---
>  2 files changed, 82 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> index 6cd3525..ee4fc05 100644
> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> @@ -18,6 +18,10 @@ Required Properties:
> specific extensions.
>   - "samsung,exynos5420-dw-mshc": for controllers with Samsung 
> Exynos5420
> specific extensions.
> + - "samsung,exynos7-dw-mshc": for controllers with Samsung Exynos7
> +   specific extensions.
> + - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung 
> Exynos7
> +   specific extensions having an SMU.
>
>  * samsung,dw-mshc-ciu-div: Specifies the divider value for the card 
> interface
>unit (ciu) clock. This property is applicable only for Exynos5 SoC's 
> and
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
> b/drivers/mmc/host/dw_mmc-exynos.c
> index 0fbc53a..509365c 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -25,6 +25,7 @@
>  #define NUM_PINS(x)  (x + 2)
>
>  #define SDMMC_CLKSEL 0x09C
> +#define SDMMC_CLKSEL64   0x0A8
>  #define SDMMC_CLKSEL_CCLK_SAMPLE(x)  (((x) & 7) << 0)
>  #define SDMMC_CLKSEL_CCLK_DRIVE(x)   (((x) & 7) << 16)
>  #define SDMMC_CLKSEL_CCLK_DIVIDER(x) (((x) & 7) << 24)
> @@ -65,6 +66,8 @@ enum dw_mci_exynos_type {
>   DW_MCI_TYPE_EXYNOS5250,
>   DW_MCI_TYPE_EXYNOS5420,
>   DW_MCI_TYPE_EXYNOS5420_SMU,
> + DW_MCI_TYPE_EXYNOS7,
> + DW_MCI_TYPE_EXYNOS7_SMU,
>  };
>
>  /* Exynos implementation specific driver private data */
> @@ -95,6 +98,12 @@ static struct dw_mci_exynos_compatible {
>   }, {
>   .compatible = "samsung,exynos5420-dw-mshc-smu",
>   .ctrl_type  = DW_MC

[PATCH 0/3] regulator: max77802: Configure suspend modes

[Javier Martinez Canillas]

Hello Mark,

This series configures the max77802 regulators mode when entering in the
Suspend-to-RAM state. The patches in this series were part of a previous
patch-set that also added initial and suspend mode support for the core.
The previous patch-set was [0] but the feedback was that instead mixing
core changes, bugfixes and new driver features, the series should be split
and core changes posted separately from driver new features.

So this series build on top of the series:

"[PATCH v6 0/5] regulator: of: Add initial and suspend modes support" [1]

and to avoid merge conflicts also depends on Krzysztof's series:

"[PATCH v2 0/3] regulator: max77686/802: Cleanup" [2].

The patch-set is composed of the following patches:

Javier Martinez Canillas (3):
  regulator: max77802: Document binding for regulator operating modes
  regulator: max77802: Fill regulator modes translation callback
  ARM: dts: Configure regulators for suspend on exynos Peach boards

 .../devicetree/bindings/regulator/max77802.txt | 35 ++
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 81 ++
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 81 ++
 drivers/regulator/max77802.c   |  6 ++
 4 files changed, 203 insertions(+)

Patch #1 documents the operating modes that are supported by the regulators
in the Maxim 77802 PMIC.

Patch #2 fills the .of_map_mode callback function that is used to translate
between the device specific modes configured in the Device Tree and the
standard modes used by the regulator core.

Patch #3 configures the regulators in the Exynos Peach boards which use a
max77802 PMIC. This patch should be merged through the linux-samsung tree
but I added to the series since shows how the DT binding is used in a DTS.

Best regards,
Javier

[0]: https://lkml.org/lkml/2014/11/3/397
[1]: https://lkml.org/lkml/2014/11/10/325
[2]: https://lkml.org/lkml/2014/11/5/118
--
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] ARM: dts: Configure regulators for suspend on exynos Peach boards

[Javier Martinez Canillas]

The regulator core now has support to choose if a regulator
has to be enabled or disabled during system suspend and also
supports changing the regulator operating mode during runtime
and when the system enters into sleep mode.

To lower power during suspend, configure the regulators state
using the same configuration found in the ChromeOS 3.8 kernel.

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 81 ++
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 81 ++
 2 files changed, 162 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 9a050e1..8b744c7 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "exynos5420.dtsi"
 
 / {
@@ -192,6 +193,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck2_reg: BUCK2 {
@@ -201,6 +205,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck3_reg: BUCK3 {
@@ -210,6 +217,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck4_reg: BUCK4 {
@@ -219,6 +229,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck5_reg: BUCK5 {
@@ -227,6 +240,9 @@
regulator-max-microvolt = <120>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck6_reg: BUCK6 {
@@ -236,6 +252,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck7_reg: BUCK7 {
@@ -244,6 +263,9 @@
regulator-max-microvolt = <135>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
buck8_reg: BUCK8 {
@@ -252,6 +274,9 @@
regulator-max-microvolt = <285>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck9_reg: BUCK9 {
@@ -260,6 +285,9 @@
regulator-max-microvolt = <200>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
buck10_reg: BUCK10 {
@@ -268,6 +296,9 @@
regulator-max-microvolt = <180>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+

[PATCH 1/3] regulator: max77802: Document binding for regulator operating modes

[Javier Martinez Canillas]

Some regulators from the max77802 PMIC support to be configured in one
of two operating mode: Output ON (normal) and Output On Low Power Mode.
Not all regulators support these two modes and for some of them, the
mode can be changed while the system is running in normal operation
while others only support their mode to be changed on system suspend.

Extend the max77802 PMIC binding by documenting the possible operating
modes values so the regulators modes can be configured correctly.

Signed-off-by: Javier Martinez Canillas 
---
 .../devicetree/bindings/regulator/max77802.txt | 35 ++
 1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt 
b/Documentation/devicetree/bindings/regulator/max77802.txt
index 5aeaffc..79e5476 100644
--- a/Documentation/devicetree/bindings/regulator/max77802.txt
+++ b/Documentation/devicetree/bindings/regulator/max77802.txt
@@ -25,6 +25,29 @@ with their hardware counterparts as follow. The valid names 
are:
example: LDO1, LDO2, LDO35.
-BUCKn  :   for BUCKs, where n can lie in range 1 to 10.
example: BUCK1, BUCK5, BUCK10.
+
+The max77802 regulator supports two different operating modes: Normal and Low
+Power Mode. Some regulators support the modes to be changed at startup or by
+the consumers during normal operation while others only support to change the
+mode during system suspend. The standard regulator suspend states binding can
+be used to configure the regulator operating mode.
+
+The regulators that support the standard "regulator-initial-mode" property,
+changing their mode during normal operation are: LDOs 1, 3, 20 and 21.
+
+The possible values for "regulator-initial-mode" and "regulator-mode" are:
+   1: Normal regulator voltage output mode.
+   3: Low Power which reduces the quiescent current down to only 1uA
+
+The list of valid modes are defined in the dt-bindings/clock/maxim,max77802.h
+header and can be included by device tree source files.
+
+The standard "regulator-mode" property can only be used for regulators that
+support changing their mode to Low Power Mode during suspend. These regulators
+are: BUCKs 2-4 and LDOs 1-35. Also, it only takes effect if the regulator has
+been enabled for the given suspend state using "regulator-on-in-suspend" and
+has not been disabled for that state using "regulator-off-in-suspend".
+
 Example:
 
max77802@09 {
@@ -36,11 +59,23 @@ Example:
#size-cells = <0>;
 
regulators {
+   ldo1_reg: LDO1 {
+   regulator-name = "vdd_1v0";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   regulator-always-on;
+   regulator-initial-mode = ;
+   };
+
ldo11_reg: LDO11 {
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <190>;
regulator-max-microvolt = <190>;
regulator-always-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   regulator-mode = ;
+   };
};
 
buck1_reg: BUCK1 {
-- 
2.1.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 2/3] regulator: max77802: Fill regulator modes translation callback

[Javier Martinez Canillas]

The max77802 PMIC regulators output can be configured in one of two
modes: Output ON (normal) and Output ON in Low Power Mode. Some of
the regulators support their operating mode to be changed on startup
or by consumers when the system is running while others only support
their operating mode to be changed while the system has entered in a
suspend state.

Use the max77802_map_mode() function to translate the device specific
modes to the standard operating modes as used by the regulator core.

Signed-off-by: Javier Martinez Canillas 
---
 drivers/regulator/max77802.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 9b4d127..0766615 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -378,6 +378,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask  = MAX77802_VSEL_MASK,   \
.enable_reg = MAX77802_REG_LDO1CTRL1 + num - 1, \
.enable_mask= MAX77802_OPMODE_MASK << MAX77802_OPMODE_SHIFT_LDO, \
+   .of_map_mode= max77802_map_mode,\
 }
 
 /* LDOs 1, 2, 8, 15, 17, 27, 30, 35 */
@@ -398,6 +399,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask  = MAX77802_VSEL_MASK,   \
.enable_reg = MAX77802_REG_LDO1CTRL1 + num - 1, \
.enable_mask= MAX77802_OPMODE_MASK << MAX77802_OPMODE_SHIFT_LDO, \
+   .of_map_mode= max77802_map_mode,\
 }
 
 /* BUCKs 1, 6 */
@@ -418,6 +420,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask  = MAX77802_DVS_VSEL_MASK,   \
.enable_reg = MAX77802_REG_BUCK ## num ## CTRL, \
.enable_mask= MAX77802_OPMODE_MASK, \
+   .of_map_mode= max77802_map_mode,\
 }
 
 /* BUCKS 2-4 */
@@ -439,6 +442,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.enable_reg = MAX77802_REG_BUCK ## num ## CTRL1,\
.enable_mask= MAX77802_OPMODE_MASK <<   \
MAX77802_OPMODE_BUCK234_SHIFT,  \
+   .of_map_mode= max77802_map_mode,\
 }
 
 /* BUCK 5 */
@@ -459,6 +463,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask  = MAX77802_VSEL_MASK,   \
.enable_reg = MAX77802_REG_BUCK5CTRL,   \
.enable_mask= MAX77802_OPMODE_MASK, \
+   .of_map_mode= max77802_map_mode,\
 }
 
 /* BUCKs 7-10 */
@@ -479,6 +484,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask  = MAX77802_VSEL_MASK,   \
.enable_reg = MAX77802_REG_BUCK7CTRL + (num - 7) * 3,   \
.enable_mask= MAX77802_OPMODE_MASK, \
+   .of_map_mode= max77802_map_mode,\
 }
 
 static const struct regulator_desc regulators[] = {
-- 
2.1.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] media: v4l2: make alloction alogthim more robust and flexible

[Sakari Ailus]

Hi Zhaowei,

My apologies for the delayed reply.

On Wed, Jul 30, 2014 at 11:55:32AM +0800, Zhaowei Yuan wrote:
> Current algothim relies on the fact that caller will align the
> size to PAGE_SIZE, otherwise order will be decreased to negative
> when remain size is less than PAGE_SIZE, it makes the function
> hard to be migrated.
> This patch sloves the hidden problem.
> 
> Signed-off-by: Zhaowei Yuan 
> ---
>  drivers/media/v4l2-core/videobuf2-dma-sg.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
> b/drivers/media/v4l2-core/videobuf2-dma-sg.c
> index adefc31..40d18aa 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
> @@ -58,7 +58,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf 
> *buf,
> 
>   order = get_order(size);
>   /* Dont over allocate*/
> - if ((PAGE_SIZE << order) > size)
> + if (order > 0 && (PAGE_SIZE << order) > size)
>   order--;
> 
>   pages = NULL;

With comments from Andreas taken into account,

Acked-by: Sakari Ailus 

I'd consider this for the stable series as well.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 0/9] PM / Domains: Fix race conditions during boot

[Ulf Hansson]

[...]

> 2) There are no requirements for arch/platforms/drivers to work in both cases
> CONFIG_PM_RUNTIME=y/n. But they must be built without errors/warning for both
> cases.

For cross SoC drivers this statement is not correct! Driver _must_
support the various combinations of CONFIG_PM*.

Therefore, I think it's better to strive towards a common solution and
to get the building blocks in place.

>
> For example, for Keystone 2 only CONFIG_PM_RUNTIME=y is going to be supported
> and if some one decided to disable it - it can be perfectly done from sys_fs/
> user space.

I can't see why the sysfs option to disable runtime PM should affect
this discussion. That's done at runtime and after the device has been
probed.

>
> 3) pm_runtime_get_sync()(or similar) is good not only because i's waking up 
> device, but also
> because:
> - it can wake up chain of devices (dev->parent->parent->...)

That's right. But that's not what this patchset aims to do.

I realize that the header of the cover letter isn't describing the
problem I am trying to solve very well. I guess the below header would
have been better:

"PM / Domains: Power up PM domains prior drivers starts to probe their devices"

> - it can wake up power domain

Yes, but it requires CONFIG_PM_RUNTIME to be set.

Thus, to solve the problem during driver ->probe() we need another
solution which don't require CONFIG_PM_RUNTIME to be set. As this
patchset proposes.

> - it connects device to domain/class/type/bus and so allow to add additional 
> PM layer on top
>   of Platform bus (for example arch/arm/mach-omap2/omap_device.c).
>
> So, it will do all needed things, and if it doesn't that problem is in 
> platfrom/bus/driver
> code and not in Runtime PM.
> if pm_runtime_get_sync() will be dropped - than all above will need to be 
> implemented
> around the ->probe().

I am not sure what you mean about dropping pm_runtime_get_sync()? All
I am saying is that we can't use it to power on PM domains during the
probe sequence.

Of course, you may still use pm_runtime_get_sync() from anywhere it's
needed, to for example handle device's parent/child relationships.

>
> 4) I've copied here comment from Rafael:
>   Of course, if ->probe() is to call pm_runtime_resume() for this purpose,
>   it must take the fact that the driver's own ->runtime_resume() may be 
> called
>   as a result of this into account.
>  Agree, that's a little bit annoying, but we are living with that for more 
> then
>  5 years already (I'm 3 years) - so, I am, as driver developer, expecting 
> above behavior
>  (just walk through the drivers and you will see how many drivers expecting 
> the same).
>
> So, any volunteers to check and fix ~500 drivers.

We don't have to change these drivers. An certainly they are not 500. :-)

They will still work as is!

Though we need this fix to comply with them, which is supposed to go
in for 3.18 rc[n].
"PM / Domains: Fix initial default state of the need_restore flag"

[...]

Kind regards
Uffe
--
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] mtd: remove .owner field for driver using module_platform_driver

[Varka Bhadram]

Hi Sanjeev Sharma,

On 11/11/2014 03:57 PM, Sanjeev Sharma wrote:

This patch removes the .owner field for drivers which use the
platform_driver_register api because this is overriden in
_platform_driver_register.

Signed-off-by: Sanjeev Sharma 
---
  drivers/mtd/nand/ams-delta.c | 1 -
  drivers/mtd/nand/atmel_nand.c| 2 --
  drivers/mtd/nand/au1550nd.c  | 1 -
  drivers/mtd/nand/bf5xx_nand.c| 1 -
  drivers/mtd/nand/davinci_nand.c  | 1 -
  drivers/mtd/nand/denali_dt.c | 1 -
  drivers/mtd/nand/docg4.c | 1 -
  drivers/mtd/nand/fsl_elbc_nand.c | 1 -
  drivers/mtd/nand/fsl_ifc_nand.c  | 1 -
  drivers/mtd/nand/fsl_upm.c   | 1 -
  drivers/mtd/nand/fsmc_nand.c | 1 -
  drivers/mtd/nand/gpio.c  | 1 -
  drivers/mtd/nand/jz4740_nand.c   | 1 -
  drivers/mtd/nand/lpc32xx_mlc.c   | 1 -
  drivers/mtd/nand/lpc32xx_slc.c   | 1 -
  drivers/mtd/nand/mpc5121_nfc.c   | 1 -
  drivers/mtd/nand/mxc_nand.c  | 1 -
  drivers/mtd/nand/ndfc.c  | 1 -
  drivers/mtd/nand/nuc900_nand.c   | 1 -
  drivers/mtd/nand/omap2.c | 1 -
  drivers/mtd/nand/omap_elm.c  | 1 -
  drivers/mtd/nand/orion_nand.c| 1 -
  drivers/mtd/nand/pasemi_nand.c   | 1 -
  drivers/mtd/nand/plat_nand.c | 1 -
  drivers/mtd/nand/s3c2410.c   | 1 -
  drivers/mtd/nand/sh_flctl.c  | 1 -
  drivers/mtd/nand/sharpsl.c   | 1 -
  drivers/mtd/nand/socrates_nand.c | 1 -
  drivers/mtd/nand/tmio_nand.c | 1 -
  drivers/mtd/nand/txx9ndfmc.c | 1 -
  30 files changed, 31 deletions(-)


This removal of .owner field should be done for all the platform drivers which 
are using
module_platform_driver().

Wolfram Sang  working on this change on the all the 
drivers. Please see [1].


[1]:https://git.kernel.org/cgit/linux/kernel/git/wsa/linux.git/log/?h=platform/remove_owner

--
Thanks and Regards,
Varka Bhadram.

--
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] mtd: remove .owner field for driver using module_platform_driver

[Sanjeev Sharma]

This patch removes the .owner field for drivers which use the
platform_driver_register api because this is overriden in
_platform_driver_register.

Signed-off-by: Sanjeev Sharma 
---
 drivers/mtd/nand/ams-delta.c | 1 -
 drivers/mtd/nand/atmel_nand.c| 2 --
 drivers/mtd/nand/au1550nd.c  | 1 -
 drivers/mtd/nand/bf5xx_nand.c| 1 -
 drivers/mtd/nand/davinci_nand.c  | 1 -
 drivers/mtd/nand/denali_dt.c | 1 -
 drivers/mtd/nand/docg4.c | 1 -
 drivers/mtd/nand/fsl_elbc_nand.c | 1 -
 drivers/mtd/nand/fsl_ifc_nand.c  | 1 -
 drivers/mtd/nand/fsl_upm.c   | 1 -
 drivers/mtd/nand/fsmc_nand.c | 1 -
 drivers/mtd/nand/gpio.c  | 1 -
 drivers/mtd/nand/jz4740_nand.c   | 1 -
 drivers/mtd/nand/lpc32xx_mlc.c   | 1 -
 drivers/mtd/nand/lpc32xx_slc.c   | 1 -
 drivers/mtd/nand/mpc5121_nfc.c   | 1 -
 drivers/mtd/nand/mxc_nand.c  | 1 -
 drivers/mtd/nand/ndfc.c  | 1 -
 drivers/mtd/nand/nuc900_nand.c   | 1 -
 drivers/mtd/nand/omap2.c | 1 -
 drivers/mtd/nand/omap_elm.c  | 1 -
 drivers/mtd/nand/orion_nand.c| 1 -
 drivers/mtd/nand/pasemi_nand.c   | 1 -
 drivers/mtd/nand/plat_nand.c | 1 -
 drivers/mtd/nand/s3c2410.c   | 1 -
 drivers/mtd/nand/sh_flctl.c  | 1 -
 drivers/mtd/nand/sharpsl.c   | 1 -
 drivers/mtd/nand/socrates_nand.c | 1 -
 drivers/mtd/nand/tmio_nand.c | 1 -
 drivers/mtd/nand/txx9ndfmc.c | 1 -
 30 files changed, 31 deletions(-)

diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 4936e9e..f1d555c 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -290,7 +290,6 @@ static struct platform_driver ams_delta_nand_driver = {
.remove = ams_delta_cleanup,
.driver = {
.name   = "ams-delta-nand",
-   .owner  = THIS_MODULE,
},
 };
 
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 19d1e9d..84c38f3 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -2312,7 +2312,6 @@ MODULE_DEVICE_TABLE(of, atmel_nand_nfc_match);
 static struct platform_driver atmel_nand_nfc_driver = {
.driver = {
.name = "atmel_nand_nfc",
-   .owner = THIS_MODULE,
.of_match_table = of_match_ptr(atmel_nand_nfc_match),
},
.probe = atmel_nand_nfc_probe,
@@ -2324,7 +2323,6 @@ static struct platform_driver atmel_nand_driver = {
.remove = atmel_nand_remove,
.driver = {
.name   = "atmel_nand",
-   .owner  = THIS_MODULE,
.of_match_table = of_match_ptr(atmel_nand_dt_ids),
},
 };
diff --git a/drivers/mtd/nand/au1550nd.c b/drivers/mtd/nand/au1550nd.c
index 77d6c17..c0c3be1 100644
--- a/drivers/mtd/nand/au1550nd.c
+++ b/drivers/mtd/nand/au1550nd.c
@@ -503,7 +503,6 @@ static int au1550nd_remove(struct platform_device *pdev)
 static struct platform_driver au1550nd_driver = {
.driver = {
.name   = "au1550-nand",
-   .owner  = THIS_MODULE,
},
.probe  = au1550nd_probe,
.remove = au1550nd_remove,
diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index 871c4f7..4d8d4ba 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -836,7 +836,6 @@ static struct platform_driver bf5xx_nand_driver = {
.remove = bf5xx_nand_remove,
.driver = {
.name   = DRV_NAME,
-   .owner  = THIS_MODULE,
},
 };
 
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index b922c8e..feb6d18 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -870,7 +870,6 @@ static struct platform_driver nand_davinci_driver = {
.remove = nand_davinci_remove,
.driver = {
.name   = "davinci_nand",
-   .owner  = THIS_MODULE,
.of_match_table = of_match_ptr(davinci_nand_of_match),
},
 };
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index 35cb17f..0cb1e8d 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -120,7 +120,6 @@ static struct platform_driver denali_dt_driver = {
.remove = denali_dt_remove,
.driver = {
.name   = "denali-nand-dt",
-   .owner  = THIS_MODULE,
.of_match_table = denali_nand_dt_ids,
},
 };
diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index ce24637..e5d7bca 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -1380,7 +1380,6 @@ static int __exit cleanup_docg4(struct platform_device 
*pdev)
 static struct platform_driver docg4_driver = {
.driver = {
.name   = "docg4",
-   .owner  = THIS_MODULE,
},
.suspend= docg4_suspend,
  

Re: [PATCH v3 2/2] ARM: EXYNOS: Call regulator core suspend prepare and finish functions

[Javier Martinez Canillas]

Hello Kukjin,

On Thu, Oct 30, 2014 at 11:06 AM, Javier Martinez Canillas
 wrote:
> Hello Kukjin,
>
> On Mon, Oct 20, 2014 at 11:05 PM, Javier Martinez Canillas
>  wrote:
>> The regulator framework has a set of helpers functions to be used when
>> the system is entering and leaving from suspend but these are not called
>> on Exynos platforms. This means that the .set_suspend_* function handlers
>> defined by regulator drivers are not called when the system is suspended.
>>
>> Suggested-by: Doug Anderson 
>> Signed-off-by: Javier Martinez Canillas 
>> Reviewed-by: Doug Anderson 
>> ---
>>  arch/arm/mach-exynos/suspend.c | 23 +++
>>  1 file changed, 23 insertions(+)
>>
>
> Any comments on this patch?
>

Just a gentle reminder about this patch.

Best regards,
Javier
--
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] PM / Domains: Fix initial default state of the need_restore flag

[Ulf Hansson]

The initial state of the device's need_restore flag should'nt depend on
the current state of the PM domain. For example it should be perfectly
valid to attach an inactive device to a powered PM domain.

The pm_genpd_dev_need_restore() API allow us to update the need_restore
flag to somewhat cope with such scenarios. Typically that should have
been done from drivers/buses ->probe() since it's those that put the
requirements on the value of the need_restore flag.

Until recently, the Exynos SOCs were the only user of the
pm_genpd_dev_need_restore() API, though invoking it from a centralized
location while adding devices to their PM domains.

Due to that Exynos now have swithed to the generic OF-based PM domain
look-up, it's no longer possible to invoke the API from a centralized
location. The reason is because devices are now added to their PM
domains during the probe sequence.

Commit "ARM: exynos: Move to generic PM domain DT bindings"
did the switch for Exynos to the generic OF-based PM domain look-up,
but it also removed the call to pm_genpd_dev_need_restore(). This
caused a regression for some of the Exynos drivers.

To handle things more properly in the generic PM domain, let's change
the default initial value of the need_restore flag to reflect that the
state is unknown. As soon as some of the runtime PM callbacks gets
invoked, update the initial value accordingly.

Moreover, since the generic PM domain is verifying that all device's
are both runtime PM enabled and suspended, using pm_runtime_suspended()
while pm_genpd_poweroff() is invoked from the scheduled work, we can be
sure of that the PM domain won't be powering off while having active
devices.

Do note that, the generic PM domain can still only know about active
devices which has been activated through invoking its runtime PM resume
callback. In other words, buses/drivers using pm_runtime_set_active()
during ->probe() will still suffer from a race condition, potentially
probing a device without having its PM domain being powered. That issue
will have to be solved using a different approach.

This a log from the boot regression for Exynos5, which is being fixed in
this patch.

[ cut here ]
WARNING: CPU: 0 PID: 308 at ../drivers/clk/clk.c:851 clk_disable+0x24/0x30()
Modules linked in:
CPU: 0 PID: 308 Comm: kworker/0:1 Not tainted 3.18.0-rc3-00569-gbd9449f-dirty 
#10
Workqueue: pm pm_runtime_work
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x70/0xbc)
[] (dump_stack) from [] (warn_slowpath_common+0x64/0x88)
[] (warn_slowpath_common) from [] 
(warn_slowpath_null+0x1c/0x24)
[] (warn_slowpath_null) from [] (clk_disable+0x24/0x30)
[] (clk_disable) from [] (gsc_runtime_suspend+0x128/0x160)
[] (gsc_runtime_suspend) from [] 
(pm_generic_runtime_suspend+0x2c/0x38)
[] (pm_generic_runtime_suspend) from [] 
(pm_genpd_default_save_state+0x2c/0x8c)
[] (pm_genpd_default_save_state) from [] 
(pm_genpd_poweroff+0x224/0x3ec)
[] (pm_genpd_poweroff) from [] 
(pm_genpd_runtime_suspend+0x9c/0xcc)
[] (pm_genpd_runtime_suspend) from [] 
(__rpm_callback+0x2c/0x60)
[] (__rpm_callback) from [] (rpm_callback+0x20/0x74)
[] (rpm_callback) from [] (rpm_suspend+0xd4/0x43c)
[] (rpm_suspend) from [] (pm_runtime_work+0x80/0x90)
[] (pm_runtime_work) from [] (process_one_work+0x12c/0x314)
[] (process_one_work) from [] (worker_thread+0x3c/0x4b0)
[] (worker_thread) from [] (kthread+0xcc/0xe8)
[] (kthread) from [] (ret_from_fork+0x14/0x3c)
---[ end trace 40cd58bcd6988f12 ]---

Fixes: a4a8c2c4962bb655 (ARM: exynos: Move to generic PM domain DT bindings)
Reported-by: Sylwester Nawrocki 
Reviewed-by: Sylwester Nawrocki 
Tested-by: Sylwester Nawrocki 
Reviewed-by: Kevin Hilman 
Signed-off-by: Ulf Hansson 
---

I am resending the v2, since I realized that I forgot to update the version in
the patch header.

Changes in v2:
Applied some Reviewed|Tested-by tags.
Added some newlines. (Kevin)
Checking for the sign instead of for a specific value. (Rafael)


This patch is intended as fix for 3.18 rc[n] due to the regression for Exynos
SOCs.

I would also like to call for help in getting this thoroughly tested.

I have tested this on Arndale Dual, Exynos 5250. According the log attached in
the commit message as well.

I have tested this on UX500, which support for the generic PM domain is about
to be queued for 3.19. Since UX500 uses the AMBA bus/drivers, which uses
pm_runtime_set_active() instead of pm_runtime_get_sync() during ->probe(), I
could also verify that this behavior is maintained.

Finally I have also tested this patchset on UX500 and using the below patchset
to make sure the approach is suitable long term wise as well.
[PATCH v3 0/9] PM / Domains: Fix race conditions during boot
http://www.spinics.net/lists/arm-kernel/msg369409.html

---
 drivers/base/power/domain.c | 38 --
 include/linux/pm_domain.h   |  2 +-
 2 files changed, 33 insertions(+), 7 deletions(

Re: [PATCH] ARM: EXYNOS: fix typo in static struct name "exynos5_list_diable_wfi_wfe"

[Javier Martinez Canillas]

Hello Kukjin,

>
> After this patch, "[PATCH v9 1/2] ARM: EXYNOS: Add platform driver
> support for Exynos PMU" [0] does not apply cleanly anymore.
>

I see that you already picked all the Exynos S2R patches on your
v3.19-next/mach-exynos branch and also resolved that conflict.

Is just that this branch was not merged in your for-next branch and
that's why I didn't see the patches in linux-next.

Sorry for the noise.

Best regards,
Javier
--
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] ARM: EXYNOS: fix typo in static struct name "exynos5_list_diable_wfi_wfe"

[Javier Martinez Canillas]

Hello Pankaj, Kukjin,

On Tue, Oct 28, 2014 at 10:50 AM, Pankaj Dubey  wrote:
> This patch fixes a typo in struct named as "exynos5_list_diable_wfi_wfe"
> by making it "exynos5_list_disable_wfi_wfe" which is more meaningful.
>
> Signed-off-by: Pankaj Dubey 

After this patch, "[PATCH v9 1/2] ARM: EXYNOS: Add platform driver
support for Exynos PMU" [0] does not apply cleanly anymore.

Pankaj,

Are you planning to rebase and re-post that patch?

Kukjin,

It would be great if you can pick all the pending Exynos5420 S2R
patches to avoid these kind of conflicts.

Thanks a lot and best regards,
Javier

[0]: https://lkml.org/lkml/2014/10/6/90
--
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 4/4] ASoC: rt5631: Adding Device Tree compatibility to Realtek's ALC5631 codec driver

[Krishna Mohan Dani]

Signed-off-by: Krishna Mohan Dani 
---
 sound/soc/codecs/rt5631.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/sound/soc/codecs/rt5631.c b/sound/soc/codecs/rt5631.c
index 1ba27db..101b205 100644
--- a/sound/soc/codecs/rt5631.c
+++ b/sound/soc/codecs/rt5631.c
@@ -1686,10 +1686,18 @@ static struct snd_soc_codec_driver soc_codec_dev_rt5631 
= {
 
 static const struct i2c_device_id rt5631_i2c_id[] = {
{ "rt5631", 0 },
+   { "alc5631", 0 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, rt5631_i2c_id);
 
+static struct of_device_id rt5631_i2c_dt_ids[] = {
+   { .compatible = "realtek,rt5631"},
+   { .compatible = "realtek,alc5631"},
+   { }
+};
+MODULE_DEVICE_TABLE(of, rt5631_i2c_dt_ids);
+
 static const struct regmap_config rt5631_regmap_config = {
.reg_bits = 8,
.val_bits = 16,
@@ -1734,6 +1742,9 @@ static struct i2c_driver rt5631_i2c_driver = {
.driver = {
.name = "rt5631",
.owner = THIS_MODULE,
+#ifdef CONFIG_OF
+   .of_match_table = of_match_ptr(rt5631_i2c_dt_ids),
+#endif
},
.probe = rt5631_i2c_probe,
.remove   = rt5631_i2c_remove,
-- 
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/4] Sound: Kconfig: Adding the description of the codec

[Krishna Mohan Dani]

Signed-off-by: Krishna Mohan Dani 
---
 sound/soc/codecs/Kconfig |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index a68d173..2d85887 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -487,7 +487,8 @@ config SND_SOC_RT286
depends on I2C
 
 config SND_SOC_RT5631
-   tristate
+   tristate "Realtek ALC5631 CODEC"
+   depends on I2C
 
 config SND_SOC_RT5640
tristate
-- 
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 2/4] ASoC: Samsung: Add arndale_rt5631 machine driver

[Krishna Mohan Dani]

Adding machine driver to instantiate I2S based realtek's ALC5631
sound card on Arndale board.

There are other variants of Audio Daughter Cards for Arndale
Board for which support already exists but there is no support for
Realtek's alc5631 codec hence support for ALC5631 based machine
driver is being added.

Signed-off-by: Krishna Mohan Dani 
---
 sound/soc/samsung/Kconfig  |6 ++
 sound/soc/samsung/Makefile |2 +
 sound/soc/samsung/arndale_rt5631.c |  166 
 3 files changed, 174 insertions(+)
 create mode 100644 sound/soc/samsung/arndale_rt5631.c

diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 55a3869..80b5c61 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -239,3 +239,9 @@ config SND_SOC_ODROIDX2
select SND_SAMSUNG_I2S
help
  Say Y here to enable audio support for the Odroid-X2/U3.
+
+config SND_SOC_ARNDALE_RT5631_ALC5631
+tristate "Audio support for RT5631(ALC5631) on Arndale Board"
+depends on SND_SOC_SAMSUNG
+select SND_SAMSUNG_I2S
+select SND_SOC_RT5631
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 91505dd..31e3dba 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -45,6 +45,7 @@ snd-soc-lowland-objs := lowland.o
 snd-soc-littlemill-objs := littlemill.o
 snd-soc-bells-objs := bells.o
 snd-soc-odroidx2-max98090-objs := odroidx2_max98090.o
+snd-soc-arndale-rt5631-objs := arndale_rt5631.o
 
 obj-$(CONFIG_SND_SOC_SAMSUNG_JIVE_WM8750) += snd-soc-jive-wm8750.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_NEO1973_WM8753) += snd-soc-neo1973-wm8753.o
@@ -71,3 +72,4 @@ obj-$(CONFIG_SND_SOC_LOWLAND) += snd-soc-lowland.o
 obj-$(CONFIG_SND_SOC_LITTLEMILL) += snd-soc-littlemill.o
 obj-$(CONFIG_SND_SOC_BELLS) += snd-soc-bells.o
 obj-$(CONFIG_SND_SOC_ODROIDX2) += snd-soc-odroidx2-max98090.o
+obj-$(CONFIG_SND_SOC_ARNDALE_RT5631_ALC5631) += snd-soc-arndale-rt5631.o
diff --git a/sound/soc/samsung/arndale_rt5631.c 
b/sound/soc/samsung/arndale_rt5631.c
new file mode 100644
index 000..17cf289
--- /dev/null
+++ b/sound/soc/samsung/arndale_rt5631.c
@@ -0,0 +1,166 @@
+/*
+ *  arndale_rt5631.c
+ *
+ *  Copyright (c) 2014, Insignal Co., Ltd.
+ *
+ *  Author: Claude 
+ *
+ *  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
+ *  Free Software Foundation;  either version 2 of the  License, or (at your
+ *  option) any later version.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "i2s.h"
+
+static int arndale_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+   struct snd_soc_dai *codec_dai = rtd->codec_dai;
+   int bfs, psr, rfs, ret;
+   unsigned long rclk;
+
+   bfs = 32;
+
+   rfs = 256;
+
+   rclk = params_rate(params) * rfs;
+
+   psr = 4;
+
+   ret = snd_soc_dai_set_sysclk(cpu_dai, SAMSUNG_I2S_CDCLK,
+   0, SND_SOC_CLOCK_OUT);
+   if (ret < 0)
+   return ret;
+
+   ret = snd_soc_dai_set_sysclk(cpu_dai, SAMSUNG_I2S_RCLKSRC_0,
+   0, SND_SOC_CLOCK_OUT);
+
+   if (ret < 0)
+   return ret;
+
+   ret = snd_soc_dai_set_sysclk(codec_dai, 0, rclk, SND_SOC_CLOCK_OUT);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static struct snd_soc_ops arndale_ops = {
+   .hw_params = arndale_hw_params,
+};
+
+static int arndale_alc5631_init_paiftx(struct snd_soc_pcm_runtime *rtd)
+{
+   struct snd_soc_codec *codec = rtd->codec;
+   struct snd_soc_dapm_context *dapm = &codec->dapm;
+
+   snd_soc_dapm_sync(dapm);
+
+   return 0;
+}
+
+static struct snd_soc_dai_link arndale_dai[] = {
+   {
+   .name = "RT5631 HiFi",
+   .stream_name = "Primary",
+   .codec_dai_name = "rt5631-hifi",
+   .init = arndale_alc5631_init_paiftx,
+   .dai_fmt = SND_SOC_DAIFMT_I2S
+   | SND_SOC_DAIFMT_NB_NF
+   | SND_SOC_DAIFMT_CBS_CFS,
+   .ops = &arndale_ops,
+   },
+};
+
+static struct snd_soc_card arndale = {
+   .name = "Arndale-I2S",
+   .dai_link = arndale_dai,
+   .num_links = ARRAY_SIZE(arndale_dai),
+};
+
+static int arndale_audio_probe(struct platform_device *pdev)
+{
+   int n, ret;
+   struct device_node *np = pdev->dev.of_node;
+   struct snd_soc_card *card = &arndale;
+
+   card->dev = &pdev->dev;
+
+   for (n = 0; np && n < ARRAY_SIZE(arndale_dai); n++) {
+   if (!arndale_dai[n].cpu_dai_name) {
+   arndale_dai[n].cpu_of_node = of_parse_phandle(np,
+ 

[PATCH 1/4] ASoC: ALC5631/RT5631: Add device tree binding documentation

[Krishna Mohan Dani]

Document the device tree binding for the ALC5631 codec and update vendor
specific prefix for the Realtek.

Signed-off-by: Krishna Mohan Dani 
---
 Documentation/devicetree/bindings/sound/rt5631.txt |   48 
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/rt5631.txt

diff --git a/Documentation/devicetree/bindings/sound/rt5631.txt 
b/Documentation/devicetree/bindings/sound/rt5631.txt
new file mode 100644
index 000..92b986c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rt5631.txt
@@ -0,0 +1,48 @@
+ALC5631/RT5631 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+  - compatible : "realtek,alc5631" or "realtek,rt5631"
+
+  - reg : the I2C address of the device.
+
+Pins on the device (for linking into audio routes):
+
+  * SPK_OUT_R_P
+  * SPK_OUT_R_N
+  * SPK_OUT_L_P
+  * SPK_OUT_L_N
+  * HP_OUT_L
+  * HP_OUT_R
+  * AUX_OUT2_LP
+  * AUX_OUT2_RN
+  * AUX_OUT1_LP
+  * AUX_OUT1_RN
+  * AUX_IN_L_JD
+  * AUX_IN_R_JD
+  * MONO_IN_P
+  * MONO_IN_N
+  * MIC1_P
+  * MIC1_N
+  * MIC2_P
+  * MIC2_N
+  * MONO_OUT_P
+  * MONO_OUT_N
+  * MICBIAS1
+  * MICBIAS2
+
+Example:
+
+alc5631: alc5631@1a {
+   compatible = "realtek,alc5631";
+   reg = <0x1a>;
+};
+
+or
+
+rt5631: rt5631@1a {
+   compatible = "realtek,rt5631";
+   reg = <0x1a>;
+};
-- 
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 0/4] Arndale: Adding Sound Machine Driver for ALC5631 Codec

[Krishna Mohan Dani]

These patches add machine driver to instantiate I2S based realtek's
 ALC5631 based sound card on Arndale board.

There are other variants of Audio Daughter Cards for Arndale
Board for which support already exists but there is no support for
Realtek's alc5631 codec based card hence support for ALC5631 based
machine driver is being added.

Most of the code has been pulled from insignal's git for Arndale and
modified to suit the maintain syntax. Machine driver has been made
DT compatible.

Krishna Mohan Dani (4):
  ASoC: ALC5631/RT5631: Add device tree binding documentation
  ASoC: Samsung: Add arndale_rt5631 machine driver
  Sound: Kconfig: Adding the description of the codec
  ASoC: rt5631: Adding Device Tree compatibility to Realtek's ALC5631
codec driver

 Documentation/devicetree/bindings/sound/rt5631.txt |   48 ++
 sound/soc/codecs/Kconfig   |3 +-
 sound/soc/codecs/rt5631.c  |   11 ++
 sound/soc/samsung/Kconfig  |6 +
 sound/soc/samsung/Makefile |2 +
 sound/soc/samsung/arndale_rt5631.c |  166 
 6 files changed, 235 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/sound/rt5631.txt
 create mode 100644 sound/soc/samsung/arndale_rt5631.c

-- 
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