Re: [PATCH 1/5 v7][RFC] ASoC: add snd_soc_register_cpu()
On Wed, Feb 27, 2013 at 03:45:45PM -0700, Stephen Warren wrote: > I can't recall how much influence the existing CODEC objects have on the > various routing/matching decisions inside the ASoC core. While this > patch does register and unregister CPU objects, I wonder if it should > have more impact on any of the existing core code? Certainly I'd expect > the CPU objects to show up in ASoC's debugfs and any similar files... All that happens with routing is that routes will be bound within the current DAPM context before other objects are searched, otherwise everything is very flat. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 0/2] crypto: sahara: Add support for SAHARA in i.MX27.
Hi, the following changes since v2: - Merge device tree binding with the driver code in the same patch. - Specify that currently, only i.MX27 is supported in device tree binding. - Replace MACH_MX27 by ARCH_MXC in Kconfig. - Remove __devexit_p from sahara_remove(). I haven't finally included support for i.MX51 submitted by Arnaud. I'd rather it to be included in a separate patch later if you don't mind. [PATCH v3 1/2] i.MX27: Add clock support for SAHARA2. [PATCH v3 2/2] crypto: sahara: Add driver for SAHARA2 accelerator. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 1/2] i.MX27: Add clock support for SAHARA2.
Signed-off-by: Javier Martin --- arch/arm/mach-imx/clk-imx27.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c index 4c1d1e4..0b9664a 100644 --- a/arch/arm/mach-imx/clk-imx27.c +++ b/arch/arm/mach-imx/clk-imx27.c @@ -253,6 +253,8 @@ int __init mx27_clocks_init(unsigned long fref) clk_register_clkdev(clk[nfc_baud_gate], NULL, "imx27-nand.0"); clk_register_clkdev(clk[vpu_baud_gate], "per", "coda-imx27.0"); clk_register_clkdev(clk[vpu_ahb_gate], "ahb", "coda-imx27.0"); + clk_register_clkdev(clk[sahara_ahb_gate], "ahb", "sahara-imx27.0"); + clk_register_clkdev(clk[sahara_ipg_gate], "ipg", "sahara-imx27.0"); clk_register_clkdev(clk[dma_ahb_gate], "ahb", "imx27-dma"); clk_register_clkdev(clk[dma_ipg_gate], "ipg", "imx27-dma"); clk_register_clkdev(clk[fec_ipg_gate], "ipg", "imx27-fec.0"); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 2/2] crypto: sahara: Add driver for SAHARA2 accelerator.
SAHARA2 HW module is included in the i.MX27 SoC from
Freescale. It is capable of performing cipher algorithms
such as AES, 3DES..., hashing and RNG too.
This driver provides support for AES-CBC and AES-ECB
by now.
Reviewed-by: Arnd Bergmann
Signed-off-by: Javier Martin
---
.../devicetree/bindings/crypto/fsl-imx-sahara.txt | 15 +
drivers/crypto/Kconfig | 10 +
drivers/crypto/Makefile|1 +
drivers/crypto/sahara.c| 1070
4 files changed, 1096 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
create mode 100644 drivers/crypto/sahara.c
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
new file mode 100644
index 000..5c65ecc
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
@@ -0,0 +1,15 @@
+Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
+Currently only i.MX27 is supported.
+
+Required properties:
+- compatible : Should be "fsl,-sahara"
+- reg : Should contain SAHARA registers location and length
+- interrupts : Should contain SAHARA interrupt number
+
+Example:
+
+sah@10025000 {
+ compatible = "fsl,imx27-sahara";
+ reg = < 0x10025000 0x800>;
+ interrupts = <75>;
+};
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 87ec4d0..8458e63 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -276,6 +276,16 @@ config CRYPTO_DEV_PICOXCELL
Saying m here will build a module named pipcoxcell_crypto.
+config CRYPTO_DEV_SAHARA
+ tristate "Support for SAHARA crypto accelerator"
+ depends on ARCH_MXC && EXPERIMENTAL && OF
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_AES
+ select CRYPTO_ECB
+ help
+ This option enables support for the SAHARA HW crypto accelerator
+ found in some Freescale i.MX chips.
+
config CRYPTO_DEV_S5P
tristate "Support for Samsung S5PV210 crypto accelerator"
depends on ARCH_S5PV210
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 880a47b..38ce13d 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
obj-$(CONFIG_CRYPTO_DEV_OMAP_SHAM) += omap-sham.o
obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o
obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o
+obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o
obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
obj-$(CONFIG_CRYPTO_DEV_TEGRA_AES) += tegra-aes.o
obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
new file mode 100644
index 000..a97bb6c
--- /dev/null
+++ b/drivers/crypto/sahara.c
@@ -0,0 +1,1070 @@
+/*
+ * Cryptographic API.
+ *
+ * Support for SAHARA cryptographic accelerator.
+ *
+ * Copyright (c) 2013 Vista Silicon S.L.
+ * Author: Javier Martin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * Based on omap-aes.c and tegra-aes.c
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SAHARA_NAME "sahara"
+#define SAHARA_VERSION_3 3
+#define SAHARA_TIMEOUT_MS 1000
+#define SAHARA_MAX_HW_DESC 2
+#define SAHARA_MAX_HW_LINK 20
+
+#define FLAGS_MODE_MASK0x000f
+#define FLAGS_ENCRYPT BIT(0)
+#define FLAGS_CBC BIT(1)
+#define FLAGS_NEW_KEY BIT(3)
+#define FLAGS_BUSY 4
+
+#define SAHARA_HDR_BASE0x0080
+#define SAHARA_HDR_SKHA_ALG_AES0
+#define SAHARA_HDR_SKHA_OP_ENC (1 << 2)
+#define SAHARA_HDR_SKHA_MODE_ECB (0 << 3)
+#define SAHARA_HDR_SKHA_MODE_CBC (1 << 3)
+#define SAHARA_HDR_FORM_DATA (5 << 16)
+#define SAHARA_HDR_FORM_KEY(8 << 16)
+#define SAHARA_HDR_LLO (1 << 24)
+#define SAHARA_HDR_CHA_SKHA(1 << 28)
+#define SAHARA_HDR_CHA_MDHA(2 << 28)
+#define SAHARA_HDR_PARITY_BIT (1 << 31)
+
+/* SAHARA can only process one request at a time */
+#define SAHARA_QUEUE_LENGTH1
+
+#define SAHARA_REG_VERSION 0x00
+#define SAHARA_REG_DAR 0x04
+#define SAHARA_REG_CONTROL 0x08
+#defineSAHARA_CONTROL_SET_THROTTLE(x) (((x) & 0xff) << 24)
+#defineSAHARA_CONTROL_SET_MAXBURST(x) (((x) & 0xff) << 16)
+#defineSAHARA_CONTROL_RNG_AUTORSD (1 << 7)
+#defineSAHARA_CONTROL_ENABLE_INT (1 << 4)
+#define SAHARA_REG_CMD 0x0C
+#defineSAHARA_CMD_RESET(1 << 0)
+#defineSAHARA_CMD_CLEAR_INT(1 << 8)
+#defineSAHAR
[PATCH 2/2] mfd: stmpe: DT: Add stmpe-i2c dt alias to get id device
From: Gabriel Fernandez
This patch augments the STMP driver to read the device id
from the stmpe-i2c dt alias if present.
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Gabriel Fernandez
Signed-off-by: Linus Walleij
---
drivers/mfd/stmpe.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index e550dcb..bc85877 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -1015,7 +1015,10 @@ void stmpe_of_probe(struct stmpe_platform_data *pdata,
struct device_node *np)
{
struct device_node *child;
- pdata->id = -1;
+ pdata->id = of_alias_get_id(np, "stmpe-i2c");
+ if (pdata->id < 0)
+ pdata->id = -1;
+
pdata->irq_trigger = IRQF_TRIGGER_NONE;
of_property_read_u32(np, "st,autosleep-timeout",
--
1.7.11.3
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] mfd: stmpe: DT: Enable no-irq mode configuration
From: Gabriel Fernandez If there is no interrupt property into stmpe node then activate the no-irq mode by setting the irq value to -1. Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Gabriel Fernandez Signed-off-by: Linus Walleij --- drivers/mfd/stmpe.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c index 4b11202..e550dcb 100644 --- a/drivers/mfd/stmpe.c +++ b/drivers/mfd/stmpe.c @@ -1057,6 +1057,9 @@ int stmpe_probe(struct stmpe_client_info *ci, int partnum) return -ENOMEM; stmpe_of_probe(pdata, np); + + if (of_find_property(np, "interrupts", NULL) == NULL) + ci->irq = -1; } stmpe = devm_kzalloc(ci->dev, sizeof(struct stmpe), GFP_KERNEL); -- 1.7.11.3 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH RESEND v2] of/pci: Provide support for parsing PCI DT ranges property
This patch factors out common implementations patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_iter iter;
for_each_of_pci_range(&iter, np) {
//directly access properties of the address range, e.g.:
//iter.pci_space, iter.pci_addr, iter.cpu_addr, iter.size or
//iter.flags
//alternatively obtain a struct resource, e.g.:
//struct resource res;
//range_iter_fill_resource(iter, np, res);
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
The modifications to microblaze, mips and powerpc have not been tested.
v2:
This follows on from suggestions made by Grant Likely
(marc.info/?l=linux-kernel&m=136079602806328)
Signed-off-by: Andrew Murray
Signed-off-by: Liviu Dudau
---
arch/microblaze/pci/pci-common.c | 100 +++--
arch/mips/pci/pci.c | 44 -
arch/powerpc/kernel/pci-common.c | 93 ++-
drivers/of/address.c | 54
include/linux/of_address.h | 30 +++
5 files changed, 151 insertions(+), 170 deletions(-)
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 4dbb505..ccc0d63 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -659,67 +659,37 @@ void __devinit pci_process_bridge_OF_ranges(struct
pci_controller *hose,
struct device_node *dev,
int primary)
{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna + 5;
int memno = 0, isa_hole = -1;
- u32 pci_space;
- unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
unsigned long long isa_mb = 0;
struct resource *res;
+ struct of_pci_range_iter iter;
printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
dev->full_name, primary ? "(primary)" : "");
- /* Get ranges property */
- ranges = of_get_property(dev, "ranges", &rlen);
- if (ranges == NULL)
- return;
-
- /* Parse it */
pr_debug("Parsing ranges property...\n");
- while ((rlen -= np * 4) >= 0) {
+ for_each_of_pci_range(&iter, dev) {
/* Read next ranges element */
- pci_space = ranges[0];
- pci_addr = of_read_number(ranges + 1, 2);
- cpu_addr = of_translate_address(dev, ranges + 3);
- size = of_read_number(ranges + pna + 3, 2);
-
pr_debug("pci_space: 0x%08x pci_addr:0x%016llx "
"cpu_addr:0x%016llx size:0x%016llx\n",
- pci_space, pci_addr, cpu_addr, size);
-
- ranges += np;
+ iter.pci_space, iter.pci_addr, iter.cpu_addr,
+ iter.size);
/* If we failed translation or got a zero-sized region
* (some FW try to feed us with non sensical zero sized regions
* such as power3 which look like some kind of attempt
* at exposing the VGA memory hole)
*/
- if (cpu_addr == OF_BAD_ADDR || size == 0)
+ if (iter.cpu_addr == OF_BAD_ADDR || iter.size == 0)
continue;
- /* Now consume following elements while they are contiguous */
- for (; rlen >= np * sizeof(u32);
-ranges += np, rlen -= np * 4) {
- if (ranges[0] != pci_space)
- break;
- pci_next = of_read_number(ranges + 1, 2);
- cpu_next = of_translate_address(dev, ranges + 3);
- if (pci_next != pci_addr + size ||
- cpu_next != cpu_addr + size)
- break;
- size += of_read_number(ranges + pna + 3, 2);
- }
-
/* Act based on address space type */
res = NULL;
- switch ((pci_space >> 24) & 0x3) {
- case 1: /* PCI IO space */
+ if (iter.flags & IORESOURCE_IO) {
printk(KERN_INFO
" IO 0x%016llx..0x%016llx -> 0x%016llx\n",
- cpu_addr, cpu_addr + size
Re: [PATCH 2/2] pinctrl: imx: use pin_func_ids to search the pinctrl item.
On Wed, Feb 27, 2013 at 3:35 AM, Huang Shijie wrote:
> The uart may works in DTE mode or DCE mode. The customer can sets the
> different
> modes by the pinctrl. But the pinctrl items for DTE or DCE may share the
> same Pad id, such as:
> MX6Q_PAD_EIM_D27__UART2_RXD_DTE and MX6Q_PAD_EIM_D27__WEIM_WEIM_D_27
> share the same MX6Q_PAD_EIM_D27 pad id.
>
> The current code only search the pinctrl items by pad id. So if there two
> pinctrl items shares the same pad id, the current code only use the first one,
> even you tell the system to use the second one in the DTS file.
>
> This patch adds a new field pin_func_ids to imx_pin_group{}, and uses the
> pin_func_ids as the index to search the pinctrl items. In this way, we can
> avoid the issue.
>
> Signed-off-by: Huang Shijie
Dong/Shawn: what about this patch?
The patches anyway has to be merged through the i.MX tree I think,
if there is a huge movement in these files currently.
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] : fix compilation warnings with DT disabled
On 03/01/2013 01:09 AM, Simon Horman wrote: > On Tue, Feb 19, 2013 at 02:58:25AM +0300, Sergei Shtylyov wrote: >> Fix the following compilation warnings (in Simon Horman's renesas.git repo): >> >> In file included from arch/arm/mach-shmobile/setup-r8a7779.c:24:0: >> include/linux/of_platform.h:107:13: warning: ‘struct of_device_id’ declared >> inside parameter list [enabled by default] >> include/linux/of_platform.h:107:13: warning: its scope is only this >> definition >> or declaration, which is probably not what you want [enabled by default] >> include/linux/of_platform.h:107:13: warning: ‘struct device_node’ declared >> inside parameter list [enabled by default] >> >> only #include's headers with definitions of the above >> mentioned structures if CONFIG_OF_DEVICE=y but uses them even if not. One >> solution is to move some #include's out of #ifdef CONFIG_OF_DEVICE and use >> incomplete declarations for the rest of the structures where the #ifdef move >> doesn't help... >> >> Reported-by: Vladimir Barinov >> Signed-off-by: Sergei Shtylyov > > Reviewed-by: Simon Horman > > Grant, could you consider taking this patch? Yes, I can, but I don't seem to have the original patch. Can you send it again. >> --- >> Actually, it compiles eve without 'struct device_node' declared, I haven't >> found the reason of this, so left it there... device.h has a forward declaration of it. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] : fix compilation warnings with DT disabled
On 03/01/2013 07:46 AM, Rob Herring wrote: > On 03/01/2013 01:09 AM, Simon Horman wrote: >> On Tue, Feb 19, 2013 at 02:58:25AM +0300, Sergei Shtylyov wrote: >>> Fix the following compilation warnings (in Simon Horman's renesas.git repo): >>> >>> In file included from arch/arm/mach-shmobile/setup-r8a7779.c:24:0: >>> include/linux/of_platform.h:107:13: warning: ‘struct of_device_id’ declared >>> inside parameter list [enabled by default] >>> include/linux/of_platform.h:107:13: warning: its scope is only this >>> definition >>> or declaration, which is probably not what you want [enabled by default] >>> include/linux/of_platform.h:107:13: warning: ‘struct device_node’ declared >>> inside parameter list [enabled by default] >>> >>> only #include's headers with definitions of the above >>> mentioned structures if CONFIG_OF_DEVICE=y but uses them even if not. One >>> solution is to move some #include's out of #ifdef CONFIG_OF_DEVICE and use >>> incomplete declarations for the rest of the structures where the #ifdef move >>> doesn't help... >>> >>> Reported-by: Vladimir Barinov >>> Signed-off-by: Sergei Shtylyov >> >> Reviewed-by: Simon Horman >> >> Grant, could you consider taking this patch? > > Yes, I can, but I don't seem to have the original patch. Can you send it > again. Nevermind. Found it. I'll apply it. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/2] dma: imx-dma: Add oftree support
On Thu, Feb 28, 2013 at 02:30:27PM +0800, Shawn Guo wrote:
> On Mon, Feb 25, 2013 at 05:04:14PM +0100, Markus Pargmann wrote:
> > Adding devicetree support for imx-dma driver. Use driver name for
> > function 'imx_dma_is_general_purpose' because the devicename for
> > devicetree initialized devices is different.
>
> ...
>
> > @@ -63,7 +66,8 @@ static inline int imx_dma_is_general_purpose(struct
> > dma_chan *chan)
> > return strstr(dev_name(chan->device->dev), "sdma") ||
> > !strcmp(dev_name(chan->device->dev), "imx1-dma") ||
> > !strcmp(dev_name(chan->device->dev), "imx21-dma") ||
> > - !strcmp(dev_name(chan->device->dev), "imx27-dma");
> > + !strcmp(dev_name(chan->device->dev), "imx27-dma") ||
> > + !strcmp(chan->device->dev->driver->name, "imx-dma");
> > }
>
> So the function could just look like the following?
>
> static inline int imx_dma_is_general_purpose(struct dma_chan *chan)
> {
> return !strcmp(chan->device->dev->driver->name, "imx-sdma") ||
> !strcmp(chan->device->dev->driver->name, "imx-dma");
> }
Yes. For imx-dma there is only imx1, imx21 and imx27 that use imx-dma
driver. And the devicenames of imx-sdma are imx31-sdma and imx35-sdma,
so all devices using imx-sdma match. I will change it for v4. Thanks
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] : fix compilation warnings with DT disabled
On 03/01/2013 07:55 AM, Sergei Shtylyov wrote: > Hello. > > On 01-03-2013 17:48, Rob Herring wrote: > > Fix the following compilation warnings (in Simon Horman's > renesas.git repo): > > In file included from arch/arm/mach-shmobile/setup-r8a7779.c:24:0: > include/linux/of_platform.h:107:13: warning: ‘struct of_device_id’ > declared > inside parameter list [enabled by default] > include/linux/of_platform.h:107:13: warning: its scope is only this > definition > or declaration, which is probably not what you want [enabled by > default] > include/linux/of_platform.h:107:13: warning: ‘struct device_node’ > declared > inside parameter list [enabled by default] > > only #include's headers with definitions of > the above > mentioned structures if CONFIG_OF_DEVICE=y but uses them even if > not. One > solution is to move some #include's out of #ifdef CONFIG_OF_DEVICE > and use > incomplete declarations for the rest of the structures where the > #ifdef move > doesn't help... > > Reported-by: Vladimir Barinov > Signed-off-by: Sergei Shtylyov > Reviewed-by: Simon Horman > Grant, could you consider taking this patch? > >>> Yes, I can, but I don't seem to have the original patch. Can you send it >>> again. > >> Nevermind. Found it. I'll apply it. > >Will you drop 'struct device_node' declaration then or should I > resend? In fact, I think I should better resend it with the changelog > somewhat edited. No, I plan to leave it as is and not rely on device.h by chance declaring device_node. Rob > >> Rob > > WBR, Sergei > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] clk: add si5351 i2c common clock driver
Hi Sebastian,
On 27.02.2013 11:01, Sebastian Hesselbarth wrote:
> first of all sorry for the late answer but thanks for testing the driver.
>
> On 2/19/13, Daniel Mack wrote:
>> Hi Sebastian,
>>
>> I did some more tests today and it took me a while to dig for the root
>> cause why things were not working for me in the first place - see below.
>>
>>
>> On 09.02.2013 13:59, Sebastian Hesselbarth wrote:
>>
>>> +==Example==
>>> +
>>> +/* 25MHz reference crystal */
>>> +ref25: ref25M {
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>;
>>> + clock-frequency = <2500>;
>>> +};
>>> +
>>> +i2c-master-node {
>>> +
>>> + /* Si5351a msop10 i2c clock generator */
>>> + si5351a: clock-generator@60 {
>>> + compatible = "silabs,si5351a-msop";
>>> + reg = <0x60>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + #clock-cells = <1>;
>>> +
>>> + /* connect xtal input to 25MHz reference */
>>> + clocks = <&ref25>;
>>
>> As referred to in another thread, registering the ref25M clock that way
>> didn't suffice for me on my platform - but that's a different story.
>
> I guess "fixed-clock" isn't registered by OMAP's clock init code? I had
> to do this on dove, too. Actually, I will come back to clock initialization
> for
> dove later and was hoping that there will be some global way of registering
> core common clock drivers (or at least fixed-clock) until then.
>
>>> +static void si5351_read_parameters(struct si5351_driver_data *drvdata,
>>> + unsigned char reg, struct si5351_parameters *params)
>>> +{
>>> + unsigned char buf[SI5351_PARAMETERS_LENGTH];
>>
>> On a general note, I think you can use u8 instead of unsigned char all
>> over the place here, which will save you some indentation trouble.
>
> Ok, I guess I was deriving "unsigned char" usage from other clock drivers
> and never went to u8. But I ll reconsider using u8 when all issues are
> worked out.
>
>>> +static inline int _si5351_clkout_reparent(struct si5351_driver_data
>>> *drvdata,
>>> + unsigned char num, unsigned char parent)
>>> +{
>>> + struct clk *pclk;
>>> +
>>> + if (num > 8 ||
>>> + (drvdata->variant == SI5351_VARIANT_A3 && num > 3))
>>> + return -EINVAL;
>>> +
>>> + switch (parent) {
>>> + case 0:
>>> + pclk = drvdata->msynth[num].hw.clk;
>>> + break;
>>> + case 1:
>>> + pclk = drvdata->msynth[0].hw.clk;
>>> + if (num >= 4)
>>> + pclk = drvdata->msynth[4].hw.clk;
>>> + break;
>>> + case 2:
>>> + pclk = drvdata->xtal.clk;
>>> + break;
>>> + case 3:
>>> + if (drvdata->variant != SI5351_VARIANT_C)
>>> + return -EINVAL;
>>> + pclk = drvdata->clkin.clk;
>>> + break;
>>> + default:
>>> + return -EINVAL;
>>> + }
>>> + return clk_set_parent(drvdata->clkout[num].hw.clk, pclk);
>>> +}
>>
>> [...]
>>
>>> +static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
>>> +{
>>> + struct si5351_hw_data *hwdata =
>>> + container_of(hw, struct si5351_hw_data, hw);
>>> + unsigned val;
>>> +
>>> + val = 0;
>>> + hw->clk->flags &= ~CLK_SET_RATE_PARENT;
>>> + switch (index) {
>>> + case 0:
>>> + hw->clk->flags |= CLK_SET_RATE_PARENT;
>>> + val = SI5351_CLK_INPUT_MULTISYNTH_N;
>>> + break;
>>
>> I fugured that _si5351_clkout_reparent() wouldn't actually call
>> ->set_parent() on the clock, which leads to the fact that
>> CLK_SET_RATE_PARENT is not set in the flags. That way, only the clkout
>> end leaf is actually supplied with a new rate, which leads to incorrect
>> effective clocks, depending on the current multisynth/pll configuration.
>
> Yeah, true. Unfortunately, _clkout_reparent() is more like a dirty hack to
> allow to reparent the clock output. At registration internal configuration of
> si5351 is not known and when I parse the DT for clock configuration I might
> have been already assigned to the same parent clk that you later explicitly
> configure.
Hmm, but then we need to either set the configuration on the chip to
match the internal state of the driver, or tell the clock framework that
the current state is not currently known (don't know if that's possible).
> What I basically want for si5351 (or any other eeprom based programmable
> clock gen) is that stored configuration is not touched. But it can be changed
> after eeprom contents have been copied into device's sram - and this _is_
> mandatory for the si5351 that I use on CuBox where there is no useful config
> stored at all.
Yes, same here. We set up the si5351 from the bootloader with some
binary blob via i2c to bring some components to live before the kernel
boots.
> Anyway, there still seem to be some more issues with doing it right on current
> common clk framwork - thanks for pointing it out.
I'd be happy to test more versio
Re: [RFC PATCH RESEND v2] of/pci: Provide support for parsing PCI DT ranges property
On 03/01/2013 06:23 AM, Andrew Murray wrote:
> This patch factors out common implementations patterns to reduce overall
> kernel
> code and provide a means for host bridge drivers to directly obtain struct
> resources from the DT's ranges property without relying on architecture
> specific
> DT handling. This will make it easier to write archiecture independent host
> bridge
> drivers and mitigate against further duplication of DT parsing code.
>
> This patch can be used in the following way:
>
> struct of_pci_range_iter iter;
> for_each_of_pci_range(&iter, np) {
>
> //directly access properties of the address range, e.g.:
> //iter.pci_space, iter.pci_addr, iter.cpu_addr, iter.size or
> //iter.flags
>
> //alternatively obtain a struct resource, e.g.:
> //struct resource res;
> //range_iter_fill_resource(iter, np, res);
> }
>
> Additionally the implementation takes care of adjacent ranges and merges them
> into a single range (as was the case with powerpc and microblaze).
>
> The modifications to microblaze, mips and powerpc have not been tested.
>
> v2:
> This follows on from suggestions made by Grant Likely
> (marc.info/?l=linux-kernel&m=136079602806328)
>
> Signed-off-by: Andrew Murray
> Signed-off-by: Liviu Dudau
> ---
> arch/microblaze/pci/pci-common.c | 100 +++--
> arch/mips/pci/pci.c | 44 -
> arch/powerpc/kernel/pci-common.c | 93 ++-
> drivers/of/address.c | 54
> include/linux/of_address.h | 30 +++
> 5 files changed, 151 insertions(+), 170 deletions(-)
The thing is that this still leaves pci_process_bridge_OF_ranges
basically identical for microblaze and powerpc which is really what
needs to be moved out to common code. Obviously, struct pci_controller
vs. struct pci_sys_data on ARM is an issue, but they all have
fundamentally the same data.
All these common fields should be in a common PCI controller struct.
Perhaps introducing this with just what you need would work. Depending
how invasive moving those fields to a new struct is, you could have a
wrapper that just copies/translates the fields to the arch specific struct.
There's also things like ioremap of the i/o range. ARM uses a fixed
virtual address, so we need to do something different. Just returning
the i/o cpu_addr and moving the ioremap out of this function would solve
that.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/14] ARM: OMAP2+: Add function for configuring GPMC settings
On 02/28/2013 11:33 PM, Philip, Avinash wrote:
> On Thu, Feb 28, 2013 at 22:42:37, Hunter, Jon wrote:
>>
>> On 02/28/2013 09:52 AM, Jon Hunter wrote:
>>>
>>> On 02/28/2013 12:05 AM, Philip, Avinash wrote:
On Tue, Feb 26, 2013 at 23:00:31, Hunter, Jon wrote:
> The GPMC has various different configuration options such as bus-width,
> synchronous or asychronous mode selection, burst mode options etc.
> Currently, there is no common function for configuring these options and
> various devices set these options by either programming the GPMC CONFIG1
> register directly or by calling gpmc_cs_configure() to set some of the
> options.
>
> Add a new function for configuring all of the GPMC options. Having a
> common
> function for configuring this options will simplify code and ease the
> migration to device-tree.
>
> Signed-off-by: Jon Hunter
> ---
> arch/arm/mach-omap2/gpmc.c | 65
>
> arch/arm/mach-omap2/gpmc.h |6
> 2 files changed, 71 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 465cac9..fb8dfd2 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1137,6 +1137,71 @@ int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
> return 0;
> }
>
> +int gpmc_cs_program_settings(int cs, struct gpmc_settings *p)
> +{
> + u32 config1;
> +
> + if ((!p->device_width) || (p->device_width > GPMC_DEVWIDTH_16BIT)) {
> + pr_err("%s: invalid width %d!", __func__, p->device_width);
> + return -EINVAL;
> + }
> +
> + /* Address-data multiplexing not supported for NAND devices */
> + if (p->device_nand && p->mux_add_data) {
> + pr_err("%s: invalid configuration!\n", __func__);
> + return -EINVAL;
> + }
> +
> + /* Page/burst mode supports lengths of 4, 8 and 16 bytes */
> + if (p->burst_read || p->burst_write) {
> + switch (p->burst_len) {
> + case GPMC_BURST_4:
> + case GPMC_BURST_8:
> + case GPMC_BURST_16:
> + break;
> + default:
> + pr_err("%s: invalid page/burst-length (%d)\n",
> +__func__, p->burst_len);
> + return -EINVAL;
> + }
> + }
> +
> + if ((p->wait_on_read || p->wait_on_write) &&
> + (p->wait_pin > gpmc_nr_waitpins)) {
> + pr_err("%s: invalid wait-pin (%d)\n", __func__, p->wait_pin);
> + return -EINVAL;
> + }
> +
> + config1 = GPMC_CONFIG1_DEVICESIZE((p->device_width - 1));
Can you consider read_modify approach?
>>>
>>> I was purposely trying to avoid that. The intent here is to program all
>>> the settings and get away from any boot-loader dependencies. If we use a
>>> read-modify approach then it will never be clear in the kernel what
>>> should actually be programmed.
>>
>> By the way, it would be good to know what your motivation for this is.
>>
>> My goal is for all gpmc settings to eventually live in the DT blob and
>> there be no dependency on the bootloader whatsoever. That may mean that
>> settings are re-programmed again by the kernel but IMO that is best.
>
> Yes I understood now and the right thing to do.
> Suggested read modify approach because of some confusion as GPMC_CONFIG1 is
> already
> modified in gpmc_cs_set_timings() and is called from omap2_nand_gpmc_retime().
> So the data modified in gpmc_cs_set_timings() will lost (not significant)
> May be better and cleaner solution is to remove GPMC_CONFIG1 modification in
> gpmc_cs_set_timings() also.
Actually that is a good point. There are some timings in CONFIG1 that
are not being configured in gpmc_cs_program_settings() but
gpmc_cs_set_timings(). I had left it this way intentionally to keep
timings together, which makes sense for where gpmc clock could change at
run time. However, this means that gpmc_cs_program_settings() needs to
be called before gpmc_cs_set_timings(). Really this is no different to
how the code was before, because the code was writing directly to
CONFIG1 and now we have a function.
So the intent is for gpmc_cs_program_settings() to only be called once
for a given device and then gpmc_cs_set_timings() be called whenever the
timings need to be updated. May be I can updated the kernel-doc for
gpmc_cs_program_settings() to reflect this. Let me know if you have any
other concerns with this.
Cheers
Jon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings()
On 02/28/2013 11:40 PM, Philip, Avinash wrote:
> On Thu, Feb 28, 2013 at 21:32:01, Hunter, Jon wrote:
>>
>> On 02/28/2013 04:38 AM, Philip, Avinash wrote:
>>> On Tue, Feb 26, 2013 at 23:00:33, Hunter, Jon wrote:
Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
This moves the configuration of some GPMC options outside the
nand_gpmc_retime() because these options should only need to be set once
regardless of whether the gpmc timing is changing dynamically at runtime.
The programming of where the wait-pin is also moved slightly, but this
will not have any impact to existing devices as no boards are currently
setting the dev_ready variable.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-nand.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c
b/arch/arm/mach-omap2/gpmc-nand.c
index afc1e8c..4bdfea2 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -43,6 +43,10 @@ static struct platform_device gpmc_nand_device = {
.resource = gpmc_nand_resource,
};
+static struct gpmc_settings nand_settings = {
+ .device_nand = true,
+};
+
>>>
>>> Is it possible to make it local variable?
>>> It would help GPMC to support NAND device on multiple chip select.
>>
>> Well gpmc_nand_init() will be called for each NAND device and so I don't
>> see why this would prevent supporting multiple NANDs on multiple
>> chip-selects.
>
> Problem exactly lies here. Here platform device initialized as statically.
> So multiple requests will points to same platform device.
>
> Recently this issue raised in TI e2e forum and solution being proposed.
> Details can found from
> http://e2e.ti.com/support/arm/sitara_arm/f/791/p/246997/865379.aspx#865379
>
> I doubt the same is the case for other GPMC client devices also.
This structure is only passed to gpmc_cs_program_settings() and not
stored in the platform device structure. So I don't think that this is
the same problem. Look at what the code is doing with the nand_settings
structure.
>> Once migration to device-tree is complete we could definitely make it
>> local as there will be no need for any static initialisations of the
>> structure as all fields would be read from device-tree.
>>
>> I can make it local now if that is preferred and seeing that will be the
>> direction once we have migrated to device-tree, is does make sense.
>
> As far as I understood, here usage of local variable won't break anything?
> If that is the case, better solution would be usage of local variable.
It will not. So yes we can.
Jon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
omap: IORESOURCE_IRQ flags not set when defining a GPIO-IRQ from DT
Hi Jon,
NOTE: I'm changing $subject to something more relevant to stop adding
noise on the original thread.
On Thu, Feb 28, 2013 at 9:49 PM, Jon Hunter wrote:
>
> On 02/28/2013 06:17 AM, Javier Martinez Canillas wrote:
>> On Thu, Feb 28, 2013 at 12:16 AM, Jon Hunter wrote:
>>>
>>> On 02/26/2013 09:57 PM, Javier Martinez Canillas wrote:
>>>
>>> [snip]
>>>
Something like that would definitely solve the GPIO request issue but
we still have the issue that the current OMAP GPIO controller binding
does not support #interrupt-cells = <2>.
So, we can't pass the trigger type and level flags for an IRQ-GPIO
when using an GPIO controller as the interrupt-parent for a device
node.
Do you have any comments on that issue?
>>>
>>> Can you elaborate a bit more on why you say this is not supported?
>>>
>>> I have been playing with this today on an omap board and if I set the
>>> #interrupt-cells = <2>, then I do see that irq_domain_xlate_onetwocell()
>>> is called and the irq number and flags read as expected. Following which
>>> I then see it will call the omap_irq_type() to set type. So AFAICT it works.
>>>
>>
>> Yes, it does.
>>
>> I (wrongly) assumed that it was not working since the GPIO OMAP
>> binding documentation says that #interrupt-cells should be <2> but all
>> OMAP2+ DTs use <1> instead. Also, when trying to change to <2> I had
>> the kernel hang.
>>
>> But it was indeed that the GPIO bank was not enabled before calling
>> gpio_irq_type() and this made the kernel to hang. Your patch fixed the
>> issue and allowed me to find the cause.
>>
>> The problem was that when using the DT hack of defining the GPIO in
>> the ethernet chip regulator, the calls to
>> irq_domain_xlate_onetwocell() and gpio_irq_type() were made before the
>> call to gpio_request_one() so the GPIO bank was not enabled.
>>
>> If gpio_request() is called in gpmc_probe_dt(), then the GPIO bank is
>> enabled and gpio_irq_type() succeeds.
>>
>> So, it was just me being stupid and don't understanding the implementation.
>
> No problem. Glad we are on the same page :-)
>
>>> Please note I do see that when the SMC driver calls request_irq() in
>>> smc_drv_probe() it is also settings the trigger type to
>>> IRQ_TYPE_EDGE_RISING (default). So if you are setting to low-level
>>> sensitive in DT, then this is being overwritten. We could fix this by
>>> setting SMC_IRQ_FLAGS to -1 for OMAP.
>>>
>>
>> Please note that I'm using a SMSC 911x chip and not a SMSC 91x, so the
>> driver is not smc91x but smc911x. It has the same behaviour though
>> (IRQ flags overwritten somehow), just to be sure that we are on the
>> same page.
>>
>> I don't know if just setting SMC_IRQ_FLAGS to -1 will be enough to fix
>> the smc91x since request_irq() is just passing whatever value is in
>> irq_flags.
>>
>> By looking at the two drivers (smc91x and smsc911x) it seems that the
>> only difference on how they manage the flags is that smc91x does:
>>
>> unsigned long irq_flags = SMC_IRQ_FLAGS;
>> ...
>>if (irq_flags == -1 || ires->flags & IRQF_TRIGGER_MASK)
>> irq_flags = ires->flags & IRQF_TRIGGER_MASK;
>>
>> while smsc911x driver's probe function uses the flags from the
>> resource unconditionally:
>>
>> irq_flags = irq_res->flags & IRQF_TRIGGER_MASK;
>>
>> So, at the end both will set irq_flags to whatever is on the
>> IORESOURCE_IRQ struct resource flags member.
>
> Actually, that's not the case for smc91x. By default SMC_IRQ_FLAGS != -1
> (for omap) and so it will not set irq_flags to ires->flags &
> IRQF_TRIGGER_MASK. However, if I force irq_flags to be -1, then I see
> that irq_flags are to 0.
>
Yes, I meant that the behaviour is the same if you define
SMC_IRQ_FLAGS to -1 for omap.
>> The real problem is irq_flags to be 0 instead of the value defined on
>> the second cell of the "interrupts" property.
>
> So the resource flags for each irq is set in
> of_irq_to_resource() which just does ...
>
> r->start = r->end = irq;
> r->flags = IORESOURCE_IRQ;
> r->name = name ? name : dev->full_name;
>
>
> of_irq_to_resource() calls irq_to_parse_and_map() which eventually just
> calls irq_set_irq_type() but type/flags is not returned and not populated.
>
> I am wondering if this is intentional.
Indeed, I was wondering the same.
>The irq_type is being correctly
> configured by irq_set_irq_type() when of_irq_to_resource() is called. In
> the smc driver, if irq_flags are 0, then when request_irq() is called
> the trigger type will not be set again (which is ok). __setup_irq has
> the following ...
>
> /* Setup the type (level, edge polarity) if configured: */
> if (new->flags & IRQF_TRIGGER_MASK) {
> ret = __irq_set_trigger(desc, irq,
> new->flags & IRQF_TRIGGER_MASK);
>
> Cheers
> Jon
I'll try to take a deeper look to this later next week.
Thanks a lot for your help!
Regards,
Javier
_
Re: omap: IORESOURCE_IRQ flags not set when defining a GPIO-IRQ from DT
On Fri, Mar 01, 2013 at 05:17:57PM +0100, Javier Martinez Canillas wrote: > >> unsigned long irq_flags = SMC_IRQ_FLAGS; > >> ... > >>if (irq_flags == -1 || ires->flags & IRQF_TRIGGER_MASK) > >> irq_flags = ires->flags & IRQF_TRIGGER_MASK; > >> > >> while smsc911x driver's probe function uses the flags from the > >> resource unconditionally: > >> > >> irq_flags = irq_res->flags & IRQF_TRIGGER_MASK; > >> > >> So, at the end both will set irq_flags to whatever is on the > >> IORESOURCE_IRQ struct resource flags member. > > > > Actually, that's not the case for smc91x. By default SMC_IRQ_FLAGS != -1 > > (for omap) and so it will not set irq_flags to ires->flags & > > IRQF_TRIGGER_MASK. However, if I force irq_flags to be -1, then I see > > that irq_flags are to 0. smc91x is complicated by the fact that it started off life before there was any possibility to pass IRQ flags through resources. So we ended up with smc91x.h containing _lots_ of platform specific data, and the driver could only be built for one platform. I fixed that by sorting out this IRQ passing method, and changing smc91x to support both the fixed configuration, and the dynamic-through-IRQflags method. There is no reason for any other driver to support the fixed method; that would be a completely backwards step. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: I2C and devicetrees
Hi, On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto wrote: > Hi everyone, > > I have a similar question. > I'd like to "name" i2c devices so that a userspace application can somehow > identify those devices with the same function across different boards (which > may have different addresses or be connected to a different i2c bus, or be a > physically different chip). > > For instance "hwmon" devices get instantiated within sysfs under > /sys/class/hwmon/hwmonX > > # cat /sys/class/hwmon/hwmon0/device/name > lm75 > > which I would like to be identified by the name "switch" (as in "switch > temperature"). I was thinking about instantiating it as something like > "lm75:switch" within i2c_board_info.type. For device-tree-less > architectures, a trivial change within i2c_match_id() so to ignore the part > following ":" seems to do the trick. Don't know about devicetree but I guess > a similar approach could be imagined. > > Another example would be given by EEPROMs: all boards are equipped with an > EEPROM containing inventory management, which I would like to identify as > "ivm". So something like "24c08:ivm". > After all, I'd like to be able to achive something like "named MTD > partitions" which you can identify by looking at "/proc/mtd". > > Maybe some other symbol could be used instead of ":", but anyhow, does the > above make any sense at all to you? > I have exactly the same request: I would like to put logical names in the device tree for various devices (i2c, spi, ...) which are in some way easily retrievable from a userspace application. The purpose seems to be the same as Gerlando's: different boards have different physical configuration but logically each has the same set of devices. How can one achieve that? Thanks, Thomas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/8] reset: Add reset controller API
On 02/26/2013 04:39 AM, Philipp Zabel wrote:
> This adds a simple API for devices to request being reset
> by separate reset controller hardware and implements the
> reset signal device tree binding.
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> +int of_reset_simple_xlate(struct reset_controller_dev *rcdev,
> + const struct of_phandle_args *reset_spec, u32 *flags)
> +{
> + if (WARN_ON(reset_spec->args_count < rcdev->of_reset_n_cells))
> + return -EINVAL;
Would != make more sense than < ?
> +
> + if (reset_spec->args[0] >= rcdev->nr_resets)
> + return -EINVAL;
> +
> + if (flags)
> + *flags = reset_spec->args[1];
if (flags)
if (reset_spec->args_count > 1)
*flags = reset_spec->args[1];
else
*flags = 0;
?
> +struct reset_control *reset_control_get(struct device *dev, const char *id)
...
> + mutex_lock(&reset_controller_list_mutex);
> + rcdev = NULL;
> + list_for_each_entry(r, &reset_controller_list, list) {
> + if (args.np == r->of_node) {
> + rcdev = r;
> + break;
> + }
> + }
> + mutex_unlock(&reset_controller_list_mutex);
At this point, rcdev could be removed from that list, and perhaps even
start to point at free'd memory.
> + of_node_put(args.np);
> +
> + if (!rcdev)
> + return ERR_PTR(-ENODEV);
> +
> + rstc_id = rcdev->of_xlate(rcdev, &args, NULL);
> + if (rstc_id < 0)
> + return ERR_PTR(rstc_id);
> +
> + try_module_get(rcdev->owner);
What about error-handling here?
I think you want to drop reset_controller_list_mutex only after the call
to try_module_get()?
> +static int devm_reset_control_match(struct device *dev, void *res, void
> *data)
> +{
> + struct reset_control **rstc = res;
> + if (!rstc || !*rstc) {
> + WARN_ON(!rstc || !*rstc);
I think you can if (WARN_ON(...)).
I'm not sure if the error-checks are quite right though;
reset_control_get always returns an error-pointer for errors, never
NULL, so the pointer can't ever be NULL. If it somehow was (e.g. client
usage error), then that NULL pointer would never match anything, so the
error-check still wouldn't be useful.
I'm not sure why this is a ** here; below in devm_reset_control_put()
you pass a just a *; are you expected to pass &rstc there instead?
> +void devm_reset_control_put(struct reset_control *rstc)
> +{
> + int ret;
> +
> + ret = devres_release(rstc->dev, devm_reset_control_release,
> + devm_reset_control_match, rstc);
> + if (ret)
> + WARN_ON(ret);
> +}
> +EXPORT_SYMBOL_GPL(devm_reset_control_put);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 3/8] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to System Reset Controller (SRC)
On 02/26/2013 04:39 AM, Philipp Zabel wrote:
> The SRC has auto-deasserting reset bits that control reset lines to
> the GPU, VPU, IPU, and OpenVG IP modules. This patch adds a reset
> controller that can be controlled by those devices using the
> reset controller API.
> diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
> b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
> +Specifying reset lines connected to IP modules
> +==
...
> +example:
> +
> +ipu1: ipu@0240 {
> +resets = <&src 2>;
> +};
> +ipu2: ipu@0280 {
> +resets = <&src 4>;
> +};
reset-names is mandatory in the documentation and implementation; you
should probably add them to the example too.
Nit: You could use BIT(x) instead of 1 << x in a few places in this
file. But not a big deal.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 3/8] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to System Reset Controller (SRC)
On 03/01/2013 01:05 PM, Stephen Warren wrote:
> On 02/26/2013 04:39 AM, Philipp Zabel wrote:
>> The SRC has auto-deasserting reset bits that control reset lines to
>> the GPU, VPU, IPU, and OpenVG IP modules. This patch adds a reset
>> controller that can be controlled by those devices using the
>> reset controller API.
>
>> diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
>> b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
>
>> +Specifying reset lines connected to IP modules
>> +==
> ...
>> +example:
>> +
>> +ipu1: ipu@0240 {
>> +resets = <&src 2>;
>> +};
>> +ipu2: ipu@0280 {
>> +resets = <&src 4>;
>> +};
>
> reset-names is mandatory in the documentation and implementation; you
> should probably add them to the example too.
Oh, looking at the code further, I see reset-names is optional if the
client node only has one reset defined. So ignore my comment above.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 12/14] ARM: OMAP2+: Add additional GPMC timing parameters
Hi Jon, On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote: [...] > > + if (!of_property_read_u32(np, "gpmc,bus-turnaround", &val)) > + gpmc_t->bus_turnaround = val; > + AFAIK, you don't need to test if the property is defined. You can just read it straightforward, and if the property is not defined then nothing will be stored in your variable: of_property_read_u32(np, "gpmc,bus-turnaround", &gpmc_t->bus_turnaround); You can simplify *a lot* your patch with this, and I believe you could also clean existent code. -- Ezequiel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 12/14] ARM: OMAP2+: Add additional GPMC timing parameters
On Fri, Mar 1, 2013 at 5:11 PM, Ezequiel Garcia wrote: > Hi Jon, > > On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote: > [...] >> >> + if (!of_property_read_u32(np, "gpmc,bus-turnaround", &val)) >> + gpmc_t->bus_turnaround = val; >> + > > AFAIK, you don't need to test if the property is defined. > You can just read it straightforward, and if the property is not defined > then nothing will be stored in your variable: > > of_property_read_u32(np, "gpmc,bus-turnaround", &gpmc_t->bus_turnaround); > > You can simplify *a lot* your patch with this, and I believe you could > also clean > existent code. > Also, since this is somewhat large patchset: would you mind pushing it somewhere so I can just pull a branch? Thanks, -- Ezequiel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 8/8] reset: Add driver for gpio-controlled reset pins
On 02/26/2013 04:39 AM, Philipp Zabel wrote: > This driver implements a reset controller device that toggles gpios > connected to reset pins of peripheral ICs. The delay between assertion > and de-assertion of the reset signal can be configured. Reviewed-by: Stephen Warren ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm/dts: Add basic support for gta04 (Openmoko next generation) board.
Ping. Any objections to that patch?
On Thu, Jan 24, 2013 at 7:34 PM, Marek Belisko
wrote:
> Signed-off-by: Marek Belisko
> ---
> arch/arm/boot/dts/omap3-gta04.dts | 94
> +
> 1 file changed, 94 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap3-gta04.dts
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dts
> b/arch/arm/boot/dts/omap3-gta04.dts
> new file mode 100644
> index 000..9e7e3ec
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-gta04.dts
> @@ -0,0 +1,94 @@
> +/*
> + * Copyright (C) 2013 Marek Belisko
> + *
> + * Based on omap3-beagle-xm.dts
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/dts-v1/;
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + model = "OMAP3 GTA04";
> + compatible = "ti,omap3-gta04", "ti,omap3";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB */
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + aux-button {
> + label = "AUX";
> + linux,code = <169>;
> + gpios = <&gpio1 7 1>;
> + gpio-key,wakeup;
> + };
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <260>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <&intc>;
> + };
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +&i2c2 {
> + clock-frequency = <40>;
> + /* Pressure Sensor */
> + bmp085@77 {
> + compatible = "bosch,bmp085";
> + reg = <0x77>;
> + };
> +
> + /* leds */
> + tca6507@45 {
> + compatible = "ti,tca6507";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x45>;
> +
> + gta04_led0: red_aux@0 {
> + label = "gta04:red:aux";
> + reg = <0x0>;
> + };
> +
> + gta04_led1: green_aux@1 {
> + label = "gta04:green:aux";
> + reg = <0x1>;
> + };
> +
> + gta04_led3: red_power@3 {
> + label = "gta04:red:power";
> + reg = <0x3>;
> + linux,default-trigger = "default-on";
> + };
> +
> + gta04_led4: green_power@4 {
> + label = "gta04:green:power";
> + reg = <0x4>;
> + };
> + };
> +};
> +
> +&i2c3 {
> + clock-frequency = <10>;
> +};
> +
> +&mmc1 {
> + vmmc-supply = <&vmmc1>;
> + bus-width = <4>;
> +};
> +
> --
> 1.7.10.4
>
Regards,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5 v7][RFC] ASoC: add snd_soc_register_cpu()
On 02/28/2013 08:14 PM, Stephen Warren wrote: > On 02/27/2013 05:42 PM, Kuninori Morimoto wrote: >> >> Hi Stephen >> >>> On 02/25/2013 01:51 AM, Kuninori Morimoto wrote: Current ASoC has register function for platform/codec/dai/card, but doesn't have for cpu. It often produces confusion and fault on ASoC. This patch adds very basic register function for cpu >>> >>> This seems reasonable to me. >>> >>> I can't recall how much influence the existing CODEC objects have on the >>> various routing/matching decisions inside the ASoC core. While this >>> patch does register and unregister CPU objects, I wonder if it should >>> have more impact on any of the existing core code? Certainly I'd expect >>> the CPU objects to show up in ASoC's debugfs and any similar files... >> >> This patch doesn't have any impact to existing drivers. >> It just added new cpu list. > > Sure. My point was that now you've added the list, perhaps the core ASoC > code might want to make use of it in the same way it makes use of CODEC > objects, since it's logically equivalent. In my opinion it makes sense to get rid of the distinction between CPU objects and CODEC objects in this case and instead introduce some kind of DAI container object. I mean the distinction is mostly for historic reasons from a time where it was only possible to bind a the cpu_dai of a link to a CPU DAI and the codec_dai to a CODEC DAI. But these dais both can for example be bound CODEC DAIs. I think to have a common base here would allow us to do some cleanups to the ASoC core and also avoid the duplication with snd_soc_of_get_cpu_dai_name and snd_soc_of_get_codec_dai_name which was introduced in this series. - Lars ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
Hi Jon,
On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote:
[...]
> +static int gpmc_probe_nor_child(struct platform_device *pdev,
> + struct device_node *child)
> +{
> + struct gpmc_settings gpmc_s;
> + struct gpmc_timings gpmc_t;
> + struct resource res;
> + unsigned long base;
> + int ret, cs;
> +
> + if (of_property_read_u32(child, "reg", &cs) < 0) {
> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
> + child->full_name);
> + return -ENODEV;
> + }
> +
> + if (of_address_to_resource(child, 0, &res)) {
> + dev_err(&pdev->dev, "%s has malformed 'reg' property\n",
> + child->full_name);
> + return -ENODEV;
> + }
> +
> + ret = gpmc_cs_request(cs, res.end - res.start, &base);
How about using resource_size() above?
BTW, I believe it's size = end - start + 1.
--
Ezequiel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: I2C and devicetrees
On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote: > Hi, > > On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto > wrote: >> Hi everyone, >> >> I have a similar question. >> I'd like to "name" i2c devices so that a userspace application can somehow >> identify those devices with the same function across different boards (which >> may have different addresses or be connected to a different i2c bus, or be a >> physically different chip). >> >> For instance "hwmon" devices get instantiated within sysfs under >> /sys/class/hwmon/hwmonX >> >> # cat /sys/class/hwmon/hwmon0/device/name >> lm75 >> >> which I would like to be identified by the name "switch" (as in "switch >> temperature"). I was thinking about instantiating it as something like >> "lm75:switch" within i2c_board_info.type. For device-tree-less >> architectures, a trivial change within i2c_match_id() so to ignore the part >> following ":" seems to do the trick. Don't know about devicetree but I guess >> a similar approach could be imagined. >> >> Another example would be given by EEPROMs: all boards are equipped with an >> EEPROM containing inventory management, which I would like to identify as >> "ivm". So something like "24c08:ivm". >> After all, I'd like to be able to achive something like "named MTD >> partitions" which you can identify by looking at "/proc/mtd". >> >> Maybe some other symbol could be used instead of ":", but anyhow, does the >> above make any sense at all to you? >> > > I have exactly the same request: I would like to put logical names in > the device tree for various devices (i2c, spi, ...) which are in some > way easily retrievable from a userspace application. > The purpose seems to be the same as Gerlando's: different boards have > different physical configuration but logically each has the same set > of devices. > > How can one achieve that? Unless I am misunderstanding your request, that is what the /aliases node is intended for. Each property name in /aliases is a logical name, and the value refers to the corresponding device node. I'm not sure about all the different ways that Linux exports information in /aliases to userspace. I do know that, in the case of some i2c, serial, and ethernet devices, aliases like: serial1 = &uart1; cause the assignment of small-integer unit numbers to specific device instances. That "serial" pattern is somewhat of a Linux-specific special case. In general, the Open Firmware standard just says that /aliases maps logical names to longer strings representing fuller pathnames, without imposing any structure (e.g. serial) on the logical names. > > Thanks, > Thomas > ___ > 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
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/01/2013 03:25 PM, Ezequiel Garcia wrote:
> Hi Jon,
>
> On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote:
> [...]
>> +static int gpmc_probe_nor_child(struct platform_device *pdev,
>> + struct device_node *child)
>> +{
>> + struct gpmc_settings gpmc_s;
>> + struct gpmc_timings gpmc_t;
>> + struct resource res;
>> + unsigned long base;
>> + int ret, cs;
>> +
>> + if (of_property_read_u32(child, "reg", &cs) < 0) {
>> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
>> + child->full_name);
>> + return -ENODEV;
>> + }
>> +
>> + if (of_address_to_resource(child, 0, &res)) {
>> + dev_err(&pdev->dev, "%s has malformed 'reg' property\n",
>> + child->full_name);
>> + return -ENODEV;
>> + }
>> +
>> + ret = gpmc_cs_request(cs, res.end - res.start, &base);
>
> How about using resource_size() above?
>
> BTW, I believe it's size = end - start + 1.
Thanks, yes I can update.
Cheers
Jon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 12/14] ARM: OMAP2+: Add additional GPMC timing parameters
On 03/01/2013 02:11 PM, Ezequiel Garcia wrote: > Hi Jon, > > On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote: > [...] >> >> + if (!of_property_read_u32(np, "gpmc,bus-turnaround", &val)) >> + gpmc_t->bus_turnaround = val; >> + > > AFAIK, you don't need to test if the property is defined. > You can just read it straightforward, and if the property is not defined > then nothing will be stored in your variable: > > of_property_read_u32(np, "gpmc,bus-turnaround", &gpmc_t->bus_turnaround); > > You can simplify *a lot* your patch with this, and I believe you could > also clean > existent code. True. I was just being consistent with the existing code in gpmc_read_timings_dt(). May be I can clean-up the entire function. Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 12/14] ARM: OMAP2+: Add additional GPMC timing parameters
On 03/01/2013 02:12 PM, Ezequiel Garcia wrote: > On Fri, Mar 1, 2013 at 5:11 PM, Ezequiel Garcia wrote: >> Hi Jon, >> >> On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote: >> [...] >>> >>> + if (!of_property_read_u32(np, "gpmc,bus-turnaround", &val)) >>> + gpmc_t->bus_turnaround = val; >>> + >> >> AFAIK, you don't need to test if the property is defined. >> You can just read it straightforward, and if the property is not defined >> then nothing will be stored in your variable: >> >> of_property_read_u32(np, "gpmc,bus-turnaround", &gpmc_t->bus_turnaround); >> >> You can simplify *a lot* your patch with this, and I believe you could >> also clean >> existent code. >> > > Also, since this is somewhat large patchset: would you mind pushing it > somewhere > so I can just pull a branch? See link in cover-letter ;-) Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: omap: IORESOURCE_IRQ flags not set when defining a GPIO-IRQ from DT
On 03/01/2013 11:30 AM, Russell King - ARM Linux wrote: > On Fri, Mar 01, 2013 at 05:17:57PM +0100, Javier Martinez Canillas wrote: unsigned long irq_flags = SMC_IRQ_FLAGS; ... if (irq_flags == -1 || ires->flags & IRQF_TRIGGER_MASK) irq_flags = ires->flags & IRQF_TRIGGER_MASK; while smsc911x driver's probe function uses the flags from the resource unconditionally: irq_flags = irq_res->flags & IRQF_TRIGGER_MASK; So, at the end both will set irq_flags to whatever is on the IORESOURCE_IRQ struct resource flags member. >>> >>> Actually, that's not the case for smc91x. By default SMC_IRQ_FLAGS != -1 >>> (for omap) and so it will not set irq_flags to ires->flags & >>> IRQF_TRIGGER_MASK. However, if I force irq_flags to be -1, then I see >>> that irq_flags are to 0. > > smc91x is complicated by the fact that it started off life before there > was any possibility to pass IRQ flags through resources. So we ended > up with smc91x.h containing _lots_ of platform specific data, and the > driver could only be built for one platform. > > I fixed that by sorting out this IRQ passing method, and changing smc91x > to support both the fixed configuration, and the dynamic-through-IRQflags > method. > > There is no reason for any other driver to support the fixed method; that > would be a completely backwards step. Thanks for the history. For OMAP I see SMC_IRQ_FLAGS getting defined as follows in smc91x.h ... #ifndef SMC_IRQ_FLAGS #define SMC_IRQ_FLAGS IRQF_TRIGGER_RISING #endif And so for OMAP devices using smc91x, it is always being configured as rising-edge. So it would be good to move OMAP to use a dynamic configuration too. Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: I2C and devicetrees
On 03/01/2013 02:47 PM, Mitch Bradley wrote:
> On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote:
>> Hi,
>>
>> On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
>> wrote:
>>> Hi everyone,
>>>
>>> I have a similar question.
>>> I'd like to "name" i2c devices so that a userspace application can somehow
>>> identify those devices with the same function across different boards (which
>>> may have different addresses or be connected to a different i2c bus, or be a
>>> physically different chip).
>>>
>>> For instance "hwmon" devices get instantiated within sysfs under
>>> /sys/class/hwmon/hwmonX
>>>
>>> # cat /sys/class/hwmon/hwmon0/device/name
>>> lm75
>>>
>>> which I would like to be identified by the name "switch" (as in "switch
>>> temperature"). I was thinking about instantiating it as something like
>>> "lm75:switch" within i2c_board_info.type. For device-tree-less
>>> architectures, a trivial change within i2c_match_id() so to ignore the part
>>> following ":" seems to do the trick. Don't know about devicetree but I guess
>>> a similar approach could be imagined.
>>>
>>> Another example would be given by EEPROMs: all boards are equipped with an
>>> EEPROM containing inventory management, which I would like to identify as
>>> "ivm". So something like "24c08:ivm".
>>> After all, I'd like to be able to achive something like "named MTD
>>> partitions" which you can identify by looking at "/proc/mtd".
>>>
>>> Maybe some other symbol could be used instead of ":", but anyhow, does the
>>> above make any sense at all to you?
>>>
>>
>> I have exactly the same request: I would like to put logical names in
>> the device tree for various devices (i2c, spi, ...) which are in some
>> way easily retrievable from a userspace application.
>> The purpose seems to be the same as Gerlando's: different boards have
>> different physical configuration but logically each has the same set
>> of devices.
>>
>> How can one achieve that?
>
> Unless I am misunderstanding your request, that is what the /aliases
> node is intended for. Each property name in /aliases is a logical name,
> and the value refers to the corresponding device node.
>
> I'm not sure about all the different ways that Linux exports information
> in /aliases to userspace. I do know that, in the case of some i2c,
> serial, and ethernet devices, aliases like:
>
> serial1 = &uart1;
>
> cause the assignment of small-integer unit numbers to specific device
> instances. That "serial" pattern is somewhat of a Linux-specific
> special case. In general, the Open Firmware standard just says that
> /aliases maps logical names to longer strings representing fuller
> pathnames, without imposing any structure (e.g. serial) on the
> logical names.
I'm not sure if aliases solve all scenarios.
If you have a DT node that's a single UART, then aliases work OK, as in
your example above.
However, what if you have a single thermal sensor ID that has 4
channels. There will be a single DT node that represents this device.
However, the 4 channels could be hooked up arbitrarily on a board, and
you really want to name the individual channels, not just the IC that
contains those channels. Can you do that; will the following work?
/aliases {
cpu-temp = <&i2cdev 1>; # 1 is the channel ID on the chip
ambient-temp = <&i2cdev 3>;
};
All the code I recall so far that handles aliases searches for alias
entries with a specific prefix for the name (e.g. "i2c*", and then finds
"i2c0", "i2c1", etc.). In order to support the syntax above, you'd have
to instead search for all aliases that include the phandle of the node
in question. I guess it's easy enough to implement that, but it's quite
a different way of thinking about aliases, I think.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: omap: IORESOURCE_IRQ flags not set when defining a GPIO-IRQ from DT
On Fri, Mar 01, 2013 at 04:41:37PM -0600, Jon Hunter wrote: > Thanks for the history. For OMAP I see SMC_IRQ_FLAGS getting defined as > follows in smc91x.h ... > > #ifndef SMC_IRQ_FLAGS > #define SMC_IRQ_FLAGS IRQF_TRIGGER_RISING > #endif > > And so for OMAP devices using smc91x, it is always being configured as > rising-edge. So it would be good to move OMAP to use a dynamic > configuration too. Yep. I think that was requested back when I did the work from those which remained... ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: I2C and devicetrees
On 3/1/2013 1:17 PM, Stephen Warren wrote:
> On 03/01/2013 02:47 PM, Mitch Bradley wrote:
>> On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote:
>>> Hi,
>>>
>>> On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
>>> wrote:
Hi everyone,
I have a similar question.
I'd like to "name" i2c devices so that a userspace application can somehow
identify those devices with the same function across different boards
(which
may have different addresses or be connected to a different i2c bus, or be
a
physically different chip).
For instance "hwmon" devices get instantiated within sysfs under
/sys/class/hwmon/hwmonX
# cat /sys/class/hwmon/hwmon0/device/name
lm75
which I would like to be identified by the name "switch" (as in "switch
temperature"). I was thinking about instantiating it as something like
"lm75:switch" within i2c_board_info.type. For device-tree-less
architectures, a trivial change within i2c_match_id() so to ignore the part
following ":" seems to do the trick. Don't know about devicetree but I
guess
a similar approach could be imagined.
Another example would be given by EEPROMs: all boards are equipped with an
EEPROM containing inventory management, which I would like to identify as
"ivm". So something like "24c08:ivm".
After all, I'd like to be able to achive something like "named MTD
partitions" which you can identify by looking at "/proc/mtd".
Maybe some other symbol could be used instead of ":", but anyhow, does the
above make any sense at all to you?
>>>
>>> I have exactly the same request: I would like to put logical names in
>>> the device tree for various devices (i2c, spi, ...) which are in some
>>> way easily retrievable from a userspace application.
>>> The purpose seems to be the same as Gerlando's: different boards have
>>> different physical configuration but logically each has the same set
>>> of devices.
>>>
>>> How can one achieve that?
>>
>> Unless I am misunderstanding your request, that is what the /aliases
>> node is intended for. Each property name in /aliases is a logical name,
>> and the value refers to the corresponding device node.
>>
>> I'm not sure about all the different ways that Linux exports information
>> in /aliases to userspace. I do know that, in the case of some i2c,
>> serial, and ethernet devices, aliases like:
>>
>> serial1 = &uart1;
>>
>> cause the assignment of small-integer unit numbers to specific device
>> instances. That "serial" pattern is somewhat of a Linux-specific
>> special case. In general, the Open Firmware standard just says that
>> /aliases maps logical names to longer strings representing fuller
>> pathnames, without imposing any structure (e.g. serial) on the
>> logical names.
>
> I'm not sure if aliases solve all scenarios.
>
> If you have a DT node that's a single UART, then aliases work OK, as in
> your example above.
>
> However, what if you have a single thermal sensor ID that has 4
> channels. There will be a single DT node that represents this device.
> However, the 4 channels could be hooked up arbitrarily on a board, and
> you really want to name the individual channels, not just the IC that
> contains those channels. Can you do that; will the following work?
>
> /aliases {
> cpu-temp = <&i2cdev 1>; # 1 is the channel ID on the chip
> ambient-temp = <&i2cdev 3>;
> };
For that case, I would put child nodes underneath the 4-channel-sensor
node, e.g. cpu-temp@1, ambient-temp@3. Those multiple channels fit
cleanly within the device tree's "child address space" concept.
I suppose that the driver for the sensor node would enumerate its
children and export their information via /sys.
I know that it's tempting to truncate the device tree too soon, as I
have fallen prey to that temptation many times. For me, the temptation
usually happens for "endpoints" that don't need separate drivers, or for
which the endpoint-driver code is "buried" inside the parent driver.
But in the end, it has usually worked out better to fill out the leaves
of the tree, especially for on-board devices.
>
> All the code I recall so far that handles aliases searches for alias
> entries with a specific prefix for the name (e.g. "i2c*", and then finds
> "i2c0", "i2c1", etc.). In order to support the syntax above, you'd have
> to instead search for all aliases that include the phandle of the node
> in question. I guess it's easy enough to implement that, but it's quite
> a different way of thinking about aliases, I think.
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm: dts: Add uart1 and uart2 to igep boards.
On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit wrote:
> Hi Matthias,
>
>
> On 2/15/2013 10:35 AM, Matthias Brugger wrote:
>>
>> 2013/1/26 Javier Martinez Canillas :
>>>
>>> On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
>>>
>>> wrote:
Hi Benoit,
2012/12/12 Benoit Cousson :
>
> Hi Matthias,
>
> On 12/12/2012 04:33 PM, Matthias Brugger wrote:
>>
>> This patch is a follow-up patch for Javier Martinez effort adding
>> initial
>> device tree support to IGEP technology devices. [1]
>>
>> It adds uart1 and uart2 bindings to the generic dtsi for the IGEP
>> boards.
>>
>> [1] http://www.spinics.net/lists/linux-omap/msg83409.html
>>
>> Signed-off-by: Matthias Brugger
>> ---
>> arch/arm/boot/dts/omap3-igep.dtsi | 24
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
>> b/arch/arm/boot/dts/omap3-igep.dtsi
>> index 125fe00..c02e3c0 100644
>> --- a/arch/arm/boot/dts/omap3-igep.dtsi
>> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
>> @@ -27,6 +27,20 @@
>> };
>>
>> &omap3_pmx_core {
>> + uart1_pins: pinmux_uart1_pins {
>> + pinctrl-single,pins = <
>> + 0x152 0x100 /* uart1_rx.uart1_rx INPUT |
>> MODE0
>> */
>> + 0x14c 0 /* uart1_tx.uart1_tx OUTPUT |
>> MODE0 */
>> + >;
>> + };
>> +
>> + uart2_pins: pinmux_uart2_pins {
>> + pinctrl-single,pins = <
>> + 0x14a 0x100 /* uart2_rx.uart2_rx INPUT |
>> MODE0
>> */
>> + 0x148 0 /* uart2_tx.uart2_tx OUTPUT |
>> MODE0 */
>> + >;
>> + };
>> +
>>uart3_pins: pinmux_uart3_pins {
>>pinctrl-single,pins = <
>>0x16e 0x100 /* uart3_rx.uart3_rx INPUT |
>> MODE0
>> */
>> @@ -77,6 +91,16 @@
>>status = "disabled";
>> };
>>
>> +&uart1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart1_pins>;
>> +};
>> +
>> +&uart2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart2_pins>;
>> +};
>> +
>> &uart3 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&uart3_pins>;
>>
>
> That looks good to me. I'll apply it on top of javier's series for 3.9.
Can you pin-point me to the repository where this patches are in right
now? I tried to figure it out these days, but didn't found where to
clone the repository from.
Thanks,
Matthias
>>>
>>> Hi Matthias,
>>>
>>> OMAP DT tree is:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
>>
>>
>> Hi all,
>>
>> unfortunately I can't find the patch in this tree.
>
>
> Sorry about that. I've never pushed the latest branch, and was busy the past
> month. I'll refresh the branch with all the pending patches.
>
> Regards,
> Benoit
>
Hi Benoit,
I realized that your for_3.9/dts branch has not landed in mainline yet
and we are near to the end of the merge window.
Are you still planing to include those changes for 3.9 or are you
going to wait until the next release?
Thanks a lot and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [alsa-devel] [PATCH 1/5 v7][RFC] ASoC: add snd_soc_register_cpu()
On Fri, Mar 01, 2013 at 09:42:10PM +, Liam Girdwood wrote: > On Fri, 2013-03-01 at 21:50 +0100, Lars-Peter Clausen wrote: > > object. I mean the distinction is mostly for historic reasons from a time > > where > > it was only possible to bind a the cpu_dai of a link to a CPU DAI and the > > codec_dai to a CODEC DAI. But these dais both can for example be bound CODEC > > DAIs. I think to have a common base here would allow us to do some cleanups > > to > > the ASoC core and also avoid the duplication with > > snd_soc_of_get_cpu_dai_name > > and snd_soc_of_get_codec_dai_name which was introduced in this series. > I've been thinking about this distinction for some time too (since > multi-component support). You are right, the division with CODEC and CPU > DAIs is entirely historical. The same logic also applies to platform and > codec drivers too. The DAIs are now the same of course, it's just the containing object that differs. Platform drivers are a bit different to CODEC drivers for me though in that they encapsulate the DMA equivalent of a DAI - I can see a SoC having multiple platform drivers if it's got a couple of different DMA controllers for example (I've seen some which have a fancier one on faster buses for example). > This does need some mechanical cleanup where we have a generic audio > component driver object that contains generic DAIs. i.e. codec and > platform drivers would become generic component drivers with generic > DAIs. There's also the perennial questions about code churn and if it's worth it of course. Should we be adding a chip driver type rather than a CPU one here and then going through and doing the work to make sure that you can use a chip driver wherever you use a CODEC driver so we can start converting things over? signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] documentation: add palmas dts definition
On Wed, Feb 27, 2013 at 11:16:57AM -0700, Stephen Warren wrote: > I believe what Mark wants is something like the following in this file > (take from Documentation/devicetree/bindings/regulator/tps6586x.txt): > > - regulators: A node that houses a sub-node for each regulator within the > > device. Each sub-node is identified using the node's name (or the > > deprecated > > regulator-compatible property if present), with valid values listed below. > > The content of each sub-node is defined by the standard binding for > > regulators; see regulator.txt. > > sys, sm[0-2], ldo[0-9] and ldo_rtc Yes, exactly. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] mfd: as3711: add OF support
On Mon, Feb 18, 2013 at 10:57:44AM +0100, Guennadi Liakhovetski wrote: > Add device-tree bindings to the AS3711 regulator and backlight drivers. Reviwed-by: Mark Brown signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
