Re: [PATCH] ARM: dts: Add USB host node for Exynos4
On Wednesday, July 24, 2013 3:29 PM, Dongjin Kim wrote:
>
> +Jingoo Han
>
> Sorry, its my bad. Typo problem.
>
> I found another patch same with mine,
> https://patchwork.kernel.org/patch/2628451, submitted by Jingoo Han
> and tested on Exynos4210. Mine is tested on Exynos4412. Both SoC have
> same USB host address space, so I think USB host device nodes can be
> placed in exynos4.dtsi.
OK, USB host device nodes can be placed in exynos4.dtsi.
However, next time, please leave comment on earlier patch.
The patch for Exynos4210 USB was already submitted 2 months ago.
>
> Regards,
> Dongjin.
>
> On Wed, Jul 24, 2013 at 12:38 PM, Sachin Kamat
> wrote:
> > On 23 July 2013 23:02, Dongjin Kim wrote:
> >> This patch adds EHCI and OHCI host device nodes for Exynos4.
> >>
> >> Signed-off-by: Dongjin Kim
> >> ---
> >> arch/arm/boot/dts/exynos4.dtsi | 20
> >> 1 file changed, 20 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos4.dtsi
> >> b/arch/arm/boot/dts/exynos4.dtsi
> >> index 3f94fe8..1cdbf89 100644
> >> --- a/arch/arm/boot/dts/exynos4.dtsi
> >> +++ b/arch/arm/boot/dts/exynos4.dtsi
> >> @@ -155,6 +155,26 @@
> >> status = "disabled";
> >> };
> >>
> >> + ehci@1258 {
> >> + compatible = "samsung,exynos4210-ehci";
> >> + reg = <0x1258 0x100>;
> >> + interrupts = <0 70 0>;
> >> + status = "disabled";
> >> +
> >> + clocks = <&clock 304>;
> >> + clock-names = "usbhost";
> >> + };
> >> +
> >> + ohci@1259 {
> >> + compatible = "samsung,exynos4210-ohci";
> >> + reg = <0x1258 0x100>;
> >
> > Register value and node name do not match. Typo?
> >
> >
> >> + interrupts = <0 70 0>;
> >> + status = "disabled";
> >> +
> >> + clocks = <&clock 304>;
> >> + clock-names = "usbhost";
> >> + };
> >> +
> >> mfc: codec@1340 {
> >> compatible = "samsung,mfc-v5";
> >> reg = <0x1340 0x1>;
> >> --
> >> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add USB host node for Exynos4
+Jingoo Han
Sorry, its my bad. Typo problem.
I found another patch same with mine,
https://patchwork.kernel.org/patch/2628451, submitted by Jingoo Han
and tested on Exynos4210. Mine is tested on Exynos4412. Both SoC have
same USB host address space, so I think USB host device nodes can be
placed in exynos4.dtsi.
Regards,
Dongjin.
On Wed, Jul 24, 2013 at 12:38 PM, Sachin Kamat wrote:
> On 23 July 2013 23:02, Dongjin Kim wrote:
>> This patch adds EHCI and OHCI host device nodes for Exynos4.
>>
>> Signed-off-by: Dongjin Kim
>> ---
>> arch/arm/boot/dts/exynos4.dtsi | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
>> index 3f94fe8..1cdbf89 100644
>> --- a/arch/arm/boot/dts/exynos4.dtsi
>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>> @@ -155,6 +155,26 @@
>> status = "disabled";
>> };
>>
>> + ehci@1258 {
>> + compatible = "samsung,exynos4210-ehci";
>> + reg = <0x1258 0x100>;
>> + interrupts = <0 70 0>;
>> + status = "disabled";
>> +
>> + clocks = <&clock 304>;
>> + clock-names = "usbhost";
>> + };
>> +
>> + ohci@1259 {
>> + compatible = "samsung,exynos4210-ohci";
>> + reg = <0x1258 0x100>;
>
> Register value and node name do not match. Typo?
>
>
>> + interrupts = <0 70 0>;
>> + status = "disabled";
>> +
>> + clocks = <&clock 304>;
>> + clock-names = "usbhost";
>> + };
>> +
>> mfc: codec@1340 {
>> compatible = "samsung,mfc-v5";
>> reg = <0x1340 0x1>;
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> With warm regards,
> Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
On 24 July 2013 11:50, Kukjin Kim wrote:
> Sachin Kamat wrote:
>>
>> With the recent cleanup in Exynos platform code notably commits
>> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
>> more") and b910 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
>> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
>> Exynos4412 which have more than the default number of GPIOs. Thus define
>> this number in KConfig file which takes care of current SoC requirements
>> and provides scope for GPIO expanders. Without this patch we get the
>> following
>> errors during boot:
>>
>> gpiochip_add: gpios 251..258 (gpv0) failed to register
>> samsung-pinctrl 106e.pinctrl: failed to register gpio_chip gpv0,
>> error code: -22
>> samsung-pinctrl: probe of 106e.pinctrl failed with error -22
>>
>> Signed-off-by: Sachin Kamat
>> Cc: Tomasz Figa
>> ---
>> Changes since v2:
>> Changed the default number to 512 to accomodate GPIO exapnders.
>> ---
>> arch/arm/Kconfig |1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index ccc388d..b3c4fa4 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1601,6 +1601,7 @@ config ARCH_NR_GPIO
>> int
>> default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
>> default 512 if SOC_OMAP5
>> + default 512 if ARCH_EXYNOS
>> default 512 if ARCH_KEYSTONE
>
> + default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 ?
Looks good. Do you want me to re-send this?
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
Sachin Kamat wrote:
>
> With the recent cleanup in Exynos platform code notably commits
> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
> more") and b910 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
> Exynos4412 which have more than the default number of GPIOs. Thus define
> this number in KConfig file which takes care of current SoC requirements
> and provides scope for GPIO expanders. Without this patch we get the
> following
> errors during boot:
>
> gpiochip_add: gpios 251..258 (gpv0) failed to register
> samsung-pinctrl 106e.pinctrl: failed to register gpio_chip gpv0,
> error code: -22
> samsung-pinctrl: probe of 106e.pinctrl failed with error -22
>
> Signed-off-by: Sachin Kamat
> Cc: Tomasz Figa
> ---
> Changes since v2:
> Changed the default number to 512 to accomodate GPIO exapnders.
> ---
> arch/arm/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ccc388d..b3c4fa4 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1601,6 +1601,7 @@ config ARCH_NR_GPIO
> int
> default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
> default 512 if SOC_OMAP5
> + default 512 if ARCH_EXYNOS
> default 512 if ARCH_KEYSTONE
+ default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 ?
Thanks,
Kukjin
> default 392 if ARCH_U8500
> default 352 if ARCH_VT8500
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add USBPHY nodes to Exynos4x12
On 24 July 2013 11:29, Dongjin Kim wrote:
> Thanks Sachin,
>
> On Wed, Jul 24, 2013 at 2:12 PM, Sachin Kamat wrote:
>> Hi Dongjin,
>>
>> On 23 July 2013 23:01, Dongjin Kim wrote:
>>> This patch adds device nodes for USBPHY to Exynos4x12.
>>>
>>> Signed-off-by: Dongjin Kim
>>> ---
>>> arch/arm/boot/dts/exynos4x12.dtsi | 18 ++
>>> 1 file changed, 18 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index 01da194..9c3335b 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -73,4 +73,22 @@
>>> clock-names = "sclk_fimg2d", "fimg2d";
>>> status = "disabled";
>>> };
>>> +
>>> + usbphy@125B0 {
>>
>> Extra 0 above.
>>
> This is my bad, I will fix.
>
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "samsung,exynos4x12-usb2phy";
>>> + reg = <0x125B 0x100>;
>>> + ranges;
>>> +
>>> + clocks = <&clock 2>, <&clock 305>;
>>> + clock-names = "xusbxti", "otg";
>>> + status = "disabled";
>>> +
>>> + usbphy-sys {
>>> + /* USB device and host PHY_CONTROL registers */
>>> + reg = <0x10020704 0xc>,
>>> + <0x1001021c 0x4>;
>>> + };
>>> + };
>>> };
>>
>> Please add this node after tmu node (satisfies alphabetical order as
>> well as increasing address value)
> No tmu node in exynos4x12.dtsi in mainline v3.11-rc2 yet, even in
> Kukjin's branch.
Sorry, that patch is not yet applied to for-next. I will re-send
again. You may ignore this comment for now.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] ARM: EXYNOS: cpuidle: Allow C1 state only in supported SOC's.
Hi, On Wed, Jul 24, 2013 at 10:45 AM, Kukjin Kim wrote: > Amit Daniel Kachhap wrote: >> >> This patch registers the basic C0 state for all exynos SOC's but >> limits the C1(AFTR -Arm off top running) state in only the supported >> SOC's(ie. EXYNOS 4210, 4212, 4412 and 5250). >> >> Signed-off-by: Amit Daniel Kachhap >> --- >> arch/arm/mach-exynos/cpuidle.c |4 +++- >> 1 files changed, 3 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach- >> exynos/cpuidle.c >> index 2d071c6..ccb2b48 100644 >> --- a/arch/arm/mach-exynos/cpuidle.c >> +++ b/arch/arm/mach-exynos/cpuidle.c >> @@ -176,7 +176,9 @@ static int __init exynos4_init_cpuidle(void) >> device->cpu = cpu_id; >> >> /* Support IDLE only */ >> - if (cpu_id != 0) >> + if (!(soc_is_exynos4210() || soc_is_exynos4212() || >> + soc_is_exynos4412() || soc_is_exynos5250()) || >> + cpu_id != 0) > > How about exynos5420? > > So... > > + if (soc_is_exynos5440() || cpu_id !=0) ? This is fine. Thanks, Amit > >> device->state_count = 1; >> >> ret = cpuidle_register_device(device); >> -- >> 1.7.1 > > - Kukjin > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add USBPHY nodes to Exynos4x12
Thanks Sachin,
On Wed, Jul 24, 2013 at 2:12 PM, Sachin Kamat wrote:
> Hi Dongjin,
>
> On 23 July 2013 23:01, Dongjin Kim wrote:
>> This patch adds device nodes for USBPHY to Exynos4x12.
>>
>> Signed-off-by: Dongjin Kim
>> ---
>> arch/arm/boot/dts/exynos4x12.dtsi | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 01da194..9c3335b 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -73,4 +73,22 @@
>> clock-names = "sclk_fimg2d", "fimg2d";
>> status = "disabled";
>> };
>> +
>> + usbphy@125B0 {
>
> Extra 0 above.
>
This is my bad, I will fix.
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "samsung,exynos4x12-usb2phy";
>> + reg = <0x125B 0x100>;
>> + ranges;
>> +
>> + clocks = <&clock 2>, <&clock 305>;
>> + clock-names = "xusbxti", "otg";
>> + status = "disabled";
>> +
>> + usbphy-sys {
>> + /* USB device and host PHY_CONTROL registers */
>> + reg = <0x10020704 0xc>,
>> + <0x1001021c 0x4>;
>> + };
>> + };
>> };
>
> Please add this node after tmu node (satisfies alphabetical order as
> well as increasing address value)
No tmu node in exynos4x12.dtsi in mainline v3.11-rc2 yet, even in
Kukjin's branch.
>
>
> --
> With warm regards,
> Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] ARM: SAMSUNG: Add SAMSUNG_PM config option to select pm
On Wed, Jul 24, 2013 at 10:24 AM, Kukjin Kim wrote:
> Amit Daniel Kachhap wrote:
>>
>> This patch enables the selection of samsung pm related stuffs
>> when SAMSUNG_PM config is enabled and not just when generic PM
>> config is enabled. Power management for s3c64XX and s3c24XX
>> is enabled by default and for other platform depends on S5P_PM.
>> This patch also fixes the following compilation error's when compiling
>> a platform like exynos5440 which does not select pm stuffs.
>>
>> arch/arm/mach-exynos/built-in.o: In function `__virt_to_phys':
>> linux/arch/arm/include/asm/memory.h:175: undefined reference to
>> `s3c_cpu_resume'
>> linux/arch/arm/include/asm/memory.h:175: undefined reference to
>> `s3c_cpu_resume'
>> linux/arch/arm/include/asm/memory.h:175: undefined reference to
>> `s3c_cpu_resume'
>> linux/arch/arm/include/asm/memory.h:175: undefined reference to
>> `s3c_cpu_resume'
>> arch/arm/mach-exynos/built-in.o: In function `exynos5_init_irq':
>> linux/arch/arm/mach-exynos/common.c:492: undefined reference to
>> `s3c_irq_wake'
>> linux/arch/arm/mach-exynos/common.c:492: undefined reference to
>> `s3c_irq_wake'
>> arch/arm/mach-exynos/built-in.o: In function `exynos4_init_irq':
>> linux/arch/arm/mach-exynos/common.c:476: undefined reference to
>> `s3c_irq_wake'
>> linux/arch/arm/mach-exynos/common.c:476: undefined reference to
>> `s3c_irq_wake'
>> arch/arm/plat-samsung/built-in.o: In function `s3c_irqext_wake':
>> linux/arch/arm/plat-samsung/pm.c:144: undefined reference to
>> `s3c_irqwake_eintallow'
>> linux/arch/arm/plat-samsung/pm.c:144: undefined reference to
>> `s3c_irqwake_eintallow'
>> arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
>> linux/arch/arm/plat-samsung/pm.c:263: undefined reference to
>> `s3c_irqwake_intallow'
>> linux/arch/arm/plat-samsung/pm.c:263: undefined reference to
>> `s3c_irqwake_intallow'
>> linux/arch/arm/plat-samsung/pm.c:264: undefined reference to
>> `s3c_irqwake_eintallow'
>> linux/arch/arm/plat-samsung/pm.c:264: undefined reference to
>> `s3c_irqwake_eintallow'
>> linux/arch/arm/plat-samsung/pm.c:275: undefined reference to
>> `s3c_pm_save_core'
>> linux/arch/arm/plat-samsung/pm.c:279: undefined reference to
>> `s3c_pm_configure_extint'
>> linux/arch/arm/plat-samsung/pm.c:310: undefined reference to
>> `s3c_pm_restore_core'
>> make: *** [vmlinux] Error 1
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> arch/arm/mach-exynos/Makefile |2 +-
>> arch/arm/mach-exynos/common.c |2 +-
>> arch/arm/mach-exynos/common.h |1 -
>> arch/arm/mach-exynos/cpuidle.c |1 +
>> arch/arm/plat-samsung/Kconfig |7 +++
>> arch/arm/plat-samsung/Makefile |3 +--
>> arch/arm/plat-samsung/include/plat/pm.h |8
>> 7 files changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
>> index 9811f87..3fa277a 100644
>> --- a/arch/arm/mach-exynos/Makefile
>> +++ b/arch/arm/mach-exynos/Makefile
>> @@ -14,7 +14,7 @@ obj-:=
>>
>> obj-$(CONFIG_ARCH_EXYNOS)+= common.o
>>
>> -obj-$(CONFIG_PM) += pm.o
>> +obj-$(CONFIG_S5P_PM) += pm.o
>> obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
>> obj-$(CONFIG_CPU_IDLE) += cpuidle.o
>>
>> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
>> index 9834357..d2b4f54 100644
>> --- a/arch/arm/mach-exynos/common.c
>> +++ b/arch/arm/mach-exynos/common.c
>> @@ -799,7 +799,7 @@ static struct irq_chip exynos_irq_eint = {
>> .irq_mask_ack = exynos_irq_eint_maskack,
>> .irq_ack= exynos_irq_eint_ack,
>> .irq_set_type = exynos_irq_eint_set_type,
>> -#ifdef CONFIG_PM
>> +#ifdef CONFIG_S5P_PM
>> .irq_set_wake = s3c_irqext_wake,
>> #endif
>> };
>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>> index 11fc1e2..f2b2e23 100644
>> --- a/arch/arm/mach-exynos/common.h
>> +++ b/arch/arm/mach-exynos/common.h
>> @@ -98,6 +98,5 @@ struct exynos_pmu_conf {
>> };
>>
>> extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
>> -extern void s3c_cpu_resume(void);
>>
>> #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
>> exynos/cpuidle.c
>> index 4667907..2d071c6 100644
>> --- a/arch/arm/mach-exynos/cpuidle.c
>> +++ b/arch/arm/mach-exynos/cpuidle.c
>> @@ -25,6 +25,7 @@
>> #include
>>
>> #include
>> +#include
>>
>> #include "common.h"
>>
>> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
>> index f8ed2de..6c25aa6 100644
>> --- a/arch/arm/plat-samsung/Kconfig
>> +++ b/arch/arm/plat-samsung/Kconfig
>> @@ -31,6 +31,13 @@ config PLAT_S5P
>> help
>> Base platform code for Samsung's S5P series SoC.
>>
>> +config SAMSUNG_PM
>> + bool
>> + depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || S5P_PM)
>
> As we discussed before, this should be
RE: [PATCH V2 2/2] ARM: EXYNOS: cpuidle: Allow C1 state only in supported SOC's.
Amit Daniel Kachhap wrote: > > This patch registers the basic C0 state for all exynos SOC's but > limits the C1(AFTR -Arm off top running) state in only the supported > SOC's(ie. EXYNOS 4210, 4212, 4412 and 5250). > > Signed-off-by: Amit Daniel Kachhap > --- > arch/arm/mach-exynos/cpuidle.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach- > exynos/cpuidle.c > index 2d071c6..ccb2b48 100644 > --- a/arch/arm/mach-exynos/cpuidle.c > +++ b/arch/arm/mach-exynos/cpuidle.c > @@ -176,7 +176,9 @@ static int __init exynos4_init_cpuidle(void) > device->cpu = cpu_id; > > /* Support IDLE only */ > - if (cpu_id != 0) > + if (!(soc_is_exynos4210() || soc_is_exynos4212() || > + soc_is_exynos4412() || soc_is_exynos5250()) || > + cpu_id != 0) How about exynos5420? So... + if (soc_is_exynos5440() || cpu_id !=0) ? > device->state_count = 1; > > ret = cpuidle_register_device(device); > -- > 1.7.1 - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add USBPHY nodes to Exynos4x12
Hi Dongjin,
On 23 July 2013 23:01, Dongjin Kim wrote:
> This patch adds device nodes for USBPHY to Exynos4x12.
>
> Signed-off-by: Dongjin Kim
> ---
> arch/arm/boot/dts/exynos4x12.dtsi | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 01da194..9c3335b 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -73,4 +73,22 @@
> clock-names = "sclk_fimg2d", "fimg2d";
> status = "disabled";
> };
> +
> + usbphy@125B0 {
Extra 0 above.
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "samsung,exynos4x12-usb2phy";
> + reg = <0x125B 0x100>;
> + ranges;
> +
> + clocks = <&clock 2>, <&clock 305>;
> + clock-names = "xusbxti", "otg";
> + status = "disabled";
> +
> + usbphy-sys {
> + /* USB device and host PHY_CONTROL registers */
> + reg = <0x10020704 0xc>,
> + <0x1001021c 0x4>;
> + };
> + };
> };
Please add this node after tmu node (satisfies alphabetical order as
well as increasing address value)
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 1/2] ARM: SAMSUNG: Add SAMSUNG_PM config option to select pm
Amit Daniel Kachhap wrote:
>
> This patch enables the selection of samsung pm related stuffs
> when SAMSUNG_PM config is enabled and not just when generic PM
> config is enabled. Power management for s3c64XX and s3c24XX
> is enabled by default and for other platform depends on S5P_PM.
> This patch also fixes the following compilation error's when compiling
> a platform like exynos5440 which does not select pm stuffs.
>
> arch/arm/mach-exynos/built-in.o: In function `__virt_to_phys':
> linux/arch/arm/include/asm/memory.h:175: undefined reference to
> `s3c_cpu_resume'
> linux/arch/arm/include/asm/memory.h:175: undefined reference to
> `s3c_cpu_resume'
> linux/arch/arm/include/asm/memory.h:175: undefined reference to
> `s3c_cpu_resume'
> linux/arch/arm/include/asm/memory.h:175: undefined reference to
> `s3c_cpu_resume'
> arch/arm/mach-exynos/built-in.o: In function `exynos5_init_irq':
> linux/arch/arm/mach-exynos/common.c:492: undefined reference to
> `s3c_irq_wake'
> linux/arch/arm/mach-exynos/common.c:492: undefined reference to
> `s3c_irq_wake'
> arch/arm/mach-exynos/built-in.o: In function `exynos4_init_irq':
> linux/arch/arm/mach-exynos/common.c:476: undefined reference to
> `s3c_irq_wake'
> linux/arch/arm/mach-exynos/common.c:476: undefined reference to
> `s3c_irq_wake'
> arch/arm/plat-samsung/built-in.o: In function `s3c_irqext_wake':
> linux/arch/arm/plat-samsung/pm.c:144: undefined reference to
> `s3c_irqwake_eintallow'
> linux/arch/arm/plat-samsung/pm.c:144: undefined reference to
> `s3c_irqwake_eintallow'
> arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
> linux/arch/arm/plat-samsung/pm.c:263: undefined reference to
> `s3c_irqwake_intallow'
> linux/arch/arm/plat-samsung/pm.c:263: undefined reference to
> `s3c_irqwake_intallow'
> linux/arch/arm/plat-samsung/pm.c:264: undefined reference to
> `s3c_irqwake_eintallow'
> linux/arch/arm/plat-samsung/pm.c:264: undefined reference to
> `s3c_irqwake_eintallow'
> linux/arch/arm/plat-samsung/pm.c:275: undefined reference to
> `s3c_pm_save_core'
> linux/arch/arm/plat-samsung/pm.c:279: undefined reference to
> `s3c_pm_configure_extint'
> linux/arch/arm/plat-samsung/pm.c:310: undefined reference to
> `s3c_pm_restore_core'
> make: *** [vmlinux] Error 1
>
> Signed-off-by: Amit Daniel Kachhap
> ---
> arch/arm/mach-exynos/Makefile |2 +-
> arch/arm/mach-exynos/common.c |2 +-
> arch/arm/mach-exynos/common.h |1 -
> arch/arm/mach-exynos/cpuidle.c |1 +
> arch/arm/plat-samsung/Kconfig |7 +++
> arch/arm/plat-samsung/Makefile |3 +--
> arch/arm/plat-samsung/include/plat/pm.h |8
> 7 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
> index 9811f87..3fa277a 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -14,7 +14,7 @@ obj-:=
>
> obj-$(CONFIG_ARCH_EXYNOS)+= common.o
>
> -obj-$(CONFIG_PM) += pm.o
> +obj-$(CONFIG_S5P_PM) += pm.o
> obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
> obj-$(CONFIG_CPU_IDLE) += cpuidle.o
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 9834357..d2b4f54 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -799,7 +799,7 @@ static struct irq_chip exynos_irq_eint = {
> .irq_mask_ack = exynos_irq_eint_maskack,
> .irq_ack= exynos_irq_eint_ack,
> .irq_set_type = exynos_irq_eint_set_type,
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_S5P_PM
> .irq_set_wake = s3c_irqext_wake,
> #endif
> };
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index 11fc1e2..f2b2e23 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -98,6 +98,5 @@ struct exynos_pmu_conf {
> };
>
> extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
> -extern void s3c_cpu_resume(void);
>
> #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> exynos/cpuidle.c
> index 4667907..2d071c6 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -25,6 +25,7 @@
> #include
>
> #include
> +#include
>
> #include "common.h"
>
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index f8ed2de..6c25aa6 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -31,6 +31,13 @@ config PLAT_S5P
> help
> Base platform code for Samsung's S5P series SoC.
>
> +config SAMSUNG_PM
> + bool
> + depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || S5P_PM)
As we discussed before, this should be:
+ depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5P64X0 ||
S5P_PM)
If not, build error happens with s5p64x0_defconfig. So I fixed.
> + default
RE: [PATCH] ARM: dts: Add basic dts for Exynos4412-based Trats 2 board
Tomasz Figa wrote: > > This patch introduces device tree sources for Samsung Trats 2 board > based on Exynos4412 SoC. > > Currently support includes: > - eMMC, > - main PMIC (max77686), > - serial ports, > - GPIO keys, > - touchscreen. > > Signed-off-by: Tomasz Figa > Signed-off-by: Kyungmin Park > --- > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/exynos4412-trats2.dts | 456 > > 2 files changed, 457 insertions(+) > create mode 100644 arch/arm/boot/dts/exynos4412-trats2.dts > Looks good to me, applied. > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 1357510..8cdc7cc 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ > exynos4412-odroidx.dtb \ > exynos4412-smdk4412.dtb \ > exynos4412-origen.dtb \ > + exynos4412-trats2.dtb \ > exynos5250-arndale.dtb \ > exynos5440-sd5v1.dtb \ > exynos5250-smdk5250.dtb \ BTW, I put some dtbs in wrong order :( I need to sort out... Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: re-ordering exynos dtbs in Makefile
Re-ordering in alphabetical. Signed-off-by: Kukjin Kim --- arch/arm/boot/dts/Makefile |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 641b3c9..ad340e4 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -53,13 +53,13 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ exynos4210-trats.dtb \ exynos4210-universal_c210.dtb \ exynos4412-odroidx.dtb \ - exynos4412-smdk4412.dtb \ exynos4412-origen.dtb \ + exynos4412-smdk4412.dtb \ exynos5250-arndale.dtb \ - exynos5440-sd5v1.dtb \ exynos5250-smdk5250.dtb \ exynos5250-snow.dtb \ exynos5420-smdk5420.dtb \ + exynos5440-sd5v1.dtb \ exynos5440-ssdk5440.dtb dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \ ecx-2000.dtb -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
With the recent cleanup in Exynos platform code notably commits
17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
more") and b910 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
Exynos4412 which have more than the default number of GPIOs. Thus define
this number in KConfig file which takes care of current SoC requirements
and provides scope for GPIO expanders. Without this patch we get the following
errors during boot:
gpiochip_add: gpios 251..258 (gpv0) failed to register
samsung-pinctrl 106e.pinctrl: failed to register gpio_chip gpv0,
error code: -22
samsung-pinctrl: probe of 106e.pinctrl failed with error -22
Signed-off-by: Sachin Kamat
Cc: Tomasz Figa
---
Changes since v2:
Changed the default number to 512 to accomodate GPIO exapnders.
---
arch/arm/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ccc388d..b3c4fa4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1601,6 +1601,7 @@ config ARCH_NR_GPIO
int
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
default 512 if SOC_OMAP5
+ default 512 if ARCH_EXYNOS
default 512 if ARCH_KEYSTONE
default 392 if ARCH_U8500
default 352 if ARCH_VT8500
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add USB host node for Exynos4
On 23 July 2013 23:02, Dongjin Kim wrote:
> This patch adds EHCI and OHCI host device nodes for Exynos4.
>
> Signed-off-by: Dongjin Kim
> ---
> arch/arm/boot/dts/exynos4.dtsi | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index 3f94fe8..1cdbf89 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -155,6 +155,26 @@
> status = "disabled";
> };
>
> + ehci@1258 {
> + compatible = "samsung,exynos4210-ehci";
> + reg = <0x1258 0x100>;
> + interrupts = <0 70 0>;
> + status = "disabled";
> +
> + clocks = <&clock 304>;
> + clock-names = "usbhost";
> + };
> +
> + ohci@1259 {
> + compatible = "samsung,exynos4210-ohci";
> + reg = <0x1258 0x100>;
Register value and node name do not match. Typo?
> + interrupts = <0 70 0>;
> + status = "disabled";
> +
> + clocks = <&clock 304>;
> + clock-names = "usbhost";
> + };
> +
> mfc: codec@1340 {
> compatible = "samsung,mfc-v5";
> reg = <0x1340 0x1>;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: EXYNOS: Cleanup common.h file
On 24 July 2013 08:43, Kukjin Kim wrote: > Kukjin Kim wrote: >> >> Sachin Kamat wrote: >> > >> > Remove unused declarations that got left behind subsequent to >> > making Exynos a DT-only platform. >> > >> > Signed-off-by: Sachin Kamat >> > --- >> > arch/arm/mach-exynos/common.h | 41 > --- >> -- >> > >> > 1 file changed, 41 deletions(-) >> > > > [...] > >> > - >> > -struct device_node; >> > - >> > extern struct smp_operations exynos_smp_ops; >> > >> > extern void exynos_cpu_die(unsigned int cpu); >> > -- >> > 1.7.9.5 >> >> Looks good to me, applied into -cleanup. >> > Just note, needed following additionally. > > -struct device_node; > -void combiner_init(void __iomem *combiner_base, struct device_node *np, > - unsigned int max_nr, int irq_base); > - There is already a patch to clean that up [1] submitted earlier as part of combiner cleanup series. Please apply that first or squash it into this one. [1] https://lkml.org/lkml/2013/6/26/296 -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] ARM: EXYNOS: Cleanup common.h file
Kukjin Kim wrote: > > Sachin Kamat wrote: > > > > Remove unused declarations that got left behind subsequent to > > making Exynos a DT-only platform. > > > > Signed-off-by: Sachin Kamat > > --- > > arch/arm/mach-exynos/common.h | 41 --- > -- > > > > 1 file changed, 41 deletions(-) > > [...] > > - > > -struct device_node; > > - > > extern struct smp_operations exynos_smp_ops; > > > > extern void exynos_cpu_die(unsigned int cpu); > > -- > > 1.7.9.5 > > Looks good to me, applied into -cleanup. > Just note, needed following additionally. -struct device_node; -void combiner_init(void __iomem *combiner_base, struct device_node *np, - unsigned int max_nr, int irq_base); - extern struct smp_operations exynos_smp_ops; extern void exynos_cpu_die(unsigned int cpu); --- Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] ARM: EXYNOS: Cleanup common.h file
Sachin Kamat wrote:
>
> Remove unused declarations that got left behind subsequent to
> making Exynos a DT-only platform.
>
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/mach-exynos/common.h | 41
-
>
> 1 file changed, 41 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index c4abde2..7318e62 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -17,7 +17,6 @@
>
> void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1);
> void exynos_init_time(void);
> -extern unsigned long xxti_f, xusbxti_f;
>
> struct map_desc;
> void exynos_init_io(void);
> @@ -25,54 +24,14 @@ void exynos4_restart(enum reboot_mode mode, const char
> *cmd);
> void exynos5_restart(enum reboot_mode mode, const char *cmd);
> void exynos_init_late(void);
>
> -/* ToDo: remove these after migrating legacy exynos4 platforms to dt */
> -void exynos4_clk_init(struct device_node *np, int is_exynos4210, void
> __iomem *reg_base, unsigned long xom);
> -void exynos4_clk_register_fixed_ext(unsigned long, unsigned long);
> -
> void exynos_firmware_init(void);
>
> -void exynos_set_timer_source(u8 channels);
> -
> #ifdef CONFIG_PM_GENERIC_DOMAINS
> int exynos_pm_late_initcall(void);
> #else
> static inline int exynos_pm_late_initcall(void) { return 0; }
> #endif
>
> -#ifdef CONFIG_ARCH_EXYNOS4
> -void exynos4_register_clocks(void);
> -void exynos4_setup_clocks(void);
> -
> -#else
> -#define exynos4_register_clocks()
> -#define exynos4_setup_clocks()
> -#endif
> -
> -#ifdef CONFIG_ARCH_EXYNOS5
> -void exynos5_register_clocks(void);
> -void exynos5_setup_clocks(void);
> -
> -#else
> -#define exynos5_register_clocks()
> -#define exynos5_setup_clocks()
> -#endif
> -
> -#ifdef CONFIG_CPU_EXYNOS4210
> -void exynos4210_register_clocks(void);
> -
> -#else
> -#define exynos4210_register_clocks()
> -#endif
> -
> -#ifdef CONFIG_SOC_EXYNOS4212
> -void exynos4212_register_clocks(void);
> -
> -#else
> -#define exynos4212_register_clocks()
> -#endif
> -
> -struct device_node;
> -
> extern struct smp_operations exynos_smp_ops;
>
> extern void exynos_cpu_die(unsigned int cpu);
> --
> 1.7.9.5
Looks good to me, applied into -cleanup.
Thanks,
Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
Sachin Kamat wrote: [...] > > Hmm, BTW, I'm wondering why it is 288 not 285 or other specific > >>> > >>> > >>> number... > >>> > I wasn't really sure if we can have any number there. I chose the > closest one (288) which was already used by other platform. > If there is no problem to use 285 itself then I can resend with that > number. Please let me know. > >>> > >>> > >>> If there is no reason, please don't use bigger value than necessary > one. > >> > >> > >> Hmm, what about some GPIO expanders that would require bigger GPIO > address > >> space? I would reserve some space just in case, i.e. define this value > to > >> be > >> the highest number of GPIOs on all Exynos SoCs + some extra, like 32 or > >> 64. > > > > > > That sounds like a good idea. IIRC I once had to increase ARCH_NR_GPIO > to > > make the wm8994 GPIO controller working. The wm8994 driver also handles > > WM1811 audio codec that some Exynos development boards are shipped with. > > Looks like a valid point. > > Kukjin, > Let me know your opinion about this before I respin the patch. > Agreed, let's use 512 including some extras, I'm not sure what value for some GPIO expanders is reasonable at this moment, though. It should be fine on current EXYNOS platforms. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] ARM: dts: Hook up IRQ for PMIC on Arndale
Mark Brown wrote:
>
> From: Mark Brown
>
> The out of tree code configures a pullup on the line indicating that it
> is an active low interrupt.
>
> Signed-off-by: Mark Brown
> ---
> arch/arm/boot/dts/exynos5250-arndale.dts | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index abc7272..dab40ae 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -11,6 +11,7 @@
>
> /dts-v1/;
> #include "exynos5250.dtsi"
> +#include
>
> / {
> model = "Insignal Arndale evaluation board based on EXYNOS5250";
> @@ -37,6 +38,8 @@
> s5m8767_pmic@66 {
> compatible = "samsung,s5m8767-pmic";
> reg = <0x66>;
> + interrupt-parent = <&gpx3>;
> + interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
>
> s5m8767,pmic-buck2-dvs-voltage = <130>;
> s5m8767,pmic-buck3-dvs-voltage = <110>;
> --
> 1.8.3.2
I'm fine on this whole series. Applied 1 to 4, thanks.
- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] ARM: dts: Add WM1811A audio CODEC to Arndale bindings
Mark Brown wrote: > > On Tue, Jul 02, 2013 at 10:51:36AM +0530, Tushar Behera wrote: > > > Arndale board also comes with two other audio codec boards - ALC5631Q > > and AK4678. Different audio codec boards came with different shipments. > > This is the default though and since they didn't bother providing any > way of identifying the modules we just have to put them all in the > device tree and hope that the individual CODEC drivers can do runtime > identification (the WM1811A can but I don't know about the other two, > nobody supported them upstream). Basically, I agree with Mark Brown's opinion, at this moment would be better if upstreamed WM1811A could be supported on Arndale and if further supporting of two codecs is required, we could discuss again next time. And they should be identified in the kernel at runtime. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/8] clk: samsung: Add clock driver for S3C64xx SoCs
This patch adds new, Common Clock Framework-based clock driver for Samsung
S3C64xx SoCs. The driver is just added, without actually letting the
platforms use it yet, since this requires more intermediate steps.
Signed-off-by: Tomasz Figa
Acked-by: Mike Turquette
---
.../bindings/clock/samsung,s3c64xx-clock.txt | 77
drivers/clk/samsung/Makefile | 3 +
drivers/clk/samsung/clk-s3c64xx.c | 473 +
include/dt-bindings/clock/samsung,s3c64xx-clock.h | 178
4 files changed, 731 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h
Changes since v2:
- Reworked to use new PLL registration method introduced by Yadwinder
Singh Brar's patch series:
( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
new file mode 100644
index 000..fa171dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
@@ -0,0 +1,77 @@
+* Samsung S3C64xx Clock Controller
+
+The S3C64xx clock controller generates and supplies clock to various
controllers
+within the SoC. The clock binding described here is applicable to all SoCs in
+the S3C64xx family.
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
+ - "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular S3C64xx SoC and this is specified where applicable.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in device
+tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "fin_pll" - PLL input clock (xtal/extclk) - required,
+ - "xusbxti" - USB xtal - required,
+ - "iiscdclk0" - I2S0 codec clock - optional,
+ - "iiscdclk1" - I2S1 codec clock - optional,
+ - "iiscdclk2" - I2S2 codec clock - optional,
+ - "pcmcdclk0" - PCM0 codec clock - optional,
+ - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
+
+Example: Clock controller node:
+
+ clock: clock-controller@7e00f000 {
+ compatible = "samsung,s3c6410-clock";
+ reg = <0x7e00f000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+Example: Required external clocks:
+
+ fin_pll: clock-fin-pll {
+ compatible = "fixed-clock";
+ clock-output-names = "fin_pll";
+ clock-frequency = <1200>;
+ #clock-cells = <0>;
+ };
+
+ xusbxti: clock-xusbxti {
+ compatible = "fixed-clock";
+ clock-output-names = "xusbxti";
+ clock-frequency = <4800>;
+ #clock-cells = <0>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller (refer to the standard clock bindings for information about
+ "clocks" and "clock-names" properties):
+
+ uart0: serial@7f005000 {
+ compatible = "samsung,s3c6400-uart";
+ reg = <0x7f005000 0x100>;
+ interrupt-parent = <&vic1>;
+ interrupts = <5>;
+ clock-names = "uart", "clk_uart_baud2",
+ "clk_uart_baud3";
+ clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>,
+ <&clock SCLK_UART>;
+ status = "disabled";
+ };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 5d4d432..3413380 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
+ifdef CONFIG_COMMON_CLK
+obj-$(CONFIG_ARCH_S3C64XX) += clk-s3c64xx.o
+endif
diff --git a/drivers/clk/samsung/clk-s3c64xx.c
b/drivers/clk/samsung/clk-s3c64xx.c
new file mode 100644
index 000..eeda567
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -0,0 +1,473 @@
+/*
+ * Copyright (c) 2013 Tomasz Figa
+ *
+ * This program is free software; you can redistribute it and/
[PATCH v3 2/8] clk: samsung: pll: Add support for PLL6552 and PLL6553
This patch adds support for PLL6552 and PLL6553 PLLs present on Samsung
S3C64xx SoCs.
Signed-off-by: Tomasz Figa
Acked-by: Mike Turquette
---
drivers/clk/samsung/clk-pll.c | 77 +++
drivers/clk/samsung/clk-pll.h | 2 ++
2 files changed, 79 insertions(+)
Changes since v2:
- Reworked to use new PLL registration method introduced by Yadwinder
Singh Brar's patch series:
( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index f80efb6..7572d1d 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -438,6 +438,77 @@ struct clk * __init samsung_clk_register_pll46xx(const
char *name,
}
/*
+ * PLL6552 Clock Type
+ */
+
+#define PLL6552_MDIV_MASK 0x3ff
+#define PLL6552_PDIV_MASK 0x3f
+#define PLL6552_SDIV_MASK 0x7
+#define PLL6552_MDIV_SHIFT 16
+#define PLL6552_PDIV_SHIFT 8
+#define PLL6552_SDIV_SHIFT 0
+
+static unsigned long samsung_pll6552_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ u32 mdiv, pdiv, sdiv, pll_con;
+ u64 fvco = parent_rate;
+
+ pll_con = __raw_readl(pll->con_reg);
+ mdiv = (pll_con >> PLL6552_MDIV_SHIFT) & PLL6552_MDIV_MASK;
+ pdiv = (pll_con >> PLL6552_PDIV_SHIFT) & PLL6552_PDIV_MASK;
+ sdiv = (pll_con >> PLL6552_SDIV_SHIFT) & PLL6552_SDIV_MASK;
+
+ fvco *= mdiv;
+ do_div(fvco, (pdiv << sdiv));
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6552_clk_ops = {
+ .recalc_rate = samsung_pll6552_recalc_rate,
+};
+
+/*
+ * PLL6553 Clock Type
+ */
+
+#define PLL6553_MDIV_MASK 0xff
+#define PLL6553_PDIV_MASK 0x3f
+#define PLL6553_SDIV_MASK 0x7
+#define PLL6553_KDIV_MASK 0x
+#define PLL6553_MDIV_SHIFT 16
+#define PLL6553_PDIV_SHIFT 8
+#define PLL6553_SDIV_SHIFT 0
+#define PLL6553_KDIV_SHIFT 0
+
+static unsigned long samsung_pll6553_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ u32 mdiv, pdiv, sdiv, kdiv, pll_con0, pll_con1;
+ u64 fvco = parent_rate;
+
+ pll_con0 = __raw_readl(pll->con_reg);
+ pll_con1 = __raw_readl(pll->con_reg + 0x4);
+ mdiv = (pll_con0 >> PLL6553_MDIV_SHIFT) & PLL6553_MDIV_MASK;
+ pdiv = (pll_con0 >> PLL6553_PDIV_SHIFT) & PLL6553_PDIV_MASK;
+ sdiv = (pll_con0 >> PLL6553_SDIV_SHIFT) & PLL6553_SDIV_MASK;
+ kdiv = (pll_con1 >> PLL6553_KDIV_SHIFT) & PLL6553_KDIV_MASK;
+
+ fvco *= (mdiv << 16) + kdiv;
+ do_div(fvco, (pdiv << sdiv));
+ fvco >>= 16;
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6553_clk_ops = {
+ .recalc_rate = samsung_pll6553_recalc_rate,
+};
+
+/*
* PLL2550x Clock Type
*/
@@ -572,6 +643,12 @@ static void __init _samsung_clk_register_pll(struct
samsung_pll_clock *pll_clk,
else
init.ops = &samsung_pll36xx_clk_ops;
break;
+ case pll_6552:
+ init.ops = &samsung_pll6552_clk_ops;
+ break;
+ case pll_6553:
+ init.ops = &samsung_pll6553_clk_ops;
+ break;
default:
pr_warn("%s: Unknown pll type for pll clk %s\n",
__func__, pll_clk->name);
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index 95ae23d..cd11037 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -17,6 +17,8 @@ enum samsung_pll_type {
pll_36xx,
pll_2550,
pll_2650,
+ pll_6552,
+ pll_6553,
};
#define PLL_35XX_RATE(_rate, _m, _p, _s) \
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 12:44:23PM -0700, Greg KH wrote: > On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: > > statement. In any case this is why the APIs doing lookups do the > > lookups in the context of the requesting device - devices ask for > > whatever name they use locally. > What do you mean by "locally"? Within themselves - for example a regulator consumer asks for a given supply on the device in terms of the supply names the device has. > The problem with the api was that the phy core wanted a id and a name to > create a phy, and then later other code was doing a "lookup" based on > the name and id (mushed together), because it "knew" that this device > was the one it wanted. Ah, that sounds like the API is missing a component to link things together. But I could be wrong. What I would expect to see is that the consumer says "I want the PHY called X" and the PHY driver says "I provide this set of PHYs" with a layer in between that plugs those together. This would normally involve talking about the parent device rather than the PHY itself. > I think, that if you create a device, then just carry around the pointer > to that device (in this case a phy) and pass it to whatever other code > needs it. No need to do lookups on "known names" or anything else, just > normal pointers, with no problems for multiple devices, busses, or > naming issues. I think you're not really talking about the lookup API at all here but rather about one way in which the matching code can be written. What everything *really* wants to do is work in terms of resources namespaced within struct devices since every bit of hardware in the system should have one of those it can use and if you have a struct device you can do useful things like call dev_printk() and find the device tree data to do device tree based lookups. Unfortunately for a number of buses even when statically registering the struct device doesn't get allocated until the device is probed so what everyone fell back on doing was using dev_name() in cases where the struct device wasn't there yet, or just always using it for consistency since for most of the affected buses dev_name() is fixed for human interface reasons. I think this is the issue you're concerned about here since if the dev_name() is dynamically allocated this breaks down. This only affects board files, DT and ACPI can both use their own data structures to do the mapping. I had thought you were talking about picking the names that the consumers use (which isn't actually that big a deal, it's just a bit annoying for the clock API). > > It's adding platform data in the first place that gets tedious - and of > > course there's also DT and ACPI to worry about, it's not just a case of > > platform data and then you're done. Pushing the lookup into library > > code means that drivers don't have to worry about any of this stuff. > I agree, so just pass around the pointer to the phy and all is good. No > need to worry about DT or ACPI or anything else. No, in practice passing around the pointer gets tricky if you're using something other than board files (or even are doing any kind of dynamic stuff with board files) since the two devices need to find each other and if you're using platform data then the code doing the matching has to know about the platform data for every device it might need to match which is just miserable. Something would need to do something like allocate the PHY objects and then arrange for them to be passed to both provider and consumer devices prior to those being registered, knowing where to place the pointers in the platform data for each device. This is straightforward with board files but not otherwise, people have tried this before. > > For most of the APIs doing this there is a clear and unambiguous name in > > the hardware that can be used (and for hardware process reasons is > > unlikely to get changed). The major exception to this is the clock API > > since it is relatively rare to have clear, segregated IP level > > information for IPs baked into larger chips. The other APIs tend to be > > establishing chip to chip links. > The clock api is having problems with multiple "names" due to dynamic > devices from what I was told. I want to prevent the PHY interface from > having that same issue. I think the underlying issue here is that we don't have a good enough general way for board files (or other C code but mostly them) to talk about devices prior to their being registered - rather than have the pointer you're talking about be the PHY object itself have the pointer be something which allows us to match the struct device when it's created. This should be transparent to drivers and would be usable by all the existing APIs. signature.asc Description: Digital signature
[PATCH v6 13/20] pwm: Add new pwm-samsung driver
This patch introduces new Samsung PWM driver, which is completely
rewritten to be multiplatform- and DeviceTree-aware.
In addition, remaining problems of old driver are fixed, such as:
- proper handling of hardware variants,
- synchronization on SMP systems,
- handling of boundary parameter values,
- hardware sharing with PWM clocksource driver,
- undefined state of PWM output after stopping PWM channel.
Signed-off-by: Tomasz Figa
Reviewed-by: Sylwester Nawrocki
Acked-by: Thierry Reding
---
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-samsung.c | 618 ++
2 files changed, 619 insertions(+)
create mode 100644 drivers/pwm/pwm-samsung.c
Changes since v5:
- No functional changes, just following cosmetic improvements.
- Used BIT() macro to define bits instead of shifting 1s directly.
- Added comment about bit layout in TCON register.
- Made macros used to define bits have more meaningful parameter names.
- Updated commit message.
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index aa94807..86a5771 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PWM_PUV3)+= pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung-legacy.o
+obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
new file mode 100644
index 000..fcc8b9a
--- /dev/null
+++ b/drivers/pwm/pwm-samsung.c
@@ -0,0 +1,618 @@
+/*
+ * Copyright (c) 2007 Ben Dooks
+ * Copyright (c) 2008 Simtec Electronics
+ * Ben Dooks ,
+ * Copyright (c) 2013 Tomasz Figa
+ *
+ * PWM driver for Samsung SoCs
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* For struct samsung_timer_variant and samsung_pwm_lock. */
+#include
+
+#define REG_TCFG0 0x00
+#define REG_TCFG1 0x04
+#define REG_TCON 0x08
+
+#define REG_TCNTB(chan)(0x0c + ((chan) * 0xc))
+#define REG_TCMPB(chan)(0x10 + ((chan) * 0xc))
+
+#define TCFG0_PRESCALER_MASK 0xff
+#define TCFG0_PRESCALER1_SHIFT 8
+
+#define TCFG1_MUX_MASK 0xf
+#define TCFG1_SHIFT(chan) (4 * (chan))
+
+/*
+ * Each channel occupies 4 bits in TCON register, but there is a gap of 4
+ * bits (one channel) after channel 0, so channels have different numbering
+ * when accessing TCON register. See to_tcon_channel() function.
+ *
+ * In addition, the location of autoreload bit for channel 4 (TCON channel 5)
+ * in its set of bits is 2 as opposed to 3 for other channels.
+ */
+#define TCON_START(chan) BIT(4 * (chan) + 0)
+#define TCON_MANUALUPDATE(chan)BIT(4 * (chan) + 1)
+#define TCON_INVERT(chan) BIT(4 * (chan) + 2)
+#define _TCON_AUTORELOAD(chan) BIT(4 * (chan) + 3)
+#define _TCON_AUTORELOAD4(chan)BIT(4 * (chan) + 2)
+#define TCON_AUTORELOAD(chan) \
+ ((chan < 5) ? _TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))
+
+/**
+ * struct samsung_pwm_channel - private data of PWM channel
+ * @period_ns: current period in nanoseconds programmed to the hardware
+ * @duty_ns: current duty time in nanoseconds programmed to the hardware
+ * @tin_ns:time of one timer tick in nanoseconds with current timer rate
+ */
+struct samsung_pwm_channel {
+ u32 period_ns;
+ u32 duty_ns;
+ u32 tin_ns;
+};
+
+/**
+ * struct samsung_pwm_chip - private data of PWM chip
+ * @chip: generic PWM chip
+ * @variant: local copy of hardware variant data
+ * @inverter_mask: inverter status for all channels - one bit per channel
+ * @base: base address of mapped PWM registers
+ * @base_clk: base clock used to drive the timers
+ * @tclk0: external clock 0 (can be ERR_PTR if not present)
+ * @tclk1: external clock 1 (can be ERR_PTR if not present)
+ */
+struct samsung_pwm_chip {
+ struct pwm_chip chip;
+ struct samsung_pwm_variant variant;
+ u8 inverter_mask;
+
+ void __iomem *base;
+ struct clk *base_clk;
+ struct clk *tclk0;
+ struct clk *tclk1;
+};
+
+#ifndef CONFIG_CLKSRC_SAMSUNG_PWM
+/*
+ * PWM block is shared between pwm-samsung and samsung_pwm_timer drivers
+ * and some registers need access synchronization. If both drivers are
+ * compiled in, the
[PATCH v6 02/20] clocksource: samsung_pwm_timer: Correct definition of AUTORELOAD bit
PWM channel 4 has its autoreload bit located at different position. This patch fixes the driver to account for that. This fixes a problem with the clocksource hanging after it overflows because it is not reloaded any more. Signed-off-by: Tomasz Figa Reviewed-by: Sylwester Nawrocki --- drivers/clocksource/samsung_pwm_timer.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) Changes since v5: - Added more detailed comment about bit layout in TCON register. diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c index 3fa5b07..5d0049f 100644 --- a/drivers/clocksource/samsung_pwm_timer.c +++ b/drivers/clocksource/samsung_pwm_timer.c @@ -44,10 +44,21 @@ #define TCFG1_SHIFT(x) ((x) * 4) #define TCFG1_MUX_MASK 0xf +/* + * Each channel occupies 4 bits in TCON register, but there is a gap of 4 + * bits (one channel) after channel 0, so channels have different numbering + * when accessing TCON register. + * + * In addition, the location of autoreload bit for channel 4 (TCON channel 5) + * in its set of bits is 2 as opposed to 3 for other channels. + */ #define TCON_START(chan) (1 << (4 * (chan) + 0)) #define TCON_MANUALUPDATE(chan)(1 << (4 * (chan) + 1)) #define TCON_INVERT(chan) (1 << (4 * (chan) + 2)) -#define TCON_AUTORELOAD(chan) (1 << (4 * (chan) + 3)) +#define _TCON_AUTORELOAD(chan) (1 << (4 * (chan) + 3)) +#define _TCON_AUTORELOAD4(chan)(1 << (4 * (chan) + 2)) +#define TCON_AUTORELOAD(chan) \ + ((chan < 5) ? _TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan)) DEFINE_SPINLOCK(samsung_pwm_lock); EXPORT_SYMBOL(samsung_pwm_lock); -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > If you want to keep the phy struct completely separate from the > > > board > > > file, there's an easy way to do it. Let's say the board file knows > > > about N different PHYs in the system. Then you define an array of N > > > pointers to phys: > > > > > > struct phy *(phy_address[N]); > > > > > > In the platform data for both PHY j and its controller, store > > > > > > &phy_address[j]. The PHY provider passes this cookie to phy_create: > > > cookie = pdev->dev.platform_data; > > > ret = phy_create(phy, cookie); > > > > > > and phy_create simply stores: *cookie = phy. The PHY consumer does > > > > > > much the same the same thing: > > > cookie = pdev->dev.platform_data; > > > phy = phy_get(cookie); > > > > > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. > > > > OK, this can work. Again, just technically, because it's rather ugly. > > There's no reason the phy_address things have to be arrays. A separate > individual pointer for each PHY would work just as well. > > > Where would you want to have those phy_address arrays stored? There > > are no board files when booting with DT. Not even saying that you > > don't need to use any hacky schemes like this when you have DT that > > nicely specifies relations between devices. > > If everybody agrees DT has a nice scheme for specifying relations > between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. > > Anyway, board file should not be considered as a method to exchange > > data between drivers. It should be used only to pass data from it to > > drivers, not the other way. Ideally all data in a board file should > > be marked as const and __init and dropped after system > > initialization. > > The phy_address things don't have to be defined or allocated in the > board file; they could be set up along with the platform data. There is no platform data when booting with DT. > In any case, this was simply meant to be a suggestion to show that it > is relatively easy to do what you need without using name or ID > strings. Sure. It's good to have different options discussed as well. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 11:05:48PM +0200, Tomasz Figa wrote: > > That's not so bad, as long as you let the phy core use whatever name it > > wants for the device when it registers it with sysfs. > > Yes, in regulator core consumer names are completely separated from this. > Regulator core simply assigns a sequential integer ID to each regulator > and registers /sys/class/regulator/regulator.ID for each regulator. Yes, that's fine. > > Use the name you > > are requesting as a "tag" or some such "hint" as to what the phy can be > > looked up by. > > > > Good luck handling duplicate "tags" :) > > The tag alone is not a key. Lookup key consists of two components, > consumer device name and consumer tag. What kind of duplicate tags can be > a problem here? Ok, I didn't realize it looked at both parts, that makes sense, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote: > > If you want to keep the phy struct completely separate from the board > > file, there's an easy way to do it. Let's say the board file knows > > about N different PHYs in the system. Then you define an array of N > > pointers to phys: > > > > struct phy *(phy_address[N]); > > > > In the platform data for both PHY j and its controller, store > > &phy_address[j]. The PHY provider passes this cookie to phy_create: > > > > cookie = pdev->dev.platform_data; > > ret = phy_create(phy, cookie); > > > > and phy_create simply stores: *cookie = phy. The PHY consumer does > > much the same the same thing: > > > > cookie = pdev->dev.platform_data; > > phy = phy_get(cookie); > > > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. > > OK, this can work. Again, just technically, because it's rather ugly. There's no reason the phy_address things have to be arrays. A separate individual pointer for each PHY would work just as well. > Where would you want to have those phy_address arrays stored? There are no > board files when booting with DT. Not even saying that you don't need to > use any hacky schemes like this when you have DT that nicely specifies > relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? > Anyway, board file should not be considered as a method to exchange data > between drivers. It should be used only to pass data from it to drivers, > not the other way. Ideally all data in a board file should be marked as > const and __init and dropped after system initialization. The phy_address things don't have to be defined or allocated in the board file; they could be set up along with the platform data. In any case, this was simply meant to be a suggestion to show that it is relatively easy to do what you need without using name or ID strings. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 13:50:07 Greg KH wrote:
> On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> > > On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > > > You don't "know" the id of the device you are looking up, due to
> > > > > multiple devices being in the system (dynamic ids, look back
> > > > > earlier
> > > > > in
> > > > > this thread for details about that.)
> > > >
> > > > I got copied in very late so don't have most of the thread I'm
> > > > afraid,
> > > > I did try looking at web archives but didn't see a clear problem
> > > > statement. In any case this is why the APIs doing lookups do the
> > > > lookups in the context of the requesting device - devices ask for
> > > > whatever name they use locally.
> > >
> > > What do you mean by "locally"?
> > >
> > > The problem with the api was that the phy core wanted a id and a
> > > name to create a phy, and then later other code was doing a
> > > "lookup" based on the name and id (mushed together), because it
> > > "knew" that this device was the one it wanted.
> > >
> > > Just like the clock api, which, for multiple devices, has proven to
> > > cause problems. I don't want to see us accept an api that we know
> > > has
> > > issues in it now, I'd rather us fix it up properly.
> > >
> > > Subsystems should be able to create ids how ever they want to, and
> > > not
> > > rely on the code calling them to specify the names of the devices
> > > that
> > > way, otherwise the api is just too fragile.
> > >
> > > I think, that if you create a device, then just carry around the
> > > pointer to that device (in this case a phy) and pass it to whatever
> > > other code needs it. No need to do lookups on "known names" or
> > > anything else, just normal pointers, with no problems for multiple
> > > devices, busses, or naming issues.
> >
> > PHY object is not a device, it is something that a device driver
> > creates (one or more instances of) when it is being probed.
>
> But you created a 'struct device' for it, so I think of it as a "device"
> be it "virtual" or "real" :)
Keep in mind that those virtual devices are created by PHY driver bound to
a real device and one real device can have multiple virtual devices behind
it.
> > You don't have a clean way to export this PHY object to other driver,
> > other than keeping this PHY on a list inside PHY core with some
> > well-known ID (e.g. device name + consumer port name/index, like in
> > regulator core) and then to use this well-known ID inside consumer
> > driver as a lookup key passed to phy_get();
> >
> > Actually I think for PHY case, exactly the same way as used for
> > regulators might be completely fine:
> >
> > 1. Each PHY would have some kind of platform, non-unique name, that is
> > just used to print some messages (like the platform/board name of a
> > regulator).
> > 2. Each PHY would have an array of consumers. Consumer specifier would
> > consist of consumer device name and consumer port name - just like in
> > regulator subsystem.
> > 3. PHY driver receives an array of, let's say, phy_init_data inside
> > its
> > platform data that it would use to register its PHYs.
> > 4. Consumer drivers would have constant consumer port names and
> > wouldn't receive any information about PHYs from platform code.
> >
> > Code example:
> >
> > [Board file]
> >
> > static const struct phy_consumer_data usb_20_phy0_consumers[] = {
> >
> > {
> >
> > .devname = "foo-ehci",
> > .port = "usbphy",
> >
> > },
> >
> > };
> >
> > static const struct phy_consumer_data usb_20_phy1_consumers[] = {
> >
> > {
> >
> > .devname = "foo-otg",
> > .port = "otgphy",
> >
> > },
> >
> > };
> >
> > static const struct phy_init_data my_phys[] = {
> >
> > {
> >
> > .name = "USB 2.0 PHY 0",
> > .consumers = usb_20_phy0_consumers,
> > .num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
> >
> > },
> > {
> >
> > .name = "USB 2.0 PHY 1",
> > .consumers = usb_20_phy1_consumers,
> > .num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
> >
> > },
> > { }
> >
> > };
> >
> > static const struct platform_device usb_phy_pdev = {
> >
> > .name = "foo-usbphy",
> > .id = -1,
> > .dev = {
> >
> > .platform_data = my_phys,
> >
> > },
> >
> > };
> >
> > [PHY driver]
> >
> > static int foo_usbphy_probe(pdev)
> > {
> >
> > struct foo_usbphy *foo;
> > struct phy_init_data *init_data = pdev->dev.platform_data;
> > /* ... */
> > // for each PHY in init_data {
> >
> > phy_register(&foo->phy[i], &init_data[i]);
> >
> > // }
> > /* ... */
> >
> > }
> >
> > [EHCI driver]
> >
> > static int foo_ehci_probe(pdev)
> > {
> >
> > struct phy *phy;
> > /* ... */
>
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 16:53:55 Alan Stern wrote: > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > That's what I was going to suggest too. The struct phy is defined > > > in > > > the board file, which already knows about all the PHYs that exist in > > > the system. (Or perhaps it is allocated dynamically, so that when > > > many > > > board files are present in the same kernel, only the entries listed > > > in > > > the board file for the current system get created.) > > > > Well, such dynamic allocation is a must. We don't accept > > non-multiplatform aware code anymore, not even saying about > > multiboard. > > > > > Then the > > > structure's address is stored in the platform data and made > > > available > > > to both the provider and the consumer. > > > > Yes, technically this can work. You would still have to perform some > > kind of synchronization to make sure that the PHY bound to this > > structure is actually present. This is again technically doable (e.g. > > a list of registered struct phys inside PHY core). > > The synchronization takes place inside phy_get. If phy_create hasn't > been called for this structure by the time phy_get runs, phy_get will > return an error. Yes, this is the solution that I had in mind when saying that this is doable. > > > Even though the struct phy is defined (or allocated) in the board > > > file, > > > its contents don't get filled in until the PHY driver provides the > > > details. > > > > You can't assure this. Board file is free to do whatever it wants with > > this struct. A clean solution would prevent this. > > I'm not sure what you mean here. Of course I can't prevent a board > file from messing up a data structure. I can't prevent it from causing > memory access violations either; in fact, I can't prevent any bugs in > other people's code. > > Besides, why do you say the board file is free to do whatever it wants > with the struct phy? Currently the struct phy is created by the PHY > provider and the PHY core, right? It's not even mentioned in the board > file. I mean, if you have a struct type of which full declaration is available for some code, this code can access any memeber of it without any hacks, which is not something that we want to have in board files. The phy struct should be opaque for them. > > > > It's technically correct, but quality of this solution isn't > > > > really > > > > nice, because it's a layering violation (at least if I understood > > > > what you mean). This is because you need to have full definition > > > > of > > > > struct phy in board file and a structure that is used as private > > > > data > > > > in PHY core comes from platform code. > > > > > > You don't have to have a full definition in the board file. Just a > > > partial definition -- most of the contents can be filled in later, > > > when > > > the PHY driver is ready to store the private data. > > > > > > It's not a layering violation for one region of the kernel to store > > > private data in a structure defined by another part of the kernel. > > > This happens all the time (e.g., dev_set_drvdata). > > > > Not really. The phy struct is something that _is_ private data of PHY > > subsystem, not something that can store private data of PHY subsystem > > (sure it can store private data of particular PHY driver, but that's > > another story) and only PHY subsystem should have access to its > > contents. > If you want to keep the phy struct completely separate from the board > file, there's an easy way to do it. Let's say the board file knows > about N different PHYs in the system. Then you define an array of N > pointers to phys: > > struct phy *(phy_address[N]); > > In the platform data for both PHY j and its controller, store > &phy_address[j]. The PHY provider passes this cookie to phy_create: > > cookie = pdev->dev.platform_data; > ret = phy_create(phy, cookie); > > and phy_create simply stores: *cookie = phy. The PHY consumer does > much the same the same thing: > > cookie = pdev->dev.platform_data; > phy = phy_get(cookie); > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. OK, this can work. Again, just technically, because it's rather ugly. > > By the way, we need to consider other cases here as well, for example > > it would be nice to have a single phy_get() function that works for > > both non- DT and DT cases to make the consumer driver not have to > > worry whether it's being probed from DT or not. > > You ought to be able to adapt this scheme to work with DT. Maybe by > having multiple "phy_address" arrays. Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. Anyway, board file should not be considered as a method to exchange data between drivers. It should be used only
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote: > > That's what I was going to suggest too. The struct phy is defined in > > the board file, which already knows about all the PHYs that exist in > > the system. (Or perhaps it is allocated dynamically, so that when many > > board files are present in the same kernel, only the entries listed in > > the board file for the current system get created.) > > Well, such dynamic allocation is a must. We don't accept non-multiplatform > aware code anymore, not even saying about multiboard. > > > Then the > > structure's address is stored in the platform data and made available > > to both the provider and the consumer. > > Yes, technically this can work. You would still have to perform some kind > of synchronization to make sure that the PHY bound to this structure is > actually present. This is again technically doable (e.g. a list of > registered struct phys inside PHY core). The synchronization takes place inside phy_get. If phy_create hasn't been called for this structure by the time phy_get runs, phy_get will return an error. > > Even though the struct phy is defined (or allocated) in the board file, > > its contents don't get filled in until the PHY driver provides the > > details. > > You can't assure this. Board file is free to do whatever it wants with > this struct. A clean solution would prevent this. I'm not sure what you mean here. Of course I can't prevent a board file from messing up a data structure. I can't prevent it from causing memory access violations either; in fact, I can't prevent any bugs in other people's code. Besides, why do you say the board file is free to do whatever it wants with the struct phy? Currently the struct phy is created by the PHY provider and the PHY core, right? It's not even mentioned in the board file. > > > It's technically correct, but quality of this solution isn't really > > > nice, because it's a layering violation (at least if I understood > > > what you mean). This is because you need to have full definition of > > > struct phy in board file and a structure that is used as private data > > > in PHY core comes from platform code. > > > > You don't have to have a full definition in the board file. Just a > > partial definition -- most of the contents can be filled in later, when > > the PHY driver is ready to store the private data. > > > > It's not a layering violation for one region of the kernel to store > > private data in a structure defined by another part of the kernel. > > This happens all the time (e.g., dev_set_drvdata). > > Not really. The phy struct is something that _is_ private data of PHY > subsystem, not something that can store private data of PHY subsystem > (sure it can store private data of particular PHY driver, but that's > another story) and only PHY subsystem should have access to its contents. If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store &phy_address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev->dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev->dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. > By the way, we need to consider other cases here as well, for example it > would be nice to have a single phy_get() function that works for both non- > DT and DT cases to make the consumer driver not have to worry whether it's > being probed from DT or not. You ought to be able to adapt this scheme to work with DT. Maybe by having multiple "phy_address" arrays. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> > On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > > You don't "know" the id of the device you are looking up, due to
> > > > multiple devices being in the system (dynamic ids, look back earlier
> > > > in
> > > > this thread for details about that.)
> > >
> > > I got copied in very late so don't have most of the thread I'm afraid,
> > > I did try looking at web archives but didn't see a clear problem
> > > statement. In any case this is why the APIs doing lookups do the
> > > lookups in the context of the requesting device - devices ask for
> > > whatever name they use locally.
> >
> > What do you mean by "locally"?
> >
> > The problem with the api was that the phy core wanted a id and a name to
> > create a phy, and then later other code was doing a "lookup" based on
> > the name and id (mushed together), because it "knew" that this device
> > was the one it wanted.
> >
> > Just like the clock api, which, for multiple devices, has proven to
> > cause problems. I don't want to see us accept an api that we know has
> > issues in it now, I'd rather us fix it up properly.
> >
> > Subsystems should be able to create ids how ever they want to, and not
> > rely on the code calling them to specify the names of the devices that
> > way, otherwise the api is just too fragile.
> >
> > I think, that if you create a device, then just carry around the pointer
> > to that device (in this case a phy) and pass it to whatever other code
> > needs it. No need to do lookups on "known names" or anything else,
> > just normal pointers, with no problems for multiple devices, busses, or
> > naming issues.
>
> PHY object is not a device, it is something that a device driver creates
> (one or more instances of) when it is being probed.
But you created a 'struct device' for it, so I think of it as a "device"
be it "virtual" or "real" :)
> You don't have a clean way to export this PHY object to other driver,
> other than keeping this PHY on a list inside PHY core with some
> well-known ID (e.g. device name + consumer port name/index, like in
> regulator core) and then to use this well-known ID inside consumer
> driver as a lookup key passed to phy_get();
>
> Actually I think for PHY case, exactly the same way as used for
> regulators might be completely fine:
>
> 1. Each PHY would have some kind of platform, non-unique name, that is
> just used to print some messages (like the platform/board name of a
> regulator).
> 2. Each PHY would have an array of consumers. Consumer specifier would
> consist of consumer device name and consumer port name - just like in
> regulator subsystem.
> 3. PHY driver receives an array of, let's say, phy_init_data inside its
> platform data that it would use to register its PHYs.
> 4. Consumer drivers would have constant consumer port names and wouldn't
> receive any information about PHYs from platform code.
>
> Code example:
>
> [Board file]
>
> static const struct phy_consumer_data usb_20_phy0_consumers[] = {
> {
> .devname = "foo-ehci",
> .port = "usbphy",
> },
> };
>
> static const struct phy_consumer_data usb_20_phy1_consumers[] = {
> {
> .devname = "foo-otg",
> .port = "otgphy",
> },
> };
>
> static const struct phy_init_data my_phys[] = {
> {
> .name = "USB 2.0 PHY 0",
> .consumers = usb_20_phy0_consumers,
> .num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
> },
> {
> .name = "USB 2.0 PHY 1",
> .consumers = usb_20_phy1_consumers,
> .num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
> },
> { }
> };
>
> static const struct platform_device usb_phy_pdev = {
> .name = "foo-usbphy",
> .id = -1,
> .dev = {
> .platform_data = my_phys,
> },
> };
>
> [PHY driver]
>
> static int foo_usbphy_probe(pdev)
> {
> struct foo_usbphy *foo;
> struct phy_init_data *init_data = pdev->dev.platform_data;
> /* ... */
> // for each PHY in init_data {
> phy_register(&foo->phy[i], &init_data[i]);
> // }
> /* ... */
> }
>
> [EHCI driver]
>
> static int foo_ehci_probe(pdev)
> {
> struct phy *phy;
> /* ... */
> phy = phy_get(&pdev->dev, "usbphy");
> /* ... */
> }
>
> [OTG driver]
>
> static int foo_otg_probe(pdev)
> {
> struct phy *phy;
> /* ... */
> phy = phy_get(&pdev->dev, "otgphy");
> /* ... */
> }
That's not so bad, as long as you let the phy core use whatever name it
wants for the device when it registers it with sysfs. Use the name you
are requesting as a "tag" or some such "hint" as to what the phy can be
looked up by.
Good luck handling duplicate "tags" :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "uns
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 11:04:14 Greg KH wrote:
> On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> > > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > > > Ick, no. Why can't you just pass the pointer to the phy itself?
> > > > > If
> > > > > you
> > > > > had a "priv" pointer to search from, then you could have just
> > > > > passed
> > > > > the
> > > > > original phy pointer in the first place, right?
> > > >
> > > > IMHO it would be better if you provided some code example, but
> > > > let's
> > > > try to check if I understood you correctly.
> > >
> > > It's not my code that I want to have added, so I don't have to write
> > > examples, I just get to complain about the existing stuff :)
> >
> > Still, I think that some small code snippets illustrating the idea are
> > really helpful.
> >
> > > > 8><---
> > > > -
> > > >
> > > >
> > > > [Board file]
> > > >
> > > > static struct phy my_phy;
> > > >
> > > > static struct platform_device phy_pdev = {
> > > >
> > > > /* ... */
> > > > .platform_data = &my_phy;
> > > > /* ... */
> > > >
> > > > };
> > > >
> > > > static struct platform_device phy_pdev = {
> > > >
> > > > /* ... */
> > > > .platform_data = &my_phy;
> > > > /* ... */
> > > >
> > > > };
> > > >
> > > > [Provider driver]
> > > >
> > > > struct phy *phy = pdev->dev.platform_data;
> > > >
> > > > ret = phy_create(phy);
> > > >
> > > > [Consumer driver]
> > > >
> > > > struct phy *phy = pdev->dev.platform_data;
> > > >
> > > > ret = phy_get(&pdev->dev, phy);
> > > >
> > > > --
> > > > -
> > > > -><8
> > > >
> > > > Is this what you mean?
> > >
> > > No. Well, kind of. What's wrong with using the platform data
> > > structure unique to the board to have the pointer?
> > >
> > > For example (just randomly picking one), the ata-pxa driver would
> > > change include/linux/platform_data/ata-pxa.h to have a phy pointer
> > > in it:
> > >
> > > struct phy;
> > >
> > > struct pata_pxa_pdata {
> > >
> > > /* PXA DMA DREQ<0:2> pin */
> > > uint32_tdma_dreq;
> > > /* Register shift */
> > > uint32_treg_shift;
> > > /* IRQ flags */
> > > uint32_tirq_flags;
> > > /* PHY */
> > > struct phy *phy;
> > >
> > > };
> > >
> > > Then, when you create the platform, set the phy* pointer with a call
> > > to
> > > phy_create(). Then you can use that pointer wherever that plaform
> > > data
> > > is available (i.e. whereever platform_data is at).
> >
> > Hmm? So, do you suggest to call phy_create() from board file? What
> > phy_ops struct and other hardware parameters would it take?
> >
> > > > > The issue is that a string "name" is not going to scale at all,
> > > > > as it
> > > > > requires hard-coded information that will change over time (as
> > > > > the
> > > > > existing clock interface is already showing.)
> > > >
> > > > I fully agree that a simple, single string will not scale even in
> > > > some,
> > > > not so uncommon cases, but there is already a lot of existing
> > > > lookup
> > > > solutions over the kernel and so there is no point in introducing
> > > > another one.
> > >
> > > I'm trying to get _rid_ of lookup "solutions" and just use a real
> > > pointer, as you should. I'll go tackle those other ones after this
> > > one
> > > is taken care of, to show how the others should be handled as well.
> >
> > There was a reason for introducing lookup solutions. The reason was
> > that in board file there is no way to get a pointer to something that
> > is going to be created much later in time. We don't do time travel
> > ;-).
> >
> > > > > Please just pass the real "phy" pointer around, that's what it
> > > > > is
> > > > > there
> > > > > for. Your "board binding" logic/code should be able to handle
> > > > > this,
> > > > > as
> > > > > it somehow was going to do the same thing with a "name".
> > > >
> > > > It's technically correct, but quality of this solution isn't
> > > > really
> > > > nice, because it's a layering violation (at least if I understood
> > > > what
> > > > you mean). This is because you need to have full definition of
> > > > struct
> > > > phy in board file and a structure that is used as private data in
> > > > PHY
> > > > core comes from platform code.
> > >
> > > No, just a pointer, you don't need the "full" structure until you
> > > get to some .c code that actually manipulates the phy itself, for
> > > all other places, you are just dealing with a pointer and a
> > > structure you never reference.
> > >
> > > Does that make more sense?
> >
> > Well, to the point that I think I now understood your suggestion.
> > Unfortunately the suggestion alone isn't really something that can be
> > done, considering how driver core
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 15:36:00 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > IMHO it would be better if you provided some code example, but let's
> > try to check if I understood you correctly.
> >
> > 8><---
> > -
> >
> > [Board file]
> >
> > static struct phy my_phy;
> >
> > static struct platform_device phy_pdev = {
> >
> > /* ... */
> > .platform_data = &my_phy;
> > /* ... */
> >
> > };
> >
> > static struct platform_device phy_pdev = {
>
> This should be controller_pdev, not phy_pdev, yes?
Right. A copy-pasto.
>
> > /* ... */
> > .platform_data = &my_phy;
> > /* ... */
> >
> > };
> >
> > [Provider driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_create(phy);
> >
> > [Consumer driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_get(&pdev->dev, phy);
>
> Or even just phy_get(&pdev->dev), because phy_get() could be smart
> enough to to set phy = dev->platform_data.
Unless you need more than one PHY in this driver...
>
> > --
> > --><8
> >
> > Is this what you mean?
>
> That's what I was going to suggest too. The struct phy is defined in
> the board file, which already knows about all the PHYs that exist in
> the system. (Or perhaps it is allocated dynamically, so that when many
> board files are present in the same kernel, only the entries listed in
> the board file for the current system get created.)
Well, such dynamic allocation is a must. We don't accept non-multiplatform
aware code anymore, not even saying about multiboard.
> Then the
> structure's address is stored in the platform data and made available
> to both the provider and the consumer.
Yes, technically this can work. You would still have to perform some kind
of synchronization to make sure that the PHY bound to this structure is
actually present. This is again technically doable (e.g. a list of
registered struct phys inside PHY core).
> Even though the struct phy is defined (or allocated) in the board file,
> its contents don't get filled in until the PHY driver provides the
> details.
You can't assure this. Board file is free to do whatever it wants with
this struct. A clean solution would prevent this.
> > It's technically correct, but quality of this solution isn't really
> > nice, because it's a layering violation (at least if I understood
> > what you mean). This is because you need to have full definition of
> > struct phy in board file and a structure that is used as private data
> > in PHY core comes from platform code.
>
> You don't have to have a full definition in the board file. Just a
> partial definition -- most of the contents can be filled in later, when
> the PHY driver is ready to store the private data.
>
> It's not a layering violation for one region of the kernel to store
> private data in a structure defined by another part of the kernel.
> This happens all the time (e.g., dev_set_drvdata).
Not really. The phy struct is something that _is_ private data of PHY
subsystem, not something that can store private data of PHY subsystem
(sure it can store private data of particular PHY driver, but that's
another story) and only PHY subsystem should have access to its contents.
By the way, we need to consider other cases here as well, for example it
would be nice to have a single phy_get() function that works for both non-
DT and DT cases to make the consumer driver not have to worry whether it's
being probed from DT or not.
I'd suggest simply reusing the lookup method of regulator framework, just
as I suggested here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=101661
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > You don't "know" the id of the device you are looking up, due to
> > > multiple devices being in the system (dynamic ids, look back earlier
> > > in
> > > this thread for details about that.)
> >
> > I got copied in very late so don't have most of the thread I'm afraid,
> > I did try looking at web archives but didn't see a clear problem
> > statement. In any case this is why the APIs doing lookups do the
> > lookups in the context of the requesting device - devices ask for
> > whatever name they use locally.
>
> What do you mean by "locally"?
>
> The problem with the api was that the phy core wanted a id and a name to
> create a phy, and then later other code was doing a "lookup" based on
> the name and id (mushed together), because it "knew" that this device
> was the one it wanted.
>
> Just like the clock api, which, for multiple devices, has proven to
> cause problems. I don't want to see us accept an api that we know has
> issues in it now, I'd rather us fix it up properly.
>
> Subsystems should be able to create ids how ever they want to, and not
> rely on the code calling them to specify the names of the devices that
> way, otherwise the api is just too fragile.
>
> I think, that if you create a device, then just carry around the pointer
> to that device (in this case a phy) and pass it to whatever other code
> needs it. No need to do lookups on "known names" or anything else,
> just normal pointers, with no problems for multiple devices, busses, or
> naming issues.
PHY object is not a device, it is something that a device driver creates
(one or more instances of) when it is being probed. You don't have a clean
way to export this PHY object to other driver, other than keeping this PHY
on a list inside PHY core with some well-known ID (e.g. device name +
consumer port name/index, like in regulator core) and then to use this
well-known ID inside consumer driver as a lookup key passed to phy_get();
Actually I think for PHY case, exactly the same way as used for regulators
might be completely fine:
1. Each PHY would have some kind of platform, non-unique name, that is
just used to print some messages (like the platform/board name of a
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would
consist of consumer device name and consumer port name - just like in
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside its
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and wouldn't
receive any information about PHYs from platform code.
Code example:
[Board file]
static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = "foo-ehci",
.port = "usbphy",
},
};
static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = "foo-otg",
.port = "otgphy",
},
};
static const struct phy_init_data my_phys[] = {
{
.name = "USB 2.0 PHY 0",
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = "USB 2.0 PHY 1",
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};
static const struct platform_device usb_phy_pdev = {
.name = "foo-usbphy",
.id = -1,
.dev = {
.platform_data = my_phys,
},
};
[PHY driver]
static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev->dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(&foo->phy[i], &init_data[i]);
// }
/* ... */
}
[EHCI driver]
static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(&pdev->dev, "usbphy");
/* ... */
}
[OTG driver]
static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(&pdev->dev, "otgphy");
/* ... */
}
> > > > Having to write platform data for everything gets old fast and the
> > > > code
> > > > duplication is pretty tedious...
> > >
> > > Adding a single pointer is "tedious"? Where is the "name" that you
> > > are
> > > going to lookup going to come from? That code doesn't write
> > > itself...
> >
> > It's adding platform data in the first place that gets tedious - and
> > of
> > course there's also DT and ACPI to worry about, it's not just a case
> > of
> > platform data and then you're done. Pushing the lookup into library
> > code means that drivers don't have to worry about any of this stuff.
>
> I agree, so just pass around the pointer to the phy and all
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: > > You don't "know" the id of the device you are looking up, due to > > multiple devices being in the system (dynamic ids, look back earlier in > > this thread for details about that.) > > I got copied in very late so don't have most of the thread I'm afraid, > I did try looking at web archives but didn't see a clear problem > statement. In any case this is why the APIs doing lookups do the > lookups in the context of the requesting device - devices ask for > whatever name they use locally. What do you mean by "locally"? The problem with the api was that the phy core wanted a id and a name to create a phy, and then later other code was doing a "lookup" based on the name and id (mushed together), because it "knew" that this device was the one it wanted. Just like the clock api, which, for multiple devices, has proven to cause problems. I don't want to see us accept an api that we know has issues in it now, I'd rather us fix it up properly. Subsystems should be able to create ids how ever they want to, and not rely on the code calling them to specify the names of the devices that way, otherwise the api is just too fragile. I think, that if you create a device, then just carry around the pointer to that device (in this case a phy) and pass it to whatever other code needs it. No need to do lookups on "known names" or anything else, just normal pointers, with no problems for multiple devices, busses, or naming issues. > > > Having to write platform data for everything gets old fast and the code > > > duplication is pretty tedious... > > > Adding a single pointer is "tedious"? Where is the "name" that you are > > going to lookup going to come from? That code doesn't write itself... > > It's adding platform data in the first place that gets tedious - and of > course there's also DT and ACPI to worry about, it's not just a case of > platform data and then you're done. Pushing the lookup into library > code means that drivers don't have to worry about any of this stuff. I agree, so just pass around the pointer to the phy and all is good. No need to worry about DT or ACPI or anything else. > For most of the APIs doing this there is a clear and unambiguous name in > the hardware that can be used (and for hardware process reasons is > unlikely to get changed). The major exception to this is the clock API > since it is relatively rare to have clear, segregated IP level > information for IPs baked into larger chips. The other APIs tend to be > establishing chip to chip links. The clock api is having problems with multiple "names" due to dynamic devices from what I was told. I want to prevent the PHY interface from having that same issue. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on Exynos5420
On Tue, Jul 23, 2013 at 09:38:00AM +0530, Padma Venkat wrote: > On Fri, Jul 12, 2013 at 2:19 PM, Mark Brown wrote: > > Yes, this is good but the quirk should just be found by software based > > on the compatible string rather than in the DT. > You mean I just need to initialize the quirks in the driver based on > the compatible string? That's the gold standard. > So what about the quirks that I added previously on 5250? Should I > also follow the same thing for other quirks? Yes, ideally. > Or it need to be passed via driver data as it is done in spi driver? > Please clarify me. This is a good way to initialise things based on the name - the core will do the lookups for you. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote:
> IMHO it would be better if you provided some code example, but let's try to
> check if I understood you correctly.
>
> 8><
>
> [Board file]
>
> static struct phy my_phy;
>
> static struct platform_device phy_pdev = {
> /* ... */
> .platform_data = &my_phy;
> /* ... */
> };
>
> static struct platform_device phy_pdev = {
This should be controller_pdev, not phy_pdev, yes?
> /* ... */
> .platform_data = &my_phy;
> /* ... */
> };
>
> [Provider driver]
>
> struct phy *phy = pdev->dev.platform_data;
>
> ret = phy_create(phy);
>
> [Consumer driver]
>
> struct phy *phy = pdev->dev.platform_data;
>
> ret = phy_get(&pdev->dev, phy);
Or even just phy_get(&pdev->dev), because phy_get() could be smart
enough to to set phy = dev->platform_data.
> ><8
>
> Is this what you mean?
That's what I was going to suggest too. The struct phy is defined in
the board file, which already knows about all the PHYs that exist in
the system. (Or perhaps it is allocated dynamically, so that when many
board files are present in the same kernel, only the entries listed in
the board file for the current system get created.) Then the
structure's address is stored in the platform data and made available
to both the provider and the consumer.
Even though the struct phy is defined (or allocated) in the board file,
its contents don't get filled in until the PHY driver provides the
details.
> It's technically correct, but quality of this solution isn't really nice,
> because it's a layering violation (at least if I understood what you mean).
> This is because you need to have full definition of struct phy in board file
> and a structure that is used as private data in PHY core comes from
> platform code.
You don't have to have a full definition in the board file. Just a
partial definition -- most of the contents can be filled in later, when
the PHY driver is ready to store the private data.
It's not a layering violation for one region of the kernel to store
private data in a structure defined by another part of the kernel.
This happens all the time (e.g., dev_set_drvdata).
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 11:01:10AM -0700, Greg KH wrote: > On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote: > > What are the problems you are seeing with doing things with lookups? > You don't "know" the id of the device you are looking up, due to > multiple devices being in the system (dynamic ids, look back earlier in > this thread for details about that.) I got copied in very late so don't have most of the thread I'm afraid, I did try looking at web archives but didn't see a clear problem statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. > > Having to write platform data for everything gets old fast and the code > > duplication is pretty tedious... > Adding a single pointer is "tedious"? Where is the "name" that you are > going to lookup going to come from? That code doesn't write itself... It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. signature.asc Description: Digital signature
[REVIEW PATCH 5/6] exynos4-is: Use external s5k6a3 sensor driver
This patch removes the common fimc-is-sensor driver for image sensors
that are normally controlled by the FIMC-IS firmware. The FIMC-IS
driver now contains only a table of properties specific to each sensor.
The sensor properties required for the ISP's firmware are parsed from
device tree and retrieved from the internal table, which is selected
based on the compatible property of an image sensor.
To use the Exynos4x12 internal ISP the S5K6A3 sensor driver (drivers/
media/i2c/s5k6a3.c) is now required.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/platform/exynos4-is/fimc-is-regs.c |2 +-
drivers/media/platform/exynos4-is/fimc-is-sensor.c | 285 +---
drivers/media/platform/exynos4-is/fimc-is-sensor.h | 49 +---
drivers/media/platform/exynos4-is/fimc-is.c| 96 +++
drivers/media/platform/exynos4-is/fimc-is.h|4 +-
5 files changed, 57 insertions(+), 379 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-is-regs.c
b/drivers/media/platform/exynos4-is/fimc-is-regs.c
index 63c68ec..3e51aa6 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-regs.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-regs.c
@@ -136,7 +136,7 @@ void fimc_is_hw_set_sensor_num(struct fimc_is *is)
mcuctl_write(IH_REPLY_DONE, is, MCUCTL_REG_ISSR(0));
mcuctl_write(is->sensor_index, is, MCUCTL_REG_ISSR(1));
mcuctl_write(IHC_GET_SENSOR_NUM, is, MCUCTL_REG_ISSR(2));
- mcuctl_write(FIMC_IS_SENSOR_NUM, is, MCUCTL_REG_ISSR(3));
+ mcuctl_write(FIMC_IS_SENSORS_NUM, is, MCUCTL_REG_ISSR(3));
}
void fimc_is_hw_close_sensor(struct fimc_is *is, unsigned int index)
diff --git a/drivers/media/platform/exynos4-is/fimc-is-sensor.c
b/drivers/media/platform/exynos4-is/fimc-is-sensor.c
index 6647421..10e82e2 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-sensor.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-sensor.c
@@ -2,276 +2,21 @@
* Samsung EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
*
* Copyright (C) 2013 Samsung Electronics Co., Ltd.
- *
* Author: Sylwester Nawrocki
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "fimc-is.h"
#include "fimc-is-sensor.h"
-#define DRIVER_NAME "FIMC-IS-SENSOR"
-
-static const char * const sensor_supply_names[] = {
- "svdda",
- "svddio",
-};
-
-static const struct v4l2_mbus_framefmt fimc_is_sensor_formats[] = {
- {
- .code = V4L2_MBUS_FMT_SGRBG10_1X10,
- .colorspace = V4L2_COLORSPACE_SRGB,
- .field = V4L2_FIELD_NONE,
- }
-};
-
-static const struct v4l2_mbus_framefmt *find_sensor_format(
- struct v4l2_mbus_framefmt *mf)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(fimc_is_sensor_formats); i++)
- if (mf->code == fimc_is_sensor_formats[i].code)
- return &fimc_is_sensor_formats[i];
-
- return &fimc_is_sensor_formats[0];
-}
-
-static int fimc_is_sensor_enum_mbus_code(struct v4l2_subdev *sd,
- struct v4l2_subdev_fh *fh,
- struct v4l2_subdev_mbus_code_enum *code)
-{
- if (code->index >= ARRAY_SIZE(fimc_is_sensor_formats))
- return -EINVAL;
-
- code->code = fimc_is_sensor_formats[code->index].code;
- return 0;
-}
-
-static void fimc_is_sensor_try_format(struct fimc_is_sensor *sensor,
- struct v4l2_mbus_framefmt *mf)
-{
- const struct sensor_drv_data *dd = sensor->drvdata;
- const struct v4l2_mbus_framefmt *fmt;
-
- fmt = find_sensor_format(mf);
- mf->code = fmt->code;
- v4l_bound_align_image(&mf->width, 16 + 8, dd->width, 0,
- &mf->height, 12 + 8, dd->height, 0, 0);
-}
-
-static struct v4l2_mbus_framefmt *__fimc_is_sensor_get_format(
- struct fimc_is_sensor *sensor, struct v4l2_subdev_fh *fh,
- u32 pad, enum v4l2_subdev_format_whence which)
-{
- if (which == V4L2_SUBDEV_FORMAT_TRY)
- return fh ? v4l2_subdev_get_try_format(fh, pad) : NULL;
-
- return &sensor->format;
-}
-
-static int fimc_is_sensor_set_fmt(struct v4l2_subdev *sd,
- struct v4l2_subdev_fh *fh,
- struct v4l2_subdev_format *fmt)
-{
- struct fimc_is_sensor *sensor = sd_to_fimc_is_sensor(sd);
- struct v4l2_mbus_framefmt *mf;
-
- fimc_is_sensor_try_format(sensor, &fmt->format);
-
- mf = __fimc_is_sensor_get_format(sensor, fh, fmt->pad, fmt->which);
- if (mf) {
- mutex_lock(&sensor->lock);
- if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE)
[REVIEW PATCH 6/6] exynos4-is: Add support for asynchronous sensor subddevs registration
Add support registering external sensor subdevs using the v4l2-async API.
The async API is used only for sensor subdevs and only for platforms
instatiated from Device Tree.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/platform/exynos4-is/media-dev.c | 163 ++---
drivers/media/platform/exynos4-is/media-dev.h | 12 +-
2 files changed, 100 insertions(+), 75 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 346e1e0..280e819 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -221,6 +222,7 @@ static int __fimc_pipeline_open(struct
exynos_media_pipeline *ep,
if (ret < 0)
return ret;
}
+
ret = fimc_md_set_camclk(sd, true);
if (ret < 0)
goto err_wbclk;
@@ -395,63 +397,6 @@ static void fimc_md_unregister_sensor(struct v4l2_subdev
*sd)
}
#ifdef CONFIG_OF
-/* Register I2C client subdev associated with @node. */
-static int fimc_md_of_add_sensor(struct fimc_md *fmd,
-struct device_node *node, int index)
-{
- struct fimc_sensor_info *si;
- struct i2c_client *client;
- struct v4l2_subdev *sd;
- int ret;
-
- if (WARN_ON(index >= ARRAY_SIZE(fmd->sensor)))
- return -EINVAL;
- si = &fmd->sensor[index];
-
- client = of_find_i2c_device_by_node(node);
- if (!client)
- return -EPROBE_DEFER;
-
- device_lock(&client->dev);
-
- if (!client->driver ||
- !try_module_get(client->driver->driver.owner)) {
- ret = -EPROBE_DEFER;
- v4l2_info(&fmd->v4l2_dev, "No driver found for %s\n",
- node->full_name);
- goto dev_put;
- }
-
- /* Enable sensor's master clock */
- ret = __fimc_md_set_camclk(fmd, &si->pdata, true);
- if (ret < 0)
- goto mod_put;
- sd = i2c_get_clientdata(client);
-
- ret = v4l2_device_register_subdev(&fmd->v4l2_dev, sd);
- __fimc_md_set_camclk(fmd, &si->pdata, false);
- if (ret < 0)
- goto mod_put;
-
- v4l2_set_subdev_hostdata(sd, &si->pdata);
- if (si->pdata.fimc_bus_type == FIMC_BUS_TYPE_ISP_WRITEBACK)
- sd->grp_id = GRP_ID_FIMC_IS_SENSOR;
- else
- sd->grp_id = GRP_ID_SENSOR;
-
- si->subdev = sd;
- v4l2_info(&fmd->v4l2_dev, "Registered sensor subdevice: %s (%d)\n",
- sd->name, fmd->num_sensors);
- fmd->num_sensors++;
-
-mod_put:
- module_put(client->driver->driver.owner);
-dev_put:
- device_unlock(&client->dev);
- put_device(&client->dev);
- return ret;
-}
-
/* Parse port node and register as a sub-device any sensor specified there. */
static int fimc_md_parse_port_node(struct fimc_md *fmd,
struct device_node *port,
@@ -460,7 +405,6 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
struct device_node *rem, *ep, *np;
struct fimc_source_info *pd;
struct v4l2_of_endpoint endpoint;
- int ret;
u32 val;
pd = &fmd->sensor[index].pdata;
@@ -527,10 +471,17 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
else
pd->fimc_bus_type = pd->sensor_bus_type;
- ret = fimc_md_of_add_sensor(fmd, rem, index);
- of_node_put(rem);
+ if (WARN_ON(index >= ARRAY_SIZE(fmd->sensor)))
+ return -EINVAL;
- return ret;
+ fmd->sensor[index].asd.match_type = V4L2_ASYNC_MATCH_OF;
+ fmd->sensor[index].asd.match.of.node = rem;
+ fmd->async_subdevs[index] = &fmd->sensor[index].asd;
+
+ fmd->num_sensors++;
+
+ of_node_put(rem);
+ return 0;
}
/* Register all SoC external sub-devices */
@@ -1225,6 +1176,14 @@ static int __fimc_md_set_camclk(struct fimc_md *fmd,
struct fimc_camclk_info *camclk;
int ret = 0;
+ /*
+* When device tree is used the sensor drivers are supposed to
+* control the clock themselves. This whole function will be
+* removed once S5PV210 platform is converted to the device tree.
+*/
+ if (fmd->pdev->dev.of_node)
+ return 0;
+
if (WARN_ON(si->clk_id >= FIMC_MAX_CAMCLKS) || !fmd || !fmd->pmf)
return -EINVAL;
@@ -1520,6 +1479,56 @@ static int fimc_md_register_clk_provider(struct fimc_md
*fmd)
#define fimc_md_register_clk_provider(fmd) (0)
#endif
+static int subdev_notifier_bound(struct v4l2_async_notifier *notifier,
+struct v4l2_subdev *subdev,
+struct v4l2_async_subdev *asd)
+{
+ struct fimc_md *fm
[REVIEW PATCH 4/6] exynos4-is: Add clock provider for the external clocks
This patch adds clock provider to expose the sclk_cam0/1 clocks
for image sensor subdevs.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
.../devicetree/bindings/media/samsung-fimc.txt | 17 +++-
drivers/media/platform/exynos4-is/media-dev.c | 92
drivers/media/platform/exynos4-is/media-dev.h | 19 +++-
3 files changed, 125 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 96312f6..04a2b87 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -91,6 +91,15 @@ Optional properties
- samsung,camclk-out : specifies clock output for remote sensor,
0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+'clock-controller' node (optional)
+--
+
+The purpose of this node is to define a clock provider for external image
+sensors and link any of the CAM_?_CLKOUT clock outputs with related external
+clock consumer device. Properties specific to this node are described in
+../clock/clock-bindings.txt.
+
+
Image sensor nodes
--
@@ -114,7 +123,7 @@ Example:
vddio-supply = <...>;
clock-frequency = <2400>;
- clocks = <...>;
+ clocks = <&camclk 1>;
clock-names = "mclk";
port {
@@ -135,7 +144,7 @@ Example:
vddio-supply = <...>;
clock-frequency = <2400>;
- clocks = <...>;
+ clocks = <&camclk 0>;
clock-names = "mclk";
port {
@@ -156,6 +165,10 @@ Example:
pinctrl-names = "default";
pinctrl-0 = <&cam_port_a_clk_active>;
+ camclk: clock-controller {
+ #clock-cells = 1;
+ };
+
/* parallel camera ports */
parallel-ports {
/* camera A input */
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 41366fe..346e1e0 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -11,6 +11,8 @@
*/
#include
+#include
+#include
#include
#include
#include
@@ -1438,6 +1440,86 @@ static int fimc_md_get_pinctrl(struct fimc_md *fmd)
return 0;
}
+#ifdef CONFIG_OF
+struct cam_clk {
+ struct clk_hw hw;
+ struct fimc_md *fmd;
+};
+#define to_cam_clk(_hw) container_of(_hw, struct cam_clk, hw)
+
+static int cam_clk_prepare(struct clk_hw *hw)
+{
+ struct cam_clk *camclk = to_cam_clk(hw);
+ int ret = pm_runtime_get_sync(camclk->fmd->pmf);
+
+ return ret < 0 ? ret : 0;
+}
+
+static void cam_clk_unprepare(struct clk_hw *hw)
+{
+ struct cam_clk *camclk = to_cam_clk(hw);
+ pm_runtime_put_sync(camclk->fmd->pmf);
+}
+
+static const struct clk_ops cam_clk_ops = {
+ .prepare = cam_clk_prepare,
+ .unprepare = cam_clk_unprepare,
+};
+
+static const char *cam_clk_p_names[] = { "sclk_cam0", "sclk_cam1" };
+
+static int fimc_md_register_clk_provider(struct fimc_md *fmd)
+{
+ struct cam_clk_provider *clk_provider = &fmd->clk_provider;
+ struct device *dev = &fmd->pdev->dev;
+ struct device_node *node;
+ unsigned int nclocks;
+
+ node = of_get_child_by_name(dev->of_node, "clock-controller");
+ if (!node) {
+ dev_warn(dev, "clock-controller node at %s not found\n",
+ dev->of_node->full_name);
+ return 0;
+ }
+ /* Instantiate the clocks */
+ for (nclocks = 0; nclocks < FIMC_MAX_CAMCLKS; nclocks++) {
+ struct clk_init_data init;
+ char clk_name[16];
+ struct clk *clk;
+ struct cam_clk *camclk;
+
+ camclk = devm_kzalloc(dev, sizeof(*camclk), GFP_KERNEL);
+ if (!camclk)
+ return -ENOMEM;
+
+ snprintf(clk_name, sizeof(clk_name), "cam_clkout%d", nclocks);
+
+ init.name = clk_name;
+ init.ops = &cam_clk_ops;
+ init.flags = CLK_SET_RATE_PARENT;
+ init.parent_names = &cam_clk_p_names[nclocks];
+ init.num_parents = 1;
+ camclk->hw.init = &init;
+ camclk->fmd = fmd;
+
+ clk = devm_clk_register(dev, &camclk->hw);
+ if (IS_ERR(clk)) {
+ kfree(camclk);
+ return PTR_ERR(clk);
+ }
+ clk_provider->clks[nclocks] = clk;
+ }
+
+ clk_provider->clk_data.clks = clk_provider->clks;
+ clk_provider->clk_data.clk_num =
[REVIEW PATCH 3/6] exynos4-is: Simplify sclk_cam clocks handling
Use clk_prepare_enable()/clk_disable_unprepare() instead of
separately prearing/unparing the clk_cam clocks. This simplifies
the code that is now mostly not going to be used, function
__fimc_md_set_camclk() is only left for S5PV210 platform which
is not yet converted to Device Tree.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/platform/exynos4-is/media-dev.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 91f21e2..41366fe 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1150,7 +1150,6 @@ static void fimc_md_put_clocks(struct fimc_md *fmd)
while (--i >= 0) {
if (IS_ERR(fmd->camclk[i].clock))
continue;
- clk_unprepare(fmd->camclk[i].clock);
clk_put(fmd->camclk[i].clock);
fmd->camclk[i].clock = ERR_PTR(-EINVAL);
}
@@ -1169,7 +1168,7 @@ static int fimc_md_get_clocks(struct fimc_md *fmd)
struct device *dev = NULL;
char clk_name[32];
struct clk *clock;
- int ret, i;
+ int i, ret = 0;
for (i = 0; i < FIMC_MAX_CAMCLKS; i++)
fmd->camclk[i].clock = ERR_PTR(-EINVAL);
@@ -1187,12 +1186,6 @@ static int fimc_md_get_clocks(struct fimc_md *fmd)
ret = PTR_ERR(clock);
break;
}
- ret = clk_prepare(clock);
- if (ret < 0) {
- clk_put(clock);
- fmd->camclk[i].clock = ERR_PTR(-EINVAL);
- break;
- }
fmd->camclk[i].clock = clock;
}
if (ret)
@@ -1249,7 +1242,7 @@ static int __fimc_md_set_camclk(struct fimc_md *fmd,
ret = pm_runtime_get_sync(fmd->pmf);
if (ret < 0)
return ret;
- ret = clk_enable(camclk->clock);
+ ret = clk_prepare_enable(camclk->clock);
dbg("Enabled camclk %d: f: %lu", si->clk_id,
clk_get_rate(camclk->clock));
}
@@ -1260,7 +1253,7 @@ static int __fimc_md_set_camclk(struct fimc_md *fmd,
return 0;
if (--camclk->use_count == 0) {
- clk_disable(camclk->clock);
+ clk_disable_unprepare(camclk->clock);
pm_runtime_put(fmd->pmf);
dbg("Disabled camclk %d", si->clk_id);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 2/6] V4L: s5k6a3: Add support for asynchronous subdev registration
This patch converts the driver to use v4l2 asynchronous subdev
registration API an the common clock API.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/i2c/s5k6a3.c | 63
1 file changed, 52 insertions(+), 11 deletions(-)
diff --git a/drivers/media/i2c/s5k6a3.c b/drivers/media/i2c/s5k6a3.c
index 21680fa..ccbb4fc 100644
--- a/drivers/media/i2c/s5k6a3.c
+++ b/drivers/media/i2c/s5k6a3.c
@@ -34,6 +34,7 @@
#define S5K6A3_DEF_PIX_HEIGHT 732
#define S5K6A3_DRV_NAME"S5K6A3"
+#define S5K6A3_CLK_NAME"mclk"
#define S5K6A3_NUM_SUPPLIES2
@@ -55,6 +56,7 @@ struct s5k6a3 {
int gpio_reset;
struct mutex lock;
struct v4l2_mbus_framefmt format;
+ struct clk *clock;
u32 clock_frequency;
};
@@ -180,19 +182,29 @@ static int s5k6a3_s_power(struct v4l2_subdev *sd, int on)
{
struct s5k6a3 *sensor = sd_to_s5k6a3(sd);
int gpio = sensor->gpio_reset;
- int ret;
+ int ret = 0;
if (on) {
+ sensor->clock = clk_get(sensor->dev, S5K6A3_CLK_NAME);
+ if (IS_ERR(sensor->clock))
+ return PTR_ERR(sensor->clock);
+
+ ret = clk_set_rate(sensor->clock, sensor->clock_frequency);
+ if (ret < 0)
+ goto clk_put;
+
ret = pm_runtime_get(sensor->dev);
if (ret < 0)
- return ret;
+ goto clk_put;
ret = regulator_bulk_enable(S5K6A3_NUM_SUPPLIES,
sensor->supplies);
- if (ret < 0) {
- pm_runtime_put(sensor->dev);
- return ret;
- }
+ if (ret < 0)
+ goto rpm_put;
+
+ ret = clk_prepare_enable(sensor->clock);
+ if (ret < 0)
+ goto reg_dis;
if (gpio_is_valid(gpio)) {
gpio_set_value(gpio, 1);
@@ -208,10 +220,14 @@ static int s5k6a3_s_power(struct v4l2_subdev *sd, int on)
if (gpio_is_valid(gpio))
gpio_set_value(gpio, 0);
- ret = regulator_bulk_disable(S5K6A3_NUM_SUPPLIES,
-sensor->supplies);
- if (!ret)
- pm_runtime_put(sensor->dev);
+ clk_disable_unprepare(sensor->clock);
+reg_dis:
+ regulator_bulk_disable(S5K6A3_NUM_SUPPLIES,
+ sensor->supplies);
+rpm_put:
+ pm_runtime_put(sensor->dev);
+clk_put:
+ clk_put(sensor->clock);
}
return ret;
}
@@ -239,6 +255,7 @@ static int s5k6a3_probe(struct i2c_client *client,
mutex_init(&sensor->lock);
sensor->gpio_reset = -EINVAL;
+ sensor->clock = ERR_PTR(-EINVAL);
sensor->dev = dev;
gpio = of_get_gpio_flags(dev->of_node, 0, NULL);
@@ -250,6 +267,13 @@ static int s5k6a3_probe(struct i2c_client *client,
}
sensor->gpio_reset = gpio;
+ if (of_property_read_u32(dev->of_node, "clock-frequency",
+&sensor->clock_frequency)) {
+ dev_err(dev, "clock-frequency property not found at %s\n",
+ dev->of_node->full_name);
+ return -EINVAL;
+ }
+
for (i = 0; i < S5K6A3_NUM_SUPPLIES; i++)
sensor->supplies[i].supply = s5k6a3_supply_names[i];
@@ -258,6 +282,11 @@ static int s5k6a3_probe(struct i2c_client *client,
if (ret < 0)
return ret;
+ /* Defer probing if the clock is not available yet */
+ sensor->clock = clk_get(dev, S5K6A3_CLK_NAME);
+ if (IS_ERR(sensor->clock))
+ return -EPROBE_DEFER;
+
sd = &sensor->subdev;
v4l2_i2c_subdev_init(sd, client, &s5k6a3_subdev_ops);
snprintf(sd->name, sizeof(sd->name), S5K6A3_DRV_NAME);
@@ -275,12 +304,24 @@ static int s5k6a3_probe(struct i2c_client *client,
pm_runtime_no_callbacks(dev);
pm_runtime_enable(dev);
- return 0;
+ ret = v4l2_async_register_subdev(sd);
+
+ /*
+* Don't hold reference to the clock to avoid circular dependency
+* between the subdev and the host driver, in case the host is
+* a supplier of the clock.
+* clk_get()/clk_put() will be called in s_power callback.
+*/
+ clk_put(sensor->clock);
+
+ return ret;
}
static int s5k6a3_remove(struct i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
+
+ v4l2_async_unregister_subdev(sd);
media_entity_cleanup(&sd->entity);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-
[REVIEW PATCH 1/6] V4L: Add driver for s5k6a3 image sensor
This patch adds subdev driver for Samsung S5K6A3 raw image sensor.
As it is intended at the moment to be used only with the Exynos
FIMC-IS (camera ISP) subsystem it is pretty minimal subdev driver.
It doesn't do any I2C communication since the sensor is controlled
by the ISP and its own firmware.
This driver can be updated in future, should anyone need it to be
a regular subdev driver where the main CPU communicates with the
sensor directly.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/i2c/Kconfig |8 ++
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k6a3.c | 315
3 files changed, 324 insertions(+)
create mode 100644 drivers/media/i2c/s5k6a3.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 3367ec2..dbd9cbb 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -564,6 +564,14 @@ config VIDEO_S5K6AA
This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
+config VIDEO_S5K6A3
+ tristate "Samsung S5K6A3 sensor support"
+ depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+ ---help---
+ This is a V4L2 sensor-level driver for Samsung S5K6A3 raw
+ camera sensor.
+
config VIDEO_S5K4ECGX
tristate "Samsung S5K4ECGX sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index d590925..44998a2 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
+obj-$(CONFIG_VIDEO_S5K6A3) += s5k6a3.o
obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o
obj-$(CONFIG_VIDEO_S5K5BAF)+= s5k5baf.o
obj-$(CONFIG_VIDEO_S5C73M3)+= s5c73m3/
diff --git a/drivers/media/i2c/s5k6a3.c b/drivers/media/i2c/s5k6a3.c
new file mode 100644
index 000..21680fa
--- /dev/null
+++ b/drivers/media/i2c/s5k6a3.c
@@ -0,0 +1,315 @@
+/*
+ * Samsung S5K6A3 image sensor driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define S5K6A3_SENSOR_MAX_WIDTH1392
+#define S5K6A3_SENSOR_MAX_HEIGHT 1392
+#define S5K6A3_SENSOR_MIN_WIDTH32
+#define S5K6A3_SENSOR_MIN_HEIGHT 32
+
+#define S5K6A3_DEF_PIX_WIDTH 1296
+#define S5K6A3_DEF_PIX_HEIGHT 732
+
+#define S5K6A3_DRV_NAME"S5K6A3"
+
+#define S5K6A3_NUM_SUPPLIES2
+
+/**
+ * struct s5k6a3 - fimc-is sensor data structure
+ * @dev: pointer to this I2C client device structure
+ * @subdev: the image sensor's v4l2 subdev
+ * @pad: subdev media source pad
+ * @supplies: image sensor's voltage regulator supplies
+ * @gpio_reset: GPIO connected to the sensor's reset pin
+ * @lock: mutex protecting the structure's members below
+ * @format: media bus format at the sensor's source pad
+ */
+struct s5k6a3 {
+ struct device *dev;
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct regulator_bulk_data supplies[S5K6A3_NUM_SUPPLIES];
+ int gpio_reset;
+ struct mutex lock;
+ struct v4l2_mbus_framefmt format;
+ u32 clock_frequency;
+};
+
+static const char * const s5k6a3_supply_names[] = {
+ "svdda",
+ "svddio"
+};
+
+static inline struct s5k6a3 *sd_to_s5k6a3(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct s5k6a3, subdev);
+}
+
+static const struct v4l2_mbus_framefmt s5k6a3_formats[] = {
+ {
+ .code = V4L2_MBUS_FMT_SGRBG10_1X10,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .field = V4L2_FIELD_NONE,
+ }
+};
+
+static const struct v4l2_mbus_framefmt *find_sensor_format(
+ struct v4l2_mbus_framefmt *mf)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(s5k6a3_formats); i++)
+ if (mf->code == s5k6a3_formats[i].code)
+ return &s5k6a3_formats[i];
+
+ return &s5k6a3_formats[0];
+}
+
+static int s5k6a3_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ if (code->index >= ARRAY_SIZE(s5k6a3_formats))
+ return -EINVAL;
+
+ code->code = s5k6a3_formats[code->index].code;
+
[REVIEW PATCH 0/6] exynos4-is: Asynchronous subdev registration support
This patch series is a refactoring of the exynos4-is driver to get rid of the common fimc-is-sensor driver and to adapt it to use "standard" sensor subdev drivers, one per each image sensor type. Then a clock provider is added to the exynos4-is driver and the s5k6a3 subdev is modified to use one of the clocks registered by exynos4-is. Arun, I think you could reuse the s5k6a3 sensor for your work on the Exynos5 FIMC-IS driver. One advantage of separate sensor drivers is that the power on/off sequences can be written specifically for each sensor. We are probably going to need such sequences per board in future. Also having the clock control inside the sensor subdev allows to better match the hardware power on/off sequence requirements, however the S5K6A3 sensor can have active clock signal on its clock input pin even when all its power supplies are turned off. I'm posting this series before having a proper implementation for clk_unregister() in the clock framework, so you are not blocked with your Exynos5 FIMC-IS works. This series with all dependencies can be found at: http://git.linuxtv.org/snawrocki/samsung.git/exynos4-is-clk Thanks, Sylwester Sylwester Nawrocki (6): V4L: Add driver for s5k6a3 image sensor V4L: s5k6a3: Add support for asynchronous subdev registration exynos4-is: Simplify sclk_cam clocks handling exynos4-is: Add clock provider for the external clocks exynos4-is: Use external s5k6a3 sensor driver exynos4-is: Add support for asynchronous sensor subddevs registration .../devicetree/bindings/media/samsung-fimc.txt | 17 +- drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k6a3.c | 356 drivers/media/platform/exynos4-is/fimc-is-regs.c |2 +- drivers/media/platform/exynos4-is/fimc-is-sensor.c | 285 +--- drivers/media/platform/exynos4-is/fimc-is-sensor.h | 49 +-- drivers/media/platform/exynos4-is/fimc-is.c| 96 +++--- drivers/media/platform/exynos4-is/fimc-is.h|4 +- drivers/media/platform/exynos4-is/media-dev.c | 268 ++- drivers/media/platform/exynos4-is/media-dev.h | 31 +- 11 files changed, 650 insertions(+), 467 deletions(-) create mode 100644 drivers/media/i2c/s5k6a3.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > > Ick, no. Why can't you just pass the pointer to the phy itself? If
> > > > you
> > > > had a "priv" pointer to search from, then you could have just passed
> > > > the
> > > > original phy pointer in the first place, right?
> > >
> > > IMHO it would be better if you provided some code example, but let's
> > > try to check if I understood you correctly.
> >
> > It's not my code that I want to have added, so I don't have to write
> > examples, I just get to complain about the existing stuff :)
>
> Still, I think that some small code snippets illustrating the idea are
> really helpful.
>
> > > 8><
> > >
> > >
> > > [Board file]
> > >
> > > static struct phy my_phy;
> > >
> > > static struct platform_device phy_pdev = {
> > >
> > > /* ... */
> > > .platform_data = &my_phy;
> > > /* ... */
> > >
> > > };
> > >
> > > static struct platform_device phy_pdev = {
> > >
> > > /* ... */
> > > .platform_data = &my_phy;
> > > /* ... */
> > >
> > > };
> > >
> > > [Provider driver]
> > >
> > > struct phy *phy = pdev->dev.platform_data;
> > >
> > > ret = phy_create(phy);
> > >
> > > [Consumer driver]
> > >
> > > struct phy *phy = pdev->dev.platform_data;
> > >
> > > ret = phy_get(&pdev->dev, phy);
> > >
> > > ---
> > > -><8
> > >
> > > Is this what you mean?
> >
> > No. Well, kind of. What's wrong with using the platform data structure
> > unique to the board to have the pointer?
> >
> > For example (just randomly picking one), the ata-pxa driver would change
> > include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
> >
> > struct phy;
> >
> > struct pata_pxa_pdata {
> > /* PXA DMA DREQ<0:2> pin */
> > uint32_tdma_dreq;
> > /* Register shift */
> > uint32_treg_shift;
> > /* IRQ flags */
> > uint32_tirq_flags;
> > /* PHY */
> > struct phy *phy;
> > };
> >
> > Then, when you create the platform, set the phy* pointer with a call to
> > phy_create(). Then you can use that pointer wherever that plaform data
> > is available (i.e. whereever platform_data is at).
>
> Hmm? So, do you suggest to call phy_create() from board file? What phy_ops
> struct and other hardware parameters would it take?
>
> > > > The issue is that a string "name" is not going to scale at all, as it
> > > > requires hard-coded information that will change over time (as the
> > > > existing clock interface is already showing.)
> > >
> > > I fully agree that a simple, single string will not scale even in some,
> > > not so uncommon cases, but there is already a lot of existing lookup
> > > solutions over the kernel and so there is no point in introducing
> > > another one.
> > I'm trying to get _rid_ of lookup "solutions" and just use a real
> > pointer, as you should. I'll go tackle those other ones after this one
> > is taken care of, to show how the others should be handled as well.
>
> There was a reason for introducing lookup solutions. The reason was that in
> board file there is no way to get a pointer to something that is going to be
> created much later in time. We don't do time travel ;-).
>
> > > > Please just pass the real "phy" pointer around, that's what it is
> > > > there
> > > > for. Your "board binding" logic/code should be able to handle this,
> > > > as
> > > > it somehow was going to do the same thing with a "name".
> > >
> > > It's technically correct, but quality of this solution isn't really
> > > nice, because it's a layering violation (at least if I understood what
> > > you mean). This is because you need to have full definition of struct
> > > phy in board file and a structure that is used as private data in PHY
> > > core comes from platform code.
> >
> > No, just a pointer, you don't need the "full" structure until you get to
> > some .c code that actually manipulates the phy itself, for all other
> > places, you are just dealing with a pointer and a structure you never
> > reference.
> >
> > Does that make more sense?
>
> Well, to the point that I think I now understood your suggestion.
> Unfortunately the suggestion alone isn't really something that can be done,
> considering how driver core and generic frameworks work.
Ok, given that I seem to be totally confused as to exactly how the
board-specific frameworks work, I'll take your word for it.
But again, I will not accept "lookup by name" type solutions, when the
"name" is dynamic and will change. Because you are using a "name", you
can deal with a pointer, putting it _somewhere_ in your board-specific
data structures, as you are going to need to store it anyway (hint, you
had to get that "name" from somewhere, right?)
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote: > On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote: > > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote: > > > > I fully agree that a simple, single string will not scale even in some, > > > not > > > so uncommon cases, but there is already a lot of existing lookup > > > solutions > > > over the kernel and so there is no point in introducing another one. > > > I'm trying to get _rid_ of lookup "solutions" and just use a real > > pointer, as you should. I'll go tackle those other ones after this one > > is taken care of, to show how the others should be handled as well. > > What are the problems you are seeing with doing things with lookups? You don't "know" the id of the device you are looking up, due to multiple devices being in the system (dynamic ids, look back earlier in this thread for details about that.) > Having to write platform data for everything gets old fast and the code > duplication is pretty tedious... Adding a single pointer is "tedious"? Where is the "name" that you are going to lookup going to come from? That code doesn't write itself... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > Ick, no. Why can't you just pass the pointer to the phy itself? If
> > > you
> > > had a "priv" pointer to search from, then you could have just passed
> > > the
> > > original phy pointer in the first place, right?
> >
> > IMHO it would be better if you provided some code example, but let's
> > try to check if I understood you correctly.
>
> It's not my code that I want to have added, so I don't have to write
> examples, I just get to complain about the existing stuff :)
Still, I think that some small code snippets illustrating the idea are
really helpful.
> > 8><
> >
> >
> > [Board file]
> >
> > static struct phy my_phy;
> >
> > static struct platform_device phy_pdev = {
> >
> > /* ... */
> > .platform_data = &my_phy;
> > /* ... */
> >
> > };
> >
> > static struct platform_device phy_pdev = {
> >
> > /* ... */
> > .platform_data = &my_phy;
> > /* ... */
> >
> > };
> >
> > [Provider driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_create(phy);
> >
> > [Consumer driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_get(&pdev->dev, phy);
> >
> > ---
> > -><8
> >
> > Is this what you mean?
>
> No. Well, kind of. What's wrong with using the platform data structure
> unique to the board to have the pointer?
>
> For example (just randomly picking one), the ata-pxa driver would change
> include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
>
> struct phy;
>
> struct pata_pxa_pdata {
> /* PXA DMA DREQ<0:2> pin */
> uint32_tdma_dreq;
> /* Register shift */
> uint32_treg_shift;
> /* IRQ flags */
> uint32_tirq_flags;
> /* PHY */
> struct phy *phy;
> };
>
> Then, when you create the platform, set the phy* pointer with a call to
> phy_create(). Then you can use that pointer wherever that plaform data
> is available (i.e. whereever platform_data is at).
Hmm? So, do you suggest to call phy_create() from board file? What phy_ops
struct and other hardware parameters would it take?
> > > The issue is that a string "name" is not going to scale at all, as it
> > > requires hard-coded information that will change over time (as the
> > > existing clock interface is already showing.)
> >
> > I fully agree that a simple, single string will not scale even in some,
> > not so uncommon cases, but there is already a lot of existing lookup
> > solutions over the kernel and so there is no point in introducing
> > another one.
> I'm trying to get _rid_ of lookup "solutions" and just use a real
> pointer, as you should. I'll go tackle those other ones after this one
> is taken care of, to show how the others should be handled as well.
There was a reason for introducing lookup solutions. The reason was that in
board file there is no way to get a pointer to something that is going to be
created much later in time. We don't do time travel ;-).
> > > Please just pass the real "phy" pointer around, that's what it is
> > > there
> > > for. Your "board binding" logic/code should be able to handle this,
> > > as
> > > it somehow was going to do the same thing with a "name".
> >
> > It's technically correct, but quality of this solution isn't really
> > nice, because it's a layering violation (at least if I understood what
> > you mean). This is because you need to have full definition of struct
> > phy in board file and a structure that is used as private data in PHY
> > core comes from platform code.
>
> No, just a pointer, you don't need the "full" structure until you get to
> some .c code that actually manipulates the phy itself, for all other
> places, you are just dealing with a pointer and a structure you never
> reference.
>
> Does that make more sense?
Well, to the point that I think I now understood your suggestion.
Unfortunately the suggestion alone isn't really something that can be done,
considering how driver core and generic frameworks work.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote: > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote: > > I fully agree that a simple, single string will not scale even in some, not > > so uncommon cases, but there is already a lot of existing lookup solutions > > over the kernel and so there is no point in introducing another one. > I'm trying to get _rid_ of lookup "solutions" and just use a real > pointer, as you should. I'll go tackle those other ones after this one > is taken care of, to show how the others should be handled as well. What are the problems you are seeing with doing things with lookups? Having to write platform data for everything gets old fast and the code duplication is pretty tedious... signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:05AM -0400, Alan Stern wrote: > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > > Okay. Are PHYs _always_ platform devices? > > > They can be i2c, spi or any other device types as well. > In those other cases, presumably there is no platform data associated > with the PHY since it isn't a platform device. Then how does the > kernel know which controller is attached to the PHY? Is this spelled > out in platform data associated with the PHY's i2c/spi/whatever parent? Platform data is nothing to do with the platform bus - it's board specific data (ie, data for the platform) and can be done with any device. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > Ick, no. Why can't you just pass the pointer to the phy itself? If you
> > had a "priv" pointer to search from, then you could have just passed the
> > original phy pointer in the first place, right?
>
> IMHO it would be better if you provided some code example, but let's try to
> check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
> 8><
>
> [Board file]
>
> static struct phy my_phy;
>
> static struct platform_device phy_pdev = {
> /* ... */
> .platform_data = &my_phy;
> /* ... */
> };
>
> static struct platform_device phy_pdev = {
> /* ... */
> .platform_data = &my_phy;
> /* ... */
> };
>
> [Provider driver]
>
> struct phy *phy = pdev->dev.platform_data;
>
> ret = phy_create(phy);
>
> [Consumer driver]
>
> struct phy *phy = pdev->dev.platform_data;
>
> ret = phy_get(&pdev->dev, phy);
>
> ><8
>
> Is this what you mean?
No. Well, kind of. What's wrong with using the platform data structure
unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would change
include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ<0:2> pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call to
phy_create(). Then you can use that pointer wherever that plaform data
is available (i.e. whereever platform_data is at).
> > The issue is that a string "name" is not going to scale at all, as it
> > requires hard-coded information that will change over time (as the
> > existing clock interface is already showing.)
>
> I fully agree that a simple, single string will not scale even in some, not
> so uncommon cases, but there is already a lot of existing lookup solutions
> over the kernel and so there is no point in introducing another one.
I'm trying to get _rid_ of lookup "solutions" and just use a real
pointer, as you should. I'll go tackle those other ones after this one
is taken care of, to show how the others should be handled as well.
> > Please just pass the real "phy" pointer around, that's what it is there
> > for. Your "board binding" logic/code should be able to handle this, as
> > it somehow was going to do the same thing with a "name".
>
> It's technically correct, but quality of this solution isn't really nice,
> because it's a layering violation (at least if I understood what you mean).
> This is because you need to have full definition of struct phy in board file
> and a structure that is used as private data in PHY core comes from
> platform code.
No, just a pointer, you don't need the "full" structure until you get to
some .c code that actually manipulates the phy itself, for all other
places, you are just dealing with a pointer and a structure you never
reference.
Does that make more sense?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: Add USB host node for Exynos4
This patch adds EHCI and OHCI host device nodes for Exynos4.
Signed-off-by: Dongjin Kim
---
arch/arm/boot/dts/exynos4.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f94fe8..1cdbf89 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -155,6 +155,26 @@
status = "disabled";
};
+ ehci@1258 {
+ compatible = "samsung,exynos4210-ehci";
+ reg = <0x1258 0x100>;
+ interrupts = <0 70 0>;
+ status = "disabled";
+
+ clocks = <&clock 304>;
+ clock-names = "usbhost";
+ };
+
+ ohci@1259 {
+ compatible = "samsung,exynos4210-ohci";
+ reg = <0x1258 0x100>;
+ interrupts = <0 70 0>;
+ status = "disabled";
+
+ clocks = <&clock 304>;
+ clock-names = "usbhost";
+ };
+
mfc: codec@1340 {
compatible = "samsung,mfc-v5";
reg = <0x1340 0x1>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: Add USBPHY nodes to Exynos4x12
This patch adds device nodes for USBPHY to Exynos4x12.
Signed-off-by: Dongjin Kim
---
arch/arm/boot/dts/exynos4x12.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 01da194..9c3335b 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -73,4 +73,22 @@
clock-names = "sclk_fimg2d", "fimg2d";
status = "disabled";
};
+
+ usbphy@125B0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "samsung,exynos4x12-usb2phy";
+ reg = <0x125B 0x100>;
+ ranges;
+
+ clocks = <&clock 2>, <&clock 305>;
+ clock-names = "xusbxti", "otg";
+ status = "disabled";
+
+ usbphy-sys {
+ /* USB device and host PHY_CONTROL registers */
+ reg = <0x10020704 0xc>,
+ <0x1001021c 0x4>;
+ };
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 09:18:46 Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > >> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > >>> Hi Alan,
> > >
> > > Thanks for helping to clarify the issues here.
> > >
> > Okay. Are PHYs _always_ platform devices?
> > >>>
> > >>> They can be i2c, spi or any other device types as well.
> > >
> > > In those other cases, presumably there is no platform data associated
> > > with the PHY since it isn't a platform device. Then how does the
> > > kernel know which controller is attached to the PHY? Is this spelled
> > > out in platform data associated with the PHY's i2c/spi/whatever
> > > parent?
> >
> > Yes. I think we could use i2c_board_info for passing platform data.
> >
> > >> PHY. Currently this information is represented by name or
> > >>
> > >> ID
> > >>
> > >> strings embedded in platform data.
> > >
> > > right. It's embedded in the platform data of the controller.
> >
> > It must also be embedded in the PHY's platform data somehow.
> > Otherwise, how would the kernel know which PHY to use?
> > >>>
> > >>> By using a PHY lookup as Stephen and I suggested in our previous
> > >>> replies. Without any extra data in platform data. (I have even
> > >>> posted a
> > >>> code example.)
> > >
> > > I don't understand, because I don't know what "a PHY lookup" does.
> >
> > It is how the PHY framework finds a PHY, when the controller (say
> > USB)requests a PHY from the PHY framework.
> >
> > In this case, it doesn't matter where the platform_device
> > structures
> > are created or where the driver source code is. Let's take a
> > simple
> > example. Suppose the system design includes a PHY named "foo".
> > Then
> > the board file could contain:
> >
> > struct phy_info { ... } phy_foo;
> > EXPORT_SYMBOL_GPL(phy_foo);
> >
> > and a header file would contain:
> >
> > extern struct phy_info phy_foo;
> >
> > The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > client could call phy_find(&phy_foo). Or something like that;
> > make up
> > your own structure tags and function names.
> >
> > It's still possible to have conflicts, but now two PHYs with the
> > same
> > name (or a misspelled name somewhere) will cause an error at link
> > time.
> > >>>
> > >>> This is incorrect, sorry. First of all it's a layering violation -
> > >>> you
> > >>> export random driver-specific symbols from one driver to another.
> > >>> Then
> > >
> > > No, that's not what I said. Neither the PHY driver nor the
> > > controller
> > > driver exports anything to the other. Instead, both drivers use data
> > > exported by the board file.
> >
> > I think instead we can use the same data while creating the platform
> > data of the controller and the PHY.
> > The PHY driver while creating the PHY (using PHY framework) will also
> > pass the *data* it actually got from the platform data to the
> > framework. The PHY user driver (USB), while requesting for the PHY
> > (from the PHY framework) will pass the *data* it got from its platform
> > data.
> > The PHY framework can do a comparison of the *data* pointers it has and
> > return the appropriate PHY to the controller.
> >
> > >>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
> > >>> and
> > >>> there are two types of consumer drivers (e.g. USB host
> > >>> controllers). Now
> > >>> consider following mapping:
> > >>>
> > >>> SoC PHY consumer
> > >>> A PHY1HOST1
> > >>> B PHY1HOST2
> > >>> C PHY2HOST1
> > >>> D PHY2HOST2
> > >>>
> > >>> So we have to be able to use any of the PHYs with any of the host
> > >>> drivers. This means you would have to export symbol with the same
> > >>> name
> > >>> from both PHY drivers, which obviously would not work in this case,
> > >>> because having both drivers enabled (in a multiplatform aware
> > >>> configuration) would lead to linking conflict.
> > >
> > > You're right; the scheme was too simple. Instead, the board file
> > > must
> > > export two types of data structures, one for PHYs and one for
> > > controllers. Like this:
> > >
> > > struct phy_info {
> > >
> > > /* Info for the controller attached to this PHY */
> > > struct controller_info *hinfo;
> > >
> > > };
> > >
> > > struct controller_info {
> > >
> > > /* Info for the PHY which this controller is attached to */
> > > struct phy_info *pinfo;
> > >
> > > };
> > >
> > > The board file for SoC A would contain:
> > >
> > > struct phy_info phy1 = {&host1);
> > > EXPORT_SYMBOL(phy1);
> > > struct controller_info host1 = {&phy1};
> > > EXPORT_SYMBOL(host1);
> > >
> > > The boa
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 09:58:34PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
>
> On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
> > On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi,
> >>
> >> On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> >>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> >>>
> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > Hi Alan,
> >>>
> >>> Thanks for helping to clarify the issues here.
> >>>
> >> Okay. Are PHYs _always_ platform devices?
> >
> > They can be i2c, spi or any other device types as well.
> >>>
> >>> In those other cases, presumably there is no platform data associated
> >>> with the PHY since it isn't a platform device. Then how does the
> >>> kernel know which controller is attached to the PHY? Is this spelled
> >>> out in platform data associated with the PHY's i2c/spi/whatever parent?
> .
> .
>
> .
> .
> >>
> >>static struct phy *phy_lookup(void *priv) {
> >>.
> >>.
> >>if (phy->priv==priv) //instead of string comparison, we'll use
> >> pointer
> >>return phy;
> >>}
> >>
> >> PHY driver should be like
> >>phy_create((dev, ops, pdata->info);
> >>
> >> The controller driver would do
> >>phy_get(dev, NULL, pdata->info);
> >>
> >> Now the PHY framework will check for a match of *priv* pointer and return
> >> the PHY.
> >>
> >> I think this should be possible?
> >
> > Ick, no. Why can't you just pass the pointer to the phy itself? If you
> > had a "priv" pointer to search from, then you could have just passed the
> > original phy pointer in the first place, right?
> >
> > The issue is that a string "name" is not going to scale at all, as it
> > requires hard-coded information that will change over time (as the
> > existing clock interface is already showing.)
> >
> > Please just pass the real "phy" pointer around, that's what it is there
> > for. Your "board binding" logic/code should be able to handle this, as
> > it somehow was going to do the same thing with a "name".
>
> The problem is the board file won't have the *phy* pointer. *phy* pointer is
> created at a much later time when the phy driver is probed.
Ok, then save it then, as no one could have used it before then, right?
All I don't want to see is any "get by name/void *" functions in the
api, as that way is fragile and will break, as people have already
shown.
Just pass the real pointer around. If that is somehow a problem, then
something larger is a problem with how board devices are tied together :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Greg,
On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
>>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
>>>
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> Hi Alan,
>>>
>>> Thanks for helping to clarify the issues here.
>>>
>> Okay. Are PHYs _always_ platform devices?
>
> They can be i2c, spi or any other device types as well.
>>>
>>> In those other cases, presumably there is no platform data associated
>>> with the PHY since it isn't a platform device. Then how does the
>>> kernel know which controller is attached to the PHY? Is this spelled
>>> out in platform data associated with the PHY's i2c/spi/whatever parent?
.
.
.
.
>>
>> static struct phy *phy_lookup(void *priv) {
>> .
>> .
>> if (phy->priv==priv) //instead of string comparison, we'll use
>> pointer
>> return phy;
>> }
>>
>> PHY driver should be like
>> phy_create((dev, ops, pdata->info);
>>
>> The controller driver would do
>> phy_get(dev, NULL, pdata->info);
>>
>> Now the PHY framework will check for a match of *priv* pointer and return
>> the PHY.
>>
>> I think this should be possible?
>
> Ick, no. Why can't you just pass the pointer to the phy itself? If you
> had a "priv" pointer to search from, then you could have just passed the
> original phy pointer in the first place, right?
>
> The issue is that a string "name" is not going to scale at all, as it
> requires hard-coded information that will change over time (as the
> existing clock interface is already showing.)
>
> Please just pass the real "phy" pointer around, that's what it is there
> for. Your "board binding" logic/code should be able to handle this, as
> it somehow was going to do the same thing with a "name".
The problem is the board file won't have the *phy* pointer. *phy* pointer is
created at a much later time when the phy driver is probed.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> >
> >> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> >>> Hi Alan,
> >
> > Thanks for helping to clarify the issues here.
> >
> Okay. Are PHYs _always_ platform devices?
> >>>
> >>> They can be i2c, spi or any other device types as well.
> >
> > In those other cases, presumably there is no platform data associated
> > with the PHY since it isn't a platform device. Then how does the
> > kernel know which controller is attached to the PHY? Is this spelled
> > out in platform data associated with the PHY's i2c/spi/whatever parent?
>
> Yes. I think we could use i2c_board_info for passing platform data.
> >
> >>PHY. Currently this information is represented by name or
> >> ID
> >>strings embedded in platform data.
> >
> > right. It's embedded in the platform data of the controller.
>
> It must also be embedded in the PHY's platform data somehow.
> Otherwise, how would the kernel know which PHY to use?
> >>>
> >>> By using a PHY lookup as Stephen and I suggested in our previous
> >>> replies. Without any extra data in platform data. (I have even posted a
> >>> code example.)
> >
> > I don't understand, because I don't know what "a PHY lookup" does.
>
> It is how the PHY framework finds a PHY, when the controller (say USB)requests
> a PHY from the PHY framework.
> >
> In this case, it doesn't matter where the platform_device structures
> are created or where the driver source code is. Let's take a simple
> example. Suppose the system design includes a PHY named "foo". Then
> the board file could contain:
>
> struct phy_info { ... } phy_foo;
> EXPORT_SYMBOL_GPL(phy_foo);
>
> and a header file would contain:
>
> extern struct phy_info phy_foo;
>
> The PHY supplier could then call phy_create(&phy_foo), and the PHY
> client could call phy_find(&phy_foo). Or something like that; make up
> your own structure tags and function names.
>
> It's still possible to have conflicts, but now two PHYs with the same
> name (or a misspelled name somewhere) will cause an error at link
> time.
> >>>
> >>> This is incorrect, sorry. First of all it's a layering violation - you
> >>> export random driver-specific symbols from one driver to another. Then
> >
> > No, that's not what I said. Neither the PHY driver nor the controller
> > driver exports anything to the other. Instead, both drivers use data
> > exported by the board file.
>
> I think instead we can use the same data while creating the platform data of
> the controller and the PHY.
> The PHY driver while creating the PHY (using PHY framework) will also pass the
> *data* it actually got from the platform data to the framework.
> The PHY user driver (USB), while requesting for the PHY (from the PHY
> framework) will pass the *data* it got from its platform data.
> The PHY framework can do a comparison of the *data* pointers it has and return
> the appropriate PHY to the controller.
> >
> >>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
> >>> there are two types of consumer drivers (e.g. USB host controllers). Now
> >>> consider following mapping:
> >>>
> >>> SoC PHY consumer
> >>> A PHY1HOST1
> >>> B PHY1HOST2
> >>> C PHY2HOST1
> >>> D PHY2HOST2
> >>>
> >>> So we have to be able to use any of the PHYs with any of the host
> >>> drivers. This means you would have to export symbol with the same name
> >>> from both PHY drivers, which obviously would not work in this case,
> >>> because having both drivers enabled (in a multiplatform aware
> >>> configuration) would lead to linking conflict.
> >
> > You're right; the scheme was too simple. Instead, the board file must
> > export two types of data structures, one for PHYs and one for
> > controllers. Like this:
> >
> > struct phy_info {
> > /* Info for the controller attached to this PHY */
> > struct controller_info *hinfo;
> > };
> >
> > struct controller_info {
> > /* Info for the PHY which this controller is attached to */
> > struct phy_info *pinfo;
> > };
> >
> > The board file for SoC A would contain:
> >
> > struct phy_info phy1 = {&host1);
> > EXPORT_SYMBOL(phy1);
> > struct controller_info host1 = {&phy1};
> > EXPORT_SYMBOL(host1);
> >
> > The board file for SoC B would contain:
> >
> > struct phy_info phy1 = {&host2);
> > EXPORT_SYMBOL(phy1);
> > struct controller_info host2 = {&phy1};
> > EXPORT_SYMBOL(host2);
>
> I meant something like this
> struct phy_info {
> const char *name;
> };
>
> struct phy_platform_data {
> .
> .
> struct phy_info *info;
> };
>
> struct usb_controller_platform_data {
> .
> .
> struct phy_info *info;
> };
>
>
Re: [PATCH v4 00/20] Samsung PWM support cleanup
On Mon, Jul 22, 2013 at 09:49:49AM +0200, Tomasz Figa wrote: > On Monday 22 of July 2013 11:01:32 Kukjin Kim wrote: > > Kukjin Kim wrote: > > > Tomasz Figa wrote: > > > > On Monday 22 of July 2013 00:22:16 Sylwester Nawrocki wrote: > > > > > On 07/20/2013 02:04 AM, Tomasz Figa wrote: > > > > > > Since we now have a proper Samsung PWM clocksource driver in > > > > > > place, > > > > > > we can proceed with further cleanup of PWM timers support on > > > > > > Samsung > > > > > > SoCs.> > > > > > > > > > > > > This series attempts to achieve this goal by: > > > > > > 1) fixing up few things in samsung_pwm_timer clocksource > > > > > > driver, > > > > > > 2) moving remaining Samsung platforms to the new clocksource > > > > > > driver, > > > > > > > > > 3) removing old clocksource driver, > > > > > > 4) adding new multiplatform- and DT-aware PWM driver, > > > > > > 5) moving all Samsung platforms to use the new PWM driver, > > > > > > 6) removing old PWM driver, > > > > > > 7) removing all PWM-related code that is not used anymore. > > > > > > > > > > > > Cleaning up the PWM driver is a bit tricky, because the design > > > > > > of > > > > > > current driver makes it completely unsuitable for DT and > > > > > > multiplatform and would require a heavy rework to make it > > > > > > usable, > > > > > > breaking any existing Samsung PWM users by the way. To avoid any > > > > > > breakage this series first renames the old driver, then adds new > > > > > > one > > > > > > using original name, migrates all platforms to use it and then > > > > > > finally removes the old driver. > > > > > > > > > > > > See particular patches for more detailed descriptions. > > > > > > > > > > > > [On S3C6410-based Tiny6410 (Mini6410-compatible) with > > > > > > pwm-beeper, > > > > > > SMDK6410 with PWM backlight and Exynos4210-based Origen board > > > > > > (with > > > > > > PWM0 attached to a scope)] > > > > > > Tested-by: Tomasz Figa > > > > > > > > > > > > [On S3C2440-based Mini2440 board] > > > > > > Tested-by: Sylwester Nawrocki > > > > > > > > > > I have retested this series on top of v3.11-rc1 with pwm-backlight > > > > > > (and > > > > > > > > buzzer > > > > > as the output :)) on Mini2440. It seems to work well - generated > > > > > frequencies are correct. I'll check pulse widths with a scope > > > > tomorrow, > > > > > > > as it's a bit late > > > > > now. FWIW you can add to this series my: > > > > > > > > > > Reviewed-by: Sylwester Nawrocki > > > > > > > > Thanks. I hope we can finally get this series merged soon. > > > > > > Yes, this whole patches look good to me, and I'd like to take this > > > whole patches into the samsung tree...but need to get any response > > > from PWM guy, Thierry Reding. Let's wait for his response... > > > > To be clarify, because his ack was on v3 and I remember he had a > > comment. So would be better if we could get his ack on pwm change > > again. > > Sure. Patches 12, 13 and 16: Acked-by: Thierry Reding signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
>
>> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
>>> Hi Alan,
>
> Thanks for helping to clarify the issues here.
>
Okay. Are PHYs _always_ platform devices?
>>>
>>> They can be i2c, spi or any other device types as well.
>
> In those other cases, presumably there is no platform data associated
> with the PHY since it isn't a platform device. Then how does the
> kernel know which controller is attached to the PHY? Is this spelled
> out in platform data associated with the PHY's i2c/spi/whatever parent?
Yes. I think we could use i2c_board_info for passing platform data.
>
>> PHY. Currently this information is represented by name or
>> ID
>> strings embedded in platform data.
>
> right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
>>>
>>> By using a PHY lookup as Stephen and I suggested in our previous
>>> replies. Without any extra data in platform data. (I have even posted a
>>> code example.)
>
> I don't understand, because I don't know what "a PHY lookup" does.
It is how the PHY framework finds a PHY, when the controller (say USB)requests
a PHY from the PHY framework.
>
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named "foo". Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(&phy_foo), and the PHY
client could call phy_find(&phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
>>>
>>> This is incorrect, sorry. First of all it's a layering violation - you
>>> export random driver-specific symbols from one driver to another. Then
>
> No, that's not what I said. Neither the PHY driver nor the controller
> driver exports anything to the other. Instead, both drivers use data
> exported by the board file.
I think instead we can use the same data while creating the platform data of
the controller and the PHY.
The PHY driver while creating the PHY (using PHY framework) will also pass the
*data* it actually got from the platform data to the framework.
The PHY user driver (USB), while requesting for the PHY (from the PHY
framework) will pass the *data* it got from its platform data.
The PHY framework can do a comparison of the *data* pointers it has and return
the appropriate PHY to the controller.
>
>>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
>>> there are two types of consumer drivers (e.g. USB host controllers). Now
>>> consider following mapping:
>>>
>>> SoC PHY consumer
>>> A PHY1HOST1
>>> B PHY1HOST2
>>> C PHY2HOST1
>>> D PHY2HOST2
>>>
>>> So we have to be able to use any of the PHYs with any of the host
>>> drivers. This means you would have to export symbol with the same name
>>> from both PHY drivers, which obviously would not work in this case,
>>> because having both drivers enabled (in a multiplatform aware
>>> configuration) would lead to linking conflict.
>
> You're right; the scheme was too simple. Instead, the board file must
> export two types of data structures, one for PHYs and one for
> controllers. Like this:
>
> struct phy_info {
> /* Info for the controller attached to this PHY */
> struct controller_info *hinfo;
> };
>
> struct controller_info {
> /* Info for the PHY which this controller is attached to */
> struct phy_info *pinfo;
> };
>
> The board file for SoC A would contain:
>
> struct phy_info phy1 = {&host1);
> EXPORT_SYMBOL(phy1);
> struct controller_info host1 = {&phy1};
> EXPORT_SYMBOL(host1);
>
> The board file for SoC B would contain:
>
> struct phy_info phy1 = {&host2);
> EXPORT_SYMBOL(phy1);
> struct controller_info host2 = {&phy1};
> EXPORT_SYMBOL(host2);
I meant something like this
struct phy_info {
const char *name;
};
struct phy_platform_data {
.
.
struct phy_info *info;
};
struct usb_controller_platform_data {
.
.
struct phy_info *info;
};
struct phy_info phy_info;
While creating the phy device
struct phy_platform_data phy_data;
phy_data.info = &info;
platform_device_add_data(pdev, &phy_data, sizeof(*phy_data))
platform_device_add();
While creating the controller device
struct usb_controller_platform_data controller_data;
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:05 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > > Hi Alan,
>
> Thanks for helping to clarify the issues here.
>
> > > > Okay. Are PHYs _always_ platform devices?
> > >
> > > They can be i2c, spi or any other device types as well.
>
> In those other cases, presumably there is no platform data associated
> with the PHY since it isn't a platform device. Then how does the
> kernel know which controller is attached to the PHY? Is this spelled
> out in platform data associated with the PHY's i2c/spi/whatever parent?
>
> > > > > > PHY. Currently this information is represented by name or
> >
> > ID
> >
> > > > > > strings embedded in platform data.
> > > > >
> > > > > right. It's embedded in the platform data of the controller.
> > > >
> > > > It must also be embedded in the PHY's platform data somehow.
> > > > Otherwise, how would the kernel know which PHY to use?
> > >
> > > By using a PHY lookup as Stephen and I suggested in our previous
> > > replies. Without any extra data in platform data. (I have even posted
> > > a
> > > code example.)
>
> I don't understand, because I don't know what "a PHY lookup" does.
I have provided a code example in [1]. Feel free to ask questions about
those code snippets.
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=20889
> > > > In this case, it doesn't matter where the platform_device
> > > > structures
> > > > are created or where the driver source code is. Let's take a
> > > > simple
> > > > example. Suppose the system design includes a PHY named "foo".
> > > > Then
> > > > the board file could contain:
> > > >
> > > > struct phy_info { ... } phy_foo;
> > > > EXPORT_SYMBOL_GPL(phy_foo);
> > > >
> > > > and a header file would contain:
> > > >
> > > > extern struct phy_info phy_foo;
> > > >
> > > > The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > > > client could call phy_find(&phy_foo). Or something like that; make
> > > > up
> > > > your own structure tags and function names.
> > > >
> > > > It's still possible to have conflicts, but now two PHYs with the
> > > > same
> > > > name (or a misspelled name somewhere) will cause an error at link
> > > > time.
> > >
> > > This is incorrect, sorry. First of all it's a layering violation -
> > > you
> > > export random driver-specific symbols from one driver to another.
> > > Then
>
> No, that's not what I said. Neither the PHY driver nor the controller
> driver exports anything to the other. Instead, both drivers use data
> exported by the board file.
It's still a random, driver-specific global symbol exported from board file
to drivers.
> > > imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
> > > and
> > > there are two types of consumer drivers (e.g. USB host controllers).
> > > Now
> > > consider following mapping:
> > >
> > > SoC PHY consumer
> > > A PHY1HOST1
> > > B PHY1HOST2
> > > C PHY2HOST1
> > > D PHY2HOST2
> > >
> > > So we have to be able to use any of the PHYs with any of the host
> > > drivers. This means you would have to export symbol with the same
> > > name
> > > from both PHY drivers, which obviously would not work in this case,
> > > because having both drivers enabled (in a multiplatform aware
> > > configuration) would lead to linking conflict.
>
> You're right; the scheme was too simple. Instead, the board file must
> export two types of data structures, one for PHYs and one for
> controllers. Like this:
>
> struct phy_info {
> /* Info for the controller attached to this PHY */
> struct controller_info *hinfo;
> };
>
> struct controller_info {
> /* Info for the PHY which this controller is attached to */
> struct phy_info *pinfo;
> };
>
> The board file for SoC A would contain:
>
> struct phy_info phy1 = {&host1);
> EXPORT_SYMBOL(phy1);
> struct controller_info host1 = {&phy1};
> EXPORT_SYMBOL(host1);
>
> The board file for SoC B would contain:
>
> struct phy_info phy1 = {&host2);
> EXPORT_SYMBOL(phy1);
> struct controller_info host2 = {&phy1};
> EXPORT_SYMBOL(host2);
>
> And so on. This explicitly gives the connection between PHYs and
> controllers. The PHY providers would use &phy1 or &phy2, and the PHY
> consumers would use &host1 or &host2.
This could work assuming that only one SoC and one board is supported in
single kernel image. However it's not the case.
We've used to support multiple boards since a long time already and now for
selected platforms we even support multiplatform, i.e. multiple SoCs in
single zImage. Such solution will not work.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > Hi Alan,
Thanks for helping to clarify the issues here.
> > > Okay. Are PHYs _always_ platform devices?
> >
> > They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
> > > > > PHY. Currently this information is represented by name or
> ID
> > > > > strings embedded in platform data.
> > > >
> > > > right. It's embedded in the platform data of the controller.
> > >
> > > It must also be embedded in the PHY's platform data somehow.
> > > Otherwise, how would the kernel know which PHY to use?
> >
> > By using a PHY lookup as Stephen and I suggested in our previous
> > replies. Without any extra data in platform data. (I have even posted a
> > code example.)
I don't understand, because I don't know what "a PHY lookup" does.
> > > In this case, it doesn't matter where the platform_device structures
> > > are created or where the driver source code is. Let's take a simple
> > > example. Suppose the system design includes a PHY named "foo". Then
> > > the board file could contain:
> > >
> > > struct phy_info { ... } phy_foo;
> > > EXPORT_SYMBOL_GPL(phy_foo);
> > >
> > > and a header file would contain:
> > >
> > > extern struct phy_info phy_foo;
> > >
> > > The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > > client could call phy_find(&phy_foo). Or something like that; make up
> > > your own structure tags and function names.
> > >
> > > It's still possible to have conflicts, but now two PHYs with the same
> > > name (or a misspelled name somewhere) will cause an error at link
> > > time.
> >
> > This is incorrect, sorry. First of all it's a layering violation - you
> > export random driver-specific symbols from one driver to another. Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
> > imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
> > there are two types of consumer drivers (e.g. USB host controllers). Now
> > consider following mapping:
> >
> > SoC PHY consumer
> > A PHY1HOST1
> > B PHY1HOST2
> > C PHY2HOST1
> > D PHY2HOST2
> >
> > So we have to be able to use any of the PHYs with any of the host
> > drivers. This means you would have to export symbol with the same name
> > from both PHY drivers, which obviously would not work in this case,
> > because having both drivers enabled (in a multiplatform aware
> > configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {&host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {&phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {&host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {&phy1};
EXPORT_SYMBOL(host2);
And so on. This explicitly gives the connection between PHYs and
controllers. The PHY providers would use &phy1 or &phy2, and the PHY
consumers would use &host1 or &host2.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] spi: s3c64xx: fix casting warning
On Tuesday 23 of July 2013 14:27:53 Mark Brown wrote: > On Mon, Jul 22, 2013 at 07:09:27PM +0200, Tomasz Figa wrote: > > On Wednesday 17 of July 2013 11:08:16 Mark Brown wrote: > > > Applied, though only the cast to unsigned long should actually be > > > needed > > > - casting to void * should be good for any pointer so changing to the > > > specific struct shouldn't be essential (might catch issues due to > > > future API changes though). > > > > Well, hopefully the old S3C DMA API with all its brokenness will get > > removed soon and we switch to generic DMA engine API. (I already have > > patches to migrate Samsung ASoC and SPI is being worked on.) > > If you've done patches for ASoC note that there is generic dmaengine > helper code which should be used. Hmm, good to know. Let me see if I can adapt my patches to use this. There is no hurry, though, as we can't merge the conversion before s3c24xx DMA engine driver and my patches for s3c64xx support in PL08x driver get merged. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] spi: s3c64xx: fix casting warning
On Mon, Jul 22, 2013 at 07:09:27PM +0200, Tomasz Figa wrote: > On Wednesday 17 of July 2013 11:08:16 Mark Brown wrote: > > Applied, though only the cast to unsigned long should actually be needed > > - casting to void * should be good for any pointer so changing to the > > specific struct shouldn't be essential (might catch issues due to > > future API changes though). > Well, hopefully the old S3C DMA API with all its brokenness will get > removed soon and we switch to generic DMA engine API. (I already have > patches to migrate Samsung ASoC and SPI is being worked on.) If you've done patches for ASoC note that there is generic dmaengine helper code which should be used. signature.asc Description: Digital signature
RE: [PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 9:05 PM
> To: Inki Dae
> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list; Alex
> Williamson
> Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
> to an IOMMU group
>
> On Tue, Jul 23, 2013 at 1:21 PM, Inki Dae wrote:
> >
> >
> >> -Original Message-
> >> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> >> Sent: Tuesday, July 23, 2013 8:00 PM
> >> To: Inki Dae
> >> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
> > KyongHo;
> >> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> >> Subject: Re: [PATCH] iommu/exynos: add devices attached to the System
> MMU
> >> to an IOMMU group
> >>
> >> On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae
wrote:
> >> >
> >> >
> >> >
> >> > > -Original Message-
> >> > > From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-
> samsung-
> >> soc-
> >> > > ow...@vger.kernel.org] On Behalf Of Antonios Motakis
> >> > > Sent: Tuesday, July 23, 2013 7:02 PM
> >> > > To: linux-arm-ker...@lists.infradead.org;
> >> > io...@lists.linux-foundation.org;
> >> > > linux-samsung-soc@vger.kernel.org
> >> > > Cc: kvm...@lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo;
> Joerg
> >> > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> >> > > Subject: [PATCH] iommu/exynos: add devices attached to the System
> MMU
> >> to
> >> > > an IOMMU group
> >> > >
> >> > > IOMMU groups are expected by certain users of the IOMMU API,
> >> > > e.g. VFIO. Since each device is behind its own System MMU, we
> >> > > can allocate a new IOMMU group for each device.
> >> > >
> >> > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
> >> 00/12]
> >> > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> >> > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> >> board.
> >> > >
> >> > > Signed-off-by: Antonios Motakis
> >> > > ---
> >> > > drivers/iommu/exynos-iommu.c | 24
> >> > > 1 file changed, 24 insertions(+)
> >> > >
> >> > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
> >> iommu.c
> >> > > index 51d43bb..9f39eaa 100644
> >> > > --- a/drivers/iommu/exynos-iommu.c
> >> > > +++ b/drivers/iommu/exynos-iommu.c
> >> > > @@ -1134,6 +1134,28 @@ static phys_addr_t
> >> exynos_iommu_iova_to_phys(struct
> >> > > iommu_domain *domain,
> >> > > return phys;
> >> > > }
> >> > >
> >> > > +static int exynos_iommu_add_device(struct device *dev)
> >> > > +{
> >> > > + struct iommu_group *group;
> >> > > + int ret;
> >> > > +
> >> > > + group = iommu_group_alloc();
> >> >
> >> > Is that correct? I don't see why you allocate a group object every
> time
> >> > add_device callback is called. That doesn't have any meaning we have
> to
> >> use
> >> > iommu group feature. I think the implementation should be one more
> >> devices
> >> > per a group. So I guess a given device object should be wrapped by
> >> higher
> >> > device object than the given device object. For a good example, you
> can
> >> > refer to intel-iommu.c file.
> >>
> >> With an Intel IOMMU it can be the case that 2 devices have to share
> >> the same IOMMU mappings (i.e. you can't program them separately). With
> >> the Exynos System MMU, there is always one System MMU per device, so
> >> there is nothing stopping you from programming any 2 devices' mappings
> >> differently. So yes, the right thing to do here is to have a one to
> >> one relationship between devices and IOMMU groups.
> >
> > In case of Exynos drm driver, a unified iommu mapping table is used for
> all
> > devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use
> the
> > same iommu mapping table even though they have each iommu hardware unit.
> And
> > the iommu mapping table is just logical data structure for hardware
> > translation process by each DMA. Actually, I am considering using iommu
> > group feature for more generic implementation.
>
> But is this grouping imposed by the hardware in some way, or is it
> just the way you handle them in software? In the latter case, then
> what you are looking for are IOMMU domains (which can contain multiple
> groups). IOMMU groups describe something that is imposed by the
> hardware.
>
That's true. That seems like out of my intention that we try to use the
iommu group feature.
> >
> > And one question. Why do you allocate a iommu group object if we should
> have
> > one to one relationship between devices and iommu groups? In this case,
> is
> > there any reason you have to use the iommu group object?
>
> Generic IOMMU code (such as VFIO) will check for IOMMU groups to
> determine how the devices behind an IOMMU relate to each other.
> Returning a unique IOMMU group object per devic
[PATCH 1/2] ARM: SAMSUNG: pm: Save/restore only selected uart's registers
Basically this code gets executed only during debugging i.e when DEBUG_LL &
SAMSUNG_PM_DEBUG is on, so required only for UART used for debugging.
Since we are removing static iodesc entries for UARTs, so now only the selected
(CONFIG_DEBUG_S3C_UART) UART will be ioremapped by the debug_ll_io_init() for
DEBUG_LL, so save/restore uart registers only for selected uart.
Signed-off-by: Yadwinder Singh Brar
---
arch/arm/plat-samsung/pm.c | 14 +++---
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
index ea36136..d0c2301 100644
--- a/arch/arm/plat-samsung/pm.c
+++ b/arch/arm/plat-samsung/pm.c
@@ -80,7 +80,7 @@ unsigned char pm_uart_udivslot;
#ifdef CONFIG_SAMSUNG_PM_DEBUG
-static struct pm_uart_save uart_save[CONFIG_SERIAL_SAMSUNG_UARTS];
+static struct pm_uart_save uart_save;
static void s3c_pm_save_uart(unsigned int uart, struct pm_uart_save *save)
{
@@ -101,11 +101,7 @@ static void s3c_pm_save_uart(unsigned int uart, struct
pm_uart_save *save)
static void s3c_pm_save_uarts(void)
{
- struct pm_uart_save *save = uart_save;
- unsigned int uart;
-
- for (uart = 0; uart < CONFIG_SERIAL_SAMSUNG_UARTS; uart++, save++)
- s3c_pm_save_uart(uart, save);
+ s3c_pm_save_uart(CONFIG_DEBUG_S3C_UART, &uart_save);
}
static void s3c_pm_restore_uart(unsigned int uart, struct pm_uart_save *save)
@@ -126,11 +122,7 @@ static void s3c_pm_restore_uart(unsigned int uart, struct
pm_uart_save *save)
static void s3c_pm_restore_uarts(void)
{
- struct pm_uart_save *save = uart_save;
- unsigned int uart;
-
- for (uart = 0; uart < CONFIG_SERIAL_SAMSUNG_UARTS; uart++, save++)
- s3c_pm_restore_uart(uart, save);
+ s3c_pm_restore_uart(CONFIG_DEBUG_S3C_UART, &uart_save);
}
#else
static void s3c_pm_save_uarts(void) { }
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: EXYNOS: Fix low level debug support
Presently, using exynos_defconfig with CONFIG_DEBUG_LL and CONFIG_EARLY_PRIN
on, kernel is not booting, we are getting following:
[0.00] [ cut here ]
[0.00] kernel BUG at mm/vmalloc.c:1134!
[0.00] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc1 #633
[0.00] task: c052ec48 ti: c0524000 task.ti: c0524000
[0.00] PC is at vm_area_add_early+0x54/0x94
[0.00] LR is at add_static_vm_early+0xc/0x60
Its because exynos[4/5]_map_io() function ioremaps a single 512KB memory
size for all the four uart ports which envelopes the mapping created by
debug_ll_io_init(), called earlier in exynos_init_io().
This patch removes iodesc entries for UART controller for all Samsung SoC's,
since now the Samsung uart driver does a ioremap during probe and any needed
iomapping for earlyprintk will be handled by debug_ll_io_init().
Tested on smdk4412 and smdk5250.
Signed-off-by: Yadwinder Singh Brar
---
arch/arm/mach-exynos/common.c | 26 --
1 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 164685b..ba95e5d 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -58,7 +58,6 @@ static const char name_exynos5440[] = "EXYNOS5440";
static void exynos4_map_io(void);
static void exynos5_map_io(void);
-static void exynos5440_map_io(void);
static int exynos_init(void);
static struct cpu_table cpu_ids[] __initdata = {
@@ -95,7 +94,6 @@ static struct cpu_table cpu_ids[] __initdata = {
}, {
.idcode = EXYNOS5440_SOC_ID,
.idmask = EXYNOS5_SOC_MASK,
- .map_io = exynos5440_map_io,
.init = exynos_init,
.name = name_exynos5440,
},
@@ -150,11 +148,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
.length = SZ_64K,
.type = MT_DEVICE,
}, {
- .virtual= (unsigned long)S3C_VA_UART,
- .pfn= __phys_to_pfn(EXYNOS4_PA_UART),
- .length = SZ_512K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_CMU,
.pfn= __phys_to_pfn(EXYNOS4_PA_CMU),
.length = SZ_128K,
@@ -268,20 +261,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_PMU),
.length = SZ_64K,
.type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S3C_VA_UART,
- .pfn= __phys_to_pfn(EXYNOS5_PA_UART),
- .length = SZ_512K,
- .type = MT_DEVICE,
- },
-};
-
-static struct map_desc exynos5440_iodesc0[] __initdata = {
- {
- .virtual= (unsigned long)S3C_VA_UART,
- .pfn= __phys_to_pfn(EXYNOS5440_PA_UART0),
- .length = SZ_512K,
- .type = MT_DEVICE,
},
};
@@ -388,11 +367,6 @@ static void __init exynos5_map_io(void)
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
}
-static void __init exynos5440_map_io(void)
-{
- iotable_init(exynos5440_iodesc0, ARRAY_SIZE(exynos5440_iodesc0));
-}
-
void __init exynos_init_time(void)
{
of_clk_init(NULL);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 PATCH 0/2] EXYNOS: Fix low level debug support
Presently, using exynos_defconfig with CONFIG_DEBUG_LL and CONFIG_EARLY_PRINTK on, kernel is not booting, we are getting following: [0.00] [ cut here ] [0.00] kernel BUG at mm/vmalloc.c:1134! [0.00] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc1 #633 [0.00] task: c052ec48 ti: c0524000 task.ti: c0524000 [0.00] PC is at vm_area_add_early+0x54/0x94 [0.00] LR is at add_static_vm_early+0xc/0x60 Its because exynos[4/5]_map_io() function ioremaps a single 512KB memory size for all the four uart ports which envelopes the mapping created by debug_ll_io_init(), called earlier in exynos_init_io(). This issue seems to be occured after : commit ee4de5d99aeac44f4507b7538b2b3faedc5205b9 ARM: 7781/1: mmu: Add debug_ll_io_init() mappings to early mappings This series removes static iodesc entries for UART controller for all Samsung SoC's and modifies pm debug code to save/restore only the selected debug uart registers. changes since v1: - removed uart iodesc entires instead of just moving inside CONFIG_DEBUG_LL check, as suggested by Thomas Abraham. - Fixed the possible issue after removing uart entries pointed by Tomasz Figa. Tested doing suspend/resume on smdk5250. Yadwinder Singh Brar (2): ARM: SAMSUNG: pm: Save/restore only selected uart's registers ARM: EXYNOS: Fix low level debug support arch/arm/mach-exynos/common.c | 26 -- arch/arm/plat-samsung/pm.c| 14 +++--- 2 files changed, 3 insertions(+), 37 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Antonios Motakis
> Sent: Tuesday, July 23, 2013 3:32 PM
> To: linux-arm-ker...@lists.infradead.org; iommu@lists.linux-
> foundation.org; linux-samsung-soc@vger.kernel.org
> Cc: Sachin Kamat; Jiri Kosina; open list; Wei Yongjun; Antonios Motakis;
> Cho KyongHo; kvm...@lists.cs.columbia.edu
> Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
> an IOMMU group
>
> IOMMU groups are expected by certain users of the IOMMU API, e.g. VFIO.
> Since each device is behind its own System MMU, we can allocate a new
> IOMMU group for each device.
>
> This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
> iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> board.
>
> Signed-off-by: Antonios Motakis
> ---
> drivers/iommu/exynos-iommu.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 51d43bb..9f39eaa 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1134,6 +1134,28 @@ static phys_addr_t
> exynos_iommu_iova_to_phys(struct iommu_domain *domain,
> return phys;
> }
>
> +static int exynos_iommu_add_device(struct device *dev) {
> + struct iommu_group *group;
> + int ret;
> +
> + group = iommu_group_alloc();
> + if (IS_ERR(group)) {
> + dev_err(dev, "Failed to allocate IOMMU group\n");
> + return PTR_ERR(group);
> + }
> +
> + ret = iommu_group_add_device(group, dev);
> + iommu_group_put(group);
> +
> + return ret;
> +}
> +
> +static void exynos_iommu_remove_device(struct device *dev) {
> + iommu_group_remove_device(dev);
> +}
> +
> static struct iommu_ops exynos_iommu_ops = {
> .domain_init = &exynos_iommu_domain_init,
> .domain_destroy = &exynos_iommu_domain_destroy, @@ -1142,6 +1164,8
> @@ static struct iommu_ops exynos_iommu_ops = {
> .map = &exynos_iommu_map,
> .unmap = &exynos_iommu_unmap,
> .iova_to_phys = &exynos_iommu_iova_to_phys,
> + .add_device = exynos_iommu_add_device,
> + .remove_device = exynos_iommu_remove_device,
> .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE, };
>
[Sethi Varun-B16395] Do you support PCI devices? This assumption of one iommu
group per pci device may not hold true in case of PCI devices.
-Varun
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 9:23 PM
>
> On Tue, Jul 23, 2013 at 2:13 PM, Cho KyongHo wrote:
> >> -Original Message-
> >> From: Inki Dae [mailto:inki@samsung.com]
> >> Sent: Tuesday, July 23, 2013 8:21 PM
> >>
> >> > -Original Message-
> >> > From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> >> > Sent: Tuesday, July 23, 2013 8:00 PM
> >> > To: Inki Dae
> >> > Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
> >> KyongHo;
> >> > Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> >> > Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
> >> > to an IOMMU group
> >> >
> >> > On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae wrote:
> >> > >
> >> > >
> >> > >
> >> > > > -Original Message-
> >> > > > From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
> >> > soc-
> >> > > > ow...@vger.kernel.org] On Behalf Of Antonios Motakis
> >> > > > Sent: Tuesday, July 23, 2013 7:02 PM
> >> > > > To: linux-arm-ker...@lists.infradead.org;
> >> > > io...@lists.linux-foundation.org;
> >> > > > linux-samsung-soc@vger.kernel.org
> >> > > > Cc: kvm...@lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo;
> >> > > > Joerg
> >> > > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> >> > > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
> >> > to
> >> > > > an IOMMU group
> >> > > >
> >> > > > IOMMU groups are expected by certain users of the IOMMU API,
> >> > > > e.g. VFIO. Since each device is behind its own System MMU, we
> >> > > > can allocate a new IOMMU group for each device.
> >> > > >
> >> > > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
> >> > 00/12]
> >> > > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> >> > > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> >> > board.
> >> > > >
> >> > > > Signed-off-by: Antonios Motakis
> >> > > > ---
> >> > > > drivers/iommu/exynos-iommu.c | 24
> >> > > > 1 file changed, 24 insertions(+)
> >> > > >
> >> > > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
> >> > iommu.c
> >> > > > index 51d43bb..9f39eaa 100644
> >> > > > --- a/drivers/iommu/exynos-iommu.c
> >> > > > +++ b/drivers/iommu/exynos-iommu.c
> >> > > > @@ -1134,6 +1134,28 @@ static phys_addr_t
> >> > exynos_iommu_iova_to_phys(struct
> >> > > > iommu_domain *domain,
> >> > > > return phys;
> >> > > > }
> >> > > >
> >> > > > +static int exynos_iommu_add_device(struct device *dev)
> >> > > > +{
> >> > > > + struct iommu_group *group;
> >> > > > + int ret;
> >> > > > +
> >> > > > + group = iommu_group_alloc();
> >> > >
> >> > > Is that correct? I don't see why you allocate a group object every time
> >> > > add_device callback is called. That doesn't have any meaning we have to
> >> > use
> >> > > iommu group feature. I think the implementation should be one more
> >> > devices
> >> > > per a group. So I guess a given device object should be wrapped by
> >> > higher
> >> > > device object than the given device object. For a good example, you can
> >> > > refer to intel-iommu.c file.
> >> >
> >> > With an Intel IOMMU it can be the case that 2 devices have to share
> >> > the same IOMMU mappings (i.e. you can't program them separately). With
> >> > the Exynos System MMU, there is always one System MMU per device, so
> >> > there is nothing stopping you from programming any 2 devices' mappings
> >> > differently. So yes, the right thing to do here is to have a one to
> >> > one relationship between devices and IOMMU groups.
> >>
> >> In case of Exynos drm driver, a unified iommu mapping table is used for all
> >> devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
> >> same iommu mapping table even though they have each iommu hardware unit.
> >> And
> >> the iommu mapping table is just logical data structure for hardware
> >> translation process by each DMA. Actually, I am considering using iommu
> >> group feature for more generic implementation.
> >>
> >> And one question. Why do you allocate a iommu group object if we should
> >> have
> >> one to one relationship between devices and iommu groups? In this case, is
> >> there any reason you have to use the iommu group object?
> >>
> >> Thanks,
> >> Inki Dae
> >>
> > Antonios,
> >
> > Your patch always creates new iommu group whenever .add_device() is called,
> > which results in memory leak. You need to check if the given device is
> > already
> > involved in an iommu group.
> >
> > BTW, I will post new patchset in a few days.
> > It will not be such different from previous one and your patch
> > will be rebased on that in a trivial manner.
>
> It is not clear to me why this is the case, can add_device be called
> multiple times per device? I will take a look into this.
>
Yes,
Re: [PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
On Tue, Jul 23, 2013 at 2:13 PM, Cho KyongHo wrote:
>> -Original Message-
>> From: Inki Dae [mailto:inki@samsung.com]
>> Sent: Tuesday, July 23, 2013 8:21 PM
>>
>> > -Original Message-
>> > From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
>> > Sent: Tuesday, July 23, 2013 8:00 PM
>> > To: Inki Dae
>> > Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
>> KyongHo;
>> > Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
>> > Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
>> > to an IOMMU group
>> >
>> > On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae wrote:
>> > >
>> > >
>> > >
>> > > > -Original Message-
>> > > > From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
>> > soc-
>> > > > ow...@vger.kernel.org] On Behalf Of Antonios Motakis
>> > > > Sent: Tuesday, July 23, 2013 7:02 PM
>> > > > To: linux-arm-ker...@lists.infradead.org;
>> > > io...@lists.linux-foundation.org;
>> > > > linux-samsung-soc@vger.kernel.org
>> > > > Cc: kvm...@lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
>> > > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
>> > > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
>> > to
>> > > > an IOMMU group
>> > > >
>> > > > IOMMU groups are expected by certain users of the IOMMU API,
>> > > > e.g. VFIO. Since each device is behind its own System MMU, we
>> > > > can allocate a new IOMMU group for each device.
>> > > >
>> > > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
>> > 00/12]
>> > > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
>> > > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
>> > board.
>> > > >
>> > > > Signed-off-by: Antonios Motakis
>> > > > ---
>> > > > drivers/iommu/exynos-iommu.c | 24
>> > > > 1 file changed, 24 insertions(+)
>> > > >
>> > > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
>> > iommu.c
>> > > > index 51d43bb..9f39eaa 100644
>> > > > --- a/drivers/iommu/exynos-iommu.c
>> > > > +++ b/drivers/iommu/exynos-iommu.c
>> > > > @@ -1134,6 +1134,28 @@ static phys_addr_t
>> > exynos_iommu_iova_to_phys(struct
>> > > > iommu_domain *domain,
>> > > > return phys;
>> > > > }
>> > > >
>> > > > +static int exynos_iommu_add_device(struct device *dev)
>> > > > +{
>> > > > + struct iommu_group *group;
>> > > > + int ret;
>> > > > +
>> > > > + group = iommu_group_alloc();
>> > >
>> > > Is that correct? I don't see why you allocate a group object every time
>> > > add_device callback is called. That doesn't have any meaning we have to
>> > use
>> > > iommu group feature. I think the implementation should be one more
>> > devices
>> > > per a group. So I guess a given device object should be wrapped by
>> > higher
>> > > device object than the given device object. For a good example, you can
>> > > refer to intel-iommu.c file.
>> >
>> > With an Intel IOMMU it can be the case that 2 devices have to share
>> > the same IOMMU mappings (i.e. you can't program them separately). With
>> > the Exynos System MMU, there is always one System MMU per device, so
>> > there is nothing stopping you from programming any 2 devices' mappings
>> > differently. So yes, the right thing to do here is to have a one to
>> > one relationship between devices and IOMMU groups.
>>
>> In case of Exynos drm driver, a unified iommu mapping table is used for all
>> devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
>> same iommu mapping table even though they have each iommu hardware unit. And
>> the iommu mapping table is just logical data structure for hardware
>> translation process by each DMA. Actually, I am considering using iommu
>> group feature for more generic implementation.
>>
>> And one question. Why do you allocate a iommu group object if we should have
>> one to one relationship between devices and iommu groups? In this case, is
>> there any reason you have to use the iommu group object?
>>
>> Thanks,
>> Inki Dae
>>
> Antonios,
>
> Your patch always creates new iommu group whenever .add_device() is called,
> which results in memory leak. You need to check if the given device is already
> involved in an iommu group.
>
> BTW, I will post new patchset in a few days.
> It will not be such different from previous one and your patch
> will be rebased on that in a trivial manner.
It is not clear to me why this is the case, can add_device be called
multiple times per device? I will take a look into this.
Anyway thanks for taking this into account.
>
> Regards,
> Cho KyongHo
>
>> >
>> > (resending because of html mail)
>> >
>> > Cheers,
>> > Antonios
>> >
>> > >
>> > >
>> > > Thanks,
>> > > Inki Dae
>> > >
>> > > > + if (IS_ERR(group)) {
>> > > > + dev_err(dev, "Failed to allocate IOMMU group\n");
>> > > > + return PTR_ERR(group);
>> > > > + }
>> > > > +
>>
RE: [PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
> -Original Message-
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Tuesday, July 23, 2013 8:21 PM
>
> > -Original Message-
> > From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> > Sent: Tuesday, July 23, 2013 8:00 PM
> > To: Inki Dae
> > Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
> KyongHo;
> > Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> > Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
> > to an IOMMU group
> >
> > On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
> > soc-
> > > > ow...@vger.kernel.org] On Behalf Of Antonios Motakis
> > > > Sent: Tuesday, July 23, 2013 7:02 PM
> > > > To: linux-arm-ker...@lists.infradead.org;
> > > io...@lists.linux-foundation.org;
> > > > linux-samsung-soc@vger.kernel.org
> > > > Cc: kvm...@lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
> > > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> > > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
> > to
> > > > an IOMMU group
> > > >
> > > > IOMMU groups are expected by certain users of the IOMMU API,
> > > > e.g. VFIO. Since each device is behind its own System MMU, we
> > > > can allocate a new IOMMU group for each device.
> > > >
> > > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
> > 00/12]
> > > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> > > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> > board.
> > > >
> > > > Signed-off-by: Antonios Motakis
> > > > ---
> > > > drivers/iommu/exynos-iommu.c | 24
> > > > 1 file changed, 24 insertions(+)
> > > >
> > > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
> > iommu.c
> > > > index 51d43bb..9f39eaa 100644
> > > > --- a/drivers/iommu/exynos-iommu.c
> > > > +++ b/drivers/iommu/exynos-iommu.c
> > > > @@ -1134,6 +1134,28 @@ static phys_addr_t
> > exynos_iommu_iova_to_phys(struct
> > > > iommu_domain *domain,
> > > > return phys;
> > > > }
> > > >
> > > > +static int exynos_iommu_add_device(struct device *dev)
> > > > +{
> > > > + struct iommu_group *group;
> > > > + int ret;
> > > > +
> > > > + group = iommu_group_alloc();
> > >
> > > Is that correct? I don't see why you allocate a group object every time
> > > add_device callback is called. That doesn't have any meaning we have to
> > use
> > > iommu group feature. I think the implementation should be one more
> > devices
> > > per a group. So I guess a given device object should be wrapped by
> > higher
> > > device object than the given device object. For a good example, you can
> > > refer to intel-iommu.c file.
> >
> > With an Intel IOMMU it can be the case that 2 devices have to share
> > the same IOMMU mappings (i.e. you can't program them separately). With
> > the Exynos System MMU, there is always one System MMU per device, so
> > there is nothing stopping you from programming any 2 devices' mappings
> > differently. So yes, the right thing to do here is to have a one to
> > one relationship between devices and IOMMU groups.
>
> In case of Exynos drm driver, a unified iommu mapping table is used for all
> devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
> same iommu mapping table even though they have each iommu hardware unit. And
> the iommu mapping table is just logical data structure for hardware
> translation process by each DMA. Actually, I am considering using iommu
> group feature for more generic implementation.
>
> And one question. Why do you allocate a iommu group object if we should have
> one to one relationship between devices and iommu groups? In this case, is
> there any reason you have to use the iommu group object?
>
> Thanks,
> Inki Dae
>
Antonios,
Your patch always creates new iommu group whenever .add_device() is called,
which results in memory leak. You need to check if the given device is already
involved in an iommu group.
BTW, I will post new patchset in a few days.
It will not be such different from previous one and your patch
will be rebased on that in a trivial manner.
Regards,
Cho KyongHo
> >
> > (resending because of html mail)
> >
> > Cheers,
> > Antonios
> >
> > >
> > >
> > > Thanks,
> > > Inki Dae
> > >
> > > > + if (IS_ERR(group)) {
> > > > + dev_err(dev, "Failed to allocate IOMMU group\n");
> > > > + return PTR_ERR(group);
> > > > + }
> > > > +
> > > > + ret = iommu_group_add_device(group, dev);
> > > > + iommu_group_put(group);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static void exynos_iommu_remove_device(struct device *dev)
> > > > +{
> > > > + iommu_group_remove_device(dev);
> > > > +}
> > > > +
> > > > static struct iommu_ops exynos_iommu_ops = {
> > >
Re: [PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
On Tue, Jul 23, 2013 at 1:21 PM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
>> Sent: Tuesday, July 23, 2013 8:00 PM
>> To: Inki Dae
>> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
> KyongHo;
>> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
>> Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
>> to an IOMMU group
>>
>> On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae wrote:
>> >
>> >
>> >
>> > > -Original Message-
>> > > From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
>> soc-
>> > > ow...@vger.kernel.org] On Behalf Of Antonios Motakis
>> > > Sent: Tuesday, July 23, 2013 7:02 PM
>> > > To: linux-arm-ker...@lists.infradead.org;
>> > io...@lists.linux-foundation.org;
>> > > linux-samsung-soc@vger.kernel.org
>> > > Cc: kvm...@lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
>> > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
>> > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
>> to
>> > > an IOMMU group
>> > >
>> > > IOMMU groups are expected by certain users of the IOMMU API,
>> > > e.g. VFIO. Since each device is behind its own System MMU, we
>> > > can allocate a new IOMMU group for each device.
>> > >
>> > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
>> 00/12]
>> > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
>> > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
>> board.
>> > >
>> > > Signed-off-by: Antonios Motakis
>> > > ---
>> > > drivers/iommu/exynos-iommu.c | 24
>> > > 1 file changed, 24 insertions(+)
>> > >
>> > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
>> iommu.c
>> > > index 51d43bb..9f39eaa 100644
>> > > --- a/drivers/iommu/exynos-iommu.c
>> > > +++ b/drivers/iommu/exynos-iommu.c
>> > > @@ -1134,6 +1134,28 @@ static phys_addr_t
>> exynos_iommu_iova_to_phys(struct
>> > > iommu_domain *domain,
>> > > return phys;
>> > > }
>> > >
>> > > +static int exynos_iommu_add_device(struct device *dev)
>> > > +{
>> > > + struct iommu_group *group;
>> > > + int ret;
>> > > +
>> > > + group = iommu_group_alloc();
>> >
>> > Is that correct? I don't see why you allocate a group object every time
>> > add_device callback is called. That doesn't have any meaning we have to
>> use
>> > iommu group feature. I think the implementation should be one more
>> devices
>> > per a group. So I guess a given device object should be wrapped by
>> higher
>> > device object than the given device object. For a good example, you can
>> > refer to intel-iommu.c file.
>>
>> With an Intel IOMMU it can be the case that 2 devices have to share
>> the same IOMMU mappings (i.e. you can't program them separately). With
>> the Exynos System MMU, there is always one System MMU per device, so
>> there is nothing stopping you from programming any 2 devices' mappings
>> differently. So yes, the right thing to do here is to have a one to
>> one relationship between devices and IOMMU groups.
>
> In case of Exynos drm driver, a unified iommu mapping table is used for all
> devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
> same iommu mapping table even though they have each iommu hardware unit. And
> the iommu mapping table is just logical data structure for hardware
> translation process by each DMA. Actually, I am considering using iommu
> group feature for more generic implementation.
But is this grouping imposed by the hardware in some way, or is it
just the way you handle them in software? In the latter case, then
what you are looking for are IOMMU domains (which can contain multiple
groups). IOMMU groups describe something that is imposed by the
hardware.
>
> And one question. Why do you allocate a iommu group object if we should have
> one to one relationship between devices and iommu groups? In this case, is
> there any reason you have to use the iommu group object?
Generic IOMMU code (such as VFIO) will check for IOMMU groups to
determine how the devices behind an IOMMU relate to each other.
Returning a unique IOMMU group object per device provides this
information - that each device can also be programmed separately. VFIO
relies on this behavior - if it doesn't find any IOMMU group objects
it will refuse to use the device.
Additionally, this information can be seen by userspace. Being able to
programmatically determine that there is a one to one relationship is
certainly useful.
I don't think the lack of IOMMU groups implies no grouping - I think
it implies unknown grouping or an incomplete driver, so in my opinion
VFIO is correct in refusing to work without IOMMU groups. So any
future ARM support for VFIO, will also rely on IOMMU groups.
>
> Thanks,
> Inki Dae
>
>>
>> (resending because of html mail)
>>
>> Cheers,
>> Antonios
>>
>> >
>> >
>> > Thanks,
>> >
Re: [PATCH v2 1/8] clk: mux: Add support for read-only muxes.
Hi Sergei,
On Tuesday 23 of July 2013 15:22:44 Sergei Shtylyov wrote:
> Hello.
>
> On 23-07-2013 3:49, Tomasz Figa wrote:
> > Some platforms have read-only clock muxes that are preconfigured at
> > reset and cannot be changed at runtime. This patch extends mux clock
> > driver to allow handling such read-only muxes by adding new
> > CLK_MUX_READ_ONLY mux flag.
> >
> > Signed-off-by: Tomasz Figa
>
> [...]
>
> > diff --git a/include/linux/clk-provider.h
> > b/include/linux/clk-provider.h
> > index 1ec14a7..9487b96 100644
> > --- a/include/linux/clk-provider.h
> > +++ b/include/linux/clk-provider.h
> > @@ -327,8 +327,10 @@ struct clk_mux {
> > #define CLK_MUX_INDEX_ONE BIT(0)
> > #define CLK_MUX_INDEX_BIT BIT(1)
> > #define CLK_MUX_HIWORD_MASK BIT(2)
> > +#define CLK_MUX_READ_ONLY BIT(3) /* mux setting cannot be changed */
>
> Please align BIT(3) with the above BIT() invocations.
Different indentation was intended here to fit the comment, like in case of
generic flags. IMHO remaining flags should be changed to this way as well,
but this is probably material for another patch.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/8] clk: mux: Add support for read-only muxes.
Hello.
On 23-07-2013 3:49, Tomasz Figa wrote:
Some platforms have read-only clock muxes that are preconfigured at
reset and cannot be changed at runtime. This patch extends mux clock
driver to allow handling such read-only muxes by adding new
CLK_MUX_READ_ONLY mux flag.
Signed-off-by: Tomasz Figa
[...]
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1ec14a7..9487b96 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -327,8 +327,10 @@ struct clk_mux {
#define CLK_MUX_INDEX_ONE BIT(0)
#define CLK_MUX_INDEX_BIT BIT(1)
#define CLK_MUX_HIWORD_MASK BIT(2)
+#define CLK_MUX_READ_ONLY BIT(3) /* mux setting cannot be changed */
Please align BIT(3) with the above BIT() invocations.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 8:00 PM
> To: Inki Dae
> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
> to an IOMMU group
>
> On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae wrote:
> >
> >
> >
> > > -Original Message-
> > > From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
> soc-
> > > ow...@vger.kernel.org] On Behalf Of Antonios Motakis
> > > Sent: Tuesday, July 23, 2013 7:02 PM
> > > To: linux-arm-ker...@lists.infradead.org;
> > io...@lists.linux-foundation.org;
> > > linux-samsung-soc@vger.kernel.org
> > > Cc: kvm...@lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
> > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
> to
> > > an IOMMU group
> > >
> > > IOMMU groups are expected by certain users of the IOMMU API,
> > > e.g. VFIO. Since each device is behind its own System MMU, we
> > > can allocate a new IOMMU group for each device.
> > >
> > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
> 00/12]
> > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> board.
> > >
> > > Signed-off-by: Antonios Motakis
> > > ---
> > > drivers/iommu/exynos-iommu.c | 24
> > > 1 file changed, 24 insertions(+)
> > >
> > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
> iommu.c
> > > index 51d43bb..9f39eaa 100644
> > > --- a/drivers/iommu/exynos-iommu.c
> > > +++ b/drivers/iommu/exynos-iommu.c
> > > @@ -1134,6 +1134,28 @@ static phys_addr_t
> exynos_iommu_iova_to_phys(struct
> > > iommu_domain *domain,
> > > return phys;
> > > }
> > >
> > > +static int exynos_iommu_add_device(struct device *dev)
> > > +{
> > > + struct iommu_group *group;
> > > + int ret;
> > > +
> > > + group = iommu_group_alloc();
> >
> > Is that correct? I don't see why you allocate a group object every time
> > add_device callback is called. That doesn't have any meaning we have to
> use
> > iommu group feature. I think the implementation should be one more
> devices
> > per a group. So I guess a given device object should be wrapped by
> higher
> > device object than the given device object. For a good example, you can
> > refer to intel-iommu.c file.
>
> With an Intel IOMMU it can be the case that 2 devices have to share
> the same IOMMU mappings (i.e. you can't program them separately). With
> the Exynos System MMU, there is always one System MMU per device, so
> there is nothing stopping you from programming any 2 devices' mappings
> differently. So yes, the right thing to do here is to have a one to
> one relationship between devices and IOMMU groups.
In case of Exynos drm driver, a unified iommu mapping table is used for all
devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
same iommu mapping table even though they have each iommu hardware unit. And
the iommu mapping table is just logical data structure for hardware
translation process by each DMA. Actually, I am considering using iommu
group feature for more generic implementation.
And one question. Why do you allocate a iommu group object if we should have
one to one relationship between devices and iommu groups? In this case, is
there any reason you have to use the iommu group object?
Thanks,
Inki Dae
>
> (resending because of html mail)
>
> Cheers,
> Antonios
>
> >
> >
> > Thanks,
> > Inki Dae
> >
> > > + if (IS_ERR(group)) {
> > > + dev_err(dev, "Failed to allocate IOMMU group\n");
> > > + return PTR_ERR(group);
> > > + }
> > > +
> > > + ret = iommu_group_add_device(group, dev);
> > > + iommu_group_put(group);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static void exynos_iommu_remove_device(struct device *dev)
> > > +{
> > > + iommu_group_remove_device(dev);
> > > +}
> > > +
> > > static struct iommu_ops exynos_iommu_ops = {
> > > .domain_init = &exynos_iommu_domain_init,
> > > .domain_destroy = &exynos_iommu_domain_destroy,
> > > @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
> > > .map = &exynos_iommu_map,
> > > .unmap = &exynos_iommu_unmap,
> > > .iova_to_phys = &exynos_iommu_iova_to_phys,
> > > + .add_device = exynos_iommu_add_device,
> > > + .remove_device = exynos_iommu_remove_device,
> > > .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
> > > };
> > >
> > > --
> > > 1.8.1.2
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-
> samsung-
> > > soc" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordom
Re: [PATCH V3] watchdog: s3c2410_wdt: remove the global variables
Hi, On Tuesday 23 of July 2013 14:29:45 Leela Krishna Amudala wrote: > This patch removes the global variables in the driver file and > group them into a structure. > > Signed-off-by: Leela Krishna Amudala > --- > Note: This patch is rebased on kgene's for-next branch and tested on > SMDK5420. > > Changes since V2: > - Addressed comments given by Tomasz Figa > https://patchwork.kernel.org/patch/2831032/ > - Renamed structure name from s3c2410_watchdog to s3c2410_wdt. > > Changes since V1: > - changed the patch subject. > - indentation correction in s3c2410_watchdog structure. > > drivers/watchdog/s3c2410_wdt.c | 225 > +++- 1 file changed, 131 > insertions(+), 94 deletions(-) Looks good to me, thanks. Reviewed-by: Tomasz Figa Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae wrote:
>
>
>
> > -Original Message-
> > From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> > ow...@vger.kernel.org] On Behalf Of Antonios Motakis
> > Sent: Tuesday, July 23, 2013 7:02 PM
> > To: linux-arm-ker...@lists.infradead.org;
> io...@lists.linux-foundation.org;
> > linux-samsung-soc@vger.kernel.org
> > Cc: kvm...@lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
> > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
> > an IOMMU group
> >
> > IOMMU groups are expected by certain users of the IOMMU API,
> > e.g. VFIO. Since each device is behind its own System MMU, we
> > can allocate a new IOMMU group for each device.
> >
> > This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
> > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale board.
> >
> > Signed-off-by: Antonios Motakis
> > ---
> > drivers/iommu/exynos-iommu.c | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index 51d43bb..9f39eaa 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -1134,6 +1134,28 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
> > iommu_domain *domain,
> > return phys;
> > }
> >
> > +static int exynos_iommu_add_device(struct device *dev)
> > +{
> > + struct iommu_group *group;
> > + int ret;
> > +
> > + group = iommu_group_alloc();
>
> Is that correct? I don't see why you allocate a group object every time
> add_device callback is called. That doesn't have any meaning we have to use
> iommu group feature. I think the implementation should be one more devices
> per a group. So I guess a given device object should be wrapped by higher
> device object than the given device object. For a good example, you can
> refer to intel-iommu.c file.
With an Intel IOMMU it can be the case that 2 devices have to share
the same IOMMU mappings (i.e. you can't program them separately). With
the Exynos System MMU, there is always one System MMU per device, so
there is nothing stopping you from programming any 2 devices' mappings
differently. So yes, the right thing to do here is to have a one to
one relationship between devices and IOMMU groups.
(resending because of html mail)
Cheers,
Antonios
>
>
> Thanks,
> Inki Dae
>
> > + if (IS_ERR(group)) {
> > + dev_err(dev, "Failed to allocate IOMMU group\n");
> > + return PTR_ERR(group);
> > + }
> > +
> > + ret = iommu_group_add_device(group, dev);
> > + iommu_group_put(group);
> > +
> > + return ret;
> > +}
> > +
> > +static void exynos_iommu_remove_device(struct device *dev)
> > +{
> > + iommu_group_remove_device(dev);
> > +}
> > +
> > static struct iommu_ops exynos_iommu_ops = {
> > .domain_init = &exynos_iommu_domain_init,
> > .domain_destroy = &exynos_iommu_domain_destroy,
> > @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
> > .map = &exynos_iommu_map,
> > .unmap = &exynos_iommu_unmap,
> > .iova_to_phys = &exynos_iommu_iova_to_phys,
> > + .add_device = exynos_iommu_add_device,
> > + .remove_device = exynos_iommu_remove_device,
> > .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
> > };
> >
> > --
> > 1.8.1.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> > soc" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Antonios Motakis
> Sent: Tuesday, July 23, 2013 7:02 PM
> To: linux-arm-ker...@lists.infradead.org;
io...@lists.linux-foundation.org;
> linux-samsung-soc@vger.kernel.org
> Cc: kvm...@lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
> Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
> an IOMMU group
>
> IOMMU groups are expected by certain users of the IOMMU API,
> e.g. VFIO. Since each device is behind its own System MMU, we
> can allocate a new IOMMU group for each device.
>
> This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
> iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> applied on a Linux 3.10.1 kernel. It has been tested on the Arndale board.
>
> Signed-off-by: Antonios Motakis
> ---
> drivers/iommu/exynos-iommu.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 51d43bb..9f39eaa 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1134,6 +1134,28 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
> iommu_domain *domain,
> return phys;
> }
>
> +static int exynos_iommu_add_device(struct device *dev)
> +{
> + struct iommu_group *group;
> + int ret;
> +
> + group = iommu_group_alloc();
Is that correct? I don't see why you allocate a group object every time
add_device callback is called. That doesn't have any meaning we have to use
iommu group feature. I think the implementation should be one more devices
per a group. So I guess a given device object should be wrapped by higher
device object than the given device object. For a good example, you can
refer to intel-iommu.c file.
Thanks,
Inki Dae
> + if (IS_ERR(group)) {
> + dev_err(dev, "Failed to allocate IOMMU group\n");
> + return PTR_ERR(group);
> + }
> +
> + ret = iommu_group_add_device(group, dev);
> + iommu_group_put(group);
> +
> + return ret;
> +}
> +
> +static void exynos_iommu_remove_device(struct device *dev)
> +{
> + iommu_group_remove_device(dev);
> +}
> +
> static struct iommu_ops exynos_iommu_ops = {
> .domain_init = &exynos_iommu_domain_init,
> .domain_destroy = &exynos_iommu_domain_destroy,
> @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
> .map = &exynos_iommu_map,
> .unmap = &exynos_iommu_unmap,
> .iova_to_phys = &exynos_iommu_iova_to_phys,
> + .add_device = exynos_iommu_add_device,
> + .remove_device = exynos_iommu_remove_device,
> .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
> };
>
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] clk: exynos-audss: allow input clocks to be specified in device tree
Hi Tomasz, On Tue, Jul 23, 2013 at 1:12 AM, Tomasz Figa wrote: > On Monday 22 of July 2013 11:15:30 Mike Turquette wrote: >> Quoting Tomasz Figa (2013-07-22 09:28:47) >> >> > Hi Padmavathi, Andrew, >> > >> > On Wednesday 10 of July 2013 17:41:51 Padmavathi Venna wrote: >> > > From: Andrew Bresticker >> > > >> > > This allows the input clocks to the Exynos AudioSS block to be >> > > specified via device-tree bindings. Default names will be used >> > > when an input clock is not given. This will be useful when adding >> > > support for the Exynos5420 where the audio bus clock is called >> > > "sclk_maudio0" instead of "sclk_audio0". >> > > >> > > Signed-off-by: Andrew Bresticker >> > > Reviewed-on: https://gerrit.chromium.org/gerrit/57833 >> > > Reviewed-by: Simon Glass >> > > --- >> > > >> > > .../devicetree/bindings/clock/clk-exynos-audss.txt | 31 >> > > >> > > ++- drivers/clk/samsung/clk-exynos-audss.c >> > > |> > >> > > 28 +++-- 2 files changed, 53 insertions(+), 6 >> > > deletions(-) >> > >> > Well, this is basically how it should be done, but in current state of >> > clock core I can see a problem: can we really rely on the order of >> > clock initialization? I mean, we can't defer initialization of >> > particular clock controller until all external clocks it needs are >> > available, because there is no probing involved here. your point is valid. In this case audio clk controller registration happening only after CMU clk controller from which audss needs clks. So this patch can't be taken in? Thanks Padma >> >> The clock core allows registering clocks even if their parents are not >> yet registered. I test this path with some dummy clocks every so often >> to make sure the re-parenting operation are completed successfully after >> the parents eventually are registered. > > Sure it does, but this patch is about something different. It adds device > tree based lookup (of_clk_get_by_name()) of external clocks (as opposed to > existing lookup by name), which will fail if provider pointed by phandle > is not registered yet. > >> This feature was not used in practice until recently with the advent of >> multiple clock controllers getting registered and DT description of >> clocks / clock controllers that may be "out of order". If you find any >> bugs please let me know ;-) > > I will send you a bunch of patches sorting out issues I found in > clk_set_rate() path, but give me some time to prepare them :). > > As for multiple clock controllers, this is going to be funny. I have > discussed this a bit with Sylwester and we managed to find some design > issues that I think must be solved: > > a) What about multiple controllers with identical clock names? Imagine two > PMICs that can also generate 32 KHz clocks, both having them named > "clk32k". Am I right saying that this won't work with current code? > > b) What are the rules of using clock-output-names property (and what > should be used in non-DT case)? I can imagine using it to assign platform- > specific names of clock outputs of extra clock controllers (this would > help in the above case of "clk32k"), but currently it seems like it is > optional to use it in clock drivers and the meaning is provider-specific. > > Best regards, > Tomasz > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] iommu/exynos: add devices attached to the System MMU to an IOMMU group
IOMMU groups are expected by certain users of the IOMMU API,
e.g. VFIO. Since each device is behind its own System MMU, we
can allocate a new IOMMU group for each device.
This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
applied on a Linux 3.10.1 kernel. It has been tested on the Arndale board.
Signed-off-by: Antonios Motakis
---
drivers/iommu/exynos-iommu.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 51d43bb..9f39eaa 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1134,6 +1134,28 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
iommu_domain *domain,
return phys;
}
+static int exynos_iommu_add_device(struct device *dev)
+{
+ struct iommu_group *group;
+ int ret;
+
+ group = iommu_group_alloc();
+ if (IS_ERR(group)) {
+ dev_err(dev, "Failed to allocate IOMMU group\n");
+ return PTR_ERR(group);
+ }
+
+ ret = iommu_group_add_device(group, dev);
+ iommu_group_put(group);
+
+ return ret;
+}
+
+static void exynos_iommu_remove_device(struct device *dev)
+{
+ iommu_group_remove_device(dev);
+}
+
static struct iommu_ops exynos_iommu_ops = {
.domain_init = &exynos_iommu_domain_init,
.domain_destroy = &exynos_iommu_domain_destroy,
@@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
.map = &exynos_iommu_map,
.unmap = &exynos_iommu_unmap,
.iova_to_phys = &exynos_iommu_iova_to_phys,
+ .add_device = exynos_iommu_add_device,
+ .remove_device = exynos_iommu_remove_device,
.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DT: Exynos: fix number of interrupt-cells in mct node
ping.
On 14 June 2013 20:11, Chander Kashyap wrote:
> Two cells were used to specify interrupts in mct node, while second cell
> always remains unused. Hence use only one cell.
> Suggested by Tomasz Figa.
>
> Signed-off-by: Chander Kashyap
> ---
> arch/arm/boot/dts/exynos4210.dtsi | 19 +--
> arch/arm/boot/dts/exynos4212.dtsi | 19 +--
> arch/arm/boot/dts/exynos4412.dtsi | 23 +++
> arch/arm/boot/dts/exynos5250.dtsi | 19 +--
> 4 files changed, 38 insertions(+), 42 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> b/arch/arm/boot/dts/exynos4210.dtsi
> index 54710de..ad50010 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -52,23 +52,22 @@
> compatible = "samsung,exynos4210-mct";
> reg = <0x1005 0x800>;
> interrupt-controller;
> - #interrups-cells = <2>;
> + #interrups-cells = <1>;
> interrupt-parent = <&mct_map>;
> - interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
> -<4 0>, <5 0>;
> + interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
> clocks = <&clock 3>, <&clock 344>;
> clock-names = "fin_pll", "mct";
>
> mct_map: mct-map {
> - #interrupt-cells = <2>;
> + #interrupt-cells = <1>;
> #address-cells = <0>;
> #size-cells = <0>;
> - interrupt-map = <0x0 0 &gic 0 57 0>,
> - <0x1 0 &gic 0 69 0>,
> - <0x2 0 &combiner 12 6>,
> - <0x3 0 &combiner 12 7>,
> - <0x4 0 &gic 0 42 0>,
> - <0x5 0 &gic 0 48 0>;
> + interrupt-map = <0 &gic 0 57 0>,
> + <1 &gic 0 69 0>,
> + <2 &combiner 12 6>,
> + <3 &combiner 12 7>,
> + <4 &gic 0 42 0>,
> + <5 &gic 0 48 0>;
> };
> };
>
> diff --git a/arch/arm/boot/dts/exynos4212.dtsi
> b/arch/arm/boot/dts/exynos4212.dtsi
> index c0f60f4..ba9ada1 100644
> --- a/arch/arm/boot/dts/exynos4212.dtsi
> +++ b/arch/arm/boot/dts/exynos4212.dtsi
> @@ -39,21 +39,20 @@
> compatible = "samsung,exynos4412-mct";
> reg = <0x1005 0x800>;
> interrupt-controller;
> - #interrups-cells = <2>;
> + #interrups-cells = <1>;
> interrupt-parent = <&mct_map>;
> - interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
> -<4 0>, <5 0>;
> + interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
>
> mct_map: mct-map {
> - #interrupt-cells = <2>;
> + #interrupt-cells = <>;
> #address-cells = <0>;
> #size-cells = <0>;
> - interrupt-map = <0x0 0 &gic 0 57 0>,
> - <0x1 0 &combiner 12 5>,
> - <0x2 0 &combiner 12 6>,
> - <0x3 0 &combiner 12 7>,
> - <0x4 0 &gic 1 12 0>,
> - <0x5 0 &gic 1 12 0>;
> + interrupt-map = <0 &gic 0 57 0>,
> + <1 &combiner 12 5>,
> + <2 &combiner 12 6>,
> + <3 &combiner 12 7>,
> + <4 &gic 1 12 0>,
> + <5 &gic 1 12 0>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> b/arch/arm/boot/dts/exynos4412.dtsi
> index 270b389..a680de7 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -39,25 +39,24 @@
> compatible = "samsung,exynos4412-mct";
> reg = <0x1005 0x800>;
> interrupt-controller;
> - #interrups-cells = <2>;
> + #interrups-cells = <1>;
> interrupt-parent = <&mct_map>;
> - interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
> -<4 0>, <5 0>, <6 0>, <7 0>;
> + interrupts = <0>, <1>, <2>, <3>, <4>, <5>, <6>, <7>;
> clocks = <&clock 3>, <&clock 344>;
> clock-names = "fin_pll", "mct";
>
> mct_map: mct-map {
> - #interrupt-cells = <2>;
> + #interrupt-cells = <1>;
> #address-ce
Re: [PATCH 07/22] ARM: exynos: Remove '0x's from Exynos4110 DTSI file
On Tuesday 23 of July 2013 09:55:52 Lee Jones wrote:
> On Mon, 22 Jul 2013, Tomasz Figa wrote:
> > Hi Lee,
> >
> > On Monday 22 of July 2013 11:52:26 Lee Jones wrote:
> > > Cc: Kukjin Kim
> > > Cc: linux-samsung-soc@vger.kernel.org
> > > Signed-off-by: Lee Jones
> > > ---
> > >
> > > arch/arm/boot/dts/exynos4210.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> > > b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
> > > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > > @@ -72,7 +72,7 @@
> > >
> > > };
> > >
> > > };
> > >
> > > - clock: clock-controller@0x1003 {
> > > + clock: clock-controller@1003 {
> > >
> > > compatible = "samsung,exynos4210-clock";
> > > reg = <0x1003 0x2>;
> > > #clock-cells = <1>;
> >
> > This looks fine, but please fix commit message - it should be
> > Exynos4210. Also some explanation why this change is needed would be
> > good, even if it's obvious.
>
> Hi Tomasz,
>
> I'm happy to fixup the $SUBJECT line, but do we really have to enter
> an explanation if it's obvious? Seems a little belt and braces.
It's obvious for us, people working with device tree, but for people that
usually don't it might not be.
Something among following lines would be fine:
This patch removes "0x" prefix from addresses in DT nodes for the sake of
consistency with other nodes and assumed convention.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/22] ARM: exynos: Remove '0x's from Exynos4110 DTSI file
On Mon, 22 Jul 2013, Tomasz Figa wrote:
> Hi Lee,
>
> On Monday 22 of July 2013 11:52:26 Lee Jones wrote:
> > Cc: Kukjin Kim
> > Cc: linux-samsung-soc@vger.kernel.org
> > Signed-off-by: Lee Jones
> > ---
> > arch/arm/boot/dts/exynos4210.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> > b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
> > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > @@ -72,7 +72,7 @@
> > };
> > };
> >
> > - clock: clock-controller@0x1003 {
> > + clock: clock-controller@1003 {
> > compatible = "samsung,exynos4210-clock";
> > reg = <0x1003 0x2>;
> > #clock-cells = <1>;
>
> This looks fine, but please fix commit message - it should be Exynos4210.
> Also some explanation why this change is needed would be good, even if
> it's obvious.
Hi Tomasz,
I'm happy to fixup the $SUBJECT line, but do we really have to enter
an explanation if it's obvious? Seems a little belt and braces.
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday, July 23, 2013 3:30 PM, Kishon Vijay Abraham I wrote:
> On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote:
> > On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote:
> >> On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote:
> >>> Exynos PCIe IP consists of Synopsys specific part and Exynos
> >>> specific part. Only core block is a Synopsys designware part;
> >>> other parts are Exynos specific.
> >>> Also, the Synopsys designware part can be shared with other
> >>> platforms; thus, it can be split two parts such as Synopsys
> >>> designware part and Exynos specific part.
> >>
> >> some more queries and comments..
> >
> .
> .
>
> .
> .
> >>> + of_pci_range_to_resource(&range, np, &pp->cfg);
> >>> + pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> >>> + pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> >>> + }
> >>> + }
> >>> +
> >>> + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start,
> >>> + resource_size(&pp->cfg));
[.]
> >
> >> Why should it be same as dbi_base?
> >> AFAIK, jacinto6 has a dedicated configuration/io/memory space that is
> >> entirely
> >> different from dbi_base.
> >
> > According to the Synopsys designware PCIe datasheet,
> > in chapter 5.1.1 Register Space Layout,
> > 'Port Logic Registers' are placed between (config space 0x0 + 0x700)
> > and (config space 0x0 + 0xFFF).
> > 'dbi_base' is used for reading/writing 'Port Logic Registers'.
> > Exynos are using 'dbi_base' like this. Thus, the base addresses of
> > both 'dbi_base' and configuration/io/memory space are same.
> >
> > Just now, I looked at Spear PCIe driver.
> > However, in the case of Spear, the base address of configuration/io/memory
> > space is defined as 0x8000. The base address of 'Port Logic Registers'
> > is defined as 0xb100.
> > I think that the situation of 'jacinto6' is similar with Spear, right?
> >
> > Then, I will move pp->dbi_base mapping code from pcie-designware.c
> > to pci-exynos.c.
>
> I think you need not move this to exynos (since registers in dbi_base is
> common
> for all platforms) but modify the pcie-designware.c to use different address
> space for dbi_base. In your case, you'll duplicate the address space for
> dbi_base and configuration space.
>
I will map 'pp->dbi_base' as below:
Also, I referenced SPEAr PCIe patches made by Pratyush Anand.
(http://permalink.gmane.org/gmane.linux.kernel.pci/18400)
(http://permalink.gmane.org/gmane.linux.kernel.pci/18403)
1. The different addresses between dbi_base and configuration space
: SPEAr PCIe, OMAP PCIe
'pp->dbi_base' value is come from DT binding, then, 'pp->dbi_base' will
be mapped in spear_pcie_probe() in pci-spear.c
(arch/arm/boot/dts/spear13xx.dtsi)
pcie0@b100 {
reg = <0xb100 0x2000 <-- dbi register
0xb1002000 0x7fdfff <-- elbi register
(drivers/pci/host/pci-spear.c)
static int __init spear_pcie_probe(struct platform_device *pdev)
{
struct resource *dbi_base;
struct resource *elbi_base;
dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pp->dbi_base = devm_ioremap_resource(&pdev->dev, dbi_base);
elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 1);
spear_pcie->elbi_base = devm_ioremap_resource(&pdev->dev, elbi_base);
2. The same addresses between dbi_base and configuration space
: Exynos PCIe
'pp->dbi_base' will be mapped in dw_pcie_host_init() of pcie-designware.c.
(drivers/pci/host/pcie-exynos.c)
static int __init exynos_pcie_probe(struct platform_device *pdev)
{
struct resource *elbi_base;
elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
exynos_pcie->elbi_base = devm_ioremap_resource(&pdev->dev, elbi_base);
(drivers/pci/host/pcie-designware.c)
int dw_pcie_host_init(struct pcie_port *pp)
{
if (!pp->dbi_base) {
pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start,
resource_size(&pp->cfg));
if (!pp->dbi_base) {
dev_err(pp->dev, "error with ioremap\n");
return -ENOMEM;
}
}
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] watchdog: s3c2410_wdt: remove the global variables
Hi Sachin,
On Tue, Jul 23, 2013 at 8:28 AM, Sachin Kamat wrote:
> Hi Leela,
>
> On 22 July 2013 11:44, Leela Krishna Amudala wrote:
>> This patch removes the global variables in the driver file and
>> group them into a structure.
>>
>> Signed-off-by: Leela Krishna Amudala
>> ---
>> Note: This patch is rebased on kgene's for-next branch and tested on
>> SMDK5420.
>>
>> Changes since V1:
>> - changed the patch subject.
>> - indentation correction in s3c2410_watchdog structure.
>>
>> drivers/watchdog/s3c2410_wdt.c | 204
>> +++-
>> 1 file changed, 119 insertions(+), 85 deletions(-)
>>
>> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
>> index 6a22cf5..de679d0 100644
>> --- a/drivers/watchdog/s3c2410_wdt.c
>> +++ b/drivers/watchdog/s3c2410_wdt.c
>> @@ -84,13 +84,20 @@ MODULE_PARM_DESC(soft_noboot, "Watchdog action, set to 1
>> to ignore reboots, "
>> "0 to reboot (default 0)");
>> MODULE_PARM_DESC(debug, "Watchdog debug, set to >1 for debug (default 0)");
>>
>> -static struct device*wdt_dev; /* platform device attached to */
>> -static struct resource *wdt_mem;
>> -static struct resource *wdt_irq;
>> -static struct clk *wdt_clock;
>> -static void __iomem*wdt_base;
>> -static unsigned int wdt_count;
>> -static DEFINE_SPINLOCK(wdt_lock);
>> +struct s3c2410_watchdog {
>> + struct device *dev; /* platform device attached to */
>
> Since you would anyway be respinning this patch to address comments
> from Tomasz, please remove the above comment too.
>
Done
> --
> With warm regards,
> Sachin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] watchdog: s3c2410_wdt: remove the global variables
Hello Tomas Figa,
Thanks for reviewing the patch.
On Mon, Jul 22, 2013 at 11:08 PM, Tomasz Figa wrote:
> Hi Leela Krishna,
>
> Looks mostly good, but see some comments inline.
>
> On Monday 22 of July 2013 11:44:09 Leela Krishna Amudala wrote:
>> This patch removes the global variables in the driver file and
>> group them into a structure.
>>
>> Signed-off-by: Leela Krishna Amudala
>> ---
>> Note: This patch is rebased on kgene's for-next branch and tested on
>> SMDK5420.
>>
>> Changes since V1:
>> - changed the patch subject.
>> - indentation correction in s3c2410_watchdog structure.
>>
>> drivers/watchdog/s3c2410_wdt.c | 204
>> +++- 1 file changed, 119
>> insertions(+), 85 deletions(-)
>>
>> diff --git a/drivers/watchdog/s3c2410_wdt.c
>> b/drivers/watchdog/s3c2410_wdt.c index 6a22cf5..de679d0 100644
>> --- a/drivers/watchdog/s3c2410_wdt.c
>> +++ b/drivers/watchdog/s3c2410_wdt.c
>> @@ -84,13 +84,20 @@ MODULE_PARM_DESC(soft_noboot, "Watchdog action, set
>> to 1 to ignore reboots, " "0 to reboot (default 0)");
>> MODULE_PARM_DESC(debug, "Watchdog debug, set to >1 for debug (default
>> 0)");
>>
>> -static struct device*wdt_dev;/* platform device attached to */
>> -static struct resource *wdt_mem;
>> -static struct resource *wdt_irq;
>> -static struct clk*wdt_clock;
>> -static void __iomem *wdt_base;
>> -static unsigned int wdt_count;
>> -static DEFINE_SPINLOCK(wdt_lock);
>> +struct s3c2410_watchdog {
>> + struct device *dev; /* platform device attached to */
>> + struct clk *clock;
>> + void __iomem*reg_base;
>> + unsigned intcount;
>> + spinlock_t lock;
>> + struct watchdog_device wdt_device;
>> + struct notifier_block freq_transition;
>> +};
>> +
>> +#define to_s3c2410_watchdog(wdd) \
>> + container_of(wdd, struct s3c2410_watchdog, wdt_device)
>> +#define freq_to_wdt(_n) \
>> + container_of(_n, struct s3c2410_watchdog, freq_transition)
>
> Please use static inlines here.
>
Done
>> /* watchdog control routines */
>>
>> @@ -104,27 +111,31 @@ do {
>> \
>>
>> static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
>> {
>> - spin_lock(&wdt_lock);
>> - writel(wdt_count, wdt_base + S3C2410_WTCNT);
>> - spin_unlock(&wdt_lock);
>> + struct s3c2410_watchdog *wdt = to_s3c2410_watchdog(wdd);
>> +
>> + spin_lock(&wdt->lock);
>> + writel(wdt->count, wdt->reg_base + S3C2410_WTCNT);
>> + spin_unlock(&wdt->lock);
>>
>> return 0;
>> }
>>
>> -static void __s3c2410wdt_stop(void)
>> +static void __s3c2410wdt_stop(struct s3c2410_watchdog *wdt)
>> {
>> unsigned long wtcon;
>>
>> - wtcon = readl(wdt_base + S3C2410_WTCON);
>> + wtcon = readl(wdt->reg_base + S3C2410_WTCON);
>> wtcon &= ~(S3C2410_WTCON_ENABLE | S3C2410_WTCON_RSTEN);
>> - writel(wtcon, wdt_base + S3C2410_WTCON);
>> + writel(wtcon, wdt->reg_base + S3C2410_WTCON);
>> }
>>
>> static int s3c2410wdt_stop(struct watchdog_device *wdd)
>> {
>> - spin_lock(&wdt_lock);
>> - __s3c2410wdt_stop();
>> - spin_unlock(&wdt_lock);
>> + struct s3c2410_watchdog *wdt = to_s3c2410_watchdog(wdd);
>> +
>> + spin_lock(&wdt->lock);
>> + __s3c2410wdt_stop(wdt);
>> + spin_unlock(&wdt->lock);
>>
>> return 0;
>> }
>> @@ -133,11 +144,13 @@ static int s3c2410wdt_start(struct watchdog_device
>> *wdd) {
>> unsigned long wtcon;
>>
>
> Stray blank line.
>
Done
>> - spin_lock(&wdt_lock);
>> + struct s3c2410_watchdog *wdt = to_s3c2410_watchdog(wdd);
>> +
>> + spin_lock(&wdt->lock);
>>
>> - __s3c2410wdt_stop();
>> + __s3c2410wdt_stop(wdt);
>>
>> - wtcon = readl(wdt_base + S3C2410_WTCON);
>> + wtcon = readl(wdt->reg_base + S3C2410_WTCON);
>> wtcon |= S3C2410_WTCON_ENABLE | S3C2410_WTCON_DIV128;
>>
>> if (soft_noboot) {
>> @@ -148,25 +161,26 @@ static int s3c2410wdt_start(struct watchdog_device
>> *wdd) wtcon |= S3C2410_WTCON_RSTEN;
>> }
>>
>> - DBG("%s: wdt_count=0x%08x, wtcon=%08lx\n",
>> - __func__, wdt_count, wtcon);
>> + DBG("%s: count=0x%08x, wtcon=%08lx\n",
>> + __func__, wdt->count, wtcon);
>>
>> - writel(wdt_count, wdt_base + S3C2410_WTDAT);
>> - writel(wdt_count, wdt_base + S3C2410_WTCNT);
>> - writel(wtcon, wdt_base + S3C2410_WTCON);
>> - spin_unlock(&wdt_lock);
>> + writel(wdt->count, wdt->reg_base + S3C2410_WTDAT);
>> + writel(wdt->count, wdt->reg_base + S3C2410_WTCNT);
>> + writel(wtcon, wdt->reg_base + S3C2410_WTCON);
>> + spin_unlock(&wdt->lock);
>>
>> return 0;
>> }
>>
>> -static inline int s3c2410wdt_is_running(void)
>> +static inline int s3c2410wdt_is_running(struct s3c2410_watchdog *wdt)
>> {
>> - return readl(wdt_base + S3C2410_WTCON) & S3C2410_WTCON_ENABLE;
>> + return readl(wdt-
[PATCH V3] watchdog: s3c2410_wdt: remove the global variables
This patch removes the global variables in the driver file and
group them into a structure.
Signed-off-by: Leela Krishna Amudala
---
Note: This patch is rebased on kgene's for-next branch and tested on SMDK5420.
Changes since V2:
- Addressed comments given by Tomasz Figa
https://patchwork.kernel.org/patch/2831032/
- Renamed structure name from s3c2410_watchdog to s3c2410_wdt.
Changes since V1:
- changed the patch subject.
- indentation correction in s3c2410_watchdog structure.
drivers/watchdog/s3c2410_wdt.c | 225 +++-
1 file changed, 131 insertions(+), 94 deletions(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 6a22cf5..739dbd3 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -84,13 +84,17 @@ MODULE_PARM_DESC(soft_noboot, "Watchdog action, set to 1 to
ignore reboots, "
"0 to reboot (default 0)");
MODULE_PARM_DESC(debug, "Watchdog debug, set to >1 for debug (default 0)");
-static struct device*wdt_dev; /* platform device attached to */
-static struct resource *wdt_mem;
-static struct resource *wdt_irq;
-static struct clk *wdt_clock;
-static void __iomem*wdt_base;
-static unsigned int wdt_count;
-static DEFINE_SPINLOCK(wdt_lock);
+struct s3c2410_wdt {
+ struct device *dev;
+ struct clk *clock;
+ void __iomem*reg_base;
+ unsigned intcount;
+ spinlock_t lock;
+ unsigned long wtcon_save;
+ unsigned long wtdat_save;
+ struct watchdog_device wdt_device;
+ struct notifier_block freq_transition;
+};
/* watchdog control routines */
@@ -102,29 +106,43 @@ do {
\
/* functions */
+static inline struct s3c2410_wdt *to_s3c2410_wdt(struct watchdog_device *wdd)
+{
+ return container_of(wdd, struct s3c2410_wdt, wdt_device);
+}
+
+static inline struct s3c2410_wdt *freq_to_wdt(struct notifier_block *nb)
+{
+ return container_of(nb, struct s3c2410_wdt, freq_transition);
+}
+
static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
{
- spin_lock(&wdt_lock);
- writel(wdt_count, wdt_base + S3C2410_WTCNT);
- spin_unlock(&wdt_lock);
+ struct s3c2410_wdt *wdt = to_s3c2410_wdt(wdd);
+
+ spin_lock(&wdt->lock);
+ writel(wdt->count, wdt->reg_base + S3C2410_WTCNT);
+ spin_unlock(&wdt->lock);
return 0;
}
-static void __s3c2410wdt_stop(void)
+static void __s3c2410wdt_stop(struct s3c2410_wdt *wdt)
{
unsigned long wtcon;
- wtcon = readl(wdt_base + S3C2410_WTCON);
+ wtcon = readl(wdt->reg_base + S3C2410_WTCON);
wtcon &= ~(S3C2410_WTCON_ENABLE | S3C2410_WTCON_RSTEN);
- writel(wtcon, wdt_base + S3C2410_WTCON);
+ writel(wtcon, wdt->reg_base + S3C2410_WTCON);
}
static int s3c2410wdt_stop(struct watchdog_device *wdd)
{
- spin_lock(&wdt_lock);
- __s3c2410wdt_stop();
- spin_unlock(&wdt_lock);
+ struct s3c2410_wdt *wdt = to_s3c2410_wdt(wdd);
+
+ spin_lock(&wdt->lock);
+ __s3c2410wdt_stop(wdt);
+ spin_unlock(&wdt->lock);
return 0;
}
@@ -132,12 +150,13 @@ static int s3c2410wdt_stop(struct watchdog_device *wdd)
static int s3c2410wdt_start(struct watchdog_device *wdd)
{
unsigned long wtcon;
+ struct s3c2410_wdt *wdt = to_s3c2410_wdt(wdd);
- spin_lock(&wdt_lock);
+ spin_lock(&wdt->lock);
- __s3c2410wdt_stop();
+ __s3c2410wdt_stop(wdt);
- wtcon = readl(wdt_base + S3C2410_WTCON);
+ wtcon = readl(wdt->reg_base + S3C2410_WTCON);
wtcon |= S3C2410_WTCON_ENABLE | S3C2410_WTCON_DIV128;
if (soft_noboot) {
@@ -148,25 +167,26 @@ static int s3c2410wdt_start(struct watchdog_device *wdd)
wtcon |= S3C2410_WTCON_RSTEN;
}
- DBG("%s: wdt_count=0x%08x, wtcon=%08lx\n",
- __func__, wdt_count, wtcon);
+ DBG("%s: count=0x%08x, wtcon=%08lx\n",
+ __func__, wdt->count, wtcon);
- writel(wdt_count, wdt_base + S3C2410_WTDAT);
- writel(wdt_count, wdt_base + S3C2410_WTCNT);
- writel(wtcon, wdt_base + S3C2410_WTCON);
- spin_unlock(&wdt_lock);
+ writel(wdt->count, wdt->reg_base + S3C2410_WTDAT);
+ writel(wdt->count, wdt->reg_base + S3C2410_WTCNT);
+ writel(wtcon, wdt->reg_base + S3C2410_WTCON);
+ spin_unlock(&wdt->lock);
return 0;
}
-static inline int s3c2410wdt_is_running(void)
+static inline int s3c2410wdt_is_running(struct s3c2410_wdt *wdt)
{
- return readl(wdt_base + S3C2410_WTCON) & S3C2410_WTCON_ENABLE;
+ return readl(wdt->reg_base + S3C2410_WTCON) & S3C2410_WTCON_ENABLE;
}
static int s3c2410wdt_set_heartbeat(struct watchdog_device *wdd, unsigned
timeout)
{
- unsigned long freq = clk_ge
Re: [PATCH] ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART
On Sunday 21 July 2013 21:42:45 Sylwester Nawrocki wrote: > This patch restores serial port operation which has been broken since > commit 60e93575476f90a72146b51283f514da655410a7 > serial: samsung: enable clock before clearing pending interrupts during > init > > That commit only uncovered the real issue which was missing clkdev > entries for the "uart" clocks on S3C2440. It went unnoticed so far > because return value of clk API calls were not being checked at all > in the samsung serial port driver. > > This patch should be backported to at least 3.10 stable kernel, since > the serial port has not been working on s3c2440 since 3.10-rc5. > > Cc: Chander Kashyap > Signed-off-by: Sylwester Nawrocki > [on S3C2440 SoC based Mini2440 board] > Tested-by: Sylwester Nawrocki > > [...] Tested-by: Juergen Beisert -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | Phone: +49-5121-206917-5128 | Peiner Str. 6-8, 31137 Hildesheim, Germany | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
[Fixed address of devicetree mailing list and added more people on CC.]
For reference, full thread can be found under following link:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813
Best regards,
Tomasz
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> Hi Alan,
>
> On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
> > On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
> > > > The PHY and the controller it is attached to are both
physical
> > > > devices.
> > > >
> > > > The connection between them is hardwired by the system
> > > > manufacturer and cannot be changed by software.
> > > >
> > > > PHYs are generally described by fixed system-specific
board
> > > > files or by Device Tree information. Are they ever
discovered
> > > > dynamically?
> > >
> > > No. They are created just like any other platform devices are
> > > created.
> >
> > Okay. Are PHYs _always_ platform devices?
>
> They can be i2c, spi or any other device types as well.
>
> > > > Is the same true for the controllers attached to the PHYs?
> > > > If not -- if both a PHY and a controller are discovered
> > > > dynamically -- how does the kernel know whether they are
> > > > connected to each other?
> > >
> > > No differences here. Both PHY and controller will have dt
> > > information
> > > or hwmod data using which platform devices will be created.
> > >
> > > > The kernel needs to know which controller is attached to
which
> > > > PHY. Currently this information is represented by name or
ID
> > > > strings embedded in platform data.
> > >
> > > right. It's embedded in the platform data of the controller.
> >
> > It must also be embedded in the PHY's platform data somehow.
> > Otherwise, how would the kernel know which PHY to use?
>
> By using a PHY lookup as Stephen and I suggested in our previous
> replies. Without any extra data in platform data. (I have even posted a
> code example.)
>
> > > > The PHY's driver (the supplier) uses the platform data to
> > > > construct a platform_device structure that represents the
PHY.
> > >
> > > Currently the driver assigns static labels (corresponding to the
> > > label
> > > used in the platform data of the controller).
> > >
> > > > Until this is done, the controller's driver (the client)
cannot
> > > > use the PHY.
> > >
> > > right.
> > >
> > > > Since there is no parent-child relation between the PHY
and the
> > > > controller, there is no guarantee that the PHY's driver
will be
> > > > ready when the controller's driver wants to use it. A
deferred
> > > > probe may be needed.
> > >
> > > right.
> > >
> > > > The issue (or one of the issues) in this discussion is
that
> > > > Greg does not like the idea of using names or IDs to
associate
> > > > PHYs with controllers, because they are too prone to
> > > > duplications or other errors. Pointers are more reliable.
> > > >
> > > > But pointers to what? Since the only data known to be
> > > > available to both the PHY driver and controller driver is
the
> > > > platform data, the obvious answer is a pointer to platform
data
> > > > (either for the PHY or for the controller, or maybe both).
> > >
> > > hmm.. it's not going to be simple though as the platform device for
> > > the PHY and controller can be created in entirely different places.
> > > e.g., in some cases the PHY device is a child of some mfd core
> > > device
> > > (the device will be created in drivers/mfd) and the controller
> > > driver
> > > (usually) is created in board file. I guess then we have to come up
> > > with something to share a pointer in two different files.
> >
> > The ability for two different source files to share a pointer to a
> > data
> > item defined in a third source file has been around since long before
> > the C language was invented. :-)
> >
> > In this case, it doesn't matter where the platform_device structures
> > are created or where the driver source code is. Let's take a simple
> > example. Suppose the system design includes a PHY named "foo". Then
> > the board file could contain:
> >
> > struct phy_info { ... } phy_foo;
> > EXPORT_SYMBOL_GPL(phy_foo);
> >
> > and a header file would contain:
> >
> > extern struct phy_info phy_foo;
> >
> > The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > client could call phy_find(&phy_foo). Or something like that; make up
> > your own structure tags and function names.
> >
> > It's still possible to have conflicts, but now two PHYs with the same
> > name (or a misspelled name somewhere) will cause an error at link
> > time.
>
> This is incorrect, sorry. First of all it's a layering violation - you
> export random driver-specific symbols from one driver to an
Re: [PATCH] ARM: EXYNOS: Fix low level debug support
On Tuesday 23 of July 2013 13:04:58 Yadwinder Singh Brar wrote:
> On Mon, Jul 22, 2013 at 6:37 PM, Tomasz Figa wrote:
> > On Monday 22 of July 2013 06:23:06 Thomas Abraham wrote:
> >> On 13 July 2013 04:57, Yadwinder Singh Brar
> >
> > wrote:
> >> > Presently, using exynos_defconfig with CONFIG_DEBUG_LL and
> >> > CONFIG_EARLY_PRINTK on, kernel is not booting, we are getting
> >> > following:
> >> >
> >> > [0.00] [ cut here ]
> >> > [0.00] kernel BUG at mm/vmalloc.c:1134!
> >> > [0.00] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> >> > [0.00] Modules linked in:
> >> > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc1
> >> > #633
> >> > [0.00] task: c052ec48 ti: c0524000 task.ti: c0524000
> >> > [0.00] PC is at vm_area_add_early+0x54/0x94
> >> > [0.00] LR is at add_static_vm_early+0xc/0x60
> >> >
> >> > Its because iotable_init tries to map UART again which is already
> >> > mapped by debug_ll_io_init() call in exynos_init_io() within same
> >> > virtal address range as requested later.
> >>
> >> debug_ll_io_init ioremaps debug uart address space with 4KB size
> >> whereas the exynos_init_io() function ioremaps a single 512KB memory
> >> size for all the four uart ports which envelops the mapping created
> >> by
> >> debug_ll_io_init. This is caught as a kernel bug.
> >
> > Right.
> >
> >> > This issue seems to be occured after :
> >> > commit ee4de5d99aeac44f4507b7538b2b3faedc5205b9
> >> > ARM: 7781/1: mmu: Add debug_ll_io_init() mappings to early mappings
> >> >
> >> > This patch moves S3C_UART iodesc(in iodesc_list) inside
> >> > CONFIG_DEBUG_LL
> >> > check.
> >>
> >> Instead of moving, all the such iodesc entries for UART controller
> >> can
> >> be removed for all Samsung SoC's now since the Samsung uart driver
> >> does a ioremap during probe and any needed iomapping for earlyprintk
> >> is handled by debug_ll_io_init().
> >
> > Yes. This mapping should not be here, but...
> >
> > If you look at plat-samsung/pm.c, there is a debugging code that
> > relies on presence of this mapping.
>
> Thanks for pointing this, I completely missed it.
>
> >So until this gets fixed/removed (I'm working on
> >
> > it right now), I'd suggest keeping Yadwinder's solution.
>
> But that debugging code is under "CONFIG_SAMSUNG_PM_DEBUG"
> and SAMSUNG_PM_DEBUG selects DEBUG_LL also.
> So the problem you stated below will their always when ever it will
> enter that code
Makes sense.
> > The only problem is that the code in pm.c expects _all_ UARTs to be
> > mapped (see s3c_pm_resture_uarts() and co.), so in case of DEBUG_LL
> > enabled, something must be done ensure that rest of the ports are
> > mapped.
> how about fixing this problem with something like below:
> saving only mapped/configured UART's registers.
>
> 8<--
> -- diff --git
> a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c index
> ea36136..34a7371 100644
> --- a/arch/arm/plat-samsung/pm.c
> +++ b/arch/arm/plat-samsung/pm.c
> @@ -102,10 +102,8 @@ static void s3c_pm_save_uart(unsigned int uart,
> struct pm_u static void s3c_pm_save_uarts(void)
> {
> struct pm_uart_save *save = uart_save;
> - unsigned int uart;
>
> - for (uart = 0; uart < CONFIG_SERIAL_SAMSUNG_UARTS; uart++,
> save++) - s3c_pm_save_uart(uart, save);
> + s3c_pm_save_uart(CONFIG_DEBUG_S3C_UART, save);
> }
>
> static void s3c_pm_restore_uart(unsigned int uart, struct pm_uart_save
> *save)
>
> 8<--
>
Looks good to me.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS: Fix low level debug support
On Mon, Jul 22, 2013 at 6:37 PM, Tomasz Figa wrote:
> On Monday 22 of July 2013 06:23:06 Thomas Abraham wrote:
>> On 13 July 2013 04:57, Yadwinder Singh Brar
> wrote:
>> > Presently, using exynos_defconfig with CONFIG_DEBUG_LL and
>> > CONFIG_EARLY_PRINTK on, kernel is not booting, we are getting
>> > following:
>> >
>> > [0.00] [ cut here ]
>> > [0.00] kernel BUG at mm/vmalloc.c:1134!
>> > [0.00] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
>> > [0.00] Modules linked in:
>> > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc1 #633
>> > [0.00] task: c052ec48 ti: c0524000 task.ti: c0524000
>> > [0.00] PC is at vm_area_add_early+0x54/0x94
>> > [0.00] LR is at add_static_vm_early+0xc/0x60
>> >
>> > Its because iotable_init tries to map UART again which is already
>> > mapped by debug_ll_io_init() call in exynos_init_io() within same
>> > virtal address range as requested later.
>>
>> debug_ll_io_init ioremaps debug uart address space with 4KB size
>> whereas the exynos_init_io() function ioremaps a single 512KB memory
>> size for all the four uart ports which envelops the mapping created by
>> debug_ll_io_init. This is caught as a kernel bug.
>
> Right.
>
>> > This issue seems to be occured after :
>> > commit ee4de5d99aeac44f4507b7538b2b3faedc5205b9
>> > ARM: 7781/1: mmu: Add debug_ll_io_init() mappings to early mappings
>> >
>> > This patch moves S3C_UART iodesc(in iodesc_list) inside CONFIG_DEBUG_LL
>> > check.
>> Instead of moving, all the such iodesc entries for UART controller can
>> be removed for all Samsung SoC's now since the Samsung uart driver
>> does a ioremap during probe and any needed iomapping for earlyprintk
>> is handled by debug_ll_io_init().
>
> Yes. This mapping should not be here, but...
>
> If you look at plat-samsung/pm.c, there is a debugging code that relies on
> presence of this mapping.
Thanks for pointing this, I completely missed it.
>So until this gets fixed/removed (I'm working on
> it right now), I'd suggest keeping Yadwinder's solution.
>
But that debugging code is under "CONFIG_SAMSUNG_PM_DEBUG"
and SAMSUNG_PM_DEBUG selects DEBUG_LL also.
So the problem you stated below will their always when ever it will
enter that code
> The only problem is that the code in pm.c expects _all_ UARTs to be mapped
> (see s3c_pm_resture_uarts() and co.), so in case of DEBUG_LL enabled,
> something must be done ensure that rest of the ports are mapped.
>
how about fixing this problem with something like below:
saving only mapped/configured UART's registers.
8<
diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
index ea36136..34a7371 100644
--- a/arch/arm/plat-samsung/pm.c
+++ b/arch/arm/plat-samsung/pm.c
@@ -102,10 +102,8 @@ static void s3c_pm_save_uart(unsigned int uart, struct pm_u
static void s3c_pm_save_uarts(void)
{
struct pm_uart_save *save = uart_save;
- unsigned int uart;
- for (uart = 0; uart < CONFIG_SERIAL_SAMSUNG_UARTS; uart++, save++)
- s3c_pm_save_uart(uart, save);
+ s3c_pm_save_uart(CONFIG_DEBUG_S3C_UART, save);
}
static void s3c_pm_restore_uart(unsigned int uart, struct pm_uart_save *save)
8<--
> I'm going to completely rework Samsung PM code in some time, so this
> problem will go away, but this must be fixed in 3.11.
>
Yes, it will be helpful if we have it fixed.
Regards,
Yadwinder
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Alan,
On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
> On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
> > > The PHY and the controller it is attached to are both physical
> > > devices.
> > >
> > > The connection between them is hardwired by the system
> > > manufacturer and cannot be changed by software.
> > >
> > > PHYs are generally described by fixed system-specific board
> > > files or by Device Tree information. Are they ever discovered
> > > dynamically?
> >
> > No. They are created just like any other platform devices are created.
>
> Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
> > > Is the same true for the controllers attached to the PHYs?
> > > If not -- if both a PHY and a controller are discovered
> > > dynamically -- how does the kernel know whether they are
> > > connected to each other?
> >
> > No differences here. Both PHY and controller will have dt information
> > or hwmod data using which platform devices will be created.
> >
> > > The kernel needs to know which controller is attached to which
> > > PHY. Currently this information is represented by name or ID
> > > strings embedded in platform data.
> >
> > right. It's embedded in the platform data of the controller.
>
> It must also be embedded in the PHY's platform data somehow.
> Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous replies.
Without any extra data in platform data. (I have even posted a code
example.)
> > > The PHY's driver (the supplier) uses the platform data to
> > > construct a platform_device structure that represents the PHY.
> >
> > Currently the driver assigns static labels (corresponding to the label
> > used in the platform data of the controller).
> >
> > > Until this is done, the controller's driver (the client) cannot
> > > use the PHY.
> >
> > right.
> >
> > > Since there is no parent-child relation between the PHY and the
> > > controller, there is no guarantee that the PHY's driver will be
> > > ready when the controller's driver wants to use it. A deferred
> > > probe may be needed.
> >
> > right.
> >
> > > The issue (or one of the issues) in this discussion is that
> > > Greg does not like the idea of using names or IDs to associate
> > > PHYs with controllers, because they are too prone to
> > > duplications or other errors. Pointers are more reliable.
> > >
> > > But pointers to what? Since the only data known to be
> > > available to both the PHY driver and controller driver is the
> > > platform data, the obvious answer is a pointer to platform data
> > > (either for the PHY or for the controller, or maybe both).
> >
> > hmm.. it's not going to be simple though as the platform device for
> > the PHY and controller can be created in entirely different places.
> > e.g., in some cases the PHY device is a child of some mfd core device
> > (the device will be created in drivers/mfd) and the controller driver
> > (usually) is created in board file. I guess then we have to come up
> > with something to share a pointer in two different files.
>
> The ability for two different source files to share a pointer to a data
> item defined in a third source file has been around since long before
> the C language was invented. :-)
>
> In this case, it doesn't matter where the platform_device structures
> are created or where the driver source code is. Let's take a simple
> example. Suppose the system design includes a PHY named "foo". Then
> the board file could contain:
>
> struct phy_info { ... } phy_foo;
> EXPORT_SYMBOL_GPL(phy_foo);
>
> and a header file would contain:
>
> extern struct phy_info phy_foo;
>
> The PHY supplier could then call phy_create(&phy_foo), and the PHY
> client could call phy_find(&phy_foo). Or something like that; make up
> your own structure tags and function names.
>
> It's still possible to have conflicts, but now two PHYs with the same
> name (or a misspelled name somewhere) will cause an error at link time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host drivers.
This means you would have to export symbol with the same name from both
PHY drivers, which obviously would not work in this case, because having
both drivers enabled (in a multiplatform aware configuration) would lead
to linking conflict.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday, July 23, 2013 3:30 PM, Kishon Vijay Abraham I wrote: > On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote: > > On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote: > >> On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote: > >>> Exynos PCIe IP consists of Synopsys specific part and Exynos > >>> specific part. Only core block is a Synopsys designware part; > >>> other parts are Exynos specific. > >>> Also, the Synopsys designware part can be shared with other > >>> platforms; thus, it can be split two parts such as Synopsys > >>> designware part and Exynos specific part. > >> > >> some more queries and comments.. > > > . > . > > . > . > >>> + of_pci_range_to_resource(&range, np, &pp->cfg); > >>> + pp->config.cfg0_size = resource_size(&pp->cfg)/2; > >>> + pp->config.cfg1_size = resource_size(&pp->cfg)/2; > >>> + } > >>> + } > >>> + > >>> + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start, > >>> + resource_size(&pp->cfg)); > >> > >> Why is configuraion space divided into two? > > > > Sorry, I don't know the exact reason. :( > > Pratyush Anand may know about this. > > Pratyush Anand, could you answer the question? > > > > Also, if you find some problems, please let me know. > > > > > >> Why should it be same as dbi_base? > >> AFAIK, jacinto6 has a dedicated configuration/io/memory space that is > >> entirely > >> different from dbi_base. > > > > According to the Synopsys designware PCIe datasheet, > > in chapter 5.1.1 Register Space Layout, > > 'Port Logic Registers' are placed between (config space 0x0 + 0x700) > > and (config space 0x0 + 0xFFF). > > 'dbi_base' is used for reading/writing 'Port Logic Registers'. > > Exynos are using 'dbi_base' like this. Thus, the base addresses of > > both 'dbi_base' and configuration/io/memory space are same. > > > > Just now, I looked at Spear PCIe driver. > > However, in the case of Spear, the base address of configuration/io/memory > > space is defined as 0x8000. The base address of 'Port Logic Registers' > > is defined as 0xb100. > > I think that the situation of 'jacinto6' is similar with Spear, right? > > > > Then, I will move pp->dbi_base mapping code from pcie-designware.c > > to pci-exynos.c. > > I think you need not move this to exynos (since registers in dbi_base is > common > for all platforms) but modify the pcie-designware.c to use different address > space for dbi_base. In your case, you'll duplicate the address space for > dbi_base and configuration space. I cannot understand fully what you said. Please, give a pseudo code. > > Also I have one more query. > In your dt binding, your pci address and cpu address is the same. But the pci > address should start at 0x and end at 0x (for 32bit). > Shouldn't > the cpu address map to something within this range of pci address? > Sorry, I cannot answer it exactly. DT binding was confirmed by Arnd Bergmann. He will answer it exactly. Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
