Re: Udoo support for chipidea

[Peter Chen]

On Fri, Nov 20, 2015 at 11:13:00AM -0500, Alan Stern wrote:
> On Fri, 20 Nov 2015, Peter Chen wrote:
> 
> > > > > Hi Alan, we have several designs that the on-board HUB need to
> > > > > be reset by gpio pin and its clock is also from the board or
> > > > > the SoC. Any suggestions how to add these platform information
> > > > > for HUB device?
> > > > 
> > > > How about putting it in the device tree?
> > > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> > > > clocks and reset-gpios properties could be added to the USB hub node.
> > > 
> > > Something like this is necessary.  Instead of making the hub driver
> > > take care of the reset gpio and the clock, I suggest you make the host
> > > controller's platform driver do these things.
> > > 
> > > This is because USB hubs are generic devices, not specific to any 
> > > platform and (usually) hot-pluggable.  Associating platform-specific 
> > > data with a hub is out of the ordinary, and it deserves to be handled 
> > > by platform-specific code -- there is no such code in the hub driver.
> > > 
> > 
> > If this on-board HUB is special, its reset pin needs to be toggled
> > after power on, no matter for Intel or ARM platforms, how we handle
> > it? It is not feasible we add this for all platform drivers.
> 
> I don't know.  Probably it should be handled the same way as any other 
> hardware with special requirements.
> 
> Are you saying that it would be better to modify the hub driver than to 
> modify all the platform drivers?  If you can figure out a way to make 
> it work, then maybe -- I don't see how to do it.
> 

Yes, changing hub.c is hard, I am think if we can have a device driver
for it, and this driver can be probed through special pid/vid, but I
can't find a way to describe one USB device (eg, its external
pins/clocks) through platform code, eg, dts or acpi.

-- 

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

Re: Udoo support for chipidea

[Alan Stern]

On Fri, 20 Nov 2015, Peter Chen wrote:

> > > > Hi Alan, we have several designs that the on-board HUB need to
> > > > be reset by gpio pin and its clock is also from the board or
> > > > the SoC. Any suggestions how to add these platform information
> > > > for HUB device?
> > > 
> > > How about putting it in the device tree?
> > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> > > clocks and reset-gpios properties could be added to the USB hub node.
> > 
> > Something like this is necessary.  Instead of making the hub driver
> > take care of the reset gpio and the clock, I suggest you make the host
> > controller's platform driver do these things.
> > 
> > This is because USB hubs are generic devices, not specific to any 
> > platform and (usually) hot-pluggable.  Associating platform-specific 
> > data with a hub is out of the ordinary, and it deserves to be handled 
> > by platform-specific code -- there is no such code in the hub driver.
> > 
> 
> If this on-board HUB is special, its reset pin needs to be toggled
> after power on, no matter for Intel or ARM platforms, how we handle
> it? It is not feasible we add this for all platform drivers.

I don't know.  Probably it should be handled the same way as any other 
hardware with special requirements.

Are you saying that it would be better to modify the hub driver than to 
modify all the platform drivers?  If you can figure out a way to make 
it work, then maybe -- I don't see how to do it.

Alan Stern

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

Re: Udoo support for chipidea

[Philipp Zabel]

Am Freitag, den 20.11.2015, 16:05 +0800 schrieb Peter Chen:
> On Thu, Nov 19, 2015 at 11:26:50AM -0500, Alan Stern wrote:
> > On Thu, 19 Nov 2015, Philipp Zabel wrote:
> > 
> > > On Wed, Oct 21, 2015 at 10:39:00AM +0800, Peter Chen wrote:
> > > > On Tue, Oct 20, 2015 at 02:09:38PM -0200, Fabio Estevam wrote:
> > > > > Hi Peter,
> > > > > 
> > > > > On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen 
> > > > >  wrote:
> > > > > 
> > > > > > Add linux-usb.
> > > > > >
> > > > > > Patryk, your problem is you may need to open 24M OSC for HUB 2514
> > > > > > manually, and you have used IMX6QDL_CLK_CKO for it in the design,
> > > > > > but this clock is not controller's clock, controller's clock has
> > > > > > already decided at SoC dts file (imx6qdl.dtsi), you don't need to
> > > > > > override it at board's dts file.
> > > > > >
> > > > > > You can try delete clock property at imx6qdl-udoo.dtsi, if it still
> > > > > > can't work, try to open IMX6QDL_CLK_CKO at one place to test.
> > > > > 
> > > > > What is the appropriate place to acquire and enable the USB hub clock?
> > > > > 
> > > > > This issue has appeared several times and it seems we don't have a
> > > > > solution for this yet.
> > > > > 
> > > > > Any suggestions?
> > > > 
> > > > Add Alan.
> > > > 
> > > > Hi Alan, we have several designs that the on-board HUB need to
> > > > be reset by gpio pin and its clock is also from the board or
> > > > the SoC. Any suggestions how to add these platform information
> > > > for HUB device?
> > > 
> > > How about putting it in the device tree?
> > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> > > clocks and reset-gpios properties could be added to the USB hub node.
> > 
> > Something like this is necessary.  Instead of making the hub driver
> > take care of the reset gpio and the clock, I suggest you make the host
> > controller's platform driver do these things.
> > 
> > This is because USB hubs are generic devices, not specific to any 
> > platform and (usually) hot-pluggable.  Associating platform-specific 
> > data with a hub is out of the ordinary, and it deserves to be handled 
> > by platform-specific code -- there is no such code in the hub driver.
> > 
> If this on-board HUB is special, its reset pin needs to be toggled
> after power on, no matter for Intel or ARM platforms, how we handle
> it? It is not feasible we add this for all platform drivers.

Further whether the GPIO reset line is initially in asserted state and
just needs to change to deasserted, or whether the GPIO reset line is
initially in deasserted state and needs to be pulsed for a certain time
is probably hub IC specific.

regards
Philipp

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

Re: Udoo support for chipidea

[Peter Chen]

On Thu, Nov 19, 2015 at 11:26:50AM -0500, Alan Stern wrote:
> On Thu, 19 Nov 2015, Philipp Zabel wrote:
> 
> > On Wed, Oct 21, 2015 at 10:39:00AM +0800, Peter Chen wrote:
> > > On Tue, Oct 20, 2015 at 02:09:38PM -0200, Fabio Estevam wrote:
> > > > Hi Peter,
> > > > 
> > > > On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen  
> > > > wrote:
> > > > 
> > > > > Add linux-usb.
> > > > >
> > > > > Patryk, your problem is you may need to open 24M OSC for HUB 2514
> > > > > manually, and you have used IMX6QDL_CLK_CKO for it in the design,
> > > > > but this clock is not controller's clock, controller's clock has
> > > > > already decided at SoC dts file (imx6qdl.dtsi), you don't need to
> > > > > override it at board's dts file.
> > > > >
> > > > > You can try delete clock property at imx6qdl-udoo.dtsi, if it still
> > > > > can't work, try to open IMX6QDL_CLK_CKO at one place to test.
> > > > 
> > > > What is the appropriate place to acquire and enable the USB hub clock?
> > > > 
> > > > This issue has appeared several times and it seems we don't have a
> > > > solution for this yet.
> > > > 
> > > > Any suggestions?
> > > 
> > > Add Alan.
> > > 
> > > Hi Alan, we have several designs that the on-board HUB need to
> > > be reset by gpio pin and its clock is also from the board or
> > > the SoC. Any suggestions how to add these platform information
> > > for HUB device?
> > 
> > How about putting it in the device tree?
> > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> > clocks and reset-gpios properties could be added to the USB hub node.
> 
> Something like this is necessary.  Instead of making the hub driver
> take care of the reset gpio and the clock, I suggest you make the host
> controller's platform driver do these things.
> 
> This is because USB hubs are generic devices, not specific to any 
> platform and (usually) hot-pluggable.  Associating platform-specific 
> data with a hub is out of the ordinary, and it deserves to be handled 
> by platform-specific code -- there is no such code in the hub driver.
> 

If this on-board HUB is special, its reset pin needs to be toggled
after power on, no matter for Intel or ARM platforms, how we handle
it? It is not feasible we add this for all platform drivers.

-- 

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

Re: Udoo support for chipidea

[Alan Stern]

On Thu, 19 Nov 2015, Philipp Zabel wrote:

> On Wed, Oct 21, 2015 at 10:39:00AM +0800, Peter Chen wrote:
> > On Tue, Oct 20, 2015 at 02:09:38PM -0200, Fabio Estevam wrote:
> > > Hi Peter,
> > > 
> > > On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen  
> > > wrote:
> > > 
> > > > Add linux-usb.
> > > >
> > > > Patryk, your problem is you may need to open 24M OSC for HUB 2514
> > > > manually, and you have used IMX6QDL_CLK_CKO for it in the design,
> > > > but this clock is not controller's clock, controller's clock has
> > > > already decided at SoC dts file (imx6qdl.dtsi), you don't need to
> > > > override it at board's dts file.
> > > >
> > > > You can try delete clock property at imx6qdl-udoo.dtsi, if it still
> > > > can't work, try to open IMX6QDL_CLK_CKO at one place to test.
> > > 
> > > What is the appropriate place to acquire and enable the USB hub clock?
> > > 
> > > This issue has appeared several times and it seems we don't have a
> > > solution for this yet.
> > > 
> > > Any suggestions?
> > 
> > Add Alan.
> > 
> > Hi Alan, we have several designs that the on-board HUB need to
> > be reset by gpio pin and its clock is also from the board or
> > the SoC. Any suggestions how to add these platform information
> > for HUB device?
> 
> How about putting it in the device tree?
> http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> clocks and reset-gpios properties could be added to the USB hub node.

Something like this is necessary.  Instead of making the hub driver
take care of the reset gpio and the clock, I suggest you make the host
controller's platform driver do these things.

This is because USB hubs are generic devices, not specific to any 
platform and (usually) hot-pluggable.  Associating platform-specific 
data with a hub is out of the ordinary, and it deserves to be handled 
by platform-specific code -- there is no such code in the hub driver.

Alan Stern

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

Re: Udoo support for chipidea

[Philipp Zabel]

On Wed, Oct 21, 2015 at 10:39:00AM +0800, Peter Chen wrote:
> On Tue, Oct 20, 2015 at 02:09:38PM -0200, Fabio Estevam wrote:
> > Hi Peter,
> > 
> > On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen  
> > wrote:
> > 
> > > Add linux-usb.
> > >
> > > Patryk, your problem is you may need to open 24M OSC for HUB 2514
> > > manually, and you have used IMX6QDL_CLK_CKO for it in the design,
> > > but this clock is not controller's clock, controller's clock has
> > > already decided at SoC dts file (imx6qdl.dtsi), you don't need to
> > > override it at board's dts file.
> > >
> > > You can try delete clock property at imx6qdl-udoo.dtsi, if it still
> > > can't work, try to open IMX6QDL_CLK_CKO at one place to test.
> > 
> > What is the appropriate place to acquire and enable the USB hub clock?
> > 
> > This issue has appeared several times and it seems we don't have a
> > solution for this yet.
> > 
> > Any suggestions?
> 
> Add Alan.
> 
> Hi Alan, we have several designs that the on-board HUB need to
> be reset by gpio pin and its clock is also from the board or
> the SoC. Any suggestions how to add these platform information
> for HUB device?

How about putting it in the device tree?
http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
clocks and reset-gpios properties could be added to the USB hub node.

regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Udoo support for chipidea

[Fabio Estevam]

Hi Peter,

On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen  wrote:

> Add linux-usb.
>
> Patryk, your problem is you may need to open 24M OSC for HUB 2514
> manually, and you have used IMX6QDL_CLK_CKO for it in the design,
> but this clock is not controller's clock, controller's clock has
> already decided at SoC dts file (imx6qdl.dtsi), you don't need to
> override it at board's dts file.
>
> You can try delete clock property at imx6qdl-udoo.dtsi, if it still
> can't work, try to open IMX6QDL_CLK_CKO at one place to test.

What is the appropriate place to acquire and enable the USB hub clock?

This issue has appeared several times and it seems we don't have a
solution for this yet.

Any suggestions?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Udoo support for chipidea

[Peter Chen]

On Tue, Oct 20, 2015 at 02:09:38PM -0200, Fabio Estevam wrote:
> Hi Peter,
> 
> On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen  wrote:
> 
> > Add linux-usb.
> >
> > Patryk, your problem is you may need to open 24M OSC for HUB 2514
> > manually, and you have used IMX6QDL_CLK_CKO for it in the design,
> > but this clock is not controller's clock, controller's clock has
> > already decided at SoC dts file (imx6qdl.dtsi), you don't need to
> > override it at board's dts file.
> >
> > You can try delete clock property at imx6qdl-udoo.dtsi, if it still
> > can't work, try to open IMX6QDL_CLK_CKO at one place to test.
> 
> What is the appropriate place to acquire and enable the USB hub clock?
> 
> This issue has appeared several times and it seems we don't have a
> solution for this yet.
> 
> Any suggestions?

Add Alan.

Hi Alan, we have several designs that the on-board HUB need to
be reset by gpio pin and its clock is also from the board or
the SoC. Any suggestions how to add these platform information
for HUB device?

-- 

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

Re: Udoo support for chipidea

[Peter Chen]

On Sat, Oct 17, 2015 at 10:38:28AM +0200, Patryk Kowalczyk wrote:
> Hi, 
>   I have had problem with udoo boot since commit
> 73dea4a912b2bfe955305de4891018f9e71e399d
> "usb: chipidea: usbmisc_imx: delete clock information"
> 
> Unfortunately for udoo usb controller we need information
> about external clock. Please check out documentation from udoo team:
> http://udoo.org/download/files/schematics/UDOO_REV_D_schematics.pdf
> (page 10).
> 
> best regards,
>   Patryk Kowalczyk
> 

Add linux-usb.

Patryk, your problem is you may need to open 24M OSC for HUB 2514
manually, and you have used IMX6QDL_CLK_CKO for it in the design,
but this clock is not controller's clock, controller's clock has
already decided at SoC dts file (imx6qdl.dtsi), you don't need to
override it at board's dts file.

You can try delete clock property at imx6qdl-udoo.dtsi, if it still
can't work, try to open IMX6QDL_CLK_CKO at one place to test.

-- 

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