On Thu, 14 Jul 2022 at 23:57, Stephan Gerhold <[email protected]> wrote: > > On Thu, Jul 14, 2022 at 01:10:45PM +0530, Sumit Garg wrote: > > On Thu, 14 Jul 2022 at 01:02, Stephan Gerhold <[email protected]> wrote: > > > Can you check how hard it would be to reuse the upstream QCS404 DT? > > > > > > > It turned out to be patch [1] on top of this patch-set. Please help me > > to test it on boards you have access to. > > > > [1] > > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ > > > > Thanks! Do you happen to have time to check the other custom bindings in > SDM845 as well? I see two other differences there in addition to the > pinctrl: > > 1. "qcom,msm-geni-uart": Linux has an additional "qcom,geni-se-qup" > node around that. >
Yeah that is for a wrapper serial engine driver around UART, SPI, I2C, I3C, etc. Text from "drivers/soc/qcom/qcom-geni-se.c": /** * DOC: Software description * * GENI SE Wrapper driver is structured into 2 parts: * * geni_wrapper represents QUP Wrapper controller. This part of the driver * manages QUP Wrapper information such as hardware version, clock * performance table that is common to all the internal serial engines. * * geni_se represents serial engine. This part of the driver manages serial * engine information such as clocks, containing QUP Wrapper, etc. This part * of driver also supports operations (eg. initialize the concerned serial * engine, select between FIFO and DMA mode of operation etc.) that are * common to all the serial engines and are independent of serial interfaces. */ I am unsure if there really exists a use-case for that in u-boot but I guess we should be able to add a dummy driver just to satisfy the upstream Linux kernel DT binding. > 2. The "qcom,pm8998-pwrkey" should be in an additional > "qcom,pm8998-pon" container node and then called > "qcom,pm8941-pwrkey". > > Also, in U-Boot the keys are modelled as GPIOs which is a bit > strange (I don't think they can be set to output mode for example). > But it might be fine to keep that in the -u-boot.dtsi part for now. > Okay, I will try to look at these as follow up patches. > I would be happy to investigate and test the remaining DB410c-specific > parts (e.g. USB there). Cleaning up the DT differences has been on my > TODO list for quite some time but I never got to it, sadly... > No worries, it's a community effort which often takes a backseat on the TODO list. -Sumit > Thanks! > Stephan
