* [PATCH v5 0/7] iio: accel: adxl345: Add spi-3wire feature
From: Lothar Rubusch @ 2024-03-27 22:03 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya, l.rubusch
Pass a function setup() as pointer from SPI/I2C specific modules to the
core module. Implement setup() to pass the spi-3wire bus option, if
declared in the device-tree.
In the core module, then update data_format register configuration bits
instead of overwriting it. The changes allow to remove a data_range field.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
V1 -> V2: split into spi-3wire and refactoring
V2 -> V3: split further, focus on needed changesets
V3 -> V4: drop "Remove single info instances";
split "Group bus configuration" into separat
comment patch; reorder patch set
V4 -> V5: Refrase comments; Align comments to 75; rebuild FORMAT_MASK by
available flags; fix indention
Lothar Rubusch (7):
iio: accel: adxl345: Make data_range obsolete
iio: accel: adxl345: Group bus configuration
iio: accel: adxl345: Move defines to header
dt-bindings: iio: accel: adxl345: Add spi-3wire
iio: accel: adxl345: Pass function pointer to core
iio: accel: adxl345: Add comment to probe
iio: accel: adxl345: Add spi-3wire option
.../bindings/iio/accel/adi,adxl345.yaml | 2 +
drivers/iio/accel/adxl345.h | 42 ++++++++++++-
drivers/iio/accel/adxl345_core.c | 62 ++++++++-----------
drivers/iio/accel/adxl345_i2c.c | 2 +-
drivers/iio/accel/adxl345_spi.c | 12 +++-
5 files changed, 80 insertions(+), 40 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH v2 2/2] mfd: rohm-bd71828: Add power off functionality
From: Andreas Kemnade @ 2024-03-27 22:02 UTC (permalink / raw)
To: Matti Vaittinen
Cc: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, devicetree,
linux-kernel
In-Reply-To: <c6f5a515-61a1-4d87-a029-4000fa96f10e@gmail.com>
Hi Matti,
On Wed, 27 Mar 2024 16:11:36 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> On 3/27/24 15:04, Andreas Kemnade wrote:
> > Hi,
> >
> > On Wed, 27 Mar 2024 09:32:29 +0200
> > Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> >
> >> It's worth noting that there is another PMIC, BD71879, which, from the
> >> driver software point of view, should be (almost?) identical to the
> >> BD71828. I believe the BD71828 drivers should work with it as well - if
> >> not out of the box, at least with very minor modifications.
> >> Unfortunately I don't know products where the BD71879 is used or if it
> >> is sold via distributors - so I don't know if adding a DT
> >> compatible/chip type define for it would be beneficial.
> >
> > yes, you already told we thet the BD71828 drivers are compatible with
> > the BD71879 and I am using the latter.
> > But that at least should be commented somewhere, so that
> > people do not raise questions, like: Do I have some strange board revision,
> > etc?
> > The most terse form to comment it is a separate dt compatible so we are
> > prepare any "almost identical" surprises.
>
> I agree. Reason why I haven't done this already is that I don't always
> (like in this case) know which of the variant are eventually sold. So,
> it's balancing dance between adding compatibles for ICs that will never
> been seen by large audience, and missing compatibles for some of the
> variants.
>
> This is also why I was interested in knowing which variant you had, and
> where was it used.
>
I have found it in the Kobo Clara 2E ebook reader.
Kobo seems to switch from RC5T619 to BD71879.
The Kobo Nia rev C also has that one.
Kobo Libra 2 has several hardware revs out in the wild, some of them
with the BD71879.
> But yes, I think that as the BD71879 has obviously been found by a
> community linux kernel user - it would make sense to add a compatible
> for it!
>
> Do you feel like adding the compatible 'rohm,bd71879' in
> rohm,bd71828-pmic.yaml as part of this series(?)
Do we want a separate chip_type now? Or do we want to add it later if
we ever see a difference. My personal opinion is to wait until there is
really a need.
If we do not need it, then it is a different series I think but sure
I will produce such a patch.
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH v4 1/2] of: create of_root if no dtb provided
From: Rob Herring @ 2024-03-27 21:56 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stephen Boyd, Frank Rowand, Clément Léger, devicetree,
linux-kernel, Lizhi Hou, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Thomas Petazzoni
In-Reply-To: <932e8cb7-1874-4c4a-8fee-bc0b9dffe94c@roeck-us.net>
On Wed, Mar 27, 2024 at 2:47 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Wed, Mar 27, 2024 at 01:38:13PM -0500, Rob Herring wrote:
> > On Wed, Mar 27, 2024 at 9:40 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On 3/27/24 06:11, Rob Herring wrote:
> > > > On Wed, Mar 20, 2024 at 3:06 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > >>
> > > >> On 3/20/24 12:14, Rob Herring wrote:
> > > >>> On Mon, Mar 18, 2024 at 4:31 PM Guenter Roeck <linux@roeck-us.net>
> > > >>> wrote:
> > > >>>>
> > > >>>> On 3/18/24 12:26, Rob Herring wrote:
> > > >>>>> +Stephen
> > > >>>>>
> > > >>>>> On Mon, Mar 18, 2024 at 12:09 PM Guenter Roeck <linux@roeck-us.net>
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>> Hi,
> > > >>>>>>
> > > >>>>>> On Fri, Mar 17, 2023 at 12:34:14AM -0500, Frank Rowand wrote:
> > > >>>>>>> When enabling CONFIG_OF on a platform where of_root is not
> > > >>>>>>> populated by firmware, we end up without a root node. In order to
> > > >>>>>>> apply overlays and create subnodes of the root node, we need one.
> > > >>>>>>> Create this root node by unflattening an empty builtin dtb.
> > > >>>>>>>
> > > >>>>>>> If firmware provides a flattened device tree (FDT) then the FDT is
> > > >>>>>>> unflattened via setup_arch(). Otherwise setup_of(), which is
> > > >>>>>>> called immediately after setup_arch(), will create the default root
> > > >>>>>>> node if it does not exist.
> > > >>>>>>>
> > > >>>>>>> Signed-off-by: Frank Rowand <frowand.list@gmail.com>
> > > >>>>>>
> > > >>>>>> This patch results in a crash on nios2.
> > > >>>>>
> > > >>>>> This patch was never applied. I assume you meant a later version of
> > > >>>>> it that did get applied.
> > > >>>>>
> > > >>>>>>
> > > >>>>>> Building nios2:10m50-ghrd:10m50_defconfig:10m50_devboard.dts ...
> > > >>>>>> running ...R failed (crashed)
> > > >>>>>
> > > >>>>> Booting with DT?
> > > >>>>>
> > > >>>>>> ------------ qemu log: earlycon: uart8250 at MMIO32 0x18001600
> > > >>>>>> (options '') printk: legacy bootconsole [uart8250] enabled Linux
> > > >>>>>> version 6.8.0-11409-gf6cef5f8c37f (groeck@desktop) (nios2-linux-gcc
> > > >>>>>> (GCC) 11.4.0, GNU ld (GNU Binutils) 2.40) #1 Sun Mar 17 23:38:59 PDT
> > > >>>>>> 2024 Kernel panic - not syncing: early_init_dt_alloc_memory_arch:
> > > >>>>>> Failed to allocate 72 bytes align=0x40 ---[ end Kernel panic - not
> > > >>>>>> syncing: early_init_dt_alloc_memory_arch: Failed to allocate 72
> > > >>>>>> bytes align=0x40 ]---
> > > >>>>>
> > > >>>>> nios2 looks utterly broken to me. This change should be a nop unless
> > > >>>>> initial_boot_params is NULL. It looks like it is possible for r6 (dtb
> > > >>>>> address) to be 0 depending on kconfig options, but that would have
> > > >>>>> skipped copying and unflattening which would then panic in
> > > >>>>> setup_cpuinfo(). If initial_boot_params is not NULL, then the same
> > > >>>>> early_init_dt_alloc_memory_arch() calls should fail when copying the
> > > >>>>> DT. So I don't see how nios2 booting with DT ever worked.
> > > >>>>>
> > > >>>>
> > > >>>> For nios2, in early_init_devtree():
> > > >>>>
> > > >>>> void __init early_init_devtree(void *params) { __be32 *dtb = (u32
> > > >>>> *)__dtb_start; ... if (be32_to_cpu((__be32) *dtb) == OF_DT_HEADER)
> > > >>>> params = (void *)__dtb_start;
> > > >>>>
> > > >>>> That worked fine until this patch. Starting with this patch,
> > > >>>> __dtb_start always points to a valid empty devicetree blob, which
> > > >>>> overrides the devicetree blob passed to early_init_devtree(). This
> > > >>>> causes the problem.
> > > >>>
> > > >>> With an external DTB, it doesn't boot with or without this patch. It
> > > >>> just dies in different spots. Before it just skipped any memory
> > > >>
> > > >> No, that is incorrect.
> > > >
> > > > Well, I can tell you it doesn't boot for me. So I must be doing something
> > > > different from your setup.
> > > >
> > >
> > > Maybe you have OF_UNITTEST enabled and it indeed results in the problem you
> > > mention below. I don't have it enabled because it produces various
> > > backtraces which would hide real problems.
> >
> > I thought of that, but I don't think I did. What I suspect is the external
> > dtb is at address 0.
Testing again, I built 10m50_defconfig without modification and ran
qemu (from debian testing):
qemu-system-nios2 -dtb
.build-nios2/arch/nios2/boot/dts/10m50_devboard.dtb -kernel
.build-nios2/vmlinux --nographic
I had to enable CONFIG_NIOS2_PASS_CMDLINE (which really means pass
cmdline, dtb, and initrd from bootloader) and it works and regresses
as you report.
> > > >> Up to this patch it booted just fine with an external dtb using the
> > > >> "-initrd" command line argument, and I explained to you above why this
> > > >> is the case.
> > > >
> > > > What does -initrd have to do with anything? Does that shift where the
> > > > external dtb is placed or something?
> > > >
> > >
> > > Nothing. I meant to say -dtb.
> > >
> > > > I think I see the issue. __dtb_start points to the start of *all*
> > > > built-in DTBs, not a specific one. In this case, arc, csky, loongarch,
> > > > mips, openrisc, riscv, sh, and xtensa may all be broken too (if one picks
> > > > the magic combination of booting modes and kconfig options). I
> > >
> > > No.
> > >
> > > - arc only picks the internal dtb if use_embedded_dtb is true. This flag is
> > > only set if there is no external dtb, or if the external dtb does not
> > > provide a valid machine description.
> >
> > Right, but when it does pick the internal dtb, it is expecting its dtb at
> > __dtb_start. What I'm saying is that's never been a good or safe assumption.
> > We just happened to add another case to trigger it. The only reliable way to
> > get a built-in DTB is if foo.dtb is built-in, then use __dtb_foo_begin to get
> > its address. That's what some MIPS platforms with multiple DTBs do.
> >
>
> I may be missing something, but it seems to me that most if not all
> platforms with support for configurable built-in dtbs use __dtb_start
> to get its address.
That was my concern as that only points to the 1st DTB and nothing
prevents there being more than one. But I think link order saves all
of them after all.
> > > - openrisc only picks the internal dtb if no external dtb is provided. -
> > > riscv only picks the internal dtb if CONFIG_BUILTIN_DTB is enabled. - sh
> > > only used the internal dtb if CONFIG_USE_BUILTIN_DTB is enabled. - xtensa
> > > only picks the internal dtb if there is no external dtb.
> > >
> > > However, nios2 picks the internal dtb _even if_ an external dtb is provided
> > > if there is an internal dtb. In other words, it prefers the internal dtb
> > > over the external dtb. All other architectures prefer the external dtb over
> > > the internal dtb.
> >
> > Thanks for the analysis. I had started and abandoned common support (mostly
> > Kconfig options) for built-in dtbs years ago. I decided against it because it
> > is not something we want to encourage (as the boot dtb). In the meantime,
> > we've gained new architectures that have added it. Sigh. So now I'm
> > reconsidering something common (though not for v6.9).
> >
> > >
> > > > would expect all these cases have been broken forever if the DT unittest
> > > > is enabled as it too adds a built-in dtb. But I would also
> > >
> > > Even if that is correct for nios2, that hardly seems to be an argument to
> > > break nios2 boot with external dtb unconditionally.
> >
> > That wasn't an argument for breaking it. Using an external dtb should really
> > be the default and strongly preferred though.
> >
> > I'm still not sure how to fix this easily for 6.9. Something like what
> > microblaze does which puts the boot dtb under a consistent symbol name. Or
> > perhaps we could iterate thru the built-in dtbs and skip ones without
> > top-level compatible.
> >
>
> I did submit a patch to only override the external dtb if support for the
> internal dtb is enabled. I copied you on it, so you should have seen it.
>
> https://lore.kernel.org/linux-kernel/20240322065419.162416-1-linux@roeck-us.net/
Now reviewed, thanks. Sadly, I rarely see anything outside the normal
workflow of what I can filter out. I'm copied pretty much 1:1 with
what is sent to the DT list which is a fire hose.
Rob
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom-qmp-ufs: Add SM8475 support
From: Konrad Dybcio @ 2024-03-27 21:38 UTC (permalink / raw)
To: Danila Tikhonov, andersson, vkoul, kishon, robh,
krzysztof.kozlowski+dt, conor+dt
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20240327180642.20146-3-danila@jiaxyga.com>
On 27.03.2024 7:06 PM, Danila Tikhonov wrote:
> Add the tables and constants for init sequences for UFS QMP phy found in
> SM8475 SoC.
>
> Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
> ---
Worth mentioning that SM8475 is a respin of SM8450 on a different
process node, which probably forced some electrical changes.
Konrad
^ permalink raw reply
* Re: [PATCH v2] clk: qcom: gcc-sm8150: De-register gcc_cpuss_ahb_clk_src
From: Konrad Dybcio @ 2024-03-27 21:35 UTC (permalink / raw)
To: Satya Priya Kakitapalli, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Ajit Pandey,
Imran Shaik, Jagadeesh Kona
In-Reply-To: <20240213-gcc-ao-support-v2-1-fd2127e8d8f4@quicinc.com>
On 13.02.2024 7:47 AM, Satya Priya Kakitapalli wrote:
> De-register the gcc_cpuss_ahb_clk_src and its branch clocks
> as there is no rate setting happening on them.
>
> Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
> ---
> Remove gcc_cpuss_ahb_clk_src and its branch clocks.
> ---
> Changes in v2:
> - As per Konrad's comments, de-register the gcc_cpuss_ahb_clk_src
> instead of adding AO support as no rate-setting is happening on it.
> - Link to v1: https://lore.kernel.org/r/20240123-gcc-ao-support-v1-0-6c18d5310874@quicinc.com
> ---
Could you please confirm that this clock is governed by something external
like RPMh and needs no input whatshowever from HLOS?
Konrad
^ permalink raw reply
* Re: [PATCH RFT] arm64: dts: qcom: sm8350: Reenable crypto & cryptobam
From: Konrad Dybcio @ 2024-03-27 21:34 UTC (permalink / raw)
To: Luca Weiss, Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bhupesh Sharma, David Heidelberg, Stephan Gerhold,
~postmarketos/upstreaming, phone-devel, Krzysztof Kozlowski,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <CZ6FR855VPP7.3GHX4EO9WEZIH@fairphone.com>
On 16.02.2024 11:36 AM, Luca Weiss wrote:
> On Mon Jan 8, 2024 at 11:45 PM CET, Dmitry Baryshkov wrote:
>> On Mon, 8 Jan 2024 at 16:23, Luca Weiss <luca.weiss@fairphone.com> wrote:
>>>
>>> On Mon Jan 8, 2024 at 3:18 PM CET, Konrad Dybcio wrote:
>>>> On 8.01.2024 14:49, Luca Weiss wrote:
>>>>> When num-channels and qcom,num-ees is not provided in devicetree, the
>>>>> driver will try to read these values from the registers during probe but
>>>>> this fails if the interconnect is not on and then crashes the system.
>>>>>
>>>>> So we can provide these properties in devicetree (queried after patching
>>>>> BAM driver to enable the necessary interconnect) so we can probe
>>>>> cryptobam without reading registers and then also use the QCE as
>>>>> expected.
>>>>
>>>> This really feels a bit backwards.. Enable the resource to query the
>>>> hardware for numbers, so that said resource can be enabled, but
>>>> slightly later :/
>>>
>>> If you think adding interconnect support to driver and dtsi is better,
>>> let me know.
>>
>> I'd say, adding the proper interconnect is a better option. Otherwise
>> we just depend on the QCE itself to set up the vote for us.
>
> Yes, currently we depend on that.
>
>>
>>>
>>> Stephan (+CC) mentioned it should be okay like this *shrug*
>>>
>>> For the record, this is the same way I got the values for sc7280[0] and
>>> sm6350[1].
>>>
>>> [0] https://lore.kernel.org/linux-arm-msm/20231229-sc7280-cryptobam-fixup-v1-1-bd8f68589b80@fairphone.com/
>>> [1] https://lore.kernel.org/linux-arm-msm/20240105-sm6350-qce-v1-0-416e5c7319ac@fairphone.com/
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
>>> index b46236235b7f..cd4dd9852d9e 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
>>> @@ -1756,8 +1756,8 @@ cryptobam: dma-controller@1dc4000 {
>>> qcom,controlled-remotely;
>>> iommus = <&apps_smmu 0x594 0x0011>,
>>> <&apps_smmu 0x596 0x0011>;
>>> - /* FIXME: Probing BAM DMA causes some abort and system hang */
>>> - status = "fail";
>>> + interconnects = <&aggre2_noc MASTER_CRYPTO 0 &mc_virt SLAVE_EBI1 0>;
>>> + interconnect-names = "memory";
>>> };
>>>
>>> crypto: crypto@1dfa000 {
>>> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
>>> index 5e7d332731e0..9de28f615639 100644
>>> --- a/drivers/dma/qcom/bam_dma.c
>>> +++ b/drivers/dma/qcom/bam_dma.c
>>> @@ -40,6 +40,7 @@
>>> #include <linux/circ_buf.h>
>>> #include <linux/clk.h>
>>> #include <linux/dmaengine.h>
>>> +#include <linux/interconnect.h>
>>> #include <linux/pm_runtime.h>
>>>
>>> #include "../dmaengine.h"
>>> @@ -394,6 +395,7 @@ struct bam_device {
>>> const struct reg_offset_data *layout;
>>>
>>> struct clk *bamclk;
>>> + struct icc_path *mem_path;
>>> int irq;
>>>
>>> /* dma start transaction tasklet */
>>> @@ -1206,6 +1208,7 @@ static int bam_init(struct bam_device *bdev)
>>> bdev->num_channels = val & BAM_NUM_PIPES_MASK;
>>> }
>>>
>>> + printk(KERN_ERR "%s:%d DBG num_ees=%u num_channels=%u\n", __func__, __LINE__, bdev->num_ees, bdev->num_channels);
>>> /* Reset BAM now if fully controlled locally */
>>> if (!bdev->controlled_remotely && !bdev->powered_remotely)
>>> bam_reset(bdev);
>>> @@ -1298,6 +1301,14 @@ static int bam_dma_probe(struct platform_device *pdev)
>>> return ret;
>>> }
>>>
>>> + bdev->mem_path = devm_of_icc_get(bdev->dev, "memory");
>>> + if (IS_ERR(bdev->mem_path))
>>> + return PTR_ERR(bdev->mem_path);
>>> +
>>> + ret = icc_set_bw(bdev->mem_path, 1, 1);
>>
>> Probably this needs some more sensible value.
>
> So downstream qcedev driver uses 384 for the interconnect. But this is
> crypto-specific and probably different BAMs have different minimum
> requirements?
>
> #define CRYPTO_AVG_BW 384
> #define CRYPTO_PEAK_BW 384
> https://github.com/xiaomi-sm8450-kernel/android_kernel_platform_msm-kernel/blob/lineage-20/drivers/crypto/msm/qce.h#L57
>
> Do you have any suggestion what to use here?
I'dve expected this to mean anything, but apparently not.
My immediate guess is that the 384 was the lowest magic value that didn't
result in the bus getting kicked offline.. 1 should be fine upstream due
to commit 91e045b93db7 ("interconnect: qcom: Fix small BW votes being
truncated to zero").
>
> Also I'd assume that with pm_runtime suspended we'd need to clear the
> votes in the driver so we don't keep the interconnect alive
> unnecessarily?
My naive understanding is that the power should only be necessary when
the thing is in use, so early probe and pm-active sounds about sane..
Konrad
^ permalink raw reply
* Re: [PATCH v3 8/8] arm64: dts: allwinner: h616: enable DVFS for all boards
From: Jernej Škrabec @ 2024-03-27 21:25 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Rafael J . Wysocki, Andre Przywara
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-9-andre.przywara@arm.com>
Dne torek, 26. marec 2024 ob 12:47:43 CET je Andre Przywara napisal(a):
> With the DT bindings now describing the format of the CPU OPP tables, we
> can include the OPP table in each board's .dts file, and specify the CPU
> power supply.
> This allows to enable DVFS, and get up to 50% of performance benefit in
> the highest OPP, or up to 60% power savings in the lowest OPP, compared
> to the fixed 1GHz @ 1.0V OPP we are running in by default at the moment.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v3 7/8] arm64: dts: allwinner: h616: Add CPU OPPs table
From: Jernej Škrabec @ 2024-03-27 21:24 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Rafael J . Wysocki, Andre Przywara
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-8-andre.przywara@arm.com>
Dne torek, 26. marec 2024 ob 12:47:42 CET je Andre Przywara napisal(a):
> From: Martin Botka <martin.botka@somainline.org>
>
> Add an Operating Performance Points table for the CPU cores to enable
> Dynamic Voltage & Frequency Scaling (DVFS) on the H616.
> The values were taken from the BSP sources. The (newer) H700 chips we
> have seen seem to use a separate speed bin, its OPP values were taken
> from a live system and added to the mix.
>
> Also add the needed cpu_speed_grade nvmem cell and the cooling cells
> properties, to enable passive cooling.
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> [Andre: rework to minimise opp-microvolt properties]
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../dts/allwinner/sun50i-h616-cpu-opp.dtsi | 125 ++++++++++++++++++
> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 8 ++
> 2 files changed, 133 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
> new file mode 100644
> index 0000000000000..6073fdf672592
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
> @@ -0,0 +1,125 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2023 Martin Botka <martin@somainline.org>
> +
> +/ {
> + cpu_opp_table: opp-table-cpu {
> + compatible = "allwinner,sun50i-h616-operating-points";
> + nvmem-cells = <&cpu_speed_grade>;
> + opp-shared;
> +
> + opp-480000000 {
> + opp-hz = /bits/ 64 <480000000>;
> + opp-microvolt = <900000>;
Ideally triplet of voltages should be specified, to support PMIC-less boards,
but that's unlikely to happen with these SoCs.
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x3f>;
> + };
> +
> + opp-600000000 {
> + opp-hz = /bits/ 64 <600000000>;
> + opp-microvolt = <900000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x12>;
> + };
> +
> + opp-720000000 {
> + opp-hz = /bits/ 64 <720000000>;
> + opp-microvolt = <900000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x2d>;
> + };
> +
> + opp-792000000 {
> + opp-hz = /bits/ 64 <792000000>;
> + opp-microvolt-speed1 = <900000>;
> + opp-microvolt-speed4 = <940000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x12>;
> + };
> +
> + opp-936000000 {
> + opp-hz = /bits/ 64 <936000000>;
> + opp-microvolt = <900000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x0d>;
> + };
> +
> + opp-1008000000 {
> + opp-hz = /bits/ 64 <1008000000>;
> + opp-microvolt-speed0 = <950000>;
> + opp-microvolt-speed1 = <940000>;
> + opp-microvolt-speed2 = <950000>;
> + opp-microvolt-speed3 = <950000>;
> + opp-microvolt-speed4 = <1020000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x1f>;
> + };
> +
> + opp-10320000 {
> + opp-hz = /bits/ 64 <1032000000>;
> + opp-microvolt = <900000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x20>;
> + };
> +
> + opp-1104000000 {
> + opp-hz = /bits/ 64 <1104000000>;
> + opp-microvolt-speed0 = <1000000>;
> + opp-microvolt-speed2 = <1000000>;
> + opp-microvolt-speed3 = <1000000>;
> + opp-microvolt-speed5 = <950000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x2d>;
> + };
> +
> + opp-1200000000 {
> + opp-hz = /bits/ 64 <1200000000>;
> + opp-microvolt-speed0 = <1050000>;
> + opp-microvolt-speed1 = <1020000>;
> + opp-microvolt-speed2 = <1050000>;
> + opp-microvolt-speed3 = <1050000>;
> + opp-microvolt-speed4 = <1100000>;
> + opp-microvolt-speed5 = <1020000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x3f>;
> + };
> +
> + opp-1320000000 {
> + opp-hz = /bits/ 64 <1320000000>;
> + opp-microvolt = <1100000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x1d>;
> + };
> +
> + opp-1416000000 {
> + opp-hz = /bits/ 64 <1416000000>;
> + opp-microvolt = <1100000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x2d>;
> + };
> +
> + opp-1512000000 {
> + opp-hz = /bits/ 64 <1512000000>;
> + opp-microvolt-speed1 = <1100000>;
> + opp-microvolt-speed3 = <1100000>;
> + opp-microvolt-speed5 = <1160000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + opp-supported-hw = <0x2a>;
> + };
> + };
> +};
> +
> +&cpu0 {
> + operating-points-v2 = <&cpu_opp_table>;
> +};
> +
> +&cpu1 {
> + operating-points-v2 = <&cpu_opp_table>;
> +};
> +
> +&cpu2 {
> + operating-points-v2 = <&cpu_opp_table>;
> +};
> +
> +&cpu3 {
> + operating-points-v2 = <&cpu_opp_table>;
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> index b2e85e52d1a12..c0fa466fa9f07 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -26,6 +26,7 @@ cpu0: cpu@0 {
> reg = <0>;
> enable-method = "psci";
> clocks = <&ccu CLK_CPUX>;
> + #cooling-cells = <2>;
> };
>
> cpu1: cpu@1 {
> @@ -34,6 +35,7 @@ cpu1: cpu@1 {
> reg = <1>;
> enable-method = "psci";
> clocks = <&ccu CLK_CPUX>;
> + #cooling-cells = <2>;
> };
>
> cpu2: cpu@2 {
> @@ -42,6 +44,7 @@ cpu2: cpu@2 {
> reg = <2>;
> enable-method = "psci";
> clocks = <&ccu CLK_CPUX>;
> + #cooling-cells = <2>;
> };
>
> cpu3: cpu@3 {
> @@ -50,6 +53,7 @@ cpu3: cpu@3 {
> reg = <3>;
> enable-method = "psci";
> clocks = <&ccu CLK_CPUX>;
> + #cooling-cells = <2>;
> };
> };
>
> @@ -156,6 +160,10 @@ sid: efuse@3006000 {
> ths_calibration: thermal-sensor-calibration@14 {
> reg = <0x14 0x8>;
> };
> +
> + cpu_speed_grade: cpu-speed-grade@0 {
> + reg = <0x0 2>;
> + };
> };
>
> watchdog: watchdog@30090a0 {
>
^ permalink raw reply
* Re: [PATCH v2 3/7] clk: qcom: Add Display Clock Controller driver for SM7150
From: Konrad Dybcio @ 2024-03-27 21:22 UTC (permalink / raw)
To: Danila Tikhonov, andersson, mturquette, sboyd, robh,
krzysztof.kozlowski+dt, conor+dt, david, adrian
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <20240321202814.59835-4-danila@jiaxyga.com>
On 21.03.2024 9:28 PM, Danila Tikhonov wrote:
> Add support for the display clock controller found on SM7150.
>
> Co-developed-by: David Wronek <david@mainlining.org>
> Signed-off-by: David Wronek <david@mainlining.org>
> Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
> ---
Please drop CLK_GET_RATE_NOCACHE as it should not be necessary
(the rate of the clocks in question should not change without the
clock framework's knowledge)
I think it looks good otherwise
Konrad
^ permalink raw reply
* Re: [PATCH v3 5/8] cpufreq: sun50i: Add support for opp_supported_hw
From: Jernej Škrabec @ 2024-03-27 21:20 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Rafael J . Wysocki, Andre Przywara
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-6-andre.przywara@arm.com>
Dne torek, 26. marec 2024 ob 12:47:40 CET je Andre Przywara napisal(a):
> The opp_supported_hw DT property allows the DT to specify a mask of chip
> revisions that a certain OPP is eligible for. This allows for easy
> limiting of maximum frequencies, for instance.
>
> Add support for that in the sun50i-cpufreq-nvmem driver. We support both
> the existing opp-microvolt suffix properties as well as the
> opp-supported-hw property, the generic code figures out which is needed
> automatically.
> However if none of the DT OPP nodes contain an opp-supported-hw
> property, the core code will ignore all OPPs and the driver will fail
> probing. So check the DT's eligibility first before using that feature.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v3 4/8] cpufreq: sun50i: Refactor speed bin decoding
From: Jernej Škrabec @ 2024-03-27 21:19 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Rafael J . Wysocki, Andre Przywara
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-5-andre.przywara@arm.com>
Dne torek, 26. marec 2024 ob 12:47:39 CET je Andre Przywara napisal(a):
> From: Brandon Cheo Fusi <fusibrandon13@gmail.com>
>
> Make converting the speed bin value into a speed grade generic and
> determined by a platform specific callback. Also change the prototypes
> involved to encode the speed bin directly in the return value.
>
> This allows to extend the driver more easily to support more SoCs.
>
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13@gmail.com>
> [Andre: merge output into return value]
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> drivers/cpufreq/sun50i-cpufreq-nvmem.c | 74 +++++++++++++++++---------
> 1 file changed, 49 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> index 32a9c88f8ff6d..7b44f3b13e7d2 100644
> --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> @@ -25,19 +25,52 @@
>
> static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
>
> +struct sunxi_cpufreq_data {
> + u32 (*efuse_xlate)(u32 speedbin);
> +};
> +
> +static u32 sun50i_h6_efuse_xlate(u32 speedbin)
> +{
> + u32 efuse_value;
> +
> + efuse_value = (speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
> +
> + /*
> + * We treat unexpected efuse values as if the SoC was from
> + * the slowest bin. Expected efuse values are 1-3, slowest
> + * to fastest.
> + */
> + if (efuse_value >= 1 && efuse_value <= 3)
> + return efuse_value - 1;
> + else
> + return 0;
> +}
> +
> +static struct sunxi_cpufreq_data sun50i_h6_cpufreq_data = {
> + .efuse_xlate = sun50i_h6_efuse_xlate,
> +};
> +
> +static const struct of_device_id cpu_opp_match_list[] = {
> + { .compatible = "allwinner,sun50i-h6-operating-points",
> + .data = &sun50i_h6_cpufreq_data,
> + },
> + {}
> +};
> +
> /**
> * sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
> - * @versions: Set to the value parsed from efuse
> *
> - * Returns 0 if success.
> + * Returns non-negative speed bin index on success, a negative error
> + * value otherwise.
> */
> -static int sun50i_cpufreq_get_efuse(u32 *versions)
> +static int sun50i_cpufreq_get_efuse(void)
> {
> struct nvmem_cell *speedbin_nvmem;
> struct device_node *np;
> struct device *cpu_dev;
> - u32 *speedbin, efuse_value;
> - size_t len;
> + const struct of_device_id *match;
> + const struct sunxi_cpufreq_data *opp_data;
> + u32 *speedbin;
nit: reverse christmas tree
Other than that,
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
> int ret;
>
> cpu_dev = get_cpu_device(0);
> @@ -48,12 +81,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
> if (!np)
> return -ENOENT;
>
> - ret = of_device_is_compatible(np,
> - "allwinner,sun50i-h6-operating-points");
> - if (!ret) {
> + match = of_match_node(cpu_opp_match_list, np);
> + if (!match) {
> of_node_put(np);
> return -ENOENT;
> }
> + opp_data = match->data;
>
> speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> of_node_put(np);
> @@ -61,25 +94,16 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
> return dev_err_probe(cpu_dev, PTR_ERR(speedbin_nvmem),
> "Could not get nvmem cell\n");
>
> - speedbin = nvmem_cell_read(speedbin_nvmem, &len);
> + speedbin = nvmem_cell_read(speedbin_nvmem, NULL);
> nvmem_cell_put(speedbin_nvmem);
> if (IS_ERR(speedbin))
> return PTR_ERR(speedbin);
>
> - efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
> -
> - /*
> - * We treat unexpected efuse values as if the SoC was from
> - * the slowest bin. Expected efuse values are 1-3, slowest
> - * to fastest.
> - */
> - if (efuse_value >= 1 && efuse_value <= 3)
> - *versions = efuse_value - 1;
> - else
> - *versions = 0;
> + ret = opp_data->efuse_xlate(*speedbin);
>
> kfree(speedbin);
> - return 0;
> +
> + return ret;
> };
>
> static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
> @@ -87,7 +111,7 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
> int *opp_tokens;
> char name[MAX_NAME_LEN];
> unsigned int cpu;
> - u32 speed = 0;
> + int speed;
> int ret;
>
> opp_tokens = kcalloc(num_possible_cpus(), sizeof(*opp_tokens),
> @@ -95,10 +119,10 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
> if (!opp_tokens)
> return -ENOMEM;
>
> - ret = sun50i_cpufreq_get_efuse(&speed);
> - if (ret) {
> + speed = sun50i_cpufreq_get_efuse();
> + if (speed < 0) {
> kfree(opp_tokens);
> - return ret;
> + return speed;
> }
>
> snprintf(name, MAX_NAME_LEN, "speed%d", speed);
>
^ permalink raw reply
* Re: [PATCH v2 1/7] clk: qcom: gcc-sm7150: Make clk_init_data const and various fixes
From: Konrad Dybcio @ 2024-03-27 21:14 UTC (permalink / raw)
To: Danila Tikhonov, andersson, mturquette, sboyd, robh,
krzysztof.kozlowski+dt, conor+dt, david, adrian
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <20240321202814.59835-2-danila@jiaxyga.com>
On 21.03.2024 9:28 PM, Danila Tikhonov wrote:
> - The clk_init_data structures are never modified, make
> them const.
> - Add missing comma
Highly debatable given you're not expecting to enlarge this enum
> - Add dependencies on "ARM64 or COMPILE_TEST"
Please split this up into two patches (or if you really care about
that comma, I won't snitch on you if you squash it together with adding
const specifiers)
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/8] cpufreq: dt-platdev: Blocklist Allwinner H616/618 SoCs
From: Jernej Škrabec @ 2024-03-27 20:57 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Rafael J . Wysocki, Andre Przywara
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-3-andre.przywara@arm.com>
Dne torek, 26. marec 2024 ob 12:47:37 CET je Andre Przywara napisal(a):
> From: Martin Botka <martin.botka@somainline.org>
>
> The AllWinner H616 SoC will use the (extended) H6 OPP driver, so add
> them to the cpufreq-dt blocklist, to not create the device twice.
> This also affects the closely related sibling SoCs H618 and H700.
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index b993a498084bc..86d8baa816795 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -104,6 +104,9 @@ static const struct of_device_id allowlist[] __initconst = {
> */
> static const struct of_device_id blocklist[] __initconst = {
> { .compatible = "allwinner,sun50i-h6", },
> + { .compatible = "allwinner,sun50i-h616", },
> + { .compatible = "allwinner,sun50i-h618", },
> + { .compatible = "allwinner,sun50i-h700", },
>
> { .compatible = "apple,arm-platform", },
>
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: quartzpro64: Enable the GPU
From: Dragan Simic @ 2024-03-27 20:28 UTC (permalink / raw)
To: Heiko Stübner
Cc: linux-rockchip, linux-arm-kernel, devicetree, robh+dt,
krzysztof.kozlowski+dt, conor+dt, boris.brezillon, linux-kernel,
kernel, sebastian.reichel
In-Reply-To: <6007945.alqRGMn8q6@diego>
Hello Heiko,
On 2024-03-27 11:29, Heiko Stübner wrote:
> Am Montag, 25. März 2024, 17:19:04 CET schrieb Dragan Simic:
>> Following the approach used to enable the Mali GPU on the rk3588-evb1,
>> [1]
>> do the same for the Pine64 QuartzPro64, which uses nearly identical
>> hardware
>> design as the RK3588 EVB1.
>>
>> The slight disadvantage is that the regulator coupling logic requires
>> the
>> regulators to be always on, which is also noted in the comments. This
>> is
>> obviously something to be improved at some point in the future, but
>> should
>> be fine for now, especially because the QuartzPro64 isn't a
>> battery-powered
>> board, so low power consumption isn't paramount.
>>
>> [1]
>> https://lore.kernel.org/linux-rockchip/20240325153850.189128-5-sebastian.reichel@collabora.com/
>>
>> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>
> as lore.kernel.org and therefore b4 seems to be on vacation today, you
> get a very personal "applied" message ;-) .
>
> So, applied for 6.10 after the core rk3588-gpu-series from Sebastian.
Oh, thank you very much for this special message. :)
^ permalink raw reply
* [PATCH 2/2] arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK 4C+
From: Folker Schwesinger @ 2024-03-27 19:26 UTC (permalink / raw)
To: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Folker Schwesinger, Dragan Simic, Christopher Obbard,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20240327192641.14220-1-dev@folker-schwesinger.de>
Commit 8b5c2b45b8f0 disabled the internal pull-down for the strobe line
causing I/O errors in HS400 mode for various eMMC modules.
Enable the internal strobe pull-down for the ROCK 4C+ board. Also re-enable
HS400 mode, that was replaced with HS200 mode as a workaround for the
stability issues in:
2bd1d2dd808c ("arm64: dts: rockchip: Disable HS400 for eMMC on ROCK 4C+").
Fixes: 8b5c2b45b8f0 ("phy: rockchip: set pulldown for strobe line in dts")
Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
---
arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
index 7baf9d1b22fd..972aea843afd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
@@ -151,6 +151,7 @@ &cpu_b1 {
};
&emmc_phy {
+ rockchip,enable-strobe-pulldown;
status = "okay";
};
@@ -549,7 +550,8 @@ &saradc {
&sdhci {
max-frequency = <150000000>;
bus-width = <8>;
- mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
non-removable;
status = "okay";
};
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] ARM: dts: qcom: Add support for Motorola Moto G (2013)
From: Konrad Dybcio @ 2024-03-27 19:50 UTC (permalink / raw)
To: Stanislav Jakubek, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-arm-kernel, phone-devel,
linux-kernel
In-Reply-To: <8c605fb9cff8364ea6ac321b5a3fc265c5686def.1711454680.git.stano.jakubek@gmail.com>
On 26.03.2024 1:11 PM, Stanislav Jakubek wrote:
> Add a device tree for the Motorola Moto G (2013) smartphone based
> on the Qualcomm MSM8226 SoC.
>
> Initially supported features:
> - Buttons (Volume Down/Up, Power)
> - eMMC
> - Hall Effect Sensor
> - SimpleFB display
> - TMP108 temperature sensor
> - Vibrator
>
> Note: the dhob and shob reserved-memory regions are seemingly a part of some
> Motorola specific (firmware?) mechanism, see [1].
>
> [1] https://github.com/LineageOS/android_kernel_motorola_msm8226/blob/cm-14.1/Documentation/devicetree/bindings/misc/hob_ram.txt
>
> Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH v4 1/2] of: create of_root if no dtb provided
From: Guenter Roeck @ 2024-03-27 19:47 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Boyd, Frank Rowand, Clément Léger, devicetree,
linux-kernel, Lizhi Hou, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Thomas Petazzoni
In-Reply-To: <CAL_JsqJ2DijyKa-WSWdOszZt9UfQbb1MnD2zHh3ywntx6a=N+w@mail.gmail.com>
On Wed, Mar 27, 2024 at 01:38:13PM -0500, Rob Herring wrote:
> On Wed, Mar 27, 2024 at 9:40 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On 3/27/24 06:11, Rob Herring wrote:
> > > On Wed, Mar 20, 2024 at 3:06 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >>
> > >> On 3/20/24 12:14, Rob Herring wrote:
> > >>> On Mon, Mar 18, 2024 at 4:31 PM Guenter Roeck <linux@roeck-us.net>
> > >>> wrote:
> > >>>>
> > >>>> On 3/18/24 12:26, Rob Herring wrote:
> > >>>>> +Stephen
> > >>>>>
> > >>>>> On Mon, Mar 18, 2024 at 12:09 PM Guenter Roeck <linux@roeck-us.net>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> On Fri, Mar 17, 2023 at 12:34:14AM -0500, Frank Rowand wrote:
> > >>>>>>> When enabling CONFIG_OF on a platform where of_root is not
> > >>>>>>> populated by firmware, we end up without a root node. In order to
> > >>>>>>> apply overlays and create subnodes of the root node, we need one.
> > >>>>>>> Create this root node by unflattening an empty builtin dtb.
> > >>>>>>>
> > >>>>>>> If firmware provides a flattened device tree (FDT) then the FDT is
> > >>>>>>> unflattened via setup_arch(). Otherwise setup_of(), which is
> > >>>>>>> called immediately after setup_arch(), will create the default root
> > >>>>>>> node if it does not exist.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Frank Rowand <frowand.list@gmail.com>
> > >>>>>>
> > >>>>>> This patch results in a crash on nios2.
> > >>>>>
> > >>>>> This patch was never applied. I assume you meant a later version of
> > >>>>> it that did get applied.
> > >>>>>
> > >>>>>>
> > >>>>>> Building nios2:10m50-ghrd:10m50_defconfig:10m50_devboard.dts ...
> > >>>>>> running ...R failed (crashed)
> > >>>>>
> > >>>>> Booting with DT?
> > >>>>>
> > >>>>>> ------------ qemu log: earlycon: uart8250 at MMIO32 0x18001600
> > >>>>>> (options '') printk: legacy bootconsole [uart8250] enabled Linux
> > >>>>>> version 6.8.0-11409-gf6cef5f8c37f (groeck@desktop) (nios2-linux-gcc
> > >>>>>> (GCC) 11.4.0, GNU ld (GNU Binutils) 2.40) #1 Sun Mar 17 23:38:59 PDT
> > >>>>>> 2024 Kernel panic - not syncing: early_init_dt_alloc_memory_arch:
> > >>>>>> Failed to allocate 72 bytes align=0x40 ---[ end Kernel panic - not
> > >>>>>> syncing: early_init_dt_alloc_memory_arch: Failed to allocate 72
> > >>>>>> bytes align=0x40 ]---
> > >>>>>
> > >>>>> nios2 looks utterly broken to me. This change should be a nop unless
> > >>>>> initial_boot_params is NULL. It looks like it is possible for r6 (dtb
> > >>>>> address) to be 0 depending on kconfig options, but that would have
> > >>>>> skipped copying and unflattening which would then panic in
> > >>>>> setup_cpuinfo(). If initial_boot_params is not NULL, then the same
> > >>>>> early_init_dt_alloc_memory_arch() calls should fail when copying the
> > >>>>> DT. So I don't see how nios2 booting with DT ever worked.
> > >>>>>
> > >>>>
> > >>>> For nios2, in early_init_devtree():
> > >>>>
> > >>>> void __init early_init_devtree(void *params) { __be32 *dtb = (u32
> > >>>> *)__dtb_start; ... if (be32_to_cpu((__be32) *dtb) == OF_DT_HEADER)
> > >>>> params = (void *)__dtb_start;
> > >>>>
> > >>>> That worked fine until this patch. Starting with this patch,
> > >>>> __dtb_start always points to a valid empty devicetree blob, which
> > >>>> overrides the devicetree blob passed to early_init_devtree(). This
> > >>>> causes the problem.
> > >>>
> > >>> With an external DTB, it doesn't boot with or without this patch. It
> > >>> just dies in different spots. Before it just skipped any memory
> > >>
> > >> No, that is incorrect.
> > >
> > > Well, I can tell you it doesn't boot for me. So I must be doing something
> > > different from your setup.
> > >
> >
> > Maybe you have OF_UNITTEST enabled and it indeed results in the problem you
> > mention below. I don't have it enabled because it produces various
> > backtraces which would hide real problems.
>
> I thought of that, but I don't think I did. What I suspect is the external
> dtb is at address 0.
>
> > >> Up to this patch it booted just fine with an external dtb using the
> > >> "-initrd" command line argument, and I explained to you above why this
> > >> is the case.
> > >
> > > What does -initrd have to do with anything? Does that shift where the
> > > external dtb is placed or something?
> > >
> >
> > Nothing. I meant to say -dtb.
> >
> > > I think I see the issue. __dtb_start points to the start of *all*
> > > built-in DTBs, not a specific one. In this case, arc, csky, loongarch,
> > > mips, openrisc, riscv, sh, and xtensa may all be broken too (if one picks
> > > the magic combination of booting modes and kconfig options). I
> >
> > No.
> >
> > - arc only picks the internal dtb if use_embedded_dtb is true. This flag is
> > only set if there is no external dtb, or if the external dtb does not
> > provide a valid machine description.
>
> Right, but when it does pick the internal dtb, it is expecting its dtb at
> __dtb_start. What I'm saying is that's never been a good or safe assumption.
> We just happened to add another case to trigger it. The only reliable way to
> get a built-in DTB is if foo.dtb is built-in, then use __dtb_foo_begin to get
> its address. That's what some MIPS platforms with multiple DTBs do.
>
I may be missing something, but it seems to me that most if not all
platforms with support for configurable built-in dtbs use __dtb_start
to get its address.
> > - openrisc only picks the internal dtb if no external dtb is provided. -
> > riscv only picks the internal dtb if CONFIG_BUILTIN_DTB is enabled. - sh
> > only used the internal dtb if CONFIG_USE_BUILTIN_DTB is enabled. - xtensa
> > only picks the internal dtb if there is no external dtb.
> >
> > However, nios2 picks the internal dtb _even if_ an external dtb is provided
> > if there is an internal dtb. In other words, it prefers the internal dtb
> > over the external dtb. All other architectures prefer the external dtb over
> > the internal dtb.
>
> Thanks for the analysis. I had started and abandoned common support (mostly
> Kconfig options) for built-in dtbs years ago. I decided against it because it
> is not something we want to encourage (as the boot dtb). In the meantime,
> we've gained new architectures that have added it. Sigh. So now I'm
> reconsidering something common (though not for v6.9).
>
> >
> > > would expect all these cases have been broken forever if the DT unittest
> > > is enabled as it too adds a built-in dtb. But I would also
> >
> > Even if that is correct for nios2, that hardly seems to be an argument to
> > break nios2 boot with external dtb unconditionally.
>
> That wasn't an argument for breaking it. Using an external dtb should really
> be the default and strongly preferred though.
>
> I'm still not sure how to fix this easily for 6.9. Something like what
> microblaze does which puts the boot dtb under a consistent symbol name. Or
> perhaps we could iterate thru the built-in dtbs and skip ones without
> top-level compatible.
>
I did submit a patch to only override the external dtb if support for the
internal dtb is enabled. I copied you on it, so you should have seen it.
https://lore.kernel.org/linux-kernel/20240322065419.162416-1-linux@roeck-us.net/
Maybe that is less than perfect, but it is minimalistic, and I didn't want
to change code behavior more than absolutely necessary without guidance
from the nios2 maintainer.
Guenter
^ permalink raw reply
* [PATCH 1/2] arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK Pi 4
From: Folker Schwesinger @ 2024-03-27 19:26 UTC (permalink / raw)
To: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Folker Schwesinger, Dragan Simic, Christopher Obbard,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20240327192641.14220-1-dev@folker-schwesinger.de>
Commit 8b5c2b45b8f0 disabled the internal pull-down for the strobe line
causing I/O errors in HS400 mode for various eMMC modules.
Enable the internal strobe pull-down for ROCK Pi 4 boards. Also re-enable
HS400 mode, that was replaced with HS200 mode as a workaround for the
stability issues in:
cee572756aa2 ("arm64: dts: rockchip: Disable HS400 for eMMC on ROCK Pi 4").
This was tested on ROCK 4SE and ROCK Pi 4B+.
Fixes: 8b5c2b45b8f0 ("phy: rockchip: set pulldown for strobe line in dts")
Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
---
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
index 281a12180703..b9d6284bb804 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
@@ -194,6 +194,7 @@ &cpu_b1 {
};
&emmc_phy {
+ rockchip,enable-strobe-pulldown;
status = "okay";
};
@@ -648,7 +649,8 @@ &saradc {
&sdhci {
max-frequency = <150000000>;
bus-width = <8>;
- mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
non-removable;
status = "okay";
};
--
2.44.0
^ permalink raw reply related
* [PATCH 0/2] Enable internal strobe pulldown on Radxa ROCK 4 SBCs
From: Folker Schwesinger @ 2024-03-27 19:26 UTC (permalink / raw)
To: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Folker Schwesinger, Dragan Simic, Christopher Obbard,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
Various RK3399 boards, including the ROCK Pi 4 series showed instabilities
with some eMMC modules when operating in HS400 mode [1]. Later, a missing
pull-down resistor on the eMMC strobe line was identified as the root
cause of these instabilities [2].
This series enables the internal pull-down on the eMMC PHY strobe line
for all ROCK 4 series boards as they all lack an external strobe
pull-down resistor.
Furthermore, HS400 mode is re-enabled for these boards. Previously, to
workaround the instabilities until the issue was investigated further,
HS400 mode was replaced with HS200 mode [1].
[1]: https://lore.kernel.org/all/20230705144255.115299-1-chris.obbard@collabora.com/
[2]: https://lore.kernel.org/all/20220822074139.3810-1-jensenhuang@friendlyarm.com/
Folker Schwesinger (2):
arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK
Pi 4
arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK
4C+
arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts | 4 +++-
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
base-commit: 4cece764965020c22cff7665b18a012006359095
--
2.44.0
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: iommu: arm,smmu-v3: Add SC8280XP compatible
From: Konrad Dybcio @ 2024-03-27 19:23 UTC (permalink / raw)
To: Robin Murphy, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Will Deacon, Joerg Roedel, Rob Herring
Cc: Marijn Suijten, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, iommu, Johan Hovold
In-Reply-To: <9b2a681e-1191-4cf7-8da7-14aa2c1fa455@arm.com>
On 19.03.2024 2:53 PM, Robin Murphy wrote:
> On 2024-03-09 1:31 pm, Konrad Dybcio wrote:
>> The smmu-v3 binding currently doesn't differentiate the SoCs it's
>> implemented on. This is a poor design choice that may bite in the future,
>> should any quirks surface.
>
> That doesn't seem entirely fair to say - the vast majority of bindings don't have separate compatibles for every known integration of the same implementation in different SoCs. And in this case we don't have per-implementation compatibles for quirks and errata because the implementation is architecturally discoverable from the SMMU_IIDR register.
>
> We have the whole mess for QCom SMMUv2 because the effective *implementation* is a mix of hardware and hypervisor, whose behaviour does seem to vary on almost a per-SoC basis. I'm not at all keen to start repeating that here without very good reason, and that of "documenting" a device which we typically expect to not even be accessible isn't really convincing me...
From my POV as an arch dts maintainer, this often ends up being the only
way to retroactively add some conditional action into the code - the kernel
is supposed to be backwards compatible with older device trees.
And so far it's been almost by luck that all of the smmuv3 implementations
have been a straight copy-and-paste of the reference design (or close enough),
I don't believe this will be for much longer.
Konrad
^ permalink raw reply
* [PATCH v2 7/7] ARM: dts: omap3: use generic node name for hsi clients
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
In-Reply-To: <20240327-hsi-dt-binding-v2-0-110fab4c32ae@collabora.com>
The HSI peripheral node name should reflect the generic type of
device for the node.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm/boot/dts/ti/omap/omap3-n900.dts | 2 +-
arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap3-n900.dts b/arch/arm/boot/dts/ti/omap/omap3-n900.dts
index b906b57371ce..bec31faf86db 100644
--- a/arch/arm/boot/dts/ti/omap/omap3-n900.dts
+++ b/arch/arm/boot/dts/ti/omap/omap3-n900.dts
@@ -1123,7 +1123,7 @@ &ssi_port1 {
ti,ssi-cawake-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
- modem: hsi-client {
+ modem: modem {
compatible = "nokia,n900-modem";
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi b/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi
index 6e0db8275227..7e6dbc1968aa 100644
--- a/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi
@@ -450,7 +450,7 @@ &ssi_port1 {
ti,ssi-cawake-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
- modem: hsi-client {
+ modem: modem {
pinctrl-names = "default";
pinctrl-0 = <&modem_pins1 &modem_pins2>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 6/7] ARM: dts: omap3: fix ti,ssi-cawake-gpio property name
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
In-Reply-To: <20240327-hsi-dt-binding-v2-0-110fab4c32ae@collabora.com>
The SSI DT binding requires, that the canonical form "ti,ssi-cawake-gpios"
is used instead of "ti,ssi-cawake-gpio".
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm/boot/dts/ti/omap/omap3-n900.dts | 2 +-
arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap3-n900.dts b/arch/arm/boot/dts/ti/omap/omap3-n900.dts
index d33485341251..b906b57371ce 100644
--- a/arch/arm/boot/dts/ti/omap/omap3-n900.dts
+++ b/arch/arm/boot/dts/ti/omap/omap3-n900.dts
@@ -1121,7 +1121,7 @@ &ssi_port1 {
pinctrl-names = "default";
pinctrl-0 = <&ssi_pins>;
- ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
+ ti,ssi-cawake-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
modem: hsi-client {
compatible = "nokia,n900-modem";
diff --git a/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi b/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi
index aa4fcdbedd8f..6e0db8275227 100644
--- a/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi
@@ -448,7 +448,7 @@ &ssi_port1 {
pinctrl-0 = <&ssi_pins>;
pinctrl-1 = <&ssi_pins_idle>;
- ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
+ ti,ssi-cawake-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
modem: hsi-client {
pinctrl-names = "default";
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/7] ARM: dts: omap3: fix ssi-port node name
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
In-Reply-To: <20240327-hsi-dt-binding-v2-0-110fab4c32ae@collabora.com>
The DT binding specifies, that the node names for the SSI ports should
be just 'port@<address>' instead of 'ssi-port@<address>'.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm/boot/dts/ti/omap/omap3.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap3.dtsi b/arch/arm/boot/dts/ti/omap/omap3.dtsi
index 92cd4c99dae7..ae2bfcd7e18e 100644
--- a/arch/arm/boot/dts/ti/omap/omap3.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3.dtsi
@@ -999,7 +999,7 @@ ssi: ssi-controller@48058000 {
#size-cells = <1>;
ranges;
- ssi_port1: ssi-port@4805a000 {
+ ssi_port1: port@4805a000 {
compatible = "ti,omap3-ssi-port";
reg = <0x4805a000 0x800>,
@@ -1011,7 +1011,7 @@ ssi_port1: ssi-port@4805a000 {
<68>;
};
- ssi_port2: ssi-port@4805b000 {
+ ssi_port2: port@4805b000 {
compatible = "ti,omap3-ssi-port";
reg = <0x4805b000 0x800>,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/7] dt-bindings: hsi: nokia-modem: convert to YAML
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
In-Reply-To: <20240327-hsi-dt-binding-v2-0-110fab4c32ae@collabora.com>
Convert the legacy txt binding to modern YAML.
No semantic change.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
.../devicetree/bindings/hsi/nokia,modem.yaml | 106 +++++++++++++++++++++
.../devicetree/bindings/hsi/nokia-modem.txt | 59 ------------
2 files changed, 106 insertions(+), 59 deletions(-)
diff --git a/Documentation/devicetree/bindings/hsi/nokia,modem.yaml b/Documentation/devicetree/bindings/hsi/nokia,modem.yaml
new file mode 100644
index 000000000000..f6d5e2c14329
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/nokia,modem.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hsi/nokia,modem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nokia modem
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - nokia,n900-modem
+ - nokia,n950-modem
+ - nokia,n9-modem
+
+ hsi-channel-ids:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 4
+ maxItems: 4
+
+ hsi-channel-names:
+ items:
+ - const: mcsaab-control
+ - const: speech-control
+ - const: speech-data
+ - const: mcsaab-data
+
+ interrupts:
+ items:
+ - description: modem reset indication
+
+ gpios:
+ minItems: 3
+ maxItems: 5
+
+ gpio-names:
+ items:
+ - const: cmt_apeslpx
+ - const: cmt_rst_rq
+ - const: cmt_en
+ - const: cmt_rst
+ - const: cmt_bsi
+ minItems: 3
+
+required:
+ - gpios
+ - gpio-names
+ - interrupts
+
+allOf:
+ - $ref: hsi-client.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nokia,n950-modem
+ - nokia,n9-modem
+ then:
+ properties:
+ gpios:
+ maxItems: 3
+ gpio-names:
+ maxItems: 3
+ else:
+ properties:
+ gpios:
+ minItems: 5
+ gpio-names:
+ minItems: 5
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ modem {
+ compatible = "nokia,n900-modem";
+
+ hsi-channel-ids = <0>, <1>, <2>, <3>;
+ hsi-channel-names = "mcsaab-control",
+ "speech-control",
+ "speech-data",
+ "mcsaab-data";
+ hsi-speed-kbps = <55000>;
+ hsi-mode = "frame";
+ hsi-flow = "synchronized";
+ hsi-arb-mode = "round-robin";
+
+ interrupts-extended = <&gpio3 8 IRQ_TYPE_EDGE_FALLING>;
+
+ gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>,
+ <&gpio3 9 GPIO_ACTIVE_HIGH>,
+ <&gpio3 10 GPIO_ACTIVE_HIGH>,
+ <&gpio3 11 GPIO_ACTIVE_HIGH>,
+ <&gpio5 29 GPIO_ACTIVE_HIGH>;
+ gpio-names = "cmt_apeslpx",
+ "cmt_rst_rq",
+ "cmt_en",
+ "cmt_rst",
+ "cmt_bsi";
+ };
diff --git a/Documentation/devicetree/bindings/hsi/nokia-modem.txt b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
deleted file mode 100644
index 53de1d9d0b95..000000000000
--- a/Documentation/devicetree/bindings/hsi/nokia-modem.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Nokia modem client bindings
-
-The Nokia modem HSI client follows the common HSI client binding
-and inherits all required properties. The following additional
-properties are needed by the Nokia modem HSI client:
-
-Required properties:
-- compatible: Should be one of
- "nokia,n900-modem"
- "nokia,n950-modem"
- "nokia,n9-modem"
-- hsi-channel-names: Should contain the following strings
- "mcsaab-control"
- "speech-control"
- "speech-data"
- "mcsaab-data"
-- gpios: Should provide a GPIO handler for each GPIO listed in
- gpio-names
-- gpio-names: Should contain the following strings
- "cmt_apeslpx" (for n900, n950, n9)
- "cmt_rst_rq" (for n900, n950, n9)
- "cmt_en" (for n900, n950, n9)
- "cmt_rst" (for n900)
- "cmt_bsi" (for n900)
-- interrupts: Should be IRQ handle for modem's reset indication
-
-Example:
-
-&ssi_port {
- modem: hsi-client {
- compatible = "nokia,n900-modem";
-
- pinctrl-names = "default";
- pinctrl-0 = <&modem_pins>;
-
- hsi-channel-ids = <0>, <1>, <2>, <3>;
- hsi-channel-names = "mcsaab-control",
- "speech-control",
- "speech-data",
- "mcsaab-data";
- hsi-speed-kbps = <55000>;
- hsi-mode = "frame";
- hsi-flow = "synchronized";
- hsi-arb-mode = "round-robin";
-
- interrupts-extended = <&gpio3 8 IRQ_TYPE_EDGE_FALLING>; /* 72 */
-
- gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>, /* 70 */
- <&gpio3 9 GPIO_ACTIVE_HIGH>, /* 73 */
- <&gpio3 10 GPIO_ACTIVE_HIGH>, /* 74 */
- <&gpio3 11 GPIO_ACTIVE_HIGH>, /* 75 */
- <&gpio5 29 GPIO_ACTIVE_HIGH>; /* 157 */
- gpio-names = "cmt_apeslpx",
- "cmt_rst_rq",
- "cmt_en",
- "cmt_rst",
- "cmt_bsi";
- };
-};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/7] Convert MIPI HSI DT bindings to YAML
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
Hi,
This converts all MIPI HSI subystem DT bindings to YAML.
I ran the following tests:
1. Check binding files
make -j$(nproc) dt_binding_check DT_SCHEMA_FILES=/hsi/
2. Check OMAP3 and nokia-modem DT
make -j$(nproc) CHECK_DTBS=y ti/omap/omap3-n900.dtb ti/omap/omap3-n950.dtb ti/omap/omap3-n9.dtb
3. Check OMAP4 DT (OMAP4 HSI is not used upstream, so one is enough)
make -j$(nproc) CHECK_DTBS=y ti/omap/omap4-droid4-xt894.dtb
FWIW I noticed a lots of warnings for OMAP3 & OMAP4, but
none related to HSI/SSI.
Greetings,
-- Sebastian
---
Changes in v2:
- Link to v1: https://lore.kernel.org/r/20240325-hsi-dt-binding-v1-0-88e8e97c3aae@collabora.com
- fixed, that "hsi-client" is not a generic node name
- hsi-client.yaml needs to use oneOf instead of anyOf for the hsi-mode requirement
- change nokia-modem.yaml to nokia,modem.yaml
- add hsi-channel-ids constraints to nokia modem binding; I had to also add
$ref: /schemas/types.yaml#/definitions/uint32-array again, because otherwise
the tooling complained about the example DT having not enough IDs for
[[0], [1], [2], [3]]. It does properly inherit the hsi-client.yaml, though.
If I drop the constraints from the modem binding and change the generic binding
to require 5 IDs, the tooling does complain. So I think this is a bug in the DT
checking tool. For now readding the ref again seems to be a good enough workaround.
- changed node name to "modem" for the nokia modem
- renamed ti,ssi-cawake-gpio to ti,ssi-cawake-gpios
- changed ssi-port@ & hsi-port@ to just port@
- dropped blank line in omap-ssi binding
- moved additionalProperties before the examples in omap-ssi binding
- fixed indentation for the omaps-ssi example in the binding
- added patches fixing up OMAP3 & OMAP4 DT files according to the latest changes
---
Sebastian Reichel (7):
dt-bindings: hsi: hsi-client: convert to YAML
dt-bindings: hsi: nokia-modem: convert to YAML
dt-bindings: hsi: omap-ssi: convert to YAML
ARM: dts: omap4: fix hsi-port node name
ARM: dts: omap3: fix ssi-port node name
ARM: dts: omap3: fix ti,ssi-cawake-gpio property name
ARM: dts: omap3: use generic node name for hsi clients
.../devicetree/bindings/hsi/client-devices.txt | 44 -----
.../devicetree/bindings/hsi/hsi-client.yaml | 81 ++++++++++
.../devicetree/bindings/hsi/nokia,modem.yaml | 106 ++++++++++++
.../devicetree/bindings/hsi/nokia-modem.txt | 59 -------
Documentation/devicetree/bindings/hsi/omap-ssi.txt | 102 ------------
.../devicetree/bindings/hsi/ti,omap-ssi.yaml | 177 +++++++++++++++++++++
arch/arm/boot/dts/ti/omap/omap3-n900.dts | 4 +-
arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap3.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 +-
10 files changed, 372 insertions(+), 213 deletions(-)
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20240325-hsi-dt-binding-a5d662e3d601
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
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