Re: [PATCH v2 0/9] arm64: dts: phy: st: usb: Add STM32MP2 USB support

[Fabrice Gasnier <fabrice.gasnier@foss.st.com>]

On 8/17/26 21:48, Marek Vasut wrote:
> On 8/17/26 6:35 PM, Fabrice Gasnier wrote:
>>
>> On 8/16/26 23:37, Marek Vasut wrote:
>>> Add USB support for STM32MP23xx/STM32MP25xx SoCs. This includes USB 2.0
>>> FEMTO-PHY driver, DWC3 glue code and DT adjustments. Parts of this are
>>> taken from ST downstream kernel fork, reduced, or rewritten, since not
>>> all of the content there was useful and bits which might be missing and
>>> are useful can be added later.
>>>
>>> Unlike the downstream implementation, the DWC3 glue code is using plain
>>> dwc3-generic-plat, the EHCI and OHCI controllers are instantiated as
>>> plain generic controllers without any wrapper glue driver, and the USB2
>>> PHY driver is simplified.
>>>
>>> Both USB 2.0 Host controller and DWC3 super-speed controller are tested.
>>
>> Hi Marek,
> 
> Hello Fabrice,
> 
>> Regarding dwc3, I've started to test and needed another patch from our
>> downstream. I've posted it here:
>> https://lore.kernel.org/linux-usb/20260817163101.6203-1-
>> fabrice.gasnier@foss.st.com/
> 
> Understood.
> 
>> Regarding USBH, there's a dedicated glue on STM32MP2x SoCs for the
>> EHCI/OHCI controllers, similar to the dwc3. On dwc3, I see it can be
>> managed.
>>
>> There are:
>> - AFMUX signals out of EHCI/OHCI controllers, to manage a Vbus power
>> switch (with polarity) control.
>> - AFMUX need pinctrl to be added, and managed during system PM
> 
> This can be managed by the PHY instead, can it not ?

Hello Marek,

Please see later comment.

> 
>> - On coming MP21 (not supported here), there's address translation
>> control
> 
> What kind of address translation ? IOMMU ?

This is much more "basic". The controller can address 4G of memory, e.g.
it's 32bits. That feature is only for STM32MP21 that can address 4G of
DDR which starts at 2G offset. So basically there's a SYSCFG bit
(SYSCFG_USBHARCR AREN), that adds a 2G offset so the controller 'DMA'
addresses directly the 4G of the DDR (instead of 2G lower memory map,
that's not necessarily useful, and 2G of the 4G DDR, requiring swiotlb
with perf penalty).

Current downstream glue driver checks the 'dma_range_map', (e.g. DT prop
dma-ranges = <0x0 0x0 0x80000000 0x1 0x0>;) that represent this, to
enable the syscon bit that adds offset in hardware (so 4G of DDR can be
accessed by the controller, without swiotlb).
For USBH, there's nothing mode: set it at probe time, based on
dma_range_map, restore it after resume from low power.

> 
>> - Common dedicated interrupt to manage wakeup
> 
> This is EXTI configuration, is it not ?
> 
>> Using generic controller drivers, I don't see how to manage it, without
>> describing it in the DT.
>>
>> For sure, generic ehci/ochi drivers and bindings can/must be used. What
>> would be the proper place for this glue to leave ? Why not adding the
>> glue driver from the downstream ? That's supposed to address this.
>>
>> Do you wish I send it upstream, so it can be properly reviewed, amended ?
> 
> I would very much prefer to avoid the glue if that is at all possible.
> Thus far, it seems this could be done (interrupts are generic interrupts
> managed by EXTI, Vbus detection polarity is likely a PHY thing since
> this is managed by SYSCFG anyway) ?

I better see your point, thanks for your explanation.
This makes sense! For this part, the approach can be the same on all
STM32MP2 SoCs (21/23/25).

Still for STM32MP21 address remapping feature (out of scope here) I
think there will be not much choice to keep a minimal glue DT & driver
(and parent to generic ehci/ohci). It seems totally out of the PHY
driver purpose.
Maybe you have some thoughts about this ?

Please advise,
Best Regards,
Fabrice

> 
>> I'd like to sort this glue management out before the DT for the USBH can
>> land.
> ACK
> 
> [...]


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy