* Re: [PATCH v4 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver
From: Marc Kleine-Budde @ 2017-04-04 15:34 UTC (permalink / raw)
To: Akshay Bhat, wg-5Yr1BZd7O62+XT7JhA+gdA
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Akshay Bhat
In-Reply-To: <32114de2-8ab7-daec-9b36-209cab0ea550-jEh4hwF5bVhBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2652 bytes --]
On 03/24/2017 06:20 PM, Akshay Bhat wrote:
> Hi Marc,
>
> On 03/17/2017 05:10 PM, Akshay Bhat wrote:
>> This patch adds support for the Holt HI-311x CAN controller. The HI311x
>> CAN controller is capable of transmitting and receiving standard data
>> frames, extended data frames and remote frames. The HI311x interfaces
>> with the host over SPI.
>>
>> Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do
>>
>> Signed-off-by: Akshay Bhat <nodeax-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>>
>
> If there are no further review comments can this series be applied to
> can-next or does it need to wait for the next kernel release cycle (4.13)?
The driver doesn't check if the workqueue allocation is successfull,
I've squashed this patch:
> diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
> index ff4bb40d855e..170e8e3971b2 100644
> --- a/drivers/net/can/spi/hi311x.c
> +++ b/drivers/net/can/spi/hi311x.c
> @@ -780,20 +780,24 @@ static int hi3110_open(struct net_device *net)
>
> priv->wq = alloc_workqueue("hi3110_wq", WQ_FREEZABLE | WQ_MEM_RECLAIM,
> 0);
> + if (!priv->wq) {
> + ret = -ENOMEM;
> + goto out_free_irq;
> + }
> INIT_WORK(&priv->tx_work, hi3110_tx_work_handler);
> INIT_WORK(&priv->restart_work, hi3110_restart_work_handler);
>
> ret = hi3110_hw_reset(spi);
> if (ret)
> - goto out_free_irq;
> + goto out_free_wq;
>
> ret = hi3110_setup(net);
> if (ret)
> - goto out_free_irq;
> + goto out_free_wq;
>
> ret = hi3110_set_normal_mode(spi);
> if (ret)
> - goto out_free_irq;
> + goto out_free_wq;
>
> can_led_event(net, CAN_LED_EVENT_OPEN);
> netif_wake_queue(net);
> @@ -801,11 +805,12 @@ static int hi3110_open(struct net_device *net)
>
> return 0;
>
> -out_free_irq:
> + out_free_wq:
> + destroy_workqueue(priv->wq);
> + out_free_irq:
> free_irq(spi->irq, priv);
> hi3110_hw_sleep(spi);
> -
> -out_close:
> + out_close:
> hi3110_power_enable(priv->transceiver, 0);
> close_candev(net);
> mutex_unlock(&priv->hi3110_lock);
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] ARM: dts: keystone: Add support for new K2G evm
From: Santosh Shilimkar @ 2017-04-04 15:33 UTC (permalink / raw)
To: Franklin S Cooper Jr, ssantosh, devicetree, linux-kernel,
linux-arm-kernel
Cc: robh+dt, linux
In-Reply-To: <694db3ba-cf40-790b-29e0-39f34607caf3@oracle.com>
On 4/3/2017 9:44 AM, santosh.shilimkar@oracle.com wrote:
> Hi Franklin,
>
> On 3/30/17 8:29 AM, Franklin S Cooper Jr wrote:
>> This patchset adds support for new K2G Industrial Communication Engine
>> evm. For now only a bare minimal dts which will allow ram boot.
>> Additional
>> peripherals will be added when base K2G SoC patches are upstreamed
>> allowing
>> peripherals to be enabled.
>>
>
>> ARM: keystone: Create new binding for K2G ICE evm
>> ARM: dts: keystone: Add minimum support for K2G ICE evm
>>
> Can you clarify Rob's comment on second patch and re-post the updated
> patch with his ack if you agree ? Will apply the series.
>
Just to be clear, you need to send v2 with Rob's comment addressed
for me to pick it up.
Regards,
Snatosh
^ permalink raw reply
* [PATCH v4 8/8] ARM: ux500: Add vendor prefix to tps61052 node
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Aaro Koskinen, Tony Lindgren,
Russell King, Javier Martinez Canillas, Rob Herring, Lee Jones,
linux-arm-kernel
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The tps61052 device node doesn't have a vendor prefix
in its compatible string, fix it by adding one.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/ste-hrefprev60.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ste-hrefprev60.dtsi b/arch/arm/boot/dts/ste-hrefprev60.dtsi
index 5882a2606ac3..3f14b4df69b4 100644
--- a/arch/arm/boot/dts/ste-hrefprev60.dtsi
+++ b/arch/arm/boot/dts/ste-hrefprev60.dtsi
@@ -30,7 +30,7 @@
i2c@80004000 {
tps61052@33 {
- compatible = "tps61052";
+ compatible = "ti,tps61052";
reg = <0x33>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 7/8] mfd: tps6105x: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have a
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4: None
Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).
Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
drivers/mfd/tps6105x.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/mfd/tps6105x.c b/drivers/mfd/tps6105x.c
index baa12ea666fb..187848c93779 100644
--- a/drivers/mfd/tps6105x.c
+++ b/drivers/mfd/tps6105x.c
@@ -173,9 +173,17 @@ static const struct i2c_device_id tps6105x_id[] = {
};
MODULE_DEVICE_TABLE(i2c, tps6105x_id);
+static const struct of_device_id tps6105x_of_match[] = {
+ { .compatible = "ti,tps61050" },
+ { .compatible = "ti,tps61052" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tps6105x_of_match);
+
static struct i2c_driver tps6105x_driver = {
.driver = {
.name = "tps6105x",
+ .of_match_table = tps6105x_of_match,
},
.probe = tps6105x_probe,
.remove = tps6105x_remove,
--
2.9.3
^ permalink raw reply related
* [PATCH v4 6/8] dt-bindings: mfd: Add TI tps6105x chip bindings
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas, Mark Rutland
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
There are Device Tree source files defining a device node for the
tps61050/61052 I2C chip but there isn't a binding document for it.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/mfd/tps6105x.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps6105x.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps6105x.txt b/Documentation/devicetree/bindings/mfd/tps6105x.txt
new file mode 100644
index 000000000000..93602c7a19c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps6105x.txt
@@ -0,0 +1,17 @@
+* Device tree bindings for TI TPS61050/61052 Boost Converters
+
+The TP61050/TPS61052 is a high-power "white LED driver". The
+device provides LED, GPIO and regulator functionalities.
+
+Required properties:
+- compatible: "ti,tps61050" or "ti,tps61052"
+- reg: Specifies the I2C slave address
+
+Example:
+
+i2c0 {
+ tps61052@33 {
+ compatible = "ti,tps61052";
+ reg = <0x33>;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 5/8] i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas, Wolfram Sang, linux-i2c, Mark Rutland
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The example contains a device node for a retu device, but
its compatible string doesn't have a vendor prefix.
While being there, drop the -mfd suffix since isn't correct.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4:
- Avoid using MFD in Device Tree (Lee Jones).
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
index 8ce9cd2855b5..c143948b2a37 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
@@ -20,8 +20,8 @@ i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
- retu-mfd: retu@1 {
- compatible = "retu-mfd";
+ retu: retu@1 {
+ compatible = "nokia,retu";
reg = <0x1>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 4/8] ARM: dts: n8x0: Add vendor prefix to retu node
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Aaro Koskinen, Tony Lindgren,
Russell King, Javier Martinez Canillas, Rob Herring,
Benoît Cousson, linux-omap, Lee Jones, linux-arm-kernel
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The retu device node doesn't have a vendor prefix
in its compatible string, fix it by adding one.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 1b06430c8013..91886231e5a8 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -16,7 +16,7 @@
#address-cells = <1>;
#size-cells = <0>;
retu: retu@1 {
- compatible = "retu";
+ compatible = "nokia,retu";
interrupt-parent = <&gpio4>;
interrupts = <12 IRQ_TYPE_EDGE_RISING>;
reg = <0x1>;
--
2.9.3
^ permalink raw reply related
* [PATCH v4 3/8] mfd: retu: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have a
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4:
- Drop -mfd suffix in compatible string (Lee Jones).
Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).
Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
drivers/mfd/retu-mfd.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index 53e1d386d2c0..e7d27b7861c1 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -308,9 +308,17 @@ static const struct i2c_device_id retu_id[] = {
};
MODULE_DEVICE_TABLE(i2c, retu_id);
+static const struct of_device_id retu_of_match[] = {
+ { .compatible = "nokia,retu" },
+ { .compatible = "nokia,tahvo" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, retu_of_match);
+
static struct i2c_driver retu_driver = {
.driver = {
.name = "retu-mfd",
+ .of_match_table = retu_of_match,
},
.probe = retu_probe,
.remove = retu_remove,
--
2.9.3
^ permalink raw reply related
* [PATCH v4 2/8] mfd: retu: Drop -mfd suffix from I2C device ID name
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Aaro Koskinen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Tony Lindgren, Lee Jones, Javier Martinez Canillas,
Benoît Cousson, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170404153036.6651-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
It's not correct to encode the subsystem in the I2C device name, so
drop the -mfd suffix. To maintain bisect-ability, change driver and
platform code / DTS users in the same patch.
Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 ++--
arch/arm/mach-omap1/board-nokia770.c | 4 ++--
drivers/mfd/retu-mfd.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 7e5ffc583c90..1b06430c8013 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -15,8 +15,8 @@
>;
#address-cells = <1>;
#size-cells = <0>;
- retu_mfd: retu@1 {
- compatible = "retu-mfd";
+ retu: retu@1 {
+ compatible = "retu";
interrupt-parent = <&gpio4>;
interrupts = <12 IRQ_TYPE_EDGE_RISING>;
reg = <0x1>;
diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
index ee8d9f553db4..06243c0b12d2 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -233,10 +233,10 @@ static struct platform_device nokia770_cbus_device = {
static struct i2c_board_info nokia770_i2c_board_info_2[] __initdata = {
{
- I2C_BOARD_INFO("retu-mfd", 0x01),
+ I2C_BOARD_INFO("retu", 0x01),
},
{
- I2C_BOARD_INFO("tahvo-mfd", 0x02),
+ I2C_BOARD_INFO("tahvo", 0x02),
},
};
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index d4c114abeb75..53e1d386d2c0 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -302,8 +302,8 @@ static int retu_remove(struct i2c_client *i2c)
}
static const struct i2c_device_id retu_id[] = {
- { "retu-mfd", 0 },
- { "tahvo-mfd", 0 },
+ { "retu", 0 },
+ { "tahvo", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, retu_id);
--
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
* [PATCH v4 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas, Mark Rutland
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
There are Device Tree source files defining a device node for the
retu/tahvo I2C chip, but there isn't a DT binding document for it.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/mfd/retu.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
diff --git a/Documentation/devicetree/bindings/mfd/retu.txt b/Documentation/devicetree/bindings/mfd/retu.txt
new file mode 100644
index 000000000000..7df21a2b28ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/retu.txt
@@ -0,0 +1,21 @@
+* Device tree bindings for Nokia Retu and Tahvo multi-function device
+
+Retu and Tahvo are a multi-function devices found on Nokia Internet
+Tablets (770, N800 and N810). The Retu chip provides watchdog timer
+and power button control functionalities while Tahvo chip provides
+USB transceiver functionality.
+
+Required properties:
+- compatible: "nokia,retu" or "nokia,tahvo"
+- reg: Specifies the I2C slave address of the ASIC chip
+
+Example:
+
+i2c0 {
+ retu: retu@1 {
+ compatible = "nokia,retu";
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_RISING>;
+ reg = <0x1>;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 0/8] mfd: Add OF device table to I2C drivers that are missing it
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas, Benoît Cousson, Wolfram Sang,
Mark Rutland, linux-omap, Russell King, linux-arm-kernel,
linux-i2c
Hello,
This series add OF device ID tables to mfd I2C drivers whose devices are
either used in Device Tree source files or are listed in binding docs as
a compatible string.
That's done because the plan is to change the I2C core to report proper OF
modaliases instead of always reporting a MODALIAS=i2c:<foo> regardless if
a device was registered via DT or using the legacy platform data mechanism.
So these patches will make sure that mfd I2C drivers modules will continue
to be autoloaded once the I2C core is changed to report proper OF modalias.
Users didn't have a vendor prefix in the used compatible strings, but since
there wasn't a DT binding document for these drivers, it can be said that
were working for mere luck and so this series fixes the users and add a DT
binding doc for the drivers.
Most patches can be applied independently, with the exception of patches
2 to 4 that should be applied in the same tree to keep bisect-ability.
Best regards,
Javier
Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
- Drop -mfd suffix in compatible string (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).
- Add a vendor prefix to the compatible string (Rob Herring).
Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
Javier Martinez Canillas (8):
dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
mfd: retu: Drop -mfd suffix from I2C device ID name
mfd: retu: Add OF device ID table
ARM: dts: n8x0: Add vendor prefix to retu node
i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
dt-bindings: mfd: Add TI tps6105x chip bindings
mfd: tps6105x: Add OF device ID table
ARM: ux500: Add vendor prefix to tps61052 node
.../devicetree/bindings/i2c/i2c-cbus-gpio.txt | 4 ++--
Documentation/devicetree/bindings/mfd/retu.txt | 21 +++++++++++++++++++++
Documentation/devicetree/bindings/mfd/tps6105x.txt | 17 +++++++++++++++++
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 ++--
arch/arm/boot/dts/ste-hrefprev60.dtsi | 2 +-
arch/arm/mach-omap1/board-nokia770.c | 4 ++--
drivers/mfd/retu-mfd.c | 12 ++++++++++--
drivers/mfd/tps6105x.c | 8 ++++++++
8 files changed, 63 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/tps6105x.txt
--
2.9.3
^ permalink raw reply
* Re: [PATCH v2 2/7] rtc: Add rtc-sh
From: Geert Uytterhoeven @ 2017-04-04 15:27 UTC (permalink / raw)
To: Rob Herring
Cc: Chris Brandt, Alessandro Zummo, Alexandre Belloni, Mark Rutland,
Simon Horman, RTCLINUX,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAL_JsqLLZsLzS4ONOexJADQXXXr9iquFUcVj8kX6AEVwM+x56A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On Tue, Apr 4, 2017 at 4:29 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Mar 29, 2017 at 1:49 AM, Geert Uytterhoeven
> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>> On Wed, Mar 29, 2017 at 3:24 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Wed, Mar 22, 2017 at 10:27:49AM -0400, Chris Brandt wrote:
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-sh.txt
>>>> +Example:
>>>> +rtc: rtc@fcff1000 {
>>>> + compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
>>>> + reg = <0xfcff1000 0x2e>;
>>>> + interrupts = <GIC_SPI 276 IRQ_TYPE_EDGE_RISING
>>>> + GIC_SPI 277 IRQ_TYPE_EDGE_RISING
>>>> + GIC_SPI 278 IRQ_TYPE_EDGE_RISING>;
>>>> + interrupt-names = "alarm", "period", "carry";
>>>> + clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>,
>>>> + <&rtc_x3_clk>, <&extal_clk>;
>>>> + clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
>>>> + power-domains = <&cpg_clocks>;
>>>
>>> Not documented.
>>
>> "power-domains" is a platform property.
>>
>> All hardware components need power.
>> All synchronous hardware components need a clock.
>> Most hardware components have a reset signal.
>
> And we document clocks and reset for every binding.
Then we'll have to add lots of them ;-)
Usually these are documented only if the user (the driver) cares about them,
and/or if there are multiple of the same type. E.g.
- The driver needs to know or control a clock frequency,
- The driver needs to enable/disable a clock,
- The driver needs to know or control one or more voltages,
- ...
It's not that devices without documented regulators, power-domains, or clocks
properties no longer consume power or don't run from a clock. These are just
not described in DT, as deemed unimportant. But on some platforms, they may
become important.
>> Whether these are exposed and can be controlled depends on the platform/SoC.
>> So documenting them in each and every device binding looks overkill to me.
>> I think this is something to be addressed by devicetree-specification (which
>> doesn't handle clocks, power-domains, resets yet).
>
> It's a question of validation. How do I validate power-domains is a
> valid property for a given compatible? What if it is required, but not
With platform property, I mean that it depends on the platform, not on the
compatible value of the device.
For a generic compatible value ("renesas,sh-srtc") you cannot know, as
it depends on the actual SoC the (same) RTC device is part of.
For an SoC-specific compatible value ("renesas,r7s72100-rtc"), you could know
from the compatible value (an r7s72100 SoC must have r7s72100 clocks, and the
r7s72100 clock domain, cfr.
Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt).
However. the SoC-specific compatible values exist only as a workaround
for not knowing
the exact version of the IP cores.
> present? Any node can have it? So it is valid for memory and chosen
> nodes, an i2c device, an LCD panel, etc?
It's not valid for a chosen node ;-)
It can be valid for memory (or the memory-controller; oops, the memory node is
not a child of the memory-controller node), i2c devices, LCD panels, ...
depending on the platform.
Consider e.g. i2c devices. I can add a GPIO-controlled MOSFET bank to my board,
to enable power to individual i2c devices, and abstract that as a
power-controller in DT. Suddenly I have to add power-domains properties to the
individual i2c device nodes, while the i2c devices itself haven't changed, and
thus keep the same compatible values.
Should I now document the power-domains property in the i2c devices' DT binding
documents?
On Linux, the drivers won't care, as the platform-specific things are handled
transparently by Runtime PM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3
From: Icenowy Zheng @ 2017-04-04 15:02 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Quentin Schulz, Chen-Yu Tsai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Lee Jones, Zhang Rui, Jonathan Cameron
In-Reply-To: <20170404144715.fa5sy427u2cz4e6z@rob-hp-laptop>
在 2017年04月04日 22:47, Rob Herring 写道:
> On Sun, Apr 02, 2017 at 09:33:01PM +0800, Icenowy Zheng wrote:
>> Allwinner H3 features a thermal sensor like the one in A33, but has its
>> register re-arranged, the clock divider moved to CCU (originally the
>> clock divider is in ADC) and added a pair of bus clock and reset.
>>
>> Update the binding document to cover H3.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 23 ++++++++++++++++++++--
>> 1 file changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> index badff3611a98..7753133ca0ff 100644
>> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> @@ -4,12 +4,20 @@ The Allwinner SoCs all have an ADC that can also act as a thermal sensor
>> and sometimes as a touchscreen controller.
>>
>> Required properties:
>> - - compatible: "allwinner,sun8i-a33-ths",
>> + - compatible: must contain one of the following compatibles:
>> + - "allwinner,sun8i-a33-ths"
>> + - "allwinner,sun8i-h3-ths"
>> - reg: mmio address range of the chip,
>> - #thermal-sensor-cells: shall be 0,
>> - #io-channel-cells: shall be 0,
>>
>> -Example:
>> +Required properties for the following compatibles:
>> + - "allwinner,sun8i-h3-ths"
>> + - clocks: the bus clock and the input clock of the ADC,
>> + - clock-names: should be "bus" and "ths",
>> + - resets: the bus reset of the ADC,
>> +
>> +Example for A33:
>> ths: ths@01c25000 {
>> compatible = "allwinner,sun8i-a33-ths";
>> reg = <0x01c25000 0x100>;
>> @@ -17,6 +25,17 @@ Example:
>> #io-channel-cells = <0>;
>> };
>>
>> +Example for H3:
>> + ths: ths@01c25000 {
>
> adc@...
It's a thermal sensor, so I think call it THS is more appropriate
here. It's implemented as an ADC driver just because the internal
code reusing of Linux. From device tree binding view I choose to
call it ths.
>
> And drop the leading 0.
OK.
>
>> + compatible = "allwinner,sun8i-h3-ths";
>> + reg = <0x01c25000 0x100>;
>> + clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
>> + clock-names = "bus", "ths";
>> + resets = <&ccu RST_BUS_THS>;
>> + #thermal-sensor-cells = <0>;
>> + #io-channel-cells = <0>;
>> + };
>> +
>> sun4i, sun5i and sun6i SoCs are also supported via the older binding:
>>
>> sun4i resistive touchscreen controller
>> --
>> 2.12.2
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v4 02/14] dt/bindings: Document gpio-ingenic
From: Rob Herring @ 2017-04-04 14:52 UTC (permalink / raw)
To: Paul Cercueil
Cc: Linus Walleij, Alexandre Courbot, Mark Rutland, Ralf Baechle,
Boris Brezillon, Thierry Reding, Bartlomiej Zolnierkiewicz,
Maarten ter Huurne, Lars-Peter Clausen, Paul Burton, james.hogan,
linux-gpio, devicetree, linux-kernel, linux-mips, linux-mmc,
linux-mtd, linux-pwm, linux-fbdev
In-Reply-To: <20170402204244.14216-3-paul@crapouillou.net>
On Sun, Apr 02, 2017 at 10:42:32PM +0200, Paul Cercueil wrote:
> This commit adds documentation for the devicetree bindings of the
> gpio-ingenic driver, which handles GPIOs of the Ingenic SoCs
> currently supported by the Linux kernel.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> .../devicetree/bindings/gpio/ingenic,gpio.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/ingenic,gpio.txt
>
> v2: New patch
> v3: No changes
> v4: Update for the v4 version of the gpio-ingenic driver
>
> diff --git a/Documentation/devicetree/bindings/gpio/ingenic,gpio.txt b/Documentation/devicetree/bindings/gpio/ingenic,gpio.txt
> new file mode 100644
> index 000000000000..f54af444f7c3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/ingenic,gpio.txt
> @@ -0,0 +1,48 @@
> +Ingenic jz47xx GPIO controller
> +
> +That the Ingenic GPIO driver node must be a sub-node of the Ingenic pinctrl
> +driver node.
> +
> +Required properties:
> +--------------------
> +
> + - compatible: Must contain one of:
> + - "ingenic,jz4740-gpio"
> + - "ingenic,jz4770-gpio"
> + - "ingenic,jz4780-gpio"
> + And one of:
> + - "ingenic,gpio-bank-a"
> + - "ingenic,gpio-bank-b"
> + - "ingenic,gpio-bank-c"
> + - "ingenic,gpio-bank-d"
> + - "ingenic,gpio-bank-e" (for SoC version > jz4740)
> + - "ingenic,gpio-bank-f" (for SoC version > jz4740)
This is quite strange. Why do you need the bank? Doesn't gpio-ranges
give you that info? Maybe use reg property here instead.
> + - interrupt-controller: Marks the device node as an interrupt controller.
> + - interrupts: Interrupt specifier for the controllers interrupt.
> + - #interrupt-cells: Should be 2. Refer to
> + ../interrupt-controller/interrupts.txt for more details.
> + - gpio-controller: Marks the device node as a GPIO controller.
> + - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
> + cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
> + GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
> + - gpio-ranges: Range of pins managed by the GPIO controller. Refer to
> + 'gpio.txt' in this directory for more details.
> +
> +Example:
> +--------
> +
> +&pinctrl {
> + gpa: gpio-controller@0 {
gpio@...
> + compatible = "ingenic,gpio-bank-a", "ingenic,jz4740-gpio";
> +
> + gpio-controller;
> + gpio-ranges = <&pinctrl 0 0 32>;
> + #gpio-cells = <2>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <28>;
> + };
> +};
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v4 01/14] dt/bindings: Document pinctrl-ingenic
From: Rob Herring @ 2017-04-04 14:48 UTC (permalink / raw)
To: Paul Cercueil
Cc: Linus Walleij, Alexandre Courbot, Mark Rutland, Ralf Baechle,
Boris Brezillon, Thierry Reding, Bartlomiej Zolnierkiewicz,
Maarten ter Huurne, Lars-Peter Clausen, Paul Burton, james.hogan,
linux-gpio, devicetree, linux-kernel, linux-mips, linux-mmc,
linux-mtd, linux-pwm, linux-fbdev
In-Reply-To: <20170402204244.14216-2-paul@crapouillou.net>
On Sun, Apr 02, 2017 at 10:42:31PM +0200, Paul Cercueil wrote:
> This commit adds documentation for the devicetree bindings of the
> pinctrl-ingenic driver, which handles pin configuration and pin
> muxing of the Ingenic SoCs currently supported by the Linux kernel.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> .../bindings/pinctrl/ingenic,pinctrl.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3
From: Rob Herring @ 2017-04-04 14:47 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Lee Jones, Maxime Ripard, Chen-Yu Tsai, Jonathan Cameron,
Quentin Schulz, Zhang Rui, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170402133304.56824-2-icenowy-h8G6r0blFSE@public.gmane.org>
On Sun, Apr 02, 2017 at 09:33:01PM +0800, Icenowy Zheng wrote:
> Allwinner H3 features a thermal sensor like the one in A33, but has its
> register re-arranged, the clock divider moved to CCU (originally the
> clock divider is in ADC) and added a pair of bus clock and reset.
>
> Update the binding document to cover H3.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 23 ++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> index badff3611a98..7753133ca0ff 100644
> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> @@ -4,12 +4,20 @@ The Allwinner SoCs all have an ADC that can also act as a thermal sensor
> and sometimes as a touchscreen controller.
>
> Required properties:
> - - compatible: "allwinner,sun8i-a33-ths",
> + - compatible: must contain one of the following compatibles:
> + - "allwinner,sun8i-a33-ths"
> + - "allwinner,sun8i-h3-ths"
> - reg: mmio address range of the chip,
> - #thermal-sensor-cells: shall be 0,
> - #io-channel-cells: shall be 0,
>
> -Example:
> +Required properties for the following compatibles:
> + - "allwinner,sun8i-h3-ths"
> + - clocks: the bus clock and the input clock of the ADC,
> + - clock-names: should be "bus" and "ths",
> + - resets: the bus reset of the ADC,
> +
> +Example for A33:
> ths: ths@01c25000 {
> compatible = "allwinner,sun8i-a33-ths";
> reg = <0x01c25000 0x100>;
> @@ -17,6 +25,17 @@ Example:
> #io-channel-cells = <0>;
> };
>
> +Example for H3:
> + ths: ths@01c25000 {
adc@...
And drop the leading 0.
> + compatible = "allwinner,sun8i-h3-ths";
> + reg = <0x01c25000 0x100>;
> + clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
> + clock-names = "bus", "ths";
> + resets = <&ccu RST_BUS_THS>;
> + #thermal-sensor-cells = <0>;
> + #io-channel-cells = <0>;
> + };
> +
> sun4i, sun5i and sun6i SoCs are also supported via the older binding:
>
> sun4i resistive touchscreen controller
> --
> 2.12.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/7] rtc: Add rtc-sh
From: Rob Herring @ 2017-04-04 14:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Chris Brandt, Alessandro Zummo, Alexandre Belloni, Mark Rutland,
Simon Horman, RTCLINUX,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAMuHMdVmwJYMzspVeDqToBrkfK+zGLMNhxGvEbqCA-vuCUXqoQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Mar 29, 2017 at 1:49 AM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi Rob,
>
> On Wed, Mar 29, 2017 at 3:24 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Wed, Mar 22, 2017 at 10:27:49AM -0400, Chris Brandt wrote:
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-sh.txt
>>> @@ -0,0 +1,29 @@
>>> +* Real Time Clock for Renesas SH and ARM SoCs
>>> +
>>> +Required properties:
>>> +- compatible: Should be "renesas,r7s72100-rtc" and "renesas,sh-rtc" as a
>>> + fallback.
>>> +- reg: physical base address and length of memory mapped region.
>>> +- interrupts: 3 interrupts for alarm, period, and carry.
>>> +- interrupt-names: The interrupts should be labeled as "alarm", "period", and
>>> + "carry".
>>> +- clocks: The functional clock source for the RTC controller must be listed
>>> + first (if exists). Additionally, potential clock counting sources are to be
>>> + listed.
>>> +- clock-names: The functional clock must be labeled as "fck". Other clocks
>>> + may be named in accordance to the SoC hardware manuals.
>>> +
>>> +
>>> +Example:
>>> +rtc: rtc@fcff1000 {
>>> + compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
>>> + reg = <0xfcff1000 0x2e>;
>>> + interrupts = <GIC_SPI 276 IRQ_TYPE_EDGE_RISING
>>> + GIC_SPI 277 IRQ_TYPE_EDGE_RISING
>>> + GIC_SPI 278 IRQ_TYPE_EDGE_RISING>;
>>> + interrupt-names = "alarm", "period", "carry";
>>> + clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>,
>>> + <&rtc_x3_clk>, <&extal_clk>;
>>> + clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
>>> + power-domains = <&cpg_clocks>;
>>
>> Not documented.
>
> "power-domains" is a platform property.
>
> All hardware components need power.
> All synchronous hardware components need a clock.
> Most hardware components have a reset signal.
And we document clocks and reset for every binding.
> Whether these are exposed and can be controlled depends on the platform/SoC.
> So documenting them in each and every device binding looks overkill to me.
> I think this is something to be addressed by devicetree-specification (which
> doesn't handle clocks, power-domains, resets yet).
It's a question of validation. How do I validate power-domains is a
valid property for a given compatible? What if it is required, but not
present? Any node can have it? So it is valid for memory and chosen
nodes, an i2c device, an LCD panel, etc?
> If you prefer, the property can be removed from the example, though.
If it is valid, then I don't want it removed.
Rob
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] mmc: core: add mmc-card hardware reset enable support
From: Richard Leitner @ 2017-04-04 14:16 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw,
adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
jh80.chung-Sze3O3UU22JBDgjK7y7TUQ,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, dev-M/VWbR8SM2SsTnJN9+BGXg,
Richard Leitner
Some eMMCs disable their hardware reset line (RST_N) by default. To enable
it the host must set the corresponding bit in ECSD. An example for such
a device is the Micron MTFCxGACAANA-4M.
This patch adds a new mmc-card devicetree property to let the host enable
this feature during card initialization.
Signed-off-by: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
---
Documentation/devicetree/bindings/mmc/mmc-card.txt | 3 +++
drivers/mmc/core/mmc.c | 21 +++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt b/Documentation/devicetree/bindings/mmc/mmc-card.txt
index a70fcd6..8590a40 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-card.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.txt
@@ -12,6 +12,9 @@ Required properties:
Optional properties:
-broken-hpi : Use this to indicate that the mmc-card has a broken hpi
implementation, and that hpi should not be used
+-enable-hw-reset : some eMMC devices have disabled the hw reset functionality
+ (RST_N_FUNCTION) by default. By adding this property the
+ host will enable it during initialization.
Example:
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index b502601..518d0e3 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1520,9 +1520,16 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
int err;
u32 cid[4];
u32 rocr;
+ struct device_node *np;
+ bool enable_rst_n = false;
WARN_ON(!host->claimed);
+ np = mmc_of_find_child_device(host, 0);
+ if (np && of_device_is_compatible(np, "mmc-card"))
+ enable_rst_n = of_property_read_bool(np, "enable-hw-reset");
+ of_node_put(np);
+
/* Set correct bus mode for MMC before attempting init */
if (!mmc_host_is_spi(host))
mmc_set_bus_mode(host, MMC_BUSMODE_OPENDRAIN);
@@ -1810,6 +1817,20 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
}
}
+ /*
+ * try to enable RST_N if requested
+ * This is needed because some eMMC chips disable this function by
+ * default.
+ */
+ if (enable_rst_n) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_RST_N_FUNCTION, EXT_CSD_RST_N_ENABLED,
+ card->ext_csd.generic_cmd6_time);
+ if (err && err != -EBADMSG)
+ pr_warn("%s: Enabling RST_N feature failed\n",
+ mmc_hostname(card->host));
+ }
+
if (!oldcard)
host->card = card;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] clk: tegra: add missing Tegra210 clocks
From: Thierry Reding @ 2017-04-04 14:03 UTC (permalink / raw)
To: Peter De Schrijver
Cc: Prashant Gaikwad, Michael Turquette, Stephen Boyd,
Jonathan Hunter, Rob Herring, Mark Rutland, Mikko Perttunen,
Rhyland Klein, linux-clk, linux-tegra, linux-kernel, devicetree
In-Reply-To: <1490192598-26862-1-git-send-email-pdeschrijver@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
On Wed, Mar 22, 2017 at 04:23:16PM +0200, Peter De Schrijver wrote:
> iqc1, iqc2, tegra_clk_pll_a_out_adsp, tegra_clk_pll_a_out0_out_adsp, adsp
> and adsp neon were not modelled. dp2 wasn't modelled for Tegra210.
>
> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> ---
> drivers/clk/tegra/clk-id.h | 6 ++++++
> drivers/clk/tegra/clk-tegra-periph.c | 6 ++++++
> drivers/clk/tegra/clk-tegra210.c | 7 +++++++
> include/dt-bindings/clock/tegra210-car.h | 16 ++++++++--------
> 4 files changed, 27 insertions(+), 8 deletions(-)
Applied to for-4.12/clk, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V3 6/6] soc/tegra: Add initial flowctrl support for Tegra132/210
From: Thierry Reding @ 2017-04-04 14:02 UTC (permalink / raw)
To: Jon Hunter
Cc: Rob Herring, Mark Rutland, Russell King, Stephen Warren,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490704978-22906-7-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
On Tue, Mar 28, 2017 at 01:42:58PM +0100, Jon Hunter wrote:
> Tegra132 and Tegra210 support the flowctrl module and so add initial
> support for these devices.
>
> Please note that Tegra186 does not support the flowctrl module, so
> update the initialisation function such that we do not fall back and
> attempt to map the 'hardcoded' address range for Tegra186. Furthermore
> 64-bit Tegra devices have always had the flowctrl node defined in their
> device-tree and so only use the 'hardcoded' addresses for 32-bit Tegra
> devices.
>
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/soc/tegra/Kconfig | 2 ++
> drivers/soc/tegra/flowctrl.c | 31 +++++++++++++++++++++----------
> 2 files changed, 23 insertions(+), 10 deletions(-)
Applied to for-4.12/soc, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V3 5/6] arm64: tegra: Update the Tegra132 flowctrl compatible string
From: Thierry Reding @ 2017-04-04 14:01 UTC (permalink / raw)
To: Jon Hunter
Cc: Rob Herring, Mark Rutland, Russell King, Stephen Warren,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490704978-22906-6-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
On Tue, Mar 28, 2017 at 01:42:57PM +0100, Jon Hunter wrote:
> Update the Tegra132 flowctrl compatible string to include
> "nvidia,tegra132-flowctrl" so it is aligned with the flowctrl binding
> documentation.
>
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm64/boot/dts/nvidia/tegra132.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-4.12/arm64/dt, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V3 4/6] dt-bindings: tegra: Update compatible strings for Tegra flowctrl
From: Thierry Reding @ 2017-04-04 14:01 UTC (permalink / raw)
To: Jon Hunter
Cc: Rob Herring, Mark Rutland, Russell King, Stephen Warren,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490704978-22906-5-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
On Tue, Mar 28, 2017 at 01:42:56PM +0100, Jon Hunter wrote:
> Update the compatible strings for Tegra Flow Control driver to match
> the device-tree source files for Tegra.
>
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Applied to for-4.12/dt-bindings, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V3 3/6] soc/tegra: flowctrl: Add basic platform driver
From: Thierry Reding @ 2017-04-04 14:01 UTC (permalink / raw)
To: Jon Hunter
Cc: Rob Herring, Mark Rutland, Russell King, Stephen Warren,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490704978-22906-4-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
On Tue, Mar 28, 2017 at 01:42:55PM +0100, Jon Hunter wrote:
> Add a simple platform driver for the flowctrl module so that it gets
> registered as a proper device.
>
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/soc/tegra/flowctrl.c | 34 ++++++++++++++++++++++++++++++----
> 1 file changed, 30 insertions(+), 4 deletions(-)
Applied to for-4.12/soc, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V3 2/6] soc/tegra: Move Tegra flowctrl driver
From: Thierry Reding @ 2017-04-04 14:01 UTC (permalink / raw)
To: Jon Hunter
Cc: Rob Herring, Mark Rutland, Russell King, Stephen Warren,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490704978-22906-3-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
On Tue, Mar 28, 2017 at 01:42:54PM +0100, Jon Hunter wrote:
> The flowctrl driver is required for both ARM and ARM64 Tegra devices
> and in order to enable support for it for ARM64, move the Tegra flowctrl
> driver into drivers/soc/tegra.
>
> By moving the flowctrl driver, tegra_flowctrl_init() is now called by
> via an early initcall and to prevent this function from attempting to
> mapping IO space for a non-Tegra device, a test for 'soc_is_tegra()'
> is also added.
>
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm/mach-tegra/Makefile | 1 -
> arch/arm/mach-tegra/cpuidle-tegra20.c | 3 +-
> arch/arm/mach-tegra/flowctrl.c | 179 --------------------------------
> arch/arm/mach-tegra/flowctrl.h | 66 ------------
> arch/arm/mach-tegra/platsmp.c | 2 +-
> arch/arm/mach-tegra/pm.c | 2 +-
> arch/arm/mach-tegra/reset-handler.S | 2 +-
> arch/arm/mach-tegra/sleep-tegra20.S | 3 +-
> arch/arm/mach-tegra/sleep-tegra30.S | 2 +-
> arch/arm/mach-tegra/tegra.c | 2 -
> drivers/soc/tegra/Kconfig | 7 ++
> drivers/soc/tegra/Makefile | 1 +
> drivers/soc/tegra/flowctrl.c | 187 ++++++++++++++++++++++++++++++++++
> include/soc/tegra/flowctrl.h | 82 +++++++++++++++
> 14 files changed, 285 insertions(+), 254 deletions(-)
> delete mode 100644 arch/arm/mach-tegra/flowctrl.c
> delete mode 100644 arch/arm/mach-tegra/flowctrl.h
> create mode 100644 drivers/soc/tegra/flowctrl.c
> create mode 100644 include/soc/tegra/flowctrl.h
Applied to for-4.12/soc, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers
From: Nicolas Ferre @ 2017-04-04 14:00 UTC (permalink / raw)
To: Hans Verkuil, linux-media
Cc: Guennadi Liakhovetski, Songjun Wu, Sakari Ailus, devicetree,
Wu, Songjun
In-Reply-To: <20170328082347.11159-1-hverkuil@xs4all.nl>
Le 28/03/2017 à 10:23, Hans Verkuil a écrit :
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> This patch series converts the soc-camera atmel-isi to a standalone V4L2
> driver.
>
> The same is done for the ov7670 and ov2640 sensor drivers: the ov7670 was
> used to test the atmel-isi driver. The ov2640 is needed because the em28xx
> driver has a soc_camera include dependency. Both ov7670 and ov2640 sensors
> have been tested with the atmel-isi driver.
>
> The first 5 patches improve the ov7670 sensor driver, mostly adding modern
> features such as DT support.
>
> The next three convert the atmel-isi and move it out of soc_camera.
>
> The following 6 patches convert ov2640 and drop the soc_camera dependency
> in em28xx. I have tested that this works with my 'SpeedLink Vicious And
> Divine Laplace webcam'.
>
> Tested with my sama5d3-Xplained board, the ov2640 sensor and two ov7670
> sensors: one with and one without reset/pwdn pins. Also tested with my
> em28xx-based webcam.
>
> I'd like to get this in for 4.12. Fingers crossed.
>
> Regards,
>
> Hans
>
> Changes since v5:
> - Dropped the last two dts patches as these were for demonstration purposes
> only.
> - Simplified isi_graph_init() return handling as suggested by Sakari.
> - Simplified atmel-isi format handling as suggested by Guennadi. Thanks for
> the suggestion, this improves the code nicely!
> - Improved RGB handling in atmel-isi, allowing for all YUV ordering and not
> just YUYV. Tested with YUYV and UYVY (the only two I can test with my
> hardware).
> - Improved commit message of the "atmel-isi: document device tree bindings"
> patch and dropped unnecessary properties from the example as per Rob's
> comments.
>
> Changes since v4:
> - the ov2640 colorspace fixes were inexplicably part of an atmel-isi patch.
> Split it off as a separate patch.
> - add V4L2_SUBDEV_FL_HAS_DEVNODE to ov2640.
> - drop #if defined(CONFIG_MEDIA_CONTROLLER) guard around media_entity_cleanup
> in ov2640.
>
> Changes since v3:
> - ov2640/ov7670: call clk_disable_unprepare where needed. I assumed this was
> done by the devm_clk_get cleanup, but that wasn't the case.
> - bindings: be even more explicit about which properties are mandatory.
> - ov2640/ov7670: drop unused bus-width from the dts binding examples and from
> the actual dts patches.
>
> Changes since v2:
> - Incorporated Sakari's and Rob's device tree bindings comments.
> - ov2640: dropped the reset/power changes. These actually broke the em28xx
> and there was really nothing wrong with it.
> - merged the "ov2640: allow use inside em28xx" into patches 10 and 11.
> It really shouldn't have been a separate patch in the first place.
> - rebased on top of 4.11-rc1.
>
> Changes since v1:
>
> - Dropped MC support from atmel-isi and ov7670: not needed to make this
> work. Only for the ov2640 was it kept since the em28xx driver requires it.
> - Use devm_clk_get instead of clk_get.
> - The ov7670 lower limit of the clock speed is 10 MHz instead of 12. Adjust
> accordingly.
>
>
> Hans Verkuil (14):
> ov7670: document device tree bindings
> ov7670: call v4l2_async_register_subdev
> ov7670: fix g/s_parm
> ov7670: get xclk
> ov7670: add devicetree support
> atmel-isi: update device tree bindings documentation
> atmel-isi: remove dependency of the soc-camera framework
> atmel-isi: move out of soc_camera to atmel
> ov2640: fix colorspace handling
> ov2640: update bindings
> ov2640: convert from soc-camera to a standard subdev sensor driver.
> ov2640: use standard clk and enable it.
> ov2640: add MC support
> em28xx: drop last soc_camera link
For the record, here is my test tag:
Tested-by: Nicolas Ferre <nicolas.ferre@microchip.com>
On a Microchip/Atmel SAMA5D4-EK with OV2640 and the per-existing OV7740.
Thanks a lot Hans for this valuable work!
Best regards,
> .../devicetree/bindings/media/atmel-isi.txt | 91 +-
> .../devicetree/bindings/media/i2c/ov2640.txt | 23 +-
> .../devicetree/bindings/media/i2c/ov7670.txt | 43 +
> MAINTAINERS | 1 +
> drivers/media/i2c/Kconfig | 11 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/{soc_camera => }/ov2640.c | 153 +--
> drivers/media/i2c/ov7670.c | 75 +-
> drivers/media/i2c/soc_camera/Kconfig | 6 -
> drivers/media/i2c/soc_camera/Makefile | 1 -
> drivers/media/platform/Makefile | 1 +
> drivers/media/platform/atmel/Kconfig | 11 +-
> drivers/media/platform/atmel/Makefile | 1 +
> drivers/media/platform/atmel/atmel-isi.c | 1368 ++++++++++++++++++++
> .../platform/{soc_camera => atmel}/atmel-isi.h | 0
> drivers/media/platform/soc_camera/Kconfig | 11 -
> drivers/media/platform/soc_camera/Makefile | 1 -
> drivers/media/platform/soc_camera/atmel-isi.c | 1167 -----------------
> drivers/media/usb/em28xx/em28xx-camera.c | 9 -
> 19 files changed, 1614 insertions(+), 1360 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7670.txt
> rename drivers/media/i2c/{soc_camera => }/ov2640.c (92%)
> create mode 100644 drivers/media/platform/atmel/atmel-isi.c
> rename drivers/media/platform/{soc_camera => atmel}/atmel-isi.h (100%)
> delete mode 100644 drivers/media/platform/soc_camera/atmel-isi.c
>
--
Nicolas Ferre
^ 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