[PATCH] usb: ohci: Allow ohci on omap5 also

[PATCH] usb: ohci: Allow ohci on omap5 also

[Tony Lindgren]

With LPAE config we don't have omap3 or omap4 selected for
omap5 variants.

Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
 drivers/usb/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -472,7 +472,7 @@ config USB_OHCI_HCD_AT91
 
 config USB_OHCI_HCD_OMAP3
 	tristate "OHCI support for OMAP3 and later chips"
-	depends on (ARCH_OMAP3 || ARCH_OMAP4)
+	depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
 	default y
 	---help---
 	  Enables support for the on-chip OHCI controller on
-- 
2.9.3

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

Re: [PATCH] usb: ohci: Allow ohci on omap5 also

[Alan Stern]

On Fri, 9 Sep 2016, Tony Lindgren wrote:

> With LPAE config we don't have omap3 or omap4 selected for
> omap5 variants.
> 
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
>  drivers/usb/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -472,7 +472,7 @@ config USB_OHCI_HCD_AT91
>  
>  config USB_OHCI_HCD_OMAP3
>  	tristate "OHCI support for OMAP3 and later chips"
> -	depends on (ARCH_OMAP3 || ARCH_OMAP4)
> +	depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
>  	default y
>  	---help---
>  	  Enables support for the on-chip OHCI controller on

Acked-by: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>

You know, as far as I can tell the only thing that is OMAP-specific
about the ohci-omap3 driver is the initialization of OHCI_CTRL_RWC.  
This could be added to the platform data or the DT bindings, after
which this driver wouldn't be needed at all -- the ohci_platform driver
would work.  Does this seem reasonable?

Alan Stern

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

Re: [PATCH] usb: ohci: Allow ohci on omap5 also

[Tony Lindgren]

* Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 12:47]:
> You know, as far as I can tell the only thing that is OMAP-specific
> about the ohci-omap3 driver is the initialization of OHCI_CTRL_RWC.  
> This could be added to the platform data or the DT bindings, after
> which this driver wouldn't be needed at all -- the ohci_platform driver
> would work.  Does this seem reasonable?

Sure makes sense to me. Do we have some standard binding for
OCHI_CTRL_RWC?

Regards,

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

Re: [PATCH] usb: ohci: Allow ohci on omap5 also

[Alan Stern]

On Fri, 9 Sep 2016, Tony Lindgren wrote:

> * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 12:47]:
> > You know, as far as I can tell the only thing that is OMAP-specific
> > about the ohci-omap3 driver is the initialization of OHCI_CTRL_RWC.  
> > This could be added to the platform data or the DT bindings, after
> > which this driver wouldn't be needed at all -- the ohci_platform driver
> > would work.  Does this seem reasonable?
> 
> Sure makes sense to me. Do we have some standard binding for
> OCHI_CTRL_RWC?

No, one would have to be created.

Alan Stern

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

Re: [PATCH] usb: ohci: Allow ohci on omap5 also

[Tony Lindgren]

* Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 13:41]:
> On Fri, 9 Sep 2016, Tony Lindgren wrote:
> 
> > * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 12:47]:
> > > You know, as far as I can tell the only thing that is OMAP-specific
> > > about the ohci-omap3 driver is the initialization of OHCI_CTRL_RWC.  
> > > This could be added to the platform data or the DT bindings, after
> > > which this driver wouldn't be needed at all -- the ohci_platform driver
> > > would work.  Does this seem reasonable?
> > 
> > Sure makes sense to me. Do we have some standard binding for
> > OCHI_CTRL_RWC?
> 
> No, one would have to be created.

OK I can do a patch for that, what should be binding be?

ohci-ctrl-rwc-something?

Regards,

Tony

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

Re: [PATCH] usb: ohci: Allow ohci on omap5 also

[Alan Stern]

On Fri, 9 Sep 2016, Tony Lindgren wrote:

> * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 13:41]:
> > On Fri, 9 Sep 2016, Tony Lindgren wrote:
> > 
> > > * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 12:47]:
> > > > You know, as far as I can tell the only thing that is OMAP-specific
> > > > about the ohci-omap3 driver is the initialization of OHCI_CTRL_RWC.  
> > > > This could be added to the platform data or the DT bindings, after
> > > > which this driver wouldn't be needed at all -- the ohci_platform driver
> > > > would work.  Does this seem reasonable?
> > > 
> > > Sure makes sense to me. Do we have some standard binding for
> > > OCHI_CTRL_RWC?
> > 
> > No, one would have to be created.
> 
> OK I can do a patch for that, what should be binding be?
> 
> ohci-ctrl-rwc-something?

OHCI_CTRL_RWC is just a single-bit flag; the RWC part stands for
"Remote Wakeup Control".  The flag indicates whether the controller
hardware is able to wake up the system, and it is supposed to be set
initially by the firmware during boot-up.  Under DT, the driver will
have to set it manually.

So you could call it ohci-ctrl-rwc-on, or ohci-ctrl-rwc-enable, or 
anything similar.  Use your own judgment.

Alan Stern

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

Re: [PATCH] usb: ohci: Allow ohci on omap5 also

[Alan Stern]

On Fri, 9 Sep 2016, Alan Stern wrote:

> On Fri, 9 Sep 2016, Tony Lindgren wrote:
> 
> > * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 13:41]:
> > > On Fri, 9 Sep 2016, Tony Lindgren wrote:
> > > 
> > > > * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 12:47]:
> > > > > You know, as far as I can tell the only thing that is OMAP-specific
> > > > > about the ohci-omap3 driver is the initialization of OHCI_CTRL_RWC.  
> > > > > This could be added to the platform data or the DT bindings, after
> > > > > which this driver wouldn't be needed at all -- the ohci_platform driver
> > > > > would work.  Does this seem reasonable?
> > > > 
> > > > Sure makes sense to me. Do we have some standard binding for
> > > > OCHI_CTRL_RWC?
> > > 
> > > No, one would have to be created.
> > 
> > OK I can do a patch for that, what should be binding be?
> > 
> > ohci-ctrl-rwc-something?
> 
> OHCI_CTRL_RWC is just a single-bit flag; the RWC part stands for
> "Remote Wakeup Control".

Sorry, careless mistake on my part.  It actually stands for "Remote 
Wakeup Connected"; meaning that the remote-wakeup output signal from 
the controller is connected to something really can wake up the system.
This is exactly the sort of hardware implementation detail that the 
firmware is supposed to know.

Alan Stern

>  The flag indicates whether the controller
> hardware is able to wake up the system, and it is supposed to be set
> initially by the firmware during boot-up.  Under DT, the driver will
> have to set it manually.
> 
> So you could call it ohci-ctrl-rwc-on, or ohci-ctrl-rwc-enable, or 
> anything similar.  Use your own judgment.
> 
> Alan Stern

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

Re: [PATCH] usb: ohci: Allow ohci on omap5 also

[Tony Lindgren]

* Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160910 19:27]:
> On Fri, 9 Sep 2016, Alan Stern wrote:
> 
> > On Fri, 9 Sep 2016, Tony Lindgren wrote:
> > 
> > > * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 13:41]:
> > > > On Fri, 9 Sep 2016, Tony Lindgren wrote:
> > > > 
> > > > > * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 12:47]:
> > > > > > You know, as far as I can tell the only thing that is OMAP-specific
> > > > > > about the ohci-omap3 driver is the initialization of OHCI_CTRL_RWC.  
> > > > > > This could be added to the platform data or the DT bindings, after
> > > > > > which this driver wouldn't be needed at all -- the ohci_platform driver
> > > > > > would work.  Does this seem reasonable?
> > > > > 
> > > > > Sure makes sense to me. Do we have some standard binding for
> > > > > OCHI_CTRL_RWC?
> > > > 
> > > > No, one would have to be created.
> > > 
> > > OK I can do a patch for that, what should be binding be?
> > > 
> > > ohci-ctrl-rwc-something?
> > 
> > OHCI_CTRL_RWC is just a single-bit flag; the RWC part stands for
> > "Remote Wakeup Control".
> 
> Sorry, careless mistake on my part.  It actually stands for "Remote 
> Wakeup Connected"; meaning that the remote-wakeup output signal from 
> the controller is connected to something really can wake up the system.
> This is exactly the sort of hardware implementation detail that the 
> firmware is supposed to know.

OK thanks. I think it can be set up as a generic wakeirq.

> >  The flag indicates whether the controller
> > hardware is able to wake up the system, and it is supposed to be set
> > initially by the firmware during boot-up.  Under DT, the driver will
> > have to set it manually.
> > 
> > So you could call it ohci-ctrl-rwc-on, or ohci-ctrl-rwc-enable, or 
> > anything similar.  Use your own judgment.

OK

Regards,

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

Re: [PATCH] usb: ohci: Allow ohci on omap5 also

[Tony Lindgren]

Hi,

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [160913 15:48]:
> * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160910 19:27]:
> > On Fri, 9 Sep 2016, Alan Stern wrote:
> > 
> > > On Fri, 9 Sep 2016, Tony Lindgren wrote:
> > > 
> > > > * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 13:41]:
> > > > > On Fri, 9 Sep 2016, Tony Lindgren wrote:
> > > > > 
> > > > > > * Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160909 12:47]:
> > > > > > > You know, as far as I can tell the only thing that is OMAP-specific
> > > > > > > about the ohci-omap3 driver is the initialization of OHCI_CTRL_RWC.  
> > > > > > > This could be added to the platform data or the DT bindings, after
> > > > > > > which this driver wouldn't be needed at all -- the ohci_platform driver
> > > > > > > would work.  Does this seem reasonable?
> > > > > > 
> > > > > > Sure makes sense to me. Do we have some standard binding for
> > > > > > OCHI_CTRL_RWC?
> > > > > 
> > > > > No, one would have to be created.
> > > > 
> > > > OK I can do a patch for that, what should be binding be?
> > > > 
> > > > ohci-ctrl-rwc-something?
> > > 
> > > OHCI_CTRL_RWC is just a single-bit flag; the RWC part stands for
> > > "Remote Wakeup Control".
> > 
> > Sorry, careless mistake on my part.  It actually stands for "Remote 
> > Wakeup Connected"; meaning that the remote-wakeup output signal from 
> > the controller is connected to something really can wake up the system.
> > This is exactly the sort of hardware implementation detail that the 
> > firmware is supposed to know.
> 
> OK thanks. I think it can be set up as a generic wakeirq.

Sorry for the slowness on this one, I have not forgotten about this.
I now do have a nice testcase of a modem on the ohci bus I can test
with :)

Also looks we can pretty easily support GPIO wake-up events some
integrated USB devices have with the Linux generic wakeirqs. I did
some testing with that and the only question really is where to
configure it. For my tests, I just patched it into bin/unbind in
drivers/net/usb/cdc_ether.c, but I think it can be generic to all
USB devices.

Anyways, patches coming at some point, might take a while though.

Regards,

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