| Message ID | 1387548804-20829-2-git-send-email-valentine.barshak@cogentembedded.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
On Fri, Dec 20, 2013 at 11:13 PM, Valentine Barshak <valentine.barshak@cogentembedded.com> wrote: > This adds USBHS PHY and registers USBHS device if the driver is enabled. > > Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> > --- > arch/arm/mach-shmobile/board-lager.c | 117 +++++++++++++++++++++++++++++++++++ > 1 file changed, 117 insertions(+) Hi Valentine, Thanks for this USB function patch. I'd like to switch focus to USB function soon. By the way, I'm happy to see that SATA platform device support is picked up by Simon. I intend to give your SATA DTS patches a go later this week, they should be ready to queue up rather soon I believe. Would it be possible for you to update your USB function platform device patches for Lager and Koelsch? I'd like to merge those after SATA, and the platform device files shouldn't change now so USB can go next now unless I'm mistaken. Please send a complete per-board series for USB function so patch pick up and testing gets easy - same style as SATA would be great. I suppose we need to control MSTP bits via Runtime PM for USBHS, so some patch for clock control may be needed as well. Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/15/2014 04:39 PM, Magnus Damm wrote: > On Fri, Dec 20, 2013 at 11:13 PM, Valentine Barshak > <valentine.barshak@cogentembedded.com> wrote: >> This adds USBHS PHY and registers USBHS device if the driver is enabled. >> >> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> >> --- >> arch/arm/mach-shmobile/board-lager.c | 117 +++++++++++++++++++++++++++++++++++ >> 1 file changed, 117 insertions(+) > > Hi Valentine, Magnus, Simon, > > Thanks for this USB function patch. I'd like to switch focus to USB > function soon. > > By the way, I'm happy to see that SATA platform device support is > picked up by Simon. I intend to give your SATA DTS patches a go later > this week, they should be ready to queue up rather soon I believe. > > Would it be possible for you to update your USB function platform > device patches for Lager and Koelsch? I'd like to merge those after > SATA, and the platform device files shouldn't change now so USB can go > next now unless I'm mistaken. Please send a complete per-board series > for USB function so patch pick up and testing gets easy - same style > as SATA would be great. Just respinned the USB series for Lager and Koelsch. I did not include defconfig changes yet. I think we need to enable kernel modules in the defconfig first, so that multiple USB gadgets can be selected as modules. Besides, I think that the USBHS device should be disabled in the defconfigs since the boards have USB channel 0 configured as PCI USB host by default. Please, let me know your thoughts regarding defconfig changes and I'll prepare the patches then. Currently, the following options should be enabled if you want to test USB: * USB device and USB host CONFIG_USB=y CONFIG_USB_RCAR_GEN2_PHY=y * USB device CONFIG_USB_RENESAS_USBHS=y CONFIG_USB_GADGET=y CONFIG_USB_RENESAS_USBHS_UDC=y * USB Host CONFIG_PCI=y CONFIG_PCI_RCAR_GEN2=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y > > I suppose we need to control MSTP bits via Runtime PM for USBHS, so > some patch for clock control may be needed as well. Works for me without any additional clock control changes. > > Thanks, > > / magnus > Thanks, Val. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Valentine, On Sat, Jan 18, 2014 at 3:31 AM, Valentine <valentine.barshak@cogentembedded.com> wrote: > On 01/15/2014 04:39 PM, Magnus Damm wrote: >> >> On Fri, Dec 20, 2013 at 11:13 PM, Valentine Barshak >> <valentine.barshak@cogentembedded.com> wrote: >>> >>> This adds USBHS PHY and registers USBHS device if the driver is enabled. >>> >>> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> >>> --- >>> arch/arm/mach-shmobile/board-lager.c | 117 >>> +++++++++++++++++++++++++++++++++++ >>> 1 file changed, 117 insertions(+) >> >> >> Hi Valentine, > > > Magnus, Simon, > > >> >> Thanks for this USB function patch. I'd like to switch focus to USB >> function soon. >> >> By the way, I'm happy to see that SATA platform device support is >> picked up by Simon. I intend to give your SATA DTS patches a go later >> this week, they should be ready to queue up rather soon I believe. >> >> Would it be possible for you to update your USB function platform >> device patches for Lager and Koelsch? I'd like to merge those after >> SATA, and the platform device files shouldn't change now so USB can go >> next now unless I'm mistaken. Please send a complete per-board series >> for USB function so patch pick up and testing gets easy - same style >> as SATA would be great. > > > Just respinned the USB series for Lager and Koelsch. > I did not include defconfig changes yet. Thanks! > I think we need to enable kernel modules in the defconfig first, > so that multiple USB gadgets can be selected as modules. I agree that for testing something is needed., but perhaps a simple composite device is enough? In general I think the USB gadget kernel configuration is something that it is left for the distributions to select since it depends on each use case. Also, using modules is fine but I also think there is some configfs interface that can be used to configure the USB gadget during run time. > Besides, I think that the USBHS device should be disabled in the defconfigs > since the boards have USB channel 0 configured as PCI USB host by default. That I disagree about. =) I know the default dip switch setting for Lager USB0 is USB Host, but I disagree that enabling it as USB Host makes sense. This because there is no proper cable detection and VBUS short circuit may happen in case of USB Host. I propose that we only use USB0 as USB Gadget on Lager. I have some incremental patches for that, so please wait for them instead of hacking up something by yourself. > Please, let me know your thoughts regarding defconfig changes and I'll > prepare the patches then. Ok! > Currently, the following options should be enabled if you want to test USB: > * USB device and USB host > CONFIG_USB=y > CONFIG_USB_RCAR_GEN2_PHY=y > * USB device > CONFIG_USB_RENESAS_USBHS=y > CONFIG_USB_GADGET=y > CONFIG_USB_RENESAS_USBHS_UDC=y > * USB Host > CONFIG_PCI=y > CONFIG_PCI_RCAR_GEN2=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y Thanks for this. It seems that CONFIG_USB_RENESAS_USBHS_UDC requires USB_HOST for some reason. If you have a cycle to spare, can you try to fix it up so it is possible to use USBHS for Gadget-only? I think some Kconfig changes are needed for USBHS. >> I suppose we need to control MSTP bits via Runtime PM for USBHS, so >> some patch for clock control may be needed as well. > > > Works for me without any additional clock control changes. That's because you have Runtime PM disabled. =) Please try with using CONFIG_PM_RUNTIME=y. In that case I believe you will need to control MSTP704. Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/24/2014 08:40 AM, Magnus Damm wrote: > Hi Valentine, > Hi Magnus, > On Sat, Jan 18, 2014 at 3:31 AM, Valentine > <valentine.barshak@cogentembedded.com> wrote: >> On 01/15/2014 04:39 PM, Magnus Damm wrote: >>> >>> On Fri, Dec 20, 2013 at 11:13 PM, Valentine Barshak >>> <valentine.barshak@cogentembedded.com> wrote: >>>> >>>> This adds USBHS PHY and registers USBHS device if the driver is enabled. >>>> >>>> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> >>>> --- >>>> arch/arm/mach-shmobile/board-lager.c | 117 >>>> +++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 117 insertions(+) >>> >>> >>> Hi Valentine, >> >> >> Magnus, Simon, >> >> >>> >>> Thanks for this USB function patch. I'd like to switch focus to USB >>> function soon. >>> >>> By the way, I'm happy to see that SATA platform device support is >>> picked up by Simon. I intend to give your SATA DTS patches a go later >>> this week, they should be ready to queue up rather soon I believe. >>> >>> Would it be possible for you to update your USB function platform >>> device patches for Lager and Koelsch? I'd like to merge those after >>> SATA, and the platform device files shouldn't change now so USB can go >>> next now unless I'm mistaken. Please send a complete per-board series >>> for USB function so patch pick up and testing gets easy - same style >>> as SATA would be great. >> >> >> Just respinned the USB series for Lager and Koelsch. >> I did not include defconfig changes yet. > > Thanks! > >> I think we need to enable kernel modules in the defconfig first, >> so that multiple USB gadgets can be selected as modules. > > I agree that for testing something is needed., but perhaps a simple > composite device is enough? > > In general I think the USB gadget kernel configuration is something > that it is left for the distributions to select since it depends on > each use case. Also, using modules is fine but I also think there is > some configfs interface that can be used to configure the USB gadget > during run time. I've sent a couple of patches that enable modules for lager and koelsch. I think this is useful even if we decide to go with composite gadget. > >> Besides, I think that the USBHS device should be disabled in the defconfigs >> since the boards have USB channel 0 configured as PCI USB host by default. > > That I disagree about. =) > > I know the default dip switch setting for Lager USB0 is USB Host, but > I disagree that enabling it as USB Host makes sense. This because > there is no proper cable detection and VBUS short circuit may happen > in case of USB Host. > > I propose that we only use USB0 as USB Gadget on Lager. I have some > incremental patches for that, so please wait for them instead of > hacking up something by yourself. I'm not sure why this should be done since the port can be configured and used as USB host as well. The approach I use is the port is always configured as USB device if USBHS gadget is enabled in the kernel. Isn't it enough to enable USBHS gadget in defconfig for you? I've respinned V3 of the USB patches for Lager and Koelsch. Could you please take a look at the Koelsch series as well (including the PCI USB host support)? > >> Please, let me know your thoughts regarding defconfig changes and I'll >> prepare the patches then. > > Ok! > >> Currently, the following options should be enabled if you want to test USB: >> * USB device and USB host >> CONFIG_USB=y >> CONFIG_USB_RCAR_GEN2_PHY=y >> * USB device >> CONFIG_USB_RENESAS_USBHS=y >> CONFIG_USB_GADGET=y >> CONFIG_USB_RENESAS_USBHS_UDC=y >> * USB Host >> CONFIG_PCI=y >> CONFIG_PCI_RCAR_GEN2=y >> CONFIG_USB_EHCI_HCD=y >> CONFIG_USB_OHCI_HCD=y > > Thanks for this. It seems that CONFIG_USB_RENESAS_USBHS_UDC requires > USB_HOST for some reason. > > If you have a cycle to spare, can you try to fix it up so it is > possible to use USBHS for Gadget-only? > > I think some Kconfig changes are needed for USBHS. OK I'll look into it. > >>> I suppose we need to control MSTP bits via Runtime PM for USBHS, so >>> some patch for clock control may be needed as well. >> >> >> Works for me without any additional clock control changes. > > That's because you have Runtime PM disabled. =) I have it enabled. > > Please try with using CONFIG_PM_RUNTIME=y. In that case I believe you > will need to control MSTP704. Seems to be working fine for me with CONFIG_PM_RUNTIME=y. > > Thanks, > > / magnus > Thanks, Val. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Valentine, On Sat, Jan 25, 2014 at 8:05 AM, Valentine <valentine.barshak@cogentembedded.com> wrote: > On 01/24/2014 08:40 AM, Magnus Damm wrote: >> >> Hi Valentine, >> > > Hi Magnus, > > >> On Sat, Jan 18, 2014 at 3:31 AM, Valentine >> <valentine.barshak@cogentembedded.com> wrote: >>> >>> On 01/15/2014 04:39 PM, Magnus Damm wrote: >>>> >>>> >>>> On Fri, Dec 20, 2013 at 11:13 PM, Valentine Barshak >>>> <valentine.barshak@cogentembedded.com> wrote: >>>>> >>>>> >>>>> This adds USBHS PHY and registers USBHS device if the driver is >>>>> enabled. >>>>> >>>>> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> >>>>> --- >>>>> arch/arm/mach-shmobile/board-lager.c | 117 >>>>> +++++++++++++++++++++++++++++++++++ >>>>> 1 file changed, 117 insertions(+) >>>> >>>> >>>> >>>> Hi Valentine, >>> >>> >>> >>> Magnus, Simon, >>> >>> >>>> >>>> Thanks for this USB function patch. I'd like to switch focus to USB >>>> function soon. >>>> >>>> By the way, I'm happy to see that SATA platform device support is >>>> picked up by Simon. I intend to give your SATA DTS patches a go later >>>> this week, they should be ready to queue up rather soon I believe. >>>> >>>> Would it be possible for you to update your USB function platform >>>> device patches for Lager and Koelsch? I'd like to merge those after >>>> SATA, and the platform device files shouldn't change now so USB can go >>>> next now unless I'm mistaken. Please send a complete per-board series >>>> for USB function so patch pick up and testing gets easy - same style >>>> as SATA would be great. >>> >>> >>> >>> Just respinned the USB series for Lager and Koelsch. >>> I did not include defconfig changes yet. >> >> >> Thanks! >> >>> I think we need to enable kernel modules in the defconfig first, >>> so that multiple USB gadgets can be selected as modules. >> >> >> I agree that for testing something is needed., but perhaps a simple >> composite device is enough? >> >> In general I think the USB gadget kernel configuration is something >> that it is left for the distributions to select since it depends on >> each use case. Also, using modules is fine but I also think there is >> some configfs interface that can be used to configure the USB gadget >> during run time. > > > I've sent a couple of patches that enable modules for lager and koelsch. > I think this is useful even if we decide to go with composite gadget. Ok, thanks, I will duck and let Simon decide about this! >>> Besides, I think that the USBHS device should be disabled in the >>> defconfigs >>> since the boards have USB channel 0 configured as PCI USB host by >>> default. >> >> >> That I disagree about. =) >> >> I know the default dip switch setting for Lager USB0 is USB Host, but >> I disagree that enabling it as USB Host makes sense. This because >> there is no proper cable detection and VBUS short circuit may happen >> in case of USB Host. >> >> I propose that we only use USB0 as USB Gadget on Lager. I have some >> incremental patches for that, so please wait for them instead of >> hacking up something by yourself. > > > I'm not sure why this should be done since the port can be configured and > used as USB host as well. It may be configured and used as USB Host as well, but only if SW5 and SW6 are setup correctly. > The approach I use is the port is always configured as USB device if USBHS > gadget is enabled in the kernel. > Isn't it enough to enable USBHS gadget in defconfig for you? But this means that depending on kernel configuration you may end up driving VBUS unexpectedly. Also, the USBHS hardware actually allows for USB Host operation too. So in the end it is a policy decision how the USB ports shall be used. Since we have three ports I suggest that we partition them as follows: USB0: USBHS Function USB1: PCI USB 2.0 USB2: USB 3.0 (but PCI USB 2.0 to begin with) > I've respinned V3 of the USB patches for Lager and Koelsch. > Could you please take a look at the Koelsch series as well > (including the PCI USB host support)? Thanks. As I wrote in a separate email, I have some concerns about lacking bounce buffers for PCI USB in the case of LPAE=y. I'd like to check the state of that before merging the actual USB PCI devices on Lager and Koelsch. >>> Please, let me know your thoughts regarding defconfig changes and I'll >>> prepare the patches then. >> >> >> Ok! >> >>> Currently, the following options should be enabled if you want to test >>> USB: >>> * USB device and USB host >>> CONFIG_USB=y >>> CONFIG_USB_RCAR_GEN2_PHY=y >>> * USB device >>> CONFIG_USB_RENESAS_USBHS=y >>> CONFIG_USB_GADGET=y >>> CONFIG_USB_RENESAS_USBHS_UDC=y >>> * USB Host >>> CONFIG_PCI=y >>> CONFIG_PCI_RCAR_GEN2=y >>> CONFIG_USB_EHCI_HCD=y >>> CONFIG_USB_OHCI_HCD=y >> >> >> Thanks for this. It seems that CONFIG_USB_RENESAS_USBHS_UDC requires >> USB_HOST for some reason. >> >> If you have a cycle to spare, can you try to fix it up so it is >> possible to use USBHS for Gadget-only? >> >> I think some Kconfig changes are needed for USBHS. > > > OK I'll look into it. Thanks! >>>> I suppose we need to control MSTP bits via Runtime PM for USBHS, so >>>> some patch for clock control may be needed as well. >>> >>> >>> >>> Works for me without any additional clock control changes. >> >> >> That's because you have Runtime PM disabled. =) > > > I have it enabled. > > >> >> Please try with using CONFIG_PM_RUNTIME=y. In that case I believe you >> will need to control MSTP704. > > > Seems to be working fine for me with CONFIG_PM_RUNTIME=y. Are you actively managing MSTP704 or just leaving it enabled in a static setting? =) Please try tying in MSTP704 using Runtime PM. If you need any assistance please let me know and I will help. Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 27, 2014 at 07:26:53PM +0900, Magnus Damm wrote: > Hi Valentine, > > On Sat, Jan 25, 2014 at 8:05 AM, Valentine > <valentine.barshak@cogentembedded.com> wrote: > > On 01/24/2014 08:40 AM, Magnus Damm wrote: > >> > >> Hi Valentine, > >> > > > > Hi Magnus, > > > > > >> On Sat, Jan 18, 2014 at 3:31 AM, Valentine > >> <valentine.barshak@cogentembedded.com> wrote: > >>> > >>> On 01/15/2014 04:39 PM, Magnus Damm wrote: > >>>> > >>>> > >>>> On Fri, Dec 20, 2013 at 11:13 PM, Valentine Barshak > >>>> <valentine.barshak@cogentembedded.com> wrote: > >>>>> > >>>>> > >>>>> This adds USBHS PHY and registers USBHS device if the driver is > >>>>> enabled. > >>>>> > >>>>> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> > >>>>> --- > >>>>> arch/arm/mach-shmobile/board-lager.c | 117 > >>>>> +++++++++++++++++++++++++++++++++++ > >>>>> 1 file changed, 117 insertions(+) > >>>> > >>>> > >>>> > >>>> Hi Valentine, > >>> > >>> > >>> > >>> Magnus, Simon, > >>> > >>> > >>>> > >>>> Thanks for this USB function patch. I'd like to switch focus to USB > >>>> function soon. > >>>> > >>>> By the way, I'm happy to see that SATA platform device support is > >>>> picked up by Simon. I intend to give your SATA DTS patches a go later > >>>> this week, they should be ready to queue up rather soon I believe. > >>>> > >>>> Would it be possible for you to update your USB function platform > >>>> device patches for Lager and Koelsch? I'd like to merge those after > >>>> SATA, and the platform device files shouldn't change now so USB can go > >>>> next now unless I'm mistaken. Please send a complete per-board series > >>>> for USB function so patch pick up and testing gets easy - same style > >>>> as SATA would be great. > >>> > >>> > >>> > >>> Just respinned the USB series for Lager and Koelsch. > >>> I did not include defconfig changes yet. > >> > >> > >> Thanks! > >> > >>> I think we need to enable kernel modules in the defconfig first, > >>> so that multiple USB gadgets can be selected as modules. > >> > >> > >> I agree that for testing something is needed., but perhaps a simple > >> composite device is enough? > >> > >> In general I think the USB gadget kernel configuration is something > >> that it is left for the distributions to select since it depends on > >> each use case. Also, using modules is fine but I also think there is > >> some configfs interface that can be used to configure the USB gadget > >> during run time. > > > > > > I've sent a couple of patches that enable modules for lager and koelsch. > > I think this is useful even if we decide to go with composite gadget. > > Ok, thanks, I will duck and let Simon decide about this! I think it would be better to wait until we need modules before turning them on. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/29/2014 10:11 AM, Simon Horman wrote: > On Mon, Jan 27, 2014 at 07:26:53PM +0900, Magnus Damm wrote: >> Hi Valentine, >> >> On Sat, Jan 25, 2014 at 8:05 AM, Valentine >> <valentine.barshak@cogentembedded.com> wrote: >>> On 01/24/2014 08:40 AM, Magnus Damm wrote: >>>> >>>> Hi Valentine, >>>> >>> >>> Hi Magnus, >>> >>> >>>> On Sat, Jan 18, 2014 at 3:31 AM, Valentine >>>> <valentine.barshak@cogentembedded.com> wrote: >>>>> >>>>> On 01/15/2014 04:39 PM, Magnus Damm wrote: >>>>>> >>>>>> >>>>>> On Fri, Dec 20, 2013 at 11:13 PM, Valentine Barshak >>>>>> <valentine.barshak@cogentembedded.com> wrote: >>>>>>> >>>>>>> >>>>>>> This adds USBHS PHY and registers USBHS device if the driver is >>>>>>> enabled. >>>>>>> >>>>>>> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> >>>>>>> --- >>>>>>> arch/arm/mach-shmobile/board-lager.c | 117 >>>>>>> +++++++++++++++++++++++++++++++++++ >>>>>>> 1 file changed, 117 insertions(+) >>>>>> >>>>>> >>>>>> >>>>>> Hi Valentine, >>>>> >>>>> >>>>> >>>>> Magnus, Simon, >>>>> >>>>> >>>>>> >>>>>> Thanks for this USB function patch. I'd like to switch focus to USB >>>>>> function soon. >>>>>> >>>>>> By the way, I'm happy to see that SATA platform device support is >>>>>> picked up by Simon. I intend to give your SATA DTS patches a go later >>>>>> this week, they should be ready to queue up rather soon I believe. >>>>>> >>>>>> Would it be possible for you to update your USB function platform >>>>>> device patches for Lager and Koelsch? I'd like to merge those after >>>>>> SATA, and the platform device files shouldn't change now so USB can go >>>>>> next now unless I'm mistaken. Please send a complete per-board series >>>>>> for USB function so patch pick up and testing gets easy - same style >>>>>> as SATA would be great. >>>>> >>>>> >>>>> >>>>> Just respinned the USB series for Lager and Koelsch. >>>>> I did not include defconfig changes yet. >>>> >>>> >>>> Thanks! >>>> >>>>> I think we need to enable kernel modules in the defconfig first, >>>>> so that multiple USB gadgets can be selected as modules. >>>> >>>> >>>> I agree that for testing something is needed., but perhaps a simple >>>> composite device is enough? >>>> >>>> In general I think the USB gadget kernel configuration is something >>>> that it is left for the distributions to select since it depends on >>>> each use case. Also, using modules is fine but I also think there is >>>> some configfs interface that can be used to configure the USB gadget >>>> during run time. >>> >>> >>> I've sent a couple of patches that enable modules for lager and koelsch. >>> I think this is useful even if we decide to go with composite gadget. >> >> Ok, thanks, I will duck and let Simon decide about this! > > I think it would be better to wait until we need modules > before turning them on. > Well, you may never need them and have everything built-in. Thought you might want modules for USB gadgets. What configuration do you propose for the USBHS gadget? Do you want me to add composite gadget built-in? Thanks, Val. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 29, 2014 at 01:21:49PM +0400, Valentine wrote: > On 01/29/2014 10:11 AM, Simon Horman wrote: > >On Mon, Jan 27, 2014 at 07:26:53PM +0900, Magnus Damm wrote: > >>Hi Valentine, > >> > >>On Sat, Jan 25, 2014 at 8:05 AM, Valentine > >><valentine.barshak@cogentembedded.com> wrote: > >>>On 01/24/2014 08:40 AM, Magnus Damm wrote: > >>>> > >>>>Hi Valentine, > >>>> > >>> > >>>Hi Magnus, > >>> > >>> > >>>>On Sat, Jan 18, 2014 at 3:31 AM, Valentine > >>>><valentine.barshak@cogentembedded.com> wrote: > >>>>> > >>>>>On 01/15/2014 04:39 PM, Magnus Damm wrote: > >>>>>> > >>>>>> > >>>>>>On Fri, Dec 20, 2013 at 11:13 PM, Valentine Barshak > >>>>>><valentine.barshak@cogentembedded.com> wrote: > >>>>>>> > >>>>>>> > >>>>>>>This adds USBHS PHY and registers USBHS device if the driver is > >>>>>>>enabled. > >>>>>>> > >>>>>>>Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> > >>>>>>>--- > >>>>>>> arch/arm/mach-shmobile/board-lager.c | 117 > >>>>>>>+++++++++++++++++++++++++++++++++++ > >>>>>>> 1 file changed, 117 insertions(+) > >>>>>> > >>>>>> > >>>>>> > >>>>>>Hi Valentine, > >>>>> > >>>>> > >>>>> > >>>>>Magnus, Simon, > >>>>> > >>>>> > >>>>>> > >>>>>>Thanks for this USB function patch. I'd like to switch focus to USB > >>>>>>function soon. > >>>>>> > >>>>>>By the way, I'm happy to see that SATA platform device support is > >>>>>>picked up by Simon. I intend to give your SATA DTS patches a go later > >>>>>>this week, they should be ready to queue up rather soon I believe. > >>>>>> > >>>>>>Would it be possible for you to update your USB function platform > >>>>>>device patches for Lager and Koelsch? I'd like to merge those after > >>>>>>SATA, and the platform device files shouldn't change now so USB can go > >>>>>>next now unless I'm mistaken. Please send a complete per-board series > >>>>>>for USB function so patch pick up and testing gets easy - same style > >>>>>>as SATA would be great. > >>>>> > >>>>> > >>>>> > >>>>>Just respinned the USB series for Lager and Koelsch. > >>>>>I did not include defconfig changes yet. > >>>> > >>>> > >>>>Thanks! > >>>> > >>>>>I think we need to enable kernel modules in the defconfig first, > >>>>>so that multiple USB gadgets can be selected as modules. > >>>> > >>>> > >>>>I agree that for testing something is needed., but perhaps a simple > >>>>composite device is enough? > >>>> > >>>>In general I think the USB gadget kernel configuration is something > >>>>that it is left for the distributions to select since it depends on > >>>>each use case. Also, using modules is fine but I also think there is > >>>>some configfs interface that can be used to configure the USB gadget > >>>>during run time. > >>> > >>> > >>>I've sent a couple of patches that enable modules for lager and koelsch. > >>>I think this is useful even if we decide to go with composite gadget. > >> > >>Ok, thanks, I will duck and let Simon decide about this! > > > >I think it would be better to wait until we need modules > >before turning them on. > > > > Well, you may never need them and have everything built-in. > > Thought you might want modules for USB gadgets. > What configuration do you propose for the USBHS gadget? > Do you want me to add composite gadget built-in? I had assumed that they needed to be modules if there was to be more than one of them. Is there an alternate approach? -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Simon, Valentine, On Tue, Feb 4, 2014 at 9:44 PM, Simon Horman <horms@verge.net.au> wrote: > On Wed, Jan 29, 2014 at 01:21:49PM +0400, Valentine wrote: >> On 01/29/2014 10:11 AM, Simon Horman wrote: >> >On Mon, Jan 27, 2014 at 07:26:53PM +0900, Magnus Damm wrote: >> >>On Sat, Jan 25, 2014 at 8:05 AM, Valentine >> >><valentine.barshak@cogentembedded.com> wrote: >> >>>On 01/24/2014 08:40 AM, Magnus Damm wrote: >> >>>>On Sat, Jan 18, 2014 at 3:31 AM, Valentine >> >>>><valentine.barshak@cogentembedded.com> wrote: >> >>>I've sent a couple of patches that enable modules for lager and koelsch. >> >>>I think this is useful even if we decide to go with composite gadget. >> >> >> >>Ok, thanks, I will duck and let Simon decide about this! >> > >> >I think it would be better to wait until we need modules >> >before turning them on. >> > >> >> Well, you may never need them and have everything built-in. >> >> Thought you might want modules for USB gadgets. >> What configuration do you propose for the USBHS gadget? >> Do you want me to add composite gadget built-in? > > I had assumed that they needed to be modules if there was to be > more than one of them. Is there an alternate approach? In older kernels there were limitations which kind of software support you wanted to support in case of USB Function/Gadget. So historically modules were used to handle that. Also, independently of modules it is and has been possible to use sysfs and bind to perform similar things, but I'm not sure if that will work with USB Function. For USB Function there is CONFIG_USB_CONFIGFS that I believe should make it possible to handle configuration during runtime. So if we should enable something for USB Function in our defconfigs then CONFIG_USB_CONFIGFS is probably the way to go. Feel free to prove me wrong though. Valentine, can you check if CONFIG_USB_CONFIGFS is working for you with USBHS? Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c index f20c10a..06cf92c 100644 --- a/arch/arm/mach-shmobile/board-lager.c +++ b/arch/arm/mach-shmobile/board-lager.c @@ -29,6 +29,7 @@ #include <linux/pinctrl/machine.h> #include <linux/platform_data/gpio-rcar.h> #include <linux/platform_data/rcar-du.h> +#include <linux/platform_data/usb-rcar-gen2-phy.h> #include <linux/platform_device.h> #include <linux/phy.h> #include <linux/regulator/driver.h> @@ -36,6 +37,8 @@ #include <linux/regulator/gpio-regulator.h> #include <linux/regulator/machine.h> #include <linux/sh_eth.h> +#include <linux/usb/phy.h> +#include <linux/usb/renesas_usbhs.h> #include <mach/common.h> #include <mach/irqs.h> #include <mach/r8a7790.h> @@ -291,6 +294,110 @@ static const struct resource qspi_resources[] __initconst = { DEFINE_RES_IRQ(gic_spi(184)), }; +/* USBHS */ +#if IS_ENABLED(CONFIG_USB_RENESAS_USBHS_UDC) +static const struct resource usbhs_resources[] __initconst = { + DEFINE_RES_MEM(0xe6590000, 0x100), + DEFINE_RES_IRQ(gic_spi(107)), +}; + +struct usbhs_private { + struct renesas_usbhs_platform_info info; + struct usb_phy *phy; +}; + +#define usbhs_get_priv(pdev) \ + container_of(renesas_usbhs_get_info(pdev), struct usbhs_private, info) + +static int usbhs_power_ctrl(struct platform_device *pdev, + void __iomem *base, int enable) +{ + struct usbhs_private *priv = usbhs_get_priv(pdev); + + if (!priv->phy) + return -ENODEV; + + if (enable) { + int retval = usb_phy_init(priv->phy); + + if (!retval) + retval = usb_phy_set_suspend(priv->phy, 0); + return retval; + } + + usb_phy_set_suspend(priv->phy, 1); + usb_phy_shutdown(priv->phy); + return 0; +} + +static int usbhs_hardware_init(struct platform_device *pdev) +{ + struct usbhs_private *priv = usbhs_get_priv(pdev); + struct usb_phy *phy; + + phy = usb_get_phy_dev(&pdev->dev, 0); + if (IS_ERR(phy)) + return PTR_ERR(phy); + + priv->phy = phy; + return 0; +} + +static int usbhs_hardware_exit(struct platform_device *pdev) +{ + struct usbhs_private *priv = usbhs_get_priv(pdev); + + if (!priv->phy) + return 0; + + usb_put_phy(priv->phy); + priv->phy = NULL; + return 0; +} + +static int usbhs_get_id(struct platform_device *pdev) +{ + return USBHS_GADGET; +} + +static struct usbhs_private usbhs_priv __initdata = { + .info = { + .platform_callback = { + .power_ctrl = usbhs_power_ctrl, + .hardware_init = usbhs_hardware_init, + .hardware_exit = usbhs_hardware_exit, + .get_id = usbhs_get_id, + }, + .driver_param = { + .buswait_bwait = 4, + }, + } +}; + +static void __init lager_register_usbhs(void) +{ + usb_bind_phy("renesas_usbhs", 0, "usb_phy_rcar_gen2"); + platform_device_register_resndata(&platform_bus, + "renesas_usbhs", -1, + usbhs_resources, + ARRAY_SIZE(usbhs_resources), + &usbhs_priv.info, + sizeof(usbhs_priv.info)); +} +#else /* CONFIG_USB_RENESAS_USBHS_UDC */ +static inline void lager_register_usbhs(void) { } +#endif /* CONFIG_USB_RENESAS_USBHS_UDC */ + +/* USBHS PHY */ +static const struct rcar_gen2_phy_platform_data usbhs_phy_pdata __initconst = { + .chan0_pci = 0, /* Channel 0 is USBHS */ + .chan2_pci = 1, /* Channel 2 is PCI USB */ +}; + +static const struct resource usbhs_phy_resources[] __initconst = { + DEFINE_RES_MEM(0xe6590100, 0x100), +}; + static const struct pinctrl_map lager_pinctrl_map[] = { /* DU (CN10: ARGB0, CN13: LVDS) */ PIN_MAP_MUX_GROUP_DEFAULT("rcar-du-r8a7790", "pfc-r8a7790", @@ -319,6 +426,9 @@ static const struct pinctrl_map lager_pinctrl_map[] = { "eth_rmii", "eth"), PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790", "intc_irq0", "intc"), + /* USB0 */ + PIN_MAP_MUX_GROUP_DEFAULT("renesas_usbhs", "pfc-r8a7790", + "usb0", "usb0"), }; static void __init lager_add_standard_devices(void) @@ -368,6 +478,13 @@ static void __init lager_add_standard_devices(void) &vccq_sdhi0_info, sizeof(struct gpio_regulator_config)); platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++, &vccq_sdhi2_info, sizeof(struct gpio_regulator_config)); + + platform_device_register_resndata(&platform_bus, "usb_phy_rcar_gen2", + -1, usbhs_phy_resources, + ARRAY_SIZE(usbhs_phy_resources), + &usbhs_phy_pdata, + sizeof(usbhs_phy_pdata)); + lager_register_usbhs(); } /*
This adds USBHS PHY and registers USBHS device if the driver is enabled. Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> --- arch/arm/mach-shmobile/board-lager.c | 117 +++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+)