From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Tue, 6 Nov 2012 00:56:05 +0100
Subject: [U-Boot] usb: ehci: Take advantage of the new multi-controller
	feature for MXC
In-Reply-To: <1204803970.595037.1352159546113.JavaMail.root@advansee.com>
References: <1204803970.595037.1352159546113.JavaMail.root@advansee.com>
Message-ID: <201211060056.05340.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Beno?t Th?baudeau,

> Dear Marek Vasut,
> 
> On Monday, November 5, 2012 11:54:12 PM, Marek Vasut wrote:
> > Dear Beno?t Th?baudeau,
> > 
> > > Hi Marek,
> > > 
> > > Thanks to Lucas' series coming with commits c7e3b2b and 676ae06,
> > > I'd like
> > > to use the multi-controller feature on MXC since most of these SoCs
> > > come
> > > with a USB IP supporting an OTG controller and multiple host-only
> > > controllers.
> > > 
> > > Currently the MXC code in ehci-mx{c|5|6}.c just ignores the index
> > > passed to
> > > ehci_hcd_init() and the like, and there are 3 port-specific configs
> > > (CONFIG_MXC_USB_PORT, CONFIG_MXC_USB_FLAGS and
> > > CONFIG_MXC_USB_PORTSC).
> > > 
> > > Not all USB ports from the USB IP will be available on each board
> > > for a
> > > given SoC, so we need a logical to physical USB port mapping.
> > > 
> > > I would suggest something like the following.
> > > 
> > > board.h:
> > > #define CONFIG_MXC_USB	{ \
> > > 
> > > 	{ \
> > > 	
> > > 		0, \
> > > 		MXC_EHCI_INTERNAL_PHY, \
> > > 		MXC_EHCI_UTMI_16BIT | MXC_EHCI_MODE_UTMI \
> > > 	
> > > 	}, { \
> > > 	
> > > 		1, \
> > > 		MXC_EHCI_POWER_PINS_ENABLED | MXC_EHCI_PWR_PIN_ACTIVE_HIGH | \
> > > 		MXC_EHCI_OC_PIN_ACTIVE_LOW, \
> > > 		MXC_EHCI_MODE_ULPI \
> > > 	
> > > 	}, \
> > > 
> > > }
> > > 
> > > ehci-fsl.h:
> > > struct mxc_ehci_cfg {
> > > 
> > > 	int port;
> > > 	u32 flags;
> > > 	u32 portsc;
> > > 
> > > };
> > > 
> > > ehci-mx{c|5|6}.c:
> > > static const struct mxc_ehci_cfg
> > > cfg[CONFIG_USB_MAX_CONTROLLER_COUNT] =
> > > 
> > > 		CONFIG_MXC_USB;
> > > 
> > > Then, in ehci_hcd_init(), there would be the following
> > > 
> > > replacements:
> > >  - CONFIG_MXC_USB_PORT -> cfg[index].port,
> > >  - CONFIG_MXC_USB_FLAGS -> cfg[index].flags,
> > >  - CONFIG_MXC_USB_PORTSC -> cfg[index].portsc.
> > > 
> > > What do you think?
> > 
> > What about passing port private / platform data instead of ID ?
> 
> The ID is already passed to ehci_hcd_init(), so we have to live with it if
> we don't want to change the newly introduced multi-controller
> infrastructure.

Let's change it .... remove the ID and pass some generic pdata.

> Or, perhaps this is what you meant, we could have some:
> int ehci_mxc_register(int index, const struct mxc_ehci_cfg *cfg);
> This function would simply fill an entry in the cfg array in
> ehci-mx{c|5|6}.c, this array becoming an array of pointers to struct
> mxc_ehci_cfg. This looks nicer, but it needs more code to do just the same
> thing as the CONFIG_MXC_USB would do, without adding any feature. The only
> benefit would be if index were actually the same as port here, but
> ehci_hcd_init() would still be called for all indexes, so it would have to
> fail e.g. if port 0 is unused but port 1 is used, which would probably
> generate some error noise for the user.
> 
> Or did you mean something else?
> 
> Best regards,
> Beno?t