* [PATCH v6 23/23] drivers/fsi: Use asynchronous slave mode
From: Christopher Bostic @ 2017-04-10 19:47 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, rostedt, mingo, gregkh, devicetree,
linux-arm-kernel
Cc: Jeremy Kerr, joel, linux-kernel, andrew, alistair, benh,
Chris Bostic
In-Reply-To: <20170410194706.64280-1-cbostic@linux.vnet.ibm.com>
From: Jeremy Kerr <jk@ozlabs.org>
For slaves that are behind a software-clocked master, we want FSI CFAMs
to run asynchronously to the FSI clock, so set up our slaves to be in
async mode.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@linux.vnet.ibm.com>
---
drivers/fsi/fsi-core.c | 22 +++++++++++++++++++++-
drivers/fsi/fsi-master-gpio.c | 1 +
drivers/fsi/fsi-master.h | 2 ++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 747d0e3..a6ed34f 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -47,6 +47,7 @@
#define FSI_SMODE 0x0 /* R/W: Mode register */
#define FSI_SISC 0x8 /* R/W: Interrupt condition */
#define FSI_SSTAT 0x14 /* R : Slave status */
+#define FSI_LLMODE 0x100 /* R/W: Link layer mode register */
/*
* SMODE fields
@@ -62,6 +63,11 @@
#define FSI_SMODE_LBCRR_SHIFT 8 /* Clk ratio shift */
#define FSI_SMODE_LBCRR_MASK 0xf /* Clk ratio mask */
+/*
+ * LLMODE fields
+ */
+#define FSI_LLMODE_ASYNC 0x1
+
#define FSI_SLAVE_SIZE_23b 0x800000
static DEFINE_IDA(master_ida);
@@ -560,8 +566,8 @@ static void fsi_slave_release(struct device *dev)
static int fsi_slave_init(struct fsi_master *master, int link, uint8_t id)
{
+ uint32_t chip_id, llmode;
struct fsi_slave *slave;
- uint32_t chip_id;
uint8_t crc;
int rc;
@@ -597,6 +603,20 @@ static int fsi_slave_init(struct fsi_master *master, int link, uint8_t id)
return -ENODEV;
}
+ /* If we're behind a master that doesn't provide a self-running bus
+ * clock, put the slave into async mode
+ */
+ if (master->flags & FSI_MASTER_FLAG_SWCLOCK) {
+ llmode = cpu_to_be32(FSI_LLMODE_ASYNC);
+ rc = fsi_master_write(master, link, id,
+ FSI_SLAVE_BASE + FSI_LLMODE,
+ &llmode, sizeof(llmode));
+ if (rc)
+ dev_warn(&master->dev,
+ "can't set llmode on slave:%02x:%02x %d\n",
+ link, id, rc);
+ }
+
/* We can communicate with a slave; create the slave device and
* register.
*/
diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c
index 5d9e0b0..d5cce88 100644
--- a/drivers/fsi/fsi-master-gpio.c
+++ b/drivers/fsi/fsi-master-gpio.c
@@ -569,6 +569,7 @@ static int fsi_master_gpio_probe(struct platform_device *pdev)
master->gpio_mux = gpio;
master->master.n_links = 1;
+ master->master.flags = FSI_MASTER_FLAG_SWCLOCK;
master->master.read = fsi_master_gpio_read;
master->master.write = fsi_master_gpio_write;
master->master.term = fsi_master_gpio_term;
diff --git a/drivers/fsi/fsi-master.h b/drivers/fsi/fsi-master.h
index d6a4885..fd39924 100644
--- a/drivers/fsi/fsi-master.h
+++ b/drivers/fsi/fsi-master.h
@@ -19,6 +19,8 @@
#include <linux/device.h>
+#define FSI_MASTER_FLAG_SWCLOCK 0x1
+
struct fsi_master {
struct device dev;
int idx;
--
1.8.2.2
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: Document STM32 I2S bindings
From: Rob Herring @ 2017-04-10 19:48 UTC (permalink / raw)
To: olivier moysan
Cc: mark.rutland, devicetree, alsa-devel, alexandre.torgue,
arnaud.pouliquen, tiwai, lgirdwood, broonie, mcoquelin.stm32,
linux-arm-kernel, benjamin.gaignard
In-Reply-To: <1491493236-2574-2-git-send-email-olivier.moysan@st.com>
On Thu, Apr 06, 2017 at 05:40:35PM +0200, olivier moysan wrote:
> Add documentation of device tree bindings for STM32 SPI/I2S.
>
> Signed-off-by: olivier moysan <olivier.moysan@st.com>
> ---
> .../devicetree/bindings/sound/st,stm32h7-i2s.txt | 71 ++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/st,stm32h7-i2s.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/st,stm32h7-i2s.txt b/Documentation/devicetree/bindings/sound/st,stm32h7-i2s.txt
> new file mode 100644
> index 0000000..b99467a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/st,stm32h7-i2s.txt
> @@ -0,0 +1,71 @@
> +STMicroelectronics STM32 SPI/I2S Controller
> +
> +The SPI/I2S block supports I2S/PCM protocols when configured on I2S mode.
> +Only some SPI instances support I2S.
> +
> +Required properties:
> + - compatible: Must be "st,stm32h7-i2s"
> + - #sound-dai-cells: Must be 1. (one parameter)
> + This parameter allows to specify CPU DAI index in soundcard CPU dai link.
> + index 0: playback DAI
> + index 1: capture DAI
> + index 2: full duplex DAI
Is this still needed for graph-card?
> + - reg: Offset and length of the device's register set.
> + - interrupts: Must contain the interrupt line id.
> + - clocks: Must contain phandle and clock specifier pairs for each entry
> + in clock-names.
> + - clock-names: Must contain "i2sclk", "pclk", "x8k" and "x11k".
> + "i2sclk": clock which feeds the internal clock generator
> + "pclk": clock which feeds the peripheral bus interface
> + "x8k": I2S parent clock for sampling rates multiple of 8kHz.
> + "x11k": I2S parent clock for sampling rates multiple of 11.025kHz.
> + - dmas: DMA specifiers for tx and rx dma.
> + See Documentation/devicetree/bindings/dma/stm32-dma.txt.
> + - dma-names: Identifier for each DMA request line. Must be "tx" and "rx".
> + - pinctrl-names: should contain only value "default"
> + - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
> +
> +Optional properties:
> + - resets: Reference to a reset controller asserting the reset controller
> +
> +Example:
> +sound_card {
> + compatible = "audio-graph-card";
> + dais = <&i2s2_port 0>;
> +};
> +
> +i2s2: audio-controller@40003800 {
> + compatible = "st,stm32h7-i2s";
> + #sound-dai-cells = <1>;
> + reg = <0x40003800 0x400>;
> + interrupts = <36>;
> + clocks = <&rcc PCLK1>, <&rcc SPI2_CK>, <&rcc PLL1_Q>, <&rcc PLL2_P>;
> + clock-names = "pclk", "i2sclk", "x8k", "x11k";
> + dmas = <&dmamux2 2 39 0x400 0x1>,
> + <&dmamux2 3 40 0x400 0x1>;
> + dma-names = "rx", "tx";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2s2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + i2s2_port: port@0 {
> + reg = <0>;
> + cpu_endpoint: endpoint {
> + remote-endpoint = <&codec_endpoint>;
> + audio-graph-card,format = "i2s";
> + audio-graph-card,bitclock-master = <&codec_endpoint>;
> + audio-graph-card,frame-master = <&codec_endpoint>;
The 'audio-graph-card,' part has been dropped.
> + };
> + };
> +};
> +
> +audio-codec {
> + codec_port: port {
> + codec_endpoint: endpoint {
> + remote-endpoint = <&cpu_endpoint>;
> + };
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 0/6] mvmdio updates
From: Marcin Wojtas @ 2017-04-10 19:57 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stefan Chulski, Andrew Lunn, Thomas Petazzoni,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In-Reply-To: <20170410152728.GT17774-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Hi Russel,
2017-04-10 17:27 GMT+02:00 Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>:
> This series of patches update mvmdio for Armada 8k CP110. A number of
> issues were found:
>
> 1. The driver fails to disable an interrupt when something goes wrong
> in the probe function.
>
> 2. The interrupt is specified in DT to be optional, but the driver
> unconditionally writes to the interrupt mask register, which may
> not exist.
>
> 3. The DT binding specifies
> "reg: address and length of the SMI register"
> however, when supporting the interrupt, the size must cover the
> interrupt register as well. Update the binding documentation
> with this information that was previously omitted.
>
> 4. If the register size is too small, have the driver print an error
> and disable use of the interrupt.
>
> 5. Armada 8k needs three clocks for the MDIO interface, otherwise the
> SoC hangs (since it is part of one of the ethernet interfaces.)
> GOP clock, MG core clock and MG clock are needed on 8k. Augment the
> binding and driver to allow three clocks to be specified.
>
Actually most of the interfaces on a7k/a8k require multiple clocks to
be enabled, however all those twisted dependencies are handled within:
drivers/clk/mvebu/cp110-system-controller.c
With the latest patch of Thomas Petazzoni, MG clock is already
specified as a child of MG_CORE, so I believe a just minor change will
resolve remaining GOP clock dependency. This way we will leave
orion-mdio driver untouched around clocks.
Thomas, what is your opinion?
Regards,
Marcin
--
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 5/6] dt-bindings: allow up to three clocks for orion-mdio
From: Andrew Lunn @ 2017-04-10 19:57 UTC (permalink / raw)
To: Russell King
Cc: Marcin Wojtas, Stefan Chulski, Thomas Petazzoni, Rob Herring,
Mark Rutland, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <E1cxbEv-0006gY-PO-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
On Mon, Apr 10, 2017 at 04:28:25PM +0100, Russell King wrote:
> Armada 8040 needs three clocks to be enabled for MDIO accesses to work.
> Update the binding to allow the extra clocks to be specified.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
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 v4 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Linus Walleij @ 2017-04-10 20:04 UTC (permalink / raw)
To: Michael Hennerich
Cc: Wolfram Sang, Peter Rosin, Rob Herring, Mark Rutland,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491397671-14675-2-git-send-email-michael.hennerich@analog.com>
On Wed, Apr 5, 2017 at 3:07 PM, <michael.hennerich@analog.com> wrote:
> From: Michael Hennerich <michael.hennerich@analog.com>
>
> This patch adds support for the Analog Devices / Linear Technology
> LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
> The LTC4306 optionally provides two general purpose input/output pins
> (GPIOs) that can be configured as logic inputs, opendrain outputs or
> push-pull outputs via the generic GPIOLIB framework.
>
> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Okay!
> +#include <linux/device.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/gpio/driver.h>
Why are you including all these?
Normally a GPIO driver should just include
<linux/gpio/driver.h>
> +#include <linux/i2c-mux.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct ltc4306 *data = gpiochip_get_data(chip);
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(data->regmap, LTC_REG_CONFIG, &val);
> + if (ret < 0)
> + return ret;
> +
> + return (val & BIT(1 - offset));
Do this:
return !!(val & BIT(1 - offset));
So you clamp the return value to [0,1]
> +static int ltc4306_gpio_set_config(struct gpio_chip *chip,
> + unsigned int offset, unsigned long config)
> +{
> + struct ltc4306 *data = gpiochip_get_data(chip);
> + unsigned int val;
> +
> + switch (pinconf_to_config_param(config)) {
> + case PIN_CONFIG_DRIVE_OPEN_DRAIN:
> + val = 0;
> + break;
> + case PIN_CONFIG_DRIVE_PUSH_PULL:
> + val = BIT(4 - offset);
> + break;
> + default:
> + return -ENOTSUPP;
> + }
> +
> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
> + BIT(4 - offset), val);
> +}
Nice!
> + data->gpiochip.label = dev_name(dev);
> + data->gpiochip.base = -1;
> + data->gpiochip.ngpio = data->chip->num_gpios;
> + data->gpiochip.parent = dev;
> + data->gpiochip.can_sleep = true;
> + data->gpiochip.direction_input = ltc4306_gpio_direction_input;
> + data->gpiochip.direction_output = ltc4306_gpio_direction_output;
> + data->gpiochip.get = ltc4306_gpio_get;
> + data->gpiochip.set = ltc4306_gpio_set;
> + data->gpiochip.set_config = ltc4306_gpio_set_config;
> + data->gpiochip.owner = THIS_MODULE;
Please implement .get_direction().
This is very helpful to userspace, have you tested to use tools/gpio/*
from the kernel? Like lsgpio?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 2/3] clk: vc5: Add bindings for IDT VersaClock 5P49V5935
From: Rob Herring @ 2017-04-10 20:10 UTC (permalink / raw)
To: Alexey Firago
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, geert-Td1EMuHUCqxL1ZNQvxDV9g,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491556344-9465-3-git-send-email-alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On Fri, Apr 07, 2017 at 12:12:23PM +0300, Alexey Firago wrote:
> IDT VersaClock 5 5P49V5935 has 4 clock outputs, 4 fractional dividers.
> Input clock source can be taken from either integrated crystal or from
> external reference clock.
>
> Signed-off-by: Alexey Firago <alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/clock/idt,versaclock5.txt | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 3/4] pwm: tegra: Add DT binding details to configure pin in suspends/resume
From: Rob Herring @ 2017-04-10 20:13 UTC (permalink / raw)
To: Laxman Dewangan
Cc: thierry.reding, jonathanh, mark.rutland, linux-pwm, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <1491557642-15940-4-git-send-email-ldewangan@nvidia.com>
On Fri, Apr 07, 2017 at 03:04:01PM +0530, Laxman Dewangan wrote:
> In some of NVIDIA Tegra's platform, PWM controller is used to
> control the PWM controlled regulators. PWM signal is connected to
> the VID pin of the regulator where duty cycle of PWM signal decide
> the voltage level of the regulator output.
>
> When system enters suspend, some PWM client/slave regulator devices
> require the PWM output to be tristated.
>
> Add DT binding details to provide the pin configuration state
> from PWM and pinctrl DT node in suspend and active state of
> the system.
>
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
>
> ---
> Changes from v1:
> - Use standard pinctrl names for sleep and active state.
>
> Changes from V2:
> - Fix the commit message and details
> ---
> .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 45 ++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] mfd: arizona: Add GPIO maintain state flag
From: Rob Herring @ 2017-04-10 20:17 UTC (permalink / raw)
To: Charles Keepax
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, gnurou-Re5JQEeQqe8AvxtiuMwx3w,
mark.rutland-5wv7dgnIgG8, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E
In-Reply-To: <1491568725-14882-1-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Fri, Apr 07, 2017 at 01:38:44PM +0100, Charles Keepax wrote:
> The Arizona devices only maintain the state of output GPIOs whilst the
> CODEC is active, this can cause issues if the CODEC suspends whilst
> something is relying on the state of one of its GPIOs. However, in
> many systems the CODEC GPIOs are used for audio related features
> and thus the state of the GPIOs is unimportant whilst the CODEC is
> suspended. Often keeping the CODEC resumed in such a system would
> incur a power impact that is unacceptable.
>
> Add a flag through the second cell of the GPIO specifier in device
> tree, to allow the user to select whether a GPIO being configured as
> an output should keep the CODEC resumed.
If the whole codec can't be suspended, why does this need to be per
GPIO? You could just have a single boolean property.
>
> Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mfd/arizona.txt | 5 ++++-
> include/dt-bindings/mfd/arizona.h | 3 +++
> 2 files changed, 7 insertions(+), 1 deletion(-)
--
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 2/7] Documentation: dt: Remove bindings for STM32 pinctrl
From: Rob Herring @ 2017-04-10 20:20 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Linus Walleij, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, lee.jones, Jonathan Corbet,
linux-arm-kernel, devicetree, linux-gpio, linux-kernel
In-Reply-To: <1491568984-20169-3-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 07, 2017 at 02:42:59PM +0200, Alexandre TORGUE wrote:
> Remove "ngpios" bindings definition as it is no more used in stm32 pinctrl
> driver.
I read the subject as "rm
Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt". You can
be more specific:
dt-bindings: pinctrl: remove ngpios from stm32-pinctrl binding
With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 3/7] includes: dt-bindings: Rename STM32F429 pinctrl DT bindings
From: Rob Herring @ 2017-04-10 20:27 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Linus Walleij, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
Jonathan Corbet,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491568984-20169-4-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Fri, Apr 07, 2017 at 02:43:00PM +0200, Alexandre TORGUE wrote:
> STM32F4 MCU series is composed of several SOC (STM32F429, STM32F469, ...).
> Most of muxing definition are identical. So to avoid to duplicate bindings
> definition, this patch create common definitions.
This is a lot of churn. Some confirmation that the resultant dtb is the
same before and after would be nice. Perhaps the script you used to
convert this as well.
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 5/7] Documentation: dt: Add new compatible to STM32 pinctrl driver bindings
From: Rob Herring @ 2017-04-10 20:30 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Linus Walleij, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, lee.jones, Jonathan Corbet,
linux-arm-kernel, devicetree, linux-gpio, linux-kernel
In-Reply-To: <1491568984-20169-6-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 07, 2017 at 02:43:02PM +0200, Alexandre TORGUE wrote:
> Add new compatible for stm32f469 MCU.
Again, the subject is a bit generic. Something like:
dt-bindings: pinctrl: Add st,stm32f469-pinctrl compatible to stm32-pinctrl
And this should come before the driver changes.
With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: DT overlay issues - dtc flags
From: Frank Rowand @ 2017-04-10 20:44 UTC (permalink / raw)
To: Andreas Färber, devicetree-u79uwXL29TY76Z2rM5mHXA, U-Boot
Cc: Simon Glass, Rob Herring,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Alexander Graf, Frank Rowand
In-Reply-To: <1264bdc3-e61e-0256-0a0f-fdd8dbf50397-l3A5Bk7waGM@public.gmane.org>
adding cc to myself so I will see replies.
On 04/10/17 09:16, Andreas Färber wrote:
> Hi,
>
> I've tried to play around with Device Tree overlays (.dtbo files):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/overlay-notes.txt
>
> First of all, that document refers to a non-existing
> Documentation/devicetree/dt-object-internal.txt. Could someone please
> fix that one way or another?
>
> In my particular example I've tried to extend the &i2c1 and &gpio nodes
> of 4.11-rc5 arm64 broadcom/bcm2837-rpi-3-b.dts. The above documentation
> prominently claims that this can be done via target = <&foo> syntax, but
> U-Boot's fdt apply command fails for such a file. If instead I use the
> alternative target-path = "/soc/..." then it works just fine.
>
> As mentioned in the very bottom of the documentation, resolution of
> phandle target references requires a __symbols__ node in the base .dtb.
> IIUC this is only generated when passing the -@ dtc command line flag.
>
> At first I thought this were an issue with how we build the .dtb files
> in openSUSE [1], but by my reading of the kernel Makefiles not passing
> -@ in DTC_FLAGS or cmd_dtc, you should run into the exact same issue.
>
> I could think of a few ARMv7-M systems where such DT bloat might be
> undesired (small flash sector sizes), but then it would seem easier to
> suppress -@ where needed than to have a feature that by all practical
> means is half unusable by default.
>
> U-Boot itself appears to face a similar issue in that its internal
> Device Trees are built without -@, and via Alex' distro boot extensions
> this internal DT is passed on via UEFI as fallback when no external .dtb
> file is found. So in the non-SPL case the DT should probably be built
> with -@, too.
>
> Or am I misunderstanding something here?
>
> Thanks,
> Andreas
>
> [1]
> https://build.opensuse.org/package/view_file/Kernel:HEAD/dtb-aarch64/dtb-aarch64.spec?expand=1
>
--
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 v2] ARM: dts: imx: ventana: fix DTC warnings
From: Tim Harvey @ 2017-04-10 20:58 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1491252168-7934-1-git-send-email-tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
Remove the sky2 ethernet device node from the pcie controller which was
invalid to begin with.
The original intent was to allow the bootloader to populate the MAC via
dt but this requires the PCI bus topology to be complete in dt as well
and as these boards have an expansion connector that topology is dynamic
and can't be represented here.
Signed-off-by: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
---
v2:
- remove eth1 aliases
Signed-off-by: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
---
arch/arm/boot/dts/imx6q-gw5400-a.dts | 5 -----
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 5 -----
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 5 -----
3 files changed, 15 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-gw5400-a.dts b/arch/arm/boot/dts/imx6q-gw5400-a.dts
index 8e84713..687ab91 100644
--- a/arch/arm/boot/dts/imx6q-gw5400-a.dts
+++ b/arch/arm/boot/dts/imx6q-gw5400-a.dts
@@ -19,7 +19,6 @@
/* these are used by bootloader for disabling nodes */
aliases {
- ethernet1 = ð1;
i2c0 = &i2c1;
i2c1 = &i2c2;
i2c2 = &i2c3;
@@ -347,10 +346,6 @@
&pcie {
reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
status = "okay";
-
- eth1: sky2@8 { /* MAC/PHY on bus 8 */
- compatible = "marvell,sky2";
- };
};
&ssi1 {
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index a208e7e..5bc6ed1 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -14,7 +14,6 @@
/ {
/* these are used by bootloader for disabling nodes */
aliases {
- ethernet1 = ð1;
led0 = &led0;
led1 = &led1;
led2 = &led2;
@@ -342,10 +341,6 @@
pinctrl-0 = <&pinctrl_pcie>;
reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
status = "okay";
-
- eth1: sky2@8 { /* MAC/PHY on bus 8 */
- compatible = "marvell,sky2";
- };
};
&pwm2 {
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index 968fda9..66fcf838 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -14,7 +14,6 @@
/ {
/* these are used by bootloader for disabling nodes */
aliases {
- ethernet1 = ð1;
led0 = &led0;
led1 = &led1;
led2 = &led2;
@@ -379,10 +378,6 @@
pinctrl-0 = <&pinctrl_pcie>;
reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
status = "okay";
-
- eth1: sky2@8 { /* MAC/PHY on bus 8 */
- compatible = "marvell,sky2";
- };
};
&pwm1 {
--
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 v2 1/2] clk: imx7d: fix USDHC NAND clock
From: Stefan Agner @ 2017-04-10 21:00 UTC (permalink / raw)
To: shawnguo, kernel, sboyd
Cc: aisheng.dong, fabio.estevam, robh+dt, mark.rutland,
linux-arm-kernel, devicetree, linux-clk, linux-kernel,
Stefan Agner
The USDHC NAND root clock is not gated by any CCM clock gate. Remove
the bogus gate definition.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/clk/imx/clk-imx7d.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 562055129ed8..93b03640da9b 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -724,7 +724,7 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_MAIN_AXI_ROOT_DIV] = imx_clk_divider2("axi_post_div", "axi_pre_div", base + 0x8800, 0, 6);
clks[IMX7D_DISP_AXI_ROOT_DIV] = imx_clk_divider2("disp_axi_post_div", "disp_axi_pre_div", base + 0x8880, 0, 6);
clks[IMX7D_ENET_AXI_ROOT_DIV] = imx_clk_divider2("enet_axi_post_div", "enet_axi_pre_div", base + 0x8900, 0, 6);
- clks[IMX7D_NAND_USDHC_BUS_ROOT_DIV] = imx_clk_divider2("nand_usdhc_post_div", "nand_usdhc_pre_div", base + 0x8980, 0, 6);
+ clks[IMX7D_NAND_USDHC_BUS_ROOT_CLK] = imx_clk_divider2("nand_usdhc_root_clk", "nand_usdhc_pre_div", base + 0x8980, 0, 6);
clks[IMX7D_AHB_CHANNEL_ROOT_DIV] = imx_clk_divider2("ahb_root_clk", "ahb_pre_div", base + 0x9000, 0, 6);
clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider2("ipg_root_clk", "ahb_root_clk", base + 0x9080, 0, 2);
clks[IMX7D_DRAM_ROOT_DIV] = imx_clk_divider2("dram_post_div", "dram_cg", base + 0x9880, 0, 3);
@@ -798,7 +798,6 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_ENET_AXI_ROOT_CLK] = imx_clk_gate4("enet_axi_root_clk", "enet_axi_post_div", base + 0x4060, 0);
clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "axi_post_div", base + 0x4110, 0);
clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk", "ahb_root_clk", base + 0x4120, 0);
- clks[IMX7D_NAND_USDHC_BUS_ROOT_CLK] = imx_clk_gate4("nand_usdhc_root_clk", "nand_usdhc_post_div", base + 0x4130, 0);
clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk", "dram_post_div", base + 0x4130, 0);
clks[IMX7D_DRAM_PHYM_ROOT_CLK] = imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130, 0);
clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] = imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div", base + 0x4130, 0);
--
2.12.1
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: imx7: add USDHC NAND and IPG clock to SDHC instances
From: Stefan Agner @ 2017-04-10 21:00 UTC (permalink / raw)
To: shawnguo, kernel, sboyd
Cc: aisheng.dong, fabio.estevam, robh+dt, mark.rutland,
linux-arm-kernel, devicetree, linux-clk, linux-kernel,
Stefan Agner
In-Reply-To: <20170410210015.1620-1-stefan@agner.ch>
The USDHC instances need the USDHC NAND and IPG clock in order to
operate. Reference them properly by replacing the dummy clocks with
the actual clocks.
Note that both clocks are currently implicitly enabled since they
are part of the i.MX 7 clock drivers init_on list. This might
change in the future.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
This patch depends on "clk: imx7d: add the missing ipg_root_clk"
which adds the IPG clock.
--
Stefan
arch/arm/boot/dts/imx7s.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index c4f12fd2e044..843eb379e1ea 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -934,8 +934,8 @@
compatible = "fsl,imx7d-usdhc", "fsl,imx6sl-usdhc";
reg = <0x30b40000 0x10000>;
interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_CLK_DUMMY>,
- <&clks IMX7D_CLK_DUMMY>,
+ clocks = <&clks IMX7D_IPG_ROOT_CLK>,
+ <&clks IMX7D_NAND_USDHC_BUS_ROOT_CLK>,
<&clks IMX7D_USDHC1_ROOT_CLK>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
@@ -946,8 +946,8 @@
compatible = "fsl,imx7d-usdhc", "fsl,imx6sl-usdhc";
reg = <0x30b50000 0x10000>;
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_CLK_DUMMY>,
- <&clks IMX7D_CLK_DUMMY>,
+ clocks = <&clks IMX7D_IPG_ROOT_CLK>,
+ <&clks IMX7D_NAND_USDHC_BUS_ROOT_CLK>,
<&clks IMX7D_USDHC2_ROOT_CLK>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
@@ -958,8 +958,8 @@
compatible = "fsl,imx7d-usdhc", "fsl,imx6sl-usdhc";
reg = <0x30b60000 0x10000>;
interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_CLK_DUMMY>,
- <&clks IMX7D_CLK_DUMMY>,
+ clocks = <&clks IMX7D_IPG_ROOT_CLK>,
+ <&clks IMX7D_NAND_USDHC_BUS_ROOT_CLK>,
<&clks IMX7D_USDHC3_ROOT_CLK>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
--
2.12.1
^ permalink raw reply related
* Re: DT overlay issues - dtc flags
From: Frank Rowand @ 2017-04-10 21:19 UTC (permalink / raw)
To: Andreas Färber, devicetree-u79uwXL29TY76Z2rM5mHXA, U-Boot
Cc: Simon Glass, Rob Herring,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Alexander Graf
In-Reply-To: <1264bdc3-e61e-0256-0a0f-fdd8dbf50397-l3A5Bk7waGM@public.gmane.org>
On 04/10/17 09:16, Andreas Färber wrote:
> Hi,
>
> I've tried to play around with Device Tree overlays (.dtbo files):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/overlay-notes.txt
>
> First of all, that document refers to a non-existing
> Documentation/devicetree/dt-object-internal.txt. Could someone please
> fix that one way or another?
I will.
> In my particular example I've tried to extend the &i2c1 and &gpio nodes
> of 4.11-rc5 arm64 broadcom/bcm2837-rpi-3-b.dts. The above documentation
> prominently claims that this can be done via target = <&foo> syntax, but
> U-Boot's fdt apply command fails for such a file. If instead I use the
> alternative target-path = "/soc/..." then it works just fine.
The "target = <&foo>" syntax is the internal dtb syntax that the kernel
expects. The plan is to hide this internal format so it is not visble
at the source level, but that will require some more changes to the dtc
compiler.
> As mentioned in the very bottom of the documentation, resolution of
> phandle target references requires a __symbols__ node in the base .dtb.
> IIUC this is only generated when passing the -@ dtc command line flag.
>
> At first I thought this were an issue with how we build the .dtb files
> in openSUSE [1], but by my reading of the kernel Makefiles not passing
> -@ in DTC_FLAGS or cmd_dtc, you should run into the exact same issue.
Yes, the kernel support for overlays is not complete. This is one of
the issues that has not been addressed yet.
I don't have the rpi-3 documentation handy, so I'm going to take a wild
guess that the &i2c1 and &gpio node changes that you need are for
hardware on a hat. If so, the plan for the kernel is to describe
the signals available via the hat connectors in the device tree and
then make those signals available through the connector node instead
of having the hat overlay directly reference the signal node. The
connector abstraction has been discussed but is not implemented.
> I could think of a few ARMv7-M systems where such DT bloat might be
> undesired (small flash sector sizes), but then it would seem easier to
> suppress -@ where needed than to have a feature that by all practical
> means is half unusable by default.
>
> U-Boot itself appears to face a similar issue in that its internal
> Device Trees are built without -@, and via Alex' distro boot extensions
> this internal DT is passed on via UEFI as fallback when no external .dtb
> file is found. So in the non-SPL case the DT should probably be built
> with -@, too.
>
> Or am I misunderstanding something here?
>
> Thanks,
> Andreas
>
> [1]
> https://build.opensuse.org/package/view_file/Kernel:HEAD/dtb-aarch64/dtb-aarch64.spec?expand=1
>
--
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
* [RFC net-next] of: mdio: Honor hints from MDIO bus drivers
From: Florian Fainelli @ 2017-04-10 21:42 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, Florian Fainelli, Andrew Lunn,
Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
A MDIO bus driver can set phy_mask to indicate which PHYs should be
probed and which should not. Right now, of_mdiobus_register() always
sets mdio->phy_mask to ~0 which means: don't probe anything yourself,
and let the Device Tree scanning do it based on the availability of
child nodes.
When MDIO buses are stacked together (on purpose, as is done by DSA), we
run into possible double probing which is, at best unnecessary, and at
worse, can cause problems if that's not expected (e.g: during probe
deferral).
Fix this by remember the original mdio->phy_mask, and make sure that if
it was set to all 0xF, we set it to zero internally in order not to
influence how the child PHY/MDIO device registration is going to behave.
When the original mdio->phy_mask is set to something non-zero, we honor
this value and utilize it as a hint to register only the child nodes
that we have both found, and indicated to be necessary.
Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Sending this as RFC because a quick look at the current tree makes
me think we are fine, but I would appreciate some review/feedback
before this gets merged.
Thank you!
drivers/of/of_mdio.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 0b2979816dbf..6bfbf00623cb 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -209,6 +209,7 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
{
struct device_node *child;
bool scanphys = false;
+ u32 orig_phy_mask;
int addr, rc;
/* Do not continue if the node is disabled */
@@ -217,8 +218,15 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
/* Mask out all PHYs from auto probing. Instead the PHYs listed in
* the device tree are populated after the bus has been registered */
+ orig_phy_mask = mdio->phy_mask;
mdio->phy_mask = ~0;
+ /* If the original phy_mask was all 0xf, we make it zero here in order
+ * to get child Device Tree nodes to be probed successfully
+ */
+ if (orig_phy_mask == mdio->phy_mask)
+ orig_phy_mask = 0;
+
mdio->dev.of_node = np;
/* Register the MDIO bus */
@@ -234,6 +242,10 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
continue;
}
+ /* Honor hints from the mdio bus */
+ if (orig_phy_mask & BIT(addr))
+ continue;
+
if (of_mdiobus_child_is_phy(child))
of_mdiobus_register_phy(mdio, child, addr);
else
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Sebastian Reichel @ 2017-04-10 23:10 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Greg Kroah-Hartman, Gustavo F. Padovan, Johan Hedberg,
Samuel Thibault, Pavel Machek, Tony Lindgren, Jiri Slaby,
Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Rob Herring
In-Reply-To: <CAL_Jsq+NU3M5yuBpK1UGgzCVvq0eABMApCqEe3_d5+tDaABsgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
Hi,
On Wed, Apr 05, 2017 at 01:16:58PM -0500, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 8:33 AM, Greg Kroah-Hartman
> <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> > On Wed, Mar 29, 2017 at 11:33:26PM +0200, Marcel Holtmann wrote:
> >> Hi Rob,
> >>
> >> >> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
> >> >> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
> >> >> they were queued by Tony. I also changed the patch order, so that the serdev
> >> >> patches come first. All of them have Acked-by from Rob, so I think it makes
> >> >> sense to merge them to serdev subsystem (now) and provide an immutable branch
> >> >> for the bluetooth subsystem.
> >> >
> >> > Greg doesn't read cover letters generally and since the serdev patches
> >> > are Cc rather than To him, he's probably not planning to pick them up.
> >>
> >> I wonder actually if we should merge all of these via bluetooth-next
> >> tree with proper Ack from Greg. However it would be good to also get
> >> buy in from Dave for merging this ultimately through net-next.
> >
> > I don't really care where it goes. I can take the whole thing in my
> > tty/serial tree now if no one objects and I get an ack from the relevant
> > maintainers {hint...}
>
> I think it is better if it goes thru BT tree. I have another driver
> converted that is dependent on this series. There's a couple other
> serdev changes on the list too, but this shouldn't depend on them.
Is this waiting for something, or could it be queued to
bluetooth-next then? It would be nice to finally have
this in 4.12 :)
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH v4 6/9] ASoC: add snd_soc_get_dai_id()
From: Kuninori Morimoto @ 2017-04-10 23:59 UTC (permalink / raw)
To: Rob Herring; +Cc: Linux-DT, Linux-ALSA, Mark Brown, Simon
In-Reply-To: <CAL_JsqLp1cg_iJ1V9bk=GW6CF5BmsqkLc04D6EcQcaFaAAL+2g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob
> > ports {
> > port { endpoint }; /* ID = 0 */
> > port { endpoint }; /* ID = 1 */
> > port { endpoint }; /* ID = 2 */
>
> These ports are audio channels? If these are 3 separate data paths,
> then this is correct. If you have a single data path with multiple
> connections (e.g. a mux), then that should be a single port with
> multiple endpoints. For example, a design that routes the same I2S
> interface to HDMI and a codec and their use is mutually exclusive. I
> imagine you will need to support both.
Thanks.
Maybe we wil need it in the future, but not yet supported now.
> The pattern I prefer to see calling graph functions is that drivers
> are specific about which port and endpoint number for a parent node
> they want. Not just searching the graph for any match.
This related feature will be needed on HDMI sound support,
because it has not only sound port/endpoint.
> > 1 question
> >
> > It will support HDMI sound feature, thus I separated
> > it into OF-graph (= this patch-set) and HDMI (= next patch-set).
> > Should I merge it ?
>
> I think so if it affects the functions here. It seems better to let
> the driver controlling the DAI determine the id mapping than trying to
> do it in the core.
At this point, this feature (= HDMI sound) is not needed for OF-graph
patch-set. Thus, as-is is OK for OF-graph patch-set ?
Best regards
---
Kuninori Morimoto
--
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] PM / OPP: Use - instead of @ for DT entries
From: Masahiro Yamada @ 2017-04-11 1:13 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Benoît Cousson,
Tony Lindgren, Rob Herring, Mark Rutland, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Maxime Ripard, Chen-Yu Tsai,
linaro-kernel
In-Reply-To: <70e7c7ee13722ab9c73cb073f88502eaf1ada5f5.1491816050.git.viresh.kumar@linaro.org>
Hi Viresh,
2017-04-10 18:21 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> (uniphier)
Thank you!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: imx7: add USDHC NAND clock to SDHC instances
From: Dong Aisheng @ 2017-04-11 2:59 UTC (permalink / raw)
To: Stefan Agner
Cc: Fabio Estevam, Shawn Guo, Sascha Hauer, Stephen Boyd,
Dong Aisheng, Fabio Estevam, robh+dt, Mark Rutland,
linux-arm-kernel, devicetree, linux-clk, linux-kernel
In-Reply-To: <c95a7f535296623bdd4e4a640b3c27f5@agner.ch>
On Tue, Apr 04, 2017 at 07:36:01PM -0700, Stefan Agner wrote:
> On 2017-04-04 19:15, Fabio Estevam wrote:
> > On Sun, Apr 2, 2017 at 2:02 PM, Fabio Estevam <festevam@gmail.com> wrote:
> >> On Sat, Apr 1, 2017 at 1:15 AM, Stefan Agner <stefan@agner.ch> wrote:
> >>
> >>> IMX7D_IPG_ROOT_CLK is currently not a valid clock in upstream... So we
> >>> would have to add it to the clock driver first.
> >>>
> >>> I guess we could/should add it anyway at one point? But probably also as
> >>> init on, just to make sure Linux does not disable it since it is
> >>> currently used by several IPs implicitly.
> >>
> >> Yes, I made a previous attempt do add IMX7D_IPG_ROOT_CLK and it did
> >> not work as I did not put it in the init_on clock list.
> >>
> >> Will submit a new patch adding it to init_on, thanks.
> >
> > I thought that adding IMX7D_IPG_ROOT_CLK would do the trick, but the
> > patch below also causes the kernel to not boot:
> >
> > --- a/drivers/clk/imx/clk-imx7d.c
> > +++ b/drivers/clk/imx/clk-imx7d.c
> > @@ -386,7 +386,7 @@ static int const clks_init_on[] __initconst = {
> > IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_NAND_USDHC_BUS_ROOT_CLK,
> > IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
> > IMX7D_DRAM_PHYM_ALT_ROOT_CLK, IMX7D_DRAM_ALT_ROOT_CLK,
> > - IMX7D_AHB_CHANNEL_ROOT_CLK,
> > + IMX7D_AHB_CHANNEL_ROOT_CLK, IMX7D_IPG_ROOT_CLK,
> > };
> >
> > static struct clk_onecell_data clk_data;
> > @@ -788,7 +788,7 @@ static void __init imx7d_clocks_init(struct
> > device_node *ccm_node)
> > clks[IMX7D_WRCLK_ROOT_DIV] =
> > imx_clk_divider2("wrclk_post_div", "wrclk_pre_div", base + 0xbd00, 0,
> > 6);
> > clks[IMX7D_CLKO1_ROOT_DIV] =
> > imx_clk_divider2("clko1_post_div", "clko1_pre_div", base + 0xbd80, 0,
> > 6);
> > clks[IMX7D_CLKO2_ROOT_DIV] =
> > imx_clk_divider2("clko2_post_div", "clko2_pre_div", base + 0xbe00, 0,
> > 6);
> > -
> > + clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider2("ipg_root_clk",
> > "ahb_root_clk", base + 0x9080, 0, 2);
> > clks[IMX7D_ARM_A7_ROOT_CLK] = imx_clk_gate4("arm_a7_root_clk",
> > "arm_a7_div", base + 0x4000, 0);
> > clks[IMX7D_ARM_M4_ROOT_CLK] = imx_clk_gate4("arm_m4_root_clk",
> > "arm_m4_div", base + 0x4010, 0);
> > clks[IMX7D_ARM_M0_ROOT_CLK] = imx_clk_gate4("arm_m0_root_clk",
> > "arm_m0_div", base + 0x4020, 0);
>
> Hm, imx_clk_divider2 sets CLK_SET_RATE_PARENT, maybe that influences the
> parent?
>
> I guess we actually don't want the clock framework to change that clock
> rate, not sure whether we can freeze it or similar.
>
This is caused by ahb_root_clk gets disabled accidently and system hangs.
Because this patch defines ipg_root_clk earlier before its parent
(ahb_root_clk) got registered, then it will be marked as a orphan clk
temporarily. Until the parent ahb_root_clk got registered, the clk core
will reparent it to the newly found parent. (see __clk_core_init() function).
Due to CLK_SET_RATE_PARENT flag, the ahb clk will be enabled during
set_parent operation and then disabled after that.
Then system hang cause we still get no chance to run init_on clks.
I just send out a proper fix patch with correct register sequence.
Probably we can switch all imx clk driver to CLK_IS_CRITICAL for critical
clocks in the future, but that's another thing to do later.
Stefan,
I think you can just resend your series based on my patches.
Regards
Dong Aisheng
> --
> Stefan
^ permalink raw reply
* Re: [PATCH v1 3/3] nvmem: dt: document SNVS LPGPR binding
From: Oleksij Rempel @ 2017-04-11 4:36 UTC (permalink / raw)
To: Rob Herring, Oleksij Rempel
Cc: Srinivas Kandagatla, Maxime Ripard, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170410182235.pmobyxn6kvyvcwsj@rob-hp-laptop>
Hi,
On 04/10/2017 08:22 PM, Rob Herring wrote:
> On Thu, Apr 06, 2017 at 09:31:07AM +0200, Oleksij Rempel wrote:
>> Documenation bindings for the Low Power General Purpose Registe
>
> s/Registe/Register/
>
>> available on i.MX6 SoCs in the Secure Non-Volatile Storage.
>>
>> Signed-off-by: Oleksij Rempel <o.rempel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> Cc: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>> Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>> new file mode 100644
>> index 000000000000..9a8be1a2d12e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>> @@ -0,0 +1,15 @@
>> +Device tree bindings for Low Power General Purpose Registe found in i.MX6Q/D
>> +Secure Non-Volatile Storage.
>> +
>> +Required properties:
>> +- compatible: should be one of
>> + "fsl,imx6q-snvs-lpgpr" (i.MX6Q/D/DL/S).
>> +- offset: Should contain the offset relative to syscon parrent node.
>
> typo
ok.
> +- regmap: Should contain a phandle pointing to syscon.
>> +
>> +Example:
>> + snvs_lpgpr: snvs-lpgpr {
>> + compatible = "fsl,imx6q-snvs-lpgpr";
>> + regmap = <&snvs>;
>> + offset = <0x68>;
>
> Why does this need to be in DT? Is something going to refer to this
> node? If not, the &snvs node should be enough information for the OS.
Jes, it is refereed by other driver.
Thank you.
--
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 01/13] devicetree/bindings: display: Document common panel properties
From: Laurent Pinchart @ 2017-04-11 5:12 UTC (permalink / raw)
To: Emil Velikov
Cc: Laurent Pinchart, ML dri-devel, linux-renesas-soc, devicetree,
Tomi Valkeinen
In-Reply-To: <CACvgo52dydV5fpcDDPnFaRN32uxoeitvazwPpxOs4wOqg0=45A@mail.gmail.com>
Hi Emil,
On Sunday 09 Apr 2017 12:47:01 Emil Velikov wrote:
> Hi Laurent,
>
> Pardon for reviving this old thread. I've noticed a couple of things
> which might want some attention.
>
> On 19 November 2016 at 03:28, Laurent Pinchart wrote:
> > +
> > +- panel-timing: Most display panels are restricted to a single resolution
> > and + require specific display timings. The panel-timing subnode
> > expresses those + timings as specified in the timing subnode section of
> > the display timing + bindings defined in
> > + Documentation/devicetree/bindings/display/display-timing.txt.
>
> Cannot find such a file in linux-next. Perhaps you meant
> Documentation/devicetree/bindings/display/panel/display-timing.txt?
Oops. My bad, I'll fix that. Thank you for noticing it.
> Documentation/devicetree/bindings/display/panel/panel.txt includes a
> "rotation" property, which we might want to fold here.
I believe that panel.txt and panel-common.txt were added concurrently. We
should indeed merge the two.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* RE: [v3, 1/7] mmc: sdhci-of-esdhc: add peripheral clock support
From: Y.B. Lu @ 2017-04-11 5:14 UTC (permalink / raw)
To: Adrian Hunter, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
ulf.hansson@linaro.org, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon
Cc: Xiaobo Xie
In-Reply-To: <a8810e0a-95fa-a590-6827-15031ff52886@intel.com>
Hi Adrian,
> -----Original Message-----
> From: Adrian Hunter [mailto:adrian.hunter@intel.com]
> Sent: Monday, April 10, 2017 8:36 PM
> To: Y.B. Lu; linux-mmc@vger.kernel.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; ulf.hansson@linaro.org; Rob Herring;
> Mark Rutland; Catalin Marinas; Will Deacon
> Cc: Xiaobo Xie
> Subject: Re: [v3, 1/7] mmc: sdhci-of-esdhc: add peripheral clock support
>
> On 27/03/17 10:49, Yangbo Lu wrote:
> > eSDHC could select peripheral clock or platform clock as clock source
> > by the PCS bit of eSDHC Control Register, and this bit couldn't be
> > reset by software reset for all. In default, the platform clock is
> > used. But we have to use peripheral clock since it has a higher
> > frequency to support eMMC
> > HS200 mode and SD UHS-I mode. This patch is to add peripheral clock
> > support and use it instead of platform clock if it's declared in eSDHC
> dts node.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
>
> Apart from minor comments:
>
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>
> > ---
> > Changes for v2:
> > - None
> > Changes for v3:
> > - None
> > ---
> > drivers/mmc/host/sdhci-esdhc.h | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 70
> > +++++++++++++++++++++++++++++++++++++--
> > 2 files changed, 69 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-esdhc.h
> > b/drivers/mmc/host/sdhci-esdhc.h index ece8b37..5343fc0 100644
> > --- a/drivers/mmc/host/sdhci-esdhc.h
> > +++ b/drivers/mmc/host/sdhci-esdhc.h
> > @@ -54,6 +54,7 @@
> >
> > /* Control Register for DMA transfer */
> > #define ESDHC_DMA_SYSCTL 0x40c
> > +#define ESDHC_PERIPHERAL_CLK_SEL 0x00080000
> > #define ESDHC_DMA_SNOOP 0x00000040
> >
> > #endif /* _DRIVERS_MMC_SDHCI_ESDHC_H */ diff --git
> > a/drivers/mmc/host/sdhci-of-esdhc.c
> > b/drivers/mmc/host/sdhci-of-esdhc.c
> > index ff37e74..7ce1caf 100644
> > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > @@ -19,6 +19,7 @@
> > #include <linux/delay.h>
> > #include <linux/module.h>
> > #include <linux/sys_soc.h>
> > +#include <linux/clk.h>
> > #include <linux/mmc/host.h>
> > #include "sdhci-pltfm.h"
> > #include "sdhci-esdhc.h"
> > @@ -30,6 +31,7 @@ struct sdhci_esdhc {
> > u8 vendor_ver;
> > u8 spec_ver;
> > bool quirk_incorrect_hostver;
> > + unsigned int peripheral_clock;
> > };
> >
> > /**
> > @@ -414,15 +416,25 @@ static int esdhc_of_enable_dma(struct sdhci_host
> > *host) static unsigned int esdhc_of_get_max_clock(struct sdhci_host
> > *host) {
> > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > + struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
> >
> > - return pltfm_host->clock;
> > + if (esdhc->peripheral_clock)
> > + return esdhc->peripheral_clock;
> > + else
> > + return pltfm_host->clock;
> > }
> >
> > static unsigned int esdhc_of_get_min_clock(struct sdhci_host *host)
> > {
> > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > + struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
> > + unsigned int clock;
> >
> > - return pltfm_host->clock / 256 / 16;
> > + if (esdhc->peripheral_clock)
> > + clock = esdhc->peripheral_clock;
> > + else
> > + clock = pltfm_host->clock;
> > + return clock / 256 / 16;
> > }
> >
> > static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int
> > clock) @@ -512,6 +524,33 @@ static void
> esdhc_pltfm_set_bus_width(struct sdhci_host *host, int width)
> > sdhci_writel(host, ctrl, ESDHC_PROCTL); }
> >
> > +static void esdhc_clock_enable(struct sdhci_host *host, bool enable)
> > +{
> > + u32 val;
> > + u32 timeout;
> > +
> > + val = sdhci_readl(host, ESDHC_SYSTEM_CONTROL);
> > +
> > + if (enable)
> > + val |= ESDHC_CLOCK_SDCLKEN;
> > + else
> > + val &= ~ESDHC_CLOCK_SDCLKEN;
> > +
> > + sdhci_writel(host, val, ESDHC_SYSTEM_CONTROL);
> > +
> > + timeout = 20;
> > + val = ESDHC_CLOCK_STABLE;
> > + while (!(sdhci_readl(host, ESDHC_PRSSTAT) & val)) {
> > + if (timeout == 0) {
> > + pr_err("%s: Internal clock never stabilised.\n",
> > + mmc_hostname(host->mmc));
> > + break;
> > + }
> > + timeout--;
> > + mdelay(1);
>
> If the time to stabilize is much less that 1 ms then this loop can waste
> time. Have a look at the change in sdhci.c.
>
[Lu Yangbo-B47093] Thanks a lot. The method in sdhci.c is really better.
I will send next version to use it soon.
Currently another place in esdhc driver could also change to use this method. I will send a separate patch for that later.
> > + }
> > +}
> > +
> > static void esdhc_reset(struct sdhci_host *host, u8 mask) {
> > sdhci_reset(host, mask);
> > @@ -613,6 +652,9 @@ static void esdhc_init(struct platform_device
> > *pdev, struct sdhci_host *host) {
> > struct sdhci_pltfm_host *pltfm_host;
> > struct sdhci_esdhc *esdhc;
> > + struct device_node *np;
> > + struct clk *clk;
> > + u32 val;
> > u16 host_ver;
> >
> > pltfm_host = sdhci_priv(host);
> > @@ -626,6 +668,30 @@ static void esdhc_init(struct platform_device
> *pdev, struct sdhci_host *host)
> > esdhc->quirk_incorrect_hostver = true;
> > else
> > esdhc->quirk_incorrect_hostver = false;
> > +
> > + np = pdev->dev.of_node;
> > + clk = of_clk_get(np, 0);
>
> Should there be a clk_put somewhere?
[Lu Yangbo-B47093] Will add it after driver gets the clock value.
>
> > + if (!IS_ERR(clk)) {
> > + /*
> > + * esdhc->peripheral_clock would be assigned with a value
> > + * which is eSDHC base clock when use periperal clock.
> > + * For ls1046a, the clock value got by common clk API is
> > + * peripheral clock while the eSDHC base clock is 1/2
> > + * peripheral clock.
> > + */
> > + if (of_device_is_compatible(np, "fsl,ls1046a-esdhc"))
> > + esdhc->peripheral_clock = clk_get_rate(clk) / 2;
> > + else
> > + esdhc->peripheral_clock = clk_get_rate(clk);
> > + }
> > +
> > + if (esdhc->peripheral_clock) {
> > + esdhc_clock_enable(host, false);
> > + val = sdhci_readl(host, ESDHC_DMA_SYSCTL);
> > + val |= ESDHC_PERIPHERAL_CLK_SEL;
> > + sdhci_writel(host, val, ESDHC_DMA_SYSCTL);
> > + esdhc_clock_enable(host, true);
> > + }
> > }
> >
> > static int sdhci_esdhc_probe(struct platform_device *pdev)
> >
^ permalink raw reply
* RE: [v3, 2/7] mmc: sdhci-of-esdhc: add support for signal voltage switch
From: Y.B. Lu @ 2017-04-11 5:20 UTC (permalink / raw)
To: Adrian Hunter, linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon
Cc: Xiaobo Xie
In-Reply-To: <e7e08c87-ecd6-ab24-636c-7707a5172b08-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Hi Adrian,
> -----Original Message-----
> From: linux-mmc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-mmc-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Adrian Hunter
> Sent: Monday, April 10, 2017 8:38 PM
> To: Y.B. Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Rob Herring;
> Mark Rutland; Catalin Marinas; Will Deacon
> Cc: Xiaobo Xie
> Subject: Re: [v3, 2/7] mmc: sdhci-of-esdhc: add support for signal
> voltage switch
>
> On 27/03/17 10:49, Yangbo Lu wrote:
> > eSDHC supports signal voltage switch from 3.3v to 1.8v by
> > eSDHC_PROCTL[VOLT_SEL] bit. This bit changes the value of output
> > signal SDHC_VS, and there must be a control circuit out of eSDHC to
> > change the signal voltage according to SDHC_VS output signal.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
>
> Apart from minor comment below:
>
> Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> > ---
> > Changes for v2:
> > - Used Adrain's method to support voltage switching:
> > host->mmc_host_ops.start_signal_voltage_switch =
> > esdhc_signal_voltage_switch; Changes for v3:
> > - Put .start_signal_voltage_switch assigning after IS_ERR(host)
> check.
> > ---
> > drivers/mmc/host/sdhci-esdhc.h | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 74
> > +++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 75 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-esdhc.h
> > b/drivers/mmc/host/sdhci-esdhc.h index 5343fc0..6869567 100644
> > --- a/drivers/mmc/host/sdhci-esdhc.h
> > +++ b/drivers/mmc/host/sdhci-esdhc.h
> > @@ -37,6 +37,7 @@
> >
> > /* Protocol Control Register */
> > #define ESDHC_PROCTL 0x28
> > +#define ESDHC_VOLT_SEL 0x00000400
> > #define ESDHC_CTRL_4BITBUS (0x1 << 1)
> > #define ESDHC_CTRL_8BITBUS (0x2 << 1)
> > #define ESDHC_CTRL_BUSWIDTH_MASK (0x3 << 1)
> > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > b/drivers/mmc/host/sdhci-of-esdhc.c
> > index 7ce1caf..a70499a 100644
> > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > @@ -16,6 +16,7 @@
> > #include <linux/err.h>
> > #include <linux/io.h>
> > #include <linux/of.h>
> > +#include <linux/of_address.h>
> > #include <linux/delay.h>
> > #include <linux/module.h>
> > #include <linux/sys_soc.h>
> > @@ -559,6 +560,76 @@ static void esdhc_reset(struct sdhci_host *host,
> u8 mask)
> > sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE); }
> >
> > +/* The SCFG, Supplemental Configuration Unit, provides SoC specific
> > + * configuration and status registers for the device. There is a
> > + * SDHC IO VSEL control register on SCFG for some platforms. It's
> > + * used to support SDHC IO voltage switching.
> > + */
> > +static const struct of_device_id scfg_device_ids[] = {
> > + { .compatible = "fsl,t1040-scfg", },
> > + { .compatible = "fsl,ls1012a-scfg", },
> > + { .compatible = "fsl,ls1046a-scfg", },
> > + {}
> > +};
> > +
> > +/* SDHC IO VSEL control register definition */
> > +#define SCFG_SDHCIOVSELCR 0x408
> > +#define SDHCIOVSELCR_TGLEN 0x80000000
> > +#define SDHCIOVSELCR_VSELVAL 0x60000000
> > +#define SDHCIOVSELCR_SDHC_VS 0x00000001
> > +
> > +static int esdhc_signal_voltage_switch(struct mmc_host *mmc,
> > + struct mmc_ios *ios)
> > +{
> > + struct sdhci_host *host = mmc_priv(mmc);
> > + struct device_node *scfg_node;
> > + void __iomem *scfg_base = NULL;
> > + u32 sdhciovselcr;
> > + u32 val;
> > +
> > + /*
> > + * Signal Voltage Switching is only applicable for Host Controllers
> > + * v3.00 and above.
> > + */
> > + if (host->version < SDHCI_SPEC_300)
> > + return 0;
> > +
> > + val = sdhci_readl(host, ESDHC_PROCTL);
> > +
> > + switch (ios->signal_voltage) {
> > + case MMC_SIGNAL_VOLTAGE_330:
> > + val &= ~ESDHC_VOLT_SEL;
> > + sdhci_writel(host, val, ESDHC_PROCTL);
> > + return 0;
> > + case MMC_SIGNAL_VOLTAGE_180:
> > + scfg_node = of_find_matching_node(NULL, scfg_device_ids);
> > + if (scfg_node)
> > + scfg_base = of_iomap(scfg_node, 0);
> > + if (scfg_base) {
> > + sdhciovselcr = SDHCIOVSELCR_TGLEN |
> > + SDHCIOVSELCR_VSELVAL;
> > + iowrite32be(sdhciovselcr,
> > + scfg_base + SCFG_SDHCIOVSELCR);
>
> In other places there is support for little endian also, so why not here?
[Lu Yangbo-B47093] The SCFG unit is always a big-endian module on both ARM and PPC QorIQ platforms.
There is little possibility to have little-endian in future.
>
> > +
> > + val |= ESDHC_VOLT_SEL;
> > + sdhci_writel(host, val, ESDHC_PROCTL);
> > + mdelay(5);
> > +
> > + sdhciovselcr = SDHCIOVSELCR_TGLEN |
> > + SDHCIOVSELCR_SDHC_VS;
> > + iowrite32be(sdhciovselcr,
> > + scfg_base + SCFG_SDHCIOVSELCR);
> > + iounmap(scfg_base);
> > + } else {
> > + val |= ESDHC_VOLT_SEL;
> > + sdhci_writel(host, val, ESDHC_PROCTL);
> > + }
> > + return 0;
> > + default:
> > + return 0;
> > + }
> > +}
> > +
> > #ifdef CONFIG_PM_SLEEP
> > static u32 esdhc_proctl;
> > static int esdhc_of_suspend(struct device *dev) @@ -714,6 +785,9 @@
> > static int sdhci_esdhc_probe(struct platform_device *pdev)
> > if (IS_ERR(host))
> > return PTR_ERR(host);
> >
> > + host->mmc_host_ops.start_signal_voltage_switch =
> > + esdhc_signal_voltage_switch;
> > +
> > esdhc_init(pdev, host);
> >
> > sdhci_get_of_property(pdev);
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
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
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