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

[Svyatoslav Ryhel]

ср, 27 трав. 2026 р. о 12:20 Krzysztof Kozlowski <krzk@xxxxxxxxxx> пише:
>
> On 27/05/2026 11:06, Svyatoslav Ryhel wrote:
> > ср, 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
>
> Just to recap:
>
> https://lore.kernel.org/all/CAPVz0n09ZP1i2tasdTvnt8RvjhALvUYjv9u_EGRtnXPOYQtuqQ@xxxxxxxxxxxxxx/
>
> And enormous discussion wasting our time here:
> https://lore.kernel.org/all/CAPVz0n0u7uhL8_FQFiuB7DrnL++ecbaEKEoV7N2PgTVRBVECkw@xxxxxxxxxxxxxx/
> because you were pushing your solution. I run out of spare time to
> handle endless discussions with you because you reject standard comments
> and expect long discussions with multiple justifications for standard
> (and documented in writing bindings) DT rules.
>
> So here I told you to do like USB and PCI. This patchset is nothing like
> them.
>

You are creating an entire database of discussions we had. I am flattered.

> Best regards,
> Krzysztof