On Thu, Dec 5 2024 at 01:27:01 PM +01:00:00, AngeloGioacchino Del Regno
<angelogioacchino.delregno@xxxxxxxxxxxxx> wrote:
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.
Wanted to get the PMIC in first but sure, could try splitting out the
initial version without the PMIC.
Oh! One dts/dtsi question: pretty much all MTK devices so far have all
pinctrl configurations defined per-device. But on this SoC, pin
assignments have their "canonical" function in the pin name e.g.:
MT8167_PIN_58_SDA0__FUNC_SDA0_0 and on this device they are used as-is.
Would it be fine to place these default pinctrl configs for SD/MMC, I2C
etc. in the SoC dtsi?
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.
Right, I was mostly unsure if the email workflow supported just sending
someone else's patches, but I guess that was silly - of course
git-send-email should do the right thing!
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.
The pipeline seems to be the same.. The pumpkin board was brought up
with DSI as well, the main pipeline I can find in the Android source is
the same (+ PWM).
I am still struggling to get it to work though: DSI command mode
configuration gets acknowledged fine, but in burst mode, the vblank
never arrives. Tried fiddling with various things (CMDQ or not, mutex
as vblank source since there was an Android commit doing that, etc.),
nothing helped.
By the way, is anyone familiar with PSCI cpuidle/hot-unplug issues on
Mediatek Android devices from around this time? [..]
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.
Interesting, thanks for the pointer!
In the Android kernel sources I could find though, there are no CPU
domains in the mtk-scpsys-mt8167 driver, and the only references I
could even find to the related register bits are from code that *reads*
the status of the CPU power domains to make decisions about sleep
states (only_one_cpu_online in mtk_idle). Trying to add those to the
driver anyway, did not succeed so far.
~val
