Re: [PATCH RESEND 3/3] ARM: S3C24XX: add dma pdata for s3c2410, s3c2440 and s3c2442

2013-10-13 Thread Vinod Koul 
On Fri, Oct 11, 2013 at 11:01:33AM +0200, Heiko Stübner wrote:
> s3c2410 and s3c2442 share the same dma channels while s3c2440 has
> slight differences. But on all three the reachable sources per dma
> channel has constraints attached and thus encodes the usable
> combinations using the S3C24XX_DMA_CHANREQ macro.
> 
> This also fixes the warning about s3c2410_dma_resource being unused
> as reported by Olof Johansson.
Perhpas you should have used Reported-by tag for that..

~Vinod
> 
> Signed-off-by: Heiko Stuebner 
> ---
>  arch/arm/mach-s3c24xx/common.c|  100 
> +
>  arch/arm/mach-s3c24xx/common.h|2 +
>  include/linux/platform_data/dma-s3c24xx.h |3 +
>  3 files changed, 105 insertions(+)
> 
> diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
> index 16ac669..4cfe7a4 100644
> --- a/arch/arm/mach-s3c24xx/common.c
> +++ b/arch/arm/mach-s3c24xx/common.c
> @@ -343,6 +343,50 @@ static struct resource s3c2410_dma_resource[] = {
>  };
>  #endif
>  
> +#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2442)
> +static struct s3c24xx_dma_channel s3c2410_dma_channels[DMACH_MAX] = {
> + [DMACH_XD0] = { S3C24XX_DMA_AHB, true, S3C24XX_DMA_CHANREQ(0, 0), },
> + [DMACH_XD1] = { S3C24XX_DMA_AHB, true, S3C24XX_DMA_CHANREQ(0, 1), },
> + [DMACH_SDI] = { S3C24XX_DMA_APB, false, S3C24XX_DMA_CHANREQ(2, 0) |
> + S3C24XX_DMA_CHANREQ(2, 2) |
> + S3C24XX_DMA_CHANREQ(1, 3),
> + },
> + [DMACH_SPI0] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(3, 1), },
> + [DMACH_SPI1] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(2, 3), },
> + [DMACH_UART0] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(1, 0), },
> + [DMACH_UART1] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(1, 1), },
> + [DMACH_UART2] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(0, 3), },
> + [DMACH_TIMER] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(3, 0) |
> +  S3C24XX_DMA_CHANREQ(3, 2) |
> +  S3C24XX_DMA_CHANREQ(3, 3),
> + },
> + [DMACH_I2S_IN] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(2, 1) |
> +   S3C24XX_DMA_CHANREQ(1, 2),
> + },
> + [DMACH_I2S_OUT] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(0, 2), },
> + [DMACH_USB_EP1] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(4, 0), },
> + [DMACH_USB_EP2] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(4, 1), },
> + [DMACH_USB_EP3] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(4, 2), },
> + [DMACH_USB_EP4] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(4, 3), },
> +};
> +
> +static struct s3c24xx_dma_platdata s3c2410_dma_platdata = {
> + .num_phy_channels = 4,
> + .channels = s3c2410_dma_channels,
> + .num_channels = DMACH_MAX,
> +};
> +
> +struct platform_device s3c2410_device_dma = {
> + .name   = "s3c2410-dma",
> + .id = 0,
> + .num_resources  = ARRAY_SIZE(s3c2410_dma_resource),
> + .resource   = s3c2410_dma_resource,
> + .dev= {
> + .platform_data  = &s3c2410_dma_platdata,
> + },
> +};
> +#endif
> +
>  #ifdef CONFIG_CPU_S3C2412
>  static struct s3c24xx_dma_channel s3c2412_dma_channels[DMACH_MAX] = {
>   [DMACH_XD0] = { S3C24XX_DMA_AHB, true, 17 },
> @@ -384,6 +428,62 @@ struct platform_device s3c2412_device_dma = {
>  };
>  #endif
>  
> +#if defined(CONFIG_CPU_S3C2440)
> +static struct s3c24xx_dma_channel s3c2440_dma_channels[DMACH_MAX] = {
> + [DMACH_XD0] = { S3C24XX_DMA_AHB, true, S3C24XX_DMA_CHANREQ(0, 0), },
> + [DMACH_XD1] = { S3C24XX_DMA_AHB, true, S3C24XX_DMA_CHANREQ(0, 1), },
> + [DMACH_SDI] = { S3C24XX_DMA_APB, false, S3C24XX_DMA_CHANREQ(2, 0) |
> + S3C24XX_DMA_CHANREQ(6, 1) |
> + S3C24XX_DMA_CHANREQ(2, 2) |
> + S3C24XX_DMA_CHANREQ(1, 3),
> + },
> + [DMACH_SPI0] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(3, 1), },
> + [DMACH_SPI1] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(2, 3), },
> + [DMACH_UART0] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(1, 0), },
> + [DMACH_UART1] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(1, 1), },
> + [DMACH_UART2] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(0, 3), },
> + [DMACH_TIMER] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(3, 0) |
> +  S3C24XX_DMA_CHANREQ(3, 2) |
> +  S3C24XX_DMA_CHANREQ(3, 3),
> + },
> + [DMACH_I2S_IN] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(2, 1) |
> +   S3C24XX_DMA_CHANREQ(1, 2),
> + },
> + [DMACH_I2S_OUT] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(5,

Re: [PATCH RESEND 0/3] ARM: S3C24XX: add missing dma-devices and warning fix

2013-10-13 Thread Vinod Koul 
On Fri, Oct 11, 2013 at 10:59:19AM +0200, Heiko Stübner wrote:
> [I messed up the linux-arm-kernel list address yesterday, so I resend it
> with a fixed address, sorry for the noise]
> 
> When Olof reported the warning about the unused s3c2410_dma_resource, I
> thought the best way forward would be to simply implement the missing
> pieces and so it has users :-) .
> 
> Therefore this series adds the necessary platform-devices for s3c2410,
> s3c2440 and s3c2442. This especially also includes the channel-constraints
> of those socs.
> 
> As I do not have access to any of those socs these changes are of course
> compile-tested only.
Do you want this to be applied thru dma or arm tree?

~Vinod
> 
> Heiko Stuebner (3):
>   ARM: S3C24XX: Fix possible dma selection warning
>   dmaengine: s3c24xx-dma: add support for the s3c2410 type of controller
>   ARM: S3C24XX: add dma platformdata for s3c2410, s3c2440 and s3c2442
> 
>  arch/arm/mach-s3c24xx/Kconfig |3 +-
>  arch/arm/mach-s3c24xx/common.c|  100 
> +
>  arch/arm/mach-s3c24xx/common.h|2 +
>  drivers/dma/s3c24xx-dma.c |   10 +++
>  include/linux/platform_data/dma-s3c24xx.h |3 +
>  sound/soc/samsung/Kconfig |2 +-
>  6 files changed, 118 insertions(+), 2 deletions(-)
> 
> -- 
> 1.7.10.4
> 

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

Re: [PATCH RESEND 0/3] ARM: S3C24XX: add missing dma-devices and warning fix

2013-10-13 Thread Heiko Stübner 
Am Sonntag, 13. Oktober 2013, 16:56:42 schrieb Vinod Koul:
> On Fri, Oct 11, 2013 at 10:59:19AM +0200, Heiko Stübner wrote:
> > [I messed up the linux-arm-kernel list address yesterday, so I resend it
> > with a fixed address, sorry for the noise]
> > 
> > When Olof reported the warning about the unused s3c2410_dma_resource, I
> > thought the best way forward would be to simply implement the missing
> > pieces and so it has users :-) .
> > 
> > Therefore this series adds the necessary platform-devices for s3c2410,
> > s3c2440 and s3c2442. This especially also includes the
> > channel-constraints of those socs.
> > 
> > As I do not have access to any of those socs these changes are of course
> > compile-tested only.
> 
> Do you want this to be applied thru dma or arm tree?

hmm, the original series went into the samsung tree for 3.13, so maybe this 
addition should go the same way?


Heiko


> ~Vinod
> 
> > Heiko Stuebner (3):
> >   ARM: S3C24XX: Fix possible dma selection warning
> >   dmaengine: s3c24xx-dma: add support for the s3c2410 type of controller
> >   ARM: S3C24XX: add dma platformdata for s3c2410, s3c2440 and s3c2442
> >  
> >  arch/arm/mach-s3c24xx/Kconfig |3 +-
> >  arch/arm/mach-s3c24xx/common.c|  100
> >  + arch/arm/mach-s3c24xx/common.h   
> >  |2 +
> >  drivers/dma/s3c24xx-dma.c |   10 +++
> >  include/linux/platform_data/dma-s3c24xx.h |3 +
> >  sound/soc/samsung/Kconfig |2 +-
> >  6 files changed, 118 insertions(+), 2 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 RESEND 3/3] ARM: S3C24XX: add dma pdata for s3c2410, s3c2440 and s3c2442

2013-10-13 Thread Heiko Stübner 
Am Sonntag, 13. Oktober 2013, 16:55:37 schrieb Vinod Koul:
> On Fri, Oct 11, 2013 at 11:01:33AM +0200, Heiko Stübner wrote:
> > s3c2410 and s3c2442 share the same dma channels while s3c2440 has
> > slight differences. But on all three the reachable sources per dma
> > channel has constraints attached and thus encodes the usable
> > combinations using the S3C24XX_DMA_CHANREQ macro.
> > 
> > This also fixes the warning about s3c2410_dma_resource being unused
> > as reported by Olof Johansson.
> 
> Perhpas you should have used Reported-by tag for that..

yep, I should've, if I hadn't forgotten.


Maybe Kgene, who will most likely apply the patches, can add a

Reported-by: Olof Johansson 

at the time.



> 
> ~Vinod
> 
> > Signed-off-by: Heiko Stuebner 
> > ---
> > 
> >  arch/arm/mach-s3c24xx/common.c|  100
> >  + arch/arm/mach-s3c24xx/common.h   
> >  |2 +
> >  include/linux/platform_data/dma-s3c24xx.h |3 +
> >  3 files changed, 105 insertions(+)
> > 
> > diff --git a/arch/arm/mach-s3c24xx/common.c
> > b/arch/arm/mach-s3c24xx/common.c index 16ac669..4cfe7a4 100644
> > --- a/arch/arm/mach-s3c24xx/common.c
> > +++ b/arch/arm/mach-s3c24xx/common.c
> > @@ -343,6 +343,50 @@ static struct resource s3c2410_dma_resource[] = {
> > 
> >  };
> >  #endif
> > 
> > +#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2442)
> > +static struct s3c24xx_dma_channel s3c2410_dma_channels[DMACH_MAX] = {
> > +   [DMACH_XD0] = { S3C24XX_DMA_AHB, true, S3C24XX_DMA_CHANREQ(0, 0), },
> > +   [DMACH_XD1] = { S3C24XX_DMA_AHB, true, S3C24XX_DMA_CHANREQ(0, 1), },
> > +   [DMACH_SDI] = { S3C24XX_DMA_APB, false, S3C24XX_DMA_CHANREQ(2, 0) |
> > +   S3C24XX_DMA_CHANREQ(2, 2) |
> > +   S3C24XX_DMA_CHANREQ(1, 3),
> > +   },
> > +   [DMACH_SPI0] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(3, 1), },
> > +   [DMACH_SPI1] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(2, 3), },
> > +   [DMACH_UART0] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(1, 0), 
},
> > +   [DMACH_UART1] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(1, 1), 
},
> > +   [DMACH_UART2] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(0, 3), 
},
> > +   [DMACH_TIMER] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(3, 0) |
> > +S3C24XX_DMA_CHANREQ(3, 2) |
> > +S3C24XX_DMA_CHANREQ(3, 3),
> > +   },
> > +   [DMACH_I2S_IN] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(2, 1) |
> > + S3C24XX_DMA_CHANREQ(1, 2),
> > +   },
> > +   [DMACH_I2S_OUT] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(0, 2),
> > }, +[DMACH_USB_EP1] = { S3C24XX_DMA_APB, true, 
> > S3C24XX_DMA_CHANREQ(4,
> > 0), }, +[DMACH_USB_EP2] = { S3C24XX_DMA_APB, true,
> > S3C24XX_DMA_CHANREQ(4, 1), }, + [DMACH_USB_EP3] = { S3C24XX_DMA_APB,
> > true, S3C24XX_DMA_CHANREQ(4, 2), }, +   [DMACH_USB_EP4] = {
> > S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(4, 3), }, +};
> > +
> > +static struct s3c24xx_dma_platdata s3c2410_dma_platdata = {
> > +   .num_phy_channels = 4,
> > +   .channels = s3c2410_dma_channels,
> > +   .num_channels = DMACH_MAX,
> > +};
> > +
> > +struct platform_device s3c2410_device_dma = {
> > +   .name   = "s3c2410-dma",
> > +   .id = 0,
> > +   .num_resources  = ARRAY_SIZE(s3c2410_dma_resource),
> > +   .resource   = s3c2410_dma_resource,
> > +   .dev= {
> > +   .platform_data  = &s3c2410_dma_platdata,
> > +   },
> > +};
> > +#endif
> > +
> > 
> >  #ifdef CONFIG_CPU_S3C2412
> >  static struct s3c24xx_dma_channel s3c2412_dma_channels[DMACH_MAX] = {
> >  
> > [DMACH_XD0] = { S3C24XX_DMA_AHB, true, 17 },
> > 
> > @@ -384,6 +428,62 @@ struct platform_device s3c2412_device_dma = {
> > 
> >  };
> >  #endif
> > 
> > +#if defined(CONFIG_CPU_S3C2440)
> > +static struct s3c24xx_dma_channel s3c2440_dma_channels[DMACH_MAX] = {
> > +   [DMACH_XD0] = { S3C24XX_DMA_AHB, true, S3C24XX_DMA_CHANREQ(0, 0), },
> > +   [DMACH_XD1] = { S3C24XX_DMA_AHB, true, S3C24XX_DMA_CHANREQ(0, 1), },
> > +   [DMACH_SDI] = { S3C24XX_DMA_APB, false, S3C24XX_DMA_CHANREQ(2, 0) |
> > +   S3C24XX_DMA_CHANREQ(6, 1) |
> > +   S3C24XX_DMA_CHANREQ(2, 2) |
> > +   S3C24XX_DMA_CHANREQ(1, 3),
> > +   },
> > +   [DMACH_SPI0] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(3, 1), },
> > +   [DMACH_SPI1] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(2, 3), },
> > +   [DMACH_UART0] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(1, 0), 
},
> > +   [DMACH_UART1] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(1, 1), 
},
> > +   [DMACH_UART2] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(0, 3), 
},
> > +   [DMACH_TIMER] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(3, 0) |
> > +

Re: [PATCH RESEND 0/3] ARM: S3C24XX: add missing dma-devices and warning fix

2013-10-13 Thread Tomasz Figa 
On Saturday 12 of October 2013 13:33:29 Mark Brown wrote:
> On Sat, Oct 12, 2013 at 06:36:36AM +0200, Tomasz Figa wrote:
> > Big thanks for this series and the one adding DMA engine support for
> > S3C24xx. It would be great if someone could test this on affected
> > platforms, so we could finally drop the old S3C-DMA nonsense.
> 
> Did the s3c64xx pl08x stuff get merged?

Most of. All the patches for the amba-pl08x driver got merged. Just the 
platform glue remains. I will rebase and send respective patches this 
week.

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

[GIT PULL] Samsung fixes-1 for v3.12

2013-10-13 Thread Kukjin Kim 

The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:

  Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/samsung-fixes-1


for you to fetch changes up to b7f8c479e112cc09422aac2bda923a86b381fcc0:

  ARM: dts: fix PL330 MDMA1 address in DT for Universal C210 board 
(2013-10-08 07:09:52 +0900)



Fixes for v3.12
- fix UART for switching FIFO
- correct typo 'samsung,pin-drv'
- correct typo 'earlyprintk'
- remove DP PHY for supporting dptx-phy on exynos5250
- cpufreq regulator lookup for exynos4210-origen and trats
- fix PL330 MDMA1 address for universal c210 board


Al Stone (1):
  ARM: dts: Correct typo in use of samsung,pin-drv for exynos5250

Alexander Shiyan (1):
  ARM: SAMSUNG: Fix switching FIFO in arch_enable_uart_fifo function

Bartlomiej Zolnierkiewicz (1):
  ARM: dts: fix PL330 MDMA1 address in DT for Universal C210 board

Jingoo Han (1):
  ARM: dts: Remove DP PHY node from exynos5250.dtsi

Tomasz Figa (1):
  ARM: dts: Work around lack of cpufreq regulator lookup for 
exynos4210-origen and trats boards


Youngmin Nam (1):
  ARM: dts: Fix a typo on Exynos5440 DTS files

 arch/arm/boot/dts/exynos4210-origen.dts |  7 +++-
 arch/arm/boot/dts/exynos4210-trats.dts  |  7 +++-
 arch/arm/boot/dts/exynos4210-universal_c210.dts |  4 +++
 arch/arm/boot/dts/exynos5250-pinctrl.dtsi   | 44 
-

 arch/arm/boot/dts/exynos5250.dtsi   | 13 +++-
 arch/arm/boot/dts/exynos5440-sd5v1.dts  |  2 +-
 arch/arm/boot/dts/exynos5440-ssdk5440.dts   |  2 +-
 arch/arm/plat-samsung/include/plat/uncompress.h |  2 ++
 8 files changed, 47 insertions(+), 34 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: [GIT PULL] Samsung fixes-1 for v3.12

2013-10-13 Thread Olof Johansson 
Hi,

On Sun, Oct 13, 2013 at 2:56 PM, Kukjin Kim  wrote:
> Alexander Shiyan (1):
>   ARM: SAMSUNG: Fix switching FIFO in arch_enable_uart_fifo function

What's the regression that this is fixing? As far as I can tell, the
code has been the same since 2008. Or did something surrounding it
change?

>
> Bartlomiej Zolnierkiewicz (1):
>   ARM: dts: fix PL330 MDMA1 address in DT for Universal C210 board
>
> Jingoo Han (1):
>   ARM: dts: Remove DP PHY node from exynos5250.dtsi

You are sending this in pretty late. Please be careful about conflicts
due to this late revert, in particular if you plan on re-introducing
something in 3.13.

> Tomasz Figa (1):
>   ARM: dts: Work around lack of cpufreq regulator lookup for
> exynos4210-origen and trats boards
>
> Youngmin Nam (1):
>   ARM: dts: Fix a typo on Exynos5440 DTS files

This is a bad patch subject, it can be way more specific. Also, this
is a good reason not to have these elaborate bootargs in the DTS, in
particular for modern platforms -- the bootargs should come from
firmware for your platform.


-Olof
--
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] USB: ohci-exynos: Remove non-DT support

2013-10-13 Thread Jingoo Han 
The non-DT for EXYNOS SoCs is not supported from v3.11.
Thus, there is no need to support non-DT for Exynos OHCI driver.

The 'include/linux/platform_data/usb-ohci-exynos.h' file has been
used for non-DT support. Thus, the 'usb-ohci-exynos.h' file can
be removed.

Signed-off-by: Jingoo Han 
---
- re-based against the latest 'usb-next' branch.

 drivers/usb/host/ohci-exynos.c|   18 +++---
 include/linux/platform_data/usb-ohci-exynos.h |   21 -
 2 files changed, 3 insertions(+), 36 deletions(-)
 delete mode 100644 include/linux/platform_data/usb-ohci-exynos.h

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 122e52e..aa50e18 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -38,7 +37,6 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
-   struct exynos4_ohci_platdata *pdata;
 };
 
 static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -48,8 +46,6 @@ static void exynos_ohci_phy_enable(struct platform_device 
*pdev)
 
if (exynos_ohci->phy)
usb_phy_init(exynos_ohci->phy);
-   else if (exynos_ohci->pdata && exynos_ohci->pdata->phy_init)
-   exynos_ohci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
 }
 
 static void exynos_ohci_phy_disable(struct platform_device *pdev)
@@ -59,13 +55,10 @@ static void exynos_ohci_phy_disable(struct platform_device 
*pdev)
 
if (exynos_ohci->phy)
usb_phy_shutdown(exynos_ohci->phy);
-   else if (exynos_ohci->pdata && exynos_ohci->pdata->phy_exit)
-   exynos_ohci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
 }
 
 static int exynos_ohci_probe(struct platform_device *pdev)
 {
-   struct exynos4_ohci_platdata *pdata = dev_get_platdata(&pdev->dev);
struct exynos_ohci_hcd *exynos_ohci;
struct usb_hcd *hcd;
struct resource *res;
@@ -98,14 +91,9 @@ static int exynos_ohci_probe(struct platform_device *pdev)
 
phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
if (IS_ERR(phy)) {
-   /* Fallback to pdata */
-   if (!pdata) {
-   usb_put_hcd(hcd);
-   dev_warn(&pdev->dev, "no platform data or transceiver 
defined\n");
-   return -EPROBE_DEFER;
-   } else {
-   exynos_ohci->pdata = pdata;
-   }
+   usb_put_hcd(hcd);
+   dev_warn(&pdev->dev, "no platform data or transceiver 
defined\n");
+   return -EPROBE_DEFER;
} else {
exynos_ohci->phy = phy;
exynos_ohci->otg = phy->otg;
diff --git a/include/linux/platform_data/usb-ohci-exynos.h 
b/include/linux/platform_data/usb-ohci-exynos.h
deleted file mode 100644
index c256c59..000
--- a/include/linux/platform_data/usb-ohci-exynos.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Copyright (C) 2011 Samsung Electronics Co.Ltd
- * http://www.samsung.com/
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- */
-
-#ifndef __MACH_EXYNOS_OHCI_H
-#define __MACH_EXYNOS_OHCI_H
-
-struct exynos4_ohci_platdata {
-   int (*phy_init)(struct platform_device *pdev, int type);
-   int (*phy_exit)(struct platform_device *pdev, int type);
-};
-
-extern void exynos4_ohci_set_platdata(struct exynos4_ohci_platdata *pd);
-
-#endif /* __MACH_EXYNOS_OHCI_H */
-- 
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: [GIT PULL] Samsung fixes-1 for v3.12

2013-10-13 Thread Kukjin Kim 
Olof Johansson wrote:
> 
> Hi,
> 
Hi,

> On Sun, Oct 13, 2013 at 2:56 PM, Kukjin Kim  wrote:
> > Alexander Shiyan (1):
> >   ARM: SAMSUNG: Fix switching FIFO in arch_enable_uart_fifo function
> 
> What's the regression that this is fixing? As far as I can tell, the
> code has been the same since 2008. Or did something surrounding it
> change?
> 
Yeah, you're right. Actually I has queued it into non-critical before but
missed to sent out. OK, I agree with you and let me sort out again.

> >
> > Bartlomiej Zolnierkiewicz (1):
> >   ARM: dts: fix PL330 MDMA1 address in DT for Universal C210 board
> >
> > Jingoo Han (1):
> >   ARM: dts: Remove DP PHY node from exynos5250.dtsi
> 
> You are sending this in pretty late. Please be careful about conflicts
> due to this late revert, in particular if you plan on re-introducing
> something in 3.13.
> 
As you know, unfortunately, DP PHY node change applied in DTS without
changing driver in 3.12 so current 3.12 kernel cannot support it. I want
3.12 kernel to support it properly and yes, I have a plan to re-introduce DP
PHY node in 3.13. BTW if you have objection, maybe I will send it to stable
3.12 instead...

> > Tomasz Figa (1):
> >   ARM: dts: Work around lack of cpufreq regulator lookup for
> > exynos4210-origen and trats boards
> >
> > Youngmin Nam (1):
> >   ARM: dts: Fix a typo on Exynos5440 DTS files
> 
> This is a bad patch subject, it can be way more specific. Also, this
> is a good reason not to have these elaborate bootargs in the DTS, in
> particular for modern platforms -- the bootargs should come from
> firmware for your platform.
> 
Agreed. The subject should be clear...Anyway current bootargs in DTS is
wrong so I think, it should be fixed, I agree with you about bootargs
though.

Thanks,
Kukjin

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

Re: [PATCH] ARM: SAMSUNG: remove IRQF_DISABLED

2013-10-13 Thread Jingoo Han 
On Saturday, October 12, 2013 12:36 PM, Michael Opdenacker wrote:
> 
> This patch proposes to remove the use of the IRQF_DISABLED flag
> 
> It's a NOOP since 2.6.35 and it will be removed one day.
> 
> Signed-off-by: Michael Opdenacker 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  arch/arm/mach-s3c24xx/dma.c | 2 +-
>  arch/arm/mach-s3c24xx/simtec-usb.c  | 3 +--
>  arch/arm/mach-s3c64xx/mach-smartq.c | 2 +-
>  3 files changed, 3 insertions(+), 4 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] s5p-jpeg: fix uninitialized use in hdr parse

2013-10-13 Thread Seung-Woo Kim 
Hi Sylwester,

Thanks for you comment.

On 2013년 10월 12일 18:39, Sylwester Nawrocki wrote:
> Hi Seung-Woo,
> 
> On 10/10/2013 09:06 AM, Seung-Woo Kim wrote:
>> For hdr parse error, it can return false without any assignments
>> which cause build warning.
>>
>> Signed-off-by: Seung-Woo Kim
>> ---
>>   drivers/media/platform/s5p-jpeg/jpeg-core.c |4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
>> b/drivers/media/platform/s5p-jpeg/jpeg-core.c
>> index 15d2396..7db374e 100644
>> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
>> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
>> @@ -442,14 +442,14 @@ static bool s5p_jpeg_parse_hdr(struct
>> s5p_jpeg_q_data *result,
>>   while (notfound) {
>>   c = get_byte(&jpeg_buffer);
>>   if (c == -1)
>> -break;
>> +return false;
> 
> notfound is being assigned before entering the while loop, so I'm not sure
> what exactly is not correct here. Can you quote the original build
> warning ?

Here is the build warning.

drivers/media/platform/s5p-jpeg/jpeg-core.c: In function
's5p_jpeg_parse_hdr':
drivers/media/platform/s5p-jpeg/jpeg-core.c:432: warning: 'components'
may be used uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'height' may
be used uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'width' may be
used uninitialized in this function

> It's a good idea to always include compiler errors/warnings in the commit
> message.

Right, I'll repost with warning message.

> 
> BTW, name of the variable is a bit confusing, I think naming it 'found' and
> using negation of it would be easier to follow; that's not something we'd
> be changing now though.
> 
>>   if (c != 0xff)
>>   continue;
>>   do
>>   c = get_byte(&jpeg_buffer);
>>   while (c == 0xff);
>>   if (c == -1)
>> -break;
>> +return false;
>>   if (c == 0)
>>   continue;
>>   length = 0;
> 
> Thanks,
> Sylwester
> 

-- 
Seung-Woo Kim
Samsung Software R&D Center
--

--
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] s5p-jpeg: fix uninitialized use in hdr parse

2013-10-13 Thread Seung-Woo Kim 
For hdr parse error, it can return false without any assignments
which cause following build warning.

drivers/media/platform/s5p-jpeg/jpeg-core.c: In function 's5p_jpeg_parse_hdr':
drivers/media/platform/s5p-jpeg/jpeg-core.c:432: warning: 'components' may be 
used uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'height' may be used 
uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'width' may be used 
uninitialized in this function

Signed-off-by: Seung-Woo Kim 
---
change from v1
- add build warning to commit message
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 15d2396..7db374e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -442,14 +442,14 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data 
*result,
while (notfound) {
c = get_byte(&jpeg_buffer);
if (c == -1)
-   break;
+   return false;
if (c != 0xff)
continue;
do
c = get_byte(&jpeg_buffer);
while (c == 0xff);
if (c == -1)
-   break;
+   return false;
if (c == 0)
continue;
length = 0;
-- 
1.7.4.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] max17042_battery: use SIMPLE_DEV_PM_OPS

2013-10-13 Thread Manish Badarkhe 
Use the SIMPLE_DEV_PM_OPS macro to declare the driver's
pm_ops.

Signed-off-by: Manish Badarkhe 
---
:100644 100644 d664ef5... bd72b0f... M  drivers/power/max17042_battery.c
 drivers/power/max17042_battery.c |   16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/power/max17042_battery.c b/drivers/power/max17042_battery.c
index d664ef5..bd72b0f 100644
--- a/drivers/power/max17042_battery.c
+++ b/drivers/power/max17042_battery.c
@@ -786,7 +786,7 @@ static int max17042_remove(struct i2c_client *client)
return 0;
 }
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 static int max17042_suspend(struct device *dev)
 {
struct max17042_chip *chip = dev_get_drvdata(dev);
@@ -816,17 +816,11 @@ static int max17042_resume(struct device *dev)
 
return 0;
 }
-
-static const struct dev_pm_ops max17042_pm_ops = {
-   .suspend= max17042_suspend,
-   .resume = max17042_resume,
-};
-
-#define MAX17042_PM_OPS (&max17042_pm_ops)
-#else
-#define MAX17042_PM_OPS NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(max17042_pm_ops, max17042_suspend,
+   max17042_resume);
+
 #ifdef CONFIG_OF
 static const struct of_device_id max17042_dt_match[] = {
{ .compatible = "maxim,max17042" },
@@ -849,7 +843,7 @@ static struct i2c_driver max17042_i2c_driver = {
.driver = {
.name   = "max17042",
.of_match_table = of_match_ptr(max17042_dt_match),
-   .pm = MAX17042_PM_OPS,
+   .pm = &max17042_pm_ops,
},
.probe  = max17042_probe,
.remove = max17042_remove,
-- 
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 0/5] thermal: exynos: Fixes for v3.12

2013-10-13 Thread Lukasz Majewski 
Hi Zhang, Eduardo,

> This patch series is divided into two parts:
> 1. Device tree node definition and enabelement for TMU at Exynos4412
> (Trats2) 2. Exynos thermal subsystem regressions for v3.12-rc4.
> Several commits were necessary to properly fix regression for TMU
> test MUX address setting after reset.
> 
> Test HW:
> - Exynos4412 - TRATS2 board (Linux v3.12-rc4)
> SHA1: 8b5ede69d24db939f52b47e2f6fe1e83e08b
> 
> 
> Lukasz Majewski (5):
>   thermal: exynos: Remove check for thermal device pointer at
> exynos_report_trigger()
>   thermal: exynos: Provide separate TMU data for Exynos4412
>   thermal: exynos: Provide initial setting for TMU's test MUX address
> at Exynos4412
>   ARM: dts: exynos4x12: Device tree node definition for TMU on
> Exynos4x12
>   ARM: dts: exynos4412-trats2: Enable TMU support at Trats2
> 

Zhang, Eduardo - any comments?

Would it be possible to add them to v3.12 since they do fix critical
error and regression on Exynos4412.


>  arch/arm/boot/dts/exynos4412-trats2.dts |5 
>  arch/arm/boot/dts/exynos4x12.dtsi   |   10 
>  drivers/thermal/samsung/exynos_thermal_common.c |2 --
>  drivers/thermal/samsung/exynos_tmu.c|   12 ++---
>  drivers/thermal/samsung/exynos_tmu.h|7 +-
>  drivers/thermal/samsung/exynos_tmu_data.c   |   30
> ++-
> drivers/thermal/samsung/exynos_tmu_data.h   |   13 +- 7
> files changed, 65 insertions(+), 14 deletions(-)
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 0/5] thermal: exynos: Fixes for v3.12

2013-10-13 Thread Zhang, Rui 
Eduardo,

What's your opinion on this patch set?
BTW, please send me all the urgent fixes for thermal soc drivers that you think 
should go to 3.12.

Thanks,
rui
> -Original Message-
> From: Lukasz Majewski [mailto:l.majew...@samsung.com]
> Sent: Monday, October 14, 2013 1:47 PM
> To: Zhang, Rui; Eduardo Valentin; kgene@samsung.com
> Cc: Lukasz Majewski; Linux PM list; Lukasz Majewski; linux-kernel;
> Bartlomiej Zolnierkiewicz; devicet...@vger.kernel.org; Amit Daniel
> Kachhap; linux-samsung-soc@vger.kernel.org
> Subject: Re: [PATCH v2 0/5] thermal: exynos: Fixes for v3.12
> Importance: High
> 
> Hi Zhang, Eduardo,
> 
> > This patch series is divided into two parts:
> > 1. Device tree node definition and enabelement for TMU at Exynos4412
> > (Trats2) 2. Exynos thermal subsystem regressions for v3.12-rc4.
> > Several commits were necessary to properly fix regression for TMU
> test
> > MUX address setting after reset.
> >
> > Test HW:
> > - Exynos4412 - TRATS2 board (Linux v3.12-rc4)
> > SHA1: 8b5ede69d24db939f52b47e2f6fe1e83e08b
> >
> >
> > Lukasz Majewski (5):
> >   thermal: exynos: Remove check for thermal device pointer at
> > exynos_report_trigger()
> >   thermal: exynos: Provide separate TMU data for Exynos4412
> >   thermal: exynos: Provide initial setting for TMU's test MUX address
> > at Exynos4412
> >   ARM: dts: exynos4x12: Device tree node definition for TMU on
> > Exynos4x12
> >   ARM: dts: exynos4412-trats2: Enable TMU support at Trats2
> >
> 
> Zhang, Eduardo - any comments?
> 
> Would it be possible to add them to v3.12 since they do fix critical
> error and regression on Exynos4412.
> 
> 
> >  arch/arm/boot/dts/exynos4412-trats2.dts |5 
> >  arch/arm/boot/dts/exynos4x12.dtsi   |   10 
> >  drivers/thermal/samsung/exynos_thermal_common.c |2 --
> >  drivers/thermal/samsung/exynos_tmu.c|   12 ++---
> >  drivers/thermal/samsung/exynos_tmu.h|7 +-
> >  drivers/thermal/samsung/exynos_tmu_data.c   |   30
> > ++-
> > drivers/thermal/samsung/exynos_tmu_data.h   |   13 +- 7
> > files changed, 65 insertions(+), 14 deletions(-)
> >
> 
> 
> 
> --
> Best regards,
> 
> Lukasz Majewski
> 
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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