Adding GPIO/SPI/I2C functionality to FTDI driver

Adding GPIO/SPI/I2C functionality to FTDI driver

[chrysn]

Hello kernelnewbies list,

I've run into situations where it would be practical to have the GPIO,
I2C and SPI functionality some FTDI chips provide as kernel devices.
(The chips are more often used as USB serial adapters; only that feature
is supported by the current kernel drivers).

The presence of an extensive userspace library (libftdi) and the
observation of a project in a similar situation[1] that has not made it
into the kernel makes me doubt that implementing that in the kernel is
the way to go.

I've written up more thoughts on this on [2], including exploration of
userspace SPI/GPIO/I2C devices (think FUSE / USBIP / uinput), but it
boils down to a simple question:


Is support for alternative operation modes in FTDI chips something that
is welcome and (easily) feasible in the kernel?


Best regards
chrysn


[1] http://danielthesantos.blogspot.co.at/2013/08/why-mcp2210-driver.html
[2] http://christian.amsuess.com/idea-incubator/ftdi-kernel-support/

-- 
You don't become great by trying to be great. You become great by
wanting to do something, and then doing it so hard that you become great
in the process.
  -- Marie Curie (as quoted by Randall Munroe)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150922/f2c84960/attachment.bin 

Adding GPIO/SPI/I2C functionality to FTDI driver

[Greg KH]

On Tue, Sep 22, 2015 at 06:28:47PM +0200, chrysn wrote:
> Hello kernelnewbies list,
> 
> I've run into situations where it would be practical to have the GPIO,
> I2C and SPI functionality some FTDI chips provide as kernel devices.
> (The chips are more often used as USB serial adapters; only that feature
> is supported by the current kernel drivers).
> 
> The presence of an extensive userspace library (libftdi) and the
> observation of a project in a similar situation[1] that has not made it
> into the kernel makes me doubt that implementing that in the kernel is
> the way to go.
> 
> I've written up more thoughts on this on [2], including exploration of
> userspace SPI/GPIO/I2C devices (think FUSE / USBIP / uinput), but it
> boils down to a simple question:
> 
> 
> Is support for alternative operation modes in FTDI chips something that
> is welcome and (easily) feasible in the kernel?

This comes up every other month or so on the linux-usb mailing list.
See the discussions there about how to do this properly in a way that
will be accepted by the USB maintainers if you wish to do this work.

And yes, this would be very welcome, but no one seems to be willing to
do the work :(

thanks,

greg k-h

Adding GPIO/SPI/I2C functionality to FTDI driver

[chrysn]

Hallo Stefan, hallo Philipp,
hello Johan and Greg,

On Tue, Sep 22, 2015 at 12:02:03PM -0700, Greg KH wrote:
> On Tue, Sep 22, 2015 at 06:28:47PM +0200, chrysn wrote:
> > Is support for alternative operation modes in FTDI chips something that
> > is welcome and (easily) feasible in the kernel?
> 
> This comes up every other month or so on the linux-usb mailing list.
> See the discussions there about how to do this properly in a way that
> will be accepted by the USB maintainers if you wish to do this work.

I've overlooked your two recent approaches when looking for existing
approaches towards extending FTDI support in the kernel (probably due to
me being too focused at SPI).

Stefan and Philipp, has any of your patch sets received updates in the
meantime that have not been sent to the mailing list?

It seems that one issue that needs to be solved for either of those to
continue is the decision of whether to base the FTDI driver on the MFD
infrastructure (which would probably be a first step then before even
implementing any of SPI, GPIO or I2C interfaces). There have been
conflicting opinions on this in different threads ([1], [2]); my
impression is that it would be a good idea, given that many of the more
recent FTDI devices can be switched to half a dozen configurations, and
that they are also shipped in products[3] where several of them would be
used in a coordinated fashion similar to the shields of widespread
embedded systems.

Johan and Greg, can you reconcile your opinions on that? Or whom is that
question best discussed with? devicetree? linux-usb?  linux-gpio / -spi
/ -i2c?

Best regards
chrysn

PS. I've updated the summary I'm keeping of what led to this thread on
[4] -- all directly relevant information / questions should be in the
mails, but the page should provide further background for the curious.

[1] https://lkml.org/lkml/2014/6/1/250
[2] https://lkml.org/lkml/2015/6/22/451
[3] http://www.mikroe.com/click/usb-adapter/
[4] http://christian.amsuess.com/idea-incubator/ftdi-kernel-support/

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150923/a46e66ab/attachment-0001.bin 

Adding GPIO/SPI/I2C functionality to FTDI driver

[Philipp Hachtmann]

> Stefan and Philipp, has any of your patch sets received updates in the
> meantime that have not been sent to the mailing list?
No, sorry. They did not even want to have my syncmode patch. For me the biggest 
problem is that the ftdi_sio driver is buried in that generic tty/usb-tty stuff 
which I don't have fully understood yet (and not found the time to really 
investigate)

Kind regards

Philipp

Adding GPIO/SPI/I2C functionality to FTDI driver

[Johan Hovold]

On Wed, Sep 23, 2015 at 05:40:58PM +0200, chrysn wrote:
> Hallo Stefan, hallo Philipp,
> hello Johan and Greg,
> 
> On Tue, Sep 22, 2015 at 12:02:03PM -0700, Greg KH wrote:
> > On Tue, Sep 22, 2015 at 06:28:47PM +0200, chrysn wrote:
> > > Is support for alternative operation modes in FTDI chips something that
> > > is welcome and (easily) feasible in the kernel?
> > 
> > This comes up every other month or so on the linux-usb mailing list.
> > See the discussions there about how to do this properly in a way that
> > will be accepted by the USB maintainers if you wish to do this work.
> 
> I've overlooked your two recent approaches when looking for existing
> approaches towards extending FTDI support in the kernel (probably due to
> me being too focused at SPI).
> 
> Stefan and Philipp, has any of your patch sets received updates in the
> meantime that have not been sent to the mailing list?
> 
> It seems that one issue that needs to be solved for either of those to
> continue is the decision of whether to base the FTDI driver on the MFD
> infrastructure (which would probably be a first step then before even
> implementing any of SPI, GPIO or I2C interfaces). There have been
> conflicting opinions on this in different threads ([1], [2]); my
> impression is that it would be a good idea, given that many of the more
> recent FTDI devices can be switched to half a dozen configurations, and
> that they are also shipped in products[3] where several of them would be
> used in a coordinated fashion similar to the shields of widespread
> embedded systems.
> 
> Johan and Greg, can you reconcile your opinions on that? Or whom is that
> question best discussed with? devicetree? linux-usb?  linux-gpio / -spi
> / -i2c?

That would be linux-usb.

These devices are serial device and there's no need to use MFD when
implementing support for controlling any additional pins that can be
used for GPIO. Just hang the gpio controller off the usb-serial device
(i.e. the USB Interface).

If these devices can be programmed to be used in other modes, then we'd
need a way to detect that and refuse to bind the serial driver at probe.
A dedicated I2C or SPI driver could then be allowed to bind instead.

Thanks,
Johan