RE: [PATCH] ARM: EXYNOS: Add USB OHCI support to ORIGEN board
Jingoo Han wrote:
>
> Hi, Tushar.
>
> Tushar Behera wrote:
> > -Original Message-
> > Subject: [PATCH] ARM: EXYNOS: Add USB OHCI support to ORIGEN board
> >
> > Signed-off-by: Tushar Behera
> > Signed-off-by: Angus Ainslie
>
> Acked-by: Jingoo Han
>
OK, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> Thanks.
>
> Best regards,
> Jingoo Han
> > ---
> >
> > This patch are based Kukjin's for-next branch and OHCI related
> > patches from Jingoo Han.
> > [PATCH v2 0/3] Support Samsung Exynos OHCI device and driver
> >
> > arch/arm/mach-exynos/Kconfig |1 +
> > arch/arm/mach-exynos/mach-origen.c | 13 +
> > 2 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> > index bd1bb9f1..0da2ced 100644
> > --- a/arch/arm/mach-exynos/Kconfig
> > +++ b/arch/arm/mach-exynos/Kconfig
> > @@ -304,6 +304,7 @@ config MACH_ORIGEN
> > select SAMSUNG_DEV_PWM
> > select EXYNOS4_DEV_DMA
> > select EXYNOS4_DEV_PD
> > + select EXYNOS4_DEV_USB_OHCI
> > select EXYNOS4_SETUP_FIMD0
> > select EXYNOS4_SETUP_SDHCI
> > select EXYNOS4_SETUP_USB_PHY
> > diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-
> exynos/mach-origen.c
> > index f56d027..a0116036 100644
> > --- a/arch/arm/mach-exynos/mach-origen.c
> > +++ b/arch/arm/mach-exynos/mach-origen.c
> > @@ -42,6 +42,7 @@
> > #include
> > #include
> >
> > +#include
> > #include
> >
> > /* Following are default values for UCON, ULCON and UFCON UART
> registers */
> > @@ -487,6 +488,16 @@ static void __init origen_ehci_init(void)
> > s5p_ehci_set_platdata(pdata);
> > }
> >
> > +/* USB OHCI */
> > +static struct exynos4_ohci_platdata origen_ohci_pdata;
> > +
> > +static void __init origen_ohci_init(void)
> > +{
> > + struct exynos4_ohci_platdata *pdata = &origen_ohci_pdata;
> > +
> > + exynos4_ohci_set_platdata(pdata);
> > +}
> > +
> > static struct gpio_keys_button origen_gpio_keys_table[] = {
> > {
> > .code = KEY_MENU,
> > @@ -627,6 +638,7 @@ static struct platform_device *origen_devices[]
> __initdata = {
> > &s5p_device_mfc_l,
> > &s5p_device_mfc_r,
> > &s5p_device_mixer,
> > + &exynos4_device_ohci,
> > &exynos4_device_pd[PD_LCD0],
> > &exynos4_device_pd[PD_TV],
> > &exynos4_device_pd[PD_G3D],
> > @@ -702,6 +714,7 @@ static void __init origen_machine_init(void)
> > s3c_sdhci0_set_platdata(&origen_hsmmc0_pdata);
> >
> > origen_ehci_init();
> > + origen_ohci_init();
> > clk_xusbxti.rate = 2400;
> >
> > s5p_tv_setup();
> > --
> > 1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Enable Bluetooth on ORIGEN
Sangwook Lee wrote: > > This patch enables Bluetooth support on ORIGEN board. > > Signed-off-by: Sangwook Maybe should be 'Signed-off-by: Sangwook Lee '? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 3/3] ARM: EXYNOS: Invert VCLK polarity for framebuffer on Origen board
Tushar Behera wrote:
>
> Framebuffer driver needs to fetch the video data during the rising
> edge of the VCLK. Otherwise, there are some glitches in the LCD
> display.
>
> Signed-off-by: Tushar Behera
> ---
> arch/arm/mach-exynos/mach-origen.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-
> exynos/mach-origen.c
> index f56d027..38f0556 100644
> --- a/arch/arm/mach-exynos/mach-origen.c
> +++ b/arch/arm/mach-exynos/mach-origen.c
> @@ -588,7 +588,8 @@ static struct s3c_fb_pd_win origen_fb_win0 = {
> static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
> .win[0] = &origen_fb_win0,
> .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> - .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> + .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC |
> + VIDCON1_INV_VCLK,
> .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
> };
>
> --
> 1.7.4.1
OK, will apply this.
And I will review 1/3 and 2/3 patches soon.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH V4 0/5] ARM: exynos: Add l2 retention mode cpuidle state
amit kachhap wrote: > > Hi Mr kim, > > All the comments have been addressed for the Exynos cpu idle patchset. > The updated patchset was posted about one month back and there have > been no further comments on the patchset since then. > > As this patchset seems to be stable now, do you think these these > patches can merged in this 3.3 merge window? Kindly let me know your > opinion. > This conflicts with local common.[ch] working for ARM restart. Please wait until after the merge window for this patches. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: February 2012 Kernel Release
Amit Kachhap wrote: > > Hi Amit Kucheria, > Hi all, (Cc'ed Jaecheol Lee and Jongpill Lee) > I have asked the samsung maintainer(Kukjin Kim) to queue this patch set 1 > month back. But seems like it is not present. > If it works fine, then I'm apply this series. But now it is not working. As a note, I use your series on top of v3.3-rc3 and fixed following for test. arch/arm/mach-exynos/cpuidle.c: In function 'exynos4_enter_core0_aftr': arch/arm/mach-exynos/cpuidle.c:119: error: implicit declaration of function 'BSYM' make[1]: *** [arch/arm/mach-exynos/cpuidle.o] Error 1 I and Jaecheol Lee tested AFTR mode on SMDKV310 and SMDKC210 and then rebooting happened. See below log. If any updates, please let me know. --- Booting Linux on physical CPU 0 Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 KST 2012 CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: SMDKV310 Memory policy: ECC disabled, Data cache writealloc CPU EXYNOS4210 (id 0x43210010) [snip] [root@Samsung ~]# cd /sys/devices/system/cpu/cpu0/cpuidle/ [root@Samsung cpuidle]# ls state0/ state1/ [root@Samsung cpuidle]# cd state1 [root@Samsung state1]# ls desc latency name powertime usage [root@Samsung state1]# cat name C1 [root@Samsung state1]# cat time 0 [root@Samsung state1]# echo 0 > /sys/devices/system/cpu/cpu1/online CPU1: shutdown [root@Samsung state1]# ðK U-Boot 2010.12-9-g300b392 (Jul 15 2011 - 16:39:20) for SMDKV310 ... [snip] Starting kernel ... Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0 Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 KST 2012 CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: SMDKC210 [snip] Samsung SMDK Board on a armv7l Samsung login: root login[1002]: root login on 'ttySAC1' [root@Samsung ~]# [root@Samsung ~]# [root@Samsung ~]# [root@Samsung ~]# [root@Samsung ~]# echo 0 > /sys/devices/system/cpu/cpu1/online CPU1: shutdown [root@Samsung ~]# O [snip] (as a note, the mark of 'O' means 'OK' printing from u-boot. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > > Hi Mr Kim, > > Can you please queue this patchset in your tree for next merge window? > The V5 version submitted fixes all the known issues. > http://lists.infradead.org/pipermail/linux-arm-kernel/2012- > January/079214.html > > Thanks, > Amit Daniel > > > On 17 February 2012 11:42, Amit Kucheria wrote: > > On Fri, Feb 17, 2012 at 11:03 AM, Deepak Saxena > wrote: > > > >> - Various patches from Linaro > >> > >> * samsung_cpuidle_l2_retention patch set from the power management > >> WG > > > > Amit, is this now in your maintainer's tree queued up for 3.4? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: February 2012 Kernel Release
Amit Kachhap wrote: > > Hi kukjin Kim, > Hi, > I was on travel for elc and linaro conferences so little late for > replying. Thanks for testing these patches. > I just submitted the V6 series of the cpuidle patchset. I rebased it > against the 3.3-rc4 kernel version. I also tested it for SMDKV310 > (evt1) and Origen (evt1.1) boards and they are working fine. > Some modification was done for CHECK_FLAG. > OK, I checked it works fine on SMDKV310 now. As I said, will apply your patches for v3.4 but I'm not sure there is a problem with common cpuidle work. Anyway, good job. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > Thanks, > Amit Daniel > > > On 18 February 2012 07:29, Kukjin Kim wrote: > > Amit Kachhap wrote: > >> > >> Hi Amit Kucheria, > >> > > Hi all, > > > > (Cc'ed Jaecheol Lee and Jongpill Lee) > > > >> I have asked the samsung maintainer(Kukjin Kim) to queue this patch set > 1 > >> month back. But seems like it is not present. > >> > > > > If it works fine, then I'm apply this series. > > > > But now it is not working. As a note, I use your series on top of v3.3- > rc3 > > and fixed following for test. > > > > arch/arm/mach-exynos/cpuidle.c: In function 'exynos4_enter_core0_aftr': > > arch/arm/mach-exynos/cpuidle.c:119: error: implicit declaration of > function > > 'BSYM' > > make[1]: *** [arch/arm/mach-exynos/cpuidle.o] Error 1 > > > > I and Jaecheol Lee tested AFTR mode on SMDKV310 and SMDKC210 and then > > rebooting happened. > > See below log. > > > > If any updates, please let me know. > > > > --- > > > > Booting Linux on physical CPU 0 > > Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc > version > > 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 > KST > > 2012 > > CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d > > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > > Machine: SMDKV310 > > Memory policy: ECC disabled, Data cache writealloc > > CPU EXYNOS4210 (id 0x43210010) > > > > [snip] > > > > [root@Samsung ~]# cd /sys/devices/system/cpu/cpu0/cpuidle/ > > [root@Samsung cpuidle]# ls > > state0/ state1/ > > [root@Samsung cpuidle]# cd state1 > > [root@Samsung state1]# ls > > desc latency name power time usage > > [root@Samsung state1]# cat name > > C1 > > [root@Samsung state1]# cat time > > 0 > > [root@Samsung state1]# echo 0 > /sys/devices/system/cpu/cpu1/online > > CPU1: shutdown > > [root@Samsung state1]# ðK > > > > U-Boot 2010.12-9-g300b392 (Jul 15 2011 - 16:39:20) for SMDKV310 > > ... > > > > [snip] > > > > Starting kernel ... > > > > Uncompressing Linux... done, booting the kernel. > > Booting Linux on physical CPU 0 > > Linux version 3.3.0-rc3-5-g20ea355-dirty (kgene@starstone) (gcc > version > > 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #2 SMP PREEMPT Sat Feb 18 09:15:42 > KST > > 2012 > > CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d > > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > > Machine: SMDKC210 > > > > [snip] > > > > Samsung SMDK Board on a armv7l > > Samsung login: root > > login[1002]: root login on 'ttySAC1' > > [root@Samsung ~]# > > [root@Samsung ~]# > > [root@Samsung ~]# > > [root@Samsung ~]# > > [root@Samsung ~]# echo 0 > /sys/devices/system/cpu/cpu1/online > > CPU1: shutdown > > [root@Samsung ~]# O > > > > [snip] (as a note, the mark of 'O' means 'OK' printing from u-boot. > > > > Thanks. > > > > Best regards, > > Kgene. > > -- > > Kukjin Kim , Senior Engineer, > > SW Solution Development Team, Samsung Electronics Co., Ltd. > > > > > > > >> > >> Hi Mr Kim, > >> > >> Can you please queue this patchset in your tree for next merge window? > >> The V5 version submitted fixes all the known issues. > >> http://lists.infradead.org/pipermail/linux-arm-kernel/2012- > >> January/079214.html > >> > >> Thanks, > >> Amit Daniel > >> > >> > >> On 17 February 2012 11:42, Amit Kucheria > wrote: > >> > On Fri, Feb 17, 2012 at 11:03 AM, Deepak Saxena > >> wrote: > >> > > >> >> - Various patches from Linaro > >> >> > >> >> * samsung_cpuidle_l2_retention patch set from the power management > >> >> WG > >> > > >> > Amit, is this now in your maintainer's tree queued up for 3.4? > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock
Jingoo Han wrote: > > Hi Tushar, > (please don't top-post) > > -Original Message- > > From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc- > ow...@vger.kernel.org] On Behalf > > Of Tushar Behera > > Sent: Thursday, December 01, 2011 2:50 PM > > To: linux-samsung-...@vger.kernel.org > > Cc: kgene@samsung.com; linaro-dev@lists.linaro.org; > patc...@linaro.org > > Subject: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock > > > > The framebuffer driver needs the clock named 'lcd' as its bus > > clock but the equivalent clock on Exynos4 is named as 'fimd'. > > Hence, create a clkdev lookup entry with the name 'lcd' that > > references the 'fimd' clock. > > > > Signed-off-by: Tushar Behera > > Acked-by: Jingoo Han > OK, I will apply this with Sylwester's 'reviewed-by' I looked at before. BTW, Tushar, what's the [1/3] and [3/3] in this series? If they are still needed now, could you please re-send? Maybe I missed. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock
Tushar Behera wrote: > > Hi Kukjin, > Tushar, please don't top-post. > On 03/01/2012 09:36 AM, Kukjin Kim wrote: > > Jingoo Han wrote: > >> > >> Hi Tushar, > >> > > > > (please don't top-post) > > > >>> -Original Message- > >>> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung- > soc- > >> ow...@vger.kernel.org] On Behalf > >>> Of Tushar Behera > >>> Sent: Thursday, December 01, 2011 2:50 PM > >>> To: linux-samsung-...@vger.kernel.org > >>> Cc: kgene@samsung.com; linaro-dev@lists.linaro.org; > >> patc...@linaro.org > >>> Subject: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd > clock > >>> > >>> The framebuffer driver needs the clock named 'lcd' as its bus > >>> clock but the equivalent clock on Exynos4 is named as 'fimd'. > >>> Hence, create a clkdev lookup entry with the name 'lcd' that > >>> references the 'fimd' clock. > >>> > >>> Signed-off-by: Tushar Behera > >> > >> Acked-by: Jingoo Han > >> > > > > OK, I will apply this with Sylwester's 'reviewed-by' I looked at before. > > > Thanks. Do you want me rebase this patch on your latest for-next and > resend? > Thanks but I can do it. > > BTW, Tushar, what's the [1/3] and [3/3] in this series? If they are > still > > needed now, could you please re-send? Maybe I missed. > > > "[PATCH 1/3] ARM: EXYNOS: Increase DMA pool allocator size for > framebuffer" > - It should be dropped. > > "[PATCH 3/3] ARM: EXYNOS: Invert VCLK polarity for framebuffer on Origen > board" > - It has already been applied. OK, thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock
On 02/29/12 21:15, Kukjin Kim wrote: Tushar Behera wrote: [...] Acked-by: Jingoo Han OK, I will apply this with Sylwester's 'reviewed-by' I looked at before. Thanks. Do you want me rebase this patch on your latest for-next and resend? Thanks but I can do it. BTW, Tushar, what's the [1/3] and [3/3] in this series? If they are still needed now, could you please re-send? Maybe I missed. "[PATCH 1/3] ARM: EXYNOS: Increase DMA pool allocator size for framebuffer" - It should be dropped. "[PATCH 3/3] ARM: EXYNOS: Invert VCLK polarity for framebuffer on Origen board" - It has already been applied. OK, thanks. Tushar, As a note, this will be applied on top of new cleanup-exynos-clock. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: exynos: Adapt to cpuidle core time keeping and irq enable
amit kachhap wrote:
>
> Hi Mr Kukjin,
>
> Any comment or update about this patch?
>
I'm not sure we don't need to check the idle_time?
Others, looks ok to me.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> Regards,
> Amit Daniel
>
> On Mon, Apr 30, 2012 at 10:13 PM, Rob Lee wrote:
> > On Wed, Apr 25, 2012 at 9:44 AM, Daniel Lezcano
> > wrote:
> >> On 04/25/2012 02:11 PM, Amit Daniel Kachhap wrote:
> >>>
> >>> This patch enables core cpuidle timekeeping and irq enabling and
> >>> remove those redundant parts from the exynos cpuidle drivers
> >>>
> >>> CC: Daniel Lezcano
> >>> CC: Robert Lee
> >>> Signed-off-by: Amit Daniel
> >>> ---
> >>> arch/arm/mach-exynos/cpuidle.c | 53
> >>> ---
> >>> 1 files changed, 6 insertions(+), 47 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-exynos/cpuidle.c
> >>> b/arch/arm/mach-exynos/cpuidle.c
> >>> index 33ab4e7..26dac28 100644
> >>> --- a/arch/arm/mach-exynos/cpuidle.c
> >>> +++ b/arch/arm/mach-exynos/cpuidle.c
> >>> @@ -20,6 +20,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>>
> >>> @@ -34,22 +35,12 @@
> >>>
> >>> #define S5P_CHECK_AFTR0xFCBA0D10
> >>>
> >>> -static int exynos4_enter_idle(struct cpuidle_device *dev,
> >>> - struct cpuidle_driver *drv,
> >>> - int index);
> >>> static int exynos4_enter_lowpower(struct cpuidle_device *dev,
> >>>struct cpuidle_driver *drv,
> >>>int index);
> >>>
> >>> static struct cpuidle_state exynos4_cpuidle_set[] __initdata = {
> >>> - [0] = {
> >>> - .enter = exynos4_enter_idle,
> >>> - .exit_latency = 1,
> >>> - .target_residency = 10,
> >>> - .flags = CPUIDLE_FLAG_TIME_VALID,
> >>> - .name = "C0",
> >>> - .desc = "ARM clock gating(WFI)",
> >>> - },
> >>> + [0] = ARM_CPUIDLE_WFI_STATE,
> >>>[1] = {
> >>>.enter = exynos4_enter_lowpower,
> >>>.exit_latency = 300,
> >>> @@ -63,8 +54,9 @@ static struct cpuidle_state exynos4_cpuidle_set[]
> >>> __initdata = {
> >>> static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
> >>>
> >>> static struct cpuidle_driver exynos4_idle_driver = {
> >>> - .name = "exynos4_idle",
> >>> - .owner = THIS_MODULE,
> >>> + .name = "exynos4_idle",
> >>> + .owner = THIS_MODULE,
> >>> + .en_core_tk_irqen = 1,
> >>> };
> >>>
> >>> /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
> >>> @@ -103,13 +95,8 @@ static int exynos4_enter_core0_aftr(struct
> >>> cpuidle_device *dev,
> >>>struct cpuidle_driver *drv,
> >>>int index)
> >>> {
> >>> - struct timeval before, after;
> >>> - int idle_time;
> >>>unsigned long tmp;
> >>>
> >>> - local_irq_disable();
> >>> - do_gettimeofday(&before);
> >>> -
> >>>exynos4_set_wakeupmask();
> >>>
> >>>/* Set value of power down register for aftr mode */
> >>> @@ -150,34 +137,6 @@ static int exynos4_enter_core0_aftr(struct
> >>> cpuidle_device *dev,
> >>>/* Clear wakeup state register */
> >>>__raw_writel(0x0, S5P_WAKEUP_STAT);
> >>>
> >>> - do_gettimeofday(&after);
> >>> -
> >>> - local_irq_enable();
> >>> - idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
> >>> - (after.tv_usec - before.tv_use
RE: [PATCH] ARM: exynos: Adapt to cpuidle core time keeping and irq enable
Daniel Lezcano wrote: > > On 05/09/2012 01:53 PM, Kukjin Kim wrote: > > amit kachhap wrote: > >> > >> Hi Mr Kukjin, > >> > >> Any comment or update about this patch? > >> > > I'm not sure we don't need to check the idle_time? > > Others, looks ok to me. > > Hi, > > may be I misunderstood your question but the behavior is not changed > here, just the code is refactored and using a common routine where the > time is computed. > > The idle_time computation is done by the cpuidle core now if the > en_core_tk_irqen flag is enabled. That allows to remove a lot of > duplicated code across the cpuidle drivers. > OK, I see and checked. Daniel, thanks. Amit, this looks ok to me, will apply. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] ARM: S3C64xx: cpuidle cleanups
On 05/14/12 18:22, Daniel Lezcano wrote: On 05/14/2012 10:57 AM, Mark Brown wrote: On Mon, May 14, 2012 at 10:52:46AM +0200, Heiko St??bner wrote: Am Montag, 14. Mai 2012, 01:51:00 schrieb Daniel Lezcano: On 05/09/2012 04:08 PM, Daniel Lezcano wrote: Are these patches ok for inclusion ? you might want to include the maintainer Kukjin Kim and the samsung list linux-samsung-...@vger.kernel.org into your recipients Also the original author (me). Oh, ok. I thought I did it, sorry. Heiko, thanks :-) Daniel, could you please re-submit this series with adding me and Mark Brown in Cc. I couldn't find your patches in my mailbox... Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 0/2] ARM: S3C64xx: cpuidle cleanups
Daniel Lezcano wrote: > > These couple of patches use the new cpuidle core api to refactor > some part of the code. The first one declares the states directly > in the driver declaration and the second one use the timekeeping > flag to let the cpuidle core to compute the idle time. > Basically, looks ok to me. > I don't have this board, I was not able to test these patches. > Mark, could you please check this patches on your board? Now, my smdk6410 has some problem to test this :( Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > Daniel Lezcano (2): > ARM: s3c64xx: cpuidle - declare the states with the new api > ARM: s3c64xx: cpuidle - use timekeeping wrapper > > arch/arm/mach-s3c64xx/cpuidle.c | 45 +-- > > 1 files changed, 15 insertions(+), 30 deletions(-) > > -- > 1.7.5.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 1/2] ARM: s3c64xx: cpuidle - declare the states with the new api
Daniel Lezcano wrote:
>
> The states are now part of the cpuidle_driver structure, so we can
> declare the states in this structure directly. That saves us an extra
> variable declaration and a memcpy.
>
> Signed-off-by: Daniel Lezcano
> ---
> arch/arm/mach-s3c64xx/cpuidle.c | 33 ++---
> 1 files changed, 14 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-
> s3c64xx/cpuidle.c
> index 179460f..2750e54 100644
> --- a/arch/arm/mach-s3c64xx/cpuidle.c
> +++ b/arch/arm/mach-s3c64xx/cpuidle.c
> @@ -51,33 +51,28 @@ static int s3c64xx_enter_idle(struct cpuidle_device
> *dev,
> return index;
> }
>
> -static struct cpuidle_state s3c64xx_cpuidle_set[] = {
> - [0] = {
> - .enter = s3c64xx_enter_idle,
> - .exit_latency = 1,
> - .target_residency = 1,
> - .flags = CPUIDLE_FLAG_TIME_VALID,
> - .name = "IDLE",
> - .desc = "System active, ARM gated",
> - },
> -};
> +static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
>
> static struct cpuidle_driver s3c64xx_cpuidle_driver = {
> - .name = "s3c64xx_cpuidle",
> - .owner = THIS_MODULE,
> - .state_count= ARRAY_SIZE(s3c64xx_cpuidle_set),
> -};
> -
> -static struct cpuidle_device s3c64xx_cpuidle_device = {
> - .state_count= ARRAY_SIZE(s3c64xx_cpuidle_set),
> + .name = "s3c64xx_cpuidle",
> + .owner = THIS_MODULE,
I'd preferred to use original 'tab'
> + .states = {
> + {
> + .enter= s3c64xx_enter_idle,
> + .exit_latency = 1,
> + .target_residency = 1,
> + .flags= CPUIDLE_FLAG_TIME_VALID,
> + .name = "IDLE",
> + .desc = "System active, ARM gated",
> + },
> + },
> + .state_count = 1,
> };
>
> static int __init s3c64xx_init_cpuidle(void)
> {
> int ret;
>
> - memcpy(s3c64xx_cpuidle_driver.states, s3c64xx_cpuidle_set,
> -sizeof(s3c64xx_cpuidle_set));
> cpuidle_register_driver(&s3c64xx_cpuidle_driver);
>
> ret = cpuidle_register_device(&s3c64xx_cpuidle_device);
> --
> 1.7.5.4
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] ARM: s3c64xx: cpuidle - declare the states with the new api
On 05/17/12 21:28, Mark Brown wrote: On Mon, May 14, 2012 at 04:06:16PM +0200, Daniel Lezcano wrote: The states are now part of the cpuidle_driver structure, so we can declare the states in this structure directly. That saves us an extra variable declaration and a memcpy. Tested-by: Mark Brown Thanks for testing, applied this series. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 03/17] ARM: gic: Use cpu pm notifiers to save gic state
Santosh Shilimkar wrote: > > On 7/7/2011 6:41 PM, Colin Cross wrote: Hi all, Now Samsung prepares updating PM on EXYNOS4210 and save/restore GIC is needed for that. Actually, it works fine on EXYNOS4210 with this. But we have some concern about following. > +/* > + * Saves the GIC distributor registers during suspend or idle. Must be called > + * with interrupts disabled but before powering down the GIC. After calling > + * this function, no interrupts will be delivered by the GIC, and another > + * platform-specific wakeup source must be enabled. > + */ PMU needs to detect interrupt which can be a wakeup source via GIC before calling WFI. Seems there is no problem but I think that can be a hole during very short time... So is it needed to disable GIC after saving context? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH V2] ARM: EXYNOS4: Add support for ORIGEN board
= EXYNOS4_GPK2(2),
> + .ext_cd_gpio_invert = 1,
> + .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> +};
> +
> +static struct platform_device *origen_devices[] __initdata = {
> + &s3c_device_hsmmc2,
> + &s3c_device_rtc,
> + &s3c_device_wdt,
> +};
> +
> +static void __init origen_map_io(void)
> +{
> + s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> + s3c24xx_init_clocks(2400);
> + s3c24xx_init_uarts(origen_uartcfgs, ARRAY_SIZE(origen_uartcfgs));
> +}
> +
> +static void __init origen_machine_init(void)
> +{
> + s3c_sdhci2_set_platdata(&origen_hsmmc2_pdata);
> + platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
> +}
> +
> +MACHINE_START(ORIGEN, "ORIGEN")
> + /* Maintainer: JeongHyeon Kim */
> + .boot_params= S5P_PA_SDRAM + 0x100,
> + .init_irq = exynos4_init_irq,
> + .map_io = origen_map_io,
> + .init_machine = origen_machine_init,
> + .timer = &exynos4_timer,
> +MACHINE_END
> --
> 1.7.4.1
Hi,
Yes, I remember this :)
Looks ok to me, applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Enable MFC on Samsung SMDKV310
Sachin Kamat wrote:
>
> Signed-off-by: Sachin Kamat
> ---
>
> This patch is based on Kukjin's for-arm-soc branch.
>
> arch/arm/mach-exynos4/Kconfig |1 +
> arch/arm/mach-exynos4/mach-smdkv310.c | 11 +++
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 9d62e13..8da2960 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -139,6 +139,7 @@ config MACH_SMDKV310
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_I2C1
> + select S5P_DEV_MFC
> select S3C_DEV_HSMMC
> select S3C_DEV_HSMMC1
> select S3C_DEV_HSMMC2
> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
> exynos4/mach-smdkv310.c
> index ea41495..2a128f4 100644
> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -177,6 +178,9 @@ static struct platform_device *smdkv310_devices[]
> __initdata = {
> &exynos4_device_ac97,
> &exynos4_device_i2s0,
> &samsung_device_keypad,
> + &s5p_device_mfc,
> + &s5p_device_mfc_l,
> + &s5p_device_mfc_r,
> &exynos4_device_pd[PD_MFC],
> &exynos4_device_pd[PD_G3D],
> &exynos4_device_pd[PD_LCD0],
> @@ -233,6 +237,11 @@ static void __init smdkv310_map_io(void)
> s3c24xx_init_uarts(smdkv310_uartcfgs,
> ARRAY_SIZE(smdkv310_uartcfgs));
> }
>
> +static void __init smdkv310_reserve(void)
> +{
> + s5p_mfc_reserve_mem(0x4300, 8 << 20, 0x5100, 8 << 20);
> +}
> +
> static void __init smdkv310_machine_init(void)
> {
> s3c_i2c1_set_platdata(NULL);
> @@ -250,6 +259,7 @@ static void __init smdkv310_machine_init(void)
> samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data);
>
> platform_add_devices(smdkv310_devices,
> ARRAY_SIZE(smdkv310_devices));
> + s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
> }
>
> MACHINE_START(SMDKV310, "SMDKV310")
> @@ -260,4 +270,5 @@ MACHINE_START(SMDKV310, "SMDKV310")
> .map_io = smdkv310_map_io,
> .init_machine = smdkv310_machine_init,
> .timer = &exynos4_timer,
> + .reserve= &smdkv310_reserve,
> MACHINE_END
> --
> 1.7.4.1
OK, applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: ADD USB EHCI device to SMDKV310
Sachin Kamat wrote:
>
> Signed-off-by: Bhuvana Kakunoori
> Signed-off-by: Pankaj Dubey
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/mach-exynos4/Kconfig |2 ++
> arch/arm/mach-exynos4/mach-smdkv310.c | 16
> 2 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index bb29d51..cc97d23 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -136,6 +136,7 @@ config MACH_SMDKV310
> bool "SMDKV310"
> select CPU_EXYNOS4210
> select S5P_DEV_FIMD0
> + select S5P_DEV_USB_EHCI
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_I2C1
> @@ -151,6 +152,7 @@ config MACH_SMDKV310
> select SAMSUNG_DEV_PWM
> select EXYNOS4_DEV_SYSMMU
> select EXYNOS4_SETUP_FIMD0
> + select EXYNOS4_SETUP_USB_PHY
> select EXYNOS4_SETUP_I2C1
> select EXYNOS4_SETUP_KEYPAD
> select EXYNOS4_SETUP_SDHCI
> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
> exynos4/mach-smdkv310.c
> index 5f62b2b..b6c28ea 100644
> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> @@ -33,6 +33,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -167,6 +169,16 @@ static struct i2c_board_info i2c_devs1[] __initdata =
{
> {I2C_BOARD_INFO("wm8994", 0x1a),},
> };
>
> +/* USB EHCI */
> +static struct s5p_ehci_platdata smdkv310_ehci_pdata;
> +
> +static void __init smdkv310_ehci_init(void)
> +{
> + struct s5p_ehci_platdata *pdata = &smdkv310_ehci_pdata;
> +
> + s5p_ehci_set_platdata(pdata);
> +}
> +
> static struct platform_device *smdkv310_devices[] __initdata = {
> &s3c_device_hsmmc0,
> &s3c_device_hsmmc1,
> @@ -175,6 +187,7 @@ static struct platform_device *smdkv310_devices[]
> __initdata = {
> &s3c_device_i2c1,
> &s3c_device_rtc,
> &s3c_device_wdt,
> + &s5p_device_ehci,
> &exynos4_device_ac97,
> &exynos4_device_i2s0,
> &samsung_device_keypad,
> @@ -258,6 +271,9 @@ static void __init smdkv310_machine_init(void)
>
> samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data);
>
> + smdkv310_ehci_init();
> + clk_xusbxti.rate = 2400;
> +
> platform_add_devices(smdkv310_devices,
> ARRAY_SIZE(smdkv310_devices));
> s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
> }
> --
> 1.7.4.1
(Cc'ed Jingoo Han)
Well, this is same with Jingoo's patch on smdkc210 which has been submitted
at 12th Aug.
I requested to him to re-work this on smdkv310 on his patch just now...
Hmm...I don't know :(
Let me think again...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Add USB EHCI device to Origen
Sachin Kamat wrote:
>
> Signed-off-by: Pankaj Dubey
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/mach-exynos4/Kconfig |2 ++
> arch/arm/mach-exynos4/mach-origen.c | 17 +
> 2 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 3ab0f18..fba97a4 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -189,8 +189,10 @@ config MACH_NURI
> config MACH_ORIGEN
> bool "ORIGEN"
> select CPU_EXYNOS4210
> + select S5P_DEV_USB_EHCI
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> + select EXYNOS4_SETUP_USB_PHY
If possible, please keep the ordering :(
> select S3C_DEV_HSMMC2
> select EXYNOS4_SETUP_SDHCI
> help
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index ed59f86..d101756 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -24,6 +24,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -79,10 +81,21 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
> __initdata = {
> .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> };
>
> +/* USB EHCI */
> +static struct s5p_ehci_platdata origen_ehci_pdata;
> +
> +static void __init origen_ehci_init(void)
> +{
> + struct s5p_ehci_platdata *pdata = &origen_ehci_pdata;
> +
> + s5p_ehci_set_platdata(pdata);
> +}
> +
> static struct platform_device *origen_devices[] __initdata = {
> &s3c_device_hsmmc2,
> &s3c_device_rtc,
> &s3c_device_wdt,
> + &s5p_device_ehci,
> };
>
> static void __init origen_map_io(void)
> @@ -95,6 +108,10 @@ static void __init origen_map_io(void)
> static void __init origen_machine_init(void)
> {
> s3c_sdhci2_set_platdata(&origen_hsmmc2_pdata);
> +
> + origen_ehci_init();
> + clk_xusbxti.rate = 2400;
> +
> platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
> }
>
> --
> 1.7.4.1
OK, will apply with re-ordering as per my comments.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 2/3] ARM: EXYNOS4: Add support for secondary MMC port on ORIGEN
Tushar Behera wrote:
> -Original Message-
> From: Tushar Behera [mailto:tushar.beh...@linaro.org]
> Sent: Friday, August 26, 2011 6:39 PM
> To: linux-samsung-...@vger.kernel.org
> Cc: linaro-dev@lists.linaro.org; kgene@samsung.com; patc...@linaro.org
> Subject: [PATCH 2/3] ARM: EXYNOS4: Add support for secondary MMC port on
> ORIGEN
>
> Secondary MMC port on ORIGEN is connected to sdhci instance 0. Support
> for secondary MMC port is extended by registering sdhci instance 0.
>
> Since sdhci instance 2 can contain a bootable media, sdhci instance 0
> is registered after instance 2.
>
Would be helpful if above comments could be included in codes :)
> Signed-off-by: Tushar Behera
> ---
> arch/arm/mach-exynos4/Kconfig |1 +
> arch/arm/mach-exynos4/mach-origen.c |7 +++
> 2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index e6925de..4c14d5e 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -229,6 +229,7 @@ config MACH_ORIGEN
> select CPU_EXYNOS4210
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> + select S3C_DEV_HSMMC
> select S3C_DEV_HSMMC2
> select EXYNOS4_SETUP_SDHCI
> help
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index e280270..ae18812 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -72,6 +72,11 @@ static struct s3c2410_uartcfg origen_uartcfgs[]
__initdata = {
> },
> };
>
> +static struct s3c_sdhci_platdata origen_hsmmc0_pdata __initdata = {
> + .cd_type= S3C_SDHCI_CD_INTERNAL,
> + .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> +};
> +
> static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
> .cd_type= S3C_SDHCI_CD_INTERNAL,
> .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> @@ -79,6 +84,7 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
> __initdata = {
>
> static struct platform_device *origen_devices[] __initdata = {
> &s3c_device_hsmmc2,
> + &s3c_device_hsmmc0,
> &s3c_device_rtc,
> &s3c_device_wdt,
> };
> @@ -93,6 +99,7 @@ static void __init origen_map_io(void)
> static void __init origen_machine_init(void)
> {
> s3c_sdhci2_set_platdata(&origen_hsmmc2_pdata);
> + s3c_sdhci0_set_platdata(&origen_hsmmc0_pdata);
> platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
> }
>
> --
> 1.7.4.1
OK, will apply.
If you don't mind, I will add comments the reason of the ordering when I
apply this.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 1/3] ARM: EXYNOS4: Fix sdhci card detection for ORIGEN
Tushar Behera wrote:
>
> Fix incorrect value of cd_type field in platform data for sdhci
> device.
>
> Based on "ARM: EXYNOS4: Fix card detection for sdhci 0 and 2".
> commit a0d8efedb203b5b908dd46cea38201761e2380f9
>
> Signed-off-by: Tushar Behera
> ---
> arch/arm/mach-exynos4/mach-origen.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index ed59f86..e280270 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -73,9 +73,7 @@ static struct s3c2410_uartcfg origen_uartcfgs[]
__initdata = {
> };
>
> static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
> - .cd_type= S3C_SDHCI_CD_GPIO,
> - .ext_cd_gpio= EXYNOS4_GPK2(2),
> - .ext_cd_gpio_invert = 1,
> + .cd_type= S3C_SDHCI_CD_INTERNAL,
> .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> };
>
> --
> 1.7.4.1
OK, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Add FIMC device on Origen board
Sachin Kamat wrote:
>
> This patch adds definitions to enable support for s5p-fimc driver on
> Origen board.
>
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/mach-exynos4/Kconfig |4
> arch/arm/mach-exynos4/mach-origen.c |4
> 2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index e6925de..a3d92a8 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -227,6 +227,10 @@ config MACH_NURI
> config MACH_ORIGEN
> bool "ORIGEN"
> select CPU_EXYNOS4210
> + select S5P_DEV_FIMC0
> + select S5P_DEV_FIMC1
> + select S5P_DEV_FIMC2
> + select S5P_DEV_FIMC3
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_HSMMC2
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index ed59f86..4a2ac49 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -80,6 +80,10 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
> __initdata = {
> };
>
> static struct platform_device *origen_devices[] __initdata = {
> + &s5p_device_fimc0,
> + &s5p_device_fimc1,
> + &s5p_device_fimc2,
> + &s5p_device_fimc3,
> &s3c_device_hsmmc2,
> &s3c_device_rtc,
> &s3c_device_wdt,
> --
> 1.7.4.1
OK, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 1/1] ARM: EXYNOS4: Add PWM backlight support on Origen
Sachin Kamat wrote:
>
> From: Giridhar Maruthy
>
> This patch adds support for LCD backlight using PWM timer on
> Origen board.
>
> Signed-off-by: Giridhar Maruthy
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/mach-exynos4/Kconfig |2 ++
> arch/arm/mach-exynos4/mach-origen.c | 16
> 2 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index e6925de..3e9138e 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -230,6 +230,8 @@ config MACH_ORIGEN
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_HSMMC2
> + select SAMSUNG_DEV_BACKLIGHT
> + select SAMSUNG_DEV_PWM
> select EXYNOS4_SETUP_SDHCI
> help
> Machine support for ORIGEN based on Samsung EXYNOS4210
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index ed59f86..b871815 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -24,6 +25,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -85,6 +88,17 @@ static struct platform_device *origen_devices[]
__initdata =
> {
> &s3c_device_wdt,
> };
>
> +/* LCD Backlight data */
> +static struct samsung_bl_gpio_info origen_bl_gpio_info = {
> + .no = EXYNOS4_GPD0(0),
> + .func = S3C_GPIO_SFN(2),
> +};
> +
> +static struct platform_pwm_backlight_data origen_bl_data = {
> + .pwm_id = 0,
> + .pwm_period_ns = 1000,
> +};
> +
> static void __init origen_map_io(void)
> {
> s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> @@ -96,6 +110,8 @@ static void __init origen_machine_init(void)
> {
> s3c_sdhci2_set_platdata(&origen_hsmmc2_pdata);
> platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
> +
> + samsung_bl_set(&origen_bl_gpio_info, &origen_bl_data);
> }
>
> MACHINE_START(ORIGEN, "ORIGEN")
> --
> 1.7.4.1
OK, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 3/3] ARM: EXYNOS4: Add support for 8-bit bus width in SDHCI for ORIGEN
Tushar Behera wrote:
>
> Platform data for SDHCI controller on ORIGEN board is missing the
> support for 8-bit bus width. The platform data is extended in sync
> with other EXYNOS4 machines.
>
> Signed-off-by: Tushar Behera
> ---
> arch/arm/mach-exynos4/mach-origen.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index ae18812..6b6cd77 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -75,11 +75,19 @@ static struct s3c2410_uartcfg origen_uartcfgs[]
__initdata =
> {
> static struct s3c_sdhci_platdata origen_hsmmc0_pdata __initdata = {
> .cd_type= S3C_SDHCI_CD_INTERNAL,
> .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> +#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
> + .max_width = 8,
> + .host_caps = MMC_CAP_8_BIT_DATA,
> +#endif
> };
>
> static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
> .cd_type= S3C_SDHCI_CD_INTERNAL,
> .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> +#ifdef CONFIG_EXYNOS4_SDHCI_CH2_8BIT
> + .max_width = 8,
> + .host_caps = MMC_CAP_8_BIT_DATA,
> +#endif
> };
>
> static struct platform_device *origen_devices[] __initdata = {
> --
> 1.7.4.1
Hi Tushar,
I wonder the bus width of SDHCI controller can be changed manually on ORIGEN
like SMDK board.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Enable system MMU support on Origen
Sachin Kamat wrote:
>
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/mach-exynos4/Kconfig |1 +
> arch/arm/mach-exynos4/mach-origen.c |1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 3ab0f18..bdb76e2 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -192,6 +192,7 @@ config MACH_ORIGEN
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_HSMMC2
> + select EXYNOS4_DEV_SYSMMU
> select EXYNOS4_SETUP_SDHCI
> help
> Machine support for ORIGEN based on Samsung EXYNOS4210
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index ed59f86..d04f7ee 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -83,6 +83,7 @@ static struct platform_device *origen_devices[]
__initdata = {
> &s3c_device_hsmmc2,
> &s3c_device_rtc,
> &s3c_device_wdt,
> + &exynos4_device_sysmmu,
> };
>
> static void __init origen_map_io(void)
> --
> 1.7.4.1
Hi Sachin,
Hmm, do you _really_ use this feature on ORIGEN board now?
As I know, the EXYNOS System MMU driver will be changed like a form of omap
and msm soon maybe it's within 1 or 2 weeks. So if this is not required on
ORIGEN now, I'd like to wait for new EXYNOS System MMU driver.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 1/2] ARM: EXYNOS4: Code cleanup and remove extra functions.
orts of both PHY and Link */
> - rstcon = readl(EXYNOS4_RSTCON) | HOST_LINK_PORT_SWRST_MASK |
> - PHY1_SWRST_MASK;
> - writel(rstcon, EXYNOS4_RSTCON);
> - udelay(10);
> + /* reset all ports of both PHY and Link */
> + rstcon = readl(EXYNOS4_RSTCON) |
> HOST_LINK_PORT_SWRST_MASK |
> + PHY1_SWRST_MASK;
> + writel(rstcon, EXYNOS4_RSTCON);
> + udelay(10);
>
> - rstcon &= ~(HOST_LINK_PORT_SWRST_MASK | PHY1_SWRST_MASK);
> - writel(rstcon, EXYNOS4_RSTCON);
> - udelay(80);
> + rstcon &= ~(HOST_LINK_PORT_SWRST_MASK |
> PHY1_SWRST_MASK);
> + writel(rstcon, EXYNOS4_RSTCON);
> + udelay(80);
>
> - clk_disable(otg_clk);
> - clk_put(otg_clk);
> + clk_disable(otg_clk);
> + clk_put(otg_clk);
>
> - return 0;
> + return 0;
> + }
> + return -EINVAL;
> }
>
> -static int exynos4_usb_phy1_exit(struct platform_device *pdev)
> +int s5p_usb_phy_exit(struct platform_device *pdev, int type)
> {
> - struct clk *otg_clk;
> - int err;
> -
> - otg_clk = clk_get(&pdev->dev, "otg");
> - if (IS_ERR(otg_clk)) {
> - dev_err(&pdev->dev, "Failed to get otg clock\n");
> - return PTR_ERR(otg_clk);
> - }
> + if (type == S5P_USB_PHY_HOST) {
> + struct clk *otg_clk;
> + int err;
> + otg_clk = clk_get(&pdev->dev, "otg");
> + if (IS_ERR(otg_clk)) {
> + dev_err(&pdev->dev, "Failed to get otg clock\n");
> + return PTR_ERR(otg_clk);
> + }
>
> - err = clk_enable(otg_clk);
> - if (err) {
> - clk_put(otg_clk);
> - return err;
> - }
> + err = clk_enable(otg_clk);
> + if (err) {
> + clk_put(otg_clk);
> + return err;
> + }
>
> - writel((readl(EXYNOS4_PHYPWR) |
> PHY1_STD_ANALOG_POWERDOWN),
> + writel((readl(EXYNOS4_PHYPWR) |
> PHY1_STD_ANALOG_POWERDOWN),
> EXYNOS4_PHYPWR);
>
> - writel(readl(S5P_USBHOST_PHY_CONTROL) &
> ~S5P_USBHOST_PHY_ENABLE,
> + writel(readl(S5P_USBHOST_PHY_CONTROL) &
> ~S5P_USBHOST_PHY_ENABLE,
> S5P_USBHOST_PHY_CONTROL);
>
> - clk_disable(otg_clk);
> - clk_put(otg_clk);
> -
> - return 0;
> -}
> -
> -int s5p_usb_phy_init(struct platform_device *pdev, int type)
> -{
> - if (type == S5P_USB_PHY_HOST)
> - return exynos4_usb_phy1_init(pdev);
> -
> - return -EINVAL;
> -}
> -
> -int s5p_usb_phy_exit(struct platform_device *pdev, int type)
> -{
> - if (type == S5P_USB_PHY_HOST)
> - return exynos4_usb_phy1_exit(pdev);
> + clk_disable(otg_clk);
> + clk_put(otg_clk);
>
> + return 0;
> + }
> return -EINVAL;
> }
> --
> 1.7.4.1
(Cc'ed Yulgon Kim and Kyoungil Kim)
Hi Sachin,
I don't know why this is required on usb-phy control for EXYNOS4 now.
Actually, other upcoming EXYNOS SoCs have more usb phys than EXYNOS4210, so
this can make it more difficult to control.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 2/2] ARM: EXYNOS4: Add USB PHY initialization for device
break;
> - case 24 * MHZ:
> - phyclk |= CLKSEL_24M;
> - break;
> - default:
> - case 48 * MHZ:
> - /* default reference clock */
> - break;
> - }
> - clk_put(xusbxti_clk);
> - }
> -
> - writel(phyclk, EXYNOS4_PHYCLK);
> -
> - /* floating prevention logic: disable */
> writel((readl(EXYNOS4_PHY1CON) | FPENABLEN),
> EXYNOS4_PHY1CON);
>
> /* set to normal HSIC 0 and 1 of PHY1 */
> @@ -84,30 +98,61 @@ int s5p_usb_phy_init(struct platform_device *pdev,
int type)
>
> rstcon &= ~(HOST_LINK_PORT_SWRST_MASK |
> PHY1_SWRST_MASK);
> writel(rstcon, EXYNOS4_RSTCON);
> - udelay(80);
> + } else if (type == S5P_USB_PHY_DEVICE) {
> + writel(readl(S5P_USBDEVICE_PHY_CONTROL) | (0x1<<0),
> + S5P_USBDEVICE_PHY_CONTROL);
> + writel((readl(EXYNOS4_PHYPWR) & ~(0x7<<3)&~(0x1<<0)),
> + EXYNOS4_PHYPWR);
> + writel((readl(EXYNOS4_PHYCLK) & ~(0x5<<2))|(0x3<<0),
> + EXYNOS4_PHYCLK);
> + writel((readl(EXYNOS4_RSTCON) & ~(0x3<<1))|(0x1<<0),
> + EXYNOS4_RSTCON);
> + udelay(10);
> + writel(readl(EXYNOS4_RSTCON) & ~(0x7<<0),
> + EXYNOS4_RSTCON);
> + }
> + udelay(80);
>
> - clk_disable(otg_clk);
> - clk_put(otg_clk);
> + clk_disable(otg_clk);
> + clk_put(otg_clk);
> + if (type == S5P_USB_PHY_HOST)
> + clk_put(usbhost_clk);
>
> - return 0;
> - }
> - return -EINVAL;
> + return 0;
> }
>
> int s5p_usb_phy_exit(struct platform_device *pdev, int type)
> {
> + struct clk *otg_clk, *usbhost_clk;
> + int err;
> +
> + if ((type != S5P_USB_PHY_HOST) && (type != S5P_USB_PHY_DEVICE))
> + return -EINVAL;
> +
> + otg_clk = clk_get(&pdev->dev, "otg");
> + if (IS_ERR(otg_clk)) {
> + dev_err(&pdev->dev, "Failed to get otg clock\n");
> + return PTR_ERR(otg_clk);
> + }
> +
> + err = clk_enable(otg_clk);
> + if (err) {
> + clk_put(otg_clk);
> + return err;
> + }
> +
> if (type == S5P_USB_PHY_HOST) {
> - struct clk *otg_clk;
> - int err;
> - otg_clk = clk_get(&pdev->dev, "otg");
> - if (IS_ERR(otg_clk)) {
> - dev_err(&pdev->dev, "Failed to get otg clock\n");
> - return PTR_ERR(otg_clk);
> +
> + usbhost_clk = clk_get(&pdev->dev, "usbhost");
> +
> + if (IS_ERR(usbhost_clk)) {
> + dev_err(&pdev->dev, "Failed to get usbhost
clock\n");
> + return PTR_ERR(usbhost_clk);
> }
>
> - err = clk_enable(otg_clk);
> + err = clk_enable(usbhost_clk);
Wrong, do you _really_ want to enable usbhost_clk here, in usb_phy_exit()?
> if (err) {
> - clk_put(otg_clk);
> + clk_put(usbhost_clk);
> return err;
> }
>
> @@ -117,10 +162,18 @@ int s5p_usb_phy_exit(struct platform_device *pdev,
int
> type)
> writel(readl(S5P_USBHOST_PHY_CONTROL) &
> ~S5P_USBHOST_PHY_ENABLE,
> S5P_USBHOST_PHY_CONTROL);
>
> - clk_disable(otg_clk);
> - clk_put(otg_clk);
> + } else if (type == S5P_USB_PHY_DEVICE) {
> + writel(readl(EXYNOS4_PHYPWR) | (0x3<<3),
> + EXYNOS4_PHYPWR);
>
> - return 0;
> + writel(readl(S5P_USBDEVICE_PHY_CONTROL) & ~(1<<0),
> + S5P_USBDEVICE_PHY_CONTROL);
> }
> - return -EINVAL;
> +
> + clk_disable(otg_clk);
> + clk_put(otg_clk);
> + if (type == S5P_USB_PHY_HOST)
> + clk_put(usbhost_clk);
> +
> + return 0;
> }
> --
> 1.7.4.1
I can't agree this patch. I think you need to check about whole USB PHY
structure on EXYNOS4 again.
In addition, I don’t have idea we need to control USB Host clock for
handling USB PHY enable/disable.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 3/3] ARM: EXYNOS4: Add support for 8-bit bus width in SDHCI for ORIGEN
Tushar Behera wrote:
>
> On Wednesday 31 August 2011 06:31 AM, Kukjin Kim wrote:
> > Tushar Behera wrote:
> >>
> >> Platform data for SDHCI controller on ORIGEN board is missing the
> >> support for 8-bit bus width. The platform data is extended in sync
> >> with other EXYNOS4 machines.
> >>
> >> Signed-off-by: Tushar Behera
> >> ---
> >> arch/arm/mach-exynos4/mach-origen.c |8
> >> 1 files changed, 8 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-exynos4/mach-origen.c
> > b/arch/arm/mach-exynos4/mach-
> >> origen.c
> >> index ae18812..6b6cd77 100644
> >> --- a/arch/arm/mach-exynos4/mach-origen.c
> >> +++ b/arch/arm/mach-exynos4/mach-origen.c
> >> @@ -75,11 +75,19 @@ static struct s3c2410_uartcfg origen_uartcfgs[]
> > __initdata =
> >> {
> >> static struct s3c_sdhci_platdata origen_hsmmc0_pdata __initdata = {
> >>.cd_type= S3C_SDHCI_CD_INTERNAL,
> >>.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> >> +#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
> >> + .max_width = 8,
> >> + .host_caps = MMC_CAP_8_BIT_DATA,
> >> +#endif
> >> };
> >>
> >> static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
> >>.cd_type= S3C_SDHCI_CD_INTERNAL,
> >>.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> >> +#ifdef CONFIG_EXYNOS4_SDHCI_CH2_8BIT
> >> + .max_width = 8,
> >> + .host_caps = MMC_CAP_8_BIT_DATA,
> >> +#endif
> >> };
> >>
> >> static struct platform_device *origen_devices[] __initdata = {
> >> --
> >> 1.7.4.1
> >
> > Hi Tushar,
> >
> > I wonder the bus width of SDHCI controller can be changed manually on
ORIGEN
> > like SMDK board.
> >
> Thanks for your review.
>
> On ORIGEN board, we have wire connections for HSMMC-0/2/3 between the
> MMC port and the SoC. Hence ideally we can work with HSMMC2 in both
> 4-bit and 8-bit mode. However HSMMC0 can only work in 4-bit mode.
>
> Also IIRC WLAN would be using HSMMC-3 controller for its operations. So
> we would have conflict when HSMMC2 is working in 8-bit mode and WLAN is
> also enabled. Hence it appears better to drop this patch now.
>
OK.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: ADD USB EHCI device to SMDKV310
Kukjin Kim wrote:
>
> Sachin Kamat wrote:
> >
> > Signed-off-by: Bhuvana Kakunoori
> > Signed-off-by: Pankaj Dubey
> > Signed-off-by: Sachin Kamat
> > ---
> > arch/arm/mach-exynos4/Kconfig |2 ++
> > arch/arm/mach-exynos4/mach-smdkv310.c | 16
> > 2 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos4/Kconfig
b/arch/arm/mach-exynos4/Kconfig
> > index bb29d51..cc97d23 100644
> > --- a/arch/arm/mach-exynos4/Kconfig
> > +++ b/arch/arm/mach-exynos4/Kconfig
> > @@ -136,6 +136,7 @@ config MACH_SMDKV310
> > bool "SMDKV310"
> > select CPU_EXYNOS4210
> > select S5P_DEV_FIMD0
> > + select S5P_DEV_USB_EHCI
> > select S3C_DEV_RTC
> > select S3C_DEV_WDT
> > select S3C_DEV_I2C1
> > @@ -151,6 +152,7 @@ config MACH_SMDKV310
> > select SAMSUNG_DEV_PWM
> > select EXYNOS4_DEV_SYSMMU
> > select EXYNOS4_SETUP_FIMD0
> > + select EXYNOS4_SETUP_USB_PHY
> > select EXYNOS4_SETUP_I2C1
> > select EXYNOS4_SETUP_KEYPAD
> > select EXYNOS4_SETUP_SDHCI
> > diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
> > exynos4/mach-smdkv310.c
> > index 5f62b2b..b6c28ea 100644
> > --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> > +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> > @@ -33,6 +33,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > #include
> >
> > @@ -167,6 +169,16 @@ static struct i2c_board_info i2c_devs1[] __initdata
= {
> > {I2C_BOARD_INFO("wm8994", 0x1a),},
> > };
> >
> > +/* USB EHCI */
> > +static struct s5p_ehci_platdata smdkv310_ehci_pdata;
> > +
> > +static void __init smdkv310_ehci_init(void)
> > +{
> > + struct s5p_ehci_platdata *pdata = &smdkv310_ehci_pdata;
> > +
> > + s5p_ehci_set_platdata(pdata);
> > +}
> > +
> > static struct platform_device *smdkv310_devices[] __initdata = {
> > &s3c_device_hsmmc0,
> > &s3c_device_hsmmc1,
> > @@ -175,6 +187,7 @@ static struct platform_device *smdkv310_devices[]
> > __initdata = {
> > &s3c_device_i2c1,
> > &s3c_device_rtc,
> > &s3c_device_wdt,
> > + &s5p_device_ehci,
> > &exynos4_device_ac97,
> > &exynos4_device_i2s0,
> > &samsung_device_keypad,
> > @@ -258,6 +271,9 @@ static void __init smdkv310_machine_init(void)
> >
> > samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data);
> >
> > + smdkv310_ehci_init();
> > + clk_xusbxti.rate = 2400;
> > +
> > platform_add_devices(smdkv310_devices,
> > ARRAY_SIZE(smdkv310_devices));
> > s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
> > }
> > --
> > 1.7.4.1
>
> (Cc'ed Jingoo Han)
>
> Well, this is same with Jingoo's patch on smdkc210 which has been
submitted at
> 12th Aug.
>
> I requested to him to re-work this on smdkv310 on his patch just now...
> Hmm...I don't know :(
>
> Let me think again...
>
As I've heard, Jingoo talked you about this patch and you agreed to use
Jingoo's patch on SMDKV310. So I dropped this and will pick up his patch.
If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
Siarhei Siamashka wrote: > > On Wed, Sep 14, 2011 at 10:57 AM, Kyungmin Park > wrote: > > On Wed, Sep 14, 2011 at 4:43 PM, Siarhei Siamashka > > wrote: > >> On Wed, Sep 14, 2011 at 9:08 AM, Kyungmin Park > wrote: > >>> Hi Siarhei, > >>> > >>> Interesting feature, and it's not samsung soc issue, so add the arm > >>> mailing list. > >>> It checked and the see the read performance improvement from 868MiB/s > >>> to 981MiB/s with lmbench. > >> > >> Maybe lmbench does not try very hard to get the best out of the > >> hardware? On my origenboard, I'm getting ~1.15GB/s performance for the > >> standard LDM/STM based memcpy from libc-ports, which is ~2.3GB/s > >> memory bandwidth if both reads and writes are accounted separately. > >> > >>> It's helpful to test other SoC., e.g., OMAP4, STE and so on. > >> > >> The current (?) state of the support for this feature in OMAP4 is > >> explained here by Richard Woodruff: > >>http://groups.google.com/group/pandaboard/msg/dfd2d2e1336d435b > >> > >>> BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit > >>> and should be zero (SBZ). > >> > >> This PL310 thing seems to have been renamed to "CoreLink Level 2 Cache > >> Controller L2C-310" in later revisions, and its Prefetch Control > >> Register is described here: > >>http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246f/CHDHIECI.html > > Thanks for link. it has 27-bit description. but does it correct bit > > description for exynos4 PL310? > > I mean I received the PL310 TRM with exynos4 chip used. there's no > > 27-bit description. it's just reserved bit. > > Can it enable the 27-bit at exynos4210? or can be used for exynos4212 or > > later? > > That's a good point. I think it is exynos4210 that is used in > origenboard. And according to the value in Cache ID Register > (0x4100c4c5), it has r3p0 revision of L2C-310. Which means that the > Prefetch Control Register is actually described at: > http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246d/CHDHIECI.html > And bit 27 is indeed reserved. However flipping it seems to have some > measurable impact on performance (unless I screwed up the benchmarks), > so maybe it does something but is undocumented? In any case, I agree > that it's better not to mess up with this bit. > Hi all, Please adding me in Cc for Samsung stuff... > By the way, does anybody have L2C-310 errata list? Is double linefill > actually safe to use in r3p0? > No. it is _not_ safe on EXYNOS4210. Since L2C-310 ERRTA, current EXYNOS4210 cannot enable double linefill feature and as Siarhei said, need to check its version of L2C-310 in Cache ID register before enabling it. As a note, it's possible to enable it on EXYNOS4212 SoC and in opposite of Siarhei's patch, enabling WRAP read is better on it. Actually my colleague, Boojin Kim is testing it so that can submit it soon. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: convert boot_params to atag_offset
Tushar Behera wrote: > > Based on "ARM: introduce atag_offset to replace boot_params" > by Nicolas Pitre (2bb9839e312ed55a6d5824ffa6077ce3d7d63b1e). > > Since boot_params variable is deleted from machine_desc, the variable > is modified in the newer board files. > > CC: Nicolas Pitre > Signed-off-by: Tushar Behera > --- > This is required when Kukjin's for-next branch is merged with > Russell's devel-stable branch. > > Nicolas's patchset already has changes for other EXYNSO4 based boards. > > arch/arm/mach-exynos4/mach-origen.c |2 +- > arch/arm/mach-exynos4/mach-smdk4212.c |2 +- > arch/arm/mach-exynos4/mach-smdkv310.c |2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-exynos4/mach-origen.c b/arch/arm/mach-exynos4/mach- > origen.c > index ed59f86..b5f6f38 100644 > --- a/arch/arm/mach-exynos4/mach-origen.c > +++ b/arch/arm/mach-exynos4/mach-origen.c > @@ -100,7 +100,7 @@ static void __init origen_machine_init(void) > > MACHINE_START(ORIGEN, "ORIGEN") > /* Maintainer: JeongHyeon Kim */ > - .boot_params= S5P_PA_SDRAM + 0x100, > + .atag_offset= 0x100, > .init_irq = exynos4_init_irq, > .map_io = origen_map_io, > .init_machine = origen_machine_init, > diff --git a/arch/arm/mach-exynos4/mach-smdk4212.c b/arch/arm/mach- > exynos4/mach-smdk4212.c > index 3479a93..8c41ae1 100644 > --- a/arch/arm/mach-exynos4/mach-smdk4212.c > +++ b/arch/arm/mach-exynos4/mach-smdk4212.c > @@ -284,7 +284,7 @@ static void __init smdk4212_machine_init(void) > > MACHINE_START(SMDK4212, "SMDK4212") > /* Maintainer: Kukjin Kim */ > - .boot_params= S5P_PA_SDRAM + 0x100, > + .atag_offset= 0x100, > .init_irq = exynos4_init_irq, > .map_io = smdk4212_map_io, > .init_machine = smdk4212_machine_init, > diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach- > exynos4/mach-smdkv310.c > index 57cf632..7ce4d8b 100644 > --- a/arch/arm/mach-exynos4/mach-smdkv310.c > +++ b/arch/arm/mach-exynos4/mach-smdkv310.c > @@ -344,7 +344,7 @@ MACHINE_END > > MACHINE_START(SMDKC210, "SMDKC210") > /* Maintainer: Kukjin Kim */ > - .boot_params= S5P_PA_SDRAM + 0x100, > + .atag_offset= 0x100, > .init_irq = exynos4_init_irq, > .map_io = smdkv310_map_io, > .init_machine = smdkv310_machine_init, > -- > 1.7.4.1 Hi Tushar, Yes you're right and actually, I received the same information from Stephen when he merges my -next the end of last month. Anyway, if above fixing is required on my -next, will apply this. Thanks :) Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH V2] ARM: EXYNOS4: Add machine support for 7" LCD on ORIGEN
Tushar Behera wrote:
>
> ORIGEN board is fitted with 7" LCD panel HV070WSA. The pixel
> resolution of the LCD panel is 1024x600.
>
> Also power domain device for LCD0 is registered.
>
> Signed-off-by: Tushar Behera
> ---
> Changes for V2:
> * Added power domain device registration for LCD0
>
> The patch is rebased on [1]. For proper working of LCD on ORIGEN,
> following patches are needed. These patches are already submitted to
> the mailing list.
>
> a. ARM: EXYNOS4: Add PWM backlight support on Origen
> Author: Giridhar Maruthy
As I said, it is already in my tree.
> b. ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
> Author: Inderpal Singh
Will review it.
(snip)
> +
> +static struct s3c_fb_pd_win origen_fb_win0 = {
> + .win_mode = {
> + .left_margin= 64,
> + .right_margin = 16,
> + .upper_margin = 64,
> + .lower_margin = 16,
> + .hsync_len = 48,
> + .vsync_len = 3,
> + .xres = 1024,
> + .yres = 600,
> + .refresh= 60,
We don't need to add '.refresh' here because its default value is 60.
> + },
> + .max_bpp= 32,
> + .default_bpp= 24,
> +};
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH V2] ARM: EXYNOS4: Add machine support for 7" LCD on ORIGEN
Tushar Behera wrote:
>
> Hi Fabio,
>
> On Wednesday 14 September 2011 05:06 PM, Fabio Estevam wrote:
> > On Wed, Sep 14, 2011 at 8:01 AM, Tushar Behera
> wrote:
> > ...
> >> +static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
> power)
> >> +{
> >> + int gpio = EXYNOS4_GPE3(4);
> >> +
> >> + gpio_request(gpio, "GPE3_4");
> >> + gpio_direction_output(gpio, power);
> >
> > You should check for returned errors for these functions.
> >
> Ok.
>
> Will this be better?
>
> static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, \
No need '\'
> unsigned int power)
> {
> int ret;
> unsigned long flag = power ? GPIOF_OUT_INIT_HIGH : \
Same as above.
> GPIOF_OUT_INIT_LOW;
>
> ret = gpio_request_one(EXYNOS4_GPE3(4), flag, "GPE3_4");
>
> if (ret)
> printk(KERN_ERR "Could not request gpio for LCD power");
> }
How about following?
if (power)
ret = gpio_request_one(EXYNOS4_GPE3(4), GPIOF_OUT_INIT_HIGH,
"GPE3_4");
else
ret = gpio_request_one(EXYNOS4_GPE3(4), GPIOF_OUT_INIT_LOW,
"GPE3_4");
if (ret)
pr_err("failed to request gpio for LCD power: %d\n", ret);
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH V4] ARM: EXYNOS4: Add machine support for 7" LCD on ORIGEN
Tushar Behera wrote:
>
> Dear Wolfgang Denk,
>
> On Thursday 15 September 2011 02:44 PM, Wolfgang Denk wrote:
> > Dear Tushar Behera,
> >
> > In message<1316076867-2138-1-git-send-email-tushar.beh...@linaro.org>
you
> wrote:
> >> ORIGEN board is fitted with 7" LCD panel HV070WSA. The pixel
> >> resolution of the LCD panel is 1024x600.
> > ...
> >> +static struct s3c_fb_pd_win origen_fb_win0 = {
> >> + .win_mode = {
> >> + .left_margin= 64,
> >> + .right_margin = 16,
> >> + .upper_margin = 64,
> >> + .lower_margin = 16,
> >> + .hsync_len = 48,
> >> + .vsync_len = 3,
> >> + .xres = 1024,
> >> + .yres = 600,
> >> + },
> >> + .max_bpp= 32,
> >> + .default_bpp= 24,
> >> +};
> >
> > Does it still make sense to hard-code such parameters?
> >
> > In PowerPC-land we pass display mode information in the device tree
> > using a verbatim EDID block.
> >
> > Would it be not better (and way more flexible) to do the same here,
> > now that ARM has device tree support?
> >
> Thanks for your suggestions.
>
> Currently work for enabling device tree support for EXYNOS4 based
> machine is going on. Once it is done, we should be able to pass this
> information through device tree blob.
>
> For non-DT machines, IMHO, we have to follow the current approach.
OK, applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Add keypad support for Origen
Sachin Kamat wrote:
>
> This patch adds keypad support for Origen board as GPIO keys.
>
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/mach-exynos4/mach-origen.c | 58
> +++
> 1 files changed, 58 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index ed59f86..61da36b 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -79,10 +80,67 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
> __initdata = {
> .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> };
>
> +static struct gpio_keys_button origen_gpio_keys_table[] = {
> + {
> + .code = KEY_MENU,
If you're ok, will change tab between '.code' and '=', I think it would be
better to read code.
> + .gpio = EXYNOS4_GPX1(5),
> + .desc = "gpio-keys: KEY_MENU",
> + .type = EV_KEY,
> + .active_low = 1,
> + .wakeup = 1,
> + .debounce_interval = 1,
> + }, {
> + .code = KEY_HOME,
> + .gpio = EXYNOS4_GPX1(6),
> + .desc = "gpio-keys: KEY_HOME",
> + .type = EV_KEY,
> + .active_low = 1,
> + .wakeup = 1,
> + .debounce_interval = 1,
> + }, {
> + .code = KEY_BACK,
> + .gpio = EXYNOS4_GPX1(7),
> + .desc = "gpio-keys: KEY_BACK",
> + .type = EV_KEY,
> + .active_low = 1,
> + .wakeup = 1,
> + .debounce_interval = 1,
> + }, {
> + .code = KEY_UP,
> + .gpio = EXYNOS4_GPX2(0),
> + .desc = "gpio-keys: KEY_UP",
> + .type = EV_KEY,
> + .active_low = 1,
> + .wakeup = 1,
> + .debounce_interval = 1,
> + }, {
> + .code = KEY_DOWN,
> + .gpio = EXYNOS4_GPX2(1),
> + .desc = "gpio-keys: KEY_DOWN",
> + .type = EV_KEY,
> + .active_low = 1,
> + .wakeup = 1,
> + .debounce_interval = 1,
> + },
> +};
> +
> +static struct gpio_keys_platform_data origen_gpio_keys_data = {
> + .buttons = origen_gpio_keys_table,
> + .nbuttons = ARRAY_SIZE(origen_gpio_keys_table),
> +};
> +
> +static struct platform_device origen_device_gpiokeys = {
> + .name = "gpio-keys",
> + .dev = {
> + .platform_data = &origen_gpio_keys_data,
> + },
> +};
> +
> static struct platform_device *origen_devices[] __initdata = {
> &s3c_device_hsmmc2,
> &s3c_device_rtc,
> &s3c_device_wdt,
> + &origen_device_gpiokeys,
> };
>
> static void __init origen_map_io(void)
> --
> 1.7.4.1
Looks ok to me, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Add header file protection macros
Sachin Kamat wrote:
>
> This patch adds header file protection macros to prevent duplication.
>
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/mach-exynos4/include/mach/pm-core.h |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/include/mach/pm-core.h b/arch/arm/mach-
> exynos4/include/mach/pm-core.h
> index 1df3b81..4c3406b 100644
> --- a/arch/arm/mach-exynos4/include/mach/pm-core.h
> +++ b/arch/arm/mach-exynos4/include/mach/pm-core.h
> @@ -14,6 +14,10 @@
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> +
> +#ifndef __ASM_ARCH_PM_CORE_H
> +#define __ASM_ARCH_PM_CORE_H __FILE__
> +
> #include
>
> static inline void s3c_pm_debug_init_uart(void)
> @@ -57,3 +61,5 @@ static inline void s3c_pm_saved_gpios(void)
> {
> /* nothing here yet */
> }
> +
> +#endif /* __ASM_ARCH_PM_CORE_H */
> --
> 1.7.4.1
OK, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] gpio/samsung: Move SoC specific codes within macro
Grant Likely wrote:
>
> On Mon, Oct 03, 2011 at 08:59:19AM +0530, Tushar Behera wrote:
> > In drivers/gpio/gpio-samsung.c, there are certain structures
> > and functions which are not getting used if the particular
> > CPU is not selected. These code segments are moved under CPU
> > specific macros to remove compilation warnings.
> >
> > Signed-off-by: Tushar Behera
>
> Acked-by: Grant Likely
>
When I applied, following error was happened with s5p64x0_defconfig. Others,
ok.
...
Inconsistent kallsyms data
This is a bug - please report about it
Try make KALLSYMS_EXTRA_PASS=1 as a workaround
make: *** [vmlinux] Error 1
And it seems due to add condition around the 'static unsigned
s3c24xx_gpio_getcfg_abank()'.
I need to check it in detail and if any problems, let you know.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> > ---
> > It has been build tested with s3c2410_defconfig, s3c6400_defconfig,
> > s5p64x0_defconfig, s5pc100_defconfig, s5pv210_defconfig and
> > exynos4_defconfig.
> >
> > The patch has been rebased onto
> > Commit: gpio/samsung: correct pin configuration for
> S5PC100/S5PC110/EXYNOS4
> >
> > on git://github.com/kgene/linux-samsung.git (next/topic-gpio-samsung)
> >
> > drivers/gpio/gpio-samsung.c | 10 ++
> > 1 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
> > index b6be77a..33d62d1 100644
> > --- a/drivers/gpio/gpio-samsung.c
> > +++ b/drivers/gpio/gpio-samsung.c
> > @@ -318,6 +318,7 @@ static unsigned samsung_gpio_getcfg_4bit(struct
> samsung_gpio_chip *chip,
> > return S3C_GPIO_SPECIAL(con);
> > }
> >
> > +#ifdef CONFIG_PLAT_S3C24XX
> > /*
> > * s3c24xx_gpio_setcfg_abank - S3C24XX style GPIO configuration (Bank
A)
> > * @chip: The gpio chip that is being configured.
> > @@ -379,7 +380,9 @@ static unsigned s3c24xx_gpio_getcfg_abank(struct
> samsung_gpio_chip *chip,
> >
> > return S3C_GPIO_SFN(con);
> > }
> > +#endif
> >
> > +#if defined(CONFIG_CPU_S5P6440) || defined(CONFIG_CPU_S5P6450)
> > static int s5p64x0_gpio_setcfg_rbank(struct samsung_gpio_chip *chip,
> > unsigned int off, unsigned int cfg)
> > {
> > @@ -417,6 +420,7 @@ static int s5p64x0_gpio_setcfg_rbank(struct
> samsung_gpio_chip *chip,
> >
> > return 0;
> > }
> > +#endif
> >
> > static void __init samsung_gpiolib_set_cfg(struct samsung_gpio_cfg
*chipcfg,
> >int nr_chips)
> > @@ -438,10 +442,12 @@ struct samsung_gpio_cfg s3c24xx_gpiocfg_default =
> {
> > .get_config = samsung_gpio_getcfg_2bit,
> > };
> >
> > +#ifdef CONFIG_PLAT_S3C24XX
> > static struct samsung_gpio_cfg s3c24xx_gpiocfg_banka = {
> > .set_config = s3c24xx_gpio_setcfg_abank,
> > .get_config = s3c24xx_gpio_getcfg_abank,
> > };
> > +#endif
> >
> > static struct samsung_gpio_cfg exynos4_gpio_cfg = {
> > .set_pull = exynos4_gpio_setpull,
> > @@ -450,6 +456,7 @@ static struct samsung_gpio_cfg exynos4_gpio_cfg = {
> > .get_config = samsung_gpio_getcfg_4bit,
> > };
> >
> > +#if defined(CONFIG_CPU_S5P6440) || defined(CONFIG_CPU_S5P6450)
> > static struct samsung_gpio_cfg s5p64x0_gpio_cfg_rbank = {
> > .cfg_eint = 0x3,
> > .set_config = s5p64x0_gpio_setcfg_rbank,
> > @@ -457,6 +464,7 @@ static struct samsung_gpio_cfg
> s5p64x0_gpio_cfg_rbank = {
> > .set_pull = samsung_gpio_setpull_updown,
> > .get_pull = samsung_gpio_getpull_updown,
> > };
> > +#endif
> >
> > static struct samsung_gpio_cfg samsung_gpio_cfgs[] = {
> > {
> > @@ -682,6 +690,7 @@ static int samsung_gpiolib_4bit2_output(struct
gpio_chip
> *chip,
> > return 0;
> > }
> >
> > +#ifdef CONFIG_PLAT_S3C24XX
> > /* The next set of routines are for the case of s3c24xx bank a */
> >
> > static int s3c24xx_gpiolib_banka_input(struct gpio_chip *chip, unsigned
offset)
> > @@ -717,6 +726,7 @@ static int s3c24xx_gpiolib_banka_output(struct
> gpio_chip *chip,
> > local_irq_restore(flags);
> > return 0;
> > }
> > +#endif
> >
> > /* The next set of routines are for the case of s5p64x0 bank r */
> >
> > --
> > 1.7.4.1
> >
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] gpio/samsung: Move SoC specific codes within macro
Kukjin Kim wrote: > > Grant Likely wrote: > > > > On Mon, Oct 03, 2011 at 08:59:19AM +0530, Tushar Behera wrote: > > > In drivers/gpio/gpio-samsung.c, there are certain structures > > > and functions which are not getting used if the particular > > > CPU is not selected. These code segments are moved under CPU > > > specific macros to remove compilation warnings. > > > > > > Signed-off-by: Tushar Behera > > > > Acked-by: Grant Likely > > > When I applied, following error was happened with s5p64x0_defconfig. Others, ok. > > ... > Inconsistent kallsyms data > This is a bug - please report about it > Try make KALLSYMS_EXTRA_PASS=1 as a workaround > make: *** [vmlinux] Error 1 > > And it seems due to add condition around the 'static unsigned > s3c24xx_gpio_getcfg_abank()'. > > I need to check it in detail and if any problems, let you know. > There is no above problem now in my -next. Applied. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Enable Bluetooth on ORIGEN
Sangwook Lee wrote:
>
> This patch enables Bluetooth support on ORIGEN board.
>
> Signed-off-by: Sangwook
> ---
> arch/arm/mach-exynos4/mach-origen.c | 32
>
> 1 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index f80b563..f8c50d7 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -232,6 +233,7 @@ static struct regulator_init_data __initdata
> max8997_ldo9_data = {
> .min_uV = 280,
> .max_uV = 280,
> .apply_uV = 1,
> + .always_on = 1,
> .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> .state_mem = {
> .disabled = 1,
> @@ -275,6 +277,7 @@ static struct regulator_init_data __initdata
> max8997_ldo14_data = {
> .min_uV = 180,
> .max_uV = 180,
> .apply_uV = 1,
> + .always_on = 1,
> .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> .state_mem = {
> .disabled = 1,
> @@ -290,6 +293,7 @@ static struct regulator_init_data __initdata
> max8997_ldo17_data = {
> .min_uV = 330,
> .max_uV = 330,
> .apply_uV = 1,
> + .always_on = 1,
> .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> .state_mem = {
> .disabled = 1,
> @@ -588,6 +592,21 @@ static struct s3c_fb_platdata origen_lcd_pdata
__initdata
> = {
> .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
> };
>
> +/* Bluetooth rfkill gpio platform data */
> +struct rfkill_gpio_platform_data origen_bt_pdata = {
> + .reset_gpio = EXYNOS4_GPX2(2),
> + .shutdown_gpio = -1,
> + .type = RFKILL_TYPE_BLUETOOTH,
> + .name = "origen-bt",
> +};
> +
> +/* Bluetooth Platform device */
> +static struct platform_device origen_device_bluetooth = {
> + .name = "rfkill_gpio",
> + .id = -1,
> + .dev.platform_data = &origen_bt_pdata,
> +};
> +
> static struct platform_device *origen_devices[] __initdata = {
> &s3c_device_hsmmc2,
> &s3c_device_hsmmc0,
> @@ -615,6 +634,7 @@ static struct platform_device *origen_devices[]
__initdata =
> {
> &exynos4_device_pd[PD_MFC],
> &origen_device_gpiokeys,
> &origen_lcd_hv070wsa,
> + &origen_device_bluetooth,
> };
>
> /* LCD Backlight data */
> @@ -628,6 +648,16 @@ static struct platform_pwm_backlight_data
> origen_bl_data = {
> .pwm_period_ns = 1000,
> };
>
> +static void __init origen_bt_setup(void)
> +{
> + gpio_request(EXYNOS4_GPA0(0), "GPIO BT_UART");
> + /* 4 UART Pins configuration */
> + s3c_gpio_cfgrange_nopull(EXYNOS4_GPA0(0), 4, S3C_GPIO_SFN(2));
> + /* Setup BT Reset, this gpio will be requesed by rfkill-gpio */
> + s3c_gpio_cfgpin(EXYNOS4_GPX2(2), S3C_GPIO_OUTPUT);
> + s3c_gpio_setpull(EXYNOS4_GPX2(2), S3C_GPIO_PULL_NONE);
> +}
> +
> static void s5p_tv_setup(void)
> {
> /* Direct HPD to HDMI chip */
> @@ -687,6 +717,8 @@ static void __init origen_machine_init(void)
> s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
>
> samsung_bl_set(&origen_bl_gpio_info, &origen_bl_data);
> +
> + origen_bt_setup();
> }
>
> MACHINE_START(ORIGEN, "ORIGEN")
> --
> 1.7.4.1
Applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 1/2] ARM: SAMSUNG: Add pm_caps into platform data
Sangwook Lee wrote:
>
> Add pm_caps into platform_data. This is power management, usually
> for SDIO device such as SDIO WLAN.
>
> Signed-off-by: Sangwook Lee
> ---
> arch/arm/plat-samsung/dev-hsmmc3.c |2 ++
> arch/arm/plat-samsung/include/plat/sdhci.h |2 ++
> 2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/dev-hsmmc3.c
b/arch/arm/plat-samsung/dev-
> hsmmc3.c
> index ede776f..8f467f2 100644
> --- a/arch/arm/plat-samsung/dev-hsmmc3.c
> +++ b/arch/arm/plat-samsung/dev-hsmmc3.c
> @@ -78,6 +78,8 @@ void s3c_sdhci3_set_platdata(struct s3c_sdhci_platdata
*pd)
> set->cfg_card = pd->cfg_card;
> if (pd->host_caps)
> set->host_caps |= pd->host_caps;
> + if (pd->pm_caps)
> + set->pm_caps |= pd->pm_caps;
> if (pd->clk_type)
> set->clk_type = pd->clk_type;
> }
> diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-
> samsung/include/plat/sdhci.h
> index 058e096..35646de 100644
> --- a/arch/arm/plat-samsung/include/plat/sdhci.h
> +++ b/arch/arm/plat-samsung/include/plat/sdhci.h
> @@ -40,6 +40,7 @@ enum clk_types {
> * struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
> * @max_width: The maximum number of data bits supported.
> * @host_caps: Standard MMC host capabilities bit field.
> + * @pm_caps: SDIO host PM capabilities bit field.
> * @cd_type: Type of Card Detection method (see cd_types enum above)
> * @clk_type: Type of clock divider method (see clk_types enum above)
> * @ext_cd_init: Initialize external card detect subsystem. Called on
> @@ -67,6 +68,7 @@ enum clk_types {
> struct s3c_sdhci_platdata {
> unsigned intmax_width;
> unsigned inthost_caps;
> + unsigned intpm_caps;
> enum cd_types cd_type;
> enum clk_types clk_type;
>
> --
> 1.7.4.1
Hi Sangwook,
I think you need to re-work based on latest my for-next.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 2/2] mmc: sdhci-s3c: Add pm_caps into SD/MMC host
Sangwook Lee wrote: > > sdhci-s3c updates pm_caps from platform data for SDIO PM. > > Signed-off-by: Sangwook Lee Acked-by: Kukjin Kim Hi Chris, Could you please pick this up in your tree for v3.3? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > --- > drivers/mmc/host/sdhci-s3c.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c > index fe886d6..f10dd52 100644 > --- a/drivers/mmc/host/sdhci-s3c.c > +++ b/drivers/mmc/host/sdhci-s3c.c > @@ -518,6 +518,9 @@ static int __devinit sdhci_s3c_probe(struct > platform_device *pdev) > if (pdata->host_caps) > host->mmc->caps |= pdata->host_caps; > > + if (pdata->pm_caps) > + host->mmc->pm_caps |= pdata->pm_caps; > + > host->quirks |= (SDHCI_QUIRK_32BIT_DMA_ADDR | >SDHCI_QUIRK_32BIT_DMA_SIZE); > > -- > 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 0/3] Moving xusbxti clock setting in clock.c file.
Pankaj Dubey wrote: > > Since there is code duplication in different mach-board.c file it is > better > to set default clock rate of xusbxti clock in plat-s5p/clock.c file. > > The patches are based on following commit on Kukjin's for-next branch. > > Pankaj (1): > ARM: S5P: Set default rate of xusbxti clock > > Pankaj Dubey (2): > ARM: EXYNOS: Removed code for setting clock rate of xusbxti > ARM: S5PV210: Removed code for setting clock rate of xusbxti 'Pankaj' and 'Pankaj Dubey'? > > arch/arm/mach-exynos/mach-nuri.c |1 - > arch/arm/mach-exynos/mach-origen.c |1 - > arch/arm/mach-exynos/mach-smdk4x12.c |2 -- > arch/arm/mach-exynos/mach-smdkv310.c |1 - > arch/arm/mach-s5pv210/mach-goni.c|1 - > arch/arm/plat-s5p/clock.c|1 + > 6 files changed, 1 insertions(+), 6 deletions(-) > > -- > 1.7.4.1 No, the clock can be different for each board even though current value is same. So it should being at the each board file. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 1/2] DMA: PL330: Remove pm_runtime_xxx calls from pl330 probe/remove
Vinod Koul wrote:
>
> On Tue, 2011-12-06 at 16:15 +0530, Tushar Behera wrote:
> > amba_probe() now calls pm_runtime_get_noresume() and pm_runtime_enable()
> > for the devices before the device probe is called. Hence we don't need
> > to call pm_runtime_get_xxx and pm_runtime_enable() in device probe again.
> > In the same way, since amba_remove() calls the respective pm_runtime
> > functions, those functions need not be called from device remove.
> >
> > This patch fixes following run time error with pl330 driver.
> >
> > dma-pl330 dma-pl330.0: Unbalanced pm_runtime_enable!
> > dma-pl330 dma-pl330.0: failed to get runtime pm
> >
> > Signed-off-by: Giridhar Maruthy
> > Signed-off-by: Tushar Behera
> Looks fine to me. Do you want these to go thru slave-dma or samsung
> tree.
Hi Vinod,
I think, this patch can be sent to upstream via slave-dma tree and second one
via Samsung tree separately and you can add my and Boojin Kim's ack(actually,
she replied) on this when you apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> For latter:
> Acked-by: Vinod Koul
>
> > ---
> > drivers/dma/pl330.c | 17 ++---
> > 1 files changed, 2 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> > index a626e15..cd07121 100644
> > --- a/drivers/dma/pl330.c
> > +++ b/drivers/dma/pl330.c
> > @@ -834,17 +834,7 @@ pl330_probe(struct amba_device *adev, const struct
> > amba_id *id)
> >
> > amba_set_drvdata(adev, pdmac);
> >
> > -#ifdef CONFIG_PM_RUNTIME
> > - /* to use the runtime PM helper functions */
> > - pm_runtime_enable(&adev->dev);
> > -
> > - /* enable the power domain */
> > - if (pm_runtime_get_sync(&adev->dev)) {
> > - dev_err(&adev->dev, "failed to get runtime pm\n");
> > - ret = -ENODEV;
> > - goto probe_err1;
> > - }
> > -#else
> > +#ifndef CONFIG_PM_RUNTIME
> > /* enable dma clk */
> > clk_enable(pdmac->clk);
> > #endif
> > @@ -977,10 +967,7 @@ static int __devexit pl330_remove(struct amba_device
> > *adev)
> > res = &adev->res;
> > release_mem_region(res->start, resource_size(res));
> >
> > -#ifdef CONFIG_PM_RUNTIME
> > - pm_runtime_put(&adev->dev);
> > - pm_runtime_disable(&adev->dev);
> > -#else
> > +#ifndef CONFIG_PM_RUNTIME
> > clk_disable(pdmac->clk);
> > #endif
> >
>
>
> --
> ~Vinod
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 2/2] ARM: EXYNOS: Add apb_pclk clkdev entry for mdma1
Tushar Behera wrote:
>
> Amba core assumes the pclk to be named as apb_pclk. During device probe,
> it tries to get that clock and enable that. When PM_RUNTIME is enabled,
> dma clock is not explicitly enabled in pl330_probe, which causes device
> probe to fail. Adding a clkdev entry for apb_pclk for mdma1 fixes the
> problem.
>
> This patch fixes following runtime error.
>
> dma-pl330 dma-pl330.2: PERIPH_ID 0x0, PCELL_ID 0x0 !
> dma-pl330: probe of dma-pl330.2 failed with error -22
>
> Signed-off-by: Tushar Behera
> ---
> arch/arm/mach-exynos/clock.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
> index 28e2842..eb33a7a 100644
> --- a/arch/arm/mach-exynos/clock.c
> +++ b/arch/arm/mach-exynos/clock.c
> @@ -1326,6 +1326,7 @@ static struct clk_lookup exynos4_clk_lookup[] = {
> CLKDEV_INIT("s3c-sdhci.3", "mmc_busclk.2", &clk_sclk_mmc3.clk),
> CLKDEV_INIT("dma-pl330.0", "apb_pclk", &clk_pdma0),
> CLKDEV_INIT("dma-pl330.1", "apb_pclk", &clk_pdma1),
> + CLKDEV_INIT("dma-pl330.2", "apb_pclk", &clk_mdma1),
> };
>
> static int xtal_rate;
> --
> 1.7.4.1
Looks ok to me, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 5/5] ARM: exynos: enable/disable cpuidle when cpu1 is down/up
Daniel Lezcano wrote: > > On 01/10/2013 11:33 PM, amit daniel kachhap wrote: > > On Thu, Jan 10, 2013 at 1:32 PM, Daniel Lezcano > wrote: > >> On 01/10/2013 09:07 PM, amit daniel kachhap wrote: > >>> Hi Daniel, > >> > >> Hi Amit Daniel, > >> > >>> This hotplug noifiers looks fine. I suppose it should add extra state > >>> C1 in cpu0. If it is done like below than for normal cases(when all > >>> cpu's are online) there wont be any statistics for C0 state > >> > >> I guess you meant state 0 which is WFI, right ? > >> C0 state is the intel semantic for cpu fully turned on. > > Yes I meant C0 as wfi > >> > >>> also which > >>> is required. Other patches look good. > >> > >> Ok, that makes sense to have statistics even if they are only doing WFI. > >> > >> Then the patch 4/5 is not ok, no ? > > yes I suppose patch 4 and patch 5 are related and depends how you > > frame patch 5. I think it is better to create C0/C1 sysfs and other > > things in the beginning because it is a filesystem call and may > > increase the cpu hotplug time which is not worth. May be if cpuidle > > framework exposes some API to enable/disable states then it is better. > > > > For patch 1,2 and 3, > > Acked-by: Amit Daniel Kachhap > > Hi Kukjin, > > is it possible to take these patches [1-3/5] ? > Looks OK to me, I will apply with Amit's ack. > The patches [3-4/5] could be ignored. > Probably, you mean [4-5/5] :-) Thanks. - Kukjin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: SAMSUNG: Add support for clock debugging through debug-fs interface
amit.dan...@samsung.com wrote:
>
Maybe missed set name in your e-mail client.
> From: Amit Daniel Kachhap
>
> This patch adds support for clock information exposed to debug-fs
> interface.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
> arch/arm/plat-samsung/clock.c | 92
>
> arch/arm/plat-samsung/include/plat/clock.h |3 +
> 2 files changed, 95 insertions(+), 0 deletions(-)
>
Please add Ben Dooks in Cc next time.
> diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-samsung/clock.c
> index e8d20b0..0ba209d 100644
> --- a/arch/arm/plat-samsung/clock.c
> +++ b/arch/arm/plat-samsung/clock.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -447,3 +448,94 @@ int __init s3c24xx_register_baseclocks(unsigned long
> xtal)
> return 0;
> }
>
> +#if defined(CONFIG_DEBUG_FS)
> +/*
> + * debugfs support to trace clock tree hierarchy and attributes
> + */
One line comment format/style is "/* ... */"
> +static struct dentry *clk_debugfs_root;
> +
> +static int clk_debugfs_register_one(struct clk *c)
> +{
> + int err;
> + struct dentry *d, *child, *child_tmp;
> + struct clk *pa = c->parent;
> + char s[255];
> + char *p = s;
> +
> + p += sprintf(p, "%s", c->name);
> +#ifdef CONFIG_PLAT_SAMSUNG
> + /*Append id field with name also*/
> + if (c->id >= 0)
> + p += sprintf(p, ":%d", c->id);
Not more used p...so just sprint(p,...);
> +#endif
Actually this file(plat-samsung/clock.c) already depends on
CONFIG_PLAT_SAMSUNG.
> +
> + d = debugfs_create_dir(s, pa ? pa->dent : clk_debugfs_root);
> + if (!d)
> + return -ENOMEM;
> +
> + c->dent = d;
> +
> + d = debugfs_create_u8("usecount", S_IRUGO, c->dent, (u8
*)&c->usage);
> + if (!d) {
> + err = -ENOMEM;
> + goto err_out;
> + }
> + d = debugfs_create_u32("rate", S_IRUGO, c->dent, (u32 *)&c->rate);
> + if (!d) {
> + err = -ENOMEM;
> + goto err_out;
> + }
> + return 0;
> +
Could you please show demo sample on board?
> +err_out:
> + d = c->dent;
> + list_for_each_entry_safe(child, child_tmp, &d->d_subdirs,
d_u.d_child)
> + debugfs_remove(child);
> + debugfs_remove(c->dent);
> + return err;
> +}
> +
> +static int clk_debugfs_register(struct clk *c)
> +{
> + int err;
> + struct clk *pa = c->parent;
> +
> + if (pa && !pa->dent) {
> + err = clk_debugfs_register(pa);
> + if (err)
> + return err;
> + }
> +
> + if (!c->dent) {
> + err = clk_debugfs_register_one(c);
> + if (err)
> + return err;
> + }
> + return 0;
> +}
> +
> +static int __init clk_debugfs_init(void)
> +{
> + struct clk *c;
> + struct dentry *d;
> + int err;
> +
> + d = debugfs_create_dir("clock", NULL);
> + if (!d)
> + return -ENOMEM;
> + clk_debugfs_root = d;
> +
> + list_for_each_entry(c, &clocks, list) {
> + err = clk_debugfs_register(c);
> + if (err)
> + goto err_out;
> + }
> + return 0;
> +err_out:
> + debugfs_remove_recursive(clk_debugfs_root);
> + return err;
> +}
> +late_initcall(clk_debugfs_init);
> +
> +#endif /* defined(CONFIG_DEBUG_FS) */
> +
> diff --git a/arch/arm/plat-samsung/include/plat/clock.h b/arch/arm/plat-
> samsung/include/plat/clock.h
> index 0fbcd0e..f6180ab 100644
> --- a/arch/arm/plat-samsung/include/plat/clock.h
> +++ b/arch/arm/plat-samsung/include/plat/clock.h
> @@ -47,6 +47,9 @@ struct clk {
>
> struct clk_ops *ops;
> int (*enable)(struct clk *, int enable);
> +#if defined(CONFIG_DEBUG_FS)
> + struct dentry *dent; /* For visible tree hierarchy */
> +#endif
> };
>
> /* other clocks which may be registered by board support */
> --
I think, you just copied this from omap.
Of course, there is small changes...
I mean, would be better, if you could add more useful debug-fs i/f for
Samsung SoCs' clock.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH V2] ARM: SAMSUNG: Add support for clock debugging through debug-fs interface
Amit Daniel Kachhap wrote:
>
> This patch adds support for clock information exposed to debug-fs
interface.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
> Code modified for V2 version are,
> a)Inserted the debug-fs code inside macro CONFIG_PM_DEBUG as suggested by
> yong.s...@linaro.org.
Could you please let me know why?
> b)Removed macro CONFIG_PLAT_SAMSUNG and implemented other coding standards
> as suggested by kgene@samsung.com
>
> arch/arm/plat-samsung/clock.c | 91
>
> arch/arm/plat-samsung/include/plat/clock.h |3 +
> 2 files changed, 94 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-samsung/clock.c
> index e8d20b0..029a49d 100644
> --- a/arch/arm/plat-samsung/clock.c
> +++ b/arch/arm/plat-samsung/clock.c
> @@ -39,6 +39,9 @@
> #include
> #include
> #include
> +#if defined(CONFIG_DEBUG_FS)
> +#include
> +#endif
>
> #include
> #include
> @@ -447,3 +450,91 @@ int __init s3c24xx_register_baseclocks(unsigned long
> xtal)
> return 0;
> }
>
> +#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
Hmm...please let me know the reason...
> +/* debugfs support to trace clock tree hierarchy and attributes */
> +
> +static struct dentry *clk_debugfs_root;
> +
> +static int clk_debugfs_register_one(struct clk *c)
> +{
> + int err;
> + struct dentry *d, *child, *child_tmp;
> + struct clk *pa = c->parent;
> + char s[255];
> + char *p = s;
> +
> + p += sprintf(p, "%s", c->name);
> + /*Append id field with name also*/
No need above comment. If required, please add other comments also.
> + if (c->id >= 0)
> + sprintf(p, ":%d", c->id);
> +
> + d = debugfs_create_dir(s, pa ? pa->dent : clk_debugfs_root);
> + if (!d)
> + return -ENOMEM;
> +
> + c->dent = d;
> +
> + d = debugfs_create_u8("usecount", S_IRUGO, c->dent, (u8
*)&c->usage);
> + if (!d) {
> + err = -ENOMEM;
> + goto err_out;
> + }
1 empty line would be helpful to read.
> + d = debugfs_create_u32("rate", S_IRUGO, c->dent, (u32 *)&c->rate);
> + if (!d) {
> + err = -ENOMEM;
> + goto err_out;
> + }
> + return 0;
> +
> +err_out:
> + d = c->dent;
> + list_for_each_entry_safe(child, child_tmp, &d->d_subdirs,
d_u.d_child)
> + debugfs_remove(child);
> + debugfs_remove(c->dent);
> + return err;
> +}
> +
> +static int clk_debugfs_register(struct clk *c)
> +{
> + int err;
> + struct clk *pa = c->parent;
> +
> + if (pa && !pa->dent) {
> + err = clk_debugfs_register(pa);
> + if (err)
> + return err;
> + }
> +
> + if (!c->dent) {
> + err = clk_debugfs_register_one(c);
> + if (err)
> + return err;
> + }
> + return 0;
> +}
> +
> +static int __init clk_debugfs_init(void)
> +{
> + struct clk *c;
> + struct dentry *d;
> + int err;
> +
> + d = debugfs_create_dir("clock", NULL);
> + if (!d)
> + return -ENOMEM;
> + clk_debugfs_root = d;
> +
> + list_for_each_entry(c, &clocks, list) {
> + err = clk_debugfs_register(c);
> + if (err)
> + goto err_out;
> + }
> + return 0;
> +err_out:
> + debugfs_remove_recursive(clk_debugfs_root);
> + return err;
> +}
> +late_initcall(clk_debugfs_init);
> +
> +#endif /* defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS) */
> +
No need last one empty line.
> diff --git a/arch/arm/plat-samsung/include/plat/clock.h b/arch/arm/plat-
> samsung/include/plat/clock.h
> index 0fbcd0e..9a82b88 100644
> --- a/arch/arm/plat-samsung/include/plat/clock.h
> +++ b/arch/arm/plat-samsung/include/plat/clock.h
> @@ -47,6 +47,9 @@ struct clk {
>
> struct clk_ops *ops;
> int (*enable)(struct clk *, int enable);
> +#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> + struct dentry *dent; /* For visible tree hierarchy */
> +#endif
> };
>
> /* other clocks which may be registered by board support */
> --
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH V2] ARM: SAMSUNG: Add support for clock debugging through debug-fs interface
Amit Daniel Kachhap wrote:
>
> Hi Mr Kim,
>
> Thanks for your comments. Please see the inline comments below.
>
Hi Amit,
I didn't get your updated patch, but it was small things.
So I applied this in my tree for this merge window.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> On 1 December 2010 13:08, Kukjin Kim wrote:
> >
> > Amit Daniel Kachhap wrote:
> > >
> > > This patch adds support for clock information exposed to debug-fs
> > interface.
> > >
> > > Signed-off-by: Amit Daniel Kachhap
> > > ---
> > > Code modified for V2 version are,
> > > a)Inserted the debug-fs code inside macro CONFIG_PM_DEBUG as suggested
by
> > > yong.s...@linaro.org.
> >
> > Could you please let me know why?
> Actually this patch is mostly taken from omap architecture, so using
> this macro in addition
> to CONFIG_DEBUG_FS macro. Also it is better to enable all PM debugging
> features with
> one configuration parameter.
>
> >
> > > b)Removed macro CONFIG_PLAT_SAMSUNG and implemented other coding
> standards
> > > as suggested by kgene@samsung.com
> > >
> > > arch/arm/plat-samsung/clock.c | 91
> > >
> > > arch/arm/plat-samsung/include/plat/clock.h | 3 +
> > > 2 files changed, 94 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-
> samsung/clock.c
> > > index e8d20b0..029a49d 100644
> > > --- a/arch/arm/plat-samsung/clock.c
> > > +++ b/arch/arm/plat-samsung/clock.c
> > > @@ -39,6 +39,9 @@
> > > #include
> > > #include
> > > #include
> > > +#if defined(CONFIG_DEBUG_FS)
> > > +#include
> > > +#endif
> > >
> > > #include
> > > #include
> > > @@ -447,3 +450,91 @@ int __init s3c24xx_register_baseclocks(unsigned
long
> > > xtal)
> > > return 0;
> > > }
> > >
> > > +#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> >
> > Hmm...please let me know the reason...
> same reason as above.
> >
> > > +/* debugfs support to trace clock tree hierarchy and attributes */
> > > +
> > > +static struct dentry *clk_debugfs_root;
> > > +
> > > +static int clk_debugfs_register_one(struct clk *c)
> > > +{
> > > + int err;
> > > + struct dentry *d, *child, *child_tmp;
> > > + struct clk *pa = c->parent;
> > > + char s[255];
> > > + char *p = s;
> > > +
> > > + p += sprintf(p, "%s", c->name);
> > > + /*Append id field with name also*/
> >
> > No need above comment. If required, please add other comments also.
> ok, will remove this comment in next patch.
> >
> > > + if (c->id >= 0)
> > > + sprintf(p, ":%d", c->id);
> > > +
> > > + d = debugfs_create_dir(s, pa ? pa->dent : clk_debugfs_root);
> > > + if (!d)
> > > + return -ENOMEM;
> > > +
> > > + c->dent = d;
> > > +
> > > + d = debugfs_create_u8("usecount", S_IRUGO, c->dent, (u8
> > *)&c->usage);
> > > + if (!d) {
> > > + err = -ENOMEM;
> > > + goto err_out;
> > > + }
> >
> > 1 empty line would be helpful to read.
> ok, will update this in next patch.
> >
> > > + d = debugfs_create_u32("rate", S_IRUGO, c->dent, (u32
*)&c->rate);
> > > + if (!d) {
> > > + err = -ENOMEM;
> > > + goto err_out;
> > > + }
> > > + return 0;
> > > +
> > > +err_out:
> > > + d = c->dent;
> > > + list_for_each_entry_safe(child, child_tmp, &d->d_subdirs,
> > d_u.d_child)
> > > + debugfs_remove(child);
> > > + debugfs_remove(c->dent);
> > > + return err;
> > > +}
> > > +
> > > +static int clk_debugfs_register(struct clk *c)
> > > +{
> > > + int err;
> > > + struct clk *pa = c->parent;
> > > +
> > > + if (pa && !pa->dent) {
> > > + err = clk_debugfs_register(pa);
> > > + if (err)
> > > + return err;
> > > + }
> > > +
> > &g
RE: [PATCH] ARM: EXYNOS4: Fix addruart macro
Thomas Abraham wrote: > > Fix incorrect conditional execution of ldr instructions in > addruart macro. > Oops :( Ok, will apply:) As a note, I found same patch with this in your previous patches. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Register HSMMC2 before HSMMC0 on SMDKV310 board
Tushar Behera wrote:
>
> On Exynos4210 SOC, of all the HSMMC controllers only HSMMC2 can
> be used as a boot media. Hence the default SD/MMC card should be
> connected to HSMMC2. The secondary card is connected to HSMMC0.
>
> If HSMMC0 is registered before HSMMC2, the device node for default
> MMC card changes depending on whether secondary card is connected
> or not. It creates problem in mounting the file-system present in
> default SD/MMC card. Hence HSMMC2 should be registered before HSMMC0.
>
> Signed-off-by: Tushar Behera
> ---
> arch/arm/mach-exynos4/mach-smdkv310.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
> exynos4/mach-smdkv310.c
> index f6b1c7e..4f34d43 100644
> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> @@ -168,9 +168,9 @@ static struct i2c_board_info i2c_devs1[] __initdata =
{
> };
>
> static struct platform_device *smdkv310_devices[] __initdata = {
> + &s3c_device_hsmmc2,
> &s3c_device_hsmmc0,
> &s3c_device_hsmmc1,
> - &s3c_device_hsmmc2,
> &s3c_device_hsmmc3,
> &s3c_device_i2c1,
> &s3c_device_rtc,
> --
> 1.7.1
Hmm...I can understand your pointing out and situation.
But as you know, channel 4 also can be used for boot media when eMMC booting
and SMDKV310 can support it by jumper setting.
I mean it can be modified according to each board's situation for mass
production and we don't need this for SMDK in mainline now.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2] ARM: S5P: Fix compilation error for exynos4_defconfig
On 06/03/11 00:04, Tushar Behera wrote:
Added Kconfig entry for setup-usb-phy.c on which EHCI support is
dependent on.
Following the naming convention of other setup files, we have following
renaming.
usb-phy.c ==> setup-usb-phy.c
Signed-off-by: Tushar Behera
---
arch/arm/mach-exynos4/Kconfig |6 ++
arch/arm/mach-exynos4/Makefile |2 +-
.../mach-exynos4/{usb-phy.c => setup-usb-phy.c}|0
3 files changed, 7 insertions(+), 1 deletions(-)
rename arch/arm/mach-exynos4/{usb-phy.c => setup-usb-phy.c} (100%)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index b92c1e5..a45a022 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -91,6 +91,11 @@ config EXYNOS4_SETUP_FIMC
help
Common setup code for the camera interfaces.
+config EXYNOS4_SETUP_USB_PHY
+ bool
+ help
+ Common setup code for USB PHY controller
+
# machine support
menu "EXYNOS4 Machines"
@@ -176,6 +181,7 @@ config MACH_NURI
select EXYNOS4_SETUP_I2C3
select EXYNOS4_SETUP_I2C5
select EXYNOS4_SETUP_SDHCI
+ select EXYNOS4_SETUP_USB_PHY
select SAMSUNG_DEV_PWM
help
Machine support for Samsung Mobile NURI Board.
diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index a9bb94f..60fe5ec 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -56,4 +56,4 @@ obj-$(CONFIG_EXYNOS4_SETUP_KEYPAD)+= setup-keypad.o
obj-$(CONFIG_EXYNOS4_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_EXYNOS4_SETUP_SDHCI_GPIO)+= setup-sdhci-gpio.o
-obj-$(CONFIG_USB_SUPPORT) += usb-phy.o
+obj-$(CONFIG_EXYNOS4_SETUP_USB_PHY)+= setup-usb-phy.o
diff --git a/arch/arm/mach-exynos4/usb-phy.c
b/arch/arm/mach-exynos4/setup-usb-phy.c
similarity index 100%
rename from arch/arm/mach-exynos4/usb-phy.c
rename to arch/arm/mach-exynos4/setup-usb-phy.c
I think, basically, the setup-usbphy.c would be in plat-s5p/ because
s5p_usb_phy_{init,exit} is called from plat-s5p/dev-echi.c and need to
separate exynos(mach-) and common s5p(plat-) stuff so that can be used
from other s5p usb to control usb phy.
Since it is not used for others so will apply this to fix build error.
However, we need to sort this out later.
Tushar, you don't need to re-submit this for removing white space :)
But as you know, please make sure that your patch has no problem with
checkpatch.pl before submitting.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
