* Re: [PATCH v6 2/4] ARM: dts: tegra: Fix unit_address_vs_reg DTC warnings for /memory
From: Krzysztof Kozlowski @ 2018-05-23 11:27 UTC (permalink / raw)
To: Stefan Agner
Cc: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel, Marcel Ziswiler,
Lucas Stach
In-Reply-To: <870361d2b9451af2e21cc570c8fca2c2@agner.ch>
On Wed, May 23, 2018 at 1:00 PM, Stefan Agner <stefan@agner.ch> wrote:
> On 23.05.2018 11:56, Krzysztof Kozlowski wrote:
>> Add a generic /memory node in each Tegra DTSI (with empty reg property,
>> to be overidden by each DTS) and set proper unit address for /memory
>> nodes to fix the DTC warnings:
>>
>> arch/arm/boot/dts/tegra20-harmony.dtb: Warning (unit_address_vs_reg):
>> /memory: node has a reg or ranges property, but no unit name
>>
>> The DTB after the change is the same as before except adding
>> unit-address to /memory node.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>>
>> ---
>>
>> Changes since v5:
>> 1. Split with skeleton.dtsi removal (suggested by Stefan).
>>
>> Changes since v4:
>> 1. None
>> ---
>> arch/arm/boot/dts/tegra114-dalmore.dts | 2 +-
>> arch/arm/boot/dts/tegra114-roth.dts | 2 +-
>> arch/arm/boot/dts/tegra114-tn7.dts | 2 +-
>> arch/arm/boot/dts/tegra114.dtsi | 3 ++-
>> arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi | 2 +-
>> arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +-
>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 2 +-
>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
>> arch/arm/boot/dts/tegra124-venice2.dts | 2 +-
>> arch/arm/boot/dts/tegra124.dtsi | 3 ++-
>> arch/arm/boot/dts/tegra20-colibri-512.dtsi | 2 +-
>> arch/arm/boot/dts/tegra20-harmony.dts | 2 +-
>> arch/arm/boot/dts/tegra20-paz00.dts | 2 +-
>> arch/arm/boot/dts/tegra20-seaboard.dts | 2 +-
>> arch/arm/boot/dts/tegra20-tamonten.dtsi | 2 +-
>> arch/arm/boot/dts/tegra20-trimslice.dts | 2 +-
>> arch/arm/boot/dts/tegra20-ventana.dts | 2 +-
>> arch/arm/boot/dts/tegra20.dtsi | 3 ++-
>> arch/arm/boot/dts/tegra30-apalis.dtsi | 4 ++--
>> arch/arm/boot/dts/tegra30-beaver.dts | 2 +-
>> arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +-
>> arch/arm/boot/dts/tegra30-colibri.dtsi | 2 +-
>> arch/arm/boot/dts/tegra30.dtsi | 3 ++-
>> 23 files changed, 28 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
>> b/arch/arm/boot/dts/tegra114-dalmore.dts
>> index eafff16765b4..1788556b4977 100644
>> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
>> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
>> @@ -23,7 +23,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@80000000 {
>> reg = <0x80000000 0x40000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra114-roth.dts
>> b/arch/arm/boot/dts/tegra114-roth.dts
>> index 7ed7370ee67a..3d3835591cd2 100644
>> --- a/arch/arm/boot/dts/tegra114-roth.dts
>> +++ b/arch/arm/boot/dts/tegra114-roth.dts
>> @@ -28,7 +28,7 @@
>> };
>> };
>>
>> - memory {
>> + memory@80000000 {
>> /* memory >= 0x79600000 is reserved for firmware usage */
>> reg = <0x80000000 0x79600000>;
>> };
>> diff --git a/arch/arm/boot/dts/tegra114-tn7.dts
>> b/arch/arm/boot/dts/tegra114-tn7.dts
>> index 7fc4a8b31e45..bfdd1bf61816 100644
>> --- a/arch/arm/boot/dts/tegra114-tn7.dts
>> +++ b/arch/arm/boot/dts/tegra114-tn7.dts
>> @@ -28,7 +28,7 @@
>> };
>> };
>>
>> - memory {
>> + memory@80000000 {
>> /* memory >= 0x37e00000 is reserved for firmware usage */
>> reg = <0x80000000 0x37e00000>;
>> };
>> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
>> index 27ef515e5640..aff4b8e115bc 100644
>> --- a/arch/arm/boot/dts/tegra114.dtsi
>> +++ b/arch/arm/boot/dts/tegra114.dtsi
>> @@ -11,8 +11,9 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> - memory {
>> + memory@80000000 {
>> device_type = "memory";
>> + reg = <0x80000000 0>;
>
> Nit: I'd rather prefer
>
> reg = <0x80000000 0x0>;
Sure.
>> };
>>
>> host1x@50000000 {
>> diff --git a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
>> b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
>> index bb67edb016c5..6a7f45651d38 100644
>> --- a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
>> +++ b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
>> @@ -15,7 +15,7 @@
>> compatible = "toradex,apalis-tk1-v1.2", "toradex,apalis-tk1",
>> "nvidia,tegra124";
>>
>> - memory {
>> + memory@0 {
>> reg = <0x0 0x80000000 0x0 0x80000000>;
>> };
>
> Unit address combines all address cells, so this should be 80000000
> here. See also the device tree spec (v0.2) which has an example in
> chapter 3.4 /memory node.
>
> So this should be:
>
> memory@80000000 {
> ...
>
> Same with all the board files below.
Ah, yes.
>>
>> diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi
>> b/arch/arm/boot/dts/tegra124-apalis.dtsi
>> index 65a2161b9b8e..e4625abd0a8a 100644
>> --- a/arch/arm/boot/dts/tegra124-apalis.dtsi
>> +++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
>> @@ -50,7 +50,7 @@
>> model = "Toradex Apalis TK1";
>> compatible = "toradex,apalis-tk1", "nvidia,tegra124";
>>
>> - memory {
>> + memory@0 {
>> reg = <0x0 0x80000000 0x0 0x80000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> index 6dbcf84dafbc..e23b1159e8fd 100644
>> --- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> +++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> @@ -24,7 +24,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x0 0x80000000 0x0 0x80000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi
>> b/arch/arm/boot/dts/tegra124-nyan.dtsi
>> index 3609367037a6..f45ac668d88c 100644
>> --- a/arch/arm/boot/dts/tegra124-nyan.dtsi
>> +++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
>> @@ -13,7 +13,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x0 0x80000000 0x0 0x80000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts
>> b/arch/arm/boot/dts/tegra124-venice2.dts
>> index 89bcc178994d..44492b48e165 100644
>> --- a/arch/arm/boot/dts/tegra124-venice2.dts
>> +++ b/arch/arm/boot/dts/tegra124-venice2.dts
>> @@ -18,7 +18,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x0 0x80000000 0x0 0x80000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
>> index 951feea784af..ad9c9cd6fa8a 100644
>> --- a/arch/arm/boot/dts/tegra124.dtsi
>> +++ b/arch/arm/boot/dts/tegra124.dtsi
>> @@ -13,8 +13,9 @@
>> #address-cells = <2>;
>> #size-cells = <2>;
>>
>> - memory {
>> + memory@0 {
>> device_type = "memory";
>> + reg = <0 0>;
>> };
>
> This should have two address and two size cells I guess. And DDR for all
> TK1 start at 0x0 0x80000000...
>
> So here with a default length of 0:
>
> memory@80000000 {
> reg = <0x0 0x80000000 0x0 0x0>;
> };
Yes, right.
>>
>> pcie@1003000 {
>> diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
>> b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
>> index 5c202b3e3bb1..5623ff8d128c 100644
>> --- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
>> +++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
>> @@ -10,7 +10,7 @@
>> rtc1 = "/rtc@7000e000";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x00000000 0x20000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra20-harmony.dts
>> b/arch/arm/boot/dts/tegra20-harmony.dts
>> index 628a55a9318b..1d96d92b72a7 100644
>> --- a/arch/arm/boot/dts/tegra20-harmony.dts
>> +++ b/arch/arm/boot/dts/tegra20-harmony.dts
>> @@ -18,7 +18,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x00000000 0x40000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
>> b/arch/arm/boot/dts/tegra20-paz00.dts
>> index 30436969adc0..ef245291924f 100644
>> --- a/arch/arm/boot/dts/tegra20-paz00.dts
>> +++ b/arch/arm/boot/dts/tegra20-paz00.dts
>> @@ -19,7 +19,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x00000000 0x20000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
>> b/arch/arm/boot/dts/tegra20-seaboard.dts
>> index 284aae351ff2..f91441683aad 100644
>> --- a/arch/arm/boot/dts/tegra20-seaboard.dts
>> +++ b/arch/arm/boot/dts/tegra20-seaboard.dts
>> @@ -18,7 +18,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x00000000 0x40000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi
>> b/arch/arm/boot/dts/tegra20-tamonten.dtsi
>> index 872046d48709..20137fc578b1 100644
>> --- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
>> +++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
>> @@ -15,7 +15,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x00000000 0x20000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts
>> b/arch/arm/boot/dts/tegra20-trimslice.dts
>> index d55c6b240a30..9eb26dc15f6b 100644
>> --- a/arch/arm/boot/dts/tegra20-trimslice.dts
>> +++ b/arch/arm/boot/dts/tegra20-trimslice.dts
>> @@ -18,7 +18,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x00000000 0x40000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
>> b/arch/arm/boot/dts/tegra20-ventana.dts
>> index ee3fbf941e79..f44551e2d9d0 100644
>> --- a/arch/arm/boot/dts/tegra20-ventana.dts
>> +++ b/arch/arm/boot/dts/tegra20-ventana.dts
>> @@ -18,7 +18,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@0 {
>> reg = <0x00000000 0x40000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
>> index 88dd1afb5877..55581c0e5105 100644
>> --- a/arch/arm/boot/dts/tegra20.dtsi
>> +++ b/arch/arm/boot/dts/tegra20.dtsi
>> @@ -13,8 +13,9 @@
>> chosen { };
>> aliases { };
>>
>> - memory {
>> + memory@0 {
>> device_type = "memory";
>> + reg = <0 0>;
>> };
>>
>> iram@40000000 {
>> diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi
>> b/arch/arm/boot/dts/tegra30-apalis.dtsi
>> index 6f29cbad6e8a..9465fc592b7b 100644
>> --- a/arch/arm/boot/dts/tegra30-apalis.dtsi
>> +++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
>> @@ -10,8 +10,8 @@
>> model = "Toradex Apalis T30";
>> compatible = "toradex,apalis_t30", "nvidia,tegra30";
>>
>> - memory {
>> - reg = <0 0>;
>> + memory@80000000 {
>> + reg = <0x80000000 0x40000000>;
>> };
>>
>> pcie@3000 {
>> diff --git a/arch/arm/boot/dts/tegra30-beaver.dts
>> b/arch/arm/boot/dts/tegra30-beaver.dts
>> index ae52a5039506..1434d50438f9 100644
>> --- a/arch/arm/boot/dts/tegra30-beaver.dts
>> +++ b/arch/arm/boot/dts/tegra30-beaver.dts
>> @@ -17,7 +17,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@80000000 {
>> reg = <0x80000000 0x7ff00000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi
>> b/arch/arm/boot/dts/tegra30-cardhu.dtsi
>> index 92a9740c533f..33b73dca16a3 100644
>> --- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
>> +++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
>> @@ -40,7 +40,7 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> - memory {
>> + memory@80000000 {
>> reg = <0x80000000 0x40000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi
>> b/arch/arm/boot/dts/tegra30-colibri.dtsi
>> index c44d8c40c410..9bf3327665d3 100644
>> --- a/arch/arm/boot/dts/tegra30-colibri.dtsi
>> +++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
>> @@ -10,7 +10,7 @@
>> model = "Toradex Colibri T30";
>> compatible = "toradex,colibri_t30", "nvidia,tegra30";
>>
>> - memory {
>> + memory@80000000 {
>> reg = <0x80000000 0x40000000>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
>> index 19237c08c166..2b6243b0c6d6 100644
>> --- a/arch/arm/boot/dts/tegra30.dtsi
>> +++ b/arch/arm/boot/dts/tegra30.dtsi
>> @@ -14,8 +14,9 @@
>> chosen { };
>> aliases { };
>>
>> - memory {
>> + memory@80000000 {
>> device_type = "memory";
>> + reg = <0x80000000 0>;
>
> Nit: for consistency sake, 0x0 :-)
Sure, thanks for review!
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
From: Viresh Kumar @ 2018-05-23 11:31 UTC (permalink / raw)
To: Ilia Lin
Cc: Sudeep Holla, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Mark Rutland, Rafael J. Wysocki,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <002901d3f286$198878b0$4c996a10$@codeaurora.org>
On 23 May 2018 at 16:36, <ilialin@codeaurora.org> wrote:
>
>
>> -----Original Message-----
>> From: Sudeep Holla <sudeep.holla@arm.com>
>> Sent: Wednesday, May 23, 2018 13:40
>> To: Ilia Lin <ilialin@codeaurora.org>; vireshk@kernel.org; nm@ti.com;
>> sboyd@kernel.org; robh@kernel.org; mark.rutland@arm.com;
>> rjw@rjwysocki.net; linux-pm@vger.kernel.org; devicetree@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Subject: Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
>>
>>
>>
>> On 23/05/18 10:40, Ilia Lin wrote:
>> > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO
>> > processors, the CPU frequency subset and voltage value of each OPP
>> > varies based on the silicon variant in use. Qualcomm Process Voltage
>> > Scaling Tables defines the voltage and frequency value based on the
>> > msm-id in SMEM and speedbin blown in the efuse combination.
>> > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the
>> > SoC to provide the OPP framework with required information.
>> > This is used to determine the voltage and frequency value for each OPP
>> > of
>> > operating-points-v2 table when it is parsed by the OPP framework.
>> >
>> > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
>>
>> [...]
>>
>> > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
>> > + if (!IS_ERR(pdev))
>> > + return 0;
>> > +
>> > + ret = PTR_ERR(pdev);
>> > + dev_err(cpu_dev, "Failed to register platform device\n");
>> > +
>> > +free_opp:
>> > + for_each_possible_cpu(cpu) {
>> > + if (IS_ERR_OR_NULL(opp_tables[cpu]))
>> > + break;
>> > + dev_pm_opp_put_supported_hw(opp_tables[cpu]);
>> > + }
>> > +free_np:
>> > + of_node_put(np);
>> > +
>> > + return ret;
>> > +}
>> > +late_initcall(qcom_cpufreq_kryo_driver_init);
>>
>> Any particular reason why this *has* to be late initcall ?
>> Please change it to module_initcall otherwise.
>
> The purpose is to give the cpufreq-dt the time to register the driver and only then my driver will add the platform device.
That isn't required, the device and its driver can be registered in any order.
^ permalink raw reply
* Re: [PATCH V2 1/2] dt-bindings: mtd: document Broadcom's BCM47xx partitions
From: Boris Brezillon @ 2018-05-23 11:34 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Jonas Gorski, Marek Vasut, Rob Herring, linux-mtd,
Cyrille Pitchen, Rafał Miłecki, Brian Norris,
David Woodhouse
In-Reply-To: <20180509081729.28347-1-zajec5@gmail.com>
On Wed, 9 May 2018 10:17:28 +0200
Rafał Miłecki <zajec5@gmail.com> wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Broadcom based home router devices use partitions which have to be
> discovered in a specific way. They are not fixed and there is not any
> standard partition table. This commit adds and describes a new custom
> binding for such devices.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Applied both.
Thanks,
Boris
> ---
> This commit documents a new binding for describing partitions. Just as a
> reminder: we agreed to use "compatible" for that purpose to avoid
> /guessing/. There are too many cases, devices and /formats/ to just
> blindly try every possible parser.
>
> This was e.g. described by Boris in his patchset 2+ years ago:
> [RFC PATCH 0/7] mtd: partitions: add of_match_table support
> http://lists.infradead.org/pipermail/linux-mtd/2015-December/064076.html
>
> Quote:
> > (2) we can't just scan for all supported parsers (like the block system does), since
> > there is a wide diversity of "formats" (no standardization), and it is not
> > always safe or efficient to attempt to do so, particularly since many of
> > them allow their data structures to be placed anywhere on the flash, and
> > so require scanning the entire flash device to find them.
>
> I believe this solution was also acked back then by Rob:
> [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding
> http://lists.infradead.org/pipermail/linux-mtd/2015-December/064100.html
>
> V2: Move documentation to the new brcm,bcm947xx-cfe-partitions.txt file
> as suggested by Rob (we don't want to bloat partition.txt).
> Slightly update commit message.
> ---
> .../devicetree/bindings/mtd/partition.txt | 2 +-
> .../partitions/brcm,bcm947xx-cfe-partitions.txt | 42 ++++++++++++++++++++++
> 2 files changed, 43 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
> index 36f3b769a626..a8f382642ba9 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -14,7 +14,7 @@ method is used for a given flash device. To describe the method there should be
> a subnode of the flash device that is named 'partitions'. It must have a
> 'compatible' property, which is used to identify the method to use.
>
> -We currently only document a binding for fixed layouts.
> +Available bindings are listed in the "partitions" subdirectory.
>
>
> Fixed Partitions
> diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt
> new file mode 100644
> index 000000000000..1d61a029395e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt
> @@ -0,0 +1,42 @@
> +Broadcom BCM47xx Partitions
> +===========================
> +
> +Broadcom is one of hardware manufacturers providing SoCs (BCM47xx) used in
> +home routers. Their BCM947xx boards using CFE bootloader have several partitions
> +without any on-flash partition table. On some devices their sizes and/or
> +meanings can also vary so fixed partitioning can't be used.
> +
> +Discovering partitions on these devices is possible thanks to having a special
> +header and/or magic signature at the beginning of each of them. They are also
> +block aligned which is important for determinig a size.
> +
> +Most of partitions use ASCII text based magic for determining a type. More
> +complex partitions (like TRX with its HDR0 magic) may include extra header
> +containing some details, including a length.
> +
> +A list of supported partitions includes:
> +1) Bootloader with Broadcom's CFE (Common Firmware Environment)
> +2) NVRAM with configuration/calibration data
> +3) Device manufacturer's data with some default values (e.g. SSIDs)
> +4) TRX firmware container which can hold up to 4 subpartitions
> +5) Backup TRX firmware used after failed upgrade
> +
> +As mentioned earlier, role of some partitions may depend on extra configuration.
> +For example both: main firmware and backup firmware use the same TRX format with
> +the same header. To distinguish currently used firmware a CFE's environment
> +variable "bootpartition" is used.
> +
> +
> +Devices using Broadcom partitions described above should should have flash node
> +with a subnode named "partitions" using following properties:
> +
> +Required properties:
> +- compatible : (required) must be "brcm,bcm947xx-cfe-partitions"
> +
> +Example:
> +
> +flash@0 {
> + partitions {
> + compatible = "brcm,bcm947xx-cfe-partitions";
> + };
> +};
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* RE: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
From: ilialin @ 2018-05-23 11:34 UTC (permalink / raw)
To: 'Viresh Kumar', 'Sudeep Holla'
Cc: 'Viresh Kumar', 'Nishanth Menon',
'Stephen Boyd', 'Rob Herring',
'Mark Rutland', 'Rafael J. Wysocki', linux-pm,
devicetree, 'Linux Kernel Mailing List'
In-Reply-To: <CAKohponbpErCeTYu9iQm_-dupz5SUr+TKsYXzqmmARB-pq95iA@mail.gmail.com>
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Wednesday, May 23, 2018 14:31
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Viresh Kumar
> <vireshk@kernel.org>; Nishanth Menon <nm@ti.com>; Stephen Boyd
> <sboyd@kernel.org>; Rob Herring <robh@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; Rafael J. Wysocki <rjw@rjwysocki.net>; linux-
> pm@vger.kernel.org; devicetree@vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
>
> On 23 May 2018 at 16:36, <ilialin@codeaurora.org> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Sudeep Holla <sudeep.holla@arm.com>
> >> Sent: Wednesday, May 23, 2018 13:40
> >> To: Ilia Lin <ilialin@codeaurora.org>; vireshk@kernel.org; nm@ti.com;
> >> sboyd@kernel.org; robh@kernel.org; mark.rutland@arm.com;
> >> rjw@rjwysocki.net; linux-pm@vger.kernel.org;
> >> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> >> Cc: Sudeep Holla <sudeep.holla@arm.com>
> >> Subject: Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
> >>
> >>
> >>
> >> On 23/05/18 10:40, Ilia Lin wrote:
> >> > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO
> >> > processors, the CPU frequency subset and voltage value of each OPP
> >> > varies based on the silicon variant in use. Qualcomm Process
> >> > Voltage Scaling Tables defines the voltage and frequency value
> >> > based on the msm-id in SMEM and speedbin blown in the efuse
> combination.
> >> > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from
> >> > the SoC to provide the OPP framework with required information.
> >> > This is used to determine the voltage and frequency value for each
> >> > OPP of
> >> > operating-points-v2 table when it is parsed by the OPP framework.
> >> >
> >> > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> >>
> >> [...]
> >>
> >> > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> >> > + if (!IS_ERR(pdev))
> >> > + return 0;
> >> > +
> >> > + ret = PTR_ERR(pdev);
> >> > + dev_err(cpu_dev, "Failed to register platform device\n");
> >> > +
> >> > +free_opp:
> >> > + for_each_possible_cpu(cpu) {
> >> > + if (IS_ERR_OR_NULL(opp_tables[cpu]))
> >> > + break;
> >> > + dev_pm_opp_put_supported_hw(opp_tables[cpu]);
> >> > + }
> >> > +free_np:
> >> > + of_node_put(np);
> >> > +
> >> > + return ret;
> >> > +}
> >> > +late_initcall(qcom_cpufreq_kryo_driver_init);
> >>
> >> Any particular reason why this *has* to be late initcall ?
> >> Please change it to module_initcall otherwise.
> >
> > The purpose is to give the cpufreq-dt the time to register the driver and
> only then my driver will add the platform device.
>
> That isn't required, the device and its driver can be registered in any order.
You are right. I already checked that in the code...
However, with module_init() the driver fails on reading the nvmem.
^ permalink raw reply
* Re: [PATCH v6 4/4] ARM: dts: tegra: Work safely with 256 MB Colibri-T20 modules
From: Stefan Agner @ 2018-05-23 11:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel, Marcel Ziswiler,
Lucas Stach
In-Reply-To: <1527069406-6359-4-git-send-email-krzk@kernel.org>
On 23.05.2018 11:56, Krzysztof Kozlowski wrote:
> Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB RAM
> (with 1024 MB NAND) flavors. Both of them will use the same DTSI
> expecting the bootloader to do the fixup of /memory node. However in
> case it does not happen, let's stay on safe side by limiting the memory
> to 256 MB for both versions of Colibri-T20.
>
Maybe also mention the renaming stuff:
"Rename to remove the unnecessary memory size from the device tree file
name. While at it, also follow the typical Toradex SoC, module, carrier
board hierarchy."
--
Stefan
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> RFT:
> Not tested on 512 MB module as I have only the 256 MB one.
>
> Changes since v5:
> 1. Add "colibri" suffix to iris DTS (suggested by Stefan).
>
> Changes since v4:
> 1. Drop the 512 suffix from file names (suggested by Stefan).
>
> Changes since v3:
> 1. Reduce the memory in existing DTSI instead of creating a new one
> (suggested by Marcel).
>
> Changes since v2:
> 1. Do not add new compatible but use everywhere existing
> "toradex,colibri_t20-512" (suggested by Rob).
>
> Changes since v1:
> 1. Fix memory size in tegra20-colibri-256.dtsi (was working fine because
> my bootloader uses mem= argument).
> ---
> arch/arm/boot/dts/Makefile | 2 +-
> .../boot/dts/{tegra20-iris-512.dts => tegra20-colibri-iris.dts} | 4 ++--
> .../boot/dts/{tegra20-colibri-512.dtsi => tegra20-colibri.dtsi} | 9 +++++++--
> 3 files changed, 10 insertions(+), 5 deletions(-)
> rename arch/arm/boot/dts/{tegra20-iris-512.dts =>
> tegra20-colibri-iris.dts} (95%)
> rename arch/arm/boot/dts/{tegra20-colibri-512.dtsi =>
> tegra20-colibri.dtsi} (98%)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ec2024ea8b1e..1c8bb55c0948 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1030,7 +1030,7 @@ dtb-$(CONFIG_ARCH_TANGO) += \
> tango4-vantage-1172.dtb
> dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
> tegra20-harmony.dtb \
> - tegra20-iris-512.dtb \
> + tegra20-colibri-iris.dtb \
> tegra20-medcom-wide.dtb \
> tegra20-paz00.dtb \
> tegra20-plutux.dtb \
> diff --git a/arch/arm/boot/dts/tegra20-iris-512.dts
> b/arch/arm/boot/dts/tegra20-colibri-iris.dts
> similarity index 95%
> rename from arch/arm/boot/dts/tegra20-iris-512.dts
> rename to arch/arm/boot/dts/tegra20-colibri-iris.dts
> index 40126388946d..57f16c0e9917 100644
> --- a/arch/arm/boot/dts/tegra20-iris-512.dts
> +++ b/arch/arm/boot/dts/tegra20-colibri-iris.dts
> @@ -1,10 +1,10 @@
> // SPDX-License-Identifier: GPL-2.0
> /dts-v1/;
>
> -#include "tegra20-colibri-512.dtsi"
> +#include "tegra20-colibri.dtsi"
>
> / {
> - model = "Toradex Colibri T20 512MB on Iris";
> + model = "Toradex Colibri T20 256/512 MB on Iris";
> compatible = "toradex,iris", "toradex,colibri_t20-512", "nvidia,tegra20";
>
> aliases {
> diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> b/arch/arm/boot/dts/tegra20-colibri.dtsi
> similarity index 98%
> rename from arch/arm/boot/dts/tegra20-colibri-512.dtsi
> rename to arch/arm/boot/dts/tegra20-colibri.dtsi
> index 5623ff8d128c..dc06b23183e1 100644
> --- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> +++ b/arch/arm/boot/dts/tegra20-colibri.dtsi
> @@ -2,7 +2,7 @@
> #include "tegra20.dtsi"
>
> / {
> - model = "Toradex Colibri T20 512MB";
> + model = "Toradex Colibri T20 256/512 MB";
> compatible = "toradex,colibri_t20-512", "nvidia,tegra20";
>
> aliases {
> @@ -11,7 +11,12 @@
> };
>
> memory@0 {
> - reg = <0x00000000 0x20000000>;
> + /*
> + * Set memory to 256 MB to be safe as this could be used on
> + * 256 or 512 MB module. It is expected from bootloader
> + * to fix this up for 512 MB version.
> + */
> + reg = <0x00000000 0x10000000>;
> };
>
> host1x@50000000 {
^ permalink raw reply
* Re: [PATCH v6 4/4] ARM: dts: tegra: Work safely with 256 MB Colibri-T20 modules
From: Krzysztof Kozlowski @ 2018-05-23 11:38 UTC (permalink / raw)
To: Stefan Agner
Cc: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel, Marcel Ziswiler,
Lucas Stach
In-Reply-To: <a8969b297da304c292e6587fba7fcc23@agner.ch>
On Wed, May 23, 2018 at 1:35 PM, Stefan Agner <stefan@agner.ch> wrote:
> On 23.05.2018 11:56, Krzysztof Kozlowski wrote:
>> Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB RAM
>> (with 1024 MB NAND) flavors. Both of them will use the same DTSI
>> expecting the bootloader to do the fixup of /memory node. However in
>> case it does not happen, let's stay on safe side by limiting the memory
>> to 256 MB for both versions of Colibri-T20.
>>
>
> Maybe also mention the renaming stuff:
>
> "Rename to remove the unnecessary memory size from the device tree file
> name. While at it, also follow the typical Toradex SoC, module, carrier
> board hierarchy."
Since I am going to resend it for v7... no problem.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
From: Viresh Kumar @ 2018-05-23 11:46 UTC (permalink / raw)
To: Ilia Lin
Cc: Sudeep Holla, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Mark Rutland, Rafael J. Wysocki,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <002b01d3f28a$0d033900$2709ab00$@codeaurora.org>
On 23 May 2018 at 17:04, <ilialin@codeaurora.org> wrote:
> You are right. I already checked that in the code...
> However, with module_init() the driver fails on reading the nvmem.
And why is it failing ?
^ permalink raw reply
* Re: [PATCH v7 1/3] gpio: pca953x: set the PCA_PCAL flag also when matching by DT
From: Linus Walleij @ 2018-05-23 11:46 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Kumar Gala, Andy Shevchenko, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Alexandre Courbot,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Discussions about the Letux Kernel, kernel
In-Reply-To: <7c9ab1d702eb62755993321865d260fa54b90358.1526533188.git.hns@goldelico.com>
On Thu, May 17, 2018 at 6:59 AM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
> The of_device_table is missing the PCA_PCAL flag so the
> pcal6524 would be operated in tca6424 compatibility mode which
> does not handle the new interrupt mask registers.
>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
From: ilialin @ 2018-05-23 11:47 UTC (permalink / raw)
To: 'Viresh Kumar'
Cc: 'Sudeep Holla', 'Viresh Kumar',
'Nishanth Menon', 'Stephen Boyd',
'Rob Herring', 'Mark Rutland',
'Rafael J. Wysocki', linux-pm, devicetree,
'Linux Kernel Mailing List'
In-Reply-To: <CAKohponruWpcjuSDg-=ZbZ1=qm2iPZs36mfKYJ3nQZREkc3JCw@mail.gmail.com>
The nvmem will return EPROBE_DEFER, and so will my driver's init. But then no one will call the init again.
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Wednesday, May 23, 2018 14:46
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Viresh Kumar
> <vireshk@kernel.org>; Nishanth Menon <nm@ti.com>; Stephen Boyd
> <sboyd@kernel.org>; Rob Herring <robh@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; Rafael J. Wysocki <rjw@rjwysocki.net>; linux-
> pm@vger.kernel.org; devicetree@vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
>
> On 23 May 2018 at 17:04, <ilialin@codeaurora.org> wrote:
> > You are right. I already checked that in the code...
> > However, with module_init() the driver fails on reading the nvmem.
>
> And why is it failing ?
^ permalink raw reply
* Re: [PATCH v7 2/3] gpio: pca953x: define masks for addressing common and extended registers
From: Linus Walleij @ 2018-05-23 11:47 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Kumar Gala, Andy Shevchenko, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Alexandre Courbot,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Discussions about the Letux Kernel, kernel
In-Reply-To: <2fe132b534a4b1ca717932e78cc3cdae5aacba0d.1526533188.git.hns@goldelico.com>
On Thu, May 17, 2018 at 6:59 AM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
> These mask bits are to be used to map the extended register
> addreseses (which are defined for an unsupported 8-bit pcal chip)
> to 16 and 24 bit chips (pcal6524).
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Robin Murphy @ 2018-05-23 11:48 UTC (permalink / raw)
To: Scott Branden, Ray Jui, Guenter Roeck
Cc: Mark Rutland, devicetree, linux-watchdog, Catalin Marinas,
Will Deacon, linux-kernel, Rob Herring, bcm-kernel-feedback-list,
Wim Van Sebroeck, Frank Rowand, linux-arm-kernel
In-Reply-To: <00c121ea-d197-93b8-2f56-bcca963f70fb@broadcom.com>
On 23/05/18 08:52, Scott Branden wrote:
>
>
> On 18-05-22 04:24 PM, Ray Jui wrote:
>> Hi Guenter,
>>
>> On 5/22/2018 1:54 PM, Guenter Roeck wrote:
>>> On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
>>>> If the watchdog hardware is already enabled during the boot process,
>>>> when the Linux watchdog driver loads, it should reset the watchdog and
>>>> tell the watchdog framework. As a result, ping can be generated from
>>>> the watchdog framework, until the userspace watchdog daemon takes over
>>>> control
>>>>
>>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>>> Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
>>>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>>>> ---
>>>> drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
>>>> 1 file changed, 22 insertions(+)
>>>>
>>>> diff --git a/drivers/watchdog/sp805_wdt.c
>>>> b/drivers/watchdog/sp805_wdt.c
>>>> index 1484609..408ffbe 100644
>>>> --- a/drivers/watchdog/sp805_wdt.c
>>>> +++ b/drivers/watchdog/sp805_wdt.c
>>>> @@ -42,6 +42,7 @@
>>>> /* control register masks */
>>>> #define INT_ENABLE (1 << 0)
>>>> #define RESET_ENABLE (1 << 1)
>>>> + #define ENABLE_MASK (INT_ENABLE | RESET_ENABLE)
>>>> #define WDTINTCLR 0x00C
>>>> #define WDTRIS 0x010
>>>> #define WDTMIS 0x014
>>>> @@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
>>>> MODULE_PARM_DESC(nowayout,
>>>> "Set to 1 to keep watchdog running after device release");
>>>> +/* returns true if wdt is running; otherwise returns false */
>>>> +static bool wdt_is_running(struct watchdog_device *wdd)
>>>> +{
>>>> + struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>>>> +
>>>> + if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
>>>> + ENABLE_MASK)
>>>> + return true;
>>>> + else
>>>> + return false;
>>>
>>> return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
>>>
>>
>> Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE);
>> therefore, a simple !!(expression) would not work? That is, the masked
>> result needs to be compared against the mask again to ensure both bits
>> are set, right?
> Ray - your original code looks correct to me. Easier to read and less
> prone to errors as shown in the attempted translation to a single
> statement.
if (<boolean condition>)
return true;
else
return false;
still looks really dumb, though, and IMO is actually harder to read than
just "return <boolean condition>;" because it forces you to stop and
double-check that the logic is, in fact, only doing the obvious thing.
Robin.
p.s. No thanks for making me remember the mind-boggling horror of
briefly maintaining part of this legacy codebase... :P
$ grep -r '? true : false' --include=*.cpp . | wc -l
951
^ permalink raw reply
* Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524
From: Linus Walleij @ 2018-05-23 11:48 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Kumar Gala, Andy Shevchenko, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Alexandre Courbot,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Discussions about the Letux Kernel, kernel
In-Reply-To: <e70e83f07aebaf702fef90a9fac61e41d8b558b0.1526533188.git.hns@goldelico.com>
On Thu, May 17, 2018 at 6:59 AM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
> The register constants are so far defined in a way that they fit
> for the pcal9555a when shifted by the number of banks, i.e. are
> multiplied by 2 in the accessor function.
>
> Now, the pcal6524 has 3 banks which means the relative offset
> is multiplied by 4 for the standard registers.
>
> Simply applying the bit shift to the extended registers gives
> a wrong result, since the base offset is already included in
> the offset.
>
> Therefore, we have to add code to the 24 bit accessor functions
> that adjusts the register number for these exended registers.
>
> The formula finally used was developed and proposed by
> Andy Shevchenko <andy.shevchenko@gmail.com>.
>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
From: Viresh Kumar @ 2018-05-23 11:51 UTC (permalink / raw)
To: Ilia Lin
Cc: Sudeep Holla, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Mark Rutland, Rafael J. Wysocki,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <002d01d3f28b$d3ce3980$7b6aac80$@codeaurora.org>
On 23 May 2018 at 17:17, <ilialin@codeaurora.org> wrote:
> The nvmem will return EPROBE_DEFER, and so will my driver's init. But then no one will call the init again.
So even your driver needs to be registered as a platform driver then
and you can create its device
from the init function, and add a comment on why you create the
platform device in the driver itself.
--
viresh
^ permalink raw reply
* [PATCH v9 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
From: Dan Murphy @ 2018-05-23 11:51 UTC (permalink / raw)
To: robh+dt, mark.rutland, jacek.anaszewski, andy.shevchenko
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v9 - No changes - https://patchwork.kernel.org/patch/10418729/
v8 - No changes - https://patchwork.kernel.org/patch/10416161/
v7 - Removed led-sources in favor of reg, fixed malformatted ranges - https://patchwork.kernel.org/patch/10401435/
v6 - Removed multiple led child nodes, fixed example to display micro ranges
for corresponding child nodes and added led-sources to define the current driver -
https://patchwork.kernel.org/patch/10392121/
v5 - No changes - https://patchwork.kernel.org/patch/10391743/
v4 - Added " " around "=", changed strobe to flash on label, removed "support and
register" comment and change ir lable to ir:torch - See v2 patchworks for comments
v3 - Removed wildcard compatible - https://patchwork.kernel.org/patch/10386241/
v2 - No changes - https://patchwork.kernel.org/patch/10384587/
.../devicetree/bindings/leds/leds-lm3601x.txt | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3601x.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
new file mode 100644
index 000000000000..a88b2c41e75b
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
@@ -0,0 +1,45 @@
+* Texas Instruments - lm3601x Single-LED Flash Driver
+
+The LM3601X are ultra-small LED flash drivers that
+provide a high level of adjustability.
+
+Required properties:
+ - compatible : Can be one of the following
+ "ti,lm36010"
+ "ti,lm36011"
+ - reg : I2C slave address
+ - #address-cells : 1
+ - #size-cells : 0
+
+Required child properties:
+ - reg : 0 - Indicates a IR mode
+ 1 - Indicates a Torch (white LED) mode
+
+Required properties for flash LED child nodes:
+ See Documentation/devicetree/bindings/leds/common.txt
+ - flash-max-microamp : Range from 11mA - 1.5A
+ - flash-max-timeout-us : Range from 40ms - 1600ms
+ - led-max-microamp : Range from 2.4mA - 376mA
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+led-controller@64 {
+ compatible = "ti,lm36010";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x64>;
+
+ led@0 {
+ reg = <1>;
+ label = "white:torch";
+ led-max-microamp = <376000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <1600000>;
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
2.17.0.582.gccdcbd54c
^ permalink raw reply related
* [PATCH v9 2/2] leds: lm3601x: Introduce the lm3601x LED driver
From: Dan Murphy @ 2018-05-23 11:51 UTC (permalink / raw)
To: robh+dt, mark.rutland, jacek.anaszewski, andy.shevchenko
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
In-Reply-To: <20180523115129.21674-1-dmurphy@ti.com>
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED driver can be configured with a strobe
timer to execute a strobe flash. The IR LED
brightness is controlled via the torch brightness
register.
The data sheet for each the LM36010 and LM36011
LED drivers can be found here:
http://www.ti.com/product/LM36010
http://www.ti.com/product/LM36011
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v9 - Changed "strobe" to flash in some cases, removed some redundant variable
assignments, updated a couple of line to make them more readable, converted to
probe_new from old probe, and change err to ret - https://patchwork.kernel.org/patch/10418731/
v8 - Removed OF Kconfig dependency, change strobe to flash, updated label generation,
fixed brightness calculation, added mutex_destroy and flash_unregister - https://patchwork.kernel.org/patch/10416163/
v7 - Numerous fixes to many to list. Highlights are moved from OF APIs to device_property
APIs, updated LED registration, timeout to reg algorithim, and fixed label generation -
https://patchwork.kernel.org/patch/10401437/
v6 - This driver has been heavily modified from v5. There is no longer reading
of individual child nodes. There are too many changes to list here see -
https://patchwork.kernel.org/patch/10392123/
v5 - Fixed magic numbers, change reg cache type, added of_put_node to release
the dt node ref, and I did not change the remove function to leave the LED in its
state on driver removal - https://patchwork.kernel.org/patch/10391741/
v4 - Fixed Cocci issue using ARRAY_SIZE - https://patchwork.kernel.org/patch/10389259/
v3 - removed wildcard dt compatible, fixed copyright, fixed struct doc, removed
RO registers from default, added regmap volatile for FLAGS_REG, updated regmap cache type,
fixed unlock and extra semi colon in strobe_set, removed unnecessary out label
in led register and fixed checking of the ret in brightness_set - https://patchwork.kernel.org/patch/10386243/
v2 - Fixed kbuild issue and removed unused cdev_strobe - https://patchwork.kernel.org/patch/10384585/
drivers/leds/Kconfig | 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3601x.c | 487 ++++++++++++++++++++++++++++++++++++
3 files changed, 497 insertions(+)
create mode 100644 drivers/leds/leds-lm3601x.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2c896c0e69e1..d95d436e6089 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -145,6 +145,15 @@ config LEDS_LM3692X
This option enables support for the TI LM3692x family
of white LED string drivers used for backlighting.
+config LEDS_LM3601X
+ tristate "LED support for LM3601x Chips"
+ depends on LEDS_CLASS && I2C
+ depends on LEDS_CLASS_FLASH
+ select REGMAP_I2C
+ help
+ This option enables support for the TI LM3601x family
+ of flash, torch and indicator classes.
+
config LEDS_LOCOMO
tristate "LED Support for Locomo device"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 91eca81cae82..b79807fe1b67 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
+obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c
new file mode 100644
index 000000000000..081aa71e43a3
--- /dev/null
+++ b/drivers/leds/leds-lm3601x.c
@@ -0,0 +1,487 @@
+// SPDX-License-Identifier: GPL-2.0
+// Flash and torch driver for Texas Instruments LM3601X LED
+// Flash driver chip family
+// Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/leds.h>
+#include <linux/led-class-flash.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <uapi/linux/uleds.h>
+
+#define LM3601X_LED_IR 0x0
+#define LM3601X_LED_TORCH 0x1
+
+/* Registers */
+#define LM3601X_ENABLE_REG 0x01
+#define LM3601X_CFG_REG 0x02
+#define LM3601X_LED_FLASH_REG 0x03
+#define LM3601X_LED_TORCH_REG 0x04
+#define LM3601X_FLAGS_REG 0x05
+#define LM3601X_DEV_ID_REG 0x06
+
+#define LM3601X_SW_RESET BIT(7)
+
+/* Enable Mode bits */
+#define LM3601X_MODE_STANDBY 0x00
+#define LM3601X_MODE_IR_DRV BIT(0)
+#define LM3601X_MODE_TORCH BIT(1)
+#define LM3601X_MODE_STROBE (BIT(0) | BIT(1))
+#define LM3601X_STRB_EN BIT(2)
+#define LM3601X_STRB_EDGE_TRIG BIT(3)
+#define LM3601X_IVFM_EN BIT(4)
+
+#define LM36010_BOOST_LIMIT_28 BIT(5)
+#define LM36010_BOOST_FREQ_4MHZ BIT(6)
+#define LM36010_BOOST_MODE_PASS BIT(7)
+
+/* Flag Mask */
+#define LM3601X_FLASH_TIME_OUT BIT(0)
+#define LM3601X_UVLO_FAULT BIT(1)
+#define LM3601X_THERM_SHUTDOWN BIT(2)
+#define LM3601X_THERM_CURR BIT(3)
+#define LM36010_CURR_LIMIT BIT(4)
+#define LM3601X_SHORT_FAULT BIT(5)
+#define LM3601X_IVFM_TRIP BIT(6)
+#define LM36010_OVP_FAULT BIT(7)
+
+#define LM3601X_MAX_TORCH_I_UA 376000
+#define LM3601X_MIN_TORCH_I_UA 2400
+#define LM3601X_TORCH_REG_DIV 2965
+
+#define LM3601X_MAX_STROBE_I_UA 1500000
+#define LM3601X_MIN_STROBE_I_UA 11000
+#define LM3601X_STROBE_REG_DIV 11800
+
+#define LM3601X_TIMEOUT_MASK 0x1e
+#define LM3601X_ENABLE_MASK (LM3601X_MODE_IR_DRV | LM3601X_MODE_TORCH)
+
+#define LM3601X_LOWER_STEP_US 40000
+#define LM3601X_UPPER_STEP_US 200000
+#define LM3601X_MIN_TIMEOUT_US 40000
+#define LM3601X_MAX_TIMEOUT_US 1600000
+#define LM3601X_TIMEOUT_XOVER_US 400000
+
+enum lm3601x_type {
+ CHIP_LM36010 = 0,
+ CHIP_LM36011,
+};
+
+/**
+ * struct lm3601x_led -
+ * @fled_cdev: flash LED class device pointer
+ * @client: Pointer to the I2C client
+ * @regmap: Devices register map
+ * @lock: Lock for reading/writing the device
+ * @led_name: LED label for the Torch or IR LED
+ * @flash_timeout: the timeout for the flash
+ * @last_flag: last known flags register value
+ * @torch_current_max: maximum current for the torch
+ * @flash_current_max: maximum current for the flash
+ * @max_flash_timeout: maximum timeout for the flash
+ * @led_mode: The mode to enable either IR or Torch
+ */
+struct lm3601x_led {
+ struct led_classdev_flash fled_cdev;
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct mutex lock;
+
+ char led_name[LED_MAX_NAME_SIZE];
+
+ unsigned int flash_timeout;
+ unsigned int last_flag;
+
+ u32 torch_current_max;
+ u32 flash_current_max;
+ u32 max_flash_timeout;
+
+ u32 led_mode;
+};
+
+static const struct reg_default lm3601x_regmap_defs[] = {
+ { LM3601X_ENABLE_REG, 0x20 },
+ { LM3601X_CFG_REG, 0x15 },
+ { LM3601X_LED_FLASH_REG, 0x00 },
+ { LM3601X_LED_TORCH_REG, 0x00 },
+};
+
+static bool lm3601x_volatile_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case LM3601X_FLAGS_REG:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const struct regmap_config lm3601x_regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LM3601X_DEV_ID_REG,
+ .reg_defaults = lm3601x_regmap_defs,
+ .num_reg_defaults = ARRAY_SIZE(lm3601x_regmap_defs),
+ .cache_type = REGCACHE_RBTREE,
+ .volatile_reg = lm3601x_volatile_reg,
+};
+
+static struct lm3601x_led *fled_cdev_to_led(struct led_classdev_flash *fled_cdev)
+{
+ return container_of(fled_cdev, struct lm3601x_led, fled_cdev);
+}
+
+static int lm3601x_read_faults(struct lm3601x_led *led)
+{
+ int flags_val;
+ int ret;
+
+ ret = regmap_read(led->regmap, LM3601X_FLAGS_REG, &flags_val);
+ if (ret < 0)
+ return -EIO;
+
+ led->last_flag = 0;
+
+ if (flags_val & LM36010_OVP_FAULT)
+ led->last_flag |= LED_FAULT_OVER_VOLTAGE;
+
+ if (flags_val & (LM3601X_THERM_SHUTDOWN | LM3601X_THERM_CURR))
+ led->last_flag |= LED_FAULT_OVER_TEMPERATURE;
+
+ if (flags_val & LM3601X_SHORT_FAULT)
+ led->last_flag |= LED_FAULT_SHORT_CIRCUIT;
+
+ if (flags_val & LM36010_CURR_LIMIT)
+ led->last_flag |= LED_FAULT_OVER_CURRENT;
+
+ if (flags_val & LM3601X_UVLO_FAULT)
+ led->last_flag |= LED_FAULT_UNDER_VOLTAGE;
+
+ if (flags_val & LM3601X_IVFM_TRIP)
+ led->last_flag |= LED_FAULT_INPUT_VOLTAGE;
+
+ if (flags_val & LM3601X_THERM_SHUTDOWN)
+ led->last_flag |= LED_FAULT_LED_OVER_TEMPERATURE;
+
+ return led->last_flag;
+}
+
+static int lm3601x_brightness_set(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(cdev);
+ struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
+ int ret, led_mode_val;
+
+ mutex_lock(&led->lock);
+
+ ret = lm3601x_read_faults(led);
+ if (ret < 0)
+ goto out;
+
+ if (led->led_mode == LM3601X_LED_TORCH)
+ led_mode_val = LM3601X_MODE_TORCH;
+ else
+ led_mode_val = LM3601X_MODE_IR_DRV;
+
+ if (brightness == LED_OFF) {
+ ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
+ led_mode_val, LED_OFF);
+ goto out;
+ }
+
+ ret = regmap_write(led->regmap, LM3601X_LED_TORCH_REG, brightness);
+ if (ret < 0)
+ goto out;
+
+ ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
+ LM3601X_MODE_TORCH | LM3601X_MODE_IR_DRV,
+ led_mode_val);
+out:
+ mutex_unlock(&led->lock);
+ return ret;
+}
+
+static int lm3601x_strobe_set(struct led_classdev_flash *fled_cdev,
+ bool state)
+{
+ struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
+ int timeout_reg_val;
+ int current_timeout;
+ int ret;
+
+ mutex_lock(&led->lock);
+
+ ret = regmap_read(led->regmap, LM3601X_CFG_REG, ¤t_timeout);
+ if (ret < 0)
+ goto out;
+
+ if (led->flash_timeout >= LM3601X_TIMEOUT_XOVER_US)
+ timeout_reg_val = led->flash_timeout / LM3601X_UPPER_STEP_US + 0x07;
+ else
+ timeout_reg_val = led->flash_timeout / LM3601X_LOWER_STEP_US - 0x01;
+
+ if (led->flash_timeout != current_timeout)
+ ret = regmap_update_bits(led->regmap, LM3601X_CFG_REG,
+ LM3601X_TIMEOUT_MASK, timeout_reg_val);
+
+ if (state)
+ ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
+ LM3601X_MODE_TORCH | LM3601X_MODE_IR_DRV,
+ LM3601X_MODE_STROBE);
+ else
+ ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
+ LM3601X_MODE_STROBE, LED_OFF);
+
+ ret = lm3601x_read_faults(led);
+out:
+ mutex_unlock(&led->lock);
+ return ret;
+}
+
+static int lm3601x_flash_brightness_set(struct led_classdev_flash *fled_cdev,
+ u32 brightness)
+{
+ struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
+ u8 brightness_val;
+ int ret;
+
+ mutex_lock(&led->lock);
+ ret = lm3601x_read_faults(led);
+ if (ret < 0)
+ goto out;
+
+ if (brightness == LED_OFF) {
+ ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
+ LM3601X_MODE_STROBE, LED_OFF);
+ goto out;
+ }
+
+ brightness_val = brightness / LM3601X_STROBE_REG_DIV;
+
+ ret = regmap_write(led->regmap, LM3601X_LED_FLASH_REG, brightness_val);
+out:
+ mutex_unlock(&led->lock);
+ return ret;
+}
+
+static int lm3601x_flash_timeout_set(struct led_classdev_flash *fled_cdev,
+ u32 timeout)
+{
+ struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
+
+ mutex_lock(&led->lock);
+
+ led->flash_timeout = timeout;
+
+ mutex_unlock(&led->lock);
+
+ return 0;
+}
+
+static int lm3601x_strobe_get(struct led_classdev_flash *fled_cdev, bool *state)
+{
+ struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
+ int strobe_state;
+ int ret;
+
+ mutex_lock(&led->lock);
+
+ ret = regmap_read(led->regmap, LM3601X_ENABLE_REG, &strobe_state);
+ if (ret < 0)
+ goto out;
+
+ *state = strobe_state & LM3601X_MODE_STROBE;
+
+out:
+ mutex_unlock(&led->lock);
+ return ret;
+}
+
+static int lm3601x_flash_fault_get(struct led_classdev_flash *fled_cdev,
+ u32 *fault)
+{
+ struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
+
+ lm3601x_read_faults(led);
+
+ *fault = led->last_flag;
+
+ return 0;
+}
+
+static const struct led_flash_ops flash_ops = {
+ .flash_brightness_set = lm3601x_flash_brightness_set,
+ .strobe_set = lm3601x_strobe_set,
+ .strobe_get = lm3601x_strobe_get,
+ .timeout_set = lm3601x_flash_timeout_set,
+ .fault_get = lm3601x_flash_fault_get,
+};
+
+static int lm3601x_register_leds(struct lm3601x_led *led)
+{
+ struct led_classdev *led_cdev;
+ struct led_flash_setting *setting;
+
+ led->fled_cdev.ops = &flash_ops;
+
+ setting = &led->fled_cdev.timeout;
+ setting->min = LM3601X_MIN_TIMEOUT_US;
+ setting->max = led->max_flash_timeout;
+ setting->step = LM3601X_LOWER_STEP_US;
+ setting->val = led->max_flash_timeout;
+
+ setting = &led->fled_cdev.brightness;
+ setting->min = LM3601X_MIN_STROBE_I_UA;
+ setting->max = led->flash_current_max;
+ setting->step = LM3601X_TORCH_REG_DIV;
+ setting->val = led->flash_current_max;
+
+ led_cdev = &led->fled_cdev.led_cdev;
+ led_cdev->name = led->led_name;
+ led_cdev->brightness_set_blocking = lm3601x_brightness_set;
+ led_cdev->max_brightness = DIV_ROUND_UP(led->torch_current_max,
+ LM3601X_TORCH_REG_DIV);
+ led_cdev->flags |= LED_DEV_CAP_FLASH;
+
+ return led_classdev_flash_register(&led->client->dev, &led->fled_cdev);
+}
+
+static int lm3601x_parse_node(struct lm3601x_led *led)
+{
+ struct fwnode_handle *child = NULL;
+ int ret = -ENODEV;
+ const char *name;
+
+ child = device_get_next_child_node(&led->client->dev, child);
+ if (!child) {
+ dev_err(&led->client->dev, "No LED Child node\n");
+ return ret;
+ }
+
+ ret = fwnode_property_read_u32(child, "reg", &led->led_mode);
+ if (ret) {
+ dev_err(&led->client->dev, "reg DT property missing\n");
+ goto out_err;
+ }
+
+ if (led->led_mode > LM3601X_LED_TORCH ||
+ led->led_mode < LM3601X_LED_IR) {
+ dev_warn(&led->client->dev, "Invalid led mode requested\n");
+ ret = -EINVAL;
+ goto out_err;
+ }
+
+ ret = fwnode_property_read_string(child, "label", &name);
+ if (ret) {
+ if (led->led_mode == LM3601X_LED_TORCH)
+ name = "torch";
+ else
+ name = "infrared";
+ }
+
+ snprintf(led->led_name, sizeof(led->led_name),
+ "%s:%s", led->client->name, name);
+
+ ret = fwnode_property_read_u32(child, "led-max-microamp",
+ &led->torch_current_max);
+ if (ret) {
+ dev_warn(&led->client->dev,
+ "led-max-microamp DT property missing\n");
+ goto out_err;
+ }
+
+ ret = fwnode_property_read_u32(child, "flash-max-microamp",
+ &led->flash_current_max);
+ if (ret) {
+ dev_warn(&led->client->dev,
+ "flash-max-microamp DT property missing\n");
+ goto out_err;
+ }
+
+ ret = fwnode_property_read_u32(child, "flash-max-timeout-us",
+ &led->max_flash_timeout);
+ if (ret) {
+ dev_warn(&led->client->dev,
+ "flash-max-timeout-us DT property missing\n");
+ goto out_err;
+ }
+
+out_err:
+ fwnode_handle_put(child);
+ return ret;
+}
+
+static int lm3601x_probe(struct i2c_client *client)
+{
+ struct lm3601x_led *led;
+ int ret;
+
+ led = devm_kzalloc(&client->dev, sizeof(*led), GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ led->client = client;
+ i2c_set_clientdata(client, led);
+
+ ret = lm3601x_parse_node(led);
+ if (ret)
+ return -ENODEV;
+
+ led->regmap = devm_regmap_init_i2c(client, &lm3601x_regmap);
+ if (IS_ERR(led->regmap)) {
+ ret = PTR_ERR(led->regmap);
+ dev_err(&client->dev,
+ "Failed to allocate register map: %d\n", ret);
+ return ret;
+ }
+
+ mutex_init(&led->lock);
+
+ return lm3601x_register_leds(led);
+}
+
+static int lm3601x_remove(struct i2c_client *client)
+{
+ struct lm3601x_led *led = i2c_get_clientdata(client);
+
+ led_classdev_flash_unregister(&led->fled_cdev);
+ mutex_destroy(&led->lock);
+
+ return regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
+ LM3601X_ENABLE_MASK,
+ LM3601X_MODE_STANDBY);
+}
+
+static const struct i2c_device_id lm3601x_id[] = {
+ { "LM36010", CHIP_LM36010 },
+ { "LM36011", CHIP_LM36011 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, lm3601x_id);
+
+static const struct of_device_id of_lm3601x_leds_match[] = {
+ { .compatible = "ti,lm36010", },
+ { .compatible = "ti,lm36011", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, of_lm3601x_leds_match);
+
+static struct i2c_driver lm3601x_i2c_driver = {
+ .driver = {
+ .name = "lm3601x",
+ .of_match_table = of_lm3601x_leds_match,
+ },
+ .probe_new = lm3601x_probe,
+ .remove = lm3601x_remove,
+ .id_table = lm3601x_id,
+};
+module_i2c_driver(lm3601x_i2c_driver);
+
+MODULE_DESCRIPTION("Texas Instruments Flash Lighting driver for LM3601X");
+MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
+MODULE_LICENSE("GPL v2");
--
2.17.0.582.gccdcbd54c
^ permalink raw reply related
* Re: [PATCH v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file
From: M P @ 2018-05-23 11:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: michel.pollet, linux-renesas-soc, Simon Horman, Phil Edworthy,
buserror+upstream, Magnus Damm, robh+dt, mark.rutland,
Michael Turquette, sboyd, geert+renesas, devicetree, linux-kernel,
linux-clk
In-Reply-To: <CAMuHMdXumeXLw_MAz5MVOKZYO3-F5samUGLSZN7bHSnmD6sfnQ@mail.gmail.com>
Hi Geert,
On Wed, 23 May 2018 at 12:18, Geert Uytterhoeven <geert@linux-m68k.org>
wrote:
> Hi Michel,
> On Wed, May 23, 2018 at 11:20 AM, M P <buserror@gmail.com> wrote:
> > On Wed, 23 May 2018 at 10:12, Geert Uytterhoeven <geert@linux-m68k.org>
> > wrote:
> >> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
> >> <michel.pollet@bp.renesas.com> wrote:
> >> > + #address-cells = <1>;
> >> > + #size-cells = <1>;
> >> > +
> >> > + cpus {
> >> > + #address-cells = <1>;
> >> > + #size-cells = <0>;
> >> > + clocks = <&clock RZN1_DIV_CA7>;
> >
> >> I think the clocks property should be moved to the individual CPU
nodes.
> >
> > Ah, I had a look around, and I found some instances that are in the cpu
> > sub-node, and others that are not -- it seems that having it in the cpu
> > sub-node would implies it's core specific... here if that clock is
changed
> > both cores would change speed...
> Assumed the driver code knows to look in the parent node, which I doubt
> the cpufreq code does.
> > Either way, it's not used by the kernel in any way at the moment -- I
had
> > hoped cpufreq or something would claim it, but it's not the case.
> I guess you have to add your main SoC compatible value to the whitelist
> in drivers/cpufreq/cpufreq-dt-platdev.c first.
Most excellent tip here -- I'll add a further patch to enable this, after
this series eventually gets merged...
Cheers,
Michel
^ permalink raw reply
* Re: [PATCH] mfd: dt: Add bindings for DA9063L
From: Geert Uytterhoeven @ 2018-05-23 12:08 UTC (permalink / raw)
To: Marek Vasut
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Marek Vasut, Geert Uytterhoeven, Lee Jones, Rob Herring,
Steve Twiss, Wolfram Sang, Linux-Renesas
In-Reply-To: <20180523112644.9464-1-marek.vasut+renesas@gmail.com>
Hi Marek,
On Wed, May 23, 2018 at 1:26 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Add device tree bindings for the Dialog DA9063L. This is a
> variant of the DA9063 chip with smaller package, with less
> LDO regulators and without RTC block. The other properties
> of the chip are the same, including the content of the chip
> ID register.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Thanks for your patch!
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Minor nit below.
> --- a/Documentation/devicetree/bindings/mfd/da9063.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9063.txt
> @@ -6,14 +6,14 @@ Device Supply Names Description
> ------ ------------ -----------
> da9063-regulator : : LDOs & BUCKs
> da9063-onkey : : On Key
> -da9063-rtc : : Real-Time Clock
> +da9063-rtc : : Real-Time Clock (DA9063 only)
> da9063-watchdog : : Watchdog
>
> ======
>
> Required properties:
>
> -- compatible : Should be "dlg,da9063"
> +- compatible : Should be "dlg,da9063" or "dlg,da9063l"
> - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
> modified to match the chip's OTP settings).
> - interrupt-parent : Specifies the reference to the interrupt controller for
> @@ -23,8 +23,8 @@ Required properties:
>
> Sub-nodes:
>
> -- regulators : This node defines the settings for the LDOs and BUCKs. The
> - DA9063 regulators are bound using their names listed below:
> +- regulators : This node defines the settings for the LDOs and BUCKs.
> + The DA9063 regulators are bound using their names listed below:
>
> bcore1 : BUCK CORE1
> bcore2 : BUCK CORE2
> @@ -44,13 +44,28 @@ Sub-nodes:
> ldo10 : LDO_10
> ldo11 : LDO_11
>
> + The DA9063L regulators are bound using their names listed below:
> +
> + bcore1 : BUCK CORE1
> + bcore2 : BUCK CORE2
> + bpro : BUCK PRO
> + bmem : BUCK MEM
> + bio : BUCK IO
> + bperi : BUCK PERI
> + ldo3 : LDO_3
> + ldo7 : LDO_7
> + ldo8 : LDO_8
> + ldo9 : LDO_9
> + ldo11 : LDO_11
> +
As an alternative to having two lists, perhaps you can use a table, or
mark entries "(DA9063 only)", like you did for da9063-rtc above?
That makes it easier to see the differences.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor
From: Robin Murphy @ 2018-05-23 12:12 UTC (permalink / raw)
To: Stefan Wahren, Rob Herring, Guenter Roeck, Eric Anholt,
Mark Rutland, Jonathan Corbet, Jean Delvare
Cc: linux-hwmon, devicetree, Florian Fainelli, Scott Branden,
linux-doc, Ray Jui, Phil Elwell, Noralf Trønnes,
bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel
In-Reply-To: <723014352.17580.1527017480381@email.1und1.de>
On 22/05/18 20:31, Stefan Wahren wrote:
[...]
>>>>> +static int rpi_hwmon_probe(struct platform_device *pdev)
>>>>> +{
>>>>> + struct device *dev = &pdev->dev;
>>>>> + struct rpi_hwmon_data *data;
>>>>> + int ret;
>>>>> +
>>>>> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>>>>> + if (!data)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + data->fw = platform_get_drvdata(to_platform_device(dev->parent));
>>>>> + if (!data->fw)
>>>>> + return -EPROBE_DEFER;
>>>>> +
>>>>
>>>> I am a bit at loss here (and sorry I didn't bring this up before).
>>>> How would this ever be possible, given that the driver is registered
>>>> from the firmware driver ?
>>>
>>> Do you refer to the (wrong) return code, the assumption that the parent must be a platform driver or a possible race?
>>>
>>
>> The return code is one thing. My question was how the driver would ever be instantiated
>> with platform_get_drvdata(to_platform_device(dev->parent)) == NULL (but dev->parent != NULL),
>> so I referred to the race. But, sure, a second question would be how that would indicate
>> that the parent is not instantiated yet (which by itself seems like an odd question).
>
> This shouldn't happen and worth a log error. In patch #3 the registration is called after the complete private data of the firmware driver is initialized. Did i missed something?
>
> But i must confess that i didn't test all builtin/module combinations.
The point is that, by construction, a "raspberrypi-hwmon" device will
only ever be created for this driver to bind to if the firmware device
is both fully initialised and known to support the GET_THROTTLED call
already. Thus trying to check those again from the hwmon driver is at
best pointless, and at worst misleading. If somebody *does* manage to
bind this driver to some random inappropriate device, you've still got
no guarantee that dev->parent is valid or that
dev_get_drvdata(dev->parent)) won't return something non-NULL that isn't
a struct rpi_firmware pointer, at which point you're liable to pass the
paranoid check yet still crash anyway.
IOW, you can't reasonably defend against incorrect operation, and under
correct operation there's nothing to defend against, so either way it's
pretty futile to waste effort trying.
Robin.
^ permalink raw reply
* Re: [PATCH] mfd: dt: Add bindings for DA9063L
From: Marek Vasut @ 2018-05-23 12:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Marek Vasut, Geert Uytterhoeven, Lee Jones, Rob Herring,
Steve Twiss, Wolfram Sang, Linux-Renesas
In-Reply-To: <CAMuHMdUC243tr9rxUbmabzixFE8JwVm4hOEkm=AvTGUXpy_6Hw@mail.gmail.com>
On 05/23/2018 02:08 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Wed, May 23, 2018 at 1:26 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> Add device tree bindings for the Dialog DA9063L. This is a
>> variant of the DA9063 chip with smaller package, with less
>> LDO regulators and without RTC block. The other properties
>> of the chip are the same, including the content of the chip
>> ID register.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Thanks for your patch!
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Minor nit below.
>
>> --- a/Documentation/devicetree/bindings/mfd/da9063.txt
>> +++ b/Documentation/devicetree/bindings/mfd/da9063.txt
>
>> @@ -6,14 +6,14 @@ Device Supply Names Description
>> ------ ------------ -----------
>> da9063-regulator : : LDOs & BUCKs
>> da9063-onkey : : On Key
>> -da9063-rtc : : Real-Time Clock
>> +da9063-rtc : : Real-Time Clock (DA9063 only)
>> da9063-watchdog : : Watchdog
>>
>> ======
>>
>> Required properties:
>>
>> -- compatible : Should be "dlg,da9063"
>> +- compatible : Should be "dlg,da9063" or "dlg,da9063l"
>> - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
>> modified to match the chip's OTP settings).
>> - interrupt-parent : Specifies the reference to the interrupt controller for
>> @@ -23,8 +23,8 @@ Required properties:
>>
>> Sub-nodes:
>>
>> -- regulators : This node defines the settings for the LDOs and BUCKs. The
>> - DA9063 regulators are bound using their names listed below:
>> +- regulators : This node defines the settings for the LDOs and BUCKs.
>> + The DA9063 regulators are bound using their names listed below:
>>
>> bcore1 : BUCK CORE1
>> bcore2 : BUCK CORE2
>> @@ -44,13 +44,28 @@ Sub-nodes:
>> ldo10 : LDO_10
>> ldo11 : LDO_11
>>
>> + The DA9063L regulators are bound using their names listed below:
>> +
>> + bcore1 : BUCK CORE1
>> + bcore2 : BUCK CORE2
>> + bpro : BUCK PRO
>> + bmem : BUCK MEM
>> + bio : BUCK IO
>> + bperi : BUCK PERI
>> + ldo3 : LDO_3
>> + ldo7 : LDO_7
>> + ldo8 : LDO_8
>> + ldo9 : LDO_9
>> + ldo11 : LDO_11
>> +
>
> As an alternative to having two lists, perhaps you can use a table, or
> mark entries "(DA9063 only)", like you did for da9063-rtc above?
> That makes it easier to see the differences.
Let's try that in V2
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH V2] mfd: dt: Add bindings for DA9063L
From: Marek Vasut @ 2018-05-23 12:21 UTC (permalink / raw)
To: devicetree
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Rob Herring,
Steve Twiss, Wolfram Sang, linux-renesas-soc
Add device tree bindings for the Dialog DA9063L. This is a
variant of the DA9063 chip with smaller package, with less
LDO regulators and without RTC block. The other properties
of the chip are the same, including the content of the chip
ID register.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Merge the DA9063/DA9063L regulator lists and mark DA9063-only
regulators in that single list
---
Documentation/devicetree/bindings/mfd/da9063.txt | 32 +++++++++++++-----------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt b/Documentation/devicetree/bindings/mfd/da9063.txt
index 05b21bcb8543..443e68286957 100644
--- a/Documentation/devicetree/bindings/mfd/da9063.txt
+++ b/Documentation/devicetree/bindings/mfd/da9063.txt
@@ -1,4 +1,4 @@
-* Dialog DA9063 Power Management Integrated Circuit (PMIC)
+* Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC)
DA9093 consists of a large and varied group of sub-devices (I2C Only):
@@ -6,14 +6,14 @@ Device Supply Names Description
------ ------------ -----------
da9063-regulator : : LDOs & BUCKs
da9063-onkey : : On Key
-da9063-rtc : : Real-Time Clock
+da9063-rtc : : Real-Time Clock (DA9063 only)
da9063-watchdog : : Watchdog
======
Required properties:
-- compatible : Should be "dlg,da9063"
+- compatible : Should be "dlg,da9063" or "dlg,da9063l"
- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
modified to match the chip's OTP settings).
- interrupt-parent : Specifies the reference to the interrupt controller for
@@ -23,8 +23,8 @@ Required properties:
Sub-nodes:
-- regulators : This node defines the settings for the LDOs and BUCKs. The
- DA9063 regulators are bound using their names listed below:
+- regulators : This node defines the settings for the LDOs and BUCKs.
+ The DA9063(L) regulators are bound using their names listed below:
bcore1 : BUCK CORE1
bcore2 : BUCK CORE2
@@ -32,16 +32,16 @@ Sub-nodes:
bmem : BUCK MEM
bio : BUCK IO
bperi : BUCK PERI
- ldo1 : LDO_1
- ldo2 : LDO_2
+ ldo1 : LDO_1 (DA9063 only)
+ ldo2 : LDO_2 (DA9063 only)
ldo3 : LDO_3
- ldo4 : LDO_4
- ldo5 : LDO_5
- ldo6 : LDO_6
+ ldo4 : LDO_4 (DA9063 only)
+ ldo5 : LDO_5 (DA9063 only)
+ ldo6 : LDO_6 (DA9063 only)
ldo7 : LDO_7
ldo8 : LDO_8
ldo9 : LDO_9
- ldo10 : LDO_10
+ ldo10 : LDO_10 (DA9063 only)
ldo11 : LDO_11
The component follows the standard regulator framework and the bindings
@@ -49,8 +49,9 @@ Sub-nodes:
Documentation/devicetree/bindings/regulator/regulator.txt
- rtc : This node defines settings for the Real-Time Clock associated with
- the DA9063. There are currently no entries in this binding, however
- compatible = "dlg,da9063-rtc" should be added if a node is created.
+ the DA9063 only. The RTC is not present in DA9063L. There are currently
+ no entries in this binding, however compatible = "dlg,da9063-rtc" should
+ be added if a node is created.
- onkey : This node defines the OnKey settings for controlling the key
functionality of the device. The node should contain the compatible property
@@ -65,8 +66,9 @@ Sub-nodes:
and KEY_SLEEP.
- watchdog : This node defines settings for the Watchdog timer associated
- with the DA9063. There are currently no entries in this binding, however
- compatible = "dlg,da9063-watchdog" should be added if a node is created.
+ with the DA9063 and DA9063L. There are currently no entries in this
+ binding, however compatible = "dlg,da9063-watchdog" should be added
+ if a node is created.
Example:
--
2.16.2
^ permalink raw reply related
* Re: [PATCH V2] mfd: dt: Add bindings for DA9063L
From: Geert Uytterhoeven @ 2018-05-23 12:27 UTC (permalink / raw)
To: Marek Vasut
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Marek Vasut, Geert Uytterhoeven, Lee Jones, Rob Herring,
Steve Twiss, Wolfram Sang, Linux-Renesas
In-Reply-To: <20180523122140.6275-1-marek.vasut+renesas@gmail.com>
On Wed, May 23, 2018 at 2:21 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Add device tree bindings for the Dialog DA9063L. This is a
> variant of the DA9063 chip with smaller package, with less
> LDO regulators and without RTC block. The other properties
> of the chip are the same, including the content of the chip
> ID register.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
(again)
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Marcel Holtmann @ 2018-05-23 12:31 UTC (permalink / raw)
To: Sean Wang
Cc: Mark Rutland, devicetree, Johan Hedberg, LKML, BlueZ development,
Rob Herring, linux-mediatek, linux-arm-kernel
In-Reply-To: <1527057423.4607.3.camel@mtkswgap22>
Hi Sean,
>>
>> [ ... ]
>>
>>>> - if (hci_dev_test_flag(hdev, HCI_SETUP)) {
>>>> + if (hci_dev_test_flag(hdev, HCI_SETUP) ||
>>>> + test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
>>>> hci_sock_dev_event(hdev, HCI_DEV_SETUP);
>>>
>>> I am not 100% sure that we want to send the HCI_DEV_SETUP event also multiple times. That is a userspace change that I would need to think about. We need to check create_monitor_event() and see what the btmon trace for this looks like. Can you send me a btmon -w trace.log when this change is active.
>>>
>>> Regards
>>>
>>> Marcel
>>>
>>
>> Sure, I'll send you the trace.log with the change is active.
>>
>> Sean
>>
>
>
> Attached trace.log was captured when I inputted commands power on and
> then off in bluetoothctl.
the trace.log is somehow mangled. Something is not fully correct. Can you read it with btmon -r trace.log?
Regards
Marcel
^ permalink raw reply
* [PATCH v11 0/2] Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-23 12:38 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel
[v11]
* Addressed comment from Russel about device_node reference
* Addressed comment from Sudeep about the late_initcall
* Transformed init into probe to take care of deferals
[v10]
* Split the series into domains
* Addressed comments from Viresh and Sudeep about logical CPU numbering.
The qcom-cpufreq-kryo driver is aimed to support different SOC versions.
The driver reads eFuse information and chooses the required OPP subset
by passing the OPP supported-hw parameter.
The series depends on the series from Viresh:
https://patchwork.kernel.org/patch/10418139/
The previous spin was here:
https://patchwork.kernel.org/patch/10420809/
Ilia Lin (2):
cpufreq: Add Kryo CPU scaling driver
dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
drivers/cpufreq/Kconfig.arm | 10 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 181 ++++++
5 files changed, 875 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
--
1.9.1
^ permalink raw reply
* [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-23 12:38 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel
In-Reply-To: <1527079139-3558-1-git-send-email-ilialin@codeaurora.org>
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
---
drivers/cpufreq/Kconfig.arm | 10 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 181 +++++++++++++++++++++++++++++++++++
4 files changed, 195 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..2339ea99d
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id */
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int qcom_cpufreq_kryo_probe(struct platform_device *pdev)
+{
+ struct opp_table *opp_tables[NR_CPUS] = {0};
+ struct platform_device *cpufreq_dt_pdev;
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct device_node *np;
+ struct device *cpu_dev;
+ unsigned cpu;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev = get_cpu_device(0);
+ if (NULL == cpu_dev)
+ return -ENODEV;
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
+ if (IS_ERR(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ of_node_put(np);
+ return -ENOENT;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ of_node_put(np);
+ if (IS_ERR(speedbin_nvmem)) {
+ dev_err(cpu_dev, "Could not get nvmem cell: %d\n", ret);
+ return PTR_ERR(speedbin_nvmem);
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ for_each_possible_cpu(cpu) {
+ cpu_dev = get_cpu_device(cpu);
+ if (NULL == cpu_dev) {
+ ret = -ENODEV;
+ goto free_opp;
+ }
+
+ opp_tables[cpu] = dev_pm_opp_set_supported_hw(cpu_dev,
+ &versions, 1);
+ if (IS_ERR(opp_tables[cpu])) {
+ ret = PTR_ERR(opp_tables[cpu]);
+ dev_err(cpu_dev, "Failed to set supported hardware\n");
+ goto free_opp;
+ }
+ }
+
+ cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+ if (!IS_ERR(cpufreq_dt_pdev))
+ return 0;
+
+ ret = PTR_ERR(cpufreq_dt_pdev);
+ dev_err(cpu_dev, "Failed to register platform device\n");
+
+free_opp:
+ for_each_possible_cpu(cpu) {
+ if (IS_ERR_OR_NULL(opp_tables[cpu]))
+ break;
+ dev_pm_opp_put_supported_hw(opp_tables[cpu]);
+ }
+
+ return ret;
+}
+
+static int __init qcom_cpufreq_kryo_init(void)
+{
+ /*
+ * Since the driver depends on smem and nvmem drivers, which may
+ * return EPROBE_DEFER, all the real activity is done in the probe,
+ * which may be defered as well. The init here is only registering
+ * a platform device.
+ */
+ platform_device_register_simple("qcom-cpufreq-kryo", -1, NULL, 0);
+ return 0;
+}
+module_init(qcom_cpufreq_kryo_init);
+
+static struct platform_driver qcom_cpufreq_kryo_driver = {
+ .probe = qcom_cpufreq_kryo_probe,
+ .driver = {
+ .name = "qcom-cpufreq-kryo",
+ },
+};
+builtin_platform_driver(qcom_cpufreq_kryo_driver);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v11 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
From: Ilia Lin @ 2018-05-23 12:38 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel
In-Reply-To: <1527079139-3558-1-git-send-email-ilialin@codeaurora.org>
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
This change adds documentation for the DT bindings.
The "operating-points-v2-kryo-cpu" DT extends the "operating-points-v2"
with following parameters:
- nvmem-cells (NVMEM area containig the speedbin information)
- opp-supported-hw: A single 32 bit bitmap value,
representing compatible HW:
0: MSM8996 V3, speedbin 0
1: MSM8996 V3, speedbin 1
2: MSM8996 V3, speedbin 2
3: unused
4: MSM8996 SG, speedbin 0
5: MSM8996 SG, speedbin 1
6: MSM8996 SG, speedbin 2
7-31: unused
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
1 file changed, 680 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
new file mode 100644
index 0000000..c2127b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
@@ -0,0 +1,680 @@
+Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
+===================================
+
+In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
+that have KRYO processors, the CPU ferequencies subset and voltage value
+of each OPP varies based on the silicon variant in use.
+Qualcomm Technologies, Inc. Process Voltage Scaling Tables
+defines the voltage and frequency value based on the msm-id in SMEM
+and speedbin blown in the efuse combination.
+The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+to provide the OPP framework with required information (existing HW bitmap).
+This is used to determine the voltage and frequency value for each OPP of
+operating-points-v2 table when it is parsed by the OPP framework.
+
+Required properties:
+--------------------
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use.
+
+In 'operating-points-v2' table:
+- compatible: Should be
+ - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
+- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
+ efuse registers that has information about the
+ speedbin that is used to select the right frequency/voltage
+ value pair.
+ Please refer the for nvmem-cells
+ bindings Documentation/devicetree/bindings/nvmem/nvmem.txt
+ and also examples below.
+
+In every OPP node:
+- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW.
+ Bitmap:
+ 0: MSM8996 V3, speedbin 0
+ 1: MSM8996 V3, speedbin 1
+ 2: MSM8996 V3, speedbin 2
+ 3: unused
+ 4: MSM8996 SG, speedbin 0
+ 5: MSM8996 SG, speedbin 1
+ 6: MSM8996 SG, speedbin 2
+ 7-31: unused
+
+Example 1:
+---------
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ };
+
+ CPU2: cpu@100 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ L2_1: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU3: cpu@101 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x101>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+
+ core1 {
+ cpu = <&CPU1>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&CPU2>;
+ };
+
+ core1 {
+ cpu = <&CPU3>;
+ };
+ };
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-422400000 {
+ opp-hz = /bits/ 64 <422400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-768000000 {
+ opp-hz = /bits/ 64 <768000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-844800000 {
+ opp-hz = /bits/ 64 <844800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-960000000 {
+ opp-hz = /bits/ 64 <960000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x72>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1497600000 {
+ opp-hz = /bits/ 64 <1497600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x4>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x20>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2188800000 {
+ opp-hz = /bits/ 64 <2188800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+ cluster1_opp: opp_table1 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-403200000 {
+ opp-hz = /bits/ 64 <403200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-748800000 {
+ opp-hz = /bits/ 64 <748800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-806400000 {
+ opp-hz = /bits/ 64 <806400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-825600000 {
+ opp-hz = /bits/ 64 <825600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-883200000 {
+ opp-hz = /bits/ 64 <883200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-940800000 {
+ opp-hz = /bits/ 64 <940800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1248000000 {
+ opp-hz = /bits/ 64 <1248000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1555200000 {
+ opp-hz = /bits/ 64 <1555200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1632000000 {
+ opp-hz = /bits/ 64 <1632000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1670400000 {
+ opp-hz = /bits/ 64 <1670400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1708800000 {
+ opp-hz = /bits/ 64 <1708800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1747200000 {
+ opp-hz = /bits/ 64 <1747200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1785600000 {
+ opp-hz = /bits/ 64 <1785600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1804800000 {
+ opp-hz = /bits/ 64 <1804800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x6>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1824000000 {
+ opp-hz = /bits/ 64 <1824000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1900800000 {
+ opp-hz = /bits/ 64 <1900800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x74>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1920000000 {
+ opp-hz = /bits/ 64 <1920000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1977600000 {
+ opp-hz = /bits/ 64 <1977600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2054400000 {
+ opp-hz = /bits/ 64 <2054400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2073600000 {
+ opp-hz = /bits/ 64 <2073600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2150400000 {
+ opp-hz = /bits/ 64 <2150400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x31>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2246400000 {
+ opp-hz = /bits/ 64 <2246400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2342400000 {
+ opp-hz = /bits/ 64 <2342400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+....
+
+reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+....
+ smem_mem: smem-mem@86000000 {
+ reg = <0x0 0x86000000 0x0 0x200000>;
+ no-map;
+ };
+....
+};
+
+smem {
+ compatible = "qcom,smem";
+ memory-region = <&smem_mem>;
+ hwlocks = <&tcsr_mutex 3>;
+};
+
+soc {
+....
+ qfprom: qfprom@74000 {
+ compatible = "qcom,qfprom";
+ reg = <0x00074000 0x8ff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ....
+ speedbin_efuse: speedbin@133 {
+ reg = <0x133 0x1>;
+ bits = <5 3>;
+ };
+ };
+};
--
1.9.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