[PATCH v1 16/24] clk: mpc512x: remove now obsolete clkdev registration
after the PSC drivers for UART and SPI mode got converted to device tree based clock lookup, the former MCLK name which depends on the PSC index isn't needed any longer -- remove the clk_register_clkdev() invocation Signed-off-by: Gerhard Sittig g...@denx.de --- arch/powerpc/platforms/512x/clock-commonclk.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c index f31f895..31707b5 100644 --- a/arch/powerpc/platforms/512x/clock-commonclk.c +++ b/arch/powerpc/platforms/512x/clock-commonclk.c @@ -529,16 +529,6 @@ static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry) entry-name_mclk, entry-name_mux1, 1, 1); } - - /* -* without this clock device registration, simple lookups in -* the SPI master initialization and serial port setup will fail -* -* those drivers need to get adjusted to lookup their required -* clocks from OF specs, before this clkdev registration becomes -* obsolete -*/ - clk_register_clkdev(clks[clks_idx_pub], entry-name_mclk, NULL); } static void mpc512x_clk_setup_mclks(struct mclk_setup_data *table, size_t count) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v1 17/24] serial: mpc512x: setup the PSC FIFO clock as well
prepare and enable the FIFO clock upon PSC FIFO initialization, disable
and unprepare the FIFO clock upon PSC FIFO uninitialization, remove the
pre-enable workaround from the platform's clock driver
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/platforms/512x/clock-commonclk.c |2 --
drivers/tty/serial/mpc52xx_uart.c | 47 +
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c
b/arch/powerpc/platforms/512x/clock-commonclk.c
index 31707b5..2c6da07 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -690,8 +690,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
clk_prepare_enable(clks[MPC512x_CLK_MEM]); /* SRAM */
clk_prepare_enable(clks[MPC512x_CLK_IPS]); /* SoC periph */
clk_prepare_enable(clks[MPC512x_CLK_LPC]); /* boot media */
- /* some are required yet no dependencies were declared */
- clk_prepare_enable(clks[MPC512x_CLK_PSC_FIFO]);
/* some are not yet acquired by their respective drivers */
clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
clk_prepare_enable(clks[MPC512x_CLK_FEC]); /* network, NFS */
diff --git a/drivers/tty/serial/mpc52xx_uart.c
b/drivers/tty/serial/mpc52xx_uart.c
index 221fb89..e67d4c0 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -567,35 +567,70 @@ static unsigned int mpc512x_psc_set_baudrate(struct
uart_port *port,
static int __init mpc512x_psc_fifoc_init(void)
{
struct device_node *np;
+ struct clk *clk;
np = of_find_compatible_node(NULL, NULL,
fsl,mpc5121-psc-fifo);
if (!np) {
pr_err(%s: Can't find FIFOC node\n, __func__);
- return -ENODEV;
+ goto out_err;
+ }
+
+ clk = of_clk_get_by_name(np, per);
+ if (IS_ERR(clk)) {
+ pr_err(%s: Can't lookup FIFO clock\n, __func__);
+ goto out_ofnode_put;
+ }
+ if (clk_prepare_enable(clk)) {
+ pr_err(%s: Can't enable FIFO clock\n, __func__);
+ goto out_clk_put;
}
psc_fifoc = of_iomap(np, 0);
if (!psc_fifoc) {
pr_err(%s: Can't map FIFOC\n, __func__);
- of_node_put(np);
- return -ENODEV;
+ goto out_clk_disable;
}
psc_fifoc_irq = irq_of_parse_and_map(np, 0);
- of_node_put(np);
if (psc_fifoc_irq == 0) {
pr_err(%s: Can't get FIFOC irq\n, __func__);
- iounmap(psc_fifoc);
- return -ENODEV;
+ goto out_unmap;
}
+ clk_put(clk);
+ of_node_put(np);
return 0;
+
+out_unmap:
+ iounmap(psc_fifoc);
+out_clk_disable:
+ clk_disable_unprepare(clk);
+out_clk_put:
+ clk_put(clk);
+out_ofnode_put:
+ of_node_put(np);
+out_err:
+ return -ENODEV;
}
static void __exit mpc512x_psc_fifoc_uninit(void)
{
+ struct device_node *np;
+ struct clk *clk;
+
iounmap(psc_fifoc);
+
+ /* disable the clock, errors are not fatal */
+ np = of_find_compatible_node(NULL, NULL, fsl,mpc5121-psc-fifo);
+ if (np) {
+ clk = of_clk_get_by_name(np, per);
+ if (!IS_ERR(clk)) {
+ clk_disable_unprepare(clk);
+ clk_put(clk);
+ }
+ of_node_put(np);
+ }
}
/* 512x specific interrupt handler. The caller holds the port lock */
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v1 18/24] i2c: mpc: OF clock lookup for MPC512x
make the MPC I2C driver prepare and enable the peripheral clock
('per' for register access) in the MPC512x setup routine,
make this clock setup non-fatal to allow for a migration period,
remove the pre-enabling hack in the platform's clock driver
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/platforms/512x/clock-commonclk.c |1 -
drivers/i2c/busses/i2c-mpc.c |9 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c
b/arch/powerpc/platforms/512x/clock-commonclk.c
index 2c6da07..29c51a5 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -693,7 +693,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
/* some are not yet acquired by their respective drivers */
clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
clk_prepare_enable(clks[MPC512x_CLK_FEC]); /* network, NFS */
- clk_prepare_enable(clks[MPC512x_CLK_I2C]);
/*
* some have their individual clock subtree with separate clock
* items and their individual enable counters, yet share a
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7607dc0..13d6822 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -21,6 +21,7 @@
#include linux/of_i2c.h
#include linux/slab.h
+#include linux/clk.h
#include linux/io.h
#include linux/fsl_devices.h
#include linux/i2c.h
@@ -264,11 +265,19 @@ static void mpc_i2c_setup_512x(struct device_node *node,
struct mpc_i2c *i2c,
u32 clock, u32 prescaler)
{
+ struct clk *clk;
struct device_node *node_ctrl;
void __iomem *ctrl;
const u32 *pval;
u32 idx;
+ /* enable clock for the I2C peripheral (non fatal) */
+ clk = of_clk_get_by_name(node, per);
+ if (!IS_ERR(clk)) {
+ clk_prepare_enable(clk);
+ clk_put(clk);
+ }
+
/* Enable I2C interrupts for mpc5121 */
node_ctrl = of_find_compatible_node(NULL, NULL,
fsl,mpc5121-i2c-ctrl);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v1 19/24] USB: fsl-mph-dr-of: OF clock lookup, prepare and enable
device tree based clock lookup in the MPC512x initialization (lookup
'per' for register access), add error check in the clock setup, must
prepare clocks before they can get enabled, unprepare after disable
Signed-off-by: Gerhard Sittig g...@denx.de
---
drivers/usb/host/fsl-mph-dr-of.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 11e0b79..eb564f3 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -260,25 +260,19 @@ int fsl_usb2_mpc5121_init(struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata = pdev-dev.platform_data;
struct clk *clk;
- char clk_name[10];
- int base, clk_num;
-
- base = pdev-resource-start 0xf000;
- if (base == 0x3000)
- clk_num = 1;
- else if (base == 0x4000)
- clk_num = 2;
- else
- return -ENODEV;
+ int err;
- snprintf(clk_name, sizeof(clk_name), usb%d_clk, clk_num);
- clk = clk_get(pdev-dev, clk_name);
+ clk = clk_get(pdev-dev, per);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clk\n);
return PTR_ERR(clk);
}
-
- clk_enable(clk);
+ err = clk_prepare_enable(clk);
+ if (err) {
+ dev_err(pdev-dev, failed to enable clk\n);
+ clk_put(clk);
+ return err;
+ }
pdata-clk = clk;
if (pdata-phy_mode == FSL_USB2_PHY_UTMI_WIDE) {
@@ -303,7 +297,7 @@ static void fsl_usb2_mpc5121_exit(struct platform_device
*pdev)
pdata-regs = NULL;
if (pdata-clk) {
- clk_disable(pdata-clk);
+ clk_disable_unprepare(pdata-clk);
clk_put(pdata-clk);
}
}
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v1 20/24] fs_enet: OF clock lookup (non-fatal), prepare and enable
device tree based clock lookup, must prepare clocks before enabling
them, unprepare after disable, error check in the clock setup, remove
the pre-enable workaround in the MPC512x platform's clock driver
this change implements non-fatal clock lookup since not all platforms
provide device tree specs for clocks, but failure to enable a specified
clock is considered fatal
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/platforms/512x/clock-commonclk.c |1 -
.../net/ethernet/freescale/fs_enet/fs_enet-main.c | 27 +++-
include/linux/fs_enet_pd.h |3 +++
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c
b/arch/powerpc/platforms/512x/clock-commonclk.c
index 29c51a5..31d0cf3 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -692,7 +692,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
clk_prepare_enable(clks[MPC512x_CLK_LPC]); /* boot media */
/* some are not yet acquired by their respective drivers */
clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
- clk_prepare_enable(clks[MPC512x_CLK_FEC]); /* network, NFS */
/*
* some have their individual clock subtree with separate clock
* items and their individual enable counters, yet share a
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 8de53a1..df92e12 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -1020,6 +1020,21 @@ static int fs_enet_probe(struct platform_device *ofdev)
fpi-cp_command = *data;
}
+ /* make clock lookup non-fatal (the driver is shared among platforms),
+* but require enable to succeed when a clock was specified/found
+*/
+ fpi-clk_per = clk_get(ofdev-dev, per);
+ if (IS_ERR(fpi-clk_per))
+ fpi-clk_per = NULL;
+ if (fpi-clk_per) {
+ int err;
+ err = clk_prepare_enable(fpi-clk_per);
+ if (err) {
+ ret = err;
+ goto out_clk_put;
+ }
+ }
+
fpi-rx_ring = 32;
fpi-tx_ring = 32;
fpi-rx_copybreak = 240;
@@ -1028,7 +1043,7 @@ static int fs_enet_probe(struct platform_device *ofdev)
fpi-phy_node = of_parse_phandle(ofdev-dev.of_node, phy-handle, 0);
if ((!fpi-phy_node) (!of_get_property(ofdev-dev.of_node,
fixed-link,
NULL)))
- goto out_free_fpi;
+ goto out_clk_dis;
if (of_device_is_compatible(ofdev-dev.of_node, fsl,mpc5125-fec)) {
phy_connection_type = of_get_property(ofdev-dev.of_node,
@@ -1108,6 +1123,12 @@ out_free_dev:
free_netdev(ndev);
out_put:
of_node_put(fpi-phy_node);
+out_clk_dis:
+ if (fpi-clk_per)
+ clk_disable_unprepare(fpi-clk_per);
+out_clk_put:
+ if (fpi-clk_per)
+ clk_put(fpi-clk_per);
out_free_fpi:
kfree(fpi);
return ret;
@@ -1124,6 +1145,10 @@ static int fs_enet_remove(struct platform_device *ofdev)
fep-ops-cleanup_data(ndev);
dev_set_drvdata(fep-dev, NULL);
of_node_put(fep-fpi-phy_node);
+ if (fep-fpi-clk_per) {
+ clk_disable_unprepare(fep-fpi-clk_per);
+ clk_put(fep-fpi-clk_per);
+ }
free_netdev(ndev);
return 0;
}
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 51b7934..a978d0d 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -16,6 +16,7 @@
#ifndef FS_ENET_PD_H
#define FS_ENET_PD_H
+#include linux/clk.h
#include linux/string.h
#include linux/of_mdio.h
#include asm/types.h
@@ -142,6 +143,8 @@ struct fs_platform_info {
int use_rmii; /* use RMII mode */
int has_phy;/* if the network is phy container as well...*/
+
+ struct clk *clk_per;/* 'per' clock for register access */
};
struct fs_mii_fec_platform_info {
u32 irq[32];
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote: Hi Philipp, On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote: This driver implements a reset controller device that toggle a gpio connected to a reset pin of a peripheral IC. The delay between assertion and de-assertion of the reset signal can be configured via device tree. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Stephen Warren swar...@nvidia.com I see this patch is very useful, as GPIOs are widely used to reset components/devices on board. But I do not find the patch in v3.11-rc1. What's your plan about it? Also, I'm wondering if we should register the driver a little bit early. Please see the following patch. If it makes sense to you, I can send the patch to you, or you can just quash it into yours. And here is another change request. Shawn 8--- From 822a0c4fb7c99b371844ba7e957affcaa8cb1cfe Mon Sep 17 00:00:00 2001 From: Shawn Guo shawn@linaro.org Date: Sun, 14 Jul 2013 20:28:05 +0800 Subject: [PATCH] ENGR00269945: reset: handle cansleep case in gpio-reset Some gpio reset may be backed by a gpio that can sleep, e.g. pca953x gpio output. For such gpio, gpio_set_value_cansleep() should be called. Otherwise, the WARN_ON(chip-can_sleep) in gpiod_set_value() will be hit. Add a gpio_cansleep() check to handle cansleep gpio. Signed-off-by: Shawn Guo shawn@linaro.org --- drivers/reset/gpio-reset.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c index 5d2515a..4f372f9 100644 --- a/drivers/reset/gpio-reset.c +++ b/drivers/reset/gpio-reset.c @@ -32,7 +32,10 @@ static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted) if (drvdata-active_low) value = !value; - gpio_set_value(drvdata-gpio, value); + if (gpio_cansleep(drvdata-gpio)) + gpio_set_value_cansleep(drvdata-gpio, value); + else + gpio_set_value(drvdata-gpio, value); } static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id) -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
On Mon, Jul 15, 2013 at 08:32:33PM -0300, Ezequiel Garcia wrote: This patchset introduces a bunch of fixes that removes the direct use of the shared timer control register, and also removes the need to include a mach-specific header. With this changes the driver can be included in multiplatforms builds, and in particular be used for the Armada 370/XP SoC. Hi Ezequiel Maybe i'm missing something here. You are making use of orion_timer_ctrl_clrset() from time-orion.c. How will this work on 370/XP which has a different clocksource driver? Thanks Andrew ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
Dear Andrew Lunn, On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote: Maybe i'm missing something here. You are making use of orion_timer_ctrl_clrset() from time-orion.c. How will this work on 370/XP which has a different clocksource driver? I *think* the idea is that the Armada 370/XP driver will expose the same function, so from the point of view of the watchdog driver, it will just work. This set of patches is just some preparation patches on the Orion watchdog driver, to later make it usable on Armada 370/XP. The patches enabling its usage on Armada 370/XP will follow. But Ezequiel will confirm all that, we had a discussion together about this yesterday, so I guess what I said should be the plan, but it's better if Ezequiel confirms, obviously :) Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote: Dear Andrew Lunn, On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote: Maybe i'm missing something here. You are making use of orion_timer_ctrl_clrset() from time-orion.c. How will this work on 370/XP which has a different clocksource driver? I *think* the idea is that the Armada 370/XP driver will expose the same function, so from the point of view of the watchdog driver, it will just work. Hi Thomas That was what i was thinking would happen. And then i started to wonder how well the kernel linker deals with multiple definitions of the same symbol. Dove and 370/XP can end up in the same kernel. So we need to have both orion-timer and the 370/XP timer in the same kernel, so we end up with the same symbol in the kernel twice... Lets wait for Ezequiel to answer. Andrew ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
Andrew, Thomas, In the discussion about orion clocksource Russell was proposing a generic thread-safe write. That puts a single lock around all those writes. Of course, it will also blocked by totally unrelated thread-safe register accesses but should prevent us from having dozens of locks and solves the symbol issue. Sebastian On July 16, 2013 9:31:01 AM Andrew Lunn and...@lunn.ch wrote: On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote: Dear Andrew Lunn, On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote: Maybe i'm missing something here. You are making use of orion_timer_ctrl_clrset() from time-orion.c. How will this work on 370/XP which has a different clocksource driver? I *think* the idea is that the Armada 370/XP driver will expose the same function, so from the point of view of the watchdog driver, it will just work. Hi Thomas That was what i was thinking would happen. And then i started to wonder how well the kernel linker deals with multiple definitions of the same symbol. Dove and 370/XP can end up in the same kernel. So we need to have both orion-timer and the 370/XP timer in the same kernel, so we end up with the same symbol in the kernel twice... Lets wait for Ezequiel to answer. Andrew ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/2] drivers: dma-contiguous: add initialization from device tree
Hello Grant,
On 7/11/2013 4:56 PM, Grant Likely wrote:
Hi Marek,
Thanks for working on this. Comments below...
On Wed, Jun 26, 2013 at 2:40 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Add device tree support for contiguous memory regions defined in device
tree. Initialization is done in 2 steps. First, the contiguous memory is
reserved, what happens very early when only flattened device tree is
available. Then on device initialization the corresponding cma regions are
assigned to each device structure.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/contiguous-memory.txt | 94 ++
arch/arm/boot/dts/skeleton.dtsi|7 +-
drivers/base/dma-contiguous.c | 132
3 files changed, 232 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt
diff --git a/Documentation/devicetree/bindings/contiguous-memory.txt
b/Documentation/devicetree/bindings/contiguous-memory.txt
new file mode 100644
index 000..a733df2
--- /dev/null
+++ b/Documentation/devicetree/bindings/contiguous-memory.txt
@@ -0,0 +1,94 @@
+*** Contiguous Memory binding ***
+
+The /chosen/contiguous-memory node provides runtime configuration of
+contiguous memory regions for Linux kernel. Such regions can be created
+for special usage by various device drivers. A good example are
+contiguous memory allocations or memory sharing with other operating
+system(s) on the same hardware board. Those special memory regions might
+depend on the selected board configuration and devices used on the target
+system.
+
+Parameters for each memory region can be encoded into the device tree
+with the following convention:
+
+contiguous-memory {
+
+ (name): region@(base-address) {
+ reg = (baseaddr) (size);
+ (linux,default-contiguous-region);
+ device = device_0 device_1 ...
+ };
+};
Okay, I've gone and read all of the backlog on the 3 versions of the
patch series, and I think I understand the issues. I actually think it
was better off to have the regions specified as children of the memory
node. I understand the argument about how would firmware know what
size the kernel wants and that it would be better to have a kernel
parameter to override the default. However, it is also reasonable for
the kernel to be provided with a default amount of CMA based on the
usage profile of the device. In that regard it is absolutely
appropriate to put the CMA region data into the memory node. I don't
think /chosen is the right place for that.
Thanks for your comments! I will prepare a new version, which will use
/memory node as it was in the first version. I hope that with Your ack
such version can be finally merged.
+
+name: an name given to the defined region;
In the above node example, name: is a label used for creating
phandles. That information doesn't appear in the resulting .dtb
output. The label is actually optional It should instead be:
[(label):] (name)@(address) { }
+base-address: the base address of the defined region;
+size: the size of the memory region (bytes);
The reg property should follow the normal reg rules which are well
defined. That also means that a memory region could have multiple reg
entries if appropriate.
Well, I'm not sure if it really makes sense to support multiple reg
entries.
I also wonder how to provide entries for LPAE systems. They are 32-bit
systems,
but physical addresses can be up to 36bit. How to specify them in device
tree?
+linux,default-contiguous-region: property indicating that the region
+ is the default region for all contiguous memory
+ allocations, Linux specific (optional);
+device:array of phandles to the client device nodes, which
+ will use the defined contiguous region.
This is backwards compared to the way device references usually work.
It would be more consistent for each device node to have a
dma-memory-region property with phandles to one or more memory
regions that it cares about.
+Each defined region must use unique name. It is optional to specify the
+base address, so if one wants to use autoconfiguration of the base
+address, he must specify the '0' as base address in the 'reg' property
+and assign ann uniqe name to such regions, following the convention:
+'region@0', 'region@1', 'region@2', ...
Drop the use of 'region'. name@0 is more typical. It would be
appropriate to have compatible = reserved-memory-region in each of
the reserved regions. That would avoid the problem of two regions
based at the same address having a conflict in name.
Ok.
...
Best regards
--
Marek Szyprowski
Samsung RD Institute Poland
___
devicetree-discuss
[PATCH v1 21/24] [media] fsl-viu: OF clock lookup, prepare before enable
device tree based clock lookup, must prepare clocks before enabling
them, unprepare after disable, error check in the clock setup
Signed-off-by: Gerhard Sittig g...@denx.de
---
drivers/media/platform/fsl-viu.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 221ec42..b95aa43 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1582,8 +1582,11 @@ static int viu_of_probe(struct platform_device *op)
dev_err(op-dev, failed to find the clock module!\n);
ret = -ENODEV;
goto err_clk;
- } else {
- clk_enable(viu_dev-clk);
+ }
+ ret = clk_prepare_enable(viu_dev-clk);
+ if (ret) {
+ dev_err(op-dev, failed to enable the clock!\n);
+ goto err_clk_put;
}
/* reset VIU module */
@@ -1602,7 +1605,8 @@ static int viu_of_probe(struct platform_device *op)
return ret;
err_irq:
- clk_disable(viu_dev-clk);
+ clk_disable_unprepare(viu_dev-clk);
+err_clk_put:
clk_put(viu_dev-clk);
err_clk:
video_unregister_device(viu_dev-vdev);
@@ -1626,7 +1630,7 @@ static int viu_of_remove(struct platform_device *op)
free_irq(dev-irq, (void *)dev);
irq_dispose_mapping(dev-irq);
- clk_disable(dev-clk);
+ clk_disable_unprepare(dev-clk);
clk_put(dev-clk);
video_unregister_device(dev-vdev);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v1 22/24] powerpc/fsl-pci: OF clock lookup, prepare before enable
device tree based clock lookup, must prepare clocks before enabling
them, error check in the clock setup
this change implements non-fatal clock lookup for compatibility with
platforms that don't provide OF clock specs, but failure to enable a
specified clock is considered fatal
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/sysdev/fsl_pci.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..cb2ed92 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -17,6 +17,8 @@
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
+
+#include linux/clk.h
#include linux/kernel.h
#include linux/pci.h
#include linux/delay.h
@@ -741,6 +743,7 @@ err0:
int __init mpc83xx_add_bridge(struct device_node *dev)
{
+ struct clk *clk;
int ret;
int len;
struct pci_controller *hose;
@@ -758,6 +761,18 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
}
pr_debug(Adding PCI host bridge %s\n, dev-full_name);
+ /* non-fatal OF clock lookup, but fatal when a clock
+* was specified yet could not get enabled */
+ clk = of_clk_get_by_name(dev, per);
+ if (!IS_ERR(clk)) {
+ ret = clk_prepare_enable(clk);
+ clk_put(clk);
+ if (ret) {
+ pr_err(Could not enable peripheral clock\n);
+ return ret;
+ }
+ }
+
/* Fetch host bridge registers address */
if (of_address_to_resource(dev, 0, rsrc_reg)) {
printk(KERN_WARNING Can't get pci register base!\n);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v1 23/24] clk: mpc512x: switch to COMMON_CLK, remove PPC_CLOCK
completely switch to, i.e. unconditionally use COMMON_CLK for the
MPC512x platform, and retire the PPC_CLOCK implementation for that
platform after the transition has completed
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/platforms/512x/Kconfig | 14 +-
arch/powerpc/platforms/512x/Makefile |3 +-
arch/powerpc/platforms/512x/clock.c | 753 --
3 files changed, 2 insertions(+), 768 deletions(-)
delete mode 100644 arch/powerpc/platforms/512x/clock.c
diff --git a/arch/powerpc/platforms/512x/Kconfig
b/arch/powerpc/platforms/512x/Kconfig
index c5fcdd0..5aa3f4b 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -1,21 +1,9 @@
-config MPC512x_COMMON_CLK
- bool MPC512x platform uses COMMON_CLK
- default y
- depends on PPC_MPC512x
- help
- This option is only here to support tests and comparison
- during development and migration. This option will get
- removed after the COMMON_CLK support for MPC512x has become
- fully operational and all drivers were adjusted to explicitly
- acquire their required clocks.
-
config PPC_MPC512x
bool 512x-based boards
depends on 6xx
+ select COMMON_CLK
select FSL_SOC
select IPIC
- select PPC_CLOCK if !MPC512x_COMMON_CLK
- select COMMON_CLK if MPC512x_COMMON_CLK
select PPC_PCI_CHOICE
select FSL_PCI if PCI
select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/powerpc/platforms/512x/Makefile
b/arch/powerpc/platforms/512x/Makefile
index 1e05f9d..bb20116 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -1,8 +1,7 @@
#
# Makefile for the Freescale PowerPC 512x linux kernel.
#
-obj-$(CONFIG_PPC_CLOCK)+= clock.o
-obj-$(CONFIG_COMMON_CLK) += clock-commonclk.o
+obj-y += clock-commonclk.o
obj-y += mpc512x_shared.o
obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o
obj-$(CONFIG_MPC512x_GENERIC) += mpc512x_generic.o
diff --git a/arch/powerpc/platforms/512x/clock.c
b/arch/powerpc/platforms/512x/clock.c
deleted file mode 100644
index e504166..000
--- a/arch/powerpc/platforms/512x/clock.c
+++ /dev/null
@@ -1,753 +0,0 @@
-/*
- * Copyright (C) 2007,2008 Freescale Semiconductor, Inc. All rights reserved.
- *
- * Author: John Rigby jri...@freescale.com
- *
- * Implements the clk api defined in include/linux/clk.h
- *
- *Original based on linux/arch/arm/mach-integrator/clock.c
- *
- *Copyright (C) 2004 ARM Limited.
- *Written by Deep Blue Solutions Limited.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include linux/kernel.h
-#include linux/list.h
-#include linux/errno.h
-#include linux/err.h
-#include linux/module.h
-#include linux/string.h
-#include linux/clk.h
-#include linux/mutex.h
-#include linux/io.h
-
-#include linux/of_platform.h
-#include asm/mpc5xxx.h
-#include asm/mpc5121.h
-#include asm/clk_interface.h
-
-#include mpc512x.h
-
-#undef CLK_DEBUG
-
-static int clocks_initialized;
-
-#define CLK_HAS_RATE 0x1 /* has rate in MHz */
-#define CLK_HAS_CTRL 0x2 /* has control reg and bit */
-
-struct clk {
- struct list_head node;
- char name[32];
- int flags;
- struct device *dev;
- unsigned long rate;
- struct module *owner;
- void (*calc) (struct clk *);
- struct clk *parent;
- int reg, bit; /* CLK_HAS_CTRL */
- int div_shift; /* only used by generic_div_clk_calc */
-};
-
-static LIST_HEAD(clocks);
-static DEFINE_MUTEX(clocks_mutex);
-
-static struct clk *mpc5121_clk_get(struct device *dev, const char *id)
-{
- struct clk *p, *clk = ERR_PTR(-ENOENT);
- int dev_match;
- int id_match;
-
- if (dev == NULL || id == NULL)
- return clk;
-
- mutex_lock(clocks_mutex);
- list_for_each_entry(p, clocks, node) {
- dev_match = id_match = 0;
-
- if (dev == p-dev)
- dev_match++;
- if (strcmp(id, p-name) == 0)
- id_match++;
- if ((dev_match || id_match) try_module_get(p-owner)) {
- clk = p;
- break;
- }
- }
- mutex_unlock(clocks_mutex);
-
- return clk;
-}
-
-#ifdef CLK_DEBUG
-static void dump_clocks(void)
-{
- struct clk *p;
-
- mutex_lock(clocks_mutex);
- printk(KERN_INFO CLOCKS:\n);
- list_for_each_entry(p, clocks, node) {
- pr_info( %s=%ld, p-name, p-rate);
- if (p-parent)
- pr_cont( %s=%ld, p-parent-name,
- p-parent-rate);
- if (p-flags
[PATCH v1 24/24] net: can: mscan: remove MPC512x non-COMMON_CLK code path
transition to the COMMON_CLK framework has completed for the MPC512x
platform, remove the now obsolete code path of the mpc5xxx mscan
driver which accessed clock control module registers directly
Signed-off-by: Gerhard Sittig g...@denx.de
---
drivers/net/can/mscan/mpc5xxx_can.c | 136 ---
1 file changed, 136 deletions(-)
diff --git a/drivers/net/can/mscan/mpc5xxx_can.c
b/drivers/net/can/mscan/mpc5xxx_can.c
index dd26ab6..cf5e4cfc 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -108,9 +108,6 @@ static u32 mpc52xx_can_get_clock(struct platform_device
*ofdev,
#endif /* CONFIG_PPC_MPC52xx */
#ifdef CONFIG_PPC_MPC512x
-
-#if IS_ENABLED(CONFIG_COMMON_CLK)
-
static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
const char *clock_source, int *mscan_clksrc)
{
@@ -244,139 +241,6 @@ err_notavail:
dev_err(ofdev-dev, cannot acquire or setup clock source\n);
return 0;
}
-#else /* COMMON_CLK */
-struct mpc512x_clockctl {
- u32 spmr; /* System PLL Mode Reg */
- u32 sccr[2];/* System Clk Ctrl Reg 1 2 */
- u32 scfr1; /* System Clk Freq Reg 1 */
- u32 scfr2; /* System Clk Freq Reg 2 */
- u32 reserved;
- u32 bcr;/* Bread Crumb Reg */
- u32 pccr[12]; /* PSC Clk Ctrl Reg 0-11 */
- u32 spccr; /* SPDIF Clk Ctrl Reg */
- u32 cccr; /* CFM Clk Ctrl Reg */
- u32 dccr; /* DIU Clk Cnfg Reg */
- u32 mccr[4];/* MSCAN Clk Ctrl Reg 1-3 */
-};
-
-static struct of_device_id mpc512x_clock_ids[] = {
- { .compatible = fsl,mpc5121-clock, },
- {}
-};
-
-static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
-const char *clock_name, int *mscan_clksrc)
-{
- struct mpc512x_clockctl __iomem *clockctl;
- struct device_node *np_clock;
- struct clk *sys_clk, *ref_clk;
- int plen, clockidx, clocksrc = -1;
- u32 sys_freq, val, clockdiv = 1, freq = 0;
- const u32 *pval;
-
- np_clock = of_find_matching_node(NULL, mpc512x_clock_ids);
- if (!np_clock) {
- dev_err(ofdev-dev, couldn't find clock node\n);
- return 0;
- }
- clockctl = of_iomap(np_clock, 0);
- if (!clockctl) {
- dev_err(ofdev-dev, couldn't map clock registers\n);
- goto exit_put;
- }
-
- /* Determine the MSCAN device index from the peripheral's
-* physical address. Register address offsets against the
-* IMMR base are: 0x1300, 0x1380, 0x2300, 0x2380
-*/
- pval = of_get_property(ofdev-dev.of_node, reg, plen);
- BUG_ON(!pval || plen sizeof(*pval));
- clockidx = (*pval 0x80) ? 1 : 0;
- if (*pval 0x2000)
- clockidx += 2;
-
- /*
-* Clock source and divider selection: 3 different clock sources
-* can be selected: ip, ref or sys. For the latter two, a
-* clock divider can be defined as well. If the clock source is
-* not specified by the device tree, we first try to find an
-* optimal CAN source clock based on the system clock. If that
-* is not posslible, the reference clock will be used.
-*/
- if (clock_name !strcmp(clock_name, ip)) {
- *mscan_clksrc = MSCAN_CLKSRC_IPS;
- freq = mpc5xxx_get_bus_frequency(ofdev-dev.of_node);
- } else {
- *mscan_clksrc = MSCAN_CLKSRC_BUS;
-
- pval = of_get_property(ofdev-dev.of_node,
- fsl,mscan-clock-divider, plen);
- if (pval plen == sizeof(*pval))
- clockdiv = *pval;
- if (!clockdiv)
- clockdiv = 1;
-
- if (!clock_name || !strcmp(clock_name, sys)) {
- sys_clk = clk_get(ofdev-dev, sys_clk);
- if (IS_ERR(sys_clk)) {
- dev_err(ofdev-dev, couldn't get sys_clk\n);
- goto exit_unmap;
- }
- /* Get and round up/down sys clock rate */
- sys_freq = 100 *
- ((clk_get_rate(sys_clk) + 49) / 100);
-
- if (!clock_name) {
- /* A multiple of 16 MHz would be optimal */
- if ((sys_freq % 1600) == 0) {
- clocksrc = 0;
- clockdiv = sys_freq / 1600;
- freq = sys_freq / clockdiv;
- }
- } else {
- clocksrc = 0;
- freq = sys_freq /
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Mon, Jul 15, 2013 at 07:50:46PM +0100, Rob Herring wrote: On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote: On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. I had to ask Russell again to drop the bindings patches from the patch system, and this is not acceptable since two months have passed and the entire series was reviewed, acked and partially merged. I will review these bindings again but I would like to understand who should give the final go ahead to get these patches queued for upstreaming, I can't continue updating this stuff forever. Most of my comments are for 64-bit. So don't blame me that it had to be reverted. I said up front I was concerned about this change breaking things and it appears it did. New kernels must not require a new DT. The patches in Russell's tree do not break anything, I asked him to drop them since, if we change the bindings again, those patches change and have to be reworked. It was not meant to blame you at all, just saying that the process to get this stuff in the kernel should be defined properly and patches reviewed in a timely fashion. And for legacy reasons the situation related to cpu/cpus node bindings is a complicated one, there are bindings in the ePAPR, bindings in the kernel, people are confused and with this set we wanted to draw a line. For arm64 this is an absolute must. I disagree with you on the new kernels must not require a new DT. That's true if bindings are well defined, not for a mix of legacy ePAPR and bindings-in-the-kernel. What's the DT standard for ARM cpu/cpus node ? ePAPR ? In kernel docs ? A combination thereof ? Things are not clear cut and I do not like that, it is confusing. But yes, this should have been reviewed more quickly. We're working on a plan to help address DT binding reviews. We have not enforced that Grant and I must ack all bindings, but in this case you certainly need mine since I have reviewed it and if you want to me to pull it. Good, that's all I wanted to know, thanks. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) [snip] + # On ARM v8 64-bit systems, where the reg property + size can be 1 or 2 cells (as defined by cpus node's + #address-cells property), this property is + required and matches: + + - On systems running the OS in AArch32: The DTS cannot change based on 32-bit or 64-bit OS. On systems running the OS in AArch32 implies a dependency on the HW execution state. Since the DT is used to configure OSs I thought that could be a valid sentence. Unfortunately this stuff is not C, so I reiterate my point above, before changing it I would like to understand who should say the wording is ok otherwise we could argue forever. It does configure the OS, but not for 32 vs. 64 bit. That is more of a problem for the bootloader to know which mode to boot in and covered under something like Documentation/arm/Booting. Booting ARM vs. Thumb mode would be similar situation. Think about how your PC boots and add to that having a DTB as part of the firmware shipped with your PC. Then the end user can install a 32-bit or 64-bit OS on it. That is the usecase that needs to be supported and having different DTB for 32 and 64 bit is totally broken and doesn't even help solve that problem. I will give it more thought, point taken. + + - cpu-release-addr + Usage: required for systems that have an enable-method + property value of spin-table. + Value type: prop-encoded-array + Definition: + # On ARM v8 64-bit systems must be a two cell + property identifying a 64-bit zero-initialised + memory location. As I mentioned previously, isn't some wake-up method needed? Most systems will be in wfi or wfe rather than continuously spinning. Mmm...this can become a minefield, wfe, wfi, CPU in reset..this needs some thought. Yes, it is today and standardizing this is a good thing.
Re: [PATCH] gpio-rcar: Add interrupt controller support to the DT bindings
Hi Linus,
On Thursday 04 July 2013 19:44:39 Laurent Pinchart wrote:
Update the DT bindings documentation with the interrupt-controller
and #interrupt-cells properties.
Patches that make use of this binding have been merged to Simon's tree. Could
you consider merging this patch in your tree (or tell me I've got something
completely wrong and ask me to fix it :-)) ?
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt index
cb3dc7b..8655df9 100644
--- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
+++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
@@ -23,6 +23,10 @@ Required Properties:
Please refer to gpio.txt in this directory for details of gpio-ranges
property and the common GPIO bindings used by client devices.
+The GPIO controller also acts as an interrupt controller. It uses the
default
+two cells specifier as described in Documentation/devicetree/bindings/
+interrupt-controller/interrupts.txt.
+
Example: R8A7779 (R-Car H1) GPIO controller nodes
gpio0: gpio@ffc4 {
@@ -33,6 +37,8 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes
#gpio-cells = 2;
gpio-controller;
gpio-ranges = pfc 0 0 32;
+ interrupt-controller;
+ #interrupt-cells = 2;
};
...
gpio6: gpio@ffc46000 {
@@ -43,4 +49,6 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes
#gpio-cells = 2;
gpio-controller;
gpio-ranges = pfc 0 192 9;
+ interrupt-controller;
+ #interrupt-cells = 2;
};
--
Regards,
Laurent Pinchart
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
Hi Shawn, Am Dienstag, den 16.07.2013, 12:10 +0800 schrieb Shawn Guo: On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote: It's a little bit late to register gpio-reset driver at module_init time, because gpio-reset provides reset control via gpio for other devices which are mostly probed at module_init time too. And it becomes even worse, when the gpio comes from IO expander on I2C bus, e.g. pca953x. In that case, gpio-reset needs to be ready before I2C bus driver which is generally ready at subsys_initcall time. Let's register gpio-reset driver in arch_initcall() to have it ready early enough. There's no need for the reset driver to be registered before its users; the users of the reset GPIO will simply have their probe deferred until the reset controller is available, and then everything will work out just fine. The defer probe mechanism is not used here, because a reset controller driver should be reasonably registered early than other devices. More importantly, defer probe doe not help in some nasty cases, e.g. the gpio-pca953x device itself needs a reset from gpio-reset driver to start working. That should work fine with deferred probe. I should probably rework the commit log. But I do not see a problem to register gpio-reset driver a little bit earlier. On the other hand, if we reply on deferred probe, many drivers probe could be deferred. For example, on my system, the gpio-pca953x on I2C bus works as a GPIO controller and provides resets to many board level components. Deferring probe of gpio-pca953x on I2C bus means every single probe of all these components gets deferred. IMO, this situation should be reasonably avoided. so you want to have gpio-reset probed at arch_initcall time and you have gpio-pca953x probed at subsys_initcall time. Won't then all gpio-reset devices that use gpios on pca953x to reset other peripherals need to be deferred? regards Philipp ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
Am Dienstag, den 16.07.2013, 14:51 +0800 schrieb Shawn Guo: On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote: Hi Philipp, On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote: This driver implements a reset controller device that toggle a gpio connected to a reset pin of a peripheral IC. The delay between assertion and de-assertion of the reset signal can be configured via device tree. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Stephen Warren swar...@nvidia.com I see this patch is very useful, as GPIOs are widely used to reset components/devices on board. But I do not find the patch in v3.11-rc1. What's your plan about it? Also, I'm wondering if we should register the driver a little bit early. Please see the following patch. If it makes sense to you, I can send the patch to you, or you can just quash it into yours. And here is another change request. Looks good to me. I can squash it into the original patch and resend if you like. regards Philipp Shawn 8--- From 822a0c4fb7c99b371844ba7e957affcaa8cb1cfe Mon Sep 17 00:00:00 2001 From: Shawn Guo shawn@linaro.org Date: Sun, 14 Jul 2013 20:28:05 +0800 Subject: [PATCH] ENGR00269945: reset: handle cansleep case in gpio-reset Some gpio reset may be backed by a gpio that can sleep, e.g. pca953x gpio output. For such gpio, gpio_set_value_cansleep() should be called. Otherwise, the WARN_ON(chip-can_sleep) in gpiod_set_value() will be hit. Add a gpio_cansleep() check to handle cansleep gpio. Signed-off-by: Shawn Guo shawn@linaro.org --- drivers/reset/gpio-reset.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c index 5d2515a..4f372f9 100644 --- a/drivers/reset/gpio-reset.c +++ b/drivers/reset/gpio-reset.c @@ -32,7 +32,10 @@ static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted) if (drvdata-active_low) value = !value; - gpio_set_value(drvdata-gpio, value); + if (gpio_cansleep(drvdata-gpio)) + gpio_set_value_cansleep(drvdata-gpio, value); + else + gpio_set_value(drvdata-gpio, value); } static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
Hi Stephen, Am Montag, den 15.07.2013, 21:35 -0600 schrieb Stephen Warren: On 07/15/2013 07:50 PM, Shawn Guo wrote: Hi Philipp, On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote: This driver implements a reset controller device that toggle a gpio connected to a reset pin of a peripheral IC. The delay between assertion and de-assertion of the reset signal can be configured via device tree. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Stephen Warren swar...@nvidia.com I see this patch is very useful, as GPIOs are widely used to reset components/devices on board. But I do not find the patch in v3.11-rc1. What's your plan about it? Also, I'm wondering if we should register the driver a little bit early. Please see the following patch. If it makes sense to you, I can send the patch to you, or you can just quash it into yours. Shawn ---8 From 2f8ce9e5d6525b98f3828b707458e83fabb39d50 Mon Sep 17 00:00:00 2001 From: Shawn Guo shawn@linaro.org Date: Sun, 14 Jul 2013 20:41:00 +0800 Subject: [PATCH] ENGR00269945: reset: register gpio-reset driver in arch_initcall It's a little bit late to register gpio-reset driver at module_init time, because gpio-reset provides reset control via gpio for other devices which are mostly probed at module_init time too. And it becomes even worse, when the gpio comes from IO expander on I2C bus, e.g. pca953x. In that case, gpio-reset needs to be ready before I2C bus driver which is generally ready at subsys_initcall time. Let's register gpio-reset driver in arch_initcall() to have it ready early enough. There's no need for the reset driver to be registered before its users; the users of the reset GPIO will simply have their probe deferred until the reset controller is available, and then everything will work out just fine. The defer probe mechanism is not used here, because a reset controller driver should be reasonably registered early than other devices. More importantly, defer probe doe not help in some nasty cases, e.g. the gpio-pca953x device itself needs a reset from gpio-reset driver to start working. That should work fine with deferred probe. Deferred probing is fine, but it'd be nice to keep the probe deferral loops to a minimum where possible and/or reasonable. regards Philipp ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC v2 2/5] dma: mpc512x: add support for peripheral transfers
On 07/14/2013 02:01 PM, Gerhard Sittig wrote:
From: Alexander Popov a13xp0p0...@gmail.com
introduce support for slave s/g transfer preparation and the associated
device control callback in the MPC512x DMA controller driver, which adds
support for data transfers between memory and peripheral I/O to the
previously supported mem-to-mem transfers
refuse to prepare chunked transfers (transfers with more than one part)
as long as proper support for scatter/gather is lacking
keep MPC8308 operational by always starting transfers from software,
this SoC appears to not have request lines for flow control when
peripherals are involved in transfers
I had a look at the current driver and it seems that any channel can be used
for memcpy operation not only the MDDRC channel. Since the dmaengine API
will just pick one of the currently free channels when performing a memcpy
operation I think this patch breaks memcpy operations. You probably need to
register two dma controllers, one for memcpy operations one for slave
operations, that way you can ensure that only the MDDRC channel is used for
memcpy operations.
[ introduction of slave s/g preparation and device control ]
Signed-off-by: Alexander Popov a13xp0p0...@gmail.com
[ execute() start condition, mpc8308 compat, terminate all, s/g length check,
reworded commit msg ]
Signed-off-by: Gerhard Sittig g...@denx.de
---
[...]
+
+static int mpc_dma_device_control(struct dma_chan *chan, enum dma_ctrl_cmd
cmd,
+ unsigned long arg)
+{
+ struct mpc_dma_chan *mchan;
+ struct mpc_dma *mdma;
+ struct dma_slave_config *cfg;
+
+ mchan = dma_chan_to_mpc_dma_chan(chan);
+ switch (cmd) {
+ case DMA_TERMINATE_ALL:
+ /* disable channel requests */
+ mdma = dma_chan_to_mpc_dma(chan);
+ out_8(mdma-regs-dmacerq, chan-chan_id);
+ list_splice_tail_init(mchan-prepared, mchan-free);
+ list_splice_tail_init(mchan-queued, mchan-free);
+ list_splice_tail_init(mchan-active, mchan-free);
This probably need locking.
+ return 0;
[...]
+}
+
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Fri, Jul 12, 2013 at 09:47:17AM -0500, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) [snip] + # On ARM v8 64-bit systems, where the reg property + size can be 1 or 2 cells (as defined by cpus node's + #address-cells property), this property is + required and matches: + + - On systems running the OS in AArch32: The DTS cannot change based on 32-bit or 64-bit OS. + + * If the cpus node's #address-cells value is 2: + + The first reg cell must be set to 0. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + Bits [23:0] in the reg cell must be set to + bits [23:0] in MPIDR_EL1. + + All other bits in the reg cell must be 0. + + - On systems running the OS in AArch64: + + * If the cpus node's #address-cells value is 2: + + The first reg cell bits [7:0] must be set to + bits [39:32] of MPIDR_EL1. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + MPIDR_EL1[63:32] is 0 on all processors in the + system. Your logic is backwards here. If the MPIDR_EL1[63:32] is 0, then #address-cells can be 1. You could say the upper bits are ignored and treated as 0. However, you should simplify all this and just mandate that #address-cells must be 2 for ARMv8 or more generally must match the size of the MPIDR. If we want to boot a 32-bit kernel, then the kernel will have to adapt to support this. I'd support this, opting for a clean split. Strictly speaking, it should be this: AArch64-capable hardware: #address-cells = 2 non-AArch64-capable hardware: #address-cells = 1 The only time it is valid to have #address-cells = 1 on AArch64-capable hardware is in an AArch32 virtual machine (in which case, the DT anyway describes the VM and not the real hardware). However, due to the awkwardness of defining precisely what AArch64- capable hardware means in a world containing firmware and hypervisors, it might be better (if slightly less correct) to go with: v8 hardware: #address-cells must be 2 =v7 hardware: #address-cells must be 1 If the firmware boots an AArch32 payload natively on AArch64-capable v8 hardware, it's the firmware's job to ensure that non-addressable CPUs are properly quiesced and shut down, otherwise the setup is pretty broken -- DT can't solve that one, nor can Linux, so we shouldn't try. Linux just needs to discard the non-addressable CPUs and maybe print out a warning. Cheers ---Dave ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR for different IP
Dear Nicolas Ferre, On Tue, 16 Jul 2013 10:46:28 +0200, Nicolas Ferre wrote: Ok, that make sense. I will use compatible names for the capabilities in next version. Thanks. Hold on a little bit Josh, I know that Jean-Christophe is not in favor of the use of multiple compatible strings. So, as the code is already there, let's wait and see if we find another argument... I've asked exactly this question last week at Linaro Connect during the ARM SoC consolidation panel/discussion, where Grant Likely, Arnd Bergmann, Olof and others were answering Device Tree related questions. My question, which precisely had the at91-adc DT binding in mind was precisely whether we should use different compatible properties to identify different revisions of an IP block and let the driver handle those differences, or whether the DT binding should provide sufficient properties (register offsets, bit numbers, etc.) to make the driver independent of the IP revisions. And clearly, the answer was that different compatible properties should be used to identify the different versions of the IP block, and the driver should abstract out the differences. I.e, was has been done for at91-adc is completely the opposite of the best practices for Device Tree on ARM. See http://www.youtube.com/watch?v=zF_AXLgkFy4feature=player_detailpage#t=1581s where I ask exactly this question, and get answers from Olof Johansson and Grant Likely. They clearly say that the solution of having separate compatible properties and a driver that handles the differences is the way to go. So the way at91-adc (and possibly other at91 drivers) is using the Device Tree is wrong, there should have been multiple compatible properties. It's a shame because this is something we did say when we submitted at91-adc and during the reviews, but the maintainer wasn't listening to our comments... Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] tty: serial: Add initial MSM UART High Speed Lite driver
Hi Greg,
On Mon, 2013-07-01 at 12:11 +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
This is a tty driver with console support for Qualcomm's UART
controllers found in the MSM8974 chipsets. Driver is completely
based on implementation found in codeaurora.org msm_serial_hs_lite
with Android dependences removed. Other changes include, moved to
device managed resources and few cleanups.
Driver functionality was tested in LEGACY_HSUART mode.
Please, could you take a look at this driver. It have been
tested on these new Snapdragon 8074 based DragonBoards.
If there is something that I have to fix or improve in
the code please let me know.
Regards,
Ivan
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
.../bindings/tty/serial/msm_serial_hsl.txt | 52 +
drivers/tty/serial/Kconfig | 18 +
drivers/tty/serial/Makefile|1 +
drivers/tty/serial/msm_serial_hsl.c| 1399
drivers/tty/serial/msm_serial_hsl.h| 294
5 files changed, 1764 insertions(+)
create mode 100644
Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
create mode 100644 drivers/tty/serial/msm_serial_hsl.c
create mode 100644 drivers/tty/serial/msm_serial_hsl.h
diff --git a/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
new file mode 100644
index 000..972552f
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
@@ -0,0 +1,52 @@
+* Qualcomm MSM HSUART Lite
+
+Required properties:
+- compatible :
+ qcom,msm-lsuart-v14 to be used for UARTDM Core v1.4
+
+- reg :
+ offset and length of the register set for both the device,
+ UART core and GBSI core
+
+- reg-names :
+ uart_mem to be used as name of the UART core
+ gbsi_mem to be used as name of the GBSI core
+
+The registers for the qcom,msm-lsuart-v14 device have specify
+UART core block. GSBI reg is optional if specified driver will use
+GSBI specific functionality.
+
+- interrupts : interrupts for UART core
+
+- clocks : Must contain an entry for each entry in clock-names.
+
+- clock-names : Must include the following entries:
+ core_clk - mandatory
+ iface_clk - optional
+
+For details see:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Example:
+
+ serial@f991e000 {
+ compatible = qcom,msm-lsuart-v14;
+ reg = 0xf991e000 0x1000;
+ reg-names = uart_mem;
+ interrupts = 0 108 0;
+ clocks = blsp1_uart2_apps_cxc, blsp1_ahb_cxc;
+ clock-names = core_clk, iface_clk;
+ };
+
+Aliases :
+An alias may be optionally used to bind the UART device to a TTY device
+(ttyHSLalias_num) with a given alias number. Aliases are of the form
+uartn where n is an integer representing the alias number to use.
+On systems with multiple UART devices present, an alias may optionally be
+defined for such devices. The alias value should be from 0 to 255.
+
+Example:
+
+ aliases {
+ uart4 = uart7; // This device will be enumerated as ttyHSL4
+ };
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 7e7006f..4482bc7 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1046,6 +1046,24 @@ config SERIAL_MSM_HS
Choose M here to compile it as a module. The module will be
called msm_serial_hs.
+config SERIAL_MSM_HSL
+ tristate MSM High speed serial lite mode driver
+ depends on ARM ARCH_MSM
+ select SERIAL_CORE
+ default n
+ help
+ Select this module to enable MSM high speed lite mode driver
+ for UART controllers found in MSM8974 SoC's
+
+ Choose M here to compile it as a module. The module will be
+ called msm_serial_hsl.
+
+config SERIAL_MSM_HSL_CONSOLE
+ bool MSM High speed serial lite mode console support
+ depends on SERIAL_MSM_HSL=y
+ select SERIAL_CORE_CONSOLE
+ default n
+
config SERIAL_VT8500
bool VIA VT8500 on-chip serial port support
depends on ARCH_VT8500
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index eedfec4..86c023b 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
obj-$(CONFIG_SERIAL_MSM_HS) += msm_serial_hs.o
+obj-$(CONFIG_SERIAL_MSM_HSL) += msm_serial_hsl.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o
diff --git a/drivers/tty/serial/msm_serial_hsl.c
b/drivers/tty/serial/msm_serial_hsl.c
new file mode 100644
index 000..56c15a8
---
[PATCH] ASoC: imx-sgtl5000: fix error return code in imx_sgtl5000_probe()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
sound/soc/fsl/imx-sgtl5000.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index 7a8bc12..25f310d 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -129,8 +129,10 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
}
data-codec_clk = devm_clk_get(codec_dev-dev, NULL);
- if (IS_ERR(data-codec_clk))
+ if (IS_ERR(data-codec_clk)) {
+ ret = PTR_ERR(data-codec_clk);
goto fail;
+ }
data-clk_frequency = clk_get_rate(data-codec_clk);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
Hi Thomas, Andrew: Thanks for looking at this! On Tue, Jul 16, 2013 at 09:31:01AM +0200, Andrew Lunn wrote: On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote: On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote: Maybe i'm missing something here. You are making use of orion_timer_ctrl_clrset() from time-orion.c. How will this work on 370/XP which has a different clocksource driver? I *think* the idea is that the Armada 370/XP driver will expose the same function, so from the point of view of the watchdog driver, it will just work. Indeed that was one of the ideas. As Thomas said, this was just preparation work. That was what i was thinking would happen. And then i started to wonder how well the kernel linker deals with multiple definitions of the same symbol. Dove and 370/XP can end up in the same kernel. So we need to have both orion-timer and the 370/XP timer in the same kernel, so we end up with the same symbol in the kernel twice... Yeah, well... I wasn't sure about using the same name, so another approach would be adding a new compatible to the driver and then make it use the appropriate function in the 370/XP clocksource driver (with a different name). And, yet another approach, is what Sebastian just said, although I'm not sure I understood it :). In any case, we have already several solutions, which is why I'm not too worried about this particular issue. On the other side, I'm much interested in knowing if you are OK with breaking the watchdog DT compatibility. If you NACK this, then I'll start preparing a different watchdog driver for 370/XP, since I don't want to extend a driver that is a bit dirty. -- Ezequiel GarcÃa, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 11:51:19AM +0200, Philipp Zabel wrote: Looks good to me. I can squash it into the original patch and resend if you like. Yes, please. Thanks. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
Hi Sebastian, On Tue, Jul 16, 2013 at 09:48:56AM +0200, Sebastian Hesselbarth wrote: In the discussion about orion clocksource Russell was proposing a generic thread-safe write. That puts a single lock around all those writes. Of course, it will also blocked by totally unrelated thread-safe register accesses but should prevent us from having dozens of locks and solves the symbol issue. Thanks for the insight! I'll try to dig this suggestion in the clocksource discussion. Do you have any plans for posting the clocksource soon? This way I can base this series on something that's in Jason's trees... Thanks! -- Ezequiel GarcÃa, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ASoC: imx-sgtl5000: fix error return code in imx_sgtl5000_probe()
On Tue, Jul 16, 2013 at 08:05:07PM +0800, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Shawn Guo shawn@linaro.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
* Roger Quadros rog...@ti.com [130715 07:11]: Hi Tony, On 06/18/2013 07:04 PM, Roger Quadros wrote: Till the OMAP clocks are correctly defined in device tree, use this temporary hack to provide clock alias to the USB PHY clocks. Without this, USB Host Ethernet will not be functional with device tree boots on Panda and uEVM. Looks like this one got missed out. USB host no longer works on Panda with DT boot. Could you please queue this for next 3.11-rc? Thanks. OK thanks for checking, applying into omap-for-v3.11/fixes. Looks like I also have some pending the .dts changes in omap-for-v3.11/dt branch: 4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB host supprot for Rev. Ax/Bx 9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB Host support fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB host pin naming consistent 39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB Host support Those should get merged as fixes, right? Can you please check and see if they're still OK or if we also need something else? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] ASoC: tlv320aic3x: Add compatible strings for specific devices
From: Mark Brown broo...@linaro.org
The driver supports a range of devices but currently doesn't allow those
device names to be used for enumeration on DT. Add the currently listed
I2C IDs as compatible strings.
Signed-off-by: Mark Brown broo...@linaro.org
---
Documentation/devicetree/bindings/sound/tlv320aic3x.txt | 8 +++-
sound/soc/codecs/tlv320aic3x.c | 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index f47c3f5..26f65f9 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -3,7 +3,13 @@ Texas Instruments - tlv320aic3x Codec module
The tlv320aic3x serial control bus communicates through I2C protocols
Required properties:
-- compatible - string - ti,tlv320aic3x
+
+- compatible - string - One of:
+ti,tlv320aic3x - Generic TLV320AIC3x device
+ti,tlv320aic33 - TLV320AIC33
+ti,tlv320aic3007 - TLV320AIC3007
+
+
- reg - int - I2C slave address
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index e5b9268..c9bb760 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -1582,6 +1582,8 @@ static int aic3x_i2c_remove(struct i2c_client *client)
#if defined(CONFIG_OF)
static const struct of_device_id tlv320aic3x_of_match[] = {
{ .compatible = ti,tlv320aic3x, },
+ { .compatible = ti,tlv320aic33 },
+ { .compatible = ti,tlv320aic3007 },
{},
};
MODULE_DEVICE_TABLE(of, tlv320aic3x_of_match);
--
1.8.3.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] ASoC: tlv320aic3x: List tlv320aic3106 as a supported device
From: Mark Brown broo...@linaro.org
Currently there is no specific handling for it but the tlv320aic3106 is
supported using this driver.
Signed-off-by: Mark Brown broo...@linaro.org
---
Documentation/devicetree/bindings/sound/tlv320aic3x.txt | 1 +
sound/soc/codecs/tlv320aic3x.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index 26f65f9..705a6b1 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -8,6 +8,7 @@ Required properties:
ti,tlv320aic3x - Generic TLV320AIC3x device
ti,tlv320aic33 - TLV320AIC33
ti,tlv320aic3007 - TLV320AIC3007
+ti,tlv320aic3106 - TLV320AIC3106
- reg - int - I2C slave address
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index c9bb760..cad4fb1 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -1492,6 +1492,7 @@ static const struct i2c_device_id aic3x_i2c_id[] = {
{ tlv320aic3x, AIC3X_MODEL_3X },
{ tlv320aic33, AIC3X_MODEL_33 },
{ tlv320aic3007, AIC3X_MODEL_3007 },
+ { tlv320aic3106, AIC3X_MODEL_3X },
{ }
};
MODULE_DEVICE_TABLE(i2c, aic3x_i2c_id);
@@ -1584,6 +1585,7 @@ static const struct of_device_id tlv320aic3x_of_match[] =
{
{ .compatible = ti,tlv320aic3x, },
{ .compatible = ti,tlv320aic33 },
{ .compatible = ti,tlv320aic3007 },
+ { .compatible = ti,tlv320aic3106 },
{},
};
MODULE_DEVICE_TABLE(of, tlv320aic3x_of_match);
--
1.8.3.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 11:49:26AM +0200, Philipp Zabel wrote: so you want to have gpio-reset probed at arch_initcall time and you have gpio-pca953x probed at subsys_initcall time. Won't then all gpio-reset devices that use gpios on pca953x to reset other peripherals need to be deferred? Yes, they will be deferred, but they will be probed and ready at subsys_initcall time when gpio-pca953x probes. This is still good since most of component device drivers probes at module_init time. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: Kirkwood: Fix the internal register ranges translation
Hi Gerlando,
On Tue, Jul 16, 2013 at 11:37:30AM +0200, Gerlando Falauto wrote:
apologies in advance for commenting on an already-merged patch.
Sure, no problem.
On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
Although the internal register window size is 1 MiB, the previous
ranges translation for the internal register space had a size of
0x400. This was done to allow the crypto and nand node to access
the corresponding 'sram' and 'nand' decoding windows.
In order to describe the hardware more accurately, we declare the
real 1 MiB internal register space in the ranges, and add a translation
entry for the nand node to access the 'nand' window.
This commit will make future improvements on the MBus DT binding easier.
Signed-off-by: Ezequiel Garcia
ezequiel.garcia-wi1+55ScJUtKEb57/3fjtnbpr1lh4...@public.gmane.org
---
Tested on Plathome Openblocks A6 board.
arch/arm/boot/dts/kirkwood.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi
b/arch/arm/boot/dts/kirkwood.dtsi
index 8a1e3bb..910fabc 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -38,7 +38,8 @@
ocp@f100 {
compatible = simple-bus;
- ranges = 0x 0xf100 0x400
+ ranges = 0x 0xf100 0x010
+ 0xf400 0xf400 0x400
0xf500 0xf500 0x400;
Apart from consistency with the following range (0xf500) used by
the crypto node, is there any reason why you did not do something like
this instead (which Valentin suggested, but I will take the blame for):
I'm not sure the reason is consistency with the crypto node.
There's an MBus window at 0xf400 for NAND, and that is what is described
in the snippet above; and this is a better reason.
That said, technically speaking, you can have any translation scheme you want,
as long as it ends up in 0xf400.
- ranges = 0x 0xf100 0x400
+ ranges = 0x 0xf100 0x010
+ 0x0300 0xf400 0x400
0xf500 0xf500 0x400;
This would keep a consistent addressing within the child device bus, and
Could you explain how this keeps a consistent addressing?
Frankly, I don't understand why you choose 0x300 ... am I missing something?
Also, speaking of device bus this nand node should be behind a devicebus node.
ranges = MBUS_ID(0xf0, 0x01) 0 0 0xf100 0x10 /*
internal-regs */
MBUS_ID(0x01, 0x2f) 0 0 0xf400 0x400;
devbus {
status = okay;
ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x400;
/* nand */
nand {
compatible = marvell,orion-nand;
reg = 0 0x400;
};
};
(notice this will allow you to relocate the base address of the NAND windows
easily if it conflicts with your PCIe needs).
avoid a later incosistency between the unit-address and the first
reg address:
#address-cells = 1;
#size-cells = 1;
@@ -171,7 +172,7 @@
nand@300 {
^^^
Oh, this should be fixed. I just missed it, and nobody noticed either.
--
Ezequiel GarcÃa, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
On 07/16/2013 03:12 PM, Arend van Spriel wrote: On 07/15/2013 04:05 PM, Roger Quadros wrote: Hi Tony, On 06/18/2013 07:04 PM, Roger Quadros wrote: Till the OMAP clocks are correctly defined in device tree, use this temporary hack to provide clock alias to the USB PHY clocks. Without this, USB Host Ethernet will not be functional with device tree boots on Panda and uEVM. Looks like this one got missed out. Could it be because you promised to resend it (see [1]). I was upgrading our test stuff to 3.11-rc1 and made a DT appended image. Boot went fine, but no USB/ethernet. Should I pickup all four patches? Nevermind. The first three seem to be in already. Regards, Arend [1] http://mid.gmane.org/51c2ec5f.8050...@ti.com USB host no longer works on Panda with DT boot. Could you please queue this for next 3.11-rc? Thanks. cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
On 07/15/2013 04:05 PM, Roger Quadros wrote: Hi Tony, On 06/18/2013 07:04 PM, Roger Quadros wrote: Till the OMAP clocks are correctly defined in device tree, use this temporary hack to provide clock alias to the USB PHY clocks. Without this, USB Host Ethernet will not be functional with device tree boots on Panda and uEVM. Looks like this one got missed out. Could it be because you promised to resend it (see [1]). I was upgrading our test stuff to 3.11-rc1 and made a DT appended image. Boot went fine, but no USB/ethernet. Should I pickup all four patches? Regards, Arend [1] http://mid.gmane.org/51c2ec5f.8050...@ti.com USB host no longer works on Panda with DT boot. Could you please queue this for next 3.11-rc? Thanks. cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] iio: lps331ap: Add support for DT
Hi Jacek, I find myself needing these bindings as well, so I'm definitely interested by your patches. On Tue, Jul 02, 2013 at 02:15:38PM +0200, Lukasz Czerwinski wrote: From: Jacek Anaszewski j.anaszew...@samsung.com This patch adds DT support for the lps331ap barometer sensor. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- .../bindings/iio/pressure/st_pressure.txt | 41 drivers/iio/pressure/st_pressure_i2c.c |9 + drivers/iio/pressure/st_pressure_spi.c |9 + 3 files changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/pressure/st_pressure.txt diff --git a/Documentation/devicetree/bindings/iio/pressure/st_pressure.txt b/Documentation/devicetree/bindings/iio/pressure/st_pressure.txt new file mode 100644 index 000..73a4b7d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/pressure/st_pressure.txt @@ -0,0 +1,41 @@ +* STMicroelectronics LPS331AP barometer sensor + +Required properties: + + - compatible : should be lps331ap + - reg : the I2C address of the barometer + +Optional properties: + + - drdy-int-pin : redirect DRDY on pin INT1 (1) or pin INT2 (2) (u8) + - interrupt-parent : phandle to the interrupt map subnode + - interrupts : interrupt mapping for LPS331AP interrupt sources: + 2 sources: 0 - INT1, 1 - INT2 Maybe you could use interrupts-names here, instead of requiring to hardcode the interrupt index. Plus, I guess that it's assuming that you can only use INT2 when you already use INT1? + - irq-map : irq sub-node defining interrupt map + (all properties listed below are required): + - #interrupt-cells : should be 1 + - #address-cells : should be 0 + - #size-cells : should be 0 + - interrupt-map : table of entries consisting of three child elements: + - unit_interrupt_specifier - 0 : INT1, 1 : INT2 + - interrupt parent phandle + - parent unit interrupt specifier consisiting of two elements: + - index of the interrupt within the controller + - flags : should be 0 I don't really get why it's needed. Isn't that redundant with the interrupt parent and the interrupt number already defined by interrupt-parent and interrupts in the top node? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/10] watchdog: orion: Update device-tree binding documentation
On Mon, Jul 15, 2013 at 08:32:39PM -0300, Ezequiel Garcia wrote:
Now that the 'reg' property meaning has been changed,
this commit updates the deivce-tree binding documentation.
nit. s/deivce/device/
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Documentation/devicetree/bindings/watchdog/orion-wdt.txt | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
index 5dc8d30..48a71fc 100644
--- a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
@@ -3,7 +3,8 @@
Required Properties:
- Compatibility : marvell,orion-wdt
-- reg: Address of the timer registers
+- reg: First cell contains the register for the watchdog
counter.
+ Second cell contains the register for the RSTOUT mask.
Optional properties:
@@ -11,9 +12,10 @@ Optional properties:
Example:
- wdt@20300 {
+ wdt@20324 {
compatible = marvell,orion-wdt;
- reg = 0x20300 0x28;
+ reg = 0x20324 0x4
+0x20108 0x4;
timeout-sec = 10;
status = okay;
};
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
* Roger Quadros rog...@ti.com [130716 06:45]: On 07/16/2013 03:32 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130715 07:11]: Hi Tony, On 06/18/2013 07:04 PM, Roger Quadros wrote: Till the OMAP clocks are correctly defined in device tree, use this temporary hack to provide clock alias to the USB PHY clocks. Without this, USB Host Ethernet will not be functional with device tree boots on Panda and uEVM. Looks like this one got missed out. USB host no longer works on Panda with DT boot. Could you please queue this for next 3.11-rc? Thanks. OK thanks for checking, applying into omap-for-v3.11/fixes. Thanks. Looks like I also have some pending the .dts changes in omap-for-v3.11/dt branch: 4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB host supprot for Rev. Ax/Bx 9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB Host support fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB host pin naming consistent Please disregard those. They are old versions. OK, poof that branch is now gone. Benoit had agreed to take the newer version of those for 3.12. Please pick this one to get usb host working on 3.11 with DT. http://www.spinics.net/lists/arm-kernel/msg253612.html 39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB Host support This one is already in through Benoit. It's best that Benoit queue all those to avoid more confusion :) Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote: On the other side, I'm much interested in knowing if you are OK with breaking the watchdog DT compatibility. If you NACK this, then I'll start preparing a different watchdog driver for 370/XP, since I don't want to extend a driver that is a bit dirty. Apparently there is some agreement that the bindings are still in flux and that they need to be for a bit longer in order to hammer out problems such as this. Arnd and Olof both mentioned that something (a doc, and email?) is forthcoming about marking some bindings as stable. Whatever form that takes, this one wouldn't get the stable marking yet. ;-) Oh, and one more nit. The work 'fix' triggers a whole bunch of get on this right away, does it need to go to stable? Has anyone confirmed it? Which commit caused the regression? etc. Although I hate the word, I think 'refactoring' is much more appropriate description for this series. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ASoC: imx-sgtl5000: fix error return code in imx_sgtl5000_probe()
On Tue, Jul 16, 2013 at 08:05:07PM +0800, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Applied, thanks. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
On Tue, Jul 16, 2013 at 09:44:22AM -0400, Jason Cooper wrote: On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote: On the other side, I'm much interested in knowing if you are OK with breaking the watchdog DT compatibility. If you NACK this, then I'll start preparing a different watchdog driver for 370/XP, since I don't want to extend a driver that is a bit dirty. Apparently there is some agreement that the bindings are still in flux and that they need to be for a bit longer in order to hammer out problems such as this. Arnd and Olof both mentioned that something (a doc, and email?) is forthcoming about marking some bindings as stable. Whatever form that takes, this one wouldn't get the stable marking yet. ;-) Yup, that's my understanding as well. But on the other side, I don't want to break possible users out there. So, just to check, you say it's early enough to safely do such change? In that case, I'll extend this patchset to include Armada 370/XP support and post it as soon as Sebastian's clocksource stuff gets in. Oh, and one more nit. The work 'fix' triggers a whole bunch of get on this right away, does it need to go to stable? Has anyone confirmed it? Which commit caused the regression? etc. Although I hate the word, I think 'refactoring' is much more appropriate description for this series. Oh, good observation. I wrote the cover letter at 8 PM, after ten long hours (*) of hacking and smashing this into something easy to review, and that's the best title I could come up with. I'll change it on v2. Thanks, (*) yes, I have another pair of eyes, in case these wear out. -- Ezequiel GarcÃa, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/10] watchdog: orion: Add a memory resource for RSTOUT register
On Mon, Jul 15, 2013 at 08:32:38PM -0300, Ezequiel Garcia wrote:
Instead of accessing the RSTOUT register directly, this commit
adds a platform memory resource to map this register into the driver.
Hi Ezequiel
Have you looked at:
arch/arm/mach-mvebu/system-controller.c
It is also using this register. Are we going to have a similar problem
as the TIMER_CTRL register, which you refactered in an earlier patch?
marvell,orion-system-controller is not actually used yet, but once
kirkwood moves into mach-mvebu, it will start using it.
Andrew
Note that by adding a required 2nd-cell for the reg property,
this change breaks the device-tree binding compatibility.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
arch/arm/mach-orion5x/include/mach/bridge-regs.h | 1 +
arch/arm/plat-orion/common.c | 10 ++
drivers/watchdog/orion_wdt.c | 18 ++
4 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
index c3f361d..dead75a 100644
--- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
+++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
@@ -21,6 +21,7 @@
#define CPU_RESET0x0002
#define RSTOUTn_MASK (BRIDGE_VIRT_BASE + 0x0108)
+#define RSTOUT_PHYS_BASE (BRIDGE_PHYS_BASE + 0x0108)
#define WDT_RESET_OUT_EN 0x0002
#define SOFT_RESET_OUT_EN0x0004
diff --git a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
index aa35de3..ccd91c9 100644
--- a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
+++ b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
@@ -18,6 +18,7 @@
#define CPU_CTRL (ORION5X_BRIDGE_VIRT_BASE + 0x104)
#define RSTOUTn_MASK (ORION5X_BRIDGE_VIRT_BASE + 0x108)
+#define RSTOUT_PHYS_BASE (ORION5X_BRIDGE_PHYS_BASE + 0x108)
#define WDT_RESET_OUT_EN 0x0002
#define CPU_SOFT_RESET (ORION5X_BRIDGE_VIRT_BASE + 0x10c)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 77fac6c..37924f8 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -594,14 +594,16 @@ void __init orion_spi_1_init(unsigned long mapbase)
/*
* Watchdog
/
-static struct resource orion_wdt_resource =
- DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04);
+static struct resource orion_wdt_resource[] = {
+ DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04),
+ DEFINE_RES_MEM(RSTOUT_PHYS_BASE, 0x04)
+};
static struct platform_device orion_wdt_device = {
.name = orion_wdt,
.id = -1,
- .num_resources = 1,
- .resource = orion_wdt_resource,
+ .num_resources = ARRAY_SIZE(orion_wdt_resource),
+ .resource = orion_wdt_resource,
};
void __init orion_wdt_init(void)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 01bcf53..3c9b3d2 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -43,6 +43,7 @@ static unsigned int wdt_max_duration; /* (seconds) */
static struct clk *clk;
static unsigned int wdt_tclk;
static void __iomem *wdt_reg;
+static void __iomem *rstout_reg;
static DEFINE_SPINLOCK(wdt_lock);
static int orion_wdt_ping(struct watchdog_device *wdt_dev)
@@ -74,9 +75,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
orion_timer_ctrl_clrset(0, WDT_EN);
/* Enable reset on watchdog */
- reg = readl(RSTOUTn_MASK);
- reg |= WDT_RESET_OUT_EN;
- writel(reg, RSTOUTn_MASK);
+ writel(readl(rstout_reg) | WDT_RESET_OUT_EN, rstout_reg);
spin_unlock(wdt_lock);
return 0;
@@ -84,14 +83,10 @@ static int orion_wdt_start(struct watchdog_device
*wdt_dev)
static int orion_wdt_stop(struct watchdog_device *wdt_dev)
{
- u32 reg;
-
spin_lock(wdt_lock);
/* Disable reset on watchdog */
- reg = readl(RSTOUTn_MASK);
- reg = ~WDT_RESET_OUT_EN;
- writel(reg, RSTOUTn_MASK);
+ writel(readl(rstout_reg) ~WDT_RESET_OUT_EN, rstout_reg);
/* Disable watchdog timer */
orion_timer_ctrl_clrset(WDT_EN, 0);
@@ -158,6 +153,13 @@ static int orion_wdt_probe(struct platform_device *pdev)
if (!wdt_reg)
return -ENOMEM;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res)
+ return -ENODEV;
+ rstout_reg = devm_ioremap(pdev-dev, res-start, resource_size(res));
+ if (!rstout_reg)
+ return -ENOMEM;
+
wdt_max_duration = WDT_MAX_CYCLE_COUNT /
Re: [PATCH 05/10] watchdog: orion: Add a memory resource for RSTOUT register
Andrew, On Tue, Jul 16, 2013 at 04:04:15PM +0200, Andrew Lunn wrote: On Mon, Jul 15, 2013 at 08:32:38PM -0300, Ezequiel Garcia wrote: Instead of accessing the RSTOUT register directly, this commit adds a platform memory resource to map this register into the driver. Have you looked at: arch/arm/mach-mvebu/system-controller.c Mmm... I saw the use of the RSTOUT register in kirkwood_restart() but wasn't sure who should be the real 'owner' of this register. It is also using this register. Are we going to have a similar problem as the TIMER_CTRL register, which you refactered in an earlier patch? Probably. marvell,orion-system-controller is not actually used yet, but once kirkwood moves into mach-mvebu, it will start using it. I guess so. We should take that into account *now*. Let me think about it and see if I can have something sane for v2. Thanks! -- Ezequiel GarcÃa, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] regulator: palmas-pmic: doc: fix typo for sleep-mode
commit 3c870e3f9d9d98f1ab98614b3b1fd5c79287d361 (regulator: palmas: Change the DT node property names to follow the convention) Missed updating mode-sleep from sleep-mode. Fix the same. Documentation seems proper for this property. Signed-off-by: Nishanth Menon n...@ti.com --- .../devicetree/bindings/regulator/palmas-pmic.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index d5a3086..04d67f0 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -31,7 +31,7 @@ Optional nodes: Optional sub-node properties: ti,warm-reset - maintain voltage during warm reset(boolean) ti,roof-floor - control voltage selection by pin(boolean) - ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto, + ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto, 2 - eco, 3 - forced pwm ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us ti,smps-range - OTP has the wrong range set for the hardware so override -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] regulator: palmas-pmic: doc: update device tree bindings
On 09:23-20130716, Nishanth Menon wrote: We seem to have a few missing updates to device tree bindings with the latest set of changes getting merged in. Oops.. seems like I have an old mailID for Mark :( Based on v3.11-rc1 tag Nishanth Menon (2): regulator: palmas-pmic: doc: fix typo for sleep-mode regulator: palmas-pmic: doc: remove ti,tstep .../devicetree/bindings/regulator/palmas-pmic.txt |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 1.7.9.5 Regards, Nishanth Menon -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v9] reset: Add driver for gpio-controlled reset pins
This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and de-assertion of the reset signal can be configured via device tree.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Stephen Warren swar...@nvidia.com
---
Changes since v8, as suggested by Shawn:
- added support for I2C gpios via gpio_set_value_cansleep
- switched from module_init to arch_initcall to avoid unnecessary
probe deferral of subsys_initcall drivers like gpio-pca953x.
---
.../devicetree/bindings/reset/gpio-reset.txt | 35
drivers/reset/Kconfig | 11 ++
drivers/reset/Makefile | 1 +
drivers/reset/gpio-reset.c | 188 +
4 files changed, 235 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/gpio-reset.txt
create mode 100644 drivers/reset/gpio-reset.c
diff --git a/Documentation/devicetree/bindings/reset/gpio-reset.txt
b/Documentation/devicetree/bindings/reset/gpio-reset.txt
new file mode 100644
index 000..bca5348
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/gpio-reset.txt
@@ -0,0 +1,35 @@
+GPIO reset controller
+=
+
+A GPIO reset controller controls a single GPIO that is connected to the reset
+pin of a peripheral IC. Please also refer to reset.txt in this directory for
+common reset controller binding usage.
+
+Required properties:
+- compatible: Should be gpio-reset
+- reset-gpios: A gpio used as reset line. The gpio specifier for this property
+ depends on the gpio controller that provides the gpio.
+- #reset-cells: 0, see below
+
+Optional properties:
+- reset-delay-us: delay in microseconds. The gpio reset line will be asserted
for
+ this duration to reset.
+- initially-in-reset: boolean. If not set, the initial state should be a
+ deasserted reset line. If this property exists, the
+ reset line should be kept in reset.
+
+example:
+
+sii902x_reset: gpio-reset {
+ compatible = gpio-reset;
+ reset-gpios = gpio5 0 GPIO_ACTIVE_LOW;
+ reset-delay-us = 1;
+ initially-in-reset;
+ #reset-cells = 0;
+};
+
+/* Device with nRESET pin connected to GPIO5_0 */
+sii902x@39 {
+ /* ... */
+ resets = sii902x_reset; /* active-low GPIO5_0, 10 ms delay */
+};
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..1a862df 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,14 @@ menuconfig RESET_CONTROLLER
via GPIOs or SoC-internal reset controller modules.
If unsure, say no.
+
+if RESET_CONTROLLER
+
+config RESET_GPIO
+ tristate GPIO reset controller support
+ depends on GPIOLIB OF
+ help
+ This driver provides support for reset lines that are controlled
+ directly by GPIOs.
+
+endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1e2d83f..b854f20 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
+obj-$(CONFIG_RESET_GPIO) += gpio-reset.o
diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
new file mode 100644
index 000..e9c15c0
--- /dev/null
+++ b/drivers/reset/gpio-reset.c
@@ -0,0 +1,188 @@
+/*
+ * GPIO Reset Controller driver
+ *
+ * Copyright 2013 Philipp Zabel, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include linux/delay.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/reset-controller.h
+
+struct gpio_reset_data {
+ struct reset_controller_dev rcdev;
+ unsigned int gpio;
+ bool active_low;
+ s32 delay_us;
+};
+
+static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted)
+{
+ struct gpio_reset_data *drvdata = container_of(rcdev,
+ struct gpio_reset_data, rcdev);
+ int value = asserted;
+
+ if (drvdata-active_low)
+ value = !value;
+
+ gpio_set_value(drvdata-gpio, value);
+ if (gpio_cansleep(drvdata-gpio))
+ gpio_set_value_cansleep(drvdata-gpio, value);
+ else
+ gpio_set_value(drvdata-gpio, value);
+}
+
+static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id)
+{
+ struct gpio_reset_data *drvdata = container_of(rcdev,
+ struct gpio_reset_data, rcdev);
+
+ if (drvdata-delay_us 0)
+ return -ENOSYS;
+
+ gpio_reset_set(rcdev, 1);
+ udelay(drvdata-delay_us);
+ gpio_reset_set(rcdev, 0);
+
+
Re: [PATCH -next] ARM: edma: remove duplicated include from edma.c
On 6/26/2013 7:28 AM, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove duplicated include. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Sending this for inclusion in v3.11-rc2. This is technically a clean-up, but this is still -rc1, so lets see. Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On 07/15/2013 10:10 PM, Shawn Guo wrote: On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote: It's a little bit late to register gpio-reset driver at module_init time, because gpio-reset provides reset control via gpio for other devices which are mostly probed at module_init time too. And it becomes even worse, when the gpio comes from IO expander on I2C bus, e.g. pca953x. In that case, gpio-reset needs to be ready before I2C bus driver which is generally ready at subsys_initcall time. Let's register gpio-reset driver in arch_initcall() to have it ready early enough. There's no need for the reset driver to be registered before its users; the users of the reset GPIO will simply have their probe deferred until the reset controller is available, and then everything will work out just fine. The defer probe mechanism is not used here, because a reset controller driver should be reasonably registered early than other devices. More importantly, defer probe doe not help in some nasty cases, e.g. the gpio-pca953x device itself needs a reset from gpio-reset driver to start working. That should work fine with deferred probe. I should probably rework the commit log. But I do not see a problem to register gpio-reset driver a little bit earlier. Registering the driver earlier won't cause any bugs. However, it's not the correct approach. Deferred probe /is/ the approach for assuring correct dependencies between drivers. It works and should be used. There are not enough initcall levels to play games using initcalls and solve all the issues, and the ordering requirements vary board-to-board. Deferred probe at runtime handles this without having to manually place all the drivers into specific initcall levels, and dynamically adjusts to board differences, since it all happens automatically at run-time. Consider a SoC that has: * An external PMIC, which the CPU has to communicate with to enable power to all SoC components outside the CPU and a single I2C instance dedicated to communicating with the PMIC. * An on-SoC reset controller (for on-SoC) modules that resets other on-SoC I2C controllers * An on-SoC I2C controller which communicates with a GPIO expander * One of the GPIOs on that expander is the reset GPIO for some other device connected by I2C What initcall levels are you going to use for all the drivers (PM-related I2C, PMIC, on-SoC reset controller, secondary I2C controller, GPIO expander IC, GPIO-reset device, the final device affected by the GPIO reset controller). Now wonder whether that same order is going to be suitable for every single other board. That's quite unlikely... On the other hand, if we reply on deferred probe, many drivers probe could be deferred. For example, on my system, the gpio-pca953x on I2C bus works as a GPIO controller and provides resets to many board level components. Deferring probe of gpio-pca953x on I2C bus means every single probe of all these components gets deferred. IMO, this situation should be reasonably avoided. Yes, deferred probe will happen. If we want to solve that, I believe we need a more generic solution specifically targeted at that, rather that playing games with initcalls. (It'd be nice if each DT node declared all its resources in a way the DT core could parse them and determine the dependency graph itself, without having to write code in all drivers to extract that information from DT. This would need a standardized resource representation in DT, and as such would mean throwing out all the bindings and starting again... Perhaps some parallel set of properties could be invented to hint at the order, but still fall back to deferred probe where that information was missing or inaccurate.) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On 07/16/2013 12:51 AM, Shawn Guo wrote: On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote: Hi Philipp, On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote: This driver implements a reset controller device that toggle a gpio connected to a reset pin of a peripheral IC. The delay between assertion and de-assertion of the reset signal can be configured via device tree. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Stephen Warren swar...@nvidia.com I see this patch is very useful, as GPIOs are widely used to reset components/devices on board. But I do not find the patch in v3.11-rc1. What's your plan about it? Also, I'm wondering if we should register the driver a little bit early. Please see the following patch. If it makes sense to you, I can send the patch to you, or you can just quash it into yours. And here is another change request. diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c - gpio_set_value(drvdata-gpio, value); + if (gpio_cansleep(drvdata-gpio)) + gpio_set_value_cansleep(drvdata-gpio, value); + else + gpio_set_value(drvdata-gpio, value); That's not right. Calling gpio_set_value() v.s. gpio_set_value_cansleep() should be based on the properties of the calling context, not the GPIO being controlled. In other words, if it's permissible to call gpio_set_value_cansleep() at this point in the code, simply always call that, and remove the conditional logic. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On 07/16/2013 03:59 AM, Philipp Zabel wrote: ... Deferred probing is fine, but it'd be nice to keep the probe deferral loops to a minimum where possible and/or reasonable. I agree, but manually selecting initcalls for drivers is not the solution. See my other email. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9] reset: Add driver for gpio-controlled reset pins
On 07/16/2013 08:33 AM, Philipp Zabel wrote: This driver implements a reset controller device that toggle a gpio connected to a reset pin of a peripheral IC. The delay between assertion and de-assertion of the reset signal can be configured via device tree. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Stephen Warren swar...@nvidia.com --- Changes since v8, as suggested by Shawn: - added support for I2C gpios via gpio_set_value_cansleep - switched from module_init to arch_initcall to avoid unnecessary probe deferral of subsys_initcall drivers like gpio-pca953x. For the record, I'm not convinced that either of those changes is correct. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Hello, version v5 of VExpress SPC driver, please read on the changelog for major changes and explanations. The probing scheme is unchanged, since after trying the early platform devices approach it appeared that the end result was no better than the current one. The only clean solution relies either on changing how secondaries are brought up in the kernel (later than now) or enable early platform device registration through DT. Please check this thread for the related discussion: https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html The interface was adapted to regmap and again reverted to old driver for the following reasons: - Power down registers locking is hairy and requires arch spinlocks in the MCPM back end to work properly, normal spinlocks cannot be used - Regmap adds unnecessary code to manage SPC since it is just a bunch of registers used to control power management flags, the overhead is just not worth it (talking about power down registers, not the vexpress config interface) - The locking scheme behind regmap requires all registers in the map to be protected with the same lock, which is not exactly what we want here - Given the reasons above, adding a regmap interface buys us nothing from a driver readability and maintainability perspective (again just talking about the power interface, a few registers) because for the SPC it would simply not be used /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Thank you for the review in advance, Lorenzo This patch is v5 of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/177150.html v5 changes: - Completely removed vexpress-config interface waiting for refactoring based on regmap - Removed frequency scaling interface and operating points programming retrieval - Trimmed the driver code and DT bindings v4 changes: - Applied review comments (trimmed function names, added comments, refactored some APIs) - Added comments throughout the set - Fixed irq handler bug in checking the transaction status - Improved commit log to explain early init synchro scheme - Created a single static structure for variables dynamically allocated to remove usage of static - Improved Kconfig entry v3 changes: - added __refdata to spc_check_loaded pointer - removed some exported symbols - added node pointer check in vexpress_spc_init() v2 changes: - Dropped timeout interface patch - Converted interfaces to non-timeout ones, integrated and retested - Removed mutex used at init - Refactored code to work around init sections warning - Fixed two minor bugs Lorenzo Pieralisi (1): drivers: mfd: vexpress: add Serial Power Controller (SPC) support Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 36 ++ drivers/mfd/Kconfig| 10 + drivers/mfd/Makefile | 1 + drivers/mfd/vexpress-spc.c | 253 ++ include/linux/vexpress.h | 17 + 5 files changed, 317 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/vexpress-spc.txt create mode 100644 drivers/mfd/vexpress-spc.c -- 1.8.2.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
The TC2 versatile express core tile integrates a logic block that provides the
interface between the dual cluster test-chip and the M3 microcontroller that
carries out power management. The logic block, called Serial Power Controller
(SPC), contains several memory mapped registers to control among other things
low-power states, wake-up irqs and per-CPU jump addresses registers.
This patch provides a driver that enables run-time control of features
implemented by the SPC power management control logic.
The SPC control logic is required to be programmed very early in the boot
process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and
wake-up IRQs for power management. Hence, waiting for core changes to be
made in the device core code to enable early registration of platform
devices, the driver puts in place an early init scheme that allows kernel
drivers to initialize the SPC driver directly from the components requiring
it, if their initialization routine is called before the driver init
function by the boot process.
Device tree bindings documentation for the SPC component is provided with
the patchset.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Olof Johansson o...@lixom.net
Cc: Pawel Moll pawel.m...@arm.com
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Jon Medhurst t...@linaro.org
Signed-off-by: Achin Gupta achin.gu...@arm.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 36 ++
drivers/mfd/Kconfig| 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/vexpress-spc.c | 253 ++
include/linux/vexpress.h | 17 +
5 files changed, 317 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
new file mode 100644
index 000..1614725
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
@@ -0,0 +1,36 @@
+* ARM Versatile Express Serial Power Controller device tree bindings
+
+Latest ARM development boards implement a power management interface (serial
+power controller - SPC) that is capable of managing power states transitions,
+wake-up IRQs and resume addresses for ARM multiprocessor testchips.
+The serial controller can be programmed through a memory mapped interface
+that enables communication between firmware running on the microcontroller
+managing power states and the application processors.
+
+The SPC DT bindings are defined as follows:
+
+- spc node
+
+ - compatible:
+ Usage: required
+ Value type: stringlist
+ Definition: must be
+ arm,vexpress-spc,v2p-ca15_a7, arm,vexpress-spc
+ - reg:
+ Usage: required
+ Value type: prop-encode-array
+ Definition: A standard property that specifies the base address
+ and the size of the SPC address space
+ - interrupts:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: SPC interrupt configuration. A standard property
+that follows ePAPR interrupts specifications
+
+Example:
+
+spc: spc@7fff {
+ compatible = arm,vexpress-spc,v2p-ca15_a7, arm,vexpress-spc;
+ reg = 0x7fff 0x1000;
+ interrupts = 0 95 4;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6959b8d..ebd23f4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1149,3 +1149,13 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile Express.
+
+config VEXPRESS_SPC
+ bool Versatile Express SPC driver support
+ depends on ARM
+ help
+ The Serial Power Controller (SPC) for ARM Ltd. test chips, is
+ an IP that provides a memory mapped interface to power controller
+ HW. The driver provides an API abstraction allowing to program
+ registers controlling low-level power management features like power
+ down flags, global and per-cpu wake-up IRQs.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 718e94a..3a01203 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -153,5 +153,6 @@ obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o vexpress-sysreg.o
+obj-$(CONFIG_VEXPRESS_SPC) += vexpress-spc.o
obj-$(CONFIG_MFD_RETU) += retu-mfd.o
obj-$(CONFIG_MFD_AS3711) += as3711.o
diff --git a/drivers/mfd/vexpress-spc.c b/drivers/mfd/vexpress-spc.c
new file mode 100644
index 000..aa8c2a4
--- /dev/null
+++
Re: [PATCH 2/4] pinmux: Add TB10x pinmux driver
On 07/16/2013 02:47 AM, Christian Ruppert wrote:
On Wed, Jul 10, 2013 at 01:27:52PM -0600, Stephen Warren wrote:
On 07/08/2013 07:02 AM, Christian Ruppert wrote:
...
OK, a small drawing of our hardware should make this clear, let's take
an imaginary example of one port with 10 pins, one i2c interface, one
spi interface and one GPIO bank:
| mux N-1|
++
|| 2
|+--/-- i2c
||
10 || 4
Pins --/--+ mux N +--/-- spi
||
|| 10
|+--/-- GPIO
||
++
| mux N+1|
This example shows the mux N inside the pin controller. It controls
all pins associated to port N through a single register value M. Let's
assume the pins are configured as follows in function of the register
value:
pin M=0 M=1 M=2 M=3
0 GPIO0 SPI_MISO GPIO0 SPI_MISO
1 GPIO1 SPI_MOSI GPIO1 SPI_MOSI
2 GPIO2SPI_CK GPIO2SPI_CK
3 GPIO3SPI_CS GPIO3SPI_CS
4 GPIO4GPIO4GPIO4GPIO4
5 GPIO5GPIO5GPIO5GPIO5
6 GPIO6GPIO6GPIO6GPIO6
7 GPIO7GPIO7GPIO7GPIO7
8 GPIO8GPIO8 I2C_SDA I2C_SDA
9 GPIO9GPIO9 I2C_SCL I2C_SCL
In that scenario, in the language of Linux's pinctrl subsystem, what you
have is:
10 pins, named 0..9
1 pin group, named perhaps mux N.
4 different functions; values M==0, 1, 2, 3.
We now have three pin groups defined, corresponding to the chip-side
ports of the pin controller:
GPIO = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
SPI = {0, 1, 2, 3}
I2C = {8, 9}
You would usually only define pin groups for the pin/ball/package side
of the pinmux HW. IIRC, you're also wanting to define pin groups for the
intra-chip side of the pinmux HW. However, you're not muxing functions
onto those pingroups; they're just there to help with naming the
GPIO-pinmux mapping. You only mux functions onto the pin/ball/package
side pins/pingroups.
Well, the GPIO-pinmux mapping is not the only reason for defining
these groups wrt. the chip-side of the pin controller. The other reasons
are:
- Make different interfaces on the same MUX orthogonal wrt. each
other, i.e. make it possible to request one independently of the
other. In the example above, SPI and I2C can be requested completely
independently and the pin controller driver decides which mode to
use.
But the pinctrl subsystem and bindings don't have any concept of that;
what gets requested is the pins on the chip, or the outer side of the
pin controller. There's no concept of resource management for the
inside of the pin controller.
- Make pin allocation more fine-grained (in the example above, only
pins 0-4 are allocated in case SPI is requested). This makes
GPIO-interface pin conflict management more natural.
I think you'd want to either:
a) Just deal with this in the driver; it knows the HW, and it knows
which mux function is selected for each mux, and hence knows exactly
which pins can be requested as GPIOs for each combination, and can
therefore allow/disallow any GPIO request or mux function change.
b) Extend the pinctrl core to know about this explicitly, and pass
information to the pinctrl core. Presumably, for each combination of
(pingroup, mux function), you'd need a list or bitmask indicating which
pins within the pingroup are actually used. Then, the pinctrl core can
perform all the validation. If you do this, you don't need to invent new
pinctrl groups in order to try and shoe-horn this into pinctrl.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] regulator: palmas-pmic: doc: update device tree bindings
On Tue, Jul 16, 2013 at 09:27:10AM -0500, Nishanth Menon wrote: On 09:23-20130716, Nishanth Menon wrote: We seem to have a few missing updates to device tree bindings with the latest set of changes getting merged in. Oops.. seems like I have an old mailID for Mark :( I'll need the actual patches as well... signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 0/2] regulator: palmas-pmic: doc: update device tree bindings
We seem to have a few missing updates to device tree bindings with the latest set of changes getting merged in. Changes since V1: Apologies on the spam, looks like I got the wrong mail ID first time around :( minor commit message cleanups V1: http://marc.info/?l=linux-docm=137398467901450w=2 Based on v3.11-rc1 tag Nishanth Menon (2): regulator: palmas-pmic: doc: fix typo for sleep-mode regulator: palmas-pmic: doc: remove ti,tstep .../devicetree/bindings/regulator/palmas-pmic.txt |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 1.7.9.5 Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 2/2] regulator: palmas-pmic: doc: remove ti,tstep
commit 28d1e8cd671a53d6b4f967abbbc2a55f7bd333f6
(regulator: palma: add ramp delay support through regulator constraints)
Removed the regulator's ti,step option from driver without updating the
documentation.
So, remove from documentation and example as well.
Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/regulator/palmas-pmic.txt |2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index 04d67f0..30b0581 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -33,7 +33,6 @@ Optional nodes:
ti,roof-floor - control voltage selection by pin(boolean)
ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
2 - eco, 3 - forced pwm
- ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3
2.5mV/us
ti,smps-range - OTP has the wrong range set for the hardware so
override
0 - low range, 1 - high range.
@@ -59,7 +58,6 @@ pmic {
ti,warm-reset;
ti,roof-floor;
ti,mode-sleep = 0;
- ti,tstep = 0;
ti,smps-range = 1;
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC v4] media: OF: add sync-on-green-active property
From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch adds 'sync-on-green-active' property as part of endpoint property. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- Changes for v4: 1: Fixed review comments pointed by Sylwester. Changes for v3: 1: Fixed review comments pointed by Laurent and Sylwester. RFC v2 https://patchwork.kernel.org/patch/2578091/ RFC V1 https://patchwork.kernel.org/patch/2572341/ .../devicetree/bindings/media/video-interfaces.txt |3 +++ drivers/media/v4l2-core/v4l2-of.c |4 include/media/v4l2-mediabus.h |2 ++ 3 files changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..5186c7e 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,9 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +- sync-on-green-active: polarity field when video synchronization is + Sync-On-Green. When set the driver determines whether it's a normal operation + or inverted operation. Example diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index aa59639..5c4c9f0 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -100,6 +100,10 @@ static void v4l2_of_parse_parallel_bus(const struct device_node *node, if (!of_property_read_u32(node, data-shift, v)) bus-data_shift = v; + if (!of_property_read_u32(node, sync-on-green-active, v)) + flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH : + V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW; + bus-flags = flags; } diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..d47eb81 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -40,6 +40,8 @@ #define V4L2_MBUS_FIELD_EVEN_HIGH (1 10) /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */ #define V4L2_MBUS_FIELD_EVEN_LOW (1 11) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH(1 12) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 13) /* Serial flags */ /* How many lanes the client can use */ -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RESEND 1/2] ARM: mmp: Add compatible entries for OLPC XO laptops
Add compatible entries to enable booting of OLPC XO-1.75 (MMP2) and
OLPC XO-4 (MMP3).
Signed-off-by: Chris Ball c...@laptop.org
Signed-off-by: Daniel Drake d...@laptop.org
---
Documentation/devicetree/bindings/arm/mrvl/intc.txt | 4 ++--
Documentation/devicetree/bindings/arm/mrvl/mrvl.txt | 8
arch/arm/mach-mmp/irq.c | 1 +
arch/arm/mach-mmp/mmp2-dt.c | 2 ++
4 files changed, 13 insertions(+), 2 deletions(-)
Resending after 1 month with no response.
diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 8b53273..3554fb9 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -1,8 +1,8 @@
* Marvell MMP Interrupt controller
Required properties:
-- compatible : Should be mrvl,mmp-intc, mrvl,mmp2-intc or
- mrvl,mmp2-mux-intc
+- compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
+ mrvl,mmp2-mux-intc
- reg : Address and length of the register set of the interrupt controller.
If the interrupt controller is intc, address and length means the range
of the whold interrupt controller. If the interrupt controller is mux-intc,
diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
index 117d741..236e884 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
@@ -12,3 +12,11 @@ Required root node properties:
MMP2 Brownstone Board
Required root node properties:
- compatible = mrvl,mmp2-brownstone;
+
+OLPC XO-1.75 (CL2) based on MMP2
+Required root node properties:
+ - compatible = olpc,xo-1.75;
+
+OLPC XO-4 (CL4) based on MMP3
+Required root node properties:
+ - compatible = olpc,xo-cl4;
diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
index 3c71246..d60b85a 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/arch/arm/mach-mmp/irq.c
@@ -329,6 +329,7 @@ void __init mmp2_init_icu(void)
static const struct of_device_id intc_ids[] __initconst = {
{ .compatible = mrvl,mmp-intc, .data = mmp_conf },
{ .compatible = mrvl,mmp2-intc, .data = mmp2_conf },
+ { .compatible = mrvl,mmp3-intc, .data = mmp2_conf },
{}
};
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 4ac2567..e67bd9f 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -44,6 +44,8 @@ static void __init mmp2_dt_init(void)
static const char *mmp2_dt_board_compat[] __initdata = {
mrvl,mmp2-brownstone,
+ olpc,xo-1.75,
+ olpc,xo-cl4,
NULL,
};
--
1.8.1.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RESEND 2/2] ARM: mmp: irq: Improve DT layout
In the mmp2 device tree, the interrupt mux nodes were peers of the
interrupt controller, yet they mapped registers in conflict with the
interrupt controller's register block. Furthermore, the reg properties of
the muxes disagreed with the unit address specified after the node's @-sign.
Move the interrupt mux nodes underneath the interrupt controller node,
because the registers are subordinate to the interrupt controller device,
and update the documentation accordingly.
In the platform code, avoid using of_address_to_resource(). Treating a
reg value of 0x150 as a resource effectively is mapping to memory
location 0x150, which is not what's happening here. Use of_get_address()
instead, to better reflect that we're dealing with an address offset
being read from the device tree.
This adds support for the device tree shipped in the OLPC XO-4 and
additionally these code changes do not break compatibility with the
old DT layout.
Based on work by Mitch Bradley.
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/arm/mrvl/intc.txt | 41 ---
arch/arm/boot/dts/mmp2.dtsi| 128 ++---
arch/arm/mach-mmp/irq.c| 16 +--
3 files changed, 95 insertions(+), 90 deletions(-)
Resending after 1 month with no response.
diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 3554fb9..0c020ff 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -2,21 +2,24 @@
Required properties:
- compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
- mrvl,mmp2-mux-intc
-- reg : Address and length of the register set of the interrupt controller.
- If the interrupt controller is intc, address and length means the range
- of the whold interrupt controller. If the interrupt controller is mux-intc,
- address and length means one register. Since address of mux-intc is in the
- range of intc. mux-intc is secondary interrupt controller.
-- reg-names : Name of the register set of the interrupt controller. It's
- only required in mux-intc interrupt controller.
-- interrupts : Should be the port interrupt shared by mux interrupts. It's
- only required in mux-intc interrupt controller.
+- reg : Address and length of the register set of the whole interrupt
+ controller.
- interrupt-controller : Identifies the node as an interrupt controller.
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source.
- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
controller.
+
+* Marvell MMP Secondary Interrupt controller (mux)
+
+Required properties:
+ - compatible : Shall be mrvl,mmp2-mux-intc
+ Address and length of one register offset into the register address space of
+ the parent interrupt controller node.
+- reg-names : Name of the register set of the interrupt controller.
+- interrupts : Should be the port interrupt shared by mux interrupts.
+- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
+ controller.
- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
detection first.
@@ -27,16 +30,16 @@ Example:
#interrupt-cells = 1;
reg = 0xd4282000 0x1000;
mrvl,intc-nr-irqs = 64;
- };
- intcmux4@d4282150 {
- compatible = mrvl,mmp2-mux-intc;
- interrupts = 4;
- interrupt-controller;
- #interrupt-cells = 1;
- reg = 0x150 0x4, 0x168 0x4;
- reg-names = mux status, mux mask;
- mrvl,intc-nr-irqs = 2;
+ intcmux4@150 {
+ compatible = mrvl,mmp2-mux-intc;
+ interrupts = 4;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ reg = 0x150 0x4, 0x168 0x4;
+ reg-names = mux status, mux mask;
+ mrvl,intc-nr-irqs = 2;
+ };
};
* Marvell Orion Interrupt controller
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 4e8b08c..1f63c8f 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -44,77 +44,77 @@
#interrupt-cells = 1;
reg = 0xd4282000 0x1000;
mrvl,intc-nr-irqs = 64;
- };
- intcmux4: interrupt-controller@d4282150 {
- compatible = mrvl,mmp2-mux-intc;
- interrupts = 4;
- interrupt-controller;
- #interrupt-cells = 1;
- reg = 0x150 0x4, 0x168 0x4;
- reg-names = mux status, mux mask;
-
[PATCH RESEND 2/2] clk: mmp: add support for DT-defined clocks
Add support to the existing mmp clock drivers for clocks to be defined
in the device tree. This will be used on OLPC MMP2/MMP3-based laptops.
If clock info cannot be found in the device tree, we fall back to the
static clock initialization already present.
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/clock/mmp-apbc.txt | 30 ++
.../devicetree/bindings/clock/mmp-apmu.txt | 30 ++
drivers/clk/mmp/clk-apbc.c | 66 +-
drivers/clk/mmp/clk-apmu.c | 37 +++-
drivers/clk/mmp/clk-mmp2.c | 19 ++-
5 files changed, 179 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/mmp-apbc.txt
create mode 100644 Documentation/devicetree/bindings/clock/mmp-apmu.txt
Resending after a month without review.
diff --git a/Documentation/devicetree/bindings/clock/mmp-apbc.txt
b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
new file mode 100644
index 000..88e1253
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Advanced Peripheral Bus clock
+
+Parent apb-clock node
+=
+Required properties:
+- reg: Address and length of the APB clock unit registers
+
+
+Child peripheral clock nodes
+
+Required properties:
+- compatible : shall be marvell,mmp-apb-clock
+- #clock-cells : from common clock binding; shall be set to 1
+- clocks : parent clock, from common clock binding
+- clock-output-names : Array of clock names, from common clock binding
+- reg : Array of control register offsets into APB clock unit register space
+
+
+Example:
+apbc: apb-clock {
+ reg = 0xd4015000 0x1000;
+
+ twsi-clocks {
+ compatible = marvell,mmp-apb-clock;
+ #clock-cells = 1;
+ clocks = vctvxo-clock;
+ clock-output-names = TWSI0, TWSI1;
+ reg = 0x04 0x08;
+ };
+};
diff --git a/Documentation/devicetree/bindings/clock/mmp-apmu.txt
b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
new file mode 100644
index 000..18bb0f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Application Subsystem Power Management Unit
+
+Parent apmu-clock node
+=
+Required properties:
+- reg: Address and length of the CPU Subsystem PMU registers
+
+
+Child peripheral clock nodes
+
+Required properties:
+- compatible : shall be marvell,mmp-apmu-clock
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : parent clock, from common clock binding
+- reg : Control register offsets into parent register space
+- enable-mask : The bits to be set in the register to enable the clock, or
+cleared to disable.
+
+Example:
+apmu-clock {
+ reg = 0xd4282800 0x1000;
+
+ usb-clock {
+ compatible = marvell,mmp-apmu-clock;
+ #clock-cells = 0;
+ clocks = usb_pll;
+ reg = 0x5c;
+ enable-mask = 0x09;
+ };
+};
diff --git a/drivers/clk/mmp/clk-apbc.c b/drivers/clk/mmp/clk-apbc.c
index 89a146a..d53bc79 100644
--- a/drivers/clk/mmp/clk-apbc.c
+++ b/drivers/clk/mmp/clk-apbc.c
@@ -15,6 +15,8 @@
#include linux/err.h
#include linux/delay.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_address.h
#include clk.h
@@ -129,8 +131,70 @@ struct clk *mmp_clk_register_apbc(const char *name, const
char *parent_name,
apbc-hw.init = init;
clk = clk_register(NULL, apbc-hw);
- if (IS_ERR(clk))
+ if (WARN_ON(IS_ERR(clk)))
kfree(apbc);
return clk;
}
+
+static void __init mmp_apbc_dt_init(struct device_node *node)
+{
+ struct device_node *parent = of_get_parent(node);
+ const __be32 *regs;
+ struct clk *clk;
+ int rc;
+ int len;
+ int num_clocks;
+ int clock_num;
+ void __iomem *baseaddr;
+ const char *clock_name;
+ const char *parent_name;
+ struct clk **clks;
+ struct clk_onecell_data *clk_data;
+
+ regs = of_get_property(node, reg, len);
+ if (WARN_ON(!regs || (len % sizeof(__be32) != 0)))
+ return;
+ num_clocks = len / sizeof(__be32);
+
+ baseaddr = of_iomap(parent, 0);
+ of_node_put(parent);
+ if (WARN_ON(!baseaddr))
+ return;
+
+ clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
+ if (WARN_ON(!clk_data))
+ goto err_clk_data;
+
+ clks = kzalloc(num_clocks * sizeof(*clks), GFP_KERNEL);
+ if (WARN_ON(!clks))
+ goto err_clks;
+
+ clock_name = of_get_property(node, clock-output-names, NULL);
+ parent_name = of_clk_get_parent_name(node, 0);
+
+ for (clock_num = 0; clock_num
Re: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR for different IP
On 07/16/2013 12:30 PM, Thomas Petazzoni wrote: Dear Nicolas Ferre, On Tue, 16 Jul 2013 10:46:28 +0200, Nicolas Ferre wrote: Ok, that make sense. I will use compatible names for the capabilities in next version. Thanks. Hold on a little bit Josh, I know that Jean-Christophe is not in favor of the use of multiple compatible strings. So, as the code is already there, let's wait and see if we find another argument... I've asked exactly this question last week at Linaro Connect during the ARM SoC consolidation panel/discussion, where Grant Likely, Arnd Bergmann, Olof and others were answering Device Tree related questions. My question, which precisely had the at91-adc DT binding in mind was precisely whether we should use different compatible properties to identify different revisions of an IP block and let the driver handle those differences, or whether the DT binding should provide sufficient properties (register offsets, bit numbers, etc.) to make the driver independent of the IP revisions. And clearly, the answer was that different compatible properties should be used to identify the different versions of the IP block, and the driver should abstract out the differences. I.e, was has been done for at91-adc is completely the opposite of the best practices for Device Tree on ARM. See http://www.youtube.com/watch?v=zF_AXLgkFy4feature=player_detailpage#t=1581s where I ask exactly this question, and get answers from Olof Johansson and Grant Likely. They clearly say that the solution of having separate compatible properties and a driver that handles the differences is the way to go. So the way at91-adc (and possibly other at91 drivers) is using the Device Tree is wrong, there should have been multiple compatible properties. It's a shame because this is something we did say when we submitted at91-adc and during the reviews, but the maintainer wasn't listening to our comments... Thanks for getting some clarity on this Thomas. So I'll ask the somewhat obvious question - how do we unwind from where we are to where we want to be wrt to the bindings? ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR for different IP
Dear Jonathan Cameron, On Tue, 16 Jul 2013 20:03:38 +0100, Jonathan Cameron wrote: On 07/16/2013 12:30 PM, Thomas Petazzoni wrote: I've asked exactly this question last week at Linaro Connect during the ARM SoC consolidation panel/discussion, where Grant Likely, Arnd Bergmann, Olof and others were answering Device Tree related questions. My question, which precisely had the at91-adc DT binding in mind was precisely whether we should use different compatible properties to identify different revisions of an IP block and let the driver handle those differences, or whether the DT binding should provide sufficient properties (register offsets, bit numbers, etc.) to make the driver independent of the IP revisions. And clearly, the answer was that different compatible properties should be used to identify the different versions of the IP block, and the driver should abstract out the differences. I.e, was has been done for at91-adc is completely the opposite of the best practices for Device Tree on ARM. See http://www.youtube.com/watch?v=zF_AXLgkFy4feature=player_detailpage#t=1581s where I ask exactly this question, and get answers from Olof Johansson and Grant Likely. They clearly say that the solution of having separate compatible properties and a driver that handles the differences is the way to go. So the way at91-adc (and possibly other at91 drivers) is using the Device Tree is wrong, there should have been multiple compatible properties. It's a shame because this is something we did say when we submitted at91-adc and during the reviews, but the maintainer wasn't listening to our comments... Thanks for getting some clarity on this Thomas. So I'll ask the somewhat obvious question - how do we unwind from where we are to where we want to be wrt to the bindings? During Linaro Connect last week, there was some discussion about marking DT bindings as unstable for a little while, once they get reviewed by a group of DT experts that mark them as stable. Until they are stable, the kernel does not offer any ABI guarantees, and we are free to change the DT bindings as needed. Now, since this unstable/stable thing is not in place at the moment, deciding whether to break or not existing bindings is something to be decided by the maintainer of this platform, judging what is the best option depending on whether there are already many users of the DT for this platform or not, for example. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
On 07/16/2013 11:05 AM, Lorenzo Pieralisi wrote:
The TC2 versatile express core tile integrates a logic block that provides the
interface between the dual cluster test-chip and the M3 microcontroller that
carries out power management. The logic block, called Serial Power Controller
(SPC), contains several memory mapped registers to control among other things
low-power states, wake-up irqs and per-CPU jump addresses registers.
This patch provides a driver that enables run-time control of features
implemented by the SPC power management control logic.
The SPC control logic is required to be programmed very early in the boot
process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and
wake-up IRQs for power management. Hence, waiting for core changes to be
made in the device core code to enable early registration of platform
devices, the driver puts in place an early init scheme that allows kernel
drivers to initialize the SPC driver directly from the components requiring
it, if their initialization routine is called before the driver init
function by the boot process.
Device tree bindings documentation for the SPC component is provided with
the patchset.
Just curious, wouldn't a TC2 PSCI implementation eliminate the need for
most/all of this code?
Rob
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Olof Johansson o...@lixom.net
Cc: Pawel Moll pawel.m...@arm.com
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Jon Medhurst t...@linaro.org
Signed-off-by: Achin Gupta achin.gu...@arm.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 36 ++
drivers/mfd/Kconfig| 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/vexpress-spc.c | 253 ++
include/linux/vexpress.h | 17 +
5 files changed, 317 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
new file mode 100644
index 000..1614725
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
@@ -0,0 +1,36 @@
+* ARM Versatile Express Serial Power Controller device tree bindings
+
+Latest ARM development boards implement a power management interface (serial
+power controller - SPC) that is capable of managing power states transitions,
+wake-up IRQs and resume addresses for ARM multiprocessor testchips.
+The serial controller can be programmed through a memory mapped interface
+that enables communication between firmware running on the microcontroller
+managing power states and the application processors.
+
+The SPC DT bindings are defined as follows:
+
+- spc node
+
+ - compatible:
+ Usage: required
+ Value type: stringlist
+ Definition: must be
+ arm,vexpress-spc,v2p-ca15_a7, arm,vexpress-spc
+ - reg:
+ Usage: required
+ Value type: prop-encode-array
+ Definition: A standard property that specifies the base address
+ and the size of the SPC address space
+ - interrupts:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: SPC interrupt configuration. A standard property
+ that follows ePAPR interrupts specifications
+
+Example:
+
+spc: spc@7fff {
+ compatible = arm,vexpress-spc,v2p-ca15_a7, arm,vexpress-spc;
+ reg = 0x7fff 0x1000;
+ interrupts = 0 95 4;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6959b8d..ebd23f4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1149,3 +1149,13 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile Express.
+
+config VEXPRESS_SPC
+ bool Versatile Express SPC driver support
+ depends on ARM
+ help
+ The Serial Power Controller (SPC) for ARM Ltd. test chips, is
+ an IP that provides a memory mapped interface to power controller
+ HW. The driver provides an API abstraction allowing to program
+ registers controlling low-level power management features like power
+ down flags, global and per-cpu wake-up IRQs.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 718e94a..3a01203 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -153,5 +153,6 @@ obj-$(CONFIG_MFD_SEC_CORE)+= sec-core.o sec-irq.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-config.o vexpress-sysreg.o
+obj-$(CONFIG_VEXPRESS_SPC) += vexpress-spc.o
obj-$(CONFIG_MFD_RETU)
Re: [PATCH RFC v4] media: OF: add sync-on-green-active property
Hi Prabhakar, On 07/16/2013 07:19 PM, Prabhakar Lad wrote: From: Lad, Prabhakarprabhakar.cse...@gmail.com This patch adds 'sync-on-green-active' property as part of endpoint property. Signed-off-by: Lad, Prabhakarprabhakar.cse...@gmail.com --- Changes for v4: 1: Fixed review comments pointed by Sylwester. Changes for v3: 1: Fixed review comments pointed by Laurent and Sylwester. RFC v2 https://patchwork.kernel.org/patch/2578091/ RFC V1 https://patchwork.kernel.org/patch/2572341/ .../devicetree/bindings/media/video-interfaces.txt |3 +++ drivers/media/v4l2-core/v4l2-of.c |4 include/media/v4l2-mediabus.h |2 ++ 3 files changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..5186c7e 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,9 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +- sync-on-green-active: polarity field when video synchronization is + Sync-On-Green. When set the driver determines whether it's a normal operation + or inverted operation. Would you mind adding this entry after pclk-sample property description ? And how about describing it a bit more precisely and similarly to VSYNC/HSYNC, e.g. - sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively. Otherwise looks good. Example diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index aa59639..5c4c9f0 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -100,6 +100,10 @@ static void v4l2_of_parse_parallel_bus(const struct device_node *node, if (!of_property_read_u32(node, data-shift,v)) bus-data_shift = v; + if (!of_property_read_u32(node, sync-on-green-active,v)) + flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH : + V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW; + bus-flags = flags; } diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..d47eb81 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -40,6 +40,8 @@ #define V4L2_MBUS_FIELD_EVEN_HIGH (1 10) /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */ #define V4L2_MBUS_FIELD_EVEN_LOW (1 11) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH(1 12) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 13) /* Serial flags */ /* How many lanes the client can use */ Thanks, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4] Input: sysrq - DT binding for key sequence
On 15 July 2013 20:43, Rob Herring robherri...@gmail.com wrote:
On 07/15/2013 10:36 AM, mathieu.poir...@linaro.org wrote:
From: Mathieu J. Poirier mathieu.poir...@linaro.org
Adding a simple device tree binding for the specification of key
sequences.
Definition of the keys found in the sequence are located in
'include/uapi/linux/input.h'.
For the sysrq driver, holding the sequence of keys down for a specific
amount of time
will reset the system.
Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org
---
changes for v4:
- Moved seach of reset sequence nodes to a single call.
---
.../devicetree/bindings/input/input-reset.txt | 34 ++
drivers/tty/sysrq.c| 54
++
2 files changed, 88 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/input-reset.txt
diff --git a/Documentation/devicetree/bindings/input/input-reset.txt
b/Documentation/devicetree/bindings/input/input-reset.txt
new file mode 100644
index 000..79504af
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/input-reset.txt
@@ -0,0 +1,34 @@
+Input: sysrq reset sequence
+
+A simple binding to represent a set of keys as described in
+include/uapi/linux/input.h. This is to communicate a
+sequence of keys to the sysrq driver. Upon holding the keys
+for a specified amount of time (if specified) the system is
+sync'ed and reset.
+
+Key sequences are global to the system but all the keys in a
+set must be coming from the same input device.
+
+The /chosen node should contain a 'linux,sysrq-reset-seq' child
+node to define a set of keys.
+
+Required property:
+sysrq-reset-seq: array of keycodes
+
+Optional property:
+timeout-ms: duration keys must be pressed together in microseconds
milliseconds (ms) or microseconds (us)?
Right, milliseconds.
+before generating a sysrq
+
+Example:
+
+ chosen {
+linux,sysrq-reset-seq {
+keyset = 0x03
+ 0x04
+ 0x0a;
+timeout-ms = 3000;
+};
+ };
+
+Would represent KEY_2, KEY_3 and KEY_9.
+
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index b51c154..01a8729 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -44,6 +44,7 @@
#include linux/uaccess.h
#include linux/moduleparam.h
#include linux/jiffies.h
+#include linux/of.h
#include asm/ptrace.h
#include asm/irq_regs.h
@@ -671,6 +672,50 @@ static void sysrq_detect_reset_sequence(struct
sysrq_state *state,
}
}
+static void sysrq_of_get_keyreset_config(void)
+{
+ unsigned short key;
+ struct device_node *np;
+ const struct property *prop;
+ const __be32 *val;
+ int count, i;
+
+ np = of_find_node_by_path(/chosen/linux,sysrq-reset-seq);
+ if (!np) {
+ pr_debug(No sysrq node found);
+ goto out;
+ }
+
+ prop = of_find_property(np, keyset, NULL);
+ if (!prop || !prop-value) {
+ pr_err(Invalid input keyset);
+ goto out;
+ }
+
+ count = prop-length / sizeof(u32);
+ val = prop-value;
None of the existing helpers to retrieve property arrays doesn't work here?
The problem here is that we never know how long the sequence will be. As
such the 'of_property_read_uXY_array' functions won't work. Or maybe
you're referring to another set of helpers... If so, please clarify.
+
+ if (count SYSRQ_KEY_RESET_MAX)
+ count = SYSRQ_KEY_RESET_MAX;
+
+ /* reset in case a __weak definition was present */
+ sysrq_reset_seq_len = 0;
+
+ for (i = 0; i count; i++) {
+ key = (unsigned short)be32_to_cpup(val++);
+ if (key == KEY_RESERVED || key KEY_MAX)
+ break;
+
+ sysrq_reset_seq[sysrq_reset_seq_len++] = key;
+ }
+
+ /* get reset timeout if any */
+ of_property_read_u32(np, timeout-ms, sysrq_reset_downtime_ms);
+
+ out:
+ ;
+}
+
static void sysrq_reinject_alt_sysrq(struct work_struct *work)
{
struct sysrq_state *sysrq =
@@ -688,6 +733,7 @@ static void sysrq_reinject_alt_sysrq(struct
work_struct *work)
input_inject_event(handle, EV_KEY, KEY_SYSRQ, 1);
input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
+
spurious ws change
input_inject_event(handle, EV_KEY, KEY_SYSRQ, 0);
input_inject_event(handle, EV_KEY, alt_code, 0);
input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
@@ -903,6 +949,7 @@ static inline void sysrq_register_handler(void)
int error;
int i;
+ /* first check if a __weak interface was instantiated */
for (i = 0; i
Re: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
On 07/15/2013 05:02 PM, Stephen Warren wrote: On 07/15/2013 01:34 PM, Rob Herring wrote: On 07/15/2013 01:40 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This property is no longer required by the GPIO binding. Remove it. Won't this break compatibility with older kernel? It is one thing to deprecate, but removal is another. If the relevant maintainers don't care, then I guess it is fine. Yes. I had originally hoped this could sneak in late for 3.11, but I suppose it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to protect. Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10. One more thought here: I know DT bindings are supposed to evolve so that a new kernel will support arbitrary old DTs. I'll call that backwards-compatibility for the DT parsing code. However, this situation is the reverse; this patch would prevent a new DT running on an older kernel. I'll call that forwards-compatibility. I'm not sure if the intent is to support this or not? It's certainly the first I explicitly thought about compatibility in this direction... ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
On Tue, 16 Jul 2013, Rob Herring wrote: On 07/16/2013 11:05 AM, Lorenzo Pieralisi wrote: The TC2 versatile express core tile integrates a logic block that provides the interface between the dual cluster test-chip and the M3 microcontroller that carries out power management. The logic block, called Serial Power Controller (SPC), contains several memory mapped registers to control among other things low-power states, wake-up irqs and per-CPU jump addresses registers. This patch provides a driver that enables run-time control of features implemented by the SPC power management control logic. The SPC control logic is required to be programmed very early in the boot process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and wake-up IRQs for power management. Hence, waiting for core changes to be made in the device core code to enable early registration of platform devices, the driver puts in place an early init scheme that allows kernel drivers to initialize the SPC driver directly from the components requiring it, if their initialization routine is called before the driver init function by the boot process. Device tree bindings documentation for the SPC component is provided with the patchset. Just curious, wouldn't a TC2 PSCI implementation eliminate the need for most/all of this code? There is a PSCI equivalent for the above already, in the sense that there is a simple MCPM backend that bypass most of the MCPM race avoidance code paths and simply calls into PSCI instead. But not all the world is going to be PSCI, and therefore we need to ensure good support for non-PSCI platforms as well. This is why TC2 supports both, and this also ensure that the PSCI implementation, which won't be part of the kernel and therefore unlikely to get the same level of scrutiny, is properly implemented and doesn't introduce any regression when compared to the non PSCI case. Remember that TC2 is multi-cluster which means that the PSCI implementation has to carry the same amount of complexity as the whole in-kernel MCPM layer and that doesn't make me overly confident it is going to always be right. All this to say that we do need this code despite PSCI availability. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 07/15/2013 05:02 PM, Stephen Warren wrote: On 07/15/2013 01:34 PM, Rob Herring wrote: On 07/15/2013 01:40 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This property is no longer required by the GPIO binding. Remove it. Won't this break compatibility with older kernel? It is one thing to deprecate, but removal is another. If the relevant maintainers don't care, then I guess it is fine. Yes. I had originally hoped this could sneak in late for 3.11, but I suppose it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to protect. Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10. One more thought here: I know DT bindings are supposed to evolve so that a new kernel will support arbitrary old DTs. I'll call that backwards-compatibility for the DT parsing code. That is the more common case. However, this situation is the reverse; this patch would prevent a new DT running on an older kernel. I'll call that forwards-compatibility. I'm not sure if the intent is to support this or not? It's certainly the first I explicitly thought about compatibility in this direction... So you would be okay if your computer stopped booting a kernel after a BIOS update? It's the same deal. It's both forwards and backwards compatibility that is needed. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH -next] mtd: orion_nand: convert to use devm_* APIs
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Convert to use devm_* APIs to avoid resources leak on error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/mtd/nand/orion_nand.c | 29 +
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index 46f308d..ce711b4 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -85,25 +85,23 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
int ret = 0;
u32 val = 0;
- nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info),
GFP_KERNEL);
+ nc = devm_kzalloc(pdev-dev,
+ sizeof(struct nand_chip) + sizeof(struct mtd_info),
+ GFP_KERNEL);
if (!nc) {
printk(KERN_ERR orion_nand: failed to allocate device
structure.\n);
- ret = -ENOMEM;
- goto no_res;
+ return -ENOMEM;
}
mtd = (struct mtd_info *)(nc + 1);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- ret = -ENODEV;
- goto no_res;
- }
+ if (!res)
+ return -ENODEV;
- io_base = ioremap(res-start, resource_size(res));
+ io_base = devm_ioremap(pdev-dev, res-start, resource_size(res));
if (!io_base) {
printk(KERN_ERR orion_nand: ioremap failed\n);
- ret = -EIO;
- goto no_res;
+ return -EIO;
}
if (pdev-dev.of_node) {
@@ -111,8 +109,7 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
GFP_KERNEL);
if (!board) {
printk(KERN_ERR orion_nand: failed to allocate board
structure.\n);
- ret = -ENOMEM;
- goto no_res;
+ return -ENOMEM;
}
if (!of_property_read_u32(pdev-dev.of_node, cle, val))
board-cle = (u8)val;
@@ -186,10 +183,6 @@ no_dev:
clk_disable_unprepare(clk);
clk_put(clk);
}
- iounmap(io_base);
-no_res:
- kfree(nc);
-
return ret;
}
@@ -201,10 +194,6 @@ static int orion_nand_remove(struct platform_device *pdev)
nand_release(mtd);
- iounmap(nc-IO_ADDR_W);
-
- kfree(nc);
-
clk = clk_get(pdev-dev, NULL);
if (!IS_ERR(clk)) {
clk_disable_unprepare(clk);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4] Input: sysrq - DT binding for key sequence
On Tue, Jul 16, 2013 at 5:24 PM, Mathieu Poirier
mathieu.poir...@linaro.org wrote:
On 15 July 2013 20:43, Rob Herring robherri...@gmail.com wrote:
On 07/15/2013 10:36 AM, mathieu.poir...@linaro.org wrote:
From: Mathieu J. Poirier mathieu.poir...@linaro.org
[snip]
+ prop = of_find_property(np, keyset, NULL);
+ if (!prop || !prop-value) {
+ pr_err(Invalid input keyset);
+ goto out;
+ }
+
+ count = prop-length / sizeof(u32);
+ val = prop-value;
None of the existing helpers to retrieve property arrays doesn't work
here?
The problem here is that we never know how long the sequence will be. As
such the 'of_property_read_uXY_array' functions won't work. Or maybe you're
referring to another set of helpers... If so, please clarify.
What about of_property_for_each_u32? Or we should make
of_property_read_uXY_array work with arrays that can be less than some
max size.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
On 07/16/2013 07:50 PM, Rob Herring wrote: On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 07/15/2013 05:02 PM, Stephen Warren wrote: On 07/15/2013 01:34 PM, Rob Herring wrote: On 07/15/2013 01:40 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This property is no longer required by the GPIO binding. Remove it. Won't this break compatibility with older kernel? It is one thing to deprecate, but removal is another. If the relevant maintainers don't care, then I guess it is fine. Yes. I had originally hoped this could sneak in late for 3.11, but I suppose it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to protect. Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10. One more thought here: I know DT bindings are supposed to evolve so that a new kernel will support arbitrary old DTs. I'll call that backwards-compatibility for the DT parsing code. That is the more common case. However, this situation is the reverse; this patch would prevent a new DT running on an older kernel. I'll call that forwards-compatibility. I'm not sure if the intent is to support this or not? It's certainly the first I explicitly thought about compatibility in this direction... So you would be okay if your computer stopped booting a kernel after a BIOS update? It's the same deal. It's both forwards and backwards compatibility that is needed. I would strongly hope the BIOS/bootloader/... would have nothing to do with the DT content. There's a reason that Grant asserted early on that DTBs shouldn't be part of the BIOS/bootloader, but rather stored separately, so the DTB could be updated without updating firmware, just like the kernel. And I see no real problem with a new DTB requiring a new kernel or even vice-versa to be honest. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote: Registering the driver earlier won't cause any bugs. However, it's not the correct approach. Deferred probe /is/ the approach for assuring correct dependencies between drivers. It works and should be used. There are not enough initcall levels to play games using initcalls and solve all the issues, and the ordering requirements vary board-to-board. Deferred probe at runtime handles this without having to manually place all the drivers into specific initcall levels, and dynamically adjusts to board differences, since it all happens automatically at run-time. I do not quite follow the argument here. I agree with you that deferred probe is the approach to solve dependencies. But it does not necessarily mean that initcall can not be used to help it save some nasty or nested deferring. Deferred probe and initcalls are not two mutually exclusive mechanisms but two which can help each other. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On 07/16/2013 04:45 AM, Lorenzo Pieralisi wrote: On Mon, Jul 15, 2013 at 07:50:46PM +0100, Rob Herring wrote: On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote: On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. I had to ask Russell again to drop the bindings patches from the patch system, and this is not acceptable since two months have passed and the entire series was reviewed, acked and partially merged. I will review these bindings again but I would like to understand who should give the final go ahead to get these patches queued for upstreaming, I can't continue updating this stuff forever. Most of my comments are for 64-bit. So don't blame me that it had to be reverted. I said up front I was concerned about this change breaking things and it appears it did. New kernels must not require a new DT. The patches in Russell's tree do not break anything, I asked him to drop them since, if we change the bindings again, those patches change and have to be reworked. It was not meant to blame you at all, just saying that the process to get this stuff in the kernel should be defined properly and patches reviewed in a timely fashion. And for legacy reasons the situation related to cpu/cpus node bindings is a complicated one, there are bindings in the ePAPR, bindings in the kernel, people are confused and with this set we wanted to draw a line. For arm64 this is an absolute must. I disagree with you on the new kernels must not require a new DT. That's true if bindings are well defined, not for a mix of legacy ePAPR and bindings-in-the-kernel. Well defined depends on the platform. For purposes of a single cluster ARM system, the ePAPR was pretty much sufficient for cpu node description. The initial discussion was whether we even needed cpu nodes at all. We're always going to have something new that we did not account for. So even for well defined bindings, we'll have to make changes/extensions at some point. It just needs to be years, not months for changes. What's the DT standard for ARM cpu/cpus node ? ePAPR ? In kernel docs ? A combination thereof ? Things are not clear cut and I do not like that, it is confusing. ePAPR is a guideline, but in the end it is a PowerPC document. In some cases we can just use what it defines and in others we need to deviate. In an ideal world, we would create the equivalent for ARM or figure out how to merge ARM requirements with ePAPR. However, since UEFI and ACPI are going to solve all our problems, no one seems interested in defining a more formal document. To further complicate things, there is also the original OF specification to follow as well. So I would say all the docs apply and the order of priority is DT binding docs, ePAPR, OF specs. The DT binding docs need to be complete enough to avoid confusion. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Tue, 16 Jul 2013, Lorenzo Pieralisi wrote: Hello, version v5 of VExpress SPC driver, please read on the changelog for major changes and explanations. The probing scheme is unchanged, since after trying the early platform devices approach it appeared that the end result was no better than the current one. The only clean solution relies either on changing how secondaries are brought up in the kernel (later than now) or enable early platform device registration through DT. Please check this thread for the related discussion: https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html The interface was adapted to regmap and again reverted to old driver for the following reasons: - Power down registers locking is hairy and requires arch spinlocks in the MCPM back end to work properly, normal spinlocks cannot be used - Regmap adds unnecessary code to manage SPC since it is just a bunch of registers used to control power management flags, the overhead is just not worth it (talking about power down registers, not the vexpress config interface) - The locking scheme behind regmap requires all registers in the map to be protected with the same lock, which is not exactly what we want here - Given the reasons above, adding a regmap interface buys us nothing from a driver readability and maintainability perspective (again just talking about the power interface, a few registers) because for the SPC it would simply not be used /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Thank you for the review in advance, Lorenzo I've integrated this patch in my MCPM backend for TC2 patch series. ACKs from concerned/interested people would be appreciated so I could send this for ARM-SOC inclusion right away. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 09:47:02AM -0600, Stephen Warren wrote: diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c - gpio_set_value(drvdata-gpio, value); + if (gpio_cansleep(drvdata-gpio)) + gpio_set_value_cansleep(drvdata-gpio, value); + else + gpio_set_value(drvdata-gpio, value); That's not right. Calling gpio_set_value() v.s. gpio_set_value_cansleep() should be based on the properties of the calling context, not the GPIO being controlled. In other words, if it's permissible to call gpio_set_value_cansleep() at this point in the code, simply always call that, and remove the conditional logic. Ah, yes. I was confused by the API gpio_cansleep(). Which API we should call depends on the calling context. And the context should come from the gpio-reset client device driver. IOW, we have no idea what the context is in gpio-reset driver. To start with something simple, we may want to define the gpio-reset as a sleepable interface and always call gpio_set_value_cansleep() in there. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos
On Fri, Jun 14, 2013 at 02:38:49PM +0200, Arnd Bergmann wrote: On Friday 14 June 2013 12:53:11 Thierry Reding wrote: I think the biggest missing piece is pci_common_exit(), the counterpart of pci_common_init(), to cleanup a host bridge on ARM. I haven't looked in detail at the other architectures, but I suspect there must be some code to call when a host bridge is removed. Looking at drivers/pci/remove.c, it seems like pci_remove_root_bus() might be what we're looking at. It isn't exported so it can't be used by modules, but that can be changed. Is that how a host bridge is typically removed from the system? It's fairly new to have host bridges in loadable modules, so I'm pretty sure it's not supported by the core yet, but it also doesn't seem hard to do. I think you are right with regard to pci_remove_root_bus, and Bjorn might be able to provide more information. Ideally we should be able to load and unload the pci host driver in a loop indefinitely without crashing or exposing any races or leaks, but I would not bet on that working without bugs in the core, since that goes beyond the normal pci (device) hotplug case. I've done some preliminary testing on Tegra using sysfs to unbind and rebind the device from and to the driver. Some code needs to be added for this to work, but it doesn't crash and PCI even continues to work after unbinding and rebinding (tested using gigabit ethernet). However I haven't looked for leaks yet, and I'm pretty sure some more code is required to undo some of what pci_common_init() does on ARM. Looking more closely, I think most (if not all) remaining leaks could be fixed by keeping the list of pci_sys_data structures around and cleaning them up properly. Given the experimental nature of this I don't want to make that part of the driver for 3.12 and I've opted to just disable any means of removing the driver for now. But I do want to get back to this after the driver has been merged. Thierry pgptZkAgaVWRI.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH -next] Input: olpc_apsp - remove redundant dev_err call in olpc_apsp_probe()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/input/serio/olpc_apsp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
index 818aa46..c96e3bd 100644
--- a/drivers/input/serio/olpc_apsp.c
+++ b/drivers/input/serio/olpc_apsp.c
@@ -187,10 +187,8 @@ static int olpc_apsp_probe(struct platform_device *pdev)
return -ENOENT;
priv-base = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(priv-base)) {
- dev_err(pdev-dev, Failed to map WTM registers\n);
+ if (IS_ERR(priv-base))
return PTR_ERR(priv-base);
- }
priv-irq = platform_get_irq(pdev, 0);
if (priv-irq 0)
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] msm_serial: add missing iounmap() on error in msm_request_port()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing iounmap() before return from msm_request_port()
in the error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/tty/serial/msm_serial.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 2c6cfb3..0b38b28 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -637,7 +637,7 @@ static int msm_request_port(struct uart_port *port)
if (!request_mem_region(gsbi_resource-start, size,
msm_serial)) {
ret = -EBUSY;
- goto fail_release_port;
+ goto fail_release_port_membase;
}
msm_port-gsbi_base = ioremap(gsbi_resource-start, size);
@@ -651,6 +651,8 @@ static int msm_request_port(struct uart_port *port)
fail_release_gsbi:
release_mem_region(gsbi_resource-start, size);
+fail_release_port_membase:
+ iounmap(port-membase);
fail_release_port:
release_mem_region(port-mapbase, size);
return ret;
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
