On Wed, Jun 24, 2015 at 12:08:50AM +0200, Stefan Agner wrote: > On 2015-06-23 11:22, Johan Hovold wrote: > > On Mon, Jun 22, 2015 at 10:11:35PM +0200, Stefan Agner wrote: > >> On 2015-06-22 19:26, Johan Hovold wrote: > > > >> > Instead, hang the gpio chip directly off the usb interface (not the > >> > port), add a new config option, and keep the gpio implementation under > >> > drivers/usb/serial (possibly in its own file ftdi_sio-gpio.c). > >> > >> Agreed sounds like a good plan. Will try this approach in v2. > >> > >> Except I don't think hanging it directly to the USB interface is the > >> right thing to do. > >> > >> Looking at the block diagram of FT232R or FT232H, the CBUS pins seem to > >> be part of the UART/FIFO controller. And I think the dual UART FT2232D > >> actually supports controlling the CBUS pins of the two UART controllers > >> individually, at least the block diagram thereof suggests so. > > > > The port is a Linux abstraction, and for FTDI we happen to have exactly > > one port child device per USB interface. As I see it, the gpio > > controller for the CBUS pins should be a sibling rather than a child > > device to the port. > > > > Note that we'd still have two gpio-controllers on FT2232D (one per USB > > interface). > > I did some research. I think the FT2232D or FT2232H devices do not > support the CBUS Bit Bang mode. For instance the D2XX Programmer's Guide > indicates that on page 69 (CBUS Bit Bang Mode (FT232R and FT232H devices > only)) as well as the AN_184 "FTDI Device Input Output Pin States", does > not mention that the CBUS pins as EEPROM selectable (the same document > does so for FT232R/FT232H devices)... > > I don't have such a device, hence I can't try it out... Just make sure to only register the gpio chip for device types that support it (and devices that are configured for it...). > > I'm aware that this requires some restructuring of the ftdi_sio-driver > > (e.g. the device type and ftdi-interface number should be a feature of > > the usb-serial rather than usb-serial-port device). > > The findings above probably do not change the fact that we should not > use the Linux port abstraction to attach the GPIO controller... > > I looked into that a bit more in depth. Do I see things right that the > multi-port devices have multiple USB interfaces, which leads to > usb_serial_probe and in turn ftdi_sio_probe getting called multiple > times by the USB stack? If yes, I think I have the bigger picture to go > ahead and try to implement it accordingly. Yes, that is correct. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
