mbox series

[v2,0/6] support oneplus-lemonade(p) devices

Message ID 20231018-nia-sm8350-for-upstream-v2-0-7b243126cb77@igalia.com
Headers show
Series support oneplus-lemonade(p) devices | expand

Message

Nia Espera Oct. 18, 2023, 2:25 p.m. UTC
Patch series adding support for oneplus-lemonade and oneplus-lemonadep
devices (OnePlus 9 & 9 Pro), along with a few needed fixups. Currently
working as of this series:

- USB OTG
- UFS
- Framebuffer display
- Touchscreen (for lemonade)
- Power & volume down keys
- Battery reading
- Modem, IPA, and remoteproc bringup

Signed-off-by: Nia Espera <nespera@igalia.com>
---
Changes in v2:
- Fixed up formatting/style.
- Removed unused pinctrl nodes.
- Removed unused properties.
- Moved ADC7 defines to vadc header.
- Edited copyright on lemonade dts and license on spmi header.
- Fixed up therm channels.
- Removed unnecessary hack w.r.t. timer node.
- Link to v1: https://lore.kernel.org/r/20231016-nia-sm8350-for-upstream-v1-0-bb557a0af2e9@igalia.com

---
Nia Espera (6):
      iio: adc: add smb139x bindings
      arm64: dts: qcom: sm8350: Fix DMA0 address
      arm64: dts: qcom: pm8350k: remove hanging whitespace
      arm64: dts: qcom: sm8350: Fix remoteproc interrupt type
      dt-bindings: arm: qcom: add oneplus-lemonade(p) bindings
      arm64: dts: qcom: sm8350-lemonade(p): new devices

 Documentation/devicetree/bindings/arm/qcom.yaml    |    2 +
 arch/arm64/boot/dts/qcom/Makefile                  |    2 +
 arch/arm64/boot/dts/qcom/pmk8350.dtsi              |    2 +-
 .../arm64/boot/dts/qcom/sm8350-oneplus-common.dtsi | 1042 ++++++++++++++++++++
 .../boot/dts/qcom/sm8350-oneplus-lemonade.dts      |   85 ++
 .../boot/dts/qcom/sm8350-oneplus-lemonadep.dts     |   20 +
 arch/arm64/boot/dts/qcom/sm8350.dtsi               |   12 +-
 include/dt-bindings/iio/qcom,spmi-adc7-smb139x.h   |   19 +
 include/dt-bindings/iio/qcom,spmi-vadc.h           |    3 +
 9 files changed, 1180 insertions(+), 7 deletions(-)
---
base-commit: 58720809f52779dc0f08e53e54b014209d13eebb
change-id: 20231016-nia-sm8350-for-upstream-2f452366e421

Best regards,

Comments

Krzysztof Kozlowski Oct. 18, 2023, 2:30 p.m. UTC | #1
On 18/10/2023 16:25, Nia Espera wrote:
> Bindings for a charger controller chip found on sm8350
> 
> Signed-off-by: Nia Espera <nespera@igalia.com>

Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.

Best regards,
Krzysztof
Konrad Dybcio Oct. 18, 2023, 8:17 p.m. UTC | #2
On 10/18/23 16:25, Nia Espera wrote:
> In a similar vein to
> https://lore.kernel.org/lkml/20220530080842.37024-3-manivannan.sadhasivam@linaro.org/,
> the remote processors on sm8350 fail to initialize with the 'correct'
> (i.e., specified in downstream) IRQ type. Change this to EDGE_RISING.
> 
> Signed-off-by: Nia Espera <nespera@igalia.com>
> ---
Hm, apparently 8250 and 7180 have the same thing.

Mani, could you elaborate on this?

Konrad
Luca Weiss Oct. 18, 2023, 8:21 p.m. UTC | #3
On Mittwoch, 18. Oktober 2023 22:17:15 CEST Konrad Dybcio wrote:
> On 10/18/23 16:25, Nia Espera wrote:
> > In a similar vein to
> > https://lore.kernel.org/lkml/20220530080842.37024-3-manivannan.sadhasivam@
> > linaro.org/, the remote processors on sm8350 fail to initialize with the
> > 'correct' (i.e., specified in downstream) IRQ type. Change this to
> > EDGE_RISING.
> > 
> > Signed-off-by: Nia Espera <nespera@igalia.com>
> > ---
> 
> Hm, apparently 8250 and 7180 have the same thing.
> 
> Mani, could you elaborate on this?
> 
> Konrad

I'm also carrying something like this for my sm6350 and sc7280 trees.

I tried getting some clarification in the lkml thread linked above about what 
should be done but never got a response.

Regards
Luca
Manivannan Sadhasivam Oct. 19, 2023, 4:06 a.m. UTC | #4
On Wed, Oct 18, 2023 at 10:17:15PM +0200, Konrad Dybcio wrote:
> 
> 
> On 10/18/23 16:25, Nia Espera wrote:
> > In a similar vein to
> > https://lore.kernel.org/lkml/20220530080842.37024-3-manivannan.sadhasivam@linaro.org/,
> > the remote processors on sm8350 fail to initialize with the 'correct'
> > (i.e., specified in downstream) IRQ type. Change this to EDGE_RISING.
> > 
> > Signed-off-by: Nia Espera <nespera@igalia.com>
> > ---
> Hm, apparently 8250 and 7180 have the same thing.
> 
> Mani, could you elaborate on this?
> 

So the remoteproc driver expects the wdog interrupts to be edge triggered as the
rest of the interrupts, but DT specifies them as level triggered. This won't
cause any issue during the first instance of the probe as the driver requested
trigger will be given precedence. But if the probe defers for some reason and
during the next try, request_irq() will fail with error similar to below:

irq: type mismatch, failed to map hwirq-x for interrupt-controller@xxxxxx!

This error is often confusing and I tried to fix it. But Maz didn't agree with
me, so I just ended up fixing the DTs for some platform I have access to.

So ideally, DTs of all platforms should be fixed to pass correct trigger type.

- Mani

> Konrad
Konrad Dybcio Oct. 21, 2023, 5:44 p.m. UTC | #5
On 10/19/23 06:06, Manivannan Sadhasivam wrote:
> On Wed, Oct 18, 2023 at 10:17:15PM +0200, Konrad Dybcio wrote:
>>
>>
>> On 10/18/23 16:25, Nia Espera wrote:
>>> In a similar vein to
>>> https://lore.kernel.org/lkml/20220530080842.37024-3-manivannan.sadhasivam@linaro.org/,
>>> the remote processors on sm8350 fail to initialize with the 'correct'
>>> (i.e., specified in downstream) IRQ type. Change this to EDGE_RISING.
>>>
>>> Signed-off-by: Nia Espera <nespera@igalia.com>
>>> ---
>> Hm, apparently 8250 and 7180 have the same thing.
>>
>> Mani, could you elaborate on this?
>>
> 
> So the remoteproc driver expects the wdog interrupts to be edge triggered as the
> rest of the interrupts, but DT specifies them as level triggered. This won't
> cause any issue during the first instance of the probe as the driver requested
> trigger will be given precedence. But if the probe defers for some reason and
> during the next try, request_irq() will fail with error similar to below:
> 
> irq: type mismatch, failed to map hwirq-x for interrupt-controller@xxxxxx!
> 
> This error is often confusing and I tried to fix it. But Maz didn't agree with
> me, so I just ended up fixing the DTs for some platform I have access to.
> 
> So ideally, DTs of all platforms should be fixed to pass correct trigger type.
So, this should be edge for all platforms, correct?

Konrad
Luca Weiss Oct. 21, 2023, 7:34 p.m. UTC | #6
On Samstag, 21. Oktober 2023 19:44:20 CEST Konrad Dybcio wrote:
> On 10/19/23 06:06, Manivannan Sadhasivam wrote:
> > On Wed, Oct 18, 2023 at 10:17:15PM +0200, Konrad Dybcio wrote:
> >> On 10/18/23 16:25, Nia Espera wrote:
> >>> In a similar vein to
> >>> https://lore.kernel.org/lkml/20220530080842.37024-3-manivannan.sadhasiva
> >>> m@linaro.org/, the remote processors on sm8350 fail to initialize with
> >>> the 'correct' (i.e., specified in downstream) IRQ type. Change this to
> >>> EDGE_RISING.
> >>> 
> >>> Signed-off-by: Nia Espera <nespera@igalia.com>
> >>> ---
> >> 
> >> Hm, apparently 8250 and 7180 have the same thing.
> >> 
> >> Mani, could you elaborate on this?
> > 
> > So the remoteproc driver expects the wdog interrupts to be edge triggered
> > as the rest of the interrupts, but DT specifies them as level triggered.
> > This won't cause any issue during the first instance of the probe as the
> > driver requested trigger will be given precedence. But if the probe
> > defers for some reason and during the next try, request_irq() will fail
> > with error similar to below:
> > 
> > irq: type mismatch, failed to map hwirq-x for interrupt-controller@xxxxxx!
> > 
> > This error is often confusing and I tried to fix it. But Maz didn't agree
> > with me, so I just ended up fixing the DTs for some platform I have
> > access to.
> > 
> > So ideally, DTs of all platforms should be fixed to pass correct trigger
> > type.
> So, this should be edge for all platforms, correct?

I'd believe so, iirc when I looked at the driver it always requests that
interrupt type.

For reference, these are my patches:

sm6350:
https://github.com/z3ntu/linux/commit/0522b7a1b981d80884a785c7e654bb5094ea1bc2

sc7280:
https://github.com/z3ntu/linux/commit/ead1d7b8f5648535b857cfa9250aac2480f00ed3

> 
> Konrad
Konrad Dybcio Oct. 23, 2023, 1:59 p.m. UTC | #7
On 21.10.2023 21:34, Luca Weiss wrote:
> On Samstag, 21. Oktober 2023 19:44:20 CEST Konrad Dybcio wrote:
>> On 10/19/23 06:06, Manivannan Sadhasivam wrote:
>>> On Wed, Oct 18, 2023 at 10:17:15PM +0200, Konrad Dybcio wrote:
>>>> On 10/18/23 16:25, Nia Espera wrote:
>>>>> In a similar vein to
>>>>> https://lore.kernel.org/lkml/20220530080842.37024-3-manivannan.sadhasiva
>>>>> m@linaro.org/, the remote processors on sm8350 fail to initialize with
>>>>> the 'correct' (i.e., specified in downstream) IRQ type. Change this to
>>>>> EDGE_RISING.
>>>>>
>>>>> Signed-off-by: Nia Espera <nespera@igalia.com>
>>>>> ---
>>>>
>>>> Hm, apparently 8250 and 7180 have the same thing.
>>>>
>>>> Mani, could you elaborate on this?
>>>
>>> So the remoteproc driver expects the wdog interrupts to be edge triggered
>>> as the rest of the interrupts, but DT specifies them as level triggered.
>>> This won't cause any issue during the first instance of the probe as the
>>> driver requested trigger will be given precedence. But if the probe
>>> defers for some reason and during the next try, request_irq() will fail
>>> with error similar to below:
>>>
>>> irq: type mismatch, failed to map hwirq-x for interrupt-controller@xxxxxx!
>>>
>>> This error is often confusing and I tried to fix it. But Maz didn't agree
>>> with me, so I just ended up fixing the DTs for some platform I have
>>> access to.
>>>
>>> So ideally, DTs of all platforms should be fixed to pass correct trigger
>>> type.
>> So, this should be edge for all platforms, correct?
> 
> I'd believe so, iirc when I looked at the driver it always requests that
> interrupt type.
> 
> For reference, these are my patches:
> 
> sm6350:
> https://github.com/z3ntu/linux/commit/0522b7a1b981d80884a785c7e654bb5094ea1bc2
> 
> sc7280:
> https://github.com/z3ntu/linux/commit/ead1d7b8f5648535b857cfa9250aac2480f00ed3
Can you send those, as well as fix up other outliers? Probably won't get in
for this cycle, but still very much worth to get them upstream..

Konrad