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

[Bartosz Golaszewski]

On Wed, 27 May 2026 11:06:11 +0200, Svyatoslav Ryhel <clamor95@xxxxxxxxx> said:
> ср, 27 трав. 2026 р. о 11:26 Krzysztof Kozlowski <krzk@xxxxxxxxxx> пише:
>>
>> On 27/05/2026 09:55, Bartosz Golaszewski wrote:
>> > 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 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
>
> Krzysztof, why are you so mean? Yes, I misunderstood you and sent this
> schema. However, I am not stating or arguing that it must be applied
> or whatever. I am just looking for a proper solution to issue I am
> currently facing.
>

Krzysztof reviews hundreds of patches so his fuse is quite short, don't take
it personally, he's a nice guy in real life. :)

> Anyway. That does not matter, what matters is how to organize
> everything I have regarding this modem into a logic set. This is why I
> am looking for maintainer suggestions.
>
> How I see it ATM:
> - I will remove this schema entirely and add usb-gpio (trigger for
> modem that USB is ready), vbus supply (yes, modem has this line too
> you can check in the P895 schematic) and infineon,usb-bus which
> represents HSIC connection to the modem to the modem schema itself.
> Obviously, I will add detailed descriptions of each component.
> - I will resent patch 2 of this pwrseq with the modem patchset to have
> a bigger picture. Pwrseq will obtain needed data from the modem node
> itself (Bartosz Golaszewski are you fine with this?)

As in: the modem driver will be the pwrseq provider? Sure, sounds good.

> - I will try to get control over Tegra USB controller in the pwrseq
> without need in externally-controlled flag I have proposed for
> chipidea driver. I hope my idea will work.
>
> Will this be acceptable for both of you?
>

Bart