Re: [PATCH] i2c: at91: Read all available bytes at once

[Ludovic Desroches]

Hi David,

On Wed, Apr 25, 2018 at 05:43:09PM +0200, David Engraf wrote:
> Hi Ludovic,
> 
> Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:
> > Hi David,
> > 
> > On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:
> > > With FIFO enabled it is possible to read multiple bytes
> > > at once in the interrupt handler as long as RXRDY is
> > > set. This may also reduce the number of interrupts.
> > > 
> > > Signed-off-by: David Engraf <david.eng...@sysgo.com>
> > > ---
> > >   drivers/i2c/busses/i2c-at91.c | 8 ++--
> > >   1 file changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> > > index bfd1fdff64a9..d01c2b2384bd 100644
> > > --- a/drivers/i2c/busses/i2c-at91.c
> > > +++ b/drivers/i2c/busses/i2c-at91.c
> > > @@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
> > > *dev_id)
> > >* the RXRDY interrupt first in order to not keep garbage data 
> > > in the
> > >* Receive Holding Register for the next transfer.
> > >*/
> > > - if (irqstatus & AT91_TWI_RXRDY)
> > > - at91_twi_read_next_byte(dev);
> > > + if (irqstatus & AT91_TWI_RXRDY) {
> > > + /* read all available bytes at once when FIFO is used */
> > > + do {
> > > + at91_twi_read_next_byte(dev);
> > > + } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);
> > 
> > You can avoid this check by using the RXFL field to know the number of
> > data you can read. Did you try to use it? If yes, did you notice some 
> > issues?
> 
> I did a quick test by reading RXFL and it worked as well but I decided to
> use the more readable solution by polling RXRDY. Also I don't need to check
> if the FIFO has been enabled.
> 
> If you prefer using RXFL I can create a new patch.

Honestly, I have no strong opinion about it. As you said you approach is
simple and easy to read.

About performances, I assume that both solutions are pretty the same for
small number of data. If the number increases, using the RXFL field
should give better results.

So I would say, maybe add a note in the commit log or in the code to
keep in mind there is this solution to go further.

Otherwise
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com>

Regards

Ludovic

> 
> Best regards
> - David
> 
> 
> > Regards
> > 
> > Ludovic
> > 
> > > + }
> > >   /*
> > >* When a NACK condition is detected, the I2C controller sets 
> > > the NACK,
> > > -- 
> > > 2.14.1
> > > 
> 

Re: [PATCH] i2c: at91: Read all available bytes at once

[Ludovic Desroches]

Hi David,

On Wed, Apr 25, 2018 at 05:43:09PM +0200, David Engraf wrote:
> Hi Ludovic,
> 
> Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:
> > Hi David,
> > 
> > On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:
> > > With FIFO enabled it is possible to read multiple bytes
> > > at once in the interrupt handler as long as RXRDY is
> > > set. This may also reduce the number of interrupts.
> > > 
> > > Signed-off-by: David Engraf 
> > > ---
> > >   drivers/i2c/busses/i2c-at91.c | 8 ++--
> > >   1 file changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> > > index bfd1fdff64a9..d01c2b2384bd 100644
> > > --- a/drivers/i2c/busses/i2c-at91.c
> > > +++ b/drivers/i2c/busses/i2c-at91.c
> > > @@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
> > > *dev_id)
> > >* the RXRDY interrupt first in order to not keep garbage data 
> > > in the
> > >* Receive Holding Register for the next transfer.
> > >*/
> > > - if (irqstatus & AT91_TWI_RXRDY)
> > > - at91_twi_read_next_byte(dev);
> > > + if (irqstatus & AT91_TWI_RXRDY) {
> > > + /* read all available bytes at once when FIFO is used */
> > > + do {
> > > + at91_twi_read_next_byte(dev);
> > > + } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);
> > 
> > You can avoid this check by using the RXFL field to know the number of
> > data you can read. Did you try to use it? If yes, did you notice some 
> > issues?
> 
> I did a quick test by reading RXFL and it worked as well but I decided to
> use the more readable solution by polling RXRDY. Also I don't need to check
> if the FIFO has been enabled.
> 
> If you prefer using RXFL I can create a new patch.

Honestly, I have no strong opinion about it. As you said you approach is
simple and easy to read.

About performances, I assume that both solutions are pretty the same for
small number of data. If the number increases, using the RXFL field
should give better results.

So I would say, maybe add a note in the commit log or in the code to
keep in mind there is this solution to go further.

Otherwise
Acked-by: Ludovic Desroches 

Regards

Ludovic

> 
> Best regards
> - David
> 
> 
> > Regards
> > 
> > Ludovic
> > 
> > > + }
> > >   /*
> > >* When a NACK condition is detected, the I2C controller sets 
> > > the NACK,
> > > -- 
> > > 2.14.1
> > > 
> 

Re: [PATCH] i2c: at91: Read all available bytes at once

[Ludovic Desroches]

Hi David,

On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:
> With FIFO enabled it is possible to read multiple bytes
> at once in the interrupt handler as long as RXRDY is
> set. This may also reduce the number of interrupts.
> 
> Signed-off-by: David Engraf 
> ---
>  drivers/i2c/busses/i2c-at91.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index bfd1fdff64a9..d01c2b2384bd 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
> *dev_id)
>* the RXRDY interrupt first in order to not keep garbage data in the
>* Receive Holding Register for the next transfer.
>*/
> - if (irqstatus & AT91_TWI_RXRDY)
> - at91_twi_read_next_byte(dev);
> + if (irqstatus & AT91_TWI_RXRDY) {
> + /* read all available bytes at once when FIFO is used */
> + do {
> + at91_twi_read_next_byte(dev);
> + } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);

You can avoid this check by using the RXFL field to know the number of
data you can read. Did you try to use it? If yes, did you notice some issues?

Regards

Ludovic

> + }
>  
>   /*
>* When a NACK condition is detected, the I2C controller sets the NACK,
> -- 
> 2.14.1
> 

Re: [PATCH] i2c: at91: Read all available bytes at once

[Ludovic Desroches]

Hi David,

On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:
> With FIFO enabled it is possible to read multiple bytes
> at once in the interrupt handler as long as RXRDY is
> set. This may also reduce the number of interrupts.
> 
> Signed-off-by: David Engraf 
> ---
>  drivers/i2c/busses/i2c-at91.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index bfd1fdff64a9..d01c2b2384bd 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
> *dev_id)
>* the RXRDY interrupt first in order to not keep garbage data in the
>* Receive Holding Register for the next transfer.
>*/
> - if (irqstatus & AT91_TWI_RXRDY)
> - at91_twi_read_next_byte(dev);
> + if (irqstatus & AT91_TWI_RXRDY) {
> + /* read all available bytes at once when FIFO is used */
> + do {
> + at91_twi_read_next_byte(dev);
> + } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);

You can avoid this check by using the RXFL field to know the number of
data you can read. Did you try to use it? If yes, did you notice some issues?

Regards

Ludovic

> + }
>  
>   /*
>* When a NACK condition is detected, the I2C controller sets the NACK,
> -- 
> 2.14.1
> 

Re: [PATCH 2/6] dmaengine: at_xdmac: simplify getting .drvdata

[Ludovic Desroches]

On Sun, Apr 22, 2018 at 11:14:10AM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com>

Thanks
> ---
> 
> Build tested only. buildbot is happy. Please apply to your tree directly.
> 
>  drivers/dma/at_xdmac.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index 94236ec9d410..4bf72561667c 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -1833,8 +1833,7 @@ static void at_xdmac_free_chan_resources(struct 
> dma_chan *chan)
>  #ifdef CONFIG_PM
>  static int atmel_xdmac_prepare(struct device *dev)
>  {
> - struct platform_device  *pdev = to_platform_device(dev);
> - struct at_xdmac *atxdmac = platform_get_drvdata(pdev);
> + struct at_xdmac *atxdmac = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   list_for_each_entry_safe(chan, _chan, >dma.channels, 
> device_node) {
> @@ -1853,8 +1852,7 @@ static int atmel_xdmac_prepare(struct device *dev)
>  #ifdef CONFIG_PM_SLEEP
>  static int atmel_xdmac_suspend(struct device *dev)
>  {
> - struct platform_device  *pdev = to_platform_device(dev);
> - struct at_xdmac *atxdmac = platform_get_drvdata(pdev);
> + struct at_xdmac *atxdmac = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   list_for_each_entry_safe(chan, _chan, >dma.channels, 
> device_node) {
> @@ -1878,8 +1876,7 @@ static int atmel_xdmac_suspend(struct device *dev)
>  
>  static int atmel_xdmac_resume(struct device *dev)
>  {
> - struct platform_device  *pdev = to_platform_device(dev);
> - struct at_xdmac *atxdmac = platform_get_drvdata(pdev);
> + struct at_xdmac *atxdmac = dev_get_drvdata(dev);
>   struct at_xdmac_chan*atchan;
>   struct dma_chan *chan, *_chan;
>   int i;
> -- 
> 2.11.0
> 

Re: [PATCH 2/6] dmaengine: at_xdmac: simplify getting .drvdata

[Ludovic Desroches]

On Sun, Apr 22, 2018 at 11:14:10AM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 
Acked-by: Ludovic Desroches 

Thanks
> ---
> 
> Build tested only. buildbot is happy. Please apply to your tree directly.
> 
>  drivers/dma/at_xdmac.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index 94236ec9d410..4bf72561667c 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -1833,8 +1833,7 @@ static void at_xdmac_free_chan_resources(struct 
> dma_chan *chan)
>  #ifdef CONFIG_PM
>  static int atmel_xdmac_prepare(struct device *dev)
>  {
> - struct platform_device  *pdev = to_platform_device(dev);
> - struct at_xdmac *atxdmac = platform_get_drvdata(pdev);
> + struct at_xdmac *atxdmac = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   list_for_each_entry_safe(chan, _chan, >dma.channels, 
> device_node) {
> @@ -1853,8 +1852,7 @@ static int atmel_xdmac_prepare(struct device *dev)
>  #ifdef CONFIG_PM_SLEEP
>  static int atmel_xdmac_suspend(struct device *dev)
>  {
> - struct platform_device  *pdev = to_platform_device(dev);
> - struct at_xdmac *atxdmac = platform_get_drvdata(pdev);
> + struct at_xdmac *atxdmac = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   list_for_each_entry_safe(chan, _chan, >dma.channels, 
> device_node) {
> @@ -1878,8 +1876,7 @@ static int atmel_xdmac_suspend(struct device *dev)
>  
>  static int atmel_xdmac_resume(struct device *dev)
>  {
> - struct platform_device  *pdev = to_platform_device(dev);
> - struct at_xdmac *atxdmac = platform_get_drvdata(pdev);
> + struct at_xdmac *atxdmac = dev_get_drvdata(dev);
>   struct at_xdmac_chan*atchan;
>   struct dma_chan *chan, *_chan;
>   int i;
> -- 
> 2.11.0
> 

Re: [PATCH 1/6] dmaengine: at_hdmac: simplify getting .drvdata

[Ludovic Desroches]

On Sun, Apr 22, 2018 at 11:14:09AM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com> 

Thanks
> ---
> 
> Build tested only. buildbot is happy. Please apply to your tree directly.
> 
>  drivers/dma/at_hdmac.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index a861b5b4d443..75f38d19fcbe 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -2041,8 +2041,7 @@ static void at_dma_shutdown(struct platform_device 
> *pdev)
>  
>  static int at_dma_prepare(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct at_dma *atdma = platform_get_drvdata(pdev);
> + struct at_dma *atdma = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   list_for_each_entry_safe(chan, _chan, >dma_common.channels,
> @@ -2076,8 +2075,7 @@ static void atc_suspend_cyclic(struct at_dma_chan 
> *atchan)
>  
>  static int at_dma_suspend_noirq(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct at_dma *atdma = platform_get_drvdata(pdev);
> + struct at_dma *atdma = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   /* preserve data */
> @@ -2118,8 +2116,7 @@ static void atc_resume_cyclic(struct at_dma_chan 
> *atchan)
>  
>  static int at_dma_resume_noirq(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct at_dma *atdma = platform_get_drvdata(pdev);
> + struct at_dma *atdma = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   /* bring back DMA controller */
> -- 
> 2.11.0
> 

Re: [PATCH 1/6] dmaengine: at_hdmac: simplify getting .drvdata

[Ludovic Desroches]

On Sun, Apr 22, 2018 at 11:14:09AM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 
Acked-by: Ludovic Desroches  

Thanks
> ---
> 
> Build tested only. buildbot is happy. Please apply to your tree directly.
> 
>  drivers/dma/at_hdmac.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index a861b5b4d443..75f38d19fcbe 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -2041,8 +2041,7 @@ static void at_dma_shutdown(struct platform_device 
> *pdev)
>  
>  static int at_dma_prepare(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct at_dma *atdma = platform_get_drvdata(pdev);
> + struct at_dma *atdma = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   list_for_each_entry_safe(chan, _chan, >dma_common.channels,
> @@ -2076,8 +2075,7 @@ static void atc_suspend_cyclic(struct at_dma_chan 
> *atchan)
>  
>  static int at_dma_suspend_noirq(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct at_dma *atdma = platform_get_drvdata(pdev);
> + struct at_dma *atdma = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   /* preserve data */
> @@ -2118,8 +2116,7 @@ static void atc_resume_cyclic(struct at_dma_chan 
> *atchan)
>  
>  static int at_dma_resume_noirq(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct at_dma *atdma = platform_get_drvdata(pdev);
> + struct at_dma *atdma = dev_get_drvdata(dev);
>   struct dma_chan *chan, *_chan;
>  
>   /* bring back DMA controller */
> -- 
> 2.11.0
> 

Re: [PATCH 3/3] usb: gadget: udc: atmel: Fix indenting

[Ludovic Desroches]

On Mon, Apr 16, 2018 at 11:34:05AM +0200, Romain Izard wrote:
> Fix the fallout of the conversion to GPIO descriptors in 3df034081021.
> 
> Signed-off-by: Romain Izard <romain.izard@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index b9623e228609..2f586f2bda7e 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -2277,15 +2277,15 @@ static int usba_udc_probe(struct platform_device 
> *pdev)
>   if (udc->vbus_pin) {
>   irq_set_status_flags(gpiod_to_irq(udc->vbus_pin), IRQ_NOAUTOEN);
>   ret = devm_request_threaded_irq(>dev,
> - gpiod_to_irq(udc->vbus_pin), NULL,
> - usba_vbus_irq_thread, 
> USBA_VBUS_IRQFLAGS,
> - "atmel_usba_udc", udc);
> - if (ret) {
> - udc->vbus_pin = NULL;
> - dev_warn(>pdev->dev,
> -  "failed to request vbus irq; "
> -  "assuming always on\n");
> - }
> + gpiod_to_irq(udc->vbus_pin), NULL,
> + usba_vbus_irq_thread, USBA_VBUS_IRQFLAGS,
> + "atmel_usba_udc", udc);
> + if (ret) {
> + udc->vbus_pin = NULL;
> + dev_warn(>pdev->dev,
> +  "failed to request vbus irq; "
> +  "assuming always on\n");
> + }
>   }
>  
>   ret = usb_add_gadget_udc(>dev, >gadget);
> -- 
> 2.14.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] usb: gadget: udc: atmel: Fix indenting

[Ludovic Desroches]

On Mon, Apr 16, 2018 at 11:34:05AM +0200, Romain Izard wrote:
> Fix the fallout of the conversion to GPIO descriptors in 3df034081021.
> 
> Signed-off-by: Romain Izard 
Acked-by: Ludovic Desroches 
> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index b9623e228609..2f586f2bda7e 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -2277,15 +2277,15 @@ static int usba_udc_probe(struct platform_device 
> *pdev)
>   if (udc->vbus_pin) {
>   irq_set_status_flags(gpiod_to_irq(udc->vbus_pin), IRQ_NOAUTOEN);
>   ret = devm_request_threaded_irq(>dev,
> - gpiod_to_irq(udc->vbus_pin), NULL,
> - usba_vbus_irq_thread, 
> USBA_VBUS_IRQFLAGS,
> - "atmel_usba_udc", udc);
> - if (ret) {
> - udc->vbus_pin = NULL;
> - dev_warn(>pdev->dev,
> -  "failed to request vbus irq; "
> -  "assuming always on\n");
> - }
> + gpiod_to_irq(udc->vbus_pin), NULL,
> + usba_vbus_irq_thread, USBA_VBUS_IRQFLAGS,
> + "atmel_usba_udc", udc);
> + if (ret) {
> + udc->vbus_pin = NULL;
> + dev_warn(>pdev->dev,
> +  "failed to request vbus irq; "
> +  "assuming always on\n");
> + }
>   }
>  
>   ret = usb_add_gadget_udc(>dev, >gadget);
> -- 
> 2.14.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] usb: gadget: udc: atmel: Remove obsolete include

[Ludovic Desroches]

On Mon, Apr 16, 2018 at 11:34:04AM +0200, Romain Izard wrote:
> The include defines the private platform_data structure used with AVR
> platforms. It has no user since 7c55984e191f. Remove it.
> 
> Signed-off-by: Romain Izard <romain.izard@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c |  1 -
>  include/linux/usb/atmel_usba_udc.h  | 24 
>  2 files changed, 25 deletions(-)
>  delete mode 100644 include/linux/usb/atmel_usba_udc.h
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 0fe3d0feb8f7..b9623e228609 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -20,7 +20,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/linux/usb/atmel_usba_udc.h 
> b/include/linux/usb/atmel_usba_udc.h
> deleted file mode 100644
> index 9bb00df3b53f..
> --- a/include/linux/usb/atmel_usba_udc.h
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -/*
> - * Platform data definitions for Atmel USBA gadget driver.
> - */
> -#ifndef __LINUX_USB_USBA_H
> -#define __LINUX_USB_USBA_H
> -
> -struct usba_ep_data {
> - char*name;
> - int index;
> - int fifo_size;
> - int nr_banks;
> - int can_dma;
> - int can_isoc;
> -};
> -
> -struct usba_platform_data {
> - int vbus_pin;
> - int vbus_pin_inverted;
> - int num_ep;
> - struct usba_ep_data ep[0];
> -};
> -
> -#endif /* __LINUX_USB_USBA_H */
> -- 
> 2.14.1
> 

Re: [PATCH 2/3] usb: gadget: udc: atmel: Remove obsolete include

[Ludovic Desroches]

On Mon, Apr 16, 2018 at 11:34:04AM +0200, Romain Izard wrote:
> The include defines the private platform_data structure used with AVR
> platforms. It has no user since 7c55984e191f. Remove it.
> 
> Signed-off-by: Romain Izard 
Acked-by: Ludovic Desroches 
> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c |  1 -
>  include/linux/usb/atmel_usba_udc.h  | 24 
>  2 files changed, 25 deletions(-)
>  delete mode 100644 include/linux/usb/atmel_usba_udc.h
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 0fe3d0feb8f7..b9623e228609 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -20,7 +20,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/linux/usb/atmel_usba_udc.h 
> b/include/linux/usb/atmel_usba_udc.h
> deleted file mode 100644
> index 9bb00df3b53f..
> --- a/include/linux/usb/atmel_usba_udc.h
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -/*
> - * Platform data definitions for Atmel USBA gadget driver.
> - */
> -#ifndef __LINUX_USB_USBA_H
> -#define __LINUX_USB_USBA_H
> -
> -struct usba_ep_data {
> - char*name;
> - int index;
> - int fifo_size;
> - int nr_banks;
> - int can_dma;
> - int can_isoc;
> -};
> -
> -struct usba_platform_data {
> - int vbus_pin;
> - int vbus_pin_inverted;
> - int num_ep;
> - struct usba_ep_data ep[0];
> -};
> -
> -#endif /* __LINUX_USB_USBA_H */
> -- 
> 2.14.1
> 

Re: [PATCH 1/3] usb: gadget: udc: atmel: GPIO inversion is handled by gpiod

[Ludovic Desroches]

On Mon, Apr 16, 2018 at 11:34:03AM +0200, Romain Izard wrote:
> When converting to GPIO descriptors, gpiod_get_value automatically
> handles the line inversion flags from the device tree.

Thanks, I totally missed it.

Regards

> 
> Do not invert the line twice.
> 
> Fixes: 3df034081021fa4b6967ce3364bc7d867ec1c870
> 
> Signed-off-by: Romain Izard <romain.izard@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com>

> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 3 +--
>  drivers/usb/gadget/udc/atmel_usba_udc.h | 1 -
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 27c16399c7e8..0fe3d0feb8f7 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -417,7 +417,7 @@ static inline void usba_int_enb_set(struct usba_udc *udc, 
> u32 val)
>  static int vbus_is_present(struct usba_udc *udc)
>  {
>   if (udc->vbus_pin)
> - return gpiod_get_value(udc->vbus_pin) ^ udc->vbus_pin_inverted;
> + return gpiod_get_value(udc->vbus_pin);
>  
>   /* No Vbus detection: Assume always present */
>   return 1;
> @@ -2076,7 +2076,6 @@ static struct usba_ep * atmel_udc_of_init(struct 
> platform_device *pdev,
>  
>   udc->vbus_pin = devm_gpiod_get_optional(>dev, "atmel,vbus",
>   GPIOD_IN);
> - udc->vbus_pin_inverted = gpiod_is_active_low(udc->vbus_pin);
>  
>   if (fifo_mode == 0) {
>   pp = NULL;
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.h 
> b/drivers/usb/gadget/udc/atmel_usba_udc.h
> index 969ce8f3c3e2..d7eb7cf4fd5c 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.h
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.h
> @@ -326,7 +326,6 @@ struct usba_udc {
>   const struct usba_udc_errata *errata;
>   int irq;
>   struct gpio_desc *vbus_pin;
> - int vbus_pin_inverted;
>   int num_ep;
>   int configured_ep;
>   struct usba_fifo_cfg *fifo_cfg;
> -- 
> 2.14.1
> 

Re: [PATCH 1/3] usb: gadget: udc: atmel: GPIO inversion is handled by gpiod

[Ludovic Desroches]

On Mon, Apr 16, 2018 at 11:34:03AM +0200, Romain Izard wrote:
> When converting to GPIO descriptors, gpiod_get_value automatically
> handles the line inversion flags from the device tree.

Thanks, I totally missed it.

Regards

> 
> Do not invert the line twice.
> 
> Fixes: 3df034081021fa4b6967ce3364bc7d867ec1c870
> 
> Signed-off-by: Romain Izard 
Acked-by: Ludovic Desroches 

> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 3 +--
>  drivers/usb/gadget/udc/atmel_usba_udc.h | 1 -
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 27c16399c7e8..0fe3d0feb8f7 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -417,7 +417,7 @@ static inline void usba_int_enb_set(struct usba_udc *udc, 
> u32 val)
>  static int vbus_is_present(struct usba_udc *udc)
>  {
>   if (udc->vbus_pin)
> - return gpiod_get_value(udc->vbus_pin) ^ udc->vbus_pin_inverted;
> + return gpiod_get_value(udc->vbus_pin);
>  
>   /* No Vbus detection: Assume always present */
>   return 1;
> @@ -2076,7 +2076,6 @@ static struct usba_ep * atmel_udc_of_init(struct 
> platform_device *pdev,
>  
>   udc->vbus_pin = devm_gpiod_get_optional(>dev, "atmel,vbus",
>   GPIOD_IN);
> - udc->vbus_pin_inverted = gpiod_is_active_low(udc->vbus_pin);
>  
>   if (fifo_mode == 0) {
>   pp = NULL;
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.h 
> b/drivers/usb/gadget/udc/atmel_usba_udc.h
> index 969ce8f3c3e2..d7eb7cf4fd5c 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.h
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.h
> @@ -326,7 +326,6 @@ struct usba_udc {
>   const struct usba_udc_errata *errata;
>   int irq;
>   struct gpio_desc *vbus_pin;
> - int vbus_pin_inverted;
>   int num_ep;
>   int configured_ep;
>   struct usba_fifo_cfg *fifo_cfg;
> -- 
> 2.14.1
> 

Re: [PATCH] dmaengine: at_xdmac: fix rare residue corruption

[Ludovic Desroches]

On Mon, Mar 19, 2018 at 01:26:09PM +0530, Vinod Koul wrote:
> On Thu, Mar 01, 2018 at 09:25:16AM +0100, Ludovic Desroches wrote:
> > Hi Maxime,
> > 
> > On Thu, Feb 22, 2018 at 12:39:55PM +0100, Maxime Jayat wrote:
> > > Despite the efforts made to correctly read the NDA and CUBC registers,
> > > the order in which the registers are read could sometimes lead to an
> > > inconsistent state.
> > > 
> > > Re-using the timeline from the comments, this following timing of
> > > registers reads could lead to reading NDA with value "@desc2" and
> > > CUBC with value "MAX desc1":
> > > 
> > >  INITD 
> > >   ||
> > >___  ___
> > >  NDA   @desc2 \/   @desc3
> > >___/\___
> > >__  ___  ___
> > >  CUBC   0\/ MAX desc1 \/  MAX desc2
> > >__/\___/\___
> > > |  |  |  |
> > > Events:(1)(2)(3)(4)
> > > 
> > > (1) check_nda = @desc2
> > > (2) initd = 1
> > > (3) cur_ubc = MAX desc1
> > > (4) cur_nda = @desc2
> > > 
> > > This is allowed by the condition ((check_nda == cur_nda) && initd),
> > > despite cur_ubc and cur_nda being in the precise state we don't want.
> > > 
> > > This error leads to incorrect residue computation.
> > > 
> > > Fix it by inversing the order in which CUBC and INITD are read. This
> > > makes sure that NDA and CUBC are always read together either _before_
> > > INITD goes to 0 or _after_ it is back at 1.
> > > The case where NDA is read before INITD is at 0 and CUBC is read after
> > > INITD is back at 1 will be rejected by check_nda and cur_nda being
> > > different.
> > > 
> > > Fixes: 53398f488821 ("dmaengine: at_xdmac: fix residue corruption")
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Maxime Jayat <maxime.ja...@mobile-devices.fr>
> > 
> > Nice work! I agree with the change you propose.
> > 
> > I am disappointed we didn't spot this case so I would like to double-check 
> > with
> > the hardware guy there is no issue with the sequence you propose. That's
> > why I am waiting a bit before giving my ack.
> 
> any update on that? This has been pending for a while...

Unfortunately not. As I am pretty confident in Maxime patch:
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com>

> 
> > 
> > Regards
> > 
> > Ludovic
> > 
> > > ---
> > > Hi,
> > > 
> > > I had a bug where the serial ports on the Atmel SAMA5D2 were sometimes
> > > returning the same data twice, for up to 4096 bytes.
> > > 
> > > After investigation, I noticed that the ring buffer used in
> > > atmel_serial (in rx dma mode) had sometimes a incorrect "head" value,
> > > which made the ring buffer do a complete extraneous loop of data
> > > pushed to the tty layer.
> > > 
> > > I tracked it down to the residue of the dma being wrong, and after
> > > more head scratching, I found this bug in the reading of the
> > > registers.
> > > 
> > > Before fixing this, I was able to reproduce the bug reliably in a few
> > > minutes. With this patch applied, the bug did not reappear after
> > > several hours in testing.
> > > 
> > > 
> > >  drivers/dma/at_xdmac.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> > > index c00e3923d7d8..94236ec9d410 100644
> > > --- a/drivers/dma/at_xdmac.c
> > > +++ b/drivers/dma/at_xdmac.c
> > > @@ -1471,10 +1471,10 @@ at_xdmac_tx_status(struct dma_chan *chan, 
> > > dma_cookie_t cookie,
> > >   for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
> > >   check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
> > > 0xfffc;
> > >   rmb();
> > > - initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
> > > AT_XDMAC_CC_INITD);
> > > - rmb();
> > >   cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
> > >   rmb();
> > > + initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
> > > AT_XDMAC_CC_INITD);
> > > + rmb();
> > >   cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
> > > 0xfffc;
> > >   rmb();
> > >  
> > > -- 
> > > 2.14.1
> > > 
> 
> -- 
> ~Vinod

Re: [PATCH] dmaengine: at_xdmac: fix rare residue corruption

[Ludovic Desroches]

On Mon, Mar 19, 2018 at 01:26:09PM +0530, Vinod Koul wrote:
> On Thu, Mar 01, 2018 at 09:25:16AM +0100, Ludovic Desroches wrote:
> > Hi Maxime,
> > 
> > On Thu, Feb 22, 2018 at 12:39:55PM +0100, Maxime Jayat wrote:
> > > Despite the efforts made to correctly read the NDA and CUBC registers,
> > > the order in which the registers are read could sometimes lead to an
> > > inconsistent state.
> > > 
> > > Re-using the timeline from the comments, this following timing of
> > > registers reads could lead to reading NDA with value "@desc2" and
> > > CUBC with value "MAX desc1":
> > > 
> > >  INITD 
> > >   ||
> > >___  ___
> > >  NDA   @desc2 \/   @desc3
> > >___/\___
> > >__  ___  ___
> > >  CUBC   0\/ MAX desc1 \/  MAX desc2
> > >__/\___/\___
> > > |  |  |  |
> > > Events:(1)(2)(3)(4)
> > > 
> > > (1) check_nda = @desc2
> > > (2) initd = 1
> > > (3) cur_ubc = MAX desc1
> > > (4) cur_nda = @desc2
> > > 
> > > This is allowed by the condition ((check_nda == cur_nda) && initd),
> > > despite cur_ubc and cur_nda being in the precise state we don't want.
> > > 
> > > This error leads to incorrect residue computation.
> > > 
> > > Fix it by inversing the order in which CUBC and INITD are read. This
> > > makes sure that NDA and CUBC are always read together either _before_
> > > INITD goes to 0 or _after_ it is back at 1.
> > > The case where NDA is read before INITD is at 0 and CUBC is read after
> > > INITD is back at 1 will be rejected by check_nda and cur_nda being
> > > different.
> > > 
> > > Fixes: 53398f488821 ("dmaengine: at_xdmac: fix residue corruption")
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Maxime Jayat 
> > 
> > Nice work! I agree with the change you propose.
> > 
> > I am disappointed we didn't spot this case so I would like to double-check 
> > with
> > the hardware guy there is no issue with the sequence you propose. That's
> > why I am waiting a bit before giving my ack.
> 
> any update on that? This has been pending for a while...

Unfortunately not. As I am pretty confident in Maxime patch:
Acked-by: Ludovic Desroches 

> 
> > 
> > Regards
> > 
> > Ludovic
> > 
> > > ---
> > > Hi,
> > > 
> > > I had a bug where the serial ports on the Atmel SAMA5D2 were sometimes
> > > returning the same data twice, for up to 4096 bytes.
> > > 
> > > After investigation, I noticed that the ring buffer used in
> > > atmel_serial (in rx dma mode) had sometimes a incorrect "head" value,
> > > which made the ring buffer do a complete extraneous loop of data
> > > pushed to the tty layer.
> > > 
> > > I tracked it down to the residue of the dma being wrong, and after
> > > more head scratching, I found this bug in the reading of the
> > > registers.
> > > 
> > > Before fixing this, I was able to reproduce the bug reliably in a few
> > > minutes. With this patch applied, the bug did not reappear after
> > > several hours in testing.
> > > 
> > > 
> > >  drivers/dma/at_xdmac.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> > > index c00e3923d7d8..94236ec9d410 100644
> > > --- a/drivers/dma/at_xdmac.c
> > > +++ b/drivers/dma/at_xdmac.c
> > > @@ -1471,10 +1471,10 @@ at_xdmac_tx_status(struct dma_chan *chan, 
> > > dma_cookie_t cookie,
> > >   for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
> > >   check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
> > > 0xfffc;
> > >   rmb();
> > > - initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
> > > AT_XDMAC_CC_INITD);
> > > - rmb();
> > >   cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
> > >   rmb();
> > > + initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
> > > AT_XDMAC_CC_INITD);
> > > + rmb();
> > >   cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
> > > 0xfffc;
> > >   rmb();
> > >  
> > > -- 
> > > 2.14.1
> > > 
> 
> -- 
> ~Vinod

Re: [PATCH] dmaengine: at_xdmac: fix rare residue corruption

[Ludovic Desroches]

Hi Maxime,

On Thu, Feb 22, 2018 at 12:39:55PM +0100, Maxime Jayat wrote:
> Despite the efforts made to correctly read the NDA and CUBC registers,
> the order in which the registers are read could sometimes lead to an
> inconsistent state.
> 
> Re-using the timeline from the comments, this following timing of
> registers reads could lead to reading NDA with value "@desc2" and
> CUBC with value "MAX desc1":
> 
>  INITD 
>   ||
>___  ___
>  NDA   @desc2 \/   @desc3
>___/\___
>__  ___  ___
>  CUBC   0\/ MAX desc1 \/  MAX desc2
>__/\___/\___
> |  |  |  |
> Events:(1)(2)(3)(4)
> 
> (1) check_nda = @desc2
> (2) initd = 1
> (3) cur_ubc = MAX desc1
> (4) cur_nda = @desc2
> 
> This is allowed by the condition ((check_nda == cur_nda) && initd),
> despite cur_ubc and cur_nda being in the precise state we don't want.
> 
> This error leads to incorrect residue computation.
> 
> Fix it by inversing the order in which CUBC and INITD are read. This
> makes sure that NDA and CUBC are always read together either _before_
> INITD goes to 0 or _after_ it is back at 1.
> The case where NDA is read before INITD is at 0 and CUBC is read after
> INITD is back at 1 will be rejected by check_nda and cur_nda being
> different.
> 
> Fixes: 53398f488821 ("dmaengine: at_xdmac: fix residue corruption")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Maxime Jayat 

Nice work! I agree with the change you propose.

I am disappointed we didn't spot this case so I would like to double-check with
the hardware guy there is no issue with the sequence you propose. That's
why I am waiting a bit before giving my ack.

Regards

Ludovic

> ---
> Hi,
> 
> I had a bug where the serial ports on the Atmel SAMA5D2 were sometimes
> returning the same data twice, for up to 4096 bytes.
> 
> After investigation, I noticed that the ring buffer used in
> atmel_serial (in rx dma mode) had sometimes a incorrect "head" value,
> which made the ring buffer do a complete extraneous loop of data
> pushed to the tty layer.
> 
> I tracked it down to the residue of the dma being wrong, and after
> more head scratching, I found this bug in the reading of the
> registers.
> 
> Before fixing this, I was able to reproduce the bug reliably in a few
> minutes. With this patch applied, the bug did not reappear after
> several hours in testing.
> 
> 
>  drivers/dma/at_xdmac.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index c00e3923d7d8..94236ec9d410 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -1471,10 +1471,10 @@ at_xdmac_tx_status(struct dma_chan *chan, 
> dma_cookie_t cookie,
>   for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
>   check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
> 0xfffc;
>   rmb();
> - initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
> AT_XDMAC_CC_INITD);
> - rmb();
>   cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
>   rmb();
> + initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
> AT_XDMAC_CC_INITD);
> + rmb();
>   cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
> 0xfffc;
>   rmb();
>  
> -- 
> 2.14.1
> 

Re: [PATCH] dmaengine: at_xdmac: fix rare residue corruption

[Ludovic Desroches]

Hi Maxime,

On Thu, Feb 22, 2018 at 12:39:55PM +0100, Maxime Jayat wrote:
> Despite the efforts made to correctly read the NDA and CUBC registers,
> the order in which the registers are read could sometimes lead to an
> inconsistent state.
> 
> Re-using the timeline from the comments, this following timing of
> registers reads could lead to reading NDA with value "@desc2" and
> CUBC with value "MAX desc1":
> 
>  INITD 
>   ||
>___  ___
>  NDA   @desc2 \/   @desc3
>___/\___
>__  ___  ___
>  CUBC   0\/ MAX desc1 \/  MAX desc2
>__/\___/\___
> |  |  |  |
> Events:(1)(2)(3)(4)
> 
> (1) check_nda = @desc2
> (2) initd = 1
> (3) cur_ubc = MAX desc1
> (4) cur_nda = @desc2
> 
> This is allowed by the condition ((check_nda == cur_nda) && initd),
> despite cur_ubc and cur_nda being in the precise state we don't want.
> 
> This error leads to incorrect residue computation.
> 
> Fix it by inversing the order in which CUBC and INITD are read. This
> makes sure that NDA and CUBC are always read together either _before_
> INITD goes to 0 or _after_ it is back at 1.
> The case where NDA is read before INITD is at 0 and CUBC is read after
> INITD is back at 1 will be rejected by check_nda and cur_nda being
> different.
> 
> Fixes: 53398f488821 ("dmaengine: at_xdmac: fix residue corruption")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Maxime Jayat 

Nice work! I agree with the change you propose.

I am disappointed we didn't spot this case so I would like to double-check with
the hardware guy there is no issue with the sequence you propose. That's
why I am waiting a bit before giving my ack.

Regards

Ludovic

> ---
> Hi,
> 
> I had a bug where the serial ports on the Atmel SAMA5D2 were sometimes
> returning the same data twice, for up to 4096 bytes.
> 
> After investigation, I noticed that the ring buffer used in
> atmel_serial (in rx dma mode) had sometimes a incorrect "head" value,
> which made the ring buffer do a complete extraneous loop of data
> pushed to the tty layer.
> 
> I tracked it down to the residue of the dma being wrong, and after
> more head scratching, I found this bug in the reading of the
> registers.
> 
> Before fixing this, I was able to reproduce the bug reliably in a few
> minutes. With this patch applied, the bug did not reappear after
> several hours in testing.
> 
> 
>  drivers/dma/at_xdmac.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index c00e3923d7d8..94236ec9d410 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -1471,10 +1471,10 @@ at_xdmac_tx_status(struct dma_chan *chan, 
> dma_cookie_t cookie,
>   for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
>   check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
> 0xfffc;
>   rmb();
> - initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
> AT_XDMAC_CC_INITD);
> - rmb();
>   cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
>   rmb();
> + initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
> AT_XDMAC_CC_INITD);
> + rmb();
>   cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
> 0xfffc;
>   rmb();
>  
> -- 
> 2.14.1
> 

Re: [PATCH 2/2] usb: gadget: udc: atmel: convert to use GPIO descriptors

[Ludovic Desroches]

On Wed, Feb 07, 2018 at 02:55:35PM +0100, Linus Walleij wrote:
> On Thu, Feb 1, 2018 at 10:34 AM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> 
> > Use GPIO descriptors instead of relying on the old method.
> > Include irq.h header since it is needed and was indirectly
> > included through of_gpio.h.
> >
> > Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
> 
> Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
> 
> Thank you for doing gpiod conversions. Making the world
> a better place!

Thanks, I wish it would be so easy!

I will send a v2 because I have the same issue that the one pointed by
Andy about the gpiod conversion for the lcd driver.

- udc->vbus_pin = devm_gpiod_get_optional(>dev, "atmel,vbus", GPIOD_IN);
+ udc->vbus_pin = devm_gpiod_get(>dev, "atmel,vbus", GPIOD_IN);
+ if (IS_ERR(udc->vbus_pin))
+   udc->vbus_pin = NULL;

I am not sure if I should prefer devm_gpiod_get_optional or
devm_gpiod_get.

Regards

Ludovic

Re: [PATCH 2/2] usb: gadget: udc: atmel: convert to use GPIO descriptors

[Ludovic Desroches]

On Wed, Feb 07, 2018 at 02:55:35PM +0100, Linus Walleij wrote:
> On Thu, Feb 1, 2018 at 10:34 AM, Ludovic Desroches
>  wrote:
> 
> > Use GPIO descriptors instead of relying on the old method.
> > Include irq.h header since it is needed and was indirectly
> > included through of_gpio.h.
> >
> > Signed-off-by: Ludovic Desroches 
> 
> Reviewed-by: Linus Walleij 
> 
> Thank you for doing gpiod conversions. Making the world
> a better place!

Thanks, I wish it would be so easy!

I will send a v2 because I have the same issue that the one pointed by
Andy about the gpiod conversion for the lcd driver.

- udc->vbus_pin = devm_gpiod_get_optional(>dev, "atmel,vbus", GPIOD_IN);
+ udc->vbus_pin = devm_gpiod_get(>dev, "atmel,vbus", GPIOD_IN);
+ if (IS_ERR(udc->vbus_pin))
+   udc->vbus_pin = NULL;

I am not sure if I should prefer devm_gpiod_get_optional or
devm_gpiod_get.

Regards

Ludovic

Re: [RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

On Mon, Feb 05, 2018 at 12:56:04PM +0100, Linus Walleij wrote:
> On Mon, Feb 5, 2018 at 9:47 AM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> 
> > Use GPIO descriptors instead of relying on the old method.
> >
> > Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
> 
> Ah there it is :D
> Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
> 
> PS: why not move it all over to use DRI/DRM/KMS? It's becoming
> easier and easier.

It concerns old products, that's why it's not converted yet.

Regards

Ludovic

> 
> Yours,
> Linus Walleij

Re: [RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

On Mon, Feb 05, 2018 at 12:56:04PM +0100, Linus Walleij wrote:
> On Mon, Feb 5, 2018 at 9:47 AM, Ludovic Desroches
>  wrote:
> 
> > Use GPIO descriptors instead of relying on the old method.
> >
> > Signed-off-by: Ludovic Desroches 
> 
> Ah there it is :D
> Reviewed-by: Linus Walleij 
> 
> PS: why not move it all over to use DRI/DRM/KMS? It's becoming
> easier and easier.

It concerns old products, that's why it's not converted yet.

Regards

Ludovic

> 
> Yours,
> Linus Walleij

[PATCH V2] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
Acked-by: Nicolas Ferre <nicolas.fe...@microchip.com>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
---
Changes
- V2:
  - remove of_gpio.h.
  - move gpiod declaration to preserve reversed tree style.
  - use devm_gpiod_get_index instead of devm_gpiod_get_index_optional
  since all errors are treated in the same way.

 drivers/video/fbdev/atmel_lcdfb.c | 31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 3dee267d7c75..076d24afbd72 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -18,10 +18,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -61,8 +61,7 @@ struct atmel_lcdfb_info {
 };
 
 struct atmel_lcdfb_power_ctrl_gpio {
-   int gpio;
-   int active_low;
+   struct gpio_desc *gpiod;
 
struct list_head list;
 };
@@ -1018,7 +1017,7 @@ static void atmel_lcdfb_power_control_gpio(struct 
atmel_lcdfb_pdata *pdata, int
struct atmel_lcdfb_power_ctrl_gpio *og;
 
list_for_each_entry(og, >pwr_gpios, list)
-   gpio_set_value(og->gpio, on);
+   gpiod_set_value(og->gpiod, on);
 }
 
 static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
@@ -1031,11 +1030,11 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
struct device_node *display_np;
struct device_node *timings_np;
struct display_timings *timings;
-   enum of_gpio_flags flags;
struct atmel_lcdfb_power_ctrl_gpio *og;
bool is_gpio_power = false;
+   struct gpio_desc *gpiod;
int ret = -ENOENT;
-   int i, gpio;
+   int i;
 
sinfo->config = (struct atmel_lcdfb_config*)
of_match_device(atmel_lcdfb_dt_ids, dev)->data;
@@ -1072,28 +1071,22 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
 
INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
-   for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
-   gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
-  i, );
-   if (gpio < 0)
+   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   gpiod = devm_gpiod_get_index(dev, "atmel,power-control",
+i, GPIOD_ASIS);
+   if (IS_ERR(gpiod))
continue;
 
og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
if (!og)
goto put_display_node;
 
-   og->gpio = gpio;
-   og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+   og->gpiod = gpiod;
is_gpio_power = true;
-   ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
-   if (ret) {
-   dev_err(dev, "request gpio %d failed\n", gpio);
-   goto put_display_node;
-   }
 
-   ret = gpio_direction_output(gpio, og->active_low);
+   ret = gpiod_direction_output(gpiod, gpiod_is_active_low(gpiod));
if (ret) {
-   dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
+   dev_err(dev, "set direction output gpio 
atmel,power-control[%d] failed\n", i);
goto put_display_node;
}
list_add(>list, >pwr_gpios);
-- 
2.12.2

[PATCH V2] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.

Signed-off-by: Ludovic Desroches 
Acked-by: Nicolas Ferre 
Reviewed-by: Linus Walleij 
Reviewed-by: Andy Shevchenko 
---
Changes
- V2:
  - remove of_gpio.h.
  - move gpiod declaration to preserve reversed tree style.
  - use devm_gpiod_get_index instead of devm_gpiod_get_index_optional
  since all errors are treated in the same way.

 drivers/video/fbdev/atmel_lcdfb.c | 31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 3dee267d7c75..076d24afbd72 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -18,10 +18,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -61,8 +61,7 @@ struct atmel_lcdfb_info {
 };
 
 struct atmel_lcdfb_power_ctrl_gpio {
-   int gpio;
-   int active_low;
+   struct gpio_desc *gpiod;
 
struct list_head list;
 };
@@ -1018,7 +1017,7 @@ static void atmel_lcdfb_power_control_gpio(struct 
atmel_lcdfb_pdata *pdata, int
struct atmel_lcdfb_power_ctrl_gpio *og;
 
list_for_each_entry(og, >pwr_gpios, list)
-   gpio_set_value(og->gpio, on);
+   gpiod_set_value(og->gpiod, on);
 }
 
 static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
@@ -1031,11 +1030,11 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
struct device_node *display_np;
struct device_node *timings_np;
struct display_timings *timings;
-   enum of_gpio_flags flags;
struct atmel_lcdfb_power_ctrl_gpio *og;
bool is_gpio_power = false;
+   struct gpio_desc *gpiod;
int ret = -ENOENT;
-   int i, gpio;
+   int i;
 
sinfo->config = (struct atmel_lcdfb_config*)
of_match_device(atmel_lcdfb_dt_ids, dev)->data;
@@ -1072,28 +1071,22 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
 
INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
-   for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
-   gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
-  i, );
-   if (gpio < 0)
+   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   gpiod = devm_gpiod_get_index(dev, "atmel,power-control",
+i, GPIOD_ASIS);
+   if (IS_ERR(gpiod))
continue;
 
og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
if (!og)
goto put_display_node;
 
-   og->gpio = gpio;
-   og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+   og->gpiod = gpiod;
is_gpio_power = true;
-   ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
-   if (ret) {
-   dev_err(dev, "request gpio %d failed\n", gpio);
-   goto put_display_node;
-   }
 
-   ret = gpio_direction_output(gpio, og->active_low);
+   ret = gpiod_direction_output(gpiod, gpiod_is_active_low(gpiod));
if (ret) {
-   dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
+   dev_err(dev, "set direction output gpio 
atmel,power-control[%d] failed\n", i);
goto put_display_node;
}
list_add(>list, >pwr_gpios);
-- 
2.12.2

Re: [RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

On Mon, Feb 05, 2018 at 03:06:33PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 5, 2018 at 10:47 AM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> > Use GPIO descriptors instead of relying on the old method.
> 
> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
> 
> Though few nitpicks below.
> 
> 
> > --- a/drivers/video/fbdev/atmel_lcdfb.c
> > +++ b/drivers/video/fbdev/atmel_lcdfb.c
> > @@ -18,6 +18,7 @@
> >  #include 
> >  #include 
> >  #include 
> 
> > +#include 
> 
> I think you forgot to remove of_gpio.h.

Right. I'll remove it.

> 
> >  #include 
> >  #include 
> >  #include 
> 
> > struct device_node *display_np;
> > struct device_node *timings_np;
> > struct display_timings *timings;
> > -   enum of_gpio_flags flags;
> > struct atmel_lcdfb_power_ctrl_gpio *og;
> > bool is_gpio_power = false;
> > int ret = -ENOENT;
> > -   int i, gpio;
> > +   int i;
> > +   struct gpio_desc *gpiod;
> 
> I would rather preserve reversed tree style, i.e. put longer line upper.

Ok.

> 
> 
> > +   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
> > +   gpiod = devm_gpiod_get_index_optional(dev,
> > +   "atmel,power-control", i, GPIOD_ASIS);
> > +   if (!gpiod)
> > continue;
> 
> What about IS_ERR() case?

if (!gpiod || IS_ERR(gpiod))
continue;

Thanks.

> 
> >
> > og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
> > if (!og)
> > goto put_display_node;
> >
> > +   og->gpiod = gpiod;
> > is_gpio_power = true;
> >
> > +   ret = gpiod_direction_output(gpiod, 
> > gpiod_is_active_low(gpiod));
> > if (ret) {
> 
> I'm not sure this will be needed if you check IS_ERR() above.
> 

When in doubt, I keep it.

Regards

Ludovic

> > +   dev_err(dev, "set direction output gpio 
> > atmel,power-control[%d] failed\n", i);
> > goto put_display_node;
> > }
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

On Mon, Feb 05, 2018 at 03:06:33PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 5, 2018 at 10:47 AM, Ludovic Desroches
>  wrote:
> > Use GPIO descriptors instead of relying on the old method.
> 
> Reviewed-by: Andy Shevchenko 
> 
> Though few nitpicks below.
> 
> 
> > --- a/drivers/video/fbdev/atmel_lcdfb.c
> > +++ b/drivers/video/fbdev/atmel_lcdfb.c
> > @@ -18,6 +18,7 @@
> >  #include 
> >  #include 
> >  #include 
> 
> > +#include 
> 
> I think you forgot to remove of_gpio.h.

Right. I'll remove it.

> 
> >  #include 
> >  #include 
> >  #include 
> 
> > struct device_node *display_np;
> > struct device_node *timings_np;
> > struct display_timings *timings;
> > -   enum of_gpio_flags flags;
> > struct atmel_lcdfb_power_ctrl_gpio *og;
> > bool is_gpio_power = false;
> > int ret = -ENOENT;
> > -   int i, gpio;
> > +   int i;
> > +   struct gpio_desc *gpiod;
> 
> I would rather preserve reversed tree style, i.e. put longer line upper.

Ok.

> 
> 
> > +   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
> > +   gpiod = devm_gpiod_get_index_optional(dev,
> > +   "atmel,power-control", i, GPIOD_ASIS);
> > +   if (!gpiod)
> > continue;
> 
> What about IS_ERR() case?

if (!gpiod || IS_ERR(gpiod))
continue;

Thanks.

> 
> >
> > og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
> > if (!og)
> > goto put_display_node;
> >
> > +   og->gpiod = gpiod;
> > is_gpio_power = true;
> >
> > +   ret = gpiod_direction_output(gpiod, 
> > gpiod_is_active_low(gpiod));
> > if (ret) {
> 
> I'm not sure this will be needed if you check IS_ERR() above.
> 

When in doubt, I keep it.

Regards

Ludovic

> > +   dev_err(dev, "set direction output gpio 
> > atmel,power-control[%d] failed\n", i);
> > goto put_display_node;
> > }
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 drivers/video/fbdev/atmel_lcdfb.c | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 3dee267d7c75..ef3d4198014f 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -61,8 +62,7 @@ struct atmel_lcdfb_info {
 };
 
 struct atmel_lcdfb_power_ctrl_gpio {
-   int gpio;
-   int active_low;
+   struct gpio_desc *gpiod;
 
struct list_head list;
 };
@@ -1018,7 +1018,7 @@ static void atmel_lcdfb_power_control_gpio(struct 
atmel_lcdfb_pdata *pdata, int
struct atmel_lcdfb_power_ctrl_gpio *og;
 
list_for_each_entry(og, >pwr_gpios, list)
-   gpio_set_value(og->gpio, on);
+   gpiod_set_value(og->gpiod, on);
 }
 
 static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
@@ -1031,11 +1031,11 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
struct device_node *display_np;
struct device_node *timings_np;
struct display_timings *timings;
-   enum of_gpio_flags flags;
struct atmel_lcdfb_power_ctrl_gpio *og;
bool is_gpio_power = false;
int ret = -ENOENT;
-   int i, gpio;
+   int i;
+   struct gpio_desc *gpiod;
 
sinfo->config = (struct atmel_lcdfb_config*)
of_match_device(atmel_lcdfb_dt_ids, dev)->data;
@@ -1072,28 +1072,22 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
 
INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
-   for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
-   gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
-  i, );
-   if (gpio < 0)
+   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   gpiod = devm_gpiod_get_index_optional(dev,
+   "atmel,power-control", i, GPIOD_ASIS);
+   if (!gpiod)
continue;
 
og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
if (!og)
goto put_display_node;
 
-   og->gpio = gpio;
-   og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+   og->gpiod = gpiod;
is_gpio_power = true;
-   ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
-   if (ret) {
-   dev_err(dev, "request gpio %d failed\n", gpio);
-   goto put_display_node;
-   }
 
-   ret = gpio_direction_output(gpio, og->active_low);
+   ret = gpiod_direction_output(gpiod, gpiod_is_active_low(gpiod));
if (ret) {
-   dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
+   dev_err(dev, "set direction output gpio 
atmel,power-control[%d] failed\n", i);
goto put_display_node;
}
list_add(>list, >pwr_gpios);
-- 
2.12.2

[RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.

Signed-off-by: Ludovic Desroches 
---
 drivers/video/fbdev/atmel_lcdfb.c | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 3dee267d7c75..ef3d4198014f 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -61,8 +62,7 @@ struct atmel_lcdfb_info {
 };
 
 struct atmel_lcdfb_power_ctrl_gpio {
-   int gpio;
-   int active_low;
+   struct gpio_desc *gpiod;
 
struct list_head list;
 };
@@ -1018,7 +1018,7 @@ static void atmel_lcdfb_power_control_gpio(struct 
atmel_lcdfb_pdata *pdata, int
struct atmel_lcdfb_power_ctrl_gpio *og;
 
list_for_each_entry(og, >pwr_gpios, list)
-   gpio_set_value(og->gpio, on);
+   gpiod_set_value(og->gpiod, on);
 }
 
 static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
@@ -1031,11 +1031,11 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
struct device_node *display_np;
struct device_node *timings_np;
struct display_timings *timings;
-   enum of_gpio_flags flags;
struct atmel_lcdfb_power_ctrl_gpio *og;
bool is_gpio_power = false;
int ret = -ENOENT;
-   int i, gpio;
+   int i;
+   struct gpio_desc *gpiod;
 
sinfo->config = (struct atmel_lcdfb_config*)
of_match_device(atmel_lcdfb_dt_ids, dev)->data;
@@ -1072,28 +1072,22 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
 
INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
-   for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
-   gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
-  i, );
-   if (gpio < 0)
+   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   gpiod = devm_gpiod_get_index_optional(dev,
+   "atmel,power-control", i, GPIOD_ASIS);
+   if (!gpiod)
continue;
 
og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
if (!og)
goto put_display_node;
 
-   og->gpio = gpio;
-   og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+   og->gpiod = gpiod;
is_gpio_power = true;
-   ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
-   if (ret) {
-   dev_err(dev, "request gpio %d failed\n", gpio);
-   goto put_display_node;
-   }
 
-   ret = gpio_direction_output(gpio, og->active_low);
+   ret = gpiod_direction_output(gpiod, gpiod_is_active_low(gpiod));
if (ret) {
-   dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
+   dev_err(dev, "set direction output gpio 
atmel,power-control[%d] failed\n", i);
goto put_display_node;
}
list_add(>list, >pwr_gpios);
-- 
2.12.2

[PATCH] video: fbdev: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 drivers/video/fbdev/atmel_lcdfb.c | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 3dee267d7c75..ef3d4198014f 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -61,8 +62,7 @@ struct atmel_lcdfb_info {
 };
 
 struct atmel_lcdfb_power_ctrl_gpio {
-   int gpio;
-   int active_low;
+   struct gpio_desc *gpiod;
 
struct list_head list;
 };
@@ -1018,7 +1018,7 @@ static void atmel_lcdfb_power_control_gpio(struct 
atmel_lcdfb_pdata *pdata, int
struct atmel_lcdfb_power_ctrl_gpio *og;
 
list_for_each_entry(og, >pwr_gpios, list)
-   gpio_set_value(og->gpio, on);
+   gpiod_set_value(og->gpiod, on);
 }
 
 static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
@@ -1031,11 +1031,11 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
struct device_node *display_np;
struct device_node *timings_np;
struct display_timings *timings;
-   enum of_gpio_flags flags;
struct atmel_lcdfb_power_ctrl_gpio *og;
bool is_gpio_power = false;
int ret = -ENOENT;
-   int i, gpio;
+   int i;
+   struct gpio_desc *gpiod;
 
sinfo->config = (struct atmel_lcdfb_config*)
of_match_device(atmel_lcdfb_dt_ids, dev)->data;
@@ -1072,28 +1072,22 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
 
INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
-   for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
-   gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
-  i, );
-   if (gpio < 0)
+   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   gpiod = devm_gpiod_get_index_optional(dev,
+   "atmel,power-control", i, GPIOD_ASIS);
+   if (!gpiod)
continue;
 
og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
if (!og)
goto put_display_node;
 
-   og->gpio = gpio;
-   og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+   og->gpiod = gpiod;
is_gpio_power = true;
-   ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
-   if (ret) {
-   dev_err(dev, "request gpio %d failed\n", gpio);
-   goto put_display_node;
-   }
 
-   ret = gpio_direction_output(gpio, og->active_low);
+   ret = gpiod_direction_output(gpiod, gpiod_is_active_low(gpiod));
if (ret) {
-   dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
+   dev_err(dev, "set direction output gpio 
atmel,power-control[%d] failed\n", i);
goto put_display_node;
}
list_add(>list, >pwr_gpios);
-- 
2.12.2

[PATCH] video: fbdev: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.

Signed-off-by: Ludovic Desroches 
---
 drivers/video/fbdev/atmel_lcdfb.c | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 3dee267d7c75..ef3d4198014f 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -61,8 +62,7 @@ struct atmel_lcdfb_info {
 };
 
 struct atmel_lcdfb_power_ctrl_gpio {
-   int gpio;
-   int active_low;
+   struct gpio_desc *gpiod;
 
struct list_head list;
 };
@@ -1018,7 +1018,7 @@ static void atmel_lcdfb_power_control_gpio(struct 
atmel_lcdfb_pdata *pdata, int
struct atmel_lcdfb_power_ctrl_gpio *og;
 
list_for_each_entry(og, >pwr_gpios, list)
-   gpio_set_value(og->gpio, on);
+   gpiod_set_value(og->gpiod, on);
 }
 
 static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
@@ -1031,11 +1031,11 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
struct device_node *display_np;
struct device_node *timings_np;
struct display_timings *timings;
-   enum of_gpio_flags flags;
struct atmel_lcdfb_power_ctrl_gpio *og;
bool is_gpio_power = false;
int ret = -ENOENT;
-   int i, gpio;
+   int i;
+   struct gpio_desc *gpiod;
 
sinfo->config = (struct atmel_lcdfb_config*)
of_match_device(atmel_lcdfb_dt_ids, dev)->data;
@@ -1072,28 +1072,22 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
 
INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
-   for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
-   gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
-  i, );
-   if (gpio < 0)
+   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   gpiod = devm_gpiod_get_index_optional(dev,
+   "atmel,power-control", i, GPIOD_ASIS);
+   if (!gpiod)
continue;
 
og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
if (!og)
goto put_display_node;
 
-   og->gpio = gpio;
-   og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+   og->gpiod = gpiod;
is_gpio_power = true;
-   ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
-   if (ret) {
-   dev_err(dev, "request gpio %d failed\n", gpio);
-   goto put_display_node;
-   }
 
-   ret = gpio_direction_output(gpio, og->active_low);
+   ret = gpiod_direction_output(gpiod, gpiod_is_active_low(gpiod));
if (ret) {
-   dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
+   dev_err(dev, "set direction output gpio 
atmel,power-control[%d] failed\n", i);
goto put_display_node;
}
list_add(>list, >pwr_gpios);
-- 
2.12.2

Re: [PATCH] pinctrl: at91-pio4: add support for drive-strength property

[Ludovic Desroches]

On Mon, Jan 29, 2018 at 01:01:30PM -0600, Rob Herring wrote:
> On Mon, Jan 22, 2018 at 09:37:38AM +0100, Linus Walleij wrote:
> > On Thu, Jan 18, 2018 at 5:02 PM, Ludovic Desroches
> > <ludovic.desroc...@microchip.com> wrote:
> > 
> > > Add support for the drive-strength property. Usually its value is
> > > expressed in mA. Since the numeric value depends on VDDIOP voltage,
> > > the controller uses low, medium and high to define the drive-strengh.
> > 
> > Aha I see. That's complex. It certainly results in a certain mA drive
> > strength in the end, but what you're saying is that this is not usually
> > what we configure.
> > 
> > > The PIO controller accepts two values for the low drive: 0 or 1. Most
> > > of the time, we don't care about the drive strength, there is no need
> > > to change it, so 0 is considered as the default value.
> > 
> > Do you mean default value as in "whatever the hardware was set
> > up as at boot time"?
> > 
> > > The low-drive
> > > value won't be advertised through pinconf-pins file excepted if it
> > 
> > except?
> > 
> > > has been set explicitly in the device tree ie if its value is
> > > different from 0.
> > >
> > > Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
> > 
> > OK I think I get it.
> > 
> > >  Optional properties:
> > >  - GENERIC_PINCONFIG: generic pinconfig options to use, bias-disable,
> > > -bias-pull-down, bias-pull-up, drive-open-drain, input-schmitt-enable,
> > > -input-debounce, output-low, output-high.
> > > +bias-pull-down, bias-pull-up, drive-open-drain, drive-strength,
> > > +input-schmitt-enable, input-debounce, output-low, output-high.
> > (...)
> > > +   drive-strength = ;
> > 
> > So you say you support this argument and it will be something like
> > 
> > include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_LO  1
> > include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_ME  2
> > include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_HI  3
> > 
> > But the definition if generic drive strength is actually in mA.
> 
> Yes, and the reason we put unit suffixes on properties is to avoid 
> differing units.
>  
> > I think it is OK to deviate from stating it in mA, but you should
> > write this in the DT bindings so people do not get confused.
> 
> I don't think it is okay. If "drive-strength" doesn't work, then use 
> a vendor specific property ("atmel,drive-strength"). Of course, I might 
> forget this in the next version and tell you to use a standard property 
> in mA. 

Ok, so I am going to send the next version! The purpose is to keep using the
generic pinconf parsing function.
If I need to use "atmel,drive-strength" property, I assume I could
manage it with custom_params, isn't it?

Regards

Ludovic

Re: [PATCH] pinctrl: at91-pio4: add support for drive-strength property

[Ludovic Desroches]

On Mon, Jan 29, 2018 at 01:01:30PM -0600, Rob Herring wrote:
> On Mon, Jan 22, 2018 at 09:37:38AM +0100, Linus Walleij wrote:
> > On Thu, Jan 18, 2018 at 5:02 PM, Ludovic Desroches
> >  wrote:
> > 
> > > Add support for the drive-strength property. Usually its value is
> > > expressed in mA. Since the numeric value depends on VDDIOP voltage,
> > > the controller uses low, medium and high to define the drive-strengh.
> > 
> > Aha I see. That's complex. It certainly results in a certain mA drive
> > strength in the end, but what you're saying is that this is not usually
> > what we configure.
> > 
> > > The PIO controller accepts two values for the low drive: 0 or 1. Most
> > > of the time, we don't care about the drive strength, there is no need
> > > to change it, so 0 is considered as the default value.
> > 
> > Do you mean default value as in "whatever the hardware was set
> > up as at boot time"?
> > 
> > > The low-drive
> > > value won't be advertised through pinconf-pins file excepted if it
> > 
> > except?
> > 
> > > has been set explicitly in the device tree ie if its value is
> > > different from 0.
> > >
> > > Signed-off-by: Ludovic Desroches 
> > 
> > OK I think I get it.
> > 
> > >  Optional properties:
> > >  - GENERIC_PINCONFIG: generic pinconfig options to use, bias-disable,
> > > -bias-pull-down, bias-pull-up, drive-open-drain, input-schmitt-enable,
> > > -input-debounce, output-low, output-high.
> > > +bias-pull-down, bias-pull-up, drive-open-drain, drive-strength,
> > > +input-schmitt-enable, input-debounce, output-low, output-high.
> > (...)
> > > +   drive-strength = ;
> > 
> > So you say you support this argument and it will be something like
> > 
> > include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_LO  1
> > include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_ME  2
> > include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_HI  3
> > 
> > But the definition if generic drive strength is actually in mA.
> 
> Yes, and the reason we put unit suffixes on properties is to avoid 
> differing units.
>  
> > I think it is OK to deviate from stating it in mA, but you should
> > write this in the DT bindings so people do not get confused.
> 
> I don't think it is okay. If "drive-strength" doesn't work, then use 
> a vendor specific property ("atmel,drive-strength"). Of course, I might 
> forget this in the next version and tell you to use a standard property 
> in mA. 

Ok, so I am going to send the next version! The purpose is to keep using the
generic pinconf parsing function.
If I need to use "atmel,drive-strength" property, I assume I could
manage it with custom_params, isn't it?

Regards

Ludovic

[PATCH 2/2] usb: gadget: udc: atmel: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.
Include irq.h header since it is needed and was indirectly
included through of_gpio.h.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 51 ++---
 drivers/usb/gadget/udc/atmel_usba_udc.h |  4 ++-
 2 files changed, 25 insertions(+), 30 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index dc2604ec38f8..ddd49281b427 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -23,7 +23,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #include "atmel_usba_udc.h"
 #define USBA_VBUS_IRQFLAGS (IRQF_ONESHOT \
@@ -415,8 +416,8 @@ static inline void usba_int_enb_set(struct usba_udc *udc, 
u32 val)
 
 static int vbus_is_present(struct usba_udc *udc)
 {
-   if (gpio_is_valid(udc->vbus_pin))
-   return gpio_get_value(udc->vbus_pin) ^ udc->vbus_pin_inverted;
+   if (udc->vbus_pin)
+   return gpiod_get_value(udc->vbus_pin) ^ udc->vbus_pin_inverted;
 
/* No Vbus detection: Assume always present */
return 1;
@@ -1975,8 +1976,8 @@ static int atmel_usba_start(struct usb_gadget *gadget,
 
mutex_lock(>vbus_mutex);
 
-   if (gpio_is_valid(udc->vbus_pin))
-   enable_irq(gpio_to_irq(udc->vbus_pin));
+   if (udc->vbus_pin)
+   enable_irq(gpiod_to_irq(udc->vbus_pin));
 
/* If Vbus is present, enable the controller and wait for reset */
udc->vbus_prev = vbus_is_present(udc);
@@ -1990,8 +1991,8 @@ static int atmel_usba_start(struct usb_gadget *gadget,
return 0;
 
 err:
-   if (gpio_is_valid(udc->vbus_pin))
-   disable_irq(gpio_to_irq(udc->vbus_pin));
+   if (udc->vbus_pin)
+   disable_irq(gpiod_to_irq(udc->vbus_pin));
 
mutex_unlock(>vbus_mutex);
 
@@ -2006,8 +2007,8 @@ static int atmel_usba_stop(struct usb_gadget *gadget)
 {
struct usba_udc *udc = container_of(gadget, struct usba_udc, gadget);
 
-   if (gpio_is_valid(udc->vbus_pin))
-   disable_irq(gpio_to_irq(udc->vbus_pin));
+   if (udc->vbus_pin)
+   disable_irq(gpiod_to_irq(udc->vbus_pin));
 
if (fifo_mode == 0)
udc->configured_ep = 1;
@@ -2054,7 +2055,6 @@ static struct usba_ep * atmel_udc_of_init(struct 
platform_device *pdev,
 {
u32 val;
const char *name;
-   enum of_gpio_flags flags;
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *match;
struct device_node *pp;
@@ -2074,9 +2074,9 @@ static struct usba_ep * atmel_udc_of_init(struct 
platform_device *pdev,
 
udc->num_ep = 0;
 
-   udc->vbus_pin = of_get_named_gpio_flags(np, "atmel,vbus-gpio", 0,
-   );
-   udc->vbus_pin_inverted = (flags & OF_GPIO_ACTIVE_LOW) ? 1 : 0;
+   udc->vbus_pin = devm_gpiod_get_optional(>dev, "atmel,vbus",
+   GPIOD_IN);
+   udc->vbus_pin_inverted = gpiod_is_active_low(udc->vbus_pin);
 
if (fifo_mode == 0) {
pp = NULL;
@@ -2239,7 +2239,6 @@ static int usba_udc_probe(struct platform_device *pdev)
udc->pdev = pdev;
udc->pclk = pclk;
udc->hclk = hclk;
-   udc->vbus_pin = -ENODEV;
 
ret = -ENOMEM;
udc->regs = devm_ioremap(>dev, regs->start, resource_size(regs));
@@ -2285,24 +2284,18 @@ static int usba_udc_probe(struct platform_device *pdev)
}
udc->irq = irq;
 
-   if (gpio_is_valid(udc->vbus_pin)) {
-   if (!devm_gpio_request(>dev, udc->vbus_pin, 
"atmel_usba_udc")) {
-   irq_set_status_flags(gpio_to_irq(udc->vbus_pin),
-   IRQ_NOAUTOEN);
-   ret = devm_request_threaded_irq(>dev,
-   gpio_to_irq(udc->vbus_pin), NULL,
+   if (udc->vbus_pin) {
+   irq_set_status_flags(gpiod_to_irq(udc->vbus_pin), IRQ_NOAUTOEN);
+   ret = devm_request_threaded_irq(>dev,
+   gpiod_to_irq(udc->vbus_pin), NULL,
usba_vbus_irq_thread, 
USBA_VBUS_IRQFLAGS,
"atmel_usba_udc", udc);
if (ret) {
-   udc->vbus_pin = -ENODEV;
+   udc->vbus_pin = NULL;
dev_warn(>pdev->dev,
 "failed to request vbus irq; "
   

[PATCH 2/2] usb: gadget: udc: atmel: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.
Include irq.h header since it is needed and was indirectly
included through of_gpio.h.

Signed-off-by: Ludovic Desroches 
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 51 ++---
 drivers/usb/gadget/udc/atmel_usba_udc.h |  4 ++-
 2 files changed, 25 insertions(+), 30 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index dc2604ec38f8..ddd49281b427 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -23,7 +23,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #include "atmel_usba_udc.h"
 #define USBA_VBUS_IRQFLAGS (IRQF_ONESHOT \
@@ -415,8 +416,8 @@ static inline void usba_int_enb_set(struct usba_udc *udc, 
u32 val)
 
 static int vbus_is_present(struct usba_udc *udc)
 {
-   if (gpio_is_valid(udc->vbus_pin))
-   return gpio_get_value(udc->vbus_pin) ^ udc->vbus_pin_inverted;
+   if (udc->vbus_pin)
+   return gpiod_get_value(udc->vbus_pin) ^ udc->vbus_pin_inverted;
 
/* No Vbus detection: Assume always present */
return 1;
@@ -1975,8 +1976,8 @@ static int atmel_usba_start(struct usb_gadget *gadget,
 
mutex_lock(>vbus_mutex);
 
-   if (gpio_is_valid(udc->vbus_pin))
-   enable_irq(gpio_to_irq(udc->vbus_pin));
+   if (udc->vbus_pin)
+   enable_irq(gpiod_to_irq(udc->vbus_pin));
 
/* If Vbus is present, enable the controller and wait for reset */
udc->vbus_prev = vbus_is_present(udc);
@@ -1990,8 +1991,8 @@ static int atmel_usba_start(struct usb_gadget *gadget,
return 0;
 
 err:
-   if (gpio_is_valid(udc->vbus_pin))
-   disable_irq(gpio_to_irq(udc->vbus_pin));
+   if (udc->vbus_pin)
+   disable_irq(gpiod_to_irq(udc->vbus_pin));
 
mutex_unlock(>vbus_mutex);
 
@@ -2006,8 +2007,8 @@ static int atmel_usba_stop(struct usb_gadget *gadget)
 {
struct usba_udc *udc = container_of(gadget, struct usba_udc, gadget);
 
-   if (gpio_is_valid(udc->vbus_pin))
-   disable_irq(gpio_to_irq(udc->vbus_pin));
+   if (udc->vbus_pin)
+   disable_irq(gpiod_to_irq(udc->vbus_pin));
 
if (fifo_mode == 0)
udc->configured_ep = 1;
@@ -2054,7 +2055,6 @@ static struct usba_ep * atmel_udc_of_init(struct 
platform_device *pdev,
 {
u32 val;
const char *name;
-   enum of_gpio_flags flags;
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *match;
struct device_node *pp;
@@ -2074,9 +2074,9 @@ static struct usba_ep * atmel_udc_of_init(struct 
platform_device *pdev,
 
udc->num_ep = 0;
 
-   udc->vbus_pin = of_get_named_gpio_flags(np, "atmel,vbus-gpio", 0,
-   );
-   udc->vbus_pin_inverted = (flags & OF_GPIO_ACTIVE_LOW) ? 1 : 0;
+   udc->vbus_pin = devm_gpiod_get_optional(>dev, "atmel,vbus",
+   GPIOD_IN);
+   udc->vbus_pin_inverted = gpiod_is_active_low(udc->vbus_pin);
 
if (fifo_mode == 0) {
pp = NULL;
@@ -2239,7 +2239,6 @@ static int usba_udc_probe(struct platform_device *pdev)
udc->pdev = pdev;
udc->pclk = pclk;
udc->hclk = hclk;
-   udc->vbus_pin = -ENODEV;
 
ret = -ENOMEM;
udc->regs = devm_ioremap(>dev, regs->start, resource_size(regs));
@@ -2285,24 +2284,18 @@ static int usba_udc_probe(struct platform_device *pdev)
}
udc->irq = irq;
 
-   if (gpio_is_valid(udc->vbus_pin)) {
-   if (!devm_gpio_request(>dev, udc->vbus_pin, 
"atmel_usba_udc")) {
-   irq_set_status_flags(gpio_to_irq(udc->vbus_pin),
-   IRQ_NOAUTOEN);
-   ret = devm_request_threaded_irq(>dev,
-   gpio_to_irq(udc->vbus_pin), NULL,
+   if (udc->vbus_pin) {
+   irq_set_status_flags(gpiod_to_irq(udc->vbus_pin), IRQ_NOAUTOEN);
+   ret = devm_request_threaded_irq(>dev,
+   gpiod_to_irq(udc->vbus_pin), NULL,
usba_vbus_irq_thread, 
USBA_VBUS_IRQFLAGS,
"atmel_usba_udc", udc);
if (ret) {
-   udc->vbus_pin = -ENODEV;
+   udc->vbus_pin = NULL;
dev_warn(>pdev->dev,
 "failed to request vbus irq; "
 "assuming always on\n");
 

[PATCH 1/2] usb: gadget: udc: atmel: remove code related to platform stuff

[Ludovic Desroches]

With the removal of AVR platforms, code related to platform stuff
is useless.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 73 +
 1 file changed, 2 insertions(+), 71 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 075eaaa8a408..dc2604ec38f8 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -2019,7 +2019,6 @@ static int atmel_usba_stop(struct usb_gadget *gadget)
return 0;
 }
 
-#ifdef CONFIG_OF
 static void at91sam9rl_toggle_bias(struct usba_udc *udc, int is_on)
 {
regmap_update_bits(udc->pmc, AT91_CKGR_UCKR, AT91_PMC_BIASEN,
@@ -2204,71 +2203,6 @@ static struct usba_ep * atmel_udc_of_init(struct 
platform_device *pdev,
 err:
return ERR_PTR(ret);
 }
-#else
-static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
-   struct usba_udc *udc)
-{
-   return ERR_PTR(-ENOSYS);
-}
-#endif
-
-static struct usba_ep * usba_udc_pdata(struct platform_device *pdev,
-struct usba_udc *udc)
-{
-   struct usba_platform_data *pdata = dev_get_platdata(>dev);
-   struct usba_ep *eps;
-   int i;
-
-   if (!pdata)
-   return ERR_PTR(-ENXIO);
-
-   eps = devm_kzalloc(>dev, sizeof(struct usba_ep) * pdata->num_ep,
-  GFP_KERNEL);
-   if (!eps)
-   return ERR_PTR(-ENOMEM);
-
-   udc->gadget.ep0 = [0].ep;
-
-   udc->vbus_pin = pdata->vbus_pin;
-   udc->vbus_pin_inverted = pdata->vbus_pin_inverted;
-   udc->num_ep = pdata->num_ep;
-
-   INIT_LIST_HEAD([0].ep.ep_list);
-
-   for (i = 0; i < pdata->num_ep; i++) {
-   struct usba_ep *ep = [i];
-
-   ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
-   ep->dma_regs = udc->regs + USBA_DMA_BASE(i);
-   ep->fifo = udc->fifo + USBA_FIFO_BASE(i);
-   ep->ep.ops = _ep_ops;
-   ep->ep.name = pdata->ep[i].name;
-   ep->fifo_size = pdata->ep[i].fifo_size;
-   usb_ep_set_maxpacket_limit(>ep, ep->fifo_size);
-   ep->udc = udc;
-   INIT_LIST_HEAD(>queue);
-   ep->nr_banks = pdata->ep[i].nr_banks;
-   ep->index = pdata->ep[i].index;
-   ep->can_dma = pdata->ep[i].can_dma;
-   ep->can_isoc = pdata->ep[i].can_isoc;
-
-   if (i == 0) {
-   ep->ep.caps.type_control = true;
-   } else {
-   ep->ep.caps.type_iso = ep->can_isoc;
-   ep->ep.caps.type_bulk = true;
-   ep->ep.caps.type_int = true;
-   }
-
-   ep->ep.caps.dir_in = true;
-   ep->ep.caps.dir_out = true;
-
-   if (i)
-   list_add_tail(>ep.ep_list, >gadget.ep_list);
-   }
-
-   return eps;
-}
 
 static int usba_udc_probe(struct platform_device *pdev)
 {
@@ -2335,10 +2269,7 @@ static int usba_udc_probe(struct platform_device *pdev)
usba_writel(udc, CTRL, USBA_DISABLE_MASK);
clk_disable_unprepare(pclk);
 
-   if (pdev->dev.of_node)
-   udc->usba_ep = atmel_udc_of_init(pdev, udc);
-   else
-   udc->usba_ep = usba_udc_pdata(pdev, udc);
+   udc->usba_ep = atmel_udc_of_init(pdev, udc);
 
toggle_bias(udc, 0);
 
@@ -2462,7 +2393,7 @@ static struct platform_driver udc_driver = {
.driver = {
.name   = "atmel_usba_udc",
.pm = _udc_pm_ops,
-   .of_match_table = of_match_ptr(atmel_udc_dt_ids),
+   .of_match_table = atmel_udc_dt_ids,
},
 };
 
-- 
2.12.2

[PATCH 1/2] usb: gadget: udc: atmel: remove code related to platform stuff

[Ludovic Desroches]

With the removal of AVR platforms, code related to platform stuff
is useless.

Signed-off-by: Ludovic Desroches 
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 73 +
 1 file changed, 2 insertions(+), 71 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 075eaaa8a408..dc2604ec38f8 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -2019,7 +2019,6 @@ static int atmel_usba_stop(struct usb_gadget *gadget)
return 0;
 }
 
-#ifdef CONFIG_OF
 static void at91sam9rl_toggle_bias(struct usba_udc *udc, int is_on)
 {
regmap_update_bits(udc->pmc, AT91_CKGR_UCKR, AT91_PMC_BIASEN,
@@ -2204,71 +2203,6 @@ static struct usba_ep * atmel_udc_of_init(struct 
platform_device *pdev,
 err:
return ERR_PTR(ret);
 }
-#else
-static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
-   struct usba_udc *udc)
-{
-   return ERR_PTR(-ENOSYS);
-}
-#endif
-
-static struct usba_ep * usba_udc_pdata(struct platform_device *pdev,
-struct usba_udc *udc)
-{
-   struct usba_platform_data *pdata = dev_get_platdata(>dev);
-   struct usba_ep *eps;
-   int i;
-
-   if (!pdata)
-   return ERR_PTR(-ENXIO);
-
-   eps = devm_kzalloc(>dev, sizeof(struct usba_ep) * pdata->num_ep,
-  GFP_KERNEL);
-   if (!eps)
-   return ERR_PTR(-ENOMEM);
-
-   udc->gadget.ep0 = [0].ep;
-
-   udc->vbus_pin = pdata->vbus_pin;
-   udc->vbus_pin_inverted = pdata->vbus_pin_inverted;
-   udc->num_ep = pdata->num_ep;
-
-   INIT_LIST_HEAD([0].ep.ep_list);
-
-   for (i = 0; i < pdata->num_ep; i++) {
-   struct usba_ep *ep = [i];
-
-   ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
-   ep->dma_regs = udc->regs + USBA_DMA_BASE(i);
-   ep->fifo = udc->fifo + USBA_FIFO_BASE(i);
-   ep->ep.ops = _ep_ops;
-   ep->ep.name = pdata->ep[i].name;
-   ep->fifo_size = pdata->ep[i].fifo_size;
-   usb_ep_set_maxpacket_limit(>ep, ep->fifo_size);
-   ep->udc = udc;
-   INIT_LIST_HEAD(>queue);
-   ep->nr_banks = pdata->ep[i].nr_banks;
-   ep->index = pdata->ep[i].index;
-   ep->can_dma = pdata->ep[i].can_dma;
-   ep->can_isoc = pdata->ep[i].can_isoc;
-
-   if (i == 0) {
-   ep->ep.caps.type_control = true;
-   } else {
-   ep->ep.caps.type_iso = ep->can_isoc;
-   ep->ep.caps.type_bulk = true;
-   ep->ep.caps.type_int = true;
-   }
-
-   ep->ep.caps.dir_in = true;
-   ep->ep.caps.dir_out = true;
-
-   if (i)
-   list_add_tail(>ep.ep_list, >gadget.ep_list);
-   }
-
-   return eps;
-}
 
 static int usba_udc_probe(struct platform_device *pdev)
 {
@@ -2335,10 +2269,7 @@ static int usba_udc_probe(struct platform_device *pdev)
usba_writel(udc, CTRL, USBA_DISABLE_MASK);
clk_disable_unprepare(pclk);
 
-   if (pdev->dev.of_node)
-   udc->usba_ep = atmel_udc_of_init(pdev, udc);
-   else
-   udc->usba_ep = usba_udc_pdata(pdev, udc);
+   udc->usba_ep = atmel_udc_of_init(pdev, udc);
 
toggle_bias(udc, 0);
 
@@ -2462,7 +2393,7 @@ static struct platform_driver udc_driver = {
.driver = {
.name   = "atmel_usba_udc",
.pm = _udc_pm_ops,
-   .of_match_table = of_match_ptr(atmel_udc_dt_ids),
+   .of_match_table = atmel_udc_dt_ids,
},
 };
 
-- 
2.12.2

Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

On Fri, Jan 26, 2018 at 07:13:32PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 26, 2018 at 9:32 AM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> > On Wed, Jan 24, 2018 at 05:42:15PM +0200, Andy Shevchenko wrote:
> >> On Wed, Jan 24, 2018 at 3:07 PM, Ludovic Desroches
> >> <ludovic.desroc...@microchip.com> wrote:
> >> > On Thu, Jan 18, 2018 at 04:22:28PM +0100, Ludovic Desroches wrote:
> >> >> On Thu, Jan 18, 2018 at 11:30:00AM +0100, Linus Walleij wrote:
> 
> >> >> > Can't we just look up the associated gpio_chip from the GPIO range,
> >> >> > and in case the pin is connected between the pin controller and
> >> >> > the GPIO chip, then we allow the gpiochip to also take a
> >> >> > reference?
> >>
> >> How do you find my proposal about introducing ownership level (not
> >> requested yet; exclusive; shared)?
> 
> > Yes but I don't see how I can fix my issue with these levels. In my
> > case, I need an exclusive ownership at device level not at pin level. In
> > reality, it is at pin level but I am in this situation because my pin
> > controler was introduced as non strict and also because I need to set
> > the configuration of the pin which is going to be used as a GPIO.
> >
> > If the ownership is exclusive, pinmuxing coming from pinctrl-default
> > will be accepted but the GPIO request will fail even if it comes from the
> > same device.
> 
> The problem here is to declare a right consumer of the resource.
> 
> My understanding that consumer at the end is device or device(s):
> 
> none: resource is free to acquire
> exclusive: certain device has access to the resource (pin)
> shared: several devices may access to the resource
> 
> In both cases couple of caveats:
> - power management has a special access level to the resource on
> behalf of the owner(s)
> - it can have some flags, like 'locked', which means no more owners
> can be changed / added, but still possible to free resource by all
> owners to go to state 'none'
> 
> > If the ownership is shared then, pinmuxing coming from pinctrl-default
> > will be accepted but a GPIO request from another device will be accepted
> > too.
> >
> > Both situations are incorrect in my case.
> 
> Yes, since the ownership design is based on subsystem rather consumer device.
> 
> > Let me know if I have not well understood your proposal. My concern is
> > to get out of this situation without breaking current DTs.
> 
> See above, hope it clarifies a bit.

Yes I get it but I still don't see how I can use your approach to solve
my issue. We have a situation for several pin controllers. If I can't
know who is requesting the GPIO, I have no idea about how to solve this
issue. Bypassing the strict mode, as suggested, if the pin controller is also
a gpio controller may lead, IMO, to wrong behaviors. 

Do I have to try to find a way to fix this situation? Maybe, it will be
easier to progress on the muxing and configuration topic and to
introduce a DT property to enable the strict mode or wathever modes you
want once everything is ready and DTs fixed.

I'd prefer to fix the current situation then to improve muxing and
configuration stuff because it will take time.

Regards

Ludovic

Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

On Fri, Jan 26, 2018 at 07:13:32PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 26, 2018 at 9:32 AM, Ludovic Desroches
>  wrote:
> > On Wed, Jan 24, 2018 at 05:42:15PM +0200, Andy Shevchenko wrote:
> >> On Wed, Jan 24, 2018 at 3:07 PM, Ludovic Desroches
> >>  wrote:
> >> > On Thu, Jan 18, 2018 at 04:22:28PM +0100, Ludovic Desroches wrote:
> >> >> On Thu, Jan 18, 2018 at 11:30:00AM +0100, Linus Walleij wrote:
> 
> >> >> > Can't we just look up the associated gpio_chip from the GPIO range,
> >> >> > and in case the pin is connected between the pin controller and
> >> >> > the GPIO chip, then we allow the gpiochip to also take a
> >> >> > reference?
> >>
> >> How do you find my proposal about introducing ownership level (not
> >> requested yet; exclusive; shared)?
> 
> > Yes but I don't see how I can fix my issue with these levels. In my
> > case, I need an exclusive ownership at device level not at pin level. In
> > reality, it is at pin level but I am in this situation because my pin
> > controler was introduced as non strict and also because I need to set
> > the configuration of the pin which is going to be used as a GPIO.
> >
> > If the ownership is exclusive, pinmuxing coming from pinctrl-default
> > will be accepted but the GPIO request will fail even if it comes from the
> > same device.
> 
> The problem here is to declare a right consumer of the resource.
> 
> My understanding that consumer at the end is device or device(s):
> 
> none: resource is free to acquire
> exclusive: certain device has access to the resource (pin)
> shared: several devices may access to the resource
> 
> In both cases couple of caveats:
> - power management has a special access level to the resource on
> behalf of the owner(s)
> - it can have some flags, like 'locked', which means no more owners
> can be changed / added, but still possible to free resource by all
> owners to go to state 'none'
> 
> > If the ownership is shared then, pinmuxing coming from pinctrl-default
> > will be accepted but a GPIO request from another device will be accepted
> > too.
> >
> > Both situations are incorrect in my case.
> 
> Yes, since the ownership design is based on subsystem rather consumer device.
> 
> > Let me know if I have not well understood your proposal. My concern is
> > to get out of this situation without breaking current DTs.
> 
> See above, hope it clarifies a bit.

Yes I get it but I still don't see how I can use your approach to solve
my issue. We have a situation for several pin controllers. If I can't
know who is requesting the GPIO, I have no idea about how to solve this
issue. Bypassing the strict mode, as suggested, if the pin controller is also
a gpio controller may lead, IMO, to wrong behaviors. 

Do I have to try to find a way to fix this situation? Maybe, it will be
easier to progress on the muxing and configuration topic and to
introduce a DT property to enable the strict mode or wathever modes you
want once everything is ready and DTs fixed.

I'd prefer to fix the current situation then to improve muxing and
configuration stuff because it will take time.

Regards

Ludovic

Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

On Wed, Jan 24, 2018 at 05:42:15PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 24, 2018 at 3:07 PM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> > On Thu, Jan 18, 2018 at 04:22:28PM +0100, Ludovic Desroches wrote:
> >> On Thu, Jan 18, 2018 at 11:30:00AM +0100, Linus Walleij wrote:
> >> > On Mon, Jan 15, 2018 at 5:24 PM, Ludovic Desroches
> >> > <ludovic.desroc...@microchip.com> wrote:
> 
> >> > I think we need to think over what is a good way to share ownership
> >> > of a pin.
> >> >
> >> > Russell pointed me to a similar problem incidentally and I briefly looked
> >> > into it: there are cases when several devices may need to hold the
> >> > same pin.
> >> >
> >> > Can't we just look up the associated gpio_chip from the GPIO range,
> >> > and in case the pin is connected between the pin controller and
> >> > the GPIO chip, then we allow the gpiochip to also take a
> >> > reference?
> 
> How do you find my proposal about introducing ownership level (not
> requested yet; exclusive; shared)?
> 

Yes but I don't see how I can fix my issue with these levels. In my
case, I need an exclusive ownership at device level not at pin level. In
reality, it is at pin level but I am in this situation because my pin
controler was introduced as non strict and also because I need to set
the configuration of the pin which is going to be used as a GPIO.

If the ownership is exclusive, pinmuxing coming from pinctrl-default
will be accepted but the GPIO request will fail even if it comes from the
same device.

If the ownership is shared then, pinmuxing coming from pinctrl-default
will be accepted but a GPIO request from another device will be accepted
too.

Both situations are incorrect in my case.

Let me know if I have not well understood your proposal. My concern is
to get out of this situation without breaking current DTs.

Regards

Ludovic

> >> It's the probably the way to go, it was Maxime's proposal and Andy seems
> >> to agree this solution.
> 
> Confirm with caveat that this is a fix for subset of cases.
> 
> > If pin_request() is called with gpio_range not NULL, it means that the
> > requests comes from a GPIO chip and the pin controller handles this pin.
> > In this case, I would say the pin is connected between the pin
> > controller and the GPIO chip. Is my assumption right?
> >
> > I am not sure it will fit all the cases:
> 
> I think it doesn't cover cases when you have UART + UART + GPIO (I
> posted early a use case example).
> 
> But at least it doesn't move things in a wrong direction.
> 
> > - case 1: device A requests the pin (pinctrl-default state) and mux it
> >   as a GPIO. Later,it requests the pin as a GPIO (gpiolib). This 'weird'
> >   situation happens because some strict pin controllers were not declared
> >   as strict and/or pinconf is needed.
> >
> > - case 2: device A requests the pin (pinctrl-default state). Device B
> >   requests the pin as a GPIO (gpiolib).
> >
> > In case 1, pin_request must not return an error. In case 2, pin_request
> > must return an error even if the pin is connected between the pin
> > controller and the GPIO chip.
> 
> For these cases looks OK to me.
> 
> >> > I.e. in that case you just allow gpio_owner to proceed and take the
> >> > pin just like with a non-strict controller.
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

On Wed, Jan 24, 2018 at 05:42:15PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 24, 2018 at 3:07 PM, Ludovic Desroches
>  wrote:
> > On Thu, Jan 18, 2018 at 04:22:28PM +0100, Ludovic Desroches wrote:
> >> On Thu, Jan 18, 2018 at 11:30:00AM +0100, Linus Walleij wrote:
> >> > On Mon, Jan 15, 2018 at 5:24 PM, Ludovic Desroches
> >> >  wrote:
> 
> >> > I think we need to think over what is a good way to share ownership
> >> > of a pin.
> >> >
> >> > Russell pointed me to a similar problem incidentally and I briefly looked
> >> > into it: there are cases when several devices may need to hold the
> >> > same pin.
> >> >
> >> > Can't we just look up the associated gpio_chip from the GPIO range,
> >> > and in case the pin is connected between the pin controller and
> >> > the GPIO chip, then we allow the gpiochip to also take a
> >> > reference?
> 
> How do you find my proposal about introducing ownership level (not
> requested yet; exclusive; shared)?
> 

Yes but I don't see how I can fix my issue with these levels. In my
case, I need an exclusive ownership at device level not at pin level. In
reality, it is at pin level but I am in this situation because my pin
controler was introduced as non strict and also because I need to set
the configuration of the pin which is going to be used as a GPIO.

If the ownership is exclusive, pinmuxing coming from pinctrl-default
will be accepted but the GPIO request will fail even if it comes from the
same device.

If the ownership is shared then, pinmuxing coming from pinctrl-default
will be accepted but a GPIO request from another device will be accepted
too.

Both situations are incorrect in my case.

Let me know if I have not well understood your proposal. My concern is
to get out of this situation without breaking current DTs.

Regards

Ludovic

> >> It's the probably the way to go, it was Maxime's proposal and Andy seems
> >> to agree this solution.
> 
> Confirm with caveat that this is a fix for subset of cases.
> 
> > If pin_request() is called with gpio_range not NULL, it means that the
> > requests comes from a GPIO chip and the pin controller handles this pin.
> > In this case, I would say the pin is connected between the pin
> > controller and the GPIO chip. Is my assumption right?
> >
> > I am not sure it will fit all the cases:
> 
> I think it doesn't cover cases when you have UART + UART + GPIO (I
> posted early a use case example).
> 
> But at least it doesn't move things in a wrong direction.
> 
> > - case 1: device A requests the pin (pinctrl-default state) and mux it
> >   as a GPIO. Later,it requests the pin as a GPIO (gpiolib). This 'weird'
> >   situation happens because some strict pin controllers were not declared
> >   as strict and/or pinconf is needed.
> >
> > - case 2: device A requests the pin (pinctrl-default state). Device B
> >   requests the pin as a GPIO (gpiolib).
> >
> > In case 1, pin_request must not return an error. In case 2, pin_request
> > must return an error even if the pin is connected between the pin
> > controller and the GPIO chip.
> 
> For these cases looks OK to me.
> 
> >> > I.e. in that case you just allow gpio_owner to proceed and take the
> >> > pin just like with a non-strict controller.
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

On Thu, Jan 18, 2018 at 04:22:28PM +0100, Ludovic Desroches wrote:
> On Thu, Jan 18, 2018 at 11:30:00AM +0100, Linus Walleij wrote:
> > On Mon, Jan 15, 2018 at 5:24 PM, Ludovic Desroches
> > <ludovic.desroc...@microchip.com> wrote:
> > 
> > > It can be useful for the pinmuxing layer to know which device is
> > > requesting a GPIO. Add a consumer variant for gpiod_request to
> > > reach this goal.
> > >
> > > GPIO chips managed by pin controllers should provide the new
> > > request_consumer operation. They can rely on
> > > gpiochip_generic_request_consumer instead of
> > > gpiochip_generic_request.
> > >
> > > Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
> > 
> > I think we need to think over what is a good way to share ownership
> > of a pin.
> > 
> > Russell pointed me to a similar problem incidentally and I briefly looked
> > into it: there are cases when several devices may need to hold the
> > same pin.
> > 
> > Can't we just look up the associated gpio_chip from the GPIO range,
> > and in case the pin is connected between the pin controller and
> > the GPIO chip, then we allow the gpiochip to also take a
> > reference?
> > 
> 
> It's the probably the way to go, it was Maxime's proposal and Andy seems
> to agree this solution.
> 

If pin_request() is called with gpio_range not NULL, it means that the
requests comes from a GPIO chip and the pin controller handles this pin.
In this case, I would say the pin is connected between the pin
controller and the GPIO chip. Is my assumption right?

I am not sure it will fit all the cases:

- case 1: device A requests the pin (pinctrl-default state) and mux it
  as a GPIO. Later,it requests the pin as a GPIO (gpiolib). This 'weird'
  situation happens because some strict pin controllers were not declared
  as strict and/or pinconf is needed.

- case 2: device A requests the pin (pinctrl-default state). Device B
  requests the pin as a GPIO (gpiolib).

In case 1, pin_request must not return an error. In case 2, pin_request
must return an error even if the pin is connected between the pin
controller and the GPIO chip.

> > I.e. in that case you just allow gpio_owner to proceed and take the
> > pin just like with a non-strict controller.

Regards

Ludovic

Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

On Thu, Jan 18, 2018 at 04:22:28PM +0100, Ludovic Desroches wrote:
> On Thu, Jan 18, 2018 at 11:30:00AM +0100, Linus Walleij wrote:
> > On Mon, Jan 15, 2018 at 5:24 PM, Ludovic Desroches
> >  wrote:
> > 
> > > It can be useful for the pinmuxing layer to know which device is
> > > requesting a GPIO. Add a consumer variant for gpiod_request to
> > > reach this goal.
> > >
> > > GPIO chips managed by pin controllers should provide the new
> > > request_consumer operation. They can rely on
> > > gpiochip_generic_request_consumer instead of
> > > gpiochip_generic_request.
> > >
> > > Signed-off-by: Ludovic Desroches 
> > 
> > I think we need to think over what is a good way to share ownership
> > of a pin.
> > 
> > Russell pointed me to a similar problem incidentally and I briefly looked
> > into it: there are cases when several devices may need to hold the
> > same pin.
> > 
> > Can't we just look up the associated gpio_chip from the GPIO range,
> > and in case the pin is connected between the pin controller and
> > the GPIO chip, then we allow the gpiochip to also take a
> > reference?
> > 
> 
> It's the probably the way to go, it was Maxime's proposal and Andy seems
> to agree this solution.
> 

If pin_request() is called with gpio_range not NULL, it means that the
requests comes from a GPIO chip and the pin controller handles this pin.
In this case, I would say the pin is connected between the pin
controller and the GPIO chip. Is my assumption right?

I am not sure it will fit all the cases:

- case 1: device A requests the pin (pinctrl-default state) and mux it
  as a GPIO. Later,it requests the pin as a GPIO (gpiolib). This 'weird'
  situation happens because some strict pin controllers were not declared
  as strict and/or pinconf is needed.

- case 2: device A requests the pin (pinctrl-default state). Device B
  requests the pin as a GPIO (gpiolib).

In case 1, pin_request must not return an error. In case 2, pin_request
must return an error even if the pin is connected between the pin
controller and the GPIO chip.

> > I.e. in that case you just allow gpio_owner to proceed and take the
> > pin just like with a non-strict controller.

Regards

Ludovic

Re: [PATCH] pinctrl: at91-pio4: add support for drive-strength property

[Ludovic Desroches]

On Mon, Jan 22, 2018 at 09:37:38AM +0100, Linus Walleij wrote:
> On Thu, Jan 18, 2018 at 5:02 PM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> 
> > Add support for the drive-strength property. Usually its value is
> > expressed in mA. Since the numeric value depends on VDDIOP voltage,
> > the controller uses low, medium and high to define the drive-strengh.
> 
> Aha I see. That's complex. It certainly results in a certain mA drive
> strength in the end, but what you're saying is that this is not usually
> what we configure.
> 

The PIO Controller Interface is:
Drive Strength:
0 Low drive
1 Low drive
2 Medium drive
3 High drive

In the Electrical Characteristics, you have:
GPIO 1.8V Low: max 1 mA
GPIO 1.8V Medium: max 10 mA
GPIO 1.8V High: max 18 mA
GPIO 3.3V Low: max 2 mA
GPIO 3.3V Medium: max 20 mA
GPIO 3.3V High: max 32 mA

> > The PIO controller accepts two values for the low drive: 0 or 1. Most
> > of the time, we don't care about the drive strength, there is no need
> > to change it, so 0 is considered as the default value.
> 
> Do you mean default value as in "whatever the hardware was set
> up as at boot time"?

Yes

> 
> > The low-drive
> > value won't be advertised through pinconf-pins file excepted if it
> 
> except?

Yes

> 
> > has been set explicitly in the device tree ie if its value is
> > different from 0.
> >
> > Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
> 
> OK I think I get it.
> 
> >  Optional properties:
> >  - GENERIC_PINCONFIG: generic pinconfig options to use, bias-disable,
> > -bias-pull-down, bias-pull-up, drive-open-drain, input-schmitt-enable,
> > -input-debounce, output-low, output-high.
> > +bias-pull-down, bias-pull-up, drive-open-drain, drive-strength,
> > +input-schmitt-enable, input-debounce, output-low, output-high.
> (...)
> > +   drive-strength = ;
> 
> So you say you support this argument and it will be something like
> 
> include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_LO  1
> include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_ME  2
> include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_HI  3
> 
> But the definition if generic drive strength is actually in mA.
> 
> I think it is OK to deviate from stating it in mA, but you should
> write this in the DT bindings so people do not get confused.
> 

Ok

> > @@ -814,6 +834,19 @@ static void atmel_conf_pin_config_dbg_show(struct 
> > pinctrl_dev *pctldev,
> > seq_printf(s, "%s ", "open-drain");
> > if (conf & ATMEL_PIO_SCHMITT_MASK)
> > seq_printf(s, "%s ", "schmitt");
> > +   if (conf & ATMEL_PIO_DRVSTR_MASK) {
> > +   switch ((conf & ATMEL_PIO_DRVSTR_MASK) >> 
> > ATMEL_PIO_DRVSTR_OFFSET) {
> > +   case ATMEL_PIO_DRVSTR_LO:
> > +   seq_printf(s, "%s ", "low-drive");
> > +   break;
> > +   case ATMEL_PIO_DRVSTR_ME:
> > +   seq_printf(s, "%s ", "medium-drive");
> > +   break;
> > +   case ATMEL_PIO_DRVSTR_HI:
> > +   seq_printf(s, "%s ", "high-drive");
> > +   break;
> 
> But here you know what VDDIOP is, right?
> 

No, I have no way to retrieve the power for the several VDDIOP power
rails.

> So in debugfs you could actually print the real drive strength
> in mA, or both "medium-drive, %u mA"?
> 
> Yours,
> Linus Walleij

Regards

Ludovic

Re: [PATCH] pinctrl: at91-pio4: add support for drive-strength property

[Ludovic Desroches]

On Mon, Jan 22, 2018 at 09:37:38AM +0100, Linus Walleij wrote:
> On Thu, Jan 18, 2018 at 5:02 PM, Ludovic Desroches
>  wrote:
> 
> > Add support for the drive-strength property. Usually its value is
> > expressed in mA. Since the numeric value depends on VDDIOP voltage,
> > the controller uses low, medium and high to define the drive-strengh.
> 
> Aha I see. That's complex. It certainly results in a certain mA drive
> strength in the end, but what you're saying is that this is not usually
> what we configure.
> 

The PIO Controller Interface is:
Drive Strength:
0 Low drive
1 Low drive
2 Medium drive
3 High drive

In the Electrical Characteristics, you have:
GPIO 1.8V Low: max 1 mA
GPIO 1.8V Medium: max 10 mA
GPIO 1.8V High: max 18 mA
GPIO 3.3V Low: max 2 mA
GPIO 3.3V Medium: max 20 mA
GPIO 3.3V High: max 32 mA

> > The PIO controller accepts two values for the low drive: 0 or 1. Most
> > of the time, we don't care about the drive strength, there is no need
> > to change it, so 0 is considered as the default value.
> 
> Do you mean default value as in "whatever the hardware was set
> up as at boot time"?

Yes

> 
> > The low-drive
> > value won't be advertised through pinconf-pins file excepted if it
> 
> except?

Yes

> 
> > has been set explicitly in the device tree ie if its value is
> > different from 0.
> >
> > Signed-off-by: Ludovic Desroches 
> 
> OK I think I get it.
> 
> >  Optional properties:
> >  - GENERIC_PINCONFIG: generic pinconfig options to use, bias-disable,
> > -bias-pull-down, bias-pull-up, drive-open-drain, input-schmitt-enable,
> > -input-debounce, output-low, output-high.
> > +bias-pull-down, bias-pull-up, drive-open-drain, drive-strength,
> > +input-schmitt-enable, input-debounce, output-low, output-high.
> (...)
> > +   drive-strength = ;
> 
> So you say you support this argument and it will be something like
> 
> include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_LO  1
> include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_ME  2
> include/dt-bindings/pinctrl/at91.h:#define ATMEL_PIO_DRVSTR_HI  3
> 
> But the definition if generic drive strength is actually in mA.
> 
> I think it is OK to deviate from stating it in mA, but you should
> write this in the DT bindings so people do not get confused.
> 

Ok

> > @@ -814,6 +834,19 @@ static void atmel_conf_pin_config_dbg_show(struct 
> > pinctrl_dev *pctldev,
> > seq_printf(s, "%s ", "open-drain");
> > if (conf & ATMEL_PIO_SCHMITT_MASK)
> > seq_printf(s, "%s ", "schmitt");
> > +   if (conf & ATMEL_PIO_DRVSTR_MASK) {
> > +   switch ((conf & ATMEL_PIO_DRVSTR_MASK) >> 
> > ATMEL_PIO_DRVSTR_OFFSET) {
> > +   case ATMEL_PIO_DRVSTR_LO:
> > +   seq_printf(s, "%s ", "low-drive");
> > +   break;
> > +   case ATMEL_PIO_DRVSTR_ME:
> > +   seq_printf(s, "%s ", "medium-drive");
> > +   break;
> > +   case ATMEL_PIO_DRVSTR_HI:
> > +   seq_printf(s, "%s ", "high-drive");
> > +   break;
> 
> But here you know what VDDIOP is, right?
> 

No, I have no way to retrieve the power for the several VDDIOP power
rails.

> So in debugfs you could actually print the real drive strength
> in mA, or both "medium-drive, %u mA"?
> 
> Yours,
> Linus Walleij

Regards

Ludovic

[PATCH] pinctrl: at91-pio4: add support for drive-strength property

[Ludovic Desroches]

Add support for the drive-strength property. Usually its value is
expressed in mA. Since the numeric value depends on VDDIOP voltage,
the controller uses low, medium and high to define the drive-strengh.

The PIO controller accepts two values for the low drive: 0 or 1. Most
of the time, we don't care about the drive strength, there is no need
to change it, so 0 is considered as the default value. The low-drive
value won't be advertised through pinconf-pins file excepted if it
has been set explicitly in the device tree ie if its value is
different from 0.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 .../bindings/pinctrl/atmel,at91-pio4-pinctrl.txt   |  5 ++--
 drivers/pinctrl/pinctrl-at91-pio4.c| 33 ++
 include/dt-bindings/pinctrl/at91.h |  4 +++
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
index 61ac75706cc9..183064bc4bda 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
@@ -34,8 +34,8 @@ right representation of the pin.
 
 Optional properties:
 - GENERIC_PINCONFIG: generic pinconfig options to use, bias-disable,
-bias-pull-down, bias-pull-up, drive-open-drain, input-schmitt-enable,
-input-debounce, output-low, output-high.
+bias-pull-down, bias-pull-up, drive-open-drain, drive-strength,
+input-schmitt-enable, input-debounce, output-low, output-high.
 
 Example:
 
@@ -66,6 +66,7 @@ Example:
pinmux = ,
 ;
bias-pull-up;
+   drive-strength = ;
};
 
pinctrl_sdmmc1_default: sdmmc1_default {
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
b/drivers/pinctrl/pinctrl-at91-pio4.c
index 4b57a13758a4..857c0a41a905 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -14,6 +14,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 /* FIXME: needed for gpio_to_irq(), get rid of this */
@@ -49,6 +50,8 @@
 #defineATMEL_PIO_IFSCEN_MASK   BIT(13)
 #defineATMEL_PIO_OPD_MASK  BIT(14)
 #defineATMEL_PIO_SCHMITT_MASK  BIT(15)
+#defineATMEL_PIO_DRVSTR_MASK   GENMASK(17, 16)
+#defineATMEL_PIO_DRVSTR_OFFSET 16
 #defineATMEL_PIO_CFGR_EVTSEL_MASK  GENMASK(26, 24)
 #defineATMEL_PIO_CFGR_EVTSEL_FALLING   (0 << 24)
 #defineATMEL_PIO_CFGR_EVTSEL_RISING(1 << 24)
@@ -685,6 +688,11 @@ static int atmel_conf_pin_config_group_get(struct 
pinctrl_dev *pctldev,
return -EINVAL;
arg = 1;
break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   if (!(res & ATMEL_PIO_DRVSTR_MASK))
+   return -EINVAL;
+   arg = (res & ATMEL_PIO_DRVSTR_MASK) >> ATMEL_PIO_DRVSTR_OFFSET;
+   break;
case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
if (!(res & ATMEL_PIO_SCHMITT_MASK))
return -EINVAL;
@@ -737,6 +745,18 @@ static int atmel_conf_pin_config_group_set(struct 
pinctrl_dev *pctldev,
else
conf |= ATMEL_PIO_OPD_MASK;
break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   switch (arg) {
+   case ATMEL_PIO_DRVSTR_LO:
+   case ATMEL_PIO_DRVSTR_ME:
+   case ATMEL_PIO_DRVSTR_HI:
+   conf &= (~ATMEL_PIO_DRVSTR_MASK);
+   conf |= arg << ATMEL_PIO_DRVSTR_OFFSET;
+   break;
+   default:
+   dev_warn(pctldev->dev, "drive strength not 
updated (incorrect value)\n");
+   }
+   break;
case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
if (arg == 0)
conf |= ATMEL_PIO_SCHMITT_MASK;
@@ -814,6 +834,19 @@ static void atmel_conf_pin_config_dbg_show(struct 
pinctrl_dev *pctldev,
seq_printf(s, "%s ", "open-drain");
if (conf & ATMEL_PIO_SCHMITT_MASK)
seq_printf(s, "%s ", "schmitt");
+   if (conf & ATMEL_PIO_DRVSTR_MASK) {
+   switch ((conf & ATMEL_PIO_DRVSTR_MASK) >> 
ATMEL_PIO_DRVSTR_OFFSET) {
+   case ATMEL_PIO_DRVSTR_LO:
+   seq_printf(s, "%s ", "low-drive");
+   bre

[PATCH] pinctrl: at91-pio4: add support for drive-strength property

[Ludovic Desroches]

Add support for the drive-strength property. Usually its value is
expressed in mA. Since the numeric value depends on VDDIOP voltage,
the controller uses low, medium and high to define the drive-strengh.

The PIO controller accepts two values for the low drive: 0 or 1. Most
of the time, we don't care about the drive strength, there is no need
to change it, so 0 is considered as the default value. The low-drive
value won't be advertised through pinconf-pins file excepted if it
has been set explicitly in the device tree ie if its value is
different from 0.

Signed-off-by: Ludovic Desroches 
---
 .../bindings/pinctrl/atmel,at91-pio4-pinctrl.txt   |  5 ++--
 drivers/pinctrl/pinctrl-at91-pio4.c| 33 ++
 include/dt-bindings/pinctrl/at91.h |  4 +++
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
index 61ac75706cc9..183064bc4bda 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
@@ -34,8 +34,8 @@ right representation of the pin.
 
 Optional properties:
 - GENERIC_PINCONFIG: generic pinconfig options to use, bias-disable,
-bias-pull-down, bias-pull-up, drive-open-drain, input-schmitt-enable,
-input-debounce, output-low, output-high.
+bias-pull-down, bias-pull-up, drive-open-drain, drive-strength,
+input-schmitt-enable, input-debounce, output-low, output-high.
 
 Example:
 
@@ -66,6 +66,7 @@ Example:
pinmux = ,
 ;
bias-pull-up;
+   drive-strength = ;
};
 
pinctrl_sdmmc1_default: sdmmc1_default {
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
b/drivers/pinctrl/pinctrl-at91-pio4.c
index 4b57a13758a4..857c0a41a905 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -14,6 +14,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 /* FIXME: needed for gpio_to_irq(), get rid of this */
@@ -49,6 +50,8 @@
 #defineATMEL_PIO_IFSCEN_MASK   BIT(13)
 #defineATMEL_PIO_OPD_MASK  BIT(14)
 #defineATMEL_PIO_SCHMITT_MASK  BIT(15)
+#defineATMEL_PIO_DRVSTR_MASK   GENMASK(17, 16)
+#defineATMEL_PIO_DRVSTR_OFFSET 16
 #defineATMEL_PIO_CFGR_EVTSEL_MASK  GENMASK(26, 24)
 #defineATMEL_PIO_CFGR_EVTSEL_FALLING   (0 << 24)
 #defineATMEL_PIO_CFGR_EVTSEL_RISING(1 << 24)
@@ -685,6 +688,11 @@ static int atmel_conf_pin_config_group_get(struct 
pinctrl_dev *pctldev,
return -EINVAL;
arg = 1;
break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   if (!(res & ATMEL_PIO_DRVSTR_MASK))
+   return -EINVAL;
+   arg = (res & ATMEL_PIO_DRVSTR_MASK) >> ATMEL_PIO_DRVSTR_OFFSET;
+   break;
case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
if (!(res & ATMEL_PIO_SCHMITT_MASK))
return -EINVAL;
@@ -737,6 +745,18 @@ static int atmel_conf_pin_config_group_set(struct 
pinctrl_dev *pctldev,
else
conf |= ATMEL_PIO_OPD_MASK;
break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   switch (arg) {
+   case ATMEL_PIO_DRVSTR_LO:
+   case ATMEL_PIO_DRVSTR_ME:
+   case ATMEL_PIO_DRVSTR_HI:
+   conf &= (~ATMEL_PIO_DRVSTR_MASK);
+   conf |= arg << ATMEL_PIO_DRVSTR_OFFSET;
+   break;
+   default:
+   dev_warn(pctldev->dev, "drive strength not 
updated (incorrect value)\n");
+   }
+   break;
case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
if (arg == 0)
conf |= ATMEL_PIO_SCHMITT_MASK;
@@ -814,6 +834,19 @@ static void atmel_conf_pin_config_dbg_show(struct 
pinctrl_dev *pctldev,
seq_printf(s, "%s ", "open-drain");
if (conf & ATMEL_PIO_SCHMITT_MASK)
seq_printf(s, "%s ", "schmitt");
+   if (conf & ATMEL_PIO_DRVSTR_MASK) {
+   switch ((conf & ATMEL_PIO_DRVSTR_MASK) >> 
ATMEL_PIO_DRVSTR_OFFSET) {
+   case ATMEL_PIO_DRVSTR_LO:
+   seq_printf(s, "%s ", "low-drive");
+   break;
+   case ATMEL_PIO_DRVSTR_ME:
+ 

Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

On Thu, Jan 18, 2018 at 11:30:00AM +0100, Linus Walleij wrote:
> On Mon, Jan 15, 2018 at 5:24 PM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> 
> > It can be useful for the pinmuxing layer to know which device is
> > requesting a GPIO. Add a consumer variant for gpiod_request to
> > reach this goal.
> >
> > GPIO chips managed by pin controllers should provide the new
> > request_consumer operation. They can rely on
> > gpiochip_generic_request_consumer instead of
> > gpiochip_generic_request.
> >
> > Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
> 
> I think we need to think over what is a good way to share ownership
> of a pin.
> 
> Russell pointed me to a similar problem incidentally and I briefly looked
> into it: there are cases when several devices may need to hold the
> same pin.
> 
> Can't we just look up the associated gpio_chip from the GPIO range,
> and in case the pin is connected between the pin controller and
> the GPIO chip, then we allow the gpiochip to also take a
> reference?
> 

It's the probably the way to go, it was Maxime's proposal and Andy seems
to agree this solution.

> I.e. in that case you just allow gpio_owner to proceed and take the
> pin just like with a non-strict controller.
> 
> Yours,
> Linus Walleij

Regards

Ludovic

Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

On Thu, Jan 18, 2018 at 11:30:00AM +0100, Linus Walleij wrote:
> On Mon, Jan 15, 2018 at 5:24 PM, Ludovic Desroches
>  wrote:
> 
> > It can be useful for the pinmuxing layer to know which device is
> > requesting a GPIO. Add a consumer variant for gpiod_request to
> > reach this goal.
> >
> > GPIO chips managed by pin controllers should provide the new
> > request_consumer operation. They can rely on
> > gpiochip_generic_request_consumer instead of
> > gpiochip_generic_request.
> >
> > Signed-off-by: Ludovic Desroches 
> 
> I think we need to think over what is a good way to share ownership
> of a pin.
> 
> Russell pointed me to a similar problem incidentally and I briefly looked
> into it: there are cases when several devices may need to hold the
> same pin.
> 
> Can't we just look up the associated gpio_chip from the GPIO range,
> and in case the pin is connected between the pin controller and
> the GPIO chip, then we allow the gpiochip to also take a
> reference?
> 

It's the probably the way to go, it was Maxime's proposal and Andy seems
to agree this solution.

> I.e. in that case you just allow gpio_owner to proceed and take the
> pin just like with a non-strict controller.
> 
> Yours,
> Linus Walleij

Regards

Ludovic

Re: [RESEND RFC PATCH 0/2] fixing the gpio ownership

[Ludovic Desroches]

On Thu, Jan 18, 2018 at 11:16:44AM +0100, Linus Walleij wrote:
> Hi Ludovic, thanks for your patches!
> 
> On Mon, Jan 15, 2018 at 5:24 PM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> 
> > A few weeks ago, I have sent an RFC about adding bias support for GPIOs [1].
> 
> I was confused I think, because the issue of ownership and adding
> bias support were conflated.
> 

No problem, at the beginning, I only wanted to enable the strict. Doing
this involves that I have to remove pinctrl nodes for the pins which are
going to be request through the gpiolib to avoid conflicts. These pins
were configured with bias-pull-up. That's why I try to add the bias
support.

> I think I discussed properly the ideas I have for pin control properties
> vs the GPIOlib API/ABI in my response to patch 1.
> 

Thanks for the detailed answer about what you have in mind.

> > It was motivated by the fact that I wanted to enable the pinmuxing strict 
> > mode
> > for my pin controller which can muxed a pin as a peripheral or as a GPIO.
> 
> So that is a different thing from bias support.
> 

Well, yes and not! As a consequence of enabling strict mode, I have to
find another way to configure the pins.

> > Enabling the strict mode prevents several devices to be probed because
> > requesting a GPIO fails. The pin request function complains about the
> > ownership of the GPIO which is different from the mux ownership. I have to
> > remove my pinctrl node to avoid this conflict but I need it to configure my
> > pins and to set a pull-up bias for my GPIOs.
> 
> Okay I think the right solution is to fix the ownership issue, and set
> up bias using pin control/config but use the line through gpiolib for now.
> 
> > The main issue is that enabling the strict mode will
> > break old DTBs.
> 
> Yeah we need to work around that.
> 
> > I was going to submit patches for this but, after using the
> > sysfs which still show me a bad ownership, I decided that it should be 
> > fixed.
> 
> Yep :)
> 
> > So I did these patches. Unfortunately, there are several ways to lead to
> > gpiod_request(). It does the trick only for the gpiod_get family. The issue 
> > is
> > still present with legacy gpio_request and fwnode_get_named_gpiod.
> 
> fwnode_get_named_gpiod() must really be fixed too. You probably
> want to have things like LEDs and GPIO keys working even if
> your pin controller is strict.
> 

Yes, I have noticed this issue.

> I don't care so much about the old functions, I guess you just have
> to make sure that the drivers for *your* pin controller all use descriptors
> so that you can enable strict mode on *your* pin controller, right?
> 

Right, I have spotted some drivers to fix.

> Restrict your task to this, I'd say.
> 
> > It seems
> > that more and more drivers are converted to use GPIO descriptors so there is
> > some hope.
> 
> Yeah I'm doing this when I have time. There is plenty of work...
> Help appreciated.
> 

I will try to handle the ones related to the platforms I am using.

Regards

Ludovic

Re: [RESEND RFC PATCH 0/2] fixing the gpio ownership

[Ludovic Desroches]

On Thu, Jan 18, 2018 at 11:16:44AM +0100, Linus Walleij wrote:
> Hi Ludovic, thanks for your patches!
> 
> On Mon, Jan 15, 2018 at 5:24 PM, Ludovic Desroches
>  wrote:
> 
> > A few weeks ago, I have sent an RFC about adding bias support for GPIOs [1].
> 
> I was confused I think, because the issue of ownership and adding
> bias support were conflated.
> 

No problem, at the beginning, I only wanted to enable the strict. Doing
this involves that I have to remove pinctrl nodes for the pins which are
going to be request through the gpiolib to avoid conflicts. These pins
were configured with bias-pull-up. That's why I try to add the bias
support.

> I think I discussed properly the ideas I have for pin control properties
> vs the GPIOlib API/ABI in my response to patch 1.
> 

Thanks for the detailed answer about what you have in mind.

> > It was motivated by the fact that I wanted to enable the pinmuxing strict 
> > mode
> > for my pin controller which can muxed a pin as a peripheral or as a GPIO.
> 
> So that is a different thing from bias support.
> 

Well, yes and not! As a consequence of enabling strict mode, I have to
find another way to configure the pins.

> > Enabling the strict mode prevents several devices to be probed because
> > requesting a GPIO fails. The pin request function complains about the
> > ownership of the GPIO which is different from the mux ownership. I have to
> > remove my pinctrl node to avoid this conflict but I need it to configure my
> > pins and to set a pull-up bias for my GPIOs.
> 
> Okay I think the right solution is to fix the ownership issue, and set
> up bias using pin control/config but use the line through gpiolib for now.
> 
> > The main issue is that enabling the strict mode will
> > break old DTBs.
> 
> Yeah we need to work around that.
> 
> > I was going to submit patches for this but, after using the
> > sysfs which still show me a bad ownership, I decided that it should be 
> > fixed.
> 
> Yep :)
> 
> > So I did these patches. Unfortunately, there are several ways to lead to
> > gpiod_request(). It does the trick only for the gpiod_get family. The issue 
> > is
> > still present with legacy gpio_request and fwnode_get_named_gpiod.
> 
> fwnode_get_named_gpiod() must really be fixed too. You probably
> want to have things like LEDs and GPIO keys working even if
> your pin controller is strict.
> 

Yes, I have noticed this issue.

> I don't care so much about the old functions, I guess you just have
> to make sure that the drivers for *your* pin controller all use descriptors
> so that you can enable strict mode on *your* pin controller, right?
> 

Right, I have spotted some drivers to fix.

> Restrict your task to this, I'd say.
> 
> > It seems
> > that more and more drivers are converted to use GPIO descriptors so there is
> > some hope.
> 
> Yeah I'm doing this when I have time. There is plenty of work...
> Help appreciated.
> 

I will try to handle the ones related to the platforms I am using.

Regards

Ludovic

[PATCH] ARM: dts: at91: sama5d4: fix pinctrl compatible string

[Ludovic Desroches]

From: Santiago Esteban <santiago.este...@microchip.com>

The compatible string is incorrect. Add atmel,sama5d3-pinctrl since
it's the appropriate compatible string. Remove the
atmel,at91rm9200-pinctrl compatible string, this fallback is
useless, there are too many changes.

Signed-off-by: Santiago Esteban <santiago.este...@microchip.com>
Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
Cc: sta...@vger.kernel.org #v3.18
---
 arch/arm/boot/dts/sama5d4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 373b3621b536..c7105096c623 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -1379,7 +1379,7 @@
pinctrl@fc06a000 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "atmel,at91sam9x5-pinctrl", 
"atmel,at91rm9200-pinctrl", "simple-bus";
+   compatible = "atmel,sama5d3-pinctrl", 
"atmel,at91sam9x5-pinctrl", "simple-bus";
ranges = <0xfc068000 0xfc068000 0x100
  0xfc06a000 0xfc06a000 0x4000>;
/* WARNING: revisit as pin spec has changed */
-- 
2.12.2

[PATCH] ARM: dts: at91: sama5d4: fix pinctrl compatible string

[Ludovic Desroches]

From: Santiago Esteban 

The compatible string is incorrect. Add atmel,sama5d3-pinctrl since
it's the appropriate compatible string. Remove the
atmel,at91rm9200-pinctrl compatible string, this fallback is
useless, there are too many changes.

Signed-off-by: Santiago Esteban 
Signed-off-by: Ludovic Desroches 
Cc: sta...@vger.kernel.org #v3.18
---
 arch/arm/boot/dts/sama5d4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 373b3621b536..c7105096c623 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -1379,7 +1379,7 @@
pinctrl@fc06a000 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "atmel,at91sam9x5-pinctrl", 
"atmel,at91rm9200-pinctrl", "simple-bus";
+   compatible = "atmel,sama5d3-pinctrl", 
"atmel,at91sam9x5-pinctrl", "simple-bus";
ranges = <0xfc068000 0xfc068000 0x100
  0xfc06a000 0xfc06a000 0x4000>;
/* WARNING: revisit as pin spec has changed */
-- 
2.12.2

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

On Wed, Jan 17, 2018 at 06:07:02PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 17, 2018 at 4:54 PM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> > On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote:
> 
> >> First of all, the main architectural issue with current pin control
> >> design is so called "states". It's quite artificial entity which is
> >> not represented by hardware per se.
> >>
> >> Instead we better to provide an API to pin configuration and pin
> >> muxing: I would like to switch to *this* pin function with *this* pin
> >> configuration.
> 
> > gpio_request_enable() allows to switch to the GPIO pin function.
> 
> ...as a particular case of "set this pin to this function".
> 
> > To clarify the situation, from my point of view there are two issues:
> >
> > - Several pin controllers didn't enabled the strict mode when they were
> >   introduced. Nowadays, enabling it will break several DTs. Maybe a DT
> >   property to enable/disable strict mode could do the trick: we remove
> >   pinctrl nodes (so pinmux + pinconf) for pins which will be requested
> >   by gpiod_request() and we set the strict property to true.
> 
> OK.
> 
> > - But... The GPIO pin configuration is missing.
> 
> Here you mixed up the things. Either we are talking about GPIO
> configuration (direction, enabling/disabling I/O buffers), or we are
> talking about pin configuration (bias, drive strength, slew rate,
> debounce, etc.).

I was talking about the pin configuration of the GPIO so about bias,
drive strength, etc.

> 
> >  Some configuration features
> >   have been added, we can continue to add new ones but I am not sure
> >   it's the best solution.
> 
> See below.
> 
> >  At the moment, we rely on a single cell to
> >   manage the configuration. It may not be enough and each time a new pin
> >   configuration will appear, it will have to be added both to the gpiolib
> >   and pinconf.
> 
> >> Second, the pin control and GPIOs are orthogonal as your hardware
> >> confirms. The propagating pin configuration or muxing via GPIO API
> >> looks to me a wrong direction.
> >>
> >
> > I agree but it seems we have started to follow this path.
> 
> Which is still wrong and nothing prevents us to just stop here and
> consider better way.
> 
> The issue is how we historically represent pins inside kernel and how
> hardware evolves at the same time.
> 
> Looking from now retrospectively I can state the following:
> - each GPIO controller *might* have (few) capabilities of pin configuration
> - pin control may not necessary have GPIO function of the pin
> 
> Design is now GPIO oriented while it should be pin oriented.
> 

Agree

> So, instead of littering GPIO API, would we consider to redesign a bit
> from the above point of view?
> 
> (Read ahead: to be backward compatible and be more friendly for simple
> GPIO IPs it would make sense to leave some of the basic pin properties
> to be controlled from GPIO API, otherwise forget completely about GPIO
> driver, and think of pin control driver for new complex IPs)
> 
> [pin]: might have attached set of functions, set of [electrical] properties.
> It might be re-configured run time in terms of function and configuration.
> It might have none, one, or more owners (this is already an OS abstraction)
> 
> Thus, the core function is pin request, while GPIO request is just a
> particular case.
> Owner of the pin is defined independently on what function or
> configuration is chosen.
> 
> Therefore, we will have something like this (permissions):
> - none (no one can do anything, except acquiring an ownership == requesting 
> pin)
> - exclusive (only one user allowed to cover all properties of the pin)
> - shared (several owners can do modify all or selected properties)
> - shared for all (anyone can do anything, perhaps we don't need this)
> 

It seems nice.

> >> To the point of the specific issue you are trying to solve.  I would
> >> rather agree with Maxime:
> >>
> >> "Something like "if the configuration is a gpio, and my pinctrl driver
> >> is also a gpio controller, and that gpiod_request is being called on
> >> that pin, hand over the reference"
> 
> > Sorry, what do you see behind "hand over the reference"?
> 
> This is similar to what I called before as "shared" ownership. To be
> precise, transformation "exclusive" to "shared".
> 
> >> Just in case of architectural review imagine a below case. We have two
>

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

On Wed, Jan 17, 2018 at 06:07:02PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 17, 2018 at 4:54 PM, Ludovic Desroches
>  wrote:
> > On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote:
> 
> >> First of all, the main architectural issue with current pin control
> >> design is so called "states". It's quite artificial entity which is
> >> not represented by hardware per se.
> >>
> >> Instead we better to provide an API to pin configuration and pin
> >> muxing: I would like to switch to *this* pin function with *this* pin
> >> configuration.
> 
> > gpio_request_enable() allows to switch to the GPIO pin function.
> 
> ...as a particular case of "set this pin to this function".
> 
> > To clarify the situation, from my point of view there are two issues:
> >
> > - Several pin controllers didn't enabled the strict mode when they were
> >   introduced. Nowadays, enabling it will break several DTs. Maybe a DT
> >   property to enable/disable strict mode could do the trick: we remove
> >   pinctrl nodes (so pinmux + pinconf) for pins which will be requested
> >   by gpiod_request() and we set the strict property to true.
> 
> OK.
> 
> > - But... The GPIO pin configuration is missing.
> 
> Here you mixed up the things. Either we are talking about GPIO
> configuration (direction, enabling/disabling I/O buffers), or we are
> talking about pin configuration (bias, drive strength, slew rate,
> debounce, etc.).

I was talking about the pin configuration of the GPIO so about bias,
drive strength, etc.

> 
> >  Some configuration features
> >   have been added, we can continue to add new ones but I am not sure
> >   it's the best solution.
> 
> See below.
> 
> >  At the moment, we rely on a single cell to
> >   manage the configuration. It may not be enough and each time a new pin
> >   configuration will appear, it will have to be added both to the gpiolib
> >   and pinconf.
> 
> >> Second, the pin control and GPIOs are orthogonal as your hardware
> >> confirms. The propagating pin configuration or muxing via GPIO API
> >> looks to me a wrong direction.
> >>
> >
> > I agree but it seems we have started to follow this path.
> 
> Which is still wrong and nothing prevents us to just stop here and
> consider better way.
> 
> The issue is how we historically represent pins inside kernel and how
> hardware evolves at the same time.
> 
> Looking from now retrospectively I can state the following:
> - each GPIO controller *might* have (few) capabilities of pin configuration
> - pin control may not necessary have GPIO function of the pin
> 
> Design is now GPIO oriented while it should be pin oriented.
> 

Agree

> So, instead of littering GPIO API, would we consider to redesign a bit
> from the above point of view?
> 
> (Read ahead: to be backward compatible and be more friendly for simple
> GPIO IPs it would make sense to leave some of the basic pin properties
> to be controlled from GPIO API, otherwise forget completely about GPIO
> driver, and think of pin control driver for new complex IPs)
> 
> [pin]: might have attached set of functions, set of [electrical] properties.
> It might be re-configured run time in terms of function and configuration.
> It might have none, one, or more owners (this is already an OS abstraction)
> 
> Thus, the core function is pin request, while GPIO request is just a
> particular case.
> Owner of the pin is defined independently on what function or
> configuration is chosen.
> 
> Therefore, we will have something like this (permissions):
> - none (no one can do anything, except acquiring an ownership == requesting 
> pin)
> - exclusive (only one user allowed to cover all properties of the pin)
> - shared (several owners can do modify all or selected properties)
> - shared for all (anyone can do anything, perhaps we don't need this)
> 

It seems nice.

> >> To the point of the specific issue you are trying to solve.  I would
> >> rather agree with Maxime:
> >>
> >> "Something like "if the configuration is a gpio, and my pinctrl driver
> >> is also a gpio controller, and that gpiod_request is being called on
> >> that pin, hand over the reference"
> 
> > Sorry, what do you see behind "hand over the reference"?
> 
> This is similar to what I called before as "shared" ownership. To be
> precise, transformation "exclusive" to "shared".
> 
> >> Just in case of architectural review imagine a below case. We have two
> >> UART devices which shar

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 16, 2018 at 11:01 AM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> > On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote:
> >> On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches
> >> <ludovic.desroc...@microchip.com> wrote:
> >>
> >> Did I miss cover letter for this?
> > It seems: https://lkml.org/lkml/2018/1/15/841
> 
> >> > Add a consumer variant to GPIO request relative functions. The goal
> >> > is to fix the bad ownership, which is arbitrary set to
> >> > "range->name:gpio", of a GPIO.
> >>
> >> Hmm... It's supposed to be name of the owner of the pin range (pin
> >> control device name IIUC).
> 
> > Yes, the owner is the pinctrl device.
> 
> > There is an interesting thread here:
> > https://www.spinics.net/lists/linux-gpio/msg16769.html
> 
> Okay, I have dove into all links provided. Below a set of my thoughts
> with regard to topic.
> 
> > If things have changed and I missed it, please tell me. I have seen some
> > improvements but it still don't fit my needs.
> 
> First of all, the main architectural issue with current pin control
> design is so called "states". It's quite artificial entity which is
> not represented by hardware per se.
> 
> Instead we better to provide an API to pin configuration and pin
> muxing: I would like to switch to *this* pin function with *this* pin
> configuration.
> 

gpio_request_enable() allows to switch to the GPIO pin function.

To clarify the situation, from my point of view there are two issues:

- Several pin controllers didn't enabled the strict mode when they were
  introduced. Nowadays, enabling it will break several DTs. Maybe a DT
  property to enable/disable strict mode could do the trick: we remove
  pinctrl nodes (so pinmux + pinconf) for pins which will be requested
  by gpiod_request() and we set the strict property to true.

- But... The GPIO pin configuration is missing. Some configuration features
  have been added, we can continue to add new ones but I am not sure
  it's the best solution. At the moment, we rely on a single cell to
  manage the configuration. It may not be enough and each time a new pin
  configuration will appear, it will have to be added both to the gpiolib
  and pinconf.

> Second, the pin control and GPIOs are orthogonal as your hardware
> confirms. The propagating pin configuration or muxing via GPIO API
> looks to me a wrong direction.
> 

I agree but it seems we have started to follow this path.

> To the point of the specific issue you are trying to solve.  I would
> rather agree with Maxime:
> 
> "Something like "if the configuration is a gpio, and my pinctrl driver
> is also a gpio controller, and that gpiod_request is being called on
> that pin, hand over the reference"
> 

Sorry, what do you see behind "hand over the reference"?

> Just in case of architectural review imagine a below case. We have two
> UART devices which share same pins, and at the same time their pins
> can be switched to GPIO function. So, use cases and questions:
> - allow potential driver to switch between UARTs at run time
> - allow UART driver to switch mode between no flow control (2 wire
> mode) and HW flow (4 wire mode), though not specifically at run time
> - allow GPIO function for some pins at run time to support OOB wake
> up, for example, when UART is a console
> 

I have the feeling that 1 and 2 are achievable with pinctrl states. 3 may be
also acheviable excepting if the pin is part of a pinctrl state.

> More caveats:
> - switching and reconfiguring pins at run time is a bad idea for the
> start (only some exceptions can be applied, see above) because of
> electrical properties of the devices and potential damage to the
> hardware
> - switching to GPIO is allowed at run time for the purpose of OOB wake source
> - after switching to GPIO and freeing it the pin configuration (and
> perhaps muxing) would return back to previous (before GPIO) settings
> (this would be helpful to case described above: OOB wake up)
> 

I share another case which is the one motivating me to do these patches.

I am writing a driver for a new device which uses several lines. The lines used
depends on the firmware loaded so there is no reason to reserve all the
lines and so the pins corresponding to these lines.

The pins will be requested as GPIOs because the pin controller in this specific
case is bypassed. I mean, if the device uses a line, it will take the ownership
even if it is muxed to a function. I want to prevent this.

Before using the line, I'll request the pin as a GPIO. If an error occur

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 16, 2018 at 11:01 AM, Ludovic Desroches
>  wrote:
> > On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote:
> >> On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches
> >>  wrote:
> >>
> >> Did I miss cover letter for this?
> > It seems: https://lkml.org/lkml/2018/1/15/841
> 
> >> > Add a consumer variant to GPIO request relative functions. The goal
> >> > is to fix the bad ownership, which is arbitrary set to
> >> > "range->name:gpio", of a GPIO.
> >>
> >> Hmm... It's supposed to be name of the owner of the pin range (pin
> >> control device name IIUC).
> 
> > Yes, the owner is the pinctrl device.
> 
> > There is an interesting thread here:
> > https://www.spinics.net/lists/linux-gpio/msg16769.html
> 
> Okay, I have dove into all links provided. Below a set of my thoughts
> with regard to topic.
> 
> > If things have changed and I missed it, please tell me. I have seen some
> > improvements but it still don't fit my needs.
> 
> First of all, the main architectural issue with current pin control
> design is so called "states". It's quite artificial entity which is
> not represented by hardware per se.
> 
> Instead we better to provide an API to pin configuration and pin
> muxing: I would like to switch to *this* pin function with *this* pin
> configuration.
> 

gpio_request_enable() allows to switch to the GPIO pin function.

To clarify the situation, from my point of view there are two issues:

- Several pin controllers didn't enabled the strict mode when they were
  introduced. Nowadays, enabling it will break several DTs. Maybe a DT
  property to enable/disable strict mode could do the trick: we remove
  pinctrl nodes (so pinmux + pinconf) for pins which will be requested
  by gpiod_request() and we set the strict property to true.

- But... The GPIO pin configuration is missing. Some configuration features
  have been added, we can continue to add new ones but I am not sure
  it's the best solution. At the moment, we rely on a single cell to
  manage the configuration. It may not be enough and each time a new pin
  configuration will appear, it will have to be added both to the gpiolib
  and pinconf.

> Second, the pin control and GPIOs are orthogonal as your hardware
> confirms. The propagating pin configuration or muxing via GPIO API
> looks to me a wrong direction.
> 

I agree but it seems we have started to follow this path.

> To the point of the specific issue you are trying to solve.  I would
> rather agree with Maxime:
> 
> "Something like "if the configuration is a gpio, and my pinctrl driver
> is also a gpio controller, and that gpiod_request is being called on
> that pin, hand over the reference"
> 

Sorry, what do you see behind "hand over the reference"?

> Just in case of architectural review imagine a below case. We have two
> UART devices which share same pins, and at the same time their pins
> can be switched to GPIO function. So, use cases and questions:
> - allow potential driver to switch between UARTs at run time
> - allow UART driver to switch mode between no flow control (2 wire
> mode) and HW flow (4 wire mode), though not specifically at run time
> - allow GPIO function for some pins at run time to support OOB wake
> up, for example, when UART is a console
> 

I have the feeling that 1 and 2 are achievable with pinctrl states. 3 may be
also acheviable excepting if the pin is part of a pinctrl state.

> More caveats:
> - switching and reconfiguring pins at run time is a bad idea for the
> start (only some exceptions can be applied, see above) because of
> electrical properties of the devices and potential damage to the
> hardware
> - switching to GPIO is allowed at run time for the purpose of OOB wake source
> - after switching to GPIO and freeing it the pin configuration (and
> perhaps muxing) would return back to previous (before GPIO) settings
> (this would be helpful to case described above: OOB wake up)
> 

I share another case which is the one motivating me to do these patches.

I am writing a driver for a new device which uses several lines. The lines used
depends on the firmware loaded so there is no reason to reserve all the
lines and so the pins corresponding to these lines.

The pins will be requested as GPIOs because the pin controller in this specific
case is bypassed. I mean, if the device uses a line, it will take the ownership
even if it is muxed to a function. I want to prevent this.

Before using the line, I'll request the pin as a GPIO. If an error occurs (this
is why I need to enable the strict mode), it means the pin is already muxed and
we are going to break the device which uses it.

> -- 
> With Best Regards,
> Andy Shevchenko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

Hi,

On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches
> <ludovic.desroc...@microchip.com> wrote:
> 
> Did I miss cover letter for this?
> 

It seems: https://lkml.org/lkml/2018/1/15/841

> > Add a consumer variant to GPIO request relative functions. The goal
> > is to fix the bad ownership, which is arbitrary set to
> > "range->name:gpio", of a GPIO.
> 
> Hmm... It's supposed to be name of the owner of the pin range (pin
> control device name IIUC).
>

Yes, the owner is the pinctrl device.

> > There is a lack of configuration features for GPIO. For instance,
> > we can't set the bias. Some pin controllers manage both device's
> > pins and GPIOs. GPIOs can benefit from pin configuration. Usually,
> > a pinctrl node is used to mux the pin as a GPIO and to set up its
> > configuration.
> 
> Don't we have means to do that?
> 

I don't think so. I am not the only one to have this issue for a long
time.

There is an interesting thread here:
https://www.spinics.net/lists/linux-gpio/msg16769.html

If things have changed and I missed it, please tell me. I have seen some
improvements but it still don't fit my needs.

> At least that what I see in aspeed_gpio_set_config().
> 

Yes this is part of the improvements I have seen. The set_config
operation is used at several places in the gpiolib:
- gpio_set_drive_single_ended
- gpiod_set_debounce
- gpiod_set_transitory

It doesn't cover all my needs. In the cover letter, I mentionned that I
based my job on this adding parameters I need. Someone told me it may be
difficult to pul all the parameters in one cell. For instance, the drive
strength is a numeric value using several bits.

I am not sure duplicating the parameters we have for pinconf is the
appropriate solution. Then I prepare a second set of patches to add a
cell with a phandle on the pin configuration. I was going to send it
when I realize that fixing the ownership issue is probably a better
solution. It may involve more code change but less duplication.

> Or I missed a point here?
> 
> > The pinmuxing strict mode involves that a pin which is muxed can't
> > be requested as a GPIO if the owner is not the same.
> 
> Any elaborated example?
> 

More details in the thread I mentionned earlier. I want to enable the
strict mode to prevent weird behavior using the sysfs (or the char
device). Moreover, the strict mode fits the behavior of my pin
controller.

In my DTS, at the moment, if a device needs GPIOs, then I add a pinctrl
node where I put the pinmuxing of the pins as GPIOs and I set the
configuration (for instance, bias pull-up, debounce). If the strict mode
is enabled, when the driver will request the GPIOs, it will fail even if
it's the owner of the pinmuxing.

> > Unfortunately,
> > the ownership of a GPIO is set arbitrarily to "range->name:gpio".
> > So there is a mismatch about the ownership which prevents a device
> > from being the owner of the pinmuxing and requesting the same pin as
> > a GPIO.
> 
> > Adding some consumer variants for GPIO request stuff will allow to
> > pass the name of the device which requests the GPIO to not return an
> > error if it's also the owner of the pinmuxing.
> 
> I think we need something more generic in core than producing more API
> functions.
> 

I didn't want to introduce too many changes to keep it safe and I didn't
want to break current API by adding a parameter.

> But I would like to get problem first.
> 
> > +   if (consumer)
> > +   return pin_request(pctldev, pin, consumer, range);
> > +
> 
> Hmm... My understanding that GPIO is just a (special) function out of
> pin muxing. So, doing musing is essential to get proper function out
> of it.
> 
> Does your hardware considers this differently? If so, I would really
> want to see some datasheets.

No you're right about the behavior of my hardware.

Regards

Ludovic

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

Hi,

On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches
>  wrote:
> 
> Did I miss cover letter for this?
> 

It seems: https://lkml.org/lkml/2018/1/15/841

> > Add a consumer variant to GPIO request relative functions. The goal
> > is to fix the bad ownership, which is arbitrary set to
> > "range->name:gpio", of a GPIO.
> 
> Hmm... It's supposed to be name of the owner of the pin range (pin
> control device name IIUC).
>

Yes, the owner is the pinctrl device.

> > There is a lack of configuration features for GPIO. For instance,
> > we can't set the bias. Some pin controllers manage both device's
> > pins and GPIOs. GPIOs can benefit from pin configuration. Usually,
> > a pinctrl node is used to mux the pin as a GPIO and to set up its
> > configuration.
> 
> Don't we have means to do that?
> 

I don't think so. I am not the only one to have this issue for a long
time.

There is an interesting thread here:
https://www.spinics.net/lists/linux-gpio/msg16769.html

If things have changed and I missed it, please tell me. I have seen some
improvements but it still don't fit my needs.

> At least that what I see in aspeed_gpio_set_config().
> 

Yes this is part of the improvements I have seen. The set_config
operation is used at several places in the gpiolib:
- gpio_set_drive_single_ended
- gpiod_set_debounce
- gpiod_set_transitory

It doesn't cover all my needs. In the cover letter, I mentionned that I
based my job on this adding parameters I need. Someone told me it may be
difficult to pul all the parameters in one cell. For instance, the drive
strength is a numeric value using several bits.

I am not sure duplicating the parameters we have for pinconf is the
appropriate solution. Then I prepare a second set of patches to add a
cell with a phandle on the pin configuration. I was going to send it
when I realize that fixing the ownership issue is probably a better
solution. It may involve more code change but less duplication.

> Or I missed a point here?
> 
> > The pinmuxing strict mode involves that a pin which is muxed can't
> > be requested as a GPIO if the owner is not the same.
> 
> Any elaborated example?
> 

More details in the thread I mentionned earlier. I want to enable the
strict mode to prevent weird behavior using the sysfs (or the char
device). Moreover, the strict mode fits the behavior of my pin
controller.

In my DTS, at the moment, if a device needs GPIOs, then I add a pinctrl
node where I put the pinmuxing of the pins as GPIOs and I set the
configuration (for instance, bias pull-up, debounce). If the strict mode
is enabled, when the driver will request the GPIOs, it will fail even if
it's the owner of the pinmuxing.

> > Unfortunately,
> > the ownership of a GPIO is set arbitrarily to "range->name:gpio".
> > So there is a mismatch about the ownership which prevents a device
> > from being the owner of the pinmuxing and requesting the same pin as
> > a GPIO.
> 
> > Adding some consumer variants for GPIO request stuff will allow to
> > pass the name of the device which requests the GPIO to not return an
> > error if it's also the owner of the pinmuxing.
> 
> I think we need something more generic in core than producing more API
> functions.
> 

I didn't want to introduce too many changes to keep it safe and I didn't
want to break current API by adding a parameter.

> But I would like to get problem first.
> 
> > +   if (consumer)
> > +   return pin_request(pctldev, pin, consumer, range);
> > +
> 
> Hmm... My understanding that GPIO is just a (special) function out of
> pin muxing. So, doing musing is essential to get proper function out
> of it.
> 
> Does your hardware considers this differently? If so, I would really
> want to see some datasheets.

No you're right about the behavior of my hardware.

Regards

Ludovic

[RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

It can be useful for the pinmuxing layer to know which device is
requesting a GPIO. Add a consumer variant for gpiod_request to
reach this goal.

GPIO chips managed by pin controllers should provide the new
request_consumer operation. They can rely on
gpiochip_generic_request_consumer instead of
gpiochip_generic_request.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 drivers/gpio/gpiolib.c  | 40 +---
 include/linux/gpio/driver.h |  5 +
 2 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 39a0144d5be5..e6645101ec74 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1970,6 +1970,20 @@ int gpiochip_generic_request(struct gpio_chip *chip, 
unsigned offset)
 EXPORT_SYMBOL_GPL(gpiochip_generic_request);
 
 /**
+ * gpiochip_generic_request_consumer() - request the gpio function for a pin
+ * @chip: the gpiochip owning the GPIO
+ * @offset: the offset of the GPIO to request for GPIO function
+ * @consumer: name of the device requesting the GPIO
+ */
+int gpiochip_generic_request_consumer(struct gpio_chip *chip, unsigned offset,
+ const char *consumer)
+{
+   return pinctrl_gpio_request_consumer(chip->gpiodev->base + offset,
+consumer);
+}
+EXPORT_SYMBOL_GPL(gpiochip_generic_request_consumer);
+
+/**
  * gpiochip_generic_free() - free the gpio function from a pin
  * @chip: the gpiochip to request the gpio function for
  * @offset: the offset of the GPIO to free from GPIO function
@@ -2119,7 +2133,8 @@ EXPORT_SYMBOL_GPL(gpiochip_remove_pin_ranges);
  * on each other, and help provide better diagnostics in debugfs.
  * They're called even less than the "set direction" calls.
  */
-static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
+static int gpiod_request_commit(struct gpio_desc *desc, const char *label,
+   const char *consumer)
 {
struct gpio_chip*chip = desc->gdev->chip;
int status;
@@ -2139,10 +2154,14 @@ static int gpiod_request_commit(struct gpio_desc *desc, 
const char *label)
goto done;
}
 
-   if (chip->request) {
+   if (chip->request || chip->request_consumer) {
/* chip->request may sleep */
spin_unlock_irqrestore(_lock, flags);
-   status = chip->request(chip, gpio_chip_hwgpio(desc));
+   if (chip->request_consumer)
+   status = chip->request_consumer(chip,
+   gpio_chip_hwgpio(desc), consumer);
+   else
+   status = chip->request(chip, gpio_chip_hwgpio(desc));
spin_lock_irqsave(_lock, flags);
 
if (status < 0) {
@@ -2200,7 +2219,8 @@ static int validate_desc(const struct gpio_desc *desc, 
const char *func)
return; \
} while (0)
 
-int gpiod_request(struct gpio_desc *desc, const char *label)
+int gpiod_request_consumer(struct gpio_desc *desc, const char *label,
+  const char *consumer)
 {
int status = -EPROBE_DEFER;
struct gpio_device *gdev;
@@ -2209,7 +2229,7 @@ int gpiod_request(struct gpio_desc *desc, const char 
*label)
gdev = desc->gdev;
 
if (try_module_get(gdev->owner)) {
-   status = gpiod_request_commit(desc, label);
+   status = gpiod_request_commit(desc, label, consumer);
if (status < 0)
module_put(gdev->owner);
else
@@ -,6 +2242,11 @@ int gpiod_request(struct gpio_desc *desc, const char 
*label)
return status;
 }
 
+int gpiod_request(struct gpio_desc *desc, const char *label)
+{
+   return gpiod_request_consumer(desc, label, NULL);
+}
+
 static bool gpiod_free_commit(struct gpio_desc *desc)
 {
boolret = false;
@@ -2320,7 +2345,7 @@ struct gpio_desc *gpiochip_request_own_desc(struct 
gpio_chip *chip, u16 hwnum,
return desc;
}
 
-   err = gpiod_request_commit(desc, label);
+   err = gpiod_request_commit(desc, label, NULL);
if (err < 0)
return ERR_PTR(err);
 
@@ -3672,7 +3697,8 @@ struct gpio_desc *__must_check gpiod_get_index(struct 
device *dev,
}
 
/* If a connection label was passed use that, else use the device name 
as label */
-   status = gpiod_request(desc, con_id ? con_id : dev_name(dev));
+   status = gpiod_request_consumer(desc, con_id ? con_id : dev_name(dev),
+   dev_name(dev));
if (status < 0)
return ERR_PTR(status);
 
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 1ba9a331ec51..6bc5c57f0cbd 100644
--- 

[RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

It can be useful for the pinmuxing layer to know which device is
requesting a GPIO. Add a consumer variant for gpiod_request to
reach this goal.

GPIO chips managed by pin controllers should provide the new
request_consumer operation. They can rely on
gpiochip_generic_request_consumer instead of
gpiochip_generic_request.

Signed-off-by: Ludovic Desroches 
---
 drivers/gpio/gpiolib.c  | 40 +---
 include/linux/gpio/driver.h |  5 +
 2 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 39a0144d5be5..e6645101ec74 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1970,6 +1970,20 @@ int gpiochip_generic_request(struct gpio_chip *chip, 
unsigned offset)
 EXPORT_SYMBOL_GPL(gpiochip_generic_request);
 
 /**
+ * gpiochip_generic_request_consumer() - request the gpio function for a pin
+ * @chip: the gpiochip owning the GPIO
+ * @offset: the offset of the GPIO to request for GPIO function
+ * @consumer: name of the device requesting the GPIO
+ */
+int gpiochip_generic_request_consumer(struct gpio_chip *chip, unsigned offset,
+ const char *consumer)
+{
+   return pinctrl_gpio_request_consumer(chip->gpiodev->base + offset,
+consumer);
+}
+EXPORT_SYMBOL_GPL(gpiochip_generic_request_consumer);
+
+/**
  * gpiochip_generic_free() - free the gpio function from a pin
  * @chip: the gpiochip to request the gpio function for
  * @offset: the offset of the GPIO to free from GPIO function
@@ -2119,7 +2133,8 @@ EXPORT_SYMBOL_GPL(gpiochip_remove_pin_ranges);
  * on each other, and help provide better diagnostics in debugfs.
  * They're called even less than the "set direction" calls.
  */
-static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
+static int gpiod_request_commit(struct gpio_desc *desc, const char *label,
+   const char *consumer)
 {
struct gpio_chip*chip = desc->gdev->chip;
int status;
@@ -2139,10 +2154,14 @@ static int gpiod_request_commit(struct gpio_desc *desc, 
const char *label)
goto done;
}
 
-   if (chip->request) {
+   if (chip->request || chip->request_consumer) {
/* chip->request may sleep */
spin_unlock_irqrestore(_lock, flags);
-   status = chip->request(chip, gpio_chip_hwgpio(desc));
+   if (chip->request_consumer)
+   status = chip->request_consumer(chip,
+   gpio_chip_hwgpio(desc), consumer);
+   else
+   status = chip->request(chip, gpio_chip_hwgpio(desc));
spin_lock_irqsave(_lock, flags);
 
if (status < 0) {
@@ -2200,7 +2219,8 @@ static int validate_desc(const struct gpio_desc *desc, 
const char *func)
return; \
} while (0)
 
-int gpiod_request(struct gpio_desc *desc, const char *label)
+int gpiod_request_consumer(struct gpio_desc *desc, const char *label,
+  const char *consumer)
 {
int status = -EPROBE_DEFER;
struct gpio_device *gdev;
@@ -2209,7 +2229,7 @@ int gpiod_request(struct gpio_desc *desc, const char 
*label)
gdev = desc->gdev;
 
if (try_module_get(gdev->owner)) {
-   status = gpiod_request_commit(desc, label);
+   status = gpiod_request_commit(desc, label, consumer);
if (status < 0)
module_put(gdev->owner);
else
@@ -,6 +2242,11 @@ int gpiod_request(struct gpio_desc *desc, const char 
*label)
return status;
 }
 
+int gpiod_request(struct gpio_desc *desc, const char *label)
+{
+   return gpiod_request_consumer(desc, label, NULL);
+}
+
 static bool gpiod_free_commit(struct gpio_desc *desc)
 {
boolret = false;
@@ -2320,7 +2345,7 @@ struct gpio_desc *gpiochip_request_own_desc(struct 
gpio_chip *chip, u16 hwnum,
return desc;
}
 
-   err = gpiod_request_commit(desc, label);
+   err = gpiod_request_commit(desc, label, NULL);
if (err < 0)
return ERR_PTR(err);
 
@@ -3672,7 +3697,8 @@ struct gpio_desc *__must_check gpiod_get_index(struct 
device *dev,
}
 
/* If a connection label was passed use that, else use the device name 
as label */
-   status = gpiod_request(desc, con_id ? con_id : dev_name(dev));
+   status = gpiod_request_consumer(desc, con_id ? con_id : dev_name(dev),
+   dev_name(dev));
if (status < 0)
return ERR_PTR(status);
 
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 1ba9a331ec51..6bc5c57f0cbd 100644
--- a/include/linux/gpio/driver.h
+++

[RESEND RFC PATCH 0/2] fixing the gpio ownership

[Ludovic Desroches]

RESEND: fix typo in email address.

Hi,

A few weeks ago, I have sent an RFC about adding bias support for GPIOs [1].

It was motivated by the fact that I wanted to enable the pinmuxing strict mode
for my pin controller which can muxed a pin as a peripheral or as a GPIO.

Enabling the strict mode prevents several devices to be probed because
requesting a GPIO fails. The pin request function complains about the
ownership of the GPIO which is different from the mux ownership. I have to
remove my pinctrl node to avoid this conflict but I need it to configure my
pins and to set a pull-up bias for my GPIOs.

My first idea was to add new flags in addition to GPIO_ACTIVE_HIGH and others.
Obviously, it was not the way to go since many new flags may be added:
strength, debounce, etc.

Then I proposed a very "quick and dirty" patch to give the picture of what I
have in mind but I had no feedback. It was probably too dirty. The idea was
to add a cell to the gpios property with a phandle on a pinctrl node which
contains only the pinconf, no pinmux. The configuration is applied later when
requesting the GPIO. The main issue is that enabling the strict mode will
break old DTBs. I was going to submit patches for this but, after using the
sysfs which still show me a bad ownership, I decided that it should be fixed.

So I did these patches. Unfortunately, there are several ways to lead to
gpiod_request(). It does the trick only for the gpiod_get family. The issue is
still present with legacy gpio_request and fwnode_get_named_gpiod. It seems
that more and more drivers are converted to use GPIO descriptors so there is
some hope. The advantage of this solution is to not break old DTBs. As I am
not aware of all usage of the gpiolib, I tried to implement it in the safest
way.

Regards

Ludovic

[1] https://www.spinics.net/lists/arm-kernel/msg623149.html


Ludovic Desroches (2):
  pinctrl: add consumer variant for gpio request
  gpio: provide a consumer when requesting a gpio

 drivers/gpio/gpiolib.c   | 40 +---
 drivers/pinctrl/core.c   | 13 ++---
 drivers/pinctrl/pinmux.c | 16 ++--
 drivers/pinctrl/pinmux.h | 10 ++
 include/linux/gpio/driver.h  |  5 +
 include/linux/pinctrl/consumer.h |  6 ++
 6 files changed, 78 insertions(+), 12 deletions(-)

-- 
2.12.2

[RESEND RFC PATCH 0/2] fixing the gpio ownership

[Ludovic Desroches]

RESEND: fix typo in email address.

Hi,

A few weeks ago, I have sent an RFC about adding bias support for GPIOs [1].

It was motivated by the fact that I wanted to enable the pinmuxing strict mode
for my pin controller which can muxed a pin as a peripheral or as a GPIO.

Enabling the strict mode prevents several devices to be probed because
requesting a GPIO fails. The pin request function complains about the
ownership of the GPIO which is different from the mux ownership. I have to
remove my pinctrl node to avoid this conflict but I need it to configure my
pins and to set a pull-up bias for my GPIOs.

My first idea was to add new flags in addition to GPIO_ACTIVE_HIGH and others.
Obviously, it was not the way to go since many new flags may be added:
strength, debounce, etc.

Then I proposed a very "quick and dirty" patch to give the picture of what I
have in mind but I had no feedback. It was probably too dirty. The idea was
to add a cell to the gpios property with a phandle on a pinctrl node which
contains only the pinconf, no pinmux. The configuration is applied later when
requesting the GPIO. The main issue is that enabling the strict mode will
break old DTBs. I was going to submit patches for this but, after using the
sysfs which still show me a bad ownership, I decided that it should be fixed.

So I did these patches. Unfortunately, there are several ways to lead to
gpiod_request(). It does the trick only for the gpiod_get family. The issue is
still present with legacy gpio_request and fwnode_get_named_gpiod. It seems
that more and more drivers are converted to use GPIO descriptors so there is
some hope. The advantage of this solution is to not break old DTBs. As I am
not aware of all usage of the gpiolib, I tried to implement it in the safest
way.

Regards

Ludovic

[1] https://www.spinics.net/lists/arm-kernel/msg623149.html


Ludovic Desroches (2):
  pinctrl: add consumer variant for gpio request
  gpio: provide a consumer when requesting a gpio

 drivers/gpio/gpiolib.c   | 40 +---
 drivers/pinctrl/core.c   | 13 ++---
 drivers/pinctrl/pinmux.c | 16 ++--
 drivers/pinctrl/pinmux.h | 10 ++
 include/linux/gpio/driver.h  |  5 +
 include/linux/pinctrl/consumer.h |  6 ++
 6 files changed, 78 insertions(+), 12 deletions(-)

-- 
2.12.2

[RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

Add a consumer variant to GPIO request relative functions. The goal
is to fix the bad ownership, which is arbitrary set to
"range->name:gpio", of a GPIO.

There is a lack of configuration features for GPIO. For instance,
we can't set the bias. Some pin controllers manage both device's
pins and GPIOs. GPIOs can benefit from pin configuration. Usually,
a pinctrl node is used to mux the pin as a GPIO and to set up its
configuration.

The pinmuxing strict mode involves that a pin which is muxed can't
be requested as a GPIO if the owner is not the same. Unfortunately,
the ownership of a GPIO is set arbitrarily to "range->name:gpio".
So there is a mismatch about the ownership which prevents a device
from being the owner of the pinmuxing and requesting the same pin as
a GPIO.

Adding some consumer variants for GPIO request stuff will allow to
pass the name of the device which requests the GPIO to not return an
error if it's also the owner of the pinmuxing.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 drivers/pinctrl/core.c   | 13 ++---
 drivers/pinctrl/pinmux.c | 16 ++--
 drivers/pinctrl/pinmux.h | 10 ++
 include/linux/pinctrl/consumer.h |  6 ++
 4 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 2c0dbfcff3e6..51c75a6057b2 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -733,14 +733,15 @@ int pinctrl_get_group_selector(struct pinctrl_dev 
*pctldev,
 }
 
 /**
- * pinctrl_gpio_request() - request a single pin to be used as GPIO
+ * pinctrl_gpio_request_consumer() - request a single pin to be used as GPIO
  * @gpio: the GPIO pin number from the GPIO subsystem number space
+ * @consumer: the name of the device requesting the GPIO
  *
  * This function should *ONLY* be used from gpiolib-based GPIO drivers,
  * as part of their gpio_request() semantics, platforms and individual drivers
  * shall *NOT* request GPIO pins to be muxed in.
  */
-int pinctrl_gpio_request(unsigned gpio)
+int pinctrl_gpio_request_consumer(unsigned gpio, const char *consumer)
 {
struct pinctrl_dev *pctldev;
struct pinctrl_gpio_range *range;
@@ -759,12 +760,18 @@ int pinctrl_gpio_request(unsigned gpio)
/* Convert to the pin controllers number space */
pin = gpio_to_pin(range, gpio);
 
-   ret = pinmux_request_gpio(pctldev, range, pin, gpio);
+   ret = pinmux_request_gpio_consumer(pctldev, range, pin, gpio, consumer);
 
mutex_unlock(>mutex);
 
return ret;
 }
+EXPORT_SYMBOL_GPL(pinctrl_gpio_request_consumer);
+
+int pinctrl_gpio_request(unsigned gpio)
+{
+   return pinctrl_gpio_request_consumer(gpio, NULL);
+}
 EXPORT_SYMBOL_GPL(pinctrl_gpio_request);
 
 /**
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 55502fc4479c..8d422eb0ed38 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -232,14 +232,19 @@ static const char *pin_free(struct pinctrl_dev *pctldev, 
int pin,
  * @pctldev: pin controller device affected
  * @pin: the pin to mux in for GPIO
  * @range: the applicable GPIO range
+ * @consumer: the name of the device requesting the GPIO
  */
-int pinmux_request_gpio(struct pinctrl_dev *pctldev,
+int pinmux_request_gpio_consumer(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
-   unsigned pin, unsigned gpio)
+   unsigned pin, unsigned gpio,
+   const char *consumer)
 {
const char *owner;
int ret;
 
+   if (consumer)
+   return pin_request(pctldev, pin, consumer, range);
+
/* Conjure some name stating what chip and pin this is taken by */
owner = kasprintf(GFP_KERNEL, "%s:%d", range->name, gpio);
if (!owner)
@@ -252,6 +257,13 @@ int pinmux_request_gpio(struct pinctrl_dev *pctldev,
return ret;
 }
 
+int pinmux_request_gpio(struct pinctrl_dev *pctldev,
+   struct pinctrl_gpio_range *range,
+   unsigned pin, unsigned gpio)
+{
+   return pinmux_request_gpio_consumer(pctldev, range, pin, gpio, NULL);
+}
+
 /**
  * pinmux_free_gpio() - release a pin from GPIO muxing
  * @pctldev: the pin controller device for the pin
diff --git a/drivers/pinctrl/pinmux.h b/drivers/pinctrl/pinmux.h
index a331fcdbedd9..837599922a42 100644
--- a/drivers/pinctrl/pinmux.h
+++ b/drivers/pinctrl/pinmux.h
@@ -19,6 +19,9 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i);
 int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio);
+int pinmux_request_gpio_consumer(struct pinctrl_dev *pctldev,
+   struct pinctrl_gpio_range *range,
+   unsigned pin, unsigned gpio, const char *consumer);
 void pinmux

[RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

Add a consumer variant to GPIO request relative functions. The goal
is to fix the bad ownership, which is arbitrary set to
"range->name:gpio", of a GPIO.

There is a lack of configuration features for GPIO. For instance,
we can't set the bias. Some pin controllers manage both device's
pins and GPIOs. GPIOs can benefit from pin configuration. Usually,
a pinctrl node is used to mux the pin as a GPIO and to set up its
configuration.

The pinmuxing strict mode involves that a pin which is muxed can't
be requested as a GPIO if the owner is not the same. Unfortunately,
the ownership of a GPIO is set arbitrarily to "range->name:gpio".
So there is a mismatch about the ownership which prevents a device
from being the owner of the pinmuxing and requesting the same pin as
a GPIO.

Adding some consumer variants for GPIO request stuff will allow to
pass the name of the device which requests the GPIO to not return an
error if it's also the owner of the pinmuxing.

Signed-off-by: Ludovic Desroches 
---
 drivers/pinctrl/core.c   | 13 ++---
 drivers/pinctrl/pinmux.c | 16 ++--
 drivers/pinctrl/pinmux.h | 10 ++
 include/linux/pinctrl/consumer.h |  6 ++
 4 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 2c0dbfcff3e6..51c75a6057b2 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -733,14 +733,15 @@ int pinctrl_get_group_selector(struct pinctrl_dev 
*pctldev,
 }
 
 /**
- * pinctrl_gpio_request() - request a single pin to be used as GPIO
+ * pinctrl_gpio_request_consumer() - request a single pin to be used as GPIO
  * @gpio: the GPIO pin number from the GPIO subsystem number space
+ * @consumer: the name of the device requesting the GPIO
  *
  * This function should *ONLY* be used from gpiolib-based GPIO drivers,
  * as part of their gpio_request() semantics, platforms and individual drivers
  * shall *NOT* request GPIO pins to be muxed in.
  */
-int pinctrl_gpio_request(unsigned gpio)
+int pinctrl_gpio_request_consumer(unsigned gpio, const char *consumer)
 {
struct pinctrl_dev *pctldev;
struct pinctrl_gpio_range *range;
@@ -759,12 +760,18 @@ int pinctrl_gpio_request(unsigned gpio)
/* Convert to the pin controllers number space */
pin = gpio_to_pin(range, gpio);
 
-   ret = pinmux_request_gpio(pctldev, range, pin, gpio);
+   ret = pinmux_request_gpio_consumer(pctldev, range, pin, gpio, consumer);
 
mutex_unlock(>mutex);
 
return ret;
 }
+EXPORT_SYMBOL_GPL(pinctrl_gpio_request_consumer);
+
+int pinctrl_gpio_request(unsigned gpio)
+{
+   return pinctrl_gpio_request_consumer(gpio, NULL);
+}
 EXPORT_SYMBOL_GPL(pinctrl_gpio_request);
 
 /**
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 55502fc4479c..8d422eb0ed38 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -232,14 +232,19 @@ static const char *pin_free(struct pinctrl_dev *pctldev, 
int pin,
  * @pctldev: pin controller device affected
  * @pin: the pin to mux in for GPIO
  * @range: the applicable GPIO range
+ * @consumer: the name of the device requesting the GPIO
  */
-int pinmux_request_gpio(struct pinctrl_dev *pctldev,
+int pinmux_request_gpio_consumer(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
-   unsigned pin, unsigned gpio)
+   unsigned pin, unsigned gpio,
+   const char *consumer)
 {
const char *owner;
int ret;
 
+   if (consumer)
+   return pin_request(pctldev, pin, consumer, range);
+
/* Conjure some name stating what chip and pin this is taken by */
owner = kasprintf(GFP_KERNEL, "%s:%d", range->name, gpio);
if (!owner)
@@ -252,6 +257,13 @@ int pinmux_request_gpio(struct pinctrl_dev *pctldev,
return ret;
 }
 
+int pinmux_request_gpio(struct pinctrl_dev *pctldev,
+   struct pinctrl_gpio_range *range,
+   unsigned pin, unsigned gpio)
+{
+   return pinmux_request_gpio_consumer(pctldev, range, pin, gpio, NULL);
+}
+
 /**
  * pinmux_free_gpio() - release a pin from GPIO muxing
  * @pctldev: the pin controller device for the pin
diff --git a/drivers/pinctrl/pinmux.h b/drivers/pinctrl/pinmux.h
index a331fcdbedd9..837599922a42 100644
--- a/drivers/pinctrl/pinmux.h
+++ b/drivers/pinctrl/pinmux.h
@@ -19,6 +19,9 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i);
 int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio);
+int pinmux_request_gpio_consumer(struct pinctrl_dev *pctldev,
+   struct pinctrl_gpio_range *range,
+   unsigned pin, unsigned gpio, const char *consumer);
 void pinmux_free_gpio(struct pinctrl_dev *pctldev, 

[RFC PATCH 0/2] fixing the gpio ownership

[Ludovic Desroches]

Hi,

A few weeks ago, I have sent an RFC about adding bias support for GPIOs [1].

It was motivated by the fact that I wanted to enable the pinmuxing strict mode
for my pin controller which can muxed a pin as a peripheral or as a GPIO.

Enabling the strict mode prevents several devices to be probed because
requesting a GPIO fails. The pin request function complains about the
ownership of the GPIO which is different from the mux ownership. I have to
remove my pinctrl node to avoid this conflict but I need it to configure my
pins and to set a pull-up bias for my GPIOs.

My first idea was to add new flags in addition to GPIO_ACTIVE_HIGH and others.
Obviously, it was not the way to go since many new flags may be added:
strength, debounce, etc.

Then I proposed a very "quick and dirty" patch to give the picture of what I
have in mind but I had no feedback. It was probably too dirty. The idea was
to add a cell to the gpios property with a phandle on a pinctrl node which
contains only the pinconf, no pinmux. The configuration is applied later when
requesting the GPIO. The main issue is that enabling the strict mode will
break old DTBs. I was going to submit patches for this but, after using the
sysfs which still show me a bad ownership, I decided that it should be fixed.

So I did these patches. Unfortunately, there are several ways to lead to
gpiod_request(). It does the trick only for the gpiod_get family. The issue is
still present with legacy gpio_request and fwnode_get_named_gpiod. It seems
that more and more drivers are converted to use GPIO descriptors so there is
some hope. The advantage of this solution is to not break old DTBs. As I am
not aware of all usage of the gpiolib, I tried to implement it in the safest
way.

Regards

Ludovic

[1] https://www.spinics.net/lists/arm-kernel/msg623149.html


Ludovic Desroches (2):
  pinctrl: add consumer variant for gpio request
  gpio: provide a consumer when requesting a gpio

 drivers/gpio/gpiolib.c   | 40 +---
 drivers/pinctrl/core.c   | 13 ++---
 drivers/pinctrl/pinmux.c | 16 ++--
 drivers/pinctrl/pinmux.h | 10 ++
 include/linux/gpio/driver.h  |  5 +
 include/linux/pinctrl/consumer.h |  6 ++
 6 files changed, 78 insertions(+), 12 deletions(-)

-- 
2.12.2

[RFC PATCH 0/2] fixing the gpio ownership

[Ludovic Desroches]

Hi,

A few weeks ago, I have sent an RFC about adding bias support for GPIOs [1].

It was motivated by the fact that I wanted to enable the pinmuxing strict mode
for my pin controller which can muxed a pin as a peripheral or as a GPIO.

Enabling the strict mode prevents several devices to be probed because
requesting a GPIO fails. The pin request function complains about the
ownership of the GPIO which is different from the mux ownership. I have to
remove my pinctrl node to avoid this conflict but I need it to configure my
pins and to set a pull-up bias for my GPIOs.

My first idea was to add new flags in addition to GPIO_ACTIVE_HIGH and others.
Obviously, it was not the way to go since many new flags may be added:
strength, debounce, etc.

Then I proposed a very "quick and dirty" patch to give the picture of what I
have in mind but I had no feedback. It was probably too dirty. The idea was
to add a cell to the gpios property with a phandle on a pinctrl node which
contains only the pinconf, no pinmux. The configuration is applied later when
requesting the GPIO. The main issue is that enabling the strict mode will
break old DTBs. I was going to submit patches for this but, after using the
sysfs which still show me a bad ownership, I decided that it should be fixed.

So I did these patches. Unfortunately, there are several ways to lead to
gpiod_request(). It does the trick only for the gpiod_get family. The issue is
still present with legacy gpio_request and fwnode_get_named_gpiod. It seems
that more and more drivers are converted to use GPIO descriptors so there is
some hope. The advantage of this solution is to not break old DTBs. As I am
not aware of all usage of the gpiolib, I tried to implement it in the safest
way.

Regards

Ludovic

[1] https://www.spinics.net/lists/arm-kernel/msg623149.html


Ludovic Desroches (2):
  pinctrl: add consumer variant for gpio request
  gpio: provide a consumer when requesting a gpio

 drivers/gpio/gpiolib.c   | 40 +---
 drivers/pinctrl/core.c   | 13 ++---
 drivers/pinctrl/pinmux.c | 16 ++--
 drivers/pinctrl/pinmux.h | 10 ++
 include/linux/gpio/driver.h  |  5 +
 include/linux/pinctrl/consumer.h |  6 ++
 6 files changed, 78 insertions(+), 12 deletions(-)

-- 
2.12.2

[RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

It can be useful for the pinmuxing layer to know which device is
requesting a GPIO. Add a consumer variant for gpiod_request to
reach this goal.

GPIO chips managed by pin controllers should provide the new
request_consumer operation. They can rely on
gpiochip_generic_request_consumer instead of
gpiochip_generic_request.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 drivers/gpio/gpiolib.c  | 40 +---
 include/linux/gpio/driver.h |  5 +
 2 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 39a0144d5be5..e6645101ec74 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1970,6 +1970,20 @@ int gpiochip_generic_request(struct gpio_chip *chip, 
unsigned offset)
 EXPORT_SYMBOL_GPL(gpiochip_generic_request);
 
 /**
+ * gpiochip_generic_request_consumer() - request the gpio function for a pin
+ * @chip: the gpiochip owning the GPIO
+ * @offset: the offset of the GPIO to request for GPIO function
+ * @consumer: name of the device requesting the GPIO
+ */
+int gpiochip_generic_request_consumer(struct gpio_chip *chip, unsigned offset,
+ const char *consumer)
+{
+   return pinctrl_gpio_request_consumer(chip->gpiodev->base + offset,
+consumer);
+}
+EXPORT_SYMBOL_GPL(gpiochip_generic_request_consumer);
+
+/**
  * gpiochip_generic_free() - free the gpio function from a pin
  * @chip: the gpiochip to request the gpio function for
  * @offset: the offset of the GPIO to free from GPIO function
@@ -2119,7 +2133,8 @@ EXPORT_SYMBOL_GPL(gpiochip_remove_pin_ranges);
  * on each other, and help provide better diagnostics in debugfs.
  * They're called even less than the "set direction" calls.
  */
-static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
+static int gpiod_request_commit(struct gpio_desc *desc, const char *label,
+   const char *consumer)
 {
struct gpio_chip*chip = desc->gdev->chip;
int status;
@@ -2139,10 +2154,14 @@ static int gpiod_request_commit(struct gpio_desc *desc, 
const char *label)
goto done;
}
 
-   if (chip->request) {
+   if (chip->request || chip->request_consumer) {
/* chip->request may sleep */
spin_unlock_irqrestore(_lock, flags);
-   status = chip->request(chip, gpio_chip_hwgpio(desc));
+   if (chip->request_consumer)
+   status = chip->request_consumer(chip,
+   gpio_chip_hwgpio(desc), consumer);
+   else
+   status = chip->request(chip, gpio_chip_hwgpio(desc));
spin_lock_irqsave(_lock, flags);
 
if (status < 0) {
@@ -2200,7 +2219,8 @@ static int validate_desc(const struct gpio_desc *desc, 
const char *func)
return; \
} while (0)
 
-int gpiod_request(struct gpio_desc *desc, const char *label)
+int gpiod_request_consumer(struct gpio_desc *desc, const char *label,
+  const char *consumer)
 {
int status = -EPROBE_DEFER;
struct gpio_device *gdev;
@@ -2209,7 +2229,7 @@ int gpiod_request(struct gpio_desc *desc, const char 
*label)
gdev = desc->gdev;
 
if (try_module_get(gdev->owner)) {
-   status = gpiod_request_commit(desc, label);
+   status = gpiod_request_commit(desc, label, consumer);
if (status < 0)
module_put(gdev->owner);
else
@@ -,6 +2242,11 @@ int gpiod_request(struct gpio_desc *desc, const char 
*label)
return status;
 }
 
+int gpiod_request(struct gpio_desc *desc, const char *label)
+{
+   return gpiod_request_consumer(desc, label, NULL);
+}
+
 static bool gpiod_free_commit(struct gpio_desc *desc)
 {
boolret = false;
@@ -2320,7 +2345,7 @@ struct gpio_desc *gpiochip_request_own_desc(struct 
gpio_chip *chip, u16 hwnum,
return desc;
}
 
-   err = gpiod_request_commit(desc, label);
+   err = gpiod_request_commit(desc, label, NULL);
if (err < 0)
return ERR_PTR(err);
 
@@ -3672,7 +3697,8 @@ struct gpio_desc *__must_check gpiod_get_index(struct 
device *dev,
}
 
/* If a connection label was passed use that, else use the device name 
as label */
-   status = gpiod_request(desc, con_id ? con_id : dev_name(dev));
+   status = gpiod_request_consumer(desc, con_id ? con_id : dev_name(dev),
+   dev_name(dev));
if (status < 0)
return ERR_PTR(status);
 
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 1ba9a331ec51..6bc5c57f0cbd 100644
--- 

[RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

[Ludovic Desroches]

It can be useful for the pinmuxing layer to know which device is
requesting a GPIO. Add a consumer variant for gpiod_request to
reach this goal.

GPIO chips managed by pin controllers should provide the new
request_consumer operation. They can rely on
gpiochip_generic_request_consumer instead of
gpiochip_generic_request.

Signed-off-by: Ludovic Desroches 
---
 drivers/gpio/gpiolib.c  | 40 +---
 include/linux/gpio/driver.h |  5 +
 2 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 39a0144d5be5..e6645101ec74 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1970,6 +1970,20 @@ int gpiochip_generic_request(struct gpio_chip *chip, 
unsigned offset)
 EXPORT_SYMBOL_GPL(gpiochip_generic_request);
 
 /**
+ * gpiochip_generic_request_consumer() - request the gpio function for a pin
+ * @chip: the gpiochip owning the GPIO
+ * @offset: the offset of the GPIO to request for GPIO function
+ * @consumer: name of the device requesting the GPIO
+ */
+int gpiochip_generic_request_consumer(struct gpio_chip *chip, unsigned offset,
+ const char *consumer)
+{
+   return pinctrl_gpio_request_consumer(chip->gpiodev->base + offset,
+consumer);
+}
+EXPORT_SYMBOL_GPL(gpiochip_generic_request_consumer);
+
+/**
  * gpiochip_generic_free() - free the gpio function from a pin
  * @chip: the gpiochip to request the gpio function for
  * @offset: the offset of the GPIO to free from GPIO function
@@ -2119,7 +2133,8 @@ EXPORT_SYMBOL_GPL(gpiochip_remove_pin_ranges);
  * on each other, and help provide better diagnostics in debugfs.
  * They're called even less than the "set direction" calls.
  */
-static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
+static int gpiod_request_commit(struct gpio_desc *desc, const char *label,
+   const char *consumer)
 {
struct gpio_chip*chip = desc->gdev->chip;
int status;
@@ -2139,10 +2154,14 @@ static int gpiod_request_commit(struct gpio_desc *desc, 
const char *label)
goto done;
}
 
-   if (chip->request) {
+   if (chip->request || chip->request_consumer) {
/* chip->request may sleep */
spin_unlock_irqrestore(_lock, flags);
-   status = chip->request(chip, gpio_chip_hwgpio(desc));
+   if (chip->request_consumer)
+   status = chip->request_consumer(chip,
+   gpio_chip_hwgpio(desc), consumer);
+   else
+   status = chip->request(chip, gpio_chip_hwgpio(desc));
spin_lock_irqsave(_lock, flags);
 
if (status < 0) {
@@ -2200,7 +2219,8 @@ static int validate_desc(const struct gpio_desc *desc, 
const char *func)
return; \
} while (0)
 
-int gpiod_request(struct gpio_desc *desc, const char *label)
+int gpiod_request_consumer(struct gpio_desc *desc, const char *label,
+  const char *consumer)
 {
int status = -EPROBE_DEFER;
struct gpio_device *gdev;
@@ -2209,7 +2229,7 @@ int gpiod_request(struct gpio_desc *desc, const char 
*label)
gdev = desc->gdev;
 
if (try_module_get(gdev->owner)) {
-   status = gpiod_request_commit(desc, label);
+   status = gpiod_request_commit(desc, label, consumer);
if (status < 0)
module_put(gdev->owner);
else
@@ -,6 +2242,11 @@ int gpiod_request(struct gpio_desc *desc, const char 
*label)
return status;
 }
 
+int gpiod_request(struct gpio_desc *desc, const char *label)
+{
+   return gpiod_request_consumer(desc, label, NULL);
+}
+
 static bool gpiod_free_commit(struct gpio_desc *desc)
 {
boolret = false;
@@ -2320,7 +2345,7 @@ struct gpio_desc *gpiochip_request_own_desc(struct 
gpio_chip *chip, u16 hwnum,
return desc;
}
 
-   err = gpiod_request_commit(desc, label);
+   err = gpiod_request_commit(desc, label, NULL);
if (err < 0)
return ERR_PTR(err);
 
@@ -3672,7 +3697,8 @@ struct gpio_desc *__must_check gpiod_get_index(struct 
device *dev,
}
 
/* If a connection label was passed use that, else use the device name 
as label */
-   status = gpiod_request(desc, con_id ? con_id : dev_name(dev));
+   status = gpiod_request_consumer(desc, con_id ? con_id : dev_name(dev),
+   dev_name(dev));
if (status < 0)
return ERR_PTR(status);
 
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 1ba9a331ec51..6bc5c57f0cbd 100644
--- a/include/linux/gpio/driver.h
+++

[RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

Add a consumer variant to GPIO request relative functions. The goal
is to fix the bad ownership, which is arbitrary set to
"range->name:gpio", of a GPIO.

There is a lack of configuration features for GPIO. For instance,
we can't set the bias. Some pin controllers manage both device's
pins and GPIOs. GPIOs can benefit from pin configuration. Usually,
a pinctrl node is used to mux the pin as a GPIO and to set up its
configuration.

The pinmuxing strict mode involves that a pin which is muxed can't
be requested as a GPIO if the owner is not the same. Unfortunately,
the ownership of a GPIO is set arbitrarily to "range->name:gpio".
So there is a mismatch about the ownership which prevents a device
from being the owner of the pinmuxing and requesting the same pin as
a GPIO.

Adding some consumer variants for GPIO request stuff will allow to
pass the name of the device which requests the GPIO to not return an
error if it's also the owner of the pinmuxing.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 drivers/pinctrl/core.c   | 13 ++---
 drivers/pinctrl/pinmux.c | 16 ++--
 drivers/pinctrl/pinmux.h | 10 ++
 include/linux/pinctrl/consumer.h |  6 ++
 4 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 2c0dbfcff3e6..51c75a6057b2 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -733,14 +733,15 @@ int pinctrl_get_group_selector(struct pinctrl_dev 
*pctldev,
 }
 
 /**
- * pinctrl_gpio_request() - request a single pin to be used as GPIO
+ * pinctrl_gpio_request_consumer() - request a single pin to be used as GPIO
  * @gpio: the GPIO pin number from the GPIO subsystem number space
+ * @consumer: the name of the device requesting the GPIO
  *
  * This function should *ONLY* be used from gpiolib-based GPIO drivers,
  * as part of their gpio_request() semantics, platforms and individual drivers
  * shall *NOT* request GPIO pins to be muxed in.
  */
-int pinctrl_gpio_request(unsigned gpio)
+int pinctrl_gpio_request_consumer(unsigned gpio, const char *consumer)
 {
struct pinctrl_dev *pctldev;
struct pinctrl_gpio_range *range;
@@ -759,12 +760,18 @@ int pinctrl_gpio_request(unsigned gpio)
/* Convert to the pin controllers number space */
pin = gpio_to_pin(range, gpio);
 
-   ret = pinmux_request_gpio(pctldev, range, pin, gpio);
+   ret = pinmux_request_gpio_consumer(pctldev, range, pin, gpio, consumer);
 
mutex_unlock(>mutex);
 
return ret;
 }
+EXPORT_SYMBOL_GPL(pinctrl_gpio_request_consumer);
+
+int pinctrl_gpio_request(unsigned gpio)
+{
+   return pinctrl_gpio_request_consumer(gpio, NULL);
+}
 EXPORT_SYMBOL_GPL(pinctrl_gpio_request);
 
 /**
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 55502fc4479c..8d422eb0ed38 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -232,14 +232,19 @@ static const char *pin_free(struct pinctrl_dev *pctldev, 
int pin,
  * @pctldev: pin controller device affected
  * @pin: the pin to mux in for GPIO
  * @range: the applicable GPIO range
+ * @consumer: the name of the device requesting the GPIO
  */
-int pinmux_request_gpio(struct pinctrl_dev *pctldev,
+int pinmux_request_gpio_consumer(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
-   unsigned pin, unsigned gpio)
+   unsigned pin, unsigned gpio,
+   const char *consumer)
 {
const char *owner;
int ret;
 
+   if (consumer)
+   return pin_request(pctldev, pin, consumer, range);
+
/* Conjure some name stating what chip and pin this is taken by */
owner = kasprintf(GFP_KERNEL, "%s:%d", range->name, gpio);
if (!owner)
@@ -252,6 +257,13 @@ int pinmux_request_gpio(struct pinctrl_dev *pctldev,
return ret;
 }
 
+int pinmux_request_gpio(struct pinctrl_dev *pctldev,
+   struct pinctrl_gpio_range *range,
+   unsigned pin, unsigned gpio)
+{
+   return pinmux_request_gpio_consumer(pctldev, range, pin, gpio, NULL);
+}
+
 /**
  * pinmux_free_gpio() - release a pin from GPIO muxing
  * @pctldev: the pin controller device for the pin
diff --git a/drivers/pinctrl/pinmux.h b/drivers/pinctrl/pinmux.h
index a331fcdbedd9..837599922a42 100644
--- a/drivers/pinctrl/pinmux.h
+++ b/drivers/pinctrl/pinmux.h
@@ -19,6 +19,9 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i);
 int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio);
+int pinmux_request_gpio_consumer(struct pinctrl_dev *pctldev,
+   struct pinctrl_gpio_range *range,
+   unsigned pin, unsigned gpio, const char *consumer);
 void pinmux

[RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

[Ludovic Desroches]

Add a consumer variant to GPIO request relative functions. The goal
is to fix the bad ownership, which is arbitrary set to
"range->name:gpio", of a GPIO.

There is a lack of configuration features for GPIO. For instance,
we can't set the bias. Some pin controllers manage both device's
pins and GPIOs. GPIOs can benefit from pin configuration. Usually,
a pinctrl node is used to mux the pin as a GPIO and to set up its
configuration.

The pinmuxing strict mode involves that a pin which is muxed can't
be requested as a GPIO if the owner is not the same. Unfortunately,
the ownership of a GPIO is set arbitrarily to "range->name:gpio".
So there is a mismatch about the ownership which prevents a device
from being the owner of the pinmuxing and requesting the same pin as
a GPIO.

Adding some consumer variants for GPIO request stuff will allow to
pass the name of the device which requests the GPIO to not return an
error if it's also the owner of the pinmuxing.

Signed-off-by: Ludovic Desroches 
---
 drivers/pinctrl/core.c   | 13 ++---
 drivers/pinctrl/pinmux.c | 16 ++--
 drivers/pinctrl/pinmux.h | 10 ++
 include/linux/pinctrl/consumer.h |  6 ++
 4 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 2c0dbfcff3e6..51c75a6057b2 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -733,14 +733,15 @@ int pinctrl_get_group_selector(struct pinctrl_dev 
*pctldev,
 }
 
 /**
- * pinctrl_gpio_request() - request a single pin to be used as GPIO
+ * pinctrl_gpio_request_consumer() - request a single pin to be used as GPIO
  * @gpio: the GPIO pin number from the GPIO subsystem number space
+ * @consumer: the name of the device requesting the GPIO
  *
  * This function should *ONLY* be used from gpiolib-based GPIO drivers,
  * as part of their gpio_request() semantics, platforms and individual drivers
  * shall *NOT* request GPIO pins to be muxed in.
  */
-int pinctrl_gpio_request(unsigned gpio)
+int pinctrl_gpio_request_consumer(unsigned gpio, const char *consumer)
 {
struct pinctrl_dev *pctldev;
struct pinctrl_gpio_range *range;
@@ -759,12 +760,18 @@ int pinctrl_gpio_request(unsigned gpio)
/* Convert to the pin controllers number space */
pin = gpio_to_pin(range, gpio);
 
-   ret = pinmux_request_gpio(pctldev, range, pin, gpio);
+   ret = pinmux_request_gpio_consumer(pctldev, range, pin, gpio, consumer);
 
mutex_unlock(>mutex);
 
return ret;
 }
+EXPORT_SYMBOL_GPL(pinctrl_gpio_request_consumer);
+
+int pinctrl_gpio_request(unsigned gpio)
+{
+   return pinctrl_gpio_request_consumer(gpio, NULL);
+}
 EXPORT_SYMBOL_GPL(pinctrl_gpio_request);
 
 /**
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 55502fc4479c..8d422eb0ed38 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -232,14 +232,19 @@ static const char *pin_free(struct pinctrl_dev *pctldev, 
int pin,
  * @pctldev: pin controller device affected
  * @pin: the pin to mux in for GPIO
  * @range: the applicable GPIO range
+ * @consumer: the name of the device requesting the GPIO
  */
-int pinmux_request_gpio(struct pinctrl_dev *pctldev,
+int pinmux_request_gpio_consumer(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
-   unsigned pin, unsigned gpio)
+   unsigned pin, unsigned gpio,
+   const char *consumer)
 {
const char *owner;
int ret;
 
+   if (consumer)
+   return pin_request(pctldev, pin, consumer, range);
+
/* Conjure some name stating what chip and pin this is taken by */
owner = kasprintf(GFP_KERNEL, "%s:%d", range->name, gpio);
if (!owner)
@@ -252,6 +257,13 @@ int pinmux_request_gpio(struct pinctrl_dev *pctldev,
return ret;
 }
 
+int pinmux_request_gpio(struct pinctrl_dev *pctldev,
+   struct pinctrl_gpio_range *range,
+   unsigned pin, unsigned gpio)
+{
+   return pinmux_request_gpio_consumer(pctldev, range, pin, gpio, NULL);
+}
+
 /**
  * pinmux_free_gpio() - release a pin from GPIO muxing
  * @pctldev: the pin controller device for the pin
diff --git a/drivers/pinctrl/pinmux.h b/drivers/pinctrl/pinmux.h
index a331fcdbedd9..837599922a42 100644
--- a/drivers/pinctrl/pinmux.h
+++ b/drivers/pinctrl/pinmux.h
@@ -19,6 +19,9 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i);
 int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio);
+int pinmux_request_gpio_consumer(struct pinctrl_dev *pctldev,
+   struct pinctrl_gpio_range *range,
+   unsigned pin, unsigned gpio, const char *consumer);
 void pinmux_free_gpio(struct pinctrl_dev *pctldev, 

Re: [PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries

[Ludovic Desroches]

On Tue, Jan 09, 2018 at 02:46:39PM +0100, Nicolas Ferre wrote:
> These two image capture interface drivers are now handled
> by Wenyou Yang.
> I benefit from this change to update the two entries by correcting the
> binding documentation link for ISC and moving the ISI to the new
> MICROCHIP / ATMEL location.
> 
> Signed-off-by: Nicolas Ferre <nicolas.fe...@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com>

> ---
> Hi,
> 
> Patch against next-20180109.
> Note that I didn't find it useful to have several patches for these changes.
> Tell me if you feel differently.
> 
> I would like to have the Ack from Ludovic and Wenyou obviously. I don't know 
> if
> Songjun can answer as he's not with Microchip anymore.
> 
> Best regards,
>   Nicolas
> 
>  MAINTAINERS | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a7d10a2bb980..65c4b59b582f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2353,13 +2353,6 @@ L: linux-...@vger.kernel.org
>  S:   Supported
>  F:   drivers/i2c/busses/i2c-at91.c
>  
> -ATMEL ISI DRIVER
> -M:   Ludovic Desroches <ludovic.desroc...@microchip.com>
> -L:   linux-me...@vger.kernel.org
> -S:   Supported
> -F:   drivers/media/platform/atmel/atmel-isi.c
> -F:   include/media/atmel-isi.h
> -
>  ATMEL LCDFB DRIVER
>  M:   Nicolas Ferre <nicolas.fe...@microchip.com>
>  L:   linux-fb...@vger.kernel.org
> @@ -9102,12 +9095,20 @@ S:Maintained
>  F:   drivers/crypto/atmel-ecc.*
>  
>  MICROCHIP / ATMEL ISC DRIVER
> -M:   Songjun Wu <songjun...@microchip.com>
> +M:   Wenyou Yang <wenyou.y...@microchip.com>
>  L:   linux-me...@vger.kernel.org
>  S:   Supported
>  F:   drivers/media/platform/atmel/atmel-isc.c
>  F:   drivers/media/platform/atmel/atmel-isc-regs.h
> -F:   devicetree/bindings/media/atmel-isc.txt
> +F:   Documentation/devicetree/bindings/media/atmel-isc.txt
> +
> +MICROCHIP / ATMEL ISI DRIVER
> +M:   Wenyou Yang <wenyou.y...@microchip.com>
> +L:   linux-me...@vger.kernel.org
> +S:   Supported
> +F:   drivers/media/platform/atmel/atmel-isi.c
> +F:   include/media/atmel-isi.h
> +F:   Documentation/devicetree/bindings/media/atmel-isi.txt
>  
>  MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
>  M:   Woojung Huh <woojung@microchip.com>
> -- 
> 2.9.0
> 

Re: [PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries

[Ludovic Desroches]

On Tue, Jan 09, 2018 at 02:46:39PM +0100, Nicolas Ferre wrote:
> These two image capture interface drivers are now handled
> by Wenyou Yang.
> I benefit from this change to update the two entries by correcting the
> binding documentation link for ISC and moving the ISI to the new
> MICROCHIP / ATMEL location.
> 
> Signed-off-by: Nicolas Ferre 
Acked-by: Ludovic Desroches 

> ---
> Hi,
> 
> Patch against next-20180109.
> Note that I didn't find it useful to have several patches for these changes.
> Tell me if you feel differently.
> 
> I would like to have the Ack from Ludovic and Wenyou obviously. I don't know 
> if
> Songjun can answer as he's not with Microchip anymore.
> 
> Best regards,
>   Nicolas
> 
>  MAINTAINERS | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a7d10a2bb980..65c4b59b582f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2353,13 +2353,6 @@ L: linux-...@vger.kernel.org
>  S:   Supported
>  F:   drivers/i2c/busses/i2c-at91.c
>  
> -ATMEL ISI DRIVER
> -M:   Ludovic Desroches 
> -L:   linux-me...@vger.kernel.org
> -S:   Supported
> -F:   drivers/media/platform/atmel/atmel-isi.c
> -F:   include/media/atmel-isi.h
> -
>  ATMEL LCDFB DRIVER
>  M:   Nicolas Ferre 
>  L:   linux-fb...@vger.kernel.org
> @@ -9102,12 +9095,20 @@ S:Maintained
>  F:   drivers/crypto/atmel-ecc.*
>  
>  MICROCHIP / ATMEL ISC DRIVER
> -M:   Songjun Wu 
> +M:   Wenyou Yang 
>  L:   linux-me...@vger.kernel.org
>  S:   Supported
>  F:   drivers/media/platform/atmel/atmel-isc.c
>  F:   drivers/media/platform/atmel/atmel-isc-regs.h
> -F:   devicetree/bindings/media/atmel-isc.txt
> +F:   Documentation/devicetree/bindings/media/atmel-isc.txt
> +
> +MICROCHIP / ATMEL ISI DRIVER
> +M:   Wenyou Yang 
> +L:   linux-me...@vger.kernel.org
> +S:   Supported
> +F:   drivers/media/platform/atmel/atmel-isi.c
> +F:   include/media/atmel-isi.h
> +F:   Documentation/devicetree/bindings/media/atmel-isi.txt
>  
>  MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
>  M:   Woojung Huh 
> -- 
> 2.9.0
> 

Re: [PATCH 12/14] iio: adc: at91-sama5d2_adc: support for position and pressure channels

[Ludovic Desroches]

Hi Jonathan, Eugen,

On Sat, Jan 06, 2018 at 03:05:37PM +, Jonathan Cameron wrote:
> On Thu, 4 Jan 2018 17:17:54 +0200
> Eugen Hristev  wrote:
> 
> > On 29.12.2017 19:02, Jonathan Cameron wrote:
> > > On Fri, 22 Dec 2017 17:07:19 +0200
> > > Eugen Hristev  wrote:
> > >   
> > >> The ADC IP supports position and pressure measurements for a touchpad
> > >> connected on channels 0,1,2,3 for a 4-wire touchscreen with pressure
> > >> measurement support.
> > >> Using the inkern API, a driver can request a trigger and read the
> > >> channel values from the ADC.
> > >> The implementation provides a trigger named "touch" which can be
> > >> connected to a consumer driver.
> > >> Once a driver connects and attaches a pollfunc to this trigger, the
> > >> configure trigger callback is called, and then the ADC driver will
> > >> initialize pad measurement.
> > >> First step is to enable touchscreen 4wire support and enable
> > >> pen detect IRQ.
> > >> Once a pen is detected, a periodic trigger is setup to trigger every
> > >> 2 ms (e.g.) and sample the resistive touchscreen values. The trigger poll
> > >> is called, and the consumer driver is then woke up, and it can read the
> > >> respective channels for the values : X, and Y for position and pressure
> > >> channel.
> > >> Because only one trigger can be active in hardware in the same time,
> > >> while touching the pad, the ADC will block any attempt to use the
> > >> triggered buffer. Same, conversions using the software trigger are also
> > >> impossible (since the periodic trigger is setup).
> > >> If some driver wants to attach while the trigger is in use, it will
> > >> also fail.
> > >> Once the pen is not detected anymore, the trigger is free for use 
> > >> (hardware
> > >> or software trigger, with or without DMA).
> > >> Channels 0,1,2 and 3 are unavailable if a touchscreen is enabled.
> > >>
> > >> Some parts of this patch are based on initial original work by
> > >> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
> > >>  
> > > OK, so comments inline.
> > > 
> > > What I'm missing currently though is an explanation of why the slightly
> > > more standard arrangement of using a callback buffer doesn't work here.
> > > The only addition I think you need to do that is to allow a consumer to
> > > request a particular trigger.  I also think some of the other provisions
> > > could be handled using standard features and slightly reducing the 
> > > flexibility.
> > > I don't know for example if it's useful to allow other channels to be
> > > read when touch is not in progress or not.
> > > 
> > > So restrictions:
> > > 
> > > 1. Touch screen channels can only be read when touch is enabled.
> > >   - use the available_scan_masks to control this. Or the callback that 
> > > lets
> > > you do the same dynamically.
> > > 2. You need to push these channels to your consumer driver.
> > >   - register a callback buffer rather than jumping through the hoops to
> > > insert your own pollfunc.  That will call a function in your
> > > consumer, providing the data from the 3 channels directly.
> > > 3. You need to make sure it is using the right driver.  For that you
> > > will I think need a new interface.
> > > 
> > > Various other comments inline. I may well be missing something as this is
> > > a fair bit of complex code to read - if so then next version should have
> > > a clear cover letter describing why this more standard approach can't be
> > > used.  
> > 
> > Hello Jonathan and thanks for the review of my patch series,
> > 
> > before starting and working over the required modifications and 
> > suggestions that you sent me, I want to be a little more explicit about 
> > the design of my implementation.
> > Hope this will clarify some things, and maybe I can as well understand 
> > better what you have in mind to support this feature set.
> > 
> > Why have I picked a pollfunction: We discussed a while back on the 
> > mailing list that you do not have an inkern mechanism to expose the 
> > triggers to other drivers, and that it may be a good idea to have it for 
> > such kind of actually multi function device, instead of having a MFD 
> > driver, an ADC driver, and an Input driver, all sharing the same 
> > register map, the same IRQ , etc, with some kind of synchronization to 
> > avoid stepping on each other for the hardware resource.
> 
> No disagreement with that principle.
> 
> > So I considered to expose the trigger by attaching and detaching 
> > pollfunctions to it. Which is the main thing what we use a trigger for.
> 
> Hmm. It's definitely one approach. But we do already have other drivers
> where the trigger is controlled by a consumer and to my mind that
> is a cleaner approach as it doesn't short cut the equivalent of
> doing it from userspace.
> 
> drivers/iio/potentiostat/lmp91000.c does something similar though
> for a rather different use. You 

Re: [PATCH 12/14] iio: adc: at91-sama5d2_adc: support for position and pressure channels

[Ludovic Desroches]

Hi Jonathan, Eugen,

On Sat, Jan 06, 2018 at 03:05:37PM +, Jonathan Cameron wrote:
> On Thu, 4 Jan 2018 17:17:54 +0200
> Eugen Hristev  wrote:
> 
> > On 29.12.2017 19:02, Jonathan Cameron wrote:
> > > On Fri, 22 Dec 2017 17:07:19 +0200
> > > Eugen Hristev  wrote:
> > >   
> > >> The ADC IP supports position and pressure measurements for a touchpad
> > >> connected on channels 0,1,2,3 for a 4-wire touchscreen with pressure
> > >> measurement support.
> > >> Using the inkern API, a driver can request a trigger and read the
> > >> channel values from the ADC.
> > >> The implementation provides a trigger named "touch" which can be
> > >> connected to a consumer driver.
> > >> Once a driver connects and attaches a pollfunc to this trigger, the
> > >> configure trigger callback is called, and then the ADC driver will
> > >> initialize pad measurement.
> > >> First step is to enable touchscreen 4wire support and enable
> > >> pen detect IRQ.
> > >> Once a pen is detected, a periodic trigger is setup to trigger every
> > >> 2 ms (e.g.) and sample the resistive touchscreen values. The trigger poll
> > >> is called, and the consumer driver is then woke up, and it can read the
> > >> respective channels for the values : X, and Y for position and pressure
> > >> channel.
> > >> Because only one trigger can be active in hardware in the same time,
> > >> while touching the pad, the ADC will block any attempt to use the
> > >> triggered buffer. Same, conversions using the software trigger are also
> > >> impossible (since the periodic trigger is setup).
> > >> If some driver wants to attach while the trigger is in use, it will
> > >> also fail.
> > >> Once the pen is not detected anymore, the trigger is free for use 
> > >> (hardware
> > >> or software trigger, with or without DMA).
> > >> Channels 0,1,2 and 3 are unavailable if a touchscreen is enabled.
> > >>
> > >> Some parts of this patch are based on initial original work by
> > >> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
> > >>  
> > > OK, so comments inline.
> > > 
> > > What I'm missing currently though is an explanation of why the slightly
> > > more standard arrangement of using a callback buffer doesn't work here.
> > > The only addition I think you need to do that is to allow a consumer to
> > > request a particular trigger.  I also think some of the other provisions
> > > could be handled using standard features and slightly reducing the 
> > > flexibility.
> > > I don't know for example if it's useful to allow other channels to be
> > > read when touch is not in progress or not.
> > > 
> > > So restrictions:
> > > 
> > > 1. Touch screen channels can only be read when touch is enabled.
> > >   - use the available_scan_masks to control this. Or the callback that 
> > > lets
> > > you do the same dynamically.
> > > 2. You need to push these channels to your consumer driver.
> > >   - register a callback buffer rather than jumping through the hoops to
> > > insert your own pollfunc.  That will call a function in your
> > > consumer, providing the data from the 3 channels directly.
> > > 3. You need to make sure it is using the right driver.  For that you
> > > will I think need a new interface.
> > > 
> > > Various other comments inline. I may well be missing something as this is
> > > a fair bit of complex code to read - if so then next version should have
> > > a clear cover letter describing why this more standard approach can't be
> > > used.  
> > 
> > Hello Jonathan and thanks for the review of my patch series,
> > 
> > before starting and working over the required modifications and 
> > suggestions that you sent me, I want to be a little more explicit about 
> > the design of my implementation.
> > Hope this will clarify some things, and maybe I can as well understand 
> > better what you have in mind to support this feature set.
> > 
> > Why have I picked a pollfunction: We discussed a while back on the 
> > mailing list that you do not have an inkern mechanism to expose the 
> > triggers to other drivers, and that it may be a good idea to have it for 
> > such kind of actually multi function device, instead of having a MFD 
> > driver, an ADC driver, and an Input driver, all sharing the same 
> > register map, the same IRQ , etc, with some kind of synchronization to 
> > avoid stepping on each other for the hardware resource.
> 
> No disagreement with that principle.
> 
> > So I considered to expose the trigger by attaching and detaching 
> > pollfunctions to it. Which is the main thing what we use a trigger for.
> 
> Hmm. It's definitely one approach. But we do already have other drivers
> where the trigger is controlled by a consumer and to my mind that
> is a cleaner approach as it doesn't short cut the equivalent of
> doing it from userspace.
> 
> drivers/iio/potentiostat/lmp91000.c does something similar though
> for a rather different use. You need your consumer interface
> to get the handle to the 

Re: [PATCH 2/3] dt-bindings: mtd: atmel-quadspi: add an optional property 'dmacap,memcpy'

[Ludovic Desroches]

Hi Cyrille,

On Wed, Dec 27, 2017 at 10:40:00PM +0100, Cyrille Pitchen wrote:
> Hi Rob,
> 
> + Ludovic Desroches, maintainer of the DMA controller drivers for AT91 SoCs.
> 
> Le 27/12/2017 à 00:23, Rob Herring a écrit :
> > On Sun, Dec 24, 2017 at 05:36:05AM +0100, Cyrille Pitchen wrote:
> >> The optional 'dmacap,memcpy' DT property tells the Atmel QSPI controller
> >> driver to reserve some DMA channel then to use it to perform DMA
> >> memcpy() during data transfers. This feature relies on the generic
> >> bounce buffer helper from spi-nor.c.
> >>
> >> Signed-off-by: Cyrille Pitchen <cyrille.pitc...@wedev4u.fr>
> >> ---
> >>  Documentation/devicetree/bindings/mtd/atmel-quadspi.txt | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt 
> >> b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> >> index b93c1e2f25dd..002d3f0a445b 100644
> >> --- a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> >> +++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> >> @@ -12,6 +12,10 @@ Required properties:
> >>  - #address-cells: Should be <1>.
> >>  - #size-cells:Should be <0>.
> >>  
> >> +Optional properties:
> >> +- dmacap,memcpy:  Reserve a DMA channel to perform DMA memcpy() between 
> >> the
> >> +  system memory and the QSPI mapped memory.
> > 
> > How is this a h/w property? Why would I not want to always enable DMA if 
> > possible?
> 
> The number of DMA channels is limited for a given SoC. This number may be
> lower than the number of enabled controllers (spi, i2c, qspi, aes, sha,
> des, sdmmc, usart, ...).
> 
> So we use a DT property to explicitly tell the matching drivers to request
> and reserved the DMA channels they need. This policy is not driver or even
> SoC specific but board specific. It's very common to reserved DMA channels
> for the most used or most performance dependent controllers, setting the
> relevant properties in the device-tree then restricting remaining
> controllers to their PIO mode.
> 
> > 
> > Furthermore, you are reusing a property, but giving it a different 
> > meaning. The current definition is an indication whether a DMA 
> > controller supports memcpy operations or not. It is not a flag for 
> > clients to use memcpy channels.
> >
> 
> I don't mind changing the name. I thought it would be better to use some
> existing one than creating another. However I was not confident on whether
> "dmacap,memcpy" was actually a good candidate for what I do in the DMA
> patch for the atmel-quadspi.c driver.
> 
> Actually, I was relying on your feedbacks :)
> 
> > Why don't you use "dmas" property to point to the DMA controller.
> 
> I didn't use the "dmas" property because I thought it would not have been
> consistent with how this property is used in all other nodes of the sama5*
> device-trees. The flags provided in the dma-cells are designed for "memory
> to peripheral" or "peripheral to memory" DMA transfers only.
> 
> However, here I need to perform some "memory to memory" transfer: the SPI
> NOR flash memory is mapped into the AHB bus of SAMA5D2 SoCs. Besides,
> once in Serial Memory Mode, data can no longer be transfered through the
> TDR or RDR registers of the QSPI controller, only through its AHB mapped
> memory window.
> 
> So I cannot configured the DMA channel for "peripheral to memory" or
> "memory to peripheral" like for other controllers embedded in the SoC but
> only for "memory to memory".
> 
> Maybe we could extend the flags supported by the "dmas" property but I
> guess it may require some little rework in the at_xdmac_xlate() function
> of the at_xdmac.c driver.
> 

I have no objection about changing the at_xdmac_xlate() behavior.

>From your cover-letter, I understand that the issue you're trying to
solve is not only related to the Atmel devices so you may also have to update
the xlate functions of the other DMA controllers.

> Or maybe no change at all is required at the at_xdmac.c driver side: we
> just don't care about the provided flags in the "dmas" property, especially
> the "peripheral id". They would be ignored anyway when the atmel-quadspi.c
> driver later calls dmaengine_prep_dma_memcpy(). So I could simply set the
> dma cells to 0 in the device-tree?
> 
> Ludovic, what do you think about that ?

It may work but I won't do this. Usually, channels requested through the xlate
function have usually their capaiblities set to DMA_SLAVE and not DMA_MEMCPY.
In the at_xdmac case, it won't be an issue but if you have a controller
which has channels which can support only mem-to-mem or peripheral, it
won't work.

Regards

Ludovic

Re: [PATCH 2/3] dt-bindings: mtd: atmel-quadspi: add an optional property 'dmacap,memcpy'

[Ludovic Desroches]

Hi Cyrille,

On Wed, Dec 27, 2017 at 10:40:00PM +0100, Cyrille Pitchen wrote:
> Hi Rob,
> 
> + Ludovic Desroches, maintainer of the DMA controller drivers for AT91 SoCs.
> 
> Le 27/12/2017 à 00:23, Rob Herring a écrit :
> > On Sun, Dec 24, 2017 at 05:36:05AM +0100, Cyrille Pitchen wrote:
> >> The optional 'dmacap,memcpy' DT property tells the Atmel QSPI controller
> >> driver to reserve some DMA channel then to use it to perform DMA
> >> memcpy() during data transfers. This feature relies on the generic
> >> bounce buffer helper from spi-nor.c.
> >>
> >> Signed-off-by: Cyrille Pitchen 
> >> ---
> >>  Documentation/devicetree/bindings/mtd/atmel-quadspi.txt | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt 
> >> b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> >> index b93c1e2f25dd..002d3f0a445b 100644
> >> --- a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> >> +++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> >> @@ -12,6 +12,10 @@ Required properties:
> >>  - #address-cells: Should be <1>.
> >>  - #size-cells:Should be <0>.
> >>  
> >> +Optional properties:
> >> +- dmacap,memcpy:  Reserve a DMA channel to perform DMA memcpy() between 
> >> the
> >> +  system memory and the QSPI mapped memory.
> > 
> > How is this a h/w property? Why would I not want to always enable DMA if 
> > possible?
> 
> The number of DMA channels is limited for a given SoC. This number may be
> lower than the number of enabled controllers (spi, i2c, qspi, aes, sha,
> des, sdmmc, usart, ...).
> 
> So we use a DT property to explicitly tell the matching drivers to request
> and reserved the DMA channels they need. This policy is not driver or even
> SoC specific but board specific. It's very common to reserved DMA channels
> for the most used or most performance dependent controllers, setting the
> relevant properties in the device-tree then restricting remaining
> controllers to their PIO mode.
> 
> > 
> > Furthermore, you are reusing a property, but giving it a different 
> > meaning. The current definition is an indication whether a DMA 
> > controller supports memcpy operations or not. It is not a flag for 
> > clients to use memcpy channels.
> >
> 
> I don't mind changing the name. I thought it would be better to use some
> existing one than creating another. However I was not confident on whether
> "dmacap,memcpy" was actually a good candidate for what I do in the DMA
> patch for the atmel-quadspi.c driver.
> 
> Actually, I was relying on your feedbacks :)
> 
> > Why don't you use "dmas" property to point to the DMA controller.
> 
> I didn't use the "dmas" property because I thought it would not have been
> consistent with how this property is used in all other nodes of the sama5*
> device-trees. The flags provided in the dma-cells are designed for "memory
> to peripheral" or "peripheral to memory" DMA transfers only.
> 
> However, here I need to perform some "memory to memory" transfer: the SPI
> NOR flash memory is mapped into the AHB bus of SAMA5D2 SoCs. Besides,
> once in Serial Memory Mode, data can no longer be transfered through the
> TDR or RDR registers of the QSPI controller, only through its AHB mapped
> memory window.
> 
> So I cannot configured the DMA channel for "peripheral to memory" or
> "memory to peripheral" like for other controllers embedded in the SoC but
> only for "memory to memory".
> 
> Maybe we could extend the flags supported by the "dmas" property but I
> guess it may require some little rework in the at_xdmac_xlate() function
> of the at_xdmac.c driver.
> 

I have no objection about changing the at_xdmac_xlate() behavior.

>From your cover-letter, I understand that the issue you're trying to
solve is not only related to the Atmel devices so you may also have to update
the xlate functions of the other DMA controllers.

> Or maybe no change at all is required at the at_xdmac.c driver side: we
> just don't care about the provided flags in the "dmas" property, especially
> the "peripheral id". They would be ignored anyway when the atmel-quadspi.c
> driver later calls dmaengine_prep_dma_memcpy(). So I could simply set the
> dma cells to 0 in the device-tree?
> 
> Ludovic, what do you think about that ?

It may work but I won't do this. Usually, channels requested through the xlate
function have usually their capaiblities set to DMA_SLAVE and not DMA_MEMCPY.
In the at_xdmac case, it won't be an issue but if you have a controller
which has channels which can support only mem-to-mem or peripheral, it
won't work.

Regards

Ludovic

Re: [PATCH 2/3] pinctrl: sunxi: Disable strict mode for old pinctrl drivers

[Ludovic Desroches]

Hi,

On Thu, Oct 05, 2017 at 10:54:07PM +0200, Maxime Ripard wrote:
> Old pinctrl drivers will need to disable strict mode for various reasons,
> among which:
>   - Some DT will still have a pinctrl group for each GPIO used, which will
> be rejected by pin_request. While we could remove those nodes, we still
> have to deal with old DTs.
>   - Some GPIOs on these boards need to have their pin configuration changed
> (for bias or current), and there's no clear migration path
> 
> Let's disable the strict mode on those SoCs so that there's no breakage.
> 

I revive this thread since I am facing the same issue. Did you find a way to
deal with it? I have not seen a new version of this set of patches, I may have
missed it.

Why you didn't choose to add an optionnal property to enforce the use of
the strict mode? I mean, with your solution, if there is a new DT with
an old pin controller, it won't benefit from the strict mode.

Ludovic

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun5i.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c  | 3 ++-
>  drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 1 +
>  7 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c
> index f763d8d62d6e..295e48fc94bc 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c
> @@ -1289,6 +1289,7 @@ static const struct sunxi_pinctrl_desc 
> sun4i_a10_pinctrl_data = {
>   .npins = ARRAY_SIZE(sun4i_a10_pins),
>   .irq_banks = 1,
>   .irq_read_needs_mux = true,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun4i_a10_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun5i.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun5i.c
> index 47afd558b114..27ec99e81c4c 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun5i.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun5i.c
> @@ -713,6 +713,7 @@ static const struct sunxi_pinctrl_desc sun5i_pinctrl_data 
> = {
>   .pins = sun5i_pins,
>   .npins = ARRAY_SIZE(sun5i_pins),
>   .irq_banks = 1,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun5i_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c
> index 951a25c18815..82ffaf466892 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c
> @@ -965,6 +965,7 @@ static const struct sunxi_pinctrl_desc 
> sun6i_a31_pinctrl_data = {
>   .pins = sun6i_a31_pins,
>   .npins = ARRAY_SIZE(sun6i_a31_pins),
>   .irq_banks = 4,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun6i_a31_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
> index 721b6935baf3..402fd7d21e7b 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
> @@ -563,6 +563,7 @@ static const struct sunxi_pinctrl_desc 
> sun8i_a23_pinctrl_data = {
>   .pins = sun8i_a23_pins,
>   .npins = ARRAY_SIZE(sun8i_a23_pins),
>   .irq_banks = 3,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun8i_a23_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c
> index ef1e0bef4099..da387211a75e 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c
> @@ -486,6 +486,7 @@ static const struct sunxi_pinctrl_desc 
> sun8i_a33_pinctrl_data = {
>   .npins = ARRAY_SIZE(sun8i_a33_pins),
>   .irq_banks = 2,
>   .irq_bank_base = 1,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun8i_a33_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
> index 518a92df4418..d1719a738c20 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
> @@ -491,7 +491,8 @@ static const struct sunxi_pinctrl_desc 
> sun8i_h3_pinctrl_data = {
>   .pins = sun8i_h3_pins,
>   .npins = ARRAY_SIZE(sun8i_h3_pins),
>   .irq_banks = 2,
> - .irq_read_needs_mux = true
> + .irq_read_needs_mux = true,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun8i_h3_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> index bc14e954d7a2..472ef0d91b99 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> +++ 

Re: [PATCH 2/3] pinctrl: sunxi: Disable strict mode for old pinctrl drivers

[Ludovic Desroches]

Hi,

On Thu, Oct 05, 2017 at 10:54:07PM +0200, Maxime Ripard wrote:
> Old pinctrl drivers will need to disable strict mode for various reasons,
> among which:
>   - Some DT will still have a pinctrl group for each GPIO used, which will
> be rejected by pin_request. While we could remove those nodes, we still
> have to deal with old DTs.
>   - Some GPIOs on these boards need to have their pin configuration changed
> (for bias or current), and there's no clear migration path
> 
> Let's disable the strict mode on those SoCs so that there's no breakage.
> 

I revive this thread since I am facing the same issue. Did you find a way to
deal with it? I have not seen a new version of this set of patches, I may have
missed it.

Why you didn't choose to add an optionnal property to enforce the use of
the strict mode? I mean, with your solution, if there is a new DT with
an old pin controller, it won't benefit from the strict mode.

Ludovic

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun5i.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c | 1 +
>  drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c  | 3 ++-
>  drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 1 +
>  7 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c
> index f763d8d62d6e..295e48fc94bc 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c
> @@ -1289,6 +1289,7 @@ static const struct sunxi_pinctrl_desc 
> sun4i_a10_pinctrl_data = {
>   .npins = ARRAY_SIZE(sun4i_a10_pins),
>   .irq_banks = 1,
>   .irq_read_needs_mux = true,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun4i_a10_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun5i.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun5i.c
> index 47afd558b114..27ec99e81c4c 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun5i.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun5i.c
> @@ -713,6 +713,7 @@ static const struct sunxi_pinctrl_desc sun5i_pinctrl_data 
> = {
>   .pins = sun5i_pins,
>   .npins = ARRAY_SIZE(sun5i_pins),
>   .irq_banks = 1,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun5i_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c
> index 951a25c18815..82ffaf466892 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c
> @@ -965,6 +965,7 @@ static const struct sunxi_pinctrl_desc 
> sun6i_a31_pinctrl_data = {
>   .pins = sun6i_a31_pins,
>   .npins = ARRAY_SIZE(sun6i_a31_pins),
>   .irq_banks = 4,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun6i_a31_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
> index 721b6935baf3..402fd7d21e7b 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
> @@ -563,6 +563,7 @@ static const struct sunxi_pinctrl_desc 
> sun8i_a23_pinctrl_data = {
>   .pins = sun8i_a23_pins,
>   .npins = ARRAY_SIZE(sun8i_a23_pins),
>   .irq_banks = 3,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun8i_a23_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c
> index ef1e0bef4099..da387211a75e 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c
> @@ -486,6 +486,7 @@ static const struct sunxi_pinctrl_desc 
> sun8i_a33_pinctrl_data = {
>   .npins = ARRAY_SIZE(sun8i_a33_pins),
>   .irq_banks = 2,
>   .irq_bank_base = 1,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun8i_a33_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
> index 518a92df4418..d1719a738c20 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
> @@ -491,7 +491,8 @@ static const struct sunxi_pinctrl_desc 
> sun8i_h3_pinctrl_data = {
>   .pins = sun8i_h3_pins,
>   .npins = ARRAY_SIZE(sun8i_h3_pins),
>   .irq_banks = 2,
> - .irq_read_needs_mux = true
> + .irq_read_needs_mux = true,
> + .disable_strict_mode = true,
>  };
>  
>  static int sun8i_h3_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> index bc14e954d7a2..472ef0d91b99 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> +++ 

[RESEND PATCH V2] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

Add the official SAMA5D2 Peripheral Touch Controller Evaluation
Kit board.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
Resend: Put SPDX-License-Identifier at the beginning of the file.

Changes:
- v2:
  - remove memory node
  - use SPDX-License-Identifier

 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 401 ++
 2 files changed, 402 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 043d7c720d0c..ed60582eb1da 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
 dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d27_som1_ek.dtb \
+   at91-sama5d2_ptc_ek.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
at91-tse850-3.dtb \
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
new file mode 100644
index ..186cb03e2672
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -0,0 +1,401 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * at91-sama5d2_ptc_ek.dts - Device Tree file for SAMA5D2 PTC EK board
+ *
+ *  Copyright (C) 2017 Microchip/Atmel,
+ *   2017 Wenyou Yang <wenyou.y...@microchip.com>
+ *   2017 Ludovic Desroches <ludovic.desroc...@microchip.com>
+ */
+/dts-v1/;
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include 
+#include 
+
+/ {
+   model = "Atmel SAMA5D2 PTC EK";
+   compatible = "atmel,sama5d2-ptc_ek", "atmel,sama5d2", "atmel,sama5";
+
+   aliases {
+   serial0 = 
+   i2c0= 
+   i2c1= 
+   i2c2= 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   clocks {
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <2400>;
+   };
+   };
+
+   ahb {
+   usb0: gadget@30 {
+   atmel,vbus-gpio = < PIN_PA27 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usba_vbus>;
+   status = "okay";
+   };
+
+   usb1: ohci@40 {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   PIN_PB12 GPIO_ACTIVE_HIGH
+  0
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+   };
+
+   usb2: ehci@50 {
+   status = "okay";
+   };
+
+   ebi: ebi@1000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_nand_default>;
+   status = "okay"; /* conflicts with sdmmc1 and qspi0 */
+
+   nand_controller: nand-controller {
+   status = "okay";
+
+   nand@3 {
+   reg = <0x3 0x0 0x2>;
+   atmel,rb = <0>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   label = "atmel_nand";
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   at91bootstrap@0 {
+   label = "bootstrap";
+   reg = <0x0 0x4>;
+   };
+
+   bootloader@4 {
+   label = "bootloader";
+   reg = <0x4 0xc>;
+   };
+
+   bootloade

[RESEND PATCH V2] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

Add the official SAMA5D2 Peripheral Touch Controller Evaluation
Kit board.

Signed-off-by: Ludovic Desroches 
---
Resend: Put SPDX-License-Identifier at the beginning of the file.

Changes:
- v2:
  - remove memory node
  - use SPDX-License-Identifier

 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 401 ++
 2 files changed, 402 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 043d7c720d0c..ed60582eb1da 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
 dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d27_som1_ek.dtb \
+   at91-sama5d2_ptc_ek.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
at91-tse850-3.dtb \
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
new file mode 100644
index ..186cb03e2672
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -0,0 +1,401 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * at91-sama5d2_ptc_ek.dts - Device Tree file for SAMA5D2 PTC EK board
+ *
+ *  Copyright (C) 2017 Microchip/Atmel,
+ *   2017 Wenyou Yang 
+ *   2017 Ludovic Desroches 
+ */
+/dts-v1/;
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include 
+#include 
+
+/ {
+   model = "Atmel SAMA5D2 PTC EK";
+   compatible = "atmel,sama5d2-ptc_ek", "atmel,sama5d2", "atmel,sama5";
+
+   aliases {
+   serial0 = 
+   i2c0= 
+   i2c1= 
+   i2c2= 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   clocks {
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <2400>;
+   };
+   };
+
+   ahb {
+   usb0: gadget@30 {
+   atmel,vbus-gpio = < PIN_PA27 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usba_vbus>;
+   status = "okay";
+   };
+
+   usb1: ohci@40 {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   PIN_PB12 GPIO_ACTIVE_HIGH
+  0
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+   };
+
+   usb2: ehci@50 {
+   status = "okay";
+   };
+
+   ebi: ebi@1000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_nand_default>;
+   status = "okay"; /* conflicts with sdmmc1 and qspi0 */
+
+   nand_controller: nand-controller {
+   status = "okay";
+
+   nand@3 {
+   reg = <0x3 0x0 0x2>;
+   atmel,rb = <0>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   label = "atmel_nand";
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   at91bootstrap@0 {
+   label = "bootstrap";
+   reg = <0x0 0x4>;
+   };
+
+   bootloader@4 {
+   label = "bootloader";
+   reg = <0x4 0xc>;
+   };
+
+   bootloaderenv@0x10 {
+   label = "bootloader 
env";
+   reg = &l

Re: [PATCH] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

On Tue, Dec 05, 2017 at 07:01:41PM +0200, Baruch Siach wrote:
> Hi Ludovic,
> 
> On Tue, Dec 05, 2017 at 03:23:12PM +0100, Ludovic Desroches wrote:
> > Add the official SAMA5D2 Peripheral Touch Controller Evaluation
> > Kit board.
> > 
> > Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
> > ---
> 
> [...]
> 
> > +   memory {
> > +   reg = <0x2000 0x8>;
> > +   };
> 
> The size value is clearly wrong; you surely don't run on 512KB RAM. You most 
> likely rely on the bootloader to fix the size value. Since sama5d2.dtsi has a 
> memory node already with the same address, you can just drop it from here.
> 

Thanks, fixed in v2.

Ludovic

> baruch
> 
> -- 
>  http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
> =}ooO--U--Ooo{=
>- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

On Tue, Dec 05, 2017 at 07:01:41PM +0200, Baruch Siach wrote:
> Hi Ludovic,
> 
> On Tue, Dec 05, 2017 at 03:23:12PM +0100, Ludovic Desroches wrote:
> > Add the official SAMA5D2 Peripheral Touch Controller Evaluation
> > Kit board.
> > 
> > Signed-off-by: Ludovic Desroches 
> > ---
> 
> [...]
> 
> > +   memory {
> > +   reg = <0x2000 0x8>;
> > +   };
> 
> The size value is clearly wrong; you surely don't run on 512KB RAM. You most 
> likely rely on the bootloader to fix the size value. Since sama5d2.dtsi has a 
> memory node already with the same address, you can just drop it from here.
> 

Thanks, fixed in v2.

Ludovic

> baruch
> 
> -- 
>  http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
> =}ooO--U--Ooo{=
>- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH V2] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

Add the official SAMA5D2 Peripheral Touch Controller Evaluation
Kit board.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---

Changes:
- v2:
  - remove memory node
  - use SPDX-License-Identifier

arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 402 ++
 2 files changed, 403 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 043d7c720d0c..ed60582eb1da 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
 dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d27_som1_ek.dtb \
+   at91-sama5d2_ptc_ek.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
at91-tse850-3.dtb \
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
new file mode 100644
index ..89ad23a7f92d
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -0,0 +1,402 @@
+/*
+ * at91-sama5d2_ptc_ek.dts - Device Tree file for SAMA5D2 PTC EK board
+ *
+ *  Copyright (C) 2017 Microchip/Atmel,
+ *   2017 Wenyou Yang <wenyou.y...@microchip.com>
+ *   2017 Ludovic Desroches <ludovic.desroc...@microchip.com>
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR X11)
+ */
+/dts-v1/;
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include 
+#include 
+
+/ {
+   model = "Atmel SAMA5D2 PTC EK";
+   compatible = "atmel,sama5d2-ptc_ek", "atmel,sama5d2", "atmel,sama5";
+
+   aliases {
+   serial0 = 
+   i2c0= 
+   i2c1= 
+   i2c2= 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   clocks {
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <2400>;
+   };
+   };
+
+   ahb {
+   usb0: gadget@30 {
+   atmel,vbus-gpio = < PIN_PA27 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usba_vbus>;
+   status = "okay";
+   };
+
+   usb1: ohci@40 {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   PIN_PB12 GPIO_ACTIVE_HIGH
+  0
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+   };
+
+   usb2: ehci@50 {
+   status = "okay";
+   };
+
+   ebi: ebi@1000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_nand_default>;
+   status = "okay"; /* conflicts with sdmmc1 and qspi0 */
+
+   nand_controller: nand-controller {
+   status = "okay";
+
+   nand@3 {
+   reg = <0x3 0x0 0x2>;
+   atmel,rb = <0>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   label = "atmel_nand";
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   at91bootstrap@0 {
+   label = "bootstrap";
+   reg = <0x0 0x4>;
+   };
+
+   bootloader@4 {
+   label = "bootloader";
+   reg = <0x4 0xc>;
+   };
+
+   bootloaderenv@0x10 {
+   label = "bootloa

[PATCH V2] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

Add the official SAMA5D2 Peripheral Touch Controller Evaluation
Kit board.

Signed-off-by: Ludovic Desroches 
---

Changes:
- v2:
  - remove memory node
  - use SPDX-License-Identifier

arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 402 ++
 2 files changed, 403 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 043d7c720d0c..ed60582eb1da 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
 dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d27_som1_ek.dtb \
+   at91-sama5d2_ptc_ek.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
at91-tse850-3.dtb \
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
new file mode 100644
index ..89ad23a7f92d
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -0,0 +1,402 @@
+/*
+ * at91-sama5d2_ptc_ek.dts - Device Tree file for SAMA5D2 PTC EK board
+ *
+ *  Copyright (C) 2017 Microchip/Atmel,
+ *   2017 Wenyou Yang 
+ *   2017 Ludovic Desroches 
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR X11)
+ */
+/dts-v1/;
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include 
+#include 
+
+/ {
+   model = "Atmel SAMA5D2 PTC EK";
+   compatible = "atmel,sama5d2-ptc_ek", "atmel,sama5d2", "atmel,sama5";
+
+   aliases {
+   serial0 = 
+   i2c0= 
+   i2c1= 
+   i2c2= 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   clocks {
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <2400>;
+   };
+   };
+
+   ahb {
+   usb0: gadget@30 {
+   atmel,vbus-gpio = < PIN_PA27 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usba_vbus>;
+   status = "okay";
+   };
+
+   usb1: ohci@40 {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   PIN_PB12 GPIO_ACTIVE_HIGH
+  0
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+   };
+
+   usb2: ehci@50 {
+   status = "okay";
+   };
+
+   ebi: ebi@1000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_nand_default>;
+   status = "okay"; /* conflicts with sdmmc1 and qspi0 */
+
+   nand_controller: nand-controller {
+   status = "okay";
+
+   nand@3 {
+   reg = <0x3 0x0 0x2>;
+   atmel,rb = <0>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   label = "atmel_nand";
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   at91bootstrap@0 {
+   label = "bootstrap";
+   reg = <0x0 0x4>;
+   };
+
+   bootloader@4 {
+   label = "bootloader";
+   reg = <0x4 0xc>;
+   };
+
+   bootloaderenv@0x10 {
+   label = "bootloader 
env";
+   reg = <0x10 
0x4&g

[PATCH] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

Add the official SAMA5D2 Peripheral Touch Controller Evaluation
Kit board.

Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com>
---
 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 442 ++
 2 files changed, 443 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 043d7c720d0c..ed60582eb1da 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
 dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d27_som1_ek.dtb \
+   at91-sama5d2_ptc_ek.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
at91-tse850-3.dtb \
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
new file mode 100644
index ..46e8bb668546
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -0,0 +1,442 @@
+/*
+ * at91-sama5d2_ptc_ek.dts - Device Tree file for SAMA5D2 PTC EK board
+ *
+ *  Copyright (C) 2017 Microchip/Atmel,
+ *   2017 Wenyou Yang <wenyou.y...@microchip.com>
+ *   2017 Ludovic Desroches <ludovic.desroc...@microchip.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include 
+#include 
+
+/ {
+   model = "Atmel SAMA5D2 PTC EK";
+   compatible = "atmel,sama5d2-ptc_ek", "atmel,sama5d2", "atmel,sama5";
+
+   aliases {
+   serial0 = 
+   i2c0= 
+   i2c1= 
+   i2c2= 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   reg = <0x2000 0x8>;
+   };
+
+   clocks {
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <2400>;
+   };
+   };
+
+   ahb {
+   usb0: gadget@30 {
+   atmel,vbus-gpio = < PIN_PA27 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usba_vbus>;
+   status = "okay";
+   };
+
+   usb1: ohci@40 {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   PIN_PB12 GPIO_ACTIVE_HIGH
+  0
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+   };
+
+   usb2: 

[PATCH] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

Add the official SAMA5D2 Peripheral Touch Controller Evaluation
Kit board.

Signed-off-by: Ludovic Desroches 
---
 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 442 ++
 2 files changed, 443 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 043d7c720d0c..ed60582eb1da 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
 dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d27_som1_ek.dtb \
+   at91-sama5d2_ptc_ek.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
at91-tse850-3.dtb \
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
new file mode 100644
index ..46e8bb668546
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -0,0 +1,442 @@
+/*
+ * at91-sama5d2_ptc_ek.dts - Device Tree file for SAMA5D2 PTC EK board
+ *
+ *  Copyright (C) 2017 Microchip/Atmel,
+ *   2017 Wenyou Yang 
+ *   2017 Ludovic Desroches 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include 
+#include 
+
+/ {
+   model = "Atmel SAMA5D2 PTC EK";
+   compatible = "atmel,sama5d2-ptc_ek", "atmel,sama5d2", "atmel,sama5";
+
+   aliases {
+   serial0 = 
+   i2c0= 
+   i2c1= 
+   i2c2= 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   reg = <0x2000 0x8>;
+   };
+
+   clocks {
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <2400>;
+   };
+   };
+
+   ahb {
+   usb0: gadget@30 {
+   atmel,vbus-gpio = < PIN_PA27 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usba_vbus>;
+   status = "okay";
+   };
+
+   usb1: ohci@40 {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   PIN_PB12 GPIO_ACTIVE_HIGH
+  0
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+   };
+
+   usb2: ehci@50 {
+   status = "okay";
+   };
+
+   ebi: ebi@10

Re: [PATCH v2 3/3] i2c: at91: added slave mode support

[Ludovic Desroches]

Hi Juergen,

On Thu, Nov 09, 2017 at 06:22:29PM +0100, Juergen Fitschen wrote:
> Slave mode driver is based on the concept of i2c-designware driver.
> 

Sorry to be so long to answer you. I would like to test it before acking
it. Unfortunately, I didn't have the time to perform all the tests I
have in mind but I don't way to delay the inclusion of the slave mode
support. If there are bugs or restrictions, we could fix it later.

I tested it quickly on a sama5d2 xplained board: I used an i2c-gpio
master and the eeprom driver. It works pretty well. I tried to increase
the size of the eeprom by adding:
+ { "slave-24c64", 65536 / 8 },
in i2c-slave-eeprom.c. Unfortunately, it no longer works: I get
different checksums. Looking quickly at i2c-slave-eeprom.c, I don't see
any reason why it may not work if I increase the size but I may have
missed something.

I have seen you described how you tested it thanks. Maybe you have also
tried in the same way as me? Did you experience the same behavior?

Regards

Ludovic

> Signed-off-by: Juergen Fitschen 
> ---
> Changes in v2:
>  - Squashed commit "take slave mode capabilities of hardware into
>account" into this commit
>  - Removed unused feature bit AT91_TWI_SM_HAS_FIFO
>  - Added NACK support
>  - Reworked interrupt handler:
>- The interrupt handler takes into account that several events can
>  occur between two handler calls and thus must be handled in one
>  handler run. It caanot be assumed that every events triggers the
>  handler individually.
>- Instead of using the states register of the I2c interface, a state
>  machine is held in the at91_twi_dev struct. This ensures that no
>  state transitions are missed due ti interrupt latency.
>  - Added Kconfig option for selection whether slave mode suppurt should
>be included in the driver or not
>  - Added example in Documentation/devicetree/bindings/i2c/i2c-at91.txt
> ---
>  Documentation/devicetree/bindings/i2c/i2c-at91.txt |  14 ++
>  drivers/i2c/busses/Kconfig |  10 +
>  drivers/i2c/busses/Makefile|   3 +
>  drivers/i2c/busses/i2c-at91-core.c |  23 ++-
>  drivers/i2c/busses/i2c-at91-slave.c| 216 
> +
>  drivers/i2c/busses/i2c-at91.h  |  42 +++-
>  6 files changed, 304 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/i2c/busses/i2c-at91-slave.c
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> index ef973a0..95c79a8 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> @@ -61,3 +61,17 @@ i2c0: i2c@f8034600 {
>   reg = <0x1a>;
>   };
>  };
> +
> +i2c0: i2c@f8028000 {
> + compatible = "atmel,sama5d2-i2c";
> + reg = <0xf8028000 0x100>;
> + interrupts = <29 4 7>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <_clk>;
> +
> + eeprom@64 {
> + compatible = "linux,slave-24c02";
> + reg = <0x4064>;
> + };
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 009345d..41338e8 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -380,6 +380,16 @@ config I2C_AT91
> the latency to fill the transmission register is too long. If you
> are facing this situation, use the i2c-gpio driver.
>  
> +config I2C_AT91_SLAVE
> + bool "Atmel AT91 I2C Two-Wire interface (TWI) Slave"
> + depends on I2C_AT91 && I2C_SLAVE
> + help
> +   This adds slave mode support to the I2C interface on Atmel AT91
> +   processors.
> +
> +   This is not a standalone module and must be compiled together with the
> +   master mode driver.
> +
>  config I2C_AU1550
>   tristate "Au1550/Au1200/Au1300 SMBus interface"
>   depends on MIPS_ALCHEMY
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 2a79c3d..daa2ea4 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -34,6 +34,9 @@ obj-$(CONFIG_I2C_ALTERA)+= i2c-altera.o
>  obj-$(CONFIG_I2C_ASPEED) += i2c-aspeed.o
>  obj-$(CONFIG_I2C_AT91)   += i2c-at91.o
>  i2c-at91-objs:= i2c-at91-core.o i2c-at91-master.o
> +ifeq ($(CONFIG_I2C_AT91_SLAVE),y)
> + i2c-at91-objs   += i2c-at91-slave.o
> +endif
>  obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
>  obj-$(CONFIG_I2C_AXXIA)  += i2c-axxia.o
>  obj-$(CONFIG_I2C_BCM2835)+= i2c-bcm2835.o
> diff --git a/drivers/i2c/busses/i2c-at91-core.c 
> b/drivers/i2c/busses/i2c-at91-core.c
> index 4fed72d..cba447e 100644
> --- a/drivers/i2c/busses/i2c-at91-core.c
> +++ b/drivers/i2c/busses/i2c-at91-core.c
> @@ -60,13 +60,16 @@ void at91_init_twi_bus(struct at91_twi_dev *dev)
>  {
>   at91_disable_twi_interrupts(dev);
>   

Re: [PATCH v2 3/3] i2c: at91: added slave mode support

[Ludovic Desroches]

Hi Juergen,

On Thu, Nov 09, 2017 at 06:22:29PM +0100, Juergen Fitschen wrote:
> Slave mode driver is based on the concept of i2c-designware driver.
> 

Sorry to be so long to answer you. I would like to test it before acking
it. Unfortunately, I didn't have the time to perform all the tests I
have in mind but I don't way to delay the inclusion of the slave mode
support. If there are bugs or restrictions, we could fix it later.

I tested it quickly on a sama5d2 xplained board: I used an i2c-gpio
master and the eeprom driver. It works pretty well. I tried to increase
the size of the eeprom by adding:
+ { "slave-24c64", 65536 / 8 },
in i2c-slave-eeprom.c. Unfortunately, it no longer works: I get
different checksums. Looking quickly at i2c-slave-eeprom.c, I don't see
any reason why it may not work if I increase the size but I may have
missed something.

I have seen you described how you tested it thanks. Maybe you have also
tried in the same way as me? Did you experience the same behavior?

Regards

Ludovic

> Signed-off-by: Juergen Fitschen 
> ---
> Changes in v2:
>  - Squashed commit "take slave mode capabilities of hardware into
>account" into this commit
>  - Removed unused feature bit AT91_TWI_SM_HAS_FIFO
>  - Added NACK support
>  - Reworked interrupt handler:
>- The interrupt handler takes into account that several events can
>  occur between two handler calls and thus must be handled in one
>  handler run. It caanot be assumed that every events triggers the
>  handler individually.
>- Instead of using the states register of the I2c interface, a state
>  machine is held in the at91_twi_dev struct. This ensures that no
>  state transitions are missed due ti interrupt latency.
>  - Added Kconfig option for selection whether slave mode suppurt should
>be included in the driver or not
>  - Added example in Documentation/devicetree/bindings/i2c/i2c-at91.txt
> ---
>  Documentation/devicetree/bindings/i2c/i2c-at91.txt |  14 ++
>  drivers/i2c/busses/Kconfig |  10 +
>  drivers/i2c/busses/Makefile|   3 +
>  drivers/i2c/busses/i2c-at91-core.c |  23 ++-
>  drivers/i2c/busses/i2c-at91-slave.c| 216 
> +
>  drivers/i2c/busses/i2c-at91.h  |  42 +++-
>  6 files changed, 304 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/i2c/busses/i2c-at91-slave.c
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> index ef973a0..95c79a8 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> @@ -61,3 +61,17 @@ i2c0: i2c@f8034600 {
>   reg = <0x1a>;
>   };
>  };
> +
> +i2c0: i2c@f8028000 {
> + compatible = "atmel,sama5d2-i2c";
> + reg = <0xf8028000 0x100>;
> + interrupts = <29 4 7>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <_clk>;
> +
> + eeprom@64 {
> + compatible = "linux,slave-24c02";
> + reg = <0x4064>;
> + };
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 009345d..41338e8 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -380,6 +380,16 @@ config I2C_AT91
> the latency to fill the transmission register is too long. If you
> are facing this situation, use the i2c-gpio driver.
>  
> +config I2C_AT91_SLAVE
> + bool "Atmel AT91 I2C Two-Wire interface (TWI) Slave"
> + depends on I2C_AT91 && I2C_SLAVE
> + help
> +   This adds slave mode support to the I2C interface on Atmel AT91
> +   processors.
> +
> +   This is not a standalone module and must be compiled together with the
> +   master mode driver.
> +
>  config I2C_AU1550
>   tristate "Au1550/Au1200/Au1300 SMBus interface"
>   depends on MIPS_ALCHEMY
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 2a79c3d..daa2ea4 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -34,6 +34,9 @@ obj-$(CONFIG_I2C_ALTERA)+= i2c-altera.o
>  obj-$(CONFIG_I2C_ASPEED) += i2c-aspeed.o
>  obj-$(CONFIG_I2C_AT91)   += i2c-at91.o
>  i2c-at91-objs:= i2c-at91-core.o i2c-at91-master.o
> +ifeq ($(CONFIG_I2C_AT91_SLAVE),y)
> + i2c-at91-objs   += i2c-at91-slave.o
> +endif
>  obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
>  obj-$(CONFIG_I2C_AXXIA)  += i2c-axxia.o
>  obj-$(CONFIG_I2C_BCM2835)+= i2c-bcm2835.o
> diff --git a/drivers/i2c/busses/i2c-at91-core.c 
> b/drivers/i2c/busses/i2c-at91-core.c
> index 4fed72d..cba447e 100644
> --- a/drivers/i2c/busses/i2c-at91-core.c
> +++ b/drivers/i2c/busses/i2c-at91-core.c
> @@ -60,13 +60,16 @@ void at91_init_twi_bus(struct at91_twi_dev *dev)
>  {
>   at91_disable_twi_interrupts(dev);
>   at91_twi_write(dev, 

Re: [PATCH] dmaengine: at_hdmac: fix potential NULL pointer dereference in atc_prep_dma_interleaved

[Ludovic Desroches]

On Mon, Nov 20, 2017 at 08:28:14AM -0600, Gustavo A. R. Silva wrote:
> _xt_ is being dereferenced before it is null checked, hence there is a
> potential null pointer dereference.
> 
> Fix this by moving the pointer dereference after _xt_ has been null
> checked.
> 
> This issue was detected with the help of Coccinelle.
> 
> Fixes: 4483320e241c ("dmaengine: Use Pointer xt after NULL check.")
> Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com>
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com>

Thanks

> ---
>  drivers/dma/at_hdmac.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index fbab271..a861b5b 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -708,7 +708,7 @@ atc_prep_dma_interleaved(struct dma_chan *chan,
>unsigned long flags)
>  {
>   struct at_dma_chan  *atchan = to_at_dma_chan(chan);
> - struct data_chunk   *first = xt->sgl;
> + struct data_chunk   *first;
>   struct at_desc  *desc = NULL;
>   size_t  xfer_count;
>   unsigned intdwidth;
> @@ -720,6 +720,8 @@ atc_prep_dma_interleaved(struct dma_chan *chan,
>   if (unlikely(!xt || xt->numf != 1 || !xt->frame_size))
>   return NULL;
>  
> + first = xt->sgl;
> +
>   dev_info(chan2dev(chan),
>"%s: src=%pad, dest=%pad, numf=%d, frame_size=%d, 
> flags=0x%lx\n",
>   __func__, >src_start, >dst_start, xt->numf,
> -- 
> 2.7.4
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] dmaengine: at_hdmac: fix potential NULL pointer dereference in atc_prep_dma_interleaved

[Ludovic Desroches]

On Mon, Nov 20, 2017 at 08:28:14AM -0600, Gustavo A. R. Silva wrote:
> _xt_ is being dereferenced before it is null checked, hence there is a
> potential null pointer dereference.
> 
> Fix this by moving the pointer dereference after _xt_ has been null
> checked.
> 
> This issue was detected with the help of Coccinelle.
> 
> Fixes: 4483320e241c ("dmaengine: Use Pointer xt after NULL check.")
> Signed-off-by: Gustavo A. R. Silva 
Acked-by: Ludovic Desroches 

Thanks

> ---
>  drivers/dma/at_hdmac.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index fbab271..a861b5b 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -708,7 +708,7 @@ atc_prep_dma_interleaved(struct dma_chan *chan,
>unsigned long flags)
>  {
>   struct at_dma_chan  *atchan = to_at_dma_chan(chan);
> - struct data_chunk   *first = xt->sgl;
> + struct data_chunk   *first;
>   struct at_desc  *desc = NULL;
>   size_t  xfer_count;
>   unsigned intdwidth;
> @@ -720,6 +720,8 @@ atc_prep_dma_interleaved(struct dma_chan *chan,
>   if (unlikely(!xt || xt->numf != 1 || !xt->frame_size))
>   return NULL;
>  
> + first = xt->sgl;
> +
>   dev_info(chan2dev(chan),
>"%s: src=%pad, dest=%pad, numf=%d, frame_size=%d, 
> flags=0x%lx\n",
>   __func__, >src_start, >dst_start, xt->numf,
> -- 
> 2.7.4
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/5] dt-bindings: iio: at91-sama5d2_adc: add optional dma property

[Ludovic Desroches]

On Tue, Nov 07, 2017 at 10:49:41AM +0200, Eugen Hristev wrote:
> 
> 
> On 20.10.2017 00:58, Rob Herring wrote:
> > On Thu, Oct 19, 2017 at 6:14 AM, Alexandre Belloni
> >  wrote:
> > > On 13/10/2017 at 16:51:42 -0500, Rob Herring wrote:
> > > > On Wed, Oct 11, 2017 at 09:35:28AM +0300, Eugen Hristev wrote:
> > > > > Added property for DMA configuration of the device.
> > > > > 
> > > > > Signed-off-by: Eugen Hristev 
> > > > > ---
> > > > >   Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt | 7 
> > > > > +++
> > > > >   1 file changed, 7 insertions(+)
> > > > > 
> > > > > diff --git 
> > > > > a/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt 
> > > > > b/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > > > > index 552e7a8..5f94d479 100644
> > > > > --- a/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > > > > +++ b/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > > > > @@ -17,6 +17,11 @@ Required properties:
> > > > > This property uses the IRQ edge types values: 
> > > > > IRQ_TYPE_EDGE_RISING ,
> > > > > IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_EDGE_BOTH
> > > > > 
> > > > > +Optional properties:
> > > > > +  - dmas: Phandle to dma channel for the ADC.
> > > > > +  See ../../dma/dma.txt for details.
> > > > > +  - dma-names: Must be "rx" when dmas property is being used.
> > > > 
> > > > -names is pointless when there is only one.
> > > > 
> > > 
> > > You didn't reply to the question I had previously about that: What if at
> > > some point, we have multiple dmas in the same binding?
> > 
> > Then add dma-names at that point and rx has to be first. If you know
> > there's other channels, then add them now. Don't evolve the bindings
> > needlessly based on what a driver supports.
> > 
> > Would another channel make sense here? Maybe multi-channel rx in which
> > case your naming wouldn't be setup for that. But "tx" on an ADC?
> > 
> > Rob
> 
> Hello Rob,
> 
> I can keep only "dmas" and remove "dma-names", but then, the API used by
> the drivers that request channels requires a name parameter
> (dma_request_slave_channel), and it will look always inside the
> "dma-names" property to match the name and find the proper channel, and
> it will fail in this case.
> 
> Looking in the general dma binding (dma.txt) I can see that both
> properties are marked as required for a client driver, so that's why
> I added both.
> 

I don't understand why dma-names should be removed. For sure, if we have
only one channel, it becomes useless but the helpers to get a dma channel
rely on dma-names property.

Ludovic

> I can either keep dma-names; or try to find the channel properties by
> looking directly into the OF node and create the dma_chan struct inside
> my driver (maybe call some xlate function for the DMA controller), but
> still need to get the DT property. A complicated option would be to
> actually create an API inside the dmaengine to find a channel without
> name.
> 
> Which approach you think it's best to pursue ?
> 
> Thanks,
> Eugen
> 
> 
> 
> > 

Re: [PATCH v2 1/5] dt-bindings: iio: at91-sama5d2_adc: add optional dma property

[Ludovic Desroches]

On Tue, Nov 07, 2017 at 10:49:41AM +0200, Eugen Hristev wrote:
> 
> 
> On 20.10.2017 00:58, Rob Herring wrote:
> > On Thu, Oct 19, 2017 at 6:14 AM, Alexandre Belloni
> >  wrote:
> > > On 13/10/2017 at 16:51:42 -0500, Rob Herring wrote:
> > > > On Wed, Oct 11, 2017 at 09:35:28AM +0300, Eugen Hristev wrote:
> > > > > Added property for DMA configuration of the device.
> > > > > 
> > > > > Signed-off-by: Eugen Hristev 
> > > > > ---
> > > > >   Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt | 7 
> > > > > +++
> > > > >   1 file changed, 7 insertions(+)
> > > > > 
> > > > > diff --git 
> > > > > a/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt 
> > > > > b/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > > > > index 552e7a8..5f94d479 100644
> > > > > --- a/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > > > > +++ b/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > > > > @@ -17,6 +17,11 @@ Required properties:
> > > > > This property uses the IRQ edge types values: 
> > > > > IRQ_TYPE_EDGE_RISING ,
> > > > > IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_EDGE_BOTH
> > > > > 
> > > > > +Optional properties:
> > > > > +  - dmas: Phandle to dma channel for the ADC.
> > > > > +  See ../../dma/dma.txt for details.
> > > > > +  - dma-names: Must be "rx" when dmas property is being used.
> > > > 
> > > > -names is pointless when there is only one.
> > > > 
> > > 
> > > You didn't reply to the question I had previously about that: What if at
> > > some point, we have multiple dmas in the same binding?
> > 
> > Then add dma-names at that point and rx has to be first. If you know
> > there's other channels, then add them now. Don't evolve the bindings
> > needlessly based on what a driver supports.
> > 
> > Would another channel make sense here? Maybe multi-channel rx in which
> > case your naming wouldn't be setup for that. But "tx" on an ADC?
> > 
> > Rob
> 
> Hello Rob,
> 
> I can keep only "dmas" and remove "dma-names", but then, the API used by
> the drivers that request channels requires a name parameter
> (dma_request_slave_channel), and it will look always inside the
> "dma-names" property to match the name and find the proper channel, and
> it will fail in this case.
> 
> Looking in the general dma binding (dma.txt) I can see that both
> properties are marked as required for a client driver, so that's why
> I added both.
> 

I don't understand why dma-names should be removed. For sure, if we have
only one channel, it becomes useless but the helpers to get a dma channel
rely on dma-names property.

Ludovic

> I can either keep dma-names; or try to find the channel properties by
> looking directly into the OF node and create the dma_chan struct inside
> my driver (maybe call some xlate function for the DMA controller), but
> still need to get the DT property. A complicated option would be to
> actually create an API inside the dmaengine to find a channel without
> name.
> 
> Which approach you think it's best to pursue ?
> 
> Thanks,
> Eugen
> 
> 
> 
> > 

Re: [PATCH RFC 4/4] i2c: at91: take slave mode capabilities of hardware into account

[Ludovic Desroches]

On Fri, Nov 03, 2017 at 03:07:32PM +0100, Juergen Fitschen wrote:
> Hello Ludovic,
> 
> On Fri, Nov 03, 2017 at 09:46:02AM +0100, Ludovic Desroches wrote:
> > > > > diff --git a/drivers/i2c/busses/i2c-at91.h 
> > > > > b/drivers/i2c/busses/i2c-at91.h
> > > > > index bb502c1..4a4fa67 100644
> > > > > --- a/drivers/i2c/busses/i2c-at91.h
> > > > > +++ b/drivers/i2c/busses/i2c-at91.h
> > > > > @@ -107,9 +107,14 @@
> > > > >  
> > > > >  #define  AT91_TWI_VER0x00fc  /* Version Register */
> > > > >  
> > > > > +#define  AT91_TWI_SM_AVAILABLE   BIT(0)  /* Slave mode supported 
> > > > > */
> > > > > +#define  AT91_TWI_SM_CAN_NACKBIT(1)  /* Can send NACKs in 
> > > > > slave mode */
> > > > > +#define  AT91_TWI_SM_HAS_FIFOBIT(2)  /* Has FIFO for slave 
> > > > > mode */
> > > > > +
> > > > 
> > > > I would not add AT91_TWI_SM_CAN_NACK, AT91_TWI_SM_HAS_FIFO since there
> > > > is no code relying on them. Maybe you have some plans for the future?
> > > 
> > > Wolfram mentioned that supporting NACKs would be a welcome feature [1]. 
> > > But I
> > > haven't implemented it, yet. The same goes for FIFO support. ATM I am not 
> > > sure
> > > if my application will need this, since I am observing quite a lot clock
> > > stretching without FIFOs due to the occupied receive holding registered 
> > > (RHR).
> > > 
> > > BTW: Both implementations would be kind of controversal. Without using 
> > > FIFOs the
> > > desired NACK would be delayed by 1 byte (cf. my "artistic" ASCII graphic 
> > > [2]).
> > > If FIFOs are enabled the delay would be even larger. So the options are:
> > > 
> > >  * No NACKs at all
> > >  * NACKs delayed by 1 byte, no FIFOs
> > >  * NACKs delayed by n byte, with FIFOs
> > > 
> > > Non of these abovementioned options is optimal and fulfill the desired 
> > > behaviour
> > > (cf. section I2C_SLAVE_WRITE_RECEIVED of [3]).  Furthermore, AFAIK NACKs 
> > > and
> > > FIFOs are just supported by SAMA5D2x MPUs.
> > > 
> > > These are the main reasons why I haven't implented anything related to
> > > AT91_TWI_SM_CAN_NACK and AT91_TWI_SM_HAS_FIFO. The designware driver 
> > > ignores
> > > the NACK problem, as well.
> > > 
> > > Do you have an opinion on this topic?
> > > 
> > 
> > After discussing with the hardware guy, I confirm that we can't NACK the
> > byte we have just received. From his point of view and according to the
> > i2c specification it's not something that can be handled:
> > 
> > "On the byte level, a device may be able to receive bytes of data at a fast 
> > rate, but needs
> > more time to store a received byte or prepare another byte to be 
> > transmitted. Slaves can
> > then hold the SCL line LOW after reception and acknowledgment of a byte to 
> > force the
> > master into a wait state until the slave is ready for the next byte 
> > transfer in a type of
> > handshake procedure (see Figure 7)." From the Clock stretching section.
> > 
> > Since the clock stretching is only allowed after the acknowledgment, we
> > won't have time to change the ACK value for the byte we have just
> > received.
> 
> Thank you very much for being this investigative! I haven't known that clock
> stretching isn't allowed everywhere in a transmission. Maybe that's a little
> flaw in the slave mode interface. It forces hardware to violate the I2C 
> standard
> due to possible waiting time until the software tells the I2C interface 
> whether
> to ACK or to NACK.
> 

It seems but I am surprised that the slave framework may rely on a
violation of the I2C standard. Maybe it depends on the way the
specification is interpreted. It says that slaves can hold the SCL line
low after recepetion and acknowledgment but it doesn't says that it
can't before...

Wolfram, what's your mind about that?

> > 
> > I think using NACKs delayed by 1 byte is the only solution. Using FIFOs
> > should not be recommended for slave mode since it will delay the NACKs
> > in an unpredictable way, it'll depend on FIFOs content.
> > 
> 
> I'm going to implement this in the next version of the patch. I already found 
> a
> bug in the IRQ handler. So please wait with further testing until I released 
> the
> next version of the patchset. I really do not want to waste your time with a
> buggy driver. Further explanation of the bug will follow next week,
> 

Ok, thanks for the work you're doing.

Regards

Ludovic

Re: [PATCH RFC 4/4] i2c: at91: take slave mode capabilities of hardware into account

[Ludovic Desroches]

On Fri, Nov 03, 2017 at 03:07:32PM +0100, Juergen Fitschen wrote:
> Hello Ludovic,
> 
> On Fri, Nov 03, 2017 at 09:46:02AM +0100, Ludovic Desroches wrote:
> > > > > diff --git a/drivers/i2c/busses/i2c-at91.h 
> > > > > b/drivers/i2c/busses/i2c-at91.h
> > > > > index bb502c1..4a4fa67 100644
> > > > > --- a/drivers/i2c/busses/i2c-at91.h
> > > > > +++ b/drivers/i2c/busses/i2c-at91.h
> > > > > @@ -107,9 +107,14 @@
> > > > >  
> > > > >  #define  AT91_TWI_VER0x00fc  /* Version Register */
> > > > >  
> > > > > +#define  AT91_TWI_SM_AVAILABLE   BIT(0)  /* Slave mode supported 
> > > > > */
> > > > > +#define  AT91_TWI_SM_CAN_NACKBIT(1)  /* Can send NACKs in 
> > > > > slave mode */
> > > > > +#define  AT91_TWI_SM_HAS_FIFOBIT(2)  /* Has FIFO for slave 
> > > > > mode */
> > > > > +
> > > > 
> > > > I would not add AT91_TWI_SM_CAN_NACK, AT91_TWI_SM_HAS_FIFO since there
> > > > is no code relying on them. Maybe you have some plans for the future?
> > > 
> > > Wolfram mentioned that supporting NACKs would be a welcome feature [1]. 
> > > But I
> > > haven't implemented it, yet. The same goes for FIFO support. ATM I am not 
> > > sure
> > > if my application will need this, since I am observing quite a lot clock
> > > stretching without FIFOs due to the occupied receive holding registered 
> > > (RHR).
> > > 
> > > BTW: Both implementations would be kind of controversal. Without using 
> > > FIFOs the
> > > desired NACK would be delayed by 1 byte (cf. my "artistic" ASCII graphic 
> > > [2]).
> > > If FIFOs are enabled the delay would be even larger. So the options are:
> > > 
> > >  * No NACKs at all
> > >  * NACKs delayed by 1 byte, no FIFOs
> > >  * NACKs delayed by n byte, with FIFOs
> > > 
> > > Non of these abovementioned options is optimal and fulfill the desired 
> > > behaviour
> > > (cf. section I2C_SLAVE_WRITE_RECEIVED of [3]).  Furthermore, AFAIK NACKs 
> > > and
> > > FIFOs are just supported by SAMA5D2x MPUs.
> > > 
> > > These are the main reasons why I haven't implented anything related to
> > > AT91_TWI_SM_CAN_NACK and AT91_TWI_SM_HAS_FIFO. The designware driver 
> > > ignores
> > > the NACK problem, as well.
> > > 
> > > Do you have an opinion on this topic?
> > > 
> > 
> > After discussing with the hardware guy, I confirm that we can't NACK the
> > byte we have just received. From his point of view and according to the
> > i2c specification it's not something that can be handled:
> > 
> > "On the byte level, a device may be able to receive bytes of data at a fast 
> > rate, but needs
> > more time to store a received byte or prepare another byte to be 
> > transmitted. Slaves can
> > then hold the SCL line LOW after reception and acknowledgment of a byte to 
> > force the
> > master into a wait state until the slave is ready for the next byte 
> > transfer in a type of
> > handshake procedure (see Figure 7)." From the Clock stretching section.
> > 
> > Since the clock stretching is only allowed after the acknowledgment, we
> > won't have time to change the ACK value for the byte we have just
> > received.
> 
> Thank you very much for being this investigative! I haven't known that clock
> stretching isn't allowed everywhere in a transmission. Maybe that's a little
> flaw in the slave mode interface. It forces hardware to violate the I2C 
> standard
> due to possible waiting time until the software tells the I2C interface 
> whether
> to ACK or to NACK.
> 

It seems but I am surprised that the slave framework may rely on a
violation of the I2C standard. Maybe it depends on the way the
specification is interpreted. It says that slaves can hold the SCL line
low after recepetion and acknowledgment but it doesn't says that it
can't before...

Wolfram, what's your mind about that?

> > 
> > I think using NACKs delayed by 1 byte is the only solution. Using FIFOs
> > should not be recommended for slave mode since it will delay the NACKs
> > in an unpredictable way, it'll depend on FIFOs content.
> > 
> 
> I'm going to implement this in the next version of the patch. I already found 
> a
> bug in the IRQ handler. So please wait with further testing until I released 
> the
> next version of the patchset. I really do not want to waste your time with a
> buggy driver. Further explanation of the bug will follow next week,
> 

Ok, thanks for the work you're doing.

Regards

Ludovic

Re: [PATCH RFC 4/4] i2c: at91: take slave mode capabilities of hardware into account

[Ludovic Desroches]

Hi Juergen,

On Wed, Nov 01, 2017 at 12:16:36PM +0100, Juergen Fitschen wrote:
> Hello Ludovic,
> 
> Thank you very much for your feedback!
> 
> On Tue, Oct 31, 2017 at 04:22:50PM +0100, Ludovic Desroches wrote:
> > On Fri, Oct 27, 2017 at 05:12:17PM +0200, Juergen Fitschen wrote:
> > > Some AT91 hardware has no slave mode included or only limited features
> > > (i.e. no fifos).
> > > 
> > 
> > I am wondering if it won't be better to squash this patch into the
> > previous one:
> > Without it, it seems that we can set slave_detected for the RM9200 even
> > if it doesn't support the slave mode.
> 
> Good point. I will squash both patches into one in the next version. In the
> first place I wanted to support the review process by splitting the changes in
> two patches.
> 
> > > diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
> > > index bb502c1..4a4fa67 100644
> > > --- a/drivers/i2c/busses/i2c-at91.h
> > > +++ b/drivers/i2c/busses/i2c-at91.h
> > > @@ -107,9 +107,14 @@
> > >  
> > >  #define  AT91_TWI_VER0x00fc  /* Version Register */
> > >  
> > > +#define  AT91_TWI_SM_AVAILABLE   BIT(0)  /* Slave mode supported */
> > > +#define  AT91_TWI_SM_CAN_NACKBIT(1)  /* Can send NACKs in slave mode 
> > > */
> > > +#define  AT91_TWI_SM_HAS_FIFOBIT(2)  /* Has FIFO for slave mode */
> > > +
> > 
> > I would not add AT91_TWI_SM_CAN_NACK, AT91_TWI_SM_HAS_FIFO since there
> > is no code relying on them. Maybe you have some plans for the future?
> 
> Wolfram mentioned that supporting NACKs would be a welcome feature [1]. But I
> haven't implemented it, yet. The same goes for FIFO support. ATM I am not sure
> if my application will need this, since I am observing quite a lot clock
> stretching without FIFOs due to the occupied receive holding registered (RHR).
> 
> BTW: Both implementations would be kind of controversal. Without using FIFOs 
> the
> desired NACK would be delayed by 1 byte (cf. my "artistic" ASCII graphic [2]).
> If FIFOs are enabled the delay would be even larger. So the options are:
> 
>  * No NACKs at all
>  * NACKs delayed by 1 byte, no FIFOs
>  * NACKs delayed by n byte, with FIFOs
> 
> Non of these abovementioned options is optimal and fulfill the desired 
> behaviour
> (cf. section I2C_SLAVE_WRITE_RECEIVED of [3]).  Furthermore, AFAIK NACKs and
> FIFOs are just supported by SAMA5D2x MPUs.
> 
> These are the main reasons why I haven't implented anything related to
> AT91_TWI_SM_CAN_NACK and AT91_TWI_SM_HAS_FIFO. The designware driver ignores
> the NACK problem, as well.
> 
> Do you have an opinion on this topic?
> 

After discussing with the hardware guy, I confirm that we can't NACK the
byte we have just received. From his point of view and according to the
i2c specification it's not something that can be handled:

"On the byte level, a device may be able to receive bytes of data at a fast 
rate, but needs
more time to store a received byte or prepare another byte to be transmitted. 
Slaves can
then hold the SCL line LOW after reception and acknowledgment of a byte to 
force the
master into a wait state until the slave is ready for the next byte transfer in 
a type of
handshake procedure (see Figure 7)." From the Clock stretching section.

Since the clock stretching is only allowed after the acknowledgment, we
won't have time to change the ACK value for the byte we have just
received.

I think using NACKs delayed by 1 byte is the only solution. Using FIFOs
should not be recommended for slave mode since it will delay the NACKs
in an unpredictable way, it'll depend on FIFOs content.

Regards

Ludovic

> In the next version of this patchset I will remove this. I think readding 
> these
> flags if needed shouldn't be a big deal.
> 
> 
> Best regards
>   Juergen
> 
> 
> [1] https://marc.info/?l=linux-i2c=150831224824540=2
> [2] https://marc.info/?l=linux-i2c=150833171430595=2
> [3] https://www.kernel.org/doc/Documentation/i2c/slave-interface

Re: [PATCH RFC 4/4] i2c: at91: take slave mode capabilities of hardware into account

[Ludovic Desroches]

Hi Juergen,

On Wed, Nov 01, 2017 at 12:16:36PM +0100, Juergen Fitschen wrote:
> Hello Ludovic,
> 
> Thank you very much for your feedback!
> 
> On Tue, Oct 31, 2017 at 04:22:50PM +0100, Ludovic Desroches wrote:
> > On Fri, Oct 27, 2017 at 05:12:17PM +0200, Juergen Fitschen wrote:
> > > Some AT91 hardware has no slave mode included or only limited features
> > > (i.e. no fifos).
> > > 
> > 
> > I am wondering if it won't be better to squash this patch into the
> > previous one:
> > Without it, it seems that we can set slave_detected for the RM9200 even
> > if it doesn't support the slave mode.
> 
> Good point. I will squash both patches into one in the next version. In the
> first place I wanted to support the review process by splitting the changes in
> two patches.
> 
> > > diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
> > > index bb502c1..4a4fa67 100644
> > > --- a/drivers/i2c/busses/i2c-at91.h
> > > +++ b/drivers/i2c/busses/i2c-at91.h
> > > @@ -107,9 +107,14 @@
> > >  
> > >  #define  AT91_TWI_VER0x00fc  /* Version Register */
> > >  
> > > +#define  AT91_TWI_SM_AVAILABLE   BIT(0)  /* Slave mode supported */
> > > +#define  AT91_TWI_SM_CAN_NACKBIT(1)  /* Can send NACKs in slave mode 
> > > */
> > > +#define  AT91_TWI_SM_HAS_FIFOBIT(2)  /* Has FIFO for slave mode */
> > > +
> > 
> > I would not add AT91_TWI_SM_CAN_NACK, AT91_TWI_SM_HAS_FIFO since there
> > is no code relying on them. Maybe you have some plans for the future?
> 
> Wolfram mentioned that supporting NACKs would be a welcome feature [1]. But I
> haven't implemented it, yet. The same goes for FIFO support. ATM I am not sure
> if my application will need this, since I am observing quite a lot clock
> stretching without FIFOs due to the occupied receive holding registered (RHR).
> 
> BTW: Both implementations would be kind of controversal. Without using FIFOs 
> the
> desired NACK would be delayed by 1 byte (cf. my "artistic" ASCII graphic [2]).
> If FIFOs are enabled the delay would be even larger. So the options are:
> 
>  * No NACKs at all
>  * NACKs delayed by 1 byte, no FIFOs
>  * NACKs delayed by n byte, with FIFOs
> 
> Non of these abovementioned options is optimal and fulfill the desired 
> behaviour
> (cf. section I2C_SLAVE_WRITE_RECEIVED of [3]).  Furthermore, AFAIK NACKs and
> FIFOs are just supported by SAMA5D2x MPUs.
> 
> These are the main reasons why I haven't implented anything related to
> AT91_TWI_SM_CAN_NACK and AT91_TWI_SM_HAS_FIFO. The designware driver ignores
> the NACK problem, as well.
> 
> Do you have an opinion on this topic?
> 

After discussing with the hardware guy, I confirm that we can't NACK the
byte we have just received. From his point of view and according to the
i2c specification it's not something that can be handled:

"On the byte level, a device may be able to receive bytes of data at a fast 
rate, but needs
more time to store a received byte or prepare another byte to be transmitted. 
Slaves can
then hold the SCL line LOW after reception and acknowledgment of a byte to 
force the
master into a wait state until the slave is ready for the next byte transfer in 
a type of
handshake procedure (see Figure 7)." From the Clock stretching section.

Since the clock stretching is only allowed after the acknowledgment, we
won't have time to change the ACK value for the byte we have just
received.

I think using NACKs delayed by 1 byte is the only solution. Using FIFOs
should not be recommended for slave mode since it will delay the NACKs
in an unpredictable way, it'll depend on FIFOs content.

Regards

Ludovic

> In the next version of this patchset I will remove this. I think readding 
> these
> flags if needed shouldn't be a big deal.
> 
> 
> Best regards
>   Juergen
> 
> 
> [1] https://marc.info/?l=linux-i2c=150831224824540=2
> [2] https://marc.info/?l=linux-i2c=150833171430595=2
> [3] https://www.kernel.org/doc/Documentation/i2c/slave-interface

Re: [PATCH RFC 3/4] i2c: at91: added slave mode support

[Ludovic Desroches]

On Wed, Nov 01, 2017 at 02:04:18PM +0100, Juergen Fitschen wrote:
> Helle Ludovic,
> 
> while going through this patch a question related to the Atmel / Microchip HW
> came into mind:
> 
> On Fri, Oct 27, 2017 at 05:12:00PM +0200, Juergen Fitschen wrote:
> > diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
> > (...)
> >  #defineAT91_TWI_INT_MASK \
> > -   (AT91_TWI_TXCOMP | AT91_TWI_RXRDY | AT91_TWI_TXRDY | AT91_TWI_NACK)
> > +   (AT91_TWI_TXCOMP | AT91_TWI_RXRDY | AT91_TWI_TXRDY | AT91_TWI_NACK \
> > +   | AT91_TWI_SVACC | AT91_TWI_EOSACC)
> 
> The AT91_TWI_INT_MASK is used to disable all interrputs in the
> at91_disable_twi_interrupts function by writing the mask to the interrupt
> disable register (IDR). I wonder what happens on MPUs that don't have
> AT91_TWI_SVACC and AT91_TWI_EOSACC implemented, like the AT91RM9200? Do you
> think we should revise this and write specific masks depending on the current
> moude the I2C HW is in?
> 
> Something like this:
> 
> void at91_disable_twi_interrupts(struct at91_twi_dev *dev)
> {
> if (dev->slave_detected)
> at91_twi_write(dev, AT91_TWI_IDR, AT91_TWI_INT_MASK_SLAVE);
> else
> at91_twi_write(dev, AT91_TWI_IDR, AT91_TWI_INT_MASK_MASTER);
> }
> 

I don't think it's necessary. Usually, writing a bit which is unused don't
cause weird behaviors.

Regards

Ludovic

Re: [PATCH RFC 3/4] i2c: at91: added slave mode support

[Ludovic Desroches]

On Wed, Nov 01, 2017 at 02:04:18PM +0100, Juergen Fitschen wrote:
> Helle Ludovic,
> 
> while going through this patch a question related to the Atmel / Microchip HW
> came into mind:
> 
> On Fri, Oct 27, 2017 at 05:12:00PM +0200, Juergen Fitschen wrote:
> > diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
> > (...)
> >  #defineAT91_TWI_INT_MASK \
> > -   (AT91_TWI_TXCOMP | AT91_TWI_RXRDY | AT91_TWI_TXRDY | AT91_TWI_NACK)
> > +   (AT91_TWI_TXCOMP | AT91_TWI_RXRDY | AT91_TWI_TXRDY | AT91_TWI_NACK \
> > +   | AT91_TWI_SVACC | AT91_TWI_EOSACC)
> 
> The AT91_TWI_INT_MASK is used to disable all interrputs in the
> at91_disable_twi_interrupts function by writing the mask to the interrupt
> disable register (IDR). I wonder what happens on MPUs that don't have
> AT91_TWI_SVACC and AT91_TWI_EOSACC implemented, like the AT91RM9200? Do you
> think we should revise this and write specific masks depending on the current
> moude the I2C HW is in?
> 
> Something like this:
> 
> void at91_disable_twi_interrupts(struct at91_twi_dev *dev)
> {
> if (dev->slave_detected)
> at91_twi_write(dev, AT91_TWI_IDR, AT91_TWI_INT_MASK_SLAVE);
> else
> at91_twi_write(dev, AT91_TWI_IDR, AT91_TWI_INT_MASK_MASTER);
> }
> 

I don't think it's necessary. Usually, writing a bit which is unused don't
cause weird behaviors.

Regards

Ludovic

Re: [PATCH RFC 4/4] i2c: at91: take slave mode capabilities of hardware into account

[Ludovic Desroches]

On Wed, Nov 01, 2017 at 12:16:36PM +0100, Juergen Fitschen wrote:
> Hello Ludovic,
> 
> Thank you very much for your feedback!
> 
> On Tue, Oct 31, 2017 at 04:22:50PM +0100, Ludovic Desroches wrote:
> > On Fri, Oct 27, 2017 at 05:12:17PM +0200, Juergen Fitschen wrote:
> > > Some AT91 hardware has no slave mode included or only limited features
> > > (i.e. no fifos).
> > > 
> > 
> > I am wondering if it won't be better to squash this patch into the
> > previous one:
> > Without it, it seems that we can set slave_detected for the RM9200 even
> > if it doesn't support the slave mode.
> 
> Good point. I will squash both patches into one in the next version. In the
> first place I wanted to support the review process by splitting the changes in
> two patches.
> 
> > > diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
> > > index bb502c1..4a4fa67 100644
> > > --- a/drivers/i2c/busses/i2c-at91.h
> > > +++ b/drivers/i2c/busses/i2c-at91.h
> > > @@ -107,9 +107,14 @@
> > >  
> > >  #define  AT91_TWI_VER0x00fc  /* Version Register */
> > >  
> > > +#define  AT91_TWI_SM_AVAILABLE   BIT(0)  /* Slave mode supported */
> > > +#define  AT91_TWI_SM_CAN_NACKBIT(1)  /* Can send NACKs in slave mode 
> > > */
> > > +#define  AT91_TWI_SM_HAS_FIFOBIT(2)  /* Has FIFO for slave mode */
> > > +
> > 
> > I would not add AT91_TWI_SM_CAN_NACK, AT91_TWI_SM_HAS_FIFO since there
> > is no code relying on them. Maybe you have some plans for the future?
> 
> Wolfram mentioned that supporting NACKs would be a welcome feature [1]. But I
> haven't implemented it, yet. The same goes for FIFO support. ATM I am not sure
> if my application will need this, since I am observing quite a lot clock
> stretching without FIFOs due to the occupied receive holding registered (RHR).
> 
> BTW: Both implementations would be kind of controversal. Without using FIFOs 
> the
> desired NACK would be delayed by 1 byte (cf. my "artistic" ASCII graphic [2]).
> If FIFOs are enabled the delay would be even larger. So the options are:
> 
>  * No NACKs at all
>  * NACKs delayed by 1 byte, no FIFOs
>  * NACKs delayed by n byte, with FIFOs
> 
> Non of these abovementioned options is optimal and fulfill the desired 
> behaviour
> (cf. section I2C_SLAVE_WRITE_RECEIVED of [3]).  Furthermore, AFAIK NACKs and
> FIFOs are just supported by SAMA5D2x MPUs.
> 
> These are the main reasons why I haven't implented anything related to
> AT91_TWI_SM_CAN_NACK and AT91_TWI_SM_HAS_FIFO. The designware driver ignores
> the NACK problem, as well.
> 
> Do you have an opinion on this topic?
> 

Not really, I'll discuss with the hardware guy to see how we can manage
NACKs or at least how we can improve it for next versions of the
controller.

Regards

Ludovic

> In the next version of this patchset I will remove this. I think readding 
> these
> flags if needed shouldn't be a big deal.
> 
> 
> Best regards
>   Juergen
> 
> 
> [1] https://marc.info/?l=linux-i2c=150831224824540=2
> [2] https://marc.info/?l=linux-i2c=150833171430595=2
> [3] https://www.kernel.org/doc/Documentation/i2c/slave-interface

Re: [PATCH RFC 4/4] i2c: at91: take slave mode capabilities of hardware into account

[Ludovic Desroches]

On Wed, Nov 01, 2017 at 12:16:36PM +0100, Juergen Fitschen wrote:
> Hello Ludovic,
> 
> Thank you very much for your feedback!
> 
> On Tue, Oct 31, 2017 at 04:22:50PM +0100, Ludovic Desroches wrote:
> > On Fri, Oct 27, 2017 at 05:12:17PM +0200, Juergen Fitschen wrote:
> > > Some AT91 hardware has no slave mode included or only limited features
> > > (i.e. no fifos).
> > > 
> > 
> > I am wondering if it won't be better to squash this patch into the
> > previous one:
> > Without it, it seems that we can set slave_detected for the RM9200 even
> > if it doesn't support the slave mode.
> 
> Good point. I will squash both patches into one in the next version. In the
> first place I wanted to support the review process by splitting the changes in
> two patches.
> 
> > > diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
> > > index bb502c1..4a4fa67 100644
> > > --- a/drivers/i2c/busses/i2c-at91.h
> > > +++ b/drivers/i2c/busses/i2c-at91.h
> > > @@ -107,9 +107,14 @@
> > >  
> > >  #define  AT91_TWI_VER0x00fc  /* Version Register */
> > >  
> > > +#define  AT91_TWI_SM_AVAILABLE   BIT(0)  /* Slave mode supported */
> > > +#define  AT91_TWI_SM_CAN_NACKBIT(1)  /* Can send NACKs in slave mode 
> > > */
> > > +#define  AT91_TWI_SM_HAS_FIFOBIT(2)  /* Has FIFO for slave mode */
> > > +
> > 
> > I would not add AT91_TWI_SM_CAN_NACK, AT91_TWI_SM_HAS_FIFO since there
> > is no code relying on them. Maybe you have some plans for the future?
> 
> Wolfram mentioned that supporting NACKs would be a welcome feature [1]. But I
> haven't implemented it, yet. The same goes for FIFO support. ATM I am not sure
> if my application will need this, since I am observing quite a lot clock
> stretching without FIFOs due to the occupied receive holding registered (RHR).
> 
> BTW: Both implementations would be kind of controversal. Without using FIFOs 
> the
> desired NACK would be delayed by 1 byte (cf. my "artistic" ASCII graphic [2]).
> If FIFOs are enabled the delay would be even larger. So the options are:
> 
>  * No NACKs at all
>  * NACKs delayed by 1 byte, no FIFOs
>  * NACKs delayed by n byte, with FIFOs
> 
> Non of these abovementioned options is optimal and fulfill the desired 
> behaviour
> (cf. section I2C_SLAVE_WRITE_RECEIVED of [3]).  Furthermore, AFAIK NACKs and
> FIFOs are just supported by SAMA5D2x MPUs.
> 
> These are the main reasons why I haven't implented anything related to
> AT91_TWI_SM_CAN_NACK and AT91_TWI_SM_HAS_FIFO. The designware driver ignores
> the NACK problem, as well.
> 
> Do you have an opinion on this topic?
> 

Not really, I'll discuss with the hardware guy to see how we can manage
NACKs or at least how we can improve it for next versions of the
controller.

Regards

Ludovic

> In the next version of this patchset I will remove this. I think readding 
> these
> flags if needed shouldn't be a big deal.
> 
> 
> Best regards
>   Juergen
> 
> 
> [1] https://marc.info/?l=linux-i2c=150831224824540=2
> [2] https://marc.info/?l=linux-i2c=150833171430595=2
> [3] https://www.kernel.org/doc/Documentation/i2c/slave-interface