Message-ID: <7bf536a5-30c1-43d8-9ea3-3aaea65c6b0a@collabora.com>
Date: Thu, 5 Dec 2024 13:27:01 +0100
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Val Packett <val@...kett.cool>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Matthias Brugger
 <matthias.bgg@...il.com>, Fabien Parent <fparent@...libre.com>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 0/5] MT8516/MT8167 dtsi fixes

Il 04/12/24 20:05, Val Packett ha scritto:
> Hi everyone,
> 
> I've been working on mainline bringup on an MT8167 tablet I found at a
> junkyard sale (lenovo,tb7304f) for postmarketOS :3
> 
> This first series consists of basic device tree fixes for the MT8516
> dtsi that the MT8167 one inherits from.
> 

...Yes, but I don't see any patch that is introducing your TB7304F device here.

I strongly suggest you to also send one that achieves basic boot with UART console
as a first step for upstreaming your board, and then go for incremental changes
everytime you get a new feature working.

> The changes that follow add support for the MT6392 PMIC, and that's
> mostly been implemented by Fabien Parent back in 2020 and not merged:
> 
> <https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201027181157.862927-3-fparent@baylibre.com/>
> <https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201024200304.1427864-2-fparent@baylibre.com/>
> 
> but I have a couple changes on top of those patches (like adding the
> missing mt6392_set_buck_vosel_reg). I'm wondering what the best way to
> get this in would be, should I squash my changes and submit the "final"
> patches with a Co-developed-by tag?
> 

Generally, if the patches are only simple additions, you could send the original
patches without any author variation (and fixing that MT6392_IRQ_numbers enum
in the original ones because lower case please!) and then your patches on top
with your additions.

Otherwise, if you're "changing a lot of stuff" it makes sense to grab authorship
and add the Co-Developed-by... but I don't think you're changing much, honestly.

Of course, you'll have to drop the TXT additions, as now they are YAML (where the
YAML additions go to a separated dt-bindings patch!).

In the end, it's your choice - that's more or less a gist of how to do it.

> (Similar situation with DRM nodes, not merged due to "concerns about
> the driver architecture" in 2021, now missing GCE/CMDQ mailbox props:
> <https://lore.kernel.org/df4c57f9-115b-c4da-e656-e4bdec62c2d7@gmail.com/>)
> 

The upstream driver just gained support for configuring the display paths
entirely in the devicetree as those are obviously device specific.

You can make use of that for upstreaming your tablet after adding the display
nodes (and bindings, if required) as if you go for the default configuration
that's probably not going to work because it's for the pumpkin boards which
will most probably have a different display pipeline compared to your board.

> By the way, is anyone familiar with PSCI cpuidle/hot-unplug issues on
> Mediatek Android devices from around this time? Specifically on this
> tablet, I can't make the cores come back from suspend. I have
> investigated local-timer-stop and arm,no-tick-in-suspend, Fabien pointed
> me to the mediatek timer and its required clocks, but nothing helped.
> Trying the psci_checker, I realized that it's not just suspend: they
> do not come back from hot-unplug either. Initial CPU_ON on boot is fine,
> but then after a CPU_OFF they do not actually come back when CPU_ON
> supposedly turns them on. Now I can't help but notice that the only DTS
> in mainline for a device that came with Android, mt6795-sony-xperia-m5,
> does not have any cpuidle nodes in its SoC's dtsi either..
> 

I did have some issues with an older bootloader on the Xperia M5 smartphone
and would even lock up at boot, because on the old firmwares the power
domains for the CPUs are not managed automatically by FW.

Before discovering that there was new FW (and this stuff is signed so you
cannot cross-flash...) I did engineer a solution, but never upstreamed it
because I did effectively lack time to clean it up and make it proper.

This solution is not upstreamable, as it makes the mtk-pm-domains driver
to be usable only as built-in and not as module anymore... so that would
probably need a separated driver or something like that.

Here's the (rather dirty, but working) code: 
https://gitlab.collabora.com/google/chromeos-kernel/-/commit/ae8f7048aadac03037391a64d9d79ca5af7b7a77

Cheers!
Angelo

> Val Packett (5):
>    arm64: dts: mediatek: mt8516: fix GICv2 range
>    arm64: dts: mediatek: mt8516: fix wdt irq type
>    arm64: dts: mediatek: mt8516: add i2c clock-div property
>    arm64: dts: mediatek: mt8516: reserve 192 KiB for TF-A
>    arm64: dts: mediatek: mt8516: add keypad node
> 
>   arch/arm64/boot/dts/mediatek/mt8516.dtsi      | 21 +++++++++++++++----
>   .../boot/dts/mediatek/pumpkin-common.dtsi     |  2 --
>   2 files changed, 17 insertions(+), 6 deletions(-)
> 

Powered by blists - more mailing lists