Re: [PATCH 3/3] MAINTAINERS: Update AT91 entries

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 28, 2017, at 1:00 AM, Alexandre Belloni 
> <alexandre.bell...@free-electrons.com> wrote:
> 
> On 28/01/2017 at 00:51:13 +0800, Jean-Christophe Plagniol-Villard wrote:
>>  this does not mean I do not follow the ML
>> 
> 
> That's not what I'm implying. Many people are following various mailing
> list without being listed in MAINTAINERS.
So I’m still maintaining the drivers even there is not much to do today

so no

Best Regards,
J.
> 
>> Best Regards,
>> J.
>>> On Jan 28, 2017, at 12:32 AM, Nicolas Ferre <nicolas.fe...@atmel.com> wrote:
>>> 
>>> Le 27/01/2017 à 17:28, Alexandre Belloni a écrit :
>>>> Jean Christophe has not been active on the mailing lists for a while.
>>>> Remove him from the maintainers
>>>> 
>>>> Also, merge both AT91 pinctrl drivers entries.
>>>> 
>>>> Cc: Jean-Christophe Plagniol-Villard <plagn...@jcrosoft.com>
>>>> Signed-off-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
>>> 
>>> Yes:
>>> 
>>> Acked-by: Nicolas Ferre <nicolas.fe...@microchip.com>
>>> 
>>> Thanks, regards,
>>> 
>>>> ---
>>>> Also, as pointed to by Tomi (https://lkml.org/lkml/2016/9/27/72), emails 
>>>> were
>>>> bouncing for a while
>>>> 
>>>> 
>>>> MAINTAINERS | 8 +---
>>>> 1 file changed, 1 insertion(+), 7 deletions(-)
>>>> 
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index eb9739ec4e92..bfcc70032254 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -1093,7 +1093,6 @@ F:   drivers/*/*aspeed*
>>>> ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT
>>>> M: Nicolas Ferre <nicolas.fe...@microchip.com>
>>>> M: Alexandre Belloni <alexandre.bell...@free-electrons.com>
>>>> -M:Jean-Christophe Plagniol-Villard <plagn...@jcrosoft.com>
>>>> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>>>> W: http://www.linux4sam.org
>>>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git
>>>> @@ -9704,16 +9703,11 @@ F: drivers/pinctrl/
>>>> F: include/linux/pinctrl/
>>>> 
>>>> PIN CONTROLLER - ATMEL AT91
>>>> -M:Jean-Christophe Plagniol-Villard <plagn...@jcrosoft.com>
>>>> -L:linux-arm-ker...@lists.infradead.org (moderated for 
>>>> non-subscribers)
>>>> -S:Maintained
>>>> -F:drivers/pinctrl/pinctrl-at91.*
>> Nack
>>>> -
>>>> -PIN CONTROLLER - ATMEL AT91 PIO4
>>>> M: Ludovic Desroches <ludovic.desroc...@microchip.com>
>>>> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>>>> L: linux-g...@vger.kernel.org
>>>> S: Supported
>>>> +F:drivers/pinctrl/pinctrl-at91.*
>>>> F: drivers/pinctrl/pinctrl-at91-pio4.*
>>>> 
>>>> PIN CONTROLLER - INTEL
>>>> 
>>> 
>>> -- 
>>> Nicolas Ferre
>>> 
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: [PATCH 3/3] MAINTAINERS: Update AT91 entries

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 28, 2017, at 1:00 AM, Alexandre Belloni 
>  wrote:
> 
> On 28/01/2017 at 00:51:13 +0800, Jean-Christophe Plagniol-Villard wrote:
>>  this does not mean I do not follow the ML
>> 
> 
> That's not what I'm implying. Many people are following various mailing
> list without being listed in MAINTAINERS.
So I’m still maintaining the drivers even there is not much to do today

so no

Best Regards,
J.
> 
>> Best Regards,
>> J.
>>> On Jan 28, 2017, at 12:32 AM, Nicolas Ferre  wrote:
>>> 
>>> Le 27/01/2017 à 17:28, Alexandre Belloni a écrit :
>>>> Jean Christophe has not been active on the mailing lists for a while.
>>>> Remove him from the maintainers
>>>> 
>>>> Also, merge both AT91 pinctrl drivers entries.
>>>> 
>>>> Cc: Jean-Christophe Plagniol-Villard 
>>>> Signed-off-by: Alexandre Belloni 
>>> 
>>> Yes:
>>> 
>>> Acked-by: Nicolas Ferre 
>>> 
>>> Thanks, regards,
>>> 
>>>> ---
>>>> Also, as pointed to by Tomi (https://lkml.org/lkml/2016/9/27/72), emails 
>>>> were
>>>> bouncing for a while
>>>> 
>>>> 
>>>> MAINTAINERS | 8 +---
>>>> 1 file changed, 1 insertion(+), 7 deletions(-)
>>>> 
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index eb9739ec4e92..bfcc70032254 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -1093,7 +1093,6 @@ F:   drivers/*/*aspeed*
>>>> ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT
>>>> M: Nicolas Ferre 
>>>> M: Alexandre Belloni 
>>>> -M:Jean-Christophe Plagniol-Villard 
>>>> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>>>> W: http://www.linux4sam.org
>>>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git
>>>> @@ -9704,16 +9703,11 @@ F: drivers/pinctrl/
>>>> F: include/linux/pinctrl/
>>>> 
>>>> PIN CONTROLLER - ATMEL AT91
>>>> -M:Jean-Christophe Plagniol-Villard 
>>>> -L:linux-arm-ker...@lists.infradead.org (moderated for 
>>>> non-subscribers)
>>>> -S:Maintained
>>>> -F:drivers/pinctrl/pinctrl-at91.*
>> Nack
>>>> -
>>>> -PIN CONTROLLER - ATMEL AT91 PIO4
>>>> M: Ludovic Desroches 
>>>> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>>>> L: linux-g...@vger.kernel.org
>>>> S: Supported
>>>> +F:drivers/pinctrl/pinctrl-at91.*
>>>> F: drivers/pinctrl/pinctrl-at91-pio4.*
>>>> 
>>>> PIN CONTROLLER - INTEL
>>>> 
>>> 
>>> -- 
>>> Nicolas Ferre
>>> 
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: [PATCH 3/3] MAINTAINERS: Update AT91 entries

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

this does not mean I do not follow the ML

Best Regards,
J.
> On Jan 28, 2017, at 12:32 AM, Nicolas Ferre <nicolas.fe...@atmel.com> wrote:
> 
> Le 27/01/2017 à 17:28, Alexandre Belloni a écrit :
>> Jean Christophe has not been active on the mailing lists for a while.
>> Remove him from the maintainers
>> 
>> Also, merge both AT91 pinctrl drivers entries.
>> 
>> Cc: Jean-Christophe Plagniol-Villard <plagn...@jcrosoft.com>
>> Signed-off-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
> 
> Yes:
> 
> Acked-by: Nicolas Ferre <nicolas.fe...@microchip.com>
> 
> Thanks, regards,
> 
>> ---
>> Also, as pointed to by Tomi (https://lkml.org/lkml/2016/9/27/72), emails were
>> bouncing for a while
>> 
>> 
>> MAINTAINERS | 8 +---
>> 1 file changed, 1 insertion(+), 7 deletions(-)
>> 
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index eb9739ec4e92..bfcc70032254 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1093,7 +1093,6 @@ F: drivers/*/*aspeed*
>> ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT
>> M:   Nicolas Ferre <nicolas.fe...@microchip.com>
>> M:   Alexandre Belloni <alexandre.bell...@free-electrons.com>
>> -M:  Jean-Christophe Plagniol-Villard <plagn...@jcrosoft.com>
>> L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>> W:   http://www.linux4sam.org
>> T:   git git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git
>> @@ -9704,16 +9703,11 @@ F:   drivers/pinctrl/
>> F:   include/linux/pinctrl/
>> 
>> PIN CONTROLLER - ATMEL AT91
>> -M:  Jean-Christophe Plagniol-Villard <plagn...@jcrosoft.com>
>> -L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>> -S:  Maintained
>> -F:  drivers/pinctrl/pinctrl-at91.*
Nack
>> -
>> -PIN CONTROLLER - ATMEL AT91 PIO4
>> M:   Ludovic Desroches <ludovic.desroc...@microchip.com>
>> L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>> L:   linux-g...@vger.kernel.org
>> S:   Supported
>> +F:  drivers/pinctrl/pinctrl-at91.*
>> F:   drivers/pinctrl/pinctrl-at91-pio4.*
>> 
>> PIN CONTROLLER - INTEL
>> 
> 
> -- 
> Nicolas Ferre
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] MAINTAINERS: Update AT91 entries

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

this does not mean I do not follow the ML

Best Regards,
J.
> On Jan 28, 2017, at 12:32 AM, Nicolas Ferre  wrote:
> 
> Le 27/01/2017 à 17:28, Alexandre Belloni a écrit :
>> Jean Christophe has not been active on the mailing lists for a while.
>> Remove him from the maintainers
>> 
>> Also, merge both AT91 pinctrl drivers entries.
>> 
>> Cc: Jean-Christophe Plagniol-Villard 
>> Signed-off-by: Alexandre Belloni 
> 
> Yes:
> 
> Acked-by: Nicolas Ferre 
> 
> Thanks, regards,
> 
>> ---
>> Also, as pointed to by Tomi (https://lkml.org/lkml/2016/9/27/72), emails were
>> bouncing for a while
>> 
>> 
>> MAINTAINERS | 8 +---
>> 1 file changed, 1 insertion(+), 7 deletions(-)
>> 
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index eb9739ec4e92..bfcc70032254 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1093,7 +1093,6 @@ F:     drivers/*/*aspeed*
>> ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT
>> M:   Nicolas Ferre 
>> M:   Alexandre Belloni 
>> -M:  Jean-Christophe Plagniol-Villard 
>> L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>> W:   http://www.linux4sam.org
>> T:   git git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git
>> @@ -9704,16 +9703,11 @@ F:   drivers/pinctrl/
>> F:   include/linux/pinctrl/
>> 
>> PIN CONTROLLER - ATMEL AT91
>> -M:  Jean-Christophe Plagniol-Villard 
>> -L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>> -S:  Maintained
>> -F:  drivers/pinctrl/pinctrl-at91.*
Nack
>> -
>> -PIN CONTROLLER - ATMEL AT91 PIO4
>> M:   Ludovic Desroches 
>> L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>> L:   linux-g...@vger.kernel.org
>> S:   Supported
>> +F:  drivers/pinctrl/pinctrl-at91.*
>> F:   drivers/pinctrl/pinctrl-at91-pio4.*
>> 
>> PIN CONTROLLER - INTEL
>> 
> 
> -- 
> Nicolas Ferre
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] MAINTAINERS: update DT binding doc locations

[Jean-Christophe PLAGNIOL-VILLARD]

> On Nov 6, 2015, at 3:41 AM, Rob Herring  wrote:
> 
> After the recent moving of DT binding documents, some maintainers entries
> are stale. Update them to the new locations.
> 
> In bindings/fb/, there were only 2 files and I'm assuming the FB
> maintainers don't want to be copied on all of bindings/display/. So I've
> dropped them.
> 
> Reported-by: Thierry Reding 
> Cc: Thierry Reding 
> Cc: Jianwei Wang 
> Cc: Alison Wang 
> Cc: Philipp Zabel 
> Cc: Mark Yao 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Tomi Valkeinen 
> Cc: James Hogan 
> Cc: Hans de Goede 
> Cc: Vineet Gupta 
> Signed-off-by: Rob Herring 

Ack
> ---
> MAINTAINERS | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9f6685f..e2aa973 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3577,7 +3577,7 @@ S:  Maintained
> F:drivers/gpu/drm/drm_panel.c
> F:drivers/gpu/drm/panel/
> F:include/drm/drm_panel.h
> -F:   Documentation/devicetree/bindings/panel/
> +F:   Documentation/devicetree/bindings/display/panel/
> 
> INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
> M:Daniel Vetter 
> @@ -3609,15 +3609,15 @@ M:Alison Wang 
> L:dri-de...@lists.freedesktop.org
> S:Supported
> F:drivers/gpu/drm/fsl-dcu/
> -F:   Documentation/devicetree/bindings/video/fsl,dcu.txt
> -F:   Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> +F:   Documentation/devicetree/bindings/display/fsl,dcu.txt
> +F:   Documentation/devicetree/bindings/display/panel/nec,nl4827hc19_05b.txt
> 
> DRM DRIVERS FOR FREESCALE IMX
> M:Philipp Zabel 
> L:dri-de...@lists.freedesktop.org
> S:Maintained
> F:drivers/gpu/drm/imx/
> -F:   Documentation/devicetree/bindings/drm/imx/
> +F:   Documentation/devicetree/bindings/display/imx/
> 
> DRM DRIVERS FOR NVIDIA TEGRA
> M:Thierry Reding 
> @@ -3630,7 +3630,7 @@ F:  drivers/gpu/drm/tegra/
> F:drivers/gpu/host1x/
> F:include/linux/host1x.h
> F:include/uapi/drm/tegra_drm.h
> -F:   Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
> +F:   
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> 
> DRM DRIVERS FOR RENESAS
> M:Laurent Pinchart 
> @@ -3647,7 +3647,7 @@ M:  Mark Yao 
> L:dri-de...@lists.freedesktop.org
> S:Maintained
> F:drivers/gpu/drm/rockchip/
> -F:   Documentation/devicetree/bindings/video/rockchip*
> +F:   Documentation/devicetree/bindings/display/rockchip*
> 
> DRM DRIVERS FOR STI
> M:Benjamin Gaignard 
> @@ -3656,7 +3656,7 @@ L:  dri-de...@lists.freedesktop.org
> T:git http://git.linaro.org/people/benjamin.gaignard/kernel.git
> S:Maintained
> F:drivers/gpu/drm/sti
> -F:   Documentation/devicetree/bindings/gpu/st,stih4xx.txt
> +F:   Documentation/devicetree/bindings/display/st,stih4xx.txt
> 
> DSBR100 USB FM RADIO DRIVER
> M:Alexey Klimov 
> @@ -4342,7 +4342,6 @@ Q:  
> http://patchwork.kernel.org/project/linux-fbdev/list/
> T:git 
> git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git
> S:Maintained
> F:Documentation/fb/
> -F:   Documentation/devicetree/bindings/fb/
> F:drivers/video/
> F:include/video/
> F:include/linux/fb.h
> @@ -6855,6 +6854,7 @@ S:  Supported
> F:arch/metag/
> F:Documentation/metag/
> F:Documentation/devicetree/bindings/metag/
> +F:   Documentation/devicetree/bindings/interrupt-controller/img,*
> F:drivers/clocksource/metag_generic.c
> F:drivers/irqchip/irq-metag.c
> F:drivers/irqchip/irq-metag-ext.c
> @@ -9443,7 +9443,7 @@ SIMPLEFB FB DRIVER
> M:Hans de Goede 
> L:linux-fb...@vger.kernel.org
> S:Maintained
> -F:   Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +F:   Documentation/devicetree/bindings/display/simple-framebuffer.txt
> F:drivers/video/fbdev/simplefb.c
> F:include/linux/platform_data/simplefb.h
> 
> @@ -10072,6 +10072,7 @@ M:Vineet Gupta 
> S:Supported
> F:arch/arc/
> F:Documentation/devicetree/bindings/arc/*
> +F:   Documentation/devicetree/bindings/interrupt-controller/snps,arc*
> F:drivers/tty/serial/arc_uart.c
> T:git git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git
> 
> -- 
> 2.5.0
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MAINTAINERS: update DT binding doc locations

[Jean-Christophe PLAGNIOL-VILLARD]

> On Nov 6, 2015, at 3:41 AM, Rob Herring <r...@kernel.org> wrote:
> 
> After the recent moving of DT binding documents, some maintainers entries
> are stale. Update them to the new locations.
> 
> In bindings/fb/, there were only 2 files and I'm assuming the FB
> maintainers don't want to be copied on all of bindings/display/. So I've
> dropped them.
> 
> Reported-by: Thierry Reding <thierry.red...@gmail.com>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Cc: Jianwei Wang <jianwei.wang@gmail.com>
> Cc: Alison Wang <alison.w...@freescale.com>
> Cc: Philipp Zabel <p.za...@pengutronix.de>
> Cc: Mark Yao <mark@rock-chips.com>
> Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org>
> Cc: Vincent Abriou <vincent.abr...@st.com>
> Cc: Jean-Christophe Plagniol-Villard <plagn...@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
> Cc: James Hogan <james.ho...@imgtec.com>
> Cc: Hans de Goede <hdego...@redhat.com>
> Cc: Vineet Gupta <vgu...@synopsys.com>
> Signed-off-by: Rob Herring <r...@kernel.org>

Ack
> ---
> MAINTAINERS | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9f6685f..e2aa973 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3577,7 +3577,7 @@ S:  Maintained
> F:drivers/gpu/drm/drm_panel.c
> F:drivers/gpu/drm/panel/
> F:include/drm/drm_panel.h
> -F:   Documentation/devicetree/bindings/panel/
> +F:   Documentation/devicetree/bindings/display/panel/
> 
> INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
> M:Daniel Vetter <daniel.vet...@intel.com>
> @@ -3609,15 +3609,15 @@ M:Alison Wang <alison.w...@freescale.com>
> L:dri-de...@lists.freedesktop.org
> S:Supported
> F:drivers/gpu/drm/fsl-dcu/
> -F:   Documentation/devicetree/bindings/video/fsl,dcu.txt
> -F:   Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> +F:   Documentation/devicetree/bindings/display/fsl,dcu.txt
> +F:   Documentation/devicetree/bindings/display/panel/nec,nl4827hc19_05b.txt
> 
> DRM DRIVERS FOR FREESCALE IMX
> M:Philipp Zabel <p.za...@pengutronix.de>
> L:dri-de...@lists.freedesktop.org
> S:Maintained
> F:drivers/gpu/drm/imx/
> -F:   Documentation/devicetree/bindings/drm/imx/
> +F:   Documentation/devicetree/bindings/display/imx/
> 
> DRM DRIVERS FOR NVIDIA TEGRA
> M:Thierry Reding <thierry.red...@gmail.com>
> @@ -3630,7 +3630,7 @@ F:  drivers/gpu/drm/tegra/
> F:drivers/gpu/host1x/
> F:include/linux/host1x.h
> F:include/uapi/drm/tegra_drm.h
> -F:   Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
> +F:   
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> 
> DRM DRIVERS FOR RENESAS
> M:Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> @@ -3647,7 +3647,7 @@ M:  Mark Yao <mark@rock-chips.com>
> L:dri-de...@lists.freedesktop.org
> S:Maintained
> F:drivers/gpu/drm/rockchip/
> -F:   Documentation/devicetree/bindings/video/rockchip*
> +F:   Documentation/devicetree/bindings/display/rockchip*
> 
> DRM DRIVERS FOR STI
> M:Benjamin Gaignard <benjamin.gaign...@linaro.org>
> @@ -3656,7 +3656,7 @@ L:  dri-de...@lists.freedesktop.org
> T:git http://git.linaro.org/people/benjamin.gaignard/kernel.git
> S:Maintained
> F:drivers/gpu/drm/sti
> -F:   Documentation/devicetree/bindings/gpu/st,stih4xx.txt
> +F:   Documentation/devicetree/bindings/display/st,stih4xx.txt
> 
> DSBR100 USB FM RADIO DRIVER
> M:Alexey Klimov <klimov.li...@gmail.com>
> @@ -4342,7 +4342,6 @@ Q:  
> http://patchwork.kernel.org/project/linux-fbdev/list/
> T:git 
> git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git
> S:Maintained
> F:Documentation/fb/
> -F:   Documentation/devicetree/bindings/fb/
> F:drivers/video/
> F:include/video/
> F:include/linux/fb.h
> @@ -6855,6 +6854,7 @@ S:  Supported
> F:arch/metag/
> F:Documentation/metag/
> F:Documentation/devicetree/bindings/metag/
> +F:   Documentation/devicetree/bindings/interrupt-controller/img,*
> F:drivers/clocksource/metag_generic.c
> F:drivers/irqchip/irq-metag.c
> F:drivers/irqchip/irq-metag-ext.c
> @@ -9443,7 +9443,7 @@ SIMPLEFB FB DRIVER
> M:Hans de Goede <hdego...@redhat.com>
> L:linux-fb...@vger.kernel.org
> S:Maintained
> -F:   Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +F:   Documentation/devicetree/bindings/display/simple-framebuffer.txt
> F

Re: [PATCH] pinctrl: at91: fix null pointer dereference

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jul 13, 2015, at 9:00 PM, Ludovic Desroches  
> wrote:
> 
> On Mon, Jul 13, 2015 at 02:14:51PM +0800, Jean-Christophe PLAGNIOL-VILLARD 
> wrote:
>> 
>>> On Jul 3, 2015, at 12:06 AM, David Dueck  wrote:
>>> 
>>> Not all gpio banks are necessarily enabled, in the current code this can
>>> lead to null pointer dereferences.
>>> 
>>> [   51.13] Unable to handle kernel NULL pointer dereference at virtual 
>>> address 0058
>>> [   51.13] pgd = dee04000
>>> [   51.13] [0058] *pgd=3f66d831, *pte=, *ppte=
>>> [   51.14] Internal error: Oops: 17 [#1] ARM
>>> [   51.14] Modules linked in:
>>> [   51.14] CPU: 0 PID: 1664 Comm: cat Not tainted 4.1.1+ #6
>>> [   51.14] Hardware name: Atmel SAMA5
>>> [   51.14] task: df6dd880 ti: dec6 task.ti: dec6
>>> [   51.14] PC is at at91_pinconf_get+0xb4/0x200
>>> [   51.14] LR is at at91_pinconf_get+0xb4/0x200
>>> [   51.14] pc : []lr : []psr: 600f0013
>>> sp : dec61e48  ip : 600f0013  fp : df522538
>>> [   51.14] r10: df52250c  r9 : 0058  r8 : 0068
>>> [   51.14] r7 :   r6 : df53c910  r5 :   r4 : dec61e7c
>>> [   51.14] r3 :   r2 : c06746d4  r1 :   r0 : 0003
>>> [   51.14] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
>>> user
>>> [   51.14] Control: 10c53c7d  Table: 3ee04059  DAC: 0015
>>> [   51.14] Process cat (pid: 1664, stack limit = 0xdec60208)
>>> [   51.14] Stack: (0xdec61e48 to 0xdec62000)
>>> [   51.14] 1e40:   0358  df522500 ded15f80 
>>> c05a9d08 ded15f80
>>> [   51.14] 1e60: 048c 0061 df522500 ded15f80 c05a9d08 c01e7304 
>>> ded15f80 
>>> [   51.14] 1e80: c01e6008 0060 048c c01e6034 c01e5f6c ded15f80 
>>> dec61ec0 
>>> [   51.14] 1ea0: 0002 ded6f280 dec61f80 0001 0001 c00ae0b8 
>>> b6e8 ded15fb0
>>> [   51.14] 1ec0:   df4bc974 0055 0800 ded6f280 
>>> b6e8 ded6f280
>>> [   51.14] 1ee0: ded6f280 0002 b6e8  0002 c0090dec 
>>> c0671e1c dec61fb0
>>> [   51.14] 1f00: b6f8b510 0001 4201 c000924c  0003 
>>> 0003 
>>> [   51.14] 1f20: df4bc940 00022000 0022 c066e188 b6e7f000 c00836f4 
>>> 000b6e7f ded6f280
>>> [   51.14] 1f40: ded6f280 b6e8 dec61f80 ded6f280 0002 c0091508 
>>>  0003
>>> [   51.14] 1f60: 00022000   ded6f280 ded6f280 0002 
>>> b6e8 c0091d9c
>>> [   51.14] 1f80:    0002 0002 b6e8 
>>> 0003 c000f124
>>> [   51.14] 1fa0: dec6 c000efa0 0002 0002 0003 b6e8 
>>> 0002 000271c4
>>> [   51.14] 1fc0: 0002 0002 b6e8 0003 7fffe000  
>>>  0002
>>> [   51.14] 1fe0:  bef50b64 00013835 b6f29c76 400f0030 0003 
>>>  
>>> [   51.14] [] (at91_pinconf_get) from [] 
>>> (at91_pinconf_dbg_show+0x18/0x2c0)
>>> [   51.14] [] (at91_pinconf_dbg_show) from [] 
>>> (pinconf_pins_show+0xc8/0xf8)
>>> [   51.14] [] (pinconf_pins_show) from [] 
>>> (seq_read+0x1a0/0x464)
>>> [   51.14] [] (seq_read) from [] 
>>> (__vfs_read+0x20/0xd0)
>>> [   51.14] [] (__vfs_read) from [] 
>>> (vfs_read+0x7c/0x108)
>>> [   51.14] [] (vfs_read) from [] 
>>> (SyS_read+0x40/0x94)
>>> [   51.14] [] (SyS_read) from [] 
>>> (ret_fast_syscall+0x0/0x3c)
>>> [   51.14] Code: eb010ec2 e30a0d08 e34c005a eb0ae5a7 (e5993000)
>>> [   51.15] ---[ end trace fb3c370da3ea4794 ]---
>>> 
>>> Signed-off-by: David Dueck 
>>> CC: Nicolas Ferre 
>>> CC: Alexandre Belloni 
>>> CC: Ludovic Desroches 
>>> CC: Boris Brezillon 
>>> CC: linux-arm-ker...@lists.infradead.org
>>> CC: linux-kernel@vger.kernel.org
>>> ---
>>> drivers/pinctrl/pinctrl-at91.c | 15 +++
>>> 1 file changed, 15 insertions(+)
>>> 
>>> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
>>> index a082447..2deb130 100644
>>> --- a/drivers/pinctrl/pinctrl-at91.c
>>> +++ b/drivers/pinctrl/pinctrl-at91.c
>>> @@ -320,6 +320,9 @@ static const s

Re: [PATCH] pinctrl: at91: fix null pointer dereference

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jul 3, 2015, at 12:06 AM, David Dueck  wrote:
> 
> Not all gpio banks are necessarily enabled, in the current code this can
> lead to null pointer dereferences.
> 
> [   51.13] Unable to handle kernel NULL pointer dereference at virtual 
> address 0058
> [   51.13] pgd = dee04000
> [   51.13] [0058] *pgd=3f66d831, *pte=, *ppte=
> [   51.14] Internal error: Oops: 17 [#1] ARM
> [   51.14] Modules linked in:
> [   51.14] CPU: 0 PID: 1664 Comm: cat Not tainted 4.1.1+ #6
> [   51.14] Hardware name: Atmel SAMA5
> [   51.14] task: df6dd880 ti: dec6 task.ti: dec6
> [   51.14] PC is at at91_pinconf_get+0xb4/0x200
> [   51.14] LR is at at91_pinconf_get+0xb4/0x200
> [   51.14] pc : []lr : []psr: 600f0013
> sp : dec61e48  ip : 600f0013  fp : df522538
> [   51.14] r10: df52250c  r9 : 0058  r8 : 0068
> [   51.14] r7 :   r6 : df53c910  r5 :   r4 : dec61e7c
> [   51.14] r3 :   r2 : c06746d4  r1 :   r0 : 0003
> [   51.14] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> user
> [   51.14] Control: 10c53c7d  Table: 3ee04059  DAC: 0015
> [   51.14] Process cat (pid: 1664, stack limit = 0xdec60208)
> [   51.14] Stack: (0xdec61e48 to 0xdec62000)
> [   51.14] 1e40:   0358  df522500 ded15f80 
> c05a9d08 ded15f80
> [   51.14] 1e60: 048c 0061 df522500 ded15f80 c05a9d08 c01e7304 
> ded15f80 
> [   51.14] 1e80: c01e6008 0060 048c c01e6034 c01e5f6c ded15f80 
> dec61ec0 
> [   51.14] 1ea0: 0002 ded6f280 dec61f80 0001 0001 c00ae0b8 
> b6e8 ded15fb0
> [   51.14] 1ec0:   df4bc974 0055 0800 ded6f280 
> b6e8 ded6f280
> [   51.14] 1ee0: ded6f280 0002 b6e8  0002 c0090dec 
> c0671e1c dec61fb0
> [   51.14] 1f00: b6f8b510 0001 4201 c000924c  0003 
> 0003 
> [   51.14] 1f20: df4bc940 00022000 0022 c066e188 b6e7f000 c00836f4 
> 000b6e7f ded6f280
> [   51.14] 1f40: ded6f280 b6e8 dec61f80 ded6f280 0002 c0091508 
>  0003
> [   51.14] 1f60: 00022000   ded6f280 ded6f280 0002 
> b6e8 c0091d9c
> [   51.14] 1f80:    0002 0002 b6e8 
> 0003 c000f124
> [   51.14] 1fa0: dec6 c000efa0 0002 0002 0003 b6e8 
> 0002 000271c4
> [   51.14] 1fc0: 0002 0002 b6e8 0003 7fffe000  
>  0002
> [   51.14] 1fe0:  bef50b64 00013835 b6f29c76 400f0030 0003 
>  
> [   51.14] [] (at91_pinconf_get) from [] 
> (at91_pinconf_dbg_show+0x18/0x2c0)
> [   51.14] [] (at91_pinconf_dbg_show) from [] 
> (pinconf_pins_show+0xc8/0xf8)
> [   51.14] [] (pinconf_pins_show) from [] 
> (seq_read+0x1a0/0x464)
> [   51.14] [] (seq_read) from [] 
> (__vfs_read+0x20/0xd0)
> [   51.14] [] (__vfs_read) from [] 
> (vfs_read+0x7c/0x108)
> [   51.14] [] (vfs_read) from [] (SyS_read+0x40/0x94)
> [   51.14] [] (SyS_read) from [] 
> (ret_fast_syscall+0x0/0x3c)
> [   51.14] Code: eb010ec2 e30a0d08 e34c005a eb0ae5a7 (e5993000)
> [   51.15] ---[ end trace fb3c370da3ea4794 ]---
> 
> Signed-off-by: David Dueck 
> CC: Nicolas Ferre 
> CC: Alexandre Belloni 
> CC: Ludovic Desroches 
> CC: Boris Brezillon 
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-kernel@vger.kernel.org
> ---
> drivers/pinctrl/pinctrl-at91.c | 15 +++
> 1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index a082447..2deb130 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -320,6 +320,9 @@ static const struct pinctrl_ops at91_pctrl_ops = {
> static void __iomem *pin_to_controller(struct at91_pinctrl *info,
>unsigned int bank)
> {
> + if (!gpio_chips[bank])
> + return NULL;

if the bank is not enabled you should never arrived here


> +
>   return gpio_chips[bank]->regbase;
> }
> 
> @@ -729,6 +732,10 @@ static int at91_pmx_set(struct pinctrl_dev *pctldev, 
> unsigned selector,
>   pin = _conf[i];
>   at91_pin_dbg(info->dev, pin);
>   pio = pin_to_controller(info, pin->bank);
> +
> + if (!pio)
> + continue;
> +

or here
>   mask = pin_to_mask(pin->pin);
>   at91_mux_disable_interrupt(pio, mask);
>   switch (pin->mux) {
> @@ -848,6 +855,10 @@ static int at91_pinconf_get(struct pinctrl_dev *pctldev,
>   *config = 0;
>   dev_dbg(info->dev, "%s:%d, pin_id=%d", __func__, __LINE__, pin_id);
>   pio = pin_to_controller(info, pin_to_bank(pin_id));
> +
> + if (!pio)
> + return -EINVAL;
> +
ditto
>   pin = pin_id % MAX_NB_GPIO_PER_BANK;
> 
>   if 

Re: [PATCH] pinctrl: at91: fix null pointer dereference

[Jean-Christophe PLAGNIOL-VILLARD]

 On Jul 3, 2015, at 12:06 AM, David Dueck davidcdu...@googlemail.com wrote:
 
 Not all gpio banks are necessarily enabled, in the current code this can
 lead to null pointer dereferences.
 
 [   51.13] Unable to handle kernel NULL pointer dereference at virtual 
 address 0058
 [   51.13] pgd = dee04000
 [   51.13] [0058] *pgd=3f66d831, *pte=, *ppte=
 [   51.14] Internal error: Oops: 17 [#1] ARM
 [   51.14] Modules linked in:
 [   51.14] CPU: 0 PID: 1664 Comm: cat Not tainted 4.1.1+ #6
 [   51.14] Hardware name: Atmel SAMA5
 [   51.14] task: df6dd880 ti: dec6 task.ti: dec6
 [   51.14] PC is at at91_pinconf_get+0xb4/0x200
 [   51.14] LR is at at91_pinconf_get+0xb4/0x200
 [   51.14] pc : [c01e71a0]lr : [c01e71a0]psr: 600f0013
 sp : dec61e48  ip : 600f0013  fp : df522538
 [   51.14] r10: df52250c  r9 : 0058  r8 : 0068
 [   51.14] r7 :   r6 : df53c910  r5 :   r4 : dec61e7c
 [   51.14] r3 :   r2 : c06746d4  r1 :   r0 : 0003
 [   51.14] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
 user
 [   51.14] Control: 10c53c7d  Table: 3ee04059  DAC: 0015
 [   51.14] Process cat (pid: 1664, stack limit = 0xdec60208)
 [   51.14] Stack: (0xdec61e48 to 0xdec62000)
 [   51.14] 1e40:   0358  df522500 ded15f80 
 c05a9d08 ded15f80
 [   51.14] 1e60: 048c 0061 df522500 ded15f80 c05a9d08 c01e7304 
 ded15f80 
 [   51.14] 1e80: c01e6008 0060 048c c01e6034 c01e5f6c ded15f80 
 dec61ec0 
 [   51.14] 1ea0: 0002 ded6f280 dec61f80 0001 0001 c00ae0b8 
 b6e8 ded15fb0
 [   51.14] 1ec0:   df4bc974 0055 0800 ded6f280 
 b6e8 ded6f280
 [   51.14] 1ee0: ded6f280 0002 b6e8  0002 c0090dec 
 c0671e1c dec61fb0
 [   51.14] 1f00: b6f8b510 0001 4201 c000924c  0003 
 0003 
 [   51.14] 1f20: df4bc940 00022000 0022 c066e188 b6e7f000 c00836f4 
 000b6e7f ded6f280
 [   51.14] 1f40: ded6f280 b6e8 dec61f80 ded6f280 0002 c0091508 
  0003
 [   51.14] 1f60: 00022000   ded6f280 ded6f280 0002 
 b6e8 c0091d9c
 [   51.14] 1f80:    0002 0002 b6e8 
 0003 c000f124
 [   51.14] 1fa0: dec6 c000efa0 0002 0002 0003 b6e8 
 0002 000271c4
 [   51.14] 1fc0: 0002 0002 b6e8 0003 7fffe000  
  0002
 [   51.14] 1fe0:  bef50b64 00013835 b6f29c76 400f0030 0003 
  
 [   51.14] [c01e71a0] (at91_pinconf_get) from [c01e7304] 
 (at91_pinconf_dbg_show+0x18/0x2c0)
 [   51.14] [c01e7304] (at91_pinconf_dbg_show) from [c01e6034] 
 (pinconf_pins_show+0xc8/0xf8)
 [   51.14] [c01e6034] (pinconf_pins_show) from [c00ae0b8] 
 (seq_read+0x1a0/0x464)
 [   51.14] [c00ae0b8] (seq_read) from [c0090dec] 
 (__vfs_read+0x20/0xd0)
 [   51.14] [c0090dec] (__vfs_read) from [c0091508] 
 (vfs_read+0x7c/0x108)
 [   51.14] [c0091508] (vfs_read) from [c0091d9c] (SyS_read+0x40/0x94)
 [   51.14] [c0091d9c] (SyS_read) from [c000efa0] 
 (ret_fast_syscall+0x0/0x3c)
 [   51.14] Code: eb010ec2 e30a0d08 e34c005a eb0ae5a7 (e5993000)
 [   51.15] ---[ end trace fb3c370da3ea4794 ]---
 
 Signed-off-by: David Dueck davidcdu...@googlemail.com
 CC: Nicolas Ferre nicolas.fe...@atmel.com
 CC: Alexandre Belloni alexandre.bell...@free-electrons.com
 CC: Ludovic Desroches ludovic.desroc...@atmel.com
 CC: Boris Brezillon boris.brezil...@free-electrons.com
 CC: linux-arm-ker...@lists.infradead.org
 CC: linux-kernel@vger.kernel.org
 ---
 drivers/pinctrl/pinctrl-at91.c | 15 +++
 1 file changed, 15 insertions(+)
 
 diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
 index a082447..2deb130 100644
 --- a/drivers/pinctrl/pinctrl-at91.c
 +++ b/drivers/pinctrl/pinctrl-at91.c
 @@ -320,6 +320,9 @@ static const struct pinctrl_ops at91_pctrl_ops = {
 static void __iomem *pin_to_controller(struct at91_pinctrl *info,
unsigned int bank)
 {
 + if (!gpio_chips[bank])
 + return NULL;

if the bank is not enabled you should never arrived here


 +
   return gpio_chips[bank]-regbase;
 }
 
 @@ -729,6 +732,10 @@ static int at91_pmx_set(struct pinctrl_dev *pctldev, 
 unsigned selector,
   pin = pins_conf[i];
   at91_pin_dbg(info-dev, pin);
   pio = pin_to_controller(info, pin-bank);
 +
 + if (!pio)
 + continue;
 +

or here
   mask = pin_to_mask(pin-pin);
   at91_mux_disable_interrupt(pio, mask);
   switch (pin-mux) {
 @@ -848,6 +855,10 @@ static int at91_pinconf_get(struct pinctrl_dev *pctldev,
   *config = 0;
   dev_dbg(info-dev, %s:%d, pin_id=%d, __func__, __LINE__, pin_id);
  

Re: [PATCH] pinctrl: at91: fix null pointer dereference

[Jean-Christophe PLAGNIOL-VILLARD]

 On Jul 13, 2015, at 9:00 PM, Ludovic Desroches ludovic.desroc...@atmel.com 
 wrote:
 
 On Mon, Jul 13, 2015 at 02:14:51PM +0800, Jean-Christophe PLAGNIOL-VILLARD 
 wrote:
 
 On Jul 3, 2015, at 12:06 AM, David Dueck davidcdu...@googlemail.com wrote:
 
 Not all gpio banks are necessarily enabled, in the current code this can
 lead to null pointer dereferences.
 
 [   51.13] Unable to handle kernel NULL pointer dereference at virtual 
 address 0058
 [   51.13] pgd = dee04000
 [   51.13] [0058] *pgd=3f66d831, *pte=, *ppte=
 [   51.14] Internal error: Oops: 17 [#1] ARM
 [   51.14] Modules linked in:
 [   51.14] CPU: 0 PID: 1664 Comm: cat Not tainted 4.1.1+ #6
 [   51.14] Hardware name: Atmel SAMA5
 [   51.14] task: df6dd880 ti: dec6 task.ti: dec6
 [   51.14] PC is at at91_pinconf_get+0xb4/0x200
 [   51.14] LR is at at91_pinconf_get+0xb4/0x200
 [   51.14] pc : [c01e71a0]lr : [c01e71a0]psr: 600f0013
 sp : dec61e48  ip : 600f0013  fp : df522538
 [   51.14] r10: df52250c  r9 : 0058  r8 : 0068
 [   51.14] r7 :   r6 : df53c910  r5 :   r4 : dec61e7c
 [   51.14] r3 :   r2 : c06746d4  r1 :   r0 : 0003
 [   51.14] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
 user
 [   51.14] Control: 10c53c7d  Table: 3ee04059  DAC: 0015
 [   51.14] Process cat (pid: 1664, stack limit = 0xdec60208)
 [   51.14] Stack: (0xdec61e48 to 0xdec62000)
 [   51.14] 1e40:   0358  df522500 ded15f80 
 c05a9d08 ded15f80
 [   51.14] 1e60: 048c 0061 df522500 ded15f80 c05a9d08 c01e7304 
 ded15f80 
 [   51.14] 1e80: c01e6008 0060 048c c01e6034 c01e5f6c ded15f80 
 dec61ec0 
 [   51.14] 1ea0: 0002 ded6f280 dec61f80 0001 0001 c00ae0b8 
 b6e8 ded15fb0
 [   51.14] 1ec0:   df4bc974 0055 0800 ded6f280 
 b6e8 ded6f280
 [   51.14] 1ee0: ded6f280 0002 b6e8  0002 c0090dec 
 c0671e1c dec61fb0
 [   51.14] 1f00: b6f8b510 0001 4201 c000924c  0003 
 0003 
 [   51.14] 1f20: df4bc940 00022000 0022 c066e188 b6e7f000 c00836f4 
 000b6e7f ded6f280
 [   51.14] 1f40: ded6f280 b6e8 dec61f80 ded6f280 0002 c0091508 
  0003
 [   51.14] 1f60: 00022000   ded6f280 ded6f280 0002 
 b6e8 c0091d9c
 [   51.14] 1f80:    0002 0002 b6e8 
 0003 c000f124
 [   51.14] 1fa0: dec6 c000efa0 0002 0002 0003 b6e8 
 0002 000271c4
 [   51.14] 1fc0: 0002 0002 b6e8 0003 7fffe000  
  0002
 [   51.14] 1fe0:  bef50b64 00013835 b6f29c76 400f0030 0003 
  
 [   51.14] [c01e71a0] (at91_pinconf_get) from [c01e7304] 
 (at91_pinconf_dbg_show+0x18/0x2c0)
 [   51.14] [c01e7304] (at91_pinconf_dbg_show) from [c01e6034] 
 (pinconf_pins_show+0xc8/0xf8)
 [   51.14] [c01e6034] (pinconf_pins_show) from [c00ae0b8] 
 (seq_read+0x1a0/0x464)
 [   51.14] [c00ae0b8] (seq_read) from [c0090dec] 
 (__vfs_read+0x20/0xd0)
 [   51.14] [c0090dec] (__vfs_read) from [c0091508] 
 (vfs_read+0x7c/0x108)
 [   51.14] [c0091508] (vfs_read) from [c0091d9c] 
 (SyS_read+0x40/0x94)
 [   51.14] [c0091d9c] (SyS_read) from [c000efa0] 
 (ret_fast_syscall+0x0/0x3c)
 [   51.14] Code: eb010ec2 e30a0d08 e34c005a eb0ae5a7 (e5993000)
 [   51.15] ---[ end trace fb3c370da3ea4794 ]---
 
 Signed-off-by: David Dueck davidcdu...@googlemail.com
 CC: Nicolas Ferre nicolas.fe...@atmel.com
 CC: Alexandre Belloni alexandre.bell...@free-electrons.com
 CC: Ludovic Desroches ludovic.desroc...@atmel.com
 CC: Boris Brezillon boris.brezil...@free-electrons.com
 CC: linux-arm-ker...@lists.infradead.org
 CC: linux-kernel@vger.kernel.org
 ---
 drivers/pinctrl/pinctrl-at91.c | 15 +++
 1 file changed, 15 insertions(+)
 
 diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
 index a082447..2deb130 100644
 --- a/drivers/pinctrl/pinctrl-at91.c
 +++ b/drivers/pinctrl/pinctrl-at91.c
 @@ -320,6 +320,9 @@ static const struct pinctrl_ops at91_pctrl_ops = {
 static void __iomem *pin_to_controller(struct at91_pinctrl *info,
  unsigned int bank)
 {
 +   if (!gpio_chips[bank])
 +   return NULL;
 
 if the bank is not enabled you should never arrived here
 
 But you can because in pinconf_pins_show you have:
 for (i = 0; i  pctldev-desc-npins; i++)
 
 And in the pinctrl-at91 driver you have:
 at91_pinctrl_desc.npins = gpio_banks * MAX_NB_GPIO_PER_BANK;
 
 
 
 +
 return gpio_chips[bank]-regbase;
 }
 
 @@ -729,6 +732,10 @@ static int at91_pmx_set(struct pinctrl_dev *pctldev, 
 unsigned selector,
 pin = pins_conf[i];
 at91_pin_dbg(info-dev, pin);
 pio = pin_to_controller(info, pin-bank

Re: Device Tree Blob (DTB) licence

[Jean-Christophe PLAGNIOL-VILLARD]

> On May 29, 2015, at 11:10 PM, Enrico Weigelt, metux IT consult 
>  wrote:
> 
> Am 29.05.2015 um 05:31 schrieb Rob Landley:
> 
> >> What's the big deal with having DTS/DTB under GPL ?
>> 
>> One problem is that there's no such thing as "The GPL" anymore.
> 
> There are different versions. The kernel source clearly states
> GPLv2 (I, personally, would prefer v3 to prevent Tivoization)
> 
>> The Linux kernel and Samba can't share code anymore,
> 
> Do they really need to ?
> One could ask, whether smb support should belong into the kernel
> at all (instead of, eg., going via FUSE or 9P), but that's an
> entirely different discussion.
> 
>> even though they implement two ends of the same protocol, thanks to GPLv3.
> 
> Samba folks made the decision to prevent Tivoization of their code.
> I fully agree with that decision, and I wish the same for the kernel.
and other think the GPLv3 is a mistake and is not commercially usable

It’s call freedom.
> 
>> This seems to have badly damaged the long term viability of GPLv2,
>> which used to be synonymous with copyleft (category killer license)
>> and acted as a universal receiver because it was a terminal node in a
>> directed graph of license convertibility reducing most licensing
>> decisions to a simple binary "is it GPL compatible or not", which
>> greatly appealed to developers who aren't lawyers and don't want to
>> be.
> 
> Well, such things happen, if people have different views. In that case
> those who want to prevent Tivoization on the one and those who wanna
> allow it on the other side.
> 
> I rerely have the need to really copy-and-paste code from one project
> to another. When patching existing ones, I just stick to the upstream's
> license. And when starting new FOSS projects, I clearly choose (L)GPLv3,
> because I'm strictly against Tivoization.
> 

This is your choice, this remove freedom too GPLv3.

>> But now a project that's "GPLv2 or later" can't accept code from
>> _either_ the kernel or samba (neither provides the implicit dual
>> license they need).
> 
> Well, that's a decision of the individual projects - everybody has
> to live with his/her own decisions.
> 
>> Projects like QEMU are stuck between wanting to
>> turn kernel drivers inside out to make device emulations (GPLv2 code)
>> and grab processor definitions from gcc or binutils (GPLv3 code) and
>> one project cannot accept both because GPL + GPL is a license
>> conflict.
> 
> Seems to be a rare case to me. In general, I'd suggest making things
> used by several distinct projects into their own distinct entities.
> 
> Note: the GPL's viral effect doesn't depend on whether the sources
> are collected in one big repo, but on what is compiled-/linked-into
> where.
> 
>> Of course "BSD-like" would be public domain except for 20 years of
>> FUD, so they're mostly choosing one of the dozens of public domain
>> equivalent licenses like the various BSDs and MIT and ISC and Apache
>> that are equivalent except for "copy this license text exactly"
>> clauses that cause endless license bloat over time.
> 
> It's not entirely FUD. The questions is NOT whether the original open
> code will be wiped out of the net or people simply dont work on it
> anymore. The main question here is, whether foss developers (often
> working for free) want to help people producing non-free stuff. BSD
> like to allow that, FSF folks dont. They just have different views on
> that matter. IMHO, BSD folks are just interested in getting back
> contributions, while FSF folks also have a broader political agenda. I,
> personally, share that agenda (even more: I strongly believe that
> software patents should be eradicated).
> 
>> Personally I prefer public domain equivalent licenses like CC0 or
>> unlicense.org or my own "zero clause bsd", which DON'T require you to
>> copy specific license text verbatim into derived works.
> 
> Well, I have an fundamentally different oppinion on that. If I publish
> my code for free, I dont want assist anybody in producing non-free
> stuff. (free like freedom, not free beer)
> 
>> Most of this can be laid at the door of GPLv3.
> 
> Because many folks don't wanna fight against Tivoization.
> I'll have to accept that, but I don't need to coorporate.
> 
> > Android's "no gpl in userspace" policy is why they ripped out bluez
> > and wrote a replacement bluedroid from scratch.
> 
> The really interesting question is: why do they have that policy ?
> Maybe because they aren't interested in *free* (as freedom) software,
> but just open source.
> 
> Otherwise they'd have an strict policy of nothing proprietary in
> kernel space.
> 
>> The bluez developers keep going "if we just
>> improve the code enough people will get over the license" (no really:
>> https://lwn.net/Articles/597293/) but their FAQ literally doesn't
>> specify _which_ GPL they're under: http://www.bluez.org/faq/common/
>> (Is it the one you can't use with kernel code, the one you can't
>> combine with samba code, or the 

Re: Device Tree Blob (DTB) licence

[Jean-Christophe PLAGNIOL-VILLARD]

 On May 29, 2015, at 11:10 PM, Enrico Weigelt, metux IT consult 
 weig...@melag.de wrote:
 
 Am 29.05.2015 um 05:31 schrieb Rob Landley:
 
  What's the big deal with having DTS/DTB under GPL ?
 
 One problem is that there's no such thing as The GPL anymore.
 
 There are different versions. The kernel source clearly states
 GPLv2 (I, personally, would prefer v3 to prevent Tivoization)
 
 The Linux kernel and Samba can't share code anymore,
 
 Do they really need to ?
 One could ask, whether smb support should belong into the kernel
 at all (instead of, eg., going via FUSE or 9P), but that's an
 entirely different discussion.
 
 even though they implement two ends of the same protocol, thanks to GPLv3.
 
 Samba folks made the decision to prevent Tivoization of their code.
 I fully agree with that decision, and I wish the same for the kernel.
and other think the GPLv3 is a mistake and is not commercially usable

It’s call freedom.
 
 This seems to have badly damaged the long term viability of GPLv2,
 which used to be synonymous with copyleft (category killer license)
 and acted as a universal receiver because it was a terminal node in a
 directed graph of license convertibility reducing most licensing
 decisions to a simple binary is it GPL compatible or not, which
 greatly appealed to developers who aren't lawyers and don't want to
 be.
 
 Well, such things happen, if people have different views. In that case
 those who want to prevent Tivoization on the one and those who wanna
 allow it on the other side.
 
 I rerely have the need to really copy-and-paste code from one project
 to another. When patching existing ones, I just stick to the upstream's
 license. And when starting new FOSS projects, I clearly choose (L)GPLv3,
 because I'm strictly against Tivoization.
 

This is your choice, this remove freedom too GPLv3.

 But now a project that's GPLv2 or later can't accept code from
 _either_ the kernel or samba (neither provides the implicit dual
 license they need).
 
 Well, that's a decision of the individual projects - everybody has
 to live with his/her own decisions.
 
 Projects like QEMU are stuck between wanting to
 turn kernel drivers inside out to make device emulations (GPLv2 code)
 and grab processor definitions from gcc or binutils (GPLv3 code) and
 one project cannot accept both because GPL + GPL is a license
 conflict.
 
 Seems to be a rare case to me. In general, I'd suggest making things
 used by several distinct projects into their own distinct entities.
 
 Note: the GPL's viral effect doesn't depend on whether the sources
 are collected in one big repo, but on what is compiled-/linked-into
 where.
 
 Of course BSD-like would be public domain except for 20 years of
 FUD, so they're mostly choosing one of the dozens of public domain
 equivalent licenses like the various BSDs and MIT and ISC and Apache
 that are equivalent except for copy this license text exactly
 clauses that cause endless license bloat over time.
 
 It's not entirely FUD. The questions is NOT whether the original open
 code will be wiped out of the net or people simply dont work on it
 anymore. The main question here is, whether foss developers (often
 working for free) want to help people producing non-free stuff. BSD
 like to allow that, FSF folks dont. They just have different views on
 that matter. IMHO, BSD folks are just interested in getting back
 contributions, while FSF folks also have a broader political agenda. I,
 personally, share that agenda (even more: I strongly believe that
 software patents should be eradicated).
 
 Personally I prefer public domain equivalent licenses like CC0 or
 unlicense.org or my own zero clause bsd, which DON'T require you to
 copy specific license text verbatim into derived works.
 
 Well, I have an fundamentally different oppinion on that. If I publish
 my code for free, I dont want assist anybody in producing non-free
 stuff. (free like freedom, not free beer)
 
 Most of this can be laid at the door of GPLv3.
 
 Because many folks don't wanna fight against Tivoization.
 I'll have to accept that, but I don't need to coorporate.
 
  Android's no gpl in userspace policy is why they ripped out bluez
  and wrote a replacement bluedroid from scratch.
 
 The really interesting question is: why do they have that policy ?
 Maybe because they aren't interested in *free* (as freedom) software,
 but just open source.
 
 Otherwise they'd have an strict policy of nothing proprietary in
 kernel space.
 
 The bluez developers keep going if we just
 improve the code enough people will get over the license (no really:
 https://lwn.net/Articles/597293/) but their FAQ literally doesn't
 specify _which_ GPL they're under: http://www.bluez.org/faq/common/
 (Is it the one you can't use with kernel code, the one you can't
 combine with samba code, or the or-later version that can't accept
 code from either source into its next release?
 
 Why would one want to mix bluez code with the kernel or samba ?
 

Re: [PATCH 35/35 linux-next] pinctrl: constify of_device_id array

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:59 Mon 16 Mar , Fabian Frederick wrote:
> of_device_id is always used as const.
> (See driver.of_match_table and open firmware functions)
> 
> Signed-off-by: Fabian Frederick 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 

Best Regards,
J.
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm2835.c   | 2 +-
>  drivers/pinctrl/mediatek/pinctrl-mt8135.c   | 2 +-
>  drivers/pinctrl/mediatek/pinctrl-mt8173.c   | 2 +-
>  drivers/pinctrl/mvebu/pinctrl-armada-370.c  | 2 +-
>  drivers/pinctrl/mvebu/pinctrl-armada-375.c  | 2 +-
>  drivers/pinctrl/mvebu/pinctrl-armada-38x.c  | 2 +-
>  drivers/pinctrl/mvebu/pinctrl-armada-39x.c  | 2 +-
>  drivers/pinctrl/mvebu/pinctrl-armada-xp.c   | 2 +-
>  drivers/pinctrl/mvebu/pinctrl-kirkwood.c| 2 +-
>  drivers/pinctrl/mvebu/pinctrl-orion.c   | 2 +-
>  drivers/pinctrl/pinctrl-as3722.c| 2 +-
>  drivers/pinctrl/pinctrl-at91.c  | 4 ++--
>  drivers/pinctrl/pinctrl-palmas.c| 2 +-
>  drivers/pinctrl/pinctrl-single.c| 4 ++--
>  drivers/pinctrl/pinctrl-st.c| 2 +-
>  drivers/pinctrl/pinctrl-tz1090-pdc.c| 2 +-
>  drivers/pinctrl/pinctrl-tz1090.c| 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c   | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun5i-a10s.c  | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun5i-a13.c   | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c   | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun6i-a31s.c  | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c   | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c   | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c   | 2 +-
>  drivers/pinctrl/vt8500/pinctrl-vt8500.c | 2 +-
>  drivers/pinctrl/vt8500/pinctrl-wm8505.c | 2 +-
>  drivers/pinctrl/vt8500/pinctrl-wm8650.c | 2 +-
>  drivers/pinctrl/vt8500/pinctrl-wm8750.c | 2 +-
>  drivers/pinctrl/vt8500/pinctrl-wm8850.c | 2 +-
>  32 files changed, 34 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
> b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 9aa8a3f..4d08b85 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -1051,7 +1051,7 @@ static int bcm2835_pinctrl_remove(struct 
> platform_device *pdev)
>   return 0;
>  }
>  
> -static struct of_device_id bcm2835_pinctrl_match[] = {
> +static const struct of_device_id bcm2835_pinctrl_match[] = {
>   { .compatible = "brcm,bcm2835-gpio" },
>   {}
>  };
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8135.c 
> b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
> index 1296d6d..82c4af4 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt8135.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
> @@ -347,7 +347,7 @@ static int mt8135_pinctrl_probe(struct platform_device 
> *pdev)
>   return mtk_pctrl_init(pdev, _pinctrl_data);
>  }
>  
> -static struct of_device_id mt8135_pctrl_match[] = {
> +static const struct of_device_id mt8135_pctrl_match[] = {
>   {
>   .compatible = "mediatek,mt8135-pinctrl",
>   }, {
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8173.c 
> b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
> index f07cafb..594f7b5 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
> @@ -427,7 +427,7 @@ static int mt8173_pinctrl_probe(struct platform_device 
> *pdev)
>   return mtk_pctrl_init(pdev, _pinctrl_data);
>  }
>  
> -static struct of_device_id mt8173_pctrl_match[] = {
> +static const struct of_device_id mt8173_pctrl_match[] = {
>   {
>   .compatible = "mediatek,mt8173-pinctrl",
>   }, {
> diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-370.c 
> b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
> index c4f51d0..42f930f 100644
> --- a/drivers/pinctrl/mvebu/pinctrl-armada-370.c
> +++ b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
> @@ -379,7 +379,7 @@ static struct mvebu_mpp_mode mv88f6710_mpp_modes[] = {
>  
>  static struct mvebu_pinctrl_soc_info armada_370_pinctrl_info;
>  
> -static struct of_device_id armada_370_pinctrl_of_match[] = {
> +static const struct of_device_id armada_370_pinctrl_of_match[] = {
>   { .compatible = "marvell,mv88f6710-pinctrl" },
>   { },
>  };
> diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-375.c 
> b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
> index cd7c8f5..ca1e757 100644
> --- a/drivers/pinctrl/mvebu/pinctrl-armada-375.c
> +++ b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
> @@ -399,7 +399,7 @@ static struct mvebu_mpp_mode mv88f6720_mpp_modes[] = {

Re: [PATCH 35/35 linux-next] pinctrl: constify of_device_id array

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:59 Mon 16 Mar , Fabian Frederick wrote:
 of_device_id is always used as const.
 (See driver.of_match_table and open firmware functions)
 
 Signed-off-by: Fabian Frederick f...@skynet.be
Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com

Best Regards,
J.
 ---
  drivers/pinctrl/bcm/pinctrl-bcm2835.c   | 2 +-
  drivers/pinctrl/mediatek/pinctrl-mt8135.c   | 2 +-
  drivers/pinctrl/mediatek/pinctrl-mt8173.c   | 2 +-
  drivers/pinctrl/mvebu/pinctrl-armada-370.c  | 2 +-
  drivers/pinctrl/mvebu/pinctrl-armada-375.c  | 2 +-
  drivers/pinctrl/mvebu/pinctrl-armada-38x.c  | 2 +-
  drivers/pinctrl/mvebu/pinctrl-armada-39x.c  | 2 +-
  drivers/pinctrl/mvebu/pinctrl-armada-xp.c   | 2 +-
  drivers/pinctrl/mvebu/pinctrl-kirkwood.c| 2 +-
  drivers/pinctrl/mvebu/pinctrl-orion.c   | 2 +-
  drivers/pinctrl/pinctrl-as3722.c| 2 +-
  drivers/pinctrl/pinctrl-at91.c  | 4 ++--
  drivers/pinctrl/pinctrl-palmas.c| 2 +-
  drivers/pinctrl/pinctrl-single.c| 4 ++--
  drivers/pinctrl/pinctrl-st.c| 2 +-
  drivers/pinctrl/pinctrl-tz1090-pdc.c| 2 +-
  drivers/pinctrl/pinctrl-tz1090.c| 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c   | 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun5i-a10s.c  | 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun5i-a13.c   | 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c | 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c   | 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun6i-a31s.c  | 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c   | 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c | 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c   | 2 +-
  drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c   | 2 +-
  drivers/pinctrl/vt8500/pinctrl-vt8500.c | 2 +-
  drivers/pinctrl/vt8500/pinctrl-wm8505.c | 2 +-
  drivers/pinctrl/vt8500/pinctrl-wm8650.c | 2 +-
  drivers/pinctrl/vt8500/pinctrl-wm8750.c | 2 +-
  drivers/pinctrl/vt8500/pinctrl-wm8850.c | 2 +-
  32 files changed, 34 insertions(+), 34 deletions(-)
 
 diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
 b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
 index 9aa8a3f..4d08b85 100644
 --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
 +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
 @@ -1051,7 +1051,7 @@ static int bcm2835_pinctrl_remove(struct 
 platform_device *pdev)
   return 0;
  }
  
 -static struct of_device_id bcm2835_pinctrl_match[] = {
 +static const struct of_device_id bcm2835_pinctrl_match[] = {
   { .compatible = brcm,bcm2835-gpio },
   {}
  };
 diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8135.c 
 b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
 index 1296d6d..82c4af4 100644
 --- a/drivers/pinctrl/mediatek/pinctrl-mt8135.c
 +++ b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
 @@ -347,7 +347,7 @@ static int mt8135_pinctrl_probe(struct platform_device 
 *pdev)
   return mtk_pctrl_init(pdev, mt8135_pinctrl_data);
  }
  
 -static struct of_device_id mt8135_pctrl_match[] = {
 +static const struct of_device_id mt8135_pctrl_match[] = {
   {
   .compatible = mediatek,mt8135-pinctrl,
   }, {
 diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8173.c 
 b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
 index f07cafb..594f7b5 100644
 --- a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
 +++ b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
 @@ -427,7 +427,7 @@ static int mt8173_pinctrl_probe(struct platform_device 
 *pdev)
   return mtk_pctrl_init(pdev, mt8173_pinctrl_data);
  }
  
 -static struct of_device_id mt8173_pctrl_match[] = {
 +static const struct of_device_id mt8173_pctrl_match[] = {
   {
   .compatible = mediatek,mt8173-pinctrl,
   }, {
 diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-370.c 
 b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
 index c4f51d0..42f930f 100644
 --- a/drivers/pinctrl/mvebu/pinctrl-armada-370.c
 +++ b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
 @@ -379,7 +379,7 @@ static struct mvebu_mpp_mode mv88f6710_mpp_modes[] = {
  
  static struct mvebu_pinctrl_soc_info armada_370_pinctrl_info;
  
 -static struct of_device_id armada_370_pinctrl_of_match[] = {
 +static const struct of_device_id armada_370_pinctrl_of_match[] = {
   { .compatible = marvell,mv88f6710-pinctrl },
   { },
  };
 diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-375.c 
 b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
 index cd7c8f5..ca1e757 100644
 --- a/drivers/pinctrl/mvebu/pinctrl-armada-375.c
 +++ b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
 @@ -399,7 +399,7 @@ static struct mvebu_mpp_mode mv88f6720_mpp_modes[] = {
  
  static struct mvebu_pinctrl_soc_info armada_375_pinctrl_info;
  
 -static struct of_device_id armada_375_pinctrl_of_match[] = {
 +static const struct of_device_id armada_375_pinctrl_of_match[] = {
   { .compatible = marvell,mv88f6720-pinctrl },
   { },
  };
 diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-38x.c 
 b/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
 index 7302f66..83bbcc7 100644
 --- a/drivers

Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods

[Jean-Christophe PLAGNIOL-VILLARD]

On 19:23 Sun 08 Feb , Boris Brezillon wrote:
> The gpiochip_lock_as_irq call can fail and return an error, while the
> irq_startup is not expected to fail (returns an unsigned int which is not
> checked by irq core code).
> 
> irq_request/release_resources functions have been created to address this
> problem.
> 
> Move gpiochip_lock/unlock_as_irq calls into
> irq_request/release_resources functions to prevent using a gpio as an irq
> if the gpiochip_lock_as_irq call failed.
> 
> Signed-off-by: Boris Brezillon 
Linus

Acked-by: Jean-Christophe PLAGNIOL-VILLARD 

Best Regards,
J.
> ---
>  drivers/pinctrl/pinctrl-at91.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index f4cd0b9..a481406 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
>   /* the interrupt is already cleared before by reading ISR */
>  }
>  
> -static unsigned int gpio_irq_startup(struct irq_data *d)
> +static int gpio_irq_request_res(struct irq_data *d)
>  {
>   struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>   unsignedpin = d->hwirq;
>   int ret;
>  
>   ret = gpiochip_lock_as_irq(_gpio->chip, pin);
> - if (ret) {
> + if (ret)
>   dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
>   d->hwirq);
> - return ret;
> - }
> - gpio_irq_unmask(d);
> - return 0;
> +
> + return ret;
>  }
>  
> -static void gpio_irq_shutdown(struct irq_data *d)
> +static void gpio_irq_release_res(struct irq_data *d)
>  {
>   struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>   unsignedpin = d->hwirq;
>  
> - gpio_irq_mask(d);
>   gpiochip_unlock_as_irq(_gpio->chip, pin);
>  }
>  
> @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
>  static struct irq_chip gpio_irqchip = {
>   .name   = "GPIO",
>   .irq_ack= gpio_irq_ack,
> - .irq_startup= gpio_irq_startup,
> - .irq_shutdown   = gpio_irq_shutdown,
> + .irq_request_resources = gpio_irq_request_res,
> + .irq_release_resources = gpio_irq_release_res,
>   .irq_disable= gpio_irq_mask,
>   .irq_mask   = gpio_irq_mask,
>   .irq_unmask = gpio_irq_unmask,
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91/dt: add uart0 to sama5d3 DT

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:26 Wed 04 Mar , Nicolas Ferre wrote:
> Signed-off-by: Nicolas Ferre 

please keep in Cc for at91 related work

Best Regards,
J.
> ---
>  arch/arm/boot/dts/sama5d3.dtsi | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index e30fee2edd55..def05e20e9d6 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -26,6 +26,7 @@
>   serial2 = 
>   serial3 = 
>   serial4 = 
> + serial5 = 
>   gpio0 = 
>   gpio1 = 
>   gpio2 = 
> @@ -206,6 +207,17 @@
>   status = "disabled";
>   };
>  
> + uart0: serial@f0024000 {
> + compatible = "atmel,at91sam9260-usart";
> + reg = <0xf0024000 0x100>;
> + interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart0>;
> + clocks = <_clk>;
> + clock-names = "usart";
> + status = "disabled";
> + };
> +
>   pwm0: pwm@f002c000 {
>   compatible = "atmel,sama5d3-pwm";
>   reg = <0xf002c000 0x300>;
> @@ -764,6 +776,14 @@
>   };
>   };
>  
> + uart0 {
> + pinctrl_uart0: uart0-0 {
> + atmel,pins =
> +  AT91_PERIPH_A AT91_PINCTRL_NONE   /* conflicts with PWMFI2, ISI_D8 */
> +  AT91_PIOC 30 
> AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;  /* conflicts with ISI_PCK */
> + };
> + };
> +
>   usart0 {
>   pinctrl_usart0: usart0-0 {
>   atmel,pins =
> @@ -1098,6 +1118,12 @@
>   atmel,clk-output-range = <0 
> 6600>;
>   };
>  
> + uart0_clk: uart0_clk {
> + #clock-cells = <0>;
> + reg = <16>;
> + atmel,clk-output-range = <0 
> 6600>;
> + };
> +
>   twi0_clk: twi0_clk {
>   reg = <18>;
>   #clock-cells = <0>;
> -- 
> 2.1.3
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91/dt: add uart0 to sama5d3 DT

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:26 Wed 04 Mar , Nicolas Ferre wrote:
 Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com

please keep in Cc for at91 related work

Best Regards,
J.
 ---
  arch/arm/boot/dts/sama5d3.dtsi | 26 ++
  1 file changed, 26 insertions(+)
 
 diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
 index e30fee2edd55..def05e20e9d6 100644
 --- a/arch/arm/boot/dts/sama5d3.dtsi
 +++ b/arch/arm/boot/dts/sama5d3.dtsi
 @@ -26,6 +26,7 @@
   serial2 = usart1;
   serial3 = usart2;
   serial4 = usart3;
 + serial5 = uart0;
   gpio0 = pioA;
   gpio1 = pioB;
   gpio2 = pioC;
 @@ -206,6 +207,17 @@
   status = disabled;
   };
  
 + uart0: serial@f0024000 {
 + compatible = atmel,at91sam9260-usart;
 + reg = 0xf0024000 0x100;
 + interrupts = 16 IRQ_TYPE_LEVEL_HIGH 5;
 + pinctrl-names = default;
 + pinctrl-0 = pinctrl_uart0;
 + clocks = uart0_clk;
 + clock-names = usart;
 + status = disabled;
 + };
 +
   pwm0: pwm@f002c000 {
   compatible = atmel,sama5d3-pwm;
   reg = 0xf002c000 0x300;
 @@ -764,6 +776,14 @@
   };
   };
  
 + uart0 {
 + pinctrl_uart0: uart0-0 {
 + atmel,pins =
 + AT91_PIOC 29 
 AT91_PERIPH_A AT91_PINCTRL_NONE   /* conflicts with PWMFI2, ISI_D8 */
 +  AT91_PIOC 30 
 AT91_PERIPH_A AT91_PINCTRL_PULL_UP;  /* conflicts with ISI_PCK */
 + };
 + };
 +
   usart0 {
   pinctrl_usart0: usart0-0 {
   atmel,pins =
 @@ -1098,6 +1118,12 @@
   atmel,clk-output-range = 0 
 6600;
   };
  
 + uart0_clk: uart0_clk {
 + #clock-cells = 0;
 + reg = 16;
 + atmel,clk-output-range = 0 
 6600;
 + };
 +
   twi0_clk: twi0_clk {
   reg = 18;
   #clock-cells = 0;
 -- 
 2.1.3
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods

[Jean-Christophe PLAGNIOL-VILLARD]

On 19:23 Sun 08 Feb , Boris Brezillon wrote:
 The gpiochip_lock_as_irq call can fail and return an error, while the
 irq_startup is not expected to fail (returns an unsigned int which is not
 checked by irq core code).
 
 irq_request/release_resources functions have been created to address this
 problem.
 
 Move gpiochip_lock/unlock_as_irq calls into
 irq_request/release_resources functions to prevent using a gpio as an irq
 if the gpiochip_lock_as_irq call failed.
 
 Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Linus

Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com

Best Regards,
J.
 ---
  drivers/pinctrl/pinctrl-at91.c | 17 +++--
  1 file changed, 7 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
 index f4cd0b9..a481406 100644
 --- a/drivers/pinctrl/pinctrl-at91.c
 +++ b/drivers/pinctrl/pinctrl-at91.c
 @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
   /* the interrupt is already cleared before by reading ISR */
  }
  
 -static unsigned int gpio_irq_startup(struct irq_data *d)
 +static int gpio_irq_request_res(struct irq_data *d)
  {
   struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
   unsignedpin = d-hwirq;
   int ret;
  
   ret = gpiochip_lock_as_irq(at91_gpio-chip, pin);
 - if (ret) {
 + if (ret)
   dev_err(at91_gpio-chip.dev, unable to lock pind %lu IRQ\n,
   d-hwirq);
 - return ret;
 - }
 - gpio_irq_unmask(d);
 - return 0;
 +
 + return ret;
  }
  
 -static void gpio_irq_shutdown(struct irq_data *d)
 +static void gpio_irq_release_res(struct irq_data *d)
  {
   struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
   unsignedpin = d-hwirq;
  
 - gpio_irq_mask(d);
   gpiochip_unlock_as_irq(at91_gpio-chip, pin);
  }
  
 @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
  static struct irq_chip gpio_irqchip = {
   .name   = GPIO,
   .irq_ack= gpio_irq_ack,
 - .irq_startup= gpio_irq_startup,
 - .irq_shutdown   = gpio_irq_shutdown,
 + .irq_request_resources = gpio_irq_request_res,
 + .irq_release_resources = gpio_irq_release_res,
   .irq_disable= gpio_irq_mask,
   .irq_mask   = gpio_irq_mask,
   .irq_unmask = gpio_irq_unmask,
 -- 
 1.9.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: pm: fix SRAM allocation

[Jean-Christophe PLAGNIOL-VILLARD]

> On Mar 2, 2015, at 6:57 PM, Alexandre Belloni 
>  wrote:
> 
> On 02/03/2015 at 18:50:27 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
>> 
>>> On Mar 2, 2015, at 6:42 PM, Alexandre Belloni 
>>>  wrote:
>>> 
>>> On some platforms, there are multiple SRAM nodes defined in the device tree 
>>> but
>>> some of them are disabled, leading to allocation failure. Try to find the 
>>> first
>>> enabled SRAM node and allocate from it.
>>> 
>>> Signed-off-by: Alexandre Belloni 
>>> ---
>>> arch/arm/mach-at91/pm.c | 20 +---
>>> 1 file changed, 9 insertions(+), 11 deletions(-)
>>> 
>>> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
>>> index 5e34fb143309..97cc529b6fa0 100644
>>> --- a/arch/arm/mach-at91/pm.c
>>> +++ b/arch/arm/mach-at91/pm.c
>>> @@ -272,35 +272,33 @@ static void __init at91_pm_sram_init(void)
>>> struct device_node *node;
>>> struct platform_device *pdev;
>> 
>> pdev not initialised at NULL
> 
> Indeed, I'll fix that. It doesn't really matter for now as all the
> at91 DT have at least one sram node.
except if we drop it or when we add a new SoC and forget it

Best Regards,
J.
> 
> Wenyou, can you test it? If it works, I'll send v2.
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: pm: fix SRAM allocation

[Jean-Christophe PLAGNIOL-VILLARD]

> On Mar 2, 2015, at 6:42 PM, Alexandre Belloni 
>  wrote:
> 
> On some platforms, there are multiple SRAM nodes defined in the device tree 
> but
> some of them are disabled, leading to allocation failure. Try to find the 
> first
> enabled SRAM node and allocate from it.
> 
> Signed-off-by: Alexandre Belloni 
> ---
> arch/arm/mach-at91/pm.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 5e34fb143309..97cc529b6fa0 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -272,35 +272,33 @@ static void __init at91_pm_sram_init(void)
>   struct device_node *node;
>   struct platform_device *pdev;

pdev not initialised at NULL
> 
> - node = of_find_compatible_node(NULL, NULL, "mmio-sram");
> - if (!node) {
> - pr_warn("%s: failed to find sram node!\n", __func__);
> - return;
> + for_each_compatible_node(node, NULL, "mmio-sram") {
> + pdev = of_find_device_by_node(node);
> + if (pdev) {
> + of_node_put(node);
> + break;
> + }
>   }
> 
> - pdev = of_find_device_by_node(node);
>   if (!pdev) {
>   pr_warn("%s: failed to find sram device!\n", __func__);
> - goto put_node;
> + return;
>   }
> 
>   sram_pool = dev_get_gen_pool(>dev);
>   if (!sram_pool) {
>   pr_warn("%s: sram pool unavailable!\n", __func__);
> - goto put_node;
> + return;
>   }
> 
>   sram_base = gen_pool_alloc(sram_pool, at91_slow_clock_sz);
>   if (!sram_base) {
>   pr_warn("%s: unable to alloc ocram!\n", __func__);
> - goto put_node;
> + return;
>   }
> 
>   sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
>   slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz, false);
> -
> -put_node:
> - of_node_put(node);
> }
> #endif
> 
> -- 
> 2.1.0
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: pm: fix SRAM allocation

[Jean-Christophe PLAGNIOL-VILLARD]

 On Mar 2, 2015, at 6:42 PM, Alexandre Belloni 
 alexandre.bell...@free-electrons.com wrote:
 
 On some platforms, there are multiple SRAM nodes defined in the device tree 
 but
 some of them are disabled, leading to allocation failure. Try to find the 
 first
 enabled SRAM node and allocate from it.
 
 Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
 ---
 arch/arm/mach-at91/pm.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)
 
 diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
 index 5e34fb143309..97cc529b6fa0 100644
 --- a/arch/arm/mach-at91/pm.c
 +++ b/arch/arm/mach-at91/pm.c
 @@ -272,35 +272,33 @@ static void __init at91_pm_sram_init(void)
   struct device_node *node;
   struct platform_device *pdev;

pdev not initialised at NULL
 
 - node = of_find_compatible_node(NULL, NULL, mmio-sram);
 - if (!node) {
 - pr_warn(%s: failed to find sram node!\n, __func__);
 - return;
 + for_each_compatible_node(node, NULL, mmio-sram) {
 + pdev = of_find_device_by_node(node);
 + if (pdev) {
 + of_node_put(node);
 + break;
 + }
   }
 
 - pdev = of_find_device_by_node(node);
   if (!pdev) {
   pr_warn(%s: failed to find sram device!\n, __func__);
 - goto put_node;
 + return;
   }
 
   sram_pool = dev_get_gen_pool(pdev-dev);
   if (!sram_pool) {
   pr_warn(%s: sram pool unavailable!\n, __func__);
 - goto put_node;
 + return;
   }
 
   sram_base = gen_pool_alloc(sram_pool, at91_slow_clock_sz);
   if (!sram_base) {
   pr_warn(%s: unable to alloc ocram!\n, __func__);
 - goto put_node;
 + return;
   }
 
   sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
   slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz, false);
 -
 -put_node:
 - of_node_put(node);
 }
 #endif
 
 -- 
 2.1.0
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: pm: fix SRAM allocation

[Jean-Christophe PLAGNIOL-VILLARD]

 On Mar 2, 2015, at 6:57 PM, Alexandre Belloni 
 alexandre.bell...@free-electrons.com wrote:
 
 On 02/03/2015 at 18:50:27 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
 
 On Mar 2, 2015, at 6:42 PM, Alexandre Belloni 
 alexandre.bell...@free-electrons.com wrote:
 
 On some platforms, there are multiple SRAM nodes defined in the device tree 
 but
 some of them are disabled, leading to allocation failure. Try to find the 
 first
 enabled SRAM node and allocate from it.
 
 Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
 ---
 arch/arm/mach-at91/pm.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)
 
 diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
 index 5e34fb143309..97cc529b6fa0 100644
 --- a/arch/arm/mach-at91/pm.c
 +++ b/arch/arm/mach-at91/pm.c
 @@ -272,35 +272,33 @@ static void __init at91_pm_sram_init(void)
 struct device_node *node;
 struct platform_device *pdev;
 
 pdev not initialised at NULL
 
 Indeed, I'll fix that. It doesn't really matter for now as all the
 at91 DT have at least one sram node.
except if we drop it or when we add a new SoC and forget it

Best Regards,
J.
 
 Wenyou, can you test it? If it works, I'll send v2.
 
 -- 
 Alexandre Belloni, Free Electrons
 Embedded Linux, Kernel and Android engineering
 http://free-electrons.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods

[Jean-Christophe PLAGNIOL-VILLARD]

> On Feb 26, 2015, at 9:32 PM, Nicolas Ferre  wrote:
> 
> Le 08/02/2015 19:23, Boris Brezillon a écrit :
>> The gpiochip_lock_as_irq call can fail and return an error, while the
>> irq_startup is not expected to fail (returns an unsigned int which is not
>> checked by irq core code).
>> 
>> irq_request/release_resources functions have been created to address this
>> problem.
>> 
>> Move gpiochip_lock/unlock_as_irq calls into
>> irq_request/release_resources functions to prevent using a gpio as an irq
>> if the gpiochip_lock_as_irq call failed.
>> 
>> Signed-off-by: Boris Brezillon 
> 
> If it can speed up things:
> Acked-by: Nicolas Ferre 
> 
> Linus,
> can we schedule this fix during the 4.0-rc phase?

As I said I’ll test after CNY which finish this week for us

as we only re-open the office Monday

Best Regards,
J.
> 
> Bye,
> 
>> ---
>> drivers/pinctrl/pinctrl-at91.c | 17 +++--
>> 1 file changed, 7 insertions(+), 10 deletions(-)
>> 
>> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
>> index f4cd0b9..a481406 100644
>> --- a/drivers/pinctrl/pinctrl-at91.c
>> +++ b/drivers/pinctrl/pinctrl-at91.c
>> @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
>>  /* the interrupt is already cleared before by reading ISR */
>> }
>> 
>> -static unsigned int gpio_irq_startup(struct irq_data *d)
>> +static int gpio_irq_request_res(struct irq_data *d)
>> {
>>  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>>  unsignedpin = d->hwirq;
>>  int ret;
>> 
>>  ret = gpiochip_lock_as_irq(_gpio->chip, pin);
>> -if (ret) {
>> +if (ret)
>>  dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
>>  d->hwirq);
>> -return ret;
>> -}
>> -gpio_irq_unmask(d);
>> -return 0;
>> +
>> +return ret;
>> }
>> 
>> -static void gpio_irq_shutdown(struct irq_data *d)
>> +static void gpio_irq_release_res(struct irq_data *d)
>> {
>>  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>>  unsignedpin = d->hwirq;
>> 
>> -gpio_irq_mask(d);
>>  gpiochip_unlock_as_irq(_gpio->chip, pin);
>> }
>> 
>> @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
>> static struct irq_chip gpio_irqchip = {
>>  .name   = "GPIO",
>>  .irq_ack= gpio_irq_ack,
>> -.irq_startup= gpio_irq_startup,
>> -.irq_shutdown   = gpio_irq_shutdown,
>> +.irq_request_resources = gpio_irq_request_res,
>> +.irq_release_resources = gpio_irq_release_res,
>>  .irq_disable= gpio_irq_mask,
>>  .irq_mask   = gpio_irq_mask,
>>  .irq_unmask = gpio_irq_unmask,
>> 
> 
> 
> -- 
> Nicolas Ferre

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods

[Jean-Christophe PLAGNIOL-VILLARD]

 On Feb 26, 2015, at 9:32 PM, Nicolas Ferre nicolas.fe...@atmel.com wrote:
 
 Le 08/02/2015 19:23, Boris Brezillon a écrit :
 The gpiochip_lock_as_irq call can fail and return an error, while the
 irq_startup is not expected to fail (returns an unsigned int which is not
 checked by irq core code).
 
 irq_request/release_resources functions have been created to address this
 problem.
 
 Move gpiochip_lock/unlock_as_irq calls into
 irq_request/release_resources functions to prevent using a gpio as an irq
 if the gpiochip_lock_as_irq call failed.
 
 Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
 
 If it can speed up things:
 Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
 
 Linus,
 can we schedule this fix during the 4.0-rc phase?

As I said I’ll test after CNY which finish this week for us

as we only re-open the office Monday

Best Regards,
J.
 
 Bye,
 
 ---
 drivers/pinctrl/pinctrl-at91.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
 index f4cd0b9..a481406 100644
 --- a/drivers/pinctrl/pinctrl-at91.c
 +++ b/drivers/pinctrl/pinctrl-at91.c
 @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
  /* the interrupt is already cleared before by reading ISR */
 }
 
 -static unsigned int gpio_irq_startup(struct irq_data *d)
 +static int gpio_irq_request_res(struct irq_data *d)
 {
  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
  unsignedpin = d-hwirq;
  int ret;
 
  ret = gpiochip_lock_as_irq(at91_gpio-chip, pin);
 -if (ret) {
 +if (ret)
  dev_err(at91_gpio-chip.dev, unable to lock pind %lu IRQ\n,
  d-hwirq);
 -return ret;
 -}
 -gpio_irq_unmask(d);
 -return 0;
 +
 +return ret;
 }
 
 -static void gpio_irq_shutdown(struct irq_data *d)
 +static void gpio_irq_release_res(struct irq_data *d)
 {
  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
  unsignedpin = d-hwirq;
 
 -gpio_irq_mask(d);
  gpiochip_unlock_as_irq(at91_gpio-chip, pin);
 }
 
 @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
 static struct irq_chip gpio_irqchip = {
  .name   = GPIO,
  .irq_ack= gpio_irq_ack,
 -.irq_startup= gpio_irq_startup,
 -.irq_shutdown   = gpio_irq_shutdown,
 +.irq_request_resources = gpio_irq_request_res,
 +.irq_release_resources = gpio_irq_release_res,
  .irq_disable= gpio_irq_mask,
  .irq_mask   = gpio_irq_mask,
  .irq_unmask = gpio_irq_unmask,
 
 
 
 -- 
 Nicolas Ferre

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: cadence: Enable MACB driver for ARM64

[Jean-Christophe PLAGNIOL-VILLARD]

> On Feb 24, 2015, at 3:45 PM, Michal Simek  wrote:
> 
> This driver is used on new Xilinx ZynqMP SoC.
> 
> Signed-off-by: Michal Simek 
> Acked-by: Sören Brinkmann 
> ---
> 
> drivers/net/ethernet/cadence/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/cadence/Kconfig 
> b/drivers/net/ethernet/cadence/Kconfig
> index 321d2ad235d9..4562f90c0348 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -4,7 +4,7 @@
> 
> config NET_CADENCE
>   bool "Cadence devices"
> - depends on HAS_IOMEM && (ARM || AVR32 || MICROBLAZE || COMPILE_TEST)
> + depends on HAS_IOMEM && (ARM || ARM64 || AVR32 || MICROBLAZE || 
> COMPILE_TEST)

drop the arch test just put HAS_IOMEM

Best Regards,
J.
>   default y
>   ---help---
> If you have a network (Ethernet) card belonging to this class, say Y.
> @@ -30,7 +30,7 @@ config ARM_AT91_ETHER
> 
> config MACB
>   tristate "Cadence MACB/GEM support"
> - depends on HAS_DMA && (PLATFORM_AT32AP || ARCH_AT91 || ARCH_PICOXCELL 
> || ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST)
> + depends on HAS_DMA && (PLATFORM_AT32AP || ARCH_AT91 || ARCH_PICOXCELL 
> || ARCH_ZYNQ || ARM64 || MICROBLAZE || COMPILE_TEST)
>   select PHYLIB
>   ---help---
> The Cadence MACB ethernet interface is found on many Atmel AT32 and
> -- 
> 1.8.2.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: cadence: Enable MACB driver for ARM64

[Jean-Christophe PLAGNIOL-VILLARD]

 On Feb 24, 2015, at 3:45 PM, Michal Simek michal.si...@xilinx.com wrote:
 
 This driver is used on new Xilinx ZynqMP SoC.
 
 Signed-off-by: Michal Simek michal.si...@xilinx.com
 Acked-by: Sören Brinkmann soren.brinkm...@xilinx.com
 ---
 
 drivers/net/ethernet/cadence/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/net/ethernet/cadence/Kconfig 
 b/drivers/net/ethernet/cadence/Kconfig
 index 321d2ad235d9..4562f90c0348 100644
 --- a/drivers/net/ethernet/cadence/Kconfig
 +++ b/drivers/net/ethernet/cadence/Kconfig
 @@ -4,7 +4,7 @@
 
 config NET_CADENCE
   bool Cadence devices
 - depends on HAS_IOMEM  (ARM || AVR32 || MICROBLAZE || COMPILE_TEST)
 + depends on HAS_IOMEM  (ARM || ARM64 || AVR32 || MICROBLAZE || 
 COMPILE_TEST)

drop the arch test just put HAS_IOMEM

Best Regards,
J.
   default y
   ---help---
 If you have a network (Ethernet) card belonging to this class, say Y.
 @@ -30,7 +30,7 @@ config ARM_AT91_ETHER
 
 config MACB
   tristate Cadence MACB/GEM support
 - depends on HAS_DMA  (PLATFORM_AT32AP || ARCH_AT91 || ARCH_PICOXCELL 
 || ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST)
 + depends on HAS_DMA  (PLATFORM_AT32AP || ARCH_AT91 || ARCH_PICOXCELL 
 || ARCH_ZYNQ || ARM64 || MICROBLAZE || COMPILE_TEST)
   select PHYLIB
   ---help---
 The Cadence MACB ethernet interface is found on many Atmel AT32 and
 -- 
 1.8.2.3
 
 --
 To unsubscribe from this list: send the line unsubscribe netdev 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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods

[Jean-Christophe PLAGNIOL-VILLARD]

> On Feb 9, 2015, at 10:50 PM, Jean-Christophe PLAGNIOL-VILLARD 
>  wrote:
> 
> 
>> On Feb 9, 2015, at 2:23 AM, Boris Brezillon 
>>  wrote:
>> 
>> The gpiochip_lock_as_irq call can fail and return an error, while the
>> irq_startup is not expected to fail (returns an unsigned int which is not
>> checked by irq core code).
>> 
>> irq_request/release_resources functions have been created to address this
>> problem.
>> 
>> Move gpiochip_lock/unlock_as_irq calls into
>> irq_request/release_resources functions to prevent using a gpio as an irq
>> if the gpiochip_lock_as_irq call failed.
>> 
>> Signed-off-by: Boris Brezillon 
>> —
> 
> I’m travelling will take a look end of the week

just get back from travelling will take a look after Chinese new year
as all my hw are at the office

Best Regards,
J.
> 
> Best Regards,
> J.
>> drivers/pinctrl/pinctrl-at91.c | 17 +++--
>> 1 file changed, 7 insertions(+), 10 deletions(-)
>> 
>> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
>> index f4cd0b9..a481406 100644
>> --- a/drivers/pinctrl/pinctrl-at91.c
>> +++ b/drivers/pinctrl/pinctrl-at91.c
>> @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
>>  /* the interrupt is already cleared before by reading ISR */
>> }
>> 
>> -static unsigned int gpio_irq_startup(struct irq_data *d)
>> +static int gpio_irq_request_res(struct irq_data *d)
>> {
>>  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>>  unsignedpin = d->hwirq;
>>  int ret;
>> 
>>  ret = gpiochip_lock_as_irq(_gpio->chip, pin);
>> -if (ret) {
>> +if (ret)
>>  dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
>>  d->hwirq);
>> -return ret;
>> -}
>> -gpio_irq_unmask(d);
>> -return 0;
>> +
>> +return ret;
>> }
>> 
>> -static void gpio_irq_shutdown(struct irq_data *d)
>> +static void gpio_irq_release_res(struct irq_data *d)
>> {
>>  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>>  unsignedpin = d->hwirq;
>> 
>> -gpio_irq_mask(d);
>>  gpiochip_unlock_as_irq(_gpio->chip, pin);
>> }
>> 
>> @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
>> static struct irq_chip gpio_irqchip = {
>>  .name   = "GPIO",
>>  .irq_ack= gpio_irq_ack,
>> -.irq_startup= gpio_irq_startup,
>> -.irq_shutdown   = gpio_irq_shutdown,
>> +.irq_request_resources = gpio_irq_request_res,
>> +.irq_release_resources = gpio_irq_release_res,
>>  .irq_disable= gpio_irq_mask,
>>  .irq_mask   = gpio_irq_mask,
>>  .irq_unmask = gpio_irq_unmask,
>> -- 
>> 1.9.1
>> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods

[Jean-Christophe PLAGNIOL-VILLARD]

 On Feb 9, 2015, at 10:50 PM, Jean-Christophe PLAGNIOL-VILLARD 
 plagn...@jcrosoft.com wrote:
 
 
 On Feb 9, 2015, at 2:23 AM, Boris Brezillon 
 boris.brezil...@free-electrons.com wrote:
 
 The gpiochip_lock_as_irq call can fail and return an error, while the
 irq_startup is not expected to fail (returns an unsigned int which is not
 checked by irq core code).
 
 irq_request/release_resources functions have been created to address this
 problem.
 
 Move gpiochip_lock/unlock_as_irq calls into
 irq_request/release_resources functions to prevent using a gpio as an irq
 if the gpiochip_lock_as_irq call failed.
 
 Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
 —
 
 I’m travelling will take a look end of the week

just get back from travelling will take a look after Chinese new year
as all my hw are at the office

Best Regards,
J.
 
 Best Regards,
 J.
 drivers/pinctrl/pinctrl-at91.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
 index f4cd0b9..a481406 100644
 --- a/drivers/pinctrl/pinctrl-at91.c
 +++ b/drivers/pinctrl/pinctrl-at91.c
 @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
  /* the interrupt is already cleared before by reading ISR */
 }
 
 -static unsigned int gpio_irq_startup(struct irq_data *d)
 +static int gpio_irq_request_res(struct irq_data *d)
 {
  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
  unsignedpin = d-hwirq;
  int ret;
 
  ret = gpiochip_lock_as_irq(at91_gpio-chip, pin);
 -if (ret) {
 +if (ret)
  dev_err(at91_gpio-chip.dev, unable to lock pind %lu IRQ\n,
  d-hwirq);
 -return ret;
 -}
 -gpio_irq_unmask(d);
 -return 0;
 +
 +return ret;
 }
 
 -static void gpio_irq_shutdown(struct irq_data *d)
 +static void gpio_irq_release_res(struct irq_data *d)
 {
  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
  unsignedpin = d-hwirq;
 
 -gpio_irq_mask(d);
  gpiochip_unlock_as_irq(at91_gpio-chip, pin);
 }
 
 @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
 static struct irq_chip gpio_irqchip = {
  .name   = GPIO,
  .irq_ack= gpio_irq_ack,
 -.irq_startup= gpio_irq_startup,
 -.irq_shutdown   = gpio_irq_shutdown,
 +.irq_request_resources = gpio_irq_request_res,
 +.irq_release_resources = gpio_irq_release_res,
  .irq_disable= gpio_irq_mask,
  .irq_mask   = gpio_irq_mask,
  .irq_unmask = gpio_irq_unmask,
 -- 
 1.9.1
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods

[Jean-Christophe PLAGNIOL-VILLARD]

> On Feb 9, 2015, at 2:23 AM, Boris Brezillon 
>  wrote:
> 
> The gpiochip_lock_as_irq call can fail and return an error, while the
> irq_startup is not expected to fail (returns an unsigned int which is not
> checked by irq core code).
> 
> irq_request/release_resources functions have been created to address this
> problem.
> 
> Move gpiochip_lock/unlock_as_irq calls into
> irq_request/release_resources functions to prevent using a gpio as an irq
> if the gpiochip_lock_as_irq call failed.
> 
> Signed-off-by: Boris Brezillon 
> —

I’m travelling will take a look end of the week

Best Regards,
J.
> drivers/pinctrl/pinctrl-at91.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index f4cd0b9..a481406 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
>   /* the interrupt is already cleared before by reading ISR */
> }
> 
> -static unsigned int gpio_irq_startup(struct irq_data *d)
> +static int gpio_irq_request_res(struct irq_data *d)
> {
>   struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>   unsignedpin = d->hwirq;
>   int ret;
> 
>   ret = gpiochip_lock_as_irq(_gpio->chip, pin);
> - if (ret) {
> + if (ret)
>   dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
>   d->hwirq);
> - return ret;
> - }
> - gpio_irq_unmask(d);
> - return 0;
> +
> + return ret;
> }
> 
> -static void gpio_irq_shutdown(struct irq_data *d)
> +static void gpio_irq_release_res(struct irq_data *d)
> {
>   struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>   unsignedpin = d->hwirq;
> 
> - gpio_irq_mask(d);
>   gpiochip_unlock_as_irq(_gpio->chip, pin);
> }
> 
> @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
> static struct irq_chip gpio_irqchip = {
>   .name   = "GPIO",
>   .irq_ack= gpio_irq_ack,
> - .irq_startup= gpio_irq_startup,
> - .irq_shutdown   = gpio_irq_shutdown,
> + .irq_request_resources = gpio_irq_request_res,
> + .irq_release_resources = gpio_irq_release_res,
>   .irq_disable= gpio_irq_mask,
>   .irq_mask   = gpio_irq_mask,
>   .irq_unmask = gpio_irq_unmask,
> -- 
> 1.9.1
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods

[Jean-Christophe PLAGNIOL-VILLARD]

 On Feb 9, 2015, at 2:23 AM, Boris Brezillon 
 boris.brezil...@free-electrons.com wrote:
 
 The gpiochip_lock_as_irq call can fail and return an error, while the
 irq_startup is not expected to fail (returns an unsigned int which is not
 checked by irq core code).
 
 irq_request/release_resources functions have been created to address this
 problem.
 
 Move gpiochip_lock/unlock_as_irq calls into
 irq_request/release_resources functions to prevent using a gpio as an irq
 if the gpiochip_lock_as_irq call failed.
 
 Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
 —

I’m travelling will take a look end of the week

Best Regards,
J.
 drivers/pinctrl/pinctrl-at91.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
 index f4cd0b9..a481406 100644
 --- a/drivers/pinctrl/pinctrl-at91.c
 +++ b/drivers/pinctrl/pinctrl-at91.c
 @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
   /* the interrupt is already cleared before by reading ISR */
 }
 
 -static unsigned int gpio_irq_startup(struct irq_data *d)
 +static int gpio_irq_request_res(struct irq_data *d)
 {
   struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
   unsignedpin = d-hwirq;
   int ret;
 
   ret = gpiochip_lock_as_irq(at91_gpio-chip, pin);
 - if (ret) {
 + if (ret)
   dev_err(at91_gpio-chip.dev, unable to lock pind %lu IRQ\n,
   d-hwirq);
 - return ret;
 - }
 - gpio_irq_unmask(d);
 - return 0;
 +
 + return ret;
 }
 
 -static void gpio_irq_shutdown(struct irq_data *d)
 +static void gpio_irq_release_res(struct irq_data *d)
 {
   struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
   unsignedpin = d-hwirq;
 
 - gpio_irq_mask(d);
   gpiochip_unlock_as_irq(at91_gpio-chip, pin);
 }
 
 @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
 static struct irq_chip gpio_irqchip = {
   .name   = GPIO,
   .irq_ack= gpio_irq_ack,
 - .irq_startup= gpio_irq_startup,
 - .irq_shutdown   = gpio_irq_shutdown,
 + .irq_request_resources = gpio_irq_request_res,
 + .irq_release_resources = gpio_irq_release_res,
   .irq_disable= gpio_irq_mask,
   .irq_mask   = gpio_irq_mask,
   .irq_unmask = gpio_irq_unmask,
 -- 
 1.9.1
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: /proc/atags: Export also for DT

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 28, 2015, at 3:19 PM, Pavel Machek  wrote:
> 
> Hi!
> 
>>> In other words, what prevents someone from creating, say, a custom 
>>> minimal Barebox version that sits on top of the existing N900 
>>> bootloader?  Wouldn't that provide a much better user experience?
>> 
>> I do agree with Nicolas
>> 
>> If I can get my hand on a phone I’ll put barebox on it
> 
> Grab it in the nearest "second hand cellphones" shop, and have fun! It
> should be less than $70.

will see if I can found one in Shanghai at the second hand market

Does it exist a qemu emulation?

Best Regards,
J.
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: /proc/atags: Export also for DT

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 28, 2015, at 9:58 PM, Pali Rohár  wrote:
> 
> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>> * Russell King - ARM Linux  [150127 
> 09:51]:
>>> We _could_ (and have in the past) turned round and refused
>>> to support these kinds of hacks - which IMHO is quite a
>>> reasonable stance to take: the message we should be sending
>>> is "if you wish to design new methods without discussing it
>>> with us, we reserve the right not to support them in
>>> mainline kernels; please discuss with us your
>>> requirements."
>>> 
>>> Each time that we accept one of these hacks, we're sending a
>>> message that says "it's okay to work in this crappy way".
>>> 
>>> Yes, I realise that the N900 has little in the way of
>>> support, and we can't exert that kind of back pressure
>>> (since there's no one to direct that onto to effect any
>>> change) so I guess we just have to live with it.
>> 
>> I believe after N900 Nokia dropped the custom ATAGs and used
>> the kernel cmdline instead. And most of the n900 custom ATAGs
>> are not even needed any longer.
>> 
> 
> Yes, almost all N900 ATAGs are static and are already hardcoded 
> into kernel or DT file.
> 
> Basically there are 4 non static values which are used:
> 
> 1. ATAG_REVISION
> 
> 2. ATAG_OMAP
> 2.1 OMAP_TAG_BOOT_REASON --> boot reason

you can pass it via DT I already do it on other platform such as amineoIP
which is full DT with barebox as bootloader

> 2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version

do you really need such information in the kernel as we have a standard boot 
API?

> 2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or “update"

this is application specific not related to the kernel just pass it via cmdline

Best Regards,
J.
> 
> ATAG_OMAP is non standard and contains sub-atags.
> 
> bootloader version is static now (as Nokia does not develop it 
> anymore), but boot reason and boot mode are set by bootloader and 
> are needed for userspace. boot mode tells init system/userspace 
> if to start normal OS or only small subset for flashing.
> 
>> The ATAG_REVISION is a standard feature that we should support
>> naturally. I don't think we should add any custom ATAGs,
>> except maybe for the bootreason.
>> 
 I think this kind of information (how was board/computer
 started) can be useful also for other architectures. E.g.
 on laptop you would like to know if if was started by
 RTC, power button, WakeOnLan, another ACPI event,
 rebooted machine, watchdog, etc... And scripts can act
 depending on this event (when by RTC, you need to run
 some planned job, when by watchdog reset you should check
 what caused that reason...).
>>> 
>>> There is a standard way to get the boot information already:
>>> look at the watchdog API:
>>> 
>>> #define WDIOC_GETBOOTSTATUS _IOR(WATCHDOG_IOCTL_BASE, 2,
>>> int)
>>> 
>>> which uses the WDIOF_* flags to indicate the last boot
>>> reason.  It probably isn't as flexible as some may desire,
>>> but it should provide at least the "watchdog rebooted us"
>>> vs "over temperature" vs some other boot reason.
>>> 
>>> The other thing to consider is whether we have a way to know
>>> what the boot reason was, and what we should do if we do
>>> not have a way of supporting some of the boot reasons.  For
>>> example, if we have support for RTC alarm based booting,
>>> but no way to actually tell if the boot was caused by the
>>> RTC alarm triggering.
>> 
>> On omaps, the bootrom passes the bootreason in r1 to the
>> bootloader that can do whatever it wants with it. We could
>> maybe pass it in the kernel cmdline to the watchdog driver
>> for user space?
>> 
> 
> Not truth for N900. Bootreason depends on PRM_RSTST omap 
> register, state of vbat charger pins, time how long was power key 
> pressed, R data stored in CAL partition and other undocumented 
> registers for omap HS devices. I already tried to implement at 
> least some subset of it in userspace (or kernel), but it is 
> impossible because NOLO bootloader clear status of PRM_RSTST 
> register.
> 
> There is also copy of PRM_RSTST register stored at address 
> 0x4020FFB8 (tracing data) but that address is rewritten (probably 
> by kernel), so we really cannot implement reading bootreason in 
> kernel.
> 
> But in early stage in uboot it is possible to read 0x4020FFB8 
> address and get some part of bootreason. But still PRM_RSTST is 
> not enough!
> 
> I would be happy if DT kernel can export /proc/atags file with 
> ATAGs passed by bootloader. It would be enough for me. In 
> userspace I can parse content and do what is needed.
> 
> In non DT kernel file /proc/atags is always exported.
> 
>> Of course the problem is that the signed bootloader on n900
>> cannot be modified so the pass through u-boot would have to
>> translate the custom ATAG for bootreason into a kernel
>> cmdline..
>> 
>> But it may actually make sense to add the bootreason ATAGs, it
>> seems quite generic to me.
>> 
> 
> Which bootreason 

Re: [PATCH] ARM: /proc/atags: Export also for DT

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 28, 2015, at 11:57 PM, Rob Herring  wrote:
> 
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre  wrote:
>> On Wed, 28 Jan 2015, Pali Rohár wrote:
>> 
>>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
 On omaps, the bootrom passes the bootreason in r1 to the
 bootloader that can do whatever it wants with it. We could
 maybe pass it in the kernel cmdline to the watchdog driver
 for user space?
 
>>> 
>>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>>> register, state of vbat charger pins, time how long was power key
>>> pressed, R data stored in CAL partition and other undocumented
>>> registers for omap HS devices. I already tried to implement at
>>> least some subset of it in userspace (or kernel), but it is
>>> impossible because NOLO bootloader clear status of PRM_RSTST
>>> register.
>>> 
>>> There is also copy of PRM_RSTST register stored at address
>>> 0x4020FFB8 (tracing data) but that address is rewritten (probably
>>> by kernel), so we really cannot implement reading bootreason in
>>> kernel.
>>> 
>>> But in early stage in uboot it is possible to read 0x4020FFB8
>>> address and get some part of bootreason. But still PRM_RSTST is
>>> not enough!
>>> 
>>> I would be happy if DT kernel can export /proc/atags file with
>>> ATAGs passed by bootloader. It would be enough for me. In
>>> userspace I can parse content and do what is needed.
>> 
>> What about defining a DT boot reason property instead?
>> Maybe it already exists?  If not, it's something that could certainly be
>> generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT is crap
> and have a new boot interface, we'll have people relying on
> /proc/device-tree. I hope to be retired when that happens…

but if we try to do this generic, where will you store the boot mode

I mean where the SoC boot from

useful to for the Userspace to known where is the bootloader in case of multi 
boot mode

Best Regards,
J.
> 
> Rob
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: /proc/atags: Export also for DT

[Jean-Christophe PLAGNIOL-VILLARD]

 On Jan 28, 2015, at 11:57 PM, Rob Herring robherri...@gmail.com wrote:
 
 On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre n...@fluxnic.net wrote:
 On Wed, 28 Jan 2015, Pali Rohár wrote:
 
 On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
 On omaps, the bootrom passes the bootreason in r1 to the
 bootloader that can do whatever it wants with it. We could
 maybe pass it in the kernel cmdline to the watchdog driver
 for user space?
 
 
 Not truth for N900. Bootreason depends on PRM_RSTST omap
 register, state of vbat charger pins, time how long was power key
 pressed, RD data stored in CAL partition and other undocumented
 registers for omap HS devices. I already tried to implement at
 least some subset of it in userspace (or kernel), but it is
 impossible because NOLO bootloader clear status of PRM_RSTST
 register.
 
 There is also copy of PRM_RSTST register stored at address
 0x4020FFB8 (tracing data) but that address is rewritten (probably
 by kernel), so we really cannot implement reading bootreason in
 kernel.
 
 But in early stage in uboot it is possible to read 0x4020FFB8
 address and get some part of bootreason. But still PRM_RSTST is
 not enough!
 
 I would be happy if DT kernel can export /proc/atags file with
 ATAGs passed by bootloader. It would be enough for me. In
 userspace I can parse content and do what is needed.
 
 What about defining a DT boot reason property instead?
 Maybe it already exists?  If not, it's something that could certainly be
 generically used on other platforms too.
 
 I'm fine with that, but we just need to have a standard kernel
 userspace interface in addition to something like
 /proc/device-tree/bootreason. Perhaps this can be the default
 implementation for the watchdog dev. Someday when we decide DT is crap
 and have a new boot interface, we'll have people relying on
 /proc/device-tree. I hope to be retired when that happens…

but if we try to do this generic, where will you store the boot mode

I mean where the SoC boot from

useful to for the Userspace to known where is the bootloader in case of multi 
boot mode

Best Regards,
J.
 
 Rob
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: /proc/atags: Export also for DT

[Jean-Christophe PLAGNIOL-VILLARD]

 On Jan 28, 2015, at 9:58 PM, Pali Rohár pali.ro...@gmail.com wrote:
 
 On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [150127 
 09:51]:
 We _could_ (and have in the past) turned round and refused
 to support these kinds of hacks - which IMHO is quite a
 reasonable stance to take: the message we should be sending
 is if you wish to design new methods without discussing it
 with us, we reserve the right not to support them in
 mainline kernels; please discuss with us your
 requirements.
 
 Each time that we accept one of these hacks, we're sending a
 message that says it's okay to work in this crappy way.
 
 Yes, I realise that the N900 has little in the way of
 support, and we can't exert that kind of back pressure
 (since there's no one to direct that onto to effect any
 change) so I guess we just have to live with it.
 
 I believe after N900 Nokia dropped the custom ATAGs and used
 the kernel cmdline instead. And most of the n900 custom ATAGs
 are not even needed any longer.
 
 
 Yes, almost all N900 ATAGs are static and are already hardcoded 
 into kernel or DT file.
 
 Basically there are 4 non static values which are used:
 
 1. ATAG_REVISION
 
 2. ATAG_OMAP
 2.1 OMAP_TAG_BOOT_REASON -- boot reason

you can pass it via DT I already do it on other platform such as amineoIP
which is full DT with barebox as bootloader

 2.2 OMAP_TAG_VERSION (nolo) -- for bootloader version

do you really need such information in the kernel as we have a standard boot 
API?

 2.3 OMAP_TAG_VERSION (boot-mode) -- normal or “update

this is application specific not related to the kernel just pass it via cmdline

Best Regards,
J.
 
 ATAG_OMAP is non standard and contains sub-atags.
 
 bootloader version is static now (as Nokia does not develop it 
 anymore), but boot reason and boot mode are set by bootloader and 
 are needed for userspace. boot mode tells init system/userspace 
 if to start normal OS or only small subset for flashing.
 
 The ATAG_REVISION is a standard feature that we should support
 naturally. I don't think we should add any custom ATAGs,
 except maybe for the bootreason.
 
 I think this kind of information (how was board/computer
 started) can be useful also for other architectures. E.g.
 on laptop you would like to know if if was started by
 RTC, power button, WakeOnLan, another ACPI event,
 rebooted machine, watchdog, etc... And scripts can act
 depending on this event (when by RTC, you need to run
 some planned job, when by watchdog reset you should check
 what caused that reason...).
 
 There is a standard way to get the boot information already:
 look at the watchdog API:
 
 #define WDIOC_GETBOOTSTATUS _IOR(WATCHDOG_IOCTL_BASE, 2,
 int)
 
 which uses the WDIOF_* flags to indicate the last boot
 reason.  It probably isn't as flexible as some may desire,
 but it should provide at least the watchdog rebooted us
 vs over temperature vs some other boot reason.
 
 The other thing to consider is whether we have a way to know
 what the boot reason was, and what we should do if we do
 not have a way of supporting some of the boot reasons.  For
 example, if we have support for RTC alarm based booting,
 but no way to actually tell if the boot was caused by the
 RTC alarm triggering.
 
 On omaps, the bootrom passes the bootreason in r1 to the
 bootloader that can do whatever it wants with it. We could
 maybe pass it in the kernel cmdline to the watchdog driver
 for user space?
 
 
 Not truth for N900. Bootreason depends on PRM_RSTST omap 
 register, state of vbat charger pins, time how long was power key 
 pressed, RD data stored in CAL partition and other undocumented 
 registers for omap HS devices. I already tried to implement at 
 least some subset of it in userspace (or kernel), but it is 
 impossible because NOLO bootloader clear status of PRM_RSTST 
 register.
 
 There is also copy of PRM_RSTST register stored at address 
 0x4020FFB8 (tracing data) but that address is rewritten (probably 
 by kernel), so we really cannot implement reading bootreason in 
 kernel.
 
 But in early stage in uboot it is possible to read 0x4020FFB8 
 address and get some part of bootreason. But still PRM_RSTST is 
 not enough!
 
 I would be happy if DT kernel can export /proc/atags file with 
 ATAGs passed by bootloader. It would be enough for me. In 
 userspace I can parse content and do what is needed.
 
 In non DT kernel file /proc/atags is always exported.
 
 Of course the problem is that the signed bootloader on n900
 cannot be modified so the pass through u-boot would have to
 translate the custom ATAG for bootreason into a kernel
 cmdline..
 
 But it may actually make sense to add the bootreason ATAGs, it
 seems quite generic to me.
 
 
 Which bootreason atag? Invent new? Or use above big ATAG_OMAP 
 structure? Inventing new does not solve anything because all 
 developers does not boot kernel for debugging from uboot -- but 
 directly.
 
 AFAIK, the 

Re: [PATCH] ARM: /proc/atags: Export also for DT

[Jean-Christophe PLAGNIOL-VILLARD]

 On Jan 28, 2015, at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
 
 Hi!
 
 In other words, what prevents someone from creating, say, a custom 
 minimal Barebox version that sits on top of the existing N900 
 bootloader?  Wouldn't that provide a much better user experience?
 
 I do agree with Nicolas
 
 If I can get my hand on a phone I’ll put barebox on it
 
 Grab it in the nearest second hand cellphones shop, and have fun! It
 should be less than $70.

will see if I can found one in Shanghai at the second hand market

Does it exist a qemu emulation?

Best Regards,
J.
   Pavel
 -- 
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: /proc/atags: Export also for DT

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 28, 2015, at 10:07 AM, Nicolas Pitre  wrote:
> 
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> 
>> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
>>> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
 Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
 and let the kernel deal with it in a much saner environment than the
 restricted decompressor environment.
>>> 
>>> ... which would be a step backward in the context of the transition to 
>>> DT we accepted.  People will have even less of an incentive to fix their 
>>> stuff.
>> 
>> Where's the people fixing their stuff today?
> 
> At least some people in this thread are, otherwise they'd still be away 
> hacking on their own.
> 
>> I think your position is something of an idealist rather than a 
>> realist - the reality is that five years down the line of DT, the 
>> platforms which have not converted are now *never* going to convert, 
>> irrespective of how much "incentive" we may think we should apply to 
>> the situation.
> 
> Don't get me wrong.  I'm not expecting those platforms to do native DT 
> booting ever.  However "faking" DT booting with already proven solutions 
> that don't bastardize the kernel further should be encouraged.
> 
>>> If there is indeed a sizable following for the device then someone 
>>> should figure out how to cope with upstream kernels, either through the 
>>> installation of some intermediate bootloader that can talk FDT directly, 
>>> or via a shim layer.  None of that has to be performed by nor linked 
>>> with the kernel binary, nor maintained in the kernel tree. And it's not 
>>> even that hard to do: we have precedents on other platforms with crappy 
>>> bootloaders where this just works.
>> 
>> That's a rediculous position if you want something which "just works"
>> on as much hardware as possible, which is, after all, what the single
>> zImage project is all about.
> 
> Agreed.
> 
>> To be pro single-zImage, and anti popular hardware is quite contradictory.
> 
> Indeed.  I'm not against popular hardware.
> 
>> You only have to look at x86 for this: just because ACPI came along does
>> not mean that the Linux kernel started demanding that ACPI is the only
>> way to describe the world.  Linux continues to directly support all the
>> old boot protocols that it did since the days of i386, such as the e820
>> memory interface and doesn't convert these to an ACPI table just because
>> it can.
> 
> Booting from a floppy boot sector is no longer supported though.
> 
> But that's besides the point.  If someone needs a 5-line addition to 
> atags_to_fdt.c in order to boot some old stuff then let's just do it and 
> move on. I'll happily ACK the patch. The code is there and it is not 
> going away soon.
> 
> However, if something more involved is needed, is platform specific and 
> is likely to require about as many lines in the kernel than it would 
> need in some externat shim then the shim solution should be encouraged 
> instead.  After all that's why LILO, Syslinux and Grub were created on 
> X86: to Supplement the crappy PC BIOS boot interface.  And if the 
> hardware is popular, then finding a motivated hacker to do it shouldn't 
> be too hard, right?
> 
> In other words, what prevents someone from creating, say, a custom 
> minimal Barebox version that sits on top of the existing N900 
> bootloader?  Wouldn't that provide a much better user experience?

I do agree with Nicolas

If I can get my hand on a phone I’ll put barebox on it

Best Regards,
J.
> 
> 
> Nicolas
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: /proc/atags: Export also for DT

[Jean-Christophe PLAGNIOL-VILLARD]

 On Jan 28, 2015, at 10:07 AM, Nicolas Pitre n...@fluxnic.net wrote:
 
 On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
 
 On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
 On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
 Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
 and let the kernel deal with it in a much saner environment than the
 restricted decompressor environment.
 
 ... which would be a step backward in the context of the transition to 
 DT we accepted.  People will have even less of an incentive to fix their 
 stuff.
 
 Where's the people fixing their stuff today?
 
 At least some people in this thread are, otherwise they'd still be away 
 hacking on their own.
 
 I think your position is something of an idealist rather than a 
 realist - the reality is that five years down the line of DT, the 
 platforms which have not converted are now *never* going to convert, 
 irrespective of how much incentive we may think we should apply to 
 the situation.
 
 Don't get me wrong.  I'm not expecting those platforms to do native DT 
 booting ever.  However faking DT booting with already proven solutions 
 that don't bastardize the kernel further should be encouraged.
 
 If there is indeed a sizable following for the device then someone 
 should figure out how to cope with upstream kernels, either through the 
 installation of some intermediate bootloader that can talk FDT directly, 
 or via a shim layer.  None of that has to be performed by nor linked 
 with the kernel binary, nor maintained in the kernel tree. And it's not 
 even that hard to do: we have precedents on other platforms with crappy 
 bootloaders where this just works.
 
 That's a rediculous position if you want something which just works
 on as much hardware as possible, which is, after all, what the single
 zImage project is all about.
 
 Agreed.
 
 To be pro single-zImage, and anti popular hardware is quite contradictory.
 
 Indeed.  I'm not against popular hardware.
 
 You only have to look at x86 for this: just because ACPI came along does
 not mean that the Linux kernel started demanding that ACPI is the only
 way to describe the world.  Linux continues to directly support all the
 old boot protocols that it did since the days of i386, such as the e820
 memory interface and doesn't convert these to an ACPI table just because
 it can.
 
 Booting from a floppy boot sector is no longer supported though.
 
 But that's besides the point.  If someone needs a 5-line addition to 
 atags_to_fdt.c in order to boot some old stuff then let's just do it and 
 move on. I'll happily ACK the patch. The code is there and it is not 
 going away soon.
 
 However, if something more involved is needed, is platform specific and 
 is likely to require about as many lines in the kernel than it would 
 need in some externat shim then the shim solution should be encouraged 
 instead.  After all that's why LILO, Syslinux and Grub were created on 
 X86: to Supplement the crappy PC BIOS boot interface.  And if the 
 hardware is popular, then finding a motivated hacker to do it shouldn't 
 be too hard, right?
 
 In other words, what prevents someone from creating, say, a custom 
 minimal Barebox version that sits on top of the existing N900 
 bootloader?  Wouldn't that provide a much better user experience?

I do agree with Nicolas

If I can get my hand on a phone I’ll put barebox on it

Best Regards,
J.
 
 
 Nicolas
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: at91: fix PM initialization for newer SoCs

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 23, 2015, at 12:07 AM, Nicolas Ferre  wrote:
> 
> Newer SoCs: at91sam9x5, at91sam9n12, sama5d3 and sama5d4 embed a DDR 
> controller
> and have a different PMC status register layout than the at91sam9g45. Create
> another at91_sam9x5_pm_init() function to match this compatibility.
> 
> Signed-off-by: Nicolas Ferre 
> ---
> arch/arm/mach-at91/board-dt-sam9.c  | 20 
> arch/arm/mach-at91/board-dt-sama5.c |  2 +-
> arch/arm/mach-at91/generic.h|  2 ++
> arch/arm/mach-at91/pm.c |  7 +++
> 4 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-at91/board-dt-sam9.c 
> b/arch/arm/mach-at91/board-dt-sam9.c
> index 0fe1ced608c5..c8252ddac6f0 100644
> --- a/arch/arm/mach-at91/board-dt-sam9.c
> +++ b/arch/arm/mach-at91/board-dt-sam9.c
> @@ -61,3 +61,23 @@ DT_MACHINE_START(at91sam9g45_dt, "Atmel AT91SAM9G45")
>   .init_machine   = sam9g45_dt_device_init,
>   .dt_compat  = at91_9g45_board_compat,
> MACHINE_END
> +
> +static void __init sam9x5_dt_device_init(void)
> +{
> + at91_sam9x5_pm_init();
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static const char *at91_9x5_board_compat[] __initconst = {
> + "atmel,at91sam9x5",
> + "atmel,at91sam9n12",
> + NULL
> +};
> +
> +DT_MACHINE_START(at91sam9x5_dt, "Atmel AT91SAM9”)
sam9? sam9x5
> + /* Maintainer: Atmel */
> + .map_io = at91_map_io,
> + .init_early = at91_dt_initialize,
> + .init_machine   = sam9x5_dt_device_init,
> + .dt_compat  = at91_9x5_board_compat,
> +MACHINE_END

why a second START instead of a pdata?

and create a second dt compatible
e
Best Regards,
J.
> diff --git a/arch/arm/mach-at91/board-dt-sama5.c 
> b/arch/arm/mach-at91/board-dt-sama5.c
> index 44d372a22a29..b7338966c8ab 100644
> --- a/arch/arm/mach-at91/board-dt-sama5.c
> +++ b/arch/arm/mach-at91/board-dt-sama5.c
> @@ -28,7 +28,7 @@
> 
> static void __init sama5_dt_device_init(void)
> {
> - at91_sam9260_pm_init();
> + at91_sam9x5_pm_init();
>   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> }
> 
> diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
> index 1e60faec2eba..709570cbef2b 100644
> --- a/arch/arm/mach-at91/generic.h
> +++ b/arch/arm/mach-at91/generic.h
> @@ -32,10 +32,12 @@ extern void at91sam9_idle(void);
> extern void __init at91_rm9200_pm_init(void);
> extern void __init at91_sam9260_pm_init(void);
> extern void __init at91_sam9g45_pm_init(void);
> +extern void __init at91_sam9x5_pm_init(void);
> #else
> void __init at91_rm9200_pm_init(void) { }
> void __init at91_sam9260_pm_init(void) { }
> void __init at91_sam9g45_pm_init(void) { }
> +void __init at91_sam9x5_pm_init(void) { }
> #endif
> 
> #endif /* _AT91_GENERIC_H */
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 81f2f12d3cc1..87c1fd8aa1b6 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -306,3 +306,10 @@ void __init at91_sam9g45_pm_init(void)
>   at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
>   return at91_pm_init();
> }
> +
> +void __init at91_sam9x5_pm_init(void)
> +{
> + at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP;
> + at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
> + return at91_pm_init();
> +}
> -- 
> 2.1.3
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: at91: fix PM initialization for newer SoCs

[Jean-Christophe PLAGNIOL-VILLARD]

 On Jan 23, 2015, at 12:07 AM, Nicolas Ferre nicolas.fe...@atmel.com wrote:
 
 Newer SoCs: at91sam9x5, at91sam9n12, sama5d3 and sama5d4 embed a DDR 
 controller
 and have a different PMC status register layout than the at91sam9g45. Create
 another at91_sam9x5_pm_init() function to match this compatibility.
 
 Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
 ---
 arch/arm/mach-at91/board-dt-sam9.c  | 20 
 arch/arm/mach-at91/board-dt-sama5.c |  2 +-
 arch/arm/mach-at91/generic.h|  2 ++
 arch/arm/mach-at91/pm.c |  7 +++
 4 files changed, 30 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/mach-at91/board-dt-sam9.c 
 b/arch/arm/mach-at91/board-dt-sam9.c
 index 0fe1ced608c5..c8252ddac6f0 100644
 --- a/arch/arm/mach-at91/board-dt-sam9.c
 +++ b/arch/arm/mach-at91/board-dt-sam9.c
 @@ -61,3 +61,23 @@ DT_MACHINE_START(at91sam9g45_dt, Atmel AT91SAM9G45)
   .init_machine   = sam9g45_dt_device_init,
   .dt_compat  = at91_9g45_board_compat,
 MACHINE_END
 +
 +static void __init sam9x5_dt_device_init(void)
 +{
 + at91_sam9x5_pm_init();
 + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 +}
 +
 +static const char *at91_9x5_board_compat[] __initconst = {
 + atmel,at91sam9x5,
 + atmel,at91sam9n12,
 + NULL
 +};
 +
 +DT_MACHINE_START(at91sam9x5_dt, Atmel AT91SAM9”)
sam9? sam9x5
 + /* Maintainer: Atmel */
 + .map_io = at91_map_io,
 + .init_early = at91_dt_initialize,
 + .init_machine   = sam9x5_dt_device_init,
 + .dt_compat  = at91_9x5_board_compat,
 +MACHINE_END

why a second START instead of a pdata?

and create a second dt compatible
e
Best Regards,
J.
 diff --git a/arch/arm/mach-at91/board-dt-sama5.c 
 b/arch/arm/mach-at91/board-dt-sama5.c
 index 44d372a22a29..b7338966c8ab 100644
 --- a/arch/arm/mach-at91/board-dt-sama5.c
 +++ b/arch/arm/mach-at91/board-dt-sama5.c
 @@ -28,7 +28,7 @@
 
 static void __init sama5_dt_device_init(void)
 {
 - at91_sam9260_pm_init();
 + at91_sam9x5_pm_init();
   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
 index 1e60faec2eba..709570cbef2b 100644
 --- a/arch/arm/mach-at91/generic.h
 +++ b/arch/arm/mach-at91/generic.h
 @@ -32,10 +32,12 @@ extern void at91sam9_idle(void);
 extern void __init at91_rm9200_pm_init(void);
 extern void __init at91_sam9260_pm_init(void);
 extern void __init at91_sam9g45_pm_init(void);
 +extern void __init at91_sam9x5_pm_init(void);
 #else
 void __init at91_rm9200_pm_init(void) { }
 void __init at91_sam9260_pm_init(void) { }
 void __init at91_sam9g45_pm_init(void) { }
 +void __init at91_sam9x5_pm_init(void) { }
 #endif
 
 #endif /* _AT91_GENERIC_H */
 diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
 index 81f2f12d3cc1..87c1fd8aa1b6 100644
 --- a/arch/arm/mach-at91/pm.c
 +++ b/arch/arm/mach-at91/pm.c
 @@ -306,3 +306,10 @@ void __init at91_sam9g45_pm_init(void)
   at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
   return at91_pm_init();
 }
 +
 +void __init at91_sam9x5_pm_init(void)
 +{
 + at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP;
 + at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
 + return at91_pm_init();
 +}
 -- 
 2.1.3
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] ARM: at91: pm: rework cpu detection

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 15, 2015, at 4:21 AM, Boris Brezillon 
>  wrote:
> 
> Hi Jean-Christophe,
> 
> On Wed, 14 Jan 2015 20:14:12 +0100
> Jean-Christophe PLAGNIOL-VILLARD  wrote:
> 
>> On 22:23 Mon 12 Jan , Alexandre Belloni wrote:
>>> Store SoC differences in a struct to remove cpu_is_* usage.
>>> 
>>> Signed-off-by: Alexandre Belloni 
>>> ---
>>> arch/arm/mach-at91/pm.c | 54 
>>> ++---
>>> 1 file changed, 33 insertions(+), 21 deletions(-)
>>> 
>>> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
>>> index 9b15169a1c62..79aa793d1f00 100644
>>> --- a/arch/arm/mach-at91/pm.c
>>> +++ b/arch/arm/mach-at91/pm.c
>>> @@ -17,6 +17,7 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>> #include 
>>> #include 
>>> @@ -32,6 +33,11 @@
>>> #include "generic.h"
>>> #include "pm.h"
>>> 
>>> +static struct {
>>> +   unsigned long uhp_udp_mask;
>>> +   int memctrl;
>>> +} at91_pm_data;
>>> +
>>> static void (*at91_pm_standby)(void);
>>> 
>>> static int at91_pm_valid_state(suspend_state_t state)
>>> @@ -71,17 +77,9 @@ static int at91_pm_verify_clocks(void)
>>> scsr = at91_pmc_read(AT91_PMC_SCSR);
>>> 
>>> /* USB must not be using PLLB */
>>> -   if (cpu_is_at91rm9200()) {
>>> -   if ((scsr & (AT91RM9200_PMC_UHP | AT91RM9200_PMC_UDP)) != 0) {
>>> -   pr_err("AT91: PM - Suspend-to-RAM with USB still 
>>> active\n");
>>> -   return 0;
>>> -   }
>>> -   } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() || 
>>> cpu_is_at91sam9263()
>>> -   || cpu_is_at91sam9g20() || cpu_is_at91sam9g10()) {
>>> -   if ((scsr & (AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP)) != 0) {
>>> -   pr_err("AT91: PM - Suspend-to-RAM with USB still 
>>> active\n");
>>> -   return 0;
>>> -   }
>>> +   if ((scsr & at91_pm_data.uhp_udp_mask) != 0) {
>>> +   pr_err("AT91: PM - Suspend-to-RAM with USB still active\n");
>>> +   return 0;
>>> }
>>> 
>>> /* PCK0..PCK3 must be disabled, or configured to use clk32k */
>>> @@ -149,18 +147,13 @@ static int at91_pm_enter(suspend_state_t state)
>>>  * turning off the main oscillator; reverse on wakeup.
>>>  */
>>> if (slow_clock) {
>>> -   int memctrl = AT91_MEMCTRL_SDRAMC;
>>> -
>>> -   if (cpu_is_at91rm9200())
>>> -   memctrl = AT91_MEMCTRL_MC;
>>> -   else if (cpu_is_at91sam9g45())
>>> -   memctrl = AT91_MEMCTRL_DDRSDR;
>>> #ifdef CONFIG_AT91_SLOW_CLOCK
>>> /* copy slow_clock handler to SRAM, and call it 
>>> */
>>> memcpy(slow_clock, at91_slow_clock, 
>>> at91_slow_clock_sz);
>>> #endif
>>> slow_clock(at91_pmc_base, at91_ramc_base[0],
>>> -  at91_ramc_base[1], memctrl);
>>> +  at91_ramc_base[1],
>>> +  at91_pm_data.memctrl);
>>> break;
>>> } else {
>>> pr_info("AT91: PM - no slow clock mode enabled 
>>> ...\n");
>>> @@ -237,10 +230,29 @@ static int __init at91_pm_init(void)
>>> 
>>> pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock 
>>> mode)" : ""));
>>> 
>>> -   /* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
>>> -   if (cpu_is_at91rm9200())
>>> +   at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
>>> +
>>> +   if (of_machine_is_compatible("atmel,at91rm9200")) {
>>> +   /*
>>> +* AT91RM9200 SDRAM low-power mode cannot be used with
>>> +* self-refresh.
>>> +*/
>>> at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
>>> -   
>>> +
>>> +   

Re: [PATCH 1/6] ARM: at91: pm: rework cpu detection

[Jean-Christophe PLAGNIOL-VILLARD]

On 22:23 Mon 12 Jan , Alexandre Belloni wrote:
> Store SoC differences in a struct to remove cpu_is_* usage.
> 
> Signed-off-by: Alexandre Belloni 
> ---
>  arch/arm/mach-at91/pm.c | 54 
> ++---
>  1 file changed, 33 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 9b15169a1c62..79aa793d1f00 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -32,6 +33,11 @@
>  #include "generic.h"
>  #include "pm.h"
>  
> +static struct {
> + unsigned long uhp_udp_mask;
> + int memctrl;
> +} at91_pm_data;
> +
>  static void (*at91_pm_standby)(void);
>  
>  static int at91_pm_valid_state(suspend_state_t state)
> @@ -71,17 +77,9 @@ static int at91_pm_verify_clocks(void)
>   scsr = at91_pmc_read(AT91_PMC_SCSR);
>  
>   /* USB must not be using PLLB */
> - if (cpu_is_at91rm9200()) {
> - if ((scsr & (AT91RM9200_PMC_UHP | AT91RM9200_PMC_UDP)) != 0) {
> - pr_err("AT91: PM - Suspend-to-RAM with USB still 
> active\n");
> - return 0;
> - }
> - } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() || 
> cpu_is_at91sam9263()
> - || cpu_is_at91sam9g20() || cpu_is_at91sam9g10()) {
> - if ((scsr & (AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP)) != 0) {
> - pr_err("AT91: PM - Suspend-to-RAM with USB still 
> active\n");
> - return 0;
> - }
> + if ((scsr & at91_pm_data.uhp_udp_mask) != 0) {
> + pr_err("AT91: PM - Suspend-to-RAM with USB still active\n");
> + return 0;
>   }
>  
>   /* PCK0..PCK3 must be disabled, or configured to use clk32k */
> @@ -149,18 +147,13 @@ static int at91_pm_enter(suspend_state_t state)
>* turning off the main oscillator; reverse on wakeup.
>*/
>   if (slow_clock) {
> - int memctrl = AT91_MEMCTRL_SDRAMC;
> -
> - if (cpu_is_at91rm9200())
> - memctrl = AT91_MEMCTRL_MC;
> - else if (cpu_is_at91sam9g45())
> - memctrl = AT91_MEMCTRL_DDRSDR;
>  #ifdef CONFIG_AT91_SLOW_CLOCK
>   /* copy slow_clock handler to SRAM, and call it 
> */
>   memcpy(slow_clock, at91_slow_clock, 
> at91_slow_clock_sz);
>  #endif
>   slow_clock(at91_pmc_base, at91_ramc_base[0],
> -at91_ramc_base[1], memctrl);
> +at91_ramc_base[1],
> +at91_pm_data.memctrl);
>   break;
>   } else {
>   pr_info("AT91: PM - no slow clock mode enabled 
> ...\n");
> @@ -237,10 +230,29 @@ static int __init at91_pm_init(void)
>  
>   pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock 
> mode)" : ""));
>  
> - /* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
> - if (cpu_is_at91rm9200())
> + at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
> +
> + if (of_machine_is_compatible("atmel,at91rm9200")) {
> + /*
> +  * AT91RM9200 SDRAM low-power mode cannot be used with
> +  * self-refresh.
> +  */
>   at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
> - 
> +
> + at91_pm_data.uhp_udp_mask = AT91RM9200_PMC_UHP |
> + AT91RM9200_PMC_UDP;
> + at91_pm_data.memctrl = AT91_MEMCTRL_MC;
> + } else if (of_machine_is_compatible("atmel,at91sam9260") ||
> +of_machine_is_compatible("atmel,at91sam9g20") ||
> +of_machine_is_compatible("atmel,at91sam9261") ||
> +of_machine_is_compatible("atmel,at91sam9g10") ||
> +of_machine_is_compatible("atmel,at91sam9263")) {
nack here

you switch for runtime information from the SOC register store in ram to DT

DT is great but I do prefer to rely on the SoC register here as the whole was
also to check that the is correct

wihich is way slower

Best Regards,
J.
> + at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP |
> + AT91SAM926x_PMC_UDP;
> + } else if (of_machine_is_compatible("atmel,at91sam9g45")) {
> + at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
> + }
> +
>   if (at91_cpuidle_device.dev.platform_data)
>   platform_device_register(_cpuidle_device);
>  
> -- 
> 2.1.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH 1/6] ARM: at91: pm: rework cpu detection

[Jean-Christophe PLAGNIOL-VILLARD]

On 22:23 Mon 12 Jan , Alexandre Belloni wrote:
 Store SoC differences in a struct to remove cpu_is_* usage.
 
 Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
 ---
  arch/arm/mach-at91/pm.c | 54 
 ++---
  1 file changed, 33 insertions(+), 21 deletions(-)
 
 diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
 index 9b15169a1c62..79aa793d1f00 100644
 --- a/arch/arm/mach-at91/pm.c
 +++ b/arch/arm/mach-at91/pm.c
 @@ -17,6 +17,7 @@
  #include linux/interrupt.h
  #include linux/sysfs.h
  #include linux/module.h
 +#include linux/of.h
  #include linux/platform_device.h
  #include linux/io.h
  #include linux/clk/at91_pmc.h
 @@ -32,6 +33,11 @@
  #include generic.h
  #include pm.h
  
 +static struct {
 + unsigned long uhp_udp_mask;
 + int memctrl;
 +} at91_pm_data;
 +
  static void (*at91_pm_standby)(void);
  
  static int at91_pm_valid_state(suspend_state_t state)
 @@ -71,17 +77,9 @@ static int at91_pm_verify_clocks(void)
   scsr = at91_pmc_read(AT91_PMC_SCSR);
  
   /* USB must not be using PLLB */
 - if (cpu_is_at91rm9200()) {
 - if ((scsr  (AT91RM9200_PMC_UHP | AT91RM9200_PMC_UDP)) != 0) {
 - pr_err(AT91: PM - Suspend-to-RAM with USB still 
 active\n);
 - return 0;
 - }
 - } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() || 
 cpu_is_at91sam9263()
 - || cpu_is_at91sam9g20() || cpu_is_at91sam9g10()) {
 - if ((scsr  (AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP)) != 0) {
 - pr_err(AT91: PM - Suspend-to-RAM with USB still 
 active\n);
 - return 0;
 - }
 + if ((scsr  at91_pm_data.uhp_udp_mask) != 0) {
 + pr_err(AT91: PM - Suspend-to-RAM with USB still active\n);
 + return 0;
   }
  
   /* PCK0..PCK3 must be disabled, or configured to use clk32k */
 @@ -149,18 +147,13 @@ static int at91_pm_enter(suspend_state_t state)
* turning off the main oscillator; reverse on wakeup.
*/
   if (slow_clock) {
 - int memctrl = AT91_MEMCTRL_SDRAMC;
 -
 - if (cpu_is_at91rm9200())
 - memctrl = AT91_MEMCTRL_MC;
 - else if (cpu_is_at91sam9g45())
 - memctrl = AT91_MEMCTRL_DDRSDR;
  #ifdef CONFIG_AT91_SLOW_CLOCK
   /* copy slow_clock handler to SRAM, and call it 
 */
   memcpy(slow_clock, at91_slow_clock, 
 at91_slow_clock_sz);
  #endif
   slow_clock(at91_pmc_base, at91_ramc_base[0],
 -at91_ramc_base[1], memctrl);
 +at91_ramc_base[1],
 +at91_pm_data.memctrl);
   break;
   } else {
   pr_info(AT91: PM - no slow clock mode enabled 
 ...\n);
 @@ -237,10 +230,29 @@ static int __init at91_pm_init(void)
  
   pr_info(AT91: Power Management%s\n, (slow_clock ?  (with slow clock 
 mode) : ));
  
 - /* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
 - if (cpu_is_at91rm9200())
 + at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
 +
 + if (of_machine_is_compatible(atmel,at91rm9200)) {
 + /*
 +  * AT91RM9200 SDRAM low-power mode cannot be used with
 +  * self-refresh.
 +  */
   at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
 - 
 +
 + at91_pm_data.uhp_udp_mask = AT91RM9200_PMC_UHP |
 + AT91RM9200_PMC_UDP;
 + at91_pm_data.memctrl = AT91_MEMCTRL_MC;
 + } else if (of_machine_is_compatible(atmel,at91sam9260) ||
 +of_machine_is_compatible(atmel,at91sam9g20) ||
 +of_machine_is_compatible(atmel,at91sam9261) ||
 +of_machine_is_compatible(atmel,at91sam9g10) ||
 +of_machine_is_compatible(atmel,at91sam9263)) {
nack here

you switch for runtime information from the SOC register store in ram to DT

DT is great but I do prefer to rely on the SoC register here as the whole was
also to check that the is correct

wihich is way slower

Best Regards,
J.
 + at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP |
 + AT91SAM926x_PMC_UDP;
 + } else if (of_machine_is_compatible(atmel,at91sam9g45)) {
 + at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
 + }
 +
   if (at91_cpuidle_device.dev.platform_data)
   platform_device_register(at91_cpuidle_device);
  
 -- 
 2.1.0
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org

Re: [PATCH 1/6] ARM: at91: pm: rework cpu detection

[Jean-Christophe PLAGNIOL-VILLARD]

 On Jan 15, 2015, at 4:21 AM, Boris Brezillon 
 boris.brezil...@free-electrons.com wrote:
 
 Hi Jean-Christophe,
 
 On Wed, 14 Jan 2015 20:14:12 +0100
 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote:
 
 On 22:23 Mon 12 Jan , Alexandre Belloni wrote:
 Store SoC differences in a struct to remove cpu_is_* usage.
 
 Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
 ---
 arch/arm/mach-at91/pm.c | 54 
 ++---
 1 file changed, 33 insertions(+), 21 deletions(-)
 
 diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
 index 9b15169a1c62..79aa793d1f00 100644
 --- a/arch/arm/mach-at91/pm.c
 +++ b/arch/arm/mach-at91/pm.c
 @@ -17,6 +17,7 @@
 #include linux/interrupt.h
 #include linux/sysfs.h
 #include linux/module.h
 +#include linux/of.h
 #include linux/platform_device.h
 #include linux/io.h
 #include linux/clk/at91_pmc.h
 @@ -32,6 +33,11 @@
 #include generic.h
 #include pm.h
 
 +static struct {
 +   unsigned long uhp_udp_mask;
 +   int memctrl;
 +} at91_pm_data;
 +
 static void (*at91_pm_standby)(void);
 
 static int at91_pm_valid_state(suspend_state_t state)
 @@ -71,17 +77,9 @@ static int at91_pm_verify_clocks(void)
 scsr = at91_pmc_read(AT91_PMC_SCSR);
 
 /* USB must not be using PLLB */
 -   if (cpu_is_at91rm9200()) {
 -   if ((scsr  (AT91RM9200_PMC_UHP | AT91RM9200_PMC_UDP)) != 0) {
 -   pr_err(AT91: PM - Suspend-to-RAM with USB still 
 active\n);
 -   return 0;
 -   }
 -   } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() || 
 cpu_is_at91sam9263()
 -   || cpu_is_at91sam9g20() || cpu_is_at91sam9g10()) {
 -   if ((scsr  (AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP)) != 0) {
 -   pr_err(AT91: PM - Suspend-to-RAM with USB still 
 active\n);
 -   return 0;
 -   }
 +   if ((scsr  at91_pm_data.uhp_udp_mask) != 0) {
 +   pr_err(AT91: PM - Suspend-to-RAM with USB still active\n);
 +   return 0;
 }
 
 /* PCK0..PCK3 must be disabled, or configured to use clk32k */
 @@ -149,18 +147,13 @@ static int at91_pm_enter(suspend_state_t state)
  * turning off the main oscillator; reverse on wakeup.
  */
 if (slow_clock) {
 -   int memctrl = AT91_MEMCTRL_SDRAMC;
 -
 -   if (cpu_is_at91rm9200())
 -   memctrl = AT91_MEMCTRL_MC;
 -   else if (cpu_is_at91sam9g45())
 -   memctrl = AT91_MEMCTRL_DDRSDR;
 #ifdef CONFIG_AT91_SLOW_CLOCK
 /* copy slow_clock handler to SRAM, and call it 
 */
 memcpy(slow_clock, at91_slow_clock, 
 at91_slow_clock_sz);
 #endif
 slow_clock(at91_pmc_base, at91_ramc_base[0],
 -  at91_ramc_base[1], memctrl);
 +  at91_ramc_base[1],
 +  at91_pm_data.memctrl);
 break;
 } else {
 pr_info(AT91: PM - no slow clock mode enabled 
 ...\n);
 @@ -237,10 +230,29 @@ static int __init at91_pm_init(void)
 
 pr_info(AT91: Power Management%s\n, (slow_clock ?  (with slow clock 
 mode) : ));
 
 -   /* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
 -   if (cpu_is_at91rm9200())
 +   at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
 +
 +   if (of_machine_is_compatible(atmel,at91rm9200)) {
 +   /*
 +* AT91RM9200 SDRAM low-power mode cannot be used with
 +* self-refresh.
 +*/
 at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
 -   
 +
 +   at91_pm_data.uhp_udp_mask = AT91RM9200_PMC_UHP |
 +   AT91RM9200_PMC_UDP;
 +   at91_pm_data.memctrl = AT91_MEMCTRL_MC;
 +   } else if (of_machine_is_compatible(atmel,at91sam9260) ||
 +  of_machine_is_compatible(atmel,at91sam9g20) ||
 +  of_machine_is_compatible(atmel,at91sam9261) ||
 +  of_machine_is_compatible(atmel,at91sam9g10) ||
 +  of_machine_is_compatible(atmel,at91sam9263)) {
 nack here
 
 you switch for runtime information from the SOC register store in ram to DT
 
 DT is great but I do prefer to rely on the SoC register here as the whole was
 also to check that the is correct
 
 Well, cpu_is_xxx macros are defined in a mach specific header, and we're
 currently trying to enable multi platform support. 

Yes does not mean we can not move this, use the REAL hardware detected cpu is 
better
as you can check that the DT is valid for this SoC and also have fixup for a 
specific
SoC version without having to have x DT per SoC

 
 
 wihich is way slower
 
 Hmm, this SoC detection has been move from the suspend path (where, as
 you stated

Re: [PATCH v3 2/3] dt-bindings: Add pinctrl bindings for mt65xx/mt81xx.

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 14, 2015, at 12:16 AM, Sascha Hauer  wrote:
> 
> On Tue, Jan 13, 2015 at 11:05:22AM +0100, Linus Walleij wrote:
 I am worried that there is something in your reasoning that sort of
 assumes all pin controllers mux pins one-by-one and not in groups.
 How do we make it impossible to write a device tree that also
 make hardware that do groupwise config viable without ambiguities?
>>> 
>>> Sorry, I don't understand this sentence. What do you mean here?
>>> 
>>> The bindings I suggested are for individual pin based controllers
>>> only. I know there are group based controllers, but I don't want to
>>> change their bindings. I believe there is no single binding that is
>>> good for both types of controllers.
>>> 
>>> I think we must face it that individual pin based controllers are
>>> different from group based controllers. That's the main difference
>>> between different pin controllers and I think there are good reasons
>>> to reflect that in the device tree.
>> 
>> OK let's work on a binding for this usecase.
> 
> Okay.
> 
>> 
>>> You often talk about ambiguities. Could you give an example what
>>> ambiguities you mean?
>> 
>> What happened was this pins = ; arguments were sometimes
>> strings and sometimes integers, that becomes strange to handle
>> in code, ambiguous.
> 
> I see. I like naming it 'pinmux' because that's what it is: pins and
> mux settings. A plain 'pinno' suggests that it contains only pin mubers,
> without mux setting. How about 'pin-no-mux'? We also could add an
> explicit "pins-are-numbered" property instead of distinguishing this
> by property names.
> 
>> 
>> I'm fuzzily referring to the concept of things being named the
>> same way in different device trees, yet lacking commonality,
>> confusing a human reader that they may be the same thing,
>> even if it is possible to write schemas and parsers handling
>> it unambigously, so not ambiguity in the formal logic sense.
>> 
>> If i later want to refactor the code around this to a central
>> parser I cannot do so because it would lead to formal ambiguities
>> and is non-doable.
> 
> There could be a flag in the pinctroller struct indicating whether the
> properties are to be interpreted as strings or as numbers.
> 
>> 
>>> Note that the way we combine pin/mux in a single define is not new,
>>> the i.MX pin controller uses this already and so far I'm not aware of
>>> any problems this makes.
>> 
>> Yeah we never had time to sit down and come up with proper
>> generic pin control bindings, we went with custom bindings
>> partly because of general disagreements, partly because I
>> was new to device tree and honestly had no idea of how
>> to skin this cat.
>> 
>> Now that we get to formalize generic bindings for DT and
>> ACPI and whatever alike, I prefer if we make both groupwise
>> and per-pin pin controllers as strict and well defined as
>> possible.
>> 
>> One minor problem I have with using an integer for mux config
>> is that it assumes something about how many pins, configs etc
>> that may exist on such a system. This should be stated
>> explicitly in the bindings atleast so we know what restrictions
>> we build into them. String-based function+group matching has
>> no such restrictions.
> 
> No problem, that can be documented. Normally the defines should be used
> anyway, not the plain pin numbers.
> 
> BTW one thing I really like about integers is the pure binary size. In
> barebox I also parse the pinmux settings from the device tree. The
> drivers using string matching are multiple times bigger due to the
> string tables:
> 
> -rw-r--r-- 1 sha ptx  5436 Jan 13 15:00 imx-iomux-v3.o
> -rw-r--r-- 1 sha ptx 42060 Jan 13 15:00 pinctrl-tegra30.o

Agreed with Sascha that’s why I chose integer for at91 too

if you want string just use define instead to make it more readable

Best Regards,
J.
> 
> Sascha
> 
> -- 
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/3] dt-bindings: Add pinctrl bindings for mt65xx/mt81xx.

[Jean-Christophe PLAGNIOL-VILLARD]

 On Jan 14, 2015, at 12:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
 
 On Tue, Jan 13, 2015 at 11:05:22AM +0100, Linus Walleij wrote:
 I am worried that there is something in your reasoning that sort of
 assumes all pin controllers mux pins one-by-one and not in groups.
 How do we make it impossible to write a device tree that also
 make hardware that do groupwise config viable without ambiguities?
 
 Sorry, I don't understand this sentence. What do you mean here?
 
 The bindings I suggested are for individual pin based controllers
 only. I know there are group based controllers, but I don't want to
 change their bindings. I believe there is no single binding that is
 good for both types of controllers.
 
 I think we must face it that individual pin based controllers are
 different from group based controllers. That's the main difference
 between different pin controllers and I think there are good reasons
 to reflect that in the device tree.
 
 OK let's work on a binding for this usecase.
 
 Okay.
 
 
 You often talk about ambiguities. Could you give an example what
 ambiguities you mean?
 
 What happened was this pins = ; arguments were sometimes
 strings and sometimes integers, that becomes strange to handle
 in code, ambiguous.
 
 I see. I like naming it 'pinmux' because that's what it is: pins and
 mux settings. A plain 'pinno' suggests that it contains only pin mubers,
 without mux setting. How about 'pin-no-mux'? We also could add an
 explicit pins-are-numbered property instead of distinguishing this
 by property names.
 
 
 I'm fuzzily referring to the concept of things being named the
 same way in different device trees, yet lacking commonality,
 confusing a human reader that they may be the same thing,
 even if it is possible to write schemas and parsers handling
 it unambigously, so not ambiguity in the formal logic sense.
 
 If i later want to refactor the code around this to a central
 parser I cannot do so because it would lead to formal ambiguities
 and is non-doable.
 
 There could be a flag in the pinctroller struct indicating whether the
 properties are to be interpreted as strings or as numbers.
 
 
 Note that the way we combine pin/mux in a single define is not new,
 the i.MX pin controller uses this already and so far I'm not aware of
 any problems this makes.
 
 Yeah we never had time to sit down and come up with proper
 generic pin control bindings, we went with custom bindings
 partly because of general disagreements, partly because I
 was new to device tree and honestly had no idea of how
 to skin this cat.
 
 Now that we get to formalize generic bindings for DT and
 ACPI and whatever alike, I prefer if we make both groupwise
 and per-pin pin controllers as strict and well defined as
 possible.
 
 One minor problem I have with using an integer for mux config
 is that it assumes something about how many pins, configs etc
 that may exist on such a system. This should be stated
 explicitly in the bindings atleast so we know what restrictions
 we build into them. String-based function+group matching has
 no such restrictions.
 
 No problem, that can be documented. Normally the defines should be used
 anyway, not the plain pin numbers.
 
 BTW one thing I really like about integers is the pure binary size. In
 barebox I also parse the pinmux settings from the device tree. The
 drivers using string matching are multiple times bigger due to the
 string tables:
 
 -rw-r--r-- 1 sha ptx  5436 Jan 13 15:00 imx-iomux-v3.o
 -rw-r--r-- 1 sha ptx 42060 Jan 13 15:00 pinctrl-tegra30.o

Agreed with Sascha that’s why I chose integer for at91 too

if you want string just use define instead to make it more readable

Best Regards,
J.
 
 Sascha
 
 -- 
 Pengutronix e.K.   | |
 Industrial Linux Solutions | http://www.pengutronix.de/  |
 Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
 Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: at91/tclib: mask interruptions at shutdown and probe

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

This is a bit weird as the clock of the TC should be off and the irq 
free

so this should never happened we need to investigate more why this 
append

Best Regards,
J.
On Aug 20, 2014, at 6:07 AM, Gaël PORTAY  wrote:

> 
> Shutdown properly the timer counter block by masking interruptions. Otherwise,
> a segmentation may happen when kexec-ing a new kernel (see backtrace below).
> An interruption may happen before the handler is set, leading to a kernel
> segmentation fault.
> 
> Furthermore, we make sure the interruptions are masked when the driver is
> initialized. This will prevent freshly kexec-ed kernel from crashing when
> launched from a kernel which does not properly mask interruptions at shutdown.
> 
> The backtrace below happened after kexec-ing a new kernel, from a kernel
> that did not shut down properly leaving interruptions unmasked.
> 
> Unable to handle kernel NULL pointer dereference at virtual address 
> pgd = c0004000
> [] *pgd=
> Internal error: Oops: 8005 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0+ #144
> task: c1828aa0 ti: c182a000 task.ti: c182a000
> PC is at 0x0
> LR is at ch2_irq+0x28/0x30
> pc : [<>]lr : []psr: 00d3
> sp : c182bd38  ip : c182bd48  fp : c182bd44
> r10: c0373390  r9 : c1825b00  r8 : 6053
> r7 :   r6 :   r5 : 0013  r4 : c036e800
> r3 :   r2 : 2004  r1 : c036e760  r0 : c036e760
> Flags: nzcv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
> Control: 0005317f  Table: 20004000  DAC: 0017
> Process swapper (pid: 1, stack limit = 0xc182a1c0)
> Stack: (0xc182bd38 to 0xc182c000)
> bd20:   c182bd7c c182bd48
> bd40: c0045430 c01db8ec  c18c6f40 c182bd74 c1825b00 c035cec4 
> bd60: c182be2c 6053 c1825b34  c182bd94 c182bd80 c0045570 c0045408
> bd80:  c1825b00 c182bdac c182bd98 c0047f34 c0045550 0013 c036619c
> bda0: c182bdc4 c182bdb0 c0044da4 c0047e98 007f 0013 c182bde4 c182bdc8
> bdc0: c0009e34 c0044d8c fefff000 c0046728 6053  c182bdf4 c182bde8
> bde0: c00086a8 c0009ddc c182be74 c182bdf8 c000cb80 c0008674  0013
> be00:  00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34
> be20:  c182be74 c182be20 c182be40 c0047994 c0046728 6053 
> be40: 0013 c036e800 c182be64 c1825b00 0013 c036e800 c035ed98 c03874bc
> be60: 0004 c036e700 c182be94 c182be78 c004689c c0046398 c036e760 c18c6080
> be80:  c035ed10 c182bedc c182be98 c0348b08 c004684c 000c c034dac8
> bea0: 004c4b3f c028c338 c036e760 0013 c014ecc8 c18e67e0 c035b9c0 c0348884
> bec0: c035b9c0 c182a020   c182bf54 c182bee0 c00089fc c0348894
> bee0: c00da51c c1ffcc78 c182bf0c c182bef8 c002d100 c002d09c c1ffcc78 
> bf00: c182bf54 c182bf10 c002d308 c0336570 c182bf3c c0334e44 0003 0003
> bf20: 0030 c0334b44 c0044d74 0003 0003 c034dac8 c0350a94 c0373440
> bf40: c0373440 0030 c182bf94 c182bf58 c0336d24 c000890c 0003 0003
> bf60: c0336560 c182bf64 c182bf64 6e616e0d  c0272fc8  
> bf80:   c182bfac c182bf98 c0272fd8 c0336bd8 c182a000 
> bfa0:  c182bfb0 c00095d0 c0272fd8    
> bfc0:        
> bfe0:     0013  374d27cd 33cc33e4
> Backtrace:
> [] (ch2_irq) from [] (handle_irq_event_percpu+0x38/0x148)
> [] (handle_irq_event_percpu) from [] 
> (handle_irq_event+0x30/0x40)
> r10: r9:c1825b34 r8:6053 r7:c182be2c r6: r5:c035cec4
> r4:c1825b00
> [] (handle_irq_event) from [] 
> (handle_fasteoi_irq+0xac/0x11c)
> r4:c1825b00 r3:
> [] (handle_fasteoi_irq) from [] 
> (generic_handle_irq+0x28/0x38)
> r5:c036619c r4:0013
> [] (generic_handle_irq) from [] (handle_IRQ+0x68/0x88)
> r4:0013 r3:007f
> [] (handle_IRQ) from [] (at91_aic_handle_irq+0x44/0x4c)
> r6: r5:6053 r4:c0046728 r3:fefff000
> [] (at91_aic_handle_irq) from [] (__irq_svc+0x40/0x4c)
> Exception stack(0xc182bdf8 to 0xc182be40)
> bde0:    0013
> be00:  00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34
> be20:  c182be74 c182be20 c182be40 c0047994 c0046728 6053 
> [] (__setup_irq) from [] (setup_irq+0x60/0x8c)
> r10:c036e700 r9:0004 r8:c03874bc r7:c035ed98 r6:c036e800 r5:0013
> r4:c1825b00
> [] (setup_irq) from [] (tcb_clksrc_init+0x284/0x31c)
> r6:c035ed10 r5: r4:c18c6080 r3:c036e760
> [] (tcb_clksrc_init) from [] (do_one_initcall+0x100/0x1b4)
> r10: r9: r8:c182a020 r7:c035b9c0 r6:c0348884 r5:c035b9c0
> r4:c18e67e0
> [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x15c/0x224)
> r9:0030 r8:c0373440 r7:c0373440 r6:c0350a94 

Re: [PATCH 3/3] ARM: at91/tclib: mask interruptions at shutdown and probe

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

This is a bit weird as the clock of the TC should be off and the irq 
free

so this should never happened we need to investigate more why this 
append

Best Regards,
J.
On Aug 20, 2014, at 6:07 AM, Gaël PORTAY gael.por...@gmail.com wrote:

 
 Shutdown properly the timer counter block by masking interruptions. Otherwise,
 a segmentation may happen when kexec-ing a new kernel (see backtrace below).
 An interruption may happen before the handler is set, leading to a kernel
 segmentation fault.
 
 Furthermore, we make sure the interruptions are masked when the driver is
 initialized. This will prevent freshly kexec-ed kernel from crashing when
 launched from a kernel which does not properly mask interruptions at shutdown.
 
 The backtrace below happened after kexec-ing a new kernel, from a kernel
 that did not shut down properly leaving interruptions unmasked.
 
 Unable to handle kernel NULL pointer dereference at virtual address 
 pgd = c0004000
 [] *pgd=
 Internal error: Oops: 8005 [#1] ARM
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0+ #144
 task: c1828aa0 ti: c182a000 task.ti: c182a000
 PC is at 0x0
 LR is at ch2_irq+0x28/0x30
 pc : []lr : [c01db904]psr: 00d3
 sp : c182bd38  ip : c182bd48  fp : c182bd44
 r10: c0373390  r9 : c1825b00  r8 : 6053
 r7 :   r6 :   r5 : 0013  r4 : c036e800
 r3 :   r2 : 2004  r1 : c036e760  r0 : c036e760
 Flags: nzcv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
 Control: 0005317f  Table: 20004000  DAC: 0017
 Process swapper (pid: 1, stack limit = 0xc182a1c0)
 Stack: (0xc182bd38 to 0xc182c000)
 bd20:   c182bd7c c182bd48
 bd40: c0045430 c01db8ec  c18c6f40 c182bd74 c1825b00 c035cec4 
 bd60: c182be2c 6053 c1825b34  c182bd94 c182bd80 c0045570 c0045408
 bd80:  c1825b00 c182bdac c182bd98 c0047f34 c0045550 0013 c036619c
 bda0: c182bdc4 c182bdb0 c0044da4 c0047e98 007f 0013 c182bde4 c182bdc8
 bdc0: c0009e34 c0044d8c fefff000 c0046728 6053  c182bdf4 c182bde8
 bde0: c00086a8 c0009ddc c182be74 c182bdf8 c000cb80 c0008674  0013
 be00:  00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34
 be20:  c182be74 c182be20 c182be40 c0047994 c0046728 6053 
 be40: 0013 c036e800 c182be64 c1825b00 0013 c036e800 c035ed98 c03874bc
 be60: 0004 c036e700 c182be94 c182be78 c004689c c0046398 c036e760 c18c6080
 be80:  c035ed10 c182bedc c182be98 c0348b08 c004684c 000c c034dac8
 bea0: 004c4b3f c028c338 c036e760 0013 c014ecc8 c18e67e0 c035b9c0 c0348884
 bec0: c035b9c0 c182a020   c182bf54 c182bee0 c00089fc c0348894
 bee0: c00da51c c1ffcc78 c182bf0c c182bef8 c002d100 c002d09c c1ffcc78 
 bf00: c182bf54 c182bf10 c002d308 c0336570 c182bf3c c0334e44 0003 0003
 bf20: 0030 c0334b44 c0044d74 0003 0003 c034dac8 c0350a94 c0373440
 bf40: c0373440 0030 c182bf94 c182bf58 c0336d24 c000890c 0003 0003
 bf60: c0336560 c182bf64 c182bf64 6e616e0d  c0272fc8  
 bf80:   c182bfac c182bf98 c0272fd8 c0336bd8 c182a000 
 bfa0:  c182bfb0 c00095d0 c0272fd8    
 bfc0:        
 bfe0:     0013  374d27cd 33cc33e4
 Backtrace:
 [c01db8dc] (ch2_irq) from [c0045430] (handle_irq_event_percpu+0x38/0x148)
 [c00453f8] (handle_irq_event_percpu) from [c0045570] 
 (handle_irq_event+0x30/0x40)
 r10: r9:c1825b34 r8:6053 r7:c182be2c r6: r5:c035cec4
 r4:c1825b00
 [c0045540] (handle_irq_event) from [c0047f34] 
 (handle_fasteoi_irq+0xac/0x11c)
 r4:c1825b00 r3:
 [c0047e88] (handle_fasteoi_irq) from [c0044da4] 
 (generic_handle_irq+0x28/0x38)
 r5:c036619c r4:0013
 [c0044d7c] (generic_handle_irq) from [c0009e34] (handle_IRQ+0x68/0x88)
 r4:0013 r3:007f
 [c0009dcc] (handle_IRQ) from [c00086a8] (at91_aic_handle_irq+0x44/0x4c)
 r6: r5:6053 r4:c0046728 r3:fefff000
 [c0008664] (at91_aic_handle_irq) from [c000cb80] (__irq_svc+0x40/0x4c)
 Exception stack(0xc182bdf8 to 0xc182be40)
 bde0:    0013
 be00:  00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34
 be20:  c182be74 c182be20 c182be40 c0047994 c0046728 6053 
 [c0046388] (__setup_irq) from [c004689c] (setup_irq+0x60/0x8c)
 r10:c036e700 r9:0004 r8:c03874bc r7:c035ed98 r6:c036e800 r5:0013
 r4:c1825b00
 [c004683c] (setup_irq) from [c0348b08] (tcb_clksrc_init+0x284/0x31c)
 r6:c035ed10 r5: r4:c18c6080 r3:c036e760
 [c0348884] (tcb_clksrc_init) from [c00089fc] (do_one_initcall+0x100/0x1b4)
 r10: r9: r8:c182a020 r7:c035b9c0 r6:c0348884 r5:c035b9c0
 r4:c18e67e0
 [c00088fc] 

Re: [PATCH] ARM: at91: spi: request all csgpio in spi probe

[Jean-Christophe PLAGNIOL-VILLARD]

On Aug 1, 2014, at 12:48 AM, Alexandre Belloni 
 wrote:

> 
> On 01/08/2014 at 00:10:05 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
>>>>> While this solves the particular issue Jiří is seeing, this will not
>>>>> solve the case where PA14 (CS0) is not used by the spi driver at all. It
>>>>> will remained muxed as CS0 and toggle when the spi master needs to
>>>>> access CS0 until another driver muxes it to something else. I still
>>>>> believe we should explicitly ask pinctrl to mux them as gpios.
>> 
>> This is not the job of the kernel but to the bootloader
>> no the pinctrl binding is not here and will never be here the configure a 
>> pin as a GPIO or
> 
> This is exactly what AT91_PERIPH_GPIO does though. Anyway, not request
> the pinmuxing in the driver is not a good idea, then nothing prevents
> another driver to request them to do something completely different.

here it’s the same issue if you need to pin as GPIO use the GPIO API not the 
pinctrl

AT91_PERIPH_GPIO is use the set specific pinmux (bouncing & etc…)


> 
>> to a specific state. This the job of the driver or the bootloader
>> 
> 
> I agree that it must not allow to set the state, we are talking about
> muxing.
> 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: spi: request all csgpio in spi probe

[Jean-Christophe PLAGNIOL-VILLARD]

On Jul 31, 2014, at 11:59 PM, Alexandre Belloni 
 wrote:

> On 29/07/2014 at 10:00:17 +0200, Boris Brezillon wrote :
>> Hi Alexandre,
>> 
>>> While this solves the particular issue Jiří is seeing, this will not
>>> solve the case where PA14 (CS0) is not used by the spi driver at all. It
>>> will remained muxed as CS0 and toggle when the spi master needs to
>>> access CS0 until another driver muxes it to something else. I still
>>> believe we should explicitly ask pinctrl to mux them as gpios.

This is not the job of the kernel but to the bootloader
no the pinctrl binding is not here and will never be here the configure a pin 
as a GPIO or
to a specific state. This the job of the driver or the bootloader

>>> 
>> 
>> Do we really care about this case ?
>> After all, if a given pin needs a specific muxing during kernel boot
>> (i.e. a pin connected to a gpio-led that needs to stay in its previous
>> state or a pin connected to the reset line of a device that needs to
>> stay up and running during kernel boot) the bootloader/bootstrap should
>> have muxed this pin appropriately before booting the kernel.
>> 
> 
> Yeah, you are right.
> 
> 
>> What do you mean by "we should explicitly ask pinctrl to mux them as
>> gpios" ?
>> Do you mean configuring all the pins as GPIOs when the pin controller is
>> probed, or just adding a new pinctrl state configuring the pin as an
>> output GPIO and reference it in the pinctrl-0 property of the spi
>> controller.
>> 
>> If the former, you'll break devices that needs their pins to stay in
>> the state they were during the bootloader/boostrap phase.
>> The latter won't work if the pin you request as GPIO is later requested
>> by another device (which, if I'm correct, is exactly the case you're
>> trying to solve).
>> 
> 
> Again you are right, let's not care about that use case. I still feel
> that the pinctrl-0 property has to be filled correctly.
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: spi: request all csgpio in spi probe

[Jean-Christophe PLAGNIOL-VILLARD]

On Jul 31, 2014, at 11:59 PM, Alexandre Belloni 
alexandre.bell...@free-electrons.com wrote:

 On 29/07/2014 at 10:00:17 +0200, Boris Brezillon wrote :
 Hi Alexandre,
 
 While this solves the particular issue Jiří is seeing, this will not
 solve the case where PA14 (CS0) is not used by the spi driver at all. It
 will remained muxed as CS0 and toggle when the spi master needs to
 access CS0 until another driver muxes it to something else. I still
 believe we should explicitly ask pinctrl to mux them as gpios.

This is not the job of the kernel but to the bootloader
no the pinctrl binding is not here and will never be here the configure a pin 
as a GPIO or
to a specific state. This the job of the driver or the bootloader

 
 
 Do we really care about this case ?
 After all, if a given pin needs a specific muxing during kernel boot
 (i.e. a pin connected to a gpio-led that needs to stay in its previous
 state or a pin connected to the reset line of a device that needs to
 stay up and running during kernel boot) the bootloader/bootstrap should
 have muxed this pin appropriately before booting the kernel.
 
 
 Yeah, you are right.
 
 
 What do you mean by we should explicitly ask pinctrl to mux them as
 gpios ?
 Do you mean configuring all the pins as GPIOs when the pin controller is
 probed, or just adding a new pinctrl state configuring the pin as an
 output GPIO and reference it in the pinctrl-0 property of the spi
 controller.
 
 If the former, you'll break devices that needs their pins to stay in
 the state they were during the bootloader/boostrap phase.
 The latter won't work if the pin you request as GPIO is later requested
 by another device (which, if I'm correct, is exactly the case you're
 trying to solve).
 
 
 Again you are right, let's not care about that use case. I still feel
 that the pinctrl-0 property has to be filled correctly.
 
 -- 
 Alexandre Belloni, Free Electrons
 Embedded Linux, Kernel and Android engineering
 http://free-electrons.com
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: spi: request all csgpio in spi probe

[Jean-Christophe PLAGNIOL-VILLARD]

On Aug 1, 2014, at 12:48 AM, Alexandre Belloni 
alexandre.bell...@free-electrons.com wrote:

 
 On 01/08/2014 at 00:10:05 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
 While this solves the particular issue Jiří is seeing, this will not
 solve the case where PA14 (CS0) is not used by the spi driver at all. It
 will remained muxed as CS0 and toggle when the spi master needs to
 access CS0 until another driver muxes it to something else. I still
 believe we should explicitly ask pinctrl to mux them as gpios.
 
 This is not the job of the kernel but to the bootloader
 no the pinctrl binding is not here and will never be here the configure a 
 pin as a GPIO or
 
 This is exactly what AT91_PERIPH_GPIO does though. Anyway, not request
 the pinmuxing in the driver is not a good idea, then nothing prevents
 another driver to request them to do something completely different.

here it’s the same issue if you need to pin as GPIO use the GPIO API not the 
pinctrl

AT91_PERIPH_GPIO is use the set specific pinmux (bouncing  etc…)


 
 to a specific state. This the job of the driver or the bootloader
 
 
 I agree that it must not allow to set the state, we are talking about
 muxing.
 
 
 -- 
 Alexandre Belloni, Free Electrons
 Embedded Linux, Kernel and Android engineering
 http://free-electrons.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/18] power: reset: Add AT91 reset driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:06 Fri 04 Jul , Maxime Ripard wrote:
> On Fri, Jul 04, 2014 at 09:14:43AM +0200, Boris BREZILLON wrote:
> > On Fri, 4 Jul 2014 11:08:20 +0800
> > Jean-Christophe PLAGNIOL-VILLARD  wrote:
> > 
> > > 
> > > On Jul 3, 2014, at 10:59 PM, Maxime Ripard 
> > >  wrote:
> > > 
> > > > On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe 
> > > > PLAGNIOL-VILLARD wrote:
> > > >>> +++ b/drivers/power/reset/at91-reset.c
> > > >>> @@ -0,0 +1,202 @@
> > > >>> +/*
> > > >>> + * Atmel AT91 SAM9 SoCs reset code
> > > >>> + *
> > > >>> + * Copyright (C) 2014 Maxime Ripard
> > > >>> + *
> > > >>> + * Maxime Ripard 
> > > >> 
> > > >> you can not own the copyright as it’s basically a copy of other
> > > >> people code
> > > > 
> > > > The previous names are missing, right.
> > > > 
> > > >>> + *
> > > >>> + * This file is licensed under the terms of the GNU General Public
> > > >>> + * License version 2.  This program is licensed "as is" without any
> > > >>> + * warranty of any kind, whether express or implied.
> > > >>> + */
> > > >>> +
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +
> > > >>> +#include 
> > > >>> +
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +
> > > >>> +#define AT91_RSTC_CR 0x00/* Reset Controller Control 
> > > >>> Register */
> > > >>> +#define  AT91_RSTC_PROCRST   BIT(0)  /* Processor 
> > > >>> Reset */
> > > >>> +#define  AT91_RSTC_PERRSTBIT(2)  /* Peripheral 
> > > >>> Reset */
> > > >>> +#define  AT91_RSTC_EXTRSTBIT(3)  /* External 
> > > >>> Reset */
> > > >>> +#define  AT91_RSTC_KEY   (0xa5 << 24)/* KEY Password 
> > > >>> */
> > > >>> +
> > > >>> +#define AT91_RSTC_SR 0x04/* Reset Controller Status 
> > > >>> Register */
> > > >>> +#define  AT91_RSTC_URSTS BIT(0)  /* User Reset 
> > > >>> Status */
> > > >>> +#define  AT91_RSTC_RSTTYPGENMASK(10, 8)  /* Reset Type */
> > > >>> +#define  AT91_RSTC_NRSTL BIT(16) /* NRST Pin 
> > > >>> Level */
> > > >>> +#define  AT91_RSTC_SRCMP BIT(17) /* Software 
> > > >>> Reset Command in Progress */
> > > >>> +
> > > >>> +#define AT91_RSTC_MR 0x08/* Reset Controller Mode 
> > > >>> Register */
> > > >>> +#define  AT91_RSTC_URSTENBIT(0)  /* User Reset 
> > > >>> Enable */
> > > >>> +#define  AT91_RSTC_URSTIEN   BIT(4)  /* User Reset 
> > > >>> Interrupt Enable */
> > > >>> +#define  AT91_RSTC_ERSTL GENMASK(11, 8)  /* External 
> > > >>> Reset Length */
> > > >>> +
> > > >>> +enum reset_type {
> > > >>> + RESET_TYPE_GENERAL  = 0,
> > > >>> + RESET_TYPE_WAKEUP   = 1,
> > > >>> + RESET_TYPE_WATCHDOG = 2,
> > > >>> + RESET_TYPE_SOFTWARE = 3,
> > > >>> + RESET_TYPE_USER = 4,
> > > >>> +};
> > > >>> +
> > > >>> +static void __iomem *at91_ramc_base[2], *at91_rstc_base;
> > > >>> +
> > > >>> +static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
> > > >>> +{
> > > >>> + asm volatile(
> > > >>> + ".balign 32\n\t"
> > > >>> +
> > > >>> + "str%2, [%0, #" __stringify(AT91_SDRAMC_TR) "]\n\t"
> > > >>> + "str%3, [%0, #" __stringify(AT91_SDRAMC_LPR) "]\n\t"
> > > >>> + "str%4, [%1, #" __stringify(AT91_RSTC_CR) "]

Re: [PATCH 1/5] memory: add a driver for atmel ram controllers

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:19 Mon 07 Jul , Alexandre Belloni wrote:
> 
> Atmel SoCs have one or multiple RAM controllers that need one or multiple 
> clocks
> to run.
> This driver handle those clocks.
> 
> Signed-off-by: Alexandre Belloni 
> ---
>  .../devicetree/bindings/arm/atmel-at91.txt |  1 +
>  drivers/memory/Kconfig |  8 ++
>  drivers/memory/Makefile|  1 +
>  drivers/memory/atmel-ramc.c| 96 
> ++
>  4 files changed, 106 insertions(+)
>  create mode 100644 drivers/memory/atmel-ramc.c
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt 
> b/Documentation/devicetree/bindings/arm/atmel-at91.txt
> index 16f60b41c147..54dc3aefb12a 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
> @@ -61,6 +61,7 @@ RAMC SDRAM/DDR Controller required properties:
>  - compatible: Should be "atmel,at91rm9200-sdramc",
>   "atmel,at91sam9260-sdramc",
>   "atmel,at91sam9g45-ddramc",
> + "atmel,sama5d3-mpddramc",
>  - reg: Should contain registers location and length
>For at91sam9263 and at91sam9g45 you must specify 2 entries.
>  
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index c59e9c96e86d..e49b9caa1b30 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -7,6 +7,14 @@ menuconfig MEMORY
>  
>  if MEMORY
>  
> +config ATMEL_RAMC
> + bool "Atmel (Multi-port DDR-)SDRAM Controller"
> + default y
> + depends on ARCH_AT91 && OF
> + help
> +   This driver is for Atmel SDRAM Controller or Atmel Multi-port
> +   DDR-SDRAM Controller available on Atmel AT91SAM9 and SAMA5 SoCs
> +
>  config TI_AEMIF
>   tristate "Texas Instruments AEMIF driver"
>   depends on (ARCH_DAVINCI || ARCH_KEYSTONE) && OF
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index 71160a2b7313..eb5d7716efa4 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -5,6 +5,7 @@
>  ifeq ($(CONFIG_DDR),y)
>  obj-$(CONFIG_OF) += of_memory.o
>  endif
> +obj-$(CONFIG_ATMEL_RAMC) += atmel-ramc.o
>  obj-$(CONFIG_TI_AEMIF)   += ti-aemif.o
>  obj-$(CONFIG_TI_EMIF)+= emif.o
>  obj-$(CONFIG_FSL_IFC)+= fsl_ifc.o
> diff --git a/drivers/memory/atmel-ramc.c b/drivers/memory/atmel-ramc.c
> new file mode 100644
> index ..1d12d3d01cbd
> --- /dev/null
> +++ b/drivers/memory/atmel-ramc.c
> @@ -0,0 +1,96 @@
> +/*
> + * Atmel (Multi-port DDR-)SDRAM Controller driver
> + *
> + * Copyright (C) 2014 Atmel
> + *
> + * 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 version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct at91_ramc_caps {
> + bool has_ddrck;
> + bool has_mpddr_clk;
> +};
> +
> +static const struct at91_ramc_caps at91rm9200_caps = { };
> +
> +static const struct at91_ramc_caps at91sam9g45_caps = {
> + .has_ddrck = 1,
> + .has_mpddr_clk = 0,
> +};
> +
> +static const struct at91_ramc_caps sama5d3_caps = {
> + .has_ddrck = 1,
> + .has_mpddr_clk = 1,
> +};
> +
> +static const struct of_device_id atmel_ramc_of_match[] = {
> + { .compatible = "atmel,at91rm9200-sdramc", .data = _caps, },
> + { .compatible = "atmel,at91sam9260-sdramc", .data = _caps, },
> + { .compatible = "atmel,at91sam9g45-ddramc", .data = _caps, 
> },
> + { .compatible = "atmel,sama5d3-mpddramc", .data = _caps, },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, atmel_ramc_of_match);
> +
> +static int atmel_ramc_probe(struct platform_device *pdev)
> +{
> + const struct of_device_id *match;
> + const struct at91_ramc_caps *caps;
> + struct clk *clk;
> +
> + match = of_match_device(atmel_ramc_of_match, >dev);
> + caps = match->data;
> +
> + if (caps->has_ddrck) {
> + clk = devm_clk_get(>dev, "ddrck");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> + clk_prepare_enable(clk);
> + }
> +
> + if (caps->has_mpddr_clk) {
> + clk = devm_clk_get(>dev, "mpddr");
> + if (WARN_ON(IS_ERR(clk)))
> + return 0;
I don't like this warn_on this need to be an error
> + clk_prepare_enable(clk);
> +

Re: [PATCH 09/18] AT91: Call at91_register_devices in the board files

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:52 Thu 03 Jul , Maxime Ripard wrote:
> Hi,
> 
> On Thu, Jul 03, 2014 at 10:29:58PM +0800, Jean-Christophe PLAGNIOL-VILLARD 
> wrote:
> > no do this at SoC level
> 
> Since it has to be done at init_machine, I don't see any other easy
> way to do this at the SoC level.
> 
> What is your suggestion?

do it earlier as there is not driver it will not change anything
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] ARM: at91/dt: sama5d3: define mpddr clock and ramc clocks

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:19 Mon 07 Jul , Alexandre Belloni wrote:
> 
> Define the available clock for mprddr and take both mpddr_clk and ddrck in the
> ram controller driver.
> 
> Signed-off-by: Alexandre Belloni 
> ---
>  arch/arm/boot/dts/sama5d3.dtsi | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index e0b15a6e8897..3bd8db9e069b 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -402,8 +402,10 @@
>   };
>  
>   ramc0: ramc@ea00 {
> - compatible = "atmel,at91sam9g45-ddramc";
> + compatible = "atmel,sama5d3-mpddramc", 
> "atmel,at91sam9g45-ddramc";
the sama5 ddr controler is not back compitble with 9g45 one the compatible is
wrong
>   reg = <0xea00 0x200>;
> + clocks = <>, <_clk>;
> + clock-names = "ddrck", "mpddr";
>   };
>  
>   dbgu: serial@ee00 {
> @@ -1170,6 +1172,11 @@
>   #clock-cells = <0>;
>   reg = <48>;
>   };
> +
> + mpddr_clk: mpddr_clk {
> + #clock-cells = <0>;
> + reg = <49>;
> + };
>   };
>   };
>  
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] ARM: at91/dt: sama5d3: define mpddr clock and ramc clocks

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:19 Mon 07 Jul , Alexandre Belloni wrote:
 
 Define the available clock for mprddr and take both mpddr_clk and ddrck in the
 ram controller driver.
 
 Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
 ---
  arch/arm/boot/dts/sama5d3.dtsi | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
 index e0b15a6e8897..3bd8db9e069b 100644
 --- a/arch/arm/boot/dts/sama5d3.dtsi
 +++ b/arch/arm/boot/dts/sama5d3.dtsi
 @@ -402,8 +402,10 @@
   };
  
   ramc0: ramc@ea00 {
 - compatible = atmel,at91sam9g45-ddramc;
 + compatible = atmel,sama5d3-mpddramc, 
 atmel,at91sam9g45-ddramc;
the sama5 ddr controler is not back compitble with 9g45 one the compatible is
wrong
   reg = 0xea00 0x200;
 + clocks = ddrck, mpddr_clk;
 + clock-names = ddrck, mpddr;
   };
  
   dbgu: serial@ee00 {
 @@ -1170,6 +1172,11 @@
   #clock-cells = 0;
   reg = 48;
   };
 +
 + mpddr_clk: mpddr_clk {
 + #clock-cells = 0;
 + reg = 49;
 + };
   };
   };
  
 -- 
 1.9.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/18] AT91: Call at91_register_devices in the board files

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:52 Thu 03 Jul , Maxime Ripard wrote:
 Hi,
 
 On Thu, Jul 03, 2014 at 10:29:58PM +0800, Jean-Christophe PLAGNIOL-VILLARD 
 wrote:
  no do this at SoC level
 
 Since it has to be done at init_machine, I don't see any other easy
 way to do this at the SoC level.
 
 What is your suggestion?

do it earlier as there is not driver it will not change anything
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] memory: add a driver for atmel ram controllers

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:19 Mon 07 Jul , Alexandre Belloni wrote:
 
 Atmel SoCs have one or multiple RAM controllers that need one or multiple 
 clocks
 to run.
 This driver handle those clocks.
 
 Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
 ---
  .../devicetree/bindings/arm/atmel-at91.txt |  1 +
  drivers/memory/Kconfig |  8 ++
  drivers/memory/Makefile|  1 +
  drivers/memory/atmel-ramc.c| 96 
 ++
  4 files changed, 106 insertions(+)
  create mode 100644 drivers/memory/atmel-ramc.c
 
 diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt 
 b/Documentation/devicetree/bindings/arm/atmel-at91.txt
 index 16f60b41c147..54dc3aefb12a 100644
 --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
 +++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
 @@ -61,6 +61,7 @@ RAMC SDRAM/DDR Controller required properties:
  - compatible: Should be atmel,at91rm9200-sdramc,
   atmel,at91sam9260-sdramc,
   atmel,at91sam9g45-ddramc,
 + atmel,sama5d3-mpddramc,
  - reg: Should contain registers location and length
For at91sam9263 and at91sam9g45 you must specify 2 entries.
  
 diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
 index c59e9c96e86d..e49b9caa1b30 100644
 --- a/drivers/memory/Kconfig
 +++ b/drivers/memory/Kconfig
 @@ -7,6 +7,14 @@ menuconfig MEMORY
  
  if MEMORY
  
 +config ATMEL_RAMC
 + bool Atmel (Multi-port DDR-)SDRAM Controller
 + default y
 + depends on ARCH_AT91  OF
 + help
 +   This driver is for Atmel SDRAM Controller or Atmel Multi-port
 +   DDR-SDRAM Controller available on Atmel AT91SAM9 and SAMA5 SoCs
 +
  config TI_AEMIF
   tristate Texas Instruments AEMIF driver
   depends on (ARCH_DAVINCI || ARCH_KEYSTONE)  OF
 diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
 index 71160a2b7313..eb5d7716efa4 100644
 --- a/drivers/memory/Makefile
 +++ b/drivers/memory/Makefile
 @@ -5,6 +5,7 @@
  ifeq ($(CONFIG_DDR),y)
  obj-$(CONFIG_OF) += of_memory.o
  endif
 +obj-$(CONFIG_ATMEL_RAMC) += atmel-ramc.o
  obj-$(CONFIG_TI_AEMIF)   += ti-aemif.o
  obj-$(CONFIG_TI_EMIF)+= emif.o
  obj-$(CONFIG_FSL_IFC)+= fsl_ifc.o
 diff --git a/drivers/memory/atmel-ramc.c b/drivers/memory/atmel-ramc.c
 new file mode 100644
 index ..1d12d3d01cbd
 --- /dev/null
 +++ b/drivers/memory/atmel-ramc.c
 @@ -0,0 +1,96 @@
 +/*
 + * Atmel (Multi-port DDR-)SDRAM Controller driver
 + *
 + * Copyright (C) 2014 Atmel
 + *
 + * 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 version 2 of the License.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + *
 + */
 +
 +#include linux/clk.h
 +#include linux/err.h
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/of_platform.h
 +#include linux/platform_device.h
 +
 +struct at91_ramc_caps {
 + bool has_ddrck;
 + bool has_mpddr_clk;
 +};
 +
 +static const struct at91_ramc_caps at91rm9200_caps = { };
 +
 +static const struct at91_ramc_caps at91sam9g45_caps = {
 + .has_ddrck = 1,
 + .has_mpddr_clk = 0,
 +};
 +
 +static const struct at91_ramc_caps sama5d3_caps = {
 + .has_ddrck = 1,
 + .has_mpddr_clk = 1,
 +};
 +
 +static const struct of_device_id atmel_ramc_of_match[] = {
 + { .compatible = atmel,at91rm9200-sdramc, .data = at91rm9200_caps, },
 + { .compatible = atmel,at91sam9260-sdramc, .data = at91rm9200_caps, },
 + { .compatible = atmel,at91sam9g45-ddramc, .data = at91sam9g45_caps, 
 },
 + { .compatible = atmel,sama5d3-mpddramc, .data = sama5d3_caps, },
 + {},
 +};
 +MODULE_DEVICE_TABLE(of, atmel_ramc_of_match);
 +
 +static int atmel_ramc_probe(struct platform_device *pdev)
 +{
 + const struct of_device_id *match;
 + const struct at91_ramc_caps *caps;
 + struct clk *clk;
 +
 + match = of_match_device(atmel_ramc_of_match, pdev-dev);
 + caps = match-data;
 +
 + if (caps-has_ddrck) {
 + clk = devm_clk_get(pdev-dev, ddrck);
 + if (IS_ERR(clk))
 + return PTR_ERR(clk);
 + clk_prepare_enable(clk);
 + }
 +
 + if (caps-has_mpddr_clk) {
 + clk = devm_clk_get(pdev-dev, mpddr);
 + if (WARN_ON(IS_ERR(clk)))
 + return 0;
I don't like this warn_on this need to be an error
 + clk_prepare_enable(clk);
 

Re: [PATCH 05/18] power: reset: Add AT91 reset driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:06 Fri 04 Jul , Maxime Ripard wrote:
 On Fri, Jul 04, 2014 at 09:14:43AM +0200, Boris BREZILLON wrote:
  On Fri, 4 Jul 2014 11:08:20 +0800
  Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote:
  
   
   On Jul 3, 2014, at 10:59 PM, Maxime Ripard 
   maxime.rip...@free-electrons.com wrote:
   
On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe 
PLAGNIOL-VILLARD wrote:
+++ b/drivers/power/reset/at91-reset.c
@@ -0,0 +1,202 @@
+/*
+ * Atmel AT91 SAM9 SoCs reset code
+ *
+ * Copyright (C) 2014 Maxime Ripard
+ *
+ * Maxime Ripard maxime.rip...@free-electrons.com

you can not own the copyright as it’s basically a copy of other
people code

The previous names are missing, right.

+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/io.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/reboot.h
+
+#include asm/system_misc.h
+
+#include mach/at91sam9_ddrsdr.h
+#include mach/at91sam9_sdramc.h
+
+#define AT91_RSTC_CR 0x00/* Reset Controller Control 
Register */
+#define  AT91_RSTC_PROCRST   BIT(0)  /* Processor 
Reset */
+#define  AT91_RSTC_PERRSTBIT(2)  /* Peripheral 
Reset */
+#define  AT91_RSTC_EXTRSTBIT(3)  /* External 
Reset */
+#define  AT91_RSTC_KEY   (0xa5  24)/* KEY Password 
*/
+
+#define AT91_RSTC_SR 0x04/* Reset Controller Status 
Register */
+#define  AT91_RSTC_URSTS BIT(0)  /* User Reset 
Status */
+#define  AT91_RSTC_RSTTYPGENMASK(10, 8)  /* Reset Type */
+#define  AT91_RSTC_NRSTL BIT(16) /* NRST Pin 
Level */
+#define  AT91_RSTC_SRCMP BIT(17) /* Software 
Reset Command in Progress */
+
+#define AT91_RSTC_MR 0x08/* Reset Controller Mode 
Register */
+#define  AT91_RSTC_URSTENBIT(0)  /* User Reset 
Enable */
+#define  AT91_RSTC_URSTIEN   BIT(4)  /* User Reset 
Interrupt Enable */
+#define  AT91_RSTC_ERSTL GENMASK(11, 8)  /* External 
Reset Length */
+
+enum reset_type {
+ RESET_TYPE_GENERAL  = 0,
+ RESET_TYPE_WAKEUP   = 1,
+ RESET_TYPE_WATCHDOG = 2,
+ RESET_TYPE_SOFTWARE = 3,
+ RESET_TYPE_USER = 4,
+};
+
+static void __iomem *at91_ramc_base[2], *at91_rstc_base;
+
+static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
+{
+ asm volatile(
+ .balign 32\n\t
+
+ str%2, [%0, # __stringify(AT91_SDRAMC_TR) ]\n\t
+ str%3, [%0, # __stringify(AT91_SDRAMC_LPR) ]\n\t
+ str%4, [%1, # __stringify(AT91_RSTC_CR) ]\n\t
+
+ b  .\n\t
+ :
+ : r (at91_ramc_base[0]),
+   r (at91_rstc_base),
+   r (1),
+   r (AT91_SDRAMC_LPCB_POWER_DOWN),
+   r (AT91_RSTC_KEY | AT91_RSTC_PERRST | 
AT91_RSTC_PROCRST));
+}
+
+static void at91sam9g45_restart(enum reboot_mode mode, const char 
*cmd)
+{
+ asm volatile(
+ cmp%1, #0\n\t
+ beq1f\n\t
+
+ ldrr0, [%1]\n\t
+ cmpr0, #0\n\t
+
+ .balign 32\n\t
+
+ 1: str %3, [%0, # 
__stringify(AT91_DDRSDRC_RTR) ]\n\t
+str %4, [%0, # 
__stringify(AT91_DDRSDRC_RTR) ]\n\t
+strne   %3, [%1, # 
__stringify(AT91_DDRSDRC_RTR) ]\n\t
+strne   %4, [%1, # 
__stringify(AT91_DDRSDRC_RTR) ]\n\t
+str %5, [%2, # __stringify(AT91_RSTC_CR) 
]\n\t
+
+b   .\n\t
+ :
+ : r (at91_ramc_base[0]),
+   r (at91_ramc_base[1]),
+   r (at91_rstc_base),
+   r (1),
+   r (AT91_DDRSDRC_LPCB_POWER_DOWN),
+   r (AT91_RSTC_KEY | AT91_RSTC_PERRST | 
AT91_RSTC_PROCRST)
+ : r0);
+}
+
move this to an assembly file more easy to read than a C code

Nope. It's a pain to pass variable to an external assembly file, and
this makes the use of global variable pretty much mandatory, which is
definitely not great.
   
   Not at all I did for the PM slow clock code just write a function and pas 
   it as a parameter
   you have 3
   
   so basically you have to use

Re: [PATCH 05/18] power: reset: Add AT91 reset driver

[Jean-Christophe PLAGNIOL-VILLARD]

On Jul 3, 2014, at 10:59 PM, Maxime Ripard  
wrote:

> On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe PLAGNIOL-VILLARD 
> wrote:
>>> +++ b/drivers/power/reset/at91-reset.c
>>> @@ -0,0 +1,202 @@
>>> +/*
>>> + * Atmel AT91 SAM9 SoCs reset code
>>> + *
>>> + * Copyright (C) 2014 Maxime Ripard
>>> + *
>>> + * Maxime Ripard 
>> 
>> you can not own the copyright as it’s basically a copy of other
>> people code
> 
> The previous names are missing, right.
> 
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public
>>> + * License version 2.  This program is licensed "as is" without any
>>> + * warranty of any kind, whether express or implied.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#define AT91_RSTC_CR   0x00/* Reset Controller Control 
>>> Register */
>>> +#defineAT91_RSTC_PROCRST   BIT(0)  /* Processor Reset */
>>> +#defineAT91_RSTC_PERRSTBIT(2)  /* Peripheral Reset */
>>> +#defineAT91_RSTC_EXTRSTBIT(3)  /* External Reset */
>>> +#defineAT91_RSTC_KEY   (0xa5 << 24)/* KEY Password */
>>> +
>>> +#define AT91_RSTC_SR   0x04/* Reset Controller Status 
>>> Register */
>>> +#defineAT91_RSTC_URSTS BIT(0)  /* User Reset Status */
>>> +#defineAT91_RSTC_RSTTYPGENMASK(10, 8)  /* Reset Type */
>>> +#defineAT91_RSTC_NRSTL BIT(16) /* NRST Pin Level */
>>> +#defineAT91_RSTC_SRCMP BIT(17) /* Software Reset 
>>> Command in Progress */
>>> +
>>> +#define AT91_RSTC_MR   0x08/* Reset Controller Mode 
>>> Register */
>>> +#defineAT91_RSTC_URSTENBIT(0)  /* User Reset Enable */
>>> +#defineAT91_RSTC_URSTIEN   BIT(4)  /* User Reset Interrupt 
>>> Enable */
>>> +#defineAT91_RSTC_ERSTL GENMASK(11, 8)  /* External Reset 
>>> Length */
>>> +
>>> +enum reset_type {
>>> +   RESET_TYPE_GENERAL  = 0,
>>> +   RESET_TYPE_WAKEUP   = 1,
>>> +   RESET_TYPE_WATCHDOG = 2,
>>> +   RESET_TYPE_SOFTWARE = 3,
>>> +   RESET_TYPE_USER = 4,
>>> +};
>>> +
>>> +static void __iomem *at91_ramc_base[2], *at91_rstc_base;
>>> +
>>> +static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
>>> +{
>>> +   asm volatile(
>>> +   ".balign 32\n\t"
>>> +
>>> +   "str%2, [%0, #" __stringify(AT91_SDRAMC_TR) "]\n\t"
>>> +   "str%3, [%0, #" __stringify(AT91_SDRAMC_LPR) "]\n\t"
>>> +   "str%4, [%1, #" __stringify(AT91_RSTC_CR) "]\n\t"
>>> +
>>> +   "b  .\n\t"
>>> +   :
>>> +   : "r" (at91_ramc_base[0]),
>>> + "r" (at91_rstc_base),
>>> + "r" (1),
>>> + "r" (AT91_SDRAMC_LPCB_POWER_DOWN),
>>> + "r" (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST));
>>> +}
>>> +
>>> +static void at91sam9g45_restart(enum reboot_mode mode, const char *cmd)
>>> +{
>>> +   asm volatile(
>>> +   "cmp%1, #0\n\t"
>>> +   "beq1f\n\t"
>>> +
>>> +   "ldrr0, [%1]\n\t"
>>> +   "cmpr0, #0\n\t"
>>> +
>>> +   ".balign 32\n\t"
>>> +
>>> +   "1: str %3, [%0, #" __stringify(AT91_DDRSDRC_RTR) 
>>> "]\n\t"
>>> +   "   str %4, [%0, #" __stringify(AT91_DDRSDRC_RTR) 
>>> "]\n\t"
>>> +   "   strne   %3, [%1, #" __stringify(AT91_DDRSDRC_RTR) 
>>> "]\n\t"
>>> +   "   strne   %4, [%1, #" __stringify(AT91_DDRSDRC_RTR) 
>>> "]\n\t"
>>> +   "   str %5, [%2, #" __stringify(AT91_RSTC_CR) "]\n\t"
>>> +
>>> +   "   b   .\n\t"
>>>

Re: [PATCH 05/18] power: reset: Add AT91 reset driver

[Jean-Christophe PLAGNIOL-VILLARD]

On Jul 3, 2014, at 10:59 PM, Maxime Ripard maxime.rip...@free-electrons.com 
wrote:

 On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe PLAGNIOL-VILLARD 
 wrote:
 +++ b/drivers/power/reset/at91-reset.c
 @@ -0,0 +1,202 @@
 +/*
 + * Atmel AT91 SAM9 SoCs reset code
 + *
 + * Copyright (C) 2014 Maxime Ripard
 + *
 + * Maxime Ripard maxime.rip...@free-electrons.com
 
 you can not own the copyright as it’s basically a copy of other
 people code
 
 The previous names are missing, right.
 
 + *
 + * This file is licensed under the terms of the GNU General Public
 + * License version 2.  This program is licensed as is without any
 + * warranty of any kind, whether express or implied.
 + */
 +
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_address.h
 +#include linux/platform_device.h
 +#include linux/reboot.h
 +
 +#include asm/system_misc.h
 +
 +#include mach/at91sam9_ddrsdr.h
 +#include mach/at91sam9_sdramc.h
 +
 +#define AT91_RSTC_CR   0x00/* Reset Controller Control 
 Register */
 +#defineAT91_RSTC_PROCRST   BIT(0)  /* Processor Reset */
 +#defineAT91_RSTC_PERRSTBIT(2)  /* Peripheral Reset */
 +#defineAT91_RSTC_EXTRSTBIT(3)  /* External Reset */
 +#defineAT91_RSTC_KEY   (0xa5  24)/* KEY Password */
 +
 +#define AT91_RSTC_SR   0x04/* Reset Controller Status 
 Register */
 +#defineAT91_RSTC_URSTS BIT(0)  /* User Reset Status */
 +#defineAT91_RSTC_RSTTYPGENMASK(10, 8)  /* Reset Type */
 +#defineAT91_RSTC_NRSTL BIT(16) /* NRST Pin Level */
 +#defineAT91_RSTC_SRCMP BIT(17) /* Software Reset 
 Command in Progress */
 +
 +#define AT91_RSTC_MR   0x08/* Reset Controller Mode 
 Register */
 +#defineAT91_RSTC_URSTENBIT(0)  /* User Reset Enable */
 +#defineAT91_RSTC_URSTIEN   BIT(4)  /* User Reset Interrupt 
 Enable */
 +#defineAT91_RSTC_ERSTL GENMASK(11, 8)  /* External Reset 
 Length */
 +
 +enum reset_type {
 +   RESET_TYPE_GENERAL  = 0,
 +   RESET_TYPE_WAKEUP   = 1,
 +   RESET_TYPE_WATCHDOG = 2,
 +   RESET_TYPE_SOFTWARE = 3,
 +   RESET_TYPE_USER = 4,
 +};
 +
 +static void __iomem *at91_ramc_base[2], *at91_rstc_base;
 +
 +static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
 +{
 +   asm volatile(
 +   .balign 32\n\t
 +
 +   str%2, [%0, # __stringify(AT91_SDRAMC_TR) ]\n\t
 +   str%3, [%0, # __stringify(AT91_SDRAMC_LPR) ]\n\t
 +   str%4, [%1, # __stringify(AT91_RSTC_CR) ]\n\t
 +
 +   b  .\n\t
 +   :
 +   : r (at91_ramc_base[0]),
 + r (at91_rstc_base),
 + r (1),
 + r (AT91_SDRAMC_LPCB_POWER_DOWN),
 + r (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST));
 +}
 +
 +static void at91sam9g45_restart(enum reboot_mode mode, const char *cmd)
 +{
 +   asm volatile(
 +   cmp%1, #0\n\t
 +   beq1f\n\t
 +
 +   ldrr0, [%1]\n\t
 +   cmpr0, #0\n\t
 +
 +   .balign 32\n\t
 +
 +   1: str %3, [%0, # __stringify(AT91_DDRSDRC_RTR) 
 ]\n\t
 +  str %4, [%0, # __stringify(AT91_DDRSDRC_RTR) 
 ]\n\t
 +  strne   %3, [%1, # __stringify(AT91_DDRSDRC_RTR) 
 ]\n\t
 +  strne   %4, [%1, # __stringify(AT91_DDRSDRC_RTR) 
 ]\n\t
 +  str %5, [%2, # __stringify(AT91_RSTC_CR) ]\n\t
 +
 +  b   .\n\t
 +   :
 +   : r (at91_ramc_base[0]),
 + r (at91_ramc_base[1]),
 + r (at91_rstc_base),
 + r (1),
 + r (AT91_DDRSDRC_LPCB_POWER_DOWN),
 + r (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST)
 +   : r0);
 +}
 +
 move this to an assembly file more easy to read than a C code
 
 Nope. It's a pain to pass variable to an external assembly file, and
 this makes the use of global variable pretty much mandatory, which is
 definitely not great.

Not at all I did for the PM slow clock code just write a function and pas it as 
a parameter
you have 3

so basically you have to use the current and just pass at91_ramc_base[0], 
at91_ramc_base[1]
and at91_rstc_base
it’s 3 lignes of modification, if you have at91_ramc_base and at91_ramc_base 
same

so NACK
 
 
 +static void __init at91_reset_status(struct platform_device *pdev)
 +{
 +   u32 reg = readl(at91_rstc_base + AT91_RSTC_SR);
 +   char *reason;
 +
 +   switch ((reg  AT91_RSTC_RSTTYP)  8) {
 +   case RESET_TYPE_GENERAL:
 +   reason = general reset;
 +   break;
 +   case RESET_TYPE_WAKEUP:
 +   reason = wakeup;
 +   break;
 +   case RESET_TYPE_WATCHDOG:
 +   reason = watchdog reset;
 +   break;
 +   case RESET_TYPE_SOFTWARE:
 +   reason = software reset;
 +   break;
 +   case RESET_TYPE_USER

Re: [PATCH 05/18] power: reset: Add AT91 reset driver

[Jean-Christophe PLAGNIOL-VILLARD]

On Jul 3, 2014, at 10:59 PM, Maxime Ripard  
wrote:

> On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe PLAGNIOL-VILLARD 
> wrote:
>>> +++ b/drivers/power/reset/at91-reset.c
>>> @@ -0,0 +1,202 @@
>>> +/*
>>> + * Atmel AT91 SAM9 SoCs reset code
>>> + *
>>> + * Copyright (C) 2014 Maxime Ripard
>>> + *
>>> + * Maxime Ripard 
>> 
>> you can not own the copyright as it’s basically a copy of other
>> people code
> 
> The previous names are missing, right.
> 
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public
>>> + * License version 2.  This program is licensed "as is" without any
>>> + * warranty of any kind, whether express or implied.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#define AT91_RSTC_CR   0x00/* Reset Controller Control 
>>> Register */
>>> +#defineAT91_RSTC_PROCRST   BIT(0)  /* Processor Reset */
>>> +#defineAT91_RSTC_PERRSTBIT(2)  /* Peripheral Reset */
>>> +#defineAT91_RSTC_EXTRSTBIT(3)  /* External Reset */
>>> +#defineAT91_RSTC_KEY   (0xa5 << 24)/* KEY Password */
>>> +
>>> +#define AT91_RSTC_SR   0x04/* Reset Controller Status 
>>> Register */
>>> +#defineAT91_RSTC_URSTS BIT(0)  /* User Reset Status */
>>> +#defineAT91_RSTC_RSTTYPGENMASK(10, 8)  /* Reset Type */
>>> +#defineAT91_RSTC_NRSTL BIT(16) /* NRST Pin Level */
>>> +#defineAT91_RSTC_SRCMP BIT(17) /* Software Reset 
>>> Command in Progress */
>>> +
>>> +#define AT91_RSTC_MR   0x08/* Reset Controller Mode 
>>> Register */
>>> +#defineAT91_RSTC_URSTENBIT(0)  /* User Reset Enable */
>>> +#defineAT91_RSTC_URSTIEN   BIT(4)  /* User Reset Interrupt 
>>> Enable */
>>> +#defineAT91_RSTC_ERSTL GENMASK(11, 8)  /* External Reset 
>>> Length */
>>> +
>>> +enum reset_type {
>>> +   RESET_TYPE_GENERAL  = 0,
>>> +   RESET_TYPE_WAKEUP   = 1,
>>> +   RESET_TYPE_WATCHDOG = 2,
>>> +   RESET_TYPE_SOFTWARE = 3,
>>> +   RESET_TYPE_USER = 4,
>>> +};
>>> +
>>> +static void __iomem *at91_ramc_base[2], *at91_rstc_base;
>>> +
>>> +static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
>>> +{
>>> +   asm volatile(
>>> +   ".balign 32\n\t"
>>> +
>>> +   "str%2, [%0, #" __stringify(AT91_SDRAMC_TR) "]\n\t"
>>> +   "str%3, [%0, #" __stringify(AT91_SDRAMC_LPR) "]\n\t"
>>> +   "str%4, [%1, #" __stringify(AT91_RSTC_CR) "]\n\t"
>>> +
>>> +   "b  .\n\t"
>>> +   :
>>> +   : "r" (at91_ramc_base[0]),
>>> + "r" (at91_rstc_base),
>>> + "r" (1),
>>> + "r" (AT91_SDRAMC_LPCB_POWER_DOWN),
>>> + "r" (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST));
>>> +}
>>> +
>>> +static void at91sam9g45_restart(enum reboot_mode mode, const char *cmd)
>>> +{
>>> +   asm volatile(
>>> +   "cmp%1, #0\n\t"
>>> +   "beq1f\n\t"
>>> +
>>> +   "ldrr0, [%1]\n\t"
>>> +   "cmpr0, #0\n\t"
>>> +
>>> +   ".balign 32\n\t"
>>> +
>>> +   "1: str %3, [%0, #" __stringify(AT91_DDRSDRC_RTR) 
>>> "]\n\t"
>>> +   "   str %4, [%0, #" __stringify(AT91_DDRSDRC_RTR) 
>>> "]\n\t"
>>> +   "   strne   %3, [%1, #" __stringify(AT91_DDRSDRC_RTR) 
>>> "]\n\t"
>>> +   "   strne   %4, [%1, #" __stringify(AT91_DDRSDRC_RTR) 
>>> "]\n\t"
>>> +   "   str %5, [%2, #" __stringify(AT91_RSTC_CR) "]\n\t"
>>> +
>>> +   "   b   .\n\t"
>>>

Re: [PATCH 09/18] AT91: Call at91_register_devices in the board files

[Jean-Christophe PLAGNIOL-VILLARD]

no do this at SoC level

Best Regards,
J.
On Jul 3, 2014, at 10:14 PM, Maxime Ripard  
wrote:

> 
> Make every board call the register_devices callback so that the devices
> declared by the SoC are registered.
> 
> Signed-off-by: Maxime Ripard 
> ---
> arch/arm/mach-at91/board-afeb-9260v1.c  | 2 ++
> arch/arm/mach-at91/board-cam60.c| 2 ++
> arch/arm/mach-at91/board-cpu9krea.c | 2 ++
> arch/arm/mach-at91/board-flexibity.c| 2 ++
> arch/arm/mach-at91/board-sam9-l9260.c   | 2 ++
> arch/arm/mach-at91/board-sam9260ek.c| 2 ++
> arch/arm/mach-at91/board-sam9261ek.c| 2 ++
> arch/arm/mach-at91/board-sam9263ek.c| 2 ++
> arch/arm/mach-at91/board-sam9m10g45ek.c | 2 ++
> arch/arm/mach-at91/board-sam9rlek.c | 2 ++
> arch/arm/mach-at91/board-snapper9260.c  | 2 ++
> 11 files changed, 22 insertions(+)
> 
> diff --git a/arch/arm/mach-at91/board-afeb-9260v1.c 
> b/arch/arm/mach-at91/board-afeb-9260v1.c
> index 597c649170aa..fc9621ccb606 100644
> --- a/arch/arm/mach-at91/board-afeb-9260v1.c
> +++ b/arch/arm/mach-at91/board-afeb-9260v1.c
> @@ -167,6 +167,8 @@ static struct at91_cf_data afeb9260_cf_data = {
> 
> static void __init afeb9260_board_init(void)
> {
> + at91_register_devices();
> +
>   /* Serial */
>   /* DBGU on ttyS0. (Rx & Tx only) */
>   at91_register_uart(0, 0, 0);
> diff --git a/arch/arm/mach-at91/board-cam60.c 
> b/arch/arm/mach-at91/board-cam60.c
> index a30502c8d379..283655bd86c1 100644
> --- a/arch/arm/mach-at91/board-cam60.c
> +++ b/arch/arm/mach-at91/board-cam60.c
> @@ -170,6 +170,8 @@ static void __init cam60_add_device_nand(void)
> 
> static void __init cam60_board_init(void)
> {
> + at91_register_devices();
> +
>   /* Serial */
>   /* DBGU on ttyS0. (Rx & Tx only) */
>   at91_register_uart(0, 0, 0);
> diff --git a/arch/arm/mach-at91/board-cpu9krea.c 
> b/arch/arm/mach-at91/board-cpu9krea.c
> index 2037f78c84e7..29a89032bb9a 100644
> --- a/arch/arm/mach-at91/board-cpu9krea.c
> +++ b/arch/arm/mach-at91/board-cpu9krea.c
> @@ -322,6 +322,8 @@ static struct mci_platform_data __initdata 
> cpu9krea_mci0_data = {
> 
> static void __init cpu9krea_board_init(void)
> {
> + at91_register_devices();
> +
>   /* NOR */
>   cpu9krea_add_device_nor();
>   /* Serial */
> diff --git a/arch/arm/mach-at91/board-flexibity.c 
> b/arch/arm/mach-at91/board-flexibity.c
> index 68f1ab6bd08f..79bd411b0cee 100644
> --- a/arch/arm/mach-at91/board-flexibity.c
> +++ b/arch/arm/mach-at91/board-flexibity.c
> @@ -138,6 +138,8 @@ static struct gpio_led flexibity_leds[] = {
> 
> static void __init flexibity_board_init(void)
> {
> + at91_register_devices();
> +
>   /* Serial */
>   /* DBGU on ttyS0. (Rx & Tx only) */
>   at91_register_uart(0, 0, 0);
> diff --git a/arch/arm/mach-at91/board-sam9-l9260.c 
> b/arch/arm/mach-at91/board-sam9-l9260.c
> index d24dda67e2d3..70309404f366 100644
> --- a/arch/arm/mach-at91/board-sam9-l9260.c
> +++ b/arch/arm/mach-at91/board-sam9-l9260.c
> @@ -187,6 +187,8 @@ static struct gpio_led ek_leds[] = {
> 
> static void __init ek_board_init(void)
> {
> + at91_register_devices();
> +
>   /* Serial */
>   /* DBGU on ttyS0. (Rx & Tx only) */
>   at91_register_uart(0, 0, 0);
> diff --git a/arch/arm/mach-at91/board-sam9260ek.c 
> b/arch/arm/mach-at91/board-sam9260ek.c
> index 65dea12d685e..da9c5f1f2c49 100644
> --- a/arch/arm/mach-at91/board-sam9260ek.c
> +++ b/arch/arm/mach-at91/board-sam9260ek.c
> @@ -307,6 +307,8 @@ static void __init ek_add_device_buttons(void) {}
> 
> static void __init ek_board_init(void)
> {
> + at91_register_devices();
> +
>   /* Serial */
>   /* DBGU on ttyS0. (Rx & Tx only) */
>   at91_register_uart(0, 0, 0);
> diff --git a/arch/arm/mach-at91/board-sam9261ek.c 
> b/arch/arm/mach-at91/board-sam9261ek.c
> index 4637432de08f..d1be10b09ab3 100644
> --- a/arch/arm/mach-at91/board-sam9261ek.c
> +++ b/arch/arm/mach-at91/board-sam9261ek.c
> @@ -561,6 +561,8 @@ static struct gpio_led ek_leds[] = {
> 
> static void __init ek_board_init(void)
> {
> + at91_register_devices();
> +
>   /* Serial */
>   /* DBGU on ttyS0. (Rx & Tx only) */
>   at91_register_uart(0, 0, 0);
> diff --git a/arch/arm/mach-at91/board-sam9263ek.c 
> b/arch/arm/mach-at91/board-sam9263ek.c
> index cd2726ee5add..3f613d962d9b 100644
> --- a/arch/arm/mach-at91/board-sam9263ek.c
> +++ b/arch/arm/mach-at91/board-sam9263ek.c
> @@ -405,6 +405,8 @@ static struct at91_can_data ek_can_data = {
> 
> static void __init ek_board_init(void)
> {
> + at91_register_devices();
> +
>   /* Serial */
>   /* DBGU on ttyS0. (Rx & Tx only) */
>   at91_register_uart(0, 0, 0);
> diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c 
> b/arch/arm/mach-at91/board-sam9m10g45ek.c
> index 1ea61328f30d..33a7b19f7400 100644
> --- a/arch/arm/mach-at91/board-sam9m10g45ek.c
> +++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
> @@ -450,6 +450,8 @@ static struct platform_device *devices[] __initdata = {
> 
> 

Re: [PATCH 04/18] AT91: Rework ramc mapping code

[Jean-Christophe PLAGNIOL-VILLARD]

patch 4 and 18 what is the difference?

Best Regards,
J.
On Jul 3, 2014, at 10:14 PM, Maxime Ripard  
wrote:

> 
> Adapt the ramc mapping code to handle multiple ram controllers in the DT.
> 
> Signed-off-by: Maxime Ripard 
> ---
> arch/arm/mach-at91/setup.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index 9c4c7fb323fb..cc520596f23b 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -393,24 +393,26 @@ static void at91_dt_ramc(void)
> {
>   struct device_node *np;
>   const struct of_device_id *of_id;
> + int idx = 0;
> 
> - np = of_find_matching_node(NULL, ramc_ids);
> - if (!np)
> - panic(pr_fmt("unable to find compatible ram controller node in 
> dtb\n"));
> + for_each_matching_node(np, ramc_ids) {
> + at91_ramc_base[idx] = of_iomap(np, 0);
> + if (!at91_ramc_base[idx])
> + panic(pr_fmt("unable to map ramc[%d] cpu registers\n"), 
> idx);
> 
> - at91_ramc_base[0] = of_iomap(np, 0);
> - if (!at91_ramc_base[0])
> - panic(pr_fmt("unable to map ramc[0] cpu registers\n"));
> - /* the controller may have 2 banks */
> - at91_ramc_base[1] = of_iomap(np, 1);
> + idx++;
> + }
> +
> + if (!idx)
> + panic(pr_fmt("unable to find compatible ram controller node in 
> dtb\n"));
> 
>   of_id = of_match_node(ramc_ids, np);
> - if (!of_id)
> + if (!of_id) {
>   pr_warn("ramc no standby function available\n");
> - else
> - at91_pm_set_standby(of_id->data);
> + return;
> + }
> 
> - of_node_put(np);
> + at91_pm_set_standby(of_id->data);
> }
> 
> static struct of_device_id shdwc_ids[] = {
> -- 
> 2.0.1
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/18] power: reset: Add AT91 reset driver

[Jean-Christophe PLAGNIOL-VILLARD]

NACK


On Jul 3, 2014, at 10:14 PM, Maxime Ripard  
wrote:

> 
> Implement the reset behaviour of the various AT91 SoCS in drivers/power/reset.
> 
> It used to be (and still is) located in arch/arm/mach-at91, and in order to
> preserve bisectability is not removed yet, but every board should be converted
> to use this driver instead.
> 
> Signed-off-by: Maxime Ripard 
> ---
> drivers/power/reset/Kconfig  |   7 ++
> drivers/power/reset/Makefile |   1 +
> drivers/power/reset/at91-reset.c | 202 +++
> 3 files changed, 210 insertions(+)
> create mode 100644 drivers/power/reset/at91-reset.c
> 
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index 19d546c5edfa..b3fef01d7cbb 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -14,6 +14,13 @@ config POWER_RESET_AS3722
>   help
> This driver supports turning off board via a ams AS3722 power-off.
> 
> +config POWER_RESET_AT91_RESET
> + bool "Atmel AT91 reset driver"
> + default SOC_AT91SAM9 || SOC_SAMA5
> + help
> +   This driver supports restart for Atmel AT91SAM9 and SAMA5
> +   SoCs
> +
> config POWER_RESET_AXXIA
>   bool "LSI Axxia reset driver"
>   depends on ARCH_AXXIA
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index dde2e8bbac53..1599214b91d9 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
> +obj-$(CONFIG_POWER_RESET_AT91_RESET) += at91-reset.o
> obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
> obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
> obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> diff --git a/drivers/power/reset/at91-reset.c 
> b/drivers/power/reset/at91-reset.c
> new file mode 100644
> index ..878547410acb
> --- /dev/null
> +++ b/drivers/power/reset/at91-reset.c
> @@ -0,0 +1,202 @@
> +/*
> + * Atmel AT91 SAM9 SoCs reset code
> + *
> + * Copyright (C) 2014 Maxime Ripard
> + *
> + * Maxime Ripard 

you can not own the copyright as it’s basically a copy of other people code
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#define AT91_RSTC_CR 0x00/* Reset Controller Control Register */
> +#define  AT91_RSTC_PROCRST   BIT(0)  /* Processor Reset */
> +#define  AT91_RSTC_PERRSTBIT(2)  /* Peripheral Reset */
> +#define  AT91_RSTC_EXTRSTBIT(3)  /* External Reset */
> +#define  AT91_RSTC_KEY   (0xa5 << 24)/* KEY Password */
> +
> +#define AT91_RSTC_SR 0x04/* Reset Controller Status Register */
> +#define  AT91_RSTC_URSTS BIT(0)  /* User Reset Status */
> +#define  AT91_RSTC_RSTTYPGENMASK(10, 8)  /* Reset Type */
> +#define  AT91_RSTC_NRSTL BIT(16) /* NRST Pin Level */
> +#define  AT91_RSTC_SRCMP BIT(17) /* Software Reset 
> Command in Progress */
> +
> +#define AT91_RSTC_MR 0x08/* Reset Controller Mode Register */
> +#define  AT91_RSTC_URSTENBIT(0)  /* User Reset Enable */
> +#define  AT91_RSTC_URSTIEN   BIT(4)  /* User Reset Interrupt 
> Enable */
> +#define  AT91_RSTC_ERSTL GENMASK(11, 8)  /* External Reset 
> Length */
> +
> +enum reset_type {
> + RESET_TYPE_GENERAL  = 0,
> + RESET_TYPE_WAKEUP   = 1,
> + RESET_TYPE_WATCHDOG = 2,
> + RESET_TYPE_SOFTWARE = 3,
> + RESET_TYPE_USER = 4,
> +};
> +
> +static void __iomem *at91_ramc_base[2], *at91_rstc_base;
> +
> +static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
> +{
> + asm volatile(
> + ".balign 32\n\t"
> +
> + "str%2, [%0, #" __stringify(AT91_SDRAMC_TR) "]\n\t"
> + "str%3, [%0, #" __stringify(AT91_SDRAMC_LPR) "]\n\t"
> + "str%4, [%1, #" __stringify(AT91_RSTC_CR) "]\n\t"
> +
> + "b  .\n\t"
> + :
> + : "r" (at91_ramc_base[0]),
> +   "r" (at91_rstc_base),
> +   "r" (1),
> +   "r" (AT91_SDRAMC_LPCB_POWER_DOWN),
> +   "r" (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST));
> +}
> +
> +static void at91sam9g45_restart(enum reboot_mode mode, const char *cmd)
> +{
> + asm volatile(
> + "cmp%1, #0\n\t"
> + "beq1f\n\t"
> +
> + "ldrr0, [%1]\n\t"
> + "cmpr0, #0\n\t"
> +
> + ".balign 32\n\t"
> +
> + "1: str %3, [%0, #" __stringify(AT91_DDRSDRC_RTR) 
> "]\n\t"
> + "   str %4, [%0, #" 

Re: [PATCH 12/18] power: reset: Add AT91 poweroff driver

[Jean-Christophe PLAGNIOL-VILLARD]

On Jul 3, 2014, at 10:14 PM, Maxime Ripard  
wrote:

> 
> Add a driver to handle the shutdown of the Atmel SoCs. This code used to be
> (and still is) in arch/arm/mach-at91. We didn't removed it yet so that we can
> convert all the boards to using this driver, before removing it entirely in a
> separate patch.
> 
> Signed-off-by: Maxime Ripard 
> ---
> drivers/power/reset/Kconfig |   7 ++
> drivers/power/reset/Makefile|   1 +
> drivers/power/reset/at91-poweroff.c | 156 
> 3 files changed, 164 insertions(+)
> create mode 100644 drivers/power/reset/at91-poweroff.c
> 
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index b3fef01d7cbb..f9d53af50ec0 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -14,6 +14,13 @@ config POWER_RESET_AS3722
>   help
> This driver supports turning off board via a ams AS3722 power-off.
> 
> +config POWER_RESET_AT91_POWEROFF
> + bool "Atmel AT91 poweroff driver"
> + default SOC_AT91SAM9 || SOC_SAMA5
> + help
> +   This driver supports poweroff for Atmel AT91SAM9 and SAMA5
> +   SoCs
> +
> config POWER_RESET_AT91_RESET
>   bool "Atmel AT91 reset driver"
>   default SOC_AT91SAM9 || SOC_SAMA5
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 1599214b91d9..8bf941bac3da 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
> +obj-$(CONFIG_POWER_RESET_AT91_POWEROFF) += at91-poweroff.o
> obj-$(CONFIG_POWER_RESET_AT91_RESET) += at91-reset.o
> obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
> obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
> diff --git a/drivers/power/reset/at91-poweroff.c 
> b/drivers/power/reset/at91-poweroff.c
> new file mode 100644
> index ..2f2a69e9bae3
> --- /dev/null
> +++ b/drivers/power/reset/at91-poweroff.c
> @@ -0,0 +1,156 @@
> +/*
> + * Atmel AT91 SAM9 SoCs reset code
> + *
> + * Copyright (C) 2014 Maxime Ripard
> + *
> + * Maxime Ripard 
> + *

As it’s mostly a copy of other people work you can not claim the copyright
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define AT91_SHDW_CR 0x00/* Shut Down Control Register */
> +#define  AT91_SHDW_SHDW  BIT(0)  /* Shut Down 
> command */
> +#define  AT91_SHDW_KEY   (0xa5 << 24)/* KEY Password 
> */
> +
> +#define AT91_SHDW_MR 0x04/* Shut Down Mode Register */
> +#define  AT91_SHDW_WKMODE0   GENMASK(2, 0)   /* Wake-up 0 
> Mode Selection */
> +#define  AT91_SHDW_CPTWK0_MAX0xf /* Maximum 
> Counter On Wake Up 0 */
> +#define  AT91_SHDW_CPTWK0(AT91_SHDW_CPTWK0_MAX << 4) /* Counter 
> On Wake Up 0 */
> +#define  AT91_SHDW_CPTWK0_(x)((x) << 4)
> +#define  AT91_SHDW_RTTWKEN   BIT(16) /* Real Time 
> Timer Wake-up Enable */
> +#define  AT91_SHDW_RTCWKEN   BIT(17) /* Real Time 
> Clock Wake-up Enable */
> +
> +#define AT91_SHDW_SR 0x08/* Shut Down Status Register */
> +#define  AT91_SHDW_WAKEUP0   BIT(0)  /* Wake-up 0 
> Status */
> +#define  AT91_SHDW_RTTWK BIT(16) /* Real-time 
> Timer Wake-up */
> +#define  AT91_SHDW_RTCWK BIT(17) /* Real-time 
> Clock Wake-up [SAM9RL] */
> +
> +enum wakeup_type {
> + AT91_SHDW_WKMODE0_NONE  = 0,
> + AT91_SHDW_WKMODE0_HIGH  = 1,
> + AT91_SHDW_WKMODE0_LOW   = 2,
> + AT91_SHDW_WKMODE0_ANYLEVEL  = 3,
> +};
> +
> +static const char *shdwc_wakeup_modes[] = {
> + [AT91_SHDW_WKMODE0_NONE]= "none",
> + [AT91_SHDW_WKMODE0_HIGH]= "high",
> + [AT91_SHDW_WKMODE0_LOW] = "low",
> + [AT91_SHDW_WKMODE0_ANYLEVEL]= "any",
> +};
> +
> +static void __iomem *at91_shdwc_base;
> +
> +static void __init at91_wakeup_status(void)
> +{
> + u32 reg = readl(at91_shdwc_base);
> + char *reason = "unknown";
> +
> + /* Simple power-on, just bail out */
> + if (!reg)
> + return;
> +
> + if (reg & AT91_SHDW_RTTWK)
> + reason = "RTT";
> + else if (reg & AT91_SHDW_RTCWK)
> + reason = "RTC";
> +
> + pr_info("AT91: Wake-Up source: %s\n", reason);
> +}
> +
> +static void at91_poweroff(void)
> +{
> + writel(AT91_SHDW_KEY | AT91_SHDW_SHDW, at91_shdwc_base + AT91_SHDW_CR);
> +}
> +
> +const enum wakeup_type at91_poweroff_get_wakeup_mode(struct device_node *np)
> +{
> + const char *pm;
> + int err, i;
> +
> + err = of_property_read_string(np, "atmel,wakeup-mode", 

Re: [PATCH 12/18] power: reset: Add AT91 poweroff driver

[Jean-Christophe PLAGNIOL-VILLARD]

On Jul 3, 2014, at 10:14 PM, Maxime Ripard maxime.rip...@free-electrons.com 
wrote:

 
 Add a driver to handle the shutdown of the Atmel SoCs. This code used to be
 (and still is) in arch/arm/mach-at91. We didn't removed it yet so that we can
 convert all the boards to using this driver, before removing it entirely in a
 separate patch.
 
 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
 ---
 drivers/power/reset/Kconfig |   7 ++
 drivers/power/reset/Makefile|   1 +
 drivers/power/reset/at91-poweroff.c | 156 
 3 files changed, 164 insertions(+)
 create mode 100644 drivers/power/reset/at91-poweroff.c
 
 diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
 index b3fef01d7cbb..f9d53af50ec0 100644
 --- a/drivers/power/reset/Kconfig
 +++ b/drivers/power/reset/Kconfig
 @@ -14,6 +14,13 @@ config POWER_RESET_AS3722
   help
 This driver supports turning off board via a ams AS3722 power-off.
 
 +config POWER_RESET_AT91_POWEROFF
 + bool Atmel AT91 poweroff driver
 + default SOC_AT91SAM9 || SOC_SAMA5
 + help
 +   This driver supports poweroff for Atmel AT91SAM9 and SAMA5
 +   SoCs
 +
 config POWER_RESET_AT91_RESET
   bool Atmel AT91 reset driver
   default SOC_AT91SAM9 || SOC_SAMA5
 diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
 index 1599214b91d9..8bf941bac3da 100644
 --- a/drivers/power/reset/Makefile
 +++ b/drivers/power/reset/Makefile
 @@ -1,4 +1,5 @@
 obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
 +obj-$(CONFIG_POWER_RESET_AT91_POWEROFF) += at91-poweroff.o
 obj-$(CONFIG_POWER_RESET_AT91_RESET) += at91-reset.o
 obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
 obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
 diff --git a/drivers/power/reset/at91-poweroff.c 
 b/drivers/power/reset/at91-poweroff.c
 new file mode 100644
 index ..2f2a69e9bae3
 --- /dev/null
 +++ b/drivers/power/reset/at91-poweroff.c
 @@ -0,0 +1,156 @@
 +/*
 + * Atmel AT91 SAM9 SoCs reset code
 + *
 + * Copyright (C) 2014 Maxime Ripard
 + *
 + * Maxime Ripard maxime.rip...@free-electrons.com
 + *

As it’s mostly a copy of other people work you can not claim the copyright
 + * This file is licensed under the terms of the GNU General Public
 + * License version 2.  This program is licensed as is without any
 + * warranty of any kind, whether express or implied.
 + */
 +
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/platform_device.h
 +#include linux/printk.h
 +
 +#define AT91_SHDW_CR 0x00/* Shut Down Control Register */
 +#define  AT91_SHDW_SHDW  BIT(0)  /* Shut Down 
 command */
 +#define  AT91_SHDW_KEY   (0xa5  24)/* KEY Password 
 */
 +
 +#define AT91_SHDW_MR 0x04/* Shut Down Mode Register */
 +#define  AT91_SHDW_WKMODE0   GENMASK(2, 0)   /* Wake-up 0 
 Mode Selection */
 +#define  AT91_SHDW_CPTWK0_MAX0xf /* Maximum 
 Counter On Wake Up 0 */
 +#define  AT91_SHDW_CPTWK0(AT91_SHDW_CPTWK0_MAX  4) /* Counter 
 On Wake Up 0 */
 +#define  AT91_SHDW_CPTWK0_(x)((x)  4)
 +#define  AT91_SHDW_RTTWKEN   BIT(16) /* Real Time 
 Timer Wake-up Enable */
 +#define  AT91_SHDW_RTCWKEN   BIT(17) /* Real Time 
 Clock Wake-up Enable */
 +
 +#define AT91_SHDW_SR 0x08/* Shut Down Status Register */
 +#define  AT91_SHDW_WAKEUP0   BIT(0)  /* Wake-up 0 
 Status */
 +#define  AT91_SHDW_RTTWK BIT(16) /* Real-time 
 Timer Wake-up */
 +#define  AT91_SHDW_RTCWK BIT(17) /* Real-time 
 Clock Wake-up [SAM9RL] */
 +
 +enum wakeup_type {
 + AT91_SHDW_WKMODE0_NONE  = 0,
 + AT91_SHDW_WKMODE0_HIGH  = 1,
 + AT91_SHDW_WKMODE0_LOW   = 2,
 + AT91_SHDW_WKMODE0_ANYLEVEL  = 3,
 +};
 +
 +static const char *shdwc_wakeup_modes[] = {
 + [AT91_SHDW_WKMODE0_NONE]= none,
 + [AT91_SHDW_WKMODE0_HIGH]= high,
 + [AT91_SHDW_WKMODE0_LOW] = low,
 + [AT91_SHDW_WKMODE0_ANYLEVEL]= any,
 +};
 +
 +static void __iomem *at91_shdwc_base;
 +
 +static void __init at91_wakeup_status(void)
 +{
 + u32 reg = readl(at91_shdwc_base);
 + char *reason = unknown;
 +
 + /* Simple power-on, just bail out */
 + if (!reg)
 + return;
 +
 + if (reg  AT91_SHDW_RTTWK)
 + reason = RTT;
 + else if (reg  AT91_SHDW_RTCWK)
 + reason = RTC;
 +
 + pr_info(AT91: Wake-Up source: %s\n, reason);
 +}
 +
 +static void at91_poweroff(void)
 +{
 + writel(AT91_SHDW_KEY | AT91_SHDW_SHDW, at91_shdwc_base + AT91_SHDW_CR);
 +}
 +
 +const enum wakeup_type at91_poweroff_get_wakeup_mode(struct device_node *np)
 +{
 + const char *pm;
 + int err, i;
 +
 + err = of_property_read_string(np, atmel,wakeup-mode, pm);

Re: [PATCH 05/18] power: reset: Add AT91 reset driver

[Jean-Christophe PLAGNIOL-VILLARD]

NACK


On Jul 3, 2014, at 10:14 PM, Maxime Ripard maxime.rip...@free-electrons.com 
wrote:

 
 Implement the reset behaviour of the various AT91 SoCS in drivers/power/reset.
 
 It used to be (and still is) located in arch/arm/mach-at91, and in order to
 preserve bisectability is not removed yet, but every board should be converted
 to use this driver instead.
 
 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
 ---
 drivers/power/reset/Kconfig  |   7 ++
 drivers/power/reset/Makefile |   1 +
 drivers/power/reset/at91-reset.c | 202 +++
 3 files changed, 210 insertions(+)
 create mode 100644 drivers/power/reset/at91-reset.c
 
 diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
 index 19d546c5edfa..b3fef01d7cbb 100644
 --- a/drivers/power/reset/Kconfig
 +++ b/drivers/power/reset/Kconfig
 @@ -14,6 +14,13 @@ config POWER_RESET_AS3722
   help
 This driver supports turning off board via a ams AS3722 power-off.
 
 +config POWER_RESET_AT91_RESET
 + bool Atmel AT91 reset driver
 + default SOC_AT91SAM9 || SOC_SAMA5
 + help
 +   This driver supports restart for Atmel AT91SAM9 and SAMA5
 +   SoCs
 +
 config POWER_RESET_AXXIA
   bool LSI Axxia reset driver
   depends on ARCH_AXXIA
 diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
 index dde2e8bbac53..1599214b91d9 100644
 --- a/drivers/power/reset/Makefile
 +++ b/drivers/power/reset/Makefile
 @@ -1,4 +1,5 @@
 obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
 +obj-$(CONFIG_POWER_RESET_AT91_RESET) += at91-reset.o
 obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
 obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
 obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
 diff --git a/drivers/power/reset/at91-reset.c 
 b/drivers/power/reset/at91-reset.c
 new file mode 100644
 index ..878547410acb
 --- /dev/null
 +++ b/drivers/power/reset/at91-reset.c
 @@ -0,0 +1,202 @@
 +/*
 + * Atmel AT91 SAM9 SoCs reset code
 + *
 + * Copyright (C) 2014 Maxime Ripard
 + *
 + * Maxime Ripard maxime.rip...@free-electrons.com

you can not own the copyright as it’s basically a copy of other people code
 + *
 + * This file is licensed under the terms of the GNU General Public
 + * License version 2.  This program is licensed as is without any
 + * warranty of any kind, whether express or implied.
 + */
 +
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_address.h
 +#include linux/platform_device.h
 +#include linux/reboot.h
 +
 +#include asm/system_misc.h
 +
 +#include mach/at91sam9_ddrsdr.h
 +#include mach/at91sam9_sdramc.h
 +
 +#define AT91_RSTC_CR 0x00/* Reset Controller Control Register */
 +#define  AT91_RSTC_PROCRST   BIT(0)  /* Processor Reset */
 +#define  AT91_RSTC_PERRSTBIT(2)  /* Peripheral Reset */
 +#define  AT91_RSTC_EXTRSTBIT(3)  /* External Reset */
 +#define  AT91_RSTC_KEY   (0xa5  24)/* KEY Password */
 +
 +#define AT91_RSTC_SR 0x04/* Reset Controller Status Register */
 +#define  AT91_RSTC_URSTS BIT(0)  /* User Reset Status */
 +#define  AT91_RSTC_RSTTYPGENMASK(10, 8)  /* Reset Type */
 +#define  AT91_RSTC_NRSTL BIT(16) /* NRST Pin Level */
 +#define  AT91_RSTC_SRCMP BIT(17) /* Software Reset 
 Command in Progress */
 +
 +#define AT91_RSTC_MR 0x08/* Reset Controller Mode Register */
 +#define  AT91_RSTC_URSTENBIT(0)  /* User Reset Enable */
 +#define  AT91_RSTC_URSTIEN   BIT(4)  /* User Reset Interrupt 
 Enable */
 +#define  AT91_RSTC_ERSTL GENMASK(11, 8)  /* External Reset 
 Length */
 +
 +enum reset_type {
 + RESET_TYPE_GENERAL  = 0,
 + RESET_TYPE_WAKEUP   = 1,
 + RESET_TYPE_WATCHDOG = 2,
 + RESET_TYPE_SOFTWARE = 3,
 + RESET_TYPE_USER = 4,
 +};
 +
 +static void __iomem *at91_ramc_base[2], *at91_rstc_base;
 +
 +static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
 +{
 + asm volatile(
 + .balign 32\n\t
 +
 + str%2, [%0, # __stringify(AT91_SDRAMC_TR) ]\n\t
 + str%3, [%0, # __stringify(AT91_SDRAMC_LPR) ]\n\t
 + str%4, [%1, # __stringify(AT91_RSTC_CR) ]\n\t
 +
 + b  .\n\t
 + :
 + : r (at91_ramc_base[0]),
 +   r (at91_rstc_base),
 +   r (1),
 +   r (AT91_SDRAMC_LPCB_POWER_DOWN),
 +   r (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST));
 +}
 +
 +static void at91sam9g45_restart(enum reboot_mode mode, const char *cmd)
 +{
 + asm volatile(
 + cmp%1, #0\n\t
 + beq1f\n\t
 +
 + ldrr0, [%1]\n\t
 + cmpr0, #0\n\t
 +
 + .balign 32\n\t
 +
 + 1: str %3, [%0, # __stringify(AT91_DDRSDRC_RTR) 
 

Re: [PATCH 04/18] AT91: Rework ramc mapping code

[Jean-Christophe PLAGNIOL-VILLARD]

patch 4 and 18 what is the difference?

Best Regards,
J.
On Jul 3, 2014, at 10:14 PM, Maxime Ripard maxime.rip...@free-electrons.com 
wrote:

 
 Adapt the ramc mapping code to handle multiple ram controllers in the DT.
 
 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
 ---
 arch/arm/mach-at91/setup.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)
 
 diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
 index 9c4c7fb323fb..cc520596f23b 100644
 --- a/arch/arm/mach-at91/setup.c
 +++ b/arch/arm/mach-at91/setup.c
 @@ -393,24 +393,26 @@ static void at91_dt_ramc(void)
 {
   struct device_node *np;
   const struct of_device_id *of_id;
 + int idx = 0;
 
 - np = of_find_matching_node(NULL, ramc_ids);
 - if (!np)
 - panic(pr_fmt(unable to find compatible ram controller node in 
 dtb\n));
 + for_each_matching_node(np, ramc_ids) {
 + at91_ramc_base[idx] = of_iomap(np, 0);
 + if (!at91_ramc_base[idx])
 + panic(pr_fmt(unable to map ramc[%d] cpu registers\n), 
 idx);
 
 - at91_ramc_base[0] = of_iomap(np, 0);
 - if (!at91_ramc_base[0])
 - panic(pr_fmt(unable to map ramc[0] cpu registers\n));
 - /* the controller may have 2 banks */
 - at91_ramc_base[1] = of_iomap(np, 1);
 + idx++;
 + }
 +
 + if (!idx)
 + panic(pr_fmt(unable to find compatible ram controller node in 
 dtb\n));
 
   of_id = of_match_node(ramc_ids, np);
 - if (!of_id)
 + if (!of_id) {
   pr_warn(ramc no standby function available\n);
 - else
 - at91_pm_set_standby(of_id-data);
 + return;
 + }
 
 - of_node_put(np);
 + at91_pm_set_standby(of_id-data);
 }
 
 static struct of_device_id shdwc_ids[] = {
 -- 
 2.0.1
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/18] AT91: Call at91_register_devices in the board files

[Jean-Christophe PLAGNIOL-VILLARD]

no do this at SoC level

Best Regards,
J.
On Jul 3, 2014, at 10:14 PM, Maxime Ripard maxime.rip...@free-electrons.com 
wrote:

 
 Make every board call the register_devices callback so that the devices
 declared by the SoC are registered.
 
 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
 ---
 arch/arm/mach-at91/board-afeb-9260v1.c  | 2 ++
 arch/arm/mach-at91/board-cam60.c| 2 ++
 arch/arm/mach-at91/board-cpu9krea.c | 2 ++
 arch/arm/mach-at91/board-flexibity.c| 2 ++
 arch/arm/mach-at91/board-sam9-l9260.c   | 2 ++
 arch/arm/mach-at91/board-sam9260ek.c| 2 ++
 arch/arm/mach-at91/board-sam9261ek.c| 2 ++
 arch/arm/mach-at91/board-sam9263ek.c| 2 ++
 arch/arm/mach-at91/board-sam9m10g45ek.c | 2 ++
 arch/arm/mach-at91/board-sam9rlek.c | 2 ++
 arch/arm/mach-at91/board-snapper9260.c  | 2 ++
 11 files changed, 22 insertions(+)
 
 diff --git a/arch/arm/mach-at91/board-afeb-9260v1.c 
 b/arch/arm/mach-at91/board-afeb-9260v1.c
 index 597c649170aa..fc9621ccb606 100644
 --- a/arch/arm/mach-at91/board-afeb-9260v1.c
 +++ b/arch/arm/mach-at91/board-afeb-9260v1.c
 @@ -167,6 +167,8 @@ static struct at91_cf_data afeb9260_cf_data = {
 
 static void __init afeb9260_board_init(void)
 {
 + at91_register_devices();
 +
   /* Serial */
   /* DBGU on ttyS0. (Rx  Tx only) */
   at91_register_uart(0, 0, 0);
 diff --git a/arch/arm/mach-at91/board-cam60.c 
 b/arch/arm/mach-at91/board-cam60.c
 index a30502c8d379..283655bd86c1 100644
 --- a/arch/arm/mach-at91/board-cam60.c
 +++ b/arch/arm/mach-at91/board-cam60.c
 @@ -170,6 +170,8 @@ static void __init cam60_add_device_nand(void)
 
 static void __init cam60_board_init(void)
 {
 + at91_register_devices();
 +
   /* Serial */
   /* DBGU on ttyS0. (Rx  Tx only) */
   at91_register_uart(0, 0, 0);
 diff --git a/arch/arm/mach-at91/board-cpu9krea.c 
 b/arch/arm/mach-at91/board-cpu9krea.c
 index 2037f78c84e7..29a89032bb9a 100644
 --- a/arch/arm/mach-at91/board-cpu9krea.c
 +++ b/arch/arm/mach-at91/board-cpu9krea.c
 @@ -322,6 +322,8 @@ static struct mci_platform_data __initdata 
 cpu9krea_mci0_data = {
 
 static void __init cpu9krea_board_init(void)
 {
 + at91_register_devices();
 +
   /* NOR */
   cpu9krea_add_device_nor();
   /* Serial */
 diff --git a/arch/arm/mach-at91/board-flexibity.c 
 b/arch/arm/mach-at91/board-flexibity.c
 index 68f1ab6bd08f..79bd411b0cee 100644
 --- a/arch/arm/mach-at91/board-flexibity.c
 +++ b/arch/arm/mach-at91/board-flexibity.c
 @@ -138,6 +138,8 @@ static struct gpio_led flexibity_leds[] = {
 
 static void __init flexibity_board_init(void)
 {
 + at91_register_devices();
 +
   /* Serial */
   /* DBGU on ttyS0. (Rx  Tx only) */
   at91_register_uart(0, 0, 0);
 diff --git a/arch/arm/mach-at91/board-sam9-l9260.c 
 b/arch/arm/mach-at91/board-sam9-l9260.c
 index d24dda67e2d3..70309404f366 100644
 --- a/arch/arm/mach-at91/board-sam9-l9260.c
 +++ b/arch/arm/mach-at91/board-sam9-l9260.c
 @@ -187,6 +187,8 @@ static struct gpio_led ek_leds[] = {
 
 static void __init ek_board_init(void)
 {
 + at91_register_devices();
 +
   /* Serial */
   /* DBGU on ttyS0. (Rx  Tx only) */
   at91_register_uart(0, 0, 0);
 diff --git a/arch/arm/mach-at91/board-sam9260ek.c 
 b/arch/arm/mach-at91/board-sam9260ek.c
 index 65dea12d685e..da9c5f1f2c49 100644
 --- a/arch/arm/mach-at91/board-sam9260ek.c
 +++ b/arch/arm/mach-at91/board-sam9260ek.c
 @@ -307,6 +307,8 @@ static void __init ek_add_device_buttons(void) {}
 
 static void __init ek_board_init(void)
 {
 + at91_register_devices();
 +
   /* Serial */
   /* DBGU on ttyS0. (Rx  Tx only) */
   at91_register_uart(0, 0, 0);
 diff --git a/arch/arm/mach-at91/board-sam9261ek.c 
 b/arch/arm/mach-at91/board-sam9261ek.c
 index 4637432de08f..d1be10b09ab3 100644
 --- a/arch/arm/mach-at91/board-sam9261ek.c
 +++ b/arch/arm/mach-at91/board-sam9261ek.c
 @@ -561,6 +561,8 @@ static struct gpio_led ek_leds[] = {
 
 static void __init ek_board_init(void)
 {
 + at91_register_devices();
 +
   /* Serial */
   /* DBGU on ttyS0. (Rx  Tx only) */
   at91_register_uart(0, 0, 0);
 diff --git a/arch/arm/mach-at91/board-sam9263ek.c 
 b/arch/arm/mach-at91/board-sam9263ek.c
 index cd2726ee5add..3f613d962d9b 100644
 --- a/arch/arm/mach-at91/board-sam9263ek.c
 +++ b/arch/arm/mach-at91/board-sam9263ek.c
 @@ -405,6 +405,8 @@ static struct at91_can_data ek_can_data = {
 
 static void __init ek_board_init(void)
 {
 + at91_register_devices();
 +
   /* Serial */
   /* DBGU on ttyS0. (Rx  Tx only) */
   at91_register_uart(0, 0, 0);
 diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c 
 b/arch/arm/mach-at91/board-sam9m10g45ek.c
 index 1ea61328f30d..33a7b19f7400 100644
 --- a/arch/arm/mach-at91/board-sam9m10g45ek.c
 +++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
 @@ -450,6 +450,8 @@ static struct platform_device *devices[] __initdata = {
 
 static void __init ek_board_init(void)
 {
 + at91_register_devices();
 +
   /* 

Re: [PATCH 05/18] power: reset: Add AT91 reset driver

[Jean-Christophe PLAGNIOL-VILLARD]

On Jul 3, 2014, at 10:59 PM, Maxime Ripard maxime.rip...@free-electrons.com 
wrote:

 On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe PLAGNIOL-VILLARD 
 wrote:
 +++ b/drivers/power/reset/at91-reset.c
 @@ -0,0 +1,202 @@
 +/*
 + * Atmel AT91 SAM9 SoCs reset code
 + *
 + * Copyright (C) 2014 Maxime Ripard
 + *
 + * Maxime Ripard maxime.rip...@free-electrons.com
 
 you can not own the copyright as it’s basically a copy of other
 people code
 
 The previous names are missing, right.
 
 + *
 + * This file is licensed under the terms of the GNU General Public
 + * License version 2.  This program is licensed as is without any
 + * warranty of any kind, whether express or implied.
 + */
 +
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of_address.h
 +#include linux/platform_device.h
 +#include linux/reboot.h
 +
 +#include asm/system_misc.h
 +
 +#include mach/at91sam9_ddrsdr.h
 +#include mach/at91sam9_sdramc.h
 +
 +#define AT91_RSTC_CR   0x00/* Reset Controller Control 
 Register */
 +#defineAT91_RSTC_PROCRST   BIT(0)  /* Processor Reset */
 +#defineAT91_RSTC_PERRSTBIT(2)  /* Peripheral Reset */
 +#defineAT91_RSTC_EXTRSTBIT(3)  /* External Reset */
 +#defineAT91_RSTC_KEY   (0xa5  24)/* KEY Password */
 +
 +#define AT91_RSTC_SR   0x04/* Reset Controller Status 
 Register */
 +#defineAT91_RSTC_URSTS BIT(0)  /* User Reset Status */
 +#defineAT91_RSTC_RSTTYPGENMASK(10, 8)  /* Reset Type */
 +#defineAT91_RSTC_NRSTL BIT(16) /* NRST Pin Level */
 +#defineAT91_RSTC_SRCMP BIT(17) /* Software Reset 
 Command in Progress */
 +
 +#define AT91_RSTC_MR   0x08/* Reset Controller Mode 
 Register */
 +#defineAT91_RSTC_URSTENBIT(0)  /* User Reset Enable */
 +#defineAT91_RSTC_URSTIEN   BIT(4)  /* User Reset Interrupt 
 Enable */
 +#defineAT91_RSTC_ERSTL GENMASK(11, 8)  /* External Reset 
 Length */
 +
 +enum reset_type {
 +   RESET_TYPE_GENERAL  = 0,
 +   RESET_TYPE_WAKEUP   = 1,
 +   RESET_TYPE_WATCHDOG = 2,
 +   RESET_TYPE_SOFTWARE = 3,
 +   RESET_TYPE_USER = 4,
 +};
 +
 +static void __iomem *at91_ramc_base[2], *at91_rstc_base;
 +
 +static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
 +{
 +   asm volatile(
 +   .balign 32\n\t
 +
 +   str%2, [%0, # __stringify(AT91_SDRAMC_TR) ]\n\t
 +   str%3, [%0, # __stringify(AT91_SDRAMC_LPR) ]\n\t
 +   str%4, [%1, # __stringify(AT91_RSTC_CR) ]\n\t
 +
 +   b  .\n\t
 +   :
 +   : r (at91_ramc_base[0]),
 + r (at91_rstc_base),
 + r (1),
 + r (AT91_SDRAMC_LPCB_POWER_DOWN),
 + r (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST));
 +}
 +
 +static void at91sam9g45_restart(enum reboot_mode mode, const char *cmd)
 +{
 +   asm volatile(
 +   cmp%1, #0\n\t
 +   beq1f\n\t
 +
 +   ldrr0, [%1]\n\t
 +   cmpr0, #0\n\t
 +
 +   .balign 32\n\t
 +
 +   1: str %3, [%0, # __stringify(AT91_DDRSDRC_RTR) 
 ]\n\t
 +  str %4, [%0, # __stringify(AT91_DDRSDRC_RTR) 
 ]\n\t
 +  strne   %3, [%1, # __stringify(AT91_DDRSDRC_RTR) 
 ]\n\t
 +  strne   %4, [%1, # __stringify(AT91_DDRSDRC_RTR) 
 ]\n\t
 +  str %5, [%2, # __stringify(AT91_RSTC_CR) ]\n\t
 +
 +  b   .\n\t
 +   :
 +   : r (at91_ramc_base[0]),
 + r (at91_ramc_base[1]),
 + r (at91_rstc_base),
 + r (1),
 + r (AT91_DDRSDRC_LPCB_POWER_DOWN),
 + r (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST)
 +   : r0);
 +}
 +
 move this to an assembly file more easy to read than a C code
 
 Nope. It's a pain to pass variable to an external assembly file, and
 this makes the use of global variable pretty much mandatory, which is
 definitely not great.

Not at all I did for the PM slow clock code just write a function and pas it as 
a parameter
you have 3

so basically you have to use the current and just pass at91_ramc_base[0], 
at91_ramc_base[1]
and at91_rstc_base
it’s 3 lignes of modification, if you have at91_ramc_base and at91_ramc_base 
same

so NACK
 
 
 +static void __init at91_reset_status(struct platform_device *pdev)
 +{
 +   u32 reg = readl(at91_rstc_base + AT91_RSTC_SR);
 +   char *reason;
 +
 +   switch ((reg  AT91_RSTC_RSTTYP)  8) {
 +   case RESET_TYPE_GENERAL:
 +   reason = general reset;
 +   break;
 +   case RESET_TYPE_WAKEUP:
 +   reason = wakeup;
 +   break;
 +   case RESET_TYPE_WATCHDOG:
 +   reason = watchdog reset;
 +   break;
 +   case RESET_TYPE_SOFTWARE:
 +   reason = software reset;
 +   break;
 +   case RESET_TYPE_USER

Re: [GIT PULL] at91: DT for 3.16 #2

[Jean-Christophe PLAGNIOL-VILLARD]

On May 20, 2014, at 1:50 PM, Olof Johansson  wrote:

> 
> On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote:
>> Arnd, Olof, Kevin,
>> 
>> More DT material for AT91. Some fixes that apply on what was merged for 3.15
>> but that are not very critical.
>> The other patches are feature additions to old or very recent product/board:
>> at91sam9261 or sama5d3 Xplained.
>> 
>> Thanks, best regards,
>> 
>> The following changes since commit 27a96a0364787d2b41d2a72d08143d95263e1b07:
>> 
>>  ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 +0200)
>> 
>> are available in the git repository at:
>> 
>>  git://github.com/at91linux/linux-at91.git tags/at91-dt2
>> 
>> for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef:
>> 
>>  ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node 
>> (2014-05-12 16:48:54 +0200)
> 
> Merged, but:
> 
>> arch/arm/boot/dts/at91-sama5d3_xplained.dts |  62 +++
>> arch/arm/boot/dts/at91sam9261.dtsi  | 114 
>> ++--
>> arch/arm/boot/dts/at91sam9rl.dtsi   |   7 +-
>> arch/arm/boot/dts/sama5d3.dtsi  |  78 +++
> 
> Grmbl. I remember being somewhat annoyed that you didn't use at91 prefix
> when you introduced the sama5d3 dtsi files, but please don't start using
> it on a random board like this, especially when other boards just use
> the sama5d3_.dts format.
> 
> Care to fix this up in time for 3.16 merge window?

there is a small issue here Atmel drop the at91 in the soc name

Best Regards,
J.
> 
> 
> Thanks,
> 
> -Olof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] at91: DT for 3.16 #2

[Jean-Christophe PLAGNIOL-VILLARD]

On May 20, 2014, at 1:50 PM, Olof Johansson o...@lixom.net wrote:

 
 On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote:
 Arnd, Olof, Kevin,
 
 More DT material for AT91. Some fixes that apply on what was merged for 3.15
 but that are not very critical.
 The other patches are feature additions to old or very recent product/board:
 at91sam9261 or sama5d3 Xplained.
 
 Thanks, best regards,
 
 The following changes since commit 27a96a0364787d2b41d2a72d08143d95263e1b07:
 
  ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 +0200)
 
 are available in the git repository at:
 
  git://github.com/at91linux/linux-at91.git tags/at91-dt2
 
 for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef:
 
  ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node 
 (2014-05-12 16:48:54 +0200)
 
 Merged, but:
 
 arch/arm/boot/dts/at91-sama5d3_xplained.dts |  62 +++
 arch/arm/boot/dts/at91sam9261.dtsi  | 114 
 ++--
 arch/arm/boot/dts/at91sam9rl.dtsi   |   7 +-
 arch/arm/boot/dts/sama5d3.dtsi  |  78 +++
 
 Grmbl. I remember being somewhat annoyed that you didn't use at91 prefix
 when you introduced the sama5d3 dtsi files, but please don't start using
 it on a random board like this, especially when other boards just use
 the sama5d3_board.dts format.
 
 Care to fix this up in time for 3.16 merge window?

there is a small issue here Atmel drop the at91 in the soc name

Best Regards,
J.
 
 
 Thanks,
 
 -Olof

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: remove ISI code for AT91SAM9263

[Jean-Christophe PLAGNIOL-VILLARD]

On May 15, 2014, at 4:34 PM, Paul Bolle  wrote:

> 
> In v2.6.25 code was added for an Image Sensor Interface (ISI) for
> AT91SAM9263. That code depended on the Kconfig macro
> CONFIG_VIDEO_AT91_ISI and its MODULE variant. The related Kconfig symbol
> has never been added to the tree. The net effect of this was that
> at91_add_device_isi() was a NOP. No one noticed because no callers of
> that function were added to the tree at that time.
> 
> The first caller of a function with that name was added in v3.4. But
> that caller apparently only called the function defined for AT91SAM9G45.
> (that function was also added in v3.4). So even then AT91SAM9263's NOP
> version of at91_add_device_isi() remained unused. This means that the
> ISI code for AT91SAM9263 can be removed.
> 

Nack

this is just resources and allow until this is converted to DTS to have the 
pinctrl and register information

Best Regards,
J.

> Signed-off-by: Paul Bolle 
> ---
> Untested!
> 
> Could someone please verify that this definition of
> at91_add_device_isi() really never will be called.
> 
> arch/arm/mach-at91/at91sam9263_devices.c | 57 
> 1 file changed, 57 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/at91sam9263_devices.c 
> b/arch/arm/mach-at91/at91sam9263_devices.c
> index 43d53d6156dd..f2dab0a872a1 100644
> --- a/arch/arm/mach-at91/at91sam9263_devices.c
> +++ b/arch/arm/mach-at91/at91sam9263_devices.c
> @@ -897,63 +897,6 @@ void __init at91_add_device_lcdc(struct 
> atmel_lcdfb_pdata *data) {}
> 
> 
> /* 
> - *  Image Sensor Interface
> - *  */
> -
> -#if defined(CONFIG_VIDEO_AT91_ISI) || defined(CONFIG_VIDEO_AT91_ISI_MODULE)
> -
> -struct resource isi_resources[] = {
> - [0] = {
> - .start  = AT91SAM9263_BASE_ISI,
> - .end= AT91SAM9263_BASE_ISI + SZ_16K - 1,
> - .flags  = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start  = NR_IRQS_LEGACY + AT91SAM9263_ID_ISI,
> - .end= NR_IRQS_LEGACY + AT91SAM9263_ID_ISI,
> - .flags  = IORESOURCE_IRQ,
> - },
> -};
> -
> -static struct platform_device at91sam9263_isi_device = {
> - .name   = "at91_isi",
> - .id = -1,
> - .resource   = isi_resources,
> - .num_resources  = ARRAY_SIZE(isi_resources),
> -};
> -
> -void __init at91_add_device_isi(struct isi_platform_data *data,
> - bool use_pck_as_mck)
> -{
> - at91_set_A_periph(AT91_PIN_PE0, 0); /* ISI_D0 */
> - at91_set_A_periph(AT91_PIN_PE1, 0); /* ISI_D1 */
> - at91_set_A_periph(AT91_PIN_PE2, 0); /* ISI_D2 */
> - at91_set_A_periph(AT91_PIN_PE3, 0); /* ISI_D3 */
> - at91_set_A_periph(AT91_PIN_PE4, 0); /* ISI_D4 */
> - at91_set_A_periph(AT91_PIN_PE5, 0); /* ISI_D5 */
> - at91_set_A_periph(AT91_PIN_PE6, 0); /* ISI_D6 */
> - at91_set_A_periph(AT91_PIN_PE7, 0); /* ISI_D7 */
> - at91_set_A_periph(AT91_PIN_PE8, 0); /* ISI_PCK */
> - at91_set_A_periph(AT91_PIN_PE9, 0); /* ISI_HSYNC */
> - at91_set_A_periph(AT91_PIN_PE10, 0);/* ISI_VSYNC */
> - at91_set_B_periph(AT91_PIN_PE12, 0);/* ISI_PD8 */
> - at91_set_B_periph(AT91_PIN_PE13, 0);/* ISI_PD9 */
> - at91_set_B_periph(AT91_PIN_PE14, 0);/* ISI_PD10 */
> - at91_set_B_periph(AT91_PIN_PE15, 0);/* ISI_PD11 */
> -
> - if (use_pck_as_mck) {
> - at91_set_B_periph(AT91_PIN_PE11, 0);/* ISI_MCK (PCK3) */
> -
> - /* TODO: register the PCK for ISI_MCK and set its parent */
> - }
> -}
> -#else
> -void __init at91_add_device_isi(struct isi_platform_data *data,
> - bool use_pck_as_mck) {}
> -#endif
> -
> -
> -/* 
>  *  Timer/Counter block
>  *  */
> 
> -- 
> 1.9.0
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91: remove ISI code for AT91SAM9263

[Jean-Christophe PLAGNIOL-VILLARD]

On May 15, 2014, at 4:34 PM, Paul Bolle pebo...@tiscali.nl wrote:

 
 In v2.6.25 code was added for an Image Sensor Interface (ISI) for
 AT91SAM9263. That code depended on the Kconfig macro
 CONFIG_VIDEO_AT91_ISI and its MODULE variant. The related Kconfig symbol
 has never been added to the tree. The net effect of this was that
 at91_add_device_isi() was a NOP. No one noticed because no callers of
 that function were added to the tree at that time.
 
 The first caller of a function with that name was added in v3.4. But
 that caller apparently only called the function defined for AT91SAM9G45.
 (that function was also added in v3.4). So even then AT91SAM9263's NOP
 version of at91_add_device_isi() remained unused. This means that the
 ISI code for AT91SAM9263 can be removed.
 

Nack

this is just resources and allow until this is converted to DTS to have the 
pinctrl and register information

Best Regards,
J.

 Signed-off-by: Paul Bolle pebo...@tiscali.nl
 ---
 Untested!
 
 Could someone please verify that this definition of
 at91_add_device_isi() really never will be called.
 
 arch/arm/mach-at91/at91sam9263_devices.c | 57 
 1 file changed, 57 deletions(-)
 
 diff --git a/arch/arm/mach-at91/at91sam9263_devices.c 
 b/arch/arm/mach-at91/at91sam9263_devices.c
 index 43d53d6156dd..f2dab0a872a1 100644
 --- a/arch/arm/mach-at91/at91sam9263_devices.c
 +++ b/arch/arm/mach-at91/at91sam9263_devices.c
 @@ -897,63 +897,6 @@ void __init at91_add_device_lcdc(struct 
 atmel_lcdfb_pdata *data) {}
 
 
 /* 
 - *  Image Sensor Interface
 - *  */
 -
 -#if defined(CONFIG_VIDEO_AT91_ISI) || defined(CONFIG_VIDEO_AT91_ISI_MODULE)
 -
 -struct resource isi_resources[] = {
 - [0] = {
 - .start  = AT91SAM9263_BASE_ISI,
 - .end= AT91SAM9263_BASE_ISI + SZ_16K - 1,
 - .flags  = IORESOURCE_MEM,
 - },
 - [1] = {
 - .start  = NR_IRQS_LEGACY + AT91SAM9263_ID_ISI,
 - .end= NR_IRQS_LEGACY + AT91SAM9263_ID_ISI,
 - .flags  = IORESOURCE_IRQ,
 - },
 -};
 -
 -static struct platform_device at91sam9263_isi_device = {
 - .name   = at91_isi,
 - .id = -1,
 - .resource   = isi_resources,
 - .num_resources  = ARRAY_SIZE(isi_resources),
 -};
 -
 -void __init at91_add_device_isi(struct isi_platform_data *data,
 - bool use_pck_as_mck)
 -{
 - at91_set_A_periph(AT91_PIN_PE0, 0); /* ISI_D0 */
 - at91_set_A_periph(AT91_PIN_PE1, 0); /* ISI_D1 */
 - at91_set_A_periph(AT91_PIN_PE2, 0); /* ISI_D2 */
 - at91_set_A_periph(AT91_PIN_PE3, 0); /* ISI_D3 */
 - at91_set_A_periph(AT91_PIN_PE4, 0); /* ISI_D4 */
 - at91_set_A_periph(AT91_PIN_PE5, 0); /* ISI_D5 */
 - at91_set_A_periph(AT91_PIN_PE6, 0); /* ISI_D6 */
 - at91_set_A_periph(AT91_PIN_PE7, 0); /* ISI_D7 */
 - at91_set_A_periph(AT91_PIN_PE8, 0); /* ISI_PCK */
 - at91_set_A_periph(AT91_PIN_PE9, 0); /* ISI_HSYNC */
 - at91_set_A_periph(AT91_PIN_PE10, 0);/* ISI_VSYNC */
 - at91_set_B_periph(AT91_PIN_PE12, 0);/* ISI_PD8 */
 - at91_set_B_periph(AT91_PIN_PE13, 0);/* ISI_PD9 */
 - at91_set_B_periph(AT91_PIN_PE14, 0);/* ISI_PD10 */
 - at91_set_B_periph(AT91_PIN_PE15, 0);/* ISI_PD11 */
 -
 - if (use_pck_as_mck) {
 - at91_set_B_periph(AT91_PIN_PE11, 0);/* ISI_MCK (PCK3) */
 -
 - /* TODO: register the PCK for ISI_MCK and set its parent */
 - }
 -}
 -#else
 -void __init at91_add_device_isi(struct isi_platform_data *data,
 - bool use_pck_as_mck) {}
 -#endif
 -
 -
 -/* 
  *  Timer/Counter block
  *  */
 
 -- 
 1.9.0
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fbdev: fix possible NULL pointer derefernce

[Jean-Christophe PLAGNIOL-VILLARD]

On Apr 16, 2014, at 5:40 PM, Daeseok Youn  wrote:

> 
> The spec->modedb can be NULL by fb_create_modedb().
> 
> And also smatch says:
> drivers/video/fbdev/core/fbmon.c:975 fb_edid_to_monspecs() error:
> potential null dereference 'specs->modedb'.
> (fb_create_modedb returns null)
> 
> Signed-off-by: Daeseok Youn 
> ---
> drivers/video/fbdev/core/fbmon.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbmon.c 
> b/drivers/video/fbdev/core/fbmon.c
> index c204ebe..db274ca 100644
> --- a/drivers/video/fbdev/core/fbmon.c
> +++ b/drivers/video/fbdev/core/fbmon.c
> @@ -966,6 +966,9 @@ void fb_edid_to_monspecs(unsigned char *edid, struct 
> fb_monspecs *specs)
> 
>   specs->modedb = fb_create_modedb(edid, >modedb_len);
> 
> + if (!specs->modedb)
> + return;
> +

we need to return an error and trace it

Best Regards,
J.
>   /*
>* Workaround for buggy EDIDs that sets that the first
>* detailed timing is preferred but has not detailed
> -- 
> 1.7.4.4
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fbdev: fix possible NULL pointer derefernce

[Jean-Christophe PLAGNIOL-VILLARD]

On Apr 16, 2014, at 5:40 PM, Daeseok Youn daeseok.y...@gmail.com wrote:

 
 The spec-modedb can be NULL by fb_create_modedb().
 
 And also smatch says:
 drivers/video/fbdev/core/fbmon.c:975 fb_edid_to_monspecs() error:
 potential null dereference 'specs-modedb'.
 (fb_create_modedb returns null)
 
 Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
 ---
 drivers/video/fbdev/core/fbmon.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/video/fbdev/core/fbmon.c 
 b/drivers/video/fbdev/core/fbmon.c
 index c204ebe..db274ca 100644
 --- a/drivers/video/fbdev/core/fbmon.c
 +++ b/drivers/video/fbdev/core/fbmon.c
 @@ -966,6 +966,9 @@ void fb_edid_to_monspecs(unsigned char *edid, struct 
 fb_monspecs *specs)
 
   specs-modedb = fb_create_modedb(edid, specs-modedb_len);
 
 + if (!specs-modedb)
 + return;
 +

we need to return an error and trace it

Best Regards,
J.
   /*
* Workaround for buggy EDIDs that sets that the first
* detailed timing is preferred but has not detailed
 -- 
 1.7.4.4
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 4/9] at91: dt: Add at91sam9261 dt SoC support

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:05 Mon 03 Mar , Jean-Jacques Hiblot wrote:
> This patch adds support for the Device Tree on a sam9261-based platform
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  arch/arm/boot/dts/at91sam9261.dtsi | 740 
> +
>  arch/arm/mach-at91/at91sam9261.c   |  17 +
>  2 files changed, 757 insertions(+)
>  create mode 100644 arch/arm/boot/dts/at91sam9261.dtsi
> 
> diff --git a/arch/arm/boot/dts/at91sam9261.dtsi 
> b/arch/arm/boot/dts/at91sam9261.dtsi
> new file mode 100644
> index 000..b40b91e
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91sam9261.dtsi
> @@ -0,0 +1,740 @@
> +/*
> + * at91sam9261.dtsi - Device Tree Include file for AT91SAM9261 SoC
> + *
> + *  Copyright (C) 2013 Jean-Jacques Hiblot 
> + *
> + * Licensed under GPLv2 only.
> + */
> +
> +#include "skeleton.dtsi"
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Atmel AT91SAM9261 family SoC";
> + compatible = "atmel,at91sam9261";
> + interrupt-parent = <>;
> +
> + aliases {
> + serial0 = 
> + serial1 = 
> + serial2 = 
> + serial3 = 
> + gpio0 = 
> + gpio1 = 
> + gpio2 = 
> + tcb0 = 
> + i2c0 = 
> + ssc0 = 
> + ssc1 = 
> + };
> +
> + cpus {
> + #address-cells = <0>;
> + #size-cells = <0>;
> +
> + cpu {
> + compatible = "arm,arm926ej-s";
> + device_type = "cpu";
> + };
> + };
> +
> + memory {
> + reg = <0x2000 0x0800>;
> + };
> +
> + ahb {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + usb0: ohci@0050 {
> + compatible = "atmel,at91rm9200-ohci", "usb-ohci";
> + reg = <0x0050 0x10>;
> + interrupts = <20 IRQ_TYPE_LEVEL_HIGH 2>;

for 5th time NACK

stop using interrupts une interrupts-extended
> + clocks = <>, <_clk>, <>, <>;
> + clock-names = "usb_clk", "ohci_clk", "hclk", "uhpck";
> + status = "disabled";
> + };
> +
> + fb0: fb@0x0060 {
> + compatible = "atmel,at91sam9261-lcdc";
> + reg = <0x0060 0x1000>;
> + interrupts = <21 IRQ_TYPE_LEVEL_HIGH 3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_fb>;
> + clocks = <_clk>, <>;
> + clock-names = "lcdc_clk", "hclk";
> + status = "disabled";
> + };
> +
> + nand0: nand@4000 {
> + compatible = "atmel,at91rm9200-nand";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x4000 0x1000>;
> + atmel,nand-addr-offset = <22>;
> + atmel,nand-cmd-offset = <21>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_nand>;
> +
> + gpios = < 15 GPIO_ACTIVE_HIGH
> +  14 GPIO_ACTIVE_HIGH
> + 0
> + >;
> + status = "disabled";
> + };
> +
> + apb {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + tcb0: timer@fffa {
> + compatible = "atmel,at91rm9200-tcb";
> + reg = <0xfffa 0x100>;
> + interrupts = < 17 IRQ_TYPE_LEVEL_HIGH 0
> + 18 IRQ_TYPE_LEVEL_HIGH 0
> + 19 IRQ_TYPE_LEVEL_HIGH 0
> + >;
> + clocks = <_clk>, <_clk>, <_clk>;
> + clock-names = "t0_clk", "t1_clk", "t2_clk";
> + };
> +
> + usb1: gadget@fffa4000 {
> + compatible = "atmel,at91rm9200-udc";
> + reg = <0xfffa4000 0x4000>;
> + interrupts = <10 IRQ_TYPE_LEVEL_HIGH 2>;
> + clocks = <>, <_clk>, <>;
> + clock-names = "usb_clk", "udc_clk", "udpck";
> + status = "disabled";
> + };
> +
> + mmc0: mmc@fffa8000 {
> + compatible = "atmel,hsmci";
> + reg = <0xfffa8000 0x600>;
> + interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>;
> +   

Re: [PATCH v5 6/9] at91: dt: sam9261: Device Tree support for the at91sam9261ek

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:05 Mon 03 Mar , Jean-Jacques Hiblot wrote:
> This patch implements a DTS to boot a at91sam9261ek with a dt-enabled
> kernel (at91_dt_defconfig).
> supported features are:
> * dbgu
> * lcdc
> * usb host
> * usb gadget,
> * spi dataflash
> * nand flash
> * touchscreen
> * leds
> * user buttons
> 
> In the TODO list:
> * dm9000 (ethernet)
> * audio
> * mmc
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  arch/arm/boot/dts/Makefile  |   2 +
>  arch/arm/boot/dts/at91sam9261ek.dts | 204 
> 
>  2 files changed, 206 insertions(+)
>  create mode 100644 arch/arm/boot/dts/at91sam9261ek.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 0320303..f496473 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -12,6 +12,8 @@ dtb-$(CONFIG_ARCH_AT91) += ethernut5.dtb
>  dtb-$(CONFIG_ARCH_AT91) += evk-pro3.dtb
>  dtb-$(CONFIG_ARCH_AT91) += tny_a9260.dtb
>  dtb-$(CONFIG_ARCH_AT91) += usb_a9260.dtb
> +# sam9261
> +dtb-$(CONFIG_ARCH_AT91) += at91sam9261ek.dtb
>  # sam9263
>  dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
>  dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
> diff --git a/arch/arm/boot/dts/at91sam9261ek.dts 
> b/arch/arm/boot/dts/at91sam9261ek.dts
> new file mode 100644
> index 000..03adb7f
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91sam9261ek.dts
> @@ -0,0 +1,204 @@
> +/*
> + * at91sam9261ek.dts - Device Tree file for Atmel at91sam9261 reference board
> + *
> + *  Copyright (C) 2013 Jean-Jacques Hiblot 
> + *
> + * Licensed under GPLv2 only.
> + */
> +/dts-v1/;
> +#include "at91sam9261.dtsi"
> +
> +/ {
> + model = "Atmel at91sam9261ek";
> + compatible = "atmel,at91sam9261ek", "atmel,at91sam9261", 
> "atmel,at91sam9";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 
> root=ubi0:rootfs rw";
> + };
> +
> + memory {
> + reg = <0x2000 0x400>;
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + main_clock: clock@0 {
> + compatible = "atmel,osc", "fixed-clock";
> + clock-frequency = <18432000>;
> + };
> + };
> +
> + ahb {
> + usb0: ohci@0050 {
> + status = "okay";
> + };
> +
> + fb0: fb@0x0060 {
> + display = <>;
> + atmel,power-control-gpio = < 12 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +
> + display0: display {
> + bits-per-pixel = <16>;
> + atmel,lcdcon-backlight;
> + atmel,dmacon = <0x1>;
> + atmel,lcdcon2 = <0x80008002>;
> + atmel,guard-time = <1>;
> + atmel,lcd-wiring-mode = "BRG";
> +
> + display-timings {
> + native-mode = <>;
> + timing0: timing0 {
> + clock-frequency = <4965000>;
> + hactive = <240>;
> + vactive = <320>;
> + hback-porch = <1>;
> + hfront-porch = <33>;
> + vback-porch = <1>;
> + vfront-porch = <0>;
> + hsync-len = <5>;
> + vsync-len = <1>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + };
> + };
> + };
> + };
> +
> + nand0: nand@4000 {
> + nand-bus-width = <8>;
> + nand-ecc-mode = "soft";
> + nand-on-flash-bbt;
> + status = "okay";
> +
> + at91bootstrap@0 {
> + label = "at91bootstrap";
> + reg = <0x0 0x4>;
> + };
> +
> + bootloader@4 {
> + label = "bootloader";
> + reg = <0x4 0x8>;
> + };
> +
> + bootloaderenv@c {
> + label = "bootloader env";
> + reg = <0xc 0xc>;
> + };
> +
> + dtb@18 {
> + label = "device tree";
> + reg = <0x18 0x8>;
> + };
> +
> +  

Re: [PATCH v5 6/9] at91: dt: sam9261: Device Tree support for the at91sam9261ek

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:05 Mon 03 Mar , Jean-Jacques Hiblot wrote:
 This patch implements a DTS to boot a at91sam9261ek with a dt-enabled
 kernel (at91_dt_defconfig).
 supported features are:
 * dbgu
 * lcdc
 * usb host
 * usb gadget,
 * spi dataflash
 * nand flash
 * touchscreen
 * leds
 * user buttons
 
 In the TODO list:
 * dm9000 (ethernet)
 * audio
 * mmc
 
 Signed-off-by: Jean-Jacques Hiblot jjhib...@traphandler.com
 ---
  arch/arm/boot/dts/Makefile  |   2 +
  arch/arm/boot/dts/at91sam9261ek.dts | 204 
 
  2 files changed, 206 insertions(+)
  create mode 100644 arch/arm/boot/dts/at91sam9261ek.dts
 
 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 0320303..f496473 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -12,6 +12,8 @@ dtb-$(CONFIG_ARCH_AT91) += ethernut5.dtb
  dtb-$(CONFIG_ARCH_AT91) += evk-pro3.dtb
  dtb-$(CONFIG_ARCH_AT91) += tny_a9260.dtb
  dtb-$(CONFIG_ARCH_AT91) += usb_a9260.dtb
 +# sam9261
 +dtb-$(CONFIG_ARCH_AT91) += at91sam9261ek.dtb
  # sam9263
  dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
  dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
 diff --git a/arch/arm/boot/dts/at91sam9261ek.dts 
 b/arch/arm/boot/dts/at91sam9261ek.dts
 new file mode 100644
 index 000..03adb7f
 --- /dev/null
 +++ b/arch/arm/boot/dts/at91sam9261ek.dts
 @@ -0,0 +1,204 @@
 +/*
 + * at91sam9261ek.dts - Device Tree file for Atmel at91sam9261 reference board
 + *
 + *  Copyright (C) 2013 Jean-Jacques Hiblot jjhib...@traphandler.com
 + *
 + * Licensed under GPLv2 only.
 + */
 +/dts-v1/;
 +#include at91sam9261.dtsi
 +
 +/ {
 + model = Atmel at91sam9261ek;
 + compatible = atmel,at91sam9261ek, atmel,at91sam9261, 
 atmel,at91sam9;
 +
 + chosen {
 + bootargs = console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 
 root=ubi0:rootfs rw;
 + };
 +
 + memory {
 + reg = 0x2000 0x400;
 + };
 +
 + clocks {
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;
 +
 + main_clock: clock@0 {
 + compatible = atmel,osc, fixed-clock;
 + clock-frequency = 18432000;
 + };
 + };
 +
 + ahb {
 + usb0: ohci@0050 {
 + status = okay;
 + };
 +
 + fb0: fb@0x0060 {
 + display = display0;
 + atmel,power-control-gpio = pioA 12 GPIO_ACTIVE_LOW;
 + status = okay;
 +
 + display0: display {
 + bits-per-pixel = 16;
 + atmel,lcdcon-backlight;
 + atmel,dmacon = 0x1;
 + atmel,lcdcon2 = 0x80008002;
 + atmel,guard-time = 1;
 + atmel,lcd-wiring-mode = BRG;
 +
 + display-timings {
 + native-mode = timing0;
 + timing0: timing0 {
 + clock-frequency = 4965000;
 + hactive = 240;
 + vactive = 320;
 + hback-porch = 1;
 + hfront-porch = 33;
 + vback-porch = 1;
 + vfront-porch = 0;
 + hsync-len = 5;
 + vsync-len = 1;
 + hsync-active = 1;
 + vsync-active = 1;
 + };
 + };
 + };
 + };
 +
 + nand0: nand@4000 {
 + nand-bus-width = 8;
 + nand-ecc-mode = soft;
 + nand-on-flash-bbt;
 + status = okay;
 +
 + at91bootstrap@0 {
 + label = at91bootstrap;
 + reg = 0x0 0x4;
 + };
 +
 + bootloader@4 {
 + label = bootloader;
 + reg = 0x4 0x8;
 + };
 +
 + bootloaderenv@c {
 + label = bootloader env;
 + reg = 0xc 0xc;
 + };
 +
 + dtb@18 {
 + label = device tree;
 + reg = 0x18 0x8;
 + };
 +
 + kernel@20 {
 + label = kernel;
 + reg = 0x20 0x60;
 + };
 +
 + 

Re: [PATCH v5 4/9] at91: dt: Add at91sam9261 dt SoC support

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:05 Mon 03 Mar , Jean-Jacques Hiblot wrote:
 This patch adds support for the Device Tree on a sam9261-based platform
 
 Signed-off-by: Jean-Jacques Hiblot jjhib...@traphandler.com
 ---
  arch/arm/boot/dts/at91sam9261.dtsi | 740 
 +
  arch/arm/mach-at91/at91sam9261.c   |  17 +
  2 files changed, 757 insertions(+)
  create mode 100644 arch/arm/boot/dts/at91sam9261.dtsi
 
 diff --git a/arch/arm/boot/dts/at91sam9261.dtsi 
 b/arch/arm/boot/dts/at91sam9261.dtsi
 new file mode 100644
 index 000..b40b91e
 --- /dev/null
 +++ b/arch/arm/boot/dts/at91sam9261.dtsi
 @@ -0,0 +1,740 @@
 +/*
 + * at91sam9261.dtsi - Device Tree Include file for AT91SAM9261 SoC
 + *
 + *  Copyright (C) 2013 Jean-Jacques Hiblot jjhib...@traphandler.com
 + *
 + * Licensed under GPLv2 only.
 + */
 +
 +#include skeleton.dtsi
 +#include dt-bindings/pinctrl/at91.h
 +#include dt-bindings/interrupt-controller/irq.h
 +#include dt-bindings/gpio/gpio.h
 +#include dt-bindings/clk/at91.h
 +
 +/ {
 + model = Atmel AT91SAM9261 family SoC;
 + compatible = atmel,at91sam9261;
 + interrupt-parent = aic;
 +
 + aliases {
 + serial0 = dbgu;
 + serial1 = usart0;
 + serial2 = usart1;
 + serial3 = usart2;
 + gpio0 = pioA;
 + gpio1 = pioB;
 + gpio2 = pioC;
 + tcb0 = tcb0;
 + i2c0 = i2c0;
 + ssc0 = ssc0;
 + ssc1 = ssc1;
 + };
 +
 + cpus {
 + #address-cells = 0;
 + #size-cells = 0;
 +
 + cpu {
 + compatible = arm,arm926ej-s;
 + device_type = cpu;
 + };
 + };
 +
 + memory {
 + reg = 0x2000 0x0800;
 + };
 +
 + ahb {
 + compatible = simple-bus;
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;
 +
 + usb0: ohci@0050 {
 + compatible = atmel,at91rm9200-ohci, usb-ohci;
 + reg = 0x0050 0x10;
 + interrupts = 20 IRQ_TYPE_LEVEL_HIGH 2;

for 5th time NACK

stop using interrupts une interrupts-extended
 + clocks = usb, ohci_clk, hclk0, uhpck;
 + clock-names = usb_clk, ohci_clk, hclk, uhpck;
 + status = disabled;
 + };
 +
 + fb0: fb@0x0060 {
 + compatible = atmel,at91sam9261-lcdc;
 + reg = 0x0060 0x1000;
 + interrupts = 21 IRQ_TYPE_LEVEL_HIGH 3;
 + pinctrl-names = default;
 + pinctrl-0 = pinctrl_fb;
 + clocks = lcd_clk, hclk1;
 + clock-names = lcdc_clk, hclk;
 + status = disabled;
 + };
 +
 + nand0: nand@4000 {
 + compatible = atmel,at91rm9200-nand;
 + #address-cells = 1;
 + #size-cells = 1;
 + reg = 0x4000 0x1000;
 + atmel,nand-addr-offset = 22;
 + atmel,nand-cmd-offset = 21;
 + pinctrl-names = default;
 + pinctrl-0 = pinctrl_nand;
 +
 + gpios = pioC 15 GPIO_ACTIVE_HIGH
 + pioC 14 GPIO_ACTIVE_HIGH
 + 0
 + ;
 + status = disabled;
 + };
 +
 + apb {
 + compatible = simple-bus;
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;
 +
 + tcb0: timer@fffa {
 + compatible = atmel,at91rm9200-tcb;
 + reg = 0xfffa 0x100;
 + interrupts =  17 IRQ_TYPE_LEVEL_HIGH 0
 + 18 IRQ_TYPE_LEVEL_HIGH 0
 + 19 IRQ_TYPE_LEVEL_HIGH 0
 + ;
 + clocks = tc0_clk, tc1_clk, tc2_clk;
 + clock-names = t0_clk, t1_clk, t2_clk;
 + };
 +
 + usb1: gadget@fffa4000 {
 + compatible = atmel,at91rm9200-udc;
 + reg = 0xfffa4000 0x4000;
 + interrupts = 10 IRQ_TYPE_LEVEL_HIGH 2;
 + clocks = usb, udc_clk, udpck;
 + clock-names = usb_clk, udc_clk, udpck;
 + status = disabled;
 + };
 +
 + mmc0: mmc@fffa8000 {
 + compatible = atmel,hsmci;
 + reg = 0xfffa8000 0x600;
 + interrupts = 9 IRQ_TYPE_LEVEL_HIGH 0;
 + 

Re: [PATCH for 3.14] ARM: at91: fix network interface ordering for sama5d36

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 10, 2014, at 10:37 PM, Nicolas Ferre  wrote:

> From: Boris BREZILLON 
> 
> On the newly introduced sama5d36, Gigabit and 10/100 Ethernet network
> interfaces are probed in a different order than for the sama5d35.
> Moreover, users are accustomed to this order in bootloaders and backports
> for older kernel revisions.
> So this patch switches DT node order as it is done for the other dual-Ethernet
> sama5d3 SoC.
> Better interface numbering which does not depend on DT node order is being
> developed for stronger interface identification.

twick ethernet enumerating by playing on the DT order is week

It’s better to introduce a new property

linux,ethernet-id or something like or simply rely on other information on the 
userspace to identify the
proper interface

Nicolas for AT91 keep me in Cc

Best Regards,
J.
> 
> Signed-off-by: Boris BREZILLON 
> Signed-off-by: Nicolas Ferre 
> ---
> Olof, Arnd and Kevin,
> 
> I would like to include this fix in 3.14-final.
> I do not have anymore patch for an at91-3.14-fixes branch so I only send this
> single patch to you. Can you still take it?
> 
> Thanks, best regards,
> 
> arch/arm/boot/dts/sama5d36.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/sama5d36.dtsi b/arch/arm/boot/dts/sama5d36.dtsi
> index 6c31c26e6cc0..db58cad6acd3 100644
> --- a/arch/arm/boot/dts/sama5d36.dtsi
> +++ b/arch/arm/boot/dts/sama5d36.dtsi
> @@ -8,8 +8,8 @@
>  */
> #include "sama5d3.dtsi"
> #include "sama5d3_can.dtsi"
> -#include "sama5d3_emac.dtsi"
> #include "sama5d3_gmac.dtsi"
> +#include "sama5d3_emac.dtsi"
> #include "sama5d3_lcd.dtsi"
> #include "sama5d3_mci2.dtsi"
> #include "sama5d3_tcb1.dtsi"
> -- 
> 1.8.2.2
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 11, 2014, at 2:54 PM, Yang, Wenyou  wrote:

> 
> 
>> -Original Message-----
>> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
>> Sent: Tuesday, March 11, 2014 12:16 PM
>> To: Yang, Wenyou
>> Cc: Jean-Christophe PLAGNIOL-VILLARD; mark.rutl...@arm.com;
>> devicet...@vger.kernel.org; pawel.m...@arm.com;
>> ijc+devicet...@hellion.org.uk; linus.wall...@linaro.org; Linux Kernel
>> list; b.brezil...@overkiz.com; robh...@kernel.org; ga...@codeaurora.org;
>>  mailing list
>> Subject: Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
>> 
>> 
>> On Mar 11, 2014, at 9:28 AM, Yang, Wenyou  wrote:
>> 
>>> Hi JC,
>>> 
>>>> -Original Message-
>>>> From: Yang, Wenyou
>>>> Sent: Wednesday, March 05, 2014 1:32 PM
>>>> To: Jean-Christophe PLAGNIOL-VILLARD
>>>> Cc: linus.wall...@linaro.org; b.brezil...@overkiz.com; >>> ker...@lists.infradead.org> mailing list; Linux Kernel list;
>>>> devicet...@vger.kernel.org; robh...@kernel.org; pawel.m...@arm.com;
>>>> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
>>>> ga...@codeaurora.org
>>>> Subject: RE: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
>>>> 
>>>> Hi JC,
>>>> 
>>>>> -Original Message-
>>>>> From: Jean-Christophe PLAGNIOL-VILLARD
>>>>> [mailto:plagn...@jcrosoft.com]
>>>>> Sent: Wednesday, March 05, 2014 12:58 PM
>>>>> To: Yang, Wenyou
>>>>> Cc: Jean-Christophe PLAGNIOL-VILLARD; linus.wall...@linaro.org;
>>>>> b.brezil...@overkiz.com; 
>>>>> mailing list; Linux Kernel list; devicet...@vger.kernel.org;
>>>>> robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
>>>>> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
>>>>> Subject: Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
>>>>> 
>>>>> 
>>>>> On Mar 5, 2014, at 9:53 AM, Wenyou Yang 
>> wrote:
>>>>> 
>>>>>> In order to support the pinctrl sleep state.
>>>>> 
>>>>> As I said before NACK
>>>>> 
>>>>> this is not the job of the pinctrl to describe gpio output or input
>>>>> state
>>>> But according to what said in the section "GPIO mode pitfalls" of
>>>> Documentation/pinctrl.txt.
>>>> It should be handle by the pinctrl.
>>>> 
>>>> If not, to deal with the sleep state will be very complicated.
>>>> Muxing the pins for FUNCTION to enable peripheral, then twist them
>>>> over to GPIO mode and use gpio_direction_output() to drive it HIGH or
>>>> LOW during sleep.
>>>> 
>>>> --->8 
>>>> The solution is to not think that what the datasheet calls "GPIO
>> mode"
>>>> has to be handled by the  interface. Instead view this
>>>> as a certain pin config setting. Look in e.g. >>> generic.h> and you find this in the documentation:
>>>> 
>>>> PIN_CONFIG_OUTPUT: this will configure the pin in output, use
>> argument
>>>>1 to indicate high level, argument 0 to indicate low level.
>>>> 
>>>> So it is perfectly possible to push a pin into "GPIO mode" and drive
>>>> the line low as part of the usual pin control map.
>>>> ---<8 
>>> 
>>> Do you have any feedback?
>> 
>> Here the issue is that you do drive the gpio and use as a gpio
>> 
>> which means you request it as a GPIO so after you can not reswitch it to
>> alternative function and the gpio is already requested as alternative
>> function
>> 
>> So basically you mess-up with the gpio API and pinctrl API by bypassing
>> both
> 
> But I don't agree with you.
> 
> As I known, in mainline the other SoC vendors provide such function, 
> configure the gpio mode with output config by pinctrl.
> 
> For example, ST. nomadisk.
> You can see it in the function: nmk_pin_config_set() of the file, 
> pinctrl-nomadik.c.
> It provides GPIO mode and OUTPUT config.
> 
> This is a good solution, as what said in Documentation/pinctrl.txt,
> 
> it is perfectly possible to push a pin into "GPIO mode" and drive the line 
> low as part of the usual pin control map.
> 

This is simple if we use gpio mode as pinctrl tomorrow we will see gpio 
configuration in pinctrl
such as chip reset, default le

Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 11, 2014, at 2:54 PM, Yang, Wenyou wenyou.y...@atmel.com wrote:

 
 
 -Original Message-
 From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
 Sent: Tuesday, March 11, 2014 12:16 PM
 To: Yang, Wenyou
 Cc: Jean-Christophe PLAGNIOL-VILLARD; mark.rutl...@arm.com;
 devicet...@vger.kernel.org; pawel.m...@arm.com;
 ijc+devicet...@hellion.org.uk; linus.wall...@linaro.org; Linux Kernel
 list; b.brezil...@overkiz.com; robh...@kernel.org; ga...@codeaurora.org;
 linux-arm-ker...@lists.infradead.org mailing list
 Subject: Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
 
 
 On Mar 11, 2014, at 9:28 AM, Yang, Wenyou wenyou.y...@atmel.com wrote:
 
 Hi JC,
 
 -Original Message-
 From: Yang, Wenyou
 Sent: Wednesday, March 05, 2014 1:32 PM
 To: Jean-Christophe PLAGNIOL-VILLARD
 Cc: linus.wall...@linaro.org; b.brezil...@overkiz.com; linux-arm-
 ker...@lists.infradead.org mailing list; Linux Kernel list;
 devicet...@vger.kernel.org; robh...@kernel.org; pawel.m...@arm.com;
 mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
 ga...@codeaurora.org
 Subject: RE: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
 
 Hi JC,
 
 -Original Message-
 From: Jean-Christophe PLAGNIOL-VILLARD
 [mailto:plagn...@jcrosoft.com]
 Sent: Wednesday, March 05, 2014 12:58 PM
 To: Yang, Wenyou
 Cc: Jean-Christophe PLAGNIOL-VILLARD; linus.wall...@linaro.org;
 b.brezil...@overkiz.com; linux-arm-ker...@lists.infradead.org
 mailing list; Linux Kernel list; devicet...@vger.kernel.org;
 robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
 ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
 Subject: Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
 
 
 On Mar 5, 2014, at 9:53 AM, Wenyou Yang wenyou.y...@atmel.com
 wrote:
 
 In order to support the pinctrl sleep state.
 
 As I said before NACK
 
 this is not the job of the pinctrl to describe gpio output or input
 state
 But according to what said in the section GPIO mode pitfalls of
 Documentation/pinctrl.txt.
 It should be handle by the pinctrl.
 
 If not, to deal with the sleep state will be very complicated.
 Muxing the pins for FUNCTION to enable peripheral, then twist them
 over to GPIO mode and use gpio_direction_output() to drive it HIGH or
 LOW during sleep.
 
 ---8 
 The solution is to not think that what the datasheet calls GPIO
 mode
 has to be handled by the linux/gpio.h interface. Instead view this
 as a certain pin config setting. Look in e.g. linux/pinctrl/pinconf-
 generic.h and you find this in the documentation:
 
 PIN_CONFIG_OUTPUT: this will configure the pin in output, use
 argument
1 to indicate high level, argument 0 to indicate low level.
 
 So it is perfectly possible to push a pin into GPIO mode and drive
 the line low as part of the usual pin control map.
 ---8 
 
 Do you have any feedback?
 
 Here the issue is that you do drive the gpio and use as a gpio
 
 which means you request it as a GPIO so after you can not reswitch it to
 alternative function and the gpio is already requested as alternative
 function
 
 So basically you mess-up with the gpio API and pinctrl API by bypassing
 both
 
 But I don't agree with you.
 
 As I known, in mainline the other SoC vendors provide such function, 
 configure the gpio mode with output config by pinctrl.
 
 For example, ST. nomadisk.
 You can see it in the function: nmk_pin_config_set() of the file, 
 pinctrl-nomadik.c.
 It provides GPIO mode and OUTPUT config.
 
 This is a good solution, as what said in Documentation/pinctrl.txt,
 
 it is perfectly possible to push a pin into GPIO mode and drive the line 
 low as part of the usual pin control map.
 

This is simple if we use gpio mode as pinctrl tomorrow we will see gpio 
configuration in pinctrl
such as chip reset, default led state etc…

The pinctrl is not here to control a *GPIO* but to describe the configuration 
of pin.

 
 Best Regards,
 Wenyou Yang
 
 Best Regards,
 J.
 
 
 Thanks,
 Wenyou Yang
 
 
 
 Best Regards,
 J.
 
 Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
 ---
 Hi Linus,
 
 The patch is based on branch: for-next
 git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
 
 Best Regards,
 Wenyou Yang
 
 drivers/pinctrl/pinctrl-at91.c |   31
 +++
 include/dt-bindings/pinctrl/at91.h |2 ++
 2 files changed, 33 insertions(+)
 
 diff --git a/drivers/pinctrl/pinctrl-at91.c
 b/drivers/pinctrl/pinctrl-at91.c index 5d24aae..fc51e59 100644
 --- a/drivers/pinctrl/pinctrl-at91.c
 +++ b/drivers/pinctrl/pinctrl-at91.c
 @@ -62,6 +62,8 @@ static int gpio_banks;
 #define DEGLITCH (1  2)
 #define PULL_DOWN(1  3)
 #define DIS_SCHMIT   (1  4)
 +#define GPIO_OUTPUT_HIGH(1  5)
 +#define GPIO_OUTPUT_LOW (1  6)
 #define DEBOUNCE (1  16)
 #define DEBOUNCE_VAL_SHIFT   17
 #define DEBOUNCE_VAL (0x3fff  DEBOUNCE_VAL_SHIFT)
 @@ -152,12 +154,15 @@ struct at91_pinctrl_mux_ops {
  void (*set_pulldown)(void

Re: [PATCH for 3.14] ARM: at91: fix network interface ordering for sama5d36

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 10, 2014, at 10:37 PM, Nicolas Ferre nicolas.fe...@atmel.com wrote:

 From: Boris BREZILLON b.brezillon@gmail.com
 
 On the newly introduced sama5d36, Gigabit and 10/100 Ethernet network
 interfaces are probed in a different order than for the sama5d35.
 Moreover, users are accustomed to this order in bootloaders and backports
 for older kernel revisions.
 So this patch switches DT node order as it is done for the other dual-Ethernet
 sama5d3 SoC.
 Better interface numbering which does not depend on DT node order is being
 developed for stronger interface identification.

twick ethernet enumerating by playing on the DT order is week

It’s better to introduce a new property

linux,ethernet-id or something like or simply rely on other information on the 
userspace to identify the
proper interface

Nicolas for AT91 keep me in Cc

Best Regards,
J.
 
 Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
 Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
 ---
 Olof, Arnd and Kevin,
 
 I would like to include this fix in 3.14-final.
 I do not have anymore patch for an at91-3.14-fixes branch so I only send this
 single patch to you. Can you still take it?
 
 Thanks, best regards,
 
 arch/arm/boot/dts/sama5d36.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/sama5d36.dtsi b/arch/arm/boot/dts/sama5d36.dtsi
 index 6c31c26e6cc0..db58cad6acd3 100644
 --- a/arch/arm/boot/dts/sama5d36.dtsi
 +++ b/arch/arm/boot/dts/sama5d36.dtsi
 @@ -8,8 +8,8 @@
  */
 #include sama5d3.dtsi
 #include sama5d3_can.dtsi
 -#include sama5d3_emac.dtsi
 #include sama5d3_gmac.dtsi
 +#include sama5d3_emac.dtsi
 #include sama5d3_lcd.dtsi
 #include sama5d3_mci2.dtsi
 #include sama5d3_tcb1.dtsi
 -- 
 1.8.2.2
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 11, 2014, at 9:28 AM, Yang, Wenyou  wrote:

> Hi JC,
> 
>> -Original Message-
>> From: Yang, Wenyou
>> Sent: Wednesday, March 05, 2014 1:32 PM
>> To: Jean-Christophe PLAGNIOL-VILLARD
>> Cc: linus.wall...@linaro.org; b.brezil...@overkiz.com; > ker...@lists.infradead.org> mailing list; Linux Kernel list;
>> devicet...@vger.kernel.org; robh...@kernel.org; pawel.m...@arm.com;
>> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
>> ga...@codeaurora.org
>> Subject: RE: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
>> 
>> Hi JC,
>> 
>>> -Original Message-
>>> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
>>> Sent: Wednesday, March 05, 2014 12:58 PM
>>> To: Yang, Wenyou
>>> Cc: Jean-Christophe PLAGNIOL-VILLARD; linus.wall...@linaro.org;
>>> b.brezil...@overkiz.com; 
>>> mailing list; Linux Kernel list; devicet...@vger.kernel.org;
>>> robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
>>> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
>>> Subject: Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
>>> 
>>> 
>>> On Mar 5, 2014, at 9:53 AM, Wenyou Yang  wrote:
>>> 
>>>> In order to support the pinctrl sleep state.
>>> 
>>> As I said before NACK
>>> 
>>> this is not the job of the pinctrl to describe gpio output or input
>>> state
>> But according to what said in the section "GPIO mode pitfalls" of
>> Documentation/pinctrl.txt.
>> It should be handle by the pinctrl.
>> 
>> If not, to deal with the sleep state will be very complicated.
>> Muxing the pins for FUNCTION to enable peripheral, then twist them over
>> to GPIO mode and use gpio_direction_output() to drive it HIGH or LOW
>> during sleep.
>> 
>> --->8 
>> The solution is to not think that what the datasheet calls "GPIO mode"
>> has to be handled by the  interface. Instead view this as
>> a certain pin config setting. Look in e.g. > generic.h> and you find this in the documentation:
>> 
>>  PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
>> 1 to indicate high level, argument 0 to indicate low level.
>> 
>> So it is perfectly possible to push a pin into "GPIO mode" and drive the
>> line low as part of the usual pin control map.
>> ---<8 
> 
> Do you have any feedback?

Here the issue is that you do drive the gpio and use as a gpio

which means you request it as a GPIO so after you can not reswitch it to 
alternative function
and the gpio is already requested as alternative function

So basically you mess-up with the gpio API and pinctrl API by bypassing both

Best Regards,
J.

> 
> Thanks,
> Wenyou Yang
> 
>> 
>>> 
>>> Best Regards,
>>> J.
>>>> 
>>>> Signed-off-by: Wenyou Yang 
>>>> ---
>>>> Hi Linus,
>>>> 
>>>> The patch is based on branch: for-next
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
>>>> 
>>>> Best Regards,
>>>> Wenyou Yang
>>>> 
>>>> drivers/pinctrl/pinctrl-at91.c |   31
>>> +++
>>>> include/dt-bindings/pinctrl/at91.h |2 ++
>>>> 2 files changed, 33 insertions(+)
>>>> 
>>>> diff --git a/drivers/pinctrl/pinctrl-at91.c
>>>> b/drivers/pinctrl/pinctrl-at91.c index 5d24aae..fc51e59 100644
>>>> --- a/drivers/pinctrl/pinctrl-at91.c
>>>> +++ b/drivers/pinctrl/pinctrl-at91.c
>>>> @@ -62,6 +62,8 @@ static int gpio_banks;
>>>> #define DEGLITCH   (1 << 2)
>>>> #define PULL_DOWN  (1 << 3)
>>>> #define DIS_SCHMIT (1 << 4)
>>>> +#define GPIO_OUTPUT_HIGH  (1 << 5)
>>>> +#define GPIO_OUTPUT_LOW   (1 << 6)
>>>> #define DEBOUNCE   (1 << 16)
>>>> #define DEBOUNCE_VAL_SHIFT 17
>>>> #define DEBOUNCE_VAL   (0x3fff << DEBOUNCE_VAL_SHIFT)
>>>> @@ -152,12 +154,15 @@ struct at91_pinctrl_mux_ops {
>>>>void (*set_pulldown)(void __iomem *pio, unsigned mask, bool is_on);
>>>>bool (*get_schmitt_trig)(void __iomem *pio, unsigned pin);
>>>>void (*disable_schmitt_trig)(void __iomem *pio, unsigned mask);
>>>> +  bool (*get_gpio_output)(void __iomem *pio, unsigned mask);
>>>> +  void (*set_gpio_output)(void __iomem *pio, unsigned mas

Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 11, 2014, at 9:28 AM, Yang, Wenyou wenyou.y...@atmel.com wrote:

 Hi JC,
 
 -Original Message-
 From: Yang, Wenyou
 Sent: Wednesday, March 05, 2014 1:32 PM
 To: Jean-Christophe PLAGNIOL-VILLARD
 Cc: linus.wall...@linaro.org; b.brezil...@overkiz.com; linux-arm-
 ker...@lists.infradead.org mailing list; Linux Kernel list;
 devicet...@vger.kernel.org; robh...@kernel.org; pawel.m...@arm.com;
 mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
 ga...@codeaurora.org
 Subject: RE: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
 
 Hi JC,
 
 -Original Message-
 From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
 Sent: Wednesday, March 05, 2014 12:58 PM
 To: Yang, Wenyou
 Cc: Jean-Christophe PLAGNIOL-VILLARD; linus.wall...@linaro.org;
 b.brezil...@overkiz.com; linux-arm-ker...@lists.infradead.org
 mailing list; Linux Kernel list; devicet...@vger.kernel.org;
 robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
 ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
 Subject: Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
 
 
 On Mar 5, 2014, at 9:53 AM, Wenyou Yang wenyou.y...@atmel.com wrote:
 
 In order to support the pinctrl sleep state.
 
 As I said before NACK
 
 this is not the job of the pinctrl to describe gpio output or input
 state
 But according to what said in the section GPIO mode pitfalls of
 Documentation/pinctrl.txt.
 It should be handle by the pinctrl.
 
 If not, to deal with the sleep state will be very complicated.
 Muxing the pins for FUNCTION to enable peripheral, then twist them over
 to GPIO mode and use gpio_direction_output() to drive it HIGH or LOW
 during sleep.
 
 ---8 
 The solution is to not think that what the datasheet calls GPIO mode
 has to be handled by the linux/gpio.h interface. Instead view this as
 a certain pin config setting. Look in e.g. linux/pinctrl/pinconf-
 generic.h and you find this in the documentation:
 
  PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
 1 to indicate high level, argument 0 to indicate low level.
 
 So it is perfectly possible to push a pin into GPIO mode and drive the
 line low as part of the usual pin control map.
 ---8 
 
 Do you have any feedback?

Here the issue is that you do drive the gpio and use as a gpio

which means you request it as a GPIO so after you can not reswitch it to 
alternative function
and the gpio is already requested as alternative function

So basically you mess-up with the gpio API and pinctrl API by bypassing both

Best Regards,
J.

 
 Thanks,
 Wenyou Yang
 
 
 
 Best Regards,
 J.
 
 Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
 ---
 Hi Linus,
 
 The patch is based on branch: for-next
 git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
 
 Best Regards,
 Wenyou Yang
 
 drivers/pinctrl/pinctrl-at91.c |   31
 +++
 include/dt-bindings/pinctrl/at91.h |2 ++
 2 files changed, 33 insertions(+)
 
 diff --git a/drivers/pinctrl/pinctrl-at91.c
 b/drivers/pinctrl/pinctrl-at91.c index 5d24aae..fc51e59 100644
 --- a/drivers/pinctrl/pinctrl-at91.c
 +++ b/drivers/pinctrl/pinctrl-at91.c
 @@ -62,6 +62,8 @@ static int gpio_banks;
 #define DEGLITCH   (1  2)
 #define PULL_DOWN  (1  3)
 #define DIS_SCHMIT (1  4)
 +#define GPIO_OUTPUT_HIGH  (1  5)
 +#define GPIO_OUTPUT_LOW   (1  6)
 #define DEBOUNCE   (1  16)
 #define DEBOUNCE_VAL_SHIFT 17
 #define DEBOUNCE_VAL   (0x3fff  DEBOUNCE_VAL_SHIFT)
 @@ -152,12 +154,15 @@ struct at91_pinctrl_mux_ops {
void (*set_pulldown)(void __iomem *pio, unsigned mask, bool is_on);
bool (*get_schmitt_trig)(void __iomem *pio, unsigned pin);
void (*disable_schmitt_trig)(void __iomem *pio, unsigned mask);
 +  bool (*get_gpio_output)(void __iomem *pio, unsigned mask);
 +  void (*set_gpio_output)(void __iomem *pio, unsigned mask, bool
 +is_high);
/* irq */
int (*irq_type)(struct irq_data *d, unsigned type); };
 
 static int gpio_irq_type(struct irq_data *d, unsigned type); static
 int alt_gpio_irq_type(struct irq_data *d, unsigned type);
 +static void at91_mux_gpio_enable(void __iomem *pio, unsigned mask,
 +bool input);
 
 struct at91_pinctrl {
struct device   *dev;
 @@ -472,6 +477,20 @@ static bool at91_mux_pio3_get_schmitt_trig(void
 __iomem *pio, unsigned pin)
return (__raw_readl(pio + PIO_SCHMITT)  pin)  0x1; }
 
 +static bool at91_mux_pio3_get_gpio_output(void __iomem *pio,
 +unsigned
 +pin) {
 +  return (__raw_readl(pio + PIO_ODSR)  pin)  0x1; }
 +
 +static void at91_mux_pio3_set_gpio_output(void __iomem *pio,
 +  unsigned mask,
 +  bool is_high)
 +{
 +  at91_mux_gpio_enable(pio, mask, 0);
 +  writel_relaxed(mask, pio + (is_high ? PIO_SODR : PIO_CODR)); }
 +
 +
 static struct at91_pinctrl_mux_ops at91rm9200_ops = {
.get_periph = at91_mux_get_periph,
.mux_A_periph   = at91_mux_set_A_periph,
 @@ -495,6 +514,8

Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 5, 2014, at 9:53 AM, Wenyou Yang  wrote:

> In order to support the pinctrl sleep state.

As I said before NACK

this is not the job of the pinctrl to describe gpio output or input state

Best Regards,
J.
> 
> Signed-off-by: Wenyou Yang 
> ---
> Hi Linus,
> 
> The patch is based on branch: for-next
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> 
> Best Regards,
> Wenyou Yang
> 
> drivers/pinctrl/pinctrl-at91.c |   31 +++
> include/dt-bindings/pinctrl/at91.h |2 ++
> 2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index 5d24aae..fc51e59 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -62,6 +62,8 @@ static int gpio_banks;
> #define DEGLITCH  (1 << 2)
> #define PULL_DOWN (1 << 3)
> #define DIS_SCHMIT(1 << 4)
> +#define GPIO_OUTPUT_HIGH (1 << 5)
> +#define GPIO_OUTPUT_LOW  (1 << 6)
> #define DEBOUNCE  (1 << 16)
> #define DEBOUNCE_VAL_SHIFT17
> #define DEBOUNCE_VAL  (0x3fff << DEBOUNCE_VAL_SHIFT)
> @@ -152,12 +154,15 @@ struct at91_pinctrl_mux_ops {
>   void (*set_pulldown)(void __iomem *pio, unsigned mask, bool is_on);
>   bool (*get_schmitt_trig)(void __iomem *pio, unsigned pin);
>   void (*disable_schmitt_trig)(void __iomem *pio, unsigned mask);
> + bool (*get_gpio_output)(void __iomem *pio, unsigned mask);
> + void (*set_gpio_output)(void __iomem *pio, unsigned mask, bool is_high);
>   /* irq */
>   int (*irq_type)(struct irq_data *d, unsigned type);
> };
> 
> static int gpio_irq_type(struct irq_data *d, unsigned type);
> static int alt_gpio_irq_type(struct irq_data *d, unsigned type);
> +static void at91_mux_gpio_enable(void __iomem *pio, unsigned mask, bool 
> input);
> 
> struct at91_pinctrl {
>   struct device   *dev;
> @@ -472,6 +477,20 @@ static bool at91_mux_pio3_get_schmitt_trig(void __iomem 
> *pio, unsigned pin)
>   return (__raw_readl(pio + PIO_SCHMITT) >> pin) & 0x1;
> }
> 
> +static bool at91_mux_pio3_get_gpio_output(void __iomem *pio, unsigned pin)
> +{
> + return (__raw_readl(pio + PIO_ODSR) >> pin) & 0x1;
> +}
> +
> +static void at91_mux_pio3_set_gpio_output(void __iomem *pio,
> + unsigned mask,
> + bool is_high)
> +{
> + at91_mux_gpio_enable(pio, mask, 0);
> + writel_relaxed(mask, pio + (is_high ? PIO_SODR : PIO_CODR));
> +}
> +
> +
> static struct at91_pinctrl_mux_ops at91rm9200_ops = {
>   .get_periph = at91_mux_get_periph,
>   .mux_A_periph   = at91_mux_set_A_periph,
> @@ -495,6 +514,8 @@ static struct at91_pinctrl_mux_ops at91sam9x5_ops = {
>   .set_pulldown   = at91_mux_pio3_set_pulldown,
>   .get_schmitt_trig = at91_mux_pio3_get_schmitt_trig,
>   .disable_schmitt_trig = at91_mux_pio3_disable_schmitt_trig,
> + .get_gpio_output = at91_mux_pio3_get_gpio_output,
> + .set_gpio_output = at91_mux_pio3_set_gpio_output,
>   .irq_type   = alt_gpio_irq_type,
> };
> 
> @@ -741,6 +762,10 @@ static int at91_pinconf_get(struct pinctrl_dev *pctldev,
>   *config |= PULL_DOWN;
>   if (info->ops->get_schmitt_trig && info->ops->get_schmitt_trig(pio, 
> pin))
>   *config |= DIS_SCHMIT;
> + if (info->ops->get_gpio_output) {
> + *config |= info->ops->get_gpio_output(pio, pin) ?
> + GPIO_OUTPUT_HIGH : GPIO_OUTPUT_LOW;
> + }
> 
>   return 0;
> }
> @@ -778,6 +803,12 @@ static int at91_pinconf_set(struct pinctrl_dev *pctldev,
>   info->ops->set_pulldown(pio, mask, config & PULL_DOWN);
>   if (info->ops->disable_schmitt_trig && config & DIS_SCHMIT)
>   info->ops->disable_schmitt_trig(pio, mask);
> + if (info->ops->set_gpio_output) {
> + if (config & GPIO_OUTPUT_HIGH)
> + info->ops->set_gpio_output(pio, mask, 1);
> + if (config & GPIO_OUTPUT_LOW)
> + info->ops->set_gpio_output(pio, mask, 0);
> + };
> 
>   } /* for each config */
> 
> diff --git a/include/dt-bindings/pinctrl/at91.h 
> b/include/dt-bindings/pinctrl/at91.h
> index 0fee6ff..e799268 100644
> --- a/include/dt-bindings/pinctrl/at91.h
> +++ b/include/dt-bindings/pinctrl/at91.h
> @@ -15,6 +15,8 @@
> #define AT91_PINCTRL_DEGLITCH (1 << 2)
> #define AT91_PINCTRL_PULL_DOWN(1 << 3)
> #define AT91_PINCTRL_DIS_SCHMIT   (1 << 4)
> +#define AT91_PINCTRL_OUTPUT_HIGH (1 << 5)
> +#define AT91_PINCTRL_OUTPUT_LOW  (1 << 6)
> #define AT91_PINCTRL_DEBOUNCE (1 << 16)
> #define AT91_PINCTRL_DEBOUNCE_VAL(x)  (x << 17)
> 
> -- 
> 1.7.9.5
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 5, 2014, at 9:53 AM, Wenyou Yang wenyou.y...@atmel.com wrote:

 In order to support the pinctrl sleep state.

As I said before NACK

this is not the job of the pinctrl to describe gpio output or input state

Best Regards,
J.
 
 Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
 ---
 Hi Linus,
 
 The patch is based on branch: for-next
 git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
 
 Best Regards,
 Wenyou Yang
 
 drivers/pinctrl/pinctrl-at91.c |   31 +++
 include/dt-bindings/pinctrl/at91.h |2 ++
 2 files changed, 33 insertions(+)
 
 diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
 index 5d24aae..fc51e59 100644
 --- a/drivers/pinctrl/pinctrl-at91.c
 +++ b/drivers/pinctrl/pinctrl-at91.c
 @@ -62,6 +62,8 @@ static int gpio_banks;
 #define DEGLITCH  (1  2)
 #define PULL_DOWN (1  3)
 #define DIS_SCHMIT(1  4)
 +#define GPIO_OUTPUT_HIGH (1  5)
 +#define GPIO_OUTPUT_LOW  (1  6)
 #define DEBOUNCE  (1  16)
 #define DEBOUNCE_VAL_SHIFT17
 #define DEBOUNCE_VAL  (0x3fff  DEBOUNCE_VAL_SHIFT)
 @@ -152,12 +154,15 @@ struct at91_pinctrl_mux_ops {
   void (*set_pulldown)(void __iomem *pio, unsigned mask, bool is_on);
   bool (*get_schmitt_trig)(void __iomem *pio, unsigned pin);
   void (*disable_schmitt_trig)(void __iomem *pio, unsigned mask);
 + bool (*get_gpio_output)(void __iomem *pio, unsigned mask);
 + void (*set_gpio_output)(void __iomem *pio, unsigned mask, bool is_high);
   /* irq */
   int (*irq_type)(struct irq_data *d, unsigned type);
 };
 
 static int gpio_irq_type(struct irq_data *d, unsigned type);
 static int alt_gpio_irq_type(struct irq_data *d, unsigned type);
 +static void at91_mux_gpio_enable(void __iomem *pio, unsigned mask, bool 
 input);
 
 struct at91_pinctrl {
   struct device   *dev;
 @@ -472,6 +477,20 @@ static bool at91_mux_pio3_get_schmitt_trig(void __iomem 
 *pio, unsigned pin)
   return (__raw_readl(pio + PIO_SCHMITT)  pin)  0x1;
 }
 
 +static bool at91_mux_pio3_get_gpio_output(void __iomem *pio, unsigned pin)
 +{
 + return (__raw_readl(pio + PIO_ODSR)  pin)  0x1;
 +}
 +
 +static void at91_mux_pio3_set_gpio_output(void __iomem *pio,
 + unsigned mask,
 + bool is_high)
 +{
 + at91_mux_gpio_enable(pio, mask, 0);
 + writel_relaxed(mask, pio + (is_high ? PIO_SODR : PIO_CODR));
 +}
 +
 +
 static struct at91_pinctrl_mux_ops at91rm9200_ops = {
   .get_periph = at91_mux_get_periph,
   .mux_A_periph   = at91_mux_set_A_periph,
 @@ -495,6 +514,8 @@ static struct at91_pinctrl_mux_ops at91sam9x5_ops = {
   .set_pulldown   = at91_mux_pio3_set_pulldown,
   .get_schmitt_trig = at91_mux_pio3_get_schmitt_trig,
   .disable_schmitt_trig = at91_mux_pio3_disable_schmitt_trig,
 + .get_gpio_output = at91_mux_pio3_get_gpio_output,
 + .set_gpio_output = at91_mux_pio3_set_gpio_output,
   .irq_type   = alt_gpio_irq_type,
 };
 
 @@ -741,6 +762,10 @@ static int at91_pinconf_get(struct pinctrl_dev *pctldev,
   *config |= PULL_DOWN;
   if (info-ops-get_schmitt_trig  info-ops-get_schmitt_trig(pio, 
 pin))
   *config |= DIS_SCHMIT;
 + if (info-ops-get_gpio_output) {
 + *config |= info-ops-get_gpio_output(pio, pin) ?
 + GPIO_OUTPUT_HIGH : GPIO_OUTPUT_LOW;
 + }
 
   return 0;
 }
 @@ -778,6 +803,12 @@ static int at91_pinconf_set(struct pinctrl_dev *pctldev,
   info-ops-set_pulldown(pio, mask, config  PULL_DOWN);
   if (info-ops-disable_schmitt_trig  config  DIS_SCHMIT)
   info-ops-disable_schmitt_trig(pio, mask);
 + if (info-ops-set_gpio_output) {
 + if (config  GPIO_OUTPUT_HIGH)
 + info-ops-set_gpio_output(pio, mask, 1);
 + if (config  GPIO_OUTPUT_LOW)
 + info-ops-set_gpio_output(pio, mask, 0);
 + };
 
   } /* for each config */
 
 diff --git a/include/dt-bindings/pinctrl/at91.h 
 b/include/dt-bindings/pinctrl/at91.h
 index 0fee6ff..e799268 100644
 --- a/include/dt-bindings/pinctrl/at91.h
 +++ b/include/dt-bindings/pinctrl/at91.h
 @@ -15,6 +15,8 @@
 #define AT91_PINCTRL_DEGLITCH (1  2)
 #define AT91_PINCTRL_PULL_DOWN(1  3)
 #define AT91_PINCTRL_DIS_SCHMIT   (1  4)
 +#define AT91_PINCTRL_OUTPUT_HIGH (1  5)
 +#define AT91_PINCTRL_OUTPUT_LOW  (1  6)
 #define AT91_PINCTRL_DEBOUNCE (1  16)
 #define AT91_PINCTRL_DEBOUNCE_VAL(x)  (x  17)
 
 -- 
 1.7.9.5
 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH v2] ARM: at91: add Atmel's SAMA5D3 Xplained board

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:37 Fri 07 Feb , Nicolas Ferre wrote:
> On 07/02/2014 09:01, Jean-Christophe PLAGNIOL-VILLARD :
> > On 09:35 Wed 05 Feb , Nicolas Ferre wrote:
> >> Add DT file for new SAMA5D3 Xpained board.
> >> This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
> >>
> >> Signed-off-by: Nicolas Ferre 
> >> ---
> >>  arch/arm/boot/dts/Makefile  |   1 +
> >>  arch/arm/boot/dts/at91-sama5d3_xplained.dts | 233 
> >> 
> >>  2 files changed, 234 insertions(+)
> >>  create mode 100644 arch/arm/boot/dts/at91-sama5d3_xplained.dts
> >>
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index b9d6a8b485e0..6d1e43d46187 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -38,6 +38,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb
> >>  dtb-$(CONFIG_ARCH_AT91) += at91sam9x25ek.dtb
> >>  dtb-$(CONFIG_ARCH_AT91) += at91sam9x35ek.dtb
> >>  # sama5d3
> >> +dtb-$(CONFIG_ARCH_AT91)   += at91-sama5d3_xplained.dtb
> >>  dtb-$(CONFIG_ARCH_AT91)   += sama5d31ek.dtb
> >>  dtb-$(CONFIG_ARCH_AT91)   += sama5d33ek.dtb
> >>  dtb-$(CONFIG_ARCH_AT91)   += sama5d34ek.dtb
> >> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts 
> >> b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> >> new file mode 100644
> >> index ..fb1349ca60a4
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> >> @@ -0,0 +1,233 @@
> >> +/*
> >> + * at91-sama5d3_xplained.dts - Device Tree file for the SAMA5D3 Xplained 
> >> board
> >> + *
> >> + *  Copyright (C) 2014 Atmel,
> >> + *  2014 Nicolas Ferre 
> >> + *
> >> + * Licensed under GPLv2 or later.
> >> + */
> >> +/dts-v1/;
> >> +#include "sama5d36.dtsi"
> >> +
> >> +/ {
> >> +  model = "SAMA5D3 Xplained";
> >> +  compatible = "atmel,sama5d3-xplained", "atmel,sama5d3", "atmel,sama5";
> >> +
> >> +  chosen {
> >> +  bootargs = "console=ttyS0,115200";
> > can you describe it via linux,stdout
> 
> Well I would have liked, but the code in the serial driver is not there yet.
> So, I keep it like this for the moment.
> 
> >> +  };
> >> +
> >> +  memory {
> >> +  reg = <0x2000 0x1000>;
> >> +  };
> >> +
> >> +  ahb {
> >> +  apb {
> >> +  mmc0: mmc@f000 {
> >> +  pinc§trl-names = "default";
> > ?? this is SoC should never been seen here
this need to move to dtsi not here
> >> +  pinctrl-0 = <_mmc0_clk_cmd_dat0 
> >> _mmc0_dat1_3 _mmc0_dat4_7 _mmc0_cd>;
> >> +  status = "okay";
> >> +  slot@0 {
> >> +  reg = <0>;
> >> +  bus-width = <8>;
> >> +  cd-gpios = < 0 GPIO_ACTIVE_LOW>;
> >> +  };
> >> +  };
> >> +
> >> +  spi0: spi@f0004000 {
> >> +  cs-gpios = < 13 0>, <0>, <0>, <0>;
> > if you use only one CS no need to specified all
> > 
> > we need to add macro per SoC for the hw CS used as GPIO so it's more clear
> 
> No, I do not think so.

yes as you dopy  13 0 everywhere instead of doing

#define SAMA5D3_SPI_CS0_GPIO 13 GPIO_ACTIVE_LOW

and then

cs-gpios = ;
and drop the
, <0>, <0>, <0>;

> >> +  status = "okay";
> >> +  };
> >> +
> >> +  can0: can@f000c000 {
> >> +  status = "okay";
> >> +  };
> >> +
> >> +  i2c0: i2c@f0014000 {
> >> +  status = "okay";
> >> +  };
> >> +
> >> +  i2c1: i2c@f0018000 {
> >> +  status = "okay";
> >> +  };
> >> +
> >> +  macb0: ethernet@f0028000 {
> >> +  phy-mode = "rgmii&q

Re: [GIT PULL] at91: fixes for 3.14 #1

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:36 Fri 07 Feb , Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> This is a first "fixes" series for AT91 on 3.14.
> The content is only DT-related and quite boring.
> I took the opportunity of this early "fixes" pull-request to collect
> some Documentation patches that were lying around and I guess that
> they can be merged by arm-soc nicely (addition of CCF to 2 drivers).
> A new board is added to the lot because it is dead simple and integrates
> well with the new sama5d36 SoC that we added earlier in this development 
> cycle.
> 
> Thanks, best regards,
> 
> The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
> 
>   Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-fixes
> 
> for you to fetch changes up to b7c2b6157079811586180d13c44a1095b57c2d47:
> 
>   ARM: at91: add Atmel's SAMA5D3 Xplained board (2014-02-07 17:20:39 +0100)
> 
> 
> First series of AT91 fixes for 3.14.
> All of them are DT-related.
> - fixes for typos in i2c and ohci clocks
> - addition of a USB host node for at91sam9n12ek
> - 2 DT documentation updates that have been sent a long time ago
> - a new board based on the sama5d36 SoC
> 
> 
> Bo Shen (1):
>   ARM: at91: enable USB host on at91sam9n12ek board
> 
> Boris BREZILLON (3):
>   ARM: at91/dt: fix sama5d3 ohci hclk clock reference
>   mmc: atmel-mci: document clock properties
>   spi/atmel: document clock properties
> 
> Jean-Jacques Hiblot (1):
>   ARM: at91/dt: sam9263: fix compatibility string for the I2C
> 
> Nicolas Ferre (1):
>   ARM: at91: add Atmel's SAMA5D3 Xplained board

still comment on it please drop it on the PULL

Best Regards,
J.
> 
>  .../devicetree/bindings/mmc/atmel-hsmci.txt|   5 +
>  .../devicetree/bindings/spi/spi_atmel.txt  |   5 +
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/at91-sama5d3_xplained.dts| 229 
> +
>  arch/arm/boot/dts/at91sam9263.dtsi |   2 +-
>  arch/arm/boot/dts/at91sam9n12ek.dts|   4 +
>  arch/arm/boot/dts/sama5d3.dtsi |   2 +-
>  7 files changed, 246 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/at91-sama5d3_xplained.dts
> 
> -- 
> Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] USB: at91: fix the number of endpoint parameter

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:06 Tue 21 Jan , Nicolas Ferre wrote:
> On 21/01/2014 09:12, Bo Shen :
> > Hi J,
> > 
> > On 01/21/2014 01:49 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 11:39 Mon 20 Jan , Bo Shen wrote:
> >>> Hi J,
> >>>
> >>> On 01/18/2014 01:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>> On 10:59 Fri 17 Jan , Bo Shen wrote:
> >>>>> In sama5d3 SoC, there are 16 endpoints. As the USBA_NR_ENDPOINTS
> >>>>> is only 7. So, fix it for sama5d3 SoC using the udc->num_ep.
> >>>>>
> >>>>> Signed-off-by: Bo Shen 
> >>>>> ---
> >>>>>
> >>>>>   drivers/usb/gadget/atmel_usba_udc.c | 2 +-
> >>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/usb/gadget/atmel_usba_udc.c 
> >>>>> b/drivers/usb/gadget/atmel_usba_udc.c
> >>>>> index 2cb52e0..7e67a81 100644
> >>>>> --- a/drivers/usb/gadget/atmel_usba_udc.c
> >>>>> +++ b/drivers/usb/gadget/atmel_usba_udc.c
> >>>>> @@ -1670,7 +1670,7 @@ static irqreturn_t usba_udc_irq(int irq, void 
> >>>>> *devid)
> >>>>> if (ep_status) {
> >>>>> int i;
> >>>>>
> >>>>> -   for (i = 0; i < USBA_NR_ENDPOINTS; i++)
> >>>>> +   for (i = 0; i < udc->num_ep; i++)
> >>>>
> >>>> no the limit need to specified in the driver as a checkpoint by the 
> >>>> compatible
> >>>> or platform driver id
> >>>
> >>> You mean, we should not trust the data passed from dt node or
> >>> platform data? Or do you think we should do double confirm?
> >>
> >> no base on the driver name or the compatible you will known the MAX EP
> >>
> >> not based on the dt ep description
> >>
> >> as we do on pinctrl-at91
> > 
> > I am sorry, I am not fully get it after reading the code of 
> > pinctrl-at91.c, can you give the example code in pinctrl-at91.c?
> > 
> > Btw, the udc->num_ep is get from the following code.
> > for dt
> > --->8---
> > while ((pp = of_get_next_child(np, pp)))
> > udc->num_ep++;
> > ---<8---
> > 
> > for non-dt
> > --->8---
> > udc->num_ep = pdata->num_ep;
> > ---8<---
> 
> It seems to me pretty valid to use num_ep in this driver and not have to
> rely on another compatibility string just for this.
> The information is here, it is retrieved pretty cleanly so I vote for a
> simple use of it: if we introduce another information we will have to
> double check the cross errors that would happen...

here is the key point you describe the HW

so choose detect the IP version and then check we do not describe  too many EP
or you prove the correct compatible so we known this not the same IP
and we can check the DT information

Best Regards,
J.
> 
> Bye,
> 
> >>>>> if (ep_status & (1 << i)) {
> >>>>> if (ep_is_control(>usba_ep[i]))
> >>>>> usba_control_irq(udc, 
> >>>>> >usba_ep[i]);
> >>>>> --
> >>>>> 1.8.5.2
> >>>>>
> >>>
> >>> Best Regards,
> >>> Bo Shen
> > 
> > Best Regards,
> > Bo Shen
> > 
> 
> 
> -- 
> Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 07/12] at91: dt: smc: Added smc bus driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:31 Thu 09 Jan , Jean-Jacques Hiblot wrote:
> The EBI/SMC external interface is used to access external peripherals (NAND
> and Ethernet controller in the case of sam9261ek). Different configurations 
> and
> timings are required for those peripherals. This bus driver can be used to
> setup the bus timings/configuration from the device tree.
> It currently accepts timings in clock period and in nanoseconds.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---

NACK on the binding

will comment on the patch

Best Regards,
J.
>  drivers/memory/Kconfig |  10 ++
>  drivers/memory/Makefile|   1 +
>  drivers/memory/atmel-smc.c | 431 
> +
>  3 files changed, 442 insertions(+)
>  create mode 100644 drivers/memory/atmel-smc.c
> 
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index 29a11db..fbdfd63 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -50,4 +50,14 @@ config TEGRA30_MC
> analysis, especially for IOMMU/SMMU(System Memory Management
> Unit) module.
>  
> +config ATMEL_SMC
> + bool "Atmel SMC/EBI driver"
> + default y
> + depends on SOC_AT91SAM9 && OF
> + help
> +   Driver for Atmel SMC/EBI controller.
> +   Used to configure the EBI (external bus interface) when the device-
> +   tree is used. This bus supports NANDs, external ethernet controller,
> +   SRAMs, ATA devices, etc.
> +
>  endif
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index 969d923..101abc4 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_TI_EMIF) += emif.o
>  obj-$(CONFIG_MVEBU_DEVBUS)   += mvebu-devbus.o
>  obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
>  obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
> +obj-$(CONFIG_ATMEL_SMC)+= atmel-smc.o
> diff --git a/drivers/memory/atmel-smc.c b/drivers/memory/atmel-smc.c
> new file mode 100644
> index 000..0a1d9ba
> --- /dev/null
> +++ b/drivers/memory/atmel-smc.c
> @@ -0,0 +1,431 @@
> +/*
> + * EBI driver for Atmel SAM9 chips
> + * inspired by the fsl weim bus driver
> + *
> + * Copyright (C) 2013 JJ Hiblot.
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct  smc_data {
> + struct clk *bus_clk;
> + void __iomem *base;
> + struct device *dev;
> +};
> +
> +struct at91_smc_devtype {
> + unsigned intcs_count;
> +};
> +
> +static const struct at91_smc_devtype sam9261_smc_devtype = {
> + .cs_count   = 6,
> +};
> +
> +static const struct of_device_id smc_id_table[] = {
> + { .compatible = "atmel,at91sam9261-smc", .data = _smc_devtype},
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, smc_id_table);
> +
> +struct smc_parameters_type {
> + const char *name;
> + u16 width;
> + u16 shift;
> +};
> +
> +static const struct smc_parameters_type smc_parameters[] = {
> + {"smc,burst_size",  2, 28},
> + {"smc,burst_enabled",   1, 24},
> + {"smc,tdf_mode",1, 20},
> + {"smc,bus_width",   2, 12},
> + {"smc,byte_access_type", 1,  8},
> + {"smc,nwait_mode",  2,  4},
> + {"smc,write_mode",  1,  0},
> + {"smc,read_mode",   1,  1},
> + {NULL}
> +};
> +
> +static int get_mode_register_from_dt(struct smc_data *smc,
> +  struct device_node *np,
> +  struct sam9_smc_config *cfg)
> +{
> + int ret;
> + u32 val;
> + struct device *dev = smc->dev;
> + const struct smc_parameters_type *p = smc_parameters;
> + u32 mode = cfg->mode;
> +
> + while (p->name) {
> + ret = of_property_read_u32(np, p->name , );
> + if (ret == -EINVAL) {
> + dev_dbg(dev, "%s: property %s not set.\n", np->name,
> + p->name);
> + p++;
> + continue;
> + } else if (ret) {
> + dev_err(dev, "%s: can't get property %s.\n", np->name,
> + p->name);
> + return ret;
> + }
> + if (val >= (1 + dev_err(dev, "%s: property %s out of range.\n",
> + np->name, p->name);
> + return -ERANGE;
> + }
> + mode &= ~(((1shift);
> + mode |= (val << p->shift);
> + p++;
> + }
> + cfg->mode = mode;
> + return 0;
> +}
> +
> +static int generic_timing_from_dt(struct smc_data *smc, struct device_node 
> *np,
> +   struct sam9_smc_config *cfg)
> +{
> + u32 val;
> +
> + if (!of_property_read_u32(np, "smc,ncs_read_setup" , ))
> + 

Re: [PATCH v2] ARM: at91: add Atmel's SAMA5D3 Xplained board

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:35 Wed 05 Feb , Nicolas Ferre wrote:
> Add DT file for new SAMA5D3 Xpained board.
> This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
> 
> Signed-off-by: Nicolas Ferre 
> ---
>  arch/arm/boot/dts/Makefile  |   1 +
>  arch/arm/boot/dts/at91-sama5d3_xplained.dts | 233 
> 
>  2 files changed, 234 insertions(+)
>  create mode 100644 arch/arm/boot/dts/at91-sama5d3_xplained.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b9d6a8b485e0..6d1e43d46187 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -38,6 +38,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb
>  dtb-$(CONFIG_ARCH_AT91) += at91sam9x25ek.dtb
>  dtb-$(CONFIG_ARCH_AT91) += at91sam9x35ek.dtb
>  # sama5d3
> +dtb-$(CONFIG_ARCH_AT91)  += at91-sama5d3_xplained.dtb
>  dtb-$(CONFIG_ARCH_AT91)  += sama5d31ek.dtb
>  dtb-$(CONFIG_ARCH_AT91)  += sama5d33ek.dtb
>  dtb-$(CONFIG_ARCH_AT91)  += sama5d34ek.dtb
> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts 
> b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> new file mode 100644
> index ..fb1349ca60a4
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> @@ -0,0 +1,233 @@
> +/*
> + * at91-sama5d3_xplained.dts - Device Tree file for the SAMA5D3 Xplained 
> board
> + *
> + *  Copyright (C) 2014 Atmel,
> + * 2014 Nicolas Ferre 
> + *
> + * Licensed under GPLv2 or later.
> + */
> +/dts-v1/;
> +#include "sama5d36.dtsi"
> +
> +/ {
> + model = "SAMA5D3 Xplained";
> + compatible = "atmel,sama5d3-xplained", "atmel,sama5d3", "atmel,sama5";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
can you describe it via linux,stdout
> + };
> +
> + memory {
> + reg = <0x2000 0x1000>;
> + };
> +
> + ahb {
> + apb {
> + mmc0: mmc@f000 {
> + pinc§trl-names = "default";
?? this is SoC should never been seen here
> + pinctrl-0 = <_mmc0_clk_cmd_dat0 
> _mmc0_dat1_3 _mmc0_dat4_7 _mmc0_cd>;
> + status = "okay";
> + slot@0 {
> + reg = <0>;
> + bus-width = <8>;
> + cd-gpios = < 0 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + spi0: spi@f0004000 {
> + cs-gpios = < 13 0>, <0>, <0>, <0>;
if you use only one CS no need to specified all

we need to add macro per SoC for the hw CS used as GPIO so it's more clear
> + status = "okay";
> + };
> +
> + can0: can@f000c000 {
> + status = "okay";
> + };
> +
> + i2c0: i2c@f0014000 {
> + status = "okay";
> + };
> +
> + i2c1: i2c@f0018000 {
> + status = "okay";
> + };
> +
> + macb0: ethernet@f0028000 {
> + phy-mode = "rgmii";
> + status = "okay";
> + };
> +
> + usart0: serial@f001c000 {
> + status = "okay";
> + };
> +
> + usart1: serial@f002 {
> + pinctrl-names = "default";
same as mmc
> + pinctrl-0 = <_usart1 
> _usart1_rts_cts>;
> + status = "okay";
> + };
> +
> + uart0: serial@f0024000 {
> + status = "okay";
> + };
> +
> + mmc1: mmc@f800 {
> + pinctrl-names = "default";
ditto
> + pinctrl-0 = <_mmc1_clk_cmd_dat0 
> _mmc1_dat1_3 _mmc1_cd>;
> + status = "okay";
> + slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = < 1 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + spi1: spi@f8008000 {
> + cs-gpios = < 25 0>, <0>, <0>, < 16 0>;
> + status = "okay";
> + };
> +
> + adc0: adc@f8018000 {
> + pinctrl-names = "default";
ditto
> + pinctrl-0 = <
> + _adc0_adtrg
> + _adc0_ad0
> + _adc0_ad1
> + _adc0_ad2
> +   

Re: [PATCH v2] ARM: at91: add Atmel's SAMA5D3 Xplained board

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:35 Wed 05 Feb , Nicolas Ferre wrote:
 Add DT file for new SAMA5D3 Xpained board.
 This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
 
 Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
 ---
  arch/arm/boot/dts/Makefile  |   1 +
  arch/arm/boot/dts/at91-sama5d3_xplained.dts | 233 
 
  2 files changed, 234 insertions(+)
  create mode 100644 arch/arm/boot/dts/at91-sama5d3_xplained.dts
 
 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index b9d6a8b485e0..6d1e43d46187 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -38,6 +38,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb
  dtb-$(CONFIG_ARCH_AT91) += at91sam9x25ek.dtb
  dtb-$(CONFIG_ARCH_AT91) += at91sam9x35ek.dtb
  # sama5d3
 +dtb-$(CONFIG_ARCH_AT91)  += at91-sama5d3_xplained.dtb
  dtb-$(CONFIG_ARCH_AT91)  += sama5d31ek.dtb
  dtb-$(CONFIG_ARCH_AT91)  += sama5d33ek.dtb
  dtb-$(CONFIG_ARCH_AT91)  += sama5d34ek.dtb
 diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts 
 b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
 new file mode 100644
 index ..fb1349ca60a4
 --- /dev/null
 +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
 @@ -0,0 +1,233 @@
 +/*
 + * at91-sama5d3_xplained.dts - Device Tree file for the SAMA5D3 Xplained 
 board
 + *
 + *  Copyright (C) 2014 Atmel,
 + * 2014 Nicolas Ferre nicolas.fe...@atmel.com
 + *
 + * Licensed under GPLv2 or later.
 + */
 +/dts-v1/;
 +#include sama5d36.dtsi
 +
 +/ {
 + model = SAMA5D3 Xplained;
 + compatible = atmel,sama5d3-xplained, atmel,sama5d3, atmel,sama5;
 +
 + chosen {
 + bootargs = console=ttyS0,115200;
can you describe it via linux,stdout
 + };
 +
 + memory {
 + reg = 0x2000 0x1000;
 + };
 +
 + ahb {
 + apb {
 + mmc0: mmc@f000 {
 + pinc§trl-names = default;
?? this is SoC should never been seen here
 + pinctrl-0 = pinctrl_mmc0_clk_cmd_dat0 
 pinctrl_mmc0_dat1_3 pinctrl_mmc0_dat4_7 pinctrl_mmc0_cd;
 + status = okay;
 + slot@0 {
 + reg = 0;
 + bus-width = 8;
 + cd-gpios = pioE 0 GPIO_ACTIVE_LOW;
 + };
 + };
 +
 + spi0: spi@f0004000 {
 + cs-gpios = pioD 13 0, 0, 0, 0;
if you use only one CS no need to specified all

we need to add macro per SoC for the hw CS used as GPIO so it's more clear
 + status = okay;
 + };
 +
 + can0: can@f000c000 {
 + status = okay;
 + };
 +
 + i2c0: i2c@f0014000 {
 + status = okay;
 + };
 +
 + i2c1: i2c@f0018000 {
 + status = okay;
 + };
 +
 + macb0: ethernet@f0028000 {
 + phy-mode = rgmii;
 + status = okay;
 + };
 +
 + usart0: serial@f001c000 {
 + status = okay;
 + };
 +
 + usart1: serial@f002 {
 + pinctrl-names = default;
same as mmc
 + pinctrl-0 = pinctrl_usart1 
 pinctrl_usart1_rts_cts;
 + status = okay;
 + };
 +
 + uart0: serial@f0024000 {
 + status = okay;
 + };
 +
 + mmc1: mmc@f800 {
 + pinctrl-names = default;
ditto
 + pinctrl-0 = pinctrl_mmc1_clk_cmd_dat0 
 pinctrl_mmc1_dat1_3 pinctrl_mmc1_cd;
 + status = okay;
 + slot@0 {
 + reg = 0;
 + bus-width = 4;
 + cd-gpios = pioE 1 GPIO_ACTIVE_HIGH;
 + };
 + };
 +
 + spi1: spi@f8008000 {
 + cs-gpios = pioC 25 0, 0, 0, pioD 16 0;
 + status = okay;
 + };
 +
 + adc0: adc@f8018000 {
 + pinctrl-names = default;
ditto
 + pinctrl-0 = 
 + pinctrl_adc0_adtrg
 + pinctrl_adc0_ad0
 + pinctrl_adc0_ad1
 + pinctrl_adc0_ad2
 + pinctrl_adc0_ad3
 + 

Re: [PATCH v2 07/12] at91: dt: smc: Added smc bus driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:31 Thu 09 Jan , Jean-Jacques Hiblot wrote:
 The EBI/SMC external interface is used to access external peripherals (NAND
 and Ethernet controller in the case of sam9261ek). Different configurations 
 and
 timings are required for those peripherals. This bus driver can be used to
 setup the bus timings/configuration from the device tree.
 It currently accepts timings in clock period and in nanoseconds.
 
 Signed-off-by: Jean-Jacques Hiblot jjhib...@traphandler.com
 ---

NACK on the binding

will comment on the patch

Best Regards,
J.
  drivers/memory/Kconfig |  10 ++
  drivers/memory/Makefile|   1 +
  drivers/memory/atmel-smc.c | 431 
 +
  3 files changed, 442 insertions(+)
  create mode 100644 drivers/memory/atmel-smc.c
 
 diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
 index 29a11db..fbdfd63 100644
 --- a/drivers/memory/Kconfig
 +++ b/drivers/memory/Kconfig
 @@ -50,4 +50,14 @@ config TEGRA30_MC
 analysis, especially for IOMMU/SMMU(System Memory Management
 Unit) module.
  
 +config ATMEL_SMC
 + bool Atmel SMC/EBI driver
 + default y
 + depends on SOC_AT91SAM9  OF
 + help
 +   Driver for Atmel SMC/EBI controller.
 +   Used to configure the EBI (external bus interface) when the device-
 +   tree is used. This bus supports NANDs, external ethernet controller,
 +   SRAMs, ATA devices, etc.
 +
  endif
 diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
 index 969d923..101abc4 100644
 --- a/drivers/memory/Makefile
 +++ b/drivers/memory/Makefile
 @@ -9,3 +9,4 @@ obj-$(CONFIG_TI_EMIF) += emif.o
  obj-$(CONFIG_MVEBU_DEVBUS)   += mvebu-devbus.o
  obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
  obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
 +obj-$(CONFIG_ATMEL_SMC)+= atmel-smc.o
 diff --git a/drivers/memory/atmel-smc.c b/drivers/memory/atmel-smc.c
 new file mode 100644
 index 000..0a1d9ba
 --- /dev/null
 +++ b/drivers/memory/atmel-smc.c
 @@ -0,0 +1,431 @@
 +/*
 + * EBI driver for Atmel SAM9 chips
 + * inspired by the fsl weim bus driver
 + *
 + * Copyright (C) 2013 JJ Hiblot.
 + *
 + * This file is licensed under the terms of the GNU General Public
 + * License version 2. This program is licensed as is without any
 + * warranty of any kind, whether express or implied.
 + */
 +#include linux/module.h
 +#include linux/clk.h
 +#include linux/io.h
 +#include linux/of_device.h
 +#include mach/at91sam9_smc.h
 +
 +struct  smc_data {
 + struct clk *bus_clk;
 + void __iomem *base;
 + struct device *dev;
 +};
 +
 +struct at91_smc_devtype {
 + unsigned intcs_count;
 +};
 +
 +static const struct at91_smc_devtype sam9261_smc_devtype = {
 + .cs_count   = 6,
 +};
 +
 +static const struct of_device_id smc_id_table[] = {
 + { .compatible = atmel,at91sam9261-smc, .data = sam9261_smc_devtype},
 + { }
 +};
 +MODULE_DEVICE_TABLE(of, smc_id_table);
 +
 +struct smc_parameters_type {
 + const char *name;
 + u16 width;
 + u16 shift;
 +};
 +
 +static const struct smc_parameters_type smc_parameters[] = {
 + {smc,burst_size,  2, 28},
 + {smc,burst_enabled,   1, 24},
 + {smc,tdf_mode,1, 20},
 + {smc,bus_width,   2, 12},
 + {smc,byte_access_type, 1,  8},
 + {smc,nwait_mode,  2,  4},
 + {smc,write_mode,  1,  0},
 + {smc,read_mode,   1,  1},
 + {NULL}
 +};
 +
 +static int get_mode_register_from_dt(struct smc_data *smc,
 +  struct device_node *np,
 +  struct sam9_smc_config *cfg)
 +{
 + int ret;
 + u32 val;
 + struct device *dev = smc-dev;
 + const struct smc_parameters_type *p = smc_parameters;
 + u32 mode = cfg-mode;
 +
 + while (p-name) {
 + ret = of_property_read_u32(np, p-name , val);
 + if (ret == -EINVAL) {
 + dev_dbg(dev, %s: property %s not set.\n, np-name,
 + p-name);
 + p++;
 + continue;
 + } else if (ret) {
 + dev_err(dev, %s: can't get property %s.\n, np-name,
 + p-name);
 + return ret;
 + }
 + if (val = (1p-width)) {
 + dev_err(dev, %s: property %s out of range.\n,
 + np-name, p-name);
 + return -ERANGE;
 + }
 + mode = ~(((1p-width)-1)  p-shift);
 + mode |= (val  p-shift);
 + p++;
 + }
 + cfg-mode = mode;
 + return 0;
 +}
 +
 +static int generic_timing_from_dt(struct smc_data *smc, struct device_node 
 *np,
 +   struct sam9_smc_config *cfg)
 +{
 + u32 val;
 +
 + if (!of_property_read_u32(np, smc,ncs_read_setup , val))
 + cfg-ncs_read_setup = val;
 +
 + if (!of_property_read_u32(np, smc,nrd_setup , 

Re: [PATCH 1/2] USB: at91: fix the number of endpoint parameter

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:06 Tue 21 Jan , Nicolas Ferre wrote:
 On 21/01/2014 09:12, Bo Shen :
  Hi J,
  
  On 01/21/2014 01:49 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
  On 11:39 Mon 20 Jan , Bo Shen wrote:
  Hi J,
 
  On 01/18/2014 01:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
  On 10:59 Fri 17 Jan , Bo Shen wrote:
  In sama5d3 SoC, there are 16 endpoints. As the USBA_NR_ENDPOINTS
  is only 7. So, fix it for sama5d3 SoC using the udc-num_ep.
 
  Signed-off-by: Bo Shen voice.s...@atmel.com
  ---
 
drivers/usb/gadget/atmel_usba_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/drivers/usb/gadget/atmel_usba_udc.c 
  b/drivers/usb/gadget/atmel_usba_udc.c
  index 2cb52e0..7e67a81 100644
  --- a/drivers/usb/gadget/atmel_usba_udc.c
  +++ b/drivers/usb/gadget/atmel_usba_udc.c
  @@ -1670,7 +1670,7 @@ static irqreturn_t usba_udc_irq(int irq, void 
  *devid)
  if (ep_status) {
  int i;
 
  -   for (i = 0; i  USBA_NR_ENDPOINTS; i++)
  +   for (i = 0; i  udc-num_ep; i++)
 
  no the limit need to specified in the driver as a checkpoint by the 
  compatible
  or platform driver id
 
  You mean, we should not trust the data passed from dt node or
  platform data? Or do you think we should do double confirm?
 
  no base on the driver name or the compatible you will known the MAX EP
 
  not based on the dt ep description
 
  as we do on pinctrl-at91
  
  I am sorry, I am not fully get it after reading the code of 
  pinctrl-at91.c, can you give the example code in pinctrl-at91.c?
  
  Btw, the udc-num_ep is get from the following code.
  for dt
  ---8---
  while ((pp = of_get_next_child(np, pp)))
  udc-num_ep++;
  ---8---
  
  for non-dt
  ---8---
  udc-num_ep = pdata-num_ep;
  ---8---
 
 It seems to me pretty valid to use num_ep in this driver and not have to
 rely on another compatibility string just for this.
 The information is here, it is retrieved pretty cleanly so I vote for a
 simple use of it: if we introduce another information we will have to
 double check the cross errors that would happen...

here is the key point you describe the HW

so choose detect the IP version and then check we do not describe  too many EP
or you prove the correct compatible so we known this not the same IP
and we can check the DT information

Best Regards,
J.
 
 Bye,
 
  if (ep_status  (1  i)) {
  if (ep_is_control(udc-usba_ep[i]))
  usba_control_irq(udc, 
  udc-usba_ep[i]);
  --
  1.8.5.2
 
 
  Best Regards,
  Bo Shen
  
  Best Regards,
  Bo Shen
  
 
 
 -- 
 Nicolas Ferre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] at91: fixes for 3.14 #1

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:36 Fri 07 Feb , Nicolas Ferre wrote:
 Arnd, Olof, Kevin,
 
 This is a first fixes series for AT91 on 3.14.
 The content is only DT-related and quite boring.
 I took the opportunity of this early fixes pull-request to collect
 some Documentation patches that were lying around and I guess that
 they can be merged by arm-soc nicely (addition of CCF to 2 drivers).
 A new board is added to the lot because it is dead simple and integrates
 well with the new sama5d36 SoC that we added earlier in this development 
 cycle.
 
 Thanks, best regards,
 
 The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
 
   Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
 
 are available in the git repository at:
 
   git://github.com/at91linux/linux-at91.git tags/at91-fixes
 
 for you to fetch changes up to b7c2b6157079811586180d13c44a1095b57c2d47:
 
   ARM: at91: add Atmel's SAMA5D3 Xplained board (2014-02-07 17:20:39 +0100)
 
 
 First series of AT91 fixes for 3.14.
 All of them are DT-related.
 - fixes for typos in i2c and ohci clocks
 - addition of a USB host node for at91sam9n12ek
 - 2 DT documentation updates that have been sent a long time ago
 - a new board based on the sama5d36 SoC
 
 
 Bo Shen (1):
   ARM: at91: enable USB host on at91sam9n12ek board
 
 Boris BREZILLON (3):
   ARM: at91/dt: fix sama5d3 ohci hclk clock reference
   mmc: atmel-mci: document clock properties
   spi/atmel: document clock properties
 
 Jean-Jacques Hiblot (1):
   ARM: at91/dt: sam9263: fix compatibility string for the I2C
 
 Nicolas Ferre (1):
   ARM: at91: add Atmel's SAMA5D3 Xplained board

still comment on it please drop it on the PULL

Best Regards,
J.
 
  .../devicetree/bindings/mmc/atmel-hsmci.txt|   5 +
  .../devicetree/bindings/spi/spi_atmel.txt  |   5 +
  arch/arm/boot/dts/Makefile |   1 +
  arch/arm/boot/dts/at91-sama5d3_xplained.dts| 229 
 +
  arch/arm/boot/dts/at91sam9263.dtsi |   2 +-
  arch/arm/boot/dts/at91sam9n12ek.dts|   4 +
  arch/arm/boot/dts/sama5d3.dtsi |   2 +-
  7 files changed, 246 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/boot/dts/at91-sama5d3_xplained.dts
 
 -- 
 Nicolas Ferre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: at91: add Atmel's SAMA5D3 Xplained board

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:37 Fri 07 Feb , Nicolas Ferre wrote:
 On 07/02/2014 09:01, Jean-Christophe PLAGNIOL-VILLARD :
  On 09:35 Wed 05 Feb , Nicolas Ferre wrote:
  Add DT file for new SAMA5D3 Xpained board.
  This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
 
  Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
  ---
   arch/arm/boot/dts/Makefile  |   1 +
   arch/arm/boot/dts/at91-sama5d3_xplained.dts | 233 
  
   2 files changed, 234 insertions(+)
   create mode 100644 arch/arm/boot/dts/at91-sama5d3_xplained.dts
 
  diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
  index b9d6a8b485e0..6d1e43d46187 100644
  --- a/arch/arm/boot/dts/Makefile
  +++ b/arch/arm/boot/dts/Makefile
  @@ -38,6 +38,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb
   dtb-$(CONFIG_ARCH_AT91) += at91sam9x25ek.dtb
   dtb-$(CONFIG_ARCH_AT91) += at91sam9x35ek.dtb
   # sama5d3
  +dtb-$(CONFIG_ARCH_AT91)   += at91-sama5d3_xplained.dtb
   dtb-$(CONFIG_ARCH_AT91)   += sama5d31ek.dtb
   dtb-$(CONFIG_ARCH_AT91)   += sama5d33ek.dtb
   dtb-$(CONFIG_ARCH_AT91)   += sama5d34ek.dtb
  diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts 
  b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
  new file mode 100644
  index ..fb1349ca60a4
  --- /dev/null
  +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
  @@ -0,0 +1,233 @@
  +/*
  + * at91-sama5d3_xplained.dts - Device Tree file for the SAMA5D3 Xplained 
  board
  + *
  + *  Copyright (C) 2014 Atmel,
  + *  2014 Nicolas Ferre nicolas.fe...@atmel.com
  + *
  + * Licensed under GPLv2 or later.
  + */
  +/dts-v1/;
  +#include sama5d36.dtsi
  +
  +/ {
  +  model = SAMA5D3 Xplained;
  +  compatible = atmel,sama5d3-xplained, atmel,sama5d3, atmel,sama5;
  +
  +  chosen {
  +  bootargs = console=ttyS0,115200;
  can you describe it via linux,stdout
 
 Well I would have liked, but the code in the serial driver is not there yet.
 So, I keep it like this for the moment.
 
  +  };
  +
  +  memory {
  +  reg = 0x2000 0x1000;
  +  };
  +
  +  ahb {
  +  apb {
  +  mmc0: mmc@f000 {
  +  pinc§trl-names = default;
  ?? this is SoC should never been seen here
this need to move to dtsi not here
  +  pinctrl-0 = pinctrl_mmc0_clk_cmd_dat0 
  pinctrl_mmc0_dat1_3 pinctrl_mmc0_dat4_7 pinctrl_mmc0_cd;
  +  status = okay;
  +  slot@0 {
  +  reg = 0;
  +  bus-width = 8;
  +  cd-gpios = pioE 0 GPIO_ACTIVE_LOW;
  +  };
  +  };
  +
  +  spi0: spi@f0004000 {
  +  cs-gpios = pioD 13 0, 0, 0, 0;
  if you use only one CS no need to specified all
  
  we need to add macro per SoC for the hw CS used as GPIO so it's more clear
 
 No, I do not think so.

yes as you dopy pioD 13 0 everywhere instead of doing

#define SAMA5D3_SPI_CS0_GPIOpioD 13 GPIO_ACTIVE_LOW

and then

cs-gpios = SAMA5D3_SPI_CS0_GPIO;
and drop the
, 0, 0, 0;

  +  status = okay;
  +  };
  +
  +  can0: can@f000c000 {
  +  status = okay;
  +  };
  +
  +  i2c0: i2c@f0014000 {
  +  status = okay;
  +  };
  +
  +  i2c1: i2c@f0018000 {
  +  status = okay;
  +  };
  +
  +  macb0: ethernet@f0028000 {
  +  phy-mode = rgmii;
  +  status = okay;
  +  };
  +
  +  usart0: serial@f001c000 {
  +  status = okay;
  +  };
  +
  +  usart1: serial@f002 {
  +  pinctrl-names = default;
  same as mmc
  +  pinctrl-0 = pinctrl_usart1 
  pinctrl_usart1_rts_cts;
  +  status = okay;
  +  };
  +
  +  uart0: serial@f0024000 {
  +  status = okay;
  +  };
  +
  +  mmc1: mmc@f800 {
  +  pinctrl-names = default;
  ditto
  +  pinctrl-0 = pinctrl_mmc1_clk_cmd_dat0 
  pinctrl_mmc1_dat1_3 pinctrl_mmc1_cd;
  +  status = okay;
  +  slot@0 {
  +  reg = 0;
  +  bus-width = 4;
  +  cd-gpios = pioE 1 GPIO_ACTIVE_HIGH;
  +  };
  +  };
  +
  +  spi1: spi@f8008000 {
  +  cs-gpios = pioC 25 0, 0, 0, pioD 16 0;
  +  status = okay