* Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Sudeep Holla @ 2018-05-21 12:50 UTC (permalink / raw)
To: Ilia Lin, mturquette, sboyd, robh, mark.rutland, viresh.kumar, nm,
lgirdwood, broonie, andy.gross, david.brown, catalin.marinas,
will.deacon, rjw, linux-clk
Cc: Sudeep Holla, devicetree, linux-kernel, linux-pm, linux-arm-msm,
linux-soc, linux-arm-kernel, rnayak, amit.kucheria,
nicolas.dechesne, celster, tfinkel
In-Reply-To: <1526729701-8589-1-git-send-email-ilialin@codeaurora.org>
On 19/05/18 12:35, 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>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/Kconfig.arm | 10 +++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
> drivers/cpufreq/qcom-cpufreq-kryo.c | 164 +++++++++++++++++++++++++++++++++++
> 4 files changed, 178 insertions(+)
> create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
>
[..]
> +
> +/*
> + * 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
> +#define SILVER_LEAD 0
> +#define GOLD_LEAD 2
> +
So I gather form other emails, that these are physical cpu number(not
even unique identifier like MPIDR). Will this work on parts or platforms
that need to boot in GOLD LEAD cpus.
[...]
> +
> +static int __init qcom_cpufreq_kryo_driver_init(void)
> +{
> + struct device *cpu_dev_silver, *cpu_dev_gold;
> + struct opp_table *opp_silver, *opp_gold;
> + enum _msm8996_version msm8996_version;
> + struct nvmem_cell *speedbin_nvmem;
> + struct platform_device *pdev;
> + struct device_node *np;
> + u8 *speedbin;
> + u32 versions;
> + size_t len;
> + int ret;
> +
> + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> + if (IS_ERR_OR_NULL(cpu_dev_silver))
> + return PTR_ERR(cpu_dev_silver);
> +
> + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
s/SILVER/GOLD/ ?
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Russell King - ARM Linux @ 2018-05-21 12:41 UTC (permalink / raw)
To: ilialin
Cc: viresh.kumar, devicetree, linux-pm, linux-arm-msm, linux-kernel,
linux-soc, linux-clk, linux-arm-kernel
In-Reply-To: <000d01d3f100$294247e0$7bc6d7a0$@codeaurora.org>
On Mon, May 21, 2018 at 03:35:07PM +0300, ilialin@codeaurora.org wrote:
> There are 2 CPU clusters in the Kryo, CPU 0 and 1 are called Silver Cluster
> and CPU 2 and 3 - Gold Cluster. Each cluster has single clock. The clusters
> differ in terms of speed capabilities, computing power and power
> consumption. Therefore, I define separate OPP table for each cluster, and my
> driver will choose the appropriate OPP subset for each cluster.
> Lead refers to first CPU in the cluster.
Ah, that is really confusing. Lead can means many things. Maybe a
little more verbosity with the names such as SILVER_CLUSTER_LEAD_CPU
would help?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* RE: [PATCH] cpufreq: Add Kryo CPU scaling driver
From: ilialin @ 2018-05-21 12:35 UTC (permalink / raw)
To: 'Russell King - ARM Linux'
Cc: viresh.kumar, devicetree, linux-pm, linux-arm-msm, linux-kernel,
linux-soc, linux-clk, linux-arm-kernel
In-Reply-To: <20180521121140.GO17671@n2100.armlinux.org.uk>
There are 2 CPU clusters in the Kryo, CPU 0 and 1 are called Silver Cluster
and CPU 2 and 3 - Gold Cluster. Each cluster has single clock. The clusters
differ in terms of speed capabilities, computing power and power
consumption. Therefore, I define separate OPP table for each cluster, and my
driver will choose the appropriate OPP subset for each cluster.
Lead refers to first CPU in the cluster.
> -----Original Message-----
> From: Russell King - ARM Linux <linux@armlinux.org.uk>
> Sent: Monday, May 21, 2018 15:12
> To: ilialin@codeaurora.org
> Cc: viresh.kumar@linaro.org; devicetree@vger.kernel.org; linux-
> pm@vger.kernel.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-soc@vger.kernel.org; linux-
> clk@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
>
> On Mon, May 21, 2018 at 02:05:41PM +0300, ilialin@codeaurora.org wrote:
> > You are right.
> > cpu_dev_silver != cpu_dev_gold, and I found this with my tests as well.
> > Thank you.
> >
> > > -----Original Message-----
> > > From: Russell King - ARM Linux <linux@armlinux.org.uk>
> > > Sent: Monday, May 21, 2018 13:54
> > > To: Ilia Lin <ilialin@codeaurora.org>
> > > Cc: viresh.kumar@linaro.org; devicetree@vger.kernel.org; linux-
> > > pm@vger.kernel.org; linux-arm-msm@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; linux-soc@vger.kernel.org; linux-
> > > clk@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> > > Subject: Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
> > >
> > > On Mon, May 21, 2018 at 01:31:30PM +0300, Ilia Lin wrote:
> > > > +#define SILVER_LEAD 0
> > > > +#define GOLD_LEAD 2
> > >
> > > Okay, two different values here, but "GOLD_LEAD" appears unused.
> > >
> > > > + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> > > > + if (NULL == cpu_dev_silver)
> > > > + return -ENODEV;
> > > > +
> > > > + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
> > > > + if (NULL == cpu_dev_gold)
> > > > + return -ENODEV;
> > >
> > > get_cpu_device() takes the logical CPU number. So the above gets
> > > CPU 0 each time, and so cpu_dev_silver == cpu_dev_gold here. So
> > > what's the point of the second get_cpu_device() ? If it's supposed to
be:
> > >
> > > cpu_dev_gold = get_cpu_device(GOLD_LEAD);
> > >
> > > That would get CPU 2, but in terms of these defines, it doesn't make
> > > that much sense. What exactly does "silver lead" and "gold lead"
> > > refer to in
> > these
> > > definitions?
>
> I think you still need to explain this.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps
> up According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: renesas: draak: Describe CVBS input
From: jacopo mondi @ 2018-05-21 12:33 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Jacopo Mondi, niklas.soderlund, horms, geert, magnus.damm,
robh+dt, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <6943843.2osudLfTFd@avalon>
[-- Attachment #1: Type: text/plain, Size: 4208 bytes --]
Hi Laurent,
On Mon, May 21, 2018 at 01:54:55PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Monday, 21 May 2018 12:57:05 EEST jacopo mondi wrote:
> > On Fri, May 18, 2018 at 06:12:15PM +0300, Laurent Pinchart wrote:
> > > On Friday, 18 May 2018 17:47:57 EEST Jacopo Mondi wrote:
> > >> Describe CVBS video input through analog video decoder ADV7180
> > >> connected to video input interface VIN4.
> > >>
> > >> The video input signal path is shared with HDMI video input, and
> > >> selected by on-board switches SW-53 and SW-54 with CVBS input selected
> > >> by the default switches configuration.
> > >>
> > >> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > >> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > >>
> > >> ---
> > >> v2 -> v3:
> > >> - Add comment to describe the shared input video path
> > >> - Add my SoB and Niklas' R-b tags
> > >> ---
> > >>
> > >> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 42 +++++++++++++++++++
> > >> 1 file changed, 42 insertions(+)
> > >>
> > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > >> b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index 9d73de8..95745fc
> > >> 100644
> > >> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > >> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > >> @@ -142,6 +142,11 @@
> > >> groups = "usb0";
> > >> function = "usb0";
> > >> };
> > >> +
> > >> + vin4_pins_cvbs: vin4 {
> > >> + groups = "vin4_data8", "vin4_sync", "vin4_clk";
> > >> + function = "vin4";
> > >> + };
> > >> };
> > >>
> > >> &i2c0 {
> > >> @@ -154,6 +159,23 @@
> > >> reg = <0x50>;
> > >> pagesize = <8>;
> > >> };
> > >> +
> > >> + analog-video@20 {
> > >> + compatible = "adi,adv7180";
> > >> + reg = <0x20>;
> > >> +
> > >> + port {
> > >
> > > The adv7180 DT bindings document the output port as 3 or 6 (respectively
> > > for the CP and ST versions of the chip). You should thus number the port.
> > > Apart from that the patch looks good.
> >
> > I admit I have barely copied this from Gen-2 boards DTS, but reading
> > the driver code and binding description again, I think this is
> > correct, as the output port numbering and mandatory input port (which
> > is missing here) only apply to adv7180cp/st chip versions.
> >
> > Here we describe plain adv7180, no need to number output ports afaict.
>
> Indeed, my bad.
>
> Shouldn't you however use "adi,adv7180cp" as that's the chip we are using ?
> The "adi,adv7180" has no port documented in its DT bindings, so it shouldn't
> have any port node at all.
I'm a bit confused here.
The only Gen-2 board using the "adi,adv7180cp" compatible string is
Gose, which is also the only one I can get schematics for. That board
indeed feature an ADV7180WBCP32Z, as the Draak does. I cannot get
schematics for any other Gen-2 board, to compare the ADV7180 variant
installed there. If anyone can confirm that all other Gen-2 board uses
a different version (or that all other Gen-2 board DTS file use a
wrong compatible string value), I'll re-send this with a different
compatible value and proper port nodes numbering.
Thanks
j
>
> > >> + /*
> > >> + * The VIN4 video input path is shared between
> > >> + * CVBS and HDMI inputs through SW[49-54] switches.
> > >> + *
> > >> + * CVBS is the default selection, link it to VIN4 here.
> > >> + */
> > >> + adv7180_out: endpoint {
> > >> + remote-endpoint = <&vin4_in>;
> > >> + };
> > >> + };
> > >> + };
> > >> };
> > >>
> > >> &i2c1 {
> > >> @@ -246,3 +268,23 @@
> > >> timeout-sec = <60>;
> > >> status = "okay";
> > >> };
> > >> +
> > >> +&vin4 {
> > >> + pinctrl-0 = <&vin4_pins_cvbs>;
> > >> + pinctrl-names = "default";
> > >> +
> > >> + status = "okay";
> > >> +
> > >> + ports {
> > >> + #address-cells = <1>;
> > >> + #size-cells = <0>;
> > >> +
> > >> + port@0 {
> > >> + reg = <0>;
> > >> +
> > >> + vin4_in: endpoint {
> > >> + remote-endpoint = <&adv7180_out>;
> > >> + };
> > >> + };
> > >> + };
> > >> +};
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3] iio: dac: Add support for external reference voltage through the regulator framework.
From: Silvan Murer @ 2018-05-21 12:29 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: lars, linux-iio, devicetree
In-Reply-To: <20180520112312.668e0213@archlinux>
Hi Jonathan,
Many Thanks for your kindly feedback and your patience!
I changed my patch process and sent them now (v4) with the "git sent-
email" command. I think this would be much more stable now. I could
also test the patch by store the mail as mbox and patch them with the
"git am" command into the clean repository.
Let me know, if it works to on your side to verify my new patch
process.
Thanks for your work and patience
Silvan
On Son, 2018-05-20 at 11:23 +0100, Jonathan Cameron wrote:
> On Sun, 20 May 2018 02:19:17 +0200
> Silvan Murer <silvan.murer@gmail.com> wrote:
>
> >
> > Add support for external reference voltage through the regulator
> > framework.
> >
> > Signed-off-by: Silvan Murer <silvan.murer@gmail.com>
> > Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
> Content looks fine, but I'm having the same issue with subtle issues
> with
> patch formatting. Please check and see if you can figure out what is
> causing this.
>
> Anyhow, I'd like this to sit on the lists a little longer to give
> time for Devicetree binding feedback.
>
> Thanks,
>
> Jonathan
>
> >
> > ---
> > Changes in v3:
> > - remove extra spaces and tab
> > Changes in v2:
> > - Add 'optional properties' documentation
> > - Return an error when a regulator is specified
> > - Use internal reference when no regulator is specified
> > - Use iio_device_register instead of devm_iio_device_register
> >
> > .../devicetree/bindings/iio/dac/ltc2632.txt | 14 +++++
> > drivers/iio/dac/ltc2632.c | 70
> > +++++++++++++++++++---
> > 2 files changed, 75 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/dac/ltc2632.txt
> > b/Documentation/devicetree/bindings/iio/dac/ltc2632.txt
> > index eb911e5..e0d5fea 100644
> > --- a/Documentation/devicetree/bindings/iio/dac/ltc2632.txt
> > +++ b/Documentation/devicetree/bindings/iio/dac/ltc2632.txt
> > @@ -12,12 +12,26 @@ Required properties:
> > Property rules described in
> > Documentation/devicetree/bindings/spi/spi-bus.txt
> > apply. In particular, "reg" and "spi-max-frequency" properties
> > must be given.
> >
> > +Optional properties:
> > + - vref-supply: Phandle to the external reference voltage
> > supply. This should
> > + only be set if there is an external reference voltage
> > connected to the VREF
> > + pin. If the property is not set the internal reference
> > is used.
> > +
> > Example:
> >
> > + vref: regulator-vref {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vref-ltc2632";
> > + regulator-min-microvolt = <1250000>;
> > + regulator-max-microvolt = <1250000>;
> > + regulator-always-on;
> > + };
> > +
> > spi_master {
> > dac: ltc2632@0 {
> > compatible = "lltc,ltc2632-l12";
> > reg = <0>; /* CS0 */
> > spi-max-frequency = <1000000>;
> > + vref-supply = <&vref>; /* optional */
> > };
> > };
> > diff --git a/drivers/iio/dac/ltc2632.c b/drivers/iio/dac/ltc2632.c
> > index d322b78..9551156 100644
> > --- a/drivers/iio/dac/ltc2632.c
> > +++ b/drivers/iio/dac/ltc2632.c
> > @@ -2,6 +2,7 @@
> > * LTC2632 Digital to analog convertors spi driver
> > *
> > * Copyright 2017 Maxime Roussin-Bélanger
> > + * expanded by Silvan Murer <silvan.murer@gmail.com>
> > *
> > * Licensed under the GPL-2.
> > */
> > @@ -10,6 +11,7 @@
> > #include <linux/spi/spi.h>
> > #include <linux/module.h>
> > #include <linux/iio/iio.h>
> > +#include <linux/regulator/consumer.h>
> >
> > #define LTC2632_DAC_CHANNELS 2
> >
> > @@ -28,7 +30,7 @@
> > /**
> > * struct ltc2632_chip_info - chip specific information
> > * @channels: channel spec for the DAC
> > - * @vref_mv: reference voltage
> > + * @vref_mv: internal reference voltage
> > */
> > struct ltc2632_chip_info {
> > const struct iio_chan_spec *channels;
> > @@ -39,10 +41,14 @@ struct ltc2632_chip_info {
> > * struct ltc2632_state - driver instance specific data
> > * @spi_dev: pointer to the spi_device
> > struct
> > * @powerdown_cache_mask used to show current channel
> > powerdown state
> > + * @vref_mv used reference voltage
> > (internal or external)
> > + * @vref_reg regulator for the reference voltage
> > */
> > struct ltc2632_state {
> > struct spi_device *spi_dev;
> > unsigned int powerdown_cache_mask;
> > + int vref_mv;
> > + struct regulator *vref_reg;
> > };
> >
> > enum ltc2632_supported_device_ids {
> > @@ -90,7 +96,7 @@ static int ltc2632_read_raw(struct iio_dev
> > *indio_dev,
> >
> > switch (m) {
> > case IIO_CHAN_INFO_SCALE:
> > - *val = chip_info->vref_mv;
> > + *val = st->vref_mv;
> > *val2 = chan->scan_type.realbits;
> > return IIO_VAL_FRACTIONAL_LOG2;
> > }
> > @@ -247,6 +253,45 @@ static int ltc2632_probe(struct spi_device
> > *spi)
> > chip_info = (struct ltc2632_chip_info *)
> > spi_get_device_id(spi)->driver_data;
> >
> > + st->vref_reg = devm_regulator_get_optional(&spi->dev,
> > "vref");
> > + if (PTR_ERR(st->vref_reg) == -ENODEV) {
> > + /* use internal reference voltage */
> > + st->vref_reg = NULL;
> > + st->vref_mv = chip_info->vref_mv;
> > +
> > + ret = ltc2632_spi_write(spi,
> > LTC2632_CMD_INTERNAL_REFER,
> > + 0, 0, 0);
> > + if (ret) {
> > + dev_err(&spi->dev,
> > + "Set internal reference command
> > failed, %d\n",
> > + ret);
> > + return ret;
> > + }
> > + } else if (IS_ERR(st->vref_reg)) {
> > + dev_err(&spi->dev,
> > + "Error getting voltage reference
> > regulator\n");
> > + return PTR_ERR(st->vref_reg);
> > + } else {
> > + /* use external reference voltage */
> > + ret = regulator_enable(st->vref_reg);
> > + if (ret) {
> > + dev_err(&spi->dev,
> > + "enable reference regulator
> > failed, %d\n",
> > + ret);
> > + return ret;
> > + }
> > + st->vref_mv = regulator_get_voltage(st->vref_reg)
> > / 1000;
> > +
> > + ret = ltc2632_spi_write(spi,
> > LTC2632_CMD_EXTERNAL_REFER,
> > + 0, 0, 0);
> > + if (ret) {
> > + dev_err(&spi->dev,
> > + "Set external reference command
> > failed, %d\n",
> > + ret);
> > + return ret;
> > + }
> > + }
> > +
> > indio_dev->dev.parent = &spi->dev;
> > indio_dev->name = dev_of_node(&spi->dev) ?
> > dev_of_node(&spi->dev)->name
> > :
> > spi_get_device_id(spi)->name;
> > @@ -255,14 +300,20 @@ static int ltc2632_probe(struct spi_device
> > *spi)
> > indio_dev->channels = chip_info->channels;
> > indio_dev->num_channels = LTC2632_DAC_CHANNELS;
> >
> > - ret = ltc2632_spi_write(spi, LTC2632_CMD_INTERNAL_REFER,
> > 0, 0, 0);
> > - if (ret) {
> > - dev_err(&spi->dev,
> > - "Set internal reference command failed,
> > %d\n", ret);
> > - return ret;
> > - }
> > + return iio_device_register(indio_dev);
> > +}
> > +
> > +static int ltc2632_remove(struct spi_device *spi)
> > +{
> > + struct iio_dev *indio_dev = spi_get_drvdata(spi);
> > + struct ltc2632_state *st = iio_priv(indio_dev);
> > +
> > + iio_device_unregister(indio_dev);
> > +
> > + if (st->vref_reg)
> > + regulator_disable(st->vref_reg);
> >
> > - return devm_iio_device_register(&spi->dev, indio_dev);
> > + return 0;
> > }
> >
> > static const struct spi_device_id ltc2632_id[] = {
> > @@ -306,6 +357,7 @@ static struct spi_driver ltc2632_driver = {
> > .of_match_table = of_match_ptr(ltc2632_of_match),
> > },
> > .probe = ltc2632_probe,
> > + .remove = ltc2632_remove,
> > .id_table = ltc2632_id,
> > };
> > module_spi_driver(ltc2632_driver);
> > --
> > 2.7.4
^ permalink raw reply
* [PATCH v4 2/2] iio: dac: Add support for external reference voltage through the regulator framework.
From: Silvan Murer @ 2018-05-21 12:21 UTC (permalink / raw)
To: jic23; +Cc: lars, linux-iio, devicetree, Silvan Murer
In-Reply-To: <1526905288-28668-1-git-send-email-silvan.murer@gmail.com>
Signed-off-by: Silvan Murer <silvan.murer@gmail.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
---
.../devicetree/bindings/iio/dac/ltc2632.txt | 14 +++++
drivers/iio/dac/ltc2632.c | 70 +++++++++++++++++++---
2 files changed, 75 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/dac/ltc2632.txt b/Documentation/devicetree/bindings/iio/dac/ltc2632.txt
index eb911e5..e0d5fea 100644
--- a/Documentation/devicetree/bindings/iio/dac/ltc2632.txt
+++ b/Documentation/devicetree/bindings/iio/dac/ltc2632.txt
@@ -12,12 +12,26 @@ Required properties:
Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
apply. In particular, "reg" and "spi-max-frequency" properties must be given.
+Optional properties:
+ - vref-supply: Phandle to the external reference voltage supply. This should
+ only be set if there is an external reference voltage connected to the VREF
+ pin. If the property is not set the internal reference is used.
+
Example:
+ vref: regulator-vref {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-ltc2632";
+ regulator-min-microvolt = <1250000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-always-on;
+ };
+
spi_master {
dac: ltc2632@0 {
compatible = "lltc,ltc2632-l12";
reg = <0>; /* CS0 */
spi-max-frequency = <1000000>;
+ vref-supply = <&vref>; /* optional */
};
};
diff --git a/drivers/iio/dac/ltc2632.c b/drivers/iio/dac/ltc2632.c
index d322b78..9551156 100644
--- a/drivers/iio/dac/ltc2632.c
+++ b/drivers/iio/dac/ltc2632.c
@@ -2,6 +2,7 @@
* LTC2632 Digital to analog convertors spi driver
*
* Copyright 2017 Maxime Roussin-B�langer
+ * expanded by Silvan Murer <silvan.murer@gmail.com>
*
* Licensed under the GPL-2.
*/
@@ -10,6 +11,7 @@
#include <linux/spi/spi.h>
#include <linux/module.h>
#include <linux/iio/iio.h>
+#include <linux/regulator/consumer.h>
#define LTC2632_DAC_CHANNELS 2
@@ -28,7 +30,7 @@
/**
* struct ltc2632_chip_info - chip specific information
* @channels: channel spec for the DAC
- * @vref_mv: reference voltage
+ * @vref_mv: internal reference voltage
*/
struct ltc2632_chip_info {
const struct iio_chan_spec *channels;
@@ -39,10 +41,14 @@ struct ltc2632_chip_info {
* struct ltc2632_state - driver instance specific data
* @spi_dev: pointer to the spi_device struct
* @powerdown_cache_mask used to show current channel powerdown state
+ * @vref_mv used reference voltage (internal or external)
+ * @vref_reg regulator for the reference voltage
*/
struct ltc2632_state {
struct spi_device *spi_dev;
unsigned int powerdown_cache_mask;
+ int vref_mv;
+ struct regulator *vref_reg;
};
enum ltc2632_supported_device_ids {
@@ -90,7 +96,7 @@ static int ltc2632_read_raw(struct iio_dev *indio_dev,
switch (m) {
case IIO_CHAN_INFO_SCALE:
- *val = chip_info->vref_mv;
+ *val = st->vref_mv;
*val2 = chan->scan_type.realbits;
return IIO_VAL_FRACTIONAL_LOG2;
}
@@ -247,6 +253,45 @@ static int ltc2632_probe(struct spi_device *spi)
chip_info = (struct ltc2632_chip_info *)
spi_get_device_id(spi)->driver_data;
+ st->vref_reg = devm_regulator_get_optional(&spi->dev, "vref");
+ if (PTR_ERR(st->vref_reg) == -ENODEV) {
+ /* use internal reference voltage */
+ st->vref_reg = NULL;
+ st->vref_mv = chip_info->vref_mv;
+
+ ret = ltc2632_spi_write(spi, LTC2632_CMD_INTERNAL_REFER,
+ 0, 0, 0);
+ if (ret) {
+ dev_err(&spi->dev,
+ "Set internal reference command failed, %d\n",
+ ret);
+ return ret;
+ }
+ } else if (IS_ERR(st->vref_reg)) {
+ dev_err(&spi->dev,
+ "Error getting voltage reference regulator\n");
+ return PTR_ERR(st->vref_reg);
+ } else {
+ /* use external reference voltage */
+ ret = regulator_enable(st->vref_reg);
+ if (ret) {
+ dev_err(&spi->dev,
+ "enable reference regulator failed, %d\n",
+ ret);
+ return ret;
+ }
+ st->vref_mv = regulator_get_voltage(st->vref_reg) / 1000;
+
+ ret = ltc2632_spi_write(spi, LTC2632_CMD_EXTERNAL_REFER,
+ 0, 0, 0);
+ if (ret) {
+ dev_err(&spi->dev,
+ "Set external reference command failed, %d\n",
+ ret);
+ return ret;
+ }
+ }
+
indio_dev->dev.parent = &spi->dev;
indio_dev->name = dev_of_node(&spi->dev) ? dev_of_node(&spi->dev)->name
: spi_get_device_id(spi)->name;
@@ -255,14 +300,20 @@ static int ltc2632_probe(struct spi_device *spi)
indio_dev->channels = chip_info->channels;
indio_dev->num_channels = LTC2632_DAC_CHANNELS;
- ret = ltc2632_spi_write(spi, LTC2632_CMD_INTERNAL_REFER, 0, 0, 0);
- if (ret) {
- dev_err(&spi->dev,
- "Set internal reference command failed, %d\n", ret);
- return ret;
- }
+ return iio_device_register(indio_dev);
+}
+
+static int ltc2632_remove(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev = spi_get_drvdata(spi);
+ struct ltc2632_state *st = iio_priv(indio_dev);
+
+ iio_device_unregister(indio_dev);
+
+ if (st->vref_reg)
+ regulator_disable(st->vref_reg);
- return devm_iio_device_register(&spi->dev, indio_dev);
+ return 0;
}
static const struct spi_device_id ltc2632_id[] = {
@@ -306,6 +357,7 @@ static struct spi_driver ltc2632_driver = {
.of_match_table = of_match_ptr(ltc2632_of_match),
},
.probe = ltc2632_probe,
+ .remove = ltc2632_remove,
.id_table = ltc2632_id,
};
module_spi_driver(ltc2632_driver);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/2] iio: dac: fix missing of_match_table assignment in the LTC 2632 device
From: Silvan Murer @ 2018-05-21 12:21 UTC (permalink / raw)
To: jic23; +Cc: lars, linux-iio, devicetree, Silvan Murer
In-Reply-To: <1526905288-28668-1-git-send-email-silvan.murer@gmail.com>
Signed-off-by: Silvan Murer <silvan.murer@gmail.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
---
drivers/iio/dac/ltc2632.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/iio/dac/ltc2632.c b/drivers/iio/dac/ltc2632.c
index ac5e05f..d322b78 100644
--- a/drivers/iio/dac/ltc2632.c
+++ b/drivers/iio/dac/ltc2632.c
@@ -276,15 +276,6 @@ static const struct spi_device_id ltc2632_id[] = {
};
MODULE_DEVICE_TABLE(spi, ltc2632_id);
-static struct spi_driver ltc2632_driver = {
- .driver = {
- .name = "ltc2632",
- },
- .probe = ltc2632_probe,
- .id_table = ltc2632_id,
-};
-module_spi_driver(ltc2632_driver);
-
static const struct of_device_id ltc2632_of_match[] = {
{
.compatible = "lltc,ltc2632-l12",
@@ -309,6 +300,16 @@ static const struct of_device_id ltc2632_of_match[] = {
};
MODULE_DEVICE_TABLE(of, ltc2632_of_match);
+static struct spi_driver ltc2632_driver = {
+ .driver = {
+ .name = "ltc2632",
+ .of_match_table = of_match_ptr(ltc2632_of_match),
+ },
+ .probe = ltc2632_probe,
+ .id_table = ltc2632_id,
+};
+module_spi_driver(ltc2632_driver);
+
MODULE_AUTHOR("Maxime Roussin-Belanger <maxime.roussinbelanger@gmail.com>");
MODULE_DESCRIPTION("LTC2632 DAC SPI driver");
MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/2] iio: dac: update ltc2632 device driver
From: Silvan Murer @ 2018-05-21 12:21 UTC (permalink / raw)
To: jic23; +Cc: lars, linux-iio, devicetree
Changes in v4:
- fix patch format issues
Change in v3:
- remove extra spaces and tab
Changes in v2:
- Add 'optional properties' documentation
- Return an error when a regulator is specified
- Use internal reference when no regulator is specified
- Use iio_device_register instead of devm_iio_device_register
^ permalink raw reply
* Re: [reset-control] How to initialize hardware state with the shared reset line?
From: Hans de Goede @ 2018-05-21 12:14 UTC (permalink / raw)
To: Masahiro Yamada, Martin Blumenstingl
Cc: Philipp Zabel, Rob Herring, Lee Jones, Felipe Balbi, DTML,
Arnd Bergmann, Linus Walleij, Linux Kernel Mailing List,
linux-arm-kernel
In-Reply-To: <CAK7LNAR1b_F_eLEWAdQc3L=daGz=ttKq0mQP78BkjzTOssaXvw@mail.gmail.com>
Hi,
On 21-05-18 03:27, Masahiro Yamada wrote:
> Hi.
>
>
> 2018-05-20 19:57 GMT+09:00 Martin Blumenstingl
> <martin.blumenstingl@googlemail.com>:
>> Hi,
>>
>> On Thu, May 10, 2018 at 11:16 AM, Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>> [snip]
>>> I may be missing something, but
>>> one solution might be reset hogging on the
>>> reset provider side. This allows us to describe
>>> the initial state of reset lines in the reset controller.
>>>
>>> The idea for "reset-hog" is similar to:
>>> - "gpio-hog" defined in
>>> Documentation/devicetree/bindings/gpio/gpio.txt
>>> - "assigned-clocks" defined in
>>> Documetation/devicetree/bindings/clock/clock-bindings.txt
>>>
>>>
>>>
>>> For example,
>>>
>>> reset-controller {
>>> ....
>>>
>>> line_a {
>>> reset-hog;
>>> resets = <1>;
>>> reset-assert;
>>> };
>>> }
>>>
>>>
>>> When the reset controller is registered,
>>> the reset ID '1' is asserted.
>>>
>>>
>>> So, all reset consumers that share the reset line '1'
>>> will start from the asserted state
>>> (i.e. defined state machine state).
>> I wonder if a "reset hog" can be board specific:
>> - GPIO hogs are definitely board specific (meson-gxbb-odroidc2.dts for
>> example uses it to take the USB hub out of reset)
>> - assigned-clock-parents (and the like) can also be board specific (I
>> made up a use-case since I don't know of any actual examples: board A
>> uses an external XTAL while board B uses some other internal
>> clock-source because it doesn't have an external XTAL)
>>
>> however, can reset lines be board specific? or in other words: do we
>> need to describe them in device-tree?
>
> Indeed.
>
> I did not come up with board-specific cases.
>
> The problem we are discussing is SoC-specific,
> and reset-controller drivers are definitely SoC-specific.
>
> So, I think the initial state can be coded in drivers instead of DT.
>
>
>> we could extend struct reset_controller_dev (= reset controller
>> driver) if they are not board specific:
>> - either assert all reset lines by default except if they are listed
>> in a new field (may break backwards compatibility, requires testing of
>> all reset controller drivers)
>
> This is quite simple, but I am afraid there are some cases where the forcible
> reset-assert is not preferred.
>
> For example, the earlycon. When we use earlycon, we would expect it has been
> initialized by a boot-loader, or something.
> If it is reset-asserted on the while, the console output
> will not be good.
>
>
>
>> - specify a list of reset lines and their desired state (or to keep it
>> easy: specify a list of reset lines that should be asserted)
>> (I must admit that this is basically your idea but the definition is
>> moved from device-tree to the reset controller driver)
>
> Yes, I think the list of "reset line ID" and "init state" pairs
> would be nicer.
>
>
>> any "chip" specific differences could be expressed by using a
>> different of_device_id
>>
>> one the other hand: your "reset hog" solution looks fine to me if
>> reset lines can be board specific
>>
>>> From the discussion with Martin Blumenstingl
>>> (https://lkml.org/lkml/2018/4/28/115),
>>> the problem for Amlogic is that
>>> the reset line is "de-asserted" by default.
>>> If so, the 'reset-hog' would fix the problem,
>>> and DWC3 driver would be able to use
>>> shared, level reset, I think.
>> I think you are right: if we could control the initial state then we
>> should be able to use level resets
>
>
> Even further, can we drop the shared reset_control_reset() support, maybe?
> (in other words, revert commit 7da33a37b48f11)
At least one some Allwinner ships shared-reset support accurately
models how the hardware works. It seems that the case you are
trying to fix is actually a special version of shared reset support,
you want shared reset behavior, combined with making sure the reset
is asserted at reset-controller-driver load time.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Russell King - ARM Linux @ 2018-05-21 12:11 UTC (permalink / raw)
To: ilialin
Cc: viresh.kumar, devicetree, linux-pm, linux-arm-msm, linux-kernel,
linux-soc, linux-clk, linux-arm-kernel
In-Reply-To: <000b01d3f0f3$aa961cc0$ffc25640$@codeaurora.org>
On Mon, May 21, 2018 at 02:05:41PM +0300, ilialin@codeaurora.org wrote:
> You are right.
> cpu_dev_silver != cpu_dev_gold, and I found this with my tests as well.
> Thank you.
>
> > -----Original Message-----
> > From: Russell King - ARM Linux <linux@armlinux.org.uk>
> > Sent: Monday, May 21, 2018 13:54
> > To: Ilia Lin <ilialin@codeaurora.org>
> > Cc: viresh.kumar@linaro.org; devicetree@vger.kernel.org; linux-
> > pm@vger.kernel.org; linux-arm-msm@vger.kernel.org; linux-
> > kernel@vger.kernel.org; linux-soc@vger.kernel.org; linux-
> > clk@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> > Subject: Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
> >
> > On Mon, May 21, 2018 at 01:31:30PM +0300, Ilia Lin wrote:
> > > +#define SILVER_LEAD 0
> > > +#define GOLD_LEAD 2
> >
> > Okay, two different values here, but "GOLD_LEAD" appears unused.
> >
> > > + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> > > + if (NULL == cpu_dev_silver)
> > > + return -ENODEV;
> > > +
> > > + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
> > > + if (NULL == cpu_dev_gold)
> > > + return -ENODEV;
> >
> > get_cpu_device() takes the logical CPU number. So the above gets CPU 0
> > each time, and so cpu_dev_silver == cpu_dev_gold here. So what's the
> > point of the second get_cpu_device() ? If it's supposed to be:
> >
> > cpu_dev_gold = get_cpu_device(GOLD_LEAD);
> >
> > That would get CPU 2, but in terms of these defines, it doesn't make that
> > much sense. What exactly does "silver lead" and "gold lead" refer to in
> these
> > definitions?
I think you still need to explain this.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH 2/2] slimbus: ngd: Add qcom SLIMBus NGD driver
From: Srinivas Kandagatla @ 2018-05-21 11:55 UTC (permalink / raw)
To: Vinod
Cc: mark.rutland, devicetree, alsa-devel, girishm, bgoswami, gregkh,
broonie, linux-kernel, robh+dt, kramasub, linux-arm-msm, sdharia
In-Reply-To: <20180521113314.GC14654@vkoul-mobl>
Thanks Vinod for the review!
On 21/05/18 12:33, Vinod wrote:
> On 16-05-18, 17:51, Srinivas Kandagatla wrote:
>> This patch adds suppor to Qualcomm SLIMBus Non-Generic Device (NGD)
>
> /s/suppor/support
>
Yep, Will fix this in next version.
>> +/* NGD (Non-ported Generic Device) registers */
>> +#define NGD_CFG 0x0
>> +#define NGD_CFG_ENABLE BIT(0)
>> +#define NGD_CFG_RX_MSGQ_EN BIT(1)
>> +#define NGD_CFG_TX_MSGQ_EN BIT(2)
>> +#define NGD_STATUS 0x4
>> +#define NGD_LADDR BIT(1)
>> +#define NGD_RX_MSGQ_CFG 0x8
>> +#define NGD_INT_EN 0x10
>> +#define SLIMBUS_QMI_POWER_RESP_MAX_MSG_LEN 7
>> +#define SLIMBUS_QMI_SELECT_INSTANCE_REQ_MAX_MSG_LEN 14
>> +#define SLIMBUS_QMI_SELECT_INSTANCE_RESP_MAX_MSG_LEN 7
>> +#define SLIMBUS_QMI_CHECK_FRAMER_STAT_RESP_MAX_MSG_LEN 7
>> +/* QMI response timeout of 500ms */
>> +#define SLIMBUS_QMI_RESP_TOUT 1000
>
> Tabs or spaces, take your pick and use one, not both...
I will check for such instances once again before sending v2.
>
>> +static void qcom_slim_qmi_power_resp_cb(struct qmi_handle *handle,
>> + struct sockaddr_qrtr *sq,
>> + struct qmi_txn *txn, const void *data)
>> +{
>> + struct slimbus_power_resp_msg_v01 *resp;
>> +
>> + resp = (struct slimbus_power_resp_msg_v01 *)data;
>
> you dont need cast away from void
It's a const void * so the compiler keeps complaining about this without
cast.
>
>> + if (resp->resp.result != QMI_RESULT_SUCCESS_V01)
>> + pr_err("%s: QMI power request failed 0x%x\n", __func__,
>> + resp->resp.result);
>
> cant we use dev_err?
I will have a look!
>
>> +static int qcom_slim_qmi_send_power_request(struct qcom_slim_ngd_ctrl *ctrl,
>> + struct slimbus_power_req_msg_v01 *req)
>> +{
>> + struct slimbus_power_resp_msg_v01 resp = { { 0, 0 } };
>> + struct qmi_txn txn;
>> + int rc;
>> +
>> + rc = qmi_txn_init(ctrl->qmi.handle, &txn,
>> + slimbus_power_resp_msg_v01_ei, &resp);
>> +
>> + rc = qmi_send_request(ctrl->qmi.handle, NULL, &txn,
>> + SLIMBUS_QMI_POWER_REQ_V01,
>> + SLIMBUS_QMI_POWER_REQ_MAX_MSG_LEN,
>> + slimbus_power_req_msg_v01_ei, req);
>> + if (rc < 0) {
>> + dev_err(ctrl->dev, "%s: QMI send req fail %d\n", __func__, rc);
>> + qmi_txn_cancel(&txn);
>> + }
>> +
>> + if (rc < 0)
>> + return rc;
>
> why not add this is prev error check?
Yes, we should move this to previous check, Will fix this in v2.
>
>> +static int qcom_slim_qmi_init(struct qcom_slim_ngd_ctrl *ctrl,
>> + bool apps_is_master)
>> +{
>> + int rc = 0;
>
> superfluous init
>
>> +static u32 *qcom_slim_ngd_tx_msg_get(struct qcom_slim_ngd_ctrl *ctrl, int len,
>> + struct completion *comp)
>> +{
>> + struct qcom_slim_ngd_dma_desc *desc;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&ctrl->tx_buf_lock, flags);
>> +
>> + if ((ctrl->tx_tail + 1) % QCOM_SLIM_NGD_DESC_NUM == ctrl->tx_head) {
>> + spin_unlock_irqrestore(&ctrl->tx_buf_lock, flags);
>> + return NULL;
>> + }
>> + desc = &ctrl->txdesc[ctrl->tx_tail];
>> + desc->base = (u32 *)((u8 *)ctrl->tx_base +
>> + (ctrl->tx_tail * SLIM_MSGQ_BUF_LEN));
>
> too many casts
>
>> +static int qcom_slim_ngd_post_rx_msgq(struct qcom_slim_ngd_ctrl *ctrl)
>> +{
>> + struct qcom_slim_ngd_dma_desc *desc;
>> + struct dma_slave_config conf = {
>> + .direction = DMA_DEV_TO_MEM,
>> + };
>> + int ret, i;
>> +
>> + ret = dmaengine_slave_config(ctrl->dma_rx_channel, &conf);
>
> so you are only setting direction for conf, not any other parameters? If not why
> bother setting direction
Nice hint, I will remove this!
>
>> + if (ret)
>> + dev_err(ctrl->dev, "Error Configuring rx dma\n");
>> +
>> + for (i = 0; i < QCOM_SLIM_NGD_DESC_NUM; i++) {
>> + desc = &ctrl->rx_desc[i];
>> + desc->phys = ctrl->rx_phys_base + i * SLIM_MSGQ_BUF_LEN;
>> + desc->ctrl = ctrl;
>> + desc->base = ctrl->rx_base + i * SLIM_MSGQ_BUF_LEN;
>> + desc->desc = dmaengine_prep_slave_single(ctrl->dma_rx_channel,
>> + desc->phys, SLIM_MSGQ_BUF_LEN,
>> + DMA_DEV_TO_MEM,
>> + DMA_PREP_INTERRUPT);
>
> why issue multiple slave_single to dmaengine, you can bundle them and issue
> dmaengine_prep_slave_sg()..
Am reusing the descriptors here, My plan is to issue multiple
descriptors with callback for each, and in each callback queue it back.
>
>> +static int qcom_slim_ngd_qmi_svc_event_init(struct qcom_slim_ngd_qmi *qmi)
>> +{
>> + int ret = 0;
>
> superfluous init here too
>
Yep.
>> +static int qcom_slim_ngd_runtime_idle(struct device *dev)
>> +{
>> + struct qcom_slim_ngd_ctrl *ctrl = dev_get_drvdata(dev);
>> +
>> + if (ctrl->state == QCOM_SLIM_NGD_CTRL_AWAKE)
>> + ctrl->state = QCOM_SLIM_NGD_CTRL_IDLE;
>> + pm_request_autosuspend(dev);
>> + return -EAGAIN;
>> +}
>> +
>> +
>
> double empty lines, here
Sure, will fix this in v2.
>
thanks,
srini
^ permalink raw reply
* [PATCH v2] ARM64: dts: sun50i: h5: Add spi flash node for OrangePi PC2
From: Emmanuel Vadot @ 2018-05-21 11:54 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt, mark.rutland, catalin.marinas,
will.deacon, linux-arm-kernel, devicetree, linux-kernel
Cc: Emmanuel Vadot
The OrangePi PC2 have an mx25l1606e spi flash.
Add a node for it.
Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
---
Changes in v2:
- Only use the compatible 'jedec,spi-nor' since the device answer to
the jedec command 0x9F
arch/arm64//boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
index 98862c7c7258..3e0d5a9c096d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
@@ -207,6 +207,18 @@
status = "okay";
};
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.17.0
^ permalink raw reply related
* [PATCH v2] ARM64: dts: sun50i: a64: Add spi flash node for sopine
From: Emmanuel Vadot @ 2018-05-21 11:54 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt, mark.rutland, catalin.marinas,
will.deacon, linux-arm-kernel, devicetree, linux-kernel
Cc: Emmanuel Vadot
The Sopine and Pine64-LTS have a winbond w25q128 spi flash on spi0.
Add a node for it.
Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
---
Changes in v2:
- Only use the compatible 'jedec,spi-nor' since the device answer to
the jedec command 0x9F
arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
index 43418bd881d8..b94f93c04acb 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
@@ -66,6 +66,18 @@
};
};
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ };
+};
+
#include "axp803.dtsi"
®_aldo2 {
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 0/2] mmc: meson-gx: add device reset
From: Ulf Hansson @ 2018-05-21 11:36 UTC (permalink / raw)
To: Jerome Brunet
Cc: Carlo Caione, Kevin Hilman, devicetree,
open list:ARM/Amlogic Meson..., linux-mmc@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <20180515095748.6794-1-jbrunet@baylibre.com>
On 15 May 2018 at 11:57, Jerome Brunet <jbrunet@baylibre.com> wrote:
> This patchset adds the optional reset of the meson-gx mmc controller and
> the related documentation.
>
> Changes since v1: [0]
> * Correct typo in the documentation
> * Separate code and documentation patches
> * Error on reset failure.
>
> [0]: https://lkml.kernel.org/r/20180426103817.12675-1-jbrunet@baylibre.com
>
> Jerome Brunet (2):
> dt-bindings: mmc: meson-gx: add reset
> mmc: meson-gx: add device reset
>
> Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt | 2 ++
> drivers/mmc/host/meson-gx-mmc.c | 9 +++++++++
> 2 files changed, 11 insertions(+)
>
> --
> 2.14.3
>
Thanks, applied for next!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v7 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver
From: Ulf Hansson @ 2018-05-21 11:36 UTC (permalink / raw)
To: Liming Sun
Cc: Rob Herring, Mark Rutland, Jaehoon Chung, Catalin Marinas,
Will Deacon, linux-mmc@vger.kernel.org, devicetree,
Linux Kernel Mailing List
In-Reply-To: <1525805210-15246-3-git-send-email-lsun@mellanox.com>
On 8 May 2018 at 20:46, Liming Sun <lsun@mellanox.com> wrote:
> This patch updates arm64 defconfig to enable dw_mmc-bluefield,
> which is a driver extension of Synopsys Designware MMC for the
> Mellanox BlueField Soc.
>
> Signed-off-by: Liming Sun <lsun@mellanox.com>
> Reviewed-by: David Woods <dwoods@mellanox.com>
I have applied the other parts in the series, but not this one as it's
probably better it goes via arm soc.
I can take it, but then I need an ack from arm64 folkz...
Kind regards
Uffe
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index ecf6137..43464ab 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -487,6 +487,7 @@ CONFIG_MMC_DW=y
> CONFIG_MMC_DW_EXYNOS=y
> CONFIG_MMC_DW_K3=y
> CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_DW_BLUEFIELD=y
> CONFIG_MMC_SUNXI=y
> CONFIG_MMC_BCM2835=y
> CONFIG_MMC_SDHCI_XENON=y
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v7 2/3] dt-bindings: mmc: Add binding for BlueField SoC
From: Ulf Hansson @ 2018-05-21 11:36 UTC (permalink / raw)
To: Liming Sun
Cc: Rob Herring, Mark Rutland, Jaehoon Chung, Catalin Marinas,
Will Deacon, linux-mmc@vger.kernel.org, devicetree,
Linux Kernel Mailing List
In-Reply-To: <1525805210-15246-2-git-send-email-lsun@mellanox.com>
On 8 May 2018 at 20:46, Liming Sun <lsun@mellanox.com> wrote:
> This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
> extension on Mellanox BlueField SoC platform.
>
> Signed-off-by: Liming Sun <lsun@mellanox.com>
> Reviewed-by: David Woods <dwoods@mellanox.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks, applied for next!
Kind regards
Uffe
> ---
> .../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
> new file mode 100644
> index 0000000..b0f0999
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
> @@ -0,0 +1,29 @@
> +* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
> + Mobile Storage Host Controller
> +
> +Read synopsys-dw-mshc.txt for more details
> +
> +The Synopsys designware mobile storage host controller is used to interface
> +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
> +differences between the core Synopsys dw mshc controller properties described
> +by synopsys-dw-mshc.txt and the properties used by the Mellanox Bluefield SoC
> +specific extensions to the Synopsys Designware Mobile Storage Host Controller.
> +
> +Required Properties:
> +
> +* compatible: should be one of the following.
> + - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield SoC
> + specific extensions.
> +
> +Example:
> +
> + /* Mellanox Bluefield SoC MMC */
> + mmc@6008000 {
> + compatible = "mellanox,bluefield-dw-mshc";
> + reg = <0x6008000 0x400>;
> + interrupts = <32>;
> + fifo-depth = <0x100>;
> + clock-frequency = <24000000>;
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + };
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v7 1/3] mmc: dw_mmc-bluefield: Add driver extension
From: Ulf Hansson @ 2018-05-21 11:36 UTC (permalink / raw)
To: Liming Sun
Cc: Rob Herring, Mark Rutland, Jaehoon Chung, Catalin Marinas,
Will Deacon, linux-mmc@vger.kernel.org, devicetree,
Linux Kernel Mailing List
In-Reply-To: <1525805210-15246-1-git-send-email-lsun@mellanox.com>
On 8 May 2018 at 20:46, Liming Sun <lsun@mellanox.com> wrote:
> This commit adds extension to the dw_mmc driver for Mellanox BlueField
> SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
> this SoC.
>
> Signed-off-by: Liming Sun <lsun@mellanox.com>
> Reviewed-by: David Woods <dwoods@mellanox.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/Kconfig | 9 +++++
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/dw_mmc-bluefield.c | 81 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 91 insertions(+)
> create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 9589f9c..7784f76 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -690,6 +690,15 @@ config MMC_DW_PLTFM
>
> If unsure, say Y.
>
> +config MMC_DW_BLUEFIELD
> + tristate "BlueField specific extensions for Synopsys DW Memory Card Interface"
> + depends on MMC_DW
> + select MMC_DW_PLTFM
> + help
> + This selects support for Mellanox BlueField SoC specific extensions to
> + the Synopsys DesignWare Memory Card Interface driver. Select this
> + option for platforms based on Mellanox BlueField SoC's.
> +
> config MMC_DW_EXYNOS
> tristate "Exynos specific extensions for Synopsys DW Memory Card Interface"
> depends on MMC_DW
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 6aead24..85dc132 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -49,6 +49,7 @@ thunderx-mmc-objs := cavium.o cavium-thunderx.o
> obj-$(CONFIG_MMC_CAVIUM_THUNDERX) += thunderx-mmc.o
> obj-$(CONFIG_MMC_DW) += dw_mmc.o
> obj-$(CONFIG_MMC_DW_PLTFM) += dw_mmc-pltfm.o
> +obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
> obj-$(CONFIG_MMC_DW_EXYNOS) += dw_mmc-exynos.o
> obj-$(CONFIG_MMC_DW_HI3798CV200) += dw_mmc-hi3798cv200.o
> obj-$(CONFIG_MMC_DW_K3) += dw_mmc-k3.o
> diff --git a/drivers/mmc/host/dw_mmc-bluefield.c b/drivers/mmc/host/dw_mmc-bluefield.c
> new file mode 100644
> index 0000000..54c3fbb
> --- /dev/null
> +++ b/drivers/mmc/host/dw_mmc-bluefield.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Mellanox Technologies.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/mmc/host.h>
> +#include <linux/mmc/mmc.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +
> +#include "dw_mmc.h"
> +#include "dw_mmc-pltfm.h"
> +
> +#define UHS_REG_EXT_SAMPLE_MASK GENMASK(22, 16)
> +#define UHS_REG_EXT_DRIVE_MASK GENMASK(29, 23)
> +#define BLUEFIELD_UHS_REG_EXT_SAMPLE 2
> +#define BLUEFIELD_UHS_REG_EXT_DRIVE 4
> +
> +static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct mmc_ios *ios)
> +{
> + u32 reg;
> +
> + /* Update the Drive and Sample fields in register UHS_REG_EXT. */
> + reg = mci_readl(host, UHS_REG_EXT);
> + reg &= ~UHS_REG_EXT_SAMPLE_MASK;
> + reg |= FIELD_PREP(UHS_REG_EXT_SAMPLE_MASK,
> + BLUEFIELD_UHS_REG_EXT_SAMPLE);
> + reg &= ~UHS_REG_EXT_DRIVE_MASK;
> + reg |= FIELD_PREP(UHS_REG_EXT_DRIVE_MASK, BLUEFIELD_UHS_REG_EXT_DRIVE);
> + mci_writel(host, UHS_REG_EXT, reg);
> +}
> +
> +static const struct dw_mci_drv_data bluefield_drv_data = {
> + .set_ios = dw_mci_bluefield_set_ios
> +};
> +
> +static const struct of_device_id dw_mci_bluefield_match[] = {
> + { .compatible = "mellanox,bluefield-dw-mshc",
> + .data = &bluefield_drv_data },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, dw_mci_bluefield_match);
> +
> +static int dw_mci_bluefield_probe(struct platform_device *pdev)
> +{
> + const struct dw_mci_drv_data *drv_data = NULL;
> + const struct of_device_id *match;
> +
> + if (pdev->dev.of_node) {
> + match = of_match_node(dw_mci_bluefield_match,
> + pdev->dev.of_node);
> + drv_data = match->data;
> + }
> +
> + return dw_mci_pltfm_register(pdev, drv_data);
> +}
> +
> +static struct platform_driver dw_mci_bluefield_pltfm_driver = {
> + .probe = dw_mci_bluefield_probe,
> + .remove = dw_mci_pltfm_remove,
> + .driver = {
> + .name = "dwmmc_bluefield",
> + .of_match_table = dw_mci_bluefield_match,
> + .pm = &dw_mci_pltfm_pmops,
> + },
> +};
> +
> +module_platform_driver(dw_mci_bluefield_pltfm_driver);
> +
> +MODULE_DESCRIPTION("BlueField DW Multimedia Card driver");
> +MODULE_AUTHOR("Mellanox Technologies");
> +MODULE_LICENSE("GPL v2");
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v3 2/2] mmc: core: add tunable delay waiting for power to be stable
From: Ulf Hansson @ 2018-05-21 11:36 UTC (permalink / raw)
To: Shawn Lin
Cc: Rob Herring, linux-mmc@vger.kernel.org, Wolfram Sang,
Adrian Hunter, devicetree
In-Reply-To: <1525741460-109455-2-git-send-email-shawn.lin@rock-chips.com>
On 8 May 2018 at 03:04, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> The hard-coded 10ms delay in mmc_power_up came from
> commit 79bccc5aefb4 ("mmc: increase power up delay"), which said "The TI
> controller on Toshiba Tecra M5 needs more time to power up or the cards
> will init incorrectly or not at all." But it's too engineering solution
> for a special board but force all platforms to wait for that long time,
> especially painful for mmc_power_up for eMMC when booting.
>
> However, it's added since 2009, and we can't tell if other platforms
> benefit from it. But in practise, the modern hardware are most likely to
> have a stable power supply with 1ms after setting it for no matter PMIC
> or discrete power. And more importnatly, most regulators implement the
> callback of ->set_voltage_time_sel() for regulator core to wait for
> specific period of time for the power supply to be stable, which means
> once regulator_set_voltage_* return, the power should reach the the
> minimum voltage that works for initialization. Of course, if there
> are some other ways for host to power the card, we should allow them
> to argue a suitable delay as well.
>
> With this patch, we could assign the delay from firmware, or we could
> assigne it via ->set_ios() callback from host drivers.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Thanks, applied for next!
Kind regards
Uffe
>
> ---
>
> Changes in v3:
> - reuse post-power-on-delay-ms
>
> Changes in v2:
> - allow to assign zero delay from firmware suggested by Adrain
>
> drivers/mmc/core/core.c | 4 ++--
> drivers/mmc/core/host.c | 4 ++++
> include/linux/mmc/host.h | 1 +
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 121ce50..a52e9c2 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1658,7 +1658,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
> * This delay should be sufficient to allow the power supply
> * to reach the minimum voltage.
> */
> - mmc_delay(10);
> + mmc_delay(host->ios.power_delay_ms);
>
> mmc_pwrseq_post_power_on(host);
>
> @@ -1671,7 +1671,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
> * This delay must be at least 74 clock sizes, or 1 ms, or the
> * time required to reach a stable voltage.
> */
> - mmc_delay(10);
> + mmc_delay(host->ios.power_delay_ms);
> }
>
> void mmc_power_off(struct mmc_host *host)
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 64b03d6..b04f239 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -338,6 +338,9 @@ int mmc_of_parse(struct mmc_host *host)
> host->dsr_req = 0;
> }
>
> + device_property_read_u32(dev, "post-power-on-delay-ms",
> + &host->ios.power_delay_ms);
> +
> return mmc_pwrseq_alloc(host);
> }
>
> @@ -403,6 +406,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
> host->max_blk_count = PAGE_SIZE / 512;
>
> host->fixed_drv_type = -EINVAL;
> + host->ios.power_delay_ms = 10;
>
> return host;
> }
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 7c6eaf6..efa9bab 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -22,6 +22,7 @@
> struct mmc_ios {
> unsigned int clock; /* clock rate */
> unsigned short vdd;
> + unsigned int power_delay_ms; /* waiting for stable power */
>
> /* vdd stores the bit number of the selected voltage range from below. */
>
> --
> 1.9.1
>
>
^ permalink raw reply
* Re: [PATCH v3 1/2] Documentation: mmc: addtional description for post-power-on-delay-ms
From: Ulf Hansson @ 2018-05-21 11:35 UTC (permalink / raw)
To: Shawn Lin
Cc: Rob Herring, linux-mmc@vger.kernel.org, Wolfram Sang,
Adrian Hunter, devicetree
In-Reply-To: <1525741460-109455-1-git-send-email-shawn.lin@rock-chips.com>
On 8 May 2018 at 03:04, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> post-power-on-delay-ms woule be reused to substitute the hard-coded 10ms
> delay waiting for power supply to be stable, specificed by individual
> platform/board. Default to 10ms as before, if no available.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Thanks, applied for next!
Kind regards
Uffe
>
> ---
>
> Changes in v3:
> - reused post-power-on-delay-ms suggested by Rob
>
> Changes in v2: None
>
> Documentation/devicetree/bindings/mmc/mmc.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
> index 467cd7b..a1d0cf4 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> @@ -56,6 +56,10 @@ Optional properties:
> - fixed-emmc-driver-type: for non-removable eMMC, enforce this driver type.
> The value <n> is the driver type as specified in the eMMC specification
> (table 206 in spec version 5.1).
> +- post-power-on-delay-ms : It was invented for MMC pwrseq-simple which could
> + be referred to mmc-pwrseq-simple.txt. But now it's reused as a tunable delay
> + waiting for I/O signalling and card power supply to be stable, regardless of
> + whether pwrseq-simple is used. Default to 10ms if no available.
>
> *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
> polarity properties, we have to fix the meaning of the "normal" and "inverted"
> --
> 1.9.1
>
>
^ permalink raw reply
* Re: [PATCH 2/2] slimbus: ngd: Add qcom SLIMBus NGD driver
From: Vinod @ 2018-05-21 11:33 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: gregkh, robh+dt, kramasub, sdharia, girishm, linux-kernel,
mark.rutland, bgoswami, devicetree, broonie, linux-arm-msm,
alsa-devel
In-Reply-To: <20180516165118.16551-3-srinivas.kandagatla@linaro.org>
On 16-05-18, 17:51, Srinivas Kandagatla wrote:
> This patch adds suppor to Qualcomm SLIMBus Non-Generic Device (NGD)
/s/suppor/support
> +/* NGD (Non-ported Generic Device) registers */
> +#define NGD_CFG 0x0
> +#define NGD_CFG_ENABLE BIT(0)
> +#define NGD_CFG_RX_MSGQ_EN BIT(1)
> +#define NGD_CFG_TX_MSGQ_EN BIT(2)
> +#define NGD_STATUS 0x4
> +#define NGD_LADDR BIT(1)
> +#define NGD_RX_MSGQ_CFG 0x8
> +#define NGD_INT_EN 0x10
> +#define NGD_INT_RECFG_DONE BIT(24)
> +#define NGD_INT_TX_NACKED_2 BIT(25)
> +#define NGD_INT_MSG_BUF_CONTE BIT(26)
> +#define NGD_INT_MSG_TX_INVAL BIT(27)
> +#define NGD_INT_IE_VE_CHG BIT(28)
> +#define NGD_INT_DEV_ERR BIT(29)
> +#define NGD_INT_RX_MSG_RCVD BIT(30)
> +#define NGD_INT_TX_MSG_SENT BIT(31)
> +#define NGD_INT_STAT 0x14
> +#define NGD_INT_CLR 0x18
> +#define DEF_NGD_INT_MASK (NGD_INT_TX_NACKED_2 | NGD_INT_MSG_BUF_CONTE | \
> + NGD_INT_MSG_TX_INVAL | NGD_INT_IE_VE_CHG | \
> + NGD_INT_DEV_ERR | NGD_INT_TX_MSG_SENT | \
> + NGD_INT_RX_MSG_RCVD)
> +
> +/* Slimbus QMI service */
> +#define SLIMBUS_QMI_SVC_ID 0x0301
> +#define SLIMBUS_QMI_SVC_V1 1
> +#define SLIMBUS_QMI_INS_ID 0
> +#define SLIMBUS_QMI_SELECT_INSTANCE_REQ_V01 0x0020
> +#define SLIMBUS_QMI_SELECT_INSTANCE_RESP_V01 0x0020
> +#define SLIMBUS_QMI_POWER_REQ_V01 0x0021
> +#define SLIMBUS_QMI_POWER_RESP_V01 0x0021
> +#define SLIMBUS_QMI_CHECK_FRAMER_STATUS_REQ 0x0022
> +#define SLIMBUS_QMI_CHECK_FRAMER_STATUS_RESP 0x0022
> +#define SLIMBUS_QMI_POWER_REQ_MAX_MSG_LEN 14
> +#define SLIMBUS_QMI_POWER_RESP_MAX_MSG_LEN 7
> +#define SLIMBUS_QMI_SELECT_INSTANCE_REQ_MAX_MSG_LEN 14
> +#define SLIMBUS_QMI_SELECT_INSTANCE_RESP_MAX_MSG_LEN 7
> +#define SLIMBUS_QMI_CHECK_FRAMER_STAT_RESP_MAX_MSG_LEN 7
> +/* QMI response timeout of 500ms */
> +#define SLIMBUS_QMI_RESP_TOUT 1000
Tabs or spaces, take your pick and use one, not both...
> +static void qcom_slim_qmi_power_resp_cb(struct qmi_handle *handle,
> + struct sockaddr_qrtr *sq,
> + struct qmi_txn *txn, const void *data)
> +{
> + struct slimbus_power_resp_msg_v01 *resp;
> +
> + resp = (struct slimbus_power_resp_msg_v01 *)data;
you dont need cast away from void
> + if (resp->resp.result != QMI_RESULT_SUCCESS_V01)
> + pr_err("%s: QMI power request failed 0x%x\n", __func__,
> + resp->resp.result);
cant we use dev_err?
> +static int qcom_slim_qmi_send_power_request(struct qcom_slim_ngd_ctrl *ctrl,
> + struct slimbus_power_req_msg_v01 *req)
> +{
> + struct slimbus_power_resp_msg_v01 resp = { { 0, 0 } };
> + struct qmi_txn txn;
> + int rc;
> +
> + rc = qmi_txn_init(ctrl->qmi.handle, &txn,
> + slimbus_power_resp_msg_v01_ei, &resp);
> +
> + rc = qmi_send_request(ctrl->qmi.handle, NULL, &txn,
> + SLIMBUS_QMI_POWER_REQ_V01,
> + SLIMBUS_QMI_POWER_REQ_MAX_MSG_LEN,
> + slimbus_power_req_msg_v01_ei, req);
> + if (rc < 0) {
> + dev_err(ctrl->dev, "%s: QMI send req fail %d\n", __func__, rc);
> + qmi_txn_cancel(&txn);
> + }
> +
> + if (rc < 0)
> + return rc;
why not add this is prev error check?
> +static int qcom_slim_qmi_init(struct qcom_slim_ngd_ctrl *ctrl,
> + bool apps_is_master)
> +{
> + int rc = 0;
superfluous init
> +static u32 *qcom_slim_ngd_tx_msg_get(struct qcom_slim_ngd_ctrl *ctrl, int len,
> + struct completion *comp)
> +{
> + struct qcom_slim_ngd_dma_desc *desc;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ctrl->tx_buf_lock, flags);
> +
> + if ((ctrl->tx_tail + 1) % QCOM_SLIM_NGD_DESC_NUM == ctrl->tx_head) {
> + spin_unlock_irqrestore(&ctrl->tx_buf_lock, flags);
> + return NULL;
> + }
> + desc = &ctrl->txdesc[ctrl->tx_tail];
> + desc->base = (u32 *)((u8 *)ctrl->tx_base +
> + (ctrl->tx_tail * SLIM_MSGQ_BUF_LEN));
too many casts
> +static int qcom_slim_ngd_post_rx_msgq(struct qcom_slim_ngd_ctrl *ctrl)
> +{
> + struct qcom_slim_ngd_dma_desc *desc;
> + struct dma_slave_config conf = {
> + .direction = DMA_DEV_TO_MEM,
> + };
> + int ret, i;
> +
> + ret = dmaengine_slave_config(ctrl->dma_rx_channel, &conf);
so you are only setting direction for conf, not any other parameters? If not why
bother setting direction
> + if (ret)
> + dev_err(ctrl->dev, "Error Configuring rx dma\n");
> +
> + for (i = 0; i < QCOM_SLIM_NGD_DESC_NUM; i++) {
> + desc = &ctrl->rx_desc[i];
> + desc->phys = ctrl->rx_phys_base + i * SLIM_MSGQ_BUF_LEN;
> + desc->ctrl = ctrl;
> + desc->base = ctrl->rx_base + i * SLIM_MSGQ_BUF_LEN;
> + desc->desc = dmaengine_prep_slave_single(ctrl->dma_rx_channel,
> + desc->phys, SLIM_MSGQ_BUF_LEN,
> + DMA_DEV_TO_MEM,
> + DMA_PREP_INTERRUPT);
why issue multiple slave_single to dmaengine, you can bundle them and issue
dmaengine_prep_slave_sg()..
> +static int qcom_slim_ngd_qmi_svc_event_init(struct qcom_slim_ngd_qmi *qmi)
> +{
> + int ret = 0;
superfluous init here too
> +static int qcom_slim_ngd_runtime_idle(struct device *dev)
> +{
> + struct qcom_slim_ngd_ctrl *ctrl = dev_get_drvdata(dev);
> +
> + if (ctrl->state == QCOM_SLIM_NGD_CTRL_AWAKE)
> + ctrl->state = QCOM_SLIM_NGD_CTRL_IDLE;
> + pm_request_autosuspend(dev);
> + return -EAGAIN;
> +}
> +
> +
double empty lines, here
--
~Vinod
^ permalink raw reply
* [PATCH v9 15/15] dt: qcom: Add SAW regulator for 8x96 CPUs
From: Ilia Lin @ 2018-05-21 11:25 UTC (permalink / raw)
To: mturquette, sboyd, robh, mark.rutland, viresh.kumar, nm,
lgirdwood, broonie, andy.gross, david.brown, catalin.marinas,
will.deacon, rjw, linux-clk
Cc: devicetree, linux-kernel, linux-pm, linux-arm-msm, linux-soc,
linux-arm-kernel, rnayak, ilialin, amit.kucheria,
nicolas.dechesne, celster, tfinkel
In-Reply-To: <1526901932-9514-1-git-send-email-ilialin@codeaurora.org>
1. Add syscon node for the SAW CPU registers
2. Add SAW regulators gang definition for s8-s11
3. Add voltages to the OPP tables
4. Add the s11 SAW regulator as CPU regulator
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 119 ++++++++++++++++++++++++++++++++++
1 file changed, 119 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index d96a112..871bfac 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/clock/qcom,mmcc-msm8996.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/thermal/thermal.h>
+#include <dt-bindings/spmi/spmi.h>
/ {
model = "Qualcomm Technologies, Inc. MSM8996";
@@ -92,6 +93,7 @@
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>;
@@ -107,6 +109,7 @@
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>;
@@ -118,6 +121,7 @@
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>;
@@ -133,6 +137,7 @@
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>;
@@ -169,171 +174,205 @@
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>;
};
@@ -346,251 +385,301 @@
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>;
};
@@ -908,6 +997,11 @@
#mbox-cells = <1>;
};
+ saw3: syscon@9A10000 {
+ compatible = "syscon";
+ reg = <0x9A10000 0x1000>;
+ };
+
gcc: clock-controller@300000 {
compatible = "qcom,gcc-msm8996";
#clock-cells = <1>;
@@ -1134,6 +1228,31 @@
#size-cells = <0>;
interrupt-controller;
#interrupt-cells = <4>;
+ pmic@1 {
+ compatible = "qcom,pm8994", "qcom,spmi-pmic";
+ reg = <0x1 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ spm-regulators {
+ compatible = "qcom,pm8994-regulators";
+ qcom,saw-reg = <&saw3>;
+ s8 {
+ qcom,saw-slave;
+ };
+ s9 {
+ qcom,saw-slave;
+ };
+ s10 {
+ qcom,saw-slave;
+ };
+ pm8994_s11_saw: s11 {
+ qcom,saw-leader;
+ regulator-always-on;
+ regulator-min-microvolt = <905000>;
+ regulator-max-microvolt = <1140000>;
+ };
+ };
+ };
};
mmcc: clock-controller@8c0000 {
--
1.9.1
^ permalink raw reply related
* [PATCH v9 14/15] dt-bindings: qcom_spmi: Document SAW support
From: Ilia Lin @ 2018-05-21 11:25 UTC (permalink / raw)
To: mturquette, sboyd, robh, mark.rutland, viresh.kumar, nm,
lgirdwood, broonie, andy.gross, david.brown, catalin.marinas,
will.deacon, rjw, linux-clk
Cc: devicetree, linux-kernel, linux-pm, linux-arm-msm, linux-soc,
linux-arm-kernel, rnayak, ilialin, amit.kucheria,
nicolas.dechesne, celster, tfinkel
In-Reply-To: <1526901932-9514-1-git-send-email-ilialin@codeaurora.org>
Document the DT bindings for the SAW regulators.
The saw-leader is the only property that is configurable in DT.
The saw-slave property allows ganging (grouping) of
several regulators so that their outputs can be combined.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/regulator/qcom,spmi-regulator.txt | 45 ++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
index 57d2c65..406f2e5 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
@@ -110,6 +110,11 @@ Qualcomm SPMI Regulators
Definition: Reference to regulator supplying the input pin, as
described in the data sheet.
+- qcom,saw-reg:
+ Usage: optional
+ Value type: <phandle>
+ Description: Reference to syscon node defining the SAW registers.
+
The regulator node houses sub-nodes for each regulator within the device. Each
sub-node is identified using the node's name, with valid values listed for each
@@ -201,6 +206,17 @@ see regulator.txt - with additional custom properties described below:
2 = 0.55 uA
3 = 0.75 uA
+- qcom,saw-slave:
+ Usage: optional
+ Value type: <boo>
+ Description: SAW controlled gang slave. Will not be configured.
+
+- qcom,saw-leader:
+ Usage: optional
+ Value type: <boo>
+ Description: SAW controlled gang leader. Will be configured as
+ SAW regulator.
+
Example:
regulators {
@@ -221,3 +237,32 @@ Example:
....
};
+
+Example 2:
+
+ saw3: syscon@9A10000 {
+ compatible = "syscon";
+ reg = <0x9A10000 0x1000>;
+ };
+
+ ...
+
+ spm-regulators {
+ compatible = "qcom,pm8994-regulators";
+ qcom,saw-reg = <&saw3>;
+ s8 {
+ qcom,saw-slave;
+ };
+ s9 {
+ qcom,saw-slave;
+ };
+ s10 {
+ qcom,saw-slave;
+ };
+ pm8994_s11_saw: s11 {
+ qcom,saw-leader;
+ regulator-always-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1140000>;
+ };
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v9 13/15] regulator: qcom_spmi: Add support for SAW
From: Ilia Lin @ 2018-05-21 11:25 UTC (permalink / raw)
To: mturquette, sboyd, robh, mark.rutland, viresh.kumar, nm,
lgirdwood, broonie, andy.gross, david.brown, catalin.marinas,
will.deacon, rjw, linux-clk
Cc: devicetree, linux-kernel, linux-pm, linux-arm-msm, linux-soc,
linux-arm-kernel, rnayak, ilialin, amit.kucheria,
nicolas.dechesne, celster, tfinkel
In-Reply-To: <1526901932-9514-1-git-send-email-ilialin@codeaurora.org>
Add support for SAW controlled regulators.
The regulators defined as SAW controlled in the device tree
will be controlled through special CPU registers instead of direct
SPMI accesses.
This is required especially for CPU supply regulators to synchronize
with clock scaling and for Automatic Voltage Switching.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
---
drivers/regulator/qcom_spmi-regulator.c | 133 +++++++++++++++++++++++++++++++-
1 file changed, 130 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/qcom_spmi-regulator.c b/drivers/regulator/qcom_spmi-regulator.c
index 63c7a0c..9817f1a 100644
--- a/drivers/regulator/qcom_spmi-regulator.c
+++ b/drivers/regulator/qcom_spmi-regulator.c
@@ -25,6 +25,8 @@
#include <linux/regulator/driver.h>
#include <linux/regmap.h>
#include <linux/list.h>
+#include <linux/mfd/syscon.h>
+#include <linux/io.h>
/* Pin control enable input pins. */
#define SPMI_REGULATOR_PIN_CTRL_ENABLE_NONE 0x00
@@ -181,6 +183,23 @@ enum spmi_boost_byp_registers {
SPMI_BOOST_BYP_REG_CURRENT_LIMIT = 0x4b,
};
+enum spmi_saw3_registers {
+ SAW3_SECURE = 0x00,
+ SAW3_ID = 0x04,
+ SAW3_SPM_STS = 0x0C,
+ SAW3_AVS_STS = 0x10,
+ SAW3_PMIC_STS = 0x14,
+ SAW3_RST = 0x18,
+ SAW3_VCTL = 0x1C,
+ SAW3_AVS_CTL = 0x20,
+ SAW3_AVS_LIMIT = 0x24,
+ SAW3_AVS_DLY = 0x28,
+ SAW3_AVS_HYSTERESIS = 0x2C,
+ SAW3_SPM_STS2 = 0x38,
+ SAW3_SPM_PMIC_DATA_3 = 0x4C,
+ SAW3_VERSION = 0xFD0,
+};
+
/* Used for indexing into ctrl_reg. These are offets from 0x40 */
enum spmi_common_control_register_index {
SPMI_COMMON_IDX_VOLTAGE_RANGE = 0,
@@ -1035,6 +1054,89 @@ static irqreturn_t spmi_regulator_vs_ocp_isr(int irq, void *data)
return IRQ_HANDLED;
}
+#define SAW3_VCTL_DATA_MASK 0xFF
+#define SAW3_VCTL_CLEAR_MASK 0x700FF
+#define SAW3_AVS_CTL_EN_MASK 0x1
+#define SAW3_AVS_CTL_TGGL_MASK 0x8000000
+#define SAW3_AVS_CTL_CLEAR_MASK 0x7efc00
+
+static struct regmap *saw_regmap = NULL;
+
+static void spmi_saw_set_vdd(void *data)
+{
+ u32 vctl, data3, avs_ctl, pmic_sts;
+ bool avs_enabled = false;
+ unsigned long timeout;
+ u8 voltage_sel = *(u8 *)data;
+
+ regmap_read(saw_regmap, SAW3_AVS_CTL, &avs_ctl);
+ regmap_read(saw_regmap, SAW3_VCTL, &vctl);
+ regmap_read(saw_regmap, SAW3_SPM_PMIC_DATA_3, &data3);
+
+ /* select the band */
+ vctl &= ~SAW3_VCTL_CLEAR_MASK;
+ vctl |= (u32)voltage_sel;
+
+ data3 &= ~SAW3_VCTL_CLEAR_MASK;
+ data3 |= (u32)voltage_sel;
+
+ /* If AVS is enabled, switch it off during the voltage change */
+ avs_enabled = SAW3_AVS_CTL_EN_MASK & avs_ctl;
+ if (avs_enabled) {
+ avs_ctl &= ~SAW3_AVS_CTL_TGGL_MASK;
+ regmap_write(saw_regmap, SAW3_AVS_CTL, avs_ctl);
+ }
+
+ regmap_write(saw_regmap, SAW3_RST, 1);
+ regmap_write(saw_regmap, SAW3_VCTL, vctl);
+ regmap_write(saw_regmap, SAW3_SPM_PMIC_DATA_3, data3);
+
+ timeout = jiffies + usecs_to_jiffies(100);
+ do {
+ regmap_read(saw_regmap, SAW3_PMIC_STS, &pmic_sts);
+ pmic_sts &= SAW3_VCTL_DATA_MASK;
+ if (pmic_sts == (u32)voltage_sel)
+ break;
+
+ cpu_relax();
+
+ } while (time_before(jiffies, timeout));
+
+ /* After successful voltage change, switch the AVS back on */
+ if (avs_enabled) {
+ pmic_sts &= 0x3f;
+ avs_ctl &= ~SAW3_AVS_CTL_CLEAR_MASK;
+ avs_ctl |= ((pmic_sts - 4) << 10);
+ avs_ctl |= (pmic_sts << 17);
+ avs_ctl |= SAW3_AVS_CTL_TGGL_MASK;
+ regmap_write(saw_regmap, SAW3_AVS_CTL, avs_ctl);
+ }
+}
+
+static int
+spmi_regulator_saw_set_voltage(struct regulator_dev *rdev, unsigned selector)
+{
+ struct spmi_regulator *vreg = rdev_get_drvdata(rdev);
+ int ret;
+ u8 range_sel, voltage_sel;
+
+ ret = spmi_sw_selector_to_hw(vreg, selector, &range_sel, &voltage_sel);
+ if (ret)
+ return ret;
+
+ if (0 != range_sel) {
+ dev_dbg(&rdev->dev, "range_sel = %02X voltage_sel = %02X", \
+ range_sel, voltage_sel);
+ return -EINVAL;
+ }
+
+ /* Always do the SAW register writes on the first CPU */
+ return smp_call_function_single(0, spmi_saw_set_vdd, \
+ &voltage_sel, true);
+}
+
+static struct regulator_ops spmi_saw_ops = {};
+
static struct regulator_ops spmi_smps_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
@@ -1250,6 +1352,7 @@ static int spmi_regulator_match(struct spmi_regulator *vreg, u16 force_type)
}
dig_major_rev = version[SPMI_COMMON_REG_DIG_MAJOR_REV
- SPMI_COMMON_REG_DIG_MAJOR_REV];
+
if (!force_type) {
type = version[SPMI_COMMON_REG_TYPE -
SPMI_COMMON_REG_DIG_MAJOR_REV];
@@ -1648,7 +1751,9 @@ static int qcom_spmi_regulator_probe(struct platform_device *pdev)
struct regmap *regmap;
const char *name;
struct device *dev = &pdev->dev;
- int ret;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *syscon;
+ int ret, lenp;
struct list_head *vreg_list;
vreg_list = devm_kzalloc(dev, sizeof(*vreg_list), GFP_KERNEL);
@@ -1665,7 +1770,22 @@ static int qcom_spmi_regulator_probe(struct platform_device *pdev)
if (!match)
return -ENODEV;
+ if (of_find_property(node, "qcom,saw-reg", &lenp)) {
+ syscon = of_parse_phandle(node, "qcom,saw-reg", 0);
+ saw_regmap = syscon_node_to_regmap(syscon);
+ of_node_put(syscon);
+ if (IS_ERR(regmap))
+ dev_err(dev, "ERROR reading SAW regmap\n");
+ }
+
for (reg = match->data; reg->name; reg++) {
+
+ if (saw_regmap && \
+ of_find_property(of_find_node_by_name(node, reg->name), \
+ "qcom,saw-slave", &lenp)) {
+ continue;
+ }
+
vreg = devm_kzalloc(dev, sizeof(*vreg), GFP_KERNEL);
if (!vreg)
return -ENOMEM;
@@ -1673,7 +1793,6 @@ static int qcom_spmi_regulator_probe(struct platform_device *pdev)
vreg->dev = dev;
vreg->base = reg->base;
vreg->regmap = regmap;
-
if (reg->ocp) {
vreg->ocp_irq = platform_get_irq_byname(pdev, reg->ocp);
if (vreg->ocp_irq < 0) {
@@ -1681,7 +1800,6 @@ static int qcom_spmi_regulator_probe(struct platform_device *pdev)
goto err;
}
}
-
vreg->desc.id = -1;
vreg->desc.owner = THIS_MODULE;
vreg->desc.type = REGULATOR_VOLTAGE;
@@ -1698,6 +1816,15 @@ static int qcom_spmi_regulator_probe(struct platform_device *pdev)
if (ret)
continue;
+ if (saw_regmap && \
+ of_find_property(of_find_node_by_name(node, reg->name), \
+ "qcom,saw-leader", &lenp)) {
+ spmi_saw_ops = *(vreg->desc.ops);
+ spmi_saw_ops.set_voltage_sel = \
+ spmi_regulator_saw_set_voltage;
+ vreg->desc.ops = &spmi_saw_ops;
+ }
+
config.dev = dev;
config.driver_data = vreg;
config.regmap = regmap;
--
1.9.1
^ permalink raw reply related
* [PATCH v9 12/15] dt: qcom: Add qcom-cpufreq-kryo driver configuration
From: Ilia Lin @ 2018-05-21 11:25 UTC (permalink / raw)
To: mturquette, sboyd, robh, mark.rutland, viresh.kumar, nm,
lgirdwood, broonie, andy.gross, david.brown, catalin.marinas,
will.deacon, rjw, linux-clk
Cc: devicetree, linux-kernel, linux-pm, linux-arm-msm, linux-soc,
linux-arm-kernel, rnayak, ilialin, amit.kucheria,
nicolas.dechesne, celster, tfinkel
In-Reply-To: <1526901932-9514-1-git-send-email-ilialin@codeaurora.org>
1. Add NVMEM node for the speedbin
2. Add definitions for all possible MSM8996 CPU OPPs.
The qcom-cpufreq-kryo driver will select the appropriate subset.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dts | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 281 ++++++++++++++++++++++++++--
2 files changed, 270 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dts b/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
index 230e9c8..da23bda 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
@@ -17,5 +17,5 @@
/ {
model = "Qualcomm Technologies, Inc. DB820c";
- compatible = "arrow,apq8096-db820c", "qcom,apq8096-sbc";
+ compatible = "arrow,apq8096-db820c", "qcom,apq8096-sbc", "qcom,apq8096";
};
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index e6cf290..d96a112 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -1,13 +1,6 @@
-/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2014-2015, 2018 The Linux Foundation. All rights reserved.
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -169,177 +162,436 @@
};
cluster0_opp: opp_table0 {
- compatible = "operating-points-v2";
+ compatible = "operating-points-v2-kryo-cpu",
+ "operating-points-v2";
+ nvmem-cells = <&speedbin_efuse>;
opp-shared;
opp-307200000 {
opp-hz = /bits/ 64 <307200000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-422400000 {
opp-hz = /bits/ 64 <422400000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-480000000 {
opp-hz = /bits/ 64 <480000000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-556800000 {
opp-hz = /bits/ 64 <556800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-652800000 {
opp-hz = /bits/ 64 <652800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-729600000 {
opp-hz = /bits/ 64 <729600000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-768000000 {
+ opp-hz = /bits/ 64 <768000000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-844800000 {
opp-hz = /bits/ 64 <844800000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-960000000 {
opp-hz = /bits/ 64 <960000000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1036800000 {
opp-hz = /bits/ 64 <1036800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1113600000 {
opp-hz = /bits/ 64 <1113600000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1190400000 {
opp-hz = /bits/ 64 <1190400000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1228800000 {
opp-hz = /bits/ 64 <1228800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1324800000 {
opp-hz = /bits/ 64 <1324800000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-supported-hw = <0x72>;
clock-latency-ns = <200000>;
};
opp-1401600000 {
opp-hz = /bits/ 64 <1401600000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1478400000 {
opp-hz = /bits/ 64 <1478400000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1497600000 {
+ opp-hz = /bits/ 64 <1497600000>;
+ opp-supported-hw = <0x4>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1593600000 {
opp-hz = /bits/ 64 <1593600000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-supported-hw = <0x20>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2188800000 {
+ opp-hz = /bits/ 64 <2188800000>;
+ opp-supported-hw = <0x10>;
clock-latency-ns = <200000>;
};
};
cluster1_opp: opp_table1 {
- compatible = "operating-points-v2";
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
opp-shared;
opp-307200000 {
opp-hz = /bits/ 64 <307200000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-403200000 {
opp-hz = /bits/ 64 <403200000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-480000000 {
opp-hz = /bits/ 64 <480000000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-556800000 {
opp-hz = /bits/ 64 <556800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-652800000 {
opp-hz = /bits/ 64 <652800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-729600000 {
opp-hz = /bits/ 64 <729600000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-748800000 {
+ opp-hz = /bits/ 64 <748800000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-806400000 {
opp-hz = /bits/ 64 <806400000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-825600000 {
+ opp-hz = /bits/ 64 <825600000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-883200000 {
opp-hz = /bits/ 64 <883200000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-940800000 {
opp-hz = /bits/ 64 <940800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1036800000 {
opp-hz = /bits/ 64 <1036800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1113600000 {
opp-hz = /bits/ 64 <1113600000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1190400000 {
opp-hz = /bits/ 64 <1190400000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1248000000 {
opp-hz = /bits/ 64 <1248000000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1324800000 {
opp-hz = /bits/ 64 <1324800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1401600000 {
opp-hz = /bits/ 64 <1401600000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1478400000 {
opp-hz = /bits/ 64 <1478400000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1555200000 {
opp-hz = /bits/ 64 <1555200000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1632000000 {
opp-hz = /bits/ 64 <1632000000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1670400000 {
+ opp-hz = /bits/ 64 <1670400000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1708800000 {
opp-hz = /bits/ 64 <1708800000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1747200000 {
+ opp-hz = /bits/ 64 <1747200000>;
+ opp-supported-hw = <0x70>;
clock-latency-ns = <200000>;
};
opp-1785600000 {
opp-hz = /bits/ 64 <1785600000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1804800000 {
+ opp-hz = /bits/ 64 <1804800000>;
+ opp-supported-hw = <0x6>;
clock-latency-ns = <200000>;
};
opp-1824000000 {
opp-hz = /bits/ 64 <1824000000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1900800000 {
+ opp-hz = /bits/ 64 <1900800000>;
+ opp-supported-hw = <0x74>;
clock-latency-ns = <200000>;
};
opp-1920000000 {
opp-hz = /bits/ 64 <1920000000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1977600000 {
+ opp-hz = /bits/ 64 <1977600000>;
+ opp-supported-hw = <0x30>;
clock-latency-ns = <200000>;
};
opp-1996800000 {
opp-hz = /bits/ 64 <1996800000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2054400000 {
+ opp-hz = /bits/ 64 <2054400000>;
+ opp-supported-hw = <0x30>;
clock-latency-ns = <200000>;
};
opp-2073600000 {
opp-hz = /bits/ 64 <2073600000>;
+ opp-supported-hw = <0x1>;
clock-latency-ns = <200000>;
};
opp-2150400000 {
opp-hz = /bits/ 64 <2150400000>;
+ opp-supported-hw = <0x31>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2246400000 {
+ opp-hz = /bits/ 64 <2246400000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2342400000 {
+ opp-hz = /bits/ 64 <2342400000>;
+ opp-supported-hw = <0x10>;
clock-latency-ns = <200000>;
};
};
@@ -917,6 +1169,11 @@
reg = <0x24f 0x1>;
bits = <1 4>;
};
+
+ speedbin_efuse: speedbin@133 {
+ reg = <0x133 0x1>;
+ bits = <5 3>;
+ };
};
phy@34000 {
--
1.9.1
^ permalink raw reply related
* [PATCH v9 11/15] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
From: Ilia Lin @ 2018-05-21 11:25 UTC (permalink / raw)
To: mturquette, sboyd, robh, mark.rutland, viresh.kumar, nm,
lgirdwood, broonie, andy.gross, david.brown, catalin.marinas,
will.deacon, rjw, linux-clk
Cc: devicetree, linux-kernel, linux-pm, linux-arm-msm, linux-soc,
linux-arm-kernel, rnayak, ilialin, amit.kucheria,
nicolas.dechesne, celster, tfinkel
In-Reply-To: <1526901932-9514-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>
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