* Re: [PATCH v2 1/3] power: supply: bq24735-charger: simplify register update to stop charging
From: Sebastian Reichel @ 2016-12-14 16:41 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-kernel, Rob Herring, Mark Rutland, linux-pm, devicetree
In-Reply-To: <1481673405-4547-2-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]
Hi,
On Wed, Dec 14, 2016 at 12:56:43AM +0100, Peter Rosin wrote:
> Providing value bits outside of the mask is pointless.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/power/supply/bq24735-charger.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
> index eb7783b42e0a..1d5c9206e0ed 100644
> --- a/drivers/power/supply/bq24735-charger.c
> +++ b/drivers/power/supply/bq24735-charger.c
> @@ -111,8 +111,7 @@ static inline int bq24735_enable_charging(struct bq24735 *charger)
> return 0;
>
> return bq24735_update_word(charger->client, BQ24735_CHG_OPT,
> - BQ24735_CHG_OPT_CHARGE_DISABLE,
> - ~BQ24735_CHG_OPT_CHARGE_DISABLE);
> + BQ24735_CHG_OPT_CHARGE_DISABLE, 0);
> }
>
> static inline int bq24735_disable_charging(struct bq24735 *charger)
Thanks for your patch. We are currently in the merge
window and your patch will appear in linux-next once
4.10-rc1 has been tagged by Linus Torvalds.
Until then I queued it into this branch:
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/log/?h=for-next-next
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] MIPS: NI 169445 board support
From: Nathan Sullivan @ 2016-12-14 16:32 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, mark.rutland-5wv7dgnIgG8,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209211828.dykl2l4kmthqgq6e@rob-hp-laptop>
On Fri, Dec 09, 2016 at 03:18:28PM -0600, Rob Herring wrote:
> On Fri, Dec 02, 2016 at 09:42:09AM -0600, Nathan Sullivan wrote:
> > Support the National Instruments 169445 board.
> >
> > Signed-off-by: Nathan Sullivan <nathan.sullivan-acOepvfBmUk@public.gmane.org>
> > ---
> > "gpio: mmio: add support for NI 169445 NAND GPIO" and
> > "devicetree: add vendor prefix for National Instruments" are required for the
> > NAND on this board to work.
>
> These should have been a series, but I already applied the first one.
>
> >
> > Documentation/devicetree/bindings/mips/ni.txt | 7 ++
> > arch/mips/Kbuild.platforms | 1 +
> > arch/mips/Kconfig | 26 ++++++
> > arch/mips/boot/dts/Makefile | 1 +
> > arch/mips/boot/dts/ni/169445.dts | 99 +++++++++++++++++++++
> > arch/mips/boot/dts/ni/Makefile | 9 ++
> > arch/mips/configs/ni169445_defconfig | 120 ++++++++++++++++++++++++++
> > arch/mips/ni169445/169445-console.c | 38 ++++++++
> > arch/mips/ni169445/169445-init.c | 39 +++++++++
> > arch/mips/ni169445/169445-int.c | 34 ++++++++
> > arch/mips/ni169445/169445-setup.c | 58 +++++++++++++
> > arch/mips/ni169445/169445-time.c | 35 ++++++++
> > arch/mips/ni169445/Makefile | 9 ++
> > arch/mips/ni169445/Platform | 6 ++
> > 14 files changed, 482 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mips/ni.txt
> > create mode 100644 arch/mips/boot/dts/ni/169445.dts
> > create mode 100644 arch/mips/boot/dts/ni/Makefile
> > create mode 100644 arch/mips/configs/ni169445_defconfig
> > create mode 100644 arch/mips/ni169445/169445-console.c
> > create mode 100644 arch/mips/ni169445/169445-init.c
> > create mode 100644 arch/mips/ni169445/169445-int.c
> > create mode 100644 arch/mips/ni169445/169445-setup.c
> > create mode 100644 arch/mips/ni169445/169445-time.c
> > create mode 100644 arch/mips/ni169445/Makefile
> > create mode 100644 arch/mips/ni169445/Platform
> >
> > diff --git a/Documentation/devicetree/bindings/mips/ni.txt b/Documentation/devicetree/bindings/mips/ni.txt
> > new file mode 100644
> > index 0000000..722bf2d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mips/ni.txt
> > @@ -0,0 +1,7 @@
> > +National Instruments MIPS platforms
> > +
> > +required root node properties:
> > + - compatible: must be "ni,169445"
> > +
> > +CPU Nodes
> > + - compatible: must be "mti,mips14KEc"
> > diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
> > index f5f1bdb..f2d7b5c 100644
> > --- a/arch/mips/Kbuild.platforms
> > +++ b/arch/mips/Kbuild.platforms
> > @@ -20,6 +20,7 @@ platforms += loongson32
> > platforms += loongson64
> > platforms += mti-malta
> > platforms += netlogic
> > +platforms += ni169445
> > platforms += paravirt
> > platforms += pic32
> > platforms += pistachio
> > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> > index b3c5bde..d24d11f 100644
> > --- a/arch/mips/Kconfig
> > +++ b/arch/mips/Kconfig
> > @@ -574,6 +574,32 @@ config NXP_STB225
> > help
> > Support for NXP Semiconductors STB225 Development Board.
> >
> > +config NI_169445
> > + bool "NI 169445 board"
> > + select ARCH_WANT_OPTIONAL_GPIOLIB
> > + select BOOT_ELF32
> > + select BOOT_RAW
> > + select BUILTIN_DTB
> > + select CEVT_R4K
> > + select CSRC_R4K
> > + select CPU_MIPSR2_IRQ_VI
> > + select CPU_MIPSR2_IRQ_EI
> > + select DMA_NONCOHERENT
> > + select IRQ_MIPS_CPU
> > + select LIBFDT
> > + select MIPS_MSC
> > + select SYS_HAS_CPU_MIPS32_R1
> > + select SYS_HAS_CPU_MIPS32_R2
> > + select SYS_HAS_EARLY_PRINTK
> > + select SYS_SUPPORTS_32BIT_KERNEL
> > + select SYS_SUPPORTS_LITTLE_ENDIAN
> > + select USE_OF
> > + select COMMON_CLK
> > + help
> > + This enables support for the National Instruments 169445A
> > + board.
> > +
> > +
> > config PMC_MSP
> > bool "PMC-Sierra MSP chipsets"
> > select CEVT_R4K
> > diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
> > index fc7a0a9..65a0ad8 100644
> > --- a/arch/mips/boot/dts/Makefile
> > +++ b/arch/mips/boot/dts/Makefile
> > @@ -3,6 +3,7 @@ dts-dirs += cavium-octeon
> > dts-dirs += ingenic
> > dts-dirs += lantiq
> > dts-dirs += mti
> > +dts-dirs += ni
> > dts-dirs += netlogic
> > dts-dirs += pic32
> > dts-dirs += qca
> > diff --git a/arch/mips/boot/dts/ni/169445.dts b/arch/mips/boot/dts/ni/169445.dts
> > new file mode 100644
> > index 0000000..a2b49f9
> > --- /dev/null
> > +++ b/arch/mips/boot/dts/ni/169445.dts
> > @@ -0,0 +1,99 @@
> > +/dts-v1/;
> > +
> > +/ {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "ni,169445";
> > +
> > + cpus {
> > + mips-hpt-frequency = <25000000>;
> > +
> > + cpu@0 {
> > + compatible = "mti,mips14KEc";
> > + };
> > + };
> > +
> > + memory {
>
> memory@0
>
> > + device_type = "memory";
> > + reg = <0x0 0x08000000>;
> > + };
> > +
> > + clocks {
> > + baseclk: baseclock {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <50000000>;
> > + };
> > + };
> > +
> > + cpu_intc: cpu_intc {
> > + #address-cells = <0>;
> > + compatible = "mti,cpu-interrupt-controller";
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + };
> > +
> > + ahb@0 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
>
> If everything is under 0x1f3xxxxx, then add in the ranges here (and the
> unit address).
>
I noticed that some systems call out their axi/ahb busses, some do not. Would
you prefer that I remove the bus entirely?
> > +
> > + gpio1: nand-gpio-out@1f300010 {
>
> As in the binding example: gpio-controller@...
>
> > + compatible = "ni,169445-nand-gpio";
> > + reg = <0x1f300010 0x4>;
> > + reg-names = "dat";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + ngpios = <5>;
> > + };
> > +
> > + gpio2: nand-gpio-in@1f300014 {
>
> ditto
>
> > + compatible = "ni,169445-nand-gpio";
> > + reg = <0x1f300014 0x4>;
> > + reg-names = "dat";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + ngpios = <1>;
> > + };
> > +
> > + nand@1f300000 {
> > + compatible = "gpio-control-nand";
> > + nand-on-flash-bbt;
> > + nand-ecc-mode = "soft_bch";
> > + nand-ecc-step-size = <512>;
> > + nand-ecc-strength = <4>;
> > + reg = <0x1f300000 4>;
> > + gpios = <&gpio2 0 0>, /* rdy */
> > + <&gpio1 1 0>, /* nce */
> > + <&gpio1 2 0>, /* ale */
> > + <&gpio1 3 0>, /* cle */
> > + <&gpio1 4 0>; /* nwp */
> > + };
> > +
> > + serial@1f380000 {
> > + compatible = "ns16550a";
> > + reg = <0x1f380000 0x1000>;
> > + interrupt-parent = <&cpu_intc>;
> > + interrupts = <6>;
> > + clocks = <&baseclk>;
> > + reg-shift = <0>;
> > + };
> > +
> > + ethernet@1f340000 {
> > + compatible = "snps,dwc-qos-ethernet-4.10";
> > + interrupt-parent = <&cpu_intc>;
> > + interrupts = <5>;
> > + reg = <0x1f340000 0x2000>;
> > + clock-names = "apb_pclk", "phy_ref_clk";
> > + clocks = <&baseclk>, <&baseclk>;
> > +
> > + phy-mode = "rgmii";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > + };
> > + };
> > +};
>
> [...]
>
> > diff --git a/arch/mips/ni169445/169445-setup.c b/arch/mips/ni169445/169445-setup.c
> > new file mode 100644
> > index 0000000..80a5c91
> > --- /dev/null
> > +++ b/arch/mips/ni169445/169445-setup.c
> > @@ -0,0 +1,58 @@
> > +/* Copyright 2016 National Instruments Corporation
> > + *
> > + * 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.
> > + *
> > + * 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.
> > + */
> > +#include <linux/init.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/libfdt.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/of_fdt.h>
> > +
> > +#include <asm/prom.h>
> > +#include <asm/fw/fw.h>
> > +
> > +#include <asm/mips-boards/generic.h>
> > +
> > +const char *get_system_type(void)
> > +{
> > + return "NI 169445 FPGA";
>
> Perhaps this should come from model property. There's a patch in flight
> to add a function to get machine name.
>
> > +}
> > +
> > +void __init plat_mem_setup(void)
> > +{
> > + /*
> > + * Load the builtin devicetree. This causes the chosen node to be
> > + * parsed resulting in our memory appearing
> > + */
> > + __dt_setup_arch(__dtb_start);
> > +}
> > +
> > +void __init device_tree_init(void)
> > +{
> > + if (!initial_boot_params)
> > + return;
> > +
> > + unflatten_and_copy_device_tree();
> > +}
> > +
> > +static int __init customize_machine(void)
> > +{
> > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>
> This should happen by default now.
>
> > + return 0;
> > +}
> > +arch_initcall(customize_machine);
Thank you for the feedback.
Nathan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: clk: clk-mstp has never worked for RZ/A1
From: Chris Brandt @ 2016-12-14 16:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-renesas-soc@vger.kernel.org, geert+renesas@glider.be,
devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdUJFSbX96pqY2Ogxztxz-SWCNfbe=d3eWKn+eWSdHLwfw@mail.gmail.com>
Hi Geert,
On Dec 14, 2016, Geert Uytterhoeven wrote:
> Another option is to let the driver bind against "renesas,r7s72100-mstp-
> clocks", and switch to 8-bit access mode.
>
> CLK_OF_DECLARE(cpg_mstp_clks, "renesas,r7s72100-mstp-clocks",
> cpg_mstp_clocks_init8);
>
> cpg_mstp_clocks_init8() can set a gloal flag, and call
> cpg_mstp_clocks_init().
>
> The latter means no DT update is needed, and thus preserves compatibility
> with old DTBs.
I just coded that and it works good. Thank you.
Now, one more question before I submit a patch for review:
I would like to add a "Fixes:" to the commit log so it can be considered for 4.9-stable (in reality it could go all the way back to when r7s72100 support was added)
But, the current file path didn't exist until after commit b3a33077c0dd ("clk: renesas: move drivers to renesas directory") on 2016-03-02.
So should I use that commit for my 'Fixes'?
Thanks,
Chris
^ permalink raw reply
* [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Andreas Klinger @ 2016-12-14 16:17 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, ak-n176/SwNRljddJNmlsFzeA
This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
cells.
The protocol is quite simple and using GPIOs:
One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
The raw value read from the chip is delivered.
To get a weight one needs to subtract the zero offset and scale it.
Signed-off-by: Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
---
drivers/iio/adc/Kconfig | 18 +++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/hx711.c | 292 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 311 insertions(+)
create mode 100644 drivers/iio/adc/hx711.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 932de1f9d1e7..918f582288c9 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -205,6 +205,24 @@ config HI8435
This driver can also be built as a module. If so, the module will be
called hi8435.
+config HX711
+ tristate "AVIA HX711 ADC for weight cells"
+ depends on GPIOLIB
+ help
+ If you say yes here you get support for AVIA HX711 ADC which is used
+ for weight cells
+
+ This driver uses two GPIOs, one for setting the clock and the other
+ one for getting the data
+
+ Currently the raw value is read from the chip and delivered.
+ For getting an actual weight one needs to subtract the
+ zero offset and multiply by a scale factor.
+ This should be done in userspace.
+
+ This driver can also be built as a module. If so, the module will be
+ called hx711.
+
config INA2XX_ADC
tristate "Texas Instruments INA2xx Power Monitors IIO driver"
depends on I2C && !SENSORS_INA2XX
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index b1aa456e6af3..d46e289900ef 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
obj-$(CONFIG_HI8435) += hi8435.o
+obj-$(CONFIG_HX711) += hx711.o
obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
new file mode 100644
index 000000000000..700281932ff0
--- /dev/null
+++ b/drivers/iio/adc/hx711.c
@@ -0,0 +1,292 @@
+/*
+ * HX711: analog to digital converter for weight sensor module
+ *
+ * Copyright (c) 2016 Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
+ *
+ * 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.
+ *
+ * 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.
+ *
+ */
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/slab.h>
+#include <linux/sched.h>
+#include <linux/delay.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define HX711_GAIN_32 2 /* gain = 32 for channel B */
+#define HX711_GAIN_64 3 /* gain = 64 for channel A */
+#define HX711_GAIN_128 1 /* gain = 128 for channel A */
+
+struct hx711_data {
+ struct device *dev;
+ struct gpio_desc *gpiod_sck;
+ struct gpio_desc *gpiod_dout;
+ int gain_pulse;
+ struct mutex lock;
+};
+
+static int hx711_reset(struct hx711_data *hx711_data)
+{
+ int i, val;
+
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ if (val) {
+ gpiod_set_value(hx711_data->gpiod_sck, 1);
+ udelay(80);
+ gpiod_set_value(hx711_data->gpiod_sck, 0);
+
+ for (i = 0; i < 1000; i++) {
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ if (!val)
+ break;
+ /* sleep at least 1 ms */
+ msleep(1);
+ }
+ }
+
+ return val;
+}
+
+static int hx711_cycle(struct hx711_data *hx711_data)
+{
+ int val;
+
+ /* if preempted for more then 60us while SCK is high:
+ * hx711 is going in reset
+ * ==> measuring is false
+ */
+ preempt_disable();
+ gpiod_set_value(hx711_data->gpiod_sck, 1);
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ gpiod_set_value(hx711_data->gpiod_sck, 0);
+ preempt_enable();
+
+ return val;
+}
+
+static int hx711_read(struct hx711_data *hx711_data)
+{
+ int i, ret;
+ int value = 0;
+
+ mutex_lock(&hx711_data->lock);
+
+ if (hx711_reset(hx711_data)) {
+ dev_err(hx711_data->dev, "reset failed!");
+ mutex_unlock(&hx711_data->lock);
+ return -1;
+ }
+
+ for (i = 0; i < 24; i++) {
+ value <<= 1;
+ ret = hx711_cycle(hx711_data);
+ if (ret)
+ value++;
+ }
+
+ value ^= 0x800000;
+
+ for (i = 0; i < hx711_data->gain_pulse; i++)
+ ret = hx711_cycle(hx711_data);
+
+ mutex_unlock(&hx711_data->lock);
+
+ return value;
+}
+
+static int hx711_read_raw(struct iio_dev *iio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct hx711_data *hx711_data = iio_priv(iio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ switch (chan->type) {
+ case IIO_VOLTAGE:
+ *val = hx711_read(hx711_data);
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static ssize_t hx711_gain_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
+ int val;
+
+ switch (hx711_data->gain_pulse) {
+ case HX711_GAIN_32:
+ val = 32;
+ break;
+ case HX711_GAIN_64:
+ val = 64;
+ break;
+ default:
+ val = 128;
+ }
+
+ return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t hx711_gain_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
+ int ret, val;
+ int gain_save = hx711_data->gain_pulse;
+
+ ret = kstrtoint((const char *) buf, 10, &val);
+ if (ret)
+ return -EINVAL;
+
+ switch (val) {
+ case 32:
+ hx711_data->gain_pulse = HX711_GAIN_32;
+ break;
+ case 64:
+ hx711_data->gain_pulse = HX711_GAIN_64;
+ break;
+ case 128:
+ hx711_data->gain_pulse = HX711_GAIN_128;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ dev_dbg(hx711_data->dev, "gain_pulse: %d\n", hx711_data->gain_pulse);
+
+ /* if gain has changed do a fake read for the new gain to be set
+ * for the next read
+ */
+ if (gain_save != hx711_data->gain_pulse)
+ hx711_read(hx711_data);
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(gain, S_IRUGO | S_IWUSR,
+ hx711_gain_show, hx711_gain_store, 0);
+
+static struct attribute *hx711_attributes[] = {
+ &iio_dev_attr_gain.dev_attr.attr,
+ NULL,
+};
+
+static struct attribute_group hx711_attribute_group = {
+ .attrs = hx711_attributes,
+};
+
+static const struct iio_info hx711_iio_info = {
+ .driver_module = THIS_MODULE,
+ .read_raw = hx711_read_raw,
+ .attrs = &hx711_attribute_group,
+};
+
+static const struct iio_chan_spec hx711_chan_spec[] = {
+ { .type = IIO_VOLTAGE,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW),
+ },
+};
+
+static int hx711_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct hx711_data *hx711_data = NULL;
+ struct iio_dev *iio;
+ int ret = 0;
+
+ iio = devm_iio_device_alloc(dev, sizeof(struct hx711_data));
+ if (!iio) {
+ dev_err(dev, "failed to allocate IIO device\n");
+ return -ENOMEM;
+ }
+
+ hx711_data = iio_priv(iio);
+ hx711_data->dev = dev;
+
+ mutex_init(&hx711_data->lock);
+
+ hx711_data->gpiod_sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_HIGH);
+ if (IS_ERR(hx711_data->gpiod_sck)) {
+ dev_err(dev, "failed to get sck-gpiod: err=%ld\n",
+ PTR_ERR(hx711_data->gpiod_sck));
+ return PTR_ERR(hx711_data->gpiod_sck);
+ }
+
+ hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
+ if (IS_ERR(hx711_data->gpiod_dout)) {
+ dev_err(dev, "failed to get dout-gpiod: err=%ld\n",
+ PTR_ERR(hx711_data->gpiod_dout));
+ return PTR_ERR(hx711_data->gpiod_dout);
+ }
+
+ ret = gpiod_direction_input(hx711_data->gpiod_dout);
+ if (ret < 0) {
+ dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
+ return ret;
+ }
+
+ ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);
+ if (ret < 0) {
+ dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, iio);
+
+ iio->name = pdev->name;
+ iio->dev.parent = &pdev->dev;
+ iio->info = &hx711_iio_info;
+ iio->modes = INDIO_DIRECT_MODE;
+ iio->channels = hx711_chan_spec;
+ iio->num_channels = ARRAY_SIZE(hx711_chan_spec);
+
+ return devm_iio_device_register(dev, iio);
+}
+
+static const struct of_device_id of_hx711_match[] = {
+ { .compatible = "avia,hx711", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, of_hx711_match);
+
+static struct platform_driver hx711_driver = {
+ .probe = hx711_probe,
+ .driver = {
+ .name = "hx711-gpio",
+ .of_match_table = of_hx711_match,
+ },
+};
+
+module_platform_driver(hx711_driver);
+
+MODULE_AUTHOR("Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>");
+MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:hx711-gpio");
+
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 1/2] iio: adc: hx711: Add DT binding for avia,hx711
From: Andreas Klinger @ 2016-12-14 16:16 UTC (permalink / raw)
To: devicetree, linux-iio
Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, jic23, knaack.h, lars, pmeerw, ak
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 16 ++++++++++++++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
new file mode 100644
index 000000000000..27300b186cf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -0,0 +1,16 @@
+* AVIA HX711 ADC chip for weight cells
+ Bit-banging driver
+
+Required properties:
+ - compatible: Should be "avia,hx711"
+ - sck-gpios: Definition of the GPIO for the clock
+ - dout-gpios: Definition of the GPIO for data-out
+ See Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+weight@0 {
+ compatible = "avia,hx711";
+ sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+};
+
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 44ddc980b085..4696bb5c2198 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -32,6 +32,7 @@ atlas Atlas Scientific LLC
atmel Atmel Corporation
auo AU Optronics Corporation
avago Avago Technologies
+avia avia semiconductor
avic Shanghai AVIC Optoelectronics Co., Ltd.
axis Axis Communications AB
boe BOE Technology Group Co., Ltd.
--
2.1.4
^ permalink raw reply related
* [PATCH v3 0/2] iio: adc: hx711: Add IIO driver for AVIA HX711 ADC
From: Andreas Klinger @ 2016-12-14 16:16 UTC (permalink / raw)
To: devicetree, linux-iio
Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, jic23, knaack.h, lars, pmeerw, ak
This series adds IIO driver support for the AVIA HX711 ADC which is
mostly used in weighting cells.
The first patch adds the new DT binding for which a new vendor avia
was also added.
The second patch is the simple IIO driver implemented as ADC.
The protocol is specific to this device and implemented using GPIO's.
Documentation of the chip can be found here:
https://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf
Changes in v3:
moved gain from devicetree to sysfs, according to comment of Lars-Peter
Thanks for reviewing and giving suggestions
* Patch 1: "iio: adc: hx711: Add DT binding for avia,hx711"
- removed property gain
* Patch 2: "iio: adc: hx711: Add IIO driver for AVIA HX711"
- removed property gain from devicetree
- added device attribute (rw) for gain
- support reading from both channels now
Changes in v2:
Lots of updates thanks to Peters review.
* Patch 1: "iio: adc: hx711: Add DT binding for avia,hx711"
- typo
- removed unneded section
* Patch 2: "iio: adc: hx711: Add IIO driver for AVIA HX711"
- updated help text in Kconfig
- removed dead code
- removed unused power management
- reduced channel spec to what is actually used
- added error handling in case reset of chip not possible
Andreas Klinger (2):
iio: adc: hx711: Add DT binding for avia,hx711
iio: adc: hx711: Add IIO driver for AVIA HX711
.../devicetree/bindings/iio/adc/avia-hx711.txt | 16 ++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/iio/adc/Kconfig | 18 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/hx711.c | 292 +++++++++++++++++++++
5 files changed, 328 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
create mode 100644 drivers/iio/adc/hx711.c
--
2.1.4
^ permalink raw reply
* Re: [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Chen-Yu Tsai @ 2016-12-14 16:12 UTC (permalink / raw)
To: Quentin Schulz
Cc: Mark Rutland, devicetree, open list:THERMAL, linux-kernel,
Sebastian Reichel, Russell King, Chen-Yu Tsai, Rob Herring,
Maxime Ripard, Lee Jones, Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20161209110419.28981-5-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> v2:
> - adding small explanation on AXP223 variation compared to the AXP221,
>
> Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> index f1d7bee..ba8d35f 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> @@ -3,6 +3,11 @@ AXP20x USB power supply
> Required Properties:
> -compatible: One of: "x-powers,axp202-usb-power-supply"
> "x-powers,axp221-usb-power-supply"
> + "x-powers,axp223-usb-power-supply"
> +
> +The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight
> +variations such as the former being able to set the VBUS power supply max
> +current to 100mA, unlike the latter.
I actually wanted this in the commit log, but this works too.
Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> This node is a subnode of the axp20x PMIC.
>
> --
> 2.9.3
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 16:10 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Arjun K V, Krzysztof Kozlowski, Kukjin Kim, Rob Herring,
Mark Rutland, Russell King, Doug Anderson, Andreas Faerber,
Thomas Abraham, Ben Gamari, linux-samsung-soc, linux-arm-kernel,
linux-pm, devicetree, linux-kernel
In-Reply-To: <ee4321d6-dcc9-4de7-c376-6b169d160322@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
> >>
> >> Hello Bartlomiej,
> >>
> >> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >>>> Hello Bartlomiej,
> >>>
> >>> Hi,
> >>>
> >>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>>>> cooling maps to account for new OPPs.
> >>>>>
> >>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>>>
> >>>>> Tested on Odroid-XU3 and XU3 Lite.
> >>>>>
> >>>>> Cc: Doug Anderson <dianders@chromium.org>
> >>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>>>> Cc: Andreas Faerber <afaerber@suse.de>
> >>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>>>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>>>
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -118,7 +118,7 @@
> >>>>> /*
> >>>>> * When reaching cpu_alert3, reduce CPU
> >>>>> * by 2 steps. On Exynos5422/5800 that would
> >>>>> - * be: 1600 MHz and 1100 MHz.
> >>>>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>>>> */
> >>>>> map3 {
> >>>>> trip = <&cpu_alert3>;
> >>>>> @@ -131,16 +131,16 @@
> >>>>>
> >>>>> /*
> >>>>> * When reaching cpu_alert4, reduce CPU
> >>>>> - * further, down to 600 MHz (11 steps for big,
> >>>>> - * 7 steps for LITTLE).
> >>>>> + * further, down to 600 MHz (13 steps for big,
> >>>>> + * 8 steps for LITTLE).
> >>>>> */
> >>>>> - map5 {
> >>>>> + cooling_map5: map5 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu0 3 7>;
> >>>>> + cooling-device = <&cpu0 3 8>;
> >>>>> };
> >>>>> - map6 {
> >>>>> + cooling_map6: map6 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu4 3 11>;
> >>>>> + cooling-device = <&cpu4 3 13>;
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -21,6 +21,23 @@
> >>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>>>> };
> >>>>>
> >>>>> +&cluster_a15_opp_table {
> >>>>> + /delete-node/opp@2000000000;
> >>>>> + /delete-node/opp@1900000000;
> >>>>> +};
> >>>>> +
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-node/opp@1400000000;
> >>>>> +};
> >>>>> +
> >>>>
> >>>> I think that a comment in the DTS why these operating points aren't available
> >>>> in this board will make more clear why the nodes are being deleted.
> >>>
> >>> Ok, I will add these comments in the next patch revision.
> >>>
> >>>>> +&cooling_map5 {
> >>>>> + cooling-device = <&cpu0 3 7>;
> >>>>> +};
> >>>>> +
> >>>>> +&cooling_map6 {
> >>>>> + cooling-device = <&cpu4 3 11>;
> >>>>> +};
> >>>>> +
> >>>>> &pwm {
> >>>>> /*
> >>>>> * PWM 0 -- fan
> >>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -146,6 +146,10 @@
> >>>>> vdd-supply = <&ldo9_reg>;
> >>>>> };
> >>>>>
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-property/opp@1400000000;
> >>>>> +};
> >>>>> +
> >>>>> &cpu0 {
> >>>>> cpu-supply = <&buck2_reg>;
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -24,6 +24,16 @@
> >>>>> };
> >>>>>
> >>>>> &cluster_a15_opp_table {
> >>>>> + opp@2000000000 {
> >>>>> + opp-hz = /bits/ 64 <2000000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> + opp@1900000000 {
> >>>>> + opp-hz = /bits/ 64 <1900000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> opp@1700000000 {
> >>>>> opp-microvolt = <1250000>;
> >>>>> };
> >>>>> @@ -85,6 +95,11 @@
> >>>>> };
> >>>>>
> >>>>
> >>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >>>> INT rail would need to be scaled up as well since there's a maximum voltage
> >>>> difference between the ARM and INT rails before the system becomes unstable:
> >>>>
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >>>> https://lkml.org/lkml/2014/5/2/419
> >>>>
> >>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >>>> the maximum voltage skew is between a limit. But that never made to mainline:
> >>>>
> >>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >>>> https://lkml.org/lkml/2014/4/29/28
> >>>>
> >>>> Did that change and there's infrastructure in mainline now to cope with that?
> >>>> If that's the case, I think it would be good to mention in the commit message.
> >>>
> >>> I was not aware of this limitation and AFAIK mainline has currently
> >>> no code to handle it. I also cannot find any code to handle this in
> >>
> >> Yes, that's what I thought as well but maybe I was missing something.
> >>
> >>> Hardkernel's vendor kernel for Odroid-XU3 board.
> >>>
> >>> Do you know whether this problem exists also on Exynos5422/5800
> >>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> >>> regulator code also on Exynos5800 SoC based Peach Pi board but was
> >>> the problem actually present on this board?
> >>>
> >>
> >> My understanding is that this problem is present in 5420/5422/5800
> >> but I have no way to confirm this. I'm just guessing from the info
> >> in the ChromiumOS vendor tree.
> >>
> >> If you look at the commit that added the regulator-locker driver,
> >> the test says to be done in a Peach Pi so it seems the problem is
> >> not restricted to only Exynos5420:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> >>
> >>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> >>> (unfortunately Inderpal's email is no longer working). ]
> >>>
> >>
> >> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> >
> > Abhilash's email is also no longer valid.. :(
> >
>
> Yes, I noticed that as well :(
>
> >>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> >>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> >>> IOW if the problem exists it is already present in the mainline
> >>> kernel.
> >>>
> >>
> >> Ah, I only looked at your patch and I didn't compare the voltage levels
> >> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
> >>
> >> I wonder if the voltage levels in your patch are correct then, since the
> >> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
> >>
> >> /*
> >> * Default ASV table
> >> */
> >> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> >> 1362500, /* L0 2100 */
> >> 1312500, /* L1 2000 */
> >> 1275000, /* L2 1900 */
> >> 1225000, /* L3 1800 */
> >> 1200000, /* L4 1700 */
> >>
> >> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> >
> > I think that the above voltages are original ones for Exynos5420
> > (not for Exynos5422/5800).
> >
>
> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
This seems suboptimal (or maybe even incorrect as Exynos5422/5800
SoCs also use different clock divider values for clocks related to
CPU clock than Exynos5420 SoC).
Anyway, I can drop Peach Pi support from my patch for now if you want.
> > The voltages in my patch were taken from Hardkernel's kernel for
> > Odroid-XU3:
> >
> > /*
> > * ASV group voltage table
> > */
> > static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> > ...
> > 1250000, /* L4 2000 */
> > 1250000, /* L5 1900 */
> > 1250000, /* L6 1800 */
> > ...
> >
> > https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
> >
>
> In general I prefer to use the ChromiumOS tree as a reference instead of the
> HardKernel one, since the former is in a much better shape IMHO.
I generally agree, OTOH Hardkernel's tree is based on Samsung's
vendor trees and additionally it contains all low-level hardware
details for Odroid-XU3 board (not present in ChromiumOS tree).
> I think is worth to check in a kernel tree in http://opensource.samsung.com/
> for a product that's Exynos5422/5800 based.
I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
S5 which is Exynos5422 based) and it uses 50mV lower voltages for
1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
identical to the ones used by HardKernel's tree,
drivers/cpufreq/exynos5422-eagle-cpufreq.c:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1200000, /* L4 2000 */
1200000, /* L5 1900 */
1200000, /* L6 1800 */
1200000, /* L7 1700 */
1200000, /* L8 1600 */
1100000, /* L9 1500 */
1100000, /* L10 1400 */
1100000, /* L11 1300 */
1000000, /* L12 1200 */
1000000, /* L13 1100 */
1000000, /* L14 1000 */
1000000, /* L15 900 */
900000, /* L16 800 */
900000, /* L17 700 */
900000, /* L18 600 */
900000, /* L19 500 */
900000, /* L20 400 */
900000, /* L22 300 */
900000, /* L22 200 */
};
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v2 03/11] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Chen-Yu Tsai @ 2016-12-14 15:45 UTC (permalink / raw)
To: Quentin Schulz
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, Lee Jones, open list:THERMAL,
devicetree, linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20161209110419.28981-4-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> AXP20X and AXP22X PMICs allow setting the min voltage and max current of
> VBUS power supply. This adds entries in sysfs to allow to do so.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Chen-Yu Tsai @ 2016-12-14 15:43 UTC (permalink / raw)
To: Quentin Schulz
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, Lee Jones, open list:THERMAL,
devicetree, linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20161209110419.28981-3-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
> and minimum current delivered by the VBUS power supply.
>
> This adds the register used by the VBUS power supply driver to the range
> of volatile and writeable regs ranges.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> added in v2
>
> drivers/mfd/axp20x.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be..6ee2cc6 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
>
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
This is already covered by the previous entry.
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> };
>
> static const struct regmap_range axp20x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
And I'm not sure why you specify it as volatile? The PMIC doesn't change any
of the bits in this register on its own.
Same for the AXP22x bits. So basically I think you don't need this patch.
ChenYu
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
> @@ -91,11 +93,13 @@ static const struct regmap_access_table axp20x_volatile_table = {
> /* AXP22x ranges are shared with the AXP809, as they cover the same range */
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
>
> static const struct regmap_range axp22x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
> regmap_reg_range(AXP20X_FG_RES, AXP20X_FG_RES),
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v9 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Alan Tull @ 2016-12-14 15:40 UTC (permalink / raw)
To: Moritz Fischer
Cc: Joel Holdsworth, Alan Tull, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Marek Vašut
In-Reply-To: <CAAtXAHcV+AG4en2U=KB0DeLa6RauC9ndojT=ffj+8hWtzS1o4w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 9 Dec 2016, Moritz Fischer wrote:
> Joel,
>
> A couple of minor nits below (none of them are real blockers), other
> than that looks good.
>
> On Thu, Dec 8, 2016 at 9:35 PM, Joel Holdsworth
> <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org> wrote:
> > The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> > and very regular structure, designed for low-cost, high-volume consumer
> > and system applications.
>
> <snip>
>
> > This patch adds support to the FPGA manager for configuring the SRAM of
> > iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
> > UltraPlus devices, through slave SPI.
>
> </snip>
>
> I think just this paragraph would be enough.
With these changes,
Acked-by: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Thanks,
Alan
> >
> > The iCE40 family is notable because it is the first FPGA family to have
> > complete reverse engineered bit-stream documentation for the iCE40LP and
> > iCE40HX devices. Furthermore, there is now a Free Software Verilog
> > synthesis tool-chain: the "IceStorm" tool-chain.
> >
> > This project is the work of Clifford Wolf, who is the maintainer of
> > Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
> > contributions from "Cotton Seed", the main author of "arachne-pnr"; a
> > place-and-route tool for iCE40 FPGAs.
> >
> > Having a Free Software synthesis tool-chain offers interesting
> > opportunities for embedded devices that are able reconfigure themselves
> > with open firmware that is generated on the device itself. For example
> > a mobile device might have an application processor with an iCE40 FPGA
> > attached, which implements slave devices, or through which the processor
> > communicates with other devices through the FPGA fabric.
> >
> > A kernel driver for the iCE40 is useful, because in some cases, the FPGA
> > may need to be configured before other devices can be accessed.
> >
> > An example of such a device is the icoBoard; a RaspberryPI HAT which
> > features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
> > Digilent-compatible PMOD modules. A PMOD module may contain a device
> > with which the kernel communicates, via the FPGA.
> >
> > Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
> Modulo nits:
>
> Reviewed-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
>
> > ---
> > drivers/fpga/Kconfig | 6 ++
> > drivers/fpga/Makefile | 1 +
> > drivers/fpga/ice40-spi.c | 213 +++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 220 insertions(+)
> > create mode 100644 drivers/fpga/ice40-spi.c
> >
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index ce861a2..967cda4 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -20,6 +20,12 @@ config FPGA_REGION
> > FPGA Regions allow loading FPGA images under control of
> > the Device Tree.
> >
> > +config FPGA_MGR_ICE40_SPI
> > + tristate "Lattice iCE40 SPI"
> > + depends on OF && SPI
> > + help
> > + FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
> > +
> > config FPGA_MGR_SOCFPGA
> > tristate "Altera SOCFPGA FPGA Manager"
> > depends on ARCH_SOCFPGA || COMPILE_TEST
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index 8df07bc..cc0d364 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -6,6 +6,7 @@
> > obj-$(CONFIG_FPGA) += fpga-mgr.o
> >
> > # FPGA Manager Drivers
> > +obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40-spi.o
> > obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> > obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
> > obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> > diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
> > new file mode 100644
> > index 0000000..3c99859
> > --- /dev/null
> > +++ b/drivers/fpga/ice40-spi.c
> > @@ -0,0 +1,213 @@
> > +/*
> > + * FPGA Manager Driver for Lattice iCE40.
> > + *
> > + * Copyright (c) 2016 Joel Holdsworth
> > + *
> > + * 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; version 2 of the License.
> > + *
> > + * This driver adds support to the FPGA manager for configuring the SRAM of
> > + * Lattice iCE40 FPGAs through slave SPI.
> > + */
> > +
> > +#include <linux/fpga/fpga-mgr.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/module.h>
> > +#include <linux/of_gpio.h>
> > +#include <linux/spi/spi.h>
> > +
> > +#define ICE40_SPI_FPGAMGR_RESET_DELAY 1 /* us (>200ns) */
> > +#define ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY 1200 /* us */
> > +
> > +#define ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES DIV_ROUND_UP(49, 8)
> > +
> > +struct ice40_fpga_priv {
> > + struct spi_device *dev;
> > + struct gpio_desc *reset;
> > + struct gpio_desc *cdone;
> > +};
> > +
> > +static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > +
> > + return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
> > + FPGA_MGR_STATE_UNKNOWN;
> > +}
> > +
> > +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr,
> > + struct fpga_image_info *info,
> > + const char *buf, size_t count)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > + struct spi_device *dev = priv->dev;
> > + struct spi_message message;
> > + struct spi_transfer assert_cs_then_reset_delay = {
> > + .cs_change = 1,
> > + .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
> > + };
> > + struct spi_transfer housekeeping_delay_then_release_cs = {
> > + .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY
> > + };
> > + int ret;
> > +
> > + if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> > + dev_err(&dev->dev,
> > + "Partial reconfiguration is not supported\n");
> > + return -ENOTSUPP;
> > + }
> > +
> > + /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
> > + spi_bus_lock(dev->master);
> > +
> > + gpiod_set_value(priv->reset, 1);
> > +
> > + spi_message_init(&message);
> > + spi_message_add_tail(&assert_cs_then_reset_delay, &message);
> > + ret = spi_sync_locked(dev, &message);
> > +
> > + /* Come out of reset */
> > + gpiod_set_value(priv->reset, 0);
> > +
> > + /* Abort if the chip-select failed */
> > + if (ret)
> > + goto fail;
> > +
> > + /* Check CDONE is de-asserted i.e. the FPGA is reset */
> > + if (gpiod_get_value(priv->cdone)) {
> > + dev_err(&dev->dev, "Device reset failed, CDONE is asserted\n");
> > + ret = -EIO;
> > + goto fail;
> > + }
> > +
> > + /* Wait for the housekeeping to complete, and release SS_B */
> > + spi_message_init(&message);
> > + spi_message_add_tail(&housekeeping_delay_then_release_cs, &message);
> > + ret = spi_sync_locked(dev, &message);
> > +
> > +fail:
> > + spi_bus_unlock(dev->master);
> > +
> > + return ret;
> > +}
> > +
> > +static int ice40_fpga_ops_write(struct fpga_manager *mgr,
> > + const char *buf, size_t count)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > +
> > + return spi_write(priv->dev, buf, count);
> > +}
> > +
> > +static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr,
> > + struct fpga_image_info *info)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > + struct spi_device *dev = priv->dev;
> > + const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0};
> > +
> > + /* Check CDONE is asserted */
> > + if (!gpiod_get_value(priv->cdone)) {
> > + dev_err(&dev->dev,
> > + "CDONE was not asserted after firmware transfer\n");
> > + return -EIO;
> > + }
> > +
> > + /* Send of zero-padding to activate the firmware */
> > + return spi_write(dev, padding, sizeof(padding));
> > +}
> > +
> > +static const struct fpga_manager_ops ice40_fpga_ops = {
> > + .state = ice40_fpga_ops_state,
> > + .write_init = ice40_fpga_ops_write_init,
> > + .write = ice40_fpga_ops_write,
> > + .write_complete = ice40_fpga_ops_write_complete,
> > +};
> > +
> > +static int ice40_fpga_probe(struct spi_device *spi)
> > +{
> > + struct device *dev = &spi->dev;
> > + struct device_node *np = spi->dev.of_node;
> > + struct ice40_fpga_priv *priv;
> > + int ret;
> > +
> > + if (!np) {
> > + dev_err(dev, "No Device Tree entry\n");
> > + return -EINVAL;
> > + }
> > +
> > + priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->dev = spi;
> > +
> > + /* Check board setup data. */
> > + if (spi->max_speed_hz > 25000000) {
> > + dev_err(dev, "Speed is too high\n");
>
> Speed is too high, maximum speed is X. Maybe make it a ICE40_SPI_MAX_SPEED
> > + return -EINVAL;
> > + }
> > +
> > + if (spi->max_speed_hz < 1000000) {
> > + dev_err(dev, "Speed is too low\n");
>
> Speed is too low, minimum speed is X. Maybe make it a ICE40_SPI_MIN_SPEED
> > + return -EINVAL;
> > + }
> > +
> > + if (spi->mode & SPI_CPHA) {
> > + dev_err(dev, "Bad mode\n");
>
> 'Bad mode, SPI_CPHA not supported' mabye.
> > + return -EINVAL;
> > + }
> > +
> > + /* Set up the GPIOs */
> > + priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
> > + if (IS_ERR(priv->cdone)) {
> > + dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
> > + PTR_ERR(priv->cdone));
> > + return -EINVAL;
> > + }
> > +
> > + priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(priv->reset)) {
> > + dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
> > + PTR_ERR(priv->reset));
> > + return -EINVAL;
> > + }
> > +
> > + /* Register with the FPGA manager */
> > + ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
> > + &ice40_fpga_ops, priv);
> > + if (ret) {
> > + dev_err(dev, "Unable to register FPGA manager");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int ice40_fpga_remove(struct spi_device *spi)
> > +{
> > + fpga_mgr_unregister(&spi->dev);
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id ice40_fpga_of_match[] = {
> > + { .compatible = "lattice,ice40-fpga-mgr", },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
> > +
> > +static struct spi_driver ice40_fpga_driver = {
> > + .probe = ice40_fpga_probe,
> > + .remove = ice40_fpga_remove,
> > + .driver = {
> > + .name = "ice40spi",
> > + .of_match_table = of_match_ptr(ice40_fpga_of_match),
> > + },
> > +};
> > +
> > +module_spi_driver(ice40_fpga_driver);
> > +
> > +MODULE_AUTHOR("Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>");
> > +MODULE_DESCRIPTION("Lattice iCE40 FPGA Manager");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 2.7.4
> >
>
> Thanks,
>
> Moritz
>
> PS: can you also Cc linux-fpga mailing list in the future?
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 01/11] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Chen-Yu Tsai @ 2016-12-14 15:38 UTC (permalink / raw)
To: Quentin Schulz
Cc: Mark Rutland, devicetree, open list:THERMAL, linux-kernel,
Sebastian Reichel, Russell King, Chen-Yu Tsai, Rob Herring,
Maxime Ripard, Lee Jones, Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20161209110419.28981-2-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This replaces calls to of_device_is_compatible to check data field of
> of_device_id matched when probing the driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-14 15:30 UTC (permalink / raw)
To: Emmanuel Vadot
Cc: robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161214145724.42745-1-manu@bidouilliste.com>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
On Wed, Dec 14, 2016 at 03:57:24PM +0100, Emmanuel Vadot wrote:
> The node name for the power seq pin is mmc2@0 like the mmc2_pins_a one.
> This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> result in a unusable eMMC if U-Boot didn't configured the pins to the
> correct functions.
>
> Changes since v1:
> * Rename the node mmc2-rst-pin
That changelog should be after the ---. Removed it and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] power: supply: bq24735-charger: optionally poll the ac-detect gpio
From: Sebastian Reichel @ 2016-12-14 15:10 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-kernel, Rob Herring, Mark Rutland, linux-pm, devicetree
In-Reply-To: <1481673405-4547-3-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Hi,
On Wed, Dec 14, 2016 at 12:56:44AM +0100, Peter Rosin wrote:
> If the ac-detect gpio does not support interrupts, provide a fallback
> to poll the gpio at a configurable interval.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>
> [...]
>
> + } else if (charger->status_gpio) {
> + ret = of_property_read_u32(client->dev.of_node,
> + "poll-interval",
> + &charger->poll_interval);
Please use device_property_read_u32() instead.
> [...]
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.
From: Rob (William) Rice @ 2016-12-14 15:00 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Herbert Xu, David S. Miller, Rob Herring,
Mark Rutland, linux-crypto, devicetree, linux-kernel, Ray Jui,
Scott Branden, Jon Mason, bcm-kernel-feedback-list,
Catalin Marinas, Will Deacon, linux-arm-kernel, Steve Lin
In-Reply-To: <201612110810.BEVbRp0B%fengguang.wu@intel.com>
I will rebase to Herbert's latest when I submit v3 to address Mark
Rutland's DT comments (and any others that come in).
Rob
On 12/10/2016 7:14 PM, kbuild test robot wrote:
> Hi Rob,
>
> [auto build test ERROR on cryptodev/master]
> [also build test ERROR on v4.9-rc8]
> [cannot apply to next-20161209]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Rob-Rice/crypto-brcm-DT-documentation-for-Broadcom-SPU-driver/20161202-010038
> base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: Input tree has errors, aborting (use -f to force output)
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Emmanuel Vadot @ 2016-12-14 14:57 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Emmanuel Vadot
The node name for the power seq pin is mmc2@0 like the mmc2_pins_a one.
This makes the original node (mmc2_pins_a) scrapped out of the dtb and
result in a unusable eMMC if U-Boot didn't configured the pins to the
correct functions.
Changes since v1:
* Rename the node mmc2-rst-pin
Signed-off-by: Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
index 5ea4915..10d3074 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
@@ -56,7 +56,7 @@
};
&pio {
- mmc2_pins_nrst: mmc2@0 {
+ mmc2_pins_nrst: mmc2-rst-pin {
allwinner,pins = "PC16";
allwinner,function = "gpio_out";
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
--
2.9.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 14:40 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Arjun K V, Krzysztof Kozlowski, Kukjin Kim, Rob Herring,
Mark Rutland, Russell King, Doug Anderson, Andreas Faerber,
Thomas Abraham, Ben Gamari, linux-samsung-soc, linux-arm-kernel,
linux-pm, devicetree, linux-kernel
In-Reply-To: <3539351.vsrnVhEgRT@amdc3058>
Hello Bartlomiej,
On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>
>> Hello Bartlomiej,
>>
>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>> Hello Bartlomiej,
>>>
>>> Hi,
>>>
>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>> cooling maps to account for new OPPs.
>>>>>
>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>
>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>
>>>>> Cc: Doug Anderson <dianders@chromium.org>
>>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>>>> Cc: Andreas Faerber <afaerber@suse.de>
>>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -118,7 +118,7 @@
>>>>> /*
>>>>> * When reaching cpu_alert3, reduce CPU
>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>> */
>>>>> map3 {
>>>>> trip = <&cpu_alert3>;
>>>>> @@ -131,16 +131,16 @@
>>>>>
>>>>> /*
>>>>> * When reaching cpu_alert4, reduce CPU
>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>> - * 7 steps for LITTLE).
>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>> + * 8 steps for LITTLE).
>>>>> */
>>>>> - map5 {
>>>>> + cooling_map5: map5 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu0 3 7>;
>>>>> + cooling-device = <&cpu0 3 8>;
>>>>> };
>>>>> - map6 {
>>>>> + cooling_map6: map6 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu4 3 11>;
>>>>> + cooling-device = <&cpu4 3 13>;
>>>>> };
>>>>> };
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -21,6 +21,23 @@
>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>> };
>>>>>
>>>>> +&cluster_a15_opp_table {
>>>>> + /delete-node/opp@2000000000;
>>>>> + /delete-node/opp@1900000000;
>>>>> +};
>>>>> +
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-node/opp@1400000000;
>>>>> +};
>>>>> +
>>>>
>>>> I think that a comment in the DTS why these operating points aren't available
>>>> in this board will make more clear why the nodes are being deleted.
>>>
>>> Ok, I will add these comments in the next patch revision.
>>>
>>>>> +&cooling_map5 {
>>>>> + cooling-device = <&cpu0 3 7>;
>>>>> +};
>>>>> +
>>>>> +&cooling_map6 {
>>>>> + cooling-device = <&cpu4 3 11>;
>>>>> +};
>>>>> +
>>>>> &pwm {
>>>>> /*
>>>>> * PWM 0 -- fan
>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -146,6 +146,10 @@
>>>>> vdd-supply = <&ldo9_reg>;
>>>>> };
>>>>>
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-property/opp@1400000000;
>>>>> +};
>>>>> +
>>>>> &cpu0 {
>>>>> cpu-supply = <&buck2_reg>;
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -24,6 +24,16 @@
>>>>> };
>>>>>
>>>>> &cluster_a15_opp_table {
>>>>> + opp@2000000000 {
>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> + opp@1900000000 {
>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> opp@1700000000 {
>>>>> opp-microvolt = <1250000>;
>>>>> };
>>>>> @@ -85,6 +95,11 @@
>>>>> };
>>>>>
>>>>
>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>> https://lkml.org/lkml/2014/5/2/419
>>>>
>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>> https://lkml.org/lkml/2014/4/29/28
>>>>
>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>> If that's the case, I think it would be good to mention in the commit message.
>>>
>>> I was not aware of this limitation and AFAIK mainline has currently
>>> no code to handle it. I also cannot find any code to handle this in
>>
>> Yes, that's what I thought as well but maybe I was missing something.
>>
>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>
>>> Do you know whether this problem exists also on Exynos5422/5800
>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>> the problem actually present on this board?
>>>
>>
>> My understanding is that this problem is present in 5420/5422/5800
>> but I have no way to confirm this. I'm just guessing from the info
>> in the ChromiumOS vendor tree.
>>
>> If you look at the commit that added the regulator-locker driver,
>> the test says to be done in a Peach Pi so it seems the problem is
>> not restricted to only Exynos5420:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>> (unfortunately Inderpal's email is no longer working). ]
>>>
>>
>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>
> Abhilash's email is also no longer valid.. :(
>
Yes, I noticed that as well :(
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>>
>>
>> Ah, I only looked at your patch and I didn't compare the voltage levels
>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>
>> I wonder if the voltage levels in your patch are correct then, since the
>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>
>> /*
>> * Default ASV table
>> */
>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>> 1362500, /* L0 2100 */
>> 1312500, /* L1 2000 */
>> 1275000, /* L2 1900 */
>> 1225000, /* L3 1800 */
>> 1200000, /* L4 1700 */
>>
>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>
> I think that the above voltages are original ones for Exynos5420
> (not for Exynos5422/5800).
>
In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
> The voltages in my patch were taken from Hardkernel's kernel for
> Odroid-XU3:
>
> /*
> * ASV group voltage table
> */
> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> ...
> 1250000, /* L4 2000 */
> 1250000, /* L5 1900 */
> 1250000, /* L6 1800 */
> ...
>
> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>
In general I prefer to use the ChromiumOS tree as a reference instead of the
HardKernel one, since the former is in a much better shape IMHO.
I think is worth to check in a kernel tree in http://opensource.samsung.com/
for a product that's Exynos5422/5800 based.
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 14:25 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Arjun K V, Krzysztof Kozlowski, Kukjin Kim, Rob Herring,
Mark Rutland, Russell King, Doug Anderson, Andreas Faerber,
Thomas Abraham, Ben Gamari, linux-samsung-soc, linux-arm-kernel,
linux-pm, devicetree, linux-kernel
In-Reply-To: <a3179721-3a0e-651b-f422-c08463aae7e6@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>
> Hello Bartlomiej,
>
> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >> Hello Bartlomiej,
> >
> > Hi,
> >
> >> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>> cooling maps to account for new OPPs.
> >>>
> >>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>
> >>> Tested on Odroid-XU3 and XU3 Lite.
> >>>
> >>> Cc: Doug Anderson <dianders@chromium.org>
> >>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>> Cc: Andreas Faerber <afaerber@suse.de>
> >>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>> ---
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -118,7 +118,7 @@
> >>> /*
> >>> * When reaching cpu_alert3, reduce CPU
> >>> * by 2 steps. On Exynos5422/5800 that would
> >>> - * be: 1600 MHz and 1100 MHz.
> >>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>> */
> >>> map3 {
> >>> trip = <&cpu_alert3>;
> >>> @@ -131,16 +131,16 @@
> >>>
> >>> /*
> >>> * When reaching cpu_alert4, reduce CPU
> >>> - * further, down to 600 MHz (11 steps for big,
> >>> - * 7 steps for LITTLE).
> >>> + * further, down to 600 MHz (13 steps for big,
> >>> + * 8 steps for LITTLE).
> >>> */
> >>> - map5 {
> >>> + cooling_map5: map5 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu0 3 7>;
> >>> + cooling-device = <&cpu0 3 8>;
> >>> };
> >>> - map6 {
> >>> + cooling_map6: map6 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu4 3 11>;
> >>> + cooling-device = <&cpu4 3 13>;
> >>> };
> >>> };
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -21,6 +21,23 @@
> >>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>> };
> >>>
> >>> +&cluster_a15_opp_table {
> >>> + /delete-node/opp@2000000000;
> >>> + /delete-node/opp@1900000000;
> >>> +};
> >>> +
> >>> +&cluster_a7_opp_table {
> >>> + /delete-node/opp@1400000000;
> >>> +};
> >>> +
> >>
> >> I think that a comment in the DTS why these operating points aren't available
> >> in this board will make more clear why the nodes are being deleted.
> >
> > Ok, I will add these comments in the next patch revision.
> >
> >>> +&cooling_map5 {
> >>> + cooling-device = <&cpu0 3 7>;
> >>> +};
> >>> +
> >>> +&cooling_map6 {
> >>> + cooling-device = <&cpu4 3 11>;
> >>> +};
> >>> +
> >>> &pwm {
> >>> /*
> >>> * PWM 0 -- fan
> >>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -146,6 +146,10 @@
> >>> vdd-supply = <&ldo9_reg>;
> >>> };
> >>>
> >>> +&cluster_a7_opp_table {
> >>> + /delete-property/opp@1400000000;
> >>> +};
> >>> +
> >>> &cpu0 {
> >>> cpu-supply = <&buck2_reg>;
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -24,6 +24,16 @@
> >>> };
> >>>
> >>> &cluster_a15_opp_table {
> >>> + opp@2000000000 {
> >>> + opp-hz = /bits/ 64 <2000000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> + opp@1900000000 {
> >>> + opp-hz = /bits/ 64 <1900000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> opp@1700000000 {
> >>> opp-microvolt = <1250000>;
> >>> };
> >>> @@ -85,6 +95,11 @@
> >>> };
> >>>
> >>
> >> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >> INT rail would need to be scaled up as well since there's a maximum voltage
> >> difference between the ARM and INT rails before the system becomes unstable:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >> https://lkml.org/lkml/2014/5/2/419
> >>
> >> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >> the maximum voltage skew is between a limit. But that never made to mainline:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >> https://lkml.org/lkml/2014/4/29/28
> >>
> >> Did that change and there's infrastructure in mainline now to cope with that?
> >> If that's the case, I think it would be good to mention in the commit message.
> >
> > I was not aware of this limitation and AFAIK mainline has currently
> > no code to handle it. I also cannot find any code to handle this in
>
> Yes, that's what I thought as well but maybe I was missing something.
>
> > Hardkernel's vendor kernel for Odroid-XU3 board.
> >
> > Do you know whether this problem exists also on Exynos5422/5800
> > SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> > regulator code also on Exynos5800 SoC based Peach Pi board but was
> > the problem actually present on this board?
> >
>
> My understanding is that this problem is present in 5420/5422/5800
> but I have no way to confirm this. I'm just guessing from the info
> in the ChromiumOS vendor tree.
>
> If you look at the commit that added the regulator-locker driver,
> the test says to be done in a Peach Pi so it seems the problem is
> not restricted to only Exynos5420:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>
> > [ I added Arjun to Cc:, maybe he can help in explaining this issue
> > (unfortunately Inderpal's email is no longer working). ]
> >
>
> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
Abhilash's email is also no longer valid.. :(
> > Please also note that on Exynos5422/5800 SoCs the same ARM rail
> > voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> > IOW if the problem exists it is already present in the mainline
> > kernel.
> >
>
> Ah, I only looked at your patch and I didn't compare the voltage levels
> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>
> I wonder if the voltage levels in your patch are correct then, since the
> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>
> /*
> * Default ASV table
> */
> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> 1362500, /* L0 2100 */
> 1312500, /* L1 2000 */
> 1275000, /* L2 1900 */
> 1225000, /* L3 1800 */
> 1200000, /* L4 1700 */
>
> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
I think that the above voltages are original ones for Exynos5420
(not for Exynos5422/5800).
The voltages in my patch were taken from Hardkernel's kernel for
Odroid-XU3:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1250000, /* L4 2000 */
1250000, /* L5 1900 */
1250000, /* L6 1800 */
...
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH] dt-bindings: mfd: stm32f429: Add QSPI & DSI constants into DT include file
From: gabriel.fernandez @ 2016-12-14 14:23 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, amelie.delaunay, kernel, olivier.bideau, linux-kernel,
linux-clk, ludovic.barre, gabriel.fernandez, linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
It will be used by clock and reset drivers, and DT bindings.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
include/dt-bindings/mfd/stm32f4-rcc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
index e98942d..315f6c3 100644
--- a/include/dt-bindings/mfd/stm32f4-rcc.h
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -40,6 +40,7 @@
/* AHB3 */
#define STM32F4_RCC_AHB3_FMC 0
+#define STM32F4_RCC_AHB3_QSPI 1
#define STM32F4_AHB3_RESET(bit) (STM32F4_RCC_AHB3_##bit + (0x18 * 8))
#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + (0x38 * 8))
@@ -91,6 +92,7 @@
#define STM32F4_RCC_APB2_SPI6 21
#define STM32F4_RCC_APB2_SAI1 22
#define STM32F4_RCC_APB2_LTDC 26
+#define STM32F4_RCC_APB2_DSI 27
#define STM32F4_APB2_RESET(bit) (STM32F4_RCC_APB2_##bit + (0x24 * 8))
#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + (0x44 * 8))
--
1.9.1
^ permalink raw reply related
* [PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method
From: gabriel.fernandez @ 2016-12-14 14:22 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, amelie.delaunay, kernel, olivier.bideau, linux-kernel,
linux-clk, ludovic.barre, gabriel.fernandez, linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
Clock and reset controller use same compatible strings (same IP).
Since commit 989eafd0b609 ("clk: core: Avoid double initialization of
clocks") the OF core flags clock controllers registered with the
CLK_OF_DECLARE() macro as OF_POPULATED, so platform devices with the same
compatible string will not be registered.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
drivers/clk/clk-stm32f4.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 11174a5..0f5ab9b 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -1325,5 +1325,5 @@ static void __init stm32f4_rcc_init(struct device_node *np)
kfree(clks);
iounmap(base);
}
-CLK_OF_DECLARE(stm32f42xx_rcc, "st,stm32f42xx-rcc", stm32f4_rcc_init);
-CLK_OF_DECLARE(stm32f46xx_rcc, "st,stm32f469-rcc", stm32f4_rcc_init);
+CLK_OF_DECLARE_DRIVER(stm32f42xx_rcc, "st,stm32f42xx-rcc", stm32f4_rcc_init);
+CLK_OF_DECLARE_DRIVER(stm32f46xx_rcc, "st,stm32f469-rcc", stm32f4_rcc_init);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH linux v1 0/4] Seven segment display support
From: Arnd Bergmann @ 2016-12-14 14:15 UTC (permalink / raw)
To: Neil Armstrong
Cc: Greg KH, Thomas Petazzoni, mark.rutland-5wv7dgnIgG8,
Jaghathiswari Rankappagounder Natarajan,
devicetree-u79uwXL29TY76Z2rM5mHXA, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, joel-U3u1mxZcP9KHXe+LvDLADg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <ac324946-41da-c090-a0ca-78155611bb7e-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote:
> On 12/14/2016 01:56 PM, Greg KH wrote:
> > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> >> Natarajan wrote:
> >>
> >>> Documentation for the binding which provides an interface for adding clock,
> >>> data and clear signal GPIO lines to control seven segment display.
> >>>
> >>> The platform device driver provides an API for displaying on two 7-segment
> >>> displays, and implements the required bit-banging. The hardware assumed is
> >>> 74HC164 wired to two 7-segment displays.
> >>>
> >>> The character device driver implements the user-space API for letting a user
> >>> write to two 7-segment displays including any conversion methods necessary
> >>> to map the user input to two 7-segment displays.
> >>>
> >>> Adding clock, data and clear signal GPIO lines in the devicetree to control
> >>> seven segment display on zaius platform.
> >>>
> >>> The platform driver matches on the device tree node; the platform driver also
> >>> initializes the character device.
> >>>
> >>> Tested that the seven segment display works properly by writing to the
> >>> character device file on a EVB AST2500 board which also has 74HC164 wired
> >>> to two 7-segment displays.
> >>
> >> FWIW, I proposed a driver for seven segment displays back in 2013:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
> >>
> >> And the feedback from Greg KH was: we don't need a driver for that, do
> >> it from userspace. See:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
> >>
> >> So: good luck
> >
> > Did anyone ever write a library for this type of thing?
> >
> > Again, I don't want to see one-off drivers for random devices like this
> > that should be able to all be controlled from userspace in a common
> > manner. Much like we did for fingerprint readers a long long time
> > ago...
> >
> Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
> characters a simple and clean driver could achieve.
> Some very well known SoCs even have integrated registers to lower the BOM and bypass the need for
> a 74HC164 like component and avoid gpio bit banging.
>
> My personal concern is that you could also need to drive more segments, thus 7-segments
> is too restrictive.
>
> But this driver is well structured, the gpio-bitbanging sub-driver is welcome.
Maybe we can find a way to fit this into the existing drivers/leds/ subsystem?
That already supports blinking, brightness and colour attributes of LEDs,
so could this be extended to support (one of) digit, number, character
or string with a common sysfs attribute and a way to hook up a led driver
to that?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Andrzej Hajda @ 2016-12-14 14:14 UTC (permalink / raw)
To: Hoegeun Kwon, thierry.reding, kgene, krzk
Cc: devicetree, linux-samsung-soc, Donghwa Lee, linux-kernel,
dri-devel, Hyungwon Hwang
In-Reply-To: <1481695445-13088-2-git-send-email-hoegeun.kwon@samsung.com>
On 14.12.2016 07:04, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Hi Hoegeun Kwon,
Is there a reason to upstream obsolete driver? Current version of the
driver is available at [1]. It differs significantly and contains
multiple fixes and improvements. I guess it still requires some
polishing but it is better base for start.
[1]:
https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=blob;f=drivers/gpu/drm/panel/panel-s6e3ha2.c;hb=refs/heads/tizen
Regards
Andrzej
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-14 14:09 UTC (permalink / raw)
To: Emmanuel Vadot; +Cc: robh+dt, wens, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20161214100856.23735-1-manu@bidouilliste.com>
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
Hi Emmanuel,
On Wed, Dec 14, 2016 at 11:08:56AM +0100, Emmanuel Vadot wrote:
> The node name for the power seq pin is mmc2@0 like the mmc2_pins_a one.
> This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> result in a unusable eMMC if U-Boot didn't configured the pins to the
> correct functions.
>
> Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> ---
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> index 5ea4915..68cb1b5 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> @@ -56,7 +56,7 @@
> };
>
> &pio {
> - mmc2_pins_nrst: mmc2@0 {
> + mmc2_pins_nrst: mmc2@1 {
That would be even better if you renamed it to something like
mmc2-rst-pin to avoid all future conflicts (for example if we ever add
a second mmc pins groups.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 14:06 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz, Arjun K V
Cc: Krzysztof Kozlowski, Kukjin Kim, Rob Herring, Mark Rutland,
Russell King, Doug Anderson, Andreas Faerber, Thomas Abraham,
Ben Gamari, linux-samsung-soc, linux-arm-kernel, linux-pm,
devicetree, linux-kernel, Abhilash Kesavan
In-Reply-To: <2340115.HEG9AYUCMD@amdc3058>
Hello Bartlomiej,
On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>
> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>
> Hi,
>
>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>> cooling maps to account for new OPPs.
>>>
>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>
>>> Tested on Odroid-XU3 and XU3 Lite.
>>>
>>> Cc: Doug Anderson <dianders@chromium.org>
>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>> Cc: Andreas Faerber <afaerber@suse.de>
>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>> @@ -118,7 +118,7 @@
>>> /*
>>> * When reaching cpu_alert3, reduce CPU
>>> * by 2 steps. On Exynos5422/5800 that would
>>> - * be: 1600 MHz and 1100 MHz.
>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>> */
>>> map3 {
>>> trip = <&cpu_alert3>;
>>> @@ -131,16 +131,16 @@
>>>
>>> /*
>>> * When reaching cpu_alert4, reduce CPU
>>> - * further, down to 600 MHz (11 steps for big,
>>> - * 7 steps for LITTLE).
>>> + * further, down to 600 MHz (13 steps for big,
>>> + * 8 steps for LITTLE).
>>> */
>>> - map5 {
>>> + cooling_map5: map5 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu0 3 7>;
>>> + cooling-device = <&cpu0 3 8>;
>>> };
>>> - map6 {
>>> + cooling_map6: map6 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu4 3 11>;
>>> + cooling-device = <&cpu4 3 13>;
>>> };
>>> };
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>> @@ -21,6 +21,23 @@
>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>> };
>>>
>>> +&cluster_a15_opp_table {
>>> + /delete-node/opp@2000000000;
>>> + /delete-node/opp@1900000000;
>>> +};
>>> +
>>> +&cluster_a7_opp_table {
>>> + /delete-node/opp@1400000000;
>>> +};
>>> +
>>
>> I think that a comment in the DTS why these operating points aren't available
>> in this board will make more clear why the nodes are being deleted.
>
> Ok, I will add these comments in the next patch revision.
>
>>> +&cooling_map5 {
>>> + cooling-device = <&cpu0 3 7>;
>>> +};
>>> +
>>> +&cooling_map6 {
>>> + cooling-device = <&cpu4 3 11>;
>>> +};
>>> +
>>> &pwm {
>>> /*
>>> * PWM 0 -- fan
>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> @@ -146,6 +146,10 @@
>>> vdd-supply = <&ldo9_reg>;
>>> };
>>>
>>> +&cluster_a7_opp_table {
>>> + /delete-property/opp@1400000000;
>>> +};
>>> +
>>> &cpu0 {
>>> cpu-supply = <&buck2_reg>;
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> @@ -24,6 +24,16 @@
>>> };
>>>
>>> &cluster_a15_opp_table {
>>> + opp@2000000000 {
>>> + opp-hz = /bits/ 64 <2000000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> + opp@1900000000 {
>>> + opp-hz = /bits/ 64 <1900000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> opp@1700000000 {
>>> opp-microvolt = <1250000>;
>>> };
>>> @@ -85,6 +95,11 @@
>>> };
>>>
>>
>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>> INT rail would need to be scaled up as well since there's a maximum voltage
>> difference between the ARM and INT rails before the system becomes unstable:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>> https://lkml.org/lkml/2014/5/2/419
>>
>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>> the maximum voltage skew is between a limit. But that never made to mainline:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>> https://lkml.org/lkml/2014/4/29/28
>>
>> Did that change and there's infrastructure in mainline now to cope with that?
>> If that's the case, I think it would be good to mention in the commit message.
>
> I was not aware of this limitation and AFAIK mainline has currently
> no code to handle it. I also cannot find any code to handle this in
Yes, that's what I thought as well but maybe I was missing something.
> Hardkernel's vendor kernel for Odroid-XU3 board.
>
> Do you know whether this problem exists also on Exynos5422/5800
> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> regulator code also on Exynos5800 SoC based Peach Pi board but was
> the problem actually present on this board?
>
My understanding is that this problem is present in 5420/5422/5800
but I have no way to confirm this. I'm just guessing from the info
in the ChromiumOS vendor tree.
If you look at the commit that added the regulator-locker driver,
the test says to be done in a Peach Pi so it seems the problem is
not restricted to only Exynos5420:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> (unfortunately Inderpal's email is no longer working). ]
>
Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> IOW if the problem exists it is already present in the mainline
> kernel.
>
Ah, I only looked at your patch and I didn't compare the voltage levels
in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
I wonder if the voltage levels in your patch are correct then, since the
ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
/*
* Default ASV table
*/
static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
1362500, /* L0 2100 */
1312500, /* L1 2000 */
1275000, /* L2 1900 */
1225000, /* L3 1800 */
1200000, /* L4 1700 */
This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v4 6/6] [media] rc: add support for IR LEDs driven through SPI
From: Andi Shyti @ 2016-12-14 14:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sean Young, Rob Herring, Mark Rutland,
Richard Purdie, Jacek Anaszewski, Heiner Kallweit
Cc: linux-media, devicetree, linux-leds, linux-kernel, Andi Shyti,
Andi Shyti
In-Reply-To: <20161214140030.28537-1-andi.shyti@samsung.com>
The ir-spi is a simple device driver which supports the
connection between an IR LED and the MOSI line of an SPI device.
The driver, indeed, uses the SPI framework to stream the raw data
provided by userspace through an rc character device. The chardev
is handled by the LIRC framework and its functionality basically
provides:
- write: the driver gets a pulse/space signal and translates it
to a binary signal that will be streamed to the IR led through
the SPI framework.
- set frequency: sets the frequency whith which the data should
be sent. This is handle with ioctl with the
LIRC_SET_SEND_CARRIER flag (as per lirc documentation)
- set duty cycle: this is also handled with ioctl with the
LIRC_SET_SEND_DUTY_CYCLE flag. The driver handles duty cycles
of 50%, 60%, 70%, 75%, 80% and 90%, calculated on 16bit data.
The character device is created under /dev/lircX name, where X is
and ID assigned by the LIRC framework.
Example of usage:
fd = open("/dev/lirc0", O_RDWR);
if (fd < 0)
return -1;
val = 608000;
ret = ioctl(fd, LIRC_SET_SEND_CARRIER, &val);
if (ret < 0)
return -1;
val = 60;
ret = ioctl(fd, LIRC_SET_SEND_DUTY_CYCLE, &val);
if (ret < 0)
return -1;
n = write(fd, buffer, BUF_LEN);
if (n < 0 || n != BUF_LEN)
ret = -1;
close(fd);
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Sean Young <sean@mess.org>
---
drivers/media/rc/Kconfig | 9 +++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-spi.c | 199 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 209 insertions(+)
create mode 100644 drivers/media/rc/ir-spi.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca..3351e25 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -261,6 +261,15 @@ config IR_REDRAT3
To compile this driver as a module, choose M here: the
module will be called redrat3.
+config IR_SPI
+ tristate "SPI connected IR LED"
+ depends on SPI && LIRC
+ ---help---
+ Say Y if you want to use an IR LED connected through SPI bus.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ir-spi.
+
config IR_STREAMZAP
tristate "Streamzap PC Remote IR Receiver"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee..938c98b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
obj-$(CONFIG_IR_RX51) += ir-rx51.o
+obj-$(CONFIG_IR_SPI) += ir-spi.o
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
new file mode 100644
index 0000000..d45c603
--- /dev/null
+++ b/drivers/media/rc/ir-spi.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Author: Andi Shyti <andi.shyti@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * SPI driven IR LED device driver
+ */
+
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of_gpio.h>
+#include <linux/regulator/consumer.h>
+#include <linux/spi/spi.h>
+#include <media/rc-core.h>
+
+#define IR_SPI_DRIVER_NAME "ir-spi"
+
+/* pulse value for different duty cycles */
+#define IR_SPI_PULSE_DC_50 0xff00
+#define IR_SPI_PULSE_DC_60 0xfc00
+#define IR_SPI_PULSE_DC_70 0xf800
+#define IR_SPI_PULSE_DC_75 0xf000
+#define IR_SPI_PULSE_DC_80 0xc000
+#define IR_SPI_PULSE_DC_90 0x8000
+
+#define IR_SPI_DEFAULT_FREQUENCY 38000
+#define IR_SPI_BIT_PER_WORD 8
+#define IR_SPI_MAX_BUFSIZE 4096
+
+struct ir_spi_data {
+ u32 freq;
+ u8 duty_cycle;
+ bool negated;
+
+ u16 tx_buf[IR_SPI_MAX_BUFSIZE];
+ u16 pulse;
+ u16 space;
+
+ struct rc_dev *rc;
+ struct spi_device *spi;
+ struct regulator *regulator;
+};
+
+static int ir_spi_tx(struct rc_dev *dev,
+ unsigned int *buffer, unsigned int count)
+{
+ int i;
+ int ret;
+ unsigned int len = 0;
+ struct ir_spi_data *idata = dev->priv;
+ struct spi_transfer xfer;
+
+ /* convert the pulse/space signal to raw binary signal */
+ for (i = 0; i < count; i++) {
+ int j;
+ u16 val = ((i+1) % 2) ? idata->pulse : idata->space;
+
+ if (len + buffer[i] >= IR_SPI_MAX_BUFSIZE)
+ return -EINVAL;
+
+ /*
+ * the first value in buffer is a pulse, so that 0, 2, 4, ...
+ * contain a pulse duration. On the contrary, 1, 3, 5, ...
+ * contain a space duration.
+ */
+ val = (i % 2) ? idata->space : idata->pulse;
+ for (j = 0; j < buffer[i]; j++)
+ idata->tx_buf[len++] = val;
+ }
+
+ memset(&xfer, 0, sizeof(xfer));
+
+ xfer.speed_hz = idata->freq;
+ xfer.len = len * sizeof(*idata->tx_buf);
+ xfer.tx_buf = idata->tx_buf;
+
+ ret = regulator_enable(idata->regulator);
+ if (ret)
+ return ret;
+
+ ret = spi_sync_transfer(idata->spi, &xfer, 1);
+ if (ret)
+ dev_err(&idata->spi->dev, "unable to deliver the signal\n");
+
+ regulator_disable(idata->regulator);
+
+ return ret ? ret : count;
+}
+
+static int ir_spi_set_tx_carrier(struct rc_dev *dev, u32 carrier)
+{
+ struct ir_spi_data *idata = dev->priv;
+
+ if (!carrier)
+ return -EINVAL;
+
+ idata->freq = carrier;
+
+ return 0;
+}
+
+static int ir_spi_set_duty_cycle(struct rc_dev *dev, u32 duty_cycle)
+{
+ struct ir_spi_data *idata = dev->priv;
+
+ if (duty_cycle >= 90)
+ idata->pulse = IR_SPI_PULSE_DC_90;
+ else if (duty_cycle >= 80)
+ idata->pulse = IR_SPI_PULSE_DC_80;
+ else if (duty_cycle >= 75)
+ idata->pulse = IR_SPI_PULSE_DC_75;
+ else if (duty_cycle >= 70)
+ idata->pulse = IR_SPI_PULSE_DC_70;
+ else if (duty_cycle >= 60)
+ idata->pulse = IR_SPI_PULSE_DC_60;
+ else
+ idata->pulse = IR_SPI_PULSE_DC_50;
+
+ if (idata->negated) {
+ idata->pulse = ~idata->pulse;
+ idata->space = 0xffff;
+ } else {
+ idata->space = 0;
+ }
+
+ return 0;
+}
+
+static int ir_spi_probe(struct spi_device *spi)
+{
+ int ret;
+ u8 dc;
+ struct ir_spi_data *idata;
+
+ idata = devm_kzalloc(&spi->dev, sizeof(*idata), GFP_KERNEL);
+ if (!idata)
+ return -ENOMEM;
+
+ idata->regulator = devm_regulator_get(&spi->dev, "irda_regulator");
+ if (IS_ERR(idata->regulator))
+ return PTR_ERR(idata->regulator);
+
+ idata->rc = devm_rc_allocate_device(&spi->dev, RC_DRIVER_IR_RAW_TX);
+ if (!idata->rc)
+ return -ENOMEM;
+
+ idata->rc->tx_ir = ir_spi_tx;
+ idata->rc->s_tx_carrier = ir_spi_set_tx_carrier;
+ idata->rc->s_tx_duty_cycle = ir_spi_set_duty_cycle;
+ idata->rc->driver_name = IR_SPI_DRIVER_NAME;
+ idata->rc->priv = idata;
+ idata->spi = spi;
+
+ idata->negated = of_property_read_bool(spi->dev.of_node,
+ "led-active-low");
+ ret = of_property_read_u8(spi->dev.of_node, "duty-cycle", &dc);
+ if (ret)
+ dc = 50;
+
+ /* ir_spi_set_duty_cycle cannot fail,
+ * it returns int to be compatible with the
+ * rc->s_tx_duty_cycle function
+ */
+ ir_spi_set_duty_cycle(idata->rc, dc);
+
+ idata->freq = IR_SPI_DEFAULT_FREQUENCY;
+
+ return devm_rc_register_device(&spi->dev, idata->rc);
+}
+
+static int ir_spi_remove(struct spi_device *spi)
+{
+ return 0;
+}
+
+static const struct of_device_id ir_spi_of_match[] = {
+ { .compatible = "ir-spi-led" },
+ {},
+};
+
+static struct spi_driver ir_spi_driver = {
+ .probe = ir_spi_probe,
+ .remove = ir_spi_remove,
+ .driver = {
+ .name = IR_SPI_DRIVER_NAME,
+ .of_match_table = ir_spi_of_match,
+ },
+};
+
+module_spi_driver(ir_spi_driver);
+
+MODULE_AUTHOR("Andi Shyti <andi.shyti@samsung.com>");
+MODULE_DESCRIPTION("SPI IR LED");
+MODULE_LICENSE("GPL v2");
--
2.10.2
^ 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