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

[Svyatoslav Ryhel]

ср, 27 трав. 2026 р. о 12:15 Bartosz Golaszewski <brgl@xxxxxxxxxx> пише:
>
> 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.
>

No, consumer. Modem calls SoC specific pwrseq.

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