* Re: [PATCH v2 04/19] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
From: Steve Longerbeam @ 2017-01-05 19:20 UTC (permalink / raw)
To: Vladimir Zapolskiy, shawnguo, kernel, fabio.estevam, robh+dt,
mark.rutland, linux, mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <0a343705-1d38-9fe2-6419-56ab9bdfb0c2@mentor.com>
Hi Vladimir,
On 01/04/2017 04:25 AM, Vladimir Zapolskiy wrote:
> Hi Steve,
>
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
>> Both hang off the same i2c2 bus, so they require different (and non-
>> default) i2c slave addresses.
>>
>> The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
>>
>> The OV5640 connects to the input port on the MIPI CSI-2 receiver on
>> mipi_csi. It is set to transmit over MIPI virtual channel 1.
>>
>> Note there is a pin conflict with GPIO6. This pin functions as a power
>> input pin to the OV5642, but ENET uses it as the h/w workaround for
>> erratum ERR006687, to wake-up the ARM cores on normal RX and TX packet
>> done events (see 6261c4c8). So workaround 6261c4c8 is reverted here to
>> support the OV5642, and the "fsl,err006687-workaround-present" boolean
>> also must be removed. The result is that the CPUidle driver will no longer
>> allow entering the deep idle states on the sabrelite.
> For me it sounds like a candidate of its own separate change.
Yes, I split out the two partial reverts into a separate commit
("ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687
workaround").
>
>
>
>> +
>> + mipi_camera: ov5640@40 {
> Please reorder device nodes by address value,
done.
> also according to ePAPR
> node names should be generic, labels can be specific:
>
> ov5640: camera@40 {
> ...
> };
>
> ov5642: camera@42 {
> ...
> };
fixed.
>
>> + pinctrl_ipu1_csi0: ipu1grp-csi0 {
> Please rename node name to ipu1csi0grp.
done.
>
>> +
>> + pinctrl_ov5640: ov5640grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x000b0
>> + MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x0b0b0
>> + >;
>> + };
>> +
> Indentation issues above, please use tabs instead of spaces.
fixed.
>
> Also please add new pin control groups preserving the alphanimerical order.
done.
Steve
^ permalink raw reply
* [PATCH] ARM: dts: Fix compatible for ti81xx uarts for 8250
From: Tony Lindgren @ 2017-01-05 19:17 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA
When using 8250_omap driver, we need to specify the right
compatible value for the UART to work on dm814x and dm816x.
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/dm814x.dtsi | 6 +++---
arch/arm/boot/dts/dm816x.dtsi | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -252,7 +252,7 @@
};
uart1: uart@20000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart1";
reg = <0x20000 0x2000>;
clock-frequency = <48000000>;
@@ -262,7 +262,7 @@
};
uart2: uart@22000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart2";
reg = <0x22000 0x2000>;
clock-frequency = <48000000>;
@@ -272,7 +272,7 @@
};
uart3: uart@24000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart3";
reg = <0x24000 0x2000>;
clock-frequency = <48000000>;
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -373,7 +373,7 @@
};
uart1: uart@48020000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart1";
reg = <0x48020000 0x2000>;
clock-frequency = <48000000>;
@@ -383,7 +383,7 @@
};
uart2: uart@48022000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart2";
reg = <0x48022000 0x2000>;
clock-frequency = <48000000>;
@@ -393,7 +393,7 @@
};
uart3: uart@48024000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart3";
reg = <0x48024000 0x2000>;
clock-frequency = <48000000>;
--
2.11.0
--
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
* [PATCH] ARM: dts: Fix am335x and dm814x scm syscon to probe children
From: Tony Lindgren @ 2017-01-05 19:10 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA
Without these changes children of the scn syscon
won't probe.
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/am33xx.dtsi | 3 ++-
arch/arm/boot/dts/dm814x.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -145,10 +145,11 @@
};
scm_conf: scm_conf@0 {
- compatible = "syscon";
+ compatible = "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0 0x800>;
scm_clocks: clocks {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -332,10 +332,11 @@
ranges = <0 0x140000 0x20000>;
scm_conf: scm_conf@0 {
- compatible = "syscon";
+ compatible = "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0 0x800>;
scm_clocks: clocks {
#address-cells = <1>;
--
2.11.0
--
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
* [PATCH] ARM: dts: Fix omap3 off mode pull defines
From: Tony Lindgren @ 2017-01-05 19:07 UTC (permalink / raw)
To: Tony Lindgren
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
We need to also have OFFPULLUDENABLE bit set to use the off mode pull values.
Otherwise the line is pulled down internally if no external pull exists.
This is has some documentation at:
http://processors.wiki.ti.com/index.php/Optimizing_OMAP35x_and_AM/DM37x_OFF_mode_PAD_configuration
Note that the value is still glitchy during off mode transitions as documented
in spz319f.pdf "Advisory 1.45". It's best to use external pulls instead of
relying on the internal ones for off mode and even then anything pulled up
will get driven down momentarily on off mode restore for GPIO banks other
than bank1.
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
include/dt-bindings/pinctrl/omap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/dt-bindings/pinctrl/omap.h b/include/dt-bindings/pinctrl/omap.h
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -45,8 +45,8 @@
#define PIN_OFF_NONE 0
#define PIN_OFF_OUTPUT_HIGH (OFF_EN | OFFOUT_EN | OFFOUT_VAL)
#define PIN_OFF_OUTPUT_LOW (OFF_EN | OFFOUT_EN)
-#define PIN_OFF_INPUT_PULLUP (OFF_EN | OFF_PULL_EN | OFF_PULL_UP)
-#define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFF_PULL_EN)
+#define PIN_OFF_INPUT_PULLUP (OFF_EN | OFFOUT_EN | OFF_PULL_EN | OFF_PULL_UP)
+#define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFFOUT_EN | OFF_PULL_EN)
#define PIN_OFF_WAKEUPENABLE WAKEUP_EN
/*
--
2.11.0
--
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] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
From: Michał Zegan @ 2017-01-05 19:04 UTC (permalink / raw)
To: Neil Armstrong, khilman, carlo
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1483628549-29486-1-git-send-email-narmstrong@baylibre.com>
[-- Attachment #1.1: Type: text/plain, Size: 2155 bytes --]
Hello.
The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
it actually works, but...
Loading the module causes few errors because of not found frequencies or
something, then it is all okay. However after loading scpi-cpufreq you
cannot actually power the cpu off and on. You will power it off
successfully, but when trying to power it on, the cpufreq driver will
error out, and then after it happens, the cpu that was trying to go
online will be offline again, and that is a little... unfortunate. The
question is, and I cannot really test that: will the module actually
autoload after this change?
W dniu 05.01.2017 o 16:02, Neil Armstrong pisze:
> The current hardware is not able to run with all cores enabled at a
> cluster frequency superior at 1536MHz.
> But the currently shipped u-boot for the platform still reports an OPP
> table with possible DVFS frequency up to 2GHz, and will not change since
> the off-tree linux tree supports limiting the OPPs with a kernel parameter.
> A recent u-boot change reports the boot-time DVFS around 100MHz and
> the default performance cpufreq governor sets the maximum frequency.
> Previous version of u-boot reported to be already at the max OPP and
> left the OPP as is.
> Nevertheless, other governors like ondemand could setup the max frequency
> and make the system crash.
>
> This patch disables the DVFS clock and disables cpufreq.
>
> Fixes: 70db166a2baa ("ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbea..5e63e3b 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -137,6 +137,10 @@
> };
> };
>
> +&scpi_dvfs {
> + status = "disabled";
> +};
> +
> &uart_AO {
> status = "okay";
> pinctrl-0 = <&uart_ao_a_pins>;
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 525 bytes --]
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: keystone: Add "ti,da830-uart" compatible string
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1483642460-6891-1-git-send-email-david@lechnology.com>
The TI Keystone SoCs have extra UART registers beyond the standard 8250
registers, so we need a new compatible string to indicate this. Also, at
least one of these registers uses the full 32 bits, so we need to specify
reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work as
long as the bootloader configures the SoC UART power management registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v3 changes:
* None
v2 changes:
* This is a new patch in v2
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 63c7cf0c..7d7b9a8 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -90,7 +90,7 @@
};
uart0: serial@02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index 0c5e74e..e91633f 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -35,7 +35,7 @@
/include/ "keystone-k2l-clocks.dtsi"
uart2: serial@02348400 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -45,7 +45,7 @@
};
uart3: serial@02348800 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba..9152610 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -98,7 +98,7 @@
/include/ "keystone-clocks.dtsi"
uart0: serial@02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -108,7 +108,7 @@
};
uart1: serial@02531000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/4] ARM: da850: Add ti,da830-uart compatible for serial ports
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1483642460-6891-1-git-send-email-david@lechnology.com>
TI DA8xx/OMAPL13x/AM17xx/AM18xx SoCs have extra UART registers beyond
the standard 8250 registers, so we need a new compatible string to
indicate this. Also, at least one of these registers uses the full 32
bits, so we need to specify reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work
as long as the bootloader configures the SoC UART power management
registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v3 changes:
* None
v2 changes:
* None
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..f6cd212 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -266,22 +266,25 @@
interrupt-names = "edm3_tcerrint";
};
serial0: serial@42000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x42000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <25>;
status = "disabled";
};
serial1: serial@10c000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10c000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <53>;
status = "disabled";
};
serial2: serial@10d000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10d000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <61>;
status = "disabled";
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/4] serial: 8250: Add new port type for TI DA8xx/66AK2x
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1483642460-6891-1-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x.
These SoCs have standard 8250 registers plus some extra non-standard
registers.
The UART will not function unless the non-standard Power and Emulation
Management Register (PWREMU_MGMT) is configured correctly. This is
currently handled in arch/arm/mach-davinci/serial.c for non-device-tree
boards. Making this part of the UART driver will allow UART to work on
device-tree boards as well and the mach code can eventually be removed.
Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
Acked-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
---
v3 changes:
* Changed list of SoCs to "DA8xx/66AK2x"
v2 changes:
* Added C66x to list of SoCs
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index d25ab1c..5281252 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -332,6 +332,7 @@ static const struct of_device_id of_platform_serial_table[] = {
.data = (void *)PORT_ALTR_16550_F128, },
{ .compatible = "mrvl,mmp-uart",
.data = (void *)PORT_XSCALE, },
+ { .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
{ /* end of list */ },
};
MODULE_DEVICE_TABLE(of, of_platform_serial_table);
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index fe4399b..3f0c994 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -273,6 +273,15 @@ static const struct serial8250_config uart_config[] = {
.rxtrig_bytes = {1, 4, 8, 14},
.flags = UART_CAP_FIFO,
},
+ [PORT_DA830] = {
+ .name = "TI DA8xx/66AK2x",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO |
+ UART_FCR_R_TRIG_10,
+ .rxtrig_bytes = {1, 4, 8, 14},
+ .flags = UART_CAP_FIFO | UART_CAP_AFE,
+ },
};
/* Uart divisor latch read */
@@ -2118,6 +2127,19 @@ int serial8250_do_startup(struct uart_port *port)
serial_port_out(port, UART_LCR, 0);
}
+ if (port->type == PORT_DA830) {
+ /* Reset the port */
+ serial_port_out(port, UART_IER, 0);
+ serial_port_out(port, UART_DA830_PWREMU_MGMT, 0);
+ mdelay(10);
+
+ /* Enable Tx, Rx and free run mode */
+ serial_port_out(port, UART_DA830_PWREMU_MGMT,
+ UART_DA830_PWREMU_MGMT_UTRST |
+ UART_DA830_PWREMU_MGMT_URRST |
+ UART_DA830_PWREMU_MGMT_FREE);
+ }
+
#ifdef CONFIG_SERIAL_8250_RSA
/*
* If this is an RSA port, see if we can kick it up to the
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 99dbed8..9ec741b 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -56,7 +56,8 @@
#define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
#define PORT_RT2880 29 /* Ralink RT2880 internal UART */
#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
-#define PORT_MAX_8250 30 /* max port ID */
+#define PORT_DA830 31 /* TI DA8xx/66AK2x */
+#define PORT_MAX_8250 31 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index b4c0484..274d8fc 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -327,6 +327,14 @@
#define SERIAL_RSA_BAUD_BASE (921600)
#define SERIAL_RSA_BAUD_BASE_LO (SERIAL_RSA_BAUD_BASE / 8)
+/* Extra registers for TI DA8xx/66AK2x */
+#define UART_DA830_PWREMU_MGMT 12
+
+/* PWREMU_MGMT register bits */
+#define UART_DA830_PWREMU_MGMT_FREE (1 << 0) /* Free-running mode */
+#define UART_DA830_PWREMU_MGMT_URRST (1 << 13) /* Receiver reset/enable */
+#define UART_DA830_PWREMU_MGMT_UTRST (1 << 14) /* Transmitter reset/enable */
+
/*
* Extra serial register definitions for the internal UARTs
* in TI OMAP processors.
--
2.7.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/4] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1483642460-6891-1-git-send-email-david@lechnology.com>
This adds the ti,da830-uart compatible string to serial 8250 UART bindings.
Signed-off-by: David Lechner <david@lechnology.com>
Acked-by: Rob Herring <robh@kernel.org>
---
v3 changes:
* None
v2 changes:
* picked up Acked-by:
Documentation/devicetree/bindings/serial/8250.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index f86bb06..10276a4 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -19,6 +19,7 @@ Required properties:
- "altr,16550-FIFO128"
- "fsl,16550-FIFO64"
- "fsl,ns16550"
+ - "ti,da830-uart"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/4] TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x UART
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
This series adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x
UART. These SoCs have a non-standard register for UART power management that
needs special handling in the UART driver.
Greg, the first two patches will need to go through your tree. Sekhar and
Santosh will pick up the 3 and 4 patches respectively.
v3 changes:
* Shortened list of SoCs to "DA8xx/66AK2x"
v2 changes:
* Added references to C66x SoC in various places, which I assume is an OK
shorthand for TI Keystone processors.
* New patch for Keystone device tree. This is untested as I don't have any
Keystone boards.
David Lechner (4):
doc: DT: Add ti,da830-uart to serial/8250 bindings
serial: 8250: Add new port type for TI DA8xx/66AK2x
ARM: da850: Add ti,da830-uart compatible for serial ports
ARM: dts: keystone: Add "ti,da830-uart" compatible string
Documentation/devicetree/bindings/serial/8250.txt | 1 +
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
9 files changed, 45 insertions(+), 9 deletions(-)
--
2.7.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
* [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
From: Tony Lindgren @ 2017-01-05 18:54 UTC (permalink / raw)
To: Linus Walleij
Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Nishanth Menon,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Lokesh Vutla
In-Reply-To: <20170105185414.27247-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
From: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
SoC family such as DRA7 family of processors have, in addition
to the regular muxing of pins (as done by pinctrl-single), a separate
hardware module called IODelay which is also expected to be configured.
The "IODelay" module has it's own register space that is independent
of the control module and the padconf register area.
With recent changes to the pinctrl framework, we can now support
this hardware with a reasonably minimal driver by using #pinctrl-cells,
GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUNCTIONS.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors during mux or
IODelay reconfiguration, there is a potential for a significant glitch
which may cause functional impairment to certain hardware. It is
hence recommended to do as little of muxing as absolutely necessary
without I/O isolation (which can only be done in initial stages of
bootloader).
NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
family, it is not reasonable to do stop all I/O operations for every
such pad configuration scheme. So, we will let it glitch when used in
this mode.
Even with the above limitation, certain functionality such as MMC has
mandatory need for IODelay reconfiguration requirements, depending on
speed of transfer. In these cases, with careful examination of usecase
involved, the expected glitch can be controlled such that it does not
impact functionality.
In short, IODelay module support as a padconf driver being introduced
here is not expected to do SoC wide I/O Isolation and is meant for
a limited subset of IODelay configuration requirements that need to
be dynamic and whose glitchy behavior will not cause functionality
failure for that interface.
IMPORTANT NOTE: we take the approach of keeping LOCK_BITs cleared
to 0x0 at all times, even when configuring Manual IO Timing Modes.
This is done by eliminating the LOCK_BIT=1 setting from Step
of the Manual IO timing Mode configuration procedure. This option
leaves the CFG_* registers unprotected from unintended writes to the
CTRL_CORE_PAD_* registers while Manual IO Timing Modes are configured.
This approach is taken to allow for a generic driver to exist in kernel
world that has to be used carefully in required usecases.
Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
[tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org: updated to use generic pinctrl functions, added
binding documentation, updated comments]
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
.../devicetree/bindings/pinctrl/ti,iodelay.txt | 47 +
drivers/pinctrl/Kconfig | 1 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/ti/Kconfig | 10 +
drivers/pinctrl/ti/Makefile | 1 +
drivers/pinctrl/ti/pinctrl-ti-iodelay.c | 944 +++++++++++++++++++++
6 files changed, 1004 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/ti,iodelay.txt
create mode 100644 drivers/pinctrl/ti/Kconfig
create mode 100644 drivers/pinctrl/ti/Makefile
create mode 100644 drivers/pinctrl/ti/pinctrl-ti-iodelay.c
diff --git a/Documentation/devicetree/bindings/pinctrl/ti,iodelay.txt b/Documentation/devicetree/bindings/pinctrl/ti,iodelay.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ti,iodelay.txt
@@ -0,0 +1,47 @@
+* Pin configuration for TI IODELAY controller
+
+TI dra7 based SoCs such as am57xx have a controller for setting the IO delay
+for each pin. For most part the IO delay values are programmed by the bootloader,
+but some pins need to be configured dynamically by the kernel such as the
+MMC pins.
+
+Required Properties:
+
+ - compatible: Must be "ti,dra7-iodelay"
+ - reg: Base address and length of the memory resource used
+ - #address-cells: Number of address cells
+ - #size-cells: Size of cells
+ - #pinctrl-cells: Number of pinctrl cells, must be 2. See also
+ Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+Example
+-------
+
+In the SoC specific dtsi file:
+
+ dra7_iodelay_core: padconf@4844a000 {
+ compatible = "ti,dra7-iodelay";
+ reg = <0x4844a000 0x0d1c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #pinctrl-cells = <2>;
+ };
+
+In board-specific file:
+
+&dra7_iodelay_core {
+ mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
+ pinctrl-pin-array = <
+ 0x18c A_DELAY_PS(0) G_DELAY_PS(120) /* CFG_GPMC_A19_IN */
+ 0x1a4 A_DELAY_PS(265) G_DELAY_PS(360) /* CFG_GPMC_A20_IN */
+ 0x1b0 A_DELAY_PS(0) G_DELAY_PS(120) /* CFG_GPMC_A21_IN */
+ 0x1bc A_DELAY_PS(0) G_DELAY_PS(120) /* CFG_GPMC_A22_IN */
+ 0x1c8 A_DELAY_PS(287) G_DELAY_PS(420) /* CFG_GPMC_A23_IN */
+ 0x1d4 A_DELAY_PS(144) G_DELAY_PS(240) /* CFG_GPMC_A24_IN */
+ 0x1e0 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_GPMC_A25_IN */
+ 0x1ec A_DELAY_PS(120) G_DELAY_PS(0) /* CFG_GPMC_A26_IN */
+ 0x1f8 A_DELAY_PS(120) G_DELAY_PS(180) /* CFG_GPMC_A27_IN */
+ 0x360 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_GPMC_CS1_IN */
+ >;
+ };
+};
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -300,6 +300,7 @@ source "drivers/pinctrl/spear/Kconfig"
source "drivers/pinctrl/stm32/Kconfig"
source "drivers/pinctrl/sunxi/Kconfig"
source "drivers/pinctrl/tegra/Kconfig"
+source "drivers/pinctrl/ti/Kconfig"
source "drivers/pinctrl/uniphier/Kconfig"
source "drivers/pinctrl/vt8500/Kconfig"
source "drivers/pinctrl/mediatek/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_PINCTRL_SH_PFC) += sh-pfc/
obj-$(CONFIG_PINCTRL_SPEAR) += spear/
obj-$(CONFIG_PINCTRL_STM32) += stm32/
obj-$(CONFIG_PINCTRL_SUNXI) += sunxi/
+obj-y += ti/
obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/
obj-$(CONFIG_ARCH_VT8500) += vt8500/
obj-$(CONFIG_PINCTRL_MTK) += mediatek/
diff --git a/drivers/pinctrl/ti/Kconfig b/drivers/pinctrl/ti/Kconfig
new file mode 100644
--- /dev/null
+++ b/drivers/pinctrl/ti/Kconfig
@@ -0,0 +1,10 @@
+config PINCTRL_TI_IODELAY
+ tristate "TI IODelay Module pinconf driver"
+ depends on OF
+ select GENERIC_PINCTRL_GROUPS
+ select GENERIC_PINMUX_FUNCTIONS
+ select GENERIC_PINCONF
+ select REGMAP_MMIO
+ help
+ Say Y here to support Texas Instruments' IO delay pinconf driver.
+ IO delay module is used for the DRA7 SoC family.
diff --git a/drivers/pinctrl/ti/Makefile b/drivers/pinctrl/ti/Makefile
new file mode 100644
--- /dev/null
+++ b/drivers/pinctrl/ti/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PINCTRL_TI_IODELAY) += pinctrl-ti-iodelay.o
diff --git a/drivers/pinctrl/ti/pinctrl-ti-iodelay.c b/drivers/pinctrl/ti/pinctrl-ti-iodelay.c
new file mode 100644
--- /dev/null
+++ b/drivers/pinctrl/ti/pinctrl-ti-iodelay.c
@@ -0,0 +1,944 @@
+/*
+ * Support for configuration of IO Delay module found on Texas Instruments SoCs
+ * such as DRA7
+ *
+ * Copyright (C) 2015-2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#include "../core.h"
+#include "../devicetree.h"
+
+#define DRIVER_NAME "ti-iodelay"
+
+/**
+ * struct ti_iodelay_reg_data - Describes the registers for the iodelay instance
+ * @signature_mask: CONFIG_REG mask for the signature bits (see TRM)
+ * @signature_value: CONFIG_REG signature value to be written (see TRM)
+ * @lock_mask: CONFIG_REG mask for the lock bits (see TRM)
+ * @lock_val: CONFIG_REG lock value for the lock bits (see TRM)
+ * @unlock_val:CONFIG_REG unlock value for the lock bits (see TRM)
+ * @binary_data_coarse_mask: CONFIG_REG coarse mask (see TRM)
+ * @binary_data_fine_mask: CONFIG_REG fine mask (see TRM)
+ * @reg_refclk_offset: Refclk register offset
+ * @refclk_period_mask: Refclk mask
+ * @reg_coarse_offset: Coarse register configuration offset
+ * @coarse_delay_count_mask: Coarse delay count mask
+ * @coarse_ref_count_mask: Coarse ref count mask
+ * @reg_fine_offset: Fine register configuration offset
+ * @fine_delay_count_mask: Fine delay count mask
+ * @fine_ref_count_mask: Fine ref count mask
+ * @reg_global_lock_offset: Global iodelay module lock register offset
+ * @global_lock_mask: Lock mask
+ * @global_unlock_val: Unlock value
+ * @global_lock_val: Lock value
+ * @reg_start_offset: Offset to iodelay registers after the CONFIG_REG_0 to 8
+ * @reg_nr_per_pin: Number of iodelay registers for each pin
+ * @regmap_config: Regmap configuration for the IODelay region
+ */
+struct ti_iodelay_reg_data {
+ u32 signature_mask;
+ u32 signature_value;
+ u32 lock_mask;
+ u32 lock_val;
+ u32 unlock_val;
+ u32 binary_data_coarse_mask;
+ u32 binary_data_fine_mask;
+
+ u32 reg_refclk_offset;
+ u32 refclk_period_mask;
+
+ u32 reg_coarse_offset;
+ u32 coarse_delay_count_mask;
+ u32 coarse_ref_count_mask;
+
+ u32 reg_fine_offset;
+ u32 fine_delay_count_mask;
+ u32 fine_ref_count_mask;
+
+ u32 reg_global_lock_offset;
+ u32 global_lock_mask;
+ u32 global_unlock_val;
+ u32 global_lock_val;
+
+ u32 reg_start_offset;
+ u32 reg_nr_per_pin;
+
+ struct regmap_config *regmap_config;
+};
+
+/**
+ * struct ti_iodelay_reg_values - Computed io_reg configuration values (see TRM)
+ * @coarse_ref_count: Coarse reference count
+ * @coarse_delay_count: Coarse delay count
+ * @fine_ref_count: Fine reference count
+ * @fine_delay_count: Fine Delay count
+ * @ref_clk_period: Reference Clock period
+ * @cdpe: Coarse delay parameter
+ * @fdpe: Fine delay parameter
+ */
+struct ti_iodelay_reg_values {
+ u16 coarse_ref_count;
+ u16 coarse_delay_count;
+
+ u16 fine_ref_count;
+ u16 fine_delay_count;
+
+ u16 ref_clk_period;
+
+ u32 cdpe;
+ u32 fdpe;
+};
+
+/**
+ * struct ti_iodelay_cfg - Description of each configuration parameters
+ * @offset: Configuration register offset
+ * @a_delay: Agnostic Delay (in ps)
+ * @g_delay: Gnostic Delay (in ps)
+ */
+struct ti_iodelay_cfg {
+ u16 offset;
+ u16 a_delay;
+ u16 g_delay;
+};
+
+/**
+ * struct ti_iodelay_pingroup - Structure that describes one group
+ * @cfg: configuration array for the pin (from dt)
+ * @ncfg: number of configuration values allocated
+ * @config: pinconf "Config" - currently a dummy value
+ */
+struct ti_iodelay_pingroup {
+ struct ti_iodelay_cfg *cfg;
+ int ncfg;
+ unsigned long config;
+};
+
+/**
+ * struct ti_iodelay_device - Represents information for a iodelay instance
+ * @dev: Device pointer
+ * @phys_base: Physical address base of the iodelay device
+ * @reg_base: Virtual address base of the iodelay device
+ * @regmap: Regmap for this iodelay instance
+ * @pctl: Pinctrl device
+ * @desc: pinctrl descriptor for pctl
+ * @pa: pinctrl pin wise description
+ * @reg_data: Register definition data for the IODelay instance
+ * @reg_init_conf_values: Initial configuration values.
+ */
+struct ti_iodelay_device {
+ struct device *dev;
+ unsigned long phys_base;
+ void __iomem *reg_base;
+ struct regmap *regmap;
+
+ struct pinctrl_dev *pctl;
+ struct pinctrl_desc desc;
+ struct pinctrl_pin_desc *pa;
+
+ const struct ti_iodelay_reg_data *reg_data;
+ struct ti_iodelay_reg_values reg_init_conf_values;
+};
+
+/**
+ * ti_iodelay_extract() - extract bits for a field
+ * @val: Register value
+ * @mask: Mask
+ *
+ * Return: extracted value which is appropriately shifted
+ */
+static inline u32 ti_iodelay_extract(u32 val, u32 mask)
+{
+ return (val & mask) >> __ffs(mask);
+}
+
+/**
+ * ti_iodelay_compute_dpe() - Compute equation for delay parameter
+ * @period: Period to use
+ * @ref: Reference Count
+ * @delay: Delay count
+ * @delay_m: Delay multiplier
+ *
+ * Return: Computed delay parameter
+ */
+static inline u32 ti_iodelay_compute_dpe(u16 period, u16 ref, u16 delay,
+ u16 delay_m)
+{
+ u64 m, d;
+
+ /* Handle overflow conditions */
+ m = 10 * (u64)period * (u64)ref;
+ d = 2 * (u64)delay * (u64)delay_m;
+
+ /* Truncate result back to 32 bits */
+ return div64_u64(m, d);
+}
+
+/**
+ * ti_iodelay_pinconf_set() - Configure the pin configuration
+ * @iod: iodelay device
+ * @cfg: Configuration
+ *
+ * Update the configuration register as per TRM and lockup once done.
+ * *IMPORTANT NOTE* SoC TRM does recommend doing iodelay programmation only
+ * while in Isolation. But, then, isolation also implies that every pin
+ * on the SoC (including DDR) will be isolated out. The only benefit being
+ * a glitchless configuration, However, the intent of this driver is purely
+ * to support a "glitchy" configuration where applicable.
+ *
+ * Return: 0 in case of success, else appropriate error value
+ */
+static int ti_iodelay_pinconf_set(struct ti_iodelay_device *iod,
+ struct ti_iodelay_cfg *cfg)
+{
+ const struct ti_iodelay_reg_data *reg = iod->reg_data;
+ struct ti_iodelay_reg_values *ival = &iod->reg_init_conf_values;
+ struct device *dev = iod->dev;
+ u32 g_delay_coarse, g_delay_fine;
+ u32 a_delay_coarse, a_delay_fine;
+ u32 c_elements, f_elements;
+ u32 total_delay;
+ u32 reg_mask, reg_val, tmp_val;
+ int r;
+
+ /* NOTE: Truncation is expected in all division below */
+ g_delay_coarse = cfg->g_delay / 920;
+ g_delay_fine = ((cfg->g_delay % 920) * 10) / 60;
+
+ a_delay_coarse = cfg->a_delay / ival->cdpe;
+ a_delay_fine = ((cfg->a_delay % ival->cdpe) * 10) / ival->fdpe;
+
+ c_elements = g_delay_coarse + a_delay_coarse;
+ f_elements = (g_delay_fine + a_delay_fine) / 10;
+
+ if (f_elements > 22) {
+ total_delay = c_elements * ival->cdpe + f_elements * ival->fdpe;
+ c_elements = total_delay / ival->cdpe;
+ f_elements = (total_delay % ival->cdpe) / ival->fdpe;
+ }
+
+ reg_mask = reg->signature_mask;
+ reg_val = reg->signature_value << __ffs(reg->signature_mask);
+
+ reg_mask |= reg->binary_data_coarse_mask;
+ tmp_val = c_elements << __ffs(reg->binary_data_coarse_mask);
+ if (tmp_val & ~reg->binary_data_coarse_mask) {
+ dev_err(dev, "Masking overflow of coarse elements %08x\n",
+ tmp_val);
+ tmp_val &= reg->binary_data_coarse_mask;
+ }
+ reg_val |= tmp_val;
+
+ reg_mask |= reg->binary_data_fine_mask;
+ tmp_val = f_elements << __ffs(reg->binary_data_fine_mask);
+ if (tmp_val & ~reg->binary_data_fine_mask) {
+ dev_err(dev, "Masking overflow of fine elements %08x\n",
+ tmp_val);
+ tmp_val &= reg->binary_data_fine_mask;
+ }
+ reg_val |= tmp_val;
+
+ /*
+ * NOTE: we leave the iodelay values unlocked - this is to work around
+ * situations such as those found with mmc mode change.
+ * However, this leaves open any unwarranted changes to padconf register
+ * impacting iodelay configuration. Use with care!
+ */
+ reg_mask |= reg->lock_mask;
+ reg_val |= reg->unlock_val << __ffs(reg->lock_mask);
+ r = regmap_update_bits(iod->regmap, cfg->offset, reg_mask, reg_val);
+
+ dev_info(dev, "Set reg 0x%x Delay(a: %d g: %d), Elements(C=%d F=%d)0x%x\n",
+ cfg->offset, cfg->a_delay, cfg->g_delay, c_elements,
+ f_elements, reg_val);
+
+ return r;
+}
+
+/**
+ * ti_iodelay_pinconf_init_dev() - Initialize IODelay device
+ * @iod: iodelay device
+ *
+ * Unlocks the iodelay region, computes the common parameters
+ *
+ * Return: 0 in case of success, else appropriate error value
+ */
+static int ti_iodelay_pinconf_init_dev(struct ti_iodelay_device *iod)
+{
+ const struct ti_iodelay_reg_data *reg = iod->reg_data;
+ struct device *dev = iod->dev;
+ struct ti_iodelay_reg_values *ival = &iod->reg_init_conf_values;
+ u32 val;
+ int r;
+
+ /* unlock the iodelay region */
+ r = regmap_update_bits(iod->regmap, reg->reg_global_lock_offset,
+ reg->global_lock_mask, reg->global_unlock_val);
+ if (r)
+ return r;
+
+ /* Read up Recalibration sequence done by bootloader */
+ r = regmap_read(iod->regmap, reg->reg_refclk_offset, &val);
+ if (r)
+ return r;
+ ival->ref_clk_period = ti_iodelay_extract(val, reg->refclk_period_mask);
+ dev_dbg(dev, "refclk_period=0x%04x\n", ival->ref_clk_period);
+
+ r = regmap_read(iod->regmap, reg->reg_coarse_offset, &val);
+ if (r)
+ return r;
+ ival->coarse_ref_count =
+ ti_iodelay_extract(val, reg->coarse_ref_count_mask);
+ ival->coarse_delay_count =
+ ti_iodelay_extract(val, reg->coarse_delay_count_mask);
+ if (!ival->coarse_delay_count) {
+ dev_err(dev, "Invalid Coarse delay count (0) (reg=0x%08x)\n",
+ val);
+ return -EINVAL;
+ }
+ ival->cdpe = ti_iodelay_compute_dpe(ival->ref_clk_period,
+ ival->coarse_ref_count,
+ ival->coarse_delay_count, 88);
+ if (!ival->cdpe) {
+ dev_err(dev, "Invalid cdpe computed params = %d %d %d\n",
+ ival->ref_clk_period, ival->coarse_ref_count,
+ ival->coarse_delay_count);
+ return -EINVAL;
+ }
+ dev_dbg(iod->dev, "coarse: ref=0x%04x delay=0x%04x cdpe=0x%08x\n",
+ ival->coarse_ref_count, ival->coarse_delay_count, ival->cdpe);
+
+ r = regmap_read(iod->regmap, reg->reg_fine_offset, &val);
+ if (r)
+ return r;
+ ival->fine_ref_count =
+ ti_iodelay_extract(val, reg->fine_ref_count_mask);
+ ival->fine_delay_count =
+ ti_iodelay_extract(val, reg->fine_delay_count_mask);
+ if (!ival->fine_delay_count) {
+ dev_err(dev, "Invalid Fine delay count (0) (reg=0x%08x)\n",
+ val);
+ return -EINVAL;
+ }
+ ival->fdpe = ti_iodelay_compute_dpe(ival->ref_clk_period,
+ ival->fine_ref_count,
+ ival->fine_delay_count, 264);
+ if (!ival->fdpe) {
+ dev_err(dev, "Invalid fdpe(0) computed params = %d %d %d\n",
+ ival->ref_clk_period, ival->fine_ref_count,
+ ival->fine_delay_count);
+ return -EINVAL;
+ }
+ dev_dbg(iod->dev, "fine: ref=0x%04x delay=0x%04x fdpe=0x%08x\n",
+ ival->fine_ref_count, ival->fine_delay_count, ival->fdpe);
+
+ return 0;
+}
+
+/**
+ * ti_iodelay_pinconf_deinit_dev() - deinit the iodelay device
+ * @iod: IODelay device
+ *
+ * Deinitialize the IODelay device (basically just lock the region back up.
+ */
+static void ti_iodelay_pinconf_deinit_dev(struct ti_iodelay_device *iod)
+{
+ const struct ti_iodelay_reg_data *reg = iod->reg_data;
+
+ /* lock the iodelay region back again */
+ regmap_update_bits(iod->regmap, reg->reg_global_lock_offset,
+ reg->global_lock_mask, reg->global_lock_val);
+}
+
+/**
+ * ti_iodelay_get_pingroup() - Find the group mapped by a group selector
+ * @iod: iodelay device
+ * @selector: Group Selector
+ *
+ * Return: Corresponding group representing group selector
+ */
+static struct ti_iodelay_pingroup *
+ti_iodelay_get_pingroup(struct ti_iodelay_device *iod, unsigned int selector)
+{
+ struct group_desc *g;
+
+ g = pinctrl_generic_get_group(iod->pctl, selector);
+ if (!g) {
+ dev_err(iod->dev, "%s could not find pingroup %i\n", __func__,
+ selector);
+
+ return NULL;
+ }
+
+ return g->data;
+}
+
+/**
+ * ti_iodelay_offset_to_pin() - get a pin index based on the register offset
+ * @iod: iodelay driver instance
+ * @offset: register offset from the base
+ */
+static int ti_iodelay_offset_to_pin(struct ti_iodelay_device *iod,
+ unsigned int offset)
+{
+ const struct ti_iodelay_reg_data *r = iod->reg_data;
+ unsigned int index;
+
+ if (offset > r->regmap_config->max_register) {
+ dev_err(iod->dev, "mux offset out of range: 0x%x (0x%x)\n",
+ offset, r->regmap_config->max_register);
+ return -EINVAL;
+ }
+
+ index = (offset - r->reg_start_offset) / r->regmap_config->reg_stride;
+ index /= r->reg_nr_per_pin;
+
+ return index;
+}
+
+/**
+ * ti_iodelay_node_iterator() - Iterate iodelay node
+ * @pctldev: Pin controller driver
+ * @np: Device node
+ * @pinctrl_spec: Parsed arguments from device tree
+ * @pins: Array of pins in the pin group
+ * @pin_index: Pin index in the pin array
+ * @data: Pin controller driver specific data
+ *
+ */
+static int ti_iodelay_node_iterator(struct pinctrl_dev *pctldev,
+ struct device_node *np,
+ const struct of_phandle_args *pinctrl_spec,
+ int *pins, int pin_index, void *data)
+{
+ struct ti_iodelay_device *iod;
+ struct ti_iodelay_cfg *cfg = data;
+ const struct ti_iodelay_reg_data *r;
+ struct pinctrl_pin_desc *pd;
+ int pin;
+
+ iod = pinctrl_dev_get_drvdata(pctldev);
+ if (!iod)
+ return -EINVAL;
+
+ r = iod->reg_data;
+
+ if (pinctrl_spec->args_count < r->reg_nr_per_pin) {
+ dev_err(iod->dev, "invalid args_count for spec: %i\n",
+ pinctrl_spec->args_count);
+
+ return -EINVAL;
+ }
+
+ /* Index plus two value cells */
+ cfg[pin_index].offset = pinctrl_spec->args[0];
+ cfg[pin_index].a_delay = pinctrl_spec->args[1] & 0xffff;
+ cfg[pin_index].g_delay = pinctrl_spec->args[2] & 0xffff;
+
+ pin = ti_iodelay_offset_to_pin(iod, cfg[pin_index].offset);
+ if (pin < 0) {
+ dev_err(iod->dev, "could not add functions for %s %ux\n",
+ np->name, cfg[pin_index].offset);
+ return -ENODEV;
+ }
+ pins[pin_index] = pin;
+
+ pd = &iod->pa[pin];
+ pd->drv_data = &cfg[pin_index];
+
+ dev_dbg(iod->dev, "%s offset=%x a_delay = %d g_delay = %d\n",
+ np->name, cfg[pin_index].offset, cfg[pin_index].a_delay,
+ cfg[pin_index].g_delay);
+
+ return 0;
+}
+
+/**
+ * ti_iodelay_dt_node_to_map() - Map a device tree node to appropriate group
+ * @pctldev: pinctrl device representing IODelay device
+ * @np: Node Pointer (device tree)
+ * @map: Pinctrl Map returned back to pinctrl framework
+ * @num_maps: Number of maps (1)
+ *
+ * Maps the device tree description into a group of configuration parameters
+ * for iodelay block entry.
+ *
+ * Return: 0 in case of success, else appropriate error value
+ */
+static int ti_iodelay_dt_node_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *np,
+ struct pinctrl_map **map,
+ unsigned int *num_maps)
+{
+ struct ti_iodelay_device *iod;
+ struct ti_iodelay_cfg *cfg;
+ struct ti_iodelay_pingroup *g;
+ const char *name = "pinctrl-pin-array";
+ int rows, *pins, error = -EINVAL, i;
+
+ iod = pinctrl_dev_get_drvdata(pctldev);
+ if (!iod)
+ return -EINVAL;
+
+ rows = pinctrl_count_index_with_args(np, name);
+ if (rows == -EINVAL)
+ return rows;
+
+ *map = devm_kzalloc(iod->dev, sizeof(**map), GFP_KERNEL);
+ if (!*map)
+ return -ENOMEM;
+ *num_maps = 0;
+
+ g = devm_kzalloc(iod->dev, sizeof(*g), GFP_KERNEL);
+ if (!g) {
+ error = -ENOMEM;
+ goto free_map;
+ }
+
+ pins = devm_kzalloc(iod->dev, sizeof(*pins) * rows, GFP_KERNEL);
+ if (!pins)
+ goto free_group;
+
+ cfg = devm_kzalloc(iod->dev, sizeof(*cfg) * rows, GFP_KERNEL);
+ if (!cfg) {
+ error = -ENOMEM;
+ goto free_pins;
+ }
+
+ for (i = 0; i < rows; i++) {
+ struct of_phandle_args pinctrl_spec;
+
+ error = pinctrl_parse_index_with_args(np, name, i,
+ &pinctrl_spec);
+ if (error)
+ goto free_data;
+
+ error = ti_iodelay_node_iterator(pctldev, np, &pinctrl_spec,
+ pins, i, cfg);
+ if (error)
+ goto free_data;
+ }
+
+ g->cfg = cfg;
+ g->ncfg = i;
+ g->config = PIN_CONFIG_END;
+
+ error = pinctrl_generic_add_group(iod->pctl, np->name, pins, i, g);
+ if (error < 0)
+ goto free_data;
+
+ (*map)->type = PIN_MAP_TYPE_CONFIGS_GROUP;
+ (*map)->data.configs.group_or_pin = np->name;
+ (*map)->data.configs.configs = &g->config;
+ (*map)->data.configs.num_configs = 1;
+ *num_maps = 1;
+
+ return 0;
+
+free_data:
+ devm_kfree(iod->dev, cfg);
+free_pins:
+ devm_kfree(iod->dev, pins);
+free_group:
+ devm_kfree(iod->dev, g);
+free_map:
+ devm_kfree(iod->dev, *map);
+
+ return error;
+}
+
+/**
+ * ti_iodelay_pinconf_group_get() - Get the group configuration
+ * @pctldev: pinctrl device representing IODelay device
+ * @selector: Group selector
+ * @config: Configuration returned
+ *
+ * Return: The configuration if the group is valid, else returns -EINVAL
+ */
+static int ti_iodelay_pinconf_group_get(struct pinctrl_dev *pctldev,
+ unsigned int selector,
+ unsigned long *config)
+{
+ struct ti_iodelay_device *iod;
+ struct device *dev;
+ struct ti_iodelay_pingroup *group;
+
+ iod = pinctrl_dev_get_drvdata(pctldev);
+ dev = iod->dev;
+ group = ti_iodelay_get_pingroup(iod, selector);
+
+ if (!group)
+ return -EINVAL;
+
+ *config = group->config;
+ return 0;
+}
+
+/**
+ * ti_iodelay_pinconf_group_set() - Configure the groups of pins
+ * @pctldev: pinctrl device representing IODelay device
+ * @selector: Group selector
+ * @configs: Configurations
+ * @num_configs: Number of configurations
+ *
+ * Return: 0 if all went fine, else appropriate error value.
+ */
+static int ti_iodelay_pinconf_group_set(struct pinctrl_dev *pctldev,
+ unsigned int selector,
+ unsigned long *configs,
+ unsigned int num_configs)
+{
+ struct ti_iodelay_device *iod;
+ struct device *dev;
+ struct ti_iodelay_pingroup *group;
+ int i;
+
+ iod = pinctrl_dev_get_drvdata(pctldev);
+ dev = iod->dev;
+ group = ti_iodelay_get_pingroup(iod, selector);
+
+ if (num_configs != 1) {
+ dev_err(dev, "Unsupported number of configurations %d\n",
+ num_configs);
+ return -EINVAL;
+ }
+
+ if (*configs != PIN_CONFIG_END) {
+ dev_err(dev, "Unsupported configuration\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < group->ncfg; i++) {
+ if (ti_iodelay_pinconf_set(iod, &group->cfg[i]))
+ return -ENOTSUPP;
+ }
+
+ return 0;
+}
+
+#ifdef CONFIG_DEBUG_FS
+/**
+ * ti_iodelay_pin_to_offset() - get pin register offset based on the pin index
+ * @iod: iodelay driver instance
+ * @selector: Pin index
+ */
+static unsigned int ti_iodelay_pin_to_offset(struct ti_iodelay_device *iod,
+ unsigned int selector)
+{
+ const struct ti_iodelay_reg_data *r = iod->reg_data;
+ unsigned int offset;
+
+ offset = selector * r->regmap_config->reg_stride;
+ offset *= r->reg_nr_per_pin;
+ offset += r->reg_start_offset;
+
+ return offset;
+}
+
+static void ti_iodelay_pin_dbg_show(struct pinctrl_dev *pctldev,
+ struct seq_file *s,
+ unsigned int pin)
+{
+ struct ti_iodelay_device *iod;
+ struct pinctrl_pin_desc *pd;
+ struct ti_iodelay_cfg *cfg;
+ const struct ti_iodelay_reg_data *r;
+ unsigned long offset;
+ u32 in, oen, out;
+
+ iod = pinctrl_dev_get_drvdata(pctldev);
+ r = iod->reg_data;
+
+ offset = ti_iodelay_pin_to_offset(iod, pin);
+ if (pin < 0) {
+ dev_err(iod->dev, "invalid pin offset for pin%i\n", pin);
+
+ return;
+ }
+
+ pd = &iod->pa[pin];
+ cfg = pd->drv_data;
+
+ regmap_read(iod->regmap, offset, &in);
+ regmap_read(iod->regmap, offset + r->regmap_config->reg_stride, &oen);
+ regmap_read(iod->regmap, offset + r->regmap_config->reg_stride * 2,
+ &out);
+
+ seq_printf(s, "%lx a: %i g: %i (%08x %08x %08x) %s ",
+ iod->phys_base + offset,
+ cfg ? cfg->a_delay : -1,
+ cfg ? cfg->g_delay : -1,
+ in, oen, out, DRIVER_NAME);
+}
+
+/**
+ * ti_iodelay_pinconf_group_dbg_show() - show the group information
+ * @pctldev: Show the group information
+ * @s: Sequence file
+ * @selector: Group selector
+ *
+ * Provide the configuration information of the selected group
+ */
+static void ti_iodelay_pinconf_group_dbg_show(struct pinctrl_dev *pctldev,
+ struct seq_file *s,
+ unsigned int selector)
+{
+ struct ti_iodelay_device *iod;
+ struct device *dev;
+ struct ti_iodelay_pingroup *group;
+ int i;
+
+ iod = pinctrl_dev_get_drvdata(pctldev);
+ dev = iod->dev;
+ group = ti_iodelay_get_pingroup(iod, selector);
+ if (!group)
+ return;
+
+ for (i = 0; i < group->ncfg; i++) {
+ struct ti_iodelay_cfg *cfg;
+ u32 reg = 0;
+
+ cfg = &group->cfg[i];
+ regmap_read(iod->regmap, cfg->offset, ®),
+ seq_printf(s, "\n\t0x%08x = 0x%08x (%3d, %3d)",
+ cfg->offset, reg, cfg->a_delay,
+ cfg->g_delay);
+ }
+}
+#endif
+
+static struct pinctrl_ops ti_iodelay_pinctrl_ops = {
+ .get_groups_count = pinctrl_generic_get_group_count,
+ .get_group_name = pinctrl_generic_get_group_name,
+ .get_group_pins = pinctrl_generic_get_group_pins,
+#ifdef CONFIG_DEBUG_FS
+ .pin_dbg_show = ti_iodelay_pin_dbg_show,
+#endif
+ .dt_node_to_map = ti_iodelay_dt_node_to_map,
+};
+
+static struct pinconf_ops ti_iodelay_pinctrl_pinconf_ops = {
+ .pin_config_group_get = ti_iodelay_pinconf_group_get,
+ .pin_config_group_set = ti_iodelay_pinconf_group_set,
+#ifdef CONFIG_DEBUG_FS
+ .pin_config_group_dbg_show = ti_iodelay_pinconf_group_dbg_show,
+#endif
+};
+
+/**
+ * ti_iodelay_alloc_pins() - Allocate structures needed for pins for iodelay
+ * @dev: Device pointer
+ * @iod: iodelay device
+ * @base_phy: Base Physical Address
+ *
+ * Return: 0 if all went fine, else appropriate error value.
+ */
+static int ti_iodelay_alloc_pins(struct device *dev,
+ struct ti_iodelay_device *iod, u32 base_phy)
+{
+ const struct ti_iodelay_reg_data *r = iod->reg_data;
+ struct pinctrl_pin_desc *pin;
+ u32 phy_reg;
+ int nr_pins, i;
+
+ nr_pins = ti_iodelay_offset_to_pin(iod, r->regmap_config->max_register);
+ dev_dbg(dev, "Allocating %i pins\n", nr_pins);
+
+ iod->pa = devm_kzalloc(dev, sizeof(*iod->pa) * nr_pins, GFP_KERNEL);
+ if (!iod->pa)
+ return -ENOMEM;
+
+ iod->desc.pins = iod->pa;
+ iod->desc.npins = nr_pins;
+
+ phy_reg = r->reg_start_offset + base_phy;
+
+ for (i = 0; i < nr_pins; i++, phy_reg += 4) {
+ pin = &iod->pa[i];
+ pin->number = i;
+ }
+
+ return 0;
+}
+
+static struct regmap_config dra7_iodelay_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0xd1c,
+};
+
+static struct ti_iodelay_reg_data dra7_iodelay_data = {
+ .signature_mask = 0x0003f000,
+ .signature_value = 0x29,
+ .lock_mask = 0x00000400,
+ .lock_val = 1,
+ .unlock_val = 0,
+ .binary_data_coarse_mask = 0x000003e0,
+ .binary_data_fine_mask = 0x0000001f,
+
+ .reg_refclk_offset = 0x14,
+ .refclk_period_mask = 0xffff,
+
+ .reg_coarse_offset = 0x18,
+ .coarse_delay_count_mask = 0xffff0000,
+ .coarse_ref_count_mask = 0x0000ffff,
+
+ .reg_fine_offset = 0x1C,
+ .fine_delay_count_mask = 0xffff0000,
+ .fine_ref_count_mask = 0x0000ffff,
+
+ .reg_global_lock_offset = 0x2c,
+ .global_lock_mask = 0x0000ffff,
+ .global_unlock_val = 0x0000aaaa,
+ .global_lock_val = 0x0000aaab,
+
+ .reg_start_offset = 0x30,
+ .reg_nr_per_pin = 3,
+ .regmap_config = &dra7_iodelay_regmap_config,
+};
+
+static const struct of_device_id ti_iodelay_of_match[] = {
+ {.compatible = "ti,dra7-iodelay", .data = &dra7_iodelay_data},
+ { /* Hopefully no more.. */ },
+};
+MODULE_DEVICE_TABLE(of, ti_iodelay_of_match);
+
+/**
+ * ti_iodelay_probe() - Standard probe
+ * @pdev: platform device
+ *
+ * Return: 0 if all went fine, else appropriate error value.
+ */
+static int ti_iodelay_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = of_node_get(dev->of_node);
+ const struct of_device_id *match;
+ struct resource *res;
+ struct ti_iodelay_device *iod;
+ int ret = 0;
+
+ if (!np) {
+ ret = -EINVAL;
+ dev_err(dev, "No OF node\n");
+ goto exit_out;
+ }
+
+ match = of_match_device(ti_iodelay_of_match, dev);
+ if (!match) {
+ ret = -EINVAL;
+ dev_err(dev, "No DATA match\n");
+ goto exit_out;
+ }
+
+ iod = devm_kzalloc(dev, sizeof(*iod), GFP_KERNEL);
+ if (!iod) {
+ ret = -ENOMEM;
+ goto exit_out;
+ }
+ iod->dev = dev;
+ iod->reg_data = match->data;
+
+ /* So far We can assume there is only 1 bank of registers */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, "Missing MEM resource\n");
+ ret = -ENODEV;
+ goto exit_out;
+ }
+
+ iod->phys_base = res->start;
+ iod->reg_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(iod->reg_base)) {
+ ret = PTR_ERR(iod->reg_base);
+ goto exit_out;
+ }
+
+ iod->regmap = devm_regmap_init_mmio(dev, iod->reg_base,
+ iod->reg_data->regmap_config);
+ if (IS_ERR(iod->regmap)) {
+ dev_err(dev, "Regmap MMIO init failed.\n");
+ ret = PTR_ERR(iod->regmap);
+ goto exit_out;
+ }
+
+ if (ti_iodelay_pinconf_init_dev(iod))
+ goto exit_out;
+
+ ret = ti_iodelay_alloc_pins(dev, iod, res->start);
+ if (ret)
+ goto exit_out;
+
+ iod->desc.pctlops = &ti_iodelay_pinctrl_ops;
+ /* no pinmux ops - we are pinconf */
+ iod->desc.confops = &ti_iodelay_pinctrl_pinconf_ops;
+ iod->desc.name = dev_name(dev);
+ iod->desc.owner = THIS_MODULE;
+
+ iod->pctl = pinctrl_register(&iod->desc, dev, iod);
+ if (!iod->pctl) {
+ dev_err(dev, "Failed to register pinctrl\n");
+ ret = -ENODEV;
+ goto exit_out;
+ }
+
+ platform_set_drvdata(pdev, iod);
+
+exit_out:
+ of_node_put(np);
+ return ret;
+}
+
+/**
+ * ti_iodelay_remove() - standard remove
+ * @pdev: platform device
+ *
+ * Return: 0 if all went fine, else appropriate error value.
+ */
+static int ti_iodelay_remove(struct platform_device *pdev)
+{
+ struct ti_iodelay_device *iod = platform_get_drvdata(pdev);
+
+ if (!iod)
+ return 0;
+
+ if (iod->pctl)
+ pinctrl_unregister(iod->pctl);
+
+ ti_iodelay_pinconf_deinit_dev(iod);
+
+ /* Expect other allocations to be freed by devm */
+
+ return 0;
+}
+
+static struct platform_driver ti_iodelay_driver = {
+ .probe = ti_iodelay_probe,
+ .remove = ti_iodelay_remove,
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRIVER_NAME,
+ .of_match_table = ti_iodelay_of_match,
+ },
+};
+module_platform_driver(ti_iodelay_driver);
+
+MODULE_AUTHOR("Texas Instruments, Inc.");
+MODULE_DESCRIPTION("Pinconf driver for TI's IO Delay module");
+MODULE_LICENSE("GPL v2");
--
2.11.0
--
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
* [PATCH 1/2] pinctrl: core: Make dt_free_map optional
From: Tony Lindgren @ 2017-01-05 18:54 UTC (permalink / raw)
To: Linus Walleij
Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Nishanth Menon,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170105185414.27247-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
If the pin controller driver is using devm_kzalloc, there may not be
anything to do for dt_free_map. Let's make it optional to avoid
unncessary boilerplate code.
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
drivers/pinctrl/core.c | 3 ---
drivers/pinctrl/devicetree.c | 3 ++-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1913,9 +1913,6 @@ static int pinctrl_check_ops(struct pinctrl_dev *pctldev)
!ops->get_group_name)
return -EINVAL;
- if (ops->dt_node_to_map && !ops->dt_free_map)
- return -EINVAL;
-
return 0;
}
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -42,7 +42,8 @@ static void dt_free_map(struct pinctrl_dev *pctldev,
{
if (pctldev) {
const struct pinctrl_ops *ops = pctldev->desc->pctlops;
- ops->dt_free_map(pctldev, map, num_maps);
+ if (ops->dt_free_map)
+ ops->dt_free_map(pctldev, map, num_maps);
} else {
/* There is no pctldev for PIN_MAP_TYPE_DUMMY_STATE */
kfree(map);
--
2.11.0
--
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
* [PATCHv3 0/2] Add TI iodelay driver using #pinctrl-cells
From: Tony Lindgren @ 2017-01-05 18:54 UTC (permalink / raw)
To: Linus Walleij
Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Nishanth Menon,
Rob Herring, devicetree, linux-gpio, linux-omap
Hi,
Here's a v3 respin of Nishanth's iodelay driver that I've updated to
use #pinctrl-cells and generic pinctrl group and function code.
Gary, note that this one has an iterator function that you may
be able to use too, and hopefully we can simplify things further
eventually by introducing a generic iterator.
Regards,
Tony
Changes since v1
- Fix compile error if CONFIG_DEBUG_FS is not set
Changes since v2
- Update with Nishanth's kerneldoc comments
- Added Rob's ack
Nishanth Menon (1):
pinctrl: Introduce TI IOdelay configuration driver
Tony Lindgren (1):
pinctrl: core: Make dt_free_map optional
.../devicetree/bindings/pinctrl/ti,iodelay.txt | 47 +
drivers/pinctrl/Kconfig | 1 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/core.c | 3 -
drivers/pinctrl/devicetree.c | 3 +-
drivers/pinctrl/ti/Kconfig | 10 +
drivers/pinctrl/ti/Makefile | 1 +
drivers/pinctrl/ti/pinctrl-ti-iodelay.c | 944 +++++++++++++++++++++
8 files changed, 1006 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pinctrl/ti,iodelay.txt
create mode 100644 drivers/pinctrl/ti/Kconfig
create mode 100644 drivers/pinctrl/ti/Makefile
create mode 100644 drivers/pinctrl/ti/pinctrl-ti-iodelay.c
--
2.11.0
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
From: Tony Lindgren @ 2017-01-05 18:50 UTC (permalink / raw)
To: Nishanth Menon
Cc: Linus Walleij, Gary Bisson, Grygorii Strashko, Mark Rutland,
Rob Herring, devicetree, linux-gpio, linux-omap, Lokesh Vutla
In-Reply-To: <41e171e7-4812-51fa-980c-197f7db7b5ef@ti.com>
* Nishanth Menon <nm@ti.com> [170104 09:58]:
> On 01/02/2017 04:12 PM, Tony Lindgren wrote:
> [...]
>
> I got the following warnings with kernel-doc:
> > $ ./scripts/kernel-doc drivers/pinctrl/ti/pinctrl-ti-iodelay.c>/dev/null
> > drivers/pinctrl/ti/pinctrl-ti-iodelay.c:132: warning: Excess struct/union/enum/typedef member 'name' description in 'ti_iodelay_pingroup'
> > drivers/pinctrl/ti/pinctrl-ti-iodelay.c:132: warning: Excess struct/union/enum/typedef member 'map' description in 'ti_iodelay_pingroup'
> > drivers/pinctrl/ti/pinctrl-ti-iodelay.c:159: warning: Excess struct/union/enum/typedef member 'names' description in 'ti_iodelay_device'
> > drivers/pinctrl/ti/pinctrl-ti-iodelay.c:211: warning: No description found for parameter 'cfg'
> > drivers/pinctrl/ti/pinctrl-ti-iodelay.c:211: warning: Excess function parameter 'val' description in 'ti_iodelay_pinconf_set'
> > drivers/pinctrl/ti/pinctrl-ti-iodelay.c:418: warning: Cannot understand *
> > on line 418 - I thought it was a doc line
>
> Marking them below
OK thanks will repost v3 shortly.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Rob Herring @ 2017-01-05 18:50 UTC (permalink / raw)
To: Laurent Pinchart, Tony Lindgren
Cc: linux-omap, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Benoît Cousson
In-Reply-To: <2557392.58vudoaMIY@avalon>
On Thu, Jan 5, 2017 at 10:48 AM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> Hello,
>
> On Thursday 05 Jan 2017 08:39:29 Tony Lindgren wrote:
>> * Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170105 08:28]:
>> > On Fri, Dec 2, 2016 at 3:11 PM, Laurent Pinchart wrote:
>> >> The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
>> >> connected to port 2 of the OMAP EHCI controller. The board however has
>> >> no EEPROM to store the ethernet MAC address, which is programmed by the
>> >> boot loader.
>> >>
>> >> To allow Linux to use the same MAC address as the boot loader (or for
>> >> that matter any fixed MAC address), we need a node in the device tree
>> >> for the ethernet controller that the boot loader can update at runtime
>> >> with a local-mac-address property. Add it, along with an alias for the
>> >> ethernet controller to let the boot loader locate it easily.
>> >>
>> >> Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>> >> ---
>> >> Changes since v1:
>> >>
>> >> - Renamed usb2 DT node to hub
>> >> ---
>> >>
>> >> arch/arm/boot/dts/omap3-beagle-xm.dts | 16 ++++++++++++++++
>> >> 1 file changed, 16 insertions(+)
>> >>
>> >> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
>> >> b/arch/arm/boot/dts/omap3-beagle-xm.dts index
>> >> 85e297ed0ea1..673cee2234b2 100644
>> >> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>> >> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>> >> @@ -27,6 +27,7 @@
>> >> aliases {
>> >> display0 = &dvi0;
>> >> display1 = &tv0;
>> >> + ethernet = ðernet;
>> >
>> > Sorry, just noticed this, but this should be dropped. It's not used
>> > nor do we want an alias here.
>>
>> OK, will update locally as I have not pushed out yet.
>
> The ethernet alias is used by U-Boot to locate the ethernet controller and
> update the MAC address.
Okay. Though with only only one, I don't see why that is hard to find.
Anyway, this is the least of u-boot's DT abuses.
>> > P.S. The display ones are questionable, too. Only OMAP has them and
>> > per platform alias names is not something we want.
>>
>> OK. What about the mmc ones? Otherwise the MMC devices keep moving
>> around depending on the kernel version..
This is a solved problem. Consistent dev numbering is not a feature of
the kernel and MMC is not special.
Rob
--
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 4/4] arm64: dts: exynos: Add tm2 touchkey node
From: Krzysztof Kozlowski @ 2017-01-05 18:41 UTC (permalink / raw)
To: Jaechul Lee
Cc: Mark Rutland, devicetree, linux-samsung-soc, Andi Shyti,
Chanwoo Choi, Catalin Marinas, Dmitry Torokhov, Will Deacon,
linux-kernel, Rob Herring, Javier Martinez Canillas, Kukjin Kim,
Krzysztof Kozlowski, linux-input, galaxyra, beomho.seo,
linux-arm-kernel
In-Reply-To: <1483604833-29746-5-git-send-email-jcsing.lee@samsung.com>
On Thu, Jan 05, 2017 at 05:27:13PM +0900, Jaechul Lee wrote:
> Add DT node support for TM2 touchkey device.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Although I said the patch looks correct, it was not an explicit Review
(and we have a quite serious "Reviewer's statement of oversight") so my
tag should not be added.
No harm was done, but I prefer clearly and explicitly given tags.
Best regards,
Krzysztof
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index aa8584a..dad6fb8 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -17,3 +17,16 @@
> model = "Samsung TM2 board";
> compatible = "samsung,tm2", "samsung,exynos5433";
> };
> +
> +&hsi2c_9 {
> + status = "okay";
> +
> + touchkey@20 {
> + compatible = "samsung,tm2-touchkey";
> + reg = <0x20>;
> + interrupt-parent = <&gpa3>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + vcc-supply = <&ldo32_reg>;
> + vdd-supply = <&ldo33_reg>;
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Krzysztof Kozlowski @ 2017-01-05 18:37 UTC (permalink / raw)
To: Andi Shyti
Cc: Chanwoo Choi, Jaechul Lee, Dmitry Torokhov, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Kukjin Kim,
Krzysztof Kozlowski, Javier Martinez Canillas, beomho.seo,
galaxyra, linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc
In-Reply-To: <20170105092315.swensammin4wbgx5@gangnam.samsung>
On Thu, Jan 05, 2017 at 06:23:15PM +0900, Andi Shyti wrote:
> Hi Chanwoo,
>
> > I add the some comment as following:
> > - ldo23/25/31/38 have the different value between tm2 and tm2e.
>
> Thanks for pointing this out. I planned to do this already in a
> following patch as for now I think it's out from the scope of this
> particular patch.
>
> > - The patch[1] was alread posted. I think you better to rebase this patch on patch[1].
> > [1] https://patchwork.kernel.org/patch/9491769/
> > - ("ARM64: dts: TM2: comply to the samsung pinctrl naming convention")
>
> Yes, I also thought about this, but I didn't know whether it was
> already picked by anyone. I didn't want to stop Jaechul that's
> why I was planning to rebase the other rather than this.
> But you are right, because some bits of the other patches I know
> that have been merged. Thank you!
>
> Krzysztof, do you mind if I send patch 3 as a reply to this
> e-mail? The changes should not affect patch 4, anyway.
By patch 3 you mean this patch? Yes, you can send another version as a
reply-to but please version it (2.1? etc).
Anyway I need a proper rename detection. I pointed proper command last
time. Is it working?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Krzysztof Kozlowski @ 2017-01-05 18:09 UTC (permalink / raw)
To: Hoegeun Kwon
Cc: robh, thierry.reding, airlied, kgene, Inki Dae, dri-devel,
linux-kernel, devicetree, linux-samsung-soc, a.hajda,
Chanwoo Choi, Jaehoon Chung, Donghwa Lee, Hyungwon Hwang
In-Reply-To: <1483611609-23522-4-git-send-email-hoegeun.kwon@samsung.com>
On Thu, Jan 5, 2017 at 12:20 PM, Hoegeun Kwon <hoegeun.kwon@samsung.com> 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>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
> .../bindings/display/panel/samsung,s6e3ha2.txt | 28 +
> drivers/gpu/drm/panel/Kconfig | 6 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 +++++++++++++++++++++
> 4 files changed, 789 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>
> diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> new file mode 100644
> index 0000000..da4c291
This should be a separate patch, preferably first one in the series. See:
Documentation/devicetree/bindings/submitting-patches.txt
Since you already got reviews and tests, I think you can retain them
in both patches (so dt-bindings patch will have reviewed-by-Andrzej
and the code will have review+tested).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] ARM: dts: sunxi: Enable spi1 and spi2 for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2017-01-05 18:04 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, linux, linux-kernel, wens, robh+dt,
linux-arm-kernel
In-Reply-To: <20170105180151.gooxj3zy53hgojah@lukather>
On Thu, 5 Jan 2017 19:01:51 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Thu, Jan 05, 2017 at 06:37:34PM +0100, Emmanuel Vadot wrote:
> >
> > Hi,
> >
> > On Thu, 5 Jan 2017 18:16:01 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > Hi,
> > >
> > > On Mon, Dec 26, 2016 at 06:53:49PM +0100, Emmanuel Vadot wrote:
> > > > Enable the spi1 and spi2 node since the pins are exposed on the UEXT
> > > > connectors.
> > > >
> > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > > > ---
> > > > arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > > index 669a1c338c76..fa8c6f60552b 100644
> > > > --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > > +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > > @@ -300,12 +300,14 @@
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <&spi1_pins_a>,
> > > > <&spi1_cs0_pins_a>;
> > > > + status = "okay";
> > > > };
> > > >
> > > > &spi2 {
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <&spi2_pins_a>,
> > > > <&spi2_cs0_pins_a>;
> > > > + status = "okay";
> > > > };
> > >
> > > Those nodes don't exist unfortunately. Maybe you forgot to send one
> > > patch?
> > >
> > > Thanks!
> > > Maxime
> > >
> > > --
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux and Kernel engineering
> > > http://free-electrons.com
> >
> > It's based on a previous sent patch :
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/469288.html
> >
> > You said you'll squash the two commits.
>
> Hmmm, indeed, I might have made a mistake on this one and ended up
> dropping it... :/
>
> I reapplied both and squashed them together, thanks (and sorry again)!
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
No problem, thank you!
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* Re: [PATCH] ARM: dts: sunxi: Enable spi1 and spi2 for Olimex A20 SOM EVB
From: Maxime Ripard @ 2017-01-05 18:01 UTC (permalink / raw)
To: Emmanuel Vadot
Cc: mark.rutland, devicetree, linux, linux-kernel, wens, robh+dt,
linux-arm-kernel
In-Reply-To: <20170105183734.c56cf3e0be4ad4ac21028851@bidouilliste.com>
[-- Attachment #1.1: Type: text/plain, Size: 1875 bytes --]
On Thu, Jan 05, 2017 at 06:37:34PM +0100, Emmanuel Vadot wrote:
>
> Hi,
>
> On Thu, 5 Jan 2017 18:16:01 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Mon, Dec 26, 2016 at 06:53:49PM +0100, Emmanuel Vadot wrote:
> > > Enable the spi1 and spi2 node since the pins are exposed on the UEXT
> > > connectors.
> > >
> > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > > ---
> > > arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > index 669a1c338c76..fa8c6f60552b 100644
> > > --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > @@ -300,12 +300,14 @@
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&spi1_pins_a>,
> > > <&spi1_cs0_pins_a>;
> > > + status = "okay";
> > > };
> > >
> > > &spi2 {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&spi2_pins_a>,
> > > <&spi2_cs0_pins_a>;
> > > + status = "okay";
> > > };
> >
> > Those nodes don't exist unfortunately. Maybe you forgot to send one
> > patch?
> >
> > Thanks!
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> It's based on a previous sent patch :
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/469288.html
>
> You said you'll squash the two commits.
Hmmm, indeed, I might have made a mistake on this one and ended up
dropping it... :/
I reapplied both and squashed them together, thanks (and sorry again)!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] spi: imx: support to set watermark level via DTS
From: Mark Brown @ 2017-01-05 17:58 UTC (permalink / raw)
To: Jiada Wang; +Cc: robh+dt, mark.rutland, linux-spi, devicetree, linux-kernel
In-Reply-To: <20170105061015.7816-1-jiada_wang@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
On Thu, Jan 05, 2017 at 03:10:15PM +0900, Jiada Wang wrote:
> Previously watermark level is configured to fifosize/2,
> DMA mode can be used only when transfer length can be divided
> by 'watermark level * bpw', which makes DMA mode not practical.
> This patch adds new DTS property 'dma-wml', user can configure
> DMA watermark level, by specify 'dma-wml' in corresponding ecspi
> node.
Doesn't this just move the problem around a bit - can we not have the
driver figure out a more sensible watermark for each transfer rather
than fixing one in the DT?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
From: Maxime Ripard @ 2017-01-05 17:57 UTC (permalink / raw)
To: Rob Herring
Cc: Andre Przywara, Ulf Hansson, Chen-Yu Tsai, Hans De Goede,
Icenowy Zheng, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170104140750.7qs4pvggwjdj5cma@rob-hp-laptop>
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]
Hi Rob,
On Wed, Jan 04, 2017 at 08:07:50AM -0600, Rob Herring wrote:
> On Mon, Jan 02, 2017 at 11:03:43PM +0000, Andre Przywara wrote:
> > From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >
> > Unlike the A64 user manual reports, the third MMC controller on the
> > A64 (and the only one capable of 8-bit HS400 eMMC transfers) has a
> > DMA buffer size limit of 8KB (much like the very old Allwinner SoCs).
> > This does not affect the other two controllers, so introduce a new
> > DT compatible string to let the driver use different settings for that
> > particular device. This will also help to enable the high-speed transfer
> > modes of that controller later.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
> > drivers/mmc/host/sunxi-mmc.c | 7 +++++++
> > 2 files changed, 8 insertions(+)
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Some kind of a digression on this: we have three MMC controllers on
this SoC. Like this patch shows, the third one is clearly different,
and supports both more modes, a wider bus, and specific quirks. We
need a new compatible for this one, everything's perfect.
However, the other two are mostly the same, but seems to need
different tuning parameters to get more performances out of the
controller (but this is unclear yet). How do we usually deal with
that?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Brian Norris @ 2017-01-05 17:56 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, devicetree, Brian Norris, Rob Herring, linux-mtd,
Benoît Cousson, Teresa Remmet, linux-omap, Adam Ford,
linux-arm-kernel
In-Reply-To: <20170105171845.GK4310@atomide.com>
On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [170105 07:37]:
> > * Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
> > > To improve NAND safety we updated the partition layout.
> > > Added barebox backup partition and removed kernel and oftree
> > > partition. They are kept in ubi now.
> >
> > What about the users with earlier partition tables?
> >
> > Please read about "flag day" changes, typically they are not
> > acceptable.
>
> Adding Brian and Adam to Cc. Can you guys come up with some
> solution on this?
I don't have much context for this thread, and no I don't plan to solve
your problems for you. But I can provide tips!
> I'm suggesting we leave the kernel nodes empty and let u-boot
> populate them, so maybe you guys can discuss this on the related
> lists.
That's an option. I've worked with platforms that did something like
this, and that's really one of the only ways you can handle putting
partition information in the device tree. You're really hamstringing
yourself when you put all the partition information in the device tree.
And it's just dumb once that gets codified in the kernel source tree.
The best solution would be to try to migrate away from static device
tree representations of partition info entirely. UBI volumes are best
where possible. If not, then some other kind of on-flash data structures
(along the lines of a GPT) with a corresponding MTD partition parser is
an OK alternative. Unfortunately, there isn't any good standard format
for this on MTD, so it's typically all custom -- and so people use the
easiest approach: device tree. And it's even more difficult with NAND,
which has reliability problems, especially with static data (e.g., read
disturb).
Anyway, the parser solution is helpful only if one can properly fix the
"flag day" first. And it requires a little bit more work to be generally
useful; I posted some work for this over a year ago, but bikeshedding
brought it down.
> The rest of the series looks fine to me so applying it into
> omap-for-v4.11/dt.
Brian
^ permalink raw reply
* [PATCH v5 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Andreas Klinger @ 2017-01-05 17:51 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 is the IIO driver for AVIA HX711 ADC which is 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@it-klinger.de>
---
drivers/iio/adc/Kconfig | 19 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/hx711.c | 531 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 551 insertions(+)
create mode 100644 drivers/iio/adc/hx711.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 932de1f9d1e7..1dcf2ace1697 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -205,6 +205,25 @@ 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 weigh cells
+
+ This driver uses two GPIOs, one acts as the clock and controls the
+ channel selection and gain, the other one is used for the measurement
+ data
+
+ Currently the raw value is read from the chip and delivered.
+ To get 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..e41414556158
--- /dev/null
+++ b/drivers/iio/adc/hx711.c
@@ -0,0 +1,531 @@
+/*
+ * HX711: analog to digital converter for weight sensor module
+ *
+ * Copyright (c) 2016 Andreas Klinger <ak@it-klinger.de>
+ *
+ * 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/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>
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+
+/* gain to pulse and scale conversion */
+#define HX711_GAIN_MAX 3
+
+struct hx711_gain_to_scale {
+ int gain;
+ int gain_pulse;
+ int scale;
+ int channel;
+};
+
+/*
+ * .scale depends on AVDD which in turn is known as soon as the regulator
+ * is available
+ * therefore we set .scale in hx711_probe()
+ *
+ * channel A in documentation is channel 0 in source code
+ * channel B in documentation is channel 1 in source code
+ */
+static struct hx711_gain_to_scale hx711_gain_to_scale[HX711_GAIN_MAX] = {
+ { 128, 1, 0, 0 },
+ { 32, 2, 0, 1 },
+ { 64, 3, 0, 0 }
+};
+
+static int hx711_get_gain_to_pulse(int gain)
+{
+ int i;
+
+ for (i = 0; i < HX711_GAIN_MAX; i++)
+ if (hx711_gain_to_scale[i].gain == gain)
+ return hx711_gain_to_scale[i].gain_pulse;
+ return 1;
+}
+
+static int hx711_get_gain_to_scale(int gain)
+{
+ int i;
+
+ for (i = 0; i < HX711_GAIN_MAX; i++)
+ if (hx711_gain_to_scale[i].gain == gain)
+ return hx711_gain_to_scale[i].scale;
+ return 0;
+}
+
+static int hx711_get_scale_to_gain(int scale)
+{
+ int i;
+
+ for (i = 0; i < HX711_GAIN_MAX; i++)
+ if (hx711_gain_to_scale[i].scale == scale)
+ return hx711_gain_to_scale[i].gain;
+ return -EINVAL;
+}
+
+struct hx711_data {
+ struct device *dev;
+ struct gpio_desc *gpiod_pd_sck;
+ struct gpio_desc *gpiod_dout;
+ struct regulator *reg_avdd;
+ int gain_set; /* gain set on device */
+ int gain_chan_a; /* gain for channel A */
+ struct mutex lock;
+};
+
+static int hx711_cycle(struct hx711_data *hx711_data)
+{
+ int val;
+
+ /*
+ * if preempted for more then 60us while PD_SCK is high:
+ * hx711 is going in reset
+ * ==> measuring is false
+ */
+ preempt_disable();
+ gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ /*
+ * here we are not waiting for 0.2 us as suggested by the datasheet,
+ * because the oszilloscope showed in a test scenario
+ * at least 1.15 us for PD_SCK high (T3 in datasheet)
+ * and 0.56 us for PD_SCK low on TI Sitara with 800 MHz
+ */
+ gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
+ preempt_enable();
+
+ return val;
+}
+
+static int hx711_read(struct hx711_data *hx711_data)
+{
+ int i, ret;
+ int value = 0;
+ int val = gpiod_get_value(hx711_data->gpiod_dout);
+
+ /* we double check if it's really down */
+ if (val)
+ return -EIO;
+
+ for (i = 0; i < 24; i++) {
+ value <<= 1;
+ ret = hx711_cycle(hx711_data);
+ if (ret)
+ value++;
+ }
+
+ value ^= 0x800000;
+
+ for (i = 0; i < hx711_get_gain_to_pulse(hx711_data->gain_set); i++)
+ hx711_cycle(hx711_data);
+
+ return value;
+}
+
+static int hx711_wait_for_ready(struct hx711_data *hx711_data)
+{
+ int i, val;
+
+ /*
+ * a maximum reset cycle time of 56 ms was measured.
+ * we round it up to 100 ms
+ */
+ for (i = 0; i < 100; i++) {
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ if (!val)
+ break;
+ /* sleep at least 1 ms */
+ msleep(1);
+ }
+ if (val)
+ return -EIO;
+
+ return 0;
+}
+
+static int hx711_reset(struct hx711_data *hx711_data)
+{
+ int ret;
+ int val = gpiod_get_value(hx711_data->gpiod_dout);
+
+ if (val) {
+ /*
+ * an examination with the oszilloscope indicated
+ * that the first value read after the reset is not stable
+ * if we reset too short;
+ * the shorter the reset cycle
+ * the less reliable the first value after reset is;
+ * there were no problems encountered with a value
+ * of 10 ms or higher
+ */
+ gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+ msleep(10);
+ gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
+
+ ret = hx711_wait_for_ready(hx711_data);
+ if (ret)
+ return ret;
+ /*
+ * after a reset the gain is 128 so we do a dummy read
+ * to set the gain for the next read
+ */
+ ret = hx711_read(hx711_data);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * after a dummy read we need to wait vor readiness
+ * for not mixing gain pulses with the clock
+ */
+ ret = hx711_wait_for_ready(hx711_data);
+ if (ret)
+ return ret;
+ }
+
+ return val;
+}
+
+static int hx711_set_gain_for_channel(struct hx711_data *hx711_data, int chan)
+{
+ int ret;
+
+ if (chan == 0) {
+ if (hx711_data->gain_set == 32) {
+ hx711_data->gain_set = hx711_data->gain_chan_a;
+
+ ret = hx711_read(hx711_data);
+ if (ret < 0)
+ return ret;
+
+ ret = hx711_wait_for_ready(hx711_data);
+ if (ret)
+ return ret;
+ }
+ } else {
+ if (hx711_data->gain_set != 32) {
+ hx711_data->gain_set = 32;
+
+ ret = hx711_read(hx711_data);
+ if (ret < 0)
+ return ret;
+
+ ret = hx711_wait_for_ready(hx711_data);
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int hx711_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct hx711_data *hx711_data = iio_priv(indio_dev);
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ mutex_lock(&hx711_data->lock);
+
+ /*
+ * hx711_reset() must be called from here
+ * because it could be calling hx711_read() by itself
+ */
+ if (hx711_reset(hx711_data)) {
+ dev_err(hx711_data->dev, "reset failed!");
+ return -EIO;
+ }
+
+ ret = hx711_set_gain_for_channel(hx711_data, chan->channel);
+ if (ret < 0) {
+ mutex_unlock(&hx711_data->lock);
+ return ret;
+ }
+
+ *val = hx711_read(hx711_data);
+
+ mutex_unlock(&hx711_data->lock);
+
+ if (*val < 0)
+ return *val;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = 0;
+ mutex_lock(&hx711_data->lock);
+
+ *val2 = hx711_get_gain_to_scale(hx711_data->gain_set);
+
+ mutex_unlock(&hx711_data->lock);
+
+ return IIO_VAL_INT_PLUS_NANO;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int hx711_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val,
+ int val2,
+ long mask)
+{
+ struct hx711_data *hx711_data = iio_priv(indio_dev);
+ int ret;
+ int gain;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ /*
+ * a scale greater than 1 mV per LSB is not possible
+ * with the HX711, therefore val must be 0
+ */
+ if (val != 0)
+ return -EINVAL;
+
+ mutex_lock(&hx711_data->lock);
+
+ gain = hx711_get_scale_to_gain(val2);
+ if (gain < 0) {
+ mutex_unlock(&hx711_data->lock);
+ return gain;
+ }
+
+ if (gain != hx711_data->gain_set) {
+ hx711_data->gain_set = gain;
+ if (gain != 32)
+ hx711_data->gain_chan_a = gain;
+
+ ret = hx711_read(hx711_data);
+ if (ret < 0) {
+ mutex_unlock(&hx711_data->lock);
+ return ret;
+ }
+ }
+
+ mutex_unlock(&hx711_data->lock);
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int hx711_write_raw_get_fmt(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ long mask)
+{
+ return IIO_VAL_INT_PLUS_NANO;
+}
+
+static ssize_t hx711_scale_available_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct iio_dev_attr *iio_attr = to_iio_dev_attr(attr);
+ int channel = iio_attr->address;
+ int i, len = 0;
+
+ for (i = 0; i < HX711_GAIN_MAX; i++)
+ if (hx711_gain_to_scale[i].channel == channel)
+ len += sprintf(buf + len, "0.%09d ",
+ hx711_gain_to_scale[i].scale);
+
+ len += sprintf(buf + len, "\n");
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(in_voltage0_scale_available, S_IRUGO,
+ hx711_scale_available_show, NULL, 0);
+
+static IIO_DEVICE_ATTR(in_voltage1_scale_available, S_IRUGO,
+ hx711_scale_available_show, NULL, 1);
+
+static struct attribute *hx711_attributes[] = {
+ &iio_dev_attr_in_voltage0_scale_available.dev_attr.attr,
+ &iio_dev_attr_in_voltage1_scale_available.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,
+ .write_raw = hx711_write_raw,
+ .write_raw_get_fmt = hx711_write_raw_get_fmt,
+ .attrs = &hx711_attribute_group,
+};
+
+static const struct iio_chan_spec hx711_chan_spec[] = {
+ {
+ .type = IIO_VOLTAGE,
+ .channel = 0,
+ .indexed = 1,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
+ },
+ {
+ .type = IIO_VOLTAGE,
+ .channel = 1,
+ .indexed = 1,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static int hx711_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct hx711_data *hx711_data;
+ struct iio_dev *indio_dev;
+ int ret;
+ int i;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(struct hx711_data));
+ if (!indio_dev) {
+ dev_err(dev, "failed to allocate IIO device\n");
+ return -ENOMEM;
+ }
+
+ hx711_data = iio_priv(indio_dev);
+ hx711_data->dev = dev;
+
+ mutex_init(&hx711_data->lock);
+
+ /*
+ * PD_SCK stands for power down and serial clock input of HX711
+ * in the driver it is an output
+ */
+ hx711_data->gpiod_pd_sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_LOW);
+ if (IS_ERR(hx711_data->gpiod_pd_sck)) {
+ dev_err(dev, "failed to get sck-gpiod: err=%ld\n",
+ PTR_ERR(hx711_data->gpiod_pd_sck));
+ return PTR_ERR(hx711_data->gpiod_pd_sck);
+ }
+
+ /*
+ * DOUT stands for serial data output of HX711
+ * for the driver it is an input
+ */
+ hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_IN);
+ 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);
+ }
+
+ hx711_data->reg_avdd = devm_regulator_get(dev, "avdd");
+ if (IS_ERR(hx711_data->reg_avdd))
+ return PTR_ERR(hx711_data->reg_avdd);
+
+ ret = regulator_enable(hx711_data->reg_avdd);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * with
+ * full scale differential input range: AVDD / GAIN
+ * full scale output data: 2^24
+ * we can say:
+ * AVDD / GAIN = 2^24
+ * therefore:
+ * 1 LSB = AVDD / GAIN / 2^24
+ * AVDD is in uV, but we need 10^-9 mV
+ * approximately to fit into a 32 bit number:
+ * 1 LSB = (AVDD * 100) / GAIN / 1678 [10^-9 mV]
+ */
+ ret = regulator_get_voltage(hx711_data->reg_avdd);
+ if (ret < 0) {
+ regulator_disable(hx711_data->reg_avdd);
+ return ret;
+ }
+ /* we need 10^-9 mV */
+ ret *= 100;
+
+ for (i = 0; i < HX711_GAIN_MAX; i++)
+ hx711_gain_to_scale[i].scale =
+ ret / hx711_gain_to_scale[i].gain / 1678;
+
+ hx711_data->gain_set = 128;
+ hx711_data->gain_chan_a = 128;
+
+ platform_set_drvdata(pdev, indio_dev);
+
+ indio_dev->name = "hx711";
+ indio_dev->dev.parent = &pdev->dev;
+ indio_dev->info = &hx711_iio_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = hx711_chan_spec;
+ indio_dev->num_channels = ARRAY_SIZE(hx711_chan_spec);
+
+ ret = iio_device_register(indio_dev);
+ if (ret < 0) {
+ dev_err(dev, "Couldn't register the device\n");
+ regulator_disable(hx711_data->reg_avdd);
+ }
+
+ return ret;
+}
+
+static int hx711_remove(struct platform_device *pdev)
+{
+ struct hx711_data *hx711_data;
+ struct iio_dev *indio_dev;
+
+ indio_dev = platform_get_drvdata(pdev);
+ hx711_data = iio_priv(indio_dev);
+
+ iio_device_unregister(indio_dev);
+
+ regulator_disable(hx711_data->reg_avdd);
+
+ return 0;
+}
+
+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,
+ .remove = hx711_remove,
+ .driver = {
+ .name = "hx711-gpio",
+ .of_match_table = of_hx711_match,
+ },
+};
+
+module_platform_driver(hx711_driver);
+
+MODULE_AUTHOR("Andreas Klinger <ak@it-klinger.de>");
+MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:hx711-gpio");
+
--
2.1.4
^ permalink raw reply related
* [PATCH v5 1/2] iio: adc: hx711: Add DT binding for avia,hx711
From: Andreas Klinger @ 2017-01-05 17:51 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>
Acked-by: Rob Herring <robh@kernel.org>
---
[PATCH v3 1/2] of this patch was Acked-by: Rob Herring <robh@kernel.org>
In v4 the regulator (avdd-supply) was added
.../devicetree/bindings/iio/adc/avia-hx711.txt | 18 ++++++++++++++++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 19 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..b3629405f568
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -0,0 +1,18 @@
+* 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
+ - avdd-supply: Definition of the regulator used as analog supply
+
+Example:
+weight@0 {
+ compatible = "avia,hx711";
+ sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+ avdd-suppy = <&avdd>;
+};
+
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
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