* Re: [Upstream] Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Frank Li @ 2026-04-07 9:37 UTC (permalink / raw)
To: Primoz Fiser
Cc: Florijan Plohl, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
imx, linux-arm-kernel, devicetree, linux-kernel, upstream
In-Reply-To: <707e106b-f444-4c26-9816-c53c8eda8cbb@norik.com>
On Tue, Apr 07, 2026 at 08:14:08AM +0200, Primoz Fiser wrote:
> Hi Frank, Florijan,
>
> On 4/6/26 04:56, Frank Li wrote:
> > On Fri, Apr 03, 2026 at 10:29:00AM +0200, Florijan Plohl wrote:
> >> Hello,
> >>
> >> On 4/2/26 15:50, Frank Li wrote:
> >>> On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
> >>>> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
> >>> what's means PEB-AV-18? Is it random board name?
> >> The PEB-AV-18 is PHYTEC designation for Audio/Video adapter modules that can
> >> be used to connect displays on their boards.
> >>
> >> I will improve commit message to add more such information in v2.
> >>
> >>>
> >>>
> >>>> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
> >>>>
> >>>> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
> >>>> ---
> >>>> arch/arm64/boot/dts/freescale/Makefile | 4 +
> >>>> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> >>>> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> >>> Any difference between 91 and 93, can use one overlay file?
> >>>
> >>> Frank
> >>
> >> Can you suggest how to do so?
> >>
> >> There are imx93-pinfunc.h and imx91-pinfunc.h which are not unified
> >> between imx91 and imx93.
> >
> > I suggest move pinmux setting to mainboard's dts files, which provide
> > plug adaptor header, signal should be descripted in mainboard's dts file,
> > which provide an unified label to overlay file.
>
> Yeah, that would be one way of doing it.
>
> However, the phycore dtsi and phyboard dts are kept simple by design
> choice. This way, all optional pinctrls and peripherals are kept
> separate from the board device-tree to maintain clutter low.
>
> For v2 I would prefer to keep as is (current downstream implementation)
> or at least use this approach:
>
> imx91-93-phyboard-segin-peb-av-18.dtsi
> |
> -> imx91-phyboard-segin-peb-av-18.dtso
> |
> -> imx93-phyboard-segin-peb-av-18.dtso
It is better than v1's method.
Frank
>
> BR,
> Primoz
>
> >
> > Frank
> >
> >>
> >> So we can only create common dtsi like so:
> >>
> >> imx91-93-phyboard-segin-peb-av-18.dtsi
> >>
> >> and still use separate dtsos:
> >>
> >> imx91-phyboard-segin-peb-av-18.dtso
> >> imx93-phyboard-segin-peb-av-18.dtso
> >>
> >> Is that your idea?
> >>
> >> BR,
> >>
> >> Florijan Plohl
> >>
> >>>> --
> >>>> 2.43.0
> >>>>
> > _______________________________________________
> > upstream mailing list -- upstream@lists.phytec.de
> > To unsubscribe send an email to upstream-leave@lists.phytec.de
>
> --
> Primoz Fiser
> phone: +386-41-390-545
> email: primoz.fiser@norik.com
> --
> Norik systems d.o.o.
> Your embedded software partner
> Slovenia, EU
> phone: +386-41-540-545
> email: info@norik.com
>
^ permalink raw reply
* Re: [PATCH v4 3/4] PCI: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-04-07 9:38 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <iaoee5r5e2w52fap7ex23wdikbuvpjpesinedgjkehsedszhzo@64yoo2avmxle>
[-- Attachment #1: Type: text/plain, Size: 12894 bytes --]
On Thu, Apr 02, 2026 at 11:02:02PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Apr 02, 2026 at 04:27:37PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Add a driver for the PCIe controller found on NVIDIA Tegra264 SoCs. The
> > driver is very small, with its main purpose being to set up the address
> > translation registers and then creating a standard PCI host using ECAM.
> >
> > Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> What is the rationale for adding a new driver? Can't you reuse the existing one?
> If so, that should be mentioned in the description.
Which existing one? Tegra PCI controllers for previou generations
(Tegra194 and Tegra234) were DesignWare IP, but Tegra264 is an internal
IP, so the programming is entirely different. I'll add something to that
effect to the commit message.
> > diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> > index 5aaed8ac6e44..6ead04f7bd6e 100644
> > --- a/drivers/pci/controller/Kconfig
> > +++ b/drivers/pci/controller/Kconfig
> > @@ -254,7 +254,15 @@ config PCI_TEGRA
> > select IRQ_MSI_LIB
> > help
> > Say Y here if you want support for the PCIe host controller found
> > - on NVIDIA Tegra SoCs.
> > + on NVIDIA Tegra SoCs (Tegra20 through Tegra186).
> > +
> > +config PCIE_TEGRA264
> > + bool "NVIDIA Tegra264 PCIe controller"
>
> This driver seems to be using external MSI controller. So it can be built as a
> module. Also, you have the remove() callback for some reason.
Okay, I can turn this into a tristate symbol.
> > + depends on ARCH_TEGRA || COMPILE_TEST
> > + depends on PCI_MSI
>
> Why?
I suppose it's not necessary in the sense of it being a build
dependency. At runtime, however, the root complex is not useful if PCI
MSI is not enabled. We can drop this dependency and rely on .config to
have it enabled as needed.
> > diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
> > new file mode 100644
> > index 000000000000..3ce1ad971bdb
> > --- /dev/null
> > +++ b/drivers/pci/controller/pcie-tegra264.c
[...]
> > +struct tegra264_pcie {
> > + struct device *dev;
> > + bool link_up;
>
> Keep bool types at the end to avoid holes.
Done.
> > +static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
> > +{
> > + int err;
> > +
> > + pcie->wake_gpio = devm_gpiod_get_optional(pcie->dev, "nvidia,pex-wake",
>
> You should switch to standard 'wake-gpios' property.
Will do.
> > + GPIOD_IN);
> > + if (IS_ERR(pcie->wake_gpio))
> > + return PTR_ERR(pcie->wake_gpio);
> > +
> > + if (pcie->wake_gpio) {
>
> Since you are bailing out above, you don't need this check.
I think we still want to have this check to handle the case of optional
wake GPIOs. Not all controllers may have this wired up and
devm_gpiod_get_optional() will return NULL (not an ERR_PTR()-encoded
error) if the wake-gpios property is missing.
> > +static void tegra264_pcie_bpmp_set_rp_state(struct tegra264_pcie *pcie)
>
> I don't think this function name is self explanatory. Looks like it is turning
> off the PCIe controller, so how about tegra264_pcie_power_off()?
Agreed. The name is a relic from when this was potentially being used to
toggle on and off the controller. But it's only used for disabling, so
tegra264_pcie__power_off() sounds much better.
> > +{
> > + struct tegra_bpmp_message msg = {};
> > + struct mrq_pcie_request req = {};
> > + int err;
> > +
> > + req.cmd = CMD_PCIE_RP_CONTROLLER_OFF;
> > + req.rp_ctrlr_off.rp_controller = pcie->ctl_id;
> > +
> > + msg.mrq = MRQ_PCIE;
> > + msg.tx.data = &req;
> > + msg.tx.size = sizeof(req);
> > +
> > + err = tegra_bpmp_transfer(pcie->bpmp, &msg);
> > + if (err)
> > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %pe\n",
>
> Why not dev_err()?
>
> > + pcie->ctl_id, ERR_PTR(err));
> > +
> > + if (msg.rx.ret)
> > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %d\n",
>
> Same here.
These are not fatal errors and are safe to ignore. dev_err() seemed too
strong for this. They also really shouldn't happen. Though I now realize
that's a bad argument, or rather, actually an argument for making them
dev_err() so that they do stand out if they really should happen.
>
> > + pcie->ctl_id, msg.rx.ret);
> > +}
> > +
> > +static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
> > +{
> > + u32 value, speed, width, bw;
> > + int err;
> > +
> > + value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> > + speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
> > + width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
> > +
> > + bw = width * (PCIE_SPEED2MBS_ENC(speed) / BITS_PER_BYTE);
> > + value = MBps_to_icc(bw);
>
> So this becomes, 'width * (PCIE_SPEED2MBS_ENC(speed) / 8) * 1000 / 8'. But don't
> you want, 'width * (PCIE_SPEED2MBS_ENC(speed)) * 1000 / 8'?
This is M*B*ps_to_icc(), not M*b*ps_to_icc(), so we do in fact get the
latter. I almost fell for this as well because I got confused by some of
these macros being all-caps and other times the case actually mattering.
> > + err = icc_set_bw(pcie->icc_path, bw, bw);
> > + if (err < 0)
> > + dev_err(pcie->dev,
> > + "failed to request bandwidth (%u MBps): %pe\n",
> > + bw, ERR_PTR(err));
>
> So you don't want to error out if this fails?
No. This is not a fatal error and the system will continue to work,
albeit perhaps at suboptimal performance. Given that Ethernet and mass
storage are connected to these, a failure to set the bandwidth and
erroring out here may leave the system unusable, but continuing on would
let the system boot and update firmware, kernel or whatever to recover.
I'll add a comment explaining this.
[...]
> > +static void tegra264_pcie_init(struct tegra264_pcie *pcie)
> > +{
> > + enum pci_bus_speed speed;
> > + unsigned int i;
> > + u32 value;
> > +
> > + /* bring the link out of reset */
>
> s/link/controller or endpoint?
This controls the PERST# signal, so I guess "endpoint" would be more
correct.
> > + value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> > + value |= XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
> > + writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> > +
> > + if (!tegra_is_silicon()) {
>
> This looks like some pre-silicon validation thing. Do you really want it to be
> present in the upstream driver?
At this point there is silicon for this chip, but we've been trying to
get some of the pre-silicon code merged upstream as well because
occasionally people will want to run upstream on simulation, even after
silicon is available. At other times we may want to reuse these drivers
on future chips during pre-silicon validation.
Obviously there needs to be a balance. We don't want to have excessive
amounts of code specifically for pre-silicon validation, but in
relatively simple cases like this it is useful.
>
> > + dev_info(pcie->dev,
> > + "skipping link state for PCIe #%u in simulation\n",
> > + pcie->ctl_id);
> > + pcie->link_up = true;
> > + return;
> > + }
> > +
> > + for (i = 0; i < PCIE_LINK_WAIT_MAX_RETRIES; i++) {
> > + if (tegra264_pcie_link_up(pcie, NULL))
> > + break;
> > +
> > + usleep_range(PCIE_LINK_WAIT_US_MIN, PCIE_LINK_WAIT_US_MAX);
> > + }
> > +
> > + if (tegra264_pcie_link_up(pcie, &speed)) {
>
> Why are you doing it for the second time?
It's just a last-resort check to see if it's really not come up after
the retries. Also, in this call we're actually interested in retrieving
the detected link speed.
>
> > + /* Per PCIe r5.0, 6.6.1 wait for 100ms after DLL up */
>
> No need of this comment.
Fair enough. This was perhaps more useful in earlier versions of the
patch before the line below used the standardize wait time.
[...]
> > +static int tegra264_pcie_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct pci_host_bridge *bridge;
> > + struct tegra264_pcie *pcie;
> > + struct resource_entry *bus;
> > + struct resource *res;
> > + int err;
> > +
> > + bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct tegra264_pcie));
> > + if (!bridge)
> > + return dev_err_probe(dev, -ENOMEM,
> > + "failed to allocate host bridge\n");
> > +
> > + pcie = pci_host_bridge_priv(bridge);
> > + platform_set_drvdata(pdev, pcie);
> > + pcie->bridge = bridge;
> > + pcie->dev = dev;
> > +
> > + err = pinctrl_pm_select_default_state(dev);
>
> I questioned this before:
> https://lore.kernel.org/linux-pci/o5sxxdikdjwd76zsedvkpsl54nw6wrhopwsflt43y5st67mrub@uuw3yfjfqthd/
I'll remove this. Looks like we should be fine with just relying on the
default state being set by the pinctrl core. We might need to move it
into the resume callback.
> > + if (err < 0)
> > + return dev_err_probe(dev, err,
> > + "failed to configure sideband pins\n");
> > +
> > + err = tegra264_pcie_parse_dt(pcie);
> > + if (err < 0)
> > + return dev_err_probe(dev, err, "failed to parse device tree");
> > +
> > + pcie->xal = devm_platform_ioremap_resource_byname(pdev, "xal");
> > + if (IS_ERR(pcie->xal))
> > + return dev_err_probe(dev, PTR_ERR(pcie->xal),
> > + "failed to map XAL memory\n");
> > +
> > + pcie->xtl = devm_platform_ioremap_resource_byname(pdev, "xtl-pri");
> > + if (IS_ERR(pcie->xtl))
> > + return dev_err_probe(dev, PTR_ERR(pcie->xtl),
> > + "failed to map XTL-PRI memory\n");
> > +
> > + bus = resource_list_first_type(&bridge->windows, IORESOURCE_BUS);
> > + if (!bus)
> > + return dev_err_probe(dev, -ENODEV,
> > + "failed to get bus resources\n");
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
> > + if (!res)
> > + return dev_err_probe(dev, -ENXIO,
> > + "failed to get ECAM resource\n");
> > +
> > + pcie->icc_path = devm_of_icc_get(&pdev->dev, "write");
> > + if (IS_ERR(pcie->icc_path))
> > + return dev_err_probe(&pdev->dev, PTR_ERR(pcie->icc_path),
> > + "failed to get ICC");
> > +
> > + /*
> > + * Parse BPMP property only for silicon, as interaction with BPMP is
> > + * not needed for other platforms.
> > + */
> > + if (tegra_is_silicon()) {
> > + pcie->bpmp = tegra_bpmp_get_with_id(dev, &pcie->ctl_id);
> > + if (IS_ERR(pcie->bpmp))
> > + return dev_err_probe(dev, PTR_ERR(pcie->bpmp),
> > + "failed to get BPMP\n");
> > + }
> > +
>
> pm_runtime_set_active()
>
> > + pm_runtime_enable(dev);
>
> devm_pm_runtime_enable()?
Looks like I can even use devm_pm_runtime_set_active_enabled() to
combine the two.
>
> > + pm_runtime_get_sync(dev);
> > +
> > + /* sanity check that programmed ranges match what's in DT */
> > + if (!tegra264_pcie_check_ranges(pdev)) {
> > + err = -EINVAL;
> > + goto put_pm;
> > + }
> > +
> > + pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
> > + if (IS_ERR(pcie->cfg)) {
> > + err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
> > + "failed to create ECAM\n");
> > + goto put_pm;
> > + }
> > +
> > + bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> > + bridge->sysdata = pcie->cfg;
> > + pcie->ecam = pcie->cfg->win;
> > +
> > + tegra264_pcie_init(pcie);
> > +
> > + if (!pcie->link_up)
> > + goto free;
>
> goto free_ecam;
It's not clear to me, but are you suggesting to rename the existing
"free" label to "free_ecam"? I can do that.
> > + err = pci_host_probe(bridge);
> > + if (err < 0) {
> > + dev_err(dev, "failed to register host: %pe\n", ERR_PTR(err));
>
> dev_err_probe()
Okay.
>
> > + goto free;
> > + }
> > +
> > + return err;
>
> return 0;
Done.
[...]
> > +static int tegra264_pcie_resume_noirq(struct device *dev)
> > +{
> > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > + int err;
> > +
> > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > + err = disable_irq_wake(pcie->wake_irq);
> > + if (err < 0)
> > + dev_err(dev, "failed to disable wake IRQ: %pe\n",
> > + ERR_PTR(err));
> > + }
> > +
> > + if (pcie->link_up == false)
> > + return 0;
> > +
> > + tegra264_pcie_init(pcie);
> > +
>
> Why do you need init() here without deinit() in tegra264_pcie_suspend_noirq()?
That's because when we come out of suspend the link may have gone down
again, so we need to take the endpoint out of reset to retrigger the
link training. I think we could possibly explicitly clear that PERST_O_N
bit in the PERST_CONTROL register in a new tegra264_pcie_deinit() to
mirror what tegra264_pcie_init() does, but it's automatically done by
firmware anyway, so not needed.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 01/19] dt-bindings: display/panel: himax,hx83102: describe Waveshare panel
From: Linus Walleij @ 2026-04-07 9:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
Liam Girdwood, Mark Brown, Bartosz Golaszewski, dri-devel,
devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260402-sticky-wooden-silkworm-5bdff4@quoll>
On Thu, Apr 2, 2026 at 10:30 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, Apr 01, 2026 at 10:26:20AM +0300, Dmitry Baryshkov wrote:
> > + # Waveshare 12.3-DSI-TOUCH-A panel
> > + - waveshare,12.3-dsi-touch-a
>
> I don't think we use '.' in compatibles, so waveshare,12-3-dsi-touch-a
Qualcomm happen to use periods in similar cases for their
"qualcomm universal peripheral":
Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml
I don't know if the policy changed since, but that's a big and widespread
platform and I never saw it challenged so I think it's kind of established
that we do.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 7/8] arm64: dts: qcom: sm8750: Correct and complete DP address spaces
From: Konrad Dybcio @ 2026-04-07 9:40 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kuogee Hsieh, Neil Armstrong, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski, Dmitry Baryshkov
In-Reply-To: <20260405-dts-qcom-display-regs-v2-7-34f4024c65dc@oss.qualcomm.com>
On 4/5/26 4:34 PM, Krzysztof Kozlowski wrote:
> DisplayPort block on Qualcomm SM8750 has few too short address space
> ranges and misses four more spaces. Complete the hardware description,
> which in the future might be important for full feature support.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 6/8] arm64: dts: qcom: sm8650: Correct and complete DP address spaces
From: Konrad Dybcio @ 2026-04-07 9:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kuogee Hsieh, Neil Armstrong, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski, Dmitry Baryshkov
In-Reply-To: <20260405-dts-qcom-display-regs-v2-6-34f4024c65dc@oss.qualcomm.com>
On 4/5/26 4:34 PM, Krzysztof Kozlowski wrote:
> DisplayPort block on Qualcomm SM8650 has few too short address space
> ranges and misses four more spaces. Complete the hardware description,
> which in the future might be important for full feature support.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH RFC v2 2/6] drm/msm/adreno: rename llc_mmio to cx_misc_mmio
From: Konrad Dybcio @ 2026-04-07 9:45 UTC (permalink / raw)
To: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Akhil P Oommen, Bjorn Andersson
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel
In-Reply-To: <20260402-adreno-810-v2-2-ce337ca87a9e@pm.me>
On 4/3/26 1:09 AM, Alexander Koskovich wrote:
> This region is used for more than just LLCC, it also provides access to
> software fuse values (raytracing, etc).
>
> Rename relevant symbols from _llc to _cx_misc for use in a follow up
> change that decouples this from LLCC.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 01/19] dt-bindings: display/panel: himax,hx83102: describe Waveshare panel
From: Krzysztof Kozlowski @ 2026-04-07 9:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
Liam Girdwood, Mark Brown, Bartosz Golaszewski, dri-devel,
devicetree, linux-kernel, linux-gpio
In-Reply-To: <CAD++jL=T9eOXujPSpTp_uNJ2rxN9P9Ybt28+H-YF_=3+_RXCkQ@mail.gmail.com>
On 07/04/2026 11:38, Linus Walleij wrote:
> On Thu, Apr 2, 2026 at 10:30 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Wed, Apr 01, 2026 at 10:26:20AM +0300, Dmitry Baryshkov wrote:
>
>>> + # Waveshare 12.3-DSI-TOUCH-A panel
>>> + - waveshare,12.3-dsi-touch-a
>>
>> I don't think we use '.' in compatibles, so waveshare,12-3-dsi-touch-a
>
> Qualcomm happen to use periods in similar cases for their
> "qualcomm universal peripheral":
> Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml
>
> I don't know if the policy changed since, but that's a big and widespread
> platform and I never saw it challenged so I think it's kind of established
> that we do.
That example is ancient, but you are right that this is widespread
pattern. I wonder why this 'dot' here felt odd - assumed that 'dot' in
version is something else than 'dot' in other place.. dunno, it's fine.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: imx8mp-ab2: Correct interrupt flags
From: Shengjiu Wang @ 2026-04-07 9:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Marek Vasut,
Peng Fan, Fedor Ross, Shawn Guo, Shengjiu Wang, Viorel Suman,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260406063810.25531-6-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, Apr 6, 2026 at 2:39 PM Krzysztof Kozlowski
<krzysztof.kozlowski@oss.qualcomm.com> wrote:
>
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted the
> same logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Fixes: bf68c18150ef ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Thanks for the fix.
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Best regards
Shengjiu Wang
> ---
> arch/arm64/boot/dts/freescale/imx8mp-ab2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts b/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
> index dbbc0df0e3d1..443e4fd5b9bf 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
> @@ -281,7 +281,7 @@ pca9450: pmic@25 {
> compatible = "nxp,pca9450c";
> reg = <0x25>;
> interrupt-parent = <&gpio1>;
> - interrupts = <3 GPIO_ACTIVE_LOW>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> pinctrl-0 = <&pinctrl_pmic>;
>
> regulators {
> --
> 2.51.0
>
>
^ permalink raw reply
* Re: [PATCH 01/19] dt-bindings: display/panel: himax,hx83102: describe Waveshare panel
From: Krzysztof Kozlowski @ 2026-04-07 9:50 UTC (permalink / raw)
To: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260401-waveshare-dsi-touch-v1-1-5e9119b5a014@oss.qualcomm.com>
On 01/04/2026 09:26, Dmitry Baryshkov wrote:
> Describe Waveshare 12.3-DSI-TOUCH-A panel which allegedly uses HX83102
> as a panel controller.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml | 2 ++
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 02/19] dt-bindings: display/panel: himax,hx8394: describe Waveshare panel
From: Krzysztof Kozlowski @ 2026-04-07 9:50 UTC (permalink / raw)
To: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260401-waveshare-dsi-touch-v1-2-5e9119b5a014@oss.qualcomm.com>
On 01/04/2026 09:26, Dmitry Baryshkov wrote:
> Describe Waveshare 5" and 5" DSI panels which use HX9365-E as a panel
> controller.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: qcom: add the TLMM driver for the Nord platforms
From: Linus Walleij @ 2026-04-07 9:54 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bartosz Golaszewski, Shawn Guo, Arnd Bergmann,
linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260403-nord-tlmm-v1-2-4864f400c700@oss.qualcomm.com>
Hi Bartosz,
thanks for your patch!
On Fri, Apr 3, 2026 at 3:28 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
> Add support for the TLMM controller on the Qualcomm Nord platform.
>
> Co-developed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
(...)
> +#define PINGROUP(id, f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11) \
> + { \
> + .grp = PINCTRL_PINGROUP("gpio" #id, \
> + gpio##id##_pins, \
> + ARRAY_SIZE(gpio##id##_pins)), \
> + .ctl_reg = REG_SIZE * id, \
> + .io_reg = 0x4 + REG_SIZE * id, \
> + .intr_cfg_reg = 0x8 + REG_SIZE * id, \
> + .intr_status_reg = 0xc + REG_SIZE * id, \
> + .intr_target_reg = 0x8 + REG_SIZE * id, \
You can drop .intr_target_reg as of:
commit 0720208b37ae4f1193dc7103ee269b180a8f8943
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Date: Fri Mar 27 22:42:40 2026 +0530
pinctrl: qcom: Drop redundant intr_target_reg on modern SoCs
On all Qualcomm TLMM generations from APQ8084 onwards, the interrupt
target routing bits are located in the same register as the interrupt
configuration bits (intr_cfg_reg). Only five older SoCs — APQ8064,
IPQ8064, MDM9615, MSM8660 and MSM8960 — have a genuinely separate
interrupt target routing register at a different offset (0x400 + 0x4 * id).
Replace MSM_ACCESSOR(intr_target) with a custom accessor that falls back
to intr_cfg_reg when intr_target_reg is zero. Apply the same fallback in
the SCM path. Drop the now-redundant .intr_target_reg initializer from
all SoC drivers where it duplicated intr_cfg_reg, keeping it only in
the five drivers where it genuinely differs.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Frank Li @ 2026-04-07 9:55 UTC (permalink / raw)
To: Liu Ying
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260407-tianma-tm050rdh03-imx93-9x9-qsb-v1-1-24d514a62fdc@nxp.com>
On Tue, Apr 07, 2026 at 05:15:31PM +0800, Liu Ying wrote:
> Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
>
> The panel connects with the QSB board through an adapter board[1]
> designed by NXP.
>
> Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 2 +
> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 +++++++++++++++++++++
> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-------------------
Can you add some description about raname in commit message?
Use -C option to create patch.
...
> diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
> new file mode 100644
> index 000000000000..c233797ec28c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2026 NXP
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
> +
> +&{/} {
> + panel {
> + compatible = "tianma,tm050rdh03";
> + enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
> + };
> +};
Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
to imx93-9x9-qsb.dtb, so needn't create dtsi.
Frank
>
> ---
> base-commit: 816f193dd0d95246f208590924dd962b192def78
> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
>
> Best regards,
> --
> Liu Ying <victor.liu@nxp.com>
>
^ permalink raw reply
* Re: [PATCH v4 0/2] Introduce TLMM driver for Qualcomm IPQ5210 SoC
From: Linus Walleij @ 2026-04-07 9:57 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-gpio, devicetree, linux-kernel,
Krzysztof Kozlowski, Konrad Dybcio
In-Reply-To: <5c0a53c5-3750-4b80-b3b0-0bc7595454d9@oss.qualcomm.com>
On Mon, Apr 6, 2026 at 11:05 AM Kathiravan Thirumoorthy
<kathiravan.thirumoorthy@oss.qualcomm.com> wrote:
> On 3/30/2026 2:11 PM, Linus Walleij wrote:
> > On Mon, Mar 30, 2026 at 6:51 AM Kathiravan Thirumoorthy
> > <kathiravan.thirumoorthy@oss.qualcomm.com> wrote:
> >
> >> The IPQ5210 is Qualcomm's SoC for Routers, Gateways and Access Points.
> >> Add the pinctrl support for the same.
> >>
> >> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> > Patches applied!
>
> Linus, I don't see these patches in linux-next or in linux-pinctrl tree.
> Do I miss something here?
I guess easter happened before I pushed by tree :(
Sorry my fault. Pushing the tree before leaving my keyboard
today.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 2/2] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Linus Walleij @ 2026-04-07 9:59 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Liam Girdwood,
Mark Brown, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260406075114.25672-3-clamor95@gmail.com>
On Mon, Apr 6, 2026 at 9:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
LGTM but waiting for DT maintainers to look at it before merging.
Can I merge this one patch separately to the pinctrl tree?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH RFC 0/2] arm64: dts: qcom: qcs6490: Introduce Radxa Dragon Q6A
From: Andriy Sharandakov @ 2026-04-07 10:16 UTC (permalink / raw)
To: Konrad Dybcio, Xilin Wu, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong,
Viken Dadhaniya, Ram Kumar Dwivedi
In-Reply-To: <cc8ba407-1d44-419d-9171-b6911f673772@oss.qualcomm.com>
On 12.09.2025 11:15, Konrad Dybcio wrote:
> On 9/12/25 11:04 AM, Xilin Wu wrote:
>> On 2025/9/12 16:56:04, Konrad Dybcio wrote:
>>> On 9/12/25 10:03 AM, Xilin Wu wrote:
>>>> Radxa Dragon Q6A (https://docs.radxa.com/en/dragon/q6a) is a single board
>>>> computer, based on the Qualcomm QCS6490 platform.
>>>>
>>>> The board ships with a modified version of the Qualcomm Linux boot
>>>> firmware, which is stored on the onboard SPI NOR flash. This allows
>>>> booting standard EFI-based bootloaders from SD/eMMC/USB/UFS/NVMe. It
>>>> supports replaceable UFS 3.1/eMMC modules for easy user upgrades.
>>>>
>>>> The board schematic is available at [1].
>>>>
>>>> Features enabled and working:
>>>>
>>>> - USB-A 3.0 port (depends on [2])
>>>> - Three USB-A 2.0 ports
>>>> - RTL8111K Ethernet connected to PCIe0
>>>> - UFS 3.1 module (depends on [3])
>>>> - eMMC module
>>>> - SD card
>>>> - M.2 M-Key 2230 PCIe 3.0 x2
>>>> - HDMI 2.0 port including audio (depends on [2])
>>>> - Configurable I2C/SPI/UART from 40-Pin GPIO (depends on [4])
>>>> - Headphone jack
>>>> - Onboard thermal sensors
>>>> - QSPI controller for updating boot firmware
>>>> - ADSP remoteproc (Type-C and charging features disabled in firmware)
>>>> - CDSP remoteproc (for AI applications using QNN)
>>>> - Venus video encode and decode accelerator
>>>
>>> You have a number of features that depend on several other series, and
>>> as Krzysztof pointed out this is difficult to merge/review.. Could you
>>> please create a "linux-next/master-ready" version of this series and
>>> separate the changes for which the dependencies are unmet, putting them
>>> at the end? This way we can take at least some of your diff.
>>>
>>> If you still want review on them, you can also send them as [PATCH DNM]
>>> or so
>>>
>>> Konrad
>>>
>>
>> Thanks for the suggestion. I think I can separate the changes that have unmet dependencies, and mark them as DNM. Can I send the new series now, or am I supposed to wait for a few days?
>
> Since we can't do much with this one, please apply Krzysztof's review
> comments and tags and feel free to resend
>
> Konrad
Xilin,
The prerequisite for the "USB-A 3.0 port (depends on [2])" feature has
been added -
https://github.com/torvalds/linux/commit/f842daf740114a8783be566219db34c6a0f1d02c
Could you please check and resend the USB 3.0 port feature?
Thanks.
Best regards,
Andriy
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: milos: Add IMEM node
From: Konrad Dybcio @ 2026-04-07 10:21 UTC (permalink / raw)
To: Luca Weiss, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260403-milos-imem-v1-2-4244ebb47017@fairphone.com>
On 4/3/26 5:00 PM, Luca Weiss wrote:
> Add a node for the IMEM found on Milos, which contains pil-reloc-info
> and the modem tables for IPA, among others.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> arch/arm64/boot/dts/qcom/milos.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> index 4a64a98a434b..1c045743ef77 100644
> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> @@ -2289,6 +2289,25 @@ scl-pins {
> };
> };
>
> + sram@14680000 {
> + compatible = "qcom,milos-imem", "syscon", "simple-mfd";
With the new compatible:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v7 00/15] arm64: dts: qcom: sdm845-lg: Improve hardware support in devicetree
From: Konrad Dybcio @ 2026-04-07 10:22 UTC (permalink / raw)
To: Paul Sajna, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Dmitry Baryshkov, Pavel Machek
In-Reply-To: <f63f25751b5db2ee5420ec4c12e36271ca22a864@postmarketos.org>
On 4/6/26 5:30 PM, Paul Sajna wrote:
> April 5, 2026 at 7:40 PM, "Bjorn Andersson" <andersson@kernel.org mailto:andersson@kernel.org?to=%22Bjorn%20Andersson%22%20%3Candersson%40kernel.org%3E > wrote:
>
>> Applied, thanks!
>>
>> [01/15] arm64: dts: qcom: sdm845-lg-common: Sort nodes and properties
>> commit: 6a9e8df732014c1c758bd3cd6254b5b4cb273c7f
>> [02/15] arm64: dts: qcom: sdm845-lg-judyln: Add firmware nodes, change path
>> commit: b9afe8581c0e14b7b56e2314dc7f9597bf23ef67
>> [03/15] arm64: dts: qcom: sdm845-lg-judyp: Define firmware paths for judyp
>> commit: 8f4c53ae286bd6a113245ad53ce957e623374cf0
>> [04/15] arm64: dts: qcom: sdm845-lg-common: Enable venus
>> commit: e9f611de7ab51540c0cf246df6b7d4d99f4cec64
>> [05/15] arm64: dts: qcom: sdm845-lg-common: Enable qups and their dma controllers
>> commit: 4ec3045c969a326c458c53ca65bde5749e575d52
>> [06/15] arm64: dts: qcom: sdm845-lg: Add uarts and Bluetooth
>> commit: e746ed5af3084e9534135679c55e69eced0c657f
>> [07/15] arm64: dts: qcom: sdm845-lg-judyln: Add battery and charger
>> commit: 995c258982429db93db103fc26fcb3a0acd6a5ee
>> [08/15] arm64: dts: qcom: sdm845-lg-common: Add LEDs
>> commit: b49722c8a18cdd11f49357f3b8be23549f76a506
>> [09/15] arm64: dts: qcom: sdm845-lg-judyln: Add lab/ibb
>> commit: 2e7cdd400b6a4e67c27fc3e839342824b51d01ff
>> [10/15] arm64: dts: qcom: sdm845-lg-judyln: Add display panel
>> commit: c6c66aa3ef33dc3076c6dac64003b29bd9515b58
>> [11/15] arm64: dts: qcom: sdm845-lg: Add wifi nodes
>> commit: eb8fa32085261a07d763e9d616b3c206d0be82ff
>> [12/15] arm64: dts: qcom: sdm845-lg-common: Add chassis-type
>> commit: a5a5ad9848980e1019ca841fe057afb83debecfa
>>
>> Best regards,
>> --
>> Bjorn Andersson <andersson@kernel.org>
>>
>
> Please apply 13-15. 15 is the only change in v8, so what you've pulled here from v7 is fine.
Please send incremental changes on top of -next if you feel they're
valuable
Konrad
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: sdm845-oneplus: Enable known blocks and add placeholders
From: Konrad Dybcio @ 2026-04-07 10:24 UTC (permalink / raw)
To: david, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel
In-Reply-To: <20260406-placeholders-v2-1-9cdbe1fc9666@ixit.cz>
On 4/6/26 10:18 PM, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> We know these devices are present; most of them are supported by
> downstream and are close to the mainline kernels.
>
> This adds placeholders for:
> - front camera (imx371)
> - rear cameras (imx519, imx376k)
> - actuators
>
> This is very handy when rebasing the integration tree with
> support for multiple different blocks at the same time.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
I assume the preset 100 kHz freq is fine
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: ashish yadav @ 2026-04-07 10:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260407-monumental-mastiff-of-sunshine-fb27ab@quoll>
Hi Krzysztof,
Thanks for your time and valuable feedback.
ACK.
I will make commit information simple in the next version of patch.
Please let me know in case any more steps are required for vdd-vin-supply.
I will take care of the same in the next version of patch.
With Best Regards,
Ashish Yadav
On Tue, Apr 7, 2026 at 12:30 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Mon, Apr 06, 2026 at 03:46:46PM +0530, ASHISH YADAV wrote:
> > From: Ashish Yadav <ashish.yadav@infineon.com>
> >
> > Add documentation for the device tree binding of the XDP720 eFuse.
> > This patch introduces a YAML schema describing the required and optional
>
> Redundant parts was supposed to go to /dev/null.
>
> You already said this in the first sentence.
>
> Also, there is no such thing as YAML schema.
>
>
> > properties for the XDP720 eFuse device node. It includes details on the
> > compatible string, register mapping,supply and rimon-micro-ohms(RIMON).
>
> So nothing here is useful - nothing explains the hardware, so drop all
> this and keep only first sentence. Or say something useful about
> hardware.
>
> >
> > Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
> > ---
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 1/4] ARM: dts: qcom: msm8974pro-htc-m8: add status LEDs
From: Konrad Dybcio @ 2026-04-07 10:27 UTC (permalink / raw)
To: alex, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Luca Weiss, linux-arm-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, devicetree, linux-kernel,
Lee Jones, Pavel Machek, linux-leds
In-Reply-To: <20260406-m8-dts-additions-v2-1-c4c4bd50af48@me.ssier.org>
On 4/6/26 7:16 AM, Alexandre Messier via B4 Relay wrote:
> From: Alexandre Messier <alex@me.ssier.org>
>
> Add support for the notification LEDs on the HTC One M8.
>
> Two LEDs are available, one orange and one green. Together,
> they both form a single notification source, so use a
> multicolor LED node to describe this arrangement.
>
> Cc: Lee Jones <lee@kernel.org>
> Cc: Pavel Machek <pavel@kernel.org>
> Cc: linux-leds@vger.kernel.org
> Signed-off-by: Alexandre Messier <alex@me.ssier.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/4] ARM: dts: qcom: msm8974pro-htc-m8: add NFC support
From: Konrad Dybcio @ 2026-04-07 10:27 UTC (permalink / raw)
To: alex, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Luca Weiss, linux-arm-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, devicetree, linux-kernel
In-Reply-To: <20260406-m8-dts-additions-v2-2-c4c4bd50af48@me.ssier.org>
On 4/6/26 7:16 AM, Alexandre Messier via B4 Relay wrote:
> From: Alexandre Messier <alex@me.ssier.org>
>
> Add the NFC chip used in the HTC One M8 to its device tree.
>
> The downstream vendor kernel used an I2C frequency of 384 kHz
> for this bus. Use the same value as the vendor.
>
> Signed-off-by: Alexandre Messier <alex@me.ssier.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 4/4] ARM: dts: qcom: msm8974pro-htc-m8: add touchscreen
From: Konrad Dybcio @ 2026-04-07 10:28 UTC (permalink / raw)
To: alex, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Luca Weiss, linux-arm-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, devicetree, linux-kernel
In-Reply-To: <20260406-m8-dts-additions-v2-4-c4c4bd50af48@me.ssier.org>
On 4/6/26 7:17 AM, Alexandre Messier via B4 Relay wrote:
> From: Alexandre Messier <alex@me.ssier.org>
>
> Add the touchscreen device node for the HTC One (M8).
>
> The downstream vendor kernel used an I2C frequency of 384 kHz
> for this bus. Use the same value as the vendor.
>
> Signed-off-by: Alexandre Messier <alex@me.ssier.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: qcom: milos: Add IPA node
From: Konrad Dybcio @ 2026-04-07 10:30 UTC (permalink / raw)
To: Luca Weiss, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-5-01e9e4e03d3e@fairphone.com>
On 4/3/26 6:43 PM, Luca Weiss wrote:
> Add the description of the IPA block in the Milos SoC.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
> + iommus = <&apps_smmu 0x4a0 0x0>,
> + <&apps_smmu 0x4a2 0x0>;
P.S.
I don't know what's the scope of upstream IPA today, but it seems like
there's two additional SIDs: 0x4a1 attached to an "ipa_smmu_wlan"
subnode and another one (0x4a4) called ipa_smmu_11ad, perhaps for
some tighter integration with ath1xk_ahb?
But again, I don't know much.
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/2] hwmon:(pmbus/xdp720) Add support for efuse xdp720
From: ashish yadav @ 2026-04-07 10:30 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260406101647.109667-3-Ashish.Yadav@infineon.com>
Hi Guenter,
In this patch, info about vdd-vin-supply is added through
devm_regulator_get_enable().
https://lore.kernel.org/all/20260406101647.109667-2-Ashish.Yadav@infineon.com/
Thanks & Regards
Ashish Yadav
On Mon, Apr 6, 2026 at 3:47 PM ASHISH YADAV <ashishyadav78@gmail.com> wrote:
>
> From: Ashish Yadav <ashish.yadav@infineon.com>
>
> Add the pmbus driver for Infineon XDP720 Digital eFuse Controller.
>
> Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
> ---
> XDP720 Digital eFuse Controller provides accurate system telemetry
> (V, I, P, T) and reports analog current at the IMON pin for post-processing.
>
> The Current and Power measurement depends on the RIMON and GIMON values.
> Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
> https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
>
> The GIMON (microA/A) depends on the 10th bit of TELEMETRY_AVG PMBUS Register.
> The value of RIMON (kohm) can be provided by the user through device tree using
> infineon,rimon-micro-ohms property.
> ---
> drivers/hwmon/pmbus/Kconfig | 9 +++
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/xdp720.c | 128 +++++++++++++++++++++++++++++++++++
> 3 files changed, 138 insertions(+)
> create mode 100644 drivers/hwmon/pmbus/xdp720.c
>
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index fc1273abe357..c419e3ecce90 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -702,6 +702,15 @@ config SENSORS_XDP710
> This driver can also be built as a module. If so, the module will
> be called xdp710.
>
> +config SENSORS_XDP720
> + tristate "Infineon XDP720 family"
> + help
> + If you say yes here you get hardware monitoring support for Infineon
> + XDP720.
> +
> + This driver can also be built as a module. If so, the module will
> + be called xdp720.
> +
> config SENSORS_XDPE152
> tristate "Infineon XDPE152 family"
> help
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index d6c86924f887..1cac7ccae79f 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -68,6 +68,7 @@ obj-$(CONFIG_SENSORS_TPS546D24) += tps546d24.o
> obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
> obj-$(CONFIG_SENSORS_UCD9200) += ucd9200.o
> obj-$(CONFIG_SENSORS_XDP710) += xdp710.o
> +obj-$(CONFIG_SENSORS_XDP720) += xdp720.o
> obj-$(CONFIG_SENSORS_XDPE122) += xdpe12284.o
> obj-$(CONFIG_SENSORS_XDPE152) += xdpe152c4.o
> obj-$(CONFIG_SENSORS_ZL6100) += zl6100.o
> diff --git a/drivers/hwmon/pmbus/xdp720.c b/drivers/hwmon/pmbus/xdp720.c
> new file mode 100644
> index 000000000000..8729a771f216
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/xdp720.c
> @@ -0,0 +1,128 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Hardware monitoring driver for Infineon XDP720 Digital eFuse Controller
> + *
> + * Copyright (c) 2026 Infineon Technologies. All rights reserved.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/of_device.h>
> +#include <linux/bitops.h>
> +#include <linux/math64.h>
> +#include "pmbus.h"
> +
> +/*
> + * The IMON resistor required to generate the system overcurrent protection.
> + * Arbitrary default Rimon value: 2k Ohm
> + */
> +#define XDP720_DEFAULT_RIMON 2000000000 /* 2k ohm */
> +#define XDP720_TELEMETRY_AVG 0xE9
> +
> +static struct pmbus_driver_info xdp720_info = {
> + .pages = 1,
> + .format[PSC_VOLTAGE_IN] = direct,
> + .format[PSC_VOLTAGE_OUT] = direct,
> + .format[PSC_CURRENT_OUT] = direct,
> + .format[PSC_POWER] = direct,
> + .format[PSC_TEMPERATURE] = direct,
> +
> + .m[PSC_VOLTAGE_IN] = 4653,
> + .b[PSC_VOLTAGE_IN] = 0,
> + .R[PSC_VOLTAGE_IN] = -2,
> + .m[PSC_VOLTAGE_OUT] = 4653,
> + .b[PSC_VOLTAGE_OUT] = 0,
> + .R[PSC_VOLTAGE_OUT] = -2,
> + /*
> + * Current and Power measurement depends on the RIMON (kOhm) and
> + * GIMON(microA/A) values.
> + */
> + .m[PSC_CURRENT_OUT] = 24668,
> + .b[PSC_CURRENT_OUT] = 0,
> + .R[PSC_CURRENT_OUT] = -4,
> + .m[PSC_POWER] = 4486,
> + .b[PSC_POWER] = 0,
> + .R[PSC_POWER] = -1,
> + .m[PSC_TEMPERATURE] = 54,
> + .b[PSC_TEMPERATURE] = 22521,
> + .R[PSC_TEMPERATURE] = -1,
> +
> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT | PMBUS_HAVE_PIN |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_INPUT |
> + PMBUS_HAVE_STATUS_TEMP,
> +};
> +
> +static int xdp720_probe(struct i2c_client *client)
> +{
> + struct pmbus_driver_info *info;
> + int ret;
> + u32 rimon;
> + int gimon;
> +
> + info = devm_kmemdup(&client->dev, &xdp720_info, sizeof(*info),
> + GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> +
> + ret = devm_regulator_get_enable(&client->dev, "vdd-vin");
> + if (ret)
> + return dev_err_probe(&client->dev, ret,
> + "failed to enable vdd-vin supply\n");
> +
> + ret = i2c_smbus_read_word_data(client, XDP720_TELEMETRY_AVG);
> + if (ret < 0) {
> + dev_err(&client->dev, "Can't get TELEMETRY_AVG\n");
> + return ret;
> + }
> +
> + ret >>= 10; /* 10th bit of TELEMETRY_AVG REG for GIMON Value */
> + ret &= GENMASK(0, 0);
> + if (ret == 1)
> + gimon = 18200; /* output gain 18.2 microA/A */
> + else
> + gimon = 9100; /* output gain 9.1 microA/A */
> +
> + if (of_property_read_u32(client->dev.of_node,
> + "infineon,rimon-micro-ohms", &rimon))
> + rimon = XDP720_DEFAULT_RIMON; /* Default if not set via DT */
> + if (rimon == 0)
> + return -EINVAL;
> +
> + /* Adapt the current and power scale for each instance */
> + info->m[PSC_CURRENT_OUT] = DIV64_U64_ROUND_CLOSEST((u64)
> + info->m[PSC_CURRENT_OUT] * rimon * gimon, 1000000000000ULL);
> + info->m[PSC_POWER] = DIV64_U64_ROUND_CLOSEST((u64)
> + info->m[PSC_POWER] * rimon * gimon, 1000000000000000ULL);
> +
> + return pmbus_do_probe(client, info);
> +}
> +
> +static const struct of_device_id xdp720_of_match[] = {
> + { .compatible = "infineon,xdp720" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, xdp720_of_match);
> +
> +static const struct i2c_device_id xdp720_id[] = {
> + { "xdp720" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, xdp720_id);
> +
> +static struct i2c_driver xdp720_driver = {
> + .driver = {
> + .name = "xdp720",
> + .of_match_table = xdp720_of_match,
> + },
> + .probe = xdp720_probe,
> + .id_table = xdp720_id,
> +};
> +
> +module_i2c_driver(xdp720_driver);
> +
> +MODULE_AUTHOR("Ashish Yadav <ashish.yadav@infineon.com>");
> +MODULE_DESCRIPTION("PMBus driver for Infineon XDP720 Digital eFuse Controller");
> +MODULE_LICENSE("GPL");
> +MODULE_IMPORT_NS("PMBUS");
> --
> 2.39.5
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: Add Motorola Edge 30 (dubai) DTS
From: Konrad Dybcio @ 2026-04-07 10:38 UTC (permalink / raw)
To: Val Packett, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kees Cook, Tony Luck,
Guilherme G. Piccoli
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260403054417.167917-2-val@packett.cool>
On 4/3/26 7:33 AM, Val Packett wrote:
> The Motorola Edge 30 is a smartphone released in 2022.
>
> This commit has the following features working:
> - Display (simplefb)
> - Touchscreen
> - Power and volume buttons
> - Storage (UFS 3.1)
> - Battery (ADSP battmgr)
> - USB (Type-C, 2.0, dual-role)
> - Wi-Fi and Bluetooth (WCN6750 hw1.0)
>
> Signed-off-by: Val Packett <val@packett.cool>
> ---
> v2: Apply suggestions from Konrad
"fix bug" :P
> v1: https://lore.kernel.org/all/20260329103055.96649-2-val@packett.cool/
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox