* Re: [PATCH 2/2] arm64: dts: qcom: Add basic support for LG G4 (H815)
From: Petr Vorel @ 2024-04-03 17:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alexander Reimelt, andersson, konrad.dybcio, robh+dt,
krzysztof.kozlowski+dt, conor+dt, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <10f02618-f16c-47d4-a27f-074b1ecffaa1@linaro.org>
Hi all,
> On 03/04/2024 12:43, Alexander Reimelt wrote:
> > To make it easier for downstream projects and avoid duplication of work.
> > Makes the device bootable and enables all buttons, most regulators, hall sensor, eMMC and SD-Card.
> > Signed-off-by: Alexander Reimelt <alexander.reimelt@posteo.de>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts | 422 +++++++++++++++++++
> > 2 files changed, 423 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts
> 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.
@Alexander arm: would be for 32bit. Correct subject prefix is:
arm64: dts: qcom: msm8992-lg-h815:
Krzysztof's comments are obviously correct.
Please Cc me on v2 to my gmail private mail. Thanks!
Kind regards,
Petr
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: PCI: qcom: Add IPQ9574 PCIe controller
From: mr.nuke.me @ 2024-04-03 18:05 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio,
Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Manivannan Sadhasivam
Cc: ansuelsmth, robimarko, linux-arm-msm, linux-pci, devicetree,
linux-kernel
In-Reply-To: <bad88189-cf70-4200-9fa3-650ea923b4b8@linaro.org>
On 4/3/24 02:14, Krzysztof Kozlowski wrote:
> On 02/04/2024 21:25, Alexandru Gagniuc wrote:
>> IPQ9574 has PCIe controllers which are almost identical to IPQ6018.
>> The only difference is that the "iface" clock is not required.
>> Document this difference along with the compatible string.
>>
>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>> ---
>> .../devicetree/bindings/pci/qcom,pcie.yaml | 32 +++++++++++++++++++
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
>> index cf9a6910b542..6eb29547c18e 100644
>> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
>> @@ -26,6 +26,7 @@ properties:
>> - qcom,pcie-ipq8064-v2
>> - qcom,pcie-ipq8074
>> - qcom,pcie-ipq8074-gen3
>> + - qcom,pcie-ipq9574
>> - qcom,pcie-msm8996
>> - qcom,pcie-qcs404
>> - qcom,pcie-sdm845
>> @@ -383,6 +384,35 @@ allOf:
>> - const: axi_s # AXI Slave clock
>> - const: axi_bridge # AXI bridge clock
>> - const: rchng
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - qcom,pcie-ipq9574
>> + then:
>> + properties:
>> + clocks:
>> + minItems: 4
>> + maxItems: 4
>> + clock-names:
>> + items:
>> + - const: axi_m # AXI Master clock
>> + - const: axi_s # AXI Slave clock
>> + - const: axi_bridge # AXI bridge clock
>> + - const: rchng
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - qcom,pcie-ipq6018
>> + - qcom,pcie-ipq8074-gen3
>> + - qcom,pcie-ipq9574
>> + then:
>
> Do not introduce inconsistent style. All if:then: define both clocks and
> resets, right? And after your patch not anymore?
>
I kept the resets in one place because they are the same cross the ipq*
variants.
Do I understand correctly that you wish me to split up the resets as well?
if ipq8074 ipq6018
clocks
resets
if ipq9754
clocks
resets
Alex
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v14 01/18] irqchip/sifive-plic: Convert PLIC driver into a platform driver
From: Lad, Prabhakar @ 2024-04-03 18:10 UTC (permalink / raw)
To: Samuel Holland, Anup Patel
Cc: Anup Patel, devicetree, Conor Dooley, Geert Uytterhoeven,
Marc Zyngier, Atish Patra, linux-kernel, Saravana Kannan,
Björn Töpel, Rob Herring, Palmer Dabbelt,
Krzysztof Kozlowski, Paul Walmsley, Thomas Gleixner, Frank Rowand,
linux-riscv, linux-arm-kernel, Andrew Jones
In-Reply-To: <4dbd5daf-d100-4ae2-8bda-c657e23a809e@sifive.com>
Hi Samuel and Anup,
On Wed, Apr 3, 2024 at 5:28 PM Samuel Holland <samuel.holland@sifive.com> wrote:
>
> Hi Prabhakar,
>
> On 2024-04-03 10:49 AM, Lad, Prabhakar wrote:
> > On Wed, Apr 3, 2024 at 3:17 PM Anup Patel <apatel@ventanamicro.com> wrote:
> >>
> >> On Wed, Apr 3, 2024 at 2:01 PM Lad, Prabhakar
> >> <prabhakar.csengg@gmail.com> wrote:
> >>>
> >>> Hi Anup,
> >>>
> >>> On Thu, Feb 22, 2024 at 9:41 AM Anup Patel <apatel@ventanamicro.com> wrote:
> >>>>
> >>>> The PLIC driver does not require very early initialization so convert
> >>>> it into a platform driver.
> >>>>
> >>>> After conversion, the PLIC driver is probed after CPUs are brought-up
> >>>> so setup cpuhp state after context handler of all online CPUs are
> >>>> initialized otherwise PLIC driver crashes for platforms with multiple
> >>>> PLIC instances.
> >>>>
> >>>> Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> >>>> ---
> >>>> drivers/irqchip/irq-sifive-plic.c | 101 ++++++++++++++++++------------
> >>>> 1 file changed, 61 insertions(+), 40 deletions(-)
> >>>>
> >>> This patch seems to have broken things on RZ/Five SoC, after reverting
> >>> this patch I get to boot it back again on v6.9-rc2. Looks like there
> >>> is some probe order issue after switching to platform driver?
> >>
> >> Yes, this is most likely related to probe ordering based on your DT.
> >>
> >> Can you share the failing boot log and DT ?
> >
> > non working case, https://paste.debian.net/1312947/
>
> Looks like you need to add "keep_bootcon" to your kernel command line to get a
> full log here.
>
Thanks for the pointer, that helped me to get to the root cause.
> > after reverting, https://paste.debian.net/1312948/
> > (attached is the DTB)
>
> I don't see anything suspicious between the "riscv-intc" lines and the "Fixed
> dependency cycle(s)" lines that looks like it would depend on the PLIC IRQ
> domain. Maybe there is some driver that does not handle -EPROBE_DEFER? It's hard
> to tell without the full log from the failure case.
>
The clock required for the PLIC wasnt available during the probe of
this driver. This bug got hidden when the PLIC driver was probed
earlier in boot where it used an incorrect clock source. Ive created
a patch which adds a missing clock for the PLIC.
Sorry for the noise!
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
From: Marc Gonzalez @ 2024-04-03 18:16 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Krzysztof Kozlowski, Kalle Valo, Jeff Johnson,
ath10k, wireless, DT, MSM, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pierre-Hugues Husson, Arnaud Vrac, Bjorn Andersson,
Jami Kettunen, Jeffrey Hugo
In-Reply-To: <CAA8EJpooJLbV+nVWedru=r6fascd8ZxKumiMm_iyzzJwyQ-tig@mail.gmail.com>
On 03/04/2024 16:12, Dmitry Baryshkov wrote:
> From [Jeff's] message it looks like we are expected to get MSA READY even on msm8998.
This is the code we're using:
https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/drivers/net/wireless/ath/ath10k/qmi.c
When ATH10K_SNOC_DRIVER_EVENT_SERVER_ARRIVE,
driver registers an "indicator handler"
ath10k_snoc_qmi_wlfw_clnt_ind()
It handles QMI_WLFW_FW_READY_IND_V01 by posting
ATH10K_SNOC_DRIVER_EVENT_FW_READY_IND
which is handled in the
ath10k_snoc_driver_event_work() work queue.
But QMI_WLFW_MSA_READY_IND_V01 only triggers
a debug log and setting qmi_cfg->msa_ready = true;
$ git grep '\<msa_ready\>'
drivers/net/wireless/ath/ath10k/qmi.c: qmi_cfg->msa_ready = true;
drivers/net/wireless/ath/ath10k/qmi.c: qmi_cfg->msa_ready = false;
drivers/net/wireless/ath/ath10k/qmi.h: * msa_ready: wlan firmware msa memory ready for board data download
drivers/net/wireless/ath/ath10k/qmi.h: bool msa_ready;
So basically, the vendor ath10k driver ignores QMI_WLFW_MSA_READY_IND_V01.
I will test the following patch which aligns the behavior
of mainline driver to that of vendor driver:
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 38e939f572a9e..0e1ab5aca663b 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -1040,6 +1040,7 @@ static void ath10k_qmi_driver_event_work(struct work_struct *work)
switch (event->type) {
case ATH10K_QMI_EVENT_SERVER_ARRIVE:
ath10k_qmi_event_server_arrive(qmi);
+ ath10k_qmi_event_msa_ready(qmi);
break;
case ATH10K_QMI_EVENT_SERVER_EXIT:
ath10k_qmi_event_server_exit(qmi);
@@ -1048,7 +1049,7 @@ static void ath10k_qmi_driver_event_work(struct work_struct *work)
ath10k_qmi_event_fw_ready_ind(qmi);
break;
case ATH10K_QMI_EVENT_MSA_READY_IND:
- ath10k_qmi_event_msa_ready(qmi);
+ printk(KERN_WARNING "IGNORING MSA_READY INDICATOR");
break;
default:
ath10k_warn(ar, "invalid event type: %d", event->type);
Dmitry Baryshkov reported:
Works on sm8150, sdm845, qrb2210
Regards
^ permalink raw reply related
* Re: [PATCH v6 00/11] riscv: add initial support for Canaan Kendryte K230
From: Palmer Dabbelt @ 2024-04-03 18:22 UTC (permalink / raw)
To: cyy
Cc: linux-riscv, Conor Dooley, dlemoal, robh+dt,
krzysztof.kozlowski+dt, Paul Walmsley, aou, guoren, mturquette,
sboyd, linus.walleij, p.zabel, linux-gpio, linux-clk, devicetree,
linux-kernel, cyy
In-Reply-To: <tencent_F76EB8D731C521C18D5D7C4F8229DAA58E08@qq.com>
On Sat, 23 Mar 2024 05:09:42 PDT (-0700), cyy@cyyself.name wrote:
> K230 is an ideal chip for RISC-V Vector 1.0 evaluation now. Add initial
> support for it to allow more people to participate in building drivers
> to mainline for it.
>
> This kernel has been tested upon factory SDK [1] with
> k230_evb_only_linux_defconfig and patched mainline opensbi [2] to skip
> locked pmp and successfully booted to busybox on initrd with this log [3].
>
> [1] https://github.com/kendryte/k230_sdk
> [2] https://github.com/cyyself/opensbi/tree/k230
> [3] https://gist.github.com/cyyself/b9445f38cc3ba1094924bd41c9086176
>
> Changes since v5:
> - Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210 SoCs
> - Modify existing K210 drivers depends on SOC_CANAAN_K210 symbol
> - Reword dts commit message
> - Modify dts to use Full 512MB memory
> - Rebase to linux mainline master
>
> Changes since v4:
> - Reword commit message on dts that the B-ext version of c908 is 1.0 rather
> than 1.0-rc1
>
> v4: https://lore.kernel.org/linux-riscv/tencent_587730262984A011834F42D0563BC6B10405@qq.com/
>
> Changes since v3:
> - Refactor Kconfig.soc which uses ARCH_CANAAN for regular Canaan SoCs and
> rename SOC_CANAAN to SOC_CANAAN_K210 for K210 in patch [5/7]
> - Sort dt-binding stings on Cannan SoCs in alphanumerical order
>
> v3: https://lore.kernel.org/linux-riscv/tencent_BB2364BBF1812F4E304F7BDDD11E57356605@qq.com/
>
> Changes since v2:
> - Add MIT License to dts file
> - Sort dt-binding stings in alphanumerical order
> - Sort filename in dts Makefile in alphanumerical order
> - Rename canmv-k230.dts to k230-canmv.dts
>
> v2: https://lore.kernel.org/linux-riscv/tencent_64A9B4B31C2D70D5633042461AC9F80C0509@qq.com/
>
> Changes since v1:
> - Patch dt-bindings in clint and plic
> - Use enum in K230 compatible dt bindings
> - Fix dts to pass `make dtbs_check`
> - Add more details in commit message
>
> v1: https://lore.kernel.org/linux-riscv/tencent_E15F8FE0B6769E6338AE690C7F4844A31706@qq.com/
>
> Yangyu Chen (11):
> dt-bindings: riscv: Add T-HEAD C908 compatible
> dt-bindings: add Canaan K230 boards compatible strings
> dt-bindings: timer: Add Canaan K230 CLINT
> dt-bindings: interrupt-controller: Add Canaan K230 PLIC
> riscv: Kconfig.socs: Split ARCH_CANAAN and SOC_CANAAN_K210
> soc: canaan: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210
> clk: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
> pinctrl: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
> reset: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
> riscv: dts: add initial canmv-k230 and k230-evb dts
> riscv: config: enable ARCH_CANAAN in defconfig
>
> .../sifive,plic-1.0.0.yaml | 1 +
> .../devicetree/bindings/riscv/canaan.yaml | 8 +-
> .../devicetree/bindings/riscv/cpus.yaml | 1 +
> .../bindings/timer/sifive,clint.yaml | 1 +
> arch/riscv/Kconfig.socs | 8 +-
> arch/riscv/Makefile | 2 +-
> arch/riscv/boot/dts/canaan/Makefile | 2 +
> arch/riscv/boot/dts/canaan/k230-canmv.dts | 24 +++
> arch/riscv/boot/dts/canaan/k230-evb.dts | 24 +++
> arch/riscv/boot/dts/canaan/k230.dtsi | 140 ++++++++++++++++++
> arch/riscv/configs/defconfig | 1 +
> arch/riscv/configs/nommu_k210_defconfig | 3 +-
> .../riscv/configs/nommu_k210_sdcard_defconfig | 3 +-
> drivers/clk/Kconfig | 4 +-
> drivers/pinctrl/Kconfig | 4 +-
> drivers/reset/Kconfig | 4 +-
> drivers/soc/Makefile | 2 +-
> drivers/soc/canaan/Kconfig | 4 +-
> 18 files changed, 220 insertions(+), 16 deletions(-)
> create mode 100644 arch/riscv/boot/dts/canaan/k230-canmv.dts
> create mode 100644 arch/riscv/boot/dts/canaan/k230-evb.dts
> create mode 100644 arch/riscv/boot/dts/canaan/k230.dtsi
>
> base-commit: 8e938e39866920ddc266898e6ae1fffc5c8f51aa
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mailbox: arm,mhuv3: Add bindings
From: Rob Herring @ 2024-04-03 18:24 UTC (permalink / raw)
To: Cristian Marussi
Cc: sudeep.holla, conor+dt, linux-arm-kernel, linux-kernel,
jassisinghbrar, robh+dt, krzysztof.kozlowski+dt, devicetree
In-Reply-To: <20240403171346.3173843-2-cristian.marussi@arm.com>
On Wed, 03 Apr 2024 18:13:45 +0100, Cristian Marussi wrote:
> Add bindings for the ARM MHUv3 Mailbox controller.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> v1 -> v2
> - clarified extension descriptions around configurability and discoverability
> - removed unused labels from the example
> - using pattern properties to define interrupt-names
> - bumped interrupt maxItems to 74 (allowing uo to 8 channels per extension)
> ---
> .../bindings/mailbox/arm,mhuv3.yaml | 217 ++++++++++++++++++
> 1 file changed, 217 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
./Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml:86:1: [error] syntax error: found character '\t' that cannot start any token (syntax)
dtschema/dtc warnings/errors:
make[2]: *** Deleting file 'Documentation/devicetree/bindings/mailbox/arm,mhuv3.example.dts'
Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml:86:1: found a tab character where an indentation space is expected
make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/mailbox/arm,mhuv3.example.dts] Error 1
make[2]: *** Waiting for unfinished jobs....
./Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml:86:1: found a tab character where an indentation space is expected
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml: ignoring, error parsing file
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2
make: *** [Makefile:240: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240403171346.3173843-2-cristian.marussi@arm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: Add basic support for LG G4 (H815)
From: Petr Vorel @ 2024-04-03 18:43 UTC (permalink / raw)
To: Alexander Reimelt
Cc: andersson, konrad.dybcio, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-arm-msm, devicetree, linux-kernel,
Dmitry Baryshkov
In-Reply-To: <20240403104415.30636-3-alexander.reimelt@posteo.de>
Hi,
> To make it easier for downstream projects and avoid duplication of work.
> Makes the device bootable and enables all buttons, most regulators, hall sensor, eMMC and SD-Card.
> Signed-off-by: Alexander Reimelt <alexander.reimelt@posteo.de>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts | 422 +++++++++++++++++++
> 2 files changed, 423 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 7d40ec5e7d21..5b7f8741006f 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -62,6 +62,7 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8956-sony-xperia-loire-kugo.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8956-sony-xperia-loire-suzu.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8992-lg-bullhead-rev-10.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8992-lg-bullhead-rev-101.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += msm8992-lg-h815.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8992-msft-lumia-octagon-talkman.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8992-xiaomi-libra.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8994-huawei-angler-rev-101.dtb
> diff --git a/arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts b/arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts
> new file mode 100644
> index 000000000000..b7fa48337e25
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts
> @@ -0,0 +1,422 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * MSM8992 LG G4 (h815) device tree.
> + *
> + * Copyright (c) 2024, Alexander Reimelt <alexander.reimelt@posteo.de>
> + */
> +
> +/dts-v1/;
> +
> +#include "msm8992.dtsi"
> +#include "pm8994.dtsi"
> +#include "pmi8994.dtsi"
> +#include <dt-bindings/leds/common.h>
> +
> +/* different mapping */
> +/delete-node/ &cont_splash_mem;
> +
> +/* disabled downstream */
> +/delete-node/ &dfps_data_mem;
> +
> +&CPU0 {
> + enable-method = "spin-table";
> +};
> +
> +&CPU1 {
> + enable-method = "spin-table";
> +};
> +
> +&CPU2 {
> + enable-method = "spin-table";
> +};
> +
> +&CPU3 {
> + enable-method = "spin-table";
> +};
> +
> +&CPU4 {
> + enable-method = "spin-table";
> +};
> +
> +&CPU5 {
> + enable-method = "spin-table";
> +};
> +
> +/ {
> + model = "LG G4 (International)";
I'm not sure if " (International)" shouldn't be dropped.
I guess maintainers will know.
> + compatible = "lg,h815", "qcom,msm8992";
> + chassis-type = "handset";
> +
> + qcom,msm-id = <251 0>;
> + qcom,pmic-id = <0x10009 0x1000a 0x00 0x00>;
> + qcom,board-id = <0xb64 0>;
> +
> + /* psci is broken */
> + /delete-node/ psci;
> +
> + chosen {
> + bootargs = "earlycon=tty0 console=tty0";
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + spin-table@6000000 {
> + reg = <0 0x6000000 0 0x1000>;
> + no-map;
> + };
> +
> + ramoops@ff00000 {
> + compatible = "ramoops";
> + reg = <0x0 0xff00000 0x0 0x100000>;
> + console-size = <0x20000>;
> + pmsg-size = <0x20000>;
> + record-size = <0x10000>;
> + ecc-size = <0x10>;
> + };
> +
> + cont_splash_mem: fb@3400000 {
> + compatible = "framebuffer";
> + reg = <0 0x3400000 0 0xc00000>;
> + no-map;
> + };
> +
> + crash_fb_mem: crash_fb@4000000 {
> + reg = <0 0x4000000 0 0xc00000>;
> + no-map;
> + };
> + };
> +
> + gpio-hall-sensor {
> + compatible = "gpio-keys";
> +
> + pinctrl-0 = <&hall_sensor_default>;
> + pinctrl-names = "default";
> +
> + label = "Hall Effect Sensor";
> +
> + event-hall-sensor {
> + gpios = <&tlmm 75 GPIO_ACTIVE_LOW>;
> + label = "hall effect sensor";
> + linux,input-type = <EV_SW>;
> + linux,code = <SW_LID>;
> + linux,can-disable;
> + wakeup-source;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + key-vol-up {
> + label = "volume up";
> + gpios = <&pm8994_gpios 3 GPIO_ACTIVE_LOW>;
> + linux,code = <KEY_VOLUMEUP>;
> + wakeup-source;
> + debounce-interval = <15>;
> + };
> + };
> +};
> +
> +&pm8994_spmi_regulators {
> + vdd_s8-supply = <&vph_pwr>;
> + vdd_s11-supply = <&vph_pwr>;
> +
> + pm8994_s8: s8 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1180000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + pm8994_s11: s11 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1225000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +};
> +
> +&rpm_requests {
> + regulators-0 {
> + compatible = "qcom,rpm-pm8994-regulators";
> +
> + vdd_s3-supply = <&vph_pwr>;
> + vdd_s4-supply = <&vph_pwr>;
> + vdd_s5-supply = <&vph_pwr>;
> + vdd_s7-supply = <&vph_pwr>;
> + vdd_l1-supply = <&pmi8994_s1>;
> + vdd_l2_26_28-supply = <&pm8994_s3>;
> + vdd_l3_11-supply = <&pm8994_s3>;
> + vdd_l4_27_31-supply = <&pm8994_s3>;
> + vdd_l5_7-supply = <&pm8994_s5>;
> + vdd_l6_12_32-supply = <&pm8994_s5>;
> + vdd_l8_16_30-supply = <&vph_pwr>;
> + vdd_l9_10_18_22-supply = <&pmi8994_bby>;
> + vdd_l13_19_23_24-supply = <&pmi8994_bby>;
> + vdd_l14_15-supply = <&pm8994_s5>;
> + vdd_l17_29-supply = <&pmi8994_bby>;
> + vdd_l20_21-supply = <&pmi8994_bby>;
> + vdd_l25-supply = <&pm8994_s5>;
> + vdd_lvs1_2-supply = <&pm8994_s4>;
> +
> + pm8994_s3: s3 {
> + regulator-min-microvolt = <1300000>;
> + regulator-max-microvolt = <1300000>;
> + };
> +
> + /* sdhc1 vqmmc and bcm */
> + pm8994_s4: s4 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-system-load = <325000>;
> + regulator-allow-set-load;
> + };
> +
> + pm8994_s5: s5 {
> + regulator-min-microvolt = <2150000>;
> + regulator-max-microvolt = <2150000>;
> + };
> +
> + pm8994_s7: s7 {
There are several unused regulators.
I remember Bjorn back at the time suggested [1] me to add only regulators which
are actually needed.
Kind regards,
Petr
[1] https://lore.kernel.org/linux-arm-msm/20230407165730.jfupmfiul6qb7yl3@ripper/
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + };
> +
> + pm8994_l1: l1 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + };
> +
> + pm8994_l2: l2 {
> + regulator-min-microvolt = <1250000>;
> + regulator-max-microvolt = <1250000>;
> + regulator-system-load = <10000>;
> + regulator-allow-set-load;
> + };
> +
> + /* camera */
> + pm8994_l3: l3 {
> + regulator-min-microvolt = <1050000>;
> + regulator-max-microvolt = <1050000>;
> + };
> +
> + pm8994_l4: l4 {
> + regulator-min-microvolt = <1225000>;
> + regulator-max-microvolt = <1225000>;
> + };
> +
> + /* L5 is inaccessible from RPM */
> +
> + pm8994_l6: l6 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + /* L7 is inaccessible from RPM */
> +
> + pm8994_l8: l8 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + pm8994_l9: l9 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + /* touch */
> + pm8994_l10: l10 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + pm8994_l11: l11 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + };
> +
> + pm8994_l12: l12 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-system-load = <10000>;
> + regulator-allow-set-load;
> + };
> +
> + /* sdhc2 vqmmc */
> + pm8994_l13: l13 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2950000>;
> + regulator-system-load = <22000>;
> + regulator-allow-set-load;
> + };
> +
> + /* camera */
> + pm8994_l14: l14 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-system-load = <10000>;
> + regulator-allow-set-load;
> + };
> +
> + pm8994_l15: l15 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + pm8994_l16: l16 {
> + regulator-min-microvolt = <2700000>;
> + regulator-max-microvolt = <2700000>;
> + };
> +
> + /* camera */
> + pm8994_l17: l17 {
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + };
> +
> + pm8994_l18: l18 {
> + regulator-min-microvolt = <2850000>;
> + regulator-max-microvolt = <2850000>;
> + };
> +
> + /* LCD */
> + pm8994_l19: l19 {
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + };
> +
> + /* sdhc1 vmmc */
> + pm8994_l20: l20 {
> + regulator-min-microvolt = <2950000>;
> + regulator-max-microvolt = <2950000>;
> + regulator-system-load = <570000>;
> + regulator-allow-set-load;
> + };
> +
> + /* sdhc2 vmmc */
> + pm8994_l21: l21 {
> + regulator-min-microvolt = <2950000>;
> + regulator-max-microvolt = <2950000>;
> + regulator-system-load = <800000>;
> + regulator-allow-set-load;
> + };
> +
> + /* touch */
> + pm8994_l22: l22 {
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + };
> +
> + /* camera */
> + pm8994_l23: l23 {
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + };
> +
> + pm8994_l24: l24 {
> + regulator-min-microvolt = <3075000>;
> + regulator-max-microvolt = <3150000>;
> + };
> +
> + /* IRRC */
> + pm8994_l25: l25 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + };
> +
> + pm8994_l26: l26 {
> + regulator-min-microvolt = <987500>;
> + regulator-max-microvolt = <987500>;
> + };
> +
> + /* hdmi */
> + pm8994_l27: l27 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + };
> +
> + pm8994_l28: l28 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-system-load = <10000>;
> + regulator-allow-set-load;
> + };
> +
> + /* camera */
> + pm8994_l29: l29 {
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + };
> +
> + /* camera */
> + pm8994_l30: l30 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + pm8994_l31: l31 {
> + regulator-min-microvolt = <1262500>;
> + regulator-max-microvolt = <1262500>;
> + };
> +
> + pm8994_l32: l32 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + pm8994_lvs1: lvs1 {};
> +
> + pm8994_lvs2: lvs2 {};
> + };
> +
> + regulators-1 {
> + compatible = "qcom,rpm-pmi8994-regulators";
> +
> + vdd_s1-supply = <&vph_pwr>;
> + vdd_bst_byp-supply = <&vph_pwr>;
> +
> + pmi8994_s1: s1 {
> + regulator-min-microvolt = <1025000>;
> + regulator-max-microvolt = <1025000>;
> + };
> +
> + /* S2 & S3 - VDD_GFX */
> +
> + pmi8994_bby: boost-bypass {
> + regulator-min-microvolt = <3150000>;
> + regulator-max-microvolt = <3600000>;
> + };
> + };
> +};
> +
> +&pm8994_resin {
> + status = "okay";
> + linux,code = <KEY_VOLUMEDOWN>;
> +};
> +
> +&sdhc1 {
> + status = "okay";
> + mmc-hs400-1_8v;
> + vmmc-supply = <&pm8994_l20>;
> + vqmmc-supply = <&pm8994_s4>;
> + non-removable;
> +};
> +
> +&sdhc2 {
> + status = "okay";
> + vmmc-supply = <&pm8994_l21>;
> + vqmmc-supply = <&pm8994_l13>;
> + cd-gpios = <&pm8994_gpios 8 GPIO_ACTIVE_LOW>;
> +};
> +
> +&tlmm {
> + hall_sensor_default: hall-sensor-default-state {
> + pins = "gpio75";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +};
^ permalink raw reply
* Re: [PATCH v3 05/25] media: i2c: imx258: Add regulator control
From: Pavel Machek @ 2024-04-03 18:44 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel
In-Reply-To: <20240403150355.189229-6-git@luigi311.com>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
Hi!
> The device tree bindings define the relevant regulators for the
> sensor, so update the driver to request the regulators and control
> them at the appropriate times.
> @@ -995,9 +1007,19 @@ static int imx258_power_on(struct device *dev)
> struct imx258 *imx258 = to_imx258(sd);
> int ret;
>
> + ret = regulator_bulk_enable(IMX258_NUM_SUPPLIES,
> + imx258->supplies);
> + if (ret) {
Will this make it fail for all current users?
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH v3 09/25] media: i2c: imx258: Add support for running on 2 CSI data lanes
From: Pavel Machek @ 2024-04-03 18:45 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel
In-Reply-To: <20240403150355.189229-10-git@luigi311.com>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
Hi!
> +/*
> + * 4208x3120 @ 30 fps needs 1267Mbps/lane, 4 lanes.
> + * To avoid further computation of clock settings, adopt the same per
> + * lane data rate when using 2 lanes, thus allowing a maximum of 15fps.
> + */
> +static const struct imx258_reg mipi_1267mbps_19_2mhz_2l[] = {
> + { 0x0136, 0x13 },
> + { 0x0137, 0x33 },
> + { 0x0301, 0x0A },
> + { 0x0303, 0x02 },
> + { 0x0305, 0x03 },
> + { 0x0306, 0x00 },
> + { 0x0307, 0xC6 },
> + { 0x0309, 0x0A },
> + { 0x030B, 0x01 },
> + { 0x030D, 0x02 },
> + { 0x030E, 0x00 },
> + { 0x030F, 0xD8 },
> + { 0x0310, 0x00 },
> +
> + { 0x0114, 0x01 },
> + { 0x0820, 0x09 },
> + { 0x0821, 0xa6 },
> + { 0x0822, 0x66 },
> + { 0x0823, 0x66 },
> +};
> +
> +static const struct imx258_reg mipi_1267mbps_19_2mhz_4l[] = {
> { 0x0136, 0x13 },
> { 0x0137, 0x33 },
> { 0x0301, 0x05 },
I wish we did not have to copy all the magic values like this.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH v3 10/25] media: i2c: imx258: Follow normal V4L2 behaviours for clipping exposure
From: Pavel Machek @ 2024-04-03 18:45 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel
In-Reply-To: <20240403150355.189229-11-git@luigi311.com>
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
On Wed 2024-04-03 09:03:39, git@luigi311.com wrote:
> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>
> V4L2 sensor drivers are expected are expected to clip the supported
Remove one copy of "are expected".
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH v3 11/25] media: i2c: imx258: Add get_selection for pixel array information
From: Pavel Machek @ 2024-04-03 18:46 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel
In-Reply-To: <20240403150355.189229-12-git@luigi311.com>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
Hi!
> Libcamera requires the cropping information for each mode, so
> add this information to the driver.
> @@ -116,6 +124,9 @@ struct imx258_mode {
> u32 link_freq_index;
> /* Default register values */
> struct imx258_reg_list reg_list;
> +
> + /* Analog crop rectangle. */
No need for "." at the end, as it is not above.
> + struct v4l2_rect crop;
> };
If the crop is same in all modes, should we have it in common place?
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH v3 12/25] media: i2c: imx258: Allow configuration of clock lane behaviour
From: Pavel Machek @ 2024-04-03 18:48 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel
In-Reply-To: <20240403150355.189229-13-git@luigi311.com>
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
Hi!
> The sensor supports the clock lane either remaining in HS mode
> during frame blanking, or dropping to LP11.
>
> Add configuration of the mode via V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK.
> + ret = imx258_write_reg(imx258, IMX258_CLK_BLANK_STOP,
> + IMX258_REG_VALUE_08BIT,
> + imx258->csi2_flags & V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK ?
> + 1 : 0);
!! can be used to turn value into 1/0. I find it easier to read than ?
1 : 0 combination, but possibly that's fine, too.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH v3 22/25] dt-bindings: media: imx258: Add binding for powerdown-gpio
From: Pavel Machek @ 2024-04-03 18:49 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel, Ondrej Jirman
In-Reply-To: <20240403150355.189229-23-git@luigi311.com>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
Hi!
> From: Luis Garcia <git@luigi311.com>
>
> Add powerdown-gpio binding as it is required for some boards
"." at end of sentence.
> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> Signed-off-by: Luis Garcia <git@luigi311.com>
If the patch is from Ondrej, he should be in From:, I believe.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: msm8916-samsung-fortuna: Add touchscreen
From: Bjorn Andersson @ 2024-04-03 18:49 UTC (permalink / raw)
To: Raymond Hackley
Cc: linux-kernel, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stephan Gerhold, Nikita Travkin, linux-arm-msm,
devicetree, ~postmarketos/upstreaming, Joe Mason
In-Reply-To: <20240312074536.62964-1-raymondhackley@protonmail.com>
On Tue, Mar 12, 2024 at 07:45:42AM +0000, Raymond Hackley wrote:
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-fortuna-common.dtsi b/arch/arm64/boot/dts/qcom/msm8916-samsung-fortuna-common.dtsi
[..]
> +&blsp_i2c5 {
> + status = "okay";
> +
> + touchscreen: touchscreen@20 {
> + compatible = "zinitix,bt541";
> + reg = <0x20>;
> +
> + interrupts-extended = <&tlmm 13 IRQ_TYPE_EDGE_FALLING>;
> +
> + touchscreen-size-x = <540>;
> + touchscreen-size-y = <960>;
> +
> + vcca-supply = <®_vdd_tsp_a>;
> + vdd-supply = <&pm8916_l6>;
> +
> + pinctrl-0 = <&tsp_int_default>;
> + pinctrl-names = "default";
> +
> + linux,keycodes = <KEY_APPSELECT KEY_BACK>;
linux,keycodes is not a valid property of zinitix,bt541 according to the
DeviceTree binding. Is there a binding update for this somewhere?
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v3 00/25] imx258 improvement series
From: Pavel Machek @ 2024-04-03 18:50 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel
In-Reply-To: <20240403150355.189229-1-git@luigi311.com>
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
Hi!
Thanks for doing this. I had some comments on 5, 9, 10, 11, 12, 21
and 22. You can add "Reviewed-by: Pavel Machek <pavel@ucw.cz>" to the
rest.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH v3 10/25] media: i2c: imx258: Follow normal V4L2 behaviours for clipping exposure
From: Luigi311 @ 2024-04-03 19:14 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel
In-Reply-To: <Zg2j1XeOhFwO2Nf2@duo.ucw.cz>
On 4/3/24 12:45, Pavel Machek wrote:
> On Wed 2024-04-03 09:03:39, git@luigi311.com wrote:
>> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>
>> V4L2 sensor drivers are expected are expected to clip the supported
>
> Remove one copy of "are expected".
>
> Best regards,
> Pavel
>
Done
^ permalink raw reply
* Re: [PATCH v3 21/25] drivers: media: i2c: imx258: Use macros
From: Luigi311 @ 2024-04-03 19:17 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel, pavel,
phone-devel, Ondrej Jirman
In-Reply-To: <Zg2CirmwL3JfjA8s@kekkonen.localdomain>
On 4/3/24 10:23, Sakari Ailus wrote:
> Hi Luis,
>
> On Wed, Apr 03, 2024 at 09:03:50AM -0600, git@luigi311.com wrote:
>> From: Luis Garcia <git@luigi311.com>
>>
>> Use understandable macros instead of raw values.
>>
>> Signed-off-by: Ondrej Jirman <megi@xff.cz>
>> Signed-off-by: Luis Garcia <git@luigi311.com>
>> ---
>> drivers/media/i2c/imx258.c | 434 ++++++++++++++++++-------------------
>> 1 file changed, 207 insertions(+), 227 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
>> index e2ecf6109516..30352c33f63c 100644
>> --- a/drivers/media/i2c/imx258.c
>> +++ b/drivers/media/i2c/imx258.c
>> @@ -33,8 +33,6 @@
>> #define IMX258_VTS_30FPS_VGA 0x034c
>> #define IMX258_VTS_MAX 65525
>>
>> -#define IMX258_REG_VTS 0x0340
>> -
>> /* HBLANK control - read only */
>> #define IMX258_PPL_DEFAULT 5352
>>
>> @@ -90,6 +88,53 @@
>> #define IMX258_PIXEL_ARRAY_WIDTH 4208U
>> #define IMX258_PIXEL_ARRAY_HEIGHT 3120U
>>
>> +/* regs */
>> +#define IMX258_REG_PLL_MULT_DRIV 0x0310
>> +#define IMX258_REG_IVTPXCK_DIV 0x0301
>> +#define IMX258_REG_IVTSYCK_DIV 0x0303
>> +#define IMX258_REG_PREPLLCK_VT_DIV 0x0305
>> +#define IMX258_REG_IOPPXCK_DIV 0x0309
>> +#define IMX258_REG_IOPSYCK_DIV 0x030b
>> +#define IMX258_REG_PREPLLCK_OP_DIV 0x030d
>> +#define IMX258_REG_PHASE_PIX_OUTEN 0x3030
>> +#define IMX258_REG_PDPIX_DATA_RATE 0x3032
>> +#define IMX258_REG_SCALE_MODE 0x0401
>> +#define IMX258_REG_SCALE_MODE_EXT 0x3038
>> +#define IMX258_REG_AF_WINDOW_MODE 0x7bcd
>> +#define IMX258_REG_FRM_LENGTH_CTL 0x0350
>> +#define IMX258_REG_CSI_LANE_MODE 0x0114
>> +#define IMX258_REG_X_EVN_INC 0x0381
>> +#define IMX258_REG_X_ODD_INC 0x0383
>> +#define IMX258_REG_Y_EVN_INC 0x0385
>> +#define IMX258_REG_Y_ODD_INC 0x0387
>> +#define IMX258_REG_BINNING_MODE 0x0900
>> +#define IMX258_REG_BINNING_TYPE_V 0x0901
>> +#define IMX258_REG_FORCE_FD_SUM 0x300d
>> +#define IMX258_REG_DIG_CROP_X_OFFSET 0x0408
>> +#define IMX258_REG_DIG_CROP_Y_OFFSET 0x040a
>> +#define IMX258_REG_DIG_CROP_IMAGE_WIDTH 0x040c
>> +#define IMX258_REG_DIG_CROP_IMAGE_HEIGHT 0x040e
>> +#define IMX258_REG_SCALE_M 0x0404
>> +#define IMX258_REG_X_OUT_SIZE 0x034c
>> +#define IMX258_REG_Y_OUT_SIZE 0x034e
>> +#define IMX258_REG_X_ADD_STA 0x0344
>> +#define IMX258_REG_Y_ADD_STA 0x0346
>> +#define IMX258_REG_X_ADD_END 0x0348
>> +#define IMX258_REG_Y_ADD_END 0x034a
>> +#define IMX258_REG_EXCK_FREQ 0x0136
>> +#define IMX258_REG_CSI_DT_FMT 0x0112
>> +#define IMX258_REG_LINE_LENGTH_PCK 0x0342
>> +#define IMX258_REG_SCALE_M_EXT 0x303a
>> +#define IMX258_REG_FRM_LENGTH_LINES 0x0340
>> +#define IMX258_REG_FINE_INTEG_TIME 0x0200
>> +#define IMX258_REG_PLL_IVT_MPY 0x0306
>> +#define IMX258_REG_PLL_IOP_MPY 0x030e
>> +#define IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H 0x0820
>> +#define IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L 0x0822
>> +
>> +#define REG8(a, v) { a, v }
>> +#define REG16(a, v) { a, ((v) >> 8) & 0xff }, { (a) + 1, (v) & 0xff }
>
> The patch is nice but these macros are better replaced by the V4L2 CCI
> helper that also offers register access functions. Could you add a patch to
> convert the driver to use it (maybe after this one)?
>
Ohh perfect, using something else would be great. Ill go ahead and see
if I can get that working.
>> +
>> struct imx258_reg {
>> u16 address;
>> u8 val;
>> @@ -145,179 +190,139 @@ struct imx258_mode {
>> * lane data rate when using 2 lanes, thus allowing a maximum of 15fps.
>> */
>> static const struct imx258_reg mipi_1267mbps_19_2mhz_2l[] = {
>> - { 0x0136, 0x13 },
>> - { 0x0137, 0x33 },
>> - { 0x0301, 0x0A },
>> - { 0x0303, 0x02 },
>> - { 0x0305, 0x03 },
>> - { 0x0306, 0x00 },
>> - { 0x0307, 0xC6 },
>> - { 0x0309, 0x0A },
>> - { 0x030B, 0x01 },
>> - { 0x030D, 0x02 },
>> - { 0x030E, 0x00 },
>> - { 0x030F, 0xD8 },
>> - { 0x0310, 0x00 },
>> -
>> - { 0x0114, 0x01 },
>> - { 0x0820, 0x09 },
>> - { 0x0821, 0xa6 },
>> - { 0x0822, 0x66 },
>> - { 0x0823, 0x66 },
>> + REG16(IMX258_REG_EXCK_FREQ, 0x1333),
>> + REG8(IMX258_REG_IVTPXCK_DIV, 10),
>> + REG8(IMX258_REG_IVTSYCK_DIV, 2),
>> + REG8(IMX258_REG_PREPLLCK_VT_DIV, 3),
>> + REG16(IMX258_REG_PLL_IVT_MPY, 0x00C6),
>> + REG8(IMX258_REG_IOPPXCK_DIV, 10),
>> + REG8(IMX258_REG_IOPSYCK_DIV, 1),
>> + REG8(IMX258_REG_PREPLLCK_OP_DIV, 2),
>> + REG16(IMX258_REG_PLL_IOP_MPY, 0x00D8),
>> + REG8(IMX258_REG_PLL_MULT_DRIV, 0),
>> +
>> + REG8(IMX258_REG_CSI_LANE_MODE, 1),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H, 0x09A6),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L, 0x6666),
>> };
>>
>> static const struct imx258_reg mipi_1267mbps_19_2mhz_4l[] = {
>> - { 0x0136, 0x13 },
>> - { 0x0137, 0x33 },
>> - { 0x0301, 0x05 },
>> - { 0x0303, 0x02 },
>> - { 0x0305, 0x03 },
>> - { 0x0306, 0x00 },
>> - { 0x0307, 0xC6 },
>> - { 0x0309, 0x0A },
>> - { 0x030B, 0x01 },
>> - { 0x030D, 0x02 },
>> - { 0x030E, 0x00 },
>> - { 0x030F, 0xD8 },
>> - { 0x0310, 0x00 },
>> -
>> - { 0x0114, 0x03 },
>> - { 0x0820, 0x13 },
>> - { 0x0821, 0x4C },
>> - { 0x0822, 0xCC },
>> - { 0x0823, 0xCC },
>> + REG16(IMX258_REG_EXCK_FREQ, 0x1333),
>> + REG8(IMX258_REG_IVTPXCK_DIV, 5),
>> + REG8(IMX258_REG_IVTSYCK_DIV, 2),
>> + REG8(IMX258_REG_PREPLLCK_VT_DIV, 3),
>> + REG16(IMX258_REG_PLL_IVT_MPY, 0x00C6),
>> + REG8(IMX258_REG_IOPPXCK_DIV, 10),
>> + REG8(IMX258_REG_IOPSYCK_DIV, 1),
>> + REG8(IMX258_REG_PREPLLCK_OP_DIV, 2),
>> + REG16(IMX258_REG_PLL_IOP_MPY, 0x00D8),
>> + REG8(IMX258_REG_PLL_MULT_DRIV, 0),
>> +
>> + REG8(IMX258_REG_CSI_LANE_MODE, 3),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H, 0x134C),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L, 0xCCCC),
>> };
>>
>> static const struct imx258_reg mipi_1272mbps_24mhz_2l[] = {
>> - { 0x0136, 0x18 },
>> - { 0x0137, 0x00 },
>> - { 0x0301, 0x0a },
>> - { 0x0303, 0x02 },
>> - { 0x0305, 0x04 },
>> - { 0x0306, 0x00 },
>> - { 0x0307, 0xD4 },
>> - { 0x0309, 0x0A },
>> - { 0x030B, 0x01 },
>> - { 0x030D, 0x02 },
>> - { 0x030E, 0x00 },
>> - { 0x030F, 0xD8 },
>> - { 0x0310, 0x00 },
>> -
>> - { 0x0114, 0x01 },
>> - { 0x0820, 0x13 },
>> - { 0x0821, 0x4C },
>> - { 0x0822, 0xCC },
>> - { 0x0823, 0xCC },
>> + REG16(IMX258_REG_EXCK_FREQ, 0x1800),
>> + REG8(IMX258_REG_IVTPXCK_DIV, 10),
>> + REG8(IMX258_REG_IVTSYCK_DIV, 2),
>> + REG8(IMX258_REG_PREPLLCK_VT_DIV, 4),
>> + REG16(IMX258_REG_PLL_IVT_MPY, 0x00D4),
>> + REG8(IMX258_REG_IOPPXCK_DIV, 10),
>> + REG8(IMX258_REG_IOPSYCK_DIV, 1),
>> + REG8(IMX258_REG_PREPLLCK_OP_DIV, 2),
>> + REG16(IMX258_REG_PLL_IOP_MPY, 0x00D8),
>> + REG8(IMX258_REG_PLL_MULT_DRIV, 0),
>> +
>> + REG8(IMX258_REG_CSI_LANE_MODE, 1),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H, 0x134C),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L, 0xCCCC),
>> };
>>
>> static const struct imx258_reg mipi_1272mbps_24mhz_4l[] = {
>> - { 0x0136, 0x18 },
>> - { 0x0137, 0x00 },
>> - { 0x0301, 0x05 },
>> - { 0x0303, 0x02 },
>> - { 0x0305, 0x04 },
>> - { 0x0306, 0x00 },
>> - { 0x0307, 0xD4 },
>> - { 0x0309, 0x0A },
>> - { 0x030B, 0x01 },
>> - { 0x030D, 0x02 },
>> - { 0x030E, 0x00 },
>> - { 0x030F, 0xD8 },
>> - { 0x0310, 0x00 },
>> -
>> - { 0x0114, 0x03 },
>> - { 0x0820, 0x13 },
>> - { 0x0821, 0xE0 },
>> - { 0x0822, 0x00 },
>> - { 0x0823, 0x00 },
>> + REG16(IMX258_REG_EXCK_FREQ, 0x1800),
>> + REG8(IMX258_REG_IVTPXCK_DIV, 5),
>> + REG8(IMX258_REG_IVTSYCK_DIV, 2),
>> + REG8(IMX258_REG_PREPLLCK_VT_DIV, 4),
>> + REG16(IMX258_REG_PLL_IVT_MPY, 0x00D4),
>> + REG8(IMX258_REG_IOPPXCK_DIV, 10),
>> + REG8(IMX258_REG_IOPSYCK_DIV, 1),
>> + REG8(IMX258_REG_PREPLLCK_OP_DIV, 2),
>> + REG16(IMX258_REG_PLL_IOP_MPY, 0x00D8),
>> + REG8(IMX258_REG_PLL_MULT_DRIV, 0),
>> +
>> + REG8(IMX258_REG_CSI_LANE_MODE, 3),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H, 0x13E0),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L, 0x0000),
>> };
>>
>> static const struct imx258_reg mipi_640mbps_19_2mhz_2l[] = {
>> - { 0x0136, 0x13 },
>> - { 0x0137, 0x33 },
>> - { 0x0301, 0x05 },
>> - { 0x0303, 0x02 },
>> - { 0x0305, 0x03 },
>> - { 0x0306, 0x00 },
>> - { 0x0307, 0x64 },
>> - { 0x0309, 0x0A },
>> - { 0x030B, 0x01 },
>> - { 0x030D, 0x02 },
>> - { 0x030E, 0x00 },
>> - { 0x030F, 0xD8 },
>> - { 0x0310, 0x00 },
>> -
>> - { 0x0114, 0x01 },
>> - { 0x0820, 0x05 },
>> - { 0x0821, 0x00 },
>> - { 0x0822, 0x00 },
>> - { 0x0823, 0x00 },
>> + REG16(IMX258_REG_EXCK_FREQ, 0x1333),
>> + REG8(IMX258_REG_IVTPXCK_DIV, 5),
>> + REG8(IMX258_REG_IVTSYCK_DIV, 2),
>> + REG8(IMX258_REG_PREPLLCK_VT_DIV, 3),
>> + REG16(IMX258_REG_PLL_IVT_MPY, 0x0064),
>> + REG8(IMX258_REG_IOPPXCK_DIV, 10),
>> + REG8(IMX258_REG_IOPSYCK_DIV, 1),
>> + REG8(IMX258_REG_PREPLLCK_OP_DIV, 2),
>> + REG16(IMX258_REG_PLL_IOP_MPY, 0x00D8),
>> + REG8(IMX258_REG_PLL_MULT_DRIV, 0),
>> +
>> + REG8(IMX258_REG_CSI_LANE_MODE, 1),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H, 0x0500),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L, 0x0000),
>> };
>>
>> static const struct imx258_reg mipi_640mbps_19_2mhz_4l[] = {
>> - { 0x0136, 0x13 },
>> - { 0x0137, 0x33 },
>> - { 0x0301, 0x05 },
>> - { 0x0303, 0x02 },
>> - { 0x0305, 0x03 },
>> - { 0x0306, 0x00 },
>> - { 0x0307, 0x64 },
>> - { 0x0309, 0x0A },
>> - { 0x030B, 0x01 },
>> - { 0x030D, 0x02 },
>> - { 0x030E, 0x00 },
>> - { 0x030F, 0xD8 },
>> - { 0x0310, 0x00 },
>> -
>> - { 0x0114, 0x03 },
>> - { 0x0820, 0x0A },
>> - { 0x0821, 0x00 },
>> - { 0x0822, 0x00 },
>> - { 0x0823, 0x00 },
>> + REG16(IMX258_REG_EXCK_FREQ, 0x1333),
>> + REG8(IMX258_REG_IVTPXCK_DIV, 5),
>> + REG8(IMX258_REG_IVTSYCK_DIV, 2),
>> + REG8(IMX258_REG_PREPLLCK_VT_DIV, 3),
>> + REG16(IMX258_REG_PLL_IVT_MPY, 0x0064),
>> + REG8(IMX258_REG_IOPPXCK_DIV, 10),
>> + REG8(IMX258_REG_IOPSYCK_DIV, 1),
>> + REG8(IMX258_REG_PREPLLCK_OP_DIV, 2),
>> + REG16(IMX258_REG_PLL_IOP_MPY, 0x00D8),
>> + REG8(IMX258_REG_PLL_MULT_DRIV, 0),
>> +
>> + REG8(IMX258_REG_CSI_LANE_MODE, 3),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H, 0x0A00),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L, 0x0000),
>> };
>>
>> static const struct imx258_reg mipi_642mbps_24mhz_2l[] = {
>> - { 0x0136, 0x18 },
>> - { 0x0137, 0x00 },
>> - { 0x0301, 0x05 },
>> - { 0x0303, 0x02 },
>> - { 0x0305, 0x04 },
>> - { 0x0306, 0x00 },
>> - { 0x0307, 0x6B },
>> - { 0x0309, 0x0A },
>> - { 0x030B, 0x01 },
>> - { 0x030D, 0x02 },
>> - { 0x030E, 0x00 },
>> - { 0x030F, 0xD8 },
>> - { 0x0310, 0x00 },
>> -
>> - { 0x0114, 0x01 },
>> - { 0x0820, 0x0A },
>> - { 0x0821, 0x00 },
>> - { 0x0822, 0x00 },
>> - { 0x0823, 0x00 },
>> + REG16(IMX258_REG_EXCK_FREQ, 0x1800),
>> + REG8(IMX258_REG_IVTPXCK_DIV, 5),
>> + REG8(IMX258_REG_IVTSYCK_DIV, 2),
>> + REG8(IMX258_REG_PREPLLCK_VT_DIV, 4),
>> + REG16(IMX258_REG_PLL_IVT_MPY, 0x006B),
>> + REG8(IMX258_REG_IOPPXCK_DIV, 10),
>> + REG8(IMX258_REG_IOPSYCK_DIV, 1),
>> + REG8(IMX258_REG_PREPLLCK_OP_DIV, 2),
>> + REG16(IMX258_REG_PLL_IOP_MPY, 0x00D8),
>> + REG8(IMX258_REG_PLL_MULT_DRIV, 0),
>> +
>> + REG8(IMX258_REG_CSI_LANE_MODE, 1),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H, 0x0A00),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L, 0x0000),
>> };
>>
>> static const struct imx258_reg mipi_642mbps_24mhz_4l[] = {
>> - { 0x0136, 0x18 },
>> - { 0x0137, 0x00 },
>> - { 0x0301, 0x05 },
>> - { 0x0303, 0x02 },
>> - { 0x0305, 0x04 },
>> - { 0x0306, 0x00 },
>> - { 0x0307, 0x6B },
>> - { 0x0309, 0x0A },
>> - { 0x030B, 0x01 },
>> - { 0x030D, 0x02 },
>> - { 0x030E, 0x00 },
>> - { 0x030F, 0xD8 },
>> - { 0x0310, 0x00 },
>> -
>> - { 0x0114, 0x03 },
>> - { 0x0820, 0x0A },
>> - { 0x0821, 0x00 },
>> - { 0x0822, 0x00 },
>> - { 0x0823, 0x00 },
>> + REG16(IMX258_REG_EXCK_FREQ, 0x1800),
>> + REG8(IMX258_REG_IVTPXCK_DIV, 5),
>> + REG8(IMX258_REG_IVTSYCK_DIV, 2),
>> + REG8(IMX258_REG_PREPLLCK_VT_DIV, 4),
>> + REG16(IMX258_REG_PLL_IVT_MPY, 0x006B),
>> + REG8(IMX258_REG_IOPPXCK_DIV, 10),
>> + REG8(IMX258_REG_IOPSYCK_DIV, 1),
>> + REG8(IMX258_REG_PREPLLCK_OP_DIV, 2),
>> + REG16(IMX258_REG_PLL_IOP_MPY, 0x00D8),
>> + REG8(IMX258_REG_PLL_MULT_DRIV, 0),
>> +
>> + REG8(IMX258_REG_CSI_LANE_MODE, 3),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H, 0x0A00),
>> + REG16(IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L, 0x0000),
>> };
>>
>> static const struct imx258_reg mode_common_regs[] = {
>> @@ -363,45 +368,29 @@ static const struct imx258_reg mode_common_regs[] = {
>> { 0x7423, 0xD7 },
>> { 0x5F04, 0x00 },
>> { 0x5F05, 0xED },
>> - { 0x0112, 0x0A },
>> - { 0x0113, 0x0A },
>> - { 0x0342, 0x14 },
>> - { 0x0343, 0xE8 },
>> - { 0x0344, 0x00 },
>> - { 0x0345, 0x00 },
>> - { 0x0346, 0x00 },
>> - { 0x0347, 0x00 },
>> - { 0x0348, 0x10 },
>> - { 0x0349, 0x6F },
>> - { 0x034A, 0x0C },
>> - { 0x034B, 0x2F },
>> - { 0x0381, 0x01 },
>> - { 0x0383, 0x01 },
>> - { 0x0385, 0x01 },
>> - { 0x0387, 0x01 },
>> - { 0x0404, 0x00 },
>> - { 0x0408, 0x00 },
>> - { 0x0409, 0x00 },
>> - { 0x040A, 0x00 },
>> - { 0x040B, 0x00 },
>> - { 0x040C, 0x10 },
>> - { 0x040D, 0x70 },
>> - { 0x3038, 0x00 },
>> - { 0x303A, 0x00 },
>> - { 0x303B, 0x10 },
>> - { 0x300D, 0x00 },
>> - { 0x0350, 0x00 },
>> - { 0x0204, 0x00 },
>> - { 0x0205, 0x00 },
>> - { 0x020E, 0x01 },
>> - { 0x020F, 0x00 },
>> - { 0x0210, 0x01 },
>> - { 0x0211, 0x00 },
>> - { 0x0212, 0x01 },
>> - { 0x0213, 0x00 },
>> - { 0x0214, 0x01 },
>> - { 0x0215, 0x00 },
>> - { 0x7BCD, 0x00 },
>> + REG16(IMX258_REG_CSI_DT_FMT, 0x0a0a),
>> + REG16(IMX258_REG_LINE_LENGTH_PCK, 5352),
>> + REG16(IMX258_REG_X_ADD_STA, 0),
>> + REG16(IMX258_REG_Y_ADD_STA, 0),
>> + REG16(IMX258_REG_X_ADD_END, 4207),
>> + REG16(IMX258_REG_Y_ADD_END, 3119),
>> + REG8(IMX258_REG_X_EVN_INC, 1),
>> + REG8(IMX258_REG_X_ODD_INC, 1),
>> + REG8(IMX258_REG_Y_EVN_INC, 1),
>> + REG8(IMX258_REG_Y_ODD_INC, 1),
>> + REG16(IMX258_REG_DIG_CROP_X_OFFSET, 0),
>> + REG16(IMX258_REG_DIG_CROP_Y_OFFSET, 0),
>> + REG16(IMX258_REG_DIG_CROP_IMAGE_WIDTH, 4208),
>> + REG8(IMX258_REG_SCALE_MODE_EXT, 0),
>> + REG16(IMX258_REG_SCALE_M_EXT, 16),
>> + REG8(IMX258_REG_FORCE_FD_SUM, 0),
>> + REG8(IMX258_REG_FRM_LENGTH_CTL, 0),
>> + REG16(IMX258_REG_ANALOG_GAIN, 0),
>> + REG16(IMX258_REG_GR_DIGITAL_GAIN, 256),
>> + REG16(IMX258_REG_R_DIGITAL_GAIN, 256),
>> + REG16(IMX258_REG_B_DIGITAL_GAIN, 256),
>> + REG16(IMX258_REG_GB_DIGITAL_GAIN, 256),
>> + REG8(IMX258_REG_AF_WINDOW_MODE, 0),
>> { 0x94DC, 0x20 },
>> { 0x94DD, 0x20 },
>> { 0x94DE, 0x20 },
>> @@ -414,48 +403,39 @@ static const struct imx258_reg mode_common_regs[] = {
>> { 0x941B, 0x50 },
>> { 0x9519, 0x50 },
>> { 0x951B, 0x50 },
>> - { 0x3030, 0x00 },
>> - { 0x3032, 0x00 },
>> - { 0x0220, 0x00 },
>> + REG8(IMX258_REG_PHASE_PIX_OUTEN, 0),
>> + REG8(IMX258_REG_PDPIX_DATA_RATE, 0),
>> + REG8(IMX258_REG_HDR, 0),
>> };
>>
>> static const struct imx258_reg mode_4208x3120_regs[] = {
>> - { 0x0900, 0x00 },
>> - { 0x0901, 0x11 },
>> - { 0x0401, 0x00 },
>> - { 0x0405, 0x10 },
>> - { 0x040E, 0x0C },
>> - { 0x040F, 0x30 },
>> - { 0x034C, 0x10 },
>> - { 0x034D, 0x70 },
>> - { 0x034E, 0x0C },
>> - { 0x034F, 0x30 },
>> + REG8(IMX258_REG_BINNING_MODE, 0),
>> + REG8(IMX258_REG_BINNING_TYPE_V, 0x11),
>> + REG8(IMX258_REG_SCALE_MODE, 0),
>> + REG16(IMX258_REG_SCALE_M, 16),
>> + REG16(IMX258_REG_DIG_CROP_IMAGE_HEIGHT, 3120),
>> + REG16(IMX258_REG_X_OUT_SIZE, 4208),
>> + REG16(IMX258_REG_Y_OUT_SIZE, 3120),
>> };
>>
>> static const struct imx258_reg mode_2104_1560_regs[] = {
>> - { 0x0900, 0x01 },
>> - { 0x0901, 0x12 },
>> - { 0x0401, 0x01 },
>> - { 0x0405, 0x20 },
>> - { 0x040E, 0x06 },
>> - { 0x040F, 0x18 },
>> - { 0x034C, 0x08 },
>> - { 0x034D, 0x38 },
>> - { 0x034E, 0x06 },
>> - { 0x034F, 0x18 },
>> + REG8(IMX258_REG_BINNING_MODE, 1),
>> + REG8(IMX258_REG_BINNING_TYPE_V, 0x12),
>> + REG8(IMX258_REG_SCALE_MODE, 1),
>> + REG16(IMX258_REG_SCALE_M, 32),
>> + REG16(IMX258_REG_DIG_CROP_IMAGE_HEIGHT, 1560),
>> + REG16(IMX258_REG_X_OUT_SIZE, 2104),
>> + REG16(IMX258_REG_Y_OUT_SIZE, 1560),
>> };
>>
>> static const struct imx258_reg mode_1048_780_regs[] = {
>> - { 0x0900, 0x01 },
>> - { 0x0901, 0x14 },
>> - { 0x0401, 0x01 },
>> - { 0x0405, 0x40 },
>> - { 0x040E, 0x03 },
>> - { 0x040F, 0x0C },
>> - { 0x034C, 0x04 },
>> - { 0x034D, 0x18 },
>> - { 0x034E, 0x03 },
>> - { 0x034F, 0x0C },
>> + REG8(IMX258_REG_BINNING_MODE, 1),
>> + REG8(IMX258_REG_BINNING_TYPE_V, 0x14),
>> + REG8(IMX258_REG_SCALE_MODE, 1),
>> + REG16(IMX258_REG_SCALE_M, 64),
>> + REG16(IMX258_REG_DIG_CROP_IMAGE_HEIGHT, 780),
>> + REG16(IMX258_REG_X_OUT_SIZE, 1048),
>> + REG16(IMX258_REG_Y_OUT_SIZE, 780),
>> };
>>
>> struct imx258_variant_cfg {
>> @@ -923,7 +903,7 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
>> }
>> break;
>> case V4L2_CID_VBLANK:
>> - ret = imx258_write_reg(imx258, IMX258_REG_VTS,
>> + ret = imx258_write_reg(imx258, IMX258_REG_FRM_LENGTH_LINES,
>> IMX258_REG_VALUE_16BIT,
>> imx258->cur_mode->height + ctrl->val);
>> break;
>
^ permalink raw reply
* Re: [PATCH v3 22/25] dt-bindings: media: imx258: Add binding for powerdown-gpio
From: Luigi311 @ 2024-04-03 19:26 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel, Ondrej Jirman
In-Reply-To: <Zg2kn5/5T9ukP4nd@duo.ucw.cz>
On 4/3/24 12:49, Pavel Machek wrote:
> Hi!
>
>> From: Luis Garcia <git@luigi311.com>
>>
>> Add powerdown-gpio binding as it is required for some boards
>
> "." at end of sentence.
>
>> Signed-off-by: Ondrej Jirman <megi@xff.cz>
>> Signed-off-by: Luis Garcia <git@luigi311.com>
>
> If the patch is from Ondrej, he should be in From:, I believe.
>
> Best regards,
> Pavel
Ohh your right, this was broken out from another patch and didn't
set it to be his actual commit same with the other ones. They
were based on his downstream changes and just modified to match
up with what Dave had set the values too. I'll set it to him
for the next revision. Thanks!
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display: bridge: add the Hot-plug MIPI DSI connector
From: Luca Ceresoli @ 2024-04-03 19:33 UTC (permalink / raw)
To: Rob Herring
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, David Airlie, Daniel Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Krzysztof Kozlowski, Conor Dooley, Paul Kocialkowski,
Hervé Codina, Thomas Petazzoni, dri-devel, devicetree,
linux-kernel, Paul Kocialkowski, Wolfram Sang
In-Reply-To: <20240327160908.GA3460963-robh@kernel.org>
Hello Rob,
[+Cc Wolfram for the I2C discussion below]
thanks for your feedback.
On Wed, 27 Mar 2024 11:09:08 -0500
Rob Herring <robh@kernel.org> wrote:
> On Tue, Mar 26, 2024 at 05:28:11PM +0100, Luca Ceresoli wrote:
> > Add bindings for a physical, hot-pluggable connector allowing the far end
> > of a MIPI DSI bus to be connected and disconnected at runtime.
> >
> > Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> > ---
> > .../bridge/hotplug-video-connector-dsi.yaml | 87 ++++++++++++++++++++++
> > MAINTAINERS | 5 ++
> > 2 files changed, 92 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml
> > new file mode 100644
> > index 000000000000..05beb8aa9ab4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml
> > @@ -0,0 +1,87 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/hotplug-video-connector-dsi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Hot-pluggable connector on a MIPI DSI bus
> > +
> > +maintainers:
> > + - Luca Ceresoli <luca.ceresoli@bootlin.com>
> > +
> > +description:
> > + A bridge representing a physical, hot-pluggable connector on a MIPI DSI
> > + video bus. The connector splits the video pipeline in a fixed part and a
> > + removable part.
> > +
> > + The fixed part of the video pipeline includes all components up to the
> > + display controller and 0 or more bridges. The removable part includes one
> > + or more bridges and any other components up to the panel.
> > +
> > + The removable part of the pipeline can be physically disconnected at any
> > + moment, making all of its components not usable anymore. The same or a
> > + different removable part of the pipeline can be reconnected later on.
> > +
> > + Note that the hotplug-video-connector does not describe video busses
> > + having native hotplug capabilities in the hardware, such as HDMI.
> > +
> > +properties:
> > + compatible:
> > + const: hotplug-video-connector-dsi
>
> Got a spec for this connector? How do I know if I have one or not?
>
> The problem here is what else is on this connector? GPIO controls,
> power rails, etc.?
>
> If this is some kind of standard connector, then we need to be able to
> remap everything on the connector not just DSI signals. And for that,
> it's not just DSI signals, so I'd say we would need some sort of generic
> graph remapping that the core graph code handles transparently.
>
> If it is not standard, then you don't need any remapping and can just
> use an overlay that connects the ports directly.
This is not a standardized connector. And it couldn't be: to the best of
my knowledge no standard removable MIPI DSI connector exists at all.
This whole work is unavoidably breaking some long-standing assumptions
and opening some new challenges: giving a proper DT description to
runtime-pluggable hardware and breaking the dogma that a DRM pipeline
is not removable, to name some. So I think it's better to take a step
back and describe the big picture.
As mentioned in the cover letter ("Development roadmap" section),
together with Hervé we are working on a set of patches to allow this
sort of removable hardware to be handled properly by the Linux kernel.
From the cover letter:
> The use case we are working on is to support professional products that
> have a portable "main" part running on battery, with the main SoC and able
> to work autonomously with limited features, and that can be connected to an
> "add-on" part that is not portable and adds more features.
The add-on gets connected via a connector that is not standardized.
There is a well-defined part number for the mechanical connector, but
the pin usage is custom for the product. Connector pins include:
* I2C lines to access various chips on the add-on
- one of these chips is an EEPROM with the add-on product ID
* Some pins to report to the CPU whether the add-on is connected and
add-on power rails are stable (these are wired to SoC GPIOs)
* An interrupt line collecting IRQs from the add-on chips
* MIPI DSI to drive a panel on the add-on
* Gigabit Ethernet (4 pairs)
* USB lines
* A few more accessory pins
Some of these are not problematic: USB is hot-pluggable and
auto-discoverable by nature, Ethernet pins are just connected directly
to the RJ-45 connector so the add-on acts as an Ethernet or USB cable.
For everything else there is going to be a separate patch series
with code to detect add-on connection, read the ID, identify the
appropriate DT overlay and load it, and unload it on disconnection.
Before that, it's good to discuss how the device tree should describe
the whole hardware described above, in these terms:
1. Should device tree describe the connector?
2. If it does, how should the various busses on the connector
(especially I2C and MIPI DSI) be described and associated to the
connector?
To address question 1, I think we _do_ need to describe the connector
itself, because it is a part of the non-discoverable hardware that the
software needs to manage. Among others we need software to know which
GPIOs report the connection and power good statuses, and to know how to
locate the ID EEPROM.
Regarding question 2 I think there are a few open possibilities, and
I must admit the example provided in this series is just too simplistic
to be adequate. Apologies, this series is mostly aiming at discussing
the DRM implementation aspects.
Let me try a more realistic DT description that allows to:
1. associate the various busses to the connector they go through
2. map components of different base board models to the connector pins
3. map components of different add-on models to the connector pins
The 2nd and 3rd items allow decoupling the base and add-on hardware so
that different base board models and different add-on models can be
mixed in all combinations if they use the same connector pinout. This
obviously resembles the Beaglebone capes and RPi hats use case.
My draft proposal is as follows:
---------------------- [my-product.dts] ----------------------
/ {
// [0]
my_hotplug_connector: my-hotplug-connector {
compatible = "vendor-abc,product-xyz-connector";
// [1]
plugged-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
powergood-gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
// [5]
hotplug_dsi_bus: hotplug-dsi-video-bus@0 {
port@0 {
reg = <0>;
hotplug_dsi_in: endpoint {
remote-endpoint = <&bridge1>;
};
};
port@1 {
reg = <1>;
hotplug_dsi_out: endpoint {
// remote-endpoint to be added by overlay
};
};
};
// [3]
// Map "placeholder" i2cA to "physical" i2c3
i2cA: hotplug-i2c-bus@A {
hotplug-connector,base-bus = <&i2c3>;
};
i2cB: hotplug-i2c-bus@B {
hotplug-connector,base-bus = <&i2c5>;
};
};
};
// Video bridge or display controller on the base board
&bridge1 {
ports {
port@1 {
bridge1_out: endpoint {
remote-endpoint = <&hotplug_dsi_in>;
};
};
};
};
--------------------------------------------------------------
------------------- [my-add-on-common.dtso] ------------------
// [2]
&my_hotplug_connector {
nvmem-cells = <addon_id>;
nvmem-cell-names = "id";
};
// [4]
// i2cA is a "placeholder" name, mapped by the connector
// definition on the base dts to a physical bus on the base board
&i2cA {
eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
nvmem-layout {
compatible = "fixed-layout";
#address-cells = <1>;
#size-cells = <1>;
addon_id: addon-id@10 {
reg = <0x10 0x4>;
};
};
};
};
--------------------------------------------------------------
----------------- [my-add-on-model-xyz.dtso] -----------------
// [6]
&hotplug_dsi_out {
remote-endpoint = <&bridge2_in>; // Fill in the missing piece
};
&{/}
{
panel {
compatible = ...;
ports {
port@0 {
reg = <0>;
panel_in: endpoint {
remote-endpoint = <&bridge2_out>;
};
};
};
};
};
&i2cB {
// Video bridge chip on the add-on
bridge@22 {
// ... compatible, other props/nodes ...
ports {
port@0 {
bridge2_in: endpoint {
remote-endpoint = <&hotplug_dsi_out>;
};
};
port@1 {
bridge2_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
};
};
--------------------------------------------------------------
The connector itself [0] is described under the root node because it is
not on any addressable bus, similarly to "sound" and "panel" nodes. I
don't think connectors addressable over I2C or other addressable busses
are going to appear in the forseeable future, but if they did they
could be represented as such in the device tree as well.
The connector GPIOs [1] allow the CPU to know the connection and "power
good" status of the connector. On the implementation side, those are the
inputs triggering overlay loading and unloading.
There is a "common" overlay which describes the common components of
all add-ons at least up to the NVMEM cell [2] holding the add-on ID
that is needed to load the model-specific overlay. This overlay adds
nvmem properties to the hotplug connector node to point to the specific
NVMEM cell. The nvmem-cells and nvmem-cell-names = "id" properties need
to be part of the hotplug-connector bindings.
The "placeholder" hotplug-i2c-bus nodes in the connector node [3] allow
decoupling the I2C bus segment on the base board from the segment on
the add-on. They point to the base bus controller phandle via
hotplug-connector,base-bus, and allow the overlay to use the
"placeholder" [4] instead of naming the "base" I2C bus name. This
allows using the same add-on and overlay on a different base board,
which could even have a totally different SoC, and where the same
connector pins are not wired to the SoC i2c3 but to e.g. i2c4.
In other words:
* [3] means connector pins X and Y are wired to i2c3 on this base board
* [4] means connector pins X and Y are wired to i2cA on this add-on
The specific pins X and Y are not described. Only the bus going through
the connector is.
This can be implemented in the I2C code similarly to a 1-port i2c-mux,
even though it might have an even better ad-hoc implementation that
avoids any unneeded overhead from the mux code, as we are not muxing
anything here, just "connecting wires". Whatever the implementation,
what it needs to do is ensure that i2cA and i2cB appear as regular I2C
busses to their subnodes (e.g. eeprom@50), and when drivers for those
subnodes try to probe they attach to the correct bus (i2c3, i2c5) in
some way -- anything else is an implementation detail. Let's call this
the "I2C decoupler driver".
Once the "common" overlay is loaded, software can read the add-on ID
from NVMEM and find out the overlay that describes the specific add-on
model, see my-add-on-model-xyz.dtso above. This other overlay needs to
be loaded and will populate all the remaining add-on hardware, possibly
using nodes from the first overlay (e.g. a regulator that is used both
by the eeprom@50 and by nodes in the 2nd overlay).
Now to the video bus. Back to the main dts, the hotplug-dsi-video-bus@0
node [5] describes the video pipeline up to the "main" board side of
the connector, represented by port@0. port@1 represents the beginning
of the add-on side of the pipeline, and as such it has no
remote-endpoint because no hardware is present before hotplug and anyway
which hardware will be connected is unknown.
Note DSI is used in the example, but it could as well be LVDS or
parallel video.
The model-specific overlay describes the continuation of the pipeline
up to the panel _and_ fills in the remote-endpoint of &hotplug_dsi_out
to connect the two segments. Just like the i2c example, the overlays
never refer to base board components: it only refers to what appears in
the hotplug connector definition node [0].
An alternative design is that the entire port@1 node is missing from the
hotplug-dsi-video-bus@0 node and is entirely added by the overlay. No
strong opinion on this, the example shows what is tested, but I think
either will be fine.
On the implementation side, the hotplug-dsi-video-bus@0 node does
materialize as the hotplug-bridge driver (patch 4 of this series). The
hotplug-bridge sits in the middle of a previous bridge and the first
bridge in the add-on to let each of them probe normally, and then
passes calls through as transparently as possible.
Still about the implementation, in this example there are 3 main
components that need an implementation:
1. the hotplug-connector driver for /my-hotplug-connector [0]
2. the I2C decoupler driver (possibly based on i2c-mux)
3. the hotplug-bridge driver (this series)
The hotplug-connector driver is responsible for monitoring the
status GPIOs, load the 1st overlay, read the NVMEM ID, load the 2nd
overlay. But it is also in charge of instantiating the "decoupling"
driver for hotplug-i2c-bus nodes [1] and hotplug-dsi-video-bus nodes
[3].
Generalizing the idea to other busses such as SPI should be quite
trivial.
This device tree representation is possibly complicated and verbose.
However I cannot think of a simpler one that can describe a connector
to a removable hardware without losing the ability of decoupling the
base hardware from the add-on hardware.
Your opinion on this will be very appreciated.
Best regards,
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 23/25] drivers: media: i2c: imx258: Add support for powerdown gpio
From: Luigi311 @ 2024-04-03 19:34 UTC (permalink / raw)
To: Ondřej Jirman, Sakari Ailus, linux-media, dave.stevenson,
jacopo.mondi, mchehab, robh, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, devicetree, imx,
linux-arm-kernel, linux-kernel, pavel, phone-devel
In-Reply-To: <wjlcde7yoooygj4hhdmiwrdloh6l4p6i2qbmjek5uwsifyzwgu@xjhutvmsdfou>
On 4/3/24 10:57, Ondřej Jirman wrote:
> Hi Sakari and Luis,
>
> On Wed, Apr 03, 2024 at 04:25:41PM GMT, Sakari Ailus wrote:
>> Hi Luis, Ondrej,
>>
>> On Wed, Apr 03, 2024 at 09:03:52AM -0600, git@luigi311.com wrote:
>>> From: Luis Garcia <git@luigi311.com>
>>>
>>> On some boards powerdown signal needs to be deasserted for this
>>> sensor to be enabled.
>>>
>>> Signed-off-by: Ondrej Jirman <megi@xff.cz>
>>> Signed-off-by: Luis Garcia <git@luigi311.com>
>>> ---
>>> drivers/media/i2c/imx258.c | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
>>> index 30352c33f63c..163f04f6f954 100644
>>> --- a/drivers/media/i2c/imx258.c
>>> +++ b/drivers/media/i2c/imx258.c
>>> @@ -679,6 +679,8 @@ struct imx258 {
>>> unsigned int lane_mode_idx;
>>> unsigned int csi2_flags;
>>>
>>> + struct gpio_desc *powerdown_gpio;
>>> +
>>> /*
>>> * Mutex for serialized access:
>>> * Protect sensor module set pad format and start/stop streaming safely.
>>> @@ -1213,6 +1215,8 @@ static int imx258_power_on(struct device *dev)
>>> struct imx258 *imx258 = to_imx258(sd);
>>> int ret;
>>>
>>> + gpiod_set_value_cansleep(imx258->powerdown_gpio, 0);
>>
>> What does the spec say? Should this really happen before switching on the
>> supplies below?
>
> There's no powerdown input in the IMX258 manual. The manual only mentions
> that XCLR (reset) should be held low during power on.
>
> https://megous.com/dl/tmp/15b0992a720ab82d.png
>
> https://megous.com/dl/tmp/f2cc991046d97641.png
>
> This sensor doesn’t have a built-in “Power ON Reset” function. The XCLR pin
> is set to “LOW” and the power supplies are brought up. Then the XCLR pin
> should be set to “High” after INCK supplied.
>
> So this input is some feature on camera module itself outside of the
> IMX258 chip, which I think is used to gate power to the module. Eg. on Pinephone
> Pro, there are two modules with shared power rails, so enabling supply to
> one module enables it to the other one, too. So this input becomes the only way
> to really enable/disable power to the chip when both are used at once at some
> point, because regulator_bulk_enable/disable becomes ineffective at that point.
>
> Luis, maybe you saw some other datasheet that mentions this input? IMO,
> it just gates the power rails via some mosfets on the module itself, since
> there's not power down input to the chip itself.
>
> kind regards,
> o.
>
Ondrej, I did not see anything else in the datasheet since I'm pretty sure
I'm looking at the same datasheet as it was supplied to me by Pine64. I'm
not sure what datasheet Dave has access to since he got his for a
completely different module than what we are testing with though.
>>> +
>>> ret = regulator_bulk_enable(IMX258_NUM_SUPPLIES,
>>> imx258->supplies);
>>> if (ret) {
>>> @@ -1224,6 +1228,7 @@ static int imx258_power_on(struct device *dev)
>>> ret = clk_prepare_enable(imx258->clk);
>>> if (ret) {
>>> dev_err(dev, "failed to enable clock\n");
>>> + gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
>>> regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
>>> }
>>>
>>> @@ -1238,6 +1243,8 @@ static int imx258_power_off(struct device *dev)
>>> clk_disable_unprepare(imx258->clk);
>>> regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
>>>
>>> + gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -1541,6 +1548,12 @@ static int imx258_probe(struct i2c_client *client)
>>> if (!imx258->variant_cfg)
>>> imx258->variant_cfg = &imx258_cfg;
>>>
>>> + /* request optional power down pin */
>>> + imx258->powerdown_gpio = devm_gpiod_get_optional(&client->dev, "powerdown",
>>> + GPIOD_OUT_HIGH);
>>> + if (IS_ERR(imx258->powerdown_gpio))
>>> + return PTR_ERR(imx258->powerdown_gpio);
>>> +
>>> /* Initialize subdev */
>>> v4l2_i2c_subdev_init(&imx258->sd, client, &imx258_subdev_ops);
>>>
>>
>> --
>> Regards,
>>
>> Sakari Ailus
^ permalink raw reply
* [PATCH] arm64: dts: imx8m/qxp: Pass the tcpci compatible
From: Fabio Estevam @ 2024-04-03 19:40 UTC (permalink / raw)
To: shawnguo
Cc: robh, krzk+dt, conor+dt, devicetree, linux-arm-kernel,
Fabio Estevam
From: Fabio Estevam <festevam@denx.de>
Per nxp,ptn5110.yaml, also pass the fallback "tcpci" compatible
to fix the following dt-schema warning:
usb-typec@50: compatible: ['nxp,ptn5110'] is too short
from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts | 2 +-
arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts | 2 +-
arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts | 2 +-
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index 888070b8b287..90d1901df2b1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -395,7 +395,7 @@ adv7535_out: endpoint {
};
ptn5110: tcpc@50 {
- compatible = "nxp,ptn5110";
+ compatible = "nxp,ptn5110", "tcpci";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec1>;
reg = <0x50>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
index 690da24a4335..9e0259ddf4bc 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
@@ -244,7 +244,7 @@ adv7535_out: endpoint {
};
ptn5110: tcpc@50 {
- compatible = "nxp,ptn5110";
+ compatible = "nxp,ptn5110", "tcpci";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec1>;
reg = <0x50>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
index a08057410bde..e5d3901f2913 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
@@ -340,7 +340,7 @@ pcieclk: clock-generator@68 {
&i2c3 {
/* Connected to USB Hub */
usb-typec@52 {
- compatible = "nxp,ptn5110";
+ compatible = "nxp,ptn5110", "tcpci";
reg = <0x52>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
index 366693f31992..e92b5d5a66b5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
@@ -42,7 +42,7 @@ &i2c2 {
status = "okay";
typec_ptn5100: usb-typec@50 {
- compatible = "nxp,ptn5110";
+ compatible = "nxp,ptn5110", "tcpci";
reg = <0x50>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts b/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
index 8055a2c23035..b268ba7a0e12 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
@@ -429,7 +429,7 @@ ldo7_reg: LDO7 {
};
typec_ptn5100: usb-typec@52 {
- compatible = "nxp,ptn5110";
+ compatible = "nxp,ptn5110", "tcpci";
reg = <0x52>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec>;
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 8360bb851ac0..83d298c2bfd3 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -149,7 +149,7 @@ light-sensor@44 {
};
ptn5110: tcpc@50 {
- compatible = "nxp,ptn5110";
+ compatible = "nxp,ptn5110", "tcpci";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec>;
reg = <0x50>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 24/25] drivers: media: i2c: imx258: Add support for reset gpio
From: Luigi311 @ 2024-04-03 19:48 UTC (permalink / raw)
To: Ondřej Jirman, Sakari Ailus, linux-media, dave.stevenson,
jacopo.mondi, mchehab, robh, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, devicetree, imx,
linux-arm-kernel, linux-kernel, pavel, phone-devel
In-Reply-To: <vesqdx7w2sobjnx7tmk6s6i5zplbhsphamoalysx625r4aqffq@hos5otov5ids>
On 4/3/24 11:03, Ondřej Jirman wrote:
> Hi,
>
> On Wed, Apr 03, 2024 at 04:28:59PM GMT, Sakari Ailus wrote:
>> Hi Luis,
>>
>> Could you unify the subject prefix for the driver patches, please? E.g.
>> "media: imx258: " would be fine.
>>
>> On Wed, Apr 03, 2024 at 09:03:53AM -0600, git@luigi311.com wrote:
>>> From: Luis Garcia <git@luigi311.com>
>>>
>>> It was documented in DT, but not implemented.
>>>
>>> Signed-off-by: Ondrej Jirman <megous@megous.com>
>>> Signed-off-by: Luis Garcia <git@luigi311.com>
>>> ---
>>> drivers/media/i2c/imx258.c | 14 +++++++++++++-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
>>> index 163f04f6f954..4c117c4829f1 100644
>>> --- a/drivers/media/i2c/imx258.c
>>> +++ b/drivers/media/i2c/imx258.c
>>> @@ -680,6 +680,7 @@ struct imx258 {
>>> unsigned int csi2_flags;
>>>
>>> struct gpio_desc *powerdown_gpio;
>>> + struct gpio_desc *reset_gpio;
>>>
>>> /*
>>> * Mutex for serialized access:
>>> @@ -1232,7 +1233,11 @@ static int imx258_power_on(struct device *dev)
>>> regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
>>> }
>>>
>>> - return ret;
>>> + gpiod_set_value_cansleep(imx258->reset_gpio, 0);
>>> +
>>> + usleep_range(400, 500);
>>
>> You could mention this at least in the commit message.
>
> This is T6 in the datasheet: https://megous.com/dl/tmp/92c9223ce877216e.png
>
>
>>> +
>>> + return 0;
>>> }
>>>
>>> static int imx258_power_off(struct device *dev)
>>> @@ -1243,6 +1248,7 @@ static int imx258_power_off(struct device *dev)
>>> clk_disable_unprepare(imx258->clk);
>>> regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
>>>
>>> + gpiod_set_value_cansleep(imx258->reset_gpio, 1);
>>
>> Same question than on the other GPIO: does this belong here?
>
> No, this should be before the regulator_bulk_disable.
>
> See: https://megous.com/dl/tmp/c96180b23d7ce63a.png
>
> kind regards,
> o.
>
Since I'm supposed to move the reset up should I also
move the power up with it to match your downstream
driver?
>>> gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
>>>
>>> return 0;
>>> @@ -1554,6 +1560,12 @@ static int imx258_probe(struct i2c_client *client)
>>> if (IS_ERR(imx258->powerdown_gpio))
>>> return PTR_ERR(imx258->powerdown_gpio);
>>>
>>> + /* request optional reset pin */
>>> + imx258->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
>>> + GPIOD_OUT_HIGH);
>>> + if (IS_ERR(imx258->reset_gpio))
>>> + return PTR_ERR(imx258->reset_gpio);
>>> +
>>> /* Initialize subdev */
>>> v4l2_i2c_subdev_init(&imx258->sd, client, &imx258_subdev_ops);
>>>
>>
>> --
>> Regards,
>>
>> Sakari Ailus
^ permalink raw reply
* [PATCH v2 0/5] Add IAX45 support for RZ/Five SoC
From: Prabhakar @ 2024-04-03 20:34 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: linux-kernel, devicetree, linux-renesas-soc, linux-riscv,
Prabhakar, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi All,
The IAX45 block on RZ/Five SoC is almost identical to the IRQC bock found
on the RZ/G2L family of SoCs.
IAX45 performs various interrupt controls including synchronization for the
external interrupts of NMI, IRQ, and GPIOINT and the interrupts of the
built-in peripheral interrupts output by each module. And it notifies the
interrupt to the PLIC.
- Select 32 TINT from 82 GPIOINT.
- Integration of bus error interrupts from system bus.
- Integration of ECC error interrupts from On-chip RAM.
- Indicate interrupt status. (NMI, IRQ, TINT, integrated bus error interrupt
and integrated ECC error interrupt)
- Setting of interrupt detection method. (NMI, IRQ and TINT)
- All interrupts are masked by INTMASK.
- Mask function for NMI, IRQ and TINT
This patch series adds support for IAX45 in the IRQC driver and enables this
on RZ/Five SoC.
v1: https://patchwork.kernel.org/project/linux-renesas-soc/cover/20240129151618.90922-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
Cheers,
Prabhakar
Lad Prabhakar (5):
dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Document
RZ/Five SoC
irqchip/renesas-rzg2l: Add support for RZ/Five SoC
riscv: dts: renesas: r9a07g043f: Add IRQC node to RZ/Five SoC DTSI
arm64: dts: renesas: r9a07g043: Move interrupt-parent property to
common DTSI
riscv: dts: renesas: rzfive-smarc-som: Drop deleting interrupt
properties from ETH0/1 nodes
.../renesas,rzg2l-irqc.yaml | 17 ++-
arch/arm64/boot/dts/renesas/r9a07g043.dtsi | 1 +
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 4 -
arch/riscv/boot/dts/renesas/r9a07g043f.dtsi | 75 ++++++++++
.../boot/dts/renesas/rzfive-smarc-som.dtsi | 16 --
drivers/irqchip/irq-renesas-rzg2l.c | 137 +++++++++++++++++-
6 files changed, 218 insertions(+), 32 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Document RZ/Five SoC
From: Prabhakar @ 2024-04-03 20:34 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: linux-kernel, devicetree, linux-renesas-soc, linux-riscv,
Prabhakar, Lad Prabhakar
In-Reply-To: <20240403203503.634465-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Document RZ/Five (R9A07G043F) IRQC bindings. The IRQC block on the RZ/Five
SoC is almost identical to the one found on the RZ/G2L SoC, with the only
difference being that it has additional mask control registers for
NMI/IRQ/TINT.
Hence new compatible string "renesas,r9a07g043f-irqc" is added for RZ/Five
SoC.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2
- Dropped the checks for interrupts as its already handled
- Added SoC specific compat string
---
.../renesas,rzg2l-irqc.yaml | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
index daef4ee06f4e..2a871cbf6f87 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
@@ -21,13 +21,16 @@ description: |
properties:
compatible:
- items:
- - enum:
- - renesas,r9a07g043u-irqc # RZ/G2UL
- - renesas,r9a07g044-irqc # RZ/G2{L,LC}
- - renesas,r9a07g054-irqc # RZ/V2L
- - renesas,r9a08g045-irqc # RZ/G3S
- - const: renesas,rzg2l-irqc
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a07g043u-irqc # RZ/G2UL
+ - renesas,r9a07g044-irqc # RZ/G2{L,LC}
+ - renesas,r9a07g054-irqc # RZ/V2L
+ - renesas,r9a08g045-irqc # RZ/G3S
+ - const: renesas,rzg2l-irqc
+ - items:
+ - const: renesas,r9a07g043f-irqc # RZ/Five
'#interrupt-cells':
description: The first cell should contain a macro RZG2L_{NMI,IRQX} included in the
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/5] irqchip/renesas-rzg2l: Add support for RZ/Five SoC
From: Prabhakar @ 2024-04-03 20:35 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: linux-kernel, devicetree, linux-renesas-soc, linux-riscv,
Prabhakar, Lad Prabhakar
In-Reply-To: <20240403203503.634465-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
The IX45 block has additional mask registers (NMSK/IMSK/TMSK) as compared
to the RZ/G2L (family) SoC.
Introduce masking/unmasking support for IRQ and TINT interrupts in IRQC
controller driver. Two new registers, IMSK and TMSK, are defined to
handle masking on RZ/Five SoC. The implementation utilizes a new data
structure, `struct rzg2l_irqc_data`, to determine mask support for a
specific controller instance.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2
- Added IRQCHIP_MATCH() for RZ/Five
- Retaining a copy of OF data in priv
- Rebased the changes
---
drivers/irqchip/irq-renesas-rzg2l.c | 137 +++++++++++++++++++++++++++-
1 file changed, 132 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-renesas-rzg2l.c b/drivers/irqchip/irq-renesas-rzg2l.c
index f6484bf15e0b..6fa8d65605dc 100644
--- a/drivers/irqchip/irq-renesas-rzg2l.c
+++ b/drivers/irqchip/irq-renesas-rzg2l.c
@@ -37,6 +37,8 @@
#define TSSEL_SHIFT(n) (8 * (n))
#define TSSEL_MASK GENMASK(7, 0)
#define IRQ_MASK 0x3
+#define IMSK 0x10010
+#define TMSK 0x10020
#define TSSR_OFFSET(n) ((n) % 4)
#define TSSR_INDEX(n) ((n) / 4)
@@ -66,15 +68,25 @@ struct rzg2l_irqc_reg_cache {
u32 titsr[2];
};
+/**
+ * struct rzg2l_irqc_of_data - OF data structure
+ * @mask_supported: Indicates if mask registers are available
+ */
+struct rzg2l_irqc_of_data {
+ bool mask_supported;
+};
+
/**
* struct rzg2l_irqc_priv - IRQ controller private data structure
* @base: Controller's base address
+ * @data: OF data pointer
* @fwspec: IRQ firmware specific data
* @lock: Lock to serialize access to hardware registers
* @cache: Registers cache for suspend/resume
*/
static struct rzg2l_irqc_priv {
void __iomem *base;
+ const struct rzg2l_irqc_of_data *data;
struct irq_fwspec fwspec[IRQC_NUM_IRQ];
raw_spinlock_t lock;
struct rzg2l_irqc_reg_cache cache;
@@ -138,18 +150,102 @@ static void rzg2l_irqc_eoi(struct irq_data *d)
irq_chip_eoi_parent(d);
}
+static void rzg2l_irqc_mask_irq_interrupt(struct rzg2l_irqc_priv *priv,
+ unsigned int hwirq)
+{
+ u32 imsk = readl_relaxed(priv->base + IMSK);
+ u32 bit = BIT(hwirq - IRQC_IRQ_START);
+
+ writel_relaxed(imsk | bit, priv->base + IMSK);
+}
+
+static void rzg2l_irqc_unmask_irq_interrupt(struct rzg2l_irqc_priv *priv,
+ unsigned int hwirq)
+{
+ u32 imsk = readl_relaxed(priv->base + IMSK);
+ u32 bit = BIT(hwirq - IRQC_IRQ_START);
+
+ writel_relaxed(imsk & ~bit, priv->base + IMSK);
+}
+
+static void rzg2l_irqc_mask_tint_interrupt(struct rzg2l_irqc_priv *priv,
+ unsigned int hwirq)
+{
+ u32 tmsk = readl_relaxed(priv->base + TMSK);
+ u32 bit = BIT(hwirq - IRQC_TINT_START);
+
+ writel_relaxed(tmsk | bit, priv->base + TMSK);
+}
+
+static void rzg2l_irqc_unmask_tint_interrupt(struct rzg2l_irqc_priv *priv,
+ unsigned int hwirq)
+{
+ u32 tmsk = readl_relaxed(priv->base + TMSK);
+ u32 bit = BIT(hwirq - IRQC_TINT_START);
+
+ writel_relaxed(tmsk & ~bit, priv->base + TMSK);
+}
+
+/* Must be called while priv->lock is held */
+static void rzg2l_irqc_mask_once(struct rzg2l_irqc_priv *priv, unsigned int hwirq)
+{
+ if (!priv->data->mask_supported)
+ return;
+
+ if (hwirq >= IRQC_IRQ_START && hwirq <= IRQC_IRQ_COUNT)
+ rzg2l_irqc_mask_irq_interrupt(priv, hwirq);
+ else if (hwirq >= IRQC_TINT_START && hwirq < IRQC_NUM_IRQ)
+ rzg2l_irqc_mask_tint_interrupt(priv, hwirq);
+}
+
+static void rzg2l_irqc_mask(struct irq_data *d)
+{
+ struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
+
+ raw_spin_lock(&priv->lock);
+ rzg2l_irqc_mask_once(priv, irqd_to_hwirq(d));
+ raw_spin_unlock(&priv->lock);
+ irq_chip_mask_parent(d);
+}
+
+/* Must be called while priv->lock is held */
+static void rzg2l_irqc_unmask_once(struct rzg2l_irqc_priv *priv, unsigned int hwirq)
+{
+ if (!priv->data->mask_supported)
+ return;
+
+ if (hwirq >= IRQC_IRQ_START && hwirq <= IRQC_IRQ_COUNT)
+ rzg2l_irqc_unmask_irq_interrupt(priv, hwirq);
+ else if (hwirq >= IRQC_TINT_START && hwirq < IRQC_NUM_IRQ)
+ rzg2l_irqc_unmask_tint_interrupt(priv, hwirq);
+}
+
+static void rzg2l_irqc_unmask(struct irq_data *d)
+{
+ struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
+
+ raw_spin_lock(&priv->lock);
+ rzg2l_irqc_unmask_once(priv, irqd_to_hwirq(d));
+ raw_spin_unlock(&priv->lock);
+ irq_chip_unmask_parent(d);
+}
+
static void rzg2l_tint_irq_endisable(struct irq_data *d, bool enable)
{
+ struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
unsigned int hw_irq = irqd_to_hwirq(d);
if (hw_irq >= IRQC_TINT_START && hw_irq < IRQC_NUM_IRQ) {
- struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
u32 offset = hw_irq - IRQC_TINT_START;
u32 tssr_offset = TSSR_OFFSET(offset);
u8 tssr_index = TSSR_INDEX(offset);
u32 reg;
raw_spin_lock(&priv->lock);
+ if (enable)
+ rzg2l_irqc_unmask_once(priv, hw_irq);
+ else
+ rzg2l_irqc_mask_once(priv, hw_irq);
reg = readl_relaxed(priv->base + TSSR(tssr_index));
if (enable)
reg |= TIEN << TSSEL_SHIFT(tssr_offset);
@@ -157,6 +253,13 @@ static void rzg2l_tint_irq_endisable(struct irq_data *d, bool enable)
reg &= ~(TIEN << TSSEL_SHIFT(tssr_offset));
writel_relaxed(reg, priv->base + TSSR(tssr_index));
raw_spin_unlock(&priv->lock);
+ } else {
+ raw_spin_lock(&priv->lock);
+ if (enable)
+ rzg2l_irqc_unmask_once(priv, hw_irq);
+ else
+ rzg2l_irqc_mask_once(priv, hw_irq);
+ raw_spin_unlock(&priv->lock);
}
}
@@ -324,8 +427,8 @@ static struct syscore_ops rzg2l_irqc_syscore_ops = {
static const struct irq_chip irqc_chip = {
.name = "rzg2l-irqc",
.irq_eoi = rzg2l_irqc_eoi,
- .irq_mask = irq_chip_mask_parent,
- .irq_unmask = irq_chip_unmask_parent,
+ .irq_mask = rzg2l_irqc_mask,
+ .irq_unmask = rzg2l_irqc_unmask,
.irq_disable = rzg2l_irqc_irq_disable,
.irq_enable = rzg2l_irqc_irq_enable,
.irq_get_irqchip_state = irq_chip_get_parent_state,
@@ -401,7 +504,16 @@ static int rzg2l_irqc_parse_interrupts(struct rzg2l_irqc_priv *priv,
return 0;
}
-static int rzg2l_irqc_init(struct device_node *node, struct device_node *parent)
+static const struct rzg2l_irqc_of_data rzg2l_irqc_mask_supported_data = {
+ .mask_supported = true,
+};
+
+static const struct rzg2l_irqc_of_data rzg2l_irqc_default_data = {
+ .mask_supported = false,
+};
+
+static int rzg2l_irqc_init(struct device_node *node, struct device_node *parent,
+ const struct rzg2l_irqc_of_data *of_data)
{
struct irq_domain *irq_domain, *parent_domain;
struct platform_device *pdev;
@@ -422,6 +534,8 @@ static int rzg2l_irqc_init(struct device_node *node, struct device_node *parent)
if (!rzg2l_irqc_data)
return -ENOMEM;
+ rzg2l_irqc_data->data = of_data;
+
rzg2l_irqc_data->base = devm_of_iomap(&pdev->dev, pdev->dev.of_node, 0, NULL);
if (IS_ERR(rzg2l_irqc_data->base))
return PTR_ERR(rzg2l_irqc_data->base);
@@ -472,8 +586,21 @@ static int rzg2l_irqc_init(struct device_node *node, struct device_node *parent)
return ret;
}
+static int __init rzg2l_irqc_default_init(struct device_node *node,
+ struct device_node *parent)
+{
+ return rzg2l_irqc_init(node, parent, &rzg2l_irqc_default_data);
+}
+
+static int __init rzg2l_irqc_mask_supported_init(struct device_node *node,
+ struct device_node *parent)
+{
+ return rzg2l_irqc_init(node, parent, &rzg2l_irqc_mask_supported_data);
+}
+
IRQCHIP_PLATFORM_DRIVER_BEGIN(rzg2l_irqc)
-IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_init)
+IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_default_init)
+IRQCHIP_MATCH("renesas,r9a07g043f-irqc", rzg2l_irqc_mask_supported_init)
IRQCHIP_PLATFORM_DRIVER_END(rzg2l_irqc)
MODULE_AUTHOR("Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>");
MODULE_DESCRIPTION("Renesas RZ/G2L IRQC Driver");
--
2.34.1
^ permalink raw reply related
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