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

[Marek Vasut <marex@nabladev.com>]

On 8/18/26 6:07 PM, Fabrice Gasnier wrote:

Hello Fabrice,

>>> - 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.

Maybe the DT syscfg node shouldn't be a plain syscon , but rather there 
should be an actual driver which binds to the syscfg DT node and 
configures all these hardware details early on boot ? The USB controller 
drivers will start only later, when the syscfg configuration is already 
set in the hardware by this (future) driver, since they depend on the 
syscfg node and the PHY subnodes. Maybe that is the way to fix the MP21 
without having USB controller glue ?

>>> - 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 see above.