Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
On Wednesday 24 April 2013 09:58 PM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-14 14:19:17) Overall strategy introduced here is simple: a clock node described in device tree blob is used to identify the exact clock provided in the SoC specific data. This is then linked back using of_clk_add_provider to the device node to be accessible by of_clk_get. Based on discussion contributions from Roger Quadros, Grygorii Strashko and others. Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Mike Turquette mturque...@linaro.org Cc: Paul Walmsley p...@pwsan.com [t...@atomide.com: co-developed] Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com I can take this into clk-next after the merge window. Please refresh it for -rc1 as we discussed on irc. As an aside, will Tero's series for migrating to drivers/clk/omap[1] and Rajendra's patch for registering clocks late[2] be refreshed after the [2] is already in mainline. merge window? It would be nice to combine these efforts. Thanks, Mike [1] http://article.gmane.org/gmane.linux.ports.arm.omap/95948 [2] http://www.spinics.net/lists/arm-kernel/msg231288.html ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] tty: serial: mpc5xxx: fix error handing in mpc52xx_uart_init()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing uart_unregister_driver() and uninit before return
from mpc52xx_uart_init() in the error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/tty/serial/mpc52xx_uart.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/mpc52xx_uart.c
b/drivers/tty/serial/mpc52xx_uart.c
index 018bad9..43a6c0a 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -1497,18 +1497,23 @@ mpc52xx_uart_init(void)
if (psc_ops psc_ops-fifoc_init) {
ret = psc_ops-fifoc_init();
if (ret)
- return ret;
+ goto err_init;
}
ret = platform_driver_register(mpc52xx_uart_of_driver);
if (ret) {
printk(KERN_ERR %s: platform_driver_register failed (%i)\n,
__FILE__, ret);
- uart_unregister_driver(mpc52xx_uart_driver);
- return ret;
+ goto err_reg;
}
return 0;
+err_reg:
+ if (psc_ops psc_ops-fifoc_uninit)
+ psc_ops-fifoc_uninit();
+err_init:
+ uart_unregister_driver(mpc52xx_uart_driver);
+ return ret;
}
static void __exit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch -next] net: calxedaxgmac: fix condition in xgmac_set_features()
From: Dan Carpenter dan.carpen...@oracle.com Date: Thu, 25 Apr 2013 10:44:20 +0300 The changed variable should be a 64 bit type, otherwise it can't store all the features. The way the code is now the test for whether NETIF_F_RXCSUM changed is always false and we return immediately. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Applied, thanks Dan. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[patch -next] net: calxedaxgmac: fix condition in xgmac_set_features()
The changed variable should be a 64 bit type, otherwise it can't store all the features. The way the code is now the test for whether NETIF_F_RXCSUM changed is always false and we return immediately. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/net/ethernet/calxeda/xgmac.c b/drivers/net/ethernet/calxeda/xgmac.c index 791e5ff..4a1f2fa 100644 --- a/drivers/net/ethernet/calxeda/xgmac.c +++ b/drivers/net/ethernet/calxeda/xgmac.c @@ -1482,7 +1482,7 @@ static int xgmac_set_features(struct net_device *dev, netdev_features_t features u32 ctrl; struct xgmac_priv *priv = netdev_priv(dev); void __iomem *ioaddr = priv-base; - u32 changed = dev-features ^ features; + netdev_features_t changed = dev-features ^ features; if (!(changed NETIF_F_RXCSUM)) return 0; ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 07/17] ARM: dts: imx: cpus/cpu nodes dts updates
On Thu, Apr 25, 2013 at 06:44:28AM +0100, Shawn Guo wrote:
On Wed, Apr 24, 2013 at 06:28:12PM +0100, Lorenzo Pieralisi wrote:
This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/boot/dts/imx23.dtsi | 8 ++--
arch/arm/boot/dts/imx28.dtsi | 8 ++--
arch/arm/boot/dts/imx6dl.dtsi | 2 ++
arch/arm/boot/dts/imx6q.dtsi | 1 +
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 56afcf4..0aae18b 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -23,8 +23,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..07f131fc 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -32,8 +32,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 63fafe2..b76d85e 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -16,12 +16,14 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0;
next-level-cache = L2;
};
cpu@1 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 1;
next-level-cache = L2;
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index cba021e..65c1b62 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -17,6 +17,7 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
Shouldn't this line be added for cpu@1, cpu@2 and cpu@3 too? Other than
that,
Yes, you are right, fixed. Thanks for reviewing.
Lorenzo
Acked-by: Shawn Guo shawn@linaro.org
reg = 0;
next-level-cache = L2;
operating-points =
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Wed, Apr 24, 2013 at 08:58:20PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: [...] + - compatible: + Usage: required + Value type: string + Definition: should be one of: + arm,arm710t + arm,arm720t + arm,arm740t + arm,arm7ej-s + arm,arm7tdmi + arm,arm7tdmi-s + arm,arm9es + arm,arm9ej-s + arm,arm920t + arm,arm922t + arm,arm925 + arm,arm926e-s + arm,arm926ej-s + arm,arm940t + arm,arm946e-s + arm,arm966e-s + arm,arm968e-s + arm,arm9tdmi + arm,arm1020e + arm,arm1020t + arm,arm1022e + arm,arm1026ej-s the common name is arm926ejs / arm1026ejs co The TRMs names are arm926ej-s/arm1026ej-s/... and other machs are using that nomenclature already in dts files, time to consolidate. Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] ARM: at91: dt: switch to pre-processor
2013/4/24 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com: HI, The follow patch series switch the at91 to DT pre-processor So we can use macro for AIC and Pinctrl instead of magic ARM: at91: dt: switch to pre-processor (2013-04-24 22:54:39 +0800) Jean-Christophe PLAGNIOL-VILLARD (3): ARM: at91: dt: add pinctrl pre-processor define ARM: at91: dt: add AIC pre-processor define ARM: at91: dt: switch to pre-processor I can't find your 3rd patch ARM: at91: dt: switch to pre-processor on the lists. This is too much suspens ! Bring it on ! Richard. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH 1/3] drivers: of: add phy fixup support in DT
On 4/25/2013 1:26 PM, David Miller wrote: From: Mugunthan V N mugunthan...@ti.com Date: Mon, 22 Apr 2013 23:50:36 +0530 In earlier case phy fixup are added in board file as this is no more the case so adding support for phy register fixup in Device Tree Signed-off-by: Mugunthan V N mugunthan...@ti.com When people put a series of undocumented PHY register writes using constants, we tell them it's firmware. If these PHY registers are actually documented in the driver, write a function in that driver which does the programming sequence, then add a property that the driver looks for in order to determine whether to call that sequence or not. I don't want people putting random PHY raw programming sequences and other crap like that into the OF device nodes. It's extremely inelegant and inviting abuse. Will modify the source as per your comments and will submit v2 patch set. Regards Mugunthan V N ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 01/10] ASoC: phycore-ac97: Add DT support
On Thu, Apr 25, 2013 at 11:35:20AM +0800, Shawn Guo wrote:
On Wed, Apr 24, 2013 at 09:45:40PM +0200, Sascha Hauer wrote:
Hi Markus,
On Wed, Apr 24, 2013 at 04:36:30PM +0200, Markus Pargmann wrote:
Add devicetree support for this audio soc fabric driver.
@@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[]
= {
.stream_name= HiFi,
.codec_dai_name = wm9712-hifi,
.codec_name = wm9712-codec,
+#ifdef CONFIG_MACH_IMX27_DT
+ .platform_name = imx-fiq-pcm-audio,
+#else
.cpu_dai_name = imx-ssi.0,
.platform_name = imx-fiq-pcm-audio.0,
+#endif
This doesn't work properly. Compiling the kernel with IMX27_DT enabled
does not necessarily mean that it also started with dt support.
Right, we should run-time check pdev-dev.of_node to see if it's a DT
boot and set .platform_of_node rather than .platform_name if it is. But
it's only possible with the cleanup series ASoC: fsl: imx-pcm driver
cleanup I just sent being the base. I hope you can rebase your series
on that :)
The current version of phycore-ac97.c is not a driver, it is just a late
init call. So run-time check is not possible unless I modify the old
part to be a driver and add a device to all board init functions using
ac97. (I would prefer dropping the non-DT part in this case ;) )
Yes I rebased this series onto your cleanups, looks good so far and
platform_of_node works finally.
Thanks,
Markus
Shawn
Personally I am fine with removing platform based support for this
driver if it's too much effort to fix it properly, but we shouldn't
start working with ifdefs here.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/8] irq-imgpdc: add ImgTec PDC irqchip driver
Hi Thomas,
On 23/04/13 16:09, Thomas Gleixner wrote:
On Tue, 23 Apr 2013, James Hogan wrote:
+pdc_write(priv, PDC_IRQ_ROUTE, irq_route);
+spin_unlock_irqrestore(priv-lock, flags);
+}
+
+static void perip_irq_unmask(struct irq_data *data)
+{
+struct pdc_intc_priv *priv = irqd_to_priv(data);
+unsigned int irq_route;
+unsigned long flags;
+
+spin_lock_irqsave(priv-lock, flags);
+irq_route = pdc_read(priv, PDC_IRQ_ROUTE);
+irq_route |= 1 data-hwirq;
+pdc_write(priv, PDC_IRQ_ROUTE, irq_route);
This code is another slightly different copy of stuff which is
available in kernel/irq/generic-chip.c
Can we please stop the code duplication and reuse existing
infrastructure? Don't tell me it does not work for you. I sent out a
patch yesterday which makes the code suitable for irq domains.
If you're referring to the one that adds the IRQ_GC_MASK_FROM_HWIRQ
flag, as far as I can tell this means I'd have to call
irq_setup_generic_chip on each individual irq (since virqs may not be
linear), or else resort to creating a legacy irqdomain (which I thought
was... well for legacy use).
It feels a bit convoluted, and wrong given that it adds itself to
gc_list. Did I misunderstand how you were expecting me to make use of
the generic chip functions with a linear irqdomain?
Given that your patch presumably isn't upstream yet anyway, is it
acceptable to go with the current version (other fixes applied) and
update it later if necessary?
Thanks
James
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re[2]: [PATCH 1/2] GPIO: clps711x: Rewrite driver for using generic GPIO code
On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
+static void __init clps711x_add_gpio(void)
+{
+ const struct resource clps711x_gpio0_res[] = {
+ DEFINE_RES_MEM(PADR, SZ_1),
+ DEFINE_RES_MEM(PADDR, SZ_1),
+ };
...
Don't do this - this is incredibly wasteful.
C lesson 1: do not put unmodified initialised structures onto the stack.
What the C compiler will do with the above is exactly the same as this
for each structure:
static const struct resource private_clps711x_gpio4_res[] = {
DEFINE_RES_MEM(PEDR, SZ_1),
DEFINE_RES_MEM(PEDDR, SZ_1),
};
static void __init clps711x_add_gpio(void)
{
const struct resource clps711x_gpio4_res[] = private_clps711x_gpio4_res;
...
which will in itself be a call out to memcpy, or an inlined memcpy. Now
do you see why it's wasteful? You might as well write the thing in that
way to start with and safe the additional code to copy the structures.
The other way to do this, which will probably be far more space efficient:
static phys_addr_t gpio_addrs[][2] = {
{ PADR, PADDR },
{ PBDR, PBDDR },
...
};
static void __init clps711x_add_gpio(void)
{
struct resource gpio_res[2];
unsigned i;
gpio_res[0].flags = IORESOURCE_MEM;
gpio_res[1].flags = IORESOURCE_MEM;
for (i = 0; i ARRAY_SIZE(gpio_addrs); i++) {
gpio_res[0].start = gpio_addrs[i][0];
gpio_res[0].end = gpio_res[0].start;
gpio_res[1].start = gpio_addrs[i][1];
gpio_res[1].end = gpio_res[1].start;
platform_device_register_simple(clps711x-gpio, i,
gpio_res, ARRAY_SIZE(gpio_res));
}
}
which results in smaller storage and most probably also smaller code size
too.
Very strange results with this change.
So, I add a debug output before platform_device_register_simple for
print resource and in __request_resource for print parent.
This is output.
gpio 0 [mem 0x8000] [mem 0x8040]
resource: root [??? 0xe3a0f000-0x flags 0xb0]
clps711x-gpio.0: failed to claim resource 0
The first line is seems correct. But I do not understand why
parent is wrong here. Normally it should be as:
resource: root [mem 0x-0x].
And it shows normal with my first version.
Have anyone any ideas?
Thanks.
---
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
On Thu, Apr 18, 2013 at 4:17 PM, Lee Jones lee.jo...@linaro.org wrote:
Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manner.
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Cc: Per Forlin per.for...@stericsson.com
Cc: Rabin Vincent ra...@rab.in
Signed-off-by: Lee Jones lee.jo...@linaro.org
This needs to be CC: to devicetree-discussed so it can be checked for OS
independence and such... Also consider including Rob Herring on posts.
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt
b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 000..2679a87
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,62 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: stericsson,dma40
+- reg: Address range of the DMAC registers
+- reg-names: Names of the above areas to use during resource look-up
+- interrupt: Should contain the DMAC interrupt number
+- #dma-cells: must be 3
+
+Optional properties:
+- dma-channels: Number of channels supported by hardware - if not present
+ the driver will attempt to obtain the information from H/W
I want you to define the memcpy channels in device tree as well.
Right now these are hardcoded into the driver and there is no way
to check whether they happen to overlap with other channels from the
device tree, i.e. a source of confusion.
Please add configuration for the static memcpy channels here.
+#define D40_DT_FLAGS_MODE(flags) ((flags 0) 0x1)
+#define D40_DT_FLAGS_DIR(flags)((flags 1) 0x1)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags 2) 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags 3) 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct stedma40_chan_cfg cfg;
+ dma_cap_mask_t cap;
+ u32 flags;
+
+ memset(cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ cfg.dev_type = dma_spec-args[0];
+ flags = dma_spec-args[2];
+
+ switch (D40_DT_FLAGS_MODE(flags)) {
+ case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+ case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+ }
+
+ switch (D40_DT_FLAGS_DIR(flags)) {
+ case 0:
+ cfg.dir = STEDMA40_MEM_TO_PERIPH;
+ cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ break;
+ case 1:
+ cfg.dir = STEDMA40_PERIPH_TO_MEM;
+ cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ break;
+ }
+
+ if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+ cfg.phy_channel = dma_spec-args[1];
+ cfg.use_fixed_channel = true;
+ }
+
+ return dma_request_channel(cap, stedma40_filter, cfg);
+}
Nice! But please include handling of the memcpy channels.
(Unclear to me how to do that, but now i becomes your problem ;-)
+ if (np) {
+ err = of_dma_controller_register(np, d40_xlate, NULL);
+ if (err err != -ENODEV)
+ dev_err(pdev-dev,
+ could not register of_dma_controller\n);
+ }
+
dev_info(base-dev, initialized\n);
return 0;
Is it really OK to just fall through after failing to register the controller
from the device tree?
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 07/10] ASoC: fsl-ssi: imx ac97 support
On Thu, Apr 25, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
On Wed, Apr 24, 2013 at 04:36:36PM +0200, Markus Pargmann wrote:
+/*
+ * Pointer to AC97 reset functions for specific boards
+ */
+#if IS_ENABLED(CONFIG_MACH_PCA100)
+extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+#if IS_ENABLED(CONFIG_MACH_PCM043)
+extern void pcm043_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pcm043_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
...
@@ -717,13 +956,39 @@ static int fsl_ssi_probe(struct platform_device *pdev)
strcpy(ssi_private-name, p);
- /* Initialize this copy of the CPU DAI driver structure */
- memcpy(ssi_private-cpu_dai_drv, fsl_ssi_dai_template,
- sizeof(fsl_ssi_dai_template));
- ssi_private-cpu_dai_drv.name = ssi_private-name;
-
ssi_private-use_dma = !of_property_read_bool(np, fsl,imx-fiq);
+ if (ac97) {
+ sprop = of_get_property(of_find_node_by_path(/), compatible,
+ NULL);
+ p = strrchr(sprop, ',');
+ if (p)
+ sprop = p + 1;
+
+ if (!strcmp(sprop, imx27-pca100)) {
+ ssi_private-ac97_reset = pca100_ac97_cold_reset;
+ ssi_private-ac97_warm_reset = pca100_ac97_warm_reset;
+ } else if (!strcmp(sprop, imx27-pcm043)) {
+ ssi_private-ac97_reset = pcm043_ac97_cold_reset;
+ ssi_private-ac97_warm_reset = pcm043_ac97_warm_reset;
+ } else {
+ dev_err(pdev-dev, Failed to enable ssi AC97 mode,
unknown board.\n);
+ ret = -EINVAL;
+ goto error_kmalloc;
+ }
I do not like these board specific hooks show up in an IP driver
in such way. Can we work it out in other ways, notification or even
platform_data with auxdata?
soc_ac97_ops is a global symbol, so we could setup soc_ac97_ops.reset
and warm_reset in board specific ac97 drivers. For this patch I would
move the assignment of reset functions to phycore-ac97.c which already
is specifically for this codec-ssi combination on the two boards.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] GPIO: clps711x: Rewrite driver for using generic GPIO code
On Thu, Apr 25, 2013 at 03:31:07PM +0400, Alexander Shiyan wrote:
On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
+static void __init clps711x_add_gpio(void)
+{
+ const struct resource clps711x_gpio0_res[] = {
+ DEFINE_RES_MEM(PADR, SZ_1),
+ DEFINE_RES_MEM(PADDR, SZ_1),
+ };
...
Don't do this - this is incredibly wasteful.
C lesson 1: do not put unmodified initialised structures onto the stack.
What the C compiler will do with the above is exactly the same as this
for each structure:
static const struct resource private_clps711x_gpio4_res[] = {
DEFINE_RES_MEM(PEDR, SZ_1),
DEFINE_RES_MEM(PEDDR, SZ_1),
};
static void __init clps711x_add_gpio(void)
{
const struct resource clps711x_gpio4_res[] = private_clps711x_gpio4_res;
...
which will in itself be a call out to memcpy, or an inlined memcpy. Now
do you see why it's wasteful? You might as well write the thing in that
way to start with and safe the additional code to copy the structures.
The other way to do this, which will probably be far more space efficient:
static phys_addr_t gpio_addrs[][2] = {
{ PADR, PADDR },
{ PBDR, PBDDR },
...
};
static void __init clps711x_add_gpio(void)
{
struct resource gpio_res[2];
unsigned i;
gpio_res[0].flags = IORESOURCE_MEM;
gpio_res[1].flags = IORESOURCE_MEM;
for (i = 0; i ARRAY_SIZE(gpio_addrs); i++) {
gpio_res[0].start = gpio_addrs[i][0];
gpio_res[0].end = gpio_res[0].start;
gpio_res[1].start = gpio_addrs[i][1];
gpio_res[1].end = gpio_res[1].start;
platform_device_register_simple(clps711x-gpio, i,
gpio_res, ARRAY_SIZE(gpio_res));
}
}
which results in smaller storage and most probably also smaller code size
too.
Very strange results with this change.
So, I add a debug output before platform_device_register_simple for
print resource and in __request_resource for print parent.
This is output.
gpio 0 [mem 0x8000] [mem 0x8040]
resource: root [??? 0xe3a0f000-0x flags 0xb0]
clps711x-gpio.0: failed to claim resource 0
The first line is seems correct. But I do not understand why
parent is wrong here. Normally it should be as:
resource: root [mem 0x-0x].
And it shows normal with my first version.
Have anyone any ideas?
memset(gpio_res, 0, sizeof(gpio_res));
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] Documentation/devicetree: make semantic of initrd-end more explicit
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Documentation/devicetree/usage-model.txt | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt index ef9d06c..0efedaa 100644 --- a/Documentation/devicetree/usage-model.txt +++ b/Documentation/devicetree/usage-model.txt @@ -191,9 +191,11 @@ Linux it will look something like this: }; The bootargs property contains the kernel arguments, and the initrd-* -properties define the address and size of an initrd blob. The -chosen node may also optionally contain an arbitrary number of -additional properties for platform-specific configuration data. +properties define the address and size of an initrd blob. Note that +initrd-end is the first address after the initrd image, so this doesn't +match the usual semantic of struct resource. The chosen node may also +optionally contain an arbitrary number of additional properties for +platform-specific configuration data. During early boot, the architecture setup code calls of_scan_flat_dt() several times with different helper callbacks to parse device tree -- 1.8.2.rc2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/4] Thermal: exynos: Support for TMU regulator defined at device tree
Hi Lukasz Majewski,
Sorry for late review but I am currently working on restructuring the
whole exynos thermal driver and this support of LDO can be added as
feature as not all socs support this. This is also suggested by
Eduardo. All your other patches looks fine.
Thanks,
Amit Daniel
On Thu, Apr 25, 2013 at 6:00 PM, Lukasz Majewski l.majew...@samsung.com wrote:
TMU probe function now checks for a device tree defined regulator.
For compatibility reasons it is allowed to probe driver even without
this regulator defined.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes for v2:
- Change dev_info() to dev_warn()
---
drivers/thermal/exynos_thermal.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 3d6e32a..328fe7e 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -38,6 +38,7 @@
#include linux/cpufreq.h
#include linux/cpu_cooling.h
#include linux/of.h
+#include linux/regulator/consumer.h
#include plat/cpu.h
@@ -119,6 +120,8 @@
#define EXYNOS_ZONE_COUNT 3
+#define EXYNOS_TMU_REGULATOR vdd_ts
+
struct exynos_tmu_data {
struct exynos_tmu_platform_data *pdata;
struct resource *mem;
@@ -948,6 +951,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
{
struct exynos_tmu_data *data;
struct exynos_tmu_platform_data *pdata = pdev-dev.platform_data;
+ struct regulator *reg;
int ret, i;
if (!pdata)
@@ -957,6 +961,21 @@ static int exynos_tmu_probe(struct platform_device *pdev)
dev_err(pdev-dev, No platform init data supplied.\n);
return -ENODEV;
}
+
+ reg = regulator_get(pdev-dev, EXYNOS_TMU_REGULATOR);
+ if (!IS_ERR(reg)) {
+ ret = regulator_enable(reg);
+ if (ret) {
+ dev_err(pdev-dev, Regulator %s not enabled.\n,
+ EXYNOS_TMU_REGULATOR);
+ return ret;
+ }
+ } else {
+ dev_warn(pdev-dev,
+Regulator %s not defined at device tree.\n,
+EXYNOS_TMU_REGULATOR);
+ }
+
data = devm_kzalloc(pdev-dev, sizeof(struct exynos_tmu_data),
GFP_KERNEL);
if (!data) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/10 v2] usb: musb: ux500: add device tree probing support
On Wed, Apr 24, 2013 at 9:43 AM, Lee Jones lee.jo...@linaro.org wrote: usb: musb: ux500: add device tree probing support This patch will allow ux500-musb to be probed and configured solely from configuration found in Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-...@vger.kernel.org Signed-off-by: Lee Jones lee.jo...@linaro.org This patch needs to be CC: devicetree-discuss. But looks good to me! Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/3] ASoC: Add devicetree support for spdif dummy codecs.
changes from v1 (for patch 2 and 3):
- add prefix linux for compatible property (for both tx and rx)
- rename spdif_transceiver.c to spdif_transmitter.c
- add bindings documentation
Marek Belisko (3):
ASoC: spdif_transceiver: Change driver filename to
spdif_transmitter.c.
ASoC: spdif_transmitter: Add DT support.
ASoC: spdif_receiver: Add DT support.
.../devicetree/bindings/sound/spdif-receiver.txt | 10 ++
.../bindings/sound/spdif-transmitter.txt | 10 ++
sound/soc/codecs/Makefile |2 +-
sound/soc/codecs/spdif_receiver.c | 10 ++
.../{spdif_transciever.c = spdif_transmitter.c} | 10 ++
5 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/sound/spdif-receiver.txt
create mode 100644
Documentation/devicetree/bindings/sound/spdif-transmitter.txt
rename sound/soc/codecs/{spdif_transciever.c = spdif_transmitter.c} (88%)
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/3] ASoC: spdif_transceiver: Change driver filename to spdif_transmitter.c.
Transceiver usually means receiver + transmitter. This codec can do only
transmit. Update driver accordingly.
Signed-off-by: Marek Belisko marek.beli...@streamunlimited.com
---
sound/soc/codecs/Makefile |2 +-
.../{spdif_transciever.c = spdif_transmitter.c} |0
2 files changed, 1 insertion(+), 1 deletion(-)
rename sound/soc/codecs/{spdif_transciever.c = spdif_transmitter.c} (100%)
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 8cf5951..4252c35 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -51,7 +51,7 @@ snd-soc-alc5632-objs := alc5632.o
snd-soc-sigmadsp-objs := sigmadsp.o
snd-soc-si476x-objs := si476x.o
snd-soc-sn95031-objs := sn95031.o
-snd-soc-spdif-tx-objs := spdif_transciever.o
+snd-soc-spdif-tx-objs := spdif_transmitter.o
snd-soc-spdif-rx-objs := spdif_receiver.o
snd-soc-ssm2602-objs := ssm2602.o
snd-soc-sta32x-objs := sta32x.o
diff --git a/sound/soc/codecs/spdif_transciever.c
b/sound/soc/codecs/spdif_transmitter.c
similarity index 100%
rename from sound/soc/codecs/spdif_transciever.c
rename to sound/soc/codecs/spdif_transmitter.c
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/3] ASoC: spdif_transmitter: Add DT support.
Add devicetree support for this dummy audio soc driver.
Signed-off-by: Michal Bachraty michal.bachr...@streamunlimited.com
Signed-off-by: Marek Belisko marek.beli...@streamunlimited.com
---
.../bindings/sound/spdif-transmitter.txt | 10 ++
sound/soc/codecs/spdif_transmitter.c | 10 ++
2 files changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/spdif-transmitter.txt
diff --git a/Documentation/devicetree/bindings/sound/spdif-transmitter.txt
b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt
new file mode 100644
index 000..55a8584
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt
@@ -0,0 +1,10 @@
+Device-Tree bindings for dummy spdif transmitter
+
+Required properties:
+ - compatible: should be linux,spdif-dit.
+
+Example node:
+
+ codec: spdif-transmitter {
+ compatible = linux,spdif-dit;
+ };
diff --git a/sound/soc/codecs/spdif_transmitter.c
b/sound/soc/codecs/spdif_transmitter.c
index 112a49d..1828049 100644
--- a/sound/soc/codecs/spdif_transmitter.c
+++ b/sound/soc/codecs/spdif_transmitter.c
@@ -20,6 +20,7 @@
#include sound/soc.h
#include sound/pcm.h
#include sound/initval.h
+#include linux/of.h
#define DRV_NAME spdif-dit
@@ -52,12 +53,21 @@ static int spdif_dit_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id spdif_dit_dt_ids[] = {
+ { .compatible = linux,spdif-dit, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, spdif_dit_dt_ids);
+#endif
+
static struct platform_driver spdif_dit_driver = {
.probe = spdif_dit_probe,
.remove = spdif_dit_remove,
.driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(spdif_dit_dt_ids),
},
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/3] ASoC: spdif_receiver: Add DT support.
Add devicetree support for this dummy audio soc driver.
Signed-off-by: Michal Bachraty michal.bachr...@streamunlimited.com
Signed-off-by: Marek Belisko marek.beli...@streamunlimited.com
---
.../devicetree/bindings/sound/spdif-receiver.txt | 10 ++
sound/soc/codecs/spdif_receiver.c | 10 ++
2 files changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/spdif-receiver.txt
diff --git a/Documentation/devicetree/bindings/sound/spdif-receiver.txt
b/Documentation/devicetree/bindings/sound/spdif-receiver.txt
new file mode 100644
index 000..80f807b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/spdif-receiver.txt
@@ -0,0 +1,10 @@
+Device-Tree bindings for dummy spdif receiver
+
+Required properties:
+ - compatible: should be linux,spdif-dir.
+
+Example node:
+
+ codec: spdif-receiver {
+ compatible = linux,spdif-dir;
+ };
diff --git a/sound/soc/codecs/spdif_receiver.c
b/sound/soc/codecs/spdif_receiver.c
index dd8d856..e9d7881 100644
--- a/sound/soc/codecs/spdif_receiver.c
+++ b/sound/soc/codecs/spdif_receiver.c
@@ -21,6 +21,7 @@
#include sound/soc.h
#include sound/pcm.h
#include sound/initval.h
+#include linux/of.h
#define STUB_RATES SNDRV_PCM_RATE_8000_192000
#define STUB_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
@@ -51,12 +52,21 @@ static int spdif_dir_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id spdif_dir_dt_ids[] = {
+ { .compatible = linux,spdif-dir, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, spdif_dir_dt_ids);
+#endif
+
static struct platform_driver spdif_dir_driver = {
.probe = spdif_dir_probe,
.remove = spdif_dir_remove,
.driver = {
.name = spdif-dir,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(spdif_dir_dt_ids),
},
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] pinctrl: samsung: Fix link error with CONFIG_PINCTRL_EXYNOS disabled
On Wed, Apr 24, 2013 at 4:47 PM, Tomasz Figa t.f...@samsung.com wrote: On Wednesday 24 of April 2013 16:27:09 Linus Walleij wrote: On Tue, Apr 23, 2013 at 2:09 PM, Tomasz Figa t.f...@samsung.com wrote: On Tuesday 23 of April 2013 14:03:12 Linus Walleij wrote: This does not apply to my devel branch in the pinctrl tree. Could you rebase it on that branch? Or is the error not even in my tree? This one got sent incorrectly due to my mistake. Please try the correct version: [PATCH RESEND 2/2] pinctrl: samsung: Fix link error with CONFIG_PINCTRL_EXYNOS disabled This does not apply either. Can you please test against the devel branch in the pinctrl tree? Right, it does not apply. Well, actually it does with git am -3, but it is incorrect, since the problem it intends to fix is not present in your tree, but rather is a merge error in linux-next in a merge of Kgene's and your tree... Oh. Then you have to send the patch to Stephen Rothwell. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
On Wed, Apr 24, 2013 at 01:50:49AM +0100, Laura Abbott wrote: By default on ARM systems, the coherent DMA mask (lowest address) is set to ~0 or 0x. Currently, of_platform_device_create_pdata sets the coherent DMA mask to 32 bits. This prevents coherent dma allocations from working by default without clients setting the DMA mask. Rather than make every client on an LPAE system set the mask, set the mask to a 64 bit value on ARM LPAE systems. Signed-off-by: Laura Abbott lau...@codeaurora.org --- drivers/of/platform.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..18b69c1 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev-archdata.dma_mask = 0xUL; #endif +#ifdef CONFIG_ARM_LPAE + dev-dev.coherent_dma_mask = DMA_BIT_MASK(64); +#else dev-dev.coherent_dma_mask = DMA_BIT_MASK(32); +#endif I wouldn't add CONFIG_ARM_LPAE checks in here, you can use CONFIG_ARCH_DMA_ADDR_T_64BIT (types.h uses this for the dma_addr_t definition). -- Catalin ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 13/23] regulator: ab3100: refactor probe to use IDs
On Mon, Apr 22, 2013 at 2:37 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Mon, Apr 22, 2013 at 11:57:14AM +0200, Linus Walleij wrote: Hi Mark, seeking an ACK on this to take it through the ARM SoC tree. Since the arm-soc tree is locked down now I may as well just apply it so it shows up in the merge window? Yep, saw you picked in these two, thanks! Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 00/13] ARM: EXYNOS: Fix Universal C210 support
On Tuesday 23 April 2013, Tomasz Figa wrote: This series intends to fix support for Universal C210 board in mainline. Main difference from other boards based on Exynos 4210 is that hardware revision of the SoC used on Universal C210 does not support MCT timers and legacy PWM timers must be used instead. First (and the biggest) part of the series deals with cleaning up and fixing the samsung_pwm_timer clocksource driver, that was posted recently by Arnd. In addition the driver is prepared to share the hardware with PWM driver that will be reworked later, since it is not a component crucial for system operation. Second part fixes ATAGS support of Exynos 4210 rev0 SoC, which needs different timer initialization, using the new samsung_pwm_timer driver. Third and last part adds Device Tree-based support for Universal C210 board by providing device tree sources for it. On Universal C210 board, both with and without DT: Tested-by: Tomasz Figa t.f...@samsung.com Reviewed-by: Arnd Bergmann a...@arndb.de Olof, Kgene, I think we should have this one in 3.10 since it fixes a regression. It looks bigger than it really is because I asked Tomasz to do small patches rather than a single combined patch. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/8] metag: minimal TZ1090 (Comet) SoC infrastructure
On 24/04/13 15:51, James Hogan wrote: On 24/04/13 14:26, Catalin Marinas wrote: On 23 April 2013 17:06, James Hogan james.ho...@imgtec.com wrote: It's certainly heading in that direction a lot. For this patchset I could get away with dropping arch/metag/soc/*, and deal with anything that really requires something like it later. The machine callbacks I was planning on using in future patches are: * init_time() for calling into the appropriate common clock driver from time_init(), prior to setting up the timer so that the right frequency can be reported based on the clock hierarchy specified in DT. I guess this could be made more general, allowing any enabled clock component to be initialised at this time. This is driven by DT on arm64, no need for platform callback (see drivers/clocksource/arch_arm_timer.c). Right. The problem is that the frequency of the core clock in TZ1090 (and hence the arch timer that is derived from it) isn't discoverable in an arch generic way. I can do something similar to tegra (see tegra_clocks_init()) to init the common clk stuff early and then do: node = of_find_compatible_node(NULL, NULL, img,meta); clk_core = of_clk_get_by_name(node, core); rate = clk_get_rate(clk_core); From time_init prior to setting up the arch timer, but I need a platform callback for that. I take that back, I've just noticed commit f2f6c2556dcc432e50003bc8fa4d62d95906f149 which makes clock setup callbacks automatic using section cunningness. :-) Cheers James ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On Sun, Apr 21, 2013 at 9:13 PM, Rob Herring robherri...@gmail.com wrote:
From: Rob Herring rob.herr...@calxeda.com
ibmebus is the last remaining user of of_platform_driver and the
conversion to a regular platform driver is trivial.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Hoang-Nam Nguyen hngu...@de.ibm.com
Cc: Christoph Raisch rai...@de.ibm.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-r...@vger.kernel.org
Cc: net...@vger.kernel.org
Ben, Can I have your Ack for this? The change is straightforward and
neither of the 2 drivers used the id parameter that is removed.
Rob
---
arch/powerpc/include/asm/ibmebus.h|4 ++--
arch/powerpc/kernel/ibmebus.c | 22 ++
drivers/infiniband/hw/ehca/ehca_main.c|5 ++---
drivers/net/ethernet/ibm/ehea/ehea_main.c |8 +++-
4 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/ibmebus.h
b/arch/powerpc/include/asm/ibmebus.h
index 1a9d9ae..088f95b 100644
--- a/arch/powerpc/include/asm/ibmebus.h
+++ b/arch/powerpc/include/asm/ibmebus.h
@@ -48,8 +48,8 @@
extern struct bus_type ibmebus_bus_type;
-int ibmebus_register_driver(struct of_platform_driver *drv);
-void ibmebus_unregister_driver(struct of_platform_driver *drv);
+int ibmebus_register_driver(struct platform_driver *drv);
+void ibmebus_unregister_driver(struct platform_driver *drv);
int ibmebus_request_irq(u32 ist, irq_handler_t handler,
unsigned long irq_flags, const char *devname,
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 8220baa..16a7c23 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -205,7 +205,7 @@ static int ibmebus_create_devices(const struct
of_device_id *matches)
return ret;
}
-int ibmebus_register_driver(struct of_platform_driver *drv)
+int ibmebus_register_driver(struct platform_driver *drv)
{
/* If the driver uses devices that ibmebus doesn't know, add them */
ibmebus_create_devices(drv-driver.of_match_table);
@@ -215,7 +215,7 @@ int ibmebus_register_driver(struct of_platform_driver
*drv)
}
EXPORT_SYMBOL(ibmebus_register_driver);
-void ibmebus_unregister_driver(struct of_platform_driver *drv)
+void ibmebus_unregister_driver(struct platform_driver *drv)
{
driver_unregister(drv-driver);
}
@@ -338,11 +338,10 @@ static int ibmebus_bus_bus_match(struct device *dev,
struct device_driver *drv)
static int ibmebus_bus_device_probe(struct device *dev)
{
int error = -ENODEV;
- struct of_platform_driver *drv;
+ struct platform_driver *drv;
struct platform_device *of_dev;
- const struct of_device_id *match;
- drv = to_of_platform_driver(dev-driver);
+ drv = to_platform_driver(dev-driver);
of_dev = to_platform_device(dev);
if (!drv-probe)
@@ -350,9 +349,8 @@ static int ibmebus_bus_device_probe(struct device *dev)
of_dev_get(of_dev);
- match = of_match_device(drv-driver.of_match_table, dev);
- if (match)
- error = drv-probe(of_dev, match);
+ if (of_driver_match_device(dev, dev-driver))
+ error = drv-probe(of_dev);
if (error)
of_dev_put(of_dev);
@@ -362,7 +360,7 @@ static int ibmebus_bus_device_probe(struct device *dev)
static int ibmebus_bus_device_remove(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct platform_driver *drv = to_platform_driver(dev-driver);
if (dev-driver drv-remove)
drv-remove(of_dev);
@@ -372,7 +370,7 @@ static int ibmebus_bus_device_remove(struct device *dev)
static void ibmebus_bus_device_shutdown(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct platform_driver *drv = to_platform_driver(dev-driver);
if (dev-driver drv-shutdown)
drv-shutdown(of_dev);
@@ -419,7 +417,7 @@ struct device_attribute ibmebus_bus_device_attrs[] = {
static int ibmebus_bus_legacy_suspend(struct device *dev, pm_message_t mesg)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct platform_driver *drv = to_platform_driver(dev-driver);
int ret = 0;
if (dev-driver drv-suspend)
@@ -430,7 +428,7 @@
Re: [PATCH v3 00/13] ARM: EXYNOS: Fix Universal C210 support
On 04/25/13 23:46, Arnd Bergmann wrote: On Universal C210 board, both with and without DT: Tested-by: Tomasz Figat.f...@samsung.com Reviewed-by: Arnd Bergmanna...@arndb.de Olof, Kgene, I think we should have this one in 3.10 since it fixes a regression. It looks bigger than it really is because I asked Tomasz to do small patches rather than a single combined patch. Basically, I have no objection, I think, dt for universal_c210 is not urgent in v3.10 though, because non-dt will be still supported... K-Gene ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH 1/3] drivers: of: add phy fixup support in DT
On Thu, 2013-04-25 at 03:56 -0400, David Miller wrote: From: Mugunthan V N mugunthan...@ti.com Date: Mon, 22 Apr 2013 23:50:36 +0530 In earlier case phy fixup are added in board file as this is no more the case so adding support for phy register fixup in Device Tree Signed-off-by: Mugunthan V N mugunthan...@ti.com When people put a series of undocumented PHY register writes using constants, we tell them it's firmware. If these PHY registers are actually documented in the driver, write a function in that driver which does the programming sequence, then add a property that the driver looks for in order to determine whether to call that sequence or not. I don't want people putting random PHY raw programming sequences and other crap like that into the OF device nodes. It's extremely inelegant and inviting abuse. I don't think booleans will be enough in general; a PHY may well require link tuning for a specific board. But the set of register addresses to program is likely to be known in advance and then only the values would belong in DT. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
On 4/25/2013 6:33 AM, Catalin Marinas wrote: On Wed, Apr 24, 2013 at 01:50:49AM +0100, Laura Abbott wrote: By default on ARM systems, the coherent DMA mask (lowest address) is set to ~0 or 0x. Currently, of_platform_device_create_pdata sets the coherent DMA mask to 32 bits. This prevents coherent dma allocations from working by default without clients setting the DMA mask. Rather than make every client on an LPAE system set the mask, set the mask to a 64 bit value on ARM LPAE systems. Signed-off-by: Laura Abbott lau...@codeaurora.org --- drivers/of/platform.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..18b69c1 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev-archdata.dma_mask = 0xUL; #endif +#ifdef CONFIG_ARM_LPAE + dev-dev.coherent_dma_mask = DMA_BIT_MASK(64); +#else dev-dev.coherent_dma_mask = DMA_BIT_MASK(32); +#endif I wouldn't add CONFIG_ARM_LPAE checks in here, you can use CONFIG_ARCH_DMA_ADDR_T_64BIT (types.h uses this for the dma_addr_t definition). I thought about this as well but in arch/arm/mm/mm.h: #ifdef CONFIG_ZONE_DMA extern phys_addr_t arm_dma_limit; #else #define arm_dma_limit ((phys_addr_t)~0) #endif arm_dma_limit is explicitly cast to phys_addr_t, which means that arm_dma_limit will be always be sizeof(phys_addr_t) regardless of sizeof(dma_addr_t). Is it safe to assume that CONFIG_ARCH_DMA_ADDR_T_64BIT will always be selected if sizeof(phys_addr_t) == 8? If not, we've defeated the point of the patch. Alternatively, should the type of arm_dma_limit be dma_addr_t instead of phys_addr_t? Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote: Ben, Can I have your Ack for this? The change is straightforward and neither of the 2 drivers used the id parameter that is removed. Didn't you get my mail about a compile failure caused by this patch ? Or did you send an update that I missed ? (Copy of the original email below) Cheers, Ben. On Sun, 2013-04-21 at 21:13 -0500, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com ibmebus is the last remaining user of of_platform_driver and the conversion to a regular platform driver is trivial. A quick build test leads to: /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_probe': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:2: error: implicit declaration of function 'to_platform_driver' [-Werror=implicit-function-declaration] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:6: error: assignment makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_remove': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:363:32: error: initialization makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_shutdown': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:373:32: error: initialization makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_suspend': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:420:32: error: initialization makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_resume': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:431:32: error: initialization makes pointer from integer without a cast [-Werror] cc1: all warnings being treated as errors make[2]: *** [arch/powerpc/kernel/ibmebus.o] Error 1 make[2]: *** Waiting for unfinished jobs Haven't had a chance to look too closely today -EJETLAG :-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] thermal: db8500_cpufreq_cooling: remove usage of IS_ERR_OR_NULL()
On Thu, Apr 25, 2013 at 10:13:34AM -0400, Eduardo Valentin wrote:
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
b/drivers/thermal/db8500_cpufreq_cooling.c
index 21419851..786d192 100644
--- a/drivers/thermal/db8500_cpufreq_cooling.c
+++ b/drivers/thermal/db8500_cpufreq_cooling.c
@@ -37,7 +37,7 @@ static int db8500_cpufreq_cooling_probe(struct
platform_device *pdev)
cpumask_set_cpu(0, mask_val);
cdev = cpufreq_cooling_register(mask_val);
- if (IS_ERR_OR_NULL(cdev)) {
+ if (IS_ERR(cdev)) {
dev_err(pdev-dev, Failed to register cooling device\n);
return PTR_ERR(cdev);
Correct. cpufreq_cooling_register() returns either an error-pointer or
a valid pointer.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
On Thu, Apr 25, 2013 at 10:09:57AM -0700, Laura Abbott wrote: I thought about this as well but in arch/arm/mm/mm.h: #ifdef CONFIG_ZONE_DMA extern phys_addr_t arm_dma_limit; #else #define arm_dma_limit ((phys_addr_t)~0) #endif arm_dma_limit is explicitly cast to phys_addr_t, which means that arm_dma_limit will be always be sizeof(phys_addr_t) regardless of sizeof(dma_addr_t). This is the size of the DMA zone, which controls the _minimum_ DMA mask that can be used in the system. DMA masks must always be greater than this limit. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] libfdt: Add fdt_next_subnode() to permit easy subnode iteration
Iterating through subnodes with libfdt is a little painful to write as we
need something like this:
for (depth = 0, count = 0,
offset = fdt_next_node(fdt, parent_offset, depth);
(offset = 0) (depth 0);
offset = fdt_next_node(fdt, offset, depth)) {
if (depth == 1) {
/* code body */
}
}
Using fdt_next_subnode() we can instead write this, which is shorter and
easier to get right:
for (depth = 0, offset = fdt_next_subnode(fdt, parent_offset, depth);
offset = 0;
offset = fdt_next_subnode(fdt, offset, depth)) {
/* code body */
}
Also, it doesn't require two levels of indentation for the loop body.
Signed-off-by: Simon Glass s...@chromium.org
---
libfdt/fdt.c | 12 ++
libfdt/libfdt.h | 17 +
tests/Makefile.tests | 3 +-
tests/run_tests.sh| 3 ++
tests/subnode_iterate.c | 97 +++
tests/subnode_iterate.dts | 44 +
6 files changed, 175 insertions(+), 1 deletion(-)
create mode 100644 tests/subnode_iterate.c
create mode 100644 tests/subnode_iterate.dts
diff --git a/libfdt/fdt.c b/libfdt/fdt.c
index 57faba3..9433f38 100644
--- a/libfdt/fdt.c
+++ b/libfdt/fdt.c
@@ -198,6 +198,18 @@ int fdt_next_node(const void *fdt, int offset, int *depth)
return offset;
}
+int fdt_next_subnode(const void *fdt, int offset, int *depth)
+{
+ /* Loop until we find a direct child of the parent (depth == 1) */
+ do {
+ offset = fdt_next_node(fdt, offset, depth);
+ if (offset 0 || *depth 1)
+ return -FDT_ERR_NOTFOUND;
+ } while (*depth 1);
+
+ return offset;
+}
+
const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
{
int len = strlen(s) + 1;
diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
index 130789a..edd5488 100644
--- a/libfdt/libfdt.h
+++ b/libfdt/libfdt.h
@@ -136,6 +136,23 @@ uint32_t fdt_next_tag(const void *fdt, int offset, int
*nextoffset);
int fdt_next_node(const void *fdt, int offset, int *depth);
+/**
+ * fdt_next_subnode() - get offset of next direct subnode
+ *
+ * Set depth to 0, offset to parent, then call this function repeatedly
+ * to get direct subnodes of a parent node.
+ *
+ * @fdt: FDT blob
+ * @offset:Set this to offset of parent for the first call. For
+ * subsquent calls, pass in the value returns from the last
+ * call.
+ * @depth: Used internally to monitor depth - set this to 0 for the
+ * first call.
+ * @return offset of next subnode, or -FDT_ERR_NOTFOUND if there are no more
+ * subnodes
+ */
+int fdt_next_subnode(const void *fdt, int offset, int *depth);
+
/**/
/* General functions */
/**/
diff --git a/tests/Makefile.tests b/tests/Makefile.tests
index d59bff8..dafb618 100644
--- a/tests/Makefile.tests
+++ b/tests/Makefile.tests
@@ -20,7 +20,8 @@ LIB_TESTS_L = get_mem_rsv \
dtb_reverse dtbs_equal_unordered \
add_subnode_with_nops path_offset_aliases \
utilfdt_test \
- integer-expressions
+ integer-expressions \
+ subnode_iterate
LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
LIBTREE_TESTS_L = truncated_property
diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index b56b626..b013761 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -241,6 +241,9 @@ libfdt_tests () {
tree1_tests_rw noppy.$basetree
done
+run_dtc_test -I dts -O dtb -o subnode_iterate.dtb subnode_iterate.dts
+run_test subnode_iterate subnode_iterate.dtb
+
# Tests for behaviour on various sorts of corrupted trees
run_test truncated_property
diff --git a/tests/subnode_iterate.c b/tests/subnode_iterate.c
new file mode 100644
index 000..9a36bb6
--- /dev/null
+++ b/tests/subnode_iterate.c
@@ -0,0 +1,97 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Tests that fdt_next_subnode() works as expected
+ *
+ * Copyright (C) 2013 Google, Inc
+ *
+ * Copyright (C) 2007 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth
Re: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding
Rob, Can I get your ack on this binding or do you think we need to change something? Thanks, Stephen On 04/15/13 14:33, Stephen Boyd wrote: On 04/15/13 14:20, Rob Herring wrote: On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd sb...@codeaurora.org wrote: @@ -26,3 +30,52 @@ Example: 1 10 0xf08; clock-frequency = 1; }; + +** Memory mapped timer node properties + +- compatible : Should at least contain arm,armv7-timer-mem. Everything about this timer is architecturally defined? If not, let's use a more specific name. I'm not sure I'm following you, but everything described here is part of the ARM definition. What would be a more specific name? + +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +- reg : The control frame base address. + +Note that #address-cells, #size-cells, and ranges shall be present to ensure +the CPU can address a frame's registers. + +Frame: + +- frame-number: 0 to 7. I'd really like to get rid of the frame numbers and sub-nodes. Is the frame number significant to software? We need the frame number to read and write registers in the control frame (the first base in the parent node). We currently use it to determine if a frame has support for the virtual timer by reading the CNTTIDR (a register with 4 bits per frame describing capabilities). If we wanted to control access to the second view of a frame we would also need to configure the CNTPL0ACRn register that pertains to the frame we're controlling. Without a frame number we wouldn't know which register to write. +- interrupts : Interrupt list for physical and virtual timers in that order. + The virtual timer interrupt is optional. Is that optional per frame? Yes the virtual and physical timer interrupt is per-frame and the virtual interrupt is optional. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote: Ben, Can I have your Ack for this? The change is straightforward and neither of the 2 drivers used the id parameter that is removed. Didn't you get my mail about a compile failure caused by this patch ? No, and I can't find any evidence of a mail in my inbox or in the list archives. A quick build test leads to: /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_probe': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:2: error: implicit declaration of function 'to_platform_driver' [-Werror=implicit-function-declaration] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:6: error: assignment makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_remove': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:363:32: error: initialization makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_shutdown': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:373:32: error: initialization makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_suspend': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:420:32: error: initialization makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_resume': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:431:32: error: initialization makes pointer from integer without a cast [-Werror] cc1: all warnings being treated as errors make[2]: *** [arch/powerpc/kernel/ibmebus.o] Error 1 make[2]: *** Waiting for unfinished jobs Haven't had a chance to look too closely today -EJETLAG :-) You need patch 2 of this series to fix this: driver core: move to_platform_driver to platform_device.h which as Arnd pointed out needs to come first. I've fixed that in my tree, but I don't think it warrants another post. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote: On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote: Ben, Can I have your Ack for this? The change is straightforward and neither of the 2 drivers used the id parameter that is removed. Didn't you get my mail about a compile failure caused by this patch ? No, and I can't find any evidence of a mail in my inbox or in the list archives. Odd... .../... You need patch 2 of this series to fix this: driver core: move to_platform_driver to platform_device.h which as Arnd pointed out needs to come first. I've fixed that in my tree, but I don't think it warrants another post. Can I pull you tree from somewhere to test ? Cheers, Ben. Rob -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On 04/25/2013 03:12 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote: On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote: [...] You need patch 2 of this series to fix this: driver core: move to_platform_driver to platform_device.h which as Arnd pointed out needs to come first. I've fixed that in my tree, but I don't think it warrants another post. Can I pull you tree from somewhere to test ? Here you go: git://sources.calxeda.com/kernel/linux.git of-platform-removal Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Call for testing: device nodes as kobjects
On Thu, Apr 25, 2013 at 6:11 PM, Nathan Fontenot nf...@linux.vnet.ibm.com wrote: Hi Grant, I finally got some time to play around with this on powerpc/pseries. Everything looks the same in the device tree, though I am seeing an issue with of_property_update(). The routine appears to work and update the property but when you read the file from userspace you still get the same content that was present before the update. The root cause appears to be that of_update_property adds the new property to the property list on the device node but does not update the binary attribute for the file created for that property. I tried to poke around a bit but couldn't get anything to work that would resolve the issue. I'll try to look around some more and send something your way if I can get it to work. Great, thanks for the testing Nathan. I'll take a look also. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding
On 04/15/2013 04:33 PM, Stephen Boyd wrote: On 04/15/13 14:20, Rob Herring wrote: On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd sb...@codeaurora.org wrote: @@ -26,3 +30,52 @@ Example: 1 10 0xf08; clock-frequency = 1; }; + +** Memory mapped timer node properties + +- compatible : Should at least contain arm,armv7-timer-mem. Everything about this timer is architecturally defined? If not, let's use a more specific name. I'm not sure I'm following you, but everything described here is part of the ARM definition. What would be a more specific name? Something that corresponds to the particular implementation like cortex-a15 (obviously not an example that has this). I'm fine with leaving this for now, but would like to see that added when specific SOC dts are added. Better to be specific in case we need to use it for something like errata work-arounds. Of course we haven't done that so far with the arch timer bindings... + +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +- reg : The control frame base address. + +Note that #address-cells, #size-cells, and ranges shall be present to ensure +the CPU can address a frame's registers. + +Frame: + +- frame-number: 0 to 7. I'd really like to get rid of the frame numbers and sub-nodes. Is the frame number significant to software? We need the frame number to read and write registers in the control frame (the first base in the parent node). We currently use it to determine if a frame has support for the virtual timer by reading the CNTTIDR (a register with 4 bits per frame describing capabilities). If we wanted to control access to the second view of a frame we would also need to configure the CNTPL0ACRn register that pertains to the frame we're controlling. Without a frame number we wouldn't know which register to write. I've gone thru the memory mapped part of the spec now, so I think I understand things better. I see how the frame number is needed, but... The control base is only accessible in secure or hyp mode. How does a guest know that it is a guest and can't map the control base? Seems like we need to allow a subset of the binding that is just a reg and interrupts properties without the frame sub nodes. Rob +- interrupts : Interrupt list for physical and virtual timers in that order. + The virtual timer interrupt is optional. Is that optional per frame? Yes the virtual and physical timer interrupt is per-frame and the virtual interrupt is optional. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation/devicetree: make semantic of initrd-end more explicit
On 04/25/2013 07:27 AM, Uwe Kleine-König wrote: Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Documentation/devicetree/usage-model.txt | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Applied. Thanks, Rob diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt index ef9d06c..0efedaa 100644 --- a/Documentation/devicetree/usage-model.txt +++ b/Documentation/devicetree/usage-model.txt @@ -191,9 +191,11 @@ Linux it will look something like this: }; The bootargs property contains the kernel arguments, and the initrd-* -properties define the address and size of an initrd blob. The -chosen node may also optionally contain an arbitrary number of -additional properties for platform-specific configuration data. +properties define the address and size of an initrd blob. Note that +initrd-end is the first address after the initrd image, so this doesn't +match the usual semantic of struct resource. The chosen node may also +optionally contain an arbitrary number of additional properties for +platform-specific configuration data. During early boot, the architecture setup code calls of_scan_flat_dt() several times with different helper callbacks to parse device tree ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/8] metag: tz1090: add asm/soc-tz1090/gpio.h
On Tue, Apr 23, 2013 at 4:33 PM, James Hogan james.ho...@imgtec.com wrote: Add asm/soc-tz1090/gpio.h with definitions to number all the GPIOs available on-chip. This is for use by the pinctrl and GPIO drivers. Signed-off-by: James Hogan james.ho...@imgtec.com Usually the specific pins and names is a pecularity best contained in the GPIO or pinctrl subsystem. Please try to push this down into the driver, and only use a simple number to access the GPIOs. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/8] pinctrl-tz1090: add TZ1090 pinctrl driver
On Tue, Apr 23, 2013 at 4:33 PM, James Hogan james.ho...@imgtec.com wrote:
Add a pin control driver for the main pins on the TZ1090 SoC. This
doesn't include the low-power pins as they're controlled separately via
the Powerdown Controller (PDC) registers.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-...@vger.kernel.org
(...)
+++ b/drivers/pinctrl/Kconfig
@@ -196,6 +196,12 @@ config PINCTRL_TEGRA114
bool
select PINCTRL_TEGRA
+config PINCTRL_TZ1090
+ bool Toumaz Xenif TZ1090 pin control driver
+ depends on SOC_TZ1090
+ select PINMUX
+ select PINCONF
Why are you not using GENERIC_PINCONF?
It doesn't seem like this pin controller is using something
that isn't covered by that library.
This way you get rid of TZ1090_PINCONF_PACK() etc
and can use the standard packing.
+#include asm/soc-tz1090/gpio.h
As mentioned I want the pin definintions from the arch to be in this
subsystem as well.
If the GPIO driver is also using the, then move the GPIO driver
into drivers/pinctrl, that is recommended in such cases.
+ * @drv: Drive control supported, 0 if unsupported.
+ * This means Schmitt, Slew, and Drive strength.
+ * @slw_bit: Slew register bit. 0 if unsupported.
+ * The same bit is used for Schmitt, and Drive (*2).
(...)
+ u32 drv:1;
So what about you use a bool for that?
+ u32 slw_bit:5;
+};
(...)
+/* Pin names */
+
+static const struct pinctrl_pin_desc tz1090_pins[] = {
+ /* Normal GPIOs */
+ PINCTRL_PIN(TZ1090_PIN_SDIO_CLK,sdio_clk),
+ PINCTRL_PIN(TZ1090_PIN_SDIO_CMD,sdio_cmd),
Are these actually the names from the datasheet? Usually these
have geographical names, like D1, A7... but just checking.
(...)
+/* Sub muxes */
Can you describe here briefly what a sub mux is and how it is
deployed in this system? It's getting complicated at this point
so some help would be appreciated.
+/* Pin group with mux control */
+#define MUX_PG(pg_name, f0, f1, f2, f3, f4,\
+ mux_r, mux_b, mux_w, slw_b) \
+ { \
+ .name = #pg_name, \
+ .pins = pg_name##_pins, \
+ .npins = ARRAY_SIZE(pg_name##_pins),\
+ .mux = MUX(f0, f1, f2, f3, f4, \
+ mux_r, mux_b, mux_w),\
+ .drv = ((slw_b) = 0), \
+ .slw_bit = (slw_b), \
+ }
+
+#define SIMPLE_PG(pg_name) \
+ { \
+ .name = #pg_name, \
+ .pins = pg_name##_pins, \
+ .npins = ARRAY_SIZE(pg_name##_pins),\
+ }
+
+#define SIMPLE_DRV_PG(pg_name, slw_b) \
+ { \
+ .name = #pg_name, \
+ .pins = pg_name##_pins, \
+ .npins = ARRAY_SIZE(pg_name##_pins),\
+ .drv = 1, \
+ .slw_bit = (slw_b), \
+ }
+
+#define DRV_PG(pg_name, slw_b) \
+ { \
+ .name = drive_#pg_name, \
+ .pins = drive_##pg_name##_pins, \
+ .npins = ARRAY_SIZE(drive_##pg_name##_pins),\
+ .drv = 1, \
+ .slw_bit = (slw_b), \
+ }
+
+/*name f0, f1,f2,f3, f4, mux r/b/w */
+DEFINE_SUBMUX(ext_dac, DAC, NOT_IQADC_STB, IQDAC_STB, NA, NA, IF_CTL, 6, 2);
Again, this is not very easy to understand, so more commenting is warranted.
The macros may need individual documentation for being quite
hard to understand.
+/**
+ * struct tz1090_pmx - Private pinctrl data
+ * @dev: Platform device
+ * @pctl: Pin control device
+ * @regs: Register region
+ * @lock: Lock protecting coherency of pin_en, gpio_en, select_en, and
+ * SELECT regs
+ * @pin_en:Pins that have been enabled (32 pins packed into each element)
+ * @gpio_en: GPIOs that have been enabled (32 pins packed into each
element)
+ * @select_en: Pins that have been force
Re: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding
On 04/25/13 14:47, Rob Herring wrote: On 04/15/2013 04:33 PM, Stephen Boyd wrote: On 04/15/13 14:20, Rob Herring wrote: On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd sb...@codeaurora.org wrote: @@ -26,3 +30,52 @@ Example: 1 10 0xf08; clock-frequency = 1; }; + +** Memory mapped timer node properties + +- compatible : Should at least contain arm,armv7-timer-mem. Everything about this timer is architecturally defined? If not, let's use a more specific name. I'm not sure I'm following you, but everything described here is part of the ARM definition. What would be a more specific name? Something that corresponds to the particular implementation like cortex-a15 (obviously not an example that has this). I'm fine with leaving this for now, but would like to see that added when specific SOC dts are added. Better to be specific in case we need to use it for something like errata work-arounds. Of course we haven't done that so far with the arch timer bindings... Agreed. I'm under the impression that most of our compatible fields should be more specific than they currently are so we can workaround hw bugs like you say. Perhaps the catch all generic one should just be arm,arm-timer-mem since it isn't tied to any particular CPU type? + +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +- reg : The control frame base address. + +Note that #address-cells, #size-cells, and ranges shall be present to ensure +the CPU can address a frame's registers. + +Frame: + +- frame-number: 0 to 7. I'd really like to get rid of the frame numbers and sub-nodes. Is the frame number significant to software? We need the frame number to read and write registers in the control frame (the first base in the parent node). We currently use it to determine if a frame has support for the virtual timer by reading the CNTTIDR (a register with 4 bits per frame describing capabilities). If we wanted to control access to the second view of a frame we would also need to configure the CNTPL0ACRn register that pertains to the frame we're controlling. Without a frame number we wouldn't know which register to write. I've gone thru the memory mapped part of the spec now, so I think I understand things better. I see how the frame number is needed, but... The control base is only accessible in secure or hyp mode. How does a guest know that it is a guest and can't map the control base? Seems like we need to allow a subset of the binding that is just a reg and interrupts properties without the frame sub nodes. I don't see that part. My understanding is that the control base is accessible in non-secure mode and by the guests. There are certain registers within that base that are only accessible in secure mode though: CNTFRQ and CNTNSAR. Also some registers are configurable: CNTACRn and CNTVOFFN. CNTVOFFN is only accessible in the hypervisor. We don't really care about CNTFRQ because it's duplicated into each view. We do care about CNTNSAR. Luckily the spec just works there in the sense that we can use CNTTIDR in conjunction with CNTACRn and determine if we have access to a frame we're interested in if the CNTTIDR bits say the frame is present and the CNTACRn register says we can access it. If not then it must be locked down for secure users. Unfortunately hardware doesn't have a way to say that a particular frame is reserved for the hypervisor or the guest kernel/userspace. We need some help from software, so we have the status property express that a particular frame is available. We have to assume the DT is going to be different depending on if you're the hypervisor or the guest. That's a valid assumption right? Otherwise I hope we can do some trapping of the guest's mapping to the control base and then rewrite what they read so that they only see the frame that we want to be available to them. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/8] gpio-tz1090: add TZ1090 gpio driver
On Tue, Apr 23, 2013 at 4:33 PM, James Hogan james.ho...@imgtec.com wrote:
Add a GPIO driver for the main GPIOs found in the TZ1090 (Comet) SoC.
This doesn't include low-power GPIOs as they're controlled separately
via the Powerdown Controller (PDC) registers.
The driver is instantiated by device tree and supports interrupts for
all GPIOs.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-...@vger.kernel.org
(...)
+ - #gpio-cells: Should be 2. The syntax of the gpio specifier used by client
+nodes should have the following values.
+ [phandle of the gpio controller node]
+[gpio number within the gpio bank]
+[standard Linux gpio flags]
So when someone using this device tree for Symbian or Windows
Mobile start to work, what does standard Linux gpio flags tell them?
+Values for gpio specifier:
+- GPIO number: a value in the range 0 to 29.
+- GPIO flags: standard Linux GPIO flags as found in of_gpio.h
Dito. Linux-specifics are not generally allowed in device trees,
and if they are anyway used they shall be prefixed with linux,
+ Bank subnode optional properties:
+ - gpio-ranges: Mapping to pin controller pins
Here you seem to use DT GPIO ranges, yet the pinctrl driver registers
some GPIO range, care to explain how that fits together?
+ - #interrupt-cells: Should be 2. The syntax of the interrupt specifier
used by
+client nodes should have the following values.
+ [phandle of the interurupt controller]
+[gpio number within the gpio bank]
+[standard Linux irq flags]
+
+Values for irq specifier:
+- GPIO number: a value in the range 0 to 29
+- IRQ flags: standard Linux IRQ flags for edge and level triggering
Same comments.
(...)
+#include asm/global_lock.h
What on earth is that. I can only fear it. I don't like the
looks of that thing.
(...)
+/* Convenience register accessors */
+static void tz1090_gpio_write(struct tz1090_gpio_bank *bank,
+ unsigned int reg_offs, u32 data)
+{
+ iowrite32(data, bank-reg + reg_offs);
+}
+
+static u32 tz1090_gpio_read(struct tz1090_gpio_bank *bank,
+ unsigned int reg_offs)
+{
+ return ioread32(bank-reg + reg_offs);
+}
The pinctrl driver included the keyword inline for these so
this should be consistent and do that too.
(...)
+static void tz1090_gpio_clear_bit(struct tz1090_gpio_bank *bank,
+ unsigned int reg_offs,
+ unsigned int offset)
+{
+ int lstat;
+
+ __global_lock2(lstat);
+ _tz1090_gpio_clear_bit(bank, reg_offs, offset);
+ __global_unlock2(lstat);
+}
This global lock scares me.
+static inline void _tz1090_gpio_clear_bit(struct tz1090_gpio_bank *bank,
+ unsigned int reg_offs,
+ unsigned int offset)
+{
+ u32 value;
+
+ value = tz1090_gpio_read(bank, reg_offs);
+ value = ~(0x1 offset);
I usually do this:
#include linux/bitops.h
value = ~BIT(offset);
+ tz1090_gpio_write(bank, reg_offs, value);
+}
+/* caller must hold LOCK2 */
+static inline void _tz1090_gpio_set_bit(struct tz1090_gpio_bank *bank,
+ unsigned int reg_offs,
+ unsigned int offset)
+{
+ u32 value;
+
+ value = tz1090_gpio_read(bank, reg_offs);
+ value |= 0x1 offset;
I usually do this:
#include linux/bitops.h
value |= BIT(offset);
+/* caller must hold LOCK2 */
+static inline void _tz1090_gpio_mod_bit(struct tz1090_gpio_bank *bank,
+ unsigned int reg_offs,
+ unsigned int offset,
+ int val)
If val is used as it is, make it a bool.
+{
+ u32 value;
+
+ value = tz1090_gpio_read(bank, reg_offs);
+ value = ~(0x1 offset);
+ value |= !!val offset;
You're claming val to [0,1] obviously it's a bool.
+ tz1090_gpio_write(bank, reg_offs, value);
+}
(...)
+static int tz1090_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+ struct tz1090_gpio_bank *bank = to_bank(chip);
+ int ret;
+
+ ret = pinctrl_request_gpio(chip-base + offset);
+ if (ret)
+ return ret;
+
+ tz1090_gpio_set_bit(bank, REG_GPIO_DIR, offset);
+ tz1090_gpio_set_bit(bank, REG_GPIO_BIT_EN, offset);
+
+ return 0;
+}
This is nice, it just glues smoothly into pinctrl here.
+static void tz1090_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+ struct tz1090_gpio_bank *bank = to_bank(chip);
+
+ pinctrl_free_gpio(chip-base + offset);
+
Re: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding
On 04/25/2013 05:48 PM, Stephen Boyd wrote: On 04/25/13 14:47, Rob Herring wrote: On 04/15/2013 04:33 PM, Stephen Boyd wrote: On 04/15/13 14:20, Rob Herring wrote: On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd sb...@codeaurora.org wrote: @@ -26,3 +30,52 @@ Example: 1 10 0xf08; clock-frequency = 1; }; + +** Memory mapped timer node properties + +- compatible : Should at least contain arm,armv7-timer-mem. Everything about this timer is architecturally defined? If not, let's use a more specific name. I'm not sure I'm following you, but everything described here is part of the ARM definition. What would be a more specific name? Something that corresponds to the particular implementation like cortex-a15 (obviously not an example that has this). I'm fine with leaving this for now, but would like to see that added when specific SOC dts are added. Better to be specific in case we need to use it for something like errata work-arounds. Of course we haven't done that so far with the arch timer bindings... Agreed. I'm under the impression that most of our compatible fields should be more specific than they currently are so we can workaround hw bugs like you say. Perhaps the catch all generic one should just be arm,arm-timer-mem since it isn't tied to any particular CPU type? + +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +- reg : The control frame base address. + +Note that #address-cells, #size-cells, and ranges shall be present to ensure +the CPU can address a frame's registers. + +Frame: + +- frame-number: 0 to 7. I'd really like to get rid of the frame numbers and sub-nodes. Is the frame number significant to software? We need the frame number to read and write registers in the control frame (the first base in the parent node). We currently use it to determine if a frame has support for the virtual timer by reading the CNTTIDR (a register with 4 bits per frame describing capabilities). If we wanted to control access to the second view of a frame we would also need to configure the CNTPL0ACRn register that pertains to the frame we're controlling. Without a frame number we wouldn't know which register to write. I've gone thru the memory mapped part of the spec now, so I think I understand things better. I see how the frame number is needed, but... The control base is only accessible in secure or hyp mode. How does a guest know that it is a guest and can't map the control base? Seems like we need to allow a subset of the binding that is just a reg and interrupts properties without the frame sub nodes. I don't see that part. My understanding is that the control base is accessible in non-secure mode and by the guests. There are certain registers within that base that are only accessible in secure mode though: CNTFRQ and CNTNSAR. Also some registers are configurable: CNTACRn and CNTVOFFN. CNTVOFFN is only accessible in the hypervisor. The example is section E.8 seems to say otherwise. Perhaps Mark R can comment further. We don't really care about CNTFRQ because it's duplicated into each view. We do care about CNTNSAR. Luckily the spec just works there in the sense that we can use CNTTIDR in conjunction with CNTACRn and determine if we have access to a frame we're interested in if the CNTTIDR bits say the frame is present and the CNTACRn register says we can access it. If not then it must be locked down for secure users. Unfortunately hardware doesn't have a way to say that a particular frame is reserved for the hypervisor or the guest kernel/userspace. We need some help from software, so we have the status property express that a particular frame is available. We have to assume the DT is going to be different depending on if you're the hypervisor or the guest. That's a valid assumption right? Otherwise I hope we can do some trapping of the guest's mapping to the control base and then rewrite what they read so that they only see the frame that we want to be available to them. Yeah, I believe the only way to prevent access within non-secure world is with the MMU. So I guess the example is just policy that the hypervisor would/may not create a stage2 mapping. You still have the same issue that the guest should not be passed the control base. You could make the reg property optional, but then what do you do with the node name? Certainly the guest dtb will be different. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding
On 04/25/13 16:06, Rob Herring wrote: On 04/25/2013 05:48 PM, Stephen Boyd wrote: We don't really care about CNTFRQ because it's duplicated into each view. We do care about CNTNSAR. Luckily the spec just works there in the sense that we can use CNTTIDR in conjunction with CNTACRn and determine if we have access to a frame we're interested in if the CNTTIDR bits say the frame is present and the CNTACRn register says we can access it. If not then it must be locked down for secure users. Unfortunately hardware doesn't have a way to say that a particular frame is reserved for the hypervisor or the guest kernel/userspace. We need some help from software, so we have the status property express that a particular frame is available. We have to assume the DT is going to be different depending on if you're the hypervisor or the guest. That's a valid assumption right? Otherwise I hope we can do some trapping of the guest's mapping to the control base and then rewrite what they read so that they only see the frame that we want to be available to them. Yeah, I believe the only way to prevent access within non-secure world is with the MMU. So I guess the example is just policy that the hypervisor would/may not create a stage2 mapping. You still have the same issue that the guest should not be passed the control base. You could make the reg property optional, but then what do you do with the node name? I don't follow. Why shouldn't we tell the guest about the hardware that's there? Shouldn't they be able to safely assume they can access the control base just like a non-guest kernel running in PL1 would be able to? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Wed, Apr 24, 2013 at 12:28 PM, 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. 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 --- [...] + - enable-method + Value type: stringlist + Usage and definition depend on ARM architecture version and + configuration: + # On ARM v8 64-bit systems running the OS in AArch64, + this property is required and must be spin-table. What about PSCI? I don't think the ePAPR spin-table definition is sufficient for ARM. How do you define wake up by SGI or sev instruction. + # On ARM 32-bit systems or ARM v8 systems running + the OS in AArch32 this property is prohibited. Why? Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
Without WLAN we cannot switch omap4 to use device tree
only booting. This patch can be reverted when the
binding for wl12xx is added.
Cc: Luciano Coelho coe...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 73762ac..69c520e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include linux/io.h
#include linux/clk.h
#include linux/err.h
+#include linux/gpio.h
#include linux/slab.h
#include linux/of.h
#include linux/pinctrl/machine.h
@@ -22,6 +23,7 @@
#include linux/platform_data/omap_ocp2scp.h
#include linux/platform_data/mailbox-omap.h
#include linux/usb/omap_control_usb.h
+#include linux/wl12xx.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -640,6 +642,40 @@ static void __init omap_init_ocp2scp(void)
static inline void omap_init_ocp2scp(void) { }
#endif
+#if IS_ENABLED(CONFIG_WL12XX)
+
+static struct wl12xx_platform_data wl12xx __initdata;
+
+void __init omap_init_wl12xx_of(void)
+{
+ int ret;
+
+ if (!of_have_populated_dt())
+ return;
+
+ if (of_machine_is_compatible(ti,omap4-sdp)) {
+ wl12xx.board_ref_clock = WL12XX_REFCLOCK_26;
+ wl12xx.board_tcxo_clock = WL12XX_TCXOCLOCK_26;
+ wl12xx.irq = gpio_to_irq(53);
+ } else if (of_machine_is_compatible(ti,omap4-panda)) {
+ wl12xx.board_ref_clock = WL12XX_REFCLOCK_38;
+ wl12xx.irq = gpio_to_irq(53);
+ } else {
+ return;
+ }
+
+ ret = wl12xx_set_platform_data(wl12xx);
+ if (ret) {
+ pr_err(error setting wl12xx data: %d\n, ret);
+ return;
+ }
+}
+#else
+static inline omap_init_wl12xx_of(void)
+{
+}
+#endif
+
/*-*/
static int __init omap2_init_devices(void)
@@ -664,6 +700,9 @@ static int __init omap2_init_devices(void)
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
+ } else {
+ /* These can be removed when bindings are done */
+ omap_init_wl12xx_of();
}
omap_init_sti();
omap_init_rng();
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for pandaboard
This is needed to get wl12xx working with device tree based
booting.
Note that we claim the various GPIO inputs in the regulator
as the proper muxing is needed to enable and disable the
regulator.
Also, we want to use non-removable instead of ti,non-removable
as the ti,non-removable also sets no_regulator_off_init which
is really not what we want as then wl12xx won't get powered
up and down which is needed for resetting it.
Cc: Luciano Coelho coe...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 43 -
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 628f744..16b23bf 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -86,6 +86,19 @@
clock-names = main_clk;
clock-frequency = 1920;
};
+
+ /* regulator for wl12xx on sdio5 */
+ wl12xx_vmmc: wl12xx_vmmc {
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_gpio;
+ compatible = regulator-fixed;
+ regulator-name = vwl1271;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ gpio = gpio2 11 0;
+ startup-delay-us = 7;
+ enable-active-high;
+ };
};
omap4_pmx_core {
@@ -185,6 +198,30 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
;
};
+
+ /* wl12xx GPIO outputs for WLAN_EN, BT_EN, FM_EN, BT_WAKEUP */
+ wl12xx_gpio: pinmux_wl12xx_gpio {
+ pinctrl-single,pins =
+ 0x26 0x3/* gpmc_a19.gpio_43 OUTPUT | MODE3 */
+ 0x2c 0x3/* gpmc_a22.gpio_46 OUTPUT | MODE3 */
+ 0x30 0xb/* gpmc_a24.gpio_48 OUTPUT | MODE3 */
+ 0x32 0xb/* gpmc_a25.gpio_49 OUTPUT | MODE3 */
+ ;
+ };
+
+ /* wl12xx GPIO inputs and SDIO pins */
+ wl12xx_pins: pinmux_wl12xx_pins {
+ pinctrl-single,pins =
+ 0x38 0x103 /* gpmc_ncs2.gpio_52 INPUT | MODE3 */
+ 0x3a 0x103 /* gpmc_ncs3.gpio_53 INPUT | MODE3 */
+ 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+ 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */
+ 0x10c 0x118 /* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP
| MODE0 */
+ 0x10e 0x118 /* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP
| MODE0 */
+ 0x110 0x118 /* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP
| MODE0 */
+ 0x112 0x118 /* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP
| MODE0 */
+ ;
+ };
};
i2c1 {
@@ -264,8 +301,12 @@
};
mmc5 {
- ti,non-removable;
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_pins;
+ vmmc-supply = wl12xx_vmmc;
+ non-removable;
bus-width = 4;
+ cap-power-off-card;
};
emif1 {
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for blaze
This should work assuming the board-4430sdp.c works, but it seems
that I don't have the 1283 PG 2.21 connectivity device on
my blaze. Anybody got a spare connectivity device for blaze?
Also, if somebody has the schematics, please provide a patch
for the missing GPIO muxes for blaze, see the the panda for
what's currently missing.
Cc: Luciano Coelho coe...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Ruslan Bilovol ruslan.bilo...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap4-sdp.dts | 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index a35d9cd..c13c483 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,19 @@
DMic, Digital Mic,
Digital Mic, Digital Mic1 Bias;
};
+
+ /* regulator for wl12xx on sdio5 */
+ wl12xx_vmmc: wl12xx_vmmc {
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_gpio;
+ compatible = regulator-fixed;
+ regulator-name = vwl1271;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ gpio = gpio2 22 0;
+ startup-delay-us = 7;
+ enable-active-high;
+ };
};
omap4_pmx_core {
@@ -275,6 +288,26 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
;
};
+
+ /* wl12xx GPIO output for WLAN_EN */
+ wl12xx_gpio: pinmux_wl12xx_gpio {
+ pinctrl-single,pins =
+ 0x3c 0x3/* gpmc_nwp.gpio_54 OUTPUT | MODE3 */
+ ;
+ };
+
+ /* wl12xx GPIO inputs and SDIO pins */
+ wl12xx_pins: pinmux_wl12xx_pins {
+ pinctrl-single,pins =
+ 0x3a 0x103 /* gpmc_ncs3.gpio_53 INPUT | MODE3 */
+ 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+ 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */
+ 0x10c 0x118 /* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP
| MODE0 */
+ 0x10e 0x118 /* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP
| MODE0 */
+ 0x110 0x118 /* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP
| MODE0 */
+ 0x112 0x118 /* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP
| MODE0 */
+ ;
+ };
};
i2c1 {
@@ -400,8 +433,12 @@
};
mmc5 {
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_pins;
+ vmmc-supply = wl12xx_vmmc;
+ non-removable;
bus-width = 4;
- ti,non-removable;
+ cap-power-off-card;
};
emif1 {
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] Thermal:exynos: Thermal Measurement Unit fix and Samsung SoCs support
Hi Eduardo,
On 25 April 2013 21:58, Lukasz Majewski l.majew...@samsung.com wrote:
Hi Eduardo,
Hello Lukasz,
On 25-04-2013 08:30, Lukasz Majewski wrote:
This patch series provide various fixes for TMU block.
First of all it fixes a problem with get_cpu_frequency() lockup at
cpu_cooling.c.
Secondly a proper regulator definition (VDD_TS) has been added.
Moreover device tree definitions and documentation entry are now in
place.
Dependencies (those patches shall be applied on top of):
- clk: exynos4: Add clock entries for TMU
Is this one same as [1/6] clk:exynos4:TMU Thermal Measurement Unit
clock added to common clock framework in your previous series?
The one sent by Lukasz has been dropped as an equivalent patch sent by
me is already under review.
Yes, this is a similar patch. However I've changed more clocks to
clk_prepare_enable (clk_unprepare_disable). I've spoken about this with
Sachin recently.
The above description is actually for the below patch. Lukasz will
test and see if additional changes are needed.
If so he will send an incremental patch to address it.
- Thermal: exynos: Add clk_{un}prepare APIs
Same as
thermal:exynos4: TMU Common clock framework support for TMU (Thermal
Monitoring Unit)
in your previous series?
- Thermal: exynos: Add compatible string for exynos4412
These 2 have been merged in the thermal next tree.
This should be same as thermal:exynos4: Enable support for Exynos4412
SoCs in your previous series?
Yes.
--
With warm regards,
Sachin
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
