Re: [PATCH 14/25] drm/exynos: introduce exynos_drm_plane_config structure

2015-11-18 Thread Tobias Jakobi 
Hey Marek,


Marek Szyprowski wrote:
> Hello,
> 
> On 2015-11-17 19:00, Tobias Jakobi wrote:
>> Marek Szyprowski wrote:
>>> This patch adds common structure for keeping plane configuration and
>>> capabilities data. This patch is inspired by similar code developed by
>>> Tobias Jakobi.
>>>
>>> Signed-off-by: Marek Szyprowski 
>>> ---
>>>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 +++---
>>>   drivers/gpu/drm/exynos/exynos7_drm_decon.c| 23 +++-
>>>   drivers/gpu/drm/exynos/exynos_drm_drv.h   | 22 
>>>   drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 25 -
>>>   drivers/gpu/drm/exynos/exynos_drm_plane.c | 34 --
>>>   drivers/gpu/drm/exynos/exynos_drm_plane.h |  7 ++--
>>>   drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 25 -
>>>   drivers/gpu/drm/exynos/exynos_mixer.c | 51
>>> ---
>>>   8 files changed, 131 insertions(+), 74 deletions(-)
>>>
>> 
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 015e85cabcc9..cdec3c1827c6 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -43,7 +43,6 @@
>>> #define MIXER_WIN_NR3
>>>   #define VP_DEFAULT_WIN2
>>> -#define CURSOR_WIN1
>>> /* The pixelformats that are natively supported by the mixer. */
>>>   #define MXR_FORMAT_RGB5654
>>> @@ -112,6 +111,31 @@ struct mixer_drv_data {
>>>   boolhas_sclk;
>>>   };
>>>   +static const struct exynos_drm_plane_config
>>> plane_configs[MIXER_WIN_NR] = {
>>> +{
>>> +.zpos = 0,
>>> +.type = DRM_PLANE_TYPE_PRIMARY,
>>> +.pixel_formats = mixer_formats,
>>> +.num_pixel_formats = ARRAY_SIZE(mixer_formats),
>>> +.capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE_X |
>>> +EXYNOS_DRM_PLANE_CAP_DOUBLE_Y,
>>> +}, {
>>> +.zpos = 1,
>>> +.type = DRM_PLANE_TYPE_CURSOR,
>>> +.pixel_formats = mixer_formats,
>>> +.num_pixel_formats = ARRAY_SIZE(mixer_formats),
>>> +.capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE_X |
>>> +EXYNOS_DRM_PLANE_CAP_DOUBLE_Y,
>>> +}, {
>>> +.zpos = 2,
>>> +.type = DRM_PLANE_TYPE_OVERLAY,
>>> +.pixel_formats = vp_formats,
>>> +.num_pixel_formats = ARRAY_SIZE(vp_formats),
>>> +.capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE_X |
>>> +EXYNOS_DRM_PLANE_CAP_DOUBLE_Y,
>> As far as I know the video plane supports arbitrary scaling and provides
>> no dedicated 'pixel doubling' mode.
> 
> Right, I've forgotten that, I will update the code then. BTW, do you
> plan to
> submit your patches for Mixer, which fixes alpha blending setup?
I'll try to send a new version out this weekend. Any specific branch I
should base these on? (e.g. Inki's exynos-drm-next)

- Tobias


> 
> Best regards

--
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/3] ASoC: samsung: pass filter function as pointer

2015-11-18 Thread Mark Brown 
On Wed, Nov 18, 2015 at 03:26:41PM +0100, Arnd Bergmann wrote:
> As we are now passing the filter data as pointers to the drivers,
> we can take the final step and also pass the filter function the
> same way. I'm keeping this change separate, as there it's less
> obvious that this is a net win.

This doens't apply against current code, please check and resend.


signature.asc
Description: PGP signature

Re: [PATCH] ARM: multi_v7_defconfig: Build ChromeOS EC drivers as modules

2015-11-18 Thread Krzysztof Kozlowski 
W dniu 18.11.2015 o 00:58, Javier Martinez Canillas pisze:
> Since the multi_v7_defconfig is used to build an image for different
> platforms, the options should be enabled as module whenever possible.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> The patch was tested on an Exynos5800 Peach Pi Chromebook
> and the drivers' modules were correctly autoloaded.
> 
>  arch/arm/configs/multi_v7_defconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

I suppose this could go through Samsung-soc. I got few other patches for
multi_v7.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
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 14/25] drm/exynos: introduce exynos_drm_plane_config structure

2015-11-18 Thread Marek Szyprowski 

Hello,

On 2015-11-17 19:00, Tobias Jakobi wrote:

Marek Szyprowski wrote:

This patch adds common structure for keeping plane configuration and
capabilities data. This patch is inspired by similar code developed by
Tobias Jakobi.

Signed-off-by: Marek Szyprowski 
---
  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 +++---
  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 23 +++-
  drivers/gpu/drm/exynos/exynos_drm_drv.h   | 22 
  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 25 -
  drivers/gpu/drm/exynos/exynos_drm_plane.c | 34 --
  drivers/gpu/drm/exynos/exynos_drm_plane.h |  7 ++--
  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 25 -
  drivers/gpu/drm/exynos/exynos_mixer.c | 51 ---
  8 files changed, 131 insertions(+), 74 deletions(-)




diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 015e85cabcc9..cdec3c1827c6 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -43,7 +43,6 @@
  
  #define MIXER_WIN_NR		3

  #define VP_DEFAULT_WIN2
-#define CURSOR_WIN 1
  
  /* The pixelformats that are natively supported by the mixer. */

  #define MXR_FORMAT_RGB565 4
@@ -112,6 +111,31 @@ struct mixer_drv_data {
boolhas_sclk;
  };
  
+static const struct exynos_drm_plane_config plane_configs[MIXER_WIN_NR] = {

+   {
+   .zpos = 0,
+   .type = DRM_PLANE_TYPE_PRIMARY,
+   .pixel_formats = mixer_formats,
+   .num_pixel_formats = ARRAY_SIZE(mixer_formats),
+   .capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE_X |
+   EXYNOS_DRM_PLANE_CAP_DOUBLE_Y,
+   }, {
+   .zpos = 1,
+   .type = DRM_PLANE_TYPE_CURSOR,
+   .pixel_formats = mixer_formats,
+   .num_pixel_formats = ARRAY_SIZE(mixer_formats),
+   .capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE_X |
+   EXYNOS_DRM_PLANE_CAP_DOUBLE_Y,
+   }, {
+   .zpos = 2,
+   .type = DRM_PLANE_TYPE_OVERLAY,
+   .pixel_formats = vp_formats,
+   .num_pixel_formats = ARRAY_SIZE(vp_formats),
+   .capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE_X |
+   EXYNOS_DRM_PLANE_CAP_DOUBLE_Y,

As far as I know the video plane supports arbitrary scaling and provides
no dedicated 'pixel doubling' mode.


Right, I've forgotten that, I will update the code then. BTW, do you plan to
submit your patches for Mixer, which fixes alpha blending setup?

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

--
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 02/16 REBASED] dt-bindings: remove deprecated compatible string from exynos-hdmi

2015-11-18 Thread Krzysztof Kozlowski 
On 18.11.2015 17:33, Andrzej Hajda wrote:
> samsung,exynos5-hdmi compatible was marked as deprecated in Jun 2013.
> It was never used since then.
> 
> Signed-off-by: Andrzej Hajda 
> Reviewed-by: Gustavo Padovan 
> ---
>  Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)

Thanks, applied.

Best regards,
Krzysztof

--
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 3/3] ASoC: samsung: pass filter function as pointer

2015-11-18 Thread Arnd Bergmann 
On Wednesday 18 November 2015 11:13:18 Krzysztof Kozlowski wrote:
> 
> I also tested entire patchset on Exynos4412/Trats2 board (custom kernel
> with audio working) for regressions and it worked fine. However, since
> this was not a S3C24xx/S3C64xx board, I don't find that testing
> sufficient for a tag. So only:
> 
> Reviewed-by: Krzysztof Kozlowski 
> 

Thanks!

Mark, can you take the three patches through the ASoC tree?

Arnd
--
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] SPI: s3c64xx: pass DMA arguments in platform data

2015-11-18 Thread Arnd Bergmann 
On Wednesday 18 November 2015 13:43:27 Krzysztof Kozlowski wrote:
> On 18.11.2015 00:48, Arnd Bergmann wrote:

> >  struct platform_device s3c64xx_device_spi0 = {
> > @@ -1135,11 +1133,13 @@ void __init s3c64xx_spi0_set_platdata(int 
> > (*cfg_gpio)(void), int src_clk_nr,
> > pd.num_cs = num_cs;
> > pd.src_clk_nr = src_clk_nr;
> > pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
> > -#if defined(CONFIG_PL330_DMA)
> > -   pd.filter = pl330_filter;
> > -#elif defined(CONFIG_S3C64XX_PL080)
> 
> Hmm why removing pl330_filter? Is it because of lack of channel
> names? It looks unrelated to this patch.

You are right, it's an unrelated cleanup, I'll drop this change
and add the same lines there.

This code was only there for mach-s5p*, which is DT-only these days
and doesn't need it any more. However, there is a lot of other code
that falls in the same category, and we should clean that up in a
separate patch series.

I'm actually thinking about moving all device definitions from
plat-samsung back to mach-s3c24xx and mach-s3c64xx and then remove
all devices that are unused now. I suspect we end up with an overall
reduction in code size that way, and it will be much easier to keep
track of how things fit together.

> > -   if (!sdd->pdev->dev.of_node) {
> > -   res = platform_get_resource(pdev, IORESOURCE_DMA,  0);
> > -   if (!res) {
> > -   dev_warn(>dev, "Unable to get SPI tx dma 
> > resource. Switching to poll mode\n");
> > -   sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
> > -   } else
> > -   sdd->tx_dma.dmach = res->start;
> > -
> > -   res = platform_get_resource(pdev, IORESOURCE_DMA,  1);
> > -   if (!res) {
> > -   dev_warn(>dev, "Unable to get SPI rx dma 
> > resource. Switching to poll mode\n");
> > -   sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
> > -   } else
> > -   sdd->rx_dma.dmach = res->start;
> > +   if (sci && (!sci->dma_tx || !sci->dma_rx)) {
> 
> No need for "sci" check. It cannot be NULL at this point - at the
> beginning of probe it is checked already.
> 
> > +   dev_warn(>dev, "Unable to get SPI tx data. Switching to 
> > poll mode\n");
> 
> The message could be now more precise, like:
> "Unable to get SPI rx or tx data. Switching to poll mode\n"

Ok.

> > +   sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
> > }
> 
> The logic here is now different for DT boards. Previously such board
> would not be marked as polling. Now it is always polling. If needed,
> split it to separate patch.


I think that was a mistake on my side, thanks for finding it.

> >  
> > sdd->tx_dma.direction = DMA_MEM_TO_DEV;
> > @@ -1197,9 +1184,10 @@ static int s3c64xx_spi_probe(struct platform_device 
> > *pdev)
> >  
> > dev_dbg(>dev, "Samsung SoC SPI Driver loaded for Bus SPI-%d with 
> > %d Slaves attached\n",
> > sdd->port_id, master->num_chipselect);
> > -   dev_dbg(>dev, "\tIOmem=[%pR]\tFIFO %dbytes\tDMA=[Rx-%d, Tx-%d]\n",
> > +   dev_dbg(>dev, "\tIOmem=[%pR]\tFIFO %dbytes\tDMA=[Rx-%p, Tx-%p]\n",
> > mem_res, (FIFO_LVL_MASK(sdd) >> 1) + 1,
> > -   sdd->rx_dma.dmach, sdd->tx_dma.dmach);
> > +   sdd->cntrlr_info->dma_rx,
> > +   sdd->cntrlr_info->dma_tx);
> 
> sci->dma_rx and sci->dma_tx would be equivalent but shorter.

Ok.

Arnd
--
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 02/16 REBASED] dt-bindings: remove deprecated compatible string from exynos-hdmi

2015-11-18 Thread Andrzej Hajda 
samsung,exynos5-hdmi compatible was marked as deprecated in Jun 2013.
It was never used since then.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Gustavo Padovan 
---
 Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index 1fd8cf9..d474f59 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -2,10 +2,9 @@ Device-Tree bindings for drm hdmi driver
 
 Required properties:
 - compatible: value should be one among the following:
-   1) "samsung,exynos5-hdmi" 
-   2) "samsung,exynos4210-hdmi"
-   3) "samsung,exynos4212-hdmi"
-   4) "samsung,exynos5420-hdmi"
+   1) "samsung,exynos4210-hdmi"
+   2) "samsung,exynos4212-hdmi"
+   3) "samsung,exynos5420-hdmi"
 - reg: physical base address of the hdmi and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
-- 
1.9.1

--
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] SPI: s3c64xx: pass DMA arguments in platform data

2015-11-18 Thread Arnd Bergmann 
The s3c64xx platform data already contains a pointer to the
DMA filter function, but not to the associated data.

This simplifies the code and makes it more generic by
passing the data along with the filter function like
we do for other drivers.

Signed-off-by: Arnd Bergmann 
---
v3: leave pl330 support in place. this is not needed any more, but this
patch should not remove it. We will however need to come back to
this for multiplatform support, so a combined s3c64xx+s5p gets the
right filter function
v3: fix bug in probe function that caused the DT case to use polling mode
v2: This version is now independent of the ASoC changes.

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 07a5a6e6dcaa..b53d4ff3befb 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1105,9 +1105,7 @@ struct platform_device s3c_device_wdt = {
 #ifdef CONFIG_S3C64XX_DEV_SPI0
 static struct resource s3c64xx_spi0_resource[] = {
[0] = DEFINE_RES_MEM(S3C_PA_SPI0, SZ_256),
-   [1] = DEFINE_RES_DMA(DMACH_SPI0_TX),
-   [2] = DEFINE_RES_DMA(DMACH_SPI0_RX),
-   [3] = DEFINE_RES_IRQ(IRQ_SPI0),
+   [1] = DEFINE_RES_IRQ(IRQ_SPI0),
 };
 
 struct platform_device s3c64xx_device_spi0 = {
@@ -1135,6 +1133,8 @@ void __init s3c64xx_spi0_set_platdata(int 
(*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
+   pd.dma_tx = (void *)DMACH_SPI0_TX;
+   pd.dma_rx = (void *)DMACH_SPI0_RX;
 #if defined(CONFIG_PL330_DMA)
pd.filter = pl330_filter;
 #elif defined(CONFIG_S3C64XX_PL080)
@@ -1150,9 +1150,7 @@ void __init s3c64xx_spi0_set_platdata(int 
(*cfg_gpio)(void), int src_clk_nr,
 #ifdef CONFIG_S3C64XX_DEV_SPI1
 static struct resource s3c64xx_spi1_resource[] = {
[0] = DEFINE_RES_MEM(S3C_PA_SPI1, SZ_256),
-   [1] = DEFINE_RES_DMA(DMACH_SPI1_TX),
-   [2] = DEFINE_RES_DMA(DMACH_SPI1_RX),
-   [3] = DEFINE_RES_IRQ(IRQ_SPI1),
+   [1] = DEFINE_RES_IRQ(IRQ_SPI1),
 };
 
 struct platform_device s3c64xx_device_spi1 = {
@@ -1180,12 +1178,15 @@ void __init s3c64xx_spi1_set_platdata(int 
(*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
+   pd.dma_tx = (void *)DMACH_SPI1_TX;
+   pd.dma_rx = (void *)DMACH_SPI1_RX;
 #if defined(CONFIG_PL330_DMA)
pd.filter = pl330_filter;
 #elif defined(CONFIG_S3C64XX_PL080)
pd.filter = pl08x_filter_id;
 #endif
 
+
s3c_set_platdata(, sizeof(pd), _device_spi1);
 }
 #endif /* CONFIG_S3C64XX_DEV_SPI1 */
@@ -1193,9 +1194,7 @@ void __init s3c64xx_spi1_set_platdata(int 
(*cfg_gpio)(void), int src_clk_nr,
 #ifdef CONFIG_S3C64XX_DEV_SPI2
 static struct resource s3c64xx_spi2_resource[] = {
[0] = DEFINE_RES_MEM(S3C_PA_SPI2, SZ_256),
-   [1] = DEFINE_RES_DMA(DMACH_SPI2_TX),
-   [2] = DEFINE_RES_DMA(DMACH_SPI2_RX),
-   [3] = DEFINE_RES_IRQ(IRQ_SPI2),
+   [1] = DEFINE_RES_IRQ(IRQ_SPI2),
 };
 
 struct platform_device s3c64xx_device_spi2 = {
@@ -1223,6 +1222,8 @@ void __init s3c64xx_spi2_set_platdata(int 
(*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi2_cfg_gpio;
+   pd.dma_tx = (void *)DMACH_SPI2_TX;
+   pd.dma_rx = (void *)DMACH_SPI2_RX;
 #if defined(CONFIG_PL330_DMA)
pd.filter = pl330_filter;
 #elif defined(CONFIG_S3C64XX_PL080)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 8e86e7f6663a..b954c5444cca 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -133,7 +133,6 @@
 struct s3c64xx_spi_dma_data {
struct dma_chan *ch;
enum dma_transfer_direction direction;
-   unsigned int dmach;
 };
 
 /**
@@ -325,7 +324,7 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master 
*spi)
 
/* Acquire DMA channels */
sdd->rx_dma.ch = dma_request_slave_channel_compat(mask, filter,
-  (void *)(long)sdd->rx_dma.dmach, dev, "rx");
+  sdd->cntrlr_info->dma_rx, dev, "rx");
if (!sdd->rx_dma.ch) {
dev_err(dev, "Failed to get RX DMA channel\n");
ret = -EBUSY;
@@ -334,7 +333,7 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master 
*spi)
spi->dma_rx = sdd->rx_dma.ch;
 
sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
-  (void *)(long)sdd->tx_dma.dmach, dev, "tx");
+  sdd->cntrlr_info->dma_tx, dev, "tx");
if (!sdd->tx_dma.ch) {
dev_err(dev, "Failed to get TX DMA channel\n");
ret = -EBUSY;
@@ -1028,7 +1027,6 @@ static inline

[RESEND PATCH v2 5/6] ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi

2015-11-18 Thread Javier Martinez Canillas 
The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.

But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Alim Akhtar 
Tested-by: Alim Akhtar 
---

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 02e99dbafcfb..35cfb07dc4bb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -690,11 +690,9 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
mmc-hs200-1_8v;
cap-mmc-highspeed;
non-removable;
-   card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
-- 
2.4.3

--
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 v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common

2015-11-18 Thread Javier Martinez Canillas 
The eMMC is non-removable so mark it using the non-removable DT
property to avoid having to redetect it after a suspend/resume.

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Tomeu Vizoso 
Tested-by: Tomeu Vizoso 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Alim Akhtar 

Series-cc Alim Akhtar 
---

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 1822c502a25a..5cb33ba5e296 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -520,8 +520,7 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
-   card-detect-delay = <200>;
+   non-removable;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
-- 
2.4.3

--
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 1/3] ASoC: samsung: pass DMA channels as pointers

2015-11-18 Thread Arnd Bergmann 
ARM64 allmodconfig produces a bunch of warnings when building the
samsung ASoC code:

sound/soc/samsung/dmaengine.c: In function 'samsung_asoc_init_dma_data':
sound/soc/samsung/dmaengine.c:53:32: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
   playback_data->filter_data = (void *)playback->channel;
sound/soc/samsung/dmaengine.c:60:31: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
   capture_data->filter_data = (void *)capture->channel;

We could easily shut up the warning by adding an intermediate cast,
but there is a bigger underlying problem: The use of IORESOURCE_DMA
to pass data from platform code to device drivers is dubious to start
with, as what we really want is a pointer that can be passed into
a filter function.

Note that on s3c64xx, the pl08x DMA data is already a pointer, but
gets cast to resource_size_t so we can pass it as a resource, and it
then gets converted back to a pointer. In contrast, the data we pass
for s3c24xx is an index into a device specific table, and we artificially
convert that into a pointer for the filter function.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Krzysztof Kozlowski 
---
v2 changes:
- no longer clash with SPI patch
- don't reference platform data that might be NULL

diff --git a/arch/arm/mach-s3c64xx/dev-audio.c 
b/arch/arm/mach-s3c64xx/dev-audio.c
index ff780a8d8366..9a42736ef4ac 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -54,12 +54,12 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device 
*pdev)
 
 static struct resource s3c64xx_iis0_resource[] = {
[0] = DEFINE_RES_MEM(S3C64XX_PA_IIS0, SZ_256),
-   [1] = DEFINE_RES_DMA(DMACH_I2S0_OUT),
-   [2] = DEFINE_RES_DMA(DMACH_I2S0_IN),
 };
 
-static struct s3c_audio_pdata i2sv3_pdata = {
+static struct s3c_audio_pdata i2s0_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
+   .dma_playback = DMACH_I2S0_OUT,
+   .dma_capture = DMACH_I2S0_IN,
 };
 
 struct platform_device s3c64xx_device_iis0 = {
@@ -68,15 +68,19 @@ struct platform_device s3c64xx_device_iis0 = {
.num_resources= ARRAY_SIZE(s3c64xx_iis0_resource),
.resource = s3c64xx_iis0_resource,
.dev = {
-   .platform_data = _pdata,
+   .platform_data = _pdata,
},
 };
 EXPORT_SYMBOL(s3c64xx_device_iis0);
 
 static struct resource s3c64xx_iis1_resource[] = {
[0] = DEFINE_RES_MEM(S3C64XX_PA_IIS1, SZ_256),
-   [1] = DEFINE_RES_DMA(DMACH_I2S1_OUT),
-   [2] = DEFINE_RES_DMA(DMACH_I2S1_IN),
+};
+
+static struct s3c_audio_pdata i2s1_pdata = {
+   .cfg_gpio = s3c64xx_i2s_cfg_gpio,
+   .dma_playback = DMACH_I2S1_OUT,
+   .dma_capture = DMACH_I2S1_IN,
 };
 
 struct platform_device s3c64xx_device_iis1 = {
@@ -85,19 +89,19 @@ struct platform_device s3c64xx_device_iis1 = {
.num_resources= ARRAY_SIZE(s3c64xx_iis1_resource),
.resource = s3c64xx_iis1_resource,
.dev = {
-   .platform_data = _pdata,
+   .platform_data = _pdata,
},
 };
 EXPORT_SYMBOL(s3c64xx_device_iis1);
 
 static struct resource s3c64xx_iisv4_resource[] = {
[0] = DEFINE_RES_MEM(S3C64XX_PA_IISV4, SZ_256),
-   [1] = DEFINE_RES_DMA(DMACH_HSI_I2SV40_TX),
-   [2] = DEFINE_RES_DMA(DMACH_HSI_I2SV40_RX),
 };
 
 static struct s3c_audio_pdata i2sv4_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
+   .dma_playback = DMACH_HSI_I2SV40_TX,
+   .dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
.i2s = {
.quirks = QUIRK_PRI_6CHAN,
@@ -142,12 +146,12 @@ static int s3c64xx_pcm_cfg_gpio(struct platform_device 
*pdev)
 
 static struct resource s3c64xx_pcm0_resource[] = {
[0] = DEFINE_RES_MEM(S3C64XX_PA_PCM0, SZ_256),
-   [1] = DEFINE_RES_DMA(DMACH_PCM0_TX),
-   [2] = DEFINE_RES_DMA(DMACH_PCM0_RX),
 };
 
 static struct s3c_audio_pdata s3c_pcm0_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
+   .dma_capture = DMACH_PCM0_RX,
+   .dma_playback = DMACH_PCM0_TX,
 };
 
 struct platform_device s3c64xx_device_pcm0 = {
@@ -163,12 +167,12 @@ EXPORT_SYMBOL(s3c64xx_device_pcm0);
 
 static struct resource s3c64xx_pcm1_resource[] = {
[0] = DEFINE_RES_MEM(S3C64XX_PA_PCM1, SZ_256),
-   [1] = DEFINE_RES_DMA(DMACH_PCM1_TX),
-   [2] = DEFINE_RES_DMA(DMACH_PCM1_RX),
 };
 
 static struct s3c_audio_pdata s3c_pcm1_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
+   .dma_playback = DMACH_PCM1_TX,
+   .dma_capture = DMACH_PCM1_RX,
 };
 
 struct platform_device s3c64xx_device_pcm1 = {
@@ -196,13 +200,14 @@ static int s3c64xx_ac97_cfg_gpe(struct platform_device 
*pdev)
 
 static struct resource s3c64xx_ac97_resource[] = {
[0] = DEFINE_RES_MEM(S3C64XX_PA_AC97, SZ_256),
-   [1] = DEFINE_RES_DMA(DMACH_AC97_PCMOUT),
-   [2] = DEFINE_RES_DMA(DMACH_AC97_PCMIN),
-   [3] =

[PATCH v3 2/3] ASoC: s3c24xx-i2s: pass DMA channels as platform data

2015-11-18 Thread Arnd Bergmann 
This is a minor cleanup to make the s3c2412-i2s and s3c24xx-i2s
drivers independent of the mach/dma.h header file and to allow
removing the dependency on the specific dmaengine driver in the
next patch.

As a side not, only the s3c24xx-i2s driver seems to still be
used, while the definition of the s3c2412-i2s platform device was
removed in commit 6d259a25b56d ("ARM: SAMSUNG: use static
declaration when it is not used in other files") after it had
never been referenced since its introduction in f0fba2ad1b6b
("ASoC: multi-component - ASoC Multi-Component Support").

Apparently it should have been used by mach-jive.c, but that
never happened. My patch at this point leaves the current state
unchanged, we can decide whether to fix or delete the jive
driver and s3c2412-i2s another time.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Krzysztof Kozlowski 
---
v3 changes:
 fix typo in s3c24xx-i2s.c

v2 changes:
 check for NULL pdata

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 69fa6a194fdf..b78b4f3ea170 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -571,6 +571,11 @@ static struct resource s3c_iis_resource[] = {
[0] = DEFINE_RES_MEM(S3C24XX_PA_IIS, S3C24XX_SZ_IIS),
 };
 
+static struct s3c_audio_pdata s3c_iis_platdata = {
+   .dma_playback = (void *)DMACH_I2S_OUT,
+   .dma_capture = (void *)DMACH_I2S_IN,
+};
+
 struct platform_device s3c_device_iis = {
.name   = "s3c24xx-iis",
.id = -1,
@@ -579,6 +584,7 @@ struct platform_device s3c_device_iis = {
.dev= {
.dma_mask   = _device_dma_mask,
.coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = _iis_platdata,
}
 };
 #endif /* CONFIG_PLAT_S3C24XX */
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index 77d27c85a32a..105317f523f2 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -33,14 +33,14 @@
 #include "regs-i2s-v2.h"
 #include "s3c2412-i2s.h"
 
+#include 
+
 static struct s3c_dma_params s3c2412_i2s_pcm_stereo_out = {
-   .slave  = (void *)(uintptr_t)DMACH_I2S_OUT,
.ch_name= "tx",
.dma_size   = 4,
 };
 
 static struct s3c_dma_params s3c2412_i2s_pcm_stereo_in = {
-   .slave  = (void *)(uintptr_t)DMACH_I2S_IN,
.ch_name= "rx",
.dma_size   = 4,
 };
@@ -152,6 +152,12 @@ static int s3c2412_iis_dev_probe(struct platform_device 
*pdev)
 {
int ret = 0;
struct resource *res;
+   struct s3c_audio_pdata *pdata = dev_get_platdata(>dev);
+
+   if (!pdata) {
+   dev_err(>dev, "missing platform data");
+   return -ENXIO;
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
s3c2412_i2s.regs = devm_ioremap_resource(>dev, res);
@@ -159,7 +165,9 @@ static int s3c2412_iis_dev_probe(struct platform_device 
*pdev)
return PTR_ERR(s3c2412_i2s.regs);
 
s3c2412_i2s_pcm_stereo_out.dma_addr = res->start + S3C2412_IISTXD;
+   s3c2412_i2s_pcm_stereo_out.slave = pdata->dma_playback;
s3c2412_i2s_pcm_stereo_in.dma_addr = res->start + S3C2412_IISRXD;
+   s3c2412_i2s_pcm_stereo_in.slave = pdata->dma_capture;
 
ret = s3c_i2sv2_register_component(>dev, -1,
   _i2s_component,
diff --git a/sound/soc/samsung/s3c24xx-i2s.c b/sound/soc/samsung/s3c24xx-i2s.c
index 9da3a77ea2c7..9e6a5bc012e3 100644
--- a/sound/soc/samsung/s3c24xx-i2s.c
+++ b/sound/soc/samsung/s3c24xx-i2s.c
@@ -31,14 +31,14 @@
 #include "dma.h"
 #include "s3c24xx-i2s.h"
 
+#include 
+
 static struct s3c_dma_params s3c24xx_i2s_pcm_stereo_out = {
-   .slave  = (void *)(uintptr_t)DMACH_I2S_OUT,
.ch_name= "tx",
.dma_size   = 2,
 };
 
 static struct s3c_dma_params s3c24xx_i2s_pcm_stereo_in = {
-   .slave  = (void *)(uintptr_t)DMACH_I2S_IN,
.ch_name= "rx",
.dma_size   = 2,
 };
@@ -454,6 +454,12 @@ static int s3c24xx_iis_dev_probe(struct platform_device 
*pdev)
 {
int ret = 0;
struct resource *res;
+   struct s3c_audio_pdata *pdata = dev_get_platdata(>dev);
+
+   if (!pdata) {
+   dev_err(>dev, "missing platform data");
+   return -ENXIO;
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -465,7 +471,9 @@ static int s3c24xx_iis_dev_probe(struct platform_device 
*pdev)
return PTR_ERR(s3c24xx_i2s.regs);
 
s3c24xx_i2s_pcm_stereo_out.dma_addr = res->start + S3C2410_IISFIFO;
+   s3c24xx_i2s_pcm_stereo_out.slave = pdata->dma_playback;
s3c24xx_i2s_pcm_stereo_in.dma_addr = res->start + S3C2410_IISFIFO;
+   s3c24xx_i2s_pcm_stereo_in.slave = pdata->dma_capture;
 
ret =

[PATCH v3 2/3] ASoC: s3c24xx-i2s: pass DMA channels as platform data

2015-11-18 Thread Arnd Bergmann 
This is a minor cleanup to make the s3c2412-i2s and s3c24xx-i2s
drivers independent of the mach/dma.h header file and to allow
removing the dependency on the specific dmaengine driver in the
next patch.

As a side not, only the s3c24xx-i2s driver seems to still be
used, while the definition of the s3c2412-i2s platform device was
removed in commit 6d259a25b56d ("ARM: SAMSUNG: use static
declaration when it is not used in other files") after it had
never been referenced since its introduction in f0fba2ad1b6b
("ASoC: multi-component - ASoC Multi-Component Support").

Apparently it should have been used by mach-jive.c, but that
never happened. My patch at this point leaves the current state
unchanged, we can decide whether to fix or delete the jive
driver and s3c2412-i2s another time.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Krzysztof Kozlowski 
---
v3: fix typo in s3c24xx-i2s.c
v2: check for NULL pdata

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 9c03b0e83bd5..1c2582f4b587 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -571,6 +571,11 @@ static struct resource s3c_iis_resource[] = {
[0] = DEFINE_RES_MEM(S3C24XX_PA_IIS, S3C24XX_SZ_IIS),
 };
 
+static struct s3c_audio_pdata s3c_iis_platdata = {
+   .dma_playback = (void *)DMACH_I2S_OUT,
+   .dma_capture = (void *)DMACH_I2S_IN,
+};
+
 struct platform_device s3c_device_iis = {
.name   = "s3c24xx-iis",
.id = -1,
@@ -579,6 +584,7 @@ struct platform_device s3c_device_iis = {
.dev= {
.dma_mask   = _device_dma_mask,
.coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = _iis_platdata,
}
 };
 #endif /* CONFIG_PLAT_S3C24XX */
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index 77d27c85a32a..105317f523f2 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -33,14 +33,14 @@
 #include "regs-i2s-v2.h"
 #include "s3c2412-i2s.h"
 
+#include 
+
 static struct s3c_dma_params s3c2412_i2s_pcm_stereo_out = {
-   .slave  = (void *)(uintptr_t)DMACH_I2S_OUT,
.ch_name= "tx",
.dma_size   = 4,
 };
 
 static struct s3c_dma_params s3c2412_i2s_pcm_stereo_in = {
-   .slave  = (void *)(uintptr_t)DMACH_I2S_IN,
.ch_name= "rx",
.dma_size   = 4,
 };
@@ -152,6 +152,12 @@ static int s3c2412_iis_dev_probe(struct platform_device 
*pdev)
 {
int ret = 0;
struct resource *res;
+   struct s3c_audio_pdata *pdata = dev_get_platdata(>dev);
+
+   if (!pdata) {
+   dev_err(>dev, "missing platform data");
+   return -ENXIO;
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
s3c2412_i2s.regs = devm_ioremap_resource(>dev, res);
@@ -159,7 +165,9 @@ static int s3c2412_iis_dev_probe(struct platform_device 
*pdev)
return PTR_ERR(s3c2412_i2s.regs);
 
s3c2412_i2s_pcm_stereo_out.dma_addr = res->start + S3C2412_IISTXD;
+   s3c2412_i2s_pcm_stereo_out.slave = pdata->dma_playback;
s3c2412_i2s_pcm_stereo_in.dma_addr = res->start + S3C2412_IISRXD;
+   s3c2412_i2s_pcm_stereo_in.slave = pdata->dma_capture;
 
ret = s3c_i2sv2_register_component(>dev, -1,
   _i2s_component,
diff --git a/sound/soc/samsung/s3c24xx-i2s.c b/sound/soc/samsung/s3c24xx-i2s.c
index 9da3a77ea2c7..9e6a5bc012e3 100644
--- a/sound/soc/samsung/s3c24xx-i2s.c
+++ b/sound/soc/samsung/s3c24xx-i2s.c
@@ -31,14 +31,14 @@
 #include "dma.h"
 #include "s3c24xx-i2s.h"
 
+#include 
+
 static struct s3c_dma_params s3c24xx_i2s_pcm_stereo_out = {
-   .slave  = (void *)(uintptr_t)DMACH_I2S_OUT,
.ch_name= "tx",
.dma_size   = 2,
 };
 
 static struct s3c_dma_params s3c24xx_i2s_pcm_stereo_in = {
-   .slave  = (void *)(uintptr_t)DMACH_I2S_IN,
.ch_name= "rx",
.dma_size   = 2,
 };
@@ -454,6 +454,12 @@ static int s3c24xx_iis_dev_probe(struct platform_device 
*pdev)
 {
int ret = 0;
struct resource *res;
+   struct s3c_audio_pdata *pdata = dev_get_platdata(>dev);
+
+   if (!pdata) {
+   dev_err(>dev, "missing platform data");
+   return -ENXIO;
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -465,7 +471,9 @@ static int s3c24xx_iis_dev_probe(struct platform_device 
*pdev)
return PTR_ERR(s3c24xx_i2s.regs);
 
s3c24xx_i2s_pcm_stereo_out.dma_addr = res->start + S3C2410_IISFIFO;
+   s3c24xx_i2s_pcm_stereo_out.slave = pdata->dma_playback;
s3c24xx_i2s_pcm_stereo_in.dma_addr = res->start + S3C2410_IISFIFO;
+   s3c24xx_i2s_pcm_stereo_in.slave = pdata->dma_capture;
 
ret =

[RESEND PATCH v2 3/6] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common

2015-11-18 Thread Javier Martinez Canillas 
The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Tomeu Vizoso 
Tested-by: Tomeu Vizoso 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Alim Akhtar 
---

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408824d8..1822c502a25a 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -552,10 +552,9 @@
 _3 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
-   card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
-- 
2.4.3

--
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 v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach

2015-11-18 Thread Javier Martinez Canillas 
Hello Krzysztof and Kukjin,

This is a resend of a series posted a month ago [0] that use the correct
card detection properties in the DTS for Exynos Chromebooks but that was
never picked.

The patches have no changed, the only difference is that I'm including
all the Reviewed-by and Tested-by tags that were previously collected.

[0]: https://lkml.org/lkml/2015/10/15/640

Best regards,
Javier


Javier Martinez Canillas (6):
  ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
  ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
  ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
  ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
  ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
  ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 6 ++
 arch/arm/boot/dts/exynos5420-peach-pit.dts| 5 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
 3 files changed, 4 insertions(+), 12 deletions(-)

-- 
2.4.3

--
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 v2 1/6] ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi

2015-11-18 Thread Javier Martinez Canillas 
The Exynos5800 Peach Pi Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Alim Akhtar 
---

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43e5ac2..ca3a467a585d 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -672,10 +672,9 @@
 _1 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
-   card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
-- 
2.4.3

--
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 v2 4/6] ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi

2015-11-18 Thread Javier Martinez Canillas 
The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.

But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Alim Akhtar 
Tested-by: Alim Akhtar 
---

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index ca3a467a585d..7b018e451880 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -652,12 +652,10 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
mmc-hs200-1_8v;
mmc-hs400-1_8v;
cap-mmc-highspeed;
non-removable;
-   card-detect-delay = <200>;
clock-frequency = <8>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
-- 
2.4.3

--
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 v2 2/6] ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit

2015-11-18 Thread Javier Martinez Canillas 
The Exynos5420 Peach Pit Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Alim Akhtar 
---

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f032ed7..02e99dbafcfb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -709,10 +709,9 @@
 _1 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
-   card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
-- 
2.4.3

--
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 v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common

2015-11-18 Thread Javier Martinez Canillas 
Hello,

On 11/18/2015 10:23 AM, Javier Martinez Canillas wrote:
> The eMMC is non-removable so mark it using the non-removable DT
> property to avoid having to redetect it after a suspend/resume.
> 
> Also remove the card-detect-delay property that is not needed with
> non-removable.
> 
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Tomeu Vizoso 
> Tested-by: Tomeu Vizoso 
> Reviewed-by: Krzysztof Kozlowski 
> Reviewed-by: Alim Akhtar 
> 
> Series-cc Alim Akhtar 

Argh, sorry about this, it was a silly typo error where I forgot ':' so
patman didn't process the tag...

I guess it can be removed when applying to avoid resending the whole series.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 2/3] ASoC: s3c24xx-i2s: pass DMA channels as platform data

2015-11-18 Thread Arnd Bergmann 
On Tuesday 17 November 2015 16:54:16 Arnd Bergmann wrote:
> +#include 
> 

My randconfig test setup has now found the typo above. Resending the
fixed version.

Arnd
--
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] ASoC: samsung: pass filter function as pointer

2015-11-18 Thread Arnd Bergmann 
As we are now passing the filter data as pointers to the drivers,
we can take the final step and also pass the filter function the
same way. I'm keeping this change separate, as there it's less
obvious that this is a net win.

Upsides of this are:

- The ASoC drivers are completely independent from the DMA engine
  implementation, which simplifies the Kconfig logic and in theory
  allows the same sound drivers to be built in a kernel that supports
  different kinds of dmaengine drivers.

- Consistency with other subsystems and drivers

On the other hand, we have a few downsides:

- The s3c24xx-dma driver now needs to be built-in for the ac97 platform
  device to be instantiated on s3c2440.

- samsung_dmaengine_pcm_config cannot be marked 'const' any more
  because the filter function pointer needs to be set at runtime.
  This is safe as long we don't have multiple different DMA engines
  in thet same system at runtime, but is nonetheless ugly.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Krzysztof Kozlowski 
---
v2 changes:
  v2: avoid possibly NULL pdata

diff --git a/arch/arm/mach-s3c64xx/dev-audio.c 
b/arch/arm/mach-s3c64xx/dev-audio.c
index 9a42736ef4ac..b57783371d52 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -58,6 +58,7 @@ static struct resource s3c64xx_iis0_resource[] = {
 
 static struct s3c_audio_pdata i2s0_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_playback = DMACH_I2S0_OUT,
.dma_capture = DMACH_I2S0_IN,
 };
@@ -79,6 +80,7 @@ static struct resource s3c64xx_iis1_resource[] = {
 
 static struct s3c_audio_pdata i2s1_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_playback = DMACH_I2S1_OUT,
.dma_capture = DMACH_I2S1_IN,
 };
@@ -100,6 +102,7 @@ static struct resource s3c64xx_iisv4_resource[] = {
 
 static struct s3c_audio_pdata i2sv4_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_playback = DMACH_HSI_I2SV40_TX,
.dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
@@ -150,6 +153,7 @@ static struct resource s3c64xx_pcm0_resource[] = {
 
 static struct s3c_audio_pdata s3c_pcm0_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_capture = DMACH_PCM0_RX,
.dma_playback = DMACH_PCM0_TX,
 };
@@ -171,6 +175,7 @@ static struct resource s3c64xx_pcm1_resource[] = {
 
 static struct s3c_audio_pdata s3c_pcm1_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_playback = DMACH_PCM1_TX,
.dma_capture = DMACH_PCM1_RX,
 };
@@ -205,6 +210,7 @@ static struct resource s3c64xx_ac97_resource[] = {
 
 static struct s3c_audio_pdata s3c_ac97_pdata = {
.dma_playback = DMACH_AC97_PCMOUT,
+   .dma_filter = pl08x_filter_id,
.dma_capture = DMACH_AC97_PCMIN,
.dma_capture_mic = DMACH_AC97_MICIN,
 };
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index b78b4f3ea170..b53d4ff3befb 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -78,6 +78,9 @@ static struct resource s3c_ac97_resource[] = {
 };
 
 static struct s3c_audio_pdata s3c_ac97_pdata = {
+#ifdef CONFIG_S3C24XX_DMAC
+   .dma_filter = s3c24xx_dma_filter,
+#endif
.dma_playback = (void *)DMACH_PCM_OUT,
.dma_capture = (void *)DMACH_PCM_IN,
.dma_capture_mic = (void *)DMACH_MIC_IN,
@@ -572,6 +575,9 @@ static struct resource s3c_iis_resource[] = {
 };
 
 static struct s3c_audio_pdata s3c_iis_platdata = {
+#ifdef CONFIG_S3C24XX_DMAC
+   .dma_filter = s3c24xx_dma_filter,
+#endif
.dma_playback = (void *)DMACH_I2S_OUT,
.dma_capture = (void *)DMACH_I2S_IN,
 };
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 3a8ce67910c2..79b1390f2016 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -444,7 +444,7 @@ config STM32_DMA
  here.
 
 config S3C24XX_DMAC
-   tristate "Samsung S3C24XX DMA support"
+   bool "Samsung S3C24XX DMA support"
depends on ARCH_S3C24XX
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
diff --git a/include/linux/platform_data/asoc-s3c.h 
b/include/linux/platform_data/asoc-s3c.h
index 33f88b4479e4..15bf56ee8af7 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -13,6 +13,9 @@
  */
 #define S3C64XX_AC97_GPD  0
 #define S3C64XX_AC97_GPE  1
+
+#include 
+
 extern void s3c64xx_ac97_setup_gpio(int);
 
 struct samsung_i2s {
@@ -39,6 +42,7 @@ struct samsung_i2s {
  */
 struct s3c_audio_pdata {
int (*cfg_gpio)(struct platform_device *);
+   dma_filter_fn dma_filter;
void *dma_playback;
void *dma_capture;
void *dma_play_sec;
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index

[RESEND PATCH v3] dt-bindings: Consolidate SRAM bindings from all vendors

2015-11-18 Thread Krzysztof Kozlowski 
SRAM bindings for various SoCs, using the mmio-sram genalloc
API, are spread over different places - per SoC vendor. Since all of
these are quite similar (they depend on mmio-sram) move them to a common
place.

Suggested-by: Rob Herring 
Signed-off-by: Krzysztof Kozlowski 
Cc: Heiko Stuebner 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: Kukjin Kim 
Acked-by: Maxime Ripard 
Acked-by: Heiko Stuebner 

---

Changes since v2:
1. Update paths to sram.txt.

Changes since v1:
1. New patch. Extended suggestion from Rob.
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt  | 2 +-
 .../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt}  | 0
 .../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt}  | 2 +-
 .../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt}   | 2 +-
 Documentation/devicetree/bindings/{misc => sram}/sram.txt   | 0
 .../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt} | 2 +-
 6 files changed, 4 insertions(+), 4 deletions(-)
 rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt => 
sram/rockchip-pmu-sram.txt} (100%)
 rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt => 
sram/rockchip-smp-sram.txt} (92%)
 rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt => 
sram/samsung-sram.txt} (95%)
 rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%)
 rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt => 
sram/sunxi-sram.txt} (97%)

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt 
b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index 86302de67c2c..313dabdc14f9 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -63,7 +63,7 @@ Required properties:
 - compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
 
 The rest of the properties should follow the generic mmio-sram description
-found in ../../misc/sysram.txt
+found in ../../sram/sram.txt
 
 Each sub-node represents the reserved area for SCPI.
 
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt 
b/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt 
b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
similarity index 92%
rename from Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
index d9416fb8db6f..800701ecffca 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
+++ b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
@@ -12,7 +12,7 @@ Required sub-node properties:
 - compatible : should be "rockchip,rk3066-smp-sram"
 
 The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sram.txt
+found in Documentation/devicetree/bindings/sram/sram.txt
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt 
b/Documentation/devicetree/bindings/sram/samsung-sram.txt
similarity index 95%
rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
rename to Documentation/devicetree/bindings/sram/samsung-sram.txt
index 4a0a4f70a0ce..6bc474b2b885 100644
--- a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
+++ b/Documentation/devicetree/bindings/sram/samsung-sram.txt
@@ -15,7 +15,7 @@ Required sub-node properties:
"samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM
 
 The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sysram.txt
+found in Documentation/devicetree/bindings/sram/sram.txt
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/misc/sram.txt 
b/Documentation/devicetree/bindings/sram/sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/misc/sram.txt
rename to Documentation/devicetree/bindings/sram/sram.txt
diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt 
b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
similarity index 97%
rename from Documentation/devicetree/bindings/soc/sunxi/sram.txt
rename to Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 067698112f5f..8d5665468fe7 100644
--- a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -16,7 +16,7 @@ SRAM nodes
 --
 
 Each SRAM is described using the mmio-sram bindings documented in
-Documentation/devicetree/bindings/misc/sram.txt
+Documentation/devicetree/bindings/sram/sram.txt

Re: [PATCH v3] SPI: s3c64xx: pass DMA arguments in platform data

2015-11-18 Thread Krzysztof Kozlowski 
On 18.11.2015 23:21, Arnd Bergmann wrote:
> The s3c64xx platform data already contains a pointer to the
> DMA filter function, but not to the associated data.
> 
> This simplifies the code and makes it more generic by
> passing the data along with the filter function like
> we do for other drivers.
> 
> Signed-off-by: Arnd Bergmann 
> ---
> v3: leave pl330 support in place. this is not needed any more, but this
> patch should not remove it. We will however need to come back to
> this for multiplatform support, so a combined s3c64xx+s5p gets the
> right filter function
> v3: fix bug in probe function that caused the DT case to use polling mode
> v2: This version is now independent of the ASoC changes.
> 
> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> index 07a5a6e6dcaa..b53d4ff3befb 100644
> --- a/arch/arm/plat-samsung/devs.c
> +++ b/arch/arm/plat-samsung/devs.c
> @@ -1105,9 +1105,7 @@ struct platform_device s3c_device_wdt = {
>  #ifdef CONFIG_S3C64XX_DEV_SPI0
>  static struct resource s3c64xx_spi0_resource[] = {
>   [0] = DEFINE_RES_MEM(S3C_PA_SPI0, SZ_256),
> - [1] = DEFINE_RES_DMA(DMACH_SPI0_TX),
> - [2] = DEFINE_RES_DMA(DMACH_SPI0_RX),
> - [3] = DEFINE_RES_IRQ(IRQ_SPI0),
> + [1] = DEFINE_RES_IRQ(IRQ_SPI0),
>  };
>  
>  struct platform_device s3c64xx_device_spi0 = {
> @@ -1135,6 +1133,8 @@ void __init s3c64xx_spi0_set_platdata(int 
> (*cfg_gpio)(void), int src_clk_nr,
>   pd.num_cs = num_cs;
>   pd.src_clk_nr = src_clk_nr;
>   pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
> + pd.dma_tx = (void *)DMACH_SPI0_TX;
> + pd.dma_rx = (void *)DMACH_SPI0_RX;
>  #if defined(CONFIG_PL330_DMA)
>   pd.filter = pl330_filter;
>  #elif defined(CONFIG_S3C64XX_PL080)
> @@ -1150,9 +1150,7 @@ void __init s3c64xx_spi0_set_platdata(int 
> (*cfg_gpio)(void), int src_clk_nr,
>  #ifdef CONFIG_S3C64XX_DEV_SPI1
>  static struct resource s3c64xx_spi1_resource[] = {
>   [0] = DEFINE_RES_MEM(S3C_PA_SPI1, SZ_256),
> - [1] = DEFINE_RES_DMA(DMACH_SPI1_TX),
> - [2] = DEFINE_RES_DMA(DMACH_SPI1_RX),
> - [3] = DEFINE_RES_IRQ(IRQ_SPI1),
> + [1] = DEFINE_RES_IRQ(IRQ_SPI1),
>  };
>  
>  struct platform_device s3c64xx_device_spi1 = {
> @@ -1180,12 +1178,15 @@ void __init s3c64xx_spi1_set_platdata(int 
> (*cfg_gpio)(void), int src_clk_nr,
>   pd.num_cs = num_cs;
>   pd.src_clk_nr = src_clk_nr;
>   pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
> + pd.dma_tx = (void *)DMACH_SPI1_TX;
> + pd.dma_rx = (void *)DMACH_SPI1_RX;
>  #if defined(CONFIG_PL330_DMA)
>   pd.filter = pl330_filter;
>  #elif defined(CONFIG_S3C64XX_PL080)
>   pd.filter = pl08x_filter_id;
>  #endif
>  
> +

That empty line is not needed here.

Rest is good so with removal of this empty line:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
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/2] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

2015-11-18 Thread Krzysztof Kozlowski 
On 19.11.2015 13:23, Tomasz Figa wrote:
> Hi Krzysztof,
> 
> 2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski :
>> The ARMv8 Exynos family SoCs in Linux kernel are currently:
>>  - Exynos5433 (controlled by ARCH_EXYNOS),
>>  - Exynos7 (controlled by ARCH_EXYNOS7).
>>
>> It duplicates Kconfig symbols unnecessarily, so consolidate them into
>> one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS
>> symbol.
>>
>> The commit should not bring any visible functional change.
> 
> I think this basically matches the general recommendation for ARM64,
> so excluding the single nitpick inline and assuming that, after this
> patch, grep ARCH_EXYNOS7 gives no results:
> 
> Reviewed-by: Tomasz Figa 
> 
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  arch/arm64/Kconfig.platforms| 11 ++-
>>  arch/arm64/boot/dts/exynos/Makefile |  2 +-
>>  arch/arm64/configs/defconfig|  2 +-
>>  3 files changed, 4 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 4043c35962cc..afa19baca94e 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -13,21 +13,14 @@ config ARCH_BERLIN
>>   This enables support for Marvell Berlin SoC Family
>>
>>  config ARCH_EXYNOS
>> -   bool
>> -   help
>> - This enables support for Samsung Exynos SoC family
>> -
>> -config ARCH_EXYNOS7
>> -   bool "ARMv8 based Samsung Exynos7"
>> -   select ARCH_EXYNOS
>> +   bool "ARMv8 based Samsung Exynos SoC family"
>> select COMMON_CLK_SAMSUNG
>> select HAVE_S3C2410_WATCHDOG if WATCHDOG
>> select HAVE_S3C_RTC if RTC_CLASS
>> select PINCTRL
>> select PINCTRL_EXYNOS
>> -
>> help
>> - This enables support for Samsung Exynos7 SoC family
>> + This enables support for Samsung Exynos ARMv8 SoC family
> 
> nit: Sounds a little bit strange. Maybe "This enables support for
> ARMv8 based Samsung Exynos SoC family"?

Sure, sounds better.

Thanks for feedback!

BR,
Krzysztof

--
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: [2/2] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

2015-11-18 Thread Alim Akhtar 

Hi Krzysztof,

On 11/16/2015 07:06 AM, Krzysztof Kozlowski wrote:

The ARMv8 Exynos family SoCs in Linux kernel are currently:
  - Exynos5433 (controlled by ARCH_EXYNOS),
  - Exynos7 (controlled by ARCH_EXYNOS7).

It duplicates Kconfig symbols unnecessarily, so consolidate them into
one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS
symbol.

The commit should not bring any visible functional change.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Chanwoo Choi 
Reviewed-by: Pankaj Dubey 



Tested on exynos7-espresso board, so
Tested-by: Alim Akhtar 


---
arch/arm64/Kconfig.platforms| 11 ++-
  arch/arm64/boot/dts/exynos/Makefile |  2 +-
  arch/arm64/configs/defconfig|  2 +-
  3 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4043c35962cc..afa19baca94e 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -13,21 +13,14 @@ config ARCH_BERLIN
  This enables support for Marvell Berlin SoC Family

  config ARCH_EXYNOS
-   bool
-   help
- This enables support for Samsung Exynos SoC family
-
-config ARCH_EXYNOS7
-   bool "ARMv8 based Samsung Exynos7"
-   select ARCH_EXYNOS
+   bool "ARMv8 based Samsung Exynos SoC family"
select COMMON_CLK_SAMSUNG
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
select PINCTRL
select PINCTRL_EXYNOS
-
help
- This enables support for Samsung Exynos7 SoC family
+ This enables support for Samsung Exynos ARMv8 SoC family

  config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
diff --git a/arch/arm64/boot/dts/exynos/Makefile 
b/arch/arm64/boot/dts/exynos/Makefile
index 20310e5b6d6f..50c9b9383cfa 100644
--- a/arch/arm64/boot/dts/exynos/Makefile
+++ b/arch/arm64/boot/dts/exynos/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos7-espresso.dtb

  always:= $(dtb-y)
  subdir-y  := $(dts-dirs)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index bdd7aa358d2a..a396fa7c69a5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -33,7 +33,7 @@ CONFIG_MODULE_UNLOAD=y
  # CONFIG_IOSCHED_DEADLINE is not set
  CONFIG_ARCH_BCM_IPROC=y
  CONFIG_ARCH_BERLIN=y
-CONFIG_ARCH_EXYNOS7=y
+CONFIG_ARCH_EXYNOS=y
  CONFIG_ARCH_LAYERSCAPE=y
  CONFIG_ARCH_HISI=y
  CONFIG_ARCH_MEDIATEK=y


--
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: [1/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

2015-11-18 Thread Alim Akhtar 

Hi Krzysztof,

On 11/16/2015 07:06 AM, Krzysztof Kozlowski wrote:

Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
so it is built also on ARMv7. This does not bring any kind of benefit.
There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
multi_v7 for ARMv7).

Instead build clock drivers only for respective SoC's architecture.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Chanwoo Choi 
Acked-by: Sylwester Nawrocki 



Tested $SUBJECT patch on exynos7-espresso board, so
Tested-by: Alim Akhtar 


---
drivers/clk/samsung/Kconfig  | 13 +
  drivers/clk/samsung/Makefile |  4 ++--
  2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
index 84196ecdaa12..5f138fc4d84d 100644
--- a/drivers/clk/samsung/Kconfig
+++ b/drivers/clk/samsung/Kconfig
@@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG
bool
select COMMON_CLK

+# ARMv7 SoCs:
  config S3C2410_COMMON_CLK
bool
select COMMON_CLK_SAMSUNG
@@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK
bool
select COMMON_CLK_SAMSUNG

+# ARMv8 SoCs:
+config EXYNOS5433_COMMON_CLK
+   bool
+   depends on ARM64 || COMPILE_TEST
+   default ARCH_EXYNOS
+   select COMMON_CLK_SAMSUNG
+
+config EXYNOS7_COMMON_CLK
+   bool
+   depends on ARM64 || COMPILE_TEST
+   default ARCH_EXYNOS
+   select COMMON_CLK_SAMSUNG
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 5f6833ea355d..a31332a24ef4 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -10,11 +10,11 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o
  obj-$(CONFIG_SOC_EXYNOS5260)  += clk-exynos5260.o
  obj-$(CONFIG_SOC_EXYNOS5410)  += clk-exynos5410.o
  obj-$(CONFIG_SOC_EXYNOS5420)  += clk-exynos5420.o
-obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos5433.o
+obj-$(CONFIG_EXYNOS5433_COMMON_CLK)+= clk-exynos5433.o
  obj-$(CONFIG_SOC_EXYNOS5440)  += clk-exynos5440.o
  obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
  obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-clkout.o
-obj-$(CONFIG_ARCH_EXYNOS7) += clk-exynos7.o
+obj-$(CONFIG_EXYNOS7_COMMON_CLK)   += clk-exynos7.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


--
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/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

2015-11-18 Thread Tomasz Figa 
Hi Krzysztof,

Good idea, just a couple of nits inline. Other than that:

Acked-by: Tomasz Figa 

2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski :
> Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
> so it is built also on ARMv7. This does not bring any kind of benefit.
> There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
> multi_v7 for ARMv7).
>
> Instead build clock drivers only for respective SoC's architecture.
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/clk/samsung/Kconfig  | 13 +
>  drivers/clk/samsung/Makefile |  4 ++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
> index 84196ecdaa12..5f138fc4d84d 100644
> --- a/drivers/clk/samsung/Kconfig
> +++ b/drivers/clk/samsung/Kconfig
> @@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG
> bool
> select COMMON_CLK
>
> +# ARMv7 SoCs:

nit: I'm not aware of any recent upgrade of the S3C24xx line-up to
ARMv7 cores. ;) I'd suggest "32-bit ARM SoCs" or just "ARM SoCs"...

>  config S3C2410_COMMON_CLK
> bool
> select COMMON_CLK_SAMSUNG
> @@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK
> bool
> select COMMON_CLK_SAMSUNG
>
> +# ARMv8 SoCs:

and then here "64-bit ARM SoCs" or "ARM64 SoCs", whichever you prefer.
I'd lean towards simple "ARM" and "ARM64".

> +config EXYNOS5433_COMMON_CLK
> +   bool
> +   depends on ARM64 || COMPILE_TEST
> +   default ARCH_EXYNOS

nit: bool and default can be combined into def_bool ARCH_EXYNOS

> +   select COMMON_CLK_SAMSUNG
> +
> +config EXYNOS7_COMMON_CLK
> +   bool
> +   depends on ARM64 || COMPILE_TEST
> +   default ARCH_EXYNOS

nit: See above.

However, I don't think we can disable compilation of particular 64-bit
SoCs, so maybe there isn't much sense in splitting their clock drivers
into separate symbols?

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 2/2] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

2015-11-18 Thread Tomasz Figa 
Hi Krzysztof,

2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski :
> The ARMv8 Exynos family SoCs in Linux kernel are currently:
>  - Exynos5433 (controlled by ARCH_EXYNOS),
>  - Exynos7 (controlled by ARCH_EXYNOS7).
>
> It duplicates Kconfig symbols unnecessarily, so consolidate them into
> one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS
> symbol.
>
> The commit should not bring any visible functional change.

I think this basically matches the general recommendation for ARM64,
so excluding the single nitpick inline and assuming that, after this
patch, grep ARCH_EXYNOS7 gives no results:

Reviewed-by: Tomasz Figa 

>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm64/Kconfig.platforms| 11 ++-
>  arch/arm64/boot/dts/exynos/Makefile |  2 +-
>  arch/arm64/configs/defconfig|  2 +-
>  3 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 4043c35962cc..afa19baca94e 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -13,21 +13,14 @@ config ARCH_BERLIN
>   This enables support for Marvell Berlin SoC Family
>
>  config ARCH_EXYNOS
> -   bool
> -   help
> - This enables support for Samsung Exynos SoC family
> -
> -config ARCH_EXYNOS7
> -   bool "ARMv8 based Samsung Exynos7"
> -   select ARCH_EXYNOS
> +   bool "ARMv8 based Samsung Exynos SoC family"
> select COMMON_CLK_SAMSUNG
> select HAVE_S3C2410_WATCHDOG if WATCHDOG
> select HAVE_S3C_RTC if RTC_CLASS
> select PINCTRL
> select PINCTRL_EXYNOS
> -
> help
> - This enables support for Samsung Exynos7 SoC family
> + This enables support for Samsung Exynos ARMv8 SoC family

nit: Sounds a little bit strange. Maybe "This enables support for
ARMv8 based Samsung Exynos SoC family"?

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 1/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

2015-11-18 Thread Krzysztof Kozlowski 
On 19.11.2015 13:18, Tomasz Figa wrote:
> Hi Krzysztof,
> 
> Good idea, just a couple of nits inline. Other than that:
> 
> Acked-by: Tomasz Figa 
> 
> 2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski :
>> Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
>> so it is built also on ARMv7. This does not bring any kind of benefit.
>> There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
>> multi_v7 for ARMv7).
>>
>> Instead build clock drivers only for respective SoC's architecture.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  drivers/clk/samsung/Kconfig  | 13 +
>>  drivers/clk/samsung/Makefile |  4 ++--
>>  2 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
>> index 84196ecdaa12..5f138fc4d84d 100644
>> --- a/drivers/clk/samsung/Kconfig
>> +++ b/drivers/clk/samsung/Kconfig
>> @@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG
>> bool
>> select COMMON_CLK
>>
>> +# ARMv7 SoCs:
> 
> nit: I'm not aware of any recent upgrade of the S3C24xx line-up to
> ARMv7 cores. ;) I'd suggest "32-bit ARM SoCs" or just "ARM SoCs"...

okay

> 
>>  config S3C2410_COMMON_CLK
>> bool
>> select COMMON_CLK_SAMSUNG
>> @@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK
>> bool
>> select COMMON_CLK_SAMSUNG
>>
>> +# ARMv8 SoCs:
> 
> and then here "64-bit ARM SoCs" or "ARM64 SoCs", whichever you prefer.
> I'd lean towards simple "ARM" and "ARM64".

ARM64 sounds good.

> 
>> +config EXYNOS5433_COMMON_CLK
>> +   bool
>> +   depends on ARM64 || COMPILE_TEST
>> +   default ARCH_EXYNOS
> 
> nit: bool and default can be combined into def_bool ARCH_EXYNOS
> 

Right.

>> +   select COMMON_CLK_SAMSUNG
>> +
>> +config EXYNOS7_COMMON_CLK
>> +   bool
>> +   depends on ARM64 || COMPILE_TEST
>> +   default ARCH_EXYNOS
> 
> nit: See above.
> 
> However, I don't think we can disable compilation of particular 64-bit
> SoCs, so maybe there isn't much sense in splitting their clock drivers
> into separate symbols?

To me it does not really matter. Indeed as you said one cannot disable
building of one particular Exynos SoCs.

However we could still want not build some parts of such SoCs (like
clock, pinctrl etc). I don't see much benefit for such case except when
someone would like to drastically reduce the size of kernel image (for
whatever reasons he has.).

On the other hand having separate symbols causes duplication and
obfuscates a little the Kconfig/Makefile. I like keeping things simple
so one symbol for all ARM64 Exynos clocks sounds good.

Sylwester preferred current approach. You and Pankaj seem to prefer one
symbol-way.

Should we make a voting? :)

Best regards,
Krzysztof
--
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 3/3] ASoC: samsung: pass filter function as pointer

2015-11-18 Thread Arnd Bergmann 
As we are now passing the filter data as pointers to the drivers,
we can take the final step and also pass the filter function the
same way. I'm keeping this change separate, as there it's less
obvious that this is a net win.

Upsides of this are:

- The ASoC drivers are completely independent from the DMA engine
  implementation, which simplifies the Kconfig logic and in theory
  allows the same sound drivers to be built in a kernel that supports
  different kinds of dmaengine drivers.

- Consistency with other subsystems and drivers

On the other hand, we have a few downsides:

- The s3c24xx-dma driver now needs to be built-in for the ac97 platform
  device to be instantiated on s3c2440.

- samsung_dmaengine_pcm_config cannot be marked 'const' any more
  because the filter function pointer needs to be set at runtime.
  This is safe as long we don't have multiple different DMA engines
  in thet same system at runtime, but is nonetheless ugly.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Krzysztof Kozlowski 
---
Same patch as the previous submission that did not apply. I don't
know what went wrong, but I have rebased on top of asoc/topic/samsung
just to be sure.

diff --git a/arch/arm/mach-s3c64xx/dev-audio.c 
b/arch/arm/mach-s3c64xx/dev-audio.c
index 9a42736ef4ac..b57783371d52 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -58,6 +58,7 @@ static struct resource s3c64xx_iis0_resource[] = {
 
 static struct s3c_audio_pdata i2s0_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_playback = DMACH_I2S0_OUT,
.dma_capture = DMACH_I2S0_IN,
 };
@@ -79,6 +80,7 @@ static struct resource s3c64xx_iis1_resource[] = {
 
 static struct s3c_audio_pdata i2s1_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_playback = DMACH_I2S1_OUT,
.dma_capture = DMACH_I2S1_IN,
 };
@@ -100,6 +102,7 @@ static struct resource s3c64xx_iisv4_resource[] = {
 
 static struct s3c_audio_pdata i2sv4_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_playback = DMACH_HSI_I2SV40_TX,
.dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
@@ -150,6 +153,7 @@ static struct resource s3c64xx_pcm0_resource[] = {
 
 static struct s3c_audio_pdata s3c_pcm0_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_capture = DMACH_PCM0_RX,
.dma_playback = DMACH_PCM0_TX,
 };
@@ -171,6 +175,7 @@ static struct resource s3c64xx_pcm1_resource[] = {
 
 static struct s3c_audio_pdata s3c_pcm1_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
+   .dma_filter = pl08x_filter_id,
.dma_playback = DMACH_PCM1_TX,
.dma_capture = DMACH_PCM1_RX,
 };
@@ -205,6 +210,7 @@ static struct resource s3c64xx_ac97_resource[] = {
 
 static struct s3c_audio_pdata s3c_ac97_pdata = {
.dma_playback = DMACH_AC97_PCMOUT,
+   .dma_filter = pl08x_filter_id,
.dma_capture = DMACH_AC97_PCMIN,
.dma_capture_mic = DMACH_AC97_MICIN,
 };
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 823de7b4e53b..7263e95a6f35 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -78,6 +78,9 @@ static struct resource s3c_ac97_resource[] = {
 };
 
 static struct s3c_audio_pdata s3c_ac97_pdata = {
+#ifdef CONFIG_S3C24XX_DMAC
+   .dma_filter = s3c24xx_dma_filter,
+#endif
.dma_playback = (void *)DMACH_PCM_OUT,
.dma_capture = (void *)DMACH_PCM_IN,
.dma_capture_mic = (void *)DMACH_MIC_IN,
@@ -572,6 +575,9 @@ static struct resource s3c_iis_resource[] = {
 };
 
 static struct s3c_audio_pdata s3c_iis_platdata = {
+#ifdef CONFIG_S3C24XX_DMAC
+   .dma_filter = s3c24xx_dma_filter,
+#endif
.dma_playback = (void *)DMACH_I2S_OUT,
.dma_capture = (void *)DMACH_I2S_IN,
 };
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index e6cd1a32025a..17655d9ba518 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -432,7 +432,7 @@ config STE_DMA40
  Support for ST-Ericsson DMA40 controller
 
 config S3C24XX_DMAC
-   tristate "Samsung S3C24XX DMA support"
+   bool "Samsung S3C24XX DMA support"
depends on ARCH_S3C24XX
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
diff --git a/include/linux/platform_data/asoc-s3c.h 
b/include/linux/platform_data/asoc-s3c.h
index 33f88b4479e4..15bf56ee8af7 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -13,6 +13,9 @@
  */
 #define S3C64XX_AC97_GPD  0
 #define S3C64XX_AC97_GPE  1
+
+#include 
+
 extern void s3c64xx_ac97_setup_gpio(int);
 
 struct samsung_i2s {
@@ -39,6 +42,7 @@ struct samsung_i2s {
  */
 struct s3c_audio_pdata {
int (*cfg_gpio)(struct platform_device *);
+   dma_filter_fn dma_filter;
void *dma_playback;