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

[Svyatoslav Ryhel]

ср, 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.

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