Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Krzysztof Kozlowski <krzk@kernel.org>]

On 27/05/2026 09:55, Bartosz Golaszewski wrote:
> On Tue, 26 May 2026 15:41:58 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
>> вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@kernel.org> пише:
>>>
>>> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>>>>
>>>>>>>
>>>>>>> The node attached to the pwrseq provider device should represent a real
>>>>>>> hardware component. Are the enable-gpios and power-supply lines connected
>>>>>>> to the modem package?
>>>>>>
>>>>>> Yes, enable-gpio is connected to the modem and signals that USB is set
>>>>>> and ready to work with the modem, while power-supply is an optional
>>>>>> supply connected to the modem's vbus input.
>>>>>>
>>>>>
>>>>> The modem is a hard-wired USB device? Do you implement it as a
>>>>> platform driver or a USB driver?
>>>>>
>>>>
>>>> It is not a traditional USB device. XMM6260 is an embedded modem used
>>>> in the Tegra phones, it is linked with the AP using USB line in HSIC
>>>> mode. The driver is implemented as a platform device since it does not
>>>> interacts with the exposed USB device directly, it just ensures that
>>>> USB device is properly configured and is ready for IPC.
>>>>
>>>>> Is there a connector of any kind that could be used as the HW
>>>>> component represented by the pwrseq device?
>>>>
>>>> I assume control over USB line is the HW base, but as I have said, I
>>>> can integrate binding in the modem node itself, and pwrseq can get all
>>>> it needs from the match. Pwrseq framework states "This framework is
>>>> designed to abstract complex power-up sequences that are shared
>>>> between multiple logical devices in the Linux kernel." it does not say
>>>> that it must represent some specific hardware.
>>>>
>>>
>>> No, not at all. We just can't make up any imaginary, logical "pwrseq"
>>> devices and describe them in DT bindings.
>>>
>>
>> Ye, ye, sure, pwrseq framework is quite flexible and I am not stating
>> this bindings is mandatory.
>>
>>>> Using pwrseq allows modem driver to be SoC independent since USB line
>>>> handling is moved into SoC specific power sequence, and this modem is
>>>> used in Exynos and OMAP too with similar setup but they all have
>>>> different USB controllers. Maybe you can point me where SoC specific
>>>> USB controller handling can be implemented?
>>>>
>>>
>>> I'm not sure I'm following. Can you atrephrase or point me where OMAP
>>> and Samsung implement it?
>>>
>>
>> They did not.
>>
>> The XMM6260 modem is used not only in the Tegra phones but in the OMAP
>> and Exynos based too. Replicant tried to implement support locally
>> with midas devices and they had some progress. From what I have seen
>> generic implementation I am proposing will work with any of those 3
>> SoCs maybe with some slight tweaks, only part that is totally
>> different and SoC specific is how USB controller used by the modem is
>> handled (well and IPC but that is out of scope of this patchset
>> anyway).
>>
>> Obviously, non of the 3 vendors have submitted any mainline patches,
>> everything is in the downstream forks. I have investigated a bit how
>> this modem works on my Tegra phone and re-implemented it to work with
>> mainline kernel (I don't have Exynos and OMAP devices to play with). I
>> have come up with generic platform driver which handles modem
>> configuration and a SoC specific part which performs USB controller
>> bind/probe when modem is ready to handle the USB. ATM this SoC
>> specific part is available and tested only for Tegra devices.
>>
> 
> Are you familiar with the PCI pwrctrl code that lives under
> drivers/pci/pwrctrl/? It seems to be solving a somewhat similar issue for
> PCI devices that are hardwired and powered externally. Maybe you could use
> some of that code for your USB use-case?


I pointed to PCI already:
https://lore.kernel.org/lkml/20260518-mustard-rabbit-of-ecstasy-eed3b6@quoll/

And emphasized to describe hardware, not drivers. This binding AGAIN
describes drivers, so we did not move forward at all.


Best regards,
Krzysztof