* [PATCH v2 1/4] Documentation: dt-bindings: add the Amlogic Meson SAR ADC documentation
From: Martin Blumenstingl @ 2017-01-15 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115224221.15510-1-martin.blumenstingl@googlemail.com>
This adds the devicetree binding documentation for the SAR ADC found in
Amlogic Meson SoCs.
Currently only the GXBB, GXL and GXM SoCs are supported.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
.../bindings/iio/adc/amlogic,meson-saradc.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
new file mode 100644
index 000000000000..9a0bec7afc63
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
@@ -0,0 +1,31 @@
+* Amlogic Meson SAR (Successive Approximation Register) A/D converter
+
+Required properties:
+- compatible: depending on the SoC this should be one of:
+ - "amlogic,meson-gxbb-saradc" for GXBB
+ - "amlogic,meson-gxl-saradc" for GXL and GXM
+ along with the generic "amlogic,meson-saradc"
+- reg: the physical base address and length of the registers
+- clocks: phandle and clock identifier (see clock-names)
+- clock-names: mandatory clocks:
+ - "clkin" for the reference clock (typically XTAL)
+ - "core" for the SAR ADC core clock
+ optional clocks:
+ - "sana" for the analog clock
+ - "adc_clk" for the ADC (sampling) clock
+ - "adc_sel" for the ADC (sampling) clock mux
+- vref-supply: the regulator supply for the ADC reference voltage
+- #io-channel-cells: must be 1, see ../iio-bindings.txt
+
+Example:
+ saradc: adc at 8680 {
+ compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
+ #io-channel-cells = <1>;
+ reg = <0x0 0x8680 0x0 0x34>;
+ clocks = <&xtal>,
+ <&clkc CLKID_SAR_ADC>,
+ <&clkc CLKID_SANA>,
+ <&clkc CLKID_SAR_ADC_CLK>,
+ <&clkc CLKID_SAR_ADC_SEL>;
+ clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
+ };
--
2.11.0
^ permalink raw reply related
* [PATCH v2 0/4] Amlogic Meson SAR ADC support
From: Martin Blumenstingl @ 2017-01-15 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111174334.24343-1-martin.blumenstingl@googlemail.com>
This series add support for the SAR ADC on Amlogic Meson GXBB, GXL and
GXM SoCs.
The hardware on GXBB provides 10-bit ADC results, while GXL and GXM are
providing 12-bit results. Support for older SoCs (Meson8b and Meson8)
can be added with little effort, most of which is testing I guess (I
don't have any pre-GXBB hardware so I can't say).
A new set of clocks had to be added to the GXBB clock controller (used
by the GXBB/GXL/GXM SoCs) which are required to get the ADC working.
The ADC itself can sample multiple channels at the same time and allows
capturing multiple samples (which can be used for filtering/averaging).
The ADC results are stored inside a FIFO register. More details on what
the driver supports (or doesn't) can be found in the description of
patch #3.
The code is based on the public S805 (Meson8b) and S905 (GXBB)
datasheets, as well as by reading (various versions of) the vendor
driver and by inspecting the registers on the vendor kernels of my
testing-hardware.
Typical use-cases for the ADC on the Meson GX SoCs are:
- adc-keys ("ADC attached resistor ladder buttons")
- SoC temperature measurement (not supported by this driver yet as
the system firmware does this already and provides the values via the
SCPI protocol)
- "version-strapping" (different resistor values are used to indicate
the board-revision)
- and of course typical ADC measurements
Thanks to Heiner Kallweit, Jonathan Cameron and Lars-Peter Clausen for
reviewing this series and providing valuable input!
Changes since v1 (all changes are for patch #3, except where noted):
- fix IRQ number in meson-gx.dtsi (thanks to Heiner Kallweit for
providing the correct value), affects patch #4
- move the most used members of meson_saradc_priv to the beginning
- remove unused struct member "completion" from meson_saradc_priv
- use devm_kasprintf() instead of snprintf() + devm_kstrdup()
- initialize indio_dev->dev.parent earlier in meson_saradc_probe()
- moved meson_saradc_clear_fifo() logic to a separate function
- add comment why a do ... while loop is required in
meson_saradc_wait_busy_clear()
- remove SAR_ADC_NUM_CHANNELS and SAR_ADC_VALUE_MASK macros (each of them
was only used once and it's an unneeded level of abstraction)
- fixed multiline comment syntax violations
- dropped unneeded log messages during initialization
- set iio_dev name to "meson-gxbb-saradc" or "meson-gxl-saradc"
- use "indio_dev->dev.parent" in all kernel log calls (dev_warn/err/etc)
to make it show the OF node name (instead of the iio device name)
- introduce struct meson_saradc_data to hold platform-specific
information (such as resolution in bits and the iio_dev name)
Martin Blumenstingl (4):
Documentation: dt-bindings: add the Amlogic Meson SAR ADC
documentation
clk: gxbb: add the SAR ADC clocks and expose them
iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs
ARM64: dts: meson: meson-gx: add the SAR ADC
.../bindings/iio/adc/amlogic,meson-saradc.txt | 31 +
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 10 +
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 10 +
drivers/clk/meson/gxbb.c | 48 ++
drivers/clk/meson/gxbb.h | 9 +-
drivers/iio/adc/Kconfig | 12 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/meson_saradc.c | 893 +++++++++++++++++++++
include/dt-bindings/clock/gxbb-clkc.h | 4 +
10 files changed, 1023 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
create mode 100644 drivers/iio/adc/meson_saradc.c
--
2.11.0
^ permalink raw reply
* [PATCH 4/4] ARM64: dts: meson-gxbb-vega-s95: enable the Bluetooth module
From: Martin Blumenstingl @ 2017-01-15 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115223255.10350-1-martin.blumenstingl@googlemail.com>
This takes the Bluetooth module out of reset (the reset line is
connected to GPIOX_20) and enables uart_A which is used to configure the
module. This is common for all Vega S95 boards.
The device can then be initialized by running the hciattach tool:
hciattach -s115200 /dev/ttyAML1 bcm43xx 2000000 flow -
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index ab497126c9a3..9e0a13b1ac93 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -47,6 +47,7 @@
aliases {
serial0 = &uart_AO;
+ serial1 = &uart_A;
};
chosen {
@@ -100,6 +101,14 @@
};
};
+/* This is connected to the Bluetooth module of the wifi/BT combo chip: */
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins &uart_a_cts_rts_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+};
+
&uart_AO {
status = "okay";
pinctrl-0 = <&uart_ao_a_pins>;
--
2.11.0
^ permalink raw reply related
* [PATCH 3/4] ARM64: dts: meson-gx-p23x-q20x: enable the Bluetooth module
From: Martin Blumenstingl @ 2017-01-15 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115223255.10350-1-martin.blumenstingl@googlemail.com>
This takes the Bluetooth module out of reset (the reset line is
connected to GPIOX_17) and enables uart_A which is used to configure the
module.
This is identical for all boards which inherit meson-gx-p23x-q20x:
- GXL S905D P230
- GXL S905D P231
- GXM S912 Q200
- GXM S912 Q201
To get the HCI interface up one has to install bluez-utils and run:
hciattach -s115200 /dev/ttyAML1 bcm43xx 2000000 flow -
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078bef04cd..7db779048091 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -48,6 +48,7 @@
/ {
aliases {
serial0 = &uart_AO;
+ serial1 = &uart_A;
};
chosen {
@@ -94,12 +95,21 @@
sdio_pwrseq: sdio-pwrseq {
compatible = "mmc-pwrseq-simple";
- reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>,
+ <&gpio GPIOX_17 GPIO_ACTIVE_LOW>;
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
};
+/* This is connected to the Bluetooth module of the wifi/BT combo chip: */
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins &uart_a_cts_rts_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+};
+
/* This UART is brought out to the DB9 connector */
&uart_AO {
status = "okay";
--
2.11.0
^ permalink raw reply related
* [PATCH 2/4] ARM64: dts: meson-gx: add the serial CTS and RTS pin groups
From: Martin Blumenstingl @ 2017-01-15 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115223255.10350-1-martin.blumenstingl@googlemail.com>
This adds pinctrl group nodes for the CTS and RTS pins of each serial
controller. This makes it possible to enable the CTS and RTS pins which
are controlled by the serial controller hardware (through the meson_uart
driver).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 40 +++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 40 +++++++++++++++++++++++++++++
2 files changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 474435e21759..f001c4d007bc 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -138,6 +138,14 @@
};
};
+ uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
+ mux {
+ groups = "uart_cts_ao_a",
+ "uart_rts_ao_a";
+ function = "uart_ao";
+ };
+ };
+
uart_ao_b_pins: uart_ao_b {
mux {
groups = "uart_tx_ao_b", "uart_rx_ao_b";
@@ -145,6 +153,14 @@
};
};
+ uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
+ mux {
+ groups = "uart_cts_ao_b",
+ "uart_rts_ao_b";
+ function = "uart_ao_b";
+ };
+ };
+
remote_input_ao_pins: remote_input_ao {
mux {
groups = "remote_input_ao";
@@ -290,6 +306,14 @@
};
};
+ uart_a_cts_rts_pins: uart_a_cts_rts {
+ mux {
+ groups = "uart_cts_a",
+ "uart_rts_a";
+ function = "uart_a";
+ };
+ };
+
uart_b_pins: uart_b {
mux {
groups = "uart_tx_b",
@@ -298,6 +322,14 @@
};
};
+ uart_b_cts_rts_pins: uart_b_cts_rts {
+ mux {
+ groups = "uart_cts_b",
+ "uart_rts_b";
+ function = "uart_b";
+ };
+ };
+
uart_c_pins: uart_c {
mux {
groups = "uart_tx_c",
@@ -306,6 +338,14 @@
};
};
+ uart_c_cts_rts_pins: uart_c_cts_rts {
+ mux {
+ groups = "uart_cts_c",
+ "uart_rts_c";
+ function = "uart_c";
+ };
+ };
+
i2c_a_pins: i2c_a {
mux {
groups = "i2c_sck_a",
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 53ed7a5f50ab..7d7fd87f094b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -82,6 +82,14 @@
};
};
+ uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
+ mux {
+ groups = "uart_cts_ao_a",
+ "uart_rts_ao_a";
+ function = "uart_ao";
+ };
+ };
+
uart_ao_b_pins: uart_ao_b {
mux {
groups = "uart_tx_ao_b", "uart_rx_ao_b";
@@ -89,6 +97,14 @@
};
};
+ uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
+ mux {
+ groups = "uart_cts_ao_b",
+ "uart_rts_ao_b";
+ function = "uart_ao_b";
+ };
+ };
+
remote_input_ao_pins: remote_input_ao {
mux {
groups = "remote_input_ao";
@@ -164,6 +180,14 @@
};
};
+ uart_a_cts_rts_pins: uart_a_cts_rts {
+ mux {
+ groups = "uart_cts_a",
+ "uart_rts_a";
+ function = "uart_a";
+ };
+ };
+
uart_b_pins: uart_b {
mux {
groups = "uart_tx_b",
@@ -172,6 +196,14 @@
};
};
+ uart_b_cts_rts_pins: uart_b_cts_rts {
+ mux {
+ groups = "uart_cts_b",
+ "uart_rts_b";
+ function = "uart_b";
+ };
+ };
+
uart_c_pins: uart_c {
mux {
groups = "uart_tx_c",
@@ -180,6 +212,14 @@
};
};
+ uart_c_cts_rts_pins: uart_c_cts_rts {
+ mux {
+ groups = "uart_cts_c",
+ "uart_rts_c";
+ function = "uart_c";
+ };
+ };
+
i2c_a_pins: i2c_a {
mux {
groups = "i2c_sck_a",
--
2.11.0
^ permalink raw reply related
* [PATCH 1/4] tty: serial: meson: allow baud-rates higher than 115200
From: Martin Blumenstingl @ 2017-01-15 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115223255.10350-1-martin.blumenstingl@googlemail.com>
The vendor driver allows setting baud-rates higher than 115200 baud.
There is a check in the vendor driver which prevents using more than
115200 baud during startup, however it does not have such a check in
.set_termios.
Higher baud-rates are often used by the bluetooth modules embedded into
the SDIO wifi chips (Amlogic devices use brcmfmac based wifi chips quite
often, 2000000 baud seems to be a common value for the UART baud-rate in
Amlogic's "libbt").
I have tested this on a Meson GXL device with uart_A (to which the
bluetooth module is connected, where initialization times out with
115200 baud) and uart_AO (which I manually set to 2000000 baud and then
connected with my USB UART adapter to that).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/tty/serial/meson_uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
index 6aea0f4a9165..60f16795d16b 100644
--- a/drivers/tty/serial/meson_uart.c
+++ b/drivers/tty/serial/meson_uart.c
@@ -364,7 +364,7 @@ static void meson_uart_set_termios(struct uart_port *port,
writel(val, port->membase + AML_UART_CONTROL);
- baud = uart_get_baud_rate(port, termios, old, 9600, 115200);
+ baud = uart_get_baud_rate(port, termios, old, 9600, 4000000);
meson_uart_change_speed(port, baud);
port->read_status_mask = AML_UART_TX_FIFO_WERR;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/4] Bluetooth support for GXBB/GXL/GXM based devices
From: Martin Blumenstingl @ 2017-01-15 22:32 UTC (permalink / raw)
To: linux-arm-kernel
This adds the missing kernel bits for Bluetooth support on the
Tronsmart Vega S95 (GXBB based) boards as well as for the GXL
P230/P231 and GXM Q200/Q201 reference boards.
The Bluetooth functionality on these boards is provided by the
SDIO wifi/Bluetooth combo-chip (Broadcom bcm43xx based). The
Bluetooth module on that combo-chip has to be taken out of reset,
which is taken care of the GPIO in the sdio_pwrseq.
Once the module is taken out of reset it can be set up from userspace
using the "hciattach" tool from bluez, which talks to the Bluetooth
module which is connected to one of the serial ports (in our case
uart_A). To get the Bluetooth module initialized within the timeout
defined by "hciattach" (and to achieve usable speeds for Bluetooth
transfers) the communication uses a speed of 2000000 baud, which was
not supported by meson_uart before.
NOTE: The .dts-changes from this series depends on my previous series
"add support for uart_AO_B" - see [0]
[0] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001982.html
Martin Blumenstingl (4):
tty: serial: meson: allow baud-rates higher than 115200
ARM64: dts: meson-gx: add the serial CTS and RTS pin groups
ARM64: dts: meson-gx-p23x-q20x: enable the Bluetooth module
ARM64: dts: meson-gxbb-vega-s95: enable the Bluetooth module
.../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 12 ++++++-
.../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 9 +++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 40 ++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 40 ++++++++++++++++++++++
drivers/tty/serial/meson_uart.c | 2 +-
5 files changed, 101 insertions(+), 2 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 2/2] ARM64: dts: meson-gx: add the missing uart_AO_B
From: Martin Blumenstingl @ 2017-01-15 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115222029.8271-1-martin.blumenstingl@googlemail.com>
This adds the missing node for the uart_AO_B port to the meson-gx.dtsi
(as this is supported by GXBB, GXL and GXM) along with the required
pinctrl pins. This is required as some boards are using it (the boards
from the Khadas VIM series for example have it exposed on the pin
headers).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 ++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 7 +++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 7 +++++++
3 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index cddad8c795ec..5ece505dca71 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -324,6 +324,14 @@
status = "disabled";
};
+ uart_AO_B: serial at 4e0 {
+ compatible = "amlogic,meson-uart";
+ reg = <0x0 0x004e0 0x0 0x14>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>;
+ status = "disabled";
+ };
+
ir: ir at 580 {
compatible = "amlogic,meson-gxbb-ir";
reg = <0x0 0x00580 0x0 0x40>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 5d686334f692..474435e21759 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -138,6 +138,13 @@
};
};
+ uart_ao_b_pins: uart_ao_b {
+ mux {
+ groups = "uart_tx_ao_b", "uart_rx_ao_b";
+ function = "uart_ao_b";
+ };
+ };
+
remote_input_ao_pins: remote_input_ao {
mux {
groups = "remote_input_ao";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index bb2842f8a08f..53ed7a5f50ab 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -82,6 +82,13 @@
};
};
+ uart_ao_b_pins: uart_ao_b {
+ mux {
+ groups = "uart_tx_ao_b", "uart_rx_ao_b";
+ function = "uart_ao_b";
+ };
+ };
+
remote_input_ao_pins: remote_input_ao {
mux {
groups = "remote_input_ao";
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] pinctrl: meson: fix uart_ao_b for GXBB and GXL/GXM
From: Martin Blumenstingl @ 2017-01-15 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115222029.8271-1-martin.blumenstingl@googlemail.com>
The GXBB and GXL/GXM pinctrl drivers had a configuration which conflicts
with uart_ao_a. According to the GXBB ("S905") datasheet the AO UART
functions are:
- GPIOAO_0: Func1 = UART_TX_AO_A (bit 12), Func2 = UART_TX_AO_B (bit 26)
- GPIOAO_1: Func1 = UART_RX_AO_A (bit 11), Func2 = UART_RX_AO_B (bit 25)
- GPIOAO_4: Func2 = UART_TX_AO_B (bit 24)
- GPIOAO_5: Func2 = UART_RX_AO_B (bit 25)
The existing definition for uart_AO_A already uses GPIOAO_0 and GPIOAO_1.
The old definition of uart_AO_B however was broken, as it used GPIOAO_0
for TX (which would be fine) and two pins (GPIOAO_1 and GPIOAO_5) for RX
(which does not make any sense).
This fixes the uart_AO_B configuration by moving it to GPIOAO_4 and
GPIOAO_5 (it would be possible to use GPIOAO_0 and GPIOAO_1 in theory,
but all existing hardware uses uart_AO_A there).
The fix for GXBB and GXL/GXM is identical since it seems that these
specific pins are identical on both SoC variants.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 7 +++----
drivers/pinctrl/meson/pinctrl-meson-gxl.c | 7 +++----
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
index c3928aa3fefa..e0bca4df2a2f 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -253,9 +253,8 @@ static const unsigned int uart_tx_ao_a_pins[] = { PIN(GPIOAO_0, 0) };
static const unsigned int uart_rx_ao_a_pins[] = { PIN(GPIOAO_1, 0) };
static const unsigned int uart_cts_ao_a_pins[] = { PIN(GPIOAO_2, 0) };
static const unsigned int uart_rts_ao_a_pins[] = { PIN(GPIOAO_3, 0) };
-static const unsigned int uart_tx_ao_b_pins[] = { PIN(GPIOAO_0, 0) };
-static const unsigned int uart_rx_ao_b_pins[] = { PIN(GPIOAO_1, 0),
- PIN(GPIOAO_5, 0) };
+static const unsigned int uart_tx_ao_b_pins[] = { PIN(GPIOAO_4, 0) };
+static const unsigned int uart_rx_ao_b_pins[] = { PIN(GPIOAO_5, 0) };
static const unsigned int uart_cts_ao_b_pins[] = { PIN(GPIOAO_2, 0) };
static const unsigned int uart_rts_ao_b_pins[] = { PIN(GPIOAO_3, 0) };
@@ -498,7 +497,7 @@ static struct meson_pmx_group meson_gxbb_aobus_groups[] = {
GPIO_GROUP(GPIOAO_13, 0),
/* bank AO */
- GROUP(uart_tx_ao_b, 0, 26),
+ GROUP(uart_tx_ao_b, 0, 24),
GROUP(uart_rx_ao_b, 0, 25),
GROUP(uart_tx_ao_a, 0, 12),
GROUP(uart_rx_ao_a, 0, 11),
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxl.c b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
index 25694f7094c7..b69743b07a1d 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxl.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
@@ -214,9 +214,8 @@ static const unsigned int uart_tx_ao_a_pins[] = { PIN(GPIOAO_0, 0) };
static const unsigned int uart_rx_ao_a_pins[] = { PIN(GPIOAO_1, 0) };
static const unsigned int uart_cts_ao_a_pins[] = { PIN(GPIOAO_2, 0) };
static const unsigned int uart_rts_ao_a_pins[] = { PIN(GPIOAO_3, 0) };
-static const unsigned int uart_tx_ao_b_pins[] = { PIN(GPIOAO_0, 0) };
-static const unsigned int uart_rx_ao_b_pins[] = { PIN(GPIOAO_1, 0),
- PIN(GPIOAO_5, 0) };
+static const unsigned int uart_tx_ao_b_pins[] = { PIN(GPIOAO_4, 0) };
+static const unsigned int uart_rx_ao_b_pins[] = { PIN(GPIOAO_5, 0) };
static const unsigned int uart_cts_ao_b_pins[] = { PIN(GPIOAO_2, 0) };
static const unsigned int uart_rts_ao_b_pins[] = { PIN(GPIOAO_3, 0) };
@@ -409,7 +408,7 @@ static struct meson_pmx_group meson_gxl_aobus_groups[] = {
GPIO_GROUP(GPIOAO_9, 0),
/* bank AO */
- GROUP(uart_tx_ao_b, 0, 26),
+ GROUP(uart_tx_ao_b, 0, 24),
GROUP(uart_rx_ao_b, 0, 25),
GROUP(uart_tx_ao_a, 0, 12),
GROUP(uart_rx_ao_a, 0, 11),
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] add support for uart_AO_B
From: Martin Blumenstingl @ 2017-01-15 22:20 UTC (permalink / raw)
To: linux-arm-kernel
This adds the uart_AO_B serial port and the related pinctrl nodes to
meson-gx.
Due to a bug in the current GXBB and GXL/GXM pinctrl code uart_AO_B
could not be used when uart_AO(_A) was enabled at the same time. The
reason for this is that uart_AO_A and uart_AO_B were both trying to
request the same pin as their RX pin (GPIOAO_1). uart_AO_B also
requests a second pin for it's RX (GPIOAO_5), which does not make any
sense.
Thus uart_AO_B is changed to only use GPIOAO_5 for RX and GPIOAO_4
for TX, which is also what the Amlogic reference kernel does.
Adding uart_AO_B is preparation work for adding support for the
Khadas VIM and VIM Pro boards, as these are both exposing uart_AO_B
on the pin-header.
Martin Blumenstingl (2):
pinctrl: meson: fix uart_ao_b for GXBB and GXL/GXM
ARM64: dts: meson-gx: add the missing uart_AO_B
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 ++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 7 +++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 7 +++++++
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 7 +++----
drivers/pinctrl/meson/pinctrl-meson-gxl.c | 7 +++----
5 files changed, 28 insertions(+), 8 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6qdl: Fix "ERROR: code indent should use tabs where possible"
From: Jagan Teki @ 2017-01-15 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484517012-13321-1-git-send-email-jagan@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Fixed code indent tabs in respetcive imx6qdl dtsi files and
also add space on imx6qdl-icore-rqs.dtsi on usdhc bus-width nodes.
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi | 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index b6078b1..91991d6 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -235,7 +235,7 @@
/* VDD_1P8 (1+R1/R2 = 2.505): GPS/VideoIn/ENET-PHY */
reg_1p8v: sw2 {
- regulator-name = "vdd1p8";
+ regulator-name = "vdd1p8";
regulator-min-microvolt = <1033310>;
regulator-max-microvolt = <2004000>;
lltc,fb-voltage-divider = <301000 200000>;
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 19cf036..a208e7e 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -227,7 +227,7 @@
/* VDD_1P8 (1+R1/R2 = 2.505): GPS/VideoIn/ENET-PHY */
reg_1p8v: sw2 {
- regulator-name = "vdd1p8";
+ regulator-name = "vdd1p8";
regulator-min-microvolt = <1033310>;
regulator-max-microvolt = <2004000>;
lltc,fb-voltage-divider = <301000 200000>;
diff --git a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
index 90200fa..67613dd 100644
--- a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
@@ -162,7 +162,7 @@
/* VDD_1P8 (1+R1/R2 = 2.505): ENET-PHY */
reg_1p8v: sw2 {
- regulator-name = "vdd1p8";
+ regulator-name = "vdd1p8";
regulator-min-microvolt = <1033310>;
regulator-max-microvolt = <2004000>;
lltc,fb-voltage-divider = <301000 200000>;
diff --git a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
index d5c3aa8..6e29d8b 100644
--- a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
@@ -223,7 +223,7 @@
pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
vmcc-supply = <®_sd3_vmmc>;
cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
- bus-witdh=<4>;
+ bus-witdh = <4>;
no-1-8-v;
status = "okay";
};
@@ -234,7 +234,7 @@
pinctrl-1 = <&pinctrl_usdhc4_100mhz>;
pinctrl-2 = <&pinctrl_usdhc4_200mhz>;
vmcc-supply = <®_sd4_vmmc>;
- bus-witdh=<8>;
+ bus-witdh = <8>;
no-1-8-v;
non-removable;
status = "okay";
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6ul-isiot: Add eMMC node
From: Jagan Teki @ 2017-01-15 21:50 UTC (permalink / raw)
To: linux-arm-kernel
From: Jagan Teki <jagan@amarulasolutions.com>
Add usdhc2 node, which is eMMC for Engicam Is.IoT MX6UL modules.
dmesg:
-----
mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
mmc1: new DDR MMC card at address 0001
mmcblk1: mmc1:0001 M62704 3.53 GiB
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Cc: Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm/boot/dts/imx6ul-isiot.dts | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul-isiot.dts b/arch/arm/boot/dts/imx6ul-isiot.dts
index 077bc26..acb97bd 100644
--- a/arch/arm/boot/dts/imx6ul-isiot.dts
+++ b/arch/arm/boot/dts/imx6ul-isiot.dts
@@ -76,6 +76,15 @@
status = "okay";
};
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ cd-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>;
+ bus-width = <8>;
+ no-1-8-v;
+ status = "okay";
+};
+
&iomuxc {
pinctrl_uart1: uart1grp {
fsl,pins = <
@@ -116,4 +125,20 @@
MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170f9
>;
};
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x17070
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x10070
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17070
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17070
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17070
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17070
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17070
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17070
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17070
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17070
+ MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x17070
+ >;
+ };
};
--
1.9.1
^ permalink raw reply related
* [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS
From: Laurent Pinchart @ 2017-01-15 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e5c066f-ddf6-30ce-392e-79bd0f401a18@arm.com>
Hi Robin,
On Friday 13 Jan 2017 12:17:24 Robin Murphy wrote:
> On 13/01/17 11:59, Geert Uytterhoeven wrote:
> > On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy wrote:
> >> On 13/01/17 11:07, Geert Uytterhoeven wrote:
> >>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
> >>> This allows to allocate physically contiguous DMA buffers on arm64
> >>> systems with an IOMMU.
> >>
> >> Can anyone explain what this attribute is actually used for? I've never
> >> quite figured it out.
> >
> > My understanding is that DMA_ATTR_FORCE_CONTIGUOUS is needed when using
> > an IOMMU but wanting the buffers to be both contiguous in IOVA space and
> > physically contiguous to allow passing to devices without IOMMU.
> >
> > Main users are graphic and remote processors.
>
> Sure, I assumed it must be to do with buffer sharing, but the systems
> I'm aware of which have IOMMUs in their media subsystems tend to have
> them in front of every IP block involved, so I was curious as to what
> bit of non-IOMMU hardware wanted to play too. The lone in-tree use in
> the Exynos DRM driver was never very revealing, and the new one I see in
> the Qualcomm PIL driver frankly looks redundant to me.
If two (or more) devices with different memory requirements are involved in
buffer sharing, we need to either allocate and export buffers from the device
with the strictest requirements, or to implement a central buffer allocator.
In any case, I don't think DMA_ATTR_FORCE_CONTIGUOUS is the right solution to
that problem.
Forcing contiguous allocation can however help with performance optimization,
as mapping physically contiguous memory through IOMMUs can make use of larger
page sizes.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Stefan Wahren @ 2017-01-15 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484512950.2026.4.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Januar 2017 um 21:42 geschrieben:
>
>
> Hi Stefan,
>
> On Tue, 2016-12-27 at 00:03 +0100, Stefan Wahren wrote:
> > Hi J?rg,
> > ...
> > I also rebased an old patch from Shawn Guo [2] with pre_req and
> > post_req support, tried to call the DMA channel callback from the
> > interrupt context instead of scheduling the tasklet within the DMA
> > engine driver and implement CMD23 support [3]. But none of them show
> > any measurable performance improvement.
>
> I tested the three patches after disabling any debugging options in the
> config. There is no performance gain, but the timings have changed.
> Please have a look at the attached graphs. The time between complete()
> and wait_for_completion() is reduced to 15us whereas the time from
> return from wait_for_completion() to return to sdio_readsb() increases
> to 23us (from maybe 2us before).
that confirms my results. I think you are searching on the wrong layer. You better step "back" and take a look at the whole transfer instead of single blocks. Maybe there are some bigger delays.
Stefan
>
> J?rg
^ permalink raw reply
* [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Andrew Lunn @ 2017-01-15 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a9ea1f45-b9a5-d840-68e0-9bf9bc7a6598@gmail.com>
> > What exactly is the relationship between these devices (a ascii-art tree
> > or sysfs tree output might be nice) so I can try to understand what is
> > going on here.
Hi Greg, Florian
A few diagrams and trees which might help understand what is going on.
The first diagram comes from the 2008 patch which added all this code:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
We have an ethernet switch and a host CPU. The switch is connected to
the CPU in two different ways. RGMII allows us to get Ethernet frames
from the CPU into the switch. MIImgmt, is the management bus normally
used for Ethernet PHYs, but Marvell switches also use it for Managing
switches.
The diagram above is the simplest setup. You can have multiple
Ethernet switches, connected together via switch ports. Each switch
has its own MIImgmt connect to the CPU, but there is only one RGMII
link.
When this code was designed back in 2008, it was decided to represent
this is a platform device, and it has a platform_data, which i have
slightly edited to keep it simple:
struct dsa_platform_data {
/*
* Reference to a Linux network interface that connects
* to the root switch chip of the tree.
*/
struct device *netdev;
/*
* Info structs describing each of the switch chips
* connected via this network interface.
*/
int nr_chips;
struct dsa_chip_data *chip;
};
This netdev is the CPU side of the RGMII interface.
Each switch has a dsa_chip_data, again edited:
struct dsa_chip_data {
/*
* How to access the switch configuration registers.
*/
struct device *host_dev;
int sw_addr;
...
}
The host_dev is the CPU side of the MIImgmt, and we have the address
the switch is using on the bus.
During probe of this platform device, we need to get from the
struct device *netdev to a struct net_device *dev.
So the code looks in the device net class to find the device
| | | |-- f1074000.ethernet
| | | | |-- deferred_probe
| | | | |-- driver -> ../../../../../bus/platform/drivers/mvneta
| | | | |-- driver_override
| | | | |-- modalias
| | | | |-- net
| | | | | `-- eth1
| | | | | |-- addr_assign_type
| | | | | |-- address
| | | | | |-- addr_len
| | | | | |-- broadcast
| | | | | |-- carrier
| | | | | |-- carrier_changes
| | | | | |-- deferred_probe
| | | | | |-- device -> ../../../f1074000.ethernet
and then use container_of() to get the net_device.
Similarly, the code needs to get from struct device *host_dev to a struct mii_bus *.
| | | |-- f1072004.mdio
| | | | |-- deferred_probe
| | | | |-- driver -> ../../../../../bus/platform/drivers/orion-mdio
| | | | |-- driver_override
| | | | |-- mdio_bus
| | | | | `-- f1072004.mdio-mi
| | | | | |-- deferred_probe
| | | | | |-- device -> ../../../f1072004.mdio
Andrew
^ permalink raw reply
* Nokia N900: mixers changed between 4.9 and 4.10-rc3, no longer can use in-call speaker
From: Jarkko Nikula @ 2017-01-15 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115100533.GA15816@amd>
On 01/15/2017 12:05 PM, Pavel Machek wrote:
>>> So regression seems to be between v4.9 and v4.10. Any ideas?
>>
>> Interesting... seems there are no sound relevant changes after v4.9.
>>
>> Looks like there are only three commits after v4.9 for sound/soc which
>> are built for Nokia N900:
>>
>> e411b0b5eb9b65257a050eac333d181d6e00e2c6
>> e7aa450fe17890e59db7d3c2d8eff5b6b41fc531
>> 63c3194b82530bd71fd49db84eb7ab656b8d404a
>>
>> Maybe something not related to sound/soc could broke it?
>
> Lets see.
>
> a9042defa29a01cc538b742eab047848e9b5ae14 -- works ok.
> ce38207f161513ee3d2bd3860489f07ebe65bc78 --
>
> alsactl: set_control:1328: failed to obtain info for control #229 (No
> such file or directory)
>
I'm unable to test older kernels at the moment since modules don't load
by some reason (bluetooth: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err
0)). Probably some recent regression in my debian/testing installation
since the same configs were working before.
However v4.9.4 works and with it I can see there is an issue with these
aic3x controls:
amixer: Unable to find simple control 'Left DAC_L1 Mixer Line',0
amixer: Unable to find simple control 'Right DAC_R1 Mixer Line',0
At quick look I don't see why above commits could cause it. Maybe
regression happened earlier between v4.6 and v4.9?
--
Jarkko
^ permalink raw reply
* [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Florian Fainelli @ 2017-01-15 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115173949.GA19268@kroah.com>
On 01/15/2017 09:39 AM, Greg KH wrote:
> On Sun, Jan 15, 2017 at 09:27:22AM -0800, Florian Fainelli wrote:
>>
>>
>> On 01/15/2017 03:06 AM, Greg KH wrote:
>>> On Sat, Jan 14, 2017 at 01:47:09PM -0800, Florian Fainelli wrote:
>>>> Now that the base device driver code provides an identical
>>>> implementation of dev_find_class() utilize device_find_class() instead
>>>> of our own version of it.
>>>>
>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>> ---
>>>> net/dsa/dsa.c | 22 ++--------------------
>>>> 1 file changed, 2 insertions(+), 20 deletions(-)
>>>>
>>>> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
>>>> index 2306d1b87c83..77fa4c4f5828 100644
>>>> --- a/net/dsa/dsa.c
>>>> +++ b/net/dsa/dsa.c
>>>> @@ -455,29 +455,11 @@ EXPORT_SYMBOL_GPL(dsa_switch_resume);
>>>> #endif
>>>>
>>>> /* platform driver init and cleanup *****************************************/
>>>> -static int dev_is_class(struct device *dev, void *class)
>>>> -{
>>>> - if (dev->class != NULL && !strcmp(dev->class->name, class))
>>>> - return 1;
>>>> -
>>>> - return 0;
>>>> -}
>>>> -
>>>> -static struct device *dev_find_class(struct device *parent, char *class)
>>>> -{
>>>> - if (dev_is_class(parent, class)) {
>>>> - get_device(parent);
>>>> - return parent;
>>>> - }
>>>> -
>>>> - return device_find_child(parent, class, dev_is_class);
>>>> -}
>>>> -
>>>> struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev)
>>>> {
>>>> struct device *d;
>>>>
>>>> - d = dev_find_class(dev, "mdio_bus");
>>>> + d = device_find_class(dev, "mdio_bus");
>>>> if (d != NULL) {
>>>> struct mii_bus *bus;
>>>
>>> You want a peer of your device on a specific class? What is this for?
>>
>> It's not a peer of our device, it's a separate device reference from the
>> one looked up in the "net" class. In the classic, and now deprecated DSA
>> device driver model, a "dsa" platform device would represent one or more
>> Ethernet switches, connected via a MDIO bus (this reference above), and
>> one Ethernet device (the CPU/host/management interface). This was
>> completely violating the Linux device driver model and imposed
>> limitations on what bus would be used, and we did not have proper struct
>> device references (therefore no adequate hierarchy either).
>>
>> Thanks to the work of Andrew, we now have proper MDIO, SPI, GPIO, I2C,
>> PCI, platform and drivers that allow us to register with DSA as a
>> specialized kind of device (so we are now finally using the right Linux
>> Device Driver model). What we still need though, in order to our switch
>> to the networking stack is a reference to the master/host network device
>> since we mangle packets in and out of it.
>
> Ok, but where in the tree are you trying to find this other device? Are
> you just going to randomly find any device that happens to be of the
> specific class type? That seems really fragile and broken :(
The search is not really random, since the platform data for the DSA
switch we want to register gives us a reference to a device registered
via any bus type, and we know (by contract it has to) that it has to
provide a network device of some kind, we do a specific search in the
"net" class for that purpose. I agree this is not great.
>
> You should NEVER have to walk the device tree to find stuff. Why can't
> you have a pointer to the device you need to talk to some other way?
We do, I think the existing code just tries to be extra careful here and
make sure that the device reference we got is actually part of the "net"
class, indicating that the reference passed is indeed pointing to a
network device, and not a random device.
>
> What exactly is the relationship between these devices (a ascii-art tree
> or sysfs tree output might be nice) so I can try to understand what is
> going on here.
OK, let me try and let's take the case of only one Ethernet switch in
the system for all simplicity:
- switch device drivers get probed by any kind of bus allocate and
register a dsa_switch with dsa_register_switch()
- this switch device has platform data (struct dsa_chip_data) that
describes its port layout (number of ports mostly) and has one struct
device references to which Ethernet network interface these ports connect to
- a dsa_switch_tree is created, this struct dsa_switch is attached to
the dsa_switch_tree at position 0 in the tree, we invoke a bunch of
switch driver operations
- we conclude with attaching this dsa_switch_tree to the network device
we looked up and assigning the tree to the dsa_ptr member
Documentation/networking/dsa/dsa.txt has some ascii art drawing that
sort of capture what is going on.
--
Florian
^ permalink raw reply
* [PATCH net-next v3 00/10] net: dsa: Support for pdata in dsa2
From: Greg KH @ 2017-01-15 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc0d9ea7-17ee-abc3-b2aa-4d241413b9a3@gmail.com>
On Sun, Jan 15, 2017 at 09:40:24AM -0800, Florian Fainelli wrote:
> On 01/15/2017 03:08 AM, Greg KH wrote:
> > On Sat, Jan 14, 2017 at 01:47:03PM -0800, Florian Fainelli wrote:
> >> Hi all,
> >>
> >> This is not exactly new, and was sent before, although back then, I did not
> >> have an user of the pre-declared MDIO board information, but now we do. Note
> >> that I have additional changes queued up to have b53 register platform data for
> >> MIPS bcm47xx and bcm63xx.
> >>
> >> Yes I know that we should have the Orion platforms eventually be converted to
> >> Device Tree, but until that happens, I don't want any remaining users of the
> >> old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu)
> >> and, there will be platforms out there that most likely won't never see DT
> >> coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant
> >> future).
> >>
> >> We would probably want the whole series to be merged via David Miller's tree
> >> to simplify things.
> >>
> >> Greg, can you Ack/Nack patch 5 since it touched the core LDD?
> >
> > I've NAKed them for now, you need to describe what you are trying to do
> > here, as it doesn't make any sense to me at the moment.
>
> For one, this is moving *existing* code from net/dsa/dsa.c part into the
> device core for device_find_class() and part into the network device
> core for dev_to_net_device(). Patch 8 is where this actually gets used.
> See my individual replies for more details.
>
> Even though the existing code is there in net/dsa/dsa.c, at this point,
> and for the sake of getting these patches merged via David, I can
> probably just keep it where it is (like what patch series v1 did) and
> just namespace it with dsa_. Later on, if this is deemed valuable to
> other parts of the kernel, I can try to relocate it to the device core,
> does that sound acceptable?
Nope!
I really want to try to understand what you all are doing with the
device tree that you feel that blindly walking it actually comes up with
a valid result.
See my other email about wanting to see a tree, we can take it from that
thread to try to consolidate all of these different ones.
And sorry, I know you are just trying to move code around, but this
isn't the first time this has come up, and I think it needs to be
resolved properly.
thanks,
greg k-h
^ permalink raw reply
* [PATCH net-next v3 07/10] net: Relocate dev_to_net_device() into core
From: Greg KH @ 2017-01-15 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <621be9fe-0869-2d0a-fd49-97468c2d4972@gmail.com>
On Sun, Jan 15, 2017 at 09:20:06AM -0800, Florian Fainelli wrote:
>
>
> On 01/15/2017 03:07 AM, Greg KH wrote:
> > On Sat, Jan 14, 2017 at 01:47:10PM -0800, Florian Fainelli wrote:
> >> dev_to_net_device() is moved from net/dsa/dsa.c to net/core/dev.c since
> >> it going to be used by net/dsa/dsa2.c and the namespace of the function
> >> justifies making it available to other users potentially.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >> include/linux/netdevice.h | 2 ++
> >> net/core/dev.c | 19 +++++++++++++++++++
> >> net/dsa/dsa.c | 18 ------------------
> >> 3 files changed, 21 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> >> index 97ae0ac513ee..6d021c37b774 100644
> >> --- a/include/linux/netdevice.h
> >> +++ b/include/linux/netdevice.h
> >> @@ -4390,4 +4390,6 @@ do { \
> >> #define PTYPE_HASH_SIZE (16)
> >> #define PTYPE_HASH_MASK (PTYPE_HASH_SIZE - 1)
> >>
> >> +struct net_device *dev_to_net_device(struct device *dev);
> >> +
> >> #endif /* _LINUX_NETDEVICE_H */
> >> diff --git a/net/core/dev.c b/net/core/dev.c
> >> index ad5959e56116..7547e2ccc06b 100644
> >> --- a/net/core/dev.c
> >> +++ b/net/core/dev.c
> >> @@ -8128,6 +8128,25 @@ const char *netdev_drivername(const struct net_device *dev)
> >> return empty;
> >> }
> >>
> >> +struct net_device *dev_to_net_device(struct device *dev)
> >> +{
> >> + struct device *d;
> >> +
> >> + d = device_find_class(dev, "net");
> >> + if (d) {
> >> + struct net_device *nd;
> >> +
> >> + nd = to_net_dev(d);
> >> + dev_hold(nd);
> >> + put_device(d);
> >> +
> >> + return nd;
> >> + }
> >> +
> >> + return NULL;
> >> +}
> >> +EXPORT_SYMBOL_GPL(dev_to_net_device);
> >
> > This really isn't just a "struct device to net device cast" type
> > function, (otherwise a simple container_of() would work). You are
> > walking the device tree and assuming it is in a specific order so that
> > this function works. You better document the hell out of this,
> > otherwise people are going to try to use this and get very confused,
> > very quickly...
>
> Fair enough. Does that make it clearer how the device_find_class() is
> used though? Maybe device_find_class() should be named
> device_find_by_class_name() instead?
Better, but you are just poking around randomly in the device tree and
"hoping" you get it right. What happens if devices move around? You
are assuming some sort of heirachy here that I don't understand at
all...
thanks,
greg k-h
^ permalink raw reply
* [PATCH net-next v3 00/10] net: dsa: Support for pdata in dsa2
From: Florian Fainelli @ 2017-01-15 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115110831.GH26374@kroah.com>
On 01/15/2017 03:08 AM, Greg KH wrote:
> On Sat, Jan 14, 2017 at 01:47:03PM -0800, Florian Fainelli wrote:
>> Hi all,
>>
>> This is not exactly new, and was sent before, although back then, I did not
>> have an user of the pre-declared MDIO board information, but now we do. Note
>> that I have additional changes queued up to have b53 register platform data for
>> MIPS bcm47xx and bcm63xx.
>>
>> Yes I know that we should have the Orion platforms eventually be converted to
>> Device Tree, but until that happens, I don't want any remaining users of the
>> old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu)
>> and, there will be platforms out there that most likely won't never see DT
>> coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant
>> future).
>>
>> We would probably want the whole series to be merged via David Miller's tree
>> to simplify things.
>>
>> Greg, can you Ack/Nack patch 5 since it touched the core LDD?
>
> I've NAKed them for now, you need to describe what you are trying to do
> here, as it doesn't make any sense to me at the moment.
For one, this is moving *existing* code from net/dsa/dsa.c part into the
device core for device_find_class() and part into the network device
core for dev_to_net_device(). Patch 8 is where this actually gets used.
See my individual replies for more details.
Even though the existing code is there in net/dsa/dsa.c, at this point,
and for the sake of getting these patches merged via David, I can
probably just keep it where it is (like what patch series v1 did) and
just namespace it with dsa_. Later on, if this is deemed valuable to
other parts of the kernel, I can try to relocate it to the device core,
does that sound acceptable?
--
Florian
^ permalink raw reply
* [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Greg KH @ 2017-01-15 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fc247aeb-a8d6-5ba9-c26d-cb057a5ac34d@gmail.com>
On Sun, Jan 15, 2017 at 09:27:22AM -0800, Florian Fainelli wrote:
>
>
> On 01/15/2017 03:06 AM, Greg KH wrote:
> > On Sat, Jan 14, 2017 at 01:47:09PM -0800, Florian Fainelli wrote:
> >> Now that the base device driver code provides an identical
> >> implementation of dev_find_class() utilize device_find_class() instead
> >> of our own version of it.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >> net/dsa/dsa.c | 22 ++--------------------
> >> 1 file changed, 2 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> >> index 2306d1b87c83..77fa4c4f5828 100644
> >> --- a/net/dsa/dsa.c
> >> +++ b/net/dsa/dsa.c
> >> @@ -455,29 +455,11 @@ EXPORT_SYMBOL_GPL(dsa_switch_resume);
> >> #endif
> >>
> >> /* platform driver init and cleanup *****************************************/
> >> -static int dev_is_class(struct device *dev, void *class)
> >> -{
> >> - if (dev->class != NULL && !strcmp(dev->class->name, class))
> >> - return 1;
> >> -
> >> - return 0;
> >> -}
> >> -
> >> -static struct device *dev_find_class(struct device *parent, char *class)
> >> -{
> >> - if (dev_is_class(parent, class)) {
> >> - get_device(parent);
> >> - return parent;
> >> - }
> >> -
> >> - return device_find_child(parent, class, dev_is_class);
> >> -}
> >> -
> >> struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev)
> >> {
> >> struct device *d;
> >>
> >> - d = dev_find_class(dev, "mdio_bus");
> >> + d = device_find_class(dev, "mdio_bus");
> >> if (d != NULL) {
> >> struct mii_bus *bus;
> >
> > You want a peer of your device on a specific class? What is this for?
>
> It's not a peer of our device, it's a separate device reference from the
> one looked up in the "net" class. In the classic, and now deprecated DSA
> device driver model, a "dsa" platform device would represent one or more
> Ethernet switches, connected via a MDIO bus (this reference above), and
> one Ethernet device (the CPU/host/management interface). This was
> completely violating the Linux device driver model and imposed
> limitations on what bus would be used, and we did not have proper struct
> device references (therefore no adequate hierarchy either).
>
> Thanks to the work of Andrew, we now have proper MDIO, SPI, GPIO, I2C,
> PCI, platform and drivers that allow us to register with DSA as a
> specialized kind of device (so we are now finally using the right Linux
> Device Driver model). What we still need though, in order to our switch
> to the networking stack is a reference to the master/host network device
> since we mangle packets in and out of it.
Ok, but where in the tree are you trying to find this other device? Are
you just going to randomly find any device that happens to be of the
specific class type? That seems really fragile and broken :(
You should NEVER have to walk the device tree to find stuff. Why can't
you have a pointer to the device you need to talk to some other way?
What exactly is the relationship between these devices (a ascii-art tree
or sysfs tree output might be nice) so I can try to understand what is
going on here.
thanks,
greg k-h
^ permalink raw reply
* [PATCH net-next v3 05/10] drivers: base: Add device_find_class()
From: Florian Fainelli @ 2017-01-15 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115110455.GE26374@kroah.com>
On 01/15/2017 03:04 AM, Greg KH wrote:
> On Sat, Jan 14, 2017 at 01:47:08PM -0800, Florian Fainelli wrote:
>> Add a helper function to lookup a device reference given a class name.
>> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
>> make it more generic.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/base/core.c | 19 +++++++++++++++++++
>> include/linux/device.h | 1 +
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>> index 020ea7f05520..3dd6047c10d8 100644
>> --- a/drivers/base/core.c
>> +++ b/drivers/base/core.c
>> @@ -2065,6 +2065,25 @@ struct device *device_find_child(struct device *parent, void *data,
>> }
>> EXPORT_SYMBOL_GPL(device_find_child);
>>
>> +static int dev_is_class(struct device *dev, void *class)
>> +{
>> + if (dev->class != NULL && !strcmp(dev->class->name, class))
>> + return 1;
>> +
>> + return 0;
>> +}
>> +
>> +struct device *device_find_class(struct device *parent, char *class)
>
> Why are you using the char * for a class, and not just a pointer to
> "struct class"? That seems to be the most logical one, no need to rely
> on string comparisons here.
A more reflective name of what that does would probably be
device_find_by_class_name() or something alike.
>
> Also, what is this being used for? You aren't trying to walk up the
> device heirachy to find a specific "type" of device, are you? If so,
> ugh, I ranted about this in the past when the hyperv driver was trying
> to do such a thing...
What's a better way to do that though?
>
>> +{
>> + if (dev_is_class(parent, class)) {
>> + get_device(parent);
>> + return parent;
>> + }
>> +
>> + return device_find_child(parent, class, dev_is_class);
>
> You are trying to find a peer device with the same parent that belongs
> to a specific class?
Correct, network devices, and MDIO bus devices usually (always?) set
dev.parent.
>
> Again, what is this being used for?
See my other replies in patches 6, 7 and how it is used in patches 8 and
10 for instance.
>
> And all exported driver core functions should have full kerneldoc
> information for them so that people know how to use them, and what the
> constraints are (see device_find_child() as an example.) Please do that
> here as well because you are returning a pointer to a structure with the
> reference count incremented, callers need to know that.
Sure.
--
Florian
^ permalink raw reply
* [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Florian Fainelli @ 2017-01-15 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115110628.GF26374@kroah.com>
On 01/15/2017 03:06 AM, Greg KH wrote:
> On Sat, Jan 14, 2017 at 01:47:09PM -0800, Florian Fainelli wrote:
>> Now that the base device driver code provides an identical
>> implementation of dev_find_class() utilize device_find_class() instead
>> of our own version of it.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> net/dsa/dsa.c | 22 ++--------------------
>> 1 file changed, 2 insertions(+), 20 deletions(-)
>>
>> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
>> index 2306d1b87c83..77fa4c4f5828 100644
>> --- a/net/dsa/dsa.c
>> +++ b/net/dsa/dsa.c
>> @@ -455,29 +455,11 @@ EXPORT_SYMBOL_GPL(dsa_switch_resume);
>> #endif
>>
>> /* platform driver init and cleanup *****************************************/
>> -static int dev_is_class(struct device *dev, void *class)
>> -{
>> - if (dev->class != NULL && !strcmp(dev->class->name, class))
>> - return 1;
>> -
>> - return 0;
>> -}
>> -
>> -static struct device *dev_find_class(struct device *parent, char *class)
>> -{
>> - if (dev_is_class(parent, class)) {
>> - get_device(parent);
>> - return parent;
>> - }
>> -
>> - return device_find_child(parent, class, dev_is_class);
>> -}
>> -
>> struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev)
>> {
>> struct device *d;
>>
>> - d = dev_find_class(dev, "mdio_bus");
>> + d = device_find_class(dev, "mdio_bus");
>> if (d != NULL) {
>> struct mii_bus *bus;
>
> You want a peer of your device on a specific class? What is this for?
It's not a peer of our device, it's a separate device reference from the
one looked up in the "net" class. In the classic, and now deprecated DSA
device driver model, a "dsa" platform device would represent one or more
Ethernet switches, connected via a MDIO bus (this reference above), and
one Ethernet device (the CPU/host/management interface). This was
completely violating the Linux device driver model and imposed
limitations on what bus would be used, and we did not have proper struct
device references (therefore no adequate hierarchy either).
Thanks to the work of Andrew, we now have proper MDIO, SPI, GPIO, I2C,
PCI, platform and drivers that allow us to register with DSA as a
specialized kind of device (so we are now finally using the right Linux
Device Driver model). What we still need though, in order to our switch
to the networking stack is a reference to the master/host network device
since we mangle packets in and out of it.
>
>> @@ -495,7 +477,7 @@ static struct net_device *dev_to_net_device(struct device *dev)
>> {
>> struct device *d;
>>
>> - d = dev_find_class(dev, "net");
>> + d = device_find_class(dev, "net");
>> if (d != NULL) {
>> struct net_device *nd;
>
> Again, huh? What is the device heirachy here that is so odd that this
> type of function is needed?
An Ethernet switch managed by DSA needs to have one ore more references
to a host/CPU/management network interface, this is what this struct
device reference is here for.
--
Florian
^ permalink raw reply
* [PATCH net-next v3 07/10] net: Relocate dev_to_net_device() into core
From: Florian Fainelli @ 2017-01-15 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115110753.GG26374@kroah.com>
On 01/15/2017 03:07 AM, Greg KH wrote:
> On Sat, Jan 14, 2017 at 01:47:10PM -0800, Florian Fainelli wrote:
>> dev_to_net_device() is moved from net/dsa/dsa.c to net/core/dev.c since
>> it going to be used by net/dsa/dsa2.c and the namespace of the function
>> justifies making it available to other users potentially.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> include/linux/netdevice.h | 2 ++
>> net/core/dev.c | 19 +++++++++++++++++++
>> net/dsa/dsa.c | 18 ------------------
>> 3 files changed, 21 insertions(+), 18 deletions(-)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 97ae0ac513ee..6d021c37b774 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -4390,4 +4390,6 @@ do { \
>> #define PTYPE_HASH_SIZE (16)
>> #define PTYPE_HASH_MASK (PTYPE_HASH_SIZE - 1)
>>
>> +struct net_device *dev_to_net_device(struct device *dev);
>> +
>> #endif /* _LINUX_NETDEVICE_H */
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index ad5959e56116..7547e2ccc06b 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -8128,6 +8128,25 @@ const char *netdev_drivername(const struct net_device *dev)
>> return empty;
>> }
>>
>> +struct net_device *dev_to_net_device(struct device *dev)
>> +{
>> + struct device *d;
>> +
>> + d = device_find_class(dev, "net");
>> + if (d) {
>> + struct net_device *nd;
>> +
>> + nd = to_net_dev(d);
>> + dev_hold(nd);
>> + put_device(d);
>> +
>> + return nd;
>> + }
>> +
>> + return NULL;
>> +}
>> +EXPORT_SYMBOL_GPL(dev_to_net_device);
>
> This really isn't just a "struct device to net device cast" type
> function, (otherwise a simple container_of() would work). You are
> walking the device tree and assuming it is in a specific order so that
> this function works. You better document the hell out of this,
> otherwise people are going to try to use this and get very confused,
> very quickly...
Fair enough. Does that make it clearer how the device_find_class() is
used though? Maybe device_find_class() should be named
device_find_by_class_name() instead?
--
Florian
^ permalink raw reply
* Dropping device tree pinmux nodes for GPIO usage (Was: [PATCH 3/5] arm64: dts: sun50i: add MMC nodes)
From: Rask Ingemann Lambertsen @ 2017-01-15 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65GJFTnQZtWHCS7CAtA+Dry94o77aakPLr938BpQksLog@mail.gmail.com>
On Tue, Jan 03, 2017 at 10:52:12AM +0800, Chen-Yu Tsai wrote:
> On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> > +
> > + mmc0_default_cd_pin: mmc0_cd_pin at 0 {
> > + pins = "PF6";
> > + function = "gpio_in";
> > + bias-pull-up;
> > + };
>
> We are starting to drop pinmux nodes for gpio usage.
How do we get the equivalent of bias-pull-up/down and drive-strength if we
run across a pin that needs it?
--
Rask Ingemann Lambertsen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox