[1/3] mfd: Add support for FTDI FT232H devices
diff mbox

Message ID 1499374158-12388-2-git-send-email-agust@denx.de
State Superseded, archived
Headers show

Commit Message

Anatolij Gustschin July 6, 2017, 8:49 p.m. UTC
Add USB part with common functions for USB-GPIO/I2C/SPI master
adapters. These allow communication with chip's control, transmit
and receive endpoints and will be used by various FT232H drivers.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
 drivers/mfd/Kconfig           |   9 +
 drivers/mfd/Makefile          |   1 +
 drivers/mfd/ftdi-ft232h.c     | 470 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/mfd/ftdi/ftdi.h |  71 +++++++
 4 files changed, 551 insertions(+)
 create mode 100644 drivers/mfd/ftdi-ft232h.c
 create mode 100644 include/linux/mfd/ftdi/ftdi.h

Comments

Bjørn Mork July 7, 2017, 7:48 a.m. UTC | #1
[adding Johan on the CC list]

Anatolij Gustschin <agust@denx.de> writes:

> +static struct usb_device_id ftdi_mfd_table[] = {
> +	{ USB_DEVICE(0x0403, 0x6014) },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);

This device ID is currently handled by the ftdi_sio driver, so I believe
you at least have to explain how you intend these two drivers to
cooperate...



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anatolij Gustschin July 7, 2017, 9:53 a.m. UTC | #2
On Fri, 07 Jul 2017 09:48:48 +0200
Bjørn Mork bjorn@mork.no wrote:

>[adding Johan on the CC list]
>
>Anatolij Gustschin <agust@denx.de> writes:
>
>> +static struct usb_device_id ftdi_mfd_table[] = {
>> +	{ USB_DEVICE(0x0403, 0x6014) },
>> +	{}
>> +};
>> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);  
>
>This device ID is currently handled by the ftdi_sio driver, so I believe
>you at least have to explain how you intend these two drivers to
>cooperate...

these drivers cannot cooperate, the different ftdi function modes
use same device pins as in UART mode. So, you either can use the
device in UART interface mode or in some different mode. I do not
load the ftdi_sio module or do unbind the USB device from the
ftdio_sio driver and bind it to the mfd driver, e.g.:

  sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
  sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"

thanks,

Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Johan Hovold July 10, 2017, 12:34 p.m. UTC | #3
On Fri, Jul 07, 2017 at 11:53:29AM +0200, Anatolij Gustschin wrote:
> On Fri, 07 Jul 2017 09:48:48 +0200
> Bjørn Mork bjorn@mork.no wrote:
> 
> >[adding Johan on the CC list]
> >
> >Anatolij Gustschin <agust@denx.de> writes:
> >
> >> +static struct usb_device_id ftdi_mfd_table[] = {
> >> +	{ USB_DEVICE(0x0403, 0x6014) },
> >> +	{}
> >> +};
> >> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);  
> >
> >This device ID is currently handled by the ftdi_sio driver, so I believe
> >you at least have to explain how you intend these two drivers to
> >cooperate...
> 
> these drivers cannot cooperate, the different ftdi function modes
> use same device pins as in UART mode. So, you either can use the
> device in UART interface mode or in some different mode. I do not
> load the ftdi_sio module or do unbind the USB device from the
> ftdio_sio driver and bind it to the mfd driver, e.g.:
> 
>   sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
>   sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"

I'm afraid that's not good enough. If we're going to support a non-UART
mode through a separate driver, we need to have all drivers for these
devices be able to retrieve the current mode during probe and only bind
when the mode matches.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Johan Hovold July 10, 2017, 12:52 p.m. UTC | #4
On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
> Add USB part with common functions for USB-GPIO/I2C/SPI master
> adapters. These allow communication with chip's control, transmit
> and receive endpoints and will be used by various FT232H drivers.

> +static const struct mfd_cell ftdi_cells[] = {
> +	{ .name = "ftdi-cbus-gpio", },
> +	{ .name = "ftdi-mpsse-i2c", },
> +	{ .name = "ftdi-mpsse-spi", },
> +	{ .name = "ftdi-fifo-fpp-mgr", },
> +};

Correct me if I'm wrong, but aren't these modes really mutually
exclusive, possibly with exception of cbus-gpio (some pins are at least
available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
here either.

And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
seems too application specific for a generic chip like this.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anatolij Gustschin July 11, 2017, 6:52 a.m. UTC | #5
On Mon, 10 Jul 2017 14:34:27 +0200
Johan Hovold johan@kernel.org wrote:

>On Fri, Jul 07, 2017 at 11:53:29AM +0200, Anatolij Gustschin wrote:
>> On Fri, 07 Jul 2017 09:48:48 +0200
>> Bjørn Mork bjorn@mork.no wrote:
>>   
>> >[adding Johan on the CC list]
>> >
>> >Anatolij Gustschin <agust@denx.de> writes:
>> >  
>> >> +static struct usb_device_id ftdi_mfd_table[] = {
>> >> +	{ USB_DEVICE(0x0403, 0x6014) },
>> >> +	{}
>> >> +};
>> >> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);    
>> >
>> >This device ID is currently handled by the ftdi_sio driver, so I believe
>> >you at least have to explain how you intend these two drivers to
>> >cooperate...  
>> 
>> these drivers cannot cooperate, the different ftdi function modes
>> use same device pins as in UART mode. So, you either can use the
>> device in UART interface mode or in some different mode. I do not
>> load the ftdi_sio module or do unbind the USB device from the
>> ftdio_sio driver and bind it to the mfd driver, e.g.:
>> 
>>   sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
>>   sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"  
>
>I'm afraid that's not good enough. If we're going to support a non-UART
>mode through a separate driver, we need to have all drivers for these
>devices be able to retrieve the current mode during probe and only bind
>when the mode matches.

Can we reliably retrieve the current mode? For devices with connected
EEPROM some modes (including UART) are configurable in the EEPROM. For
devices without EEPROM the default mode is always UART, but FIFO-,
Bitbang- and MPSSE-mode can be switched via commands to the the chip.

Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Johan Hovold July 12, 2017, 8:50 a.m. UTC | #6
On Tue, Jul 11, 2017 at 08:52:37AM +0200, Anatolij Gustschin wrote:
> On Mon, 10 Jul 2017 14:34:27 +0200
> Johan Hovold johan@kernel.org wrote:
> 
> >On Fri, Jul 07, 2017 at 11:53:29AM +0200, Anatolij Gustschin wrote:
> >> On Fri, 07 Jul 2017 09:48:48 +0200
> >> Bjørn Mork bjorn@mork.no wrote:
> >>   
> >> >[adding Johan on the CC list]
> >> >
> >> >Anatolij Gustschin <agust@denx.de> writes:
> >> >  
> >> >> +static struct usb_device_id ftdi_mfd_table[] = {
> >> >> +	{ USB_DEVICE(0x0403, 0x6014) },
> >> >> +	{}
> >> >> +};
> >> >> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);    
> >> >
> >> >This device ID is currently handled by the ftdi_sio driver, so I believe
> >> >you at least have to explain how you intend these two drivers to
> >> >cooperate...  
> >> 
> >> these drivers cannot cooperate, the different ftdi function modes
> >> use same device pins as in UART mode. So, you either can use the
> >> device in UART interface mode or in some different mode. I do not
> >> load the ftdi_sio module or do unbind the USB device from the
> >> ftdio_sio driver and bind it to the mfd driver, e.g.:
> >> 
> >>   sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
> >>   sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"  
> >
> >I'm afraid that's not good enough. If we're going to support a non-UART
> >mode through a separate driver, we need to have all drivers for these
> >devices be able to retrieve the current mode during probe and only bind
> >when the mode matches.
> 
> Can we reliably retrieve the current mode? 

You tell me. ;)

> For devices with connected EEPROM some modes (including UART) are
> configurable in the EEPROM. For devices without EEPROM the default
> mode is always UART, but FIFO-, Bitbang- and MPSSE-mode can be
> switched via commands to the the chip.

IIRC we should be able read from the EEPROM, and I would at least expect
there to be a way to retrieve the current mode as well.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjørn Mork July 12, 2017, 9:11 a.m. UTC | #7
Johan Hovold <johan@kernel.org> writes:
> On Tue, Jul 11, 2017 at 08:52:37AM +0200, Anatolij Gustschin wrote:
>
>> For devices with connected EEPROM some modes (including UART) are
>> configurable in the EEPROM. For devices without EEPROM the default
>> mode is always UART, but FIFO-, Bitbang- and MPSSE-mode can be
>> switched via commands to the the chip.
>
> IIRC we should be able read from the EEPROM, and I would at least expect
> there to be a way to retrieve the current mode as well.

Stupid question, I know, but I cannot help thinking: If you have an
EEPROM then why the h... don't you use an application specific device
ID?


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anatolij Gustschin July 13, 2017, 4:32 p.m. UTC | #8
On Wed, 12 Jul 2017 10:50:03 +0200
Johan Hovold johan@kernel.org wrote:
...
>IIRC we should be able read from the EEPROM, and I would at least expect
>there to be a way to retrieve the current mode as well.

I've just send a patch for ftdi_sio.

Thanks,

Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Johan Hovold July 19, 2017, 8:59 a.m. UTC | #9
On Mon, Jul 10, 2017 at 02:52:10PM +0200, Johan Hovold wrote:
> On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
> > Add USB part with common functions for USB-GPIO/I2C/SPI master
> > adapters. These allow communication with chip's control, transmit
> > and receive endpoints and will be used by various FT232H drivers.
> 
> > +static const struct mfd_cell ftdi_cells[] = {
> > +	{ .name = "ftdi-cbus-gpio", },
> > +	{ .name = "ftdi-mpsse-i2c", },
> > +	{ .name = "ftdi-mpsse-spi", },
> > +	{ .name = "ftdi-fifo-fpp-mgr", },
> > +};
> 
> Correct me if I'm wrong, but aren't these modes really mutually
> exclusive, possibly with exception of cbus-gpio (some pins are at least
> available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
> here either.

You never replied to this, and I'm afraid there are more issue with this
series.

> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
> seems too application specific for a generic chip like this.

Of which this is one is one of the major.

In short, your driver is much to application specific and is probably
something that needs to be implemented in userspace using libftdi.

Speaking of libftdi, you seem to have copied or borrowed a lot of code
and protocol from libftdi and this should have been mentioned in commit
messages and file headers (not just in a comment to one specific
function).

These chips can be used for a many different applications (also in FIFO
mode) so you cannot tie a driver to it exposing just a specific
interface for programming a certain class of FPGAs.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anatolij Gustschin July 19, 2017, 11:58 a.m. UTC | #10
On Mon, 10 Jul 2017 14:52:10 +0200
Johan Hovold johan@kernel.org wrote:

>On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
>> Add USB part with common functions for USB-GPIO/I2C/SPI master
>> adapters. These allow communication with chip's control, transmit
>> and receive endpoints and will be used by various FT232H drivers.  
>
>> +static const struct mfd_cell ftdi_cells[] = {
>> +	{ .name = "ftdi-cbus-gpio", },
>> +	{ .name = "ftdi-mpsse-i2c", },
>> +	{ .name = "ftdi-mpsse-spi", },
>> +	{ .name = "ftdi-fifo-fpp-mgr", },
>> +};  
>
>Correct me if I'm wrong, but aren't these modes really mutually
>exclusive, possibly with exception of cbus-gpio (some pins are at least
>available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
>here either.

MPSSE and FIFO modes are mutually exclusive, but I'm not sure about
MPSSE and CBUS-GPIO. CBUS-GPIO didn't work as expected when I was
testing with MPSSE SPI master driver, but maybe it is a driver issue.
FT245 FIFO and CBUS GPIO can be switched by a control request, when
FIFO mode is configured in the EEPROM.

>And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
>seems too application specific for a generic chip like this.

Yes, I agree. I'm thinking of a rework to add a FIFO driver instead
and use it in the fpp-mgr driver. Is that the right direction? 

Thanks,
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anatolij Gustschin July 19, 2017, 12:59 p.m. UTC | #11
On Wed, 19 Jul 2017 10:59:34 +0200
Johan Hovold johan@kernel.org wrote:
...
>> > +static const struct mfd_cell ftdi_cells[] = {
>> > +	{ .name = "ftdi-cbus-gpio", },
>> > +	{ .name = "ftdi-mpsse-i2c", },
>> > +	{ .name = "ftdi-mpsse-spi", },
>> > +	{ .name = "ftdi-fifo-fpp-mgr", },
>> > +};  
>> 
>> Correct me if I'm wrong, but aren't these modes really mutually
>> exclusive, possibly with exception of cbus-gpio (some pins are at least
>> available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
>> here either.  
>
>You never replied to this, and I'm afraid there are more issue with this
>series.

Sorry, unfortunately I'm too busy with other stuff. Will try to find
time to rework.

>> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
>> seems too application specific for a generic chip like this.  
>
>Of which this is one is one of the major.

Thanks all for feedback. I'm still pondering how to interface the
fpga manager driver to FTDI FIFO driver.

>In short, your driver is much to application specific and is probably
>something that needs to be implemented in userspace using libftdi.

I have a requirement to use the fpga manager framework, therefore the
kernel driver is needed. Our usage scenario is a multi stage fpga
configuration process, the first stage is a pre-configuration via
FTDI SPI/FIFO, all subsequent stages are also done by other fpga
manager drivers. libftdi based driver already existed for hardware
bring-up, now I need similar functionality as kernel fpga manager.

>Speaking of libftdi, you seem to have copied or borrowed a lot of code
>and protocol from libftdi and this should have been mentioned in commit
>messages and file headers (not just in a comment to one specific
>function).

I'll mention this in next patch series.

>These chips can be used for a many different applications (also in FIFO
>mode) so you cannot tie a driver to it exposing just a specific
>interface for programming a certain class of FPGAs.

Agreed.

Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anatolij Gustschin July 19, 2017, 1:29 p.m. UTC | #12
On Wed, 12 Jul 2017 11:11:46 +0200
Bjørn Mork bjorn@mork.no wrote:

>Johan Hovold <johan@kernel.org> writes:
>> On Tue, Jul 11, 2017 at 08:52:37AM +0200, Anatolij Gustschin wrote:
>>  
>>> For devices with connected EEPROM some modes (including UART) are
>>> configurable in the EEPROM. For devices without EEPROM the default
>>> mode is always UART, but FIFO-, Bitbang- and MPSSE-mode can be
>>> switched via commands to the the chip.  
>>
>> IIRC we should be able read from the EEPROM, and I would at least expect
>> there to be a way to retrieve the current mode as well.  
>
>Stupid question, I know, but I cannot help thinking: If you have an
>EEPROM then why the h... don't you use an application specific device
>ID?

It would make sense for adapter devices that you can buy and plug.
In my particular case the configuration device with FTDI chips is
internal part of embedded board, the configuration interface is
never exposed to end users. I doesn't make sense to register an
ID for such hardware.

Thanks,
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Laight July 19, 2017, 1:39 p.m. UTC | #13
From: Anatolij Gustschin

> Sent: 19 July 2017 14:30

...
> >Stupid question, I know, but I cannot help thinking: If you have an

> >EEPROM then why the h... don't you use an application specific device

> >ID?

> 

> It would make sense for adapter devices that you can buy and plug.

> In my particular case the configuration device with FTDI chips is

> internal part of embedded board, the configuration interface is

> never exposed to end users. I doesn't make sense to register an

> ID for such hardware.


Sounds like you should absolutely be registering an ID so that
nothing can try to use it using the default one.

	David
Anatolij Gustschin July 19, 2017, 3:03 p.m. UTC | #14
On Wed, 19 Jul 2017 13:39:36 +0000
David Laight David.Laight@ACULAB.COM wrote:

>From: Anatolij Gustschin
>> Sent: 19 July 2017 14:30  
>...
>> >Stupid question, I know, but I cannot help thinking: If you have an
>> >EEPROM then why the h... don't you use an application specific device
>> >ID?  
>> 
>> It would make sense for adapter devices that you can buy and plug.
>> In my particular case the configuration device with FTDI chips is
>> internal part of embedded board, the configuration interface is
>> never exposed to end users. I doesn't make sense to register an
>> ID for such hardware.  
>
>Sounds like you should absolutely be registering an ID so that
>nothing can try to use it using the default one.

The intended usage can already be enforced by rejecting not signed
bootloader/kernel/firmware.

Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Johan Hovold July 25, 2017, 11:49 a.m. UTC | #15
On Wed, Jul 19, 2017 at 01:58:30PM +0200, Anatolij Gustschin wrote:
> On Mon, 10 Jul 2017 14:52:10 +0200
> Johan Hovold johan@kernel.org wrote:
> 
> >On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
> >> Add USB part with common functions for USB-GPIO/I2C/SPI master
> >> adapters. These allow communication with chip's control, transmit
> >> and receive endpoints and will be used by various FT232H drivers.  
> >
> >> +static const struct mfd_cell ftdi_cells[] = {
> >> +	{ .name = "ftdi-cbus-gpio", },
> >> +	{ .name = "ftdi-mpsse-i2c", },
> >> +	{ .name = "ftdi-mpsse-spi", },
> >> +	{ .name = "ftdi-fifo-fpp-mgr", },
> >> +};  
> >
> >Correct me if I'm wrong, but aren't these modes really mutually
> >exclusive, possibly with exception of cbus-gpio (some pins are at least
> >available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
> >here either.
> 
> MPSSE and FIFO modes are mutually exclusive, but I'm not sure about
> MPSSE and CBUS-GPIO. CBUS-GPIO didn't work as expected when I was
> testing with MPSSE SPI master driver, but maybe it is a driver issue.

Yes, that wasn't clear to me either from just looking at the data
sheets. MPSSE seems to deal with its GPIOs differently.

> FT245 FIFO and CBUS GPIO can be switched by a control request, when
> FIFO mode is configured in the EEPROM.

Since the set_bitmode command is used to control the CBUS gpios, does
that mean that they cannot be toggled independently while FIFO mode is
in use (as the same command is used to set FIFO mode)?

> >And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
> >seems too application specific for a generic chip like this.
> 
> Yes, I agree. I'm thinking of a rework to add a FIFO driver instead
> and use it in the fpp-mgr driver. Is that the right direction? 

That sounds better, but I'm still not sure that we would be able to bind
it to devices with the default (generic) VID/PID.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Johan Hovold July 25, 2017, 11:52 a.m. UTC | #16
On Wed, Jul 19, 2017 at 02:59:00PM +0200, Anatolij Gustschin wrote:
> On Wed, 19 Jul 2017 10:59:34 +0200
> Johan Hovold johan@kernel.org wrote:

> >> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
> >> seems too application specific for a generic chip like this.  
> >
> >Of which this is one is one of the major.
> 
> Thanks all for feedback. I'm still pondering how to interface the
> fpga manager driver to FTDI FIFO driver.
> 
> >In short, your driver is much to application specific and is probably
> >something that needs to be implemented in userspace using libftdi.
> 
> I have a requirement to use the fpga manager framework, therefore the
> kernel driver is needed. Our usage scenario is a multi stage fpga
> configuration process, the first stage is a pre-configuration via
> FTDI SPI/FIFO, all subsequent stages are also done by other fpga
> manager drivers. libftdi based driver already existed for hardware
> bring-up, now I need similar functionality as kernel fpga manager.

How are you even accessing these fpga-managers from userspace? I thought
current interface was for in-kernel use only?

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anatolij Gustschin July 25, 2017, 12:14 p.m. UTC | #17
On Tue, 25 Jul 2017 13:52:35 +0200
Johan Hovold johan@kernel.org wrote:

>On Wed, Jul 19, 2017 at 02:59:00PM +0200, Anatolij Gustschin wrote:
>> On Wed, 19 Jul 2017 10:59:34 +0200
>> Johan Hovold johan@kernel.org wrote:  
>
>> >> And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
>> >> seems too application specific for a generic chip like this.    
>> >
>> >Of which this is one is one of the major.  
>> 
>> Thanks all for feedback. I'm still pondering how to interface the
>> fpga manager driver to FTDI FIFO driver.
>>   
>> >In short, your driver is much to application specific and is probably
>> >something that needs to be implemented in userspace using libftdi.  
>> 
>> I have a requirement to use the fpga manager framework, therefore the
>> kernel driver is needed. Our usage scenario is a multi stage fpga
>> configuration process, the first stage is a pre-configuration via
>> FTDI SPI/FIFO, all subsequent stages are also done by other fpga
>> manager drivers. libftdi based driver already existed for hardware
>> bring-up, now I need similar functionality as kernel fpga manager.  
>
>How are you even accessing these fpga-managers from userspace? I thought
>current interface was for in-kernel use only?

We have different possibilities to access to these fpga-managers from
userspace. On platforms with device-tree support there is a DT-Overlay
configfs interface for inserting a blob with configuration data and
fpga device description. After inserting the blob the fpga manager is
invoked automatically. There are also fpga-mgr debugfs config interface
patches in Altera linux-socfpga git tree for accessing from userspace.
I used them for initial testing, but now I'm using additional kernel
module with a single configuration interface for different managers.

Thanks,
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anatolij Gustschin July 25, 2017, 12:34 p.m. UTC | #18
On Tue, 25 Jul 2017 13:49:08 +0200
Johan Hovold johan@kernel.org wrote:

>On Wed, Jul 19, 2017 at 01:58:30PM +0200, Anatolij Gustschin wrote:
>> On Mon, 10 Jul 2017 14:52:10 +0200
>> Johan Hovold johan@kernel.org wrote:
>>   
>> >On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:  
>> >> Add USB part with common functions for USB-GPIO/I2C/SPI master
>> >> adapters. These allow communication with chip's control, transmit
>> >> and receive endpoints and will be used by various FT232H drivers.    
>> >  
>> >> +static const struct mfd_cell ftdi_cells[] = {
>> >> +	{ .name = "ftdi-cbus-gpio", },
>> >> +	{ .name = "ftdi-mpsse-i2c", },
>> >> +	{ .name = "ftdi-mpsse-spi", },
>> >> +	{ .name = "ftdi-fifo-fpp-mgr", },
>> >> +};    
>> >
>> >Correct me if I'm wrong, but aren't these modes really mutually
>> >exclusive, possibly with exception of cbus-gpio (some pins are at least
>> >available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
>> >here either.  
>> 
>> MPSSE and FIFO modes are mutually exclusive, but I'm not sure about
>> MPSSE and CBUS-GPIO. CBUS-GPIO didn't work as expected when I was
>> testing with MPSSE SPI master driver, but maybe it is a driver issue.  
>
>Yes, that wasn't clear to me either from just looking at the data
>sheets. MPSSE seems to deal with its GPIOs differently.

yes, the GPIOs are at different pins in MPSSE mode and these pins are
controlled via writes/reads to/from bulk endpoint with MPSSE commands.

>> FT245 FIFO and CBUS GPIO can be switched by a control request, when
>> FIFO mode is configured in the EEPROM.  
>
>Since the set_bitmode command is used to control the CBUS gpios, does
>that mean that they cannot be toggled independently while FIFO mode is
>in use (as the same command is used to set FIFO mode)?

yes.

Thanks,
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 94ad2c1..2c4e6f2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -327,6 +327,15 @@  config MFD_EXYNOS_LPASS
 	  Select this option to enable support for Samsung Exynos Low Power
 	  Audio Subsystem.
 
+config MFD_FTDI_FT232H
+	tristate "FTDI FT232H MFD driver"
+	select MFD_CORE
+	depends on USB
+	help
+	  Enable support for the FTDI FT232H USB-GPIO/I2C/SPI/FIFO
+	  Master Adapter. Additional drivers such as CBUS_GPIO, etc.
+	  must be enabled in order to use the functionality of the device.
+
 config MFD_MC13XXX
 	tristate
 	depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 080793b..a75163a 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -223,3 +223,4 @@  obj-$(CONFIG_MFD_SUN4I_GPADC)	+= sun4i-gpadc.o
 
 obj-$(CONFIG_MFD_STM32_TIMERS) 	+= stm32-timers.o
 obj-$(CONFIG_MFD_MXS_LRADC)     += mxs-lradc.o
+obj-$(CONFIG_MFD_FTDI_FT232H)	+= ftdi-ft232h.o
diff --git a/drivers/mfd/ftdi-ft232h.c b/drivers/mfd/ftdi-ft232h.c
new file mode 100644
index 0000000..d5d6d35
--- /dev/null
+++ b/drivers/mfd/ftdi-ft232h.c
@@ -0,0 +1,470 @@ 
+/*
+ * FTDI FT232H MFD driver
+ *
+ * Copyright (C) 2017 DENX Software Engineering
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/usb.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/ftdi/ftdi.h>
+
+struct ftdi_mfd_priv {
+	struct usb_interface	*intf;
+	struct usb_device	*udev;
+	struct mutex		io_mutex; /* sync I/O with disconnect */
+	int			bitbang_enabled;
+	int			index;
+	u8			bulk_in;
+	u8			bulk_out;
+	size_t			bulk_in_sz;
+	void			*bulk_in_buf;
+};
+
+/* Use baudrate calculation from libftdi */
+static int ftdi_to_clkbits(int baudrate, unsigned int clk, int clk_div,
+			   unsigned long *encoded_divisor)
+{
+	static const char frac_code[8] = { 0, 3, 2, 4, 1, 5, 6, 7 };
+	int best_baud = 0;
+	int div, best_div;
+
+	if (baudrate >= clk / clk_div) {
+		*encoded_divisor = 0;
+		best_baud = clk / clk_div;
+	} else if (baudrate >= clk / (clk_div + clk_div / 2)) {
+		*encoded_divisor = 1;
+		best_baud = clk / (clk_div + clk_div / 2);
+	} else if (baudrate >= clk / (2 * clk_div)) {
+		*encoded_divisor = 2;
+		best_baud = clk / (2 * clk_div);
+	} else {
+		/*
+		 * Divide by 16 to have 3 fractional bits and
+		 * one bit for rounding
+		 */
+		div = clk * 16 / clk_div / baudrate;
+		if (div & 1)	/* Decide if to round up or down */
+			best_div = div / 2 + 1;
+		else
+			best_div = div / 2;
+		if (best_div > 0x20000)
+			best_div = 0x1ffff;
+		best_baud = clk * 16 / clk_div / best_div;
+		if (best_baud & 1)	/* Decide if to round up or down */
+			best_baud = best_baud / 2 + 1;
+		else
+			best_baud = best_baud / 2;
+		*encoded_divisor = (best_div >> 3) |
+				   (frac_code[best_div & 0x7] << 14);
+	}
+	return best_baud;
+}
+
+#define H_CLK	120000000
+#define C_CLK	48000000
+static int ftdi_convert_baudrate(struct ftdi_mfd_priv *priv, int baud,
+				 u16 *value, u16 *index)
+{
+	unsigned long encoded_divisor = 0;
+	int best_baud = 0;
+
+	if (baud <= 0)
+		return -EINVAL;
+
+	/*
+	 * On H Devices, use 12000000 baudrate when possible.
+	 * We have a 14 bit divisor, a 1 bit divisor switch (10 or 16),
+	 * three fractional bits and a 120 MHz clock. Assume AN_120
+	 * "Sub-integer divisors between 0 and 2 are not allowed" holds
+	 * for DIV/10 CLK too, so /1, /1.5 and /2 can be handled the same
+	 */
+	if (baud * 10 > H_CLK / 0x3fff) {
+		best_baud = ftdi_to_clkbits(baud, H_CLK, 10, &encoded_divisor);
+		encoded_divisor |= 0x20000;	/* switch on CLK/10 */
+	} else {
+		best_baud = ftdi_to_clkbits(baud, C_CLK, 16, &encoded_divisor);
+	}
+
+	if (best_baud <= 0) {
+		pr_err("Invalid baudrate: %d\n", best_baud);
+		return -EINVAL;
+	}
+
+	/* Check within tolerance (about 5%) */
+	if ((best_baud * 2 < baud) ||
+	    (best_baud < baud
+		? (best_baud * 21 < baud * 20)
+		: (baud * 21 < best_baud * 20))) {
+		pr_err("Unsupported baudrate.\n");
+		return -EINVAL;
+	}
+
+	/* Split into "value" and "index" values */
+	*value = (u16)(encoded_divisor & 0xffff);
+	*index = (u16)(((encoded_divisor >> 8) & 0xff00) | priv->index);
+
+	dev_dbg(&priv->intf->dev, "best baud %d, v/i: %d, %d\n",
+		best_baud, *value, *index);
+	return best_baud;
+}
+
+/**
+ * ftdi_ctrl_xfer - FTDI control endpoint transfer
+ * @pdev: pointer to FTDI MFD platform device
+ * @desc: pointer to descriptor struct for control transfer
+ *
+ * Return:
+ * Return: If successful, the number of bytes transferred. Otherwise,
+ * a negative error number.
+ */
+int ftdi_ctrl_xfer(struct platform_device *pdev, struct ctrl_desc *desc)
+{
+	struct ftdi_mfd_priv *priv;
+	struct usb_device *udev;
+	unsigned int pipe;
+	int ret;
+
+	priv = dev_get_drvdata(pdev->dev.parent);
+	udev = priv->udev;
+
+	mutex_lock(&priv->io_mutex);
+	if (!priv->intf) {
+		ret = -ENODEV;
+		goto exit;
+	}
+
+	if (!desc->data && desc->size)
+		desc->data = priv->bulk_in_buf;
+
+	if (desc->dir_out)
+		pipe = usb_sndctrlpipe(udev, 0);
+	else
+		pipe = usb_rcvctrlpipe(udev, 0);
+
+	ret = usb_control_msg(udev, pipe, desc->request, desc->requesttype,
+			      desc->value, desc->index, desc->data, desc->size,
+			      desc->timeout);
+	if (ret < 0)
+		dev_err(&udev->dev, "ctrl msg failed: %d\n", ret);
+exit:
+	mutex_unlock(&priv->io_mutex);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(ftdi_ctrl_xfer);
+
+/**
+ * ftdi_bulk_xfer - FTDI bulk endpoint transfer
+ * @pdev: pointer to FTDI MFD platform device
+ * @desc: pointer to descriptor struct for bulk-in or bulk-out transfer
+ *
+ * Return:
+ * If successful, 0. Otherwise a negative error number. The number of actual
+ * bytes transferred will be stored in the @desc->act_len field of the
+ * descriptor struct.
+ */
+int ftdi_bulk_xfer(struct platform_device *pdev, struct bulk_desc *desc)
+{
+	struct ftdi_mfd_priv *priv = dev_get_drvdata(pdev->dev.parent);
+	struct usb_device *udev = priv->udev;
+	unsigned int pipe;
+	int ret;
+
+	mutex_lock(&priv->io_mutex);
+	if (!priv->intf) {
+		ret = -ENODEV;
+		goto exit;
+	}
+
+	if (desc->dir_out)
+		pipe = usb_sndbulkpipe(udev, priv->bulk_out);
+	else
+		pipe = usb_rcvbulkpipe(udev, priv->bulk_in);
+
+	ret = usb_bulk_msg(udev, pipe, desc->data, desc->len,
+			   &desc->act_len, desc->timeout);
+	if (ret)
+		dev_err(&udev->dev, "bulk msg failed: %d\n", ret);
+
+exit:
+	mutex_unlock(&priv->io_mutex);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(ftdi_bulk_xfer);
+
+/**
+ * ftdi_set_baudrate - set the device baud rate
+ * @pdev: pointer to FTDI MFD platform device
+ * @baudrate: baud rate value to set
+ *
+ * Return: If successful, 0. Otherwise a negative error number.
+ */
+int ftdi_set_baudrate(struct platform_device *pdev, int baudrate)
+{
+	struct ftdi_mfd_priv *priv = dev_get_drvdata(pdev->dev.parent);
+	struct ctrl_desc desc;
+	u16 index, value;
+	int ret;
+
+	if (priv->bitbang_enabled)
+		baudrate *= 4;
+
+	ret = ftdi_convert_baudrate(priv, baudrate, &value, &index);
+	if (ret < 0)
+		return ret;
+
+	desc.dir_out = true;
+	desc.request = FTDI_SIO_SET_BAUDRATE_REQUEST;
+	desc.requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT;
+	desc.value = value;
+	desc.index = index;
+	desc.data = NULL;
+	desc.size = 0;
+	desc.timeout = USB_CTRL_SET_TIMEOUT;
+
+	ret = ftdi_ctrl_xfer(pdev, &desc);
+	if (ret < 0) {
+		dev_dbg(&pdev->dev, "failed to set baudrate: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ftdi_set_baudrate);
+
+/**
+ * ftdi_read_data - read from FTDI bulk-in endpoint
+ * @pdev: pointer to FTDI MFD platform device
+ * @buf:  pointer to data buffer
+ * @len:  length in bytes of the data to read
+ *
+ * The two modem status bytes transferred in every read will
+ * be removed and will not appear in the data buffer.
+ *
+ * Return:
+ * If successful, the number of data bytes received (can be 0).
+ * Otherwise, a negative error number.
+ */
+int ftdi_read_data(struct platform_device *pdev, void *buf, size_t len)
+{
+	struct ftdi_mfd_priv *priv = dev_get_drvdata(pdev->dev.parent);
+	struct bulk_desc desc;
+	int ret;
+
+	desc.act_len = 0;
+	desc.dir_out = false;
+	desc.data = priv->bulk_in_buf;
+	/* Device sends 2 additional status bytes, read at least len + 2 */
+	desc.len = min_t(size_t, len + 2, priv->bulk_in_sz);
+	desc.timeout = FTDI_USB_READ_TIMEOUT;
+
+	ret = ftdi_bulk_xfer(pdev, &desc);
+	if (ret)
+		return ret;
+
+	/* Only status bytes and no data? */
+	if (desc.act_len <= 2)
+		return 0;
+
+	/* Skip first two status bytes */
+	ret = desc.act_len - 2;
+	memcpy(buf, desc.data + 2, ret);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(ftdi_read_data);
+
+/**
+ * ftdi_write_data - write to FTDI bulk-out endpoint
+ * @pdev: pointer to FTDI MFD platform device
+ * @buf:  pointer to data buffer
+ * @len:  length in bytes of the data to send
+ *
+ * Return:
+ * If successful, the number of bytes transferred. Otherwise a negative
+ * error number.
+ */
+int ftdi_write_data(struct platform_device *pdev, const char *buf, size_t len)
+{
+	struct bulk_desc desc;
+	int ret;
+
+	desc.act_len = 0;
+	desc.dir_out = true;
+	desc.data = (char *)buf;
+	desc.len = len;
+	desc.timeout = FTDI_USB_WRITE_TIMEOUT;
+
+	ret = ftdi_bulk_xfer(pdev, &desc);
+	if (ret < 0)
+		return ret;
+
+	return desc.act_len;
+}
+EXPORT_SYMBOL_GPL(ftdi_write_data);
+
+/**
+ * ftdi_set_bitmode - configure bitbang mode
+ * @pdev: pointer to FTDI MFD platform device
+ * @bitmask: line configuration bitmask
+ * @mode: bitbang mode to set
+ *
+ * Return:
+ * If successful, 0. Otherwise a negative error number.
+ */
+int ftdi_set_bitmode(struct platform_device *pdev, unsigned char bitmask,
+		     unsigned char mode)
+{
+	struct ftdi_mfd_priv *priv = dev_get_drvdata(pdev->dev.parent);
+	struct ctrl_desc desc;
+	int ret;
+
+	desc.dir_out = true;
+	desc.data = NULL;
+	desc.request = FTDI_SIO_SET_BITMODE_REQUEST;
+	desc.requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT;
+	desc.index = 1;
+	desc.value = (mode << 8) | bitmask;
+	desc.size = 0;
+	desc.timeout = USB_CTRL_SET_TIMEOUT;
+
+	ret = ftdi_ctrl_xfer(pdev, &desc);
+	if (ret < 0)
+		return ret;
+
+	switch (mode) {
+	case BITMODE_BITBANG:
+	case BITMODE_CBUS:
+	case BITMODE_SYNCBB:
+	case BITMODE_SYNCFF:
+		priv->bitbang_enabled = 1;
+		break;
+	case BITMODE_MPSSE:
+	case BITMODE_RESET:
+	default:
+		priv->bitbang_enabled = 0;
+		break;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ftdi_set_bitmode);
+
+/**
+ * ftdi_disable_bitbang - disable bitbang mode
+ * @pdev: pointer to FTDI MFD platform device
+ *
+ * Return:
+ * If successful, 0. Otherwise a negative error number.
+ */
+int ftdi_disable_bitbang(struct platform_device *pdev)
+{
+	int ret;
+
+	ret = ftdi_set_bitmode(pdev, 0, BITMODE_RESET);
+	if (ret < 0) {
+		dev_dbg(&pdev->dev, "disable bitbang failed: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ftdi_disable_bitbang);
+
+static const struct mfd_cell ftdi_cells[] = {
+	{ .name = "ftdi-cbus-gpio", },
+	{ .name = "ftdi-mpsse-i2c", },
+	{ .name = "ftdi-mpsse-spi", },
+	{ .name = "ftdi-fifo-fpp-mgr", },
+};
+
+static int ftdi_mfd_probe(struct usb_interface *intf,
+			  const struct usb_device_id *id)
+{
+	struct ftdi_mfd_priv *priv;
+	struct device *dev = &intf->dev;
+	struct usb_host_interface *iface_desc;
+	struct usb_endpoint_descriptor *endpoint;
+	unsigned int i;
+	int ret;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	iface_desc = intf->cur_altsetting;
+
+	for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
+		endpoint = &iface_desc->endpoint[i].desc;
+
+		if (usb_endpoint_is_bulk_out(endpoint))
+			priv->bulk_out = endpoint->bEndpointAddress;
+
+		if (usb_endpoint_is_bulk_in(endpoint)) {
+			priv->bulk_in = endpoint->bEndpointAddress;
+			priv->bulk_in_sz = usb_endpoint_maxp(endpoint);
+		}
+	}
+
+	priv->index = 1;
+	priv->intf = intf;
+
+	mutex_init(&priv->io_mutex);
+	usb_set_intfdata(intf, priv);
+
+	priv->bulk_in_buf = devm_kmalloc(dev, priv->bulk_in_sz,
+					 GFP_KERNEL | GFP_DMA32);
+	if (!priv->bulk_in_buf)
+		return -ENOMEM;
+
+	priv->udev = usb_get_dev(interface_to_usbdev(intf));
+
+	ret = mfd_add_hotplug_devices(dev, ftdi_cells, ARRAY_SIZE(ftdi_cells));
+	if (ret) {
+		usb_put_dev(priv->udev);
+		dev_err(dev, "failed to add mfd devices\n");
+	}
+
+	return ret;
+}
+
+static void ftdi_mfd_disconnect(struct usb_interface *intf)
+{
+	struct ftdi_mfd_priv *priv = usb_get_intfdata(intf);
+
+	mutex_lock(&priv->io_mutex);
+	priv->intf = NULL;
+	mutex_unlock(&priv->io_mutex);
+
+	mfd_remove_devices(&intf->dev);
+	usb_set_intfdata(intf, NULL);
+	usb_put_dev(priv->udev);
+}
+
+static struct usb_device_id ftdi_mfd_table[] = {
+	{ USB_DEVICE(0x0403, 0x6014) },
+	{}
+};
+MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);
+
+static struct usb_driver ftdi_mfd_driver = {
+	.name		= "ftdi-mfd",
+	.id_table	= ftdi_mfd_table,
+	.probe		= ftdi_mfd_probe,
+	.disconnect	= ftdi_mfd_disconnect,
+};
+
+module_usb_driver(ftdi_mfd_driver);
+
+MODULE_ALIAS("ftdi-mfd");
+MODULE_AUTHOR("Anatolij Gustschin <agust@denx.de>");
+MODULE_DESCRIPTION("FTDI FT232H MFD core driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/ftdi/ftdi.h b/include/linux/mfd/ftdi/ftdi.h
new file mode 100644
index 0000000..0fc9317
--- /dev/null
+++ b/include/linux/mfd/ftdi/ftdi.h
@@ -0,0 +1,71 @@ 
+/*
+ * Common definitions for FTDI FT232H device
+ *
+ * Copyright (C) 2017 DENX Software Engineering
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef MFD_FTDI_H
+#define MFD_FTDI_H
+
+/* Used FTDI USB Requests */
+#define FTDI_SIO_RESET_REQUEST		0x00
+#define FTDI_SIO_SET_BAUDRATE_REQUEST	0x03
+#define FTDI_SIO_SET_BITMODE_REQUEST	0x0B
+#define FTDI_SIO_READ_PINS_REQUEST	0x0C
+#define FTDI_SIO_READ_EEPROM_REQUEST	0x90
+
+/* For EEPROM I/O mode */
+#define FTDI_MAX_EEPROM_SIZE	256
+#define FTDI_232H_CBUS_IOMODE	0x08
+
+#define FTDI_USB_READ_TIMEOUT	5000
+#define FTDI_USB_WRITE_TIMEOUT	5000
+
+/* MPSSE bitbang modes */
+enum ftdi_mpsse_mode {
+	BITMODE_RESET	= 0x00,	/* switch off bitbang mode */
+	BITMODE_BITBANG	= 0x01,	/* asynchronous bitbang mode */
+	BITMODE_MPSSE	= 0x02,	/* MPSSE mode, on 2232x chips */
+	BITMODE_SYNCBB	= 0x04,	/* synchronous bitbang mode  */
+	BITMODE_MCU	= 0x08,	/* MCU Host Bus Emulation mode */
+				/* CPU-style fifo mode gets set via EEPROM */
+	BITMODE_OPTO	= 0x10,	/* Fast Opto-Isolated Serial Interface Mode */
+	BITMODE_CBUS	= 0x20,	/* Bitbang on CBUS pins, EEPROM config needed */
+	BITMODE_SYNCFF	= 0x40,	/* Single Channel Synchronous FIFO mode */
+	BITMODE_FT1284	= 0x80,	/* FT1284 mode, available on 232H chips */
+};
+
+struct ctrl_desc {
+	bool dir_out;
+	u8 request;
+	u8 requesttype;
+	u16 value;
+	u16 index;
+	void *data;
+	u16 size;
+	int timeout;
+};
+
+struct bulk_desc {
+	bool dir_out;
+	void *data;
+	int len;
+	int act_len;
+	int timeout;
+};
+
+int ftdi_ctrl_xfer(struct platform_device *pdev, struct ctrl_desc *desc);
+int ftdi_bulk_xfer(struct platform_device *pdev, struct bulk_desc *desc);
+int ftdi_read_data(struct platform_device *pdev, void *buf, size_t len);
+int ftdi_write_data(struct platform_device *pdev, const char *buf, size_t len);
+int ftdi_set_baudrate(struct platform_device *pdev, int baudrate);
+int ftdi_set_bitmode(struct platform_device *pdev, unsigned char bitmask,
+		     unsigned char mode);
+int ftdi_disable_bitbang(struct platform_device *pdev);
+
+#endif /* MFD_FTDI_H */