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

[Bartosz Golaszewski]

On Tue, 26 May 2026 15:41:58 +0200, Svyatoslav Ryhel <clamor95@xxxxxxxxx> said:
> вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@xxxxxxxxxx> пише:
>>
>> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@xxxxxxxxx> 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 rephrase 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?

Bartosz