Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D
On 6 February 2013 13:02, Inki Dae inki@samsung.com wrote: Looks good to me but please add document for it. Yes. I will. I was planning to send the bindings document patch along with the dt patches (adding node entries to dts files). Sylwester had suggested adding this to Documentation/devicetree/bindings/media/ which contains other media IPs. To other guys, And is there anyone who know where this document should be added to? I'm not sure that the g2d document should be placed in Documentation/devicetree/bindings/gpu, media, drm/exynos or arm/exynos. At least, this document should be shared with the g2d hw relevant drivers such as v4l2 and drm. So is .../bindings/gpu proper place? -- With warm regards, Sachin ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RESEND] media: rc: gpio-ir-recv: add support for device tree parsing
This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but optional properties allow linux specific support for rc
protocols and maps.
There was a similar patch sent by Matus Ujhelyi but that discussion
died after the first reviews.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Benoit Thebaudeau benoit.thebaud...@advansee.com
Cc: David Hardeman da...@hardeman.nu
Cc: Trilok Soni ts...@codeaurora.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
.../devicetree/bindings/media/gpio-ir-receiver.txt | 20 ++
drivers/media/rc/gpio-ir-recv.c| 68 +++-
2 files changed, 86 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 000..937760c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+ - compatible = gpio-ir-receiver;
+ - gpios: OF device-tree gpio specification.
+
+Optional properties:
+ - linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
+ rc protocols.
+ - linux,rc-map-name: Linux specific remote control map name.
+
+Example node:
+
+ ir: ir-receiver {
+ compatible = gpio-ir-receiver;
+ gpios = gpio0 19 1;
+ /* allow rc protocols 1-4 */
+ linux,allowed-rc-protocols = 0x 0x001e;
+ linux,rc-map-name = rc-rc6-mce;
+ };
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 4f71a7d..25e09fa 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -16,6 +16,7 @@
#include linux/interrupt.h
#include linux/gpio.h
#include linux/slab.h
+#include linux/of_gpio.h
#include linux/platform_device.h
#include linux/irq.h
#include media/rc-core.h
@@ -30,6 +31,63 @@ struct gpio_rc_dev {
bool active_low;
};
+#ifdef CONFIG_OF
+/*
+ * Translate OpenFirmware node properties into platform_data
+ */
+static struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ struct gpio_ir_recv_platform_data *pdata;
+ enum of_gpio_flags flags;
+ int gpio;
+
+ if (!np)
+ return ERR_PTR(-ENODEV);
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_find_property(np, gpios, NULL)) {
+ dev_err(dev, Found gpio-ir-receiver without gpios\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ gpio = of_get_gpio_flags(np, 0, flags);
+ if (gpio 0) {
+ if (gpio != -EPROBE_DEFER)
+ dev_err(dev, Failed to get gpio flags, error: %d\n,
+ gpio);
+ return ERR_PTR(gpio);
+ }
+
+ pdata-gpio_nr = gpio;
+ pdata-active_low = (flags OF_GPIO_ACTIVE_LOW) ? true : false;
+ pdata-map_name = of_get_property(np, linux,rc-map-name, NULL);
+ of_property_read_u64(np, linux,allowed-rc-protocols,
+pdata-allowed_protos);
+
+ return pdata;
+}
+
+static struct of_device_id gpio_ir_recv_of_match[] = {
+ { .compatible = gpio-ir-receiver, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, gpio_ir_recv_of_match);
+
+#else /* !CONFIG_OF */
+
+static inline struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+#endif
+
static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
{
struct gpio_rc_dev *gpio_dev = dev_id;
@@ -66,8 +124,11 @@ static int gpio_ir_recv_probe(struct platform_device *pdev)
pdev-dev.platform_data;
int rc;
- if (!pdata)
- return -EINVAL;
+ if (!pdata) {
+ pdata = gpio_ir_recv_get_devtree_pdata(pdev-dev);
+ if (IS_ERR(pdata))
+ return PTR_ERR(pdata);
+ }
if (pdata-gpio_nr 0)
return -EINVAL;
@@ -195,6 +256,9 @@ static struct platform_driver gpio_ir_recv_driver = {
#ifdef CONFIG_PM
.pm = gpio_ir_recv_pm_ops,
#endif
+#ifdef
Re: [PATCH] net: sh_eth: Add support of device tree probe
Hey Simon, Iwamatsu-san, On Wed, Feb 6, 2013 at 11:00 AM, Simon Horman horms+rene...@verge.net.au wrote: From: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com This adds support of device tree probe for Renesas sh-ether driver. Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com Thanks for your work on this +++ b/Documentation/devicetree/bindings/net/sh_ether.txt @@ -0,0 +1,43 @@ +* Renesas Electronics SuperH EMAC + +This file provides information, what the device node +for the sh_eth interface contains. + +Required properties: +- compatible: renesas,sh-eth; +- interrupt-parent: The phandle for the interrupt controller that +services interrupts for this device. +- reg: Offset and length of the register set for the +device. +- interrupts: Interrupt mapping for the sh_eth interrupt +sources (vector id). +- phy-mode: String, operation mode of the PHY interface. +- sh-eth,edmac-endian: String, endian of sh_eth dmac. +- sh-eth,register-type: String, register type of sh_eth. +Please select gigabit, fast-sh4 or +fast-sh3-sh2. +Please select little or big. +- sh-eth,endian:String, endian of sh_eth dmac. +- sh-eth,phy-id:PHY id. + +Optional properties: +- local-mac-address : 6 bytes, mac address +- sh-eth,no-ether-link: set link control by software. When device does +not support ether-link, set. +- sh-etn,ether-link-active-low: set link check method. +When detection of link is treated as active-low, +set. +- sh-etn,needs-init:Initialization flag. +When initialize device in probing device, set. I believe there is a spelling mistake here with sh-etn instead of sh-eth. Also, I am happy when DT is used to describe hardware information, but in the case of needs-init it more looks like software policy. Thanks, / magnus ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net: sh_eth: Add support of device tree probe
Hi Simon, Iwamatsu-san +Required properties: +- compatible: renesas,sh-eth; +- interrupt-parent: The phandle for the interrupt controller that +services interrupts for this device. +- reg: Offset and length of the register set for the +device. +- interrupts: Interrupt mapping for the sh_eth interrupt +sources (vector id). +- phy-mode: String, operation mode of the PHY interface. +- sh-eth,edmac-endian: String, endian of sh_eth dmac. I believe endian is only little/big. It can be bool settings, not string ? +- sh-eth,endian:String, endian of sh_eth dmac. Is this really used it in this driver ? Best regards --- Kuninori Morimoto ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: pci: Keep pci_common_init() around after init
Dear Thierry Reding, On Wed, 9 Jan 2013 21:43:06 +0100, Thierry Reding wrote: When using deferred driver probing, PCI host controller drivers may actually require this function after the init stage. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][PATCH 0/3 v4] ASoC: simple-card: add Device Tree support
Hi Mark, Stephen Kuninori Morimoto (3): ASoC: use list_add_tail() instead of list_add() for platform/codec/dai list ASoC: add snd_soc_of_get_port_dai_name() ASoC: simple-card: add Device Tree support #1, #2 enable to get cpu/codec_dai_name from device node and specific port number. #3 adds simple-card. I noticed that #3 patch has compile error without CONFIG_OF. Please give me v5 chance for it. But, I still need any feedback about it. Best regards --- Kuninori Morimoto ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D
-Original Message- From: Sachin Kamat [mailto:sachin.ka...@linaro.org] Sent: Wednesday, February 06, 2013 5:03 PM To: Inki Dae Cc: linux-me...@vger.kernel.org; dri-de...@lists.freedesktop.org; devicetree-discuss@lists.ozlabs.org; k.deb...@samsung.com; s.nawro...@samsung.com; kgene@samsung.com; patc...@linaro.org; Ajay Kumar Subject: Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D On 6 February 2013 13:02, Inki Dae inki@samsung.com wrote: Looks good to me but please add document for it. Yes. I will. I was planning to send the bindings document patch along with the dt patches (adding node entries to dts files). Sylwester had suggested adding this to Documentation/devicetree/bindings/media/ which contains other media IPs. I think that it's better to go to gpu than media and we can divide Exynos IPs into the bellow categories, Media : mfc GPU : g2d, g3d, fimc, gsc Video : fimd, hdmi, eDP, MIPI-DSI And I think that the device-tree describes hardware so possibly, all documents in .../bindings/drm/exynos/* should be moved to proper place also. Please give me any opinions. Thanks, Inki Dae To other guys, And is there anyone who know where this document should be added to? I'm not sure that the g2d document should be placed in Documentation/devicetree/bindings/gpu, media, drm/exynos or arm/exynos. At least, this document should be shared with the g2d hw relevant drivers such as v4l2 and drm. So is .../bindings/gpu proper place? -- With warm regards, Sachin ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 09/13] mfd: omap-usb-host: Add device tree support and binding information
On 02/05/2013 06:11 PM, Mark Rutland wrote: [...] + +- single_ulpi_bypass: Must be present if the controller contains a single + ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1 Again it would be nicer to have '-' rather than '_' here. It might be worth prefixing this ti,. Is prefixing with ti really required? how does it better? I thought single-ulpi-bypass sounded rather generic, but it probably is specific enough as-is. I don't know enough about USB hardware to have strong feelings either way. Yes, it is specific to the TI silicon. I'll leave it as it is then. cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/5] DMA: PL330: Add new pl330 filter for DT case.
On Wednesday 06 February 2013, Padmavathi Venna wrote: This patch adds a new pl330_dt_filter for DT case to filter the required channel based on the new filter params and modifies the old filter only for non-DT case as suggested by Arnd Bergmann. Signed-off-by: Padmavathi Venna padm...@samsung.com Acked-by: Arnd Bergmann a...@arndb.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 5/5] ARM: SAMSUNG: dma: Remove unnecessary code
On Wednesday 06 February 2013, Padmavathi Venna wrote: This patch removes the usage of DMACH_DT_PROP and dt_dmach_prop from dma code as the new generic dma dt binding support has been added. Signed-off-by: Padmavathi Venna padm...@samsung.com Acked-by: Arnd Bergmann a...@arndb.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 1/1] gpio: mcp23s08: convert driver to DT
On Tuesday 05 February 2013 at 15:29:09, Grant Likely wrote:
On Thu, 31 Jan 2013 21:51:36 +0100, Linus Walleij
linus.wall...@linaro.org wrote:
On Thu, Jan 31, 2013 at 4:58 PM, Lars Poeschel la...@wh2.tu-dresden.de
wrote:
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
@@ -0,0 +1,27 @@
+Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
+8-/16-bit I/O expander with serial interface (I2C/SPI)
+
+Required properties:
+- compatible : Should be mcp,mcp23s08-gpio, mcp,mcp23s17-gpio,
+ mcp,mcp23008-gpio or mcp,mcp23017-gpio
+- base : The first gpio number that should be assigned by this chip.
No. We do not tie the global GPIO numbers into the device tree.
In the DT GPIOs are referenced by ampersand gpio0 1 2
notation referring to the instance, so as you realize DT itself
has no need for that number.
Further it is not OS-neutral.
You have to find another way to handle this in the driver code.
In worst case: use AUXDATA.
Hi Lars,
The trick is to declare the io expander to be a gpio-controller and
use the #gpio-cells property to declare how many cells (32-bit numbers)
are need to specify a single gpio line. Most gpio controllers use
gpio-cells=2; The first cell is the *controller local* gpio
number, and the second cell is used for flags. That way your gpio
controller can be referenced by other nodes in the tree with a gpios
property.
You can find lots of examples of this in the tree.
Linus, Grant, thanks for the explanations. I think I have catched where it
should go.
The thing that confused me was, that the platform_data for the chip has a
mandatory base member, that sets the linux global gpio number at which the
chip should appear. A value of -1 for automatic assigning gpio number is not
allowed, the chip will not probe.
I have to change the driver to allow at least this -1 as an additional value.
As Linus pointed out, it is not desirable to set the global gpio base number
from device tree, right ? If I have 3 instances of this chips then, how can
userspace sw distinguish then to which one it is talking ?
This is an example for a DT entry (for i2c version) of the chip as I am
targetting it now:
gpiom1: gpio@20 {
reg = 0x20;
compatible = mcp,mcp23017-gpio;
gpio-controller;
#gpio-cells = 2;
};
I am working on this but I have some strange issues with the driver
probing/not probing and kernel debug output. I hope I will solve this today.
I will send a new patch then.
Lars
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: davinci: da850: add DT node for I2C0
Add I2C0 device tree and pin muxing information to da850-evm.
Also, add OF_DEV_AUXDATA for I2C0 controller driver in da850
board dt file to use I2C0 clock.
Verified i2c0 node gets created in sys class interface as
/sys/class/i2c-dev/i2c-0/subsystem/i2c-0.
Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com
---
Applies on top of v3.8-rc6 of linus tree.
Depends on
- drivers/pinctrl: grab default handles from device core
http://www.gossamer-threads.com/lists/linux/kernel/1665411
- ARM: davinci: da850: add interrupt-parent property in soc node
https://patchwork.kernel.org/patch/2044101/
- ARM: davinci: da850: add pinctrl support
http://comments.gmane.org/gmane.linux.davinci/25993
:100644 100644 433027f... 738d5d4... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 4b02167... a0072aa... M arch/arm/boot/dts/da850.dtsi
:100644 100644 37c27af... 95ca4e9... M arch/arm/mach-davinci/da8xx-dt.c
arch/arm/boot/dts/da850-evm.dts |6 ++
arch/arm/boot/dts/da850.dtsi | 14 ++
arch/arm/mach-davinci/da8xx-dt.c |8 +++-
3 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 433027f..738d5d4 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,6 +27,12 @@
serial2: serial@1d0d000 {
status = okay;
};
+ i2c0: i2c@1c22000 {
+ status = okay;
+ clock-frequency = 10;
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+ };
};
nand_cs3@6200 {
status = okay;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4b02167..a0072aa 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,6 +56,12 @@
0x30 0x0110 0x0ff0
;
};
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,bits =
+ /* I2C0_SDA,I2C0_SCL */
+ 0x10 0x2200 0xff00
+ ;
+ };
};
serial0: serial@1c42000 {
compatible = ns16550a;
@@ -81,6 +87,14 @@
interrupts = 61;
status = disabled;
};
+ i2c0: i2c@1c22000 {
+ compatible = ti,davinci-i2c;
+ reg = 0x22000 0x1000;
+ interrupts = 15;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
};
nand_cs3@6200 {
compatible = ti,davinci-nand;
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..95ca4e9 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -37,11 +37,17 @@ static void __init da8xx_init_irq(void)
of_irq_init(da8xx_irq_match);
}
+struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA(ti,davinci-i2c, 0x01c22000, i2c_davinci.1, NULL),
+ {}
+};
+
#ifdef CONFIG_ARCH_DAVINCI_DA850
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+ da850_auxdata_lookup, NULL);
da8xx_uart_clk_enable();
}
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 1/1] gpio: mcp23s08: convert driver to DT
On Wed, Feb 6, 2013 at 10:31 AM, Lars Poeschel poesc...@lemonage.de wrote: The thing that confused me was, that the platform_data for the chip has a mandatory base member, that sets the linux global gpio number at which the chip should appear. Yes this is common. I think you should look at other drivers under drivers/gpio using device tree, and how they work around this. As stated, as a last resort you can use AUXDATA to anyway assign a piece of platform data per instance. In the Nomadik driver, we use the block instance ID and multiply by a factor of the numbers of GPIOs on each instance. And luckily the base is zero. Not elegant maybe, but the global GPIO numberspace is not elegant by nature. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: how to specify an OMAP clock in device tree?
On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote: Doesn't look very elegant to me, but I wouldn't mind if there is no better option. Even then, we can't rely on the device name as its index can change based on where it is Well, thats what I said in the first mail, that *if* you are able to fix the device name, *then* we could use clkdev the way its used in non-DT case. But then you came back saying 'Fixing the device name doesn't really solve the problem.' :) located in the dts file. e.g. in the beginning it may be named phy.8, and if a device node is added before it, it will get changed to phy.9 If you provide a phandle to the PHY node in the board node, for which you need to add the clk alias, you can always extract the device (using of_find_device_by_node() ) and hence its name, so it doesn't matter if its phy.8 or phy.9. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: how to specify an OMAP clock in device tree?
On 02/06/2013 12:21 PM, Rajendra Nayak wrote: On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote: Doesn't look very elegant to me, but I wouldn't mind if there is no better option. Even then, we can't rely on the device name as its index can change based on where it is Well, thats what I said in the first mail, that *if* you are able to fix the device name, *then* we could use clkdev the way its used in non-DT case. But then you came back saying 'Fixing the device name doesn't really solve the problem.' :) It does, yes, but depending on fixed device names is not so great for DT, is it? Doesn't solve the problem in the right sense :) located in the dts file. e.g. in the beginning it may be named phy.8, and if a device node is added before it, it will get changed to phy.9 If you provide a phandle to the PHY node in the board node, for which you need to add the clk alias, you can always extract the device (using of_find_device_by_node() ) and hence its name, so it doesn't matter if its phy.8 or phy.9. Right, I'll come up with something on these lines. Thanks for the suggestions :). cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
Hi Gregory,
On Tue, Feb 05, 2013 at 09:17:02PM +0100, Gregory CLEMENT wrote:
On 02/05/2013 05:28 PM, Gregory CLEMENT wrote:
Hi Ezequiel,
On 02/05/2013 12:24 PM, Ezequiel Garcia wrote:
This patch adds an SPI master device node for Armada XP-GP board.
This master node is an SPI flash controller 'n25q128a13'.
Since there is no 'partitions' node declared, one full sized
partition named as the device will be created.
Cc: Gregory Clement gregory.clem...@free-electrons.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Lior Amsalem al...@marvell.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
This patch depends on:
1. Gregory's patch for Armada XP GP board:
arm: mvebu: support for the new Armada XP development
board(DB-MV784MP-GP)
2. My previous patch for SPI on Armada 370/XP:
arm: mvebu: Add support for SPI controller in Armada 370/XP
And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y
arch/arm/boot/dts/armada-xp-gp.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 3eea531..1c8afe2 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -97,5 +97,17 @@
phy = phy3;
phy-mode = rgmii-id;
};
+
+ spi0: spi@d0010600 {
+ status = okay;
+
+ spi-flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = n25q128a13;
+ reg = 0; /* Chip select 0 */
+ spi-max-frequency = 10800;
I had a remark about it, according to the datasheet, 108MHz is the
maximum frequency for the all the instructions but the READ
instruction. For the READ the maximum frequency is 54MHz. So I wonder
if we shouldn't use 5400 here.
Mmm... nice catch.
The mtd driver for the spi flash (m25p80) will use FAST_READ opcode
if CONFIG_M25PXX_USE_FAST_READ is selected, and this option
is selected by default.
However we cannot count on this option being selected, of course.
On the other side, after some testing with spi-max-frequency = 50 MHz
and also with spi-max-frequency = 108 MHz I'm seeing the flash often
(not always) stalls when trying to read the full device through dd:
/ # dd if=/dev/mtd0ro of=/dev/null
This happens regardless of CONFIG_M25PXX_USE_FAST_READ, and regardless
of spi-max-frequency = 50 MHz or 54 MHz or 108 MHz.
Note that setting 108 MHz is useless in our case, because there's
an upper limit of 62.5 MHz set by the core clock of the SoC.
Using a read block size of 1M, the read completes OK -- always:
/ # dd if=/dev/mtd0 of=/dev/null bs=1M
16+0 records in
16+0 records out
16777216 bytes (16.0MB) copied, 27.306048 seconds, 600.0KB/s
Moreover, when the read completes, the achieved bandwidth
is the same for 40, 50, 54, or 108 MHz.
If we set spi-max-frequency to 27 MHz (108 MHz / 4), it looks like the stalling
disappear and the read always completes OK, at almost half the speed:
/ # dd if=/dev/mtd0ro of=/dev/null
32768+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 49.005122 seconds, 334.3KB/s
So according to this analysis, we whould set 27 MHz as the max
frequency, based on nothing but in these tests.
I'm not sure the stalling is due to the clocking or due to
some driver bug (I don't like the tricks pulled by the busy loop
in orion_spi_wait_till_ready() but probably this is completely unrelated).
Adding some SPI people in Cc, hoping they can shed a light on this.
What do you think?
--
Ezequiel GarcĂa, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/8] Remove fdtdump and use fdtgrep instead
On Mon, Jan 21, 2013 at 12:59:21PM -0800, Simon Glass wrote: Since fdtgrep does everything that fdtdump does now, perhaps we should replace it with a symlink. Nack. The point of fdtdump is not simply to be a tool for dumping device trees - dtc -I dtb -O dts will do that already. The point is to be a really simple, independent implementation of dumping the tree, which can be used for analyzing bugs in the more complex tools. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
Hi Koen, SNIP Since AM335x is DT only, why is there a platform data codepath and why is it the first branch it tries? And I guess the next question is related to the first: why doesn't it work when used with DT? When I copy over the nodes from the evm.dts to my board I get tsc tsc: Missing platform data in dmesg. This IP came up 1st on AM335x, but it is not platform dependent. The driver can be used on other platforms where-in DT is not supported. According to the maintainers platform data takes precedence over DT. Hence the order. Rachana, I see no point adding support for platform_data when you know that none of older platforms are going to use this driver and all future platforms _must_ follow device-tree model. So I agree that you should remove board file dependency from the driver. Ok. I will remove support for platform data in the next version of patches. I do not see Missing platform data error msg in the latest driver. I am not able to trace from where this got populated. Can you share the branch which you have tested? https://github.com/patilrachna/linux/tree/v3.8_rc3_MFD_TSCADC_DT-v2 Did you get a chance to test this branch? And can you also share your branch, on which you observed the issue. Regards, Rachna ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D
On 02/06/2013 09:51 AM, Inki Dae wrote: [...] I think that it's better to go to gpu than media and we can divide Exynos IPs into the bellow categories, Media : mfc GPU : g2d, g3d, fimc, gsc Heh, nice try! :) GPU and FIMC ? FIMC is a camera subsystem (hence 'C' in the acronym), so what it has really to do with GPU ? All right, this IP has really two functions: camera capture and video post-processing (colorspace conversion, scaling), but the main feature is camera capture (fimc-lite is a camera capture interface IP only). Also, Exynos5 GScaler is used as a DMA engine for camera capture data pipelines, so it will be used by a camera capture driver as well. It really belongs to Media and GPU, as this is a multifunctional device (similarly to FIMC). So I propose following classification, which seems less inaccurate: GPU: g2d, g3d Media: mfc, fimc, fimc-lite, fimc-is, mipi-csis, gsc Video: fimd, hdmi, eDP, mipi-dsim I have already a DT bindings description prepared for fimc [1]. (probably it needs to be rephrased a bit not to refer to the linux device model). I put it in Documentation/devicetree/bindings/media/soc, but likely there is no need for the 'soc' subdirectory... Video : fimd, hdmi, eDP, MIPI-DSI And I think that the device-tree describes hardware so possibly, all documents in .../bindings/drm/exynos/* should be moved to proper place also. Please give me any opinions. Yes, I agree. If possible, it would be nice to have some Linux API agnostic locations. [1] goo.gl/eTGOl -- Thanks, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D
On 6 February 2013 16:53, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 02/06/2013 09:51 AM, Inki Dae wrote: [...] So I propose following classification, which seems less inaccurate: GPU: g2d, g3d Media: mfc, fimc, fimc-lite, fimc-is, mipi-csis, gsc Video: fimd, hdmi, eDP, mipi-dsim Thanks Inki and Sylwester for your inputs. We need to figure out some sensible location for these drivers' documentation though I liked what you have proposed for now. I will add g2d document to gpu directory as both of you suggest the same. If there are better opinions will move it later. -- With warm regards, Sachin ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Sylwester Nawrocki Sent: Wednesday, February 06, 2013 8:24 PM To: Inki Dae Cc: 'Sachin Kamat'; linux-me...@vger.kernel.org; dri- de...@lists.freedesktop.org; devicetree-discuss@lists.ozlabs.org; k.deb...@samsung.com; kgene@samsung.com; patc...@linaro.org; 'Ajay Kumar'; kyungmin.p...@samsung.com; sw0312@samsung.com; jy0922.s...@samsung.com Subject: Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D On 02/06/2013 09:51 AM, Inki Dae wrote: [...] I think that it's better to go to gpu than media and we can divide Exynos IPs into the bellow categories, Media : mfc GPU : g2d, g3d, fimc, gsc Heh, nice try! :) GPU and FIMC ? FIMC is a camera subsystem (hence 'C' in the acronym), so what it has really to do with GPU ? All right, this IP has really two functions: camera capture and video post-processing (colorspace conversion, scaling), but the main feature is camera capture (fimc-lite is a camera capture interface IP only). Also, Exynos5 GScaler is used as a DMA engine for camera capture data pipelines, so it will be used by a camera capture driver as well. It really belongs to Media and GPU, as this is a multifunctional device (similarly to FIMC). So I propose following classification, which seems less inaccurate: GPU: g2d, g3d Media: mfc, fimc, fimc-lite, fimc-is, mipi-csis, gsc Video: fimd, hdmi, eDP, mipi-dsim Ok, it seems that your propose is better. :) To Sachin, Please add g2d document to .../bindings/gpu To Rahul, Could you please move .../drm/exynos/* to .../bindings/video? Probably you need to rename the files there to exynos*.txt If there are no other opinions, let's start :) Thanks, Inki Dae I have already a DT bindings description prepared for fimc [1]. (probably it needs to be rephrased a bit not to refer to the linux device model). I put it in Documentation/devicetree/bindings/media/soc, but likely there is no need for the 'soc' subdirectory... Video : fimd, hdmi, eDP, MIPI-DSI And I think that the device-tree describes hardware so possibly, all documents in .../bindings/drm/exynos/* should be moved to proper place also. Please give me any opinions. Yes, I agree. If possible, it would be nice to have some Linux API agnostic locations. [1] goo.gl/eTGOl -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media 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
[PATCH 1/7] ARM: dts: Add G2D node to exynos4210.dtsi
Added G2D DT node to Exynos4210.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 79ba247..3410d5f 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -47,6 +47,14 @@
0 12 0, 0 13 0, 0 14 0, 0 15 0;
};
+ g2d@1280 {
+ compatible = samsung,s5pv210-g2d;
+ reg = 0x1280 0x1000;
+ interrupts = 0 89 0;
+ samsung,power-domain = pd_lcd0;
+ status = disabled;
+ };
+
pmu {
compatible = arm,cortex-a9-pmu;
interrupt-parent = combiner;
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/7] ARM: dts: Add G2D DT nodes to Exynos4 machines
This patch series is based on for-next branch of Kukjin Kim's tree git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git Patches added on top of MFC DT series which has been accepted by Kukjin. http://www.spinics.net/lists/linux-samsung-soc/msg15419.html Sachin Kamat (7): ARM: dts: Add G2D node to exynos4210.dtsi ARM: dts: Add G2D node to SMDKV310 ARM: dts: Add G2D node to exynos4210-origen ARM: dts: Add G2D node to exynos4x12.dtsi ARM: dts: Add G2D node to SMDK4412 ARM: dts: Add G2D node to exynos4412-origen ARM: dts: Add Samsung G2D DT bindings documentation .../devicetree/bindings/gpu/samsung-g2d.txt| 30 arch/arm/boot/dts/exynos4210-origen.dts|4 ++ arch/arm/boot/dts/exynos4210-smdkv310.dts |4 ++ arch/arm/boot/dts/exynos4210.dtsi |8 + arch/arm/boot/dts/exynos4412-origen.dts|4 ++ arch/arm/boot/dts/exynos4412-smdk4412.dts |4 ++ arch/arm/boot/dts/exynos4x12.dtsi |7 7 files changed, 61 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/samsung-g2d.txt -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/7] ARM: dts: Add G2D node to SMDKV310
Added G2D DT node to SMDKV310 board.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210-smdkv310.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 2b1e03a..7bb16aa 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -43,6 +43,10 @@
status = okay;
};
+ g2d@1280 {
+ status = okay;
+ };
+
codec@1340 {
samsung,mfc-r = 0x4300 0x80;
samsung,mfc-l = 0x5100 0x80;
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/7] ARM: dts: Add G2D node to exynos4210-origen
Added G2D DT node to Origen4210 board.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210-origen.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 052606b..e081d89 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -57,6 +57,10 @@
status = okay;
};
+ g2d@1280 {
+ status = okay;
+ };
+
codec@1340 {
samsung,mfc-r = 0x4300 0x80;
samsung,mfc-l = 0x5100 0x80;
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/7] ARM: dts: Add G2D node to exynos4x12.dtsi
Added G2D DT node to exynos4x12.dtsi file.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4x12.dtsi |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 022a839..f9247b9 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -36,6 +36,13 @@
0 16 0, 0 17 0, 0 18 0, 0 19 0;
};
+ g2d@1080 {
+ compatible = samsung,exynos4212-g2d;
+ reg = 0x1080 0x1000;
+ interrupts = 0 89 0;
+ status = disabled;
+ };
+
pinctrl_0: pinctrl@1140 {
compatible = samsung,exynos4x12-pinctrl;
reg = 0x1140 0x1000;
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/7] ARM: dts: Add G2D node to SMDK4412
Added G2D DT node to SMDK4412 board.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
This patch is added on top of below patch:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15148.html
---
arch/arm/boot/dts/exynos4412-smdk4412.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-smdk4412.dts
b/arch/arm/boot/dts/exynos4412-smdk4412.dts
index 6ae4276..bba53a8 100644
--- a/arch/arm/boot/dts/exynos4412-smdk4412.dts
+++ b/arch/arm/boot/dts/exynos4412-smdk4412.dts
@@ -27,6 +27,10 @@
bootargs =root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC1,115200 init=/linuxrc;
};
+ g2d@1080 {
+ status = okay;
+ };
+
sdhci@1253 {
bus-width = 4;
pinctrl-0 = sd2_clk sd2_cmd sd2_bus4 sd2_cd;
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 6/7] ARM: dts: Add G2D node to exynos4412-origen
Added G2D DT node to Origen4412 board.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
This patch is added on top of below patch:
http://www.spinics.net/lists/linux-samsung-soc/msg15543.html
---
arch/arm/boot/dts/exynos4412-origen.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index daa3884..1df7ebd 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -36,6 +36,10 @@
enable-active-high;
};
+ g2d@1080 {
+ status = okay;
+ };
+
sdhci@1253 {
bus-width = 4;
pinctrl-0 = sd2_clk sd2_cmd sd2_bus4 sd2_cd;
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 7/7] ARM: dts: Add Samsung G2D DT bindings documentation
Added documentaion about G2D bindings.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
.../devicetree/bindings/gpu/samsung-g2d.txt| 30
1 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpu/samsung-g2d.txt
diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
new file mode 100644
index 000..838b26b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
@@ -0,0 +1,30 @@
+* Samsung 2D Graphics Accelerator
+
+Samsung FIMG2D is a 2D graphics accelerator which supports Bit Block Transfer.
+We set the drawing-context registers for configuring the rendering parameters
+and then start rendering.
+The G2D has V4L2 as well as DRM framework based driver support.
+
+Required properties:
+ - compatible : value should be one among the following
+ (a) samsung,s5pv210-g2d for G2D IP present in S5PV210 Exynos4210 SoC
+ (b) samsung,exynos4212-g2d for G2D IP present in Exynos4x12 SoCs
+ (b) samsung,exynos5250-g2d for G2D IP present in Exynos5250 SoC
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : G2D interrupt number to the CPU.
+
+Optional properties:
+ - samsung,power-domain : power-domain property defined with a phandle
+ to respective power domain.
+
+Example:
+ g2d@1280 {
+ compatible = samsung,s5pv210-g2d;
+ reg = 0x1280 0x1000;
+ interrupts = 0 89 0;
+ samsung,power-domain = pd_lcd0;
+ status = disabled;
+ };
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
On 02/06/2013 11:54 AM, Ezequiel Garcia wrote:
Hi Gregory,
On Tue, Feb 05, 2013 at 09:17:02PM +0100, Gregory CLEMENT wrote:
On 02/05/2013 05:28 PM, Gregory CLEMENT wrote:
Hi Ezequiel,
On 02/05/2013 12:24 PM, Ezequiel Garcia wrote:
This patch adds an SPI master device node for Armada XP-GP board.
This master node is an SPI flash controller 'n25q128a13'.
Since there is no 'partitions' node declared, one full sized
partition named as the device will be created.
Cc: Gregory Clement gregory.clem...@free-electrons.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Lior Amsalem al...@marvell.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
This patch depends on:
1. Gregory's patch for Armada XP GP board:
arm: mvebu: support for the new Armada XP development
board(DB-MV784MP-GP)
2. My previous patch for SPI on Armada 370/XP:
arm: mvebu: Add support for SPI controller in Armada 370/XP
And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y
arch/arm/boot/dts/armada-xp-gp.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 3eea531..1c8afe2 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -97,5 +97,17 @@
phy = phy3;
phy-mode = rgmii-id;
};
+
+ spi0: spi@d0010600 {
+ status = okay;
+
+ spi-flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = n25q128a13;
+ reg = 0; /* Chip select 0 */
+ spi-max-frequency = 10800;
I had a remark about it, according to the datasheet, 108MHz is the
maximum frequency for the all the instructions but the READ
instruction. For the READ the maximum frequency is 54MHz. So I wonder
if we shouldn't use 5400 here.
Mmm... nice catch.
The mtd driver for the spi flash (m25p80) will use FAST_READ opcode
if CONFIG_M25PXX_USE_FAST_READ is selected, and this option
is selected by default.
OK I didn't notice that thre wre a FAST_READ which was supported by
Linux. So I think we can keep 10800 as spi-max-frequency.
However we cannot count on this option being selected, of course.
On the other side, after some testing with spi-max-frequency = 50 MHz
and also with spi-max-frequency = 108 MHz I'm seeing the flash often
(not always) stalls when trying to read the full device through dd:
/ # dd if=/dev/mtd0ro of=/dev/null
This happens regardless of CONFIG_M25PXX_USE_FAST_READ, and regardless
of spi-max-frequency = 50 MHz or 54 MHz or 108 MHz.
Note that setting 108 MHz is useless in our case, because there's
an upper limit of 62.5 MHz set by the core clock of the SoC.
Using a read block size of 1M, the read completes OK -- always:
/ # dd if=/dev/mtd0 of=/dev/null bs=1M
16+0 records in
16+0 records out
16777216 bytes (16.0MB) copied, 27.306048 seconds, 600.0KB/s
Moreover, when the read completes, the achieved bandwidth
is the same for 40, 50, 54, or 108 MHz.
If we set spi-max-frequency to 27 MHz (108 MHz / 4), it looks like the
stalling
disappear and the read always completes OK, at almost half the speed:
/ # dd if=/dev/mtd0ro of=/dev/null
32768+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 49.005122 seconds, 334.3KB/s
So according to this analysis, we whould set 27 MHz as the max
frequency, based on nothing but in these tests.
I'm not sure the stalling is due to the clocking or due to
some driver bug (I don't like the tricks pulled by the busy loop
in orion_spi_wait_till_ready() but probably this is completely unrelated).
Adding some SPI people in Cc, hoping they can shed a light on this.
What do you think?
We have just seen this on IRC, so it seemed it was actually a problem in
userspace not in kernel space.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 01/10] clk: tegra: Refactor PLL programming code
On Tue, Feb 05, 2013 at 02:23:55PM +0100, Peter De Schrijver wrote:
On Tue, Feb 05, 2013 at 06:42:11AM +0100, Prashant Gaikwad wrote:
On Monday 04 February 2013 08:02 PM, Peter De Schrijver wrote:
On Mon, Feb 04, 2013 at 07:06:47AM +0100, Prashant Gaikwad wrote:
On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:
...
-static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll,
-void __iomem *lock_addr, u32
lock_bit_idx)
+static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll)
{
int i;
- u32 val;
+ u32 val, lock_bit;
+ void __iomem *lock_addr;
if (!(pll-flags TEGRA_PLL_USE_LOCK)) {
udelay(pll-params-lock_delay);
return 0;
}
+ lock_addr = pll-clk_base + pll-params-base_reg;
This will not work for PLLE. Lock bit for PLLE is in misc register.
+ lock_bit = BIT(pll-params-lock_bit_idx);
+
for (i = 0; i pll-params-lock_delay; i++) {
val = readl_relaxed(lock_addr);
- if (val BIT(lock_bit_idx)) {
+ if (val lock_bit) {
Need to change the lock bit idx parameter for Tegra20 and Tegra30 PLLs
else this patch will break those.
Looking at commit 37c26a906527b8a6a252614ca83d21ad318c4e84 and commit
b08e8c0ecc42afa3a2e1019851af741980dd5a6b, these fields seem correctly
initialized for both Tegra20 and Tegra30? Or am I missing something?
Ohh, I missed to read
lock_bit = BIT(pll-params-lock_bit_idx);
Am I missing something about PLLE lock_addr also?
Ah no indeed... my bad. So we need a lock_addr field.
Or a flag. Flag seems less invasive for now.
Cheers,
Peter.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] omap_hsmmc DT DMA Client support
Hi Matt! At first thanks for you efforts on DMA Engine on AM33XX. On Friday 01 February 2013 at 22:01:17, Matt Porter wrote: This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers in -next and the dma_request_slave_channel_compat() wrapper introduced in the AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. The series depends on the following patches: - dmaengine DT support and edma dmaengine driver fix from the git://git.infradead.org/users/vkoul/slave-dma.git next branch - dma_request_slave_channel_compat() support https://patchwork.kernel.org/patch/2081671/ The series with all dependencies can be found at https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1 I cloned your github repository and did short testing with it. I get the following error when the kernel mounts my sd-card: Starting udev [5.884738] udevd[72]: starting version 182 [8.879651] edma-dma-engine edma-dma-engine.0: Exceeded max SG segments 33 16 [8.887377] omap_hsmmc mmc.3: prep_slave_sg() failed [8.892588] omap_hsmmc mmc.3: MMC start dma failure [8.897725] mmcblk0: unknown error -1 sending read/write command, card status 0x900 [8.905889] end_request: I/O error, dev mmcblk0, sector 17039 [8.911926] end_request: I/O error, dev mmcblk0, sector 17047 [8.917934] end_request: I/O error, dev mmcblk0, sector 17055 [8.923960] end_request: I/O error, dev mmcblk0, sector 17063 [8.929967] end_request: I/O error, dev mmcblk0, sector 17071 [8.935988] end_request: I/O error, dev mmcblk0, sector 17079 [8.942010] end_request: I/O error, dev mmcblk0, sector 17087 [8.948016] end_request: I/O error, dev mmcblk0, sector 17095 [8.954037] end_request: I/O error, dev mmcblk0, sector 17103 [8.960043] end_request: I/O error, dev mmcblk0, sector 17111 [9.020919] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc:3764: inode #8: block 239: comm mount: unable to read itable block [9.033514] EXT4-fs (mmcblk0p2): no journal found [9.043799] kjournald starting. Commit interval 5 seconds [9.049589] EXT3-fs (mmcblk0p2): warning: mounting fs with errors, running e2fsck is recommended [9.060940] EXT3-fs (mmcblk0p2): using internal journal [9.066437] EXT3-fs (mmcblk0p2): recovery complete [9.071460] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode After that the filesystem on the sd-card has an error that I have to fix with e2fsck. As rootfs I use a nfsroot. In my quick tests, same setup, I don't get any error on edma-dmaengine- am33xx-v5 branch of your repository. If you need any further information, let me now. Regards, Lars ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/4] ARM: mvebu: Add support for SPI flash devices in Armada 370/XP
This is second version of the SPI patchset for Armada 370/XP. This series first adds support for the SPI controller and then adds the SPI flash for the Armada XP GP board. This series is based on 3.8-rc5 plus: * arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP) * arm: mvebu: i2c come back in defconfig Feel free to test or provide any feedback! Ezequiel Garcia (4): arm: mvebu: Add support for SPI controller in Armada 370/XP ARM: mvebu: Update defconfig to select SPI support arm: mvebu: Add SPI flash on Armada XP-GP board ARM: mvebu: Update defconfig to select SPI flash and MTD support arch/arm/boot/dts/armada-370-xp.dtsi | 22 ++ arch/arm/boot/dts/armada-xp-gp.dts | 12 arch/arm/configs/mvebu_defconfig |5 + 3 files changed, 39 insertions(+), 0 deletions(-) Thanks, Ezequiel -- 1.7.8.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/4] arm: mvebu: Add support for SPI controller in Armada 370/XP
The Armada 370 and Armada XP SoC has an SPI controller.
This patch adds support for this controller in Armada 370
and Armada XP SoC common device tree files.
Note that the Armada XP SPI register length is 0x50 bytes,
while Armada 370 SPI register length is 0x28 bytes,
so we choose the smaller of the two.
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Lior Amsalem al...@marvell.com
Acked-by: Gregory Clement gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v1:
* Register offset must be 0x28 instead of 0x50,
as pointed out by Gregory
arch/arm/boot/dts/armada-370-xp.dtsi | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 4c0abe8..5cf8fb4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -131,6 +131,28 @@
clocks = coreclk 0;
status = disabled;
};
+
+ spi0: spi@d0010600 {
+ compatible = marvell,orion-spi;
+ reg = 0xd0010600 0x28;
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ interrupts = 30;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ spi1: spi@d0010680 {
+ compatible = marvell,orion-spi;
+ reg = 0xd0010680 0x28;
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ interrupts = 92;
+ clocks = coreclk 0;
+ status = disabled;
+ };
};
};
--
1.7.8.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/4] ARM: mvebu: Update defconfig to select SPI support
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Lior Amsalem al...@marvell.com Acked-by: Gregory Clement gregory.clem...@free-electrons.com Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- arch/arm/configs/mvebu_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index 43a0dbf..322baca 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -35,6 +35,8 @@ CONFIG_MARVELL_PHY=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_I2C=y +CONFIG_SPI=y +CONFIG_SPI_ORION=y CONFIG_I2C_MV64XXX=y CONFIG_SERIAL_8250_DW=y CONFIG_GPIOLIB=y -- 1.7.8.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/4] arm: mvebu: Add SPI flash on Armada XP-GP board
This patch adds an SPI master device node for Armada XP-GP board.
This master node is an SPI flash controller 'n25q128a13'.
Since there is no 'partitions' node declared, one full sized
partition named as the device will be created.
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Lior Amsalem al...@marvell.com
Tested-by: Gregory Clement gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Depends on Gregory's patch for Armada XP GP board:
arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP)
arch/arm/boot/dts/armada-xp-gp.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 872ed04..b1aa952 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -97,5 +97,17 @@
phy = phy3;
phy-mode = rgmii-id;
};
+
+ spi0: spi@d0010600 {
+ status = okay;
+
+ spi-flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = n25q128a13;
+ reg = 0; /* Chip select 0 */
+ spi-max-frequency = 10800;
+ };
+ };
};
};
--
1.7.8.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/4] ARM: mvebu: Update defconfig to select SPI flash and MTD support
The Armada XP DB-MV784MP-GP board has an SPI flash device. These options allow to access that device over MTD. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- Depends on patch: arm: mvebu: i2c come back in defconfig arch/arm/configs/mvebu_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index 322baca..3359535 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -38,6 +38,9 @@ CONFIG_I2C=y CONFIG_SPI=y CONFIG_SPI_ORION=y CONFIG_I2C_MV64XXX=y +CONFIG_MTD=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_M25P80=y CONFIG_SERIAL_8250_DW=y CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y -- 1.7.8.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] ARM: mvebu: Add support for SPI flash devices in Armada 370/XP
On 02/06/2013 02:06 PM, Ezequiel Garcia wrote: This is second version of the SPI patchset for Armada 370/XP. This series first adds support for the SPI controller and then adds the SPI flash for the Armada XP GP board. This series is based on 3.8-rc5 plus: * arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP) * arm: mvebu: i2c come back in defconfig Feel free to test or provide any feedback! Ezequiel, I reviewed the patches, I have nothing more to say, I can add my: Acked-by: Gregory Clement gregory.clem...@free-electrons.com on the patch that didn't have yet. Jason, could you add this series in your incoming pull request? Thanks, Ezequiel Garcia (4): arm: mvebu: Add support for SPI controller in Armada 370/XP ARM: mvebu: Update defconfig to select SPI support arm: mvebu: Add SPI flash on Armada XP-GP board ARM: mvebu: Update defconfig to select SPI flash and MTD support arch/arm/boot/dts/armada-370-xp.dtsi | 22 ++ arch/arm/boot/dts/armada-xp-gp.dts | 12 arch/arm/configs/mvebu_defconfig |5 + 3 files changed, 39 insertions(+), 0 deletions(-) Thanks, Ezequiel -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] ARM: mvebu: Add support for SPI flash devices in Armada 370/XP
On Wed, Feb 06, 2013 at 02:16:54PM +0100, Gregory CLEMENT wrote: On 02/06/2013 02:06 PM, Ezequiel Garcia wrote: This is second version of the SPI patchset for Armada 370/XP. This series first adds support for the SPI controller and then adds the SPI flash for the Armada XP GP board. This series is based on 3.8-rc5 plus: * arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP) * arm: mvebu: i2c come back in defconfig Feel free to test or provide any feedback! Ezequiel, I reviewed the patches, I have nothing more to say, I can add my: Acked-by: Gregory Clement gregory.clem...@free-electrons.com on the patch that didn't have yet. Jason, could you add this series in your incoming pull request? That's the plan. I'm waiting for a response from Olof to see If I need to redo /boards and /dt. In either case, my next round of pull requests with have this and a bunch of other stuff. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] omap_hsmmc DT DMA Client support
On Wed, Feb 06, 2013 at 01:41:06PM +0100, Lars Poeschel wrote: Hi Matt! At first thanks for you efforts on DMA Engine on AM33XX. On Friday 01 February 2013 at 22:01:17, Matt Porter wrote: This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers in -next and the dma_request_slave_channel_compat() wrapper introduced in the AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. The series depends on the following patches: - dmaengine DT support and edma dmaengine driver fix from the git://git.infradead.org/users/vkoul/slave-dma.git next branch - dma_request_slave_channel_compat() support https://patchwork.kernel.org/patch/2081671/ The series with all dependencies can be found at https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1 I cloned your github repository and did short testing with it. I get the following error when the kernel mounts my sd-card: Starting udev [5.884738] udevd[72]: starting version 182 [8.879651] edma-dma-engine edma-dma-engine.0: Exceeded max SG segments 33 Hi Lars, I left it somewhat ambiguous as to what this series claims to support, sorry about that. This series, by itself, supports only platforms using SDMA (omap 2/3/4/5 assuming you add the appropriate DMA dts bits). This is only part of what am33xx requires for working mmc support. I've also posted v3 of dmaengine slave sg caps series at https://lkml.org/lkml/2013/2/4/561 I have to rebase the am33xx specific bits for omap_hsmmc on top of that and post. That was previously all contained in one series but I didn't want to block omap2/3/4/5 from working DMA on DT support until the api change is resolved for am33xx. -Matt [8.887377] omap_hsmmc mmc.3: prep_slave_sg() failed [8.892588] omap_hsmmc mmc.3: MMC start dma failure [8.897725] mmcblk0: unknown error -1 sending read/write command, card status 0x900 [8.905889] end_request: I/O error, dev mmcblk0, sector 17039 [8.911926] end_request: I/O error, dev mmcblk0, sector 17047 [8.917934] end_request: I/O error, dev mmcblk0, sector 17055 [8.923960] end_request: I/O error, dev mmcblk0, sector 17063 [8.929967] end_request: I/O error, dev mmcblk0, sector 17071 [8.935988] end_request: I/O error, dev mmcblk0, sector 17079 [8.942010] end_request: I/O error, dev mmcblk0, sector 17087 [8.948016] end_request: I/O error, dev mmcblk0, sector 17095 [8.954037] end_request: I/O error, dev mmcblk0, sector 17103 [8.960043] end_request: I/O error, dev mmcblk0, sector 17111 [9.020919] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc:3764: inode #8: block 239: comm mount: unable to read itable block [9.033514] EXT4-fs (mmcblk0p2): no journal found [9.043799] kjournald starting. Commit interval 5 seconds [9.049589] EXT3-fs (mmcblk0p2): warning: mounting fs with errors, running e2fsck is recommended [9.060940] EXT3-fs (mmcblk0p2): using internal journal [9.066437] EXT3-fs (mmcblk0p2): recovery complete [9.071460] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode After that the filesystem on the sd-card has an error that I have to fix with e2fsck. As rootfs I use a nfsroot. In my quick tests, same setup, I don't get any error on edma-dmaengine- am33xx-v5 branch of your repository. If you need any further information, let me now. Regards, Lars ___ 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 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support
Salut Florian, On 02/04/2013 10:14 AM, Florian Vaussard wrote: Hello Benoit, On 01/24/2013 01:21 PM, Benoit Cousson wrote: + Peter who did the original PWM Hi Florian, On 01/23/2013 06:56 PM, Florian Vaussard wrote: Hello Benoit, This patchset adds some new DT supports to the Overo products. The first patch converts the PMIC LEDB output to use the pwm-leds, newly merged in your branch for_3.9/dts. The second patch adds the audio support. Excellent, that looks very good to me, but I'd like to get the feedback from Peter before merging it. So a patch is being merged to handle triggers in the case of pwm leds [1]. When done, we will be able to add back the default trigger. Do you want to wait on it to merge this series? What kind of dependency do we have between these two series? I mean what will happen if the DTS is merged before the pwm subsystem? If that does not generate any regression / crash, then it is OK, if not, we should take care of the order. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Heads up on a device tree change
On 06/02/13 13:11, Grant Likely wrote: Hi Stephen, I've just pushed out a change which cleans up platform device registration to use the same path whether or not the device tree is used. It should be safe, but there is a risk of breakage on powerpc platforms. The patch has two effects of note: - DT generated platform devices move from /sys/devices to under /sys/devices/platform. Userspace *should* be okay with this, but if there are any problems then I can post a workaround patch that keeps DT generiated platform_devices in the current location. - Resources on platform_devices get registered so they appear in /proc/iomem and /proc/ioports and so that device drivers get the added protection of request_region. This will cause breakage on device trees nodes with partially overlapping memory regions. (ie. 0x100..0x1ff and 0x180..0x27f). I also have a workaround for this, but I doubt that it will be necessary. Hi Grant, If I understand you correctly, the non-overlapping memory regions thing could be a problem for me. We have a Meta based SoC that has various SoC registers grouped together for doing GPIOs and Pin control things. I'm still in the process of converting it to device tree, but the way I've been handling it is to provide overlapping registers to both the gpio and pinctl DT nodes. Each GPIO bank's registers are also interleaved with the others, so I've been providing overlapping register ranges (offset by 4 for each bank) to the DT node for each gpio bank too, so each bank can function independently and the driver doesn't have to worry about multiple banks. Does that sound like a reasonable use case? I guess I could cheat with the length, or specify each register in it's own memory resource, but it seems like overkill. Cheers James ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] omap_hsmmc DT DMA Client support
On Friday 01 February 2013, Matt Porter wrote: This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers in -next and the dma_request_slave_channel_compat() wrapper introduced in the AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. The series depends on the following patches: - dmaengine DT support and edma dmaengine driver fix from the git://git.infradead.org/users/vkoul/slave-dma.git next branch - dma_request_slave_channel_compat() support https://patchwork.kernel.org/patch/2081671/ The series with all dependencies can be found at https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1 Nice series, Acked-by: Arnd Bergmann a...@arndb.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND] media: rc: gpio-ir-recv: add support for device tree parsing
Hi,
On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but optional properties allow linux specific support for rc
protocols and maps.
There was a similar patch sent by Matus Ujhelyi but that discussion
died after the first reviews.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
...
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 000..937760c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+ - compatible = gpio-ir-receiver;
+ - gpios: OF device-tree gpio specification.
+
+Optional properties:
+ - linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
+ rc protocols.
You likely need to specify in these bindings documentation which bit
corresponds to which RC protocol.
I'm not very familiar with the RC internals, but why it has to be
specified statically in the device tree, when decoding seems to be
mostly software defined ? I might be missing something though..
Couldn't this be configured at run time, with all protocols allowed
as the default ?
+ - linux,rc-map-name: Linux specific remote control map name.
+
+Example node:
+
+ ir: ir-receiver {
+ compatible = gpio-ir-receiver;
+ gpios = gpio0 19 1;
+ /* allow rc protocols 1-4 */
+ linux,allowed-rc-protocols = 0x 0x001e;
+ linux,rc-map-name = rc-rc6-mce;
+ };
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 4f71a7d..25e09fa 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -16,6 +16,7 @@
#include linux/interrupt.h
#include linux/gpio.h
#include linux/slab.h
+#include linux/of_gpio.h
#include linux/platform_device.h
#include linux/irq.h
#include media/rc-core.h
@@ -30,6 +31,63 @@ struct gpio_rc_dev {
bool active_low;
};
+#ifdef CONFIG_OF
+/*
+ * Translate OpenFirmware node properties into platform_data
+ */
+static struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ struct gpio_ir_recv_platform_data *pdata;
+ enum of_gpio_flags flags;
+ int gpio;
+
+ if (!np)
+ return ERR_PTR(-ENODEV);
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_find_property(np, gpios, NULL)) {
Why do you need this ? Isn't of_get_gpio_flags() sufficient ?
+ dev_err(dev, Found gpio-ir-receiver without gpios\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ gpio = of_get_gpio_flags(np, 0, flags);
+ if (gpio 0) {
+ if (gpio != -EPROBE_DEFER)
+ dev_err(dev, Failed to get gpio flags, error: %d\n,
+ gpio);
+ return ERR_PTR(gpio);
+ }
+
+ pdata-gpio_nr = gpio;
+ pdata-active_low = (flags OF_GPIO_ACTIVE_LOW) ? true : false;
+ pdata-map_name = of_get_property(np, linux,rc-map-name, NULL);
+ of_property_read_u64(np, linux,allowed-rc-protocols,
+ pdata-allowed_protos);
+
+ return pdata;
+}
+
+static struct of_device_id gpio_ir_recv_of_match[] = {
+ { .compatible = gpio-ir-receiver, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, gpio_ir_recv_of_match);
+
+#else /* !CONFIG_OF */
+
+static inline struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+#endif
+
static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
{
struct gpio_rc_dev *gpio_dev = dev_id;
@@ -66,8 +124,11 @@ static int gpio_ir_recv_probe(struct platform_device
*pdev)
pdev-dev.platform_data;
int rc;
- if (!pdata)
- return -EINVAL;
+ if (!pdata) {
+ pdata = gpio_ir_recv_get_devtree_pdata(pdev-dev);
Could assigning to pdev-dev.platform_data be avoided here ?
platform_data is only referenced in probe(), so maybe something like
this would be better:
const struct gpio_ir_recv_platform_data *pdata = NULL;
if (pdev-dev.of_node) {
ret = gpio_ir_recv_parse_dt(pdev-dev, pdata);
if (ret 0)
return ret;
} else {
pdata = pdev-dev.platform_data;
}
if (!pdata)
return -EINVAL;
+ if
Heads up on a device tree change
Hi Stephen, I've just pushed out a change which cleans up platform device registration to use the same path whether or not the device tree is used. It should be safe, but there is a risk of breakage on powerpc platforms. The patch has two effects of note: - DT generated platform devices move from /sys/devices to under /sys/devices/platform. Userspace *should* be okay with this, but if there are any problems then I can post a workaround patch that keeps DT generiated platform_devices in the current location. - Resources on platform_devices get registered so they appear in /proc/iomem and /proc/ioports and so that device drivers get the added protection of request_region. This will cause breakage on device trees nodes with partially overlapping memory regions. (ie. 0x100..0x1ff and 0x180..0x27f). I also have a workaround for this, but I doubt that it will be necessary. I'm not worried about it, but it is a sufficiently visible change that I want you to be aware that it is there. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: dts: moving dt binding documents for video devices to common place
Binding Documents for drm-devices are placed in
Documentation/devicetree/bindings/drm/*. But these devices are common
for v4l framework, hence moved to a common place at
Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
associate them with exynos soc series.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
It is base on for-next branch of
git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
.../devicetree/bindings/drm/exynos/hdmi.txt| 22 --
.../devicetree/bindings/drm/exynos/hdmiddc.txt | 12
.../devicetree/bindings/drm/exynos/hdmiphy.txt | 12
.../devicetree/bindings/drm/exynos/mixer.txt | 15 ---
.../devicetree/bindings/video/exynos_hdmi.txt | 22 ++
.../devicetree/bindings/video/exynos_hdmiddc.txt | 12
.../devicetree/bindings/video/exynos_hdmiphy.txt | 12
.../devicetree/bindings/video/exynos_mixer.txt | 15 +++
8 files changed, 61 insertions(+), 61 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmi.txt
delete mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
delete mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
delete mode 100644 Documentation/devicetree/bindings/drm/exynos/mixer.txt
create mode 100644 Documentation/devicetree/bindings/video/exynos_hdmi.txt
create mode 100644 Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
create mode 100644 Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
create mode 100644 Documentation/devicetree/bindings/video/exynos_mixer.txt
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
deleted file mode 100644
index 589edee..000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Device-Tree bindings for drm hdmi driver
-
-Required properties:
-- compatible: value should be samsung,exynos5-hdmi.
-- reg: physical base address of the hdmi and length of memory mapped
- region.
-- interrupts: interrupt number to the cpu.
-- hpd-gpio: following information about the hotplug gpio pin.
- a) phandle of the gpio controller node.
- b) pin number within the gpio controller.
- c) pin function mode.
- d) optional flags and pull up/down.
- e) drive strength.
-
-Example:
-
- hdmi {
- compatible = samsung,exynos5-hdmi;
- reg = 0x1453 0x10;
- interrupts = 0 95 0;
- hpd-gpio = gpx3 7 0xf 1 3;
- };
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
deleted file mode 100644
index fa166d9..000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Device-Tree bindings for hdmiddc driver
-
-Required properties:
-- compatible: value should be samsung,exynos5-hdmiddc.
-- reg: I2C address of the hdmiddc device.
-
-Example:
-
- hdmiddc {
- compatible = samsung,exynos5-hdmiddc;
- reg = 0x50;
- };
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
deleted file mode 100644
index 858f4f9..000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Device-Tree bindings for hdmiphy driver
-
-Required properties:
-- compatible: value should be samsung,exynos5-hdmiphy.
-- reg: I2C address of the hdmiphy device.
-
-Example:
-
- hdmiphy {
- compatible = samsung,exynos5-hdmiphy;
- reg = 0x38;
- };
diff --git a/Documentation/devicetree/bindings/drm/exynos/mixer.txt
b/Documentation/devicetree/bindings/drm/exynos/mixer.txt
deleted file mode 100644
index 9b2ea03..000
--- a/Documentation/devicetree/bindings/drm/exynos/mixer.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Device-Tree bindings for mixer driver
-
-Required properties:
-- compatible: value should be samsung,exynos5-mixer.
-- reg: physical base address of the mixer and length of memory mapped
- region.
-- interrupts: interrupt number to the cpu.
-
-Example:
-
- mixer {
- compatible = samsung,exynos5-mixer;
- reg = 0x1445 0x1;
- interrupts = 0 94 0;
- };
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
new file mode 100644
index 000..589edee
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -0,0 +1,22 @@
+Device-Tree bindings for drm hdmi driver
+
+Required properties:
+- compatible: value should be samsung,exynos5-hdmi.
+- reg: physical base address of the hdmi and length of memory mapped
+ region.
+- interrupts: interrupt number to the cpu.
Re: Heads up on a device tree change
On Wed, Feb 6, 2013 at 1:32 PM, James Hogan james.ho...@imgtec.com wrote: On 06/02/13 13:11, Grant Likely wrote: Hi Stephen, I've just pushed out a change which cleans up platform device registration to use the same path whether or not the device tree is used. It should be safe, but there is a risk of breakage on powerpc platforms. The patch has two effects of note: - DT generated platform devices move from /sys/devices to under /sys/devices/platform. Userspace *should* be okay with this, but if there are any problems then I can post a workaround patch that keeps DT generiated platform_devices in the current location. - Resources on platform_devices get registered so they appear in /proc/iomem and /proc/ioports and so that device drivers get the added protection of request_region. This will cause breakage on device trees nodes with partially overlapping memory regions. (ie. 0x100..0x1ff and 0x180..0x27f). I also have a workaround for this, but I doubt that it will be necessary. Hi Grant, If I understand you correctly, the non-overlapping memory regions thing could be a problem for me. We have a Meta based SoC that has various SoC registers grouped together for doing GPIOs and Pin control things. I'm still in the process of converting it to device tree, but the way I've been handling it is to provide overlapping registers to both the gpio and pinctl DT nodes. Each GPIO bank's registers are also interleaved with the others, so I've been providing overlapping register ranges (offset by 4 for each bank) to the DT node for each gpio bank too, so each bank can function independently and the driver doesn't have to worry about multiple banks. Does that sound like a reasonable use case? I guess I could cheat with the length, or specify each register in it's own memory resource, but it seems like overkill. Note that overlapping regions are fine /provided/ that they are the same size or one fits nicely inside another. It's partial overlap that is a problem I've been thinking about your exact problem though and I think the best way to handle it is for the gpio driver to understand multiple banks. Most memory mapped GPIO controllers should be drivable by the generic gpio driver anyway, so it is a matter of crafting the binding so a single node can describe multiple banks. I still need to review the patch that adds a DT binding for the generic gpio driver. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: dts: moving dt binding documents for video devices to common place
Binding Documents for drm-devices are placed in
Documentation/devicetree/bindings/drm/*. But these devices are common
for v4l framework, hence moved to a common place
Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
associate them with exynos soc series.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
It is base on for-next branch of
git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
.../devicetree/bindings/drm/exynos/hdmi.txt| 22 --
.../devicetree/bindings/drm/exynos/hdmiddc.txt | 12
.../devicetree/bindings/drm/exynos/hdmiphy.txt | 12
.../devicetree/bindings/drm/exynos/mixer.txt | 15 ---
.../devicetree/bindings/video/exynos_hdmi.txt | 22 ++
.../devicetree/bindings/video/exynos_hdmiddc.txt | 12
.../devicetree/bindings/video/exynos_hdmiphy.txt | 12
.../devicetree/bindings/video/exynos_mixer.txt | 15 +++
8 files changed, 61 insertions(+), 61 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmi.txt
delete mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
delete mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
delete mode 100644 Documentation/devicetree/bindings/drm/exynos/mixer.txt
create mode 100644 Documentation/devicetree/bindings/video/exynos_hdmi.txt
create mode 100644 Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
create mode 100644 Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
create mode 100644 Documentation/devicetree/bindings/video/exynos_mixer.txt
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
deleted file mode 100644
index 589edee..000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Device-Tree bindings for drm hdmi driver
-
-Required properties:
-- compatible: value should be samsung,exynos5-hdmi.
-- reg: physical base address of the hdmi and length of memory mapped
- region.
-- interrupts: interrupt number to the cpu.
-- hpd-gpio: following information about the hotplug gpio pin.
- a) phandle of the gpio controller node.
- b) pin number within the gpio controller.
- c) pin function mode.
- d) optional flags and pull up/down.
- e) drive strength.
-
-Example:
-
- hdmi {
- compatible = samsung,exynos5-hdmi;
- reg = 0x1453 0x10;
- interrupts = 0 95 0;
- hpd-gpio = gpx3 7 0xf 1 3;
- };
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
deleted file mode 100644
index fa166d9..000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Device-Tree bindings for hdmiddc driver
-
-Required properties:
-- compatible: value should be samsung,exynos5-hdmiddc.
-- reg: I2C address of the hdmiddc device.
-
-Example:
-
- hdmiddc {
- compatible = samsung,exynos5-hdmiddc;
- reg = 0x50;
- };
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
deleted file mode 100644
index 858f4f9..000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Device-Tree bindings for hdmiphy driver
-
-Required properties:
-- compatible: value should be samsung,exynos5-hdmiphy.
-- reg: I2C address of the hdmiphy device.
-
-Example:
-
- hdmiphy {
- compatible = samsung,exynos5-hdmiphy;
- reg = 0x38;
- };
diff --git a/Documentation/devicetree/bindings/drm/exynos/mixer.txt
b/Documentation/devicetree/bindings/drm/exynos/mixer.txt
deleted file mode 100644
index 9b2ea03..000
--- a/Documentation/devicetree/bindings/drm/exynos/mixer.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Device-Tree bindings for mixer driver
-
-Required properties:
-- compatible: value should be samsung,exynos5-mixer.
-- reg: physical base address of the mixer and length of memory mapped
- region.
-- interrupts: interrupt number to the cpu.
-
-Example:
-
- mixer {
- compatible = samsung,exynos5-mixer;
- reg = 0x1445 0x1;
- interrupts = 0 94 0;
- };
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
new file mode 100644
index 000..4c48a83
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -0,0 +1,22 @@
+Device-Tree bindings for hdmi driver
+
+Required properties:
+- compatible: value should be samsung,exynos5-hdmi.
+- reg: physical base address of the hdmi and length of memory mapped
+ region.
+- interrupts: interrupt number to the cpu.
+-
Re: [PATCH] ARM: dts: moving dt binding documents for video devices to common place
Hi Rahul, On 02/06/2013 03:57 PM, Rahul Sharma wrote: Binding Documents for drm-devices are placed in Documentation/devicetree/bindings/drm/*. But these devices are common for v4l framework, hence moved to a common place Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to associate them with exynos soc series. It looks good to me, I would just use 'exynos-' prefix instead, this seems to be more common across existing files. Sorry for the nitpicking.. I suppose you should address the patch to and base on the tree of the device tree maintainers. Thanks, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/8] ARM: dts: omap5: Add ocp2scp data
Add ocp2scp data node in omap5 device tree file. The information for
the node added here can be found @
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index c937500..230b779 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -504,5 +504,13 @@
reg-names = control_dev_conf, phy_power_usb;
ti,type = 2;
};
+
+ ocp2scp {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp1;
+ };
};
};
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 7/8] ARM: dts: omap5: add dwc3 omap dt data
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index bd73257..c4eb2ec 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -505,6 +505,17 @@
ti,type = 2;
};
+ omap_dwc3@4a02 {
+ compatible = ti,dwc3;
+ ti,hwmods = usb_otg_ss;
+ reg = 0x4a02 0x1000;
+ interrupts = 0 93 4;
+ #address-cells = 1;
+ #size-cells = 1;
+ utmi-mode = 2;
+ ranges;
+ };
+
ocp2scp {
compatible = ti,omap-ocp2scp;
#address-cells = 1;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 8/8] ARM: dts: omap5: add dwc3 core dt data
Add dwc3 core dt data as a subnode to dwc3 omap glue data in omap5 dt
data file. The information for the entered data node is available @
Documentation/devicetree/bindings/usb/dwc3.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index c4eb2ec..24dd69f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -514,6 +514,13 @@
#size-cells = 1;
utmi-mode = 2;
ranges;
+ dwc3@4a03 {
+ compatible = synopsys,dwc3;
+ reg = 0x4a03 0x1000;
+ interrupts = 0 92 4;
+ usb-phy = usb2_phy, usb3_phy;
+ tx-fifo-resize;
+ };
};
ocp2scp {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/8] ARM: dts: omap: Add omap control usb data
Add omap control usb data in omap4 device tree file. This will have the
register address of registers to power on the PHY and to write to
mailbox. The information about this data node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..ffc7352 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,13 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+ omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,omap-control-usb;
+ reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+ reg-names = control_dev_conf, otghs_control;
+ ti,type = 1;
+ };
};
};
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/8] ARM: dts: omap: Add dts data for USB
Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. This series applies cleanly in both for_3.9/dts and 3.8-rc6. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Kishon Vijay Abraham I (8): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap dt data ARM: dts: omap5: add dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ arch/arm/boot/dts/omap3-evm.dts|6 +++ arch/arm/boot/dts/omap3-overo.dtsi |6 +++ arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/8] ARM: dts: omap5: Add omap control usb data
Add omap control usb data in omap5 device tree file. This will have the
register address of registers to power on the USB2 PHY and USB3 PHY. The
information for the node added here is available in
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..c937500 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -496,5 +496,13 @@
hw-caps-ll-interface;
hw-caps-temp-alert;
};
+
+ omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,omap-control-usb;
+ reg = 0x4a002300 0x4,
+ 0x4a002370 0x4;
+ reg-names = control_dev_conf, phy_power_usb;
+ ti,type = 2;
+ };
};
};
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/8] ARM: dts: omap: Add omap-usb2 dt data
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp. The information about this data node is availabe @
Documentation/devicetree/bindings/usb/usb-phy.txt
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index ffc7352..c829d7e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -438,6 +438,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2_phy: usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58;
+ ctrl-module = omap_control_usb;
+ };
};
timer1: timer@4a318000 {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/8] ARM: dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host mode.
The information about usb otg node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |1 +
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3-overo.dtsi |6 ++
arch/arm/boot/dts/omap3.dtsi | 12
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi | 13 +
arch/arm/boot/dts/twl4030.dtsi |2 +-
9 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
represents PERIPHERAL.
- power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
*/
ti,pulldowns = 0x03a1c4;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
twl_gpio {
ti,use-leds;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
twl_gpio {
ti,use-leds;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ usb_otg_hs: usb_otg_hs@480ab000 {
+ compatible = ti,omap3-musb;
+ reg = 0x480ab000 0x1000;
+ interrupts = 0 92 0x4, 0 93 0x4;
+ interrupt-names = mc, dma;
+ ti,hwmods = usb_otg_hs;
+ usb-phy = usb2_phy;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..612c9bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,9 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..582d7ee 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,9 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index c829d7e..5171739 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -542,5 +542,18 @@
reg-names = control_dev_conf, otghs_control;
ti,type = 1;
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ reg = 0x4a0ab000 0x7ff;
+ interrupts = 0 92 0x4, 0 93 0x4;
+ interrupt-names = mc, dma;
+ ti,hwmods = usb_otg_hs;
+ usb-phy = usb2_phy;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits
[PATCH 6/8] ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data
Add omap-usb3 and omap-usb2 data node in omap5 device tree file.
The information for the node added here is available @
Documentation/devicetree/bindings/usb/usb-phy.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 230b779..bd73257 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -511,6 +511,20 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp1;
+ usb2_phy: usb2phy@4a084000 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a084000 0x7c;
+ ctrl-module = omap_control_usb;
+ };
+
+ usb3_phy: usb3phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_usb;
+ };
};
};
};
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH/RFC] mmc: add DT bindings for more MMC capability flags
Hi, On Wed, Jan 23, 2013 at 04:45:11PM +, Guennadi Liakhovetski wrote: Many MMC capability flags are platform-dependent and are traditionally set in platform data. With DT often each such capability requires a special binding. Add bindings for MMC_CAP_SD_HIGHSPEED, MMC_CAP_MMC_HIGHSPEED and MMC_CAP_POWER_OFF_CARD capabilities. Also add code to DT parser to look up keep-power-in-suspend and enable-sdio-wakeup bindings and set MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ respectively, if found. I've Cc'd Arnd, who had some related comments a while back: https://lkml.org/lkml/2012/10/15/231 MMC_CAP_POWER_OFF_CARD sounds like something that can be selected in the driver by checking the compatible string or probing the hardware revision, and not something that should be taken directly from the dts where it could be completely invalid for the hardware. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Attention: contains new DT bindings, please, comment! Documentation/devicetree/bindings/mmc/mmc.txt |5 - drivers/mmc/core/host.c | 11 +++ 2 files changed, 15 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index e180892..92ec534c 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -25,8 +25,11 @@ Optional properties: - max-frequency: maximum operating clock frequency - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on this system, even if the controller claims it is. +- cap-sd-highspeed: SD high-speed timing is supported +- cap-mmc-highspeed: MMC high-speed timing is supported +- cap-power-off-card: powering off the card is safe -cd-inverted and wp-inverted properties are deprecated ans shouldn't be used, +cd-inverted and wp-inverted properties are deprecated and shouldn't be used, instead pleaseuse the OF_GPIO_ACTIVE_LOW flag in respective GPIO bindings. Note, that the default (as defined by the SDHCI standard) CD and WP polarity is active-low, so, OF_GPIO_ACTIVE_LOW should normally be set, and only be left diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index e4c1cbd..f3ea268 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -372,6 +372,17 @@ void mmc_of_parse(struct mmc_host *host) dev_err(host-parent, Failed to request WP GPIO: %d!\n, ret); } + + if (of_find_property(np, cap-sd-highspeed, len)) + host-caps |= MMC_CAP_SD_HIGHSPEED; + if (of_find_property(np, cap-mmc-highspeed, len)) + host-caps |= MMC_CAP_MMC_HIGHSPEED; + if (of_find_property(np, cap-power-off-card, len)) + host-caps |= MMC_CAP_POWER_OFF_CARD; + if (of_find_property(np, keep-power-in-suspend, len)) + host-pm_caps |= MMC_PM_KEEP_POWER; + if (of_find_property(np, enable-sdio-wakeup, len)) + host-pm_caps |= MMC_PM_WAKE_SDIO_IRQ; } EXPORT_SYMBOL(mmc_of_parse); -- 1.7.2.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss Thanks, Mark. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 4/5] ARM: dts: Add #dma-cells for generic dma binding support
On 02/06/2013 12:18 AM, Padmavathi Venna wrote:
This patch adds #dma-cells property to PL330 DMA controller
nodes for supporting generic dma dt bindings on samsung
exynos5250 platform.
The subject doesn't reflect this is for pl330.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
.../devicetree/bindings/dma/arm-pl330.txt | 15 +++
arch/arm/boot/dts/exynos5250.dtsi |4
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
index 36e27d5..1fdbff6 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl330.txt
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -8,6 +8,8 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
+ - #dma-cells: must be 1. used to represent the number of integer
+cells in the dmas property of client device.
This should be optional in the case of platforms supporting only memory
to memory xfers.
Rob
Optional properties:
- dma-coherent : Present if dma operations are coherent
@@ -18,16 +20,21 @@ Example:
compatible = arm,pl330, arm,primecell;
reg = 0x1268 0x1000;
interrupts = 99;
+ #dma-cells = 1;
};
Client drivers (device nodes requiring dma transfers from dev-to-mem or
-mem-to-dev) should specify the DMA channel numbers using a two-value pair
+mem-to-dev) should specify the DMA channel numbers and dma channel names
as shown below.
[property name] = [phandle of the dma controller] [dma request id];
+ [property name] = [dma channel name]
where 'dma request id' is the dma request number which is connected
- to the client controller. The 'property name' is recommended to be
- of the form name-dma-channel.
+ to the client controller. The 'property name' 'dmas' and 'dma-names'
+ as required by the generic dma device tree binding helpers. The dma
+ names correspond 1:1 with the dma request ids in the dmas property.
- Example: tx-dma-channel = pdma0 12;
+ Example: dmas = pdma0 12
+ pdma1 11;
+ dma-names = tx, rx;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index f50b4e8..724f5bd 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -312,24 +312,28 @@
compatible = arm,pl330, arm,primecell;
reg = 0x121A 0x1000;
interrupts = 0 34 0;
+ #dma-cells = 1;
};
pdma1: pdma@121B {
compatible = arm,pl330, arm,primecell;
reg = 0x121B 0x1000;
interrupts = 0 35 0;
+ #dma-cells = 1;
};
mdma0: mdma@1080 {
compatible = arm,pl330, arm,primecell;
reg = 0x1080 0x1000;
interrupts = 0 33 0;
+ #dma-cells = 1;
};
mdma1: mdma@11C1 {
compatible = arm,pl330, arm,primecell;
reg = 0x11C1 0x1000;
interrupts = 0 124 0;
+ #dma-cells = 1;
};
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board
(Adding mtd in Cc)
On Wed, Feb 06, 2013 at 07:54:31AM -0300, Ezequiel Garcia wrote:
Hi Gregory,
On Tue, Feb 05, 2013 at 09:17:02PM +0100, Gregory CLEMENT wrote:
On 02/05/2013 05:28 PM, Gregory CLEMENT wrote:
Hi Ezequiel,
On 02/05/2013 12:24 PM, Ezequiel Garcia wrote:
This patch adds an SPI master device node for Armada XP-GP board.
This master node is an SPI flash controller 'n25q128a13'.
Since there is no 'partitions' node declared, one full sized
partition named as the device will be created.
Cc: Gregory Clement gregory.clem...@free-electrons.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Lior Amsalem al...@marvell.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
This patch depends on:
1. Gregory's patch for Armada XP GP board:
arm: mvebu: support for the new Armada XP development
board(DB-MV784MP-GP)
2. My previous patch for SPI on Armada 370/XP:
arm: mvebu: Add support for SPI controller in Armada 370/XP
And don't forget to compile the SPI flash driver, CONFIG_MTD_M25P80=y
arch/arm/boot/dts/armada-xp-gp.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 3eea531..1c8afe2 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -97,5 +97,17 @@
phy = phy3;
phy-mode = rgmii-id;
};
+
+spi0: spi@d0010600 {
+status = okay;
+
+spi-flash@0 {
+#address-cells = 1;
+#size-cells = 1;
+compatible = n25q128a13;
+reg = 0; /* Chip select 0 */
+spi-max-frequency = 10800;
I had a remark about it, according to the datasheet, 108MHz is the
maximum frequency for the all the instructions but the READ
instruction. For the READ the maximum frequency is 54MHz. So I wonder
if we shouldn't use 5400 here.
Mmm... nice catch.
The mtd driver for the spi flash (m25p80) will use FAST_READ opcode
if CONFIG_M25PXX_USE_FAST_READ is selected, and this option
is selected by default.
However we cannot count on this option being selected, of course.
On the other side, after some testing with spi-max-frequency = 50 MHz
and also with spi-max-frequency = 108 MHz I'm seeing the flash often
(not always) stalls when trying to read the full device through dd:
/ # dd if=/dev/mtd0ro of=/dev/null
FWIW, using CONFIG_DETECT_HUNG_TASK we can see the hung happens inside
spi_sync().
It seems the completion handler is never called,
though I still don't understand under what circumstances that can happen.
dd D c02d79c8 0 964961 0x
[c02d79c8] (__schedule+0x1c8/0x504) from [c02d61d0]
(schedule_timeout+0x158/0x200)
[c02d61d0] (schedule_timeout+0x158/0x200) from [c02d7504]
(wait_for_common+0xe0/0x194)
[c02d7504] (wait_for_common+0xe0/0x194) from [c0215b44] (spi_sync+0x74/0x90)
[c0215b44] (spi_sync+0x74/0x90) from [c0214c80] (m25p80_read+0x100/0x17c)
[c0214c80] (m25p80_read+0x100/0x17c) from [c020edac] (mtd_read+0x8c/0xc0)
[c020edac] (mtd_read+0x8c/0xc0) from [c021404c] (mtdchar_read+0xe0/0x224)
[c021404c] (mtdchar_read+0xe0/0x224) from [c00c757c] (vfs_read+0xa4/0x148)
[c00c757c] (vfs_read+0xa4/0x148) from [c00c7664] (sys_read+0x44/0x78)
[c00c7664] (sys_read+0x44/0x78) from [c000ede0] (ret_fast_syscall+0x0/0x30)
--
Ezequiel GarcĂa, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH next] OF: convert devtree lock from rw_lock to raw spinlock
On 02/04/2013 10:05 AM, Paul Gortmaker wrote:
From: Thomas Gleixner t...@linutronix.de
With the locking cleanup in place (from OF: Fixup resursive
locking code paths), we can now do the conversion from the
rw_lock to a raw spinlock as required for preempt-rt.
The previous cleanup and the this conversion were originally
separate since they predated when mainline got raw spinlock (in
commit c2f21ce2e31286a locking: Implement new raw_spinlock).
So, at that point in time, the cleanup was considered plausible
for mainline, but not this conversion. In any case, we've kept
them separate as it makes for easier review and better bisection.
Signed-off-by: Thomas Gleixner t...@linutronix.de
[PG: taken from preempt-rt, update subject add a commit log]
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
[ Patch against linux-next of Feb4, where the recursive
locking cleanup currently is. Boot tested on ppc 8548,
compile tested for sparc and arm defconfigs ]
Applied.
Rob
arch/sparc/kernel/prom_common.c | 4 +-
drivers/of/base.c | 96
+++--
include/linux/of.h | 2 +-
3 files changed, 57 insertions(+), 45 deletions(-)
diff --git a/arch/sparc/kernel/prom_common.c b/arch/sparc/kernel/prom_common.c
index 1303021..9f20566 100644
--- a/arch/sparc/kernel/prom_common.c
+++ b/arch/sparc/kernel/prom_common.c
@@ -64,7 +64,7 @@ int of_set_property(struct device_node *dp, const char
*name, void *val, int len
err = -ENODEV;
mutex_lock(of_set_property_mutex);
- write_lock(devtree_lock);
+ raw_spin_lock(devtree_lock);
prevp = dp-properties;
while (*prevp) {
struct property *prop = *prevp;
@@ -91,7 +91,7 @@ int of_set_property(struct device_node *dp, const char
*name, void *val, int len
}
prevp = (*prevp)-next;
}
- write_unlock(devtree_lock);
+ raw_spin_unlock(devtree_lock);
mutex_unlock(of_set_property_mutex);
/* XXX Upate procfs if necessary... */
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 16ee7a0..4a2f58b 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -55,7 +55,7 @@ static DEFINE_MUTEX(of_aliases_mutex);
/* use when traversing tree through the allnext, child, sibling,
* or parent members of struct device_node.
*/
-DEFINE_RWLOCK(devtree_lock);
+DEFINE_RAW_SPINLOCK(devtree_lock);
int of_n_addr_cells(struct device_node *np)
{
@@ -188,10 +188,11 @@ struct property *of_find_property(const struct
device_node *np,
int *lenp)
{
struct property *pp;
+ unsigned long flags;
- read_lock(devtree_lock);
+ raw_spin_lock_irqsave(devtree_lock, flags);
pp = __of_find_property(np, name, lenp);
- read_unlock(devtree_lock);
+ raw_spin_unlock_irqrestore(devtree_lock, flags);
return pp;
}
@@ -209,13 +210,13 @@ struct device_node *of_find_all_nodes(struct
device_node *prev)
{
struct device_node *np;
- read_lock(devtree_lock);
+ raw_spin_lock(devtree_lock);
np = prev ? prev-allnext : of_allnodes;
for (; np != NULL; np = np-allnext)
if (of_node_get(np))
break;
of_node_put(prev);
- read_unlock(devtree_lock);
+ raw_spin_unlock(devtree_lock);
return np;
}
EXPORT_SYMBOL(of_find_all_nodes);
@@ -274,11 +275,12 @@ static int __of_device_is_compatible(const struct
device_node *device,
int of_device_is_compatible(const struct device_node *device,
const char *compat)
{
+ unsigned long flags;
int res;
- read_lock(devtree_lock);
+ raw_spin_lock_irqsave(devtree_lock, flags);
res = __of_device_is_compatible(device, compat);
- read_unlock(devtree_lock);
+ raw_spin_unlock_irqrestore(devtree_lock, flags);
return res;
}
EXPORT_SYMBOL(of_device_is_compatible);
@@ -340,13 +342,14 @@ EXPORT_SYMBOL(of_device_is_available);
struct device_node *of_get_parent(const struct device_node *node)
{
struct device_node *np;
+ unsigned long flags;
if (!node)
return NULL;
- read_lock(devtree_lock);
+ raw_spin_lock_irqsave(devtree_lock, flags);
np = of_node_get(node-parent);
- read_unlock(devtree_lock);
+ raw_spin_unlock_irqrestore(devtree_lock, flags);
return np;
}
EXPORT_SYMBOL(of_get_parent);
@@ -365,14 +368,15 @@ EXPORT_SYMBOL(of_get_parent);
struct device_node *of_get_next_parent(struct device_node *node)
{
struct device_node *parent;
+ unsigned long flags;
if (!node)
return NULL;
- read_lock(devtree_lock);
+ raw_spin_lock_irqsave(devtree_lock, flags);
parent = of_node_get(node-parent);
of_node_put(node);
- read_unlock(devtree_lock);
+
Re: [PATCH/RFC] mmc: add DT bindings for more MMC capability flags
Hi Mark On Wed, 6 Feb 2013, Mark Rutland wrote: Hi, On Wed, Jan 23, 2013 at 04:45:11PM +, Guennadi Liakhovetski wrote: Many MMC capability flags are platform-dependent and are traditionally set in platform data. With DT often each such capability requires a special binding. Add bindings for MMC_CAP_SD_HIGHSPEED, MMC_CAP_MMC_HIGHSPEED and MMC_CAP_POWER_OFF_CARD capabilities. Also add code to DT parser to look up keep-power-in-suspend and enable-sdio-wakeup bindings and set MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ respectively, if found. I've Cc'd Arnd, who had some related comments a while back: https://lkml.org/lkml/2012/10/15/231 MMC_CAP_POWER_OFF_CARD sounds like something that can be selected in the driver by checking the compatible string or probing the hardware revision, and not something that should be taken directly from the dts where it could be completely invalid for the hardware. Thank for pointing me out at that thread. However, I don't think MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware revisions. At least I haven't yet come across any sd/mmc hosts, that also supply card power. You could derive this flag from the presence of a regulator, capable of changing its status (switching on / off), but even then you're not guaranteed, that you actually can (and want to) power the card off at run-time - the regulator can be shared etc. So, an explicit flag is needed. Thanks Guennadi Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Attention: contains new DT bindings, please, comment! Documentation/devicetree/bindings/mmc/mmc.txt |5 - drivers/mmc/core/host.c | 11 +++ 2 files changed, 15 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index e180892..92ec534c 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -25,8 +25,11 @@ Optional properties: - max-frequency: maximum operating clock frequency - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on this system, even if the controller claims it is. +- cap-sd-highspeed: SD high-speed timing is supported +- cap-mmc-highspeed: MMC high-speed timing is supported +- cap-power-off-card: powering off the card is safe -cd-inverted and wp-inverted properties are deprecated ans shouldn't be used, +cd-inverted and wp-inverted properties are deprecated and shouldn't be used, instead pleaseuse the OF_GPIO_ACTIVE_LOW flag in respective GPIO bindings. Note, that the default (as defined by the SDHCI standard) CD and WP polarity is active-low, so, OF_GPIO_ACTIVE_LOW should normally be set, and only be left diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index e4c1cbd..f3ea268 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -372,6 +372,17 @@ void mmc_of_parse(struct mmc_host *host) dev_err(host-parent, Failed to request WP GPIO: %d!\n, ret); } + + if (of_find_property(np, cap-sd-highspeed, len)) + host-caps |= MMC_CAP_SD_HIGHSPEED; + if (of_find_property(np, cap-mmc-highspeed, len)) + host-caps |= MMC_CAP_MMC_HIGHSPEED; + if (of_find_property(np, cap-power-off-card, len)) + host-caps |= MMC_CAP_POWER_OFF_CARD; + if (of_find_property(np, keep-power-in-suspend, len)) + host-pm_caps |= MMC_PM_KEEP_POWER; + if (of_find_property(np, enable-sdio-wakeup, len)) + host-pm_caps |= MMC_PM_WAKE_SDIO_IRQ; } EXPORT_SYMBOL(mmc_of_parse); -- 1.7.2.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss Thanks, Mark. --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: pci: Keep pci_common_init() around after init
On Tue, Feb 05, 2013 at 09:41:48PM +0100, Thierry Reding wrote: On Wed, Jan 09, 2013 at 09:43:06PM +0100, Thierry Reding wrote: When using deferred driver probing, PCI host controller drivers may actually require this function after the init stage. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- arch/arm/kernel/bios32.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Russell, Can this patch and patch 7 (ARM: pci: Allow passing per-controller private data) of this series be applied for 3.9? Thomas uses them in his Marvell PCIe series as well and it would allow to reduce the complexity of the dependencies. It'll need to go into the patch system in that case... ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: pci: Keep pci_common_init() around after init
On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding thierry.red...@avionic-design.de wrote: When using deferred driver probing, PCI host controller drivers may actually require this function after the init stage. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de There seem to be a proliferation of these patches now. Isn't this just papering over the real problem? The discarding of __init sections need to happen *after* all deferred probes are complete, lest we have to remove *all* __init sections from *all* drivers in the kernel, don't we? Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/8] Remove fdtdump and use fdtgrep instead
Hi David, On Tue, Feb 5, 2013 at 11:16 PM, David Gibson da...@gibson.dropbear.id.au wrote: On Mon, Jan 21, 2013 at 12:59:21PM -0800, Simon Glass wrote: Since fdtgrep does everything that fdtdump does now, perhaps we should replace it with a symlink. Nack. The point of fdtdump is not simply to be a tool for dumping device trees - dtc -I dtb -O dts will do that already. The point is to be a really simple, independent implementation of dumping the tree, which can be used for analyzing bugs in the more complex tools. Sounds reasonable - I wasn't aware of that. I figured that if I didn't send a patch to implement dump with grep then someone would ask for it... But I agree it is nice to keep the simple code and I have made the output function common anyway. Regards, Simon -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH/RFC] mmc: add DT bindings for more MMC capability flags
On Wednesday 06 February 2013 17:25:42 Guennadi Liakhovetski wrote: Thank for pointing me out at that thread. However, I don't think MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware revisions. At least I haven't yet come across any sd/mmc hosts, that also supply card power. You could derive this flag from the presence of a regulator, capable of changing its status (switching on / off), but even then you're not guaranteed, that you actually can (and want to) power the card off at run-time - the regulator can be shared etc. So, an explicit flag is needed. It sounds like something that should be handled in a controller specific way I think. E.g. on SDHCI, there seems to always be a method to power down the card using the SDHCI_POWER_CONTROL register, even without any external regulators. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: pci: Keep pci_common_init() around after init
On Wednesday 06 February 2013 17:38:20 Linus Walleij wrote: On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding thierry.red...@avionic-design.de wrote: When using deferred driver probing, PCI host controller drivers may actually require this function after the init stage. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de There seem to be a proliferation of these patches now. Isn't this just papering over the real problem? The discarding of __init sections need to happen *after* all deferred probes are complete, lest we have to remove *all* __init sections from *all* drivers in the kernel, don't we? No, I think it's not quite that bad. I think the rule is still just that .probe() functions and anything called from them must not be __init. They used to be __devinit, which would cause problems with deferred probing on !HOTPLUG systems but that's gone in 3.9. Thierry's patch is just necessary because pci_common_init used to be called only from actual __init functions, and not it gets called from a .probe() function for the first time. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/2] Convert mcp23s08 to DT usage
From: Lars Poeschel poesc...@lemonage.de I wanted to use mcp23s08 driver with a device that boots using device tree. I modified the driver to allow the DT usage and tested with a mcp23017 which is a i2c device. I could not test the spi path, because I have no such device. Regards, Lars Lars Poeschel (2): gpio: mcp23s08: Allow -1 as a legal value for global gpio base gpio: mcp23s08: convert driver to DT .../devicetree/bindings/gpio/gpio-mcp23s08.txt | 36 drivers/gpio/gpio-mcp23s08.c | 95 ++-- include/linux/spi/mcp23s08.h |1 + 3 files changed, 126 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] gpio: mcp23s08: Allow -1 as a legal value for global gpio base
From: Lars Poeschel poesc...@lemonage.de
Explicitly allow -1 as a legal value for the
mcp23s08_platform_data-base. This is the special value lets the
kernel choose a valid global gpio base number.
Signed-off-by: Lars Poeschel poesc...@lemonage.de
---
drivers/gpio/gpio-mcp23s08.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-mcp23s08.c b/drivers/gpio/gpio-mcp23s08.c
index 3cea0ea..2afb828 100644
--- a/drivers/gpio/gpio-mcp23s08.c
+++ b/drivers/gpio/gpio-mcp23s08.c
@@ -483,7 +483,7 @@ static int mcp230xx_probe(struct i2c_client *client,
int status;
pdata = client-dev.platform_data;
- if (!pdata || !gpio_is_valid(pdata-base)) {
+ if ((!pdata || !gpio_is_valid(pdata-base)) pdata-base != -1) {
dev_dbg(client-dev, invalid or missing platform data\n);
return -EINVAL;
}
@@ -570,7 +570,7 @@ static int mcp23s08_probe(struct spi_device *spi)
type = spi_get_device_id(spi)-driver_data;
pdata = spi-dev.platform_data;
- if (!pdata || !gpio_is_valid(pdata-base)) {
+ if ((!pdata || !gpio_is_valid(pdata-base)) pdata-base != -1) {
dev_dbg(spi-dev, invalid or missing platform data\n);
return -EINVAL;
}
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] gpio: mcp23s08: convert driver to DT
From: Lars Poeschel poesc...@lemonage.de
This converts the mcp23s08 driver to be able to be used with device
tree.
There is a special mcp,chips property, that correspond to the chips
member of the struct mcp23s08_platform_data. It can be used for
multiple mcp23s08/mc23s17 on the same spi chipselect.
Signed-off-by: Lars Poeschel poesc...@lemonage.de
---
.../devicetree/bindings/gpio/gpio-mcp23s08.txt | 36
drivers/gpio/gpio-mcp23s08.c | 91 +++-
include/linux/spi/mcp23s08.h |1 +
3 files changed, 124 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
new file mode 100644
index 000..17eb669
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
@@ -0,0 +1,36 @@
+Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
+8-/16-bit I/O expander with serial interface (I2C/SPI)
+
+Required properties:
+- compatible : Should be
+- mcp,mcp23s08 for 8 GPIO SPI version
+- mcp,mcp23s17 for 16 GPIO SPI version
+- mcp,mcp23008 for 8 GPIO I2C version or
+- mcp,mcp23017 for 16 GPIO I2C version of the chip
+- #gpio-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify optional parameters (currently unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+- reg : For an address on its bus
+
+Optional device specific properties:
+- mcp,chips : This is a table with 2 columns and up to 8 entries. The first
column
+ is a is_present flag, that makes only sense for SPI chips. Multiple
+ chips can share the same chipselect. This flag can be 0 or 1 depending
+ if there is a chip at this address or not.
+ The second column is written to the GPPU register, selecting a 100k
+ pullup resistor or not. Setting a 1 is activating the pullup.
+ For I2C chips only the first line in this table is used. Further chips
+ are registered at different addresses at the I2C bus.
+
+Example:
+gpiom1: gpio@20 {
+compatible = mcp,mcp23017;
+gpio-controller;
+#gpio-cells = 2;
+reg = 0x20;
+ chips =
+ /* is_present pullups */
+ 1 0x07/* chip address 0 */
+ ;
+};
diff --git a/drivers/gpio/gpio-mcp23s08.c b/drivers/gpio/gpio-mcp23s08.c
index 2afb828..9c9bc1a 100644
--- a/drivers/gpio/gpio-mcp23s08.c
+++ b/drivers/gpio/gpio-mcp23s08.c
@@ -12,6 +12,8 @@
#include linux/spi/mcp23s08.h
#include linux/slab.h
#include asm/byteorder.h
+#include linux/of.h
+#include linux/of_device.h
/**
* MCP types supported by driver
@@ -473,16 +475,87 @@ fail:
/*--*/
+#ifdef CONFIG_OF
+static struct of_device_id mcp23s08_of_match[] = {
+#ifdef CONFIG_SPI_MASTER
+ {
+ .compatible = mcp,mcp23s08,
+ },
+ {
+ .compatible = mcp,mcp23s17,
+ },
+#endif
+#if IS_ENABLED(CONFIG_I2C)
+ {
+ .compatible = mcp,mcp23008,
+ },
+ {
+ .compatible = mcp,mcp23017,
+ },
+#endif
+ { },
+};
+MODULE_DEVICE_TABLE(of, mcp23s08_of_match);
+
+static struct mcp23s08_platform_data *
+ of_get_mcp23s08_pdata(struct device *dev)
+{
+ struct mcp23s08_platform_data *pdata;
+ struct device_node *np = dev-of_node;
+ u32 chips[sizeof(pdata-chip)];
+ int ret, i, j;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ pdata-base = -1;
+
+ for (i = ARRAY_SIZE(pdata-chip) * MCP23S08_CHIP_INFO_MEMBERS;
+ i 0; i -= MCP23S08_CHIP_INFO_MEMBERS) {
+ ret = of_property_read_u32_array(np, mcp,chips, chips, i);
+ if (ret == -EOVERFLOW)
+ continue;
+ break;
+ }
+ if (!ret) {
+ for (j = 0; j i / MCP23S08_CHIP_INFO_MEMBERS ; j++) {
+ pdata-chip[j].is_present =
+ chips[j * MCP23S08_CHIP_INFO_MEMBERS];
+ pdata-chip[j].pullups =
+ chips[j * MCP23S08_CHIP_INFO_MEMBERS + 1];
+ }
+ }
+
+ return pdata;
+}
+#else
+static struct mcp23s08_platform_data *
+ of_get_mcp23s08_pdata(struct i2c_client *client, int *chip_id)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
+
#if IS_ENABLED(CONFIG_I2C)
static int mcp230xx_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct mcp23s08_platform_data *pdata;
+ struct mcp23s08_platform_data *pdata = NULL;
struct mcp23s08 *mcp;
int status;
+ const struct
Re: [PATCH 06/14] ARM: pci: Keep pci_common_init() around after init
On Thu, Feb 7, 2013 at 1:54 AM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 06 February 2013 17:38:20 Linus Walleij wrote: On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding thierry.red...@avionic-design.de wrote: When using deferred driver probing, PCI host controller drivers may actually require this function after the init stage. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de There seem to be a proliferation of these patches now. Isn't this just papering over the real problem? The discarding of __init sections need to happen *after* all deferred probes are complete, lest we have to remove *all* __init sections from *all* drivers in the kernel, don't we? No, I think it's not quite that bad. I think the rule is still just that .probe() functions and anything called from them must not be __init. They used to be __devinit, which would cause problems with deferred probing on !HOTPLUG systems but that's gone in 3.9. Thierry's patch is just necessary because pci_common_init used to be called only from actual __init functions, and not it gets called from a .probe() function for the first time. Aha OK, then it feels much better now. However it leaves the question of how much __init, __initdata and __initconst we have littering around. Oh, well, we'll see I guess. Thanks, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND] media: rc: gpio-ir-recv: add support for device tree parsing
On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:
On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but optional properties allow linux specific support for rc
protocols and maps.
There was a similar patch sent by Matus Ujhelyi but that discussion
died after the first reviews.
Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
---
...
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 000..937760c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+ - compatible = gpio-ir-receiver;
+ - gpios: OF device-tree gpio specification.
+
+Optional properties:
+ - linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
+ rc protocols.
You likely need to specify in these bindings documentation which bit
corresponds to which RC protocol.
I'm not very familiar with the RC internals, but why it has to be
specified statically in the device tree, when decoding seems to be
mostly software defined ? I might be missing something though..
Sylwester,
I am not familiar with RC internals either. Maybe somebody with more
insight in media/rc can clarify the specific needs for the rc subsystem.
I was just transferring the DT support approach taken by gpio_keys to
gpio_ir_recv as I will be using it on mach-dove/cubox soon.
Couldn't this be configured at run time, with all protocols allowed
as the default ?
Actually, this is how the internal rc code works. If there is nothing
defined for allowed_protocols it assumes that all protocols are supported.
That is why above node properties are optional.
About the binding documentation of allowed_protocols, rc_map, or the
default behavior of current linux code, I don't think they will stay
in-sync for long. I'd rather completely remove those os-specific properties
from DT, but that hits the above statement about the needs of media/rc
subsystem.
+ - linux,rc-map-name: Linux specific remote control map name.
+
+Example node:
+
+ ir: ir-receiver {
+ compatible = gpio-ir-receiver;
+ gpios =gpio0 19 1;
+ /* allow rc protocols 1-4 */
+ linux,allowed-rc-protocols =0x 0x001e;
+ linux,rc-map-name = rc-rc6-mce;
+ };
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 4f71a7d..25e09fa 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -16,6 +16,7 @@
#includelinux/interrupt.h
#includelinux/gpio.h
#includelinux/slab.h
+#includelinux/of_gpio.h
#includelinux/platform_device.h
#includelinux/irq.h
#includemedia/rc-core.h
@@ -30,6 +31,63 @@ struct gpio_rc_dev {
bool active_low;
};
+#ifdef CONFIG_OF
+/*
+ * Translate OpenFirmware node properties into platform_data
+ */
+static struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ struct gpio_ir_recv_platform_data *pdata;
+ enum of_gpio_flags flags;
+ int gpio;
+
+ if (!np)
+ return ERR_PTR(-ENODEV);
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_find_property(np, gpios, NULL)) {
Why do you need this ? Isn't of_get_gpio_flags() sufficient ?
Ok. Now that you point at it, I agree that this check and the error
below is not needed. It is in gpio_keys, so that explains why it also
moved in here.
+ dev_err(dev, Found gpio-ir-receiver without gpios\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ gpio = of_get_gpio_flags(np, 0,flags);
+ if (gpio 0) {
+ if (gpio != -EPROBE_DEFER)
+ dev_err(dev, Failed to get gpio flags, error: %d\n,
+ gpio);
+ return ERR_PTR(gpio);
+ }
+
+ pdata-gpio_nr = gpio;
+ pdata-active_low = (flags OF_GPIO_ACTIVE_LOW) ? true : false;
+ pdata-map_name = of_get_property(np, linux,rc-map-name, NULL);
+ of_property_read_u64(np, linux,allowed-rc-protocols,
+ pdata-allowed_protos);
+
+ return pdata;
+}
+
+static struct of_device_id gpio_ir_recv_of_match[] = {
+ { .compatible = gpio-ir-receiver, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, gpio_ir_recv_of_match);
+
+#else /* !CONFIG_OF */
+
+static inline struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+#endif
Re: [PATCH 06/14] ARM: pci: Keep pci_common_init() around after init
On Wednesday 06 February 2013 18:07:53 Linus Walleij wrote: However it leaves the question of how much __init, __initdata and __initconst we have littering around. Oh, well, we'll see I guess. Actually, kbuild is pretty good at warning around the bugs there. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH/RFC] mmc: add DT bindings for more MMC capability flags
On Thu, 7 Feb 2013, Arnd Bergmann wrote: On Wednesday 06 February 2013 17:25:42 Guennadi Liakhovetski wrote: Thank for pointing me out at that thread. However, I don't think MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware revisions. At least I haven't yet come across any sd/mmc hosts, that also supply card power. You could derive this flag from the presence of a regulator, capable of changing its status (switching on / off), but even then you're not guaranteed, that you actually can (and want to) power the card off at run-time - the regulator can be shared etc. So, an explicit flag is needed. It sounds like something that should be handled in a controller specific way I think. E.g. on SDHCI, there seems to always be a method to power down the card using the SDHCI_POWER_CONTROL register, even without any external regulators. If I understand correctly, that register only controls card bus power. Further sdhci.c uses regulators (host-vmmc) to power up and down the card. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 2/2] iio: Add OF support
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
v4:
- Fixed wrong parameter to dummy of_iio_channel_get_by_name if CONFIG_OF is
undefined, and wrong return value.
- Initialize indio_dev-of_node in iio_device_register if the calling driver
neglected to do it.
v3:
- Cleaned up documentation (formatting, left-over clock references)
- Updated bindings description to permit sub-devices
- When searching for iio devices, use the pointer to the iio device type instead
of strcmp. Rename iio_dev_type to iio_device_type (to match other device
types) and make it global for that purpose. Check the OF node first, then the
device type, as the node is less likely to match.
- Move the common code in of_iio_channel_get and of_iio_channel_get_all to
__of_iio_channel_get.
- Return NULL from of_iio_channel_get_by_name if nothing is found, or
an error if there is a problem with consistency or if the provider device is
not yet available.
- In iio_channel_get, return if of_iio_channel_get_by_name() returns a channel
or an error, and continue otherwise.
v2:
- Rebased to iio/togreg
- Documentation update per feedback
- Dropped io-channel-output-names from the bindings document. The property is
not used in the code, and it is not entirely clear what it would be used for.
If there is a need for it, we can add it back in later on.
- Don't export OF specific API calls
- For OF support, no longer depend on iio_map
- Add #ifdef CONFIG_OF where appropriate, and ensure that the code still builds
if it is not selected.
- Change iio_channel_get to take device pointer as argument instead of device
name. Retain old API as of_iio_channel_get_sys.
- iio_channel_get now works for both OF and non-OF configurations
- Use regulator to get vref for max1363 driver.
drivers/iio/iio_core.h |1 +
drivers/iio/industrialio-core.c|8 +-
drivers/iio/inkern.c | 171
4 files changed, 268 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
b/Documentation/devicetree/bindings/iio/iio-bindings.txt
new file mode 100644
index 000..2475c2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,90 @@
+This binding is a work-in-progress. It is derived from clock bindings,
+and based on suggestions from Lars-Peter Clausen [1].
+
+Sources of IIO channels can be represented by any node in the device
+tree. Those nodes are designated as IIO providers. IIO consumer
+nodes use a phandle and IIO specifier pair to connect IIO provider
+outputs to IIO inputs. Similar to the gpio specifiers, an IIO
+specifier is an array of one or more cells identifying the IIO
+output on a device. The length of an IIO specifier is defined by the
+value of a #io-channel-cells property in the IIO provider node.
+
+[1] http://marc.info/?l=linux-iiom=135902119507483w=2
+
+==IIO providers==
+
+Required properties:
+#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
+ with a single IIO output and 1 for nodes with multiple
+ IIO outputs.
+
+Example for a simple configuration with no trigger:
+
+ adc: voltage-sensor@35 {
+ compatible = maxim,max1139;
+ reg = 0x35;
+ #io-channel-cells = 1;
+ };
+
+Example for a configuration with trigger:
+
+ adc@35 {
+ compatible = maxim,max1139;
+ reg = 0x35;
+
+ adc: iio-device {
+ #io-channel-cells = 1;
+ };
+ trigger: iio-trigger {
+ #io-channel-cells = 1;
+ };
+ };
+
+==IIO consumers==
+
+Required properties:
+io-channels: List of phandle and IIO specifier pairs, one pair
+ for each IIO input to the device. Note: if the
+ IIO provider specifies '0' for #io-channel-cells,
+ then only the phandle portion of the pair will appear.
+
+Optional properties:
+io-channel-names:
+ List of IIO input name strings sorted in the same
+ order as the io-channels property. Consumers drivers
+ will use io-channel-names to match IIO input names
+ with IIO specifiers.
+io-channel-ranges:
+ Empty property indicating that child nodes can inherit named
+ IIO channels from this node. Useful for bus nodes to provide
+ and IIO channel to their children.
+
+For example:
+
+ device {
+ io-channels = adc 1, ref 0;
+ io-channel-names = vcc, vdd;
+ };
+
+This represents a device with two IIO inputs, named vcc and vdd.
+The vcc channel is connected to output 1 of the adc device, and the
+vdd channel is connected to
Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
On Tue, Feb 5, 2013 at 6:56 PM, 김승우 sw0312@samsung.com wrote:
On 2013년 02월 06일 09:56, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
Binding looks sane to me.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
#ifdef CONFIG_OF
static struct of_device_id hdmi_match_types[] = {
{
- .compatible = samsung,exynos5-hdmi,
- .data = (void *)HDMI_TYPE14,
+ .compatible = samsung,exynos4-hdmi,
}, {
/* end node */
}
Why not fill in all the base compatible values there (I think you need
this anyway so that DTs don't all have to be compatible with
samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
values, then ...
At the moment, all DTs have to be compatible with exynos4-hdmi since
it provides the base for the current driver. The driver uses 4210 and
4212 to differentiate between different register addresses and
features, but most things are just exynos4-hdmi compatible.
The DT nodes should include only the compatible values that the HW is
actually compatible with. If the HW isn't compatible with exynos4-hdmi,
that value shouldn't be in the compatible property, but instead whatever
the base value that the HW really is compatible with. The driver can
support multiple base compatible values from this table.
All devices that use this driver are compatible, at some level, with
exynos4-hdmi, so I think its usage is correct here.
@@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device
*pdev)
+
+ if (of_device_is_compatible(dev-of_node,
samsung,exynos4210-hdmi))
+ hdata-version |= HDMI_VER_EXYNOS4210;
+ if (of_device_is_compatible(dev-of_node,
samsung,exynos4212-hdmi))
+ hdata-version |= HDMI_VER_EXYNOS4212;
+ if (of_device_is_compatible(dev-of_node,
samsung,exynos5250-hdmi))
+ hdata-version |= HDMI_VER_EXYNOS5250;
Instead of that, do roughly:
match = of_match_device(hdmi_match_types, pdev-dev);
if (match)
hdata-version |= (int)match-data;
That way, it's all table-based. Any future additions to
hdmi_match_types[] won't require another if statement to be added to
probe().
I don't think it's that easy. of_match_device returns the first match
from the device table, so I'd still need to iterate through the
matches. I could still break this out into a table, but I don't think
of_match_device is the right way to probe it.
You shouldn't have to iterate over multiple matches. of_match_device()
is supposed to return the match for the first entry in the compatible
property, then if there was no match, move on to looking at the next
entry in the compatible property, etc. In practice, I think it's still
not implemented quite correctly for this, but you can make it work by
putting the newest compatible value first in the match table.
I think the only way that works is if you hardcode the compatible
versions in the driver, like this:
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos5250-hdmi,
.data = (void *)(HDMI_VER_EXYNOS5250 | HDMI_VER_EXYNOS4212);
}, {
.compatible = samsung,exynos4212-hdmi,
.data = (void *)HDMI_VER_EXYNOS4212;
}, {
.compatible = samsung,exynos4210-hdmi,
.data = (void *)HDMI_VER_EXYNOS4210;
}, {
/* end node */
}
};
Actually, I can't understand why there is HDMI_VER_EXYNOS5250 because it
is not used anywhere in your patch. I'm not sure I missed something from
your v2 patch thread, but to me, just hdmi version or hdmi ip version
can be used as data field of struct of_device_id as like your v2 patch
set. and then of_match_device() can be used without | in data field.
If I have missed some point from v2 thread, please let me know.
Exactly. I think that's causing some of this confusion. It'd be easier
to just leave any 5250 reference out of this patch. The _only_ place
5250 should be used now is in the 5250 dtsi file, as the most specific
compatible field. Compatible there should be, in order:
5250, 4212, 4
(or maybe not 4 at all, if the driver can't successfully drive the
hardware in degraded mode using the HDMI 1.3 register maps, etc).
... But there's no need to
Re: [PATCH 1/2] iio: Update iio_channel_get API to use consumer device pointer as argument
On 02/04/2013 11:57 PM, Chanwoo Choi wrote:
On 02/05/2013 05:26 AM, Guenter Roeck wrote:
For iio_channel_get to work with OF based configurations, it needs the
consumer device pointer instead of the consumer device name as argument.
Signed-off-by: Guenter Roeck li...@roeck-us.net
Applied to togreg branch of iio.git.
Thanks all.
I'll hold off on taking the actual device tree patch (2 of this series)
for a day or two to give more time for comments on that.
---
drivers/extcon/extcon-adc-jack.c|3 +--
drivers/iio/inkern.c| 11 ++-
drivers/power/generic-adc-battery.c |4 ++--
drivers/power/lp8788-charger.c |8
include/linux/iio/consumer.h|5 +++--
5 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c
b/drivers/extcon/extcon-adc-jack.c
index eda2a1a..d0233cd 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -135,8 +135,7 @@ static int adc_jack_probe(struct platform_device *pdev)
;
data-num_conditions = i;
-data-chan = iio_channel_get(dev_name(pdev-dev),
-pdata-consumer_channel);
+data-chan = iio_channel_get(pdev-dev, pdata-consumer_channel);
if (IS_ERR(data-chan)) {
err = PTR_ERR(data-chan);
goto out;
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index c42aba6..b289915 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -93,7 +93,8 @@ static const struct iio_chan_spec
Ack for drivers/extcon .
Acked-by: Chanwoo Choi cw00.c...@samsung.com
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-iio 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/14] ARM: pci: Keep pci_common_init() around after init
On Wed, Feb 06, 2013 at 04:30:41PM +, Russell King - ARM Linux wrote: On Tue, Feb 05, 2013 at 09:41:48PM +0100, Thierry Reding wrote: On Wed, Jan 09, 2013 at 09:43:06PM +0100, Thierry Reding wrote: When using deferred driver probing, PCI host controller drivers may actually require this function after the init stage. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- arch/arm/kernel/bios32.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Russell, Can this patch and patch 7 (ARM: pci: Allow passing per-controller private data) of this series be applied for 3.9? Thomas uses them in his Marvell PCIe series as well and it would allow to reduce the complexity of the dependencies. It'll need to go into the patch system in that case... Alright, I'll submit them to the patch system. Thanks. Thierry pgpTiJWLJ31Cd.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/2] iio: Add OF support
On 02/06/2013 06:29 PM, Guenter Roeck wrote:
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck li...@roeck-us.net
looks good to me. Couple of little queries inline.
---
v4:
- Fixed wrong parameter to dummy of_iio_channel_get_by_name if CONFIG_OF is
undefined, and wrong return value.
- Initialize indio_dev-of_node in iio_device_register if the calling driver
neglected to do it.
v3:
- Cleaned up documentation (formatting, left-over clock references)
- Updated bindings description to permit sub-devices
- When searching for iio devices, use the pointer to the iio device type
instead
of strcmp. Rename iio_dev_type to iio_device_type (to match other device
types) and make it global for that purpose. Check the OF node first, then
the
device type, as the node is less likely to match.
- Move the common code in of_iio_channel_get and of_iio_channel_get_all to
__of_iio_channel_get.
- Return NULL from of_iio_channel_get_by_name if nothing is found, or
an error if there is a problem with consistency or if the provider device is
not yet available.
- In iio_channel_get, return if of_iio_channel_get_by_name() returns a channel
or an error, and continue otherwise.
v2:
- Rebased to iio/togreg
- Documentation update per feedback
- Dropped io-channel-output-names from the bindings document. The property is
not used in the code, and it is not entirely clear what it would be used
for.
If there is a need for it, we can add it back in later on.
- Don't export OF specific API calls
- For OF support, no longer depend on iio_map
- Add #ifdef CONFIG_OF where appropriate, and ensure that the code still
builds
if it is not selected.
- Change iio_channel_get to take device pointer as argument instead of device
name. Retain old API as of_iio_channel_get_sys.
- iio_channel_get now works for both OF and non-OF configurations
- Use regulator to get vref for max1363 driver.
drivers/iio/iio_core.h |1 +
drivers/iio/industrialio-core.c|8 +-
drivers/iio/inkern.c | 171
4 files changed, 268 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
b/Documentation/devicetree/bindings/iio/iio-bindings.txt
new file mode 100644
index 000..2475c2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,90 @@
+This binding is a work-in-progress. It is derived from clock bindings,
+and based on suggestions from Lars-Peter Clausen [1].
+
+Sources of IIO channels can be represented by any node in the device
+tree. Those nodes are designated as IIO providers. IIO consumer
+nodes use a phandle and IIO specifier pair to connect IIO provider
+outputs to IIO inputs. Similar to the gpio specifiers, an IIO
+specifier is an array of one or more cells identifying the IIO
+output on a device. The length of an IIO specifier is defined by the
+value of a #io-channel-cells property in the IIO provider node.
+
+[1] http://marc.info/?l=linux-iiom=135902119507483w=2
+
+==IIO providers==
+
+Required properties:
+#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
+with a single IIO output and 1 for nodes with multiple
+IIO outputs.
+
+Example for a simple configuration with no trigger:
+
+ adc: voltage-sensor@35 {
+ compatible = maxim,max1139;
+ reg = 0x35;
+ #io-channel-cells = 1;
+ };
+
+Example for a configuration with trigger:
+
+ adc@35 {
+ compatible = maxim,max1139;
+ reg = 0x35;
+
+ adc: iio-device {
+ #io-channel-cells = 1;
+ };
+ trigger: iio-trigger {
+ #io-channel-cells = 1;
Why would the trigger have channel-cells?
So far we don't have any device tree stuff for the triggers.
+ };
+ };
+
+==IIO consumers==
+
+Required properties:
+io-channels: List of phandle and IIO specifier pairs, one pair
+ for each IIO input to the device. Note: if the
+ IIO provider specifies '0' for #io-channel-cells,
+ then only the phandle portion of the pair will appear.
+
+Optional properties:
+io-channel-names:
+ List of IIO input name strings sorted in the same
+ order as the io-channels property. Consumers drivers
+ will use io-channel-names to match IIO input names
+ with IIO specifiers.
+io-channel-ranges:
+ Empty property indicating that child nodes can inherit named
+ IIO channels from this node. Useful for bus nodes to provide
+ and IIO channel to their children.
+
+For example:
+
+ device
[PATCH v3 06/13] mmc: tmio-mmc: define device-tree bindings
Define device-tree bindings for the tmio-mmc driver to be able to specify parameters, currently provided in platform data. Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v3: make the property to set TMIO_MMC_SDIO_IRQ global Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/tmio_mmc.txt diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt new file mode 100644 index 000..5762a55 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -0,0 +1,15 @@ +* Toshiba Mobile IO SD/MMC controller + +The tmio-mmc driver doesn't probe its devices actively, instead its binding to +devices is managed by either MFD drivers or by the sh_mobile_sdhi platform +driver. Those drivers supply the tmio-mmc driver with platform data, that either +describe hardware capabilities, known to them, or are obtained by them from +their own platform data or from their DT information. In the latter case all +compulsory and any optional properties, common to all SD/MMC drivers, as +described in mmc.txt, should or can be used. Additionally the following optional +bindings can be used. They set respective TMIO_MMC_* flags. + +Optional properties: +- toshiba,mmc-wrprotect-disable: set TMIO_MMC_WRPROTECT_DISABLE flag +- toshiba,mmc-blksz-2bytes : set TMIO_MMC_BLKSZ_2BYTES +- toshiba,mmc-has-idle-wait: set TMIO_MMC_HAS_IDLE_WAIT -- 1.7.2.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 01/13] mmc: sdhi, tmio: only check flags in tmio-mmc driver proper
tmio-mmc platform flags can be set by various means, including caller
drivers and device-tree bindings, therefore it is better to only check
them in the tmio-mmc driver proper, not in caller drivers themselves.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/sh_mobile_sdhi.c |3 +--
drivers/mmc/host/tmio_mmc_pio.c |3 +++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index 524a7f7..e0ca0ab 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -153,10 +153,9 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
mmc_data-clk_enable = sh_mobile_sdhi_clk_enable;
mmc_data-clk_disable = sh_mobile_sdhi_clk_disable;
mmc_data-capabilities = MMC_CAP_MMC_HIGHSPEED;
+ mmc_data-write16_hook = sh_mobile_sdhi_write16_hook;
if (p) {
mmc_data-flags = p-tmio_flags;
- if (mmc_data-flags TMIO_MMC_HAS_IDLE_WAIT)
- mmc_data-write16_hook = sh_mobile_sdhi_write16_hook;
mmc_data-ocr_mask = p-tmio_ocr_mask;
mmc_data-capabilities |= p-tmio_caps;
mmc_data-capabilities2 |= p-tmio_caps2;
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 0f992e9..b25adb4 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -928,6 +928,9 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
int ret;
u32 irq_mask = TMIO_MASK_CMD;
+ if (!(pdata-flags TMIO_MMC_HAS_IDLE_WAIT))
+ pdata-write16_hook = NULL;
+
res_ctl = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res_ctl)
return -EINVAL;
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 05/13] mmc: sh-mmcif: use mmc_of_parse() to parse standard MMC DT bindings
Use mmc_of_parse() to get interface capability flags and used GPIOs from device-tree bindings. Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v3: updated on top of mmc: sh_mmcif: Avoid unnecessary mmc_delay() at mmc_card_sleepawake() drivers/mmc/host/sh_mmcif.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c index 7d05852..adb4f68 100644 --- a/drivers/mmc/host/sh_mmcif.c +++ b/drivers/mmc/host/sh_mmcif.c @@ -1331,6 +1331,7 @@ static int sh_mmcif_probe(struct platform_device *pdev) ret = -ENOMEM; goto ealloch; } + mmc_of_parse(mmc); host= mmc_priv(mmc); host-mmc = mmc; host-addr = reg; @@ -1343,7 +1344,7 @@ static int sh_mmcif_probe(struct platform_device *pdev) mmc-ops = sh_mmcif_ops; sh_mmcif_init_ocr(host); - mmc-caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_WAIT_WHILE_BUSY; + mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_WAIT_WHILE_BUSY; if (pd pd-caps) mmc-caps |= pd-caps; mmc-max_segs = 32; -- 1.7.2.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 09/13] mmc: sh_mobile_sdhi: use managed resource allocations
Use managed allocations to get memory, clock and interrupts . This
significantly simplifies clean up paths.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/sh_mobile_sdhi.c | 57 +
1 files changed, 14 insertions(+), 43 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index 17d5778..e095d5c 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -126,7 +126,7 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
int irq, ret, i = 0;
bool multiplexed_isr = true;
- priv = kzalloc(sizeof(struct sh_mobile_sdhi), GFP_KERNEL);
+ priv = devm_kzalloc(pdev-dev, sizeof(struct sh_mobile_sdhi),
GFP_KERNEL);
if (priv == NULL) {
dev_err(pdev-dev, kzalloc failed\n);
return -ENOMEM;
@@ -138,11 +138,11 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
if (p-init) {
ret = p-init(pdev, sdhi_ops);
if (ret)
- goto einit;
+ return ret;
}
}
- priv-clk = clk_get(pdev-dev, NULL);
+ priv-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(priv-clk)) {
ret = PTR_ERR(priv-clk);
dev_err(pdev-dev, cannot get clock: %d\n, ret);
@@ -197,33 +197,33 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
irq = platform_get_irq_byname(pdev, SH_MOBILE_SDHI_IRQ_CARD_DETECT);
if (irq = 0) {
multiplexed_isr = false;
- ret = request_irq(irq, tmio_mmc_card_detect_irq, 0,
+ ret = devm_request_irq(pdev-dev, irq,
tmio_mmc_card_detect_irq, 0,
dev_name(pdev-dev), host);
if (ret)
- goto eirq_card_detect;
+ goto eirq;
}
irq = platform_get_irq_byname(pdev, SH_MOBILE_SDHI_IRQ_SDIO);
if (irq = 0) {
multiplexed_isr = false;
- ret = request_irq(irq, tmio_mmc_sdio_irq, 0,
+ ret = devm_request_irq(pdev-dev, irq, tmio_mmc_sdio_irq, 0,
dev_name(pdev-dev), host);
if (ret)
- goto eirq_sdio;
+ goto eirq;
}
irq = platform_get_irq_byname(pdev, SH_MOBILE_SDHI_IRQ_SDCARD);
if (irq = 0) {
multiplexed_isr = false;
- ret = request_irq(irq, tmio_mmc_sdcard_irq, 0,
+ ret = devm_request_irq(pdev-dev, irq, tmio_mmc_sdcard_irq, 0,
dev_name(pdev-dev), host);
if (ret)
- goto eirq_sdcard;
+ goto eirq;
} else if (!multiplexed_isr) {
dev_err(pdev-dev,
Principal SD-card IRQ is missing among named
interrupts\n);
ret = irq;
- goto eirq_sdcard;
+ goto eirq;
}
if (multiplexed_isr) {
@@ -232,15 +232,15 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
if (irq 0)
break;
i++;
- ret = request_irq(irq, tmio_mmc_irq, 0,
+ ret = devm_request_irq(pdev-dev, irq, tmio_mmc_irq, 0,
dev_name(pdev-dev), host);
if (ret)
- goto eirq_multiplexed;
+ goto eirq;
}
/* There must be at least one IRQ source */
if (!i)
- goto eirq_multiplexed;
+ goto eirq;
}
dev_info(pdev-dev, %s base at 0x%08lx clock rate %u MHz\n,
@@ -250,28 +250,12 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
return ret;
-eirq_multiplexed:
- while (i--) {
- irq = platform_get_irq(pdev, i);
- free_irq(irq, host);
- }
-eirq_sdcard:
- irq = platform_get_irq_byname(pdev, SH_MOBILE_SDHI_IRQ_SDIO);
- if (irq = 0)
- free_irq(irq, host);
-eirq_sdio:
- irq = platform_get_irq_byname(pdev, SH_MOBILE_SDHI_IRQ_CARD_DETECT);
- if (irq = 0)
- free_irq(irq, host);
-eirq_card_detect:
+eirq:
tmio_mmc_host_remove(host);
eprobe:
- clk_put(priv-clk);
eclkget:
if (p p-cleanup)
p-cleanup(pdev);
-einit:
- kfree(priv);
return ret;
}
@@ -279,26 +263,13 @@ static int sh_mobile_sdhi_remove(struct platform_device
*pdev)
{
struct mmc_host *mmc = platform_get_drvdata(pdev);
struct tmio_mmc_host *host = mmc_priv(mmc);
- struct sh_mobile_sdhi *priv =
[PATCH v3 02/13] mmc: detailed definition of CD and WP MMC line polarities in DT
Clarify ways to specify write-protect and card-detect MMC lines in FDT.
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v3: {wp,cd}-inverted properties can now be used together with GPIO
binding flags. A detailed explanation added.
Documentation/devicetree/bindings/mmc/mmc.txt | 43 +++-
1 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 34f28ed..51dd64f 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -18,12 +18,51 @@ Only one of the properties in this section should be
supplied:
Optional properties:
- wp-gpios: Specify GPIOs for write protection, see gpio binding
-- cd-inverted: when present, polarity on the cd gpio line is inverted
-- wp-inverted: when present, polarity on the wp gpio line is inverted
+- cd-inverted: when present, polarity on the CD line is inverted. See the note
+ below for the case, when a GPIO is used for the CD line
+- wp-inverted: when present, polarity on the WP line is inverted. See the note
+ below for the case, when a GPIO is used for the WP line
- max-frequency: maximum operating clock frequency
- no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
this system, even if the controller claims it is.
+*NOTE* on CD and WP polarity. As of 3.8, SD/MMC drivers parse their DT nodes
+each in its own way, including calculation of CD and WP polarities. Our goal is
+to implement a common MMC DT parser and convert all drivers to using it. For
+this we also have to fix the meaning of the normal and inverted line
levels.
+We choose to follow the SDHCI standard, which specifies both those lines as
+active low. To deliver line polarity to drivers the parser will set
+MMC_CAP2_CD_ACTIVE_HIGH and / or MMC_CAP2_RO_ACTIVE_HIGH capabilities.
+
+CD and WP lines can be implemented on the hardware in one of two ways: as
GPIOs,
+specified in cd-gpios and wp-gpios properties, or as dedicated pins. Polarity
of
+dedicated pins can be specified, using *-inverted properties. GPIO polarity can
+also be specified using the OF_GPIO_ACTIVE_LOW flag. This creates an ambiguity
+in the latter case. So far there are no drivers, that evaluate both these
+possibilities. Also, all .dts files only use one of them. Boards with mmc
+devices, whose drivers use *-inverted properties, leave the OF_GPIO_ACTIVE_LOW
+flag clear (which is actually usually wrong, since it means active high, i.e.
+inverted.) OTOH, boards with mmc devices, whose drivers use the
+OF_GPIO_ACTIVE_LOW flag, never specify *-inverted properties. This means, that
+the safest way to implement a common MMC DT parser is by using the XOR logic,
as
+in
+
+ explicit_inv_cd = !!of_find_property(np, cd-inverted, len);
+
+ cd_gpio = of_get_named_gpio_flags(np, cd-gpios, 0, flags);
+ if (gpio_is_valid(cd_gpio) !(flags OF_GPIO_ACTIVE_LOW))
+ gpio_inv_cd = 1;
+ else
+ gpio_inv_cd = 0;
+
+ if (gpio_inv_cd ^ explicit_inv_cd)
+ host-caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+
+Similarly for WP. This way drivers, currently only interpreting *-inverted
+properties with .dts files always having cd-gpios' OF_GPIO_ACTIVE_LOW flag
+clear, will have to invert the MMC_CAP2_CD_ACTIVE_HIGH capability, but at least
+this capability will not miss any toggles.
+
Optional SDIO properties:
- keep-power-in-suspend: Preserves card power during a suspend/resume cycle
- enable-sdio-wakeup: Enables wake up of host system on SDIO IRQ assertion
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 13/13] mmc: tmio: add barriers to IO operations
Without barriers SDIO operations fail with runtime PM enabled.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Paul Mundt let...@linux-sh.org
---
v3: use iowrite16_rep() and ioread16_rep() for consistency.
drivers/mmc/host/tmio_mmc.h | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index d857f5c..a10ebd0 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -159,19 +159,20 @@ int tmio_mmc_host_runtime_resume(struct device *dev);
static inline u16 sd_ctrl_read16(struct tmio_mmc_host *host, int addr)
{
- return readw(host-ctl + (addr host-bus_shift));
+ return ioread16(host-ctl + (addr host-bus_shift));
}
static inline void sd_ctrl_read16_rep(struct tmio_mmc_host *host, int addr,
u16 *buf, int count)
{
- readsw(host-ctl + (addr host-bus_shift), buf, count);
+ wmb();
+ ioread16_rep(host-ctl + (addr host-bus_shift), buf, count);
}
static inline u32 sd_ctrl_read32(struct tmio_mmc_host *host, int addr)
{
- return readw(host-ctl + (addr host-bus_shift)) |
- readw(host-ctl + ((addr + 2) host-bus_shift)) 16;
+ return ioread16(host-ctl + (addr host-bus_shift)) |
+ ioread16(host-ctl + ((addr + 2) host-bus_shift)) 16;
}
static inline void sd_ctrl_write16(struct tmio_mmc_host *host, int addr, u16
val)
@@ -181,19 +182,20 @@ static inline void sd_ctrl_write16(struct tmio_mmc_host
*host, int addr, u16 val
*/
if (host-pdata-write16_hook host-pdata-write16_hook(host, addr))
return;
- writew(val, host-ctl + (addr host-bus_shift));
+ iowrite16(val, host-ctl + (addr host-bus_shift));
}
static inline void sd_ctrl_write16_rep(struct tmio_mmc_host *host, int addr,
u16 *buf, int count)
{
- writesw(host-ctl + (addr host-bus_shift), buf, count);
+ iowrite16_rep(host-ctl + (addr host-bus_shift), buf, count);
+ wmb();
}
static inline void sd_ctrl_write32(struct tmio_mmc_host *host, int addr, u32
val)
{
- writew(val, host-ctl + (addr host-bus_shift));
- writew(val 16, host-ctl + ((addr + 2) host-bus_shift));
+ iowrite16(val, host-ctl + (addr host-bus_shift));
+ iowrite16(val 16, host-ctl + ((addr + 2) host-bus_shift));
}
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 03/13] mmc: provide a standard MMC device-tree binding parser centrally
MMC defines a number of standard DT bindings. Having each driver parse
them individually adds code redundancy and is error prone. Provide a
standard function to unify the parsing. After all drivers are converted
to using it instead of their own parsers, this function can be integrated
into mmc_alloc_host().
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v3: updated to match v3 of mmc.txt disambiguation in patch 02/13.
drivers/mmc/core/host.c | 90 ++
include/linux/mmc/host.h |1 +
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index ee2e16b..c412612 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -15,6 +15,8 @@
#include linux/device.h
#include linux/err.h
#include linux/idr.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/pagemap.h
#include linux/export.h
#include linux/leds.h
@@ -23,6 +25,7 @@
#include linux/mmc/host.h
#include linux/mmc/card.h
+#include linux/mmc/slot-gpio.h
#include core.h
#include host.h
@@ -294,6 +297,93 @@ static inline void mmc_host_clk_sysfs_init(struct mmc_host
*host)
#endif
+void mmc_of_parse(struct mmc_host *host)
+{
+ struct device_node *np;
+ u32 bus_width;
+ bool explicit_inv_wp, gpio_inv_wp = false;
+ enum of_gpio_flags flags;
+ int len, ret, gpio;
+
+ if (!host-parent || !host-parent-of_node)
+ return;
+
+ np = host-parent-of_node;
+
+ if (of_property_read_u32_array(np, bus-width, bus_width, 1) 0) {
+ dev_err(host-parent,
+ Compulsory \bus-width\ property is missing!\n);
+ return;
+ }
+
+ switch (bus_width) {
+ case 8:
+ host-caps |= MMC_CAP_8_BIT_DATA;
+ /* Hosts, capable of 8-bit transfers can also do 4 bits */
+ case 4:
+ host-caps |= MMC_CAP_4_BIT_DATA;
+ break;
+ case 1:
+ break;
+ default:
+ dev_err(host-parent,
+ Invalid \bus-width\ value %ud!\n, bus_width);
+ }
+
+ /* Optional property: ignore errors */
+ of_property_read_u32_array(np, max-frequency, host-f_max, 1);
+
+ /* Both CD and WP pins are by default active low */
+
+ /* Parse Card Detection */
+ if (of_find_property(np, non-removable, len)) {
+ host-caps |= MMC_CAP_NONREMOVABLE;
+ } else {
+ bool explicit_inv_cd, gpio_inv_cd = false;
+
+ explicit_inv_cd = !!of_find_property(np, cd-inverted, len);
+
+ if (of_find_property(np, broken-cd, len))
+ host-caps |= MMC_CAP_NEEDS_POLL;
+
+ gpio = of_get_named_gpio_flags(np, cd-gpios, 0, flags);
+ if (gpio_is_valid(gpio)) {
+ if (!(flags OF_GPIO_ACTIVE_LOW))
+ gpio_inv_cd = true;
+
+ ret = mmc_gpio_request_cd(host, gpio);
+ if (ret 0)
+ dev_err(host-parent,
+ Failed to request CD GPIO #%d: %d!\n,
+ gpio, ret);
+ else
+ dev_info(host-parent, Got CD GPIO #%d.\n,
+gpio);
+ }
+
+ if (explicit_inv_cd ^ gpio_inv_cd)
+ host-caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+ }
+
+ /* Parse Write Protection */
+ explicit_inv_wp = !!of_find_property(np, wp-inverted, len);
+
+ gpio = of_get_named_gpio_flags(np, wp-gpios, 0, flags);
+ if (gpio_is_valid(gpio)) {
+ if (!(flags OF_GPIO_ACTIVE_LOW))
+ gpio_inv_wp = true;
+
+ ret = mmc_gpio_request_ro(host, gpio);
+ if (ret 0)
+ dev_err(host-parent,
+ Failed to request WP GPIO: %d!\n, ret);
+ }
+ if (explicit_inv_wp ^ gpio_inv_wp)
+ host-caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
+}
+
+EXPORT_SYMBOL(mmc_of_parse);
+
/**
* mmc_alloc_host - initialise the per-host structure.
* @extra: sizeof private data structure
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 61a10c1..13c0c8d 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -345,6 +345,7 @@ extern struct mmc_host *mmc_alloc_host(int extra, struct
device *);
extern int mmc_add_host(struct mmc_host *);
extern void mmc_remove_host(struct mmc_host *);
extern void mmc_free_host(struct mmc_host *);
+void mmc_of_parse(struct mmc_host *host);
static inline void *mmc_priv(struct mmc_host *host)
{
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
[PATCH v3 00/13] mmc: core and driver DT and related development
This is v3 of my mmc DT patchset with several patches updated and two patches, previously sent separately, now integrated into the series. Guennadi Liakhovetski (13): mmc: sdhi, tmio: only check flags in tmio-mmc driver proper mmc: detailed definition of CD and WP MMC line polarities in DT mmc: provide a standard MMC device-tree binding parser centrally mmc: (cosmetic) remove extern from function declarations mmc: sh-mmcif: use mmc_of_parse() to parse standard MMC DT bindings mmc: tmio-mmc: define device-tree bindings mmc: tmio-mmc: parse device-tree bindings mmc: sh_mobile_sdhi: remove unused .pdata field mmc: sh_mobile_sdhi: use managed resource allocations mmc: tmio: remove unused and deprecated symbols mmc: tmio: add support for the VccQ regulator mmc: add DT bindings for more MMC capability flags mmc: tmio: add barriers to IO operations Documentation/devicetree/bindings/mmc/mmc.txt | 47 +- Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 15 +++ drivers/mmc/core/host.c| 103 drivers/mmc/host/sh_mmcif.c|3 +- drivers/mmc/host/sh_mobile_sdhi.c | 64 +++- drivers/mmc/host/tmio_mmc.h| 18 ++-- drivers/mmc/host/tmio_mmc_pio.c| 83 ++--- include/linux/mfd/tmio.h | 18 include/linux/mmc/host.h | 23 +++-- include/linux/mmc/sh_mobile_sdhi.h |2 - 10 files changed, 273 insertions(+), 103 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/tmio_mmc.txt -- 1.7.2.5 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 11/13] mmc: tmio: add support for the VccQ regulator
Some SD/MMC interfaces use 2 power regulators: one to power the card itself
(Vcc) and another one to pull signal lines up (VccQ). In case of eMMC and
UHS SD cards the regulators also have to be configured to supply different
voltages. The preferred order of turning supply power on and off is to
turn Vcc first on and last off.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/tmio_mmc_pio.c | 56 ---
1 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index e32e9b4..3a44086 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -43,6 +43,7 @@
#include linux/platform_device.h
#include linux/pm_qos.h
#include linux/pm_runtime.h
+#include linux/regulator/consumer.h
#include linux/scatterlist.h
#include linux/spinlock.h
#include linux/workqueue.h
@@ -155,6 +156,7 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
int new_clock)
host-set_clk_div(host-pdev, (clk22) 1);
sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk 0x1ff);
+ msleep(10);
}
static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
@@ -768,16 +770,48 @@ static int tmio_mmc_clk_update(struct mmc_host *mmc)
return ret;
}
-static void tmio_mmc_set_power(struct tmio_mmc_host *host, struct mmc_ios *ios)
+static void tmio_mmc_power_on(struct tmio_mmc_host *host, unsigned short vdd)
{
struct mmc_host *mmc = host-mmc;
+ int ret = 0;
+
+ /* .set_ios() is returning void, so, no chance to report an error */
if (host-set_pwr)
- host-set_pwr(host-pdev, ios-power_mode != MMC_POWER_OFF);
+ host-set_pwr(host-pdev, 1);
+
+ if (!IS_ERR(mmc-supply.vmmc)) {
+ ret = mmc_regulator_set_ocr(mmc, mmc-supply.vmmc, vdd);
+ /*
+* Attention: empiric value. With a b43 WiFi SDIO card this
+* delay proved necessary for reliable card-insertion probing.
+* 100us were not enough. Is this the same 140us delay, as in
+* tmio_mmc_set_ios()?
+*/
+ udelay(200);
+ }
+ /*
+* It seems, VccQ should be switched on after Vcc, this is also what the
+* omap_hsmmc.c driver does.
+*/
+ if (!IS_ERR(mmc-supply.vqmmc) !ret) {
+ regulator_enable(mmc-supply.vqmmc);
+ udelay(200);
+ }
+}
+
+static void tmio_mmc_power_off(struct tmio_mmc_host *host)
+{
+ struct mmc_host *mmc = host-mmc;
+
+ if (!IS_ERR(mmc-supply.vqmmc))
+ regulator_disable(mmc-supply.vqmmc);
+
if (!IS_ERR(mmc-supply.vmmc))
- /* Errors ignored... */
- mmc_regulator_set_ocr(mmc, mmc-supply.vmmc,
- ios-power_mode ? ios-vdd : 0);
+ mmc_regulator_set_ocr(mmc, mmc-supply.vmmc, 0);
+
+ if (host-set_pwr)
+ host-set_pwr(host-pdev, 0);
}
/* Set MMC clock / power.
@@ -828,18 +862,20 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
if (!host-power) {
tmio_mmc_clk_update(mmc);
pm_runtime_get_sync(dev);
- host-power = true;
}
tmio_mmc_set_clock(host, ios-clock);
- /* power up SD bus */
- tmio_mmc_set_power(host, ios);
+ if (!host-power) {
+ /* power up SD card and the bus */
+ tmio_mmc_power_on(host, ios-vdd);
+ host-power = true;
+ }
/* start bus clock */
tmio_mmc_clk_start(host);
} else if (ios-power_mode != MMC_POWER_UP) {
- if (ios-power_mode == MMC_POWER_OFF)
- tmio_mmc_set_power(host, ios);
if (host-power) {
struct tmio_mmc_data *pdata = host-pdata;
+ if (ios-power_mode == MMC_POWER_OFF)
+ tmio_mmc_power_off(host);
tmio_mmc_clk_stop(host);
host-power = false;
pm_runtime_put(dev);
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 12/13] mmc: add DT bindings for more MMC capability flags
Many MMC capability flags are platform-dependent and are traditionally set in platform data. With DT often each such capability requires a special binding. Add bindings for MMC_CAP_SD_HIGHSPEED, MMC_CAP_MMC_HIGHSPEED, MMC_CAP_POWER_OFF_CARD and MMC_CAP_SDIO_IRQ capabilities. Also add code to DT parser to look up keep-power-in-suspend and enable-sdio-wakeup bindings and set MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ respectively, if found. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Arnd Bergmann a...@arndb.de --- v3: add cap-sdio-irq Documentation/devicetree/bindings/mmc/mmc.txt |4 drivers/mmc/core/host.c | 13 + 2 files changed, 17 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 51dd64f..a043c78 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -25,6 +25,10 @@ Optional properties: - max-frequency: maximum operating clock frequency - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on this system, even if the controller claims it is. +- cap-sd-highspeed: SD high-speed timing is supported +- cap-mmc-highspeed: MMC high-speed timing is supported +- cap-power-off-card: powering off the card is safe +- cap-sdio-irq: enable SDIO IRQ signalling on this interface *NOTE* on CD and WP polarity. As of 3.8, SD/MMC drivers parse their DT nodes each in its own way, including calculation of CD and WP polarities. Our goal is diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index c412612..56b6227 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -380,6 +380,19 @@ void mmc_of_parse(struct mmc_host *host) } if (explicit_inv_wp ^ gpio_inv_wp) host-caps2 |= MMC_CAP2_RO_ACTIVE_HIGH; + + if (of_find_property(np, cap-sd-highspeed, len)) + host-caps |= MMC_CAP_SD_HIGHSPEED; + if (of_find_property(np, cap-mmc-highspeed, len)) + host-caps |= MMC_CAP_MMC_HIGHSPEED; + if (of_find_property(np, cap-power-off-card, len)) + host-caps |= MMC_CAP_POWER_OFF_CARD; + if (of_find_property(np, cap-sdio-irq, len)) + host-caps |= MMC_CAP_SDIO_IRQ; + if (of_find_property(np, keep-power-in-suspend, len)) + host-pm_caps |= MMC_PM_KEEP_POWER; + if (of_find_property(np, enable-sdio-wakeup, len)) + host-pm_caps |= MMC_PM_WAKE_SDIO_IRQ; } EXPORT_SYMBOL(mmc_of_parse); -- 1.7.2.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 10/13] mmc: tmio: remove unused and deprecated symbols
The tmio_mmc_cd_wakeup() inline function has been deprecated since 3.4 and
is unused since 3.4 too. Remove them.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/linux/mfd/tmio.h | 18 --
1 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index d83af39..99bf3e66 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -65,12 +65,6 @@
*/
#define TMIO_MMC_SDIO_IRQ (1 2)
/*
- * Some platforms can detect card insertion events with controller powered
- * down, using a GPIO IRQ, in which case they have to fill in cd_irq, cd_gpio,
- * and cd_flags fields of struct tmio_mmc_data.
- */
-#define TMIO_MMC_HAS_COLD_CD (1 3)
-/*
* Some controllers require waiting for the SD bus to become
* idle before writing to some registers.
*/
@@ -117,18 +111,6 @@ struct tmio_mmc_data {
};
/*
- * This function is deprecated and will be removed soon. Please, convert your
- * platform to use drivers/mmc/core/cd-gpio.c
- */
-#include linux/mmc/host.h
-static inline void tmio_mmc_cd_wakeup(struct tmio_mmc_data *pdata)
-{
- if (pdata)
- mmc_detect_change(dev_get_drvdata(pdata-dev),
- msecs_to_jiffies(100));
-}
-
-/*
* data for the NAND controller
*/
struct tmio_nand_data {
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 07/13] mmc: tmio-mmc: parse device-tree bindings
Add parsing of common and driver-specific DT bindings to the tmio-mmc
MMC host driver.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Arnd Bergmann a...@arndb.de
---
v3: remove the toshiba,mmc-cap-sdio-irq property
drivers/mmc/host/tmio_mmc_pio.c | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index b25adb4..e32e9b4 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -918,6 +918,21 @@ static void tmio_mmc_init_ocr(struct tmio_mmc_host *host)
dev_warn(mmc_dev(mmc), Platform OCR mask is ignored\n);
}
+static void tmio_mmc_of_parse(struct platform_device *pdev,
+ struct tmio_mmc_data *pdata)
+{
+ const struct device_node *np = pdev-dev.of_node;
+ if (!np)
+ return;
+
+ if (of_get_property(np, toshiba,mmc-wrprotect-disable, NULL))
+ pdata-flags |= TMIO_MMC_WRPROTECT_DISABLE;
+ if (of_get_property(np, toshiba,mmc-blksz-2bytes, NULL))
+ pdata-flags |= TMIO_MMC_BLKSZ_2BYTES;
+ if (of_get_property(np, toshiba,mmc-has-idle-wait, NULL))
+ pdata-flags |= TMIO_MMC_HAS_IDLE_WAIT;
+}
+
int tmio_mmc_host_probe(struct tmio_mmc_host **host,
struct platform_device *pdev,
struct tmio_mmc_data *pdata)
@@ -928,6 +943,8 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
int ret;
u32 irq_mask = TMIO_MASK_CMD;
+ tmio_mmc_of_parse(pdev, pdata);
+
if (!(pdata-flags TMIO_MMC_HAS_IDLE_WAIT))
pdata-write16_hook = NULL;
@@ -939,6 +956,8 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
if (!mmc)
return -ENOMEM;
+ mmc_of_parse(mmc);
+
pdata-dev = pdev-dev;
_host = mmc_priv(mmc);
_host-pdata = pdata;
@@ -959,7 +978,7 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
}
mmc-ops = tmio_mmc_ops;
- mmc-caps = MMC_CAP_4_BIT_DATA | pdata-capabilities;
+ mmc-caps |= MMC_CAP_4_BIT_DATA | pdata-capabilities;
mmc-caps2 = pdata-capabilities2;
mmc-max_segs = 32;
mmc-max_blk_size = 512;
@@ -971,7 +990,8 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
_host-native_hotplug = !(pdata-flags TMIO_MMC_USE_GPIO_CD ||
mmc-caps MMC_CAP_NEEDS_POLL ||
- mmc-caps MMC_CAP_NONREMOVABLE);
+ mmc-caps MMC_CAP_NONREMOVABLE ||
+ mmc-slot.cd_irq = 0);
_host-power = false;
pm_runtime_enable(pdev-dev);
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 04/13] mmc: (cosmetic) remove extern from function declarations
The extern keyword isn't required in function declarations, remove it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/linux/mmc/host.h | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 13c0c8d..356ae0a 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -341,10 +341,10 @@ struct mmc_host {
unsigned long private[0] cacheline_aligned;
};
-extern struct mmc_host *mmc_alloc_host(int extra, struct device *);
-extern int mmc_add_host(struct mmc_host *);
-extern void mmc_remove_host(struct mmc_host *);
-extern void mmc_free_host(struct mmc_host *);
+struct mmc_host *mmc_alloc_host(int extra, struct device *);
+int mmc_add_host(struct mmc_host *);
+void mmc_remove_host(struct mmc_host *);
+void mmc_free_host(struct mmc_host *);
void mmc_of_parse(struct mmc_host *host);
static inline void *mmc_priv(struct mmc_host *host)
@@ -358,16 +358,16 @@ static inline void *mmc_priv(struct mmc_host *host)
#define mmc_classdev(x)((x)-class_dev)
#define mmc_hostname(x)(dev_name((x)-class_dev))
-extern int mmc_suspend_host(struct mmc_host *);
-extern int mmc_resume_host(struct mmc_host *);
+int mmc_suspend_host(struct mmc_host *);
+int mmc_resume_host(struct mmc_host *);
-extern int mmc_power_save_host(struct mmc_host *host);
-extern int mmc_power_restore_host(struct mmc_host *host);
+int mmc_power_save_host(struct mmc_host *host);
+int mmc_power_restore_host(struct mmc_host *host);
-extern void mmc_detect_change(struct mmc_host *, unsigned long delay);
-extern void mmc_request_done(struct mmc_host *, struct mmc_request *);
+void mmc_detect_change(struct mmc_host *, unsigned long delay);
+void mmc_request_done(struct mmc_host *, struct mmc_request *);
-extern int mmc_cache_ctrl(struct mmc_host *, u8);
+int mmc_cache_ctrl(struct mmc_host *, u8);
static inline void mmc_signal_sdio_irq(struct mmc_host *host)
{
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 08/13] mmc: sh_mobile_sdhi: remove unused .pdata field
The struct sh_mobile_sdhi_info::pdata field was only used for platform-
based card detection and isn't used anymore since the migration to GPIO-
based MMC slot functions. Remove it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/sh_mobile_sdhi.c |4
include/linux/mmc/sh_mobile_sdhi.h |2 --
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index e0ca0ab..17d5778 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -135,7 +135,6 @@ static int sh_mobile_sdhi_probe(struct platform_device
*pdev)
mmc_data = priv-mmc_data;
if (p) {
- p-pdata = mmc_data;
if (p-init) {
ret = p-init(pdev, sdhi_ops);
if (ret)
@@ -284,9 +283,6 @@ static int sh_mobile_sdhi_remove(struct platform_device
*pdev)
struct sh_mobile_sdhi_info *p = pdev-dev.platform_data;
int i = 0, irq;
- if (p)
- p-pdata = NULL;
-
tmio_mmc_host_remove(host);
while (1) {
diff --git a/include/linux/mmc/sh_mobile_sdhi.h
b/include/linux/mmc/sh_mobile_sdhi.h
index b65679f..b76bcf0 100644
--- a/include/linux/mmc/sh_mobile_sdhi.h
+++ b/include/linux/mmc/sh_mobile_sdhi.h
@@ -4,7 +4,6 @@
#include linux/types.h
struct platform_device;
-struct tmio_mmc_data;
#define SH_MOBILE_SDHI_IRQ_CARD_DETECT card_detect
#define SH_MOBILE_SDHI_IRQ_SDCARD sdcard
@@ -26,7 +25,6 @@ struct sh_mobile_sdhi_info {
unsigned long tmio_caps2;
u32 tmio_ocr_mask; /* available MMC voltages */
unsigned int cd_gpio;
- struct tmio_mmc_data *pdata;
void (*set_pwr)(struct platform_device *pdev, int state);
int (*get_cd)(struct platform_device *pdev);
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/2] iio: Add OF support
On Wed, Feb 06, 2013 at 07:37:37PM +, Jonathan Cameron wrote:
On 02/06/2013 06:29 PM, Guenter Roeck wrote:
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck li...@roeck-us.net
looks good to me. Couple of little queries inline.
---
v4:
- Fixed wrong parameter to dummy of_iio_channel_get_by_name if CONFIG_OF is
undefined, and wrong return value.
- Initialize indio_dev-of_node in iio_device_register if the calling driver
neglected to do it.
v3:
- Cleaned up documentation (formatting, left-over clock references)
- Updated bindings description to permit sub-devices
- When searching for iio devices, use the pointer to the iio device type
instead
of strcmp. Rename iio_dev_type to iio_device_type (to match other device
types) and make it global for that purpose. Check the OF node first, then
the
device type, as the node is less likely to match.
- Move the common code in of_iio_channel_get and of_iio_channel_get_all to
__of_iio_channel_get.
- Return NULL from of_iio_channel_get_by_name if nothing is found, or
an error if there is a problem with consistency or if the provider device
is
not yet available.
- In iio_channel_get, return if of_iio_channel_get_by_name() returns a
channel
or an error, and continue otherwise.
v2:
- Rebased to iio/togreg
- Documentation update per feedback
- Dropped io-channel-output-names from the bindings document. The property
is
not used in the code, and it is not entirely clear what it would be used
for.
If there is a need for it, we can add it back in later on.
- Don't export OF specific API calls
- For OF support, no longer depend on iio_map
- Add #ifdef CONFIG_OF where appropriate, and ensure that the code still
builds
if it is not selected.
- Change iio_channel_get to take device pointer as argument instead of
device
name. Retain old API as of_iio_channel_get_sys.
- iio_channel_get now works for both OF and non-OF configurations
- Use regulator to get vref for max1363 driver.
drivers/iio/iio_core.h |1 +
drivers/iio/industrialio-core.c|8 +-
drivers/iio/inkern.c | 171
4 files changed, 268 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
b/Documentation/devicetree/bindings/iio/iio-bindings.txt
new file mode 100644
index 000..2475c2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,90 @@
+This binding is a work-in-progress. It is derived from clock bindings,
+and based on suggestions from Lars-Peter Clausen [1].
+
+Sources of IIO channels can be represented by any node in the device
+tree. Those nodes are designated as IIO providers. IIO consumer
+nodes use a phandle and IIO specifier pair to connect IIO provider
+outputs to IIO inputs. Similar to the gpio specifiers, an IIO
+specifier is an array of one or more cells identifying the IIO
+output on a device. The length of an IIO specifier is defined by the
+value of a #io-channel-cells property in the IIO provider node.
+
+[1] http://marc.info/?l=linux-iiom=135902119507483w=2
+
+==IIO providers==
+
+Required properties:
+#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for
nodes
+ with a single IIO output and 1 for nodes with multiple
+ IIO outputs.
+
+Example for a simple configuration with no trigger:
+
+ adc: voltage-sensor@35 {
+ compatible = maxim,max1139;
+ reg = 0x35;
+ #io-channel-cells = 1;
+ };
+
+Example for a configuration with trigger:
+
+ adc@35 {
+ compatible = maxim,max1139;
+ reg = 0x35;
+
+ adc: iio-device {
+ #io-channel-cells = 1;
+ };
+ trigger: iio-trigger {
+ #io-channel-cells = 1;
Why would the trigger have channel-cells?
So far we don't have any device tree stuff for the triggers.
This comes from one of the examples passed around earlier.
Presumably, when triggers are supported through devicetree, you would have more
than one per device, meaning you need the same logic as for devices.
Though on the other side that isn't supported yet - I don't have hardware to
test, so I can not implement - or, rather, test - devicetree based trigger
support.
I can take the entire thing out if you prefer - I don't really have a strong
opinion.
+ };
+ };
+
+==IIO consumers==
+
+Required properties:
+io-channels: List of phandle and IIO specifier pairs, one pair
+ for each IIO input to the device. Note: if the
+ IIO provider specifies '0' for
Re: [PATCH v4 2/2] iio: Add OF support
On Wednesday 06 of February 2013 12:05:13 Guenter Roeck wrote:
On Wed, Feb 06, 2013 at 07:37:37PM +, Jonathan Cameron wrote:
On 02/06/2013 06:29 PM, Guenter Roeck wrote:
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck li...@roeck-us.net
looks good to me. Couple of little queries inline.
---
v4:
- Fixed wrong parameter to dummy of_iio_channel_get_by_name if
CONFIG_OF is
undefined, and wrong return value.
- Initialize indio_dev-of_node in iio_device_register if the
calling driver
neglected to do it.
v3:
- Cleaned up documentation (formatting, left-over clock references)
- Updated bindings description to permit sub-devices
- When searching for iio devices, use the pointer to the iio device
type instead
of strcmp. Rename iio_dev_type to iio_device_type (to match other
device types) and make it global for that purpose. Check the OF
node first, then the device type, as the node is less likely to
match.
- Move the common code in of_iio_channel_get and
of_iio_channel_get_all to
__of_iio_channel_get.
- Return NULL from of_iio_channel_get_by_name if nothing is found,
or
an error if there is a problem with consistency or if the provider
device is not yet available.
- In iio_channel_get, return if of_iio_channel_get_by_name() returns
a channel
or an error, and continue otherwise.
v2:
- Rebased to iio/togreg
- Documentation update per feedback
- Dropped io-channel-output-names from the bindings document. The
property is
not used in the code, and it is not entirely clear what it would
be used for. If there is a need for it, we can add it back in
later on.
- Don't export OF specific API calls
- For OF support, no longer depend on iio_map
- Add #ifdef CONFIG_OF where appropriate, and ensure that the code
still builds
if it is not selected.
- Change iio_channel_get to take device pointer as argument instead
of device
name. Retain old API as of_iio_channel_get_sys.
- iio_channel_get now works for both OF and non-OF configurations
- Use regulator to get vref for max1363 driver.
drivers/iio/iio_core.h |1 +
drivers/iio/industrialio-core.c|8 +-
drivers/iio/inkern.c | 171
4 files changed, 268 insertions(+), 2
deletions(-)
create mode 100644
Documentation/devicetree/bindings/iio/iio-bindings.txt
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
b/Documentation/devicetree/bindings/iio/iio-bindings.txt new file
mode 100644
index 000..2475c2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,90 @@
+This binding is a work-in-progress. It is derived from clock
bindings,
+and based on suggestions from Lars-Peter Clausen [1].
+
+Sources of IIO channels can be represented by any node in the
device
+tree. Those nodes are designated as IIO providers. IIO consumer
+nodes use a phandle and IIO specifier pair to connect IIO provider
+outputs to IIO inputs. Similar to the gpio specifiers, an IIO
+specifier is an array of one or more cells identifying the IIO
+output on a device. The length of an IIO specifier is defined by
the
+value of a #io-channel-cells property in the IIO provider node.
+
+[1] http://marc.info/?l=linux-iiom=135902119507483w=2
+
+==IIO providers==
+
+Required properties:
+#io-channel-cells: Number of cells in an IIO specifier; Typically 0
for nodes + with a single IIO output and 1 for nodes with
multiple
+IIO outputs.
+
+Example for a simple configuration with no trigger:
+
+ adc: voltage-sensor@35 {
+ compatible = maxim,max1139;
+ reg = 0x35;
+ #io-channel-cells = 1;
+ };
+
+Example for a configuration with trigger:
+
+ adc@35 {
+ compatible = maxim,max1139;
+ reg = 0x35;
+
+ adc: iio-device {
+ #io-channel-cells = 1;
+ };
+ trigger: iio-trigger {
+ #io-channel-cells = 1;
Why would the trigger have channel-cells?
So far we don't have any device tree stuff for the triggers.
This comes from one of the examples passed around earlier.
Presumably, when triggers are supported through devicetree, you would
have more than one per device, meaning you need the same logic as for
devices.
Though on the other side that isn't supported yet - I don't have
hardware to test, so I can not implement - or, rather, test -
devicetree based trigger support. I can take the entire thing out if
you prefer - I don't really have a strong opinion.
+ };
+ };
+
[PATCH next v2] OF: convert devtree lock from rw_lock to raw spinlock
From: Thomas Gleixner t...@linutronix.de
With the locking cleanup in place (from OF: Fixup resursive
locking code paths), we can now do the conversion from the
rw_lock to a raw spinlock as required for preempt-rt.
The previous cleanup and this conversion were originally
separate since they predated when mainline got raw spinlock (in
commit c2f21ce2e31286a locking: Implement new raw_spinlock).
So, at that point in time, the cleanup was considered plausible
for mainline, but not this conversion. In any case, we've kept
them separate as it makes for easier review and better bisection.
Signed-off-by: Thomas Gleixner t...@linutronix.de
[PG: taken from preempt-rt, update subject add a commit log]
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
[v2: recent commit e81b329 (powerpc+of: Add /proc device tree
updating to of node add/remove) added two more instances of
write_unlock that also needed converting to raw_spin_unlock.
Retested (boot) on sbc8548, defconfig builds on arm/sparc; no
new warnings observed.]
arch/sparc/kernel/prom_common.c | 4 +-
drivers/of/base.c | 100 ++--
include/linux/of.h | 2 +-
3 files changed, 59 insertions(+), 47 deletions(-)
diff --git a/arch/sparc/kernel/prom_common.c b/arch/sparc/kernel/prom_common.c
index 1303021..9f20566 100644
--- a/arch/sparc/kernel/prom_common.c
+++ b/arch/sparc/kernel/prom_common.c
@@ -64,7 +64,7 @@ int of_set_property(struct device_node *dp, const char *name,
void *val, int len
err = -ENODEV;
mutex_lock(of_set_property_mutex);
- write_lock(devtree_lock);
+ raw_spin_lock(devtree_lock);
prevp = dp-properties;
while (*prevp) {
struct property *prop = *prevp;
@@ -91,7 +91,7 @@ int of_set_property(struct device_node *dp, const char *name,
void *val, int len
}
prevp = (*prevp)-next;
}
- write_unlock(devtree_lock);
+ raw_spin_unlock(devtree_lock);
mutex_unlock(of_set_property_mutex);
/* XXX Upate procfs if necessary... */
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 16ee7a0..f86be55 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -55,7 +55,7 @@ static DEFINE_MUTEX(of_aliases_mutex);
/* use when traversing tree through the allnext, child, sibling,
* or parent members of struct device_node.
*/
-DEFINE_RWLOCK(devtree_lock);
+DEFINE_RAW_SPINLOCK(devtree_lock);
int of_n_addr_cells(struct device_node *np)
{
@@ -188,10 +188,11 @@ struct property *of_find_property(const struct
device_node *np,
int *lenp)
{
struct property *pp;
+ unsigned long flags;
- read_lock(devtree_lock);
+ raw_spin_lock_irqsave(devtree_lock, flags);
pp = __of_find_property(np, name, lenp);
- read_unlock(devtree_lock);
+ raw_spin_unlock_irqrestore(devtree_lock, flags);
return pp;
}
@@ -209,13 +210,13 @@ struct device_node *of_find_all_nodes(struct device_node
*prev)
{
struct device_node *np;
- read_lock(devtree_lock);
+ raw_spin_lock(devtree_lock);
np = prev ? prev-allnext : of_allnodes;
for (; np != NULL; np = np-allnext)
if (of_node_get(np))
break;
of_node_put(prev);
- read_unlock(devtree_lock);
+ raw_spin_unlock(devtree_lock);
return np;
}
EXPORT_SYMBOL(of_find_all_nodes);
@@ -274,11 +275,12 @@ static int __of_device_is_compatible(const struct
device_node *device,
int of_device_is_compatible(const struct device_node *device,
const char *compat)
{
+ unsigned long flags;
int res;
- read_lock(devtree_lock);
+ raw_spin_lock_irqsave(devtree_lock, flags);
res = __of_device_is_compatible(device, compat);
- read_unlock(devtree_lock);
+ raw_spin_unlock_irqrestore(devtree_lock, flags);
return res;
}
EXPORT_SYMBOL(of_device_is_compatible);
@@ -340,13 +342,14 @@ EXPORT_SYMBOL(of_device_is_available);
struct device_node *of_get_parent(const struct device_node *node)
{
struct device_node *np;
+ unsigned long flags;
if (!node)
return NULL;
- read_lock(devtree_lock);
+ raw_spin_lock_irqsave(devtree_lock, flags);
np = of_node_get(node-parent);
- read_unlock(devtree_lock);
+ raw_spin_unlock_irqrestore(devtree_lock, flags);
return np;
}
EXPORT_SYMBOL(of_get_parent);
@@ -365,14 +368,15 @@ EXPORT_SYMBOL(of_get_parent);
struct device_node *of_get_next_parent(struct device_node *node)
{
struct device_node *parent;
+ unsigned long flags;
if (!node)
return NULL;
- read_lock(devtree_lock);
+ raw_spin_lock_irqsave(devtree_lock, flags);
parent = of_node_get(node-parent);
of_node_put(node);
- read_unlock(devtree_lock);
+
[PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA
Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client bindings are also added for devices that have SPI and MMC bindings populated. Client binding data is based upon existing HWMOD data for OMAP and has been checked against OMAP documentation. Testing includes ... 1. Boot tested on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. 2. Testing of MMC1 with SD card on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. Testing branch available here [1]. Series is based upon v3.8-rc6 on top of the following ... - Vinod's topic/dmaengine_dt branch [2] - Matt Porter's series DMA Engine support for AM33XX [3] - Matt Porter's series omap_hsmmc DT DMA Client support [4] - Sourav Poddar's series add omap mcspi device tree data [5] [1] https://github.com/jonhunter/linux/commits/dev-dt-dma [2] http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt [3] http://permalink.gmane.org/gmane.linux.kernel.spi.devel/12508 [4] http://permalink.gmane.org/gmane.linux.ports.arm.omap/93165 [5] http://permalink.gmane.org/gmane.linux.kernel/1435002 Jon Hunter (2): ARM: dts: OMAP2+: Add SDMA controller bindings and nodes dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver .../devicetree/bindings/dma/omap-sdma.txt | 44 arch/arm/boot/dts/omap2.dtsi | 12 ++ arch/arm/boot/dts/omap3.dtsi | 40 ++ arch/arm/boot/dts/omap4.dtsi | 41 ++ arch/arm/boot/dts/omap5.dtsi | 41 ++ drivers/dma/omap-dma.c | 31 +- 6 files changed, 208 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/dma/omap-sdma.txt | 44
arch/arm/boot/dts/omap2.dtsi | 12 ++
arch/arm/boot/dts/omap3.dtsi | 40 ++
arch/arm/boot/dts/omap4.dtsi | 41 ++
arch/arm/boot/dts/omap5.dtsi | 41 ++
5 files changed, 178 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt
b/Documentation/devicetree/bindings/dma/omap-sdma.txt
new file mode 100644
index 000..5c2c125
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
@@ -0,0 +1,44 @@
+* TI OMAP SDMA controller
+
+Required properties:
+- compatible: Must be ti,omap-sdma
+- reg: Contains DMA registers location and length.
+- interrupts: Contains DMA interrupt information.
+- #dma-cells: Must be 1.
+- #dma-channels: Contains total number of programmable DMA channels.
+- #dma-requests: Contains total number of DMA requests.
+
+Example:
+
+ sdma: dma-controller@4A056000 {
+ compatible = ti,omap-sdma;
+ reg = 0x4A056000 0x1000;
+ interrupts = 0 12 0x4,
+0 13 0x4,
+0 14 0x4,
+0 15 0x4;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 127;
+ };
+
+
+* TI OMAP SDMA clients
+
+Required properties:
+- dmas:List of one or more DMA specifiers, each
consisting of
+ - A phandle pointing to DMA controller node
+ - The DMA request number associated with client device
+- dma-names: Contains one identifier string for each dma specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
+
+Example:
+
+ mmc1: mmc@4809c000 {
+ ...
+ dmas = sdma 61, /* TX channel */
+ sdma 62; /* RX channel */
+ dma-names = tx, rx;
+ ...
+ };
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..7288972 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -49,6 +49,18 @@
reg = 0x480FE000 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+13,
+14,
+15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 64;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap2-uart;
ti,hwmods = uart1;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..4d63aa2 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -75,6 +75,18 @@
reg = 0x4820 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+13,
+14,
+15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 96;
+ };
+
omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002030 0x05cc;
@@ -192,6 +204,16 @@
#size-cells = 0;
ti,hwmods = mcspi1;
ti,spi-num-cs = 4;
+ dmas = sdma 35,
+ sdma 36,
+ sdma 37,
+ sdma 38,
+ sdma 39,
+ sdma 40,
+ sdma 41,
+ sdma 42;
+ dma-names = tx0, rx0, tx1, rx1,
+ tx2, rx2, tx3, rx3;
};
[PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/dma/omap-dma.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 5a31264..a32d81b 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -16,6 +16,8 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/spinlock.h
+#include linux/of_dma.h
+#include linux/of_device.h
#include virt-dma.h
@@ -67,6 +69,8 @@ static const unsigned es_bytes[] = {
[OMAP_DMA_DATA_TYPE_S32] = 4,
};
+static struct of_dma_filter_info info;
+
static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
{
return container_of(d, struct omap_dmadev, ddev);
@@ -621,10 +625,25 @@ static int omap_dma_probe(struct platform_device *pdev)
pr_warn(OMAP-DMA: failed to register slave DMA engine device:
%d\n,
rc);
omap_dma_free(od);
+ return rc;
} else {
platform_set_drvdata(pdev, od);
}
+ if (pdev-dev.of_node) {
+ info.dma_cap = od-ddev.cap_mask;
+ info.filter_fn = omap_dma_filter_fn;
+
+ /* Device-tree DMA controller registration */
+ rc = of_dma_controller_register(pdev-dev.of_node,
+ of_dma_simple_xlate, info);
+ if (rc) {
+ pr_warn(OMAP-DMA: failed to register DMA
controller\n);
+ dma_async_device_unregister(od-ddev);
+ omap_dma_free(od);
+ }
+ }
+
dev_info(pdev-dev, OMAP DMA engine driver\n);
return rc;
@@ -634,18 +653,28 @@ static int omap_dma_remove(struct platform_device *pdev)
{
struct omap_dmadev *od = platform_get_drvdata(pdev);
+ if (pdev-dev.of_node)
+ of_dma_controller_free(pdev-dev.of_node);
+
dma_async_device_unregister(od-ddev);
omap_dma_free(od);
return 0;
}
+static const struct of_device_id omap_dma_match[] = {
+ { .compatible = ti,omap-sdma, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_dma_match);
+
static struct platform_driver omap_dma_driver = {
.probe = omap_dma_probe,
.remove = omap_dma_remove,
.driver = {
.name = omap-dma-engine,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(omap_dma_match)
},
};
@@ -673,7 +702,7 @@ static int omap_dma_init(void)
{
int rc = platform_driver_register(omap_dma_driver);
- if (rc == 0) {
+ if ((rc == 0) (!of_have_populated_dt())) {
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev)) {
platform_driver_unregister(omap_dma_driver);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
