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

On 8/18/26 18:35, Marek Vasut wrote:
> 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 ?

Hello Marek,

Ok, I'll think more about it regarding MP21. Let's continue on current
series without any additional glue driver for MP23/25.

Thanks,
Best Regards,
Fabrice

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


-- 
linux-phy mailing list
[email protected]
https://lists.infradead.org/mailman/listinfo/linux-phy