Re: [PATCH -next] Input: olpc_apsp - remove redundant dev_err call in olpc_apsp_probe()
On Tue, Jul 16, 2013 at 11:31 PM, Wei Yongjun weiyj...@gmail.com wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Daniel Drake d...@laptop.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: DT binding review for Armada display subsystem
On Mon, Jul 15, 2013 at 3:09 PM, Sascha Hauer s.ha...@pengutronix.de wrote: You don't have to call drm_irq_install(). Both the exynos and i.MX driver do without it and at least the i.MX driver uses multiple irqs per drm_device. Good point, thanks. That unblocks that item. Secondly, devm. I understand from the best practices thread that we want to have exactly one platform_device which corresponds to the super node, and all of the individual display controller components will be represented by DT nodes but *without* their own platform_device. A super node approach doesn't mean that there's only one platform device. You can still have a platform device for each component. Yes. As noted, this was simply a preference that seemed to emerge in the previous discussion. If in practice it causes too many headaches, maybe we will change our minds. For now devm is the only issue I have seen; I am avoiding devm where it is no longer possible under this design. The goal of getting this driver working properly on OLPC XO seems to be a twisty path that presents a new issue at every turn. In the above work I am trying to first implement the DT binding for Armada 510/cubox, as that is what the current code is aimed at. I am now facing a problem with i2c/TDA998x which Russell already noted: http://lists.freedesktop.org/archives/dri-devel/2013-June/039632.html What *can't* be done without a rewrite of the DRM slave encoder backend is to have the TDA998x I2C device provided by DT. There are mumblings about redoing the slave encoder API, hopefully this will be fixed there. This is because the existing DRM/encoder system works something like this: 1. i2c driver (e.g. tda998x_drv) registers as an i2c_driver via drm_i2c_encoder_register() 2. The drm driver (i.e. armada) later has to know that it is expecting a tda998x instance. It calls drm_i2c_encoder_init() to set this up. drm_i2c_encoder init requires: 1. The i2c_adapter in question. In a DT world, we could get this from finding the parent node of the tda998x node (this is the i2c bus master), and then using i2c_for_each_dev to find the first i2c adapter instance that has the same of_node. 2. i2c_board_info - basically the address of the device on the i2c bus. This is basically the way of instantiating i2c devices from platform data. Not the DT way :( In a DT world the i2c driver would be instantiated from a node in the DT, which already includes the info that would come in i2c_board_info. Then later it would have to be linked to a DRM slave/encoder, perhaps when the DRM device finds the of_node corresponding to it. So I think the next step is fixing up DRM, as Russell hinted. Unless someone sees another acceptable option that doesn't break our DT design. I am going away for 3-4 weeks now, so you won't be hearing for me for a while. Just in case someone else wants to pick up the task in the mean time, here is my work in progress. I'm still reading and learning, so please don't do any detailed reviews yet :) http://dev.laptop.org/~dsd/20130717/0001-dove-clk-dt-wip.patch It includes the previous clock selection patch as this stuff is quite closely bound with DT support. Thanks Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RESEND 1/2] ARM: mmp: Add compatible entries for OLPC XO laptops
Add compatible entries to enable booting of OLPC XO-1.75 (MMP2) and
OLPC XO-4 (MMP3).
Signed-off-by: Chris Ball c...@laptop.org
Signed-off-by: Daniel Drake d...@laptop.org
---
Documentation/devicetree/bindings/arm/mrvl/intc.txt | 4 ++--
Documentation/devicetree/bindings/arm/mrvl/mrvl.txt | 8
arch/arm/mach-mmp/irq.c | 1 +
arch/arm/mach-mmp/mmp2-dt.c | 2 ++
4 files changed, 13 insertions(+), 2 deletions(-)
Resending after 1 month with no response.
diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 8b53273..3554fb9 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -1,8 +1,8 @@
* Marvell MMP Interrupt controller
Required properties:
-- compatible : Should be mrvl,mmp-intc, mrvl,mmp2-intc or
- mrvl,mmp2-mux-intc
+- compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
+ mrvl,mmp2-mux-intc
- reg : Address and length of the register set of the interrupt controller.
If the interrupt controller is intc, address and length means the range
of the whold interrupt controller. If the interrupt controller is mux-intc,
diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
index 117d741..236e884 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
@@ -12,3 +12,11 @@ Required root node properties:
MMP2 Brownstone Board
Required root node properties:
- compatible = mrvl,mmp2-brownstone;
+
+OLPC XO-1.75 (CL2) based on MMP2
+Required root node properties:
+ - compatible = olpc,xo-1.75;
+
+OLPC XO-4 (CL4) based on MMP3
+Required root node properties:
+ - compatible = olpc,xo-cl4;
diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
index 3c71246..d60b85a 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/arch/arm/mach-mmp/irq.c
@@ -329,6 +329,7 @@ void __init mmp2_init_icu(void)
static const struct of_device_id intc_ids[] __initconst = {
{ .compatible = mrvl,mmp-intc, .data = mmp_conf },
{ .compatible = mrvl,mmp2-intc, .data = mmp2_conf },
+ { .compatible = mrvl,mmp3-intc, .data = mmp2_conf },
{}
};
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 4ac2567..e67bd9f 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -44,6 +44,8 @@ static void __init mmp2_dt_init(void)
static const char *mmp2_dt_board_compat[] __initdata = {
mrvl,mmp2-brownstone,
+ olpc,xo-1.75,
+ olpc,xo-cl4,
NULL,
};
--
1.8.1.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RESEND 2/2] ARM: mmp: irq: Improve DT layout
In the mmp2 device tree, the interrupt mux nodes were peers of the
interrupt controller, yet they mapped registers in conflict with the
interrupt controller's register block. Furthermore, the reg properties of
the muxes disagreed with the unit address specified after the node's @-sign.
Move the interrupt mux nodes underneath the interrupt controller node,
because the registers are subordinate to the interrupt controller device,
and update the documentation accordingly.
In the platform code, avoid using of_address_to_resource(). Treating a
reg value of 0x150 as a resource effectively is mapping to memory
location 0x150, which is not what's happening here. Use of_get_address()
instead, to better reflect that we're dealing with an address offset
being read from the device tree.
This adds support for the device tree shipped in the OLPC XO-4 and
additionally these code changes do not break compatibility with the
old DT layout.
Based on work by Mitch Bradley.
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/arm/mrvl/intc.txt | 41 ---
arch/arm/boot/dts/mmp2.dtsi| 128 ++---
arch/arm/mach-mmp/irq.c| 16 +--
3 files changed, 95 insertions(+), 90 deletions(-)
Resending after 1 month with no response.
diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 3554fb9..0c020ff 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -2,21 +2,24 @@
Required properties:
- compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
- mrvl,mmp2-mux-intc
-- reg : Address and length of the register set of the interrupt controller.
- If the interrupt controller is intc, address and length means the range
- of the whold interrupt controller. If the interrupt controller is mux-intc,
- address and length means one register. Since address of mux-intc is in the
- range of intc. mux-intc is secondary interrupt controller.
-- reg-names : Name of the register set of the interrupt controller. It's
- only required in mux-intc interrupt controller.
-- interrupts : Should be the port interrupt shared by mux interrupts. It's
- only required in mux-intc interrupt controller.
+- reg : Address and length of the register set of the whole interrupt
+ controller.
- interrupt-controller : Identifies the node as an interrupt controller.
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source.
- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
controller.
+
+* Marvell MMP Secondary Interrupt controller (mux)
+
+Required properties:
+ - compatible : Shall be mrvl,mmp2-mux-intc
+ Address and length of one register offset into the register address space of
+ the parent interrupt controller node.
+- reg-names : Name of the register set of the interrupt controller.
+- interrupts : Should be the port interrupt shared by mux interrupts.
+- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
+ controller.
- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
detection first.
@@ -27,16 +30,16 @@ Example:
#interrupt-cells = 1;
reg = 0xd4282000 0x1000;
mrvl,intc-nr-irqs = 64;
- };
- intcmux4@d4282150 {
- compatible = mrvl,mmp2-mux-intc;
- interrupts = 4;
- interrupt-controller;
- #interrupt-cells = 1;
- reg = 0x150 0x4, 0x168 0x4;
- reg-names = mux status, mux mask;
- mrvl,intc-nr-irqs = 2;
+ intcmux4@150 {
+ compatible = mrvl,mmp2-mux-intc;
+ interrupts = 4;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ reg = 0x150 0x4, 0x168 0x4;
+ reg-names = mux status, mux mask;
+ mrvl,intc-nr-irqs = 2;
+ };
};
* Marvell Orion Interrupt controller
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 4e8b08c..1f63c8f 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -44,77 +44,77 @@
#interrupt-cells = 1;
reg = 0xd4282000 0x1000;
mrvl,intc-nr-irqs = 64;
- };
- intcmux4: interrupt-controller@d4282150 {
- compatible = mrvl,mmp2-mux-intc;
- interrupts = 4;
- interrupt-controller;
- #interrupt-cells = 1;
- reg = 0x150 0x4, 0x168 0x4;
- reg-names = mux status, mux mask
[PATCH RESEND 2/2] clk: mmp: add support for DT-defined clocks
Add support to the existing mmp clock drivers for clocks to be defined
in the device tree. This will be used on OLPC MMP2/MMP3-based laptops.
If clock info cannot be found in the device tree, we fall back to the
static clock initialization already present.
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/clock/mmp-apbc.txt | 30 ++
.../devicetree/bindings/clock/mmp-apmu.txt | 30 ++
drivers/clk/mmp/clk-apbc.c | 66 +-
drivers/clk/mmp/clk-apmu.c | 37 +++-
drivers/clk/mmp/clk-mmp2.c | 19 ++-
5 files changed, 179 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/mmp-apbc.txt
create mode 100644 Documentation/devicetree/bindings/clock/mmp-apmu.txt
Resending after a month without review.
diff --git a/Documentation/devicetree/bindings/clock/mmp-apbc.txt
b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
new file mode 100644
index 000..88e1253
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Advanced Peripheral Bus clock
+
+Parent apb-clock node
+=
+Required properties:
+- reg: Address and length of the APB clock unit registers
+
+
+Child peripheral clock nodes
+
+Required properties:
+- compatible : shall be marvell,mmp-apb-clock
+- #clock-cells : from common clock binding; shall be set to 1
+- clocks : parent clock, from common clock binding
+- clock-output-names : Array of clock names, from common clock binding
+- reg : Array of control register offsets into APB clock unit register space
+
+
+Example:
+apbc: apb-clock {
+ reg = 0xd4015000 0x1000;
+
+ twsi-clocks {
+ compatible = marvell,mmp-apb-clock;
+ #clock-cells = 1;
+ clocks = vctvxo-clock;
+ clock-output-names = TWSI0, TWSI1;
+ reg = 0x04 0x08;
+ };
+};
diff --git a/Documentation/devicetree/bindings/clock/mmp-apmu.txt
b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
new file mode 100644
index 000..18bb0f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Application Subsystem Power Management Unit
+
+Parent apmu-clock node
+=
+Required properties:
+- reg: Address and length of the CPU Subsystem PMU registers
+
+
+Child peripheral clock nodes
+
+Required properties:
+- compatible : shall be marvell,mmp-apmu-clock
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : parent clock, from common clock binding
+- reg : Control register offsets into parent register space
+- enable-mask : The bits to be set in the register to enable the clock, or
+cleared to disable.
+
+Example:
+apmu-clock {
+ reg = 0xd4282800 0x1000;
+
+ usb-clock {
+ compatible = marvell,mmp-apmu-clock;
+ #clock-cells = 0;
+ clocks = usb_pll;
+ reg = 0x5c;
+ enable-mask = 0x09;
+ };
+};
diff --git a/drivers/clk/mmp/clk-apbc.c b/drivers/clk/mmp/clk-apbc.c
index 89a146a..d53bc79 100644
--- a/drivers/clk/mmp/clk-apbc.c
+++ b/drivers/clk/mmp/clk-apbc.c
@@ -15,6 +15,8 @@
#include linux/err.h
#include linux/delay.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_address.h
#include clk.h
@@ -129,8 +131,70 @@ struct clk *mmp_clk_register_apbc(const char *name, const
char *parent_name,
apbc-hw.init = init;
clk = clk_register(NULL, apbc-hw);
- if (IS_ERR(clk))
+ if (WARN_ON(IS_ERR(clk)))
kfree(apbc);
return clk;
}
+
+static void __init mmp_apbc_dt_init(struct device_node *node)
+{
+ struct device_node *parent = of_get_parent(node);
+ const __be32 *regs;
+ struct clk *clk;
+ int rc;
+ int len;
+ int num_clocks;
+ int clock_num;
+ void __iomem *baseaddr;
+ const char *clock_name;
+ const char *parent_name;
+ struct clk **clks;
+ struct clk_onecell_data *clk_data;
+
+ regs = of_get_property(node, reg, len);
+ if (WARN_ON(!regs || (len % sizeof(__be32) != 0)))
+ return;
+ num_clocks = len / sizeof(__be32);
+
+ baseaddr = of_iomap(parent, 0);
+ of_node_put(parent);
+ if (WARN_ON(!baseaddr))
+ return;
+
+ clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
+ if (WARN_ON(!clk_data))
+ goto err_clk_data;
+
+ clks = kzalloc(num_clocks * sizeof(*clks), GFP_KERNEL);
+ if (WARN_ON(!clks))
+ goto err_clks;
+
+ clock_name = of_get_property(node, clock-output-names, NULL);
+ parent_name = of_clk_get_parent_name(node, 0);
+
+ for (clock_num = 0; clock_num num_clocks
Re: DT binding review for Armada display subsystem
On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake d...@laptop.org wrote: Based on the outcomes of the Best practice device tree design for display subsystems discussion I have drafted a DT binding. Comments much appreciated. At a high level, it uses a super node as something for the driver to bind to, needed because there is no clear one device that controls all the others, and also to distinguish between the Armada 510 possible use cases of having one video card with two outputs, or two independent video cards. It uses node-to-node linking beyond that point, V4L2 style. As this hasn't been shot down very far, I've started to implement the driver side of this binding. I have already run into a couple of little problems. First, interrupts. In the dt binding, each lcd controller node defines which interrupt it listens to, and in the armada 510 case there are indeed 2 interrupts (47 and 46, one for each LCD controller). And remember that the drm driver itself binds to the super-node. Looking at drm_irq_install(), it looks like DRM only supports 1 interrupt line per drm_device. As we have no known users who will want these two LCD controllers represented as 2 CRTCs on 1 DRM device (which would require management of 2 interrupt lines), I figured this might be a reason to ignore that use case for now (from the coding standpoint), meaning that in all cases we are left with each DRM device having 1 CRTC, corresponding to 1 LCD controller, which has exactly 1 interrupt line. That still doesn't solve the problem though. drm_irq_install calls into drm_platform to figure out which IRQ number to use, and that code looks at the platform_device (i.e. super node). In this case we don't have the irq info there, we have it in the lcd controller node. Do I invent our own DRM bus implementation so that we can override get_irq()? Start to standardise our DT design as a generic drm_dt.c bus implementation? Any thoughts? Secondly, devm. I understand from the best practices thread that we want to have exactly one platform_device which corresponds to the super node, and all of the individual display controller components will be represented by DT nodes but *without* their own platform_device. As we now put things (clocks, interrupts) into DT nodes that don't have a corresponding platform_device, we lose the ability to use devm. Russell wasn't too pleased last time I posted a patch moving away from devm, admittedly last time the patch was bad and it wasn't necessary, but this time it looks like it might be. Finally, just curious, do we still want to support non-DT platform data type setups on this driver? That adds a bit of coding effort. Not a problem, just wanted to check. Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: DT binding review for Armada display subsystem
On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine moin...@free.fr wrote:
I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
(si5351). Normally, the external clock is used, but, sometimes, the
si5351 module is not yet initialized when the drm driver starts. So,
for 1920x1080p, it uses the lcdclk which sets the LCD clock to 13
(40/3) instead of 148500. As a result, display and sound still work
correctly on my TV set thru HDMI.
So, it would be nice to have 2 usable clocks per LCD, until we find a
good way to initialize the modules in the right order at startup time.
Having multiple usable clocks is implemented in the patch I referred
you to. However it doesn't solve the better clock turns up after
initializing the driver problem, which seems like a tricky one.
Maybe the best solution is to defer probe until all DT-defined clocks
become available. That means that whoever compiles the kernel must
take care to not forget to build the clock drivers for all the clocks
referenced in this part of the DT, but perhaps that is a reasonable
thing to require.
On the other hand, this problem acts in support of a simpler approach
mentioned by Sebastian: developers figure out what the best clock is
for each CRTC on each board, and the DT only specifies that one clock.
The driver uses that clock if it is available and defers probe if it
is not.
Back to the specific case of the Cubox with new ideas.
The Cubox is based on the Armada 510 (Dove), so, all the hardware must
be described in dove.dtsi. This includes the LCDs and DCON/IRE, the
possible clocks and the (static) v4l2 links:
As a sidenote, I think we have concluded that we are not going to
interact with the armada 510 DCON in any way at the moment. The driver
will not have code that touches it, and the DT will not mention it.
The first person who actually needs to use the DCON will have the
responsibility for doing that work. Nevertheless it makes sense for us
to pick a DT design where we know that the DCON could be slotted in
later.
lcd0: lcd-controller@82 {
compatible = marvell,dove-lcd0;
reg = 0x82 0x1c8;
interrupts = 47;
clocks = core_clk 3, lcdclk;
clock-names = axi, lcdclk;
marvell-output = dcon 0;
status = disabled;
};
lcd1: lcd-controller@81 {
compatible = marvell,dove-lcd1;
reg = 0x81 0x1c8;
interrupts = 46;
clocks = core_clk 3, lcdclk;
clock-names = axi, lcdclk;
marvell-output = dcon 1;
status = disabled;
};
/* display controller and image rotation engine */
dcon: display-controller@83 {
compatible = marvell,dove-dcon;
reg = 0x83 0xc4, /* DCON */
0x831000 0x8c; /* IRE */
interrupts = 45;
marvell-input = lcd0, lcd1;
status = disabled;
};
I guess the IRE falls into the same category as the DCON - we won't
implement it for now, but knowing where it might fit in is useful.
Why would you put it in the same node as the DCON though? It has its
own separate register space and additionally it is a component shared
with the MMP boards (whereas the DCON is not).
The specific Cubox hardware (tda998x and si5351) is described in
dove-cubox.dts, with the new clocks and the v4l2 link dcon0 -- tda998x.
i2c0 {
si5351: clock-generator {
...
};
tda998x: hdmi-encoder {
compatible = nxp,tda998x;
reg = 0x70;
interrupt-parent = gpio0;
interrupts = 27 2;/* falling edge */
marvell-input = dcon 0;
};
};
lcd0 {
status = okay;
clocks = si5351 0;
clock-names = extclk0;
};
dcon {
status = okay;
marvell-output = tda998x, 0; /* no connector on
port B */
};
So now you are taking an approach equivalent to the v4l2 standard
video interfaces binding, which is the concept of representing a
connection graph via phandles. This means that our two proposals are
equivalent yet I proposed using a standard interface and you proposed
inventing your own, again without explaining why you don't like the
standard interface.
Then, about the software, the drm driver may not need to know anything
more (it scans the DT for the LCDs and gets all the subdevices thanks
to the v4l2
Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
On Fri, Jul 12, 2013 at 6:35 PM, Haojian Zhuang haojian.zhu...@gmail.com wrote: These patches couldn't be applied. Since we're moving irq drivers from arch directories to irq directories. It does not seem in line with the collaborative manner of kernel development to block my patches for a whole month because they conflict with your own private patches which do not exist for anyone else (at least I searched and couldn't find them). Please, either post your patches immediately (I will help review), or review mine and figure out how to handle any conflict with your own work afterwards. When the irq patches are applied, you can rebase your patches. 2 of the pending patches don't touch the irq stuff anyway. Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
On Thu, Jul 11, 2013 at 5:54 PM, Haojian Zhuang haojian.zhu...@gmail.com wrote: Well, Daniel Drake spoke up for OLPC. Does that count? We don't know they used DT on Marvell MMP2/MMP3. So they don't have DTS file in kernel, we could use both old name new name in driver. You are listed as one of the MMP maintainers in the MAINTAINERS file and I have sent you several patches in the few 3 weeks which make OLPC's usage of MMP + DT pretty obvious. As a maintainer I believe you are supposed to review the patches too. hint hint ;) My request to avoid breaking compatibility actually comes as a two-prong request. I would prefer to see these compatible properties stay the same as it seems like changing them has little purpose/benefit - and there *will* become a later point where changing them causes major breakage. At the same time I see that there have been recent efforts to remove MMP2 platform code and make it entirely DT-driven, which could also generate some compatibility concerns. However, such movements are much appreciated and I think they will become increasingly necessary as we bring up the devices on the MMP3 SoC to a fuller extent, so please continue :) I would not want to discourage you from breaking compatibility when *that* type of work needs to be done. So: breaking compatibility is actually OK from my standpoint, but only for now (while we stabilise), and I would advise/appreciate that it only be done in cases where there is a clear purpose and benefit. Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
On Fri, Jul 12, 2013 at 9:57 AM, Jason Cooper ja...@lakedaemon.net wrote:
This also means we should do a patch for stable v3.5+ appending the
mrvl,... string to the drivers that had it removed improperly, as
Daniel discovered. Daniel, since you are probably most familiar (and
most able to test ;-) ), would you mind putting that patch together?
I will look at that. There was another case of a quiet mrvl-marvell
conversion that bit us around a year ago as well, so I will dig that
up too for consideration.
So we don't have to keep it around forever, we could do as Arnd has
suggested in the past (for an entirely different problem):
/* assuming it goes in for v3.12 */
if (WARN_ON(of_device_is_compatible(dev, mrvl,...))) {
dev_info(dev-dev, compatible string \mrvl,...\ being
removed in v3.15\n);
BUG_ON(LINUX_VERSION_CODE = KERNEL_VERSION(3,15,0));
}
* I can't find where Arnd's suggestion was, so this hack is completely
my own.
Keep in mind, the above hack is just a suggestion, it makes my skin
crawl just looking at it... I'm open to other ideas. Or, not doing it
at all.
A new OpenFirmware or dtb file would want to keep the old mrvl
compatible string around in order to have compatibility with old
kernels. So I think that hack would have to be extended to if device
is compatible with mrvl, but not marvell, then warn. And that seems
so ugly that my vote would be to avoid it. Especially while we don't
know of existing users who have a requirement of stability.
Daniel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
DT binding review for Armada display subsystem
Hi,
Based on the outcomes of the Best practice device tree design for display
subsystems discussion I have drafted a DT binding. Comments much appreciated.
At a high level, it uses a super node as something for the driver to bind
to, needed because there is no clear one device that controls all the
others, and also to distinguish between the Armada 510 possible use cases
of having one video card with two outputs, or two independent video cards.
It uses node-to-node linking beyond that point, V4L2 style.
I have some questions still:
1. What names does the Armada 510 datasheet give to the components? Below
I renamed the LCD controllers (which don't control LCDs on any of the
current target hardware) to display controllers. For what we were
previously referring to as DCON, I renamed to output selector. I would
like to match the docs.
Actually the output selector is not mentioned as per Sebastian's
suggestion, but I believe it would fit in the below design once the first
user comes along (e.g. it would slot in the graph between dcon0 and tda99x).
2. On that topic, what names does the Armada 510 datasheet give to the
available clocks? Lets make them match the docs.
3. What is the remote property in the video interfaces binding? Doesn't
seem to be documented. But I think I copied its usage style below.
Marvell Armada Display Subsystem
Design considerations
-
The display device that emerges from this subsystem is quite heavily
componentized and the formation of the composite device will vary by SoC and
by board. The DT binding is designed with this flexibility in mind.
For example, there are 2 display controllers on the Armada 510.
They could legitametely be used to form two independent video cards, or
they could be combined into a single video card with two outputs, depending
on board wiring and use case.
As there is no clear component that controls the other components, especially
when we wish to combine the two display controllers into one virtual device, we
define a top-level super node that describes the basic composition of the
overall display device. That node uses phandles to define the start of the
graph of display components.
In the bindings for the individual display components, phandle properties
are used to represent direct, fixed links to other components. We use the
port/endpoint abstraction from bindings/media/video-interfaces.txt to
represent these links.
display super node
--
Required properties:
- compatible: marvell,armada-display
- marvell,video-devices : List of phandles to the display controllers that
form this composite device.
Optional properties;
- reg: Memory address and size of a RAM allocation designated as graphics
memory
- linux,video-memory-size: If reg is not provided, this property defines
how much memory to cut out of regular available RAM to be used as graphics
memory.
display-controller node
---
Required properties:
- compatible: marvell,armada-510-display, marvell,mmp2-display or
marvell,mmp3-display
- reg: Register space for this display controller
- clocks: List of clocks available to this device. From common clock binding.
- clock-names: Names of the given clocks (see below)
- ports: From video interface binding
Valid clock names for Armada 510: extclk0 extclk1 axi pll
Valid clock names for MMP2: lcd1 lcd2 axi hdmi
Valid clock names for MMP3: lcd1 lcd2 axi hdmi dsi lvds
Example:
display {
  compatible = marvell,armada-display;
   reg = 0 0x3f00 0x100; /* video-mem hole */
   marvell,video-devices = dcon0;
  };
dcon0: display-controller@2 {
compatible = marvell,armada-510-display-controller;
   reg = 0x2 0x1000;
   interrupts = 47;
   clocks = ext_clk0;
   clock-names = extclk0;
port {
dcon0_1: endpoint {
remote = tda998x;
};
};
};
i2c0 {
  tda998x: hdmi-transmitter@60 {
   compatible = nxp,tda19988;
    reg = 0x60;
port {
tda998x_1: endpoint {
remote-endpoint = dcon0_1;
};
};
   };
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: DT binding review for Armada display subsystem
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine moin...@free.fr wrote:
- I think it is better to keep the names 'lcd' for the memory to dumb panel
sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
named in the spec.
I agree it is worth keeping the spec-defined names, if they do not
cause excessive confusion when mixed with the spec-defined names for
MMP2/MMP3. I'll check the spec you pointed out, thanks.
- the phandles to the clocks does not tell how the clock may be set by
the driver (it is an array index in the 510).
In the other threads on clock selection, we decided that that exact
information on how to select a clock (i.e. register bits/values) must
be in the driver, not in the DT. What was suggested there is a
well-documented scheme for clock naming, so the driver knows which
clock is which. That is defined in the proposed DT binding though the
valid clock names part. For an example driver implementation of this
you can see my patch armada_drm clock selection - try 2.
- I don't see the use of the phandles in the leaves (dcon and tda998x).
That is defined by the video interfaces common binding. I'm not
immediately aware of the use, but the ability to easily traverse the
graph in both directions seems like a requirement that could easily
emerge from somewhere.
Well, here is how I feel the DTs:
- for the Cubox (one LCD, the DCON is not used, TDA998x for HDMI/DVI
output):
That is the same as my proposal except you have decided to use direct
phandle properties instead of using the common video interfaces
binding (which is just a slightly more detailed way of describing such
links). In the best practices thread, the suggestion was raised
multiple times of doing what v4l2 does, so thats why I decided to
explore this here.
- for some tablet based on the Armada 510 with a LCD and a VGA connector:
video {
compatible = marvell,armada-video;
marvell,video-devices = lcd0, lcd1, dcon
};
This proposal is slightly different because it does not describe the
relationship between the LCD controllers and the DCON. Focusing
specifically on LCD1, which would be connected to a DAC via a phandle
property in your proposal. The interconnectivity between the
components represented as a graph (and in the v4l2 way, which includes
my proposal) would be:
LCD1 --- DCON --- DAC
However your phandle properties would suggest that LCD1 is directly
connected to the DAC. The driver would have to have special knowledge
that the DCON sits right in the middle. Maybe that is not an issue, as
it is obviously OK for the driver to have *some* knowledge about how
the hardware works :)
I don't think we have a full consensus on whether we want to go the
v4l2 way here. But I figured that would be a good thing to propose
in a first iteration to have a clearer idea of what the result would
look like. It sounds like you are not overly keen on it, I would be
interested to hear exactly why.
Thanks,
Daniel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
On Wed, Jul 10, 2013 at 6:20 AM, Jason Cooper ja...@lakedaemon.net wrote: Please keep in mind that the DT is supposed to be tied to the hardware, *not* the kernel. iow, a dtb comes with a board, and the user/OS upgrades the kernel as needed w/o upgrading or changing the dtb. Thank you for making this position clear to those trying to break compatibility... This will affect OLPC where the dtb comes from the firmware (OpenFirmware), which is similar to the dtb coming with the board as you describe. We run on Marvell SoCs. So the question you need to ask yourself is: Are there any users (since v3.5) that are doing this? If so, they have mrvl,... compatible strings in their dtbs. You don't want to break their systems on kernel upgrade, right? In the OLPC case, the devicetree currently exported from the firmware is unfortunately quite insufficient to boot mainline kernels. So we are currently in a state of flux where we must break firmware/OS compatibility in significant ways in order to support mainline kernels. We are heading in this direction despite the pains. Therefore right now its OK for us if we break compatibility during our in-flux major firmware/DT restructuring, as this patch does. However, once we have stabilised in the near future, it will no longer be possible to break compatibility like this. My vote would be to maintain the old names (in addition to the new) in case there are people that will be affected by this that haven't seen this thread. We were recently hit by another backwards-incompatible change in Marvell's Linux gpio drivers where the compatible strings recognised were changed (f87311743eaf85). This is not a big problem in our current state however it cost me about 3 hours of changelog skimming, glancing around in the code, and finally running a git bisect, before I managed to figure out why things had suddenly stopped working. That was irritating. Thanks Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Best practice device tree design for display subsystems/DRM
Hi,
I'm looking into implementing devicetree support in armada_drm and
would like to better understand the best practice here.
Adding DT support for a DRM driver seems to be complicated by the fact
that DRM is not hotpluggable - it is not possible for the drm_device
to be initialised without an output, with the output connector/encoder
appearing at some later moment. Instead, the connectors/encoders must
be fully loaded before the drm_driver load function returns. This
means that we cannot drive the individual display components through
individual, separate modules - we need a way to control their load
order.
Looking at existing DRM drivers:
tilcdc_drm takes an approach that each of the components in the
display subsystem (panel, framebuffer, encoder, display controllers)
are separate DT nodes and do not have any DT-level linkage.
It implements just a single module, and that module carefully
initialises things in this order:
1. Register platform drivers for output components
2. Register main drm_driver
When the output component's platform drivers get loaded, probes for
such drivers immediately run as they match things in the device tree.
At this point, there is no drm_device available for the outputs to
bind to, so instead, references to these platform devices just get
saved in some global structures.
Later, when the drm_driver gets registered and loaded, the global
structures are consulted to find all of the output devices at the
right moment.
exynos seems to take a the same approach. Components are separate in
the device tree, and each component is implemented as a platform
driver or i2c driver. However all the drivers are built together in
the same module, and the module_init sequence is careful to initialise
all of the output component drivers before loading the DRM driver. The
output component driver store their findings in global structures.
Russell King suggested an alternative design for armada_drm. If all
display components are represented within the same display
super-node, we can examine the DT during drm_device initialisation and
initialise the appropriate output components. In this case, the output
components would not be registered as platform drivers.
The end result would be something similar to exynos/tilcdc (i.e.
drm_driver figuring out its output in the appropriate moment), however
the hackyness of using global storage to store output devices before
drm_driver is ready is avoided. And there is the obvious difference in
devicetree layout, which would look something like:
display {
compatible = marvell,armada-510-display;
clocks = ext_clk0, lcd_pll_clk;
lcd0 {
compatible = marvell,armada-510-lcd;
reg = 0xf182 0x1000;
interrupts = 47;
};
lcd1 {
compatible = marvell,armada-510-lcd;
reg = 0xf181 0x1000;
interrupts = 46;
};
dcon {
compatible = marvell,armada-510-dcon;
reg = ...;
};
};
Any thoughts/comments?
Thanks
Daniel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk wrote:
I will point out that relying on driver probing orders has already been
stated by driver model people to be unsafe. This is why I will not
adopt such a solution for my driver; it is a bad design.
Just to clarify, what you're objecting to is effectively the
following? Because it is not guaranteed in the future that the probe
order will be the same as the platform_driver_register() calls?
static int __init exynos_drm_init(void)
{
ret = platform_driver_register(hdmi_driver);
if (ret 0)
goto out_hdmi;
ret = platform_driver_register(mixer_driver);
if (ret 0)
goto out_mixer;
ret = platform_driver_register(exynos_drm_common_hdmi_driver);
if (ret 0)
goto out_common_hdmi;
ret = platform_driver_register(exynos_drm_platform_driver);
if (ret 0)
goto out_drm;
(exynos_drm_platform_driver is the driver that creates the drm_device)
Thanks
Daniel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: I am against a super node which contains lcd and dcon/ire nodes. You can enable those devices on a per board basis. We add them to dove.dtsi but disable them by default (status = disabled). The DRM driver itself should get a video-card node outside of soc/internal-regs where you can put e.g. video memory hole (or video mem size if it will be taken from RAM later) For completeness of the discussion, and my understanding too, can you explain your objections to the display super-node in a bit more detail? Thanks Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] Add OLPC AP-SP input driver
The OLPC XO-1.75 and XO-4 laptops include a PS/2 touchpad and an AT
keyboard, yet they do not have a hardware PS/2 controller. Instead, a
firmware runs on a dedicated core (Security Processor, part of the SoC)
that acts as a PS/2 controller through bit-banging.
Communication between the main cpu (Application Processor) and the
Security Processor happens via a standard command mechanism implemented
by the SoC. Add a driver for this interface to enable keyboard/mouse
input on this platform.
Original author: Saadia Baloch
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/serio/olpc,ap-sp.txt | 13 +
drivers/input/serio/Kconfig| 10 +
drivers/input/serio/Makefile | 1 +
drivers/input/serio/olpc_apsp.c| 276 +
4 files changed, 300 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
create mode 100644 drivers/input/serio/olpc_apsp.c
v2: Use dev_dbg(). Disable interrupts during unload, and remove bad use of
devm. Thanks to Dmitry for the quick review.
diff --git a/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
new file mode 100644
index 000..0e72183
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
@@ -0,0 +1,13 @@
+OLPC AP-SP serio interface
+
+Required properties:
+- compatible : olpc,ap-sp
+- reg : base address and length of SoC's WTM registers
+- interrupts : SP-AP interrupt
+
+Example:
+ ap-sp@d429 {
+ compatible = olpc,ap-sp;
+ reg = 0xd429 0x1000;
+ interrupts = 40;
+ }
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 1bda828..94c17c2 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -256,4 +256,14 @@ config SERIO_APBPS2
To compile this driver as a module, choose M here: the module will
be called apbps2.
+config SERIO_OLPC_APSP
+ tristate OLPC AP-SP input support
+ depends on OF
+ help
+ Say Y here if you want support for the keyboard and touchpad included
+ in the OLPC XO-1.75 and XO-4 laptops.
+
+ To compile this driver as a module, choose M here: the module will
+ be called olpc_apsp.
+
endif
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 8edb36c..12298b1 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -27,3 +27,4 @@ obj-$(CONFIG_SERIO_XILINX_XPS_PS2)+= xilinx_ps2.o
obj-$(CONFIG_SERIO_ALTERA_PS2) += altera_ps2.o
obj-$(CONFIG_SERIO_ARC_PS2)+= arc_ps2.o
obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
+obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o
diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
new file mode 100644
index 000..9d65b6b
--- /dev/null
+++ b/drivers/input/serio/olpc_apsp.c
@@ -0,0 +1,276 @@
+/*
+ * OLPC serio driver for multiplexed input from Marvell MMP security processor
+ *
+ * Copyright (C) 2011-2013 One Laptop Per Child
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/init.h
+#include linux/serio.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/of.h
+#include linux/slab.h
+#include linux/delay.h
+
+/*
+ * The OLPC XO-1.75 and XO-4 laptops do not have a hardware PS/2 controller.
+ * Instead, the OLPC firmware runs a bit-banging PS/2 implementation on an
+ * otherwise-unused slow processor which is included in the Marvell MMP2/MMP3
+ * SoC, known as the Security Processor (SP) or Wireless Trusted Module
+ * (WTM). This firmware then reports its results via the WTM registers,
+ * which we read from the Application Processor (AP, i.e. main CPU) in this
+ * driver.
+ *
+ * On the hardware side we have a PS/2 mouse and an AT keyboard, the data
+ * is multiplexed through this system. We create a serio port for each one,
+ * and demultiplex the data accordingly.
+ */
+
+/* WTM register offsets */
+#define SECURE_PROCESSOR_COMMAND 0x40
+#define COMMAND_RETURN_STATUS 0x80
+#define COMMAND_FIFO_STATUS0xc4
+#define PJ_RST_INTERRUPT 0xc8
+#define PJ_INTERRUPT_MASK 0xcc
+
+/* The upper byte of SECURE_PROCESSOR_COMMAND and COMMAND_RETURN_STATUS is
+ * used to identify which port (device) is being talked to. The lower byte
[PATCH v3] Add OLPC AP-SP input driver
The OLPC XO-1.75 and XO-4 laptops include a PS/2 touchpad and an AT
keyboard, yet they do not have a hardware PS/2 controller. Instead, a
firmware runs on a dedicated core (Security Processor, part of the SoC)
that acts as a PS/2 controller through bit-banging.
Communication between the main cpu (Application Processor) and the
Security Processor happens via a standard command mechanism implemented
by the SoC. Add a driver for this interface to enable keyboard/mouse
input on this platform.
Original author: Saadia Baloch
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/serio/olpc,ap-sp.txt | 13 +
drivers/input/serio/Kconfig| 10 +
drivers/input/serio/Makefile | 1 +
drivers/input/serio/olpc_apsp.c| 280 +
4 files changed, 304 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
create mode 100644 drivers/input/serio/olpc_apsp.c
v2: Use dev_dbg(). Disable interrupts during unload, and remove bad use of
devm.
v3: Avoid sleep in write function. Reference count open/close operations
as both ports share the same interrupt. Fix devm_ioremap_resource() error
handling. Use SERIO_8042 type. Only register IRQ handler after port structure
is ready.
diff --git a/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
new file mode 100644
index 000..0e72183
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
@@ -0,0 +1,13 @@
+OLPC AP-SP serio interface
+
+Required properties:
+- compatible : olpc,ap-sp
+- reg : base address and length of SoC's WTM registers
+- interrupts : SP-AP interrupt
+
+Example:
+ ap-sp@d429 {
+ compatible = olpc,ap-sp;
+ reg = 0xd429 0x1000;
+ interrupts = 40;
+ }
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 1bda828..94c17c2 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -256,4 +256,14 @@ config SERIO_APBPS2
To compile this driver as a module, choose M here: the module will
be called apbps2.
+config SERIO_OLPC_APSP
+ tristate OLPC AP-SP input support
+ depends on OF
+ help
+ Say Y here if you want support for the keyboard and touchpad included
+ in the OLPC XO-1.75 and XO-4 laptops.
+
+ To compile this driver as a module, choose M here: the module will
+ be called olpc_apsp.
+
endif
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 8edb36c..12298b1 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -27,3 +27,4 @@ obj-$(CONFIG_SERIO_XILINX_XPS_PS2)+= xilinx_ps2.o
obj-$(CONFIG_SERIO_ALTERA_PS2) += altera_ps2.o
obj-$(CONFIG_SERIO_ARC_PS2)+= arc_ps2.o
obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
+obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o
diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
new file mode 100644
index 000..c4d3624
--- /dev/null
+++ b/drivers/input/serio/olpc_apsp.c
@@ -0,0 +1,280 @@
+/*
+ * OLPC serio driver for multiplexed input from Marvell MMP security processor
+ *
+ * Copyright (C) 2011-2013 One Laptop Per Child
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/init.h
+#include linux/serio.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/of.h
+#include linux/slab.h
+#include linux/delay.h
+
+/*
+ * The OLPC XO-1.75 and XO-4 laptops do not have a hardware PS/2 controller.
+ * Instead, the OLPC firmware runs a bit-banging PS/2 implementation on an
+ * otherwise-unused slow processor which is included in the Marvell MMP2/MMP3
+ * SoC, known as the Security Processor (SP) or Wireless Trusted Module
+ * (WTM). This firmware then reports its results via the WTM registers,
+ * which we read from the Application Processor (AP, i.e. main CPU) in this
+ * driver.
+ *
+ * On the hardware side we have a PS/2 mouse and an AT keyboard, the data
+ * is multiplexed through this system. We create a serio port for each one,
+ * and demultiplex the data accordingly.
+ */
+
+/* WTM register offsets */
+#define SECURE_PROCESSOR_COMMAND 0x40
+#define COMMAND_RETURN_STATUS 0x80
+#define COMMAND_FIFO_STATUS0xc4
+#define PJ_RST_INTERRUPT 0xc8
+#define
Re: [PATCH v3] Add OLPC AP-SP input driver
On Fri, Jun 28, 2013 at 12:20 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
+static void olpc_apsp_close(struct serio *port)
+{
+ struct olpc_apsp *priv = port-port_data;
+ unsigned int tmp;
+
+ if (--priv-open_count == 0) {
Both need locking. It looks like you need the song and dance similar to
what i8042 has to do with it's multiplexed ports. Or ps2mult.c...
I thought they would both be locked already, due to this comment in serio.c:
/* called from serio_driver-connect/disconnect methods under serio_mutex */
Or am I missing something there?
Thanks
Daniel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] Add OLPC AP-SP input driver
The OLPC XO-1.75 and XO-4 laptops include a PS/2 touchpad and an AT
keyboard, yet they do not have a hardware PS/2 controller. Instead, a
firmware runs on a dedicated core (Security Processor, part of the SoC)
that acts as a PS/2 controller through bit-banging.
Communication between the main cpu (Application Processor) and the
Security Processor happens via a standard command mechanism implemented
by the SoC. Add a driver for this interface to enable keyboard/mouse
input on this platform.
Original author: Saadia Baloch
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/serio/olpc,ap-sp.txt | 13 +
drivers/input/serio/Kconfig| 10 +
drivers/input/serio/Makefile | 1 +
drivers/input/serio/olpc_apsp.c| 264 +
4 files changed, 288 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
create mode 100644 drivers/input/serio/olpc_apsp.c
diff --git a/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
new file mode 100644
index 000..0e72183
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
@@ -0,0 +1,13 @@
+OLPC AP-SP serio interface
+
+Required properties:
+- compatible : olpc,ap-sp
+- reg : base address and length of SoC's WTM registers
+- interrupts : SP-AP interrupt
+
+Example:
+ ap-sp@d429 {
+ compatible = olpc,ap-sp;
+ reg = 0xd429 0x1000;
+ interrupts = 40;
+ }
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 1bda828..94c17c2 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -256,4 +256,14 @@ config SERIO_APBPS2
To compile this driver as a module, choose M here: the module will
be called apbps2.
+config SERIO_OLPC_APSP
+ tristate OLPC AP-SP input support
+ depends on OF
+ help
+ Say Y here if you want support for the keyboard and touchpad included
+ in the OLPC XO-1.75 and XO-4 laptops.
+
+ To compile this driver as a module, choose M here: the module will
+ be called olpc_apsp.
+
endif
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 8edb36c..12298b1 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -27,3 +27,4 @@ obj-$(CONFIG_SERIO_XILINX_XPS_PS2)+= xilinx_ps2.o
obj-$(CONFIG_SERIO_ALTERA_PS2) += altera_ps2.o
obj-$(CONFIG_SERIO_ARC_PS2)+= arc_ps2.o
obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
+obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o
diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
new file mode 100644
index 000..068195c
--- /dev/null
+++ b/drivers/input/serio/olpc_apsp.c
@@ -0,0 +1,264 @@
+/*
+ * OLPC serio driver for multiplexed input from Marvell MMP security processor
+ *
+ * Copyright (C) 2011-2013 One Laptop Per Child
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/init.h
+#include linux/serio.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/of.h
+#include asm/irq.h
+#include linux/delay.h
+
+/*
+ * The OLPC XO-1.75 and XO-4 laptops do not have a hardware PS/2 controller.
+ * Instead, the OLPC firmware runs a bit-banging PS/2 implementation on an
+ * otherwise-unused slow processor which is included in the Marvell MMP2/MMP3
+ * SoC, known as the Security Processor (SP) or Wireless Trusted Module
+ * (WTM). This firmware then reports its results via the WTM registers,
+ * which we read from the Application Processor (AP, i.e. main CPU) in this
+ * driver.
+ *
+ * On the hardware side we have a PS/2 mouse and an AT keyboard, the data
+ * is multiplexed through this system. We create a serio port for each one,
+ * and demultiplex the data accordingly.
+ */
+
+static bool apsp_debug;
+module_param_named(debug, apsp_debug, bool, 0600);
+MODULE_PARM_DESC(debug, Turn debugging mode on and off);
+
+#define dbg(format, arg...)\
+ do {\
+ if (apsp_debug) \
+ pr_info(KBUILD_MODNAME : format, ##arg); \
+ } while (0)
+
+
+/* WTM register offsets */
+#define SECURE_PROCESSOR_COMMAND 0x40
+#define
[PATCH 2/2] clk: mmp: add support for DT-defined clocks
Add support to the existing mmp clock drivers for clocks to be defined
in the device tree. This will be used on OLPC MMP2/MMP3-based laptops.
If clock info cannot be found in the device tree, we fall back to the
static clock initialization already present.
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/clock/mmp-apbc.txt | 30 ++
.../devicetree/bindings/clock/mmp-apmu.txt | 30 ++
drivers/clk/mmp/clk-apbc.c | 66 +-
drivers/clk/mmp/clk-apmu.c | 37 +++-
drivers/clk/mmp/clk-mmp2.c | 19 ++-
5 files changed, 179 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/mmp-apbc.txt
create mode 100644 Documentation/devicetree/bindings/clock/mmp-apmu.txt
diff --git a/Documentation/devicetree/bindings/clock/mmp-apbc.txt
b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
new file mode 100644
index 000..88e1253
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Advanced Peripheral Bus clock
+
+Parent apb-clock node
+=
+Required properties:
+- reg: Address and length of the APB clock unit registers
+
+
+Child peripheral clock nodes
+
+Required properties:
+- compatible : shall be marvell,mmp-apb-clock
+- #clock-cells : from common clock binding; shall be set to 1
+- clocks : parent clock, from common clock binding
+- clock-output-names : Array of clock names, from common clock binding
+- reg : Array of control register offsets into APB clock unit register space
+
+
+Example:
+apbc: apb-clock {
+ reg = 0xd4015000 0x1000;
+
+ twsi-clocks {
+ compatible = marvell,mmp-apb-clock;
+ #clock-cells = 1;
+ clocks = vctvxo-clock;
+ clock-output-names = TWSI0, TWSI1;
+ reg = 0x04 0x08;
+ };
+};
diff --git a/Documentation/devicetree/bindings/clock/mmp-apmu.txt
b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
new file mode 100644
index 000..18bb0f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Application Subsystem Power Management Unit
+
+Parent apmu-clock node
+=
+Required properties:
+- reg: Address and length of the CPU Subsystem PMU registers
+
+
+Child peripheral clock nodes
+
+Required properties:
+- compatible : shall be marvell,mmp-apmu-clock
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : parent clock, from common clock binding
+- reg : Control register offsets into parent register space
+- enable-mask : The bits to be set in the register to enable the clock, or
+cleared to disable.
+
+Example:
+apmu-clock {
+ reg = 0xd4282800 0x1000;
+
+ usb-clock {
+ compatible = marvell,mmp-apmu-clock;
+ #clock-cells = 0;
+ clocks = usb_pll;
+ reg = 0x5c;
+ enable-mask = 0x09;
+ };
+};
diff --git a/drivers/clk/mmp/clk-apbc.c b/drivers/clk/mmp/clk-apbc.c
index 89a146a..d53bc79 100644
--- a/drivers/clk/mmp/clk-apbc.c
+++ b/drivers/clk/mmp/clk-apbc.c
@@ -15,6 +15,8 @@
#include linux/err.h
#include linux/delay.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_address.h
#include clk.h
@@ -129,8 +131,70 @@ struct clk *mmp_clk_register_apbc(const char *name, const
char *parent_name,
apbc-hw.init = init;
clk = clk_register(NULL, apbc-hw);
- if (IS_ERR(clk))
+ if (WARN_ON(IS_ERR(clk)))
kfree(apbc);
return clk;
}
+
+static void __init mmp_apbc_dt_init(struct device_node *node)
+{
+ struct device_node *parent = of_get_parent(node);
+ const __be32 *regs;
+ struct clk *clk;
+ int rc;
+ int len;
+ int num_clocks;
+ int clock_num;
+ void __iomem *baseaddr;
+ const char *clock_name;
+ const char *parent_name;
+ struct clk **clks;
+ struct clk_onecell_data *clk_data;
+
+ regs = of_get_property(node, reg, len);
+ if (WARN_ON(!regs || (len % sizeof(__be32) != 0)))
+ return;
+ num_clocks = len / sizeof(__be32);
+
+ baseaddr = of_iomap(parent, 0);
+ of_node_put(parent);
+ if (WARN_ON(!baseaddr))
+ return;
+
+ clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
+ if (WARN_ON(!clk_data))
+ goto err_clk_data;
+
+ clks = kzalloc(num_clocks * sizeof(*clks), GFP_KERNEL);
+ if (WARN_ON(!clks))
+ goto err_clks;
+
+ clock_name = of_get_property(node, clock-output-names, NULL);
+ parent_name = of_clk_get_parent_name(node, 0);
+
+ for (clock_num = 0; clock_num num_clocks; clock_num++) {
+ void
[PATCH] ARM: mmp: irq: Improve DT layout
In the mmp2 device tree, the interrupt mux nodes were peers of the
interrupt controller, yet they mapped registers in conflict with the
interrupt controller's register block. Furthermore, the reg properties of
the muxes disagreed with the unit address specified after the node's @-sign.
Move the interrupt mux nodes underneath the interrupt controller node,
because the registers are subordinate to the interrupt controller device,
and update the documentation accordingly.
In the platform code, avoid using of_address_to_resource(). Treating a
reg value of 0x150 as a resource effectively is mapping to memory
location 0x150, which is not what's happening here. Use of_get_address()
instead, to better reflect that we're dealing with an address offset
being read from the device tree.
This adds support for the device tree shipped in the OLPC XO-4 and
additionally these code changes do not break compatibility with the
old DT layout.
Based on work by Mitch Bradley.
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/arm/mrvl/intc.txt | 41 ---
arch/arm/boot/dts/mmp2.dtsi| 128 ++---
arch/arm/mach-mmp/irq.c| 16 +--
3 files changed, 95 insertions(+), 90 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 3554fb9..0c020ff 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -2,21 +2,24 @@
Required properties:
- compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
- mrvl,mmp2-mux-intc
-- reg : Address and length of the register set of the interrupt controller.
- If the interrupt controller is intc, address and length means the range
- of the whold interrupt controller. If the interrupt controller is mux-intc,
- address and length means one register. Since address of mux-intc is in the
- range of intc. mux-intc is secondary interrupt controller.
-- reg-names : Name of the register set of the interrupt controller. It's
- only required in mux-intc interrupt controller.
-- interrupts : Should be the port interrupt shared by mux interrupts. It's
- only required in mux-intc interrupt controller.
+- reg : Address and length of the register set of the whole interrupt
+ controller.
- interrupt-controller : Identifies the node as an interrupt controller.
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source.
- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
controller.
+
+* Marvell MMP Secondary Interrupt controller (mux)
+
+Required properties:
+ - compatible : Shall be mrvl,mmp2-mux-intc
+ Address and length of one register offset into the register address space of
+ the parent interrupt controller node.
+- reg-names : Name of the register set of the interrupt controller.
+- interrupts : Should be the port interrupt shared by mux interrupts.
+- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
+ controller.
- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
detection first.
@@ -27,16 +30,16 @@ Example:
#interrupt-cells = 1;
reg = 0xd4282000 0x1000;
mrvl,intc-nr-irqs = 64;
- };
- intcmux4@d4282150 {
- compatible = mrvl,mmp2-mux-intc;
- interrupts = 4;
- interrupt-controller;
- #interrupt-cells = 1;
- reg = 0x150 0x4, 0x168 0x4;
- reg-names = mux status, mux mask;
- mrvl,intc-nr-irqs = 2;
+ intcmux4@150 {
+ compatible = mrvl,mmp2-mux-intc;
+ interrupts = 4;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ reg = 0x150 0x4, 0x168 0x4;
+ reg-names = mux status, mux mask;
+ mrvl,intc-nr-irqs = 2;
+ };
};
* Marvell Orion Interrupt controller
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 4e8b08c..171e6e2 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -44,77 +44,77 @@
#interrupt-cells = 1;
reg = 0xd4282000 0x1000;
mrvl,intc-nr-irqs = 64;
- };
- intcmux4: interrupt-controller@d4282150 {
- compatible = mrvl,mmp2-mux-intc;
- interrupts = 4;
- interrupt-controller;
- #interrupt-cells = 1;
- reg = 0x150 0x4, 0x168 0x4;
- reg-names = mux status, mux mask;
- mrvl,intc-nr-irqs = 2
[PATCH 1/2] sdhci: add quirk for lack of 1.8v support
The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
capable, and it truthfully reports so in its capabilities. This
alternate voltage is used for driving new UHS-I SD cards at their
full speed.
However, what the controller doesn't know is that the motherboard
physically doesn't have a 1.8v supply available.
Add a quirk so that systems such as this one can override disable
1.8v support, adding support for UHS-I cards (by running them at
3.3v).
This avoids a problem where the system would first try to run the
card at 1.8v, fail, and then not be able to fully reset the card
to retry at the normal 3.3v voltage.
This is more appropriate than using the MISSING_CAPS quirk, which
is intended for cases where the SDHCI controller is actually lying
about its capabilities, and would force us to somehow override both
caps words from another source.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/mmc/host/sdhci.c | 4
include/linux/mmc/sdhci.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c7851c0..7273523 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2865,6 +2865,10 @@ int sdhci_add_host(struct sdhci_host *host)
caps[1] = ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
SDHCI_SUPPORT_DDR50);
+ if (host-quirks2 SDHCI_QUIRK2_NO_1_8_V)
+ caps[1] = ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
+ SDHCI_SUPPORT_DDR50);
+
/* Any UHS-I mode in caps implies SDR12 and SDR25 support. */
if (caps[1] (SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
SDHCI_SUPPORT_DDR50))
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 1edcb4d..1a42747 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -92,6 +92,8 @@ struct sdhci_host {
#define SDHCI_QUIRK2_HOST_OFF_CARD_ON (10)
#define SDHCI_QUIRK2_HOST_NO_CMD23 (11)
+/* The system physically doesn't support 1.8v, even if the host does */
+#define SDHCI_QUIRK2_NO_1_8_V (12)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.7.11.7
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] mmc: add no-1-8-v device tree flag
The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v capable, and it truthfully reports so in its capabilities. This alternate voltage is used for driving new UHS-I SD cards at their full speed. However, what the controller doesn't know is that the motherboard physically doesn't have a 1.8v supply available, so attempting to switch to the 1.8v level will result in a situation that cannot be recovered from without physically replugging the SD card. Add a device tree flag that can be used on systems like these, and hook it up to the equivalent SDHCI quirk. Signed-off-by: Daniel Drake d...@laptop.org --- Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ drivers/mmc/host/sdhci-pltfm.c| 3 +++ 2 files changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8e2e0ba..3f13702 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -21,6 +21,8 @@ Optional properties: - cd-inverted: when present, polarity on the cd gpio line is inverted - wp-inverted: when present, polarity on the wp gpio line is inverted - 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. Example: diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index 2716445..0a16534 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -78,6 +78,9 @@ void sdhci_get_of_property(struct platform_device *pdev) if (of_get_property(np, broken-cd, NULL)) host-quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION; + if (of_get_property(np, no-1-8-v, NULL)) + host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V; + if (of_device_is_compatible(np, fsl,p2020-rev1-esdhc)) host-quirks |= SDHCI_QUIRK_BROKEN_DMA; -- 1.7.11.7 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] sdhci: add quirk for lack of 1.8v support
On Sun, Nov 25, 2012 at 12:36 PM, Philip Rakity prak...@nvidia.com wrote: The same effect can be achieved by setting the quirk SDHCI_QUIRK_MISSING_CAPS reading caps[0] and removing from caps[1] the UHS values in the controller specific code for your board. What is the reason you cannot do this ? The same reasons we already touched upon in the other thread. http://marc.info/?l=linux-mmcm=135240077826454w=2 http://marc.info/?l=linux-mmcm=135240181826846w=2 To reiterate (I know this has been broken out over a couple of weeks): There is no controller-specific or board-specific code. We are working with the device tree. It must be done generically. SDHCI_QUIRK_MISSING_CAPS seems to be aimed at cases where the controller does not report caps, or it is lying about the caps it does/doesn't support. In this case our controller is being truthful, so this does not feel appropriate. Also, the only realistic way that I can see to combine SDHCI_QUIRK_MISSING_CAPS with the device tree would be to put the caps/caps1 override data in the device tree. This just seems ugly, and feels like it is taking the wrong approach of again suggesting that the controller is providing bad data, when in this case actually it is correctly saying that 1.8v is supported (by the controller - it obviously cannot speak for external components). We don't have a regulator to work with here. Thanks Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Challenges of migrating to DT
Hi, At OLPC we are working hard to migrate from board files to the device tree for our existing ARM laptop XO-1.75, and we are also working directly with the DT (no board file) from day 1 with development of our upcoming XO-4 ARM laptop. While the coding aspect is going fine, we have some open questions around the migration aspects and sustainability of our DT efforts. I'm wondering if these issues extend to other DT users and if there are any experiences that we can learn from. The root of the issue is that using DT creates a strong bond between the firmware (DT provider) and the kernel (DT consumer). However, we cannot guarantee that our users stick to specific firmware/DT pair. 1. For our existing XO-1.75 users in the field, our existing DT is not good enough to allow a DT-based kernel to boot. When we upgrade these systems from board-file-based kernels to DT ones, we can also push a firmware update, but we cannot guarantee that the firmware update gets installed at the same time as the new kernel. (The firmware will only be updated when AC power is available, and it typically isn't available at the time when the software update is received from the school server). So this covers the first tricky situation: upgrades. We have an issue where we ideally need to support an old, DT-less firmware running against a kernel with no board file that looks to do everything from the DT. 2. For our new XO-4 efforts, we are having to define DT layouts for the hardware shipped in the laptop. And while we're working hard to do this cleanly, I fear that the upstreaming process will result in some (incompatible?) changes to these nodes and layouts. However, we're under time pressures and we're a small team; it seems unlikely that we'll be able to upstream much of this before our initial shipment to real users. So we will again potentially find ourselves in a similar situation to above, where old software releases (i.e. the one shipped to first customers) include a DT that it somehow incompatible/insufficient for a new kernel (some time later when we upstream things and move to the upstream-refined DT layout). I know that there is a great deal of help available on this list for the upstreaming process, and in an ideal world we'd upstream everything before shipping, but in this case reality takes a nasty bite (resources-wise this would be difficult to achieve for us) and I'm wondering if others have faced similar situations in the past. One solution that initially stands out is appending the DT to the kernel image, to break the tricky bond between firmware and kernel. But this is probably harder than it sounds; we ship slightly different versions of these laptops (with/without touchscreen, different camera sensors, ...) and shipping different kernels to cover all the different combinations would be painful. More discussion here: http://wiki.laptop.org/go/Device_tree_upgrade_considerations Thanks Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
On Wed, Sep 28, 2011 at 1:31 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Right, but your modification was to the MFD core so it's going to affect other devices... But only when they start using the newly added functionality. At this point, it affects nobody except vx855. Grant, any chance I could have your comments on the latest patches? http://marc.info/?l=linux-kernelm=131720353308737w=2 http://marc.info/?l=linux-kernelm=131720341808574w=2 http://marc.info/?l=linux-kernelm=131720093305636w=2 Thanks, Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
On Mon, Oct 3, 2011 at 1:16 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: It seems to me like either the IP block is heavily dependant on the core and shouldn't be split out in the device tree at all (but should instead be part of the core node) or the IP block is very isolated from the core (in which case we should just be able to instantiate the device from the device tree without using explict code in the core driver). This all feels like there's some abstraction violation going on. I guess it is a matter of opinion. To me, the abstraction is sensible and representative of the hardware. The gpio controller (and several other components) are abstracted at the hardware level behind an ISA bridge. In the device tree, we have the ISA bridge represented as /pci/isa. Then we have various child nodes of that ISA bridge, such as the gpio controller at /pci/isa/gpios or the timer controller at /pci/isa/timer This also matches the way that the hardware is described by VIA in the specs, and it matches the way that Linux has its own device hierachy laid out (i.e. the ISA bridge driven by the mfd driver, which then spawns off a child device for the GPIO controller). It would not be possible to fold all of the isa bridge child components into the same device tree node without dealing with various namespace collisions. Grant, could we have your opinion on whether this is a good abstraction or not? and generally how we go forward. Thanks, Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
On Mon, Oct 3, 2011 at 1:40 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: So, I made two suggestions above and it sounds like you want the second one but you've only responded to the first one without commenting on the second. My second suggestion was that if the block is sufficiently isoltated from the core we should be able instantiate it from the device tree without requiring explicit code in the core driver. Sorry, hadn't quite grasped what you meant there. I understand now. It is an interesting idea but leaves me with some questions/problems: The GPIO controller needs to find its register space by looking at the PCI device (the ISA bridge). So probing it independently could maybe be viewed by some as a hierarchy violation as it would have to then hunt around for its PCI dev. According to Grant's hard rule, the parent device needs to be the thing that passes the of_node to the child. So we would still need a driver for the parent ISA bridge instantiating the child GPIO controller. Wouldn't that bring us straight back to the same problem (that the core needs code to instantiate the child)? Also, not an argument against the direction, but an outstanding problem that would need to be resolved: the x86 device tree implementation doesn't seem to follow Grant's design for how things should work (or maybe I misunderstood something), so work would be needed there first. See the unfinished discussion at http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-July/006853.html Thanks, Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
On Tue, Sep 27, 2011 at 7:38 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: You're modifying global data which should really be const and is shared between multiple devices in place. Probably you'll not notice any practical effects, especially if you don't happen to have multiple devices in the same system. I see. In this case, it would be impossible to have two VX855s in the same system, and if you did, you would have bigger problems. In this context what we're doing is safe. Thanks, Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] mfd: allow mfd_cell association with device tree node
This allows a mfd_cell to be linked with a device tree node, which
then allows child drivers to have easy access to that handle.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/mfd/mfd-core.c |1 +
include/linux/mfd/core.h |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 0902523..7d22dcd 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -87,6 +87,7 @@ static int mfd_add_device(struct device *parent, int id,
goto fail_device;
pdev-dev.parent = parent;
+ pdev-dev.of_node = cell-of_node;
if (cell-pdata_size) {
ret = platform_device_add_data(pdev,
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index 4e76163..9b836f9 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -15,6 +15,7 @@
#define MFD_CORE_H
#include linux/platform_device.h
+#include linux/of.h
/*
* This struct describes the MFD part (cell).
@@ -37,6 +38,9 @@ struct mfd_cell {
void*platform_data;
size_t pdata_size;
+ /* association with device tree node (optional) */
+ struct device_node *of_node;
+
/*
* These resources can be specified relative to the parent device.
* For accessing hardware you should use resources from the platform dev
--
1.7.6.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] mfd: link vx855 with device tree
Set the of_node of the mfd device, and use it to assign the of_node
of the child gpio cell. The child driver will then pass the handle to
gpiolib, which enables device-tree-probed gpio-leds and more.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/mfd/vx855.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/vx855.c b/drivers/mfd/vx855.c
index d698703..d223840 100644
--- a/drivers/mfd/vx855.c
+++ b/drivers/mfd/vx855.c
@@ -30,6 +30,7 @@
#include linux/platform_device.h
#include linux/pci.h
#include linux/mfd/core.h
+#include linux/of.h
/* offset into pci config space indicating the 16bit register containing
* the power management IO space base */
@@ -72,6 +73,27 @@ static struct mfd_cell vx855_cells[] = {
},
};
+static __devinit void vx855_set_of_nodes(struct pci_dev *pdev)
+{
+#ifdef CONFIG_OF
+ struct device_node *isa_node;
+ struct device_node *child;
+
+ isa_node = of_find_compatible_node(NULL, NULL, via,vx855-isa);
+ pdev-dev.of_node = isa_node;
+
+ if (!isa_node)
+ return;
+
+ for_each_child_of_node(isa_node, child) {
+ if (of_device_is_compatible(child, via,vx855-gpio)) {
+ vx855_cells[0].of_node = child;
+ break;
+ }
+ }
+#endif
+}
+
static __devinit int vx855_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
@@ -90,6 +112,8 @@ static __devinit int vx855_probe(struct pci_dev *pdev,
goto out;
}
+ vx855_set_of_nodes(pdev);
+
/* mask out the lowest seven bits, as they are always zero, but
* hardware returns them as 0x01 */
gpio_io_offset = 0xff80;
--
1.7.6.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] gpio-vx855: Add device tree binding
This is needed to enable the HDD LED on the OLPC XO-1.5 laptop,
enabled through devicetree and the gpio-leds driver.
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/gpio/gpio_vx855.txt| 20
drivers/gpio/gpio-vx855.c |9 +++--
2 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vx855.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio_vx855.txt
b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt
new file mode 100644
index 000..17285a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt
@@ -0,0 +1,20 @@
+VIA VX855 GPIO controller
+
+Required properties:
+- compatible : via,vx855-gpio
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters:
+ - bit 0 specifies polarity (0 for normal, 1 for inverted)
+- gpio-controller : Marks the device node as a GPIO controller.
+
+As VIA differentiates between GPI, GPO and GPIO on its 42 available pins,
+with each pin type restarting numbering at 0, the following numbering scheme
+is used in the device tree for the pin number:
+
+PIN NO VIA NAME
+0..13 GPI 0..13
+14..26 GPO 0..12
+27..41 GPIO 0..14
+
+For example, GPIO 11 (VIA name) is referred to with pin number 38 in the
+device tree.
diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c
index ef5aabd..2c300c9 100644
--- a/drivers/gpio/gpio-vx855.c
+++ b/drivers/gpio/gpio-vx855.c
@@ -201,7 +201,8 @@ static const char *vx855gpio_names[NR_VX855_GP] = {
VX855_GPIO12, VX855_GPIO13, VX855_GPIO14
};
-static void vx855gpio_gpio_setup(struct vx855_gpio *vg)
+static void vx855gpio_gpio_setup(struct vx855_gpio *vg,
+struct platform_device *pdev)
{
struct gpio_chip *c = vg-gpio;
@@ -216,6 +217,10 @@ static void vx855gpio_gpio_setup(struct vx855_gpio *vg)
c-ngpio = NR_VX855_GP;
c-can_sleep = 0;
c-names = vx855gpio_names;
+
+#ifdef CONFIG_OF_GPIO
+ c-of_node = pdev-dev.of_node;
+#endif
}
/* This platform device is ordinarily registered by the vx855 mfd driver */
@@ -264,7 +269,7 @@ static __devinit int vx855gpio_probe(struct platform_device
*pdev)
else
vg-gpo_reserved = true;
- vx855gpio_gpio_setup(vg);
+ vx855gpio_gpio_setup(vg, pdev);
ret = gpiochip_add(vg-gpio);
if (ret) {
--
1.7.6.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
On Wed, Sep 21, 2011 at 2:16 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
Not sure how the MFD cells could get at the OF node by using the
parent device - if the parent device had a OF node, wouldn't this
correspond to the parent instead of the child? Also, as far as I can
Well, obviously. But then with a lot of MFDs (including this one, the
GPIO driver is entirely specific to the parent) it's not clear that we
should be splitting the device up in the device tree in the first place
- our use of MFDs is a Linux implementation detail. If the child is
specific to the parent it can cooperate with the parent device happily.
My suspicion is that for device tree in cases where the MFD really is
totally independent of the parent we shouldn't need explicit MFD code to
instantiate the child at all any more in the same way that we should be
avoiding this for the SoCs.
The VX855 is somewhat a SoC if you ignore the fact that the processor
is separate.
The software-visible architecture is somewhat messy and may hide this however.
The fact that it exposes some things as individual PCI devices and
some as behind the ISA bridge (which the mfd driver latches onto) is
probably just there for legacy reasons. Once you get behind that
cover, you see that the VX855 register space is really quite
disorganised with individual bits within the same byte of
configuration space used for vastly different system components (e.g.
gpio bits mixed with acpi and audio stuff in the same byte) and you
get the feeling that this really is a lot of hardware combined. So the
discussion of independence is particularly tricky in this case.
Anyway, I think I have come up with an approach on these lines. The
mfd driver latches onto the ISA bridge, and the documented
architecture suggests that a whole bunch of stuff comes off this:
8042, interrupt controller, dma controller, rtc, serial, timer, gpio,
spi, ...
We already have this accurately laid out in the device tree hierarchy:
/pci/isa/ has a child node for each of the above mentioned things
(e.g. /pci/isa/timer , /pci/isa/rtc and so on)
So, the /pci/isa node nicely matches the vx855-mfd driver, so we can
assign its of_node to that. Then, the vx855-gpio driver can consult
the parent and then look at its children in order to find the of_node
for the gpio controller. I think this nicely crosses with Mark's
request that the ability to have constant mfd definitions isn't broken
any more than it is already, and with Grant's preference that the
parent resource has some contribution in helping the child gpio
controller driver find its of_node. How does the attached patch look?
Grant, what do you think of this, and the rest of the discussion so far?
Daniel (just trying to make our gpio-based HDD LED go blinky blink...)
diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c
index ef5aabd..fd24213 100644
--- a/drivers/gpio/gpio-vx855.c
+++ b/drivers/gpio/gpio-vx855.c
@@ -31,6 +31,7 @@
#include linux/platform_device.h
#include linux/pci.h
#include linux/io.h
+#include linux/of.h
#define MODULE_NAME vx855_gpio
@@ -201,7 +202,27 @@ static const char *vx855gpio_names[NR_VX855_GP] = {
VX855_GPIO12, VX855_GPIO13, VX855_GPIO14
};
-static void vx855gpio_gpio_setup(struct vx855_gpio *vg)
+static void vx855gpio_set_of_node(struct platform_device *pdev,
+ struct gpio_chip *c)
+{
+#ifdef CONFIG_OF
+ struct device_node *parent_node = pdev-dev.parent-of_node;
+ struct device_node *child;
+
+ if (!parent_node)
+ return;
+
+ for_each_child_of_node(parent_node, child) {
+ if (of_device_is_compatible(child, via,vx855-gpio)) {
+ c-of_node = child;
+ break;
+ }
+ }
+#endif
+}
+
+static void vx855gpio_gpio_setup(struct vx855_gpio *vg,
+struct platform_device *pdev)
{
struct gpio_chip *c = vg-gpio;
@@ -216,6 +237,7 @@ static void vx855gpio_gpio_setup(struct vx855_gpio *vg)
c-ngpio = NR_VX855_GP;
c-can_sleep = 0;
c-names = vx855gpio_names;
+ vx855gpio_set_of_node(pdev, c);
}
/* This platform device is ordinarily registered by the vx855 mfd driver */
@@ -264,7 +286,7 @@ static __devinit int vx855gpio_probe(struct platform_device
*pdev)
else
vg-gpo_reserved = true;
- vx855gpio_gpio_setup(vg);
+ vx855gpio_gpio_setup(vg, pdev);
ret = gpiochip_add(vg-gpio);
if (ret) {
diff --git a/drivers/mfd/vx855.c b/drivers/mfd/vx855.c
index d698703..aee9a5f 100644
--- a/drivers/mfd/vx855.c
+++ b/drivers/mfd/vx855.c
@@ -30,6 +30,7 @@
#include linux/platform_device.h
#include linux/pci.h
#include linux/mfd/core.h
+#include linux/of.h
/* offset into pci config space indicating the 16bit register containing
* the power management IO space base */
@@ -90,6 +91,10 @@ static __devinit int
Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
On Tue, Sep 27, 2011 at 4:05 PM, Grant Likely grant.lik...@secretlab.ca wrote:
What is a hard rule is that the code creating the children needs to
know what the binding is and populate the child's of_node
appropriately. Similarly, the child driver needs to know something
about the kinds of nodes it will be passed (can be tested by the
compatible property).
Thanks for your input.
Here is an updated patch which takes account of this hard rule.
It uses the dynamic mfd cell creation like before. Mark isn't keen on
this, but its how the driver works already, so I don't think it should
be a blocker. I don't know how else we can make the mfd framework meet
Grant's hard rule.
However, it does take Mark's suggestion into account that the mfd
should have some clear representation in the device tree. For us it
already did have (naturally), but this wasn't reflected in my earlier
patch. It is now - the location of the vx855-gpio node is based on
finding the mfd node and going from there.
Comments?
It obviously needs to be tested and split up into individual patches -
I'll do that shortly if this doesn't get shot down.
cheers
Daniel
diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c
index ef5aabd..2c300c9 100644
--- a/drivers/gpio/gpio-vx855.c
+++ b/drivers/gpio/gpio-vx855.c
@@ -201,7 +201,8 @@ static const char *vx855gpio_names[NR_VX855_GP] = {
VX855_GPIO12, VX855_GPIO13, VX855_GPIO14
};
-static void vx855gpio_gpio_setup(struct vx855_gpio *vg)
+static void vx855gpio_gpio_setup(struct vx855_gpio *vg,
+struct platform_device *pdev)
{
struct gpio_chip *c = vg-gpio;
@@ -216,6 +217,10 @@ static void vx855gpio_gpio_setup(struct vx855_gpio *vg)
c-ngpio = NR_VX855_GP;
c-can_sleep = 0;
c-names = vx855gpio_names;
+
+#ifdef CONFIG_OF_GPIO
+ c-of_node = pdev-dev.of_node;
+#endif
}
/* This platform device is ordinarily registered by the vx855 mfd driver */
@@ -264,7 +269,7 @@ static __devinit int vx855gpio_probe(struct platform_device
*pdev)
else
vg-gpo_reserved = true;
- vx855gpio_gpio_setup(vg);
+ vx855gpio_gpio_setup(vg, pdev);
ret = gpiochip_add(vg-gpio);
if (ret) {
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 0902523..7d22dcd 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -87,6 +87,7 @@ static int mfd_add_device(struct device *parent, int id,
goto fail_device;
pdev-dev.parent = parent;
+ pdev-dev.of_node = cell-of_node;
if (cell-pdata_size) {
ret = platform_device_add_data(pdev,
diff --git a/drivers/mfd/vx855.c b/drivers/mfd/vx855.c
index d698703..d223840 100644
--- a/drivers/mfd/vx855.c
+++ b/drivers/mfd/vx855.c
@@ -30,6 +30,7 @@
#include linux/platform_device.h
#include linux/pci.h
#include linux/mfd/core.h
+#include linux/of.h
/* offset into pci config space indicating the 16bit register containing
* the power management IO space base */
@@ -72,6 +73,27 @@ static struct mfd_cell vx855_cells[] = {
},
};
+static __devinit void vx855_set_of_nodes(struct pci_dev *pdev)
+{
+#ifdef CONFIG_OF
+ struct device_node *isa_node;
+ struct device_node *child;
+
+ isa_node = of_find_compatible_node(NULL, NULL, via,vx855-isa);
+ pdev-dev.of_node = isa_node;
+
+ if (!isa_node)
+ return;
+
+ for_each_child_of_node(isa_node, child) {
+ if (of_device_is_compatible(child, via,vx855-gpio)) {
+ vx855_cells[0].of_node = child;
+ break;
+ }
+ }
+#endif
+}
+
static __devinit int vx855_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
@@ -90,6 +112,8 @@ static __devinit int vx855_probe(struct pci_dev *pdev,
goto out;
}
+ vx855_set_of_nodes(pdev);
+
/* mask out the lowest seven bits, as they are always zero, but
* hardware returns them as 0x01 */
gpio_io_offset = 0xff80;
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index 4e76163..9b836f9 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -15,6 +15,7 @@
#define MFD_CORE_H
#include linux/platform_device.h
+#include linux/of.h
/*
* This struct describes the MFD part (cell).
@@ -37,6 +38,9 @@ struct mfd_cell {
void*platform_data;
size_t pdata_size;
+ /* association with device tree node (optional) */
+ struct device_node *of_node;
+
/*
* These resources can be specified relative to the parent device.
* For accessing hardware you should use resources from the platform dev
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
On Tue, Sep 27, 2011 at 7:14 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Sep 27, 2011 at 05:44:04PM +0100, Daniel Drake wrote: However, it does take Mark's suggestion into account that the mfd should have some clear representation in the device tree. For us it already did have (naturally), but this wasn't reflected in my earlier patch. It is now - the location of the vx855-gpio node is based on finding the mfd node and going from there. Why not just kmemdup() the template you're using rather than modifying it in place? Could do, but is there any point in this case? I'm not seeing it. The template is already being modified in this way in the current driver as well. Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
On Tue, Sep 27, 2011 at 7:26 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: That seems like a bug that just happened to get noticed while reviewing this change, though... Sorry if I'm missing something obvious but I'm not seeing the issue. What exactly is this bug and what effects could it cause? Thanks, Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] mfd: allow mfd_cell association with device tree node
This allows a mfd_cell to be linked with a device tree node, which
then allows child drivers to have easy access to that handle.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/mfd/mfd-core.c |1 +
include/linux/mfd/core.h |4
2 files changed, 5 insertions(+), 0 deletions(-)
I think this is what is being suggested at
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-September/008235.html
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 0902523..7d22dcd 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -87,6 +87,7 @@ static int mfd_add_device(struct device *parent, int id,
goto fail_device;
pdev-dev.parent = parent;
+ pdev-dev.of_node = cell-of_node;
if (cell-pdata_size) {
ret = platform_device_add_data(pdev,
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index 4e76163..9b836f9 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -15,6 +15,7 @@
#define MFD_CORE_H
#include linux/platform_device.h
+#include linux/of.h
/*
* This struct describes the MFD part (cell).
@@ -37,6 +38,9 @@ struct mfd_cell {
void*platform_data;
size_t pdata_size;
+ /* association with device tree node (optional) */
+ struct device_node *of_node;
+
/*
* These resources can be specified relative to the parent device.
* For accessing hardware you should use resources from the platform dev
--
1.7.6.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] mfd: link vx855 GPIO cell with device tree
The child driver will then pass the handle to gpiolib, which enables device-tree-probed gpio-leds and more. Signed-off-by: Daniel Drake d...@laptop.org --- drivers/mfd/vx855.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/vx855.c b/drivers/mfd/vx855.c index d698703..6466c21 100644 --- a/drivers/mfd/vx855.c +++ b/drivers/mfd/vx855.c @@ -101,6 +101,11 @@ static __devinit int vx855_probe(struct pci_dev *pdev, vx855_gpio_resources[1].start = gpio_io_offset + VX855_PMIO_R_GPO; vx855_gpio_resources[1].end = vx855_gpio_resources[1].start + 3; +#ifdef CONFIG_OF_GPIO + vx855_cells[0].of_node = of_find_compatible_node(NULL, NULL, +via,vx855-gpio); +#endif + ret = mfd_add_devices(pdev-dev, -1, vx855_cells, ARRAY_SIZE(vx855_cells), NULL, 0); -- 1.7.6.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] gpio-vx855: Add device tree binding
This is needed to enable the HDD LED on the OLPC XO-1.5 laptop,
enabled through devicetree and the gpio-leds driver.
Signed-off-by: Daniel Drake d...@laptop.org
---
.../devicetree/bindings/gpio/gpio_vx855.txt| 20
drivers/gpio/gpio-vx855.c |9 +++--
2 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vx855.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio_vx855.txt
b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt
new file mode 100644
index 000..17285a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt
@@ -0,0 +1,20 @@
+VIA VX855 GPIO controller
+
+Required properties:
+- compatible : via,vx855-gpio
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters:
+ - bit 0 specifies polarity (0 for normal, 1 for inverted)
+- gpio-controller : Marks the device node as a GPIO controller.
+
+As VIA differentiates between GPI, GPO and GPIO on its 42 available pins,
+with each pin type restarting numbering at 0, the following numbering scheme
+is used in the device tree for the pin number:
+
+PIN NO VIA NAME
+0..13 GPI 0..13
+14..26 GPO 0..12
+27..41 GPIO 0..14
+
+For example, GPIO 11 (VIA name) is referred to with pin number 38 in the
+device tree.
diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c
index ef5aabd..2c300c9 100644
--- a/drivers/gpio/gpio-vx855.c
+++ b/drivers/gpio/gpio-vx855.c
@@ -201,7 +201,8 @@ static const char *vx855gpio_names[NR_VX855_GP] = {
VX855_GPIO12, VX855_GPIO13, VX855_GPIO14
};
-static void vx855gpio_gpio_setup(struct vx855_gpio *vg)
+static void vx855gpio_gpio_setup(struct vx855_gpio *vg,
+struct platform_device *pdev)
{
struct gpio_chip *c = vg-gpio;
@@ -216,6 +217,10 @@ static void vx855gpio_gpio_setup(struct vx855_gpio *vg)
c-ngpio = NR_VX855_GP;
c-can_sleep = 0;
c-names = vx855gpio_names;
+
+#ifdef CONFIG_OF_GPIO
+ c-of_node = pdev-dev.of_node;
+#endif
}
/* This platform device is ordinarily registered by the vx855 mfd driver */
@@ -264,7 +269,7 @@ static __devinit int vx855gpio_probe(struct platform_device
*pdev)
else
vg-gpo_reserved = true;
- vx855gpio_gpio_setup(vg);
+ vx855gpio_gpio_setup(vg, pdev);
ret = gpiochip_add(vg-gpio);
if (ret) {
--
1.7.6.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
On Wed, Sep 21, 2011 at 1:49 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Wed, Sep 21, 2011 at 01:01:48PM +0100, Daniel Drake wrote:
@@ -37,6 +38,9 @@ struct mfd_cell {
void *platform_data;
size_t pdata_size;
+ /* association with device tree node (optional) */
+ struct device_node *of_node;
+
This doesn't seem great as it means that the mfd_cells can't be static
data, they have to be allocated per device. Why can't the MFD cells get
at the OF node by using the parent device in the same way as they
(mostly) get platform data at the minute?
Thanks for reviewing.
The data can still be static, not needing allocation, it just has to
be modified at runtime. See patch 2.
Not sure how the MFD cells could get at the OF node by using the
parent device - if the parent device had a OF node, wouldn't this
correspond to the parent instead of the child? Also, as far as I can
see, platform data is passed to the child in exactly the same way - by
including it in the mfd_cell definition - see mfd_add_device():
if (cell-pdata_size) {
ret = platform_device_add_data(pdev,
cell-platform_data, cell-pdata_size);
if (ret)
goto fail_res;
}
Daniel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] gpio-vx855: Add device tree binding
On Wed, Sep 21, 2011 at 1:50 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Sep 21, 2011 at 01:02:14PM +0100, Daniel Drake wrote: +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) Shouldn't we just have a property for the polarity? Can't comment on the general design, but the way it is described/implemented in the patch is consistent with GPIO controllers in general in the kernel. e.g. its the same as gpio_nvidia, and it is then driven by the generic gpio/dt code rather than having to implement extra stuff in the vx855 driver. Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 RESEND 2] gpio-vx855: add device tree binding
Hi Grant, Thanks for looking at this. On Sat, Sep 17, 2011 at 4:56 PM, Grant Likely grant.lik...@secretlab.ca wrote: drivers/mfd/vx855.c should be modified to assign pdev-of_node, which can be used here for setting up c-of_node. There doesn't seem to be any obvious place in mfd/vx855.c to insert this. All the platform device creation and addition is done inside the mfd layer (e.g. mfd_add_device()). Should I look at extending the MFD API to allow for of_nodes to be passed in? Thanks, Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 RESEND 2] gpio-vx855: add device tree binding
This is needed to enable the HDD LED on the OLPC XO-1.5 laptop, enabled through devicetree and the gpio-leds driver. Signed-off-by: Daniel Drake d...@laptop.org --- .../devicetree/bindings/gpio/gpio_vx855.txt| 20 drivers/gpio/gpio-vx855.c |5 + 2 files changed, 25 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vx855.txt v2: extended the documentation with information about the pin numbering scheme, which matches that of the driver. diff --git a/Documentation/devicetree/bindings/gpio/gpio_vx855.txt b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt new file mode 100644 index 000..17285a5 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt @@ -0,0 +1,20 @@ +VIA VX855 GPIO controller + +Required properties: +- compatible : via,vx855-gpio +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) +- gpio-controller : Marks the device node as a GPIO controller. + +As VIA differentiates between GPI, GPO and GPIO on its 42 available pins, +with each pin type restarting numbering at 0, the following numbering scheme +is used in the device tree for the pin number: + +PIN NO VIA NAME +0..13 GPI 0..13 +14..26 GPO 0..12 +27..41 GPIO 0..14 + +For example, GPIO 11 (VIA name) is referred to with pin number 38 in the +device tree. diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c index ef5aabd..5b7e9ba 100644 --- a/drivers/gpio/gpio-vx855.c +++ b/drivers/gpio/gpio-vx855.c @@ -31,6 +31,7 @@ #include linux/platform_device.h #include linux/pci.h #include linux/io.h +#include linux/of.h #define MODULE_NAME vx855_gpio @@ -216,6 +217,10 @@ static void vx855gpio_gpio_setup(struct vx855_gpio *vg) c-ngpio = NR_VX855_GP; c-can_sleep = 0; c-names = vx855gpio_names; + +#ifdef CONFIG_OF_GPIO + c-of_node = of_find_compatible_node(NULL, NULL, via,vx855-gpio); +#endif } /* This platform device is ordinarily registered by the vx855 mfd driver */ -- 1.7.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 RESEND] gpio-vx855: add device tree binding
This is needed to enable the HDD LED on the OLPC XO-1.5 laptop, enabled through devicetree and the gpio-leds driver. Signed-off-by: Daniel Drake d...@laptop.org --- .../devicetree/bindings/gpio/gpio_vx855.txt| 20 drivers/gpio/gpio-vx855.c |5 + 2 files changed, 25 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vx855.txt v2: extended the documentation with information about the pin numbering scheme, which matches that of the driver. diff --git a/Documentation/devicetree/bindings/gpio/gpio_vx855.txt b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt new file mode 100644 index 000..17285a5 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt @@ -0,0 +1,20 @@ +VIA VX855 GPIO controller + +Required properties: +- compatible : via,vx855-gpio +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) +- gpio-controller : Marks the device node as a GPIO controller. + +As VIA differentiates between GPI, GPO and GPIO on its 42 available pins, +with each pin type restarting numbering at 0, the following numbering scheme +is used in the device tree for the pin number: + +PIN NO VIA NAME +0..13 GPI 0..13 +14..26 GPO 0..12 +27..41 GPIO 0..14 + +For example, GPIO 11 (VIA name) is referred to with pin number 38 in the +device tree. diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c index ef5aabd..5b7e9ba 100644 --- a/drivers/gpio/gpio-vx855.c +++ b/drivers/gpio/gpio-vx855.c @@ -31,6 +31,7 @@ #include linux/platform_device.h #include linux/pci.h #include linux/io.h +#include linux/of.h #define MODULE_NAME vx855_gpio @@ -216,6 +217,10 @@ static void vx855gpio_gpio_setup(struct vx855_gpio *vg) c-ngpio = NR_VX855_GP; c-can_sleep = 0; c-names = vx855gpio_names; + +#ifdef CONFIG_OF_GPIO + c-of_node = of_find_compatible_node(NULL, NULL, via,vx855-gpio); +#endif } /* This platform device is ordinarily registered by the vx855 mfd driver */ -- 1.7.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Enabling OLPC XO-1.5 HDD LED through device tree
Hi,
We'd like to use devicetree and gpio-leds magic to enable the HDD LED
on the XO-1.5 laptop. There are 3 steps needed. Review would be
appreciated:
1. The vx855-gpio driver patch just resubmitted:
http://marc.info/?l=linux-kernelm=131300843332366w=2
2. Addition of the gpio-leds device to the list of DT nodes probed as platform
devices on OLPC laptops (see patch included at end of mail), which will be
submitted to x86 tree for inclusion.
3. The following code which we plan to include in OpenFirmware for XO-1.5.
As advised, the gpio-leds node has been moved to the root of the tree, which
avoids the problems discussed in the thread titled
Same parts of DT being probed twice.
\ to be placed in new file via/gpio.fth
\ floaded by via/devices.fth
\ This implements the HDD LED in the form expected by Linux.
\ See Documentation/devicetree/bindings/gpio/led.txt
0 0 i44b /isa begin-package
gpios device-name
via,vx855-gpio +compatible
0 0 gpio-controller property
2 #gpio-cells integer-property
my-address my-space 8 reg
end-package
0 0 / begin-package
gpio-leds device-name
gpio-leds +compatible
new-device
hdd device-name
mmc2 linux,default-trigger string-property
\ gpios property will be added later to avoid relocation/byte-order issues
\ with embedding phandles in property values
finish-device
end-package
\ Create a gpios property in the child node. The
: make-gpios-property ( flags gpio# child-node$ -- )
find-device ( n1 n0 )
/isa/gpios locate-device abort Can't find gpios ( n1 n0 phandle )
encode-int rot encode-int encode+ rot encode-int encode+ gpios
property
device-end
;
stand-init: gpios properties
\ HDD LED is on GPIO38 as seen by Linux
\ which is GPIO11 in VIA docs. It is active low.
1 d# 38 /gpio-leds/hdd make-gpios-property
;
Thanks,
Daniel
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index d6ee929..63f8903 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -291,6 +291,7 @@ static struct of_device_id __initdata of_ids[] = {
{ .compatible = olpc,xo1-battery },
{ .compatible = olpc,xo1-dcon },
{ .compatible = olpc,xo1-rtc },
+ { .compatible = gpio-leds },
{},
};
--
1.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Same parts of DT being probed twice
On 22 July 2011 18:35, Grant Likely grant.lik...@secretlab.ca wrote: of_platform_bus_probe() from the root of the tree is the wrong approach for registering 'deep' devices. of_platform_bus_probe() only knows how to deal with platform_devices. The moment something non-trivial appears in between, it no longer works. What you really want from the description you've given is the following struct device hierarchy: platform_device(representing the pci bus) ---pci_dev(representing the isa bridge) ---isa_device(representing the via,vx855-gpio) To make this work, of_platform_bus_probe() creates the pci bus instance. The pci bus /driver/ is responsible for creating the isa bridge, and similarly the isa driver must be responsible for creating the gpio controller instance. Most of the pci support code that you need should already be there, but I haven't looked at what ISA is doing. OK, thanks for the explanation. In this case we don't need to create a platform_device for the vx855 gpio device - it is already handled through probing of the PCI bus which is discovered through other means. I only added it in the list as an item inbetween the root and gpio-leds. The gpio-leds node should be at the root of the tree, and everything gets a lot easier if you switch to using the new of_platform_populate() instead of of_platform_bus_probe(). That sounds more sensible. I'll check with our firmware guy when he gets back from his break and continue from there. However, even after fixing that, we will still be left with the generic x86 code probing pci and isa. This creates a huge array of platform devices (which are useless, or are devices that we already have other device instances for), and seems to take quite a while during boot. Is commit 9079b35364e75 wrong in some way? It has your acked-by, but seems to go against what you wrote above. Thanks, Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] of/irq: use of_find_property() to check for interrupt-controller
The interrupt-controller property is used as a marker with no value.
This check should check for existence of the property, rather than for
a non-NULL property value.
On the OLPC XO-1.5, this marker property exists in the correct place
but was not being picked up due to having no value. Using
of_find_property() avoids this issue.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/of/irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9f689f1..f86cc43 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -155,7 +155,7 @@ int of_irq_map_raw(struct device_node *parent, const __be32
*intspec,
/* Now check if cursor is an interrupt-controller and if it is
* then we are done
*/
- if (of_get_property(ipar, interrupt-controller, NULL) !=
+ if (of_find_property(ipar, interrupt-controller, NULL) !=
NULL) {
pr_debug( - got it !\n);
for (i = 0; i intsize; i++)
--
1.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] gpio-vx855: add device tree binding
This is needed to enable the HDD LED on the OLPC XO-1.5 laptop, enabled through devicetree and the gpio-leds driver. Signed-off-by: Daniel Drake d...@laptop.org --- .../devicetree/bindings/gpio/gpio_vx855.txt|8 drivers/gpio/gpio-vx855.c |5 + 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vx855.txt Grant, please review the chosen scheme (based on gpio_nvidia). Is the via,vx855-gpio compatible tag OK? I made it up. diff --git a/Documentation/devicetree/bindings/gpio/gpio_vx855.txt b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt new file mode 100644 index 000..93c0747 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt @@ -0,0 +1,8 @@ +VIA VX855 GPIO controller + +Required properties: +- compatible : via,vx855-gpio +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) +- gpio-controller : Marks the device node as a GPIO controller. diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c index ef5aabd..5b7e9ba 100644 --- a/drivers/gpio/gpio-vx855.c +++ b/drivers/gpio/gpio-vx855.c @@ -31,6 +31,7 @@ #include linux/platform_device.h #include linux/pci.h #include linux/io.h +#include linux/of.h #define MODULE_NAME vx855_gpio @@ -216,6 +217,10 @@ static void vx855gpio_gpio_setup(struct vx855_gpio *vg) c-ngpio = NR_VX855_GP; c-can_sleep = 0; c-names = vx855gpio_names; + +#ifdef CONFIG_OF_GPIO + c-of_node = of_find_compatible_node(NULL, NULL, via,vx855-gpio); +#endif } /* This platform device is ordinarily registered by the vx855 mfd driver */ -- 1.7.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Same parts of DT being probed twice
Hi,
We're working on enabling the HDD LED on the XO-1.5 laptop using
gpio-leds and its automatic interaction with the device tree. I have
it working locally, but there is something not quite right.
We have modified the device tree to add /pci/isa/gpios
gpios then has a child gpio-leds which has a child hdd as
described in Documentation/devicetree/bindings/gpio/gpio-leds.txt
This means that we must extend the matches list passed to
of_platform_bus_probe() in arch/x86/platform/olpc/olpc_dt.c so that
the search goes deep enough into the tree to find the gpio-leds
element and create a device for it. Specifically we must add:
{ .compatible = pci },
{ .compatible = isa },
{ .compatible = via,vx855-gpio },
{ .compatible = gpio-leds },
This works, but it causes huge duplication of the whole pci and isa
trees in /sys/devices. These devices were already created because
arch/x86/kernel/devicetree.c unconditionally calls
of_platform_bus_probe() for pci and isa devices (see add_bus_probe()
and ce4100_ids), but not for vx855-gpio and gpio-leds.
Whats the best way to solve this?
Thanks,
Daniel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 01/11] x86, olpc: add missing elements to device tree
In response to new device tree code in the kernel, OLPC will start
using it for probing of certain devices. However, some firmware fixes
are needed to put the devicetree into a usable state.
Retain compatibility with old firmware by fixing up the device tree
at boot-time if it does not contain the new nodes/properties that
we need for probing. This is the same approach taken on PPC platforms.
Signed-off-by: Daniel Drake d...@laptop.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Andres Salomon dilin...@queued.net
Cc: devicetree-discuss@lists.ozlabs.org
---
arch/x86/platform/olpc/olpc_dt.c | 103 ++
1 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index d39f63d..d6ee929 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -165,6 +165,107 @@ static struct of_pdt_ops prom_olpc_ops __initdata = {
.pkg2path = olpc_dt_pkg2path,
};
+static phandle __init olpc_dt_finddevice(const char *path)
+{
+ phandle node;
+ const void *args[] = { path };
+ void *res[] = { node };
+
+ if (olpc_ofw(finddevice, args, res)) {
+ pr_err(olpc_dt: finddevice failed!\n);
+ return 0;
+ }
+
+ if ((s32) node == -1)
+ return 0;
+
+ return node;
+}
+
+static int __init olpc_dt_interpret(const char *words)
+{
+ int result;
+ const void *args[] = { words };
+ void *res[] = { result };
+
+ if (olpc_ofw(interpret, args, res)) {
+ pr_err(olpc_dt: interpret failed!\n);
+ return -1;
+ }
+
+ return result;
+}
+
+/*
+ * Extract board revision directly from OFW device tree.
+ * We can't use olpc_platform_info because that hasn't been set up yet.
+ */
+static u32 __init olpc_dt_get_board_revision(void)
+{
+ phandle node;
+ __be32 rev;
+ int r;
+
+ node = olpc_dt_finddevice(/);
+ if (!node)
+ return 0;
+
+ r = olpc_dt_getproperty(node, board-revision-int,
+ (char *) rev, sizeof(rev));
+ if (r 0)
+ return 0;
+
+ return be32_to_cpu(rev);
+}
+
+void __init olpc_dt_fixup(void)
+{
+ int r;
+ char buf[64];
+ phandle node;
+ u32 board_rev;
+
+ node = olpc_dt_finddevice(/battery@0);
+ if (!node)
+ return;
+
+ /*
+* If the battery node has a compatible property, we are running a new
+* enough firmware and don't have fixups to make.
+*/
+ r = olpc_dt_getproperty(node, compatible, buf, sizeof(buf));
+ if (r 0)
+ return;
+
+ pr_info(PROM DT: Old firmware detected, applying fixes\n);
+
+ /* Add olpc,xo1-battery compatible marker to battery node */
+ olpc_dt_interpret(\ /battery@0\ find-device
+\ olpc,xo1-battery\ +compatible
+device-end);
+
+ board_rev = olpc_dt_get_board_revision();
+ if (!board_rev)
+ return;
+
+ if (board_rev = olpc_board_pre(0xd0)) {
+ /* XO-1.5: add dcon device */
+ olpc_dt_interpret(\ /pci/display@1\ find-device
+new-device
+\ dcon\ device-name \ olpc,xo1-dcon\ +compatible
+finish-device device-end);
+ } else {
+ /* XO-1: add dcon device, mark RTC as olpc,xo1-rtc */
+ olpc_dt_interpret(\ /pci/display@1,1\ find-device
+new-device
+\ dcon\ device-name \ olpc,xo1-dcon\ +compatible
+finish-device device-end
+\ /rtc\ find-device
+\ olpc,xo1-rtc\ +compatible
+device-end);
+ }
+}
+
void __init olpc_dt_build_devicetree(void)
{
phandle root;
@@ -172,6 +273,8 @@ void __init olpc_dt_build_devicetree(void)
if (!olpc_ofw_is_installed())
return;
+ olpc_dt_fixup();
+
root = olpc_dt_getsibling(0);
if (!root) {
pr_err(PROM: unable to get root node from OFW!\n);
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 10/11] x86, olpc: Add XO-1 RTC driver
Add a driver to configure the XO-1 RTC via CS5536 MSRs, to be used as a
system wakeup source via olpc-xo1-pm.
Device detection is based on finding the relevant device tree node.
Signed-off-by: Daniel Drake d...@laptop.org
Acked-by: Andres Salomon dilin...@queued.net
Acked-by: Grant Likely grant.lik...@secretlab.ca
Reviewed-by: Sebastian Andrzej Siewior bige...@linutronix.de
Cc: devicetree-discuss@lists.ozlabs.org
---
.../devicetree/bindings/rtc/olpc-xo1-rtc.txt |5 +
arch/x86/Kconfig |7 ++
arch/x86/platform/olpc/Makefile|1 +
arch/x86/platform/olpc/olpc-xo1-rtc.c | 82
include/linux/cs5535.h |5 +
5 files changed, 100 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt
create mode 100644 arch/x86/platform/olpc/olpc-xo1-rtc.c
diff --git a/Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt
b/Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt
new file mode 100644
index 000..a2891ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt
@@ -0,0 +1,5 @@
+OLPC XO-1 RTC
+~
+
+Required properties:
+ - compatible : olpc,xo1-rtc
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 38af371..de81496 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2082,6 +2082,13 @@ config OLPC_XO1_PM
---help---
Add support for poweroff and suspend of the OLPC XO-1 laptop.
+config OLPC_XO1_RTC
+ bool OLPC XO-1 Real Time Clock
+ depends on OLPC_XO1_PM RTC_DRV_CMOS
+ ---help---
+ Add support for the XO-1 real time clock, which can be used as a
+ programmable wakeup source.
+
config OLPC_XO1_SCI
bool OLPC XO-1 SCI extras
depends on OLPC OLPC_XO1_PM POWER_SUPPLY
diff --git a/arch/x86/platform/olpc/Makefile b/arch/x86/platform/olpc/Makefile
index 1ec5ade..8922b9b 100644
--- a/arch/x86/platform/olpc/Makefile
+++ b/arch/x86/platform/olpc/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_OLPC) += olpc.o olpc_ofw.o olpc_dt.o
obj-$(CONFIG_OLPC_XO1_PM) += olpc-xo1-pm.o xo1-wakeup.o
+obj-$(CONFIG_OLPC_XO1_RTC) += olpc-xo1-rtc.o
obj-$(CONFIG_OLPC_XO1_SCI) += olpc-xo1-sci.o
diff --git a/arch/x86/platform/olpc/olpc-xo1-rtc.c
b/arch/x86/platform/olpc/olpc-xo1-rtc.c
new file mode 100644
index 000..476cc98
--- /dev/null
+++ b/arch/x86/platform/olpc/olpc-xo1-rtc.c
@@ -0,0 +1,82 @@
+/*
+ * Support for OLPC XO-1 Real Time Clock (RTC)
+ *
+ * Copyright (C) 2011 One Laptop per Child
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/mc146818rtc.h
+#include linux/platform_device.h
+#include linux/rtc.h
+#include linux/of.h
+
+#include asm/msr.h
+#include asm/olpc.h
+
+static void rtc_wake_on(struct device *dev)
+{
+ olpc_xo1_pm_wakeup_set(CS5536_PM_RTC);
+}
+
+static void rtc_wake_off(struct device *dev)
+{
+ olpc_xo1_pm_wakeup_clear(CS5536_PM_RTC);
+}
+
+static struct resource rtc_platform_resource[] = {
+ [0] = {
+ .start = RTC_PORT(0),
+ .end= RTC_PORT(1),
+ .flags = IORESOURCE_IO,
+ },
+ [1] = {
+ .start = RTC_IRQ,
+ .end= RTC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct cmos_rtc_board_info rtc_info = {
+ .rtc_day_alarm = 0,
+ .rtc_mon_alarm = 0,
+ .rtc_century = 0,
+ .wake_on = rtc_wake_on,
+ .wake_off = rtc_wake_off,
+};
+
+static struct platform_device xo1_rtc_device = {
+ .name = rtc_cmos,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(rtc_platform_resource),
+ .dev.platform_data = rtc_info,
+ .resource = rtc_platform_resource,
+};
+
+static int __init xo1_rtc_init(void)
+{
+ int r;
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, olpc,xo1-rtc);
+ if (!node)
+ return 0;
+ of_node_put(node);
+
+ pr_info(olpc-xo1-rtc: Initializing OLPC XO-1 RTC\n);
+ rdmsrl(MSR_RTC_DOMA_OFFSET, rtc_info.rtc_day_alarm);
+ rdmsrl(MSR_RTC_MONA_OFFSET, rtc_info.rtc_mon_alarm);
+ rdmsrl(MSR_RTC_CEN_OFFSET, rtc_info.rtc_century);
+
+ r = platform_device_register(xo1_rtc_device);
+ if (r)
+ return r;
+
+ device_init_wakeup(xo1_rtc_device.dev, 1);
+ return 0;
+}
+arch_initcall(xo1_rtc_init);
+
diff --git a/include/linux/cs5535.h b/include/linux/cs5535.h
index 72954c6..c077aec 100644
--- a/include/linux/cs5535.h
+++ b/include/linux/cs5535.h
@@ -40,6 +40,10 @@
#define MSR_MFGPT_NR 0x51400029
#define MSR_MFGPT_SETUP0x5140002B
+#define
[PATCH v2 01/11] x86, olpc: add missing elements to device tree
In response to new device tree code in the kernel, OLPC will start
using it for probing of certain devices. However, some firmware fixes
are needed to put the devicetree into a usable state.
Retain compatibility with old firmware by fixing up the device tree
at boot-time if it does not contain the new nodes/properties that
we need for probing. This is the same approach taken on PPC platforms.
Signed-off-by: Daniel Drake d...@laptop.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Andres Salomon dilin...@queued.net
Cc: devicetree-discuss@lists.ozlabs.org
---
arch/x86/platform/olpc/olpc_dt.c | 103 ++
1 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index d39f63d..d6ee929 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -165,6 +165,107 @@ static struct of_pdt_ops prom_olpc_ops __initdata = {
.pkg2path = olpc_dt_pkg2path,
};
+static phandle __init olpc_dt_finddevice(const char *path)
+{
+ phandle node;
+ const void *args[] = { path };
+ void *res[] = { node };
+
+ if (olpc_ofw(finddevice, args, res)) {
+ pr_err(olpc_dt: finddevice failed!\n);
+ return 0;
+ }
+
+ if ((s32) node == -1)
+ return 0;
+
+ return node;
+}
+
+static int __init olpc_dt_interpret(const char *words)
+{
+ int result;
+ const void *args[] = { words };
+ void *res[] = { result };
+
+ if (olpc_ofw(interpret, args, res)) {
+ pr_err(olpc_dt: interpret failed!\n);
+ return -1;
+ }
+
+ return result;
+}
+
+/*
+ * Extract board revision directly from OFW device tree.
+ * We can't use olpc_platform_info because that hasn't been set up yet.
+ */
+static u32 __init olpc_dt_get_board_revision(void)
+{
+ phandle node;
+ __be32 rev;
+ int r;
+
+ node = olpc_dt_finddevice(/);
+ if (!node)
+ return 0;
+
+ r = olpc_dt_getproperty(node, board-revision-int,
+ (char *) rev, sizeof(rev));
+ if (r 0)
+ return 0;
+
+ return be32_to_cpu(rev);
+}
+
+void __init olpc_dt_fixup(void)
+{
+ int r;
+ char buf[64];
+ phandle node;
+ u32 board_rev;
+
+ node = olpc_dt_finddevice(/battery@0);
+ if (!node)
+ return;
+
+ /*
+* If the battery node has a compatible property, we are running a new
+* enough firmware and don't have fixups to make.
+*/
+ r = olpc_dt_getproperty(node, compatible, buf, sizeof(buf));
+ if (r 0)
+ return;
+
+ pr_info(PROM DT: Old firmware detected, applying fixes\n);
+
+ /* Add olpc,xo1-battery compatible marker to battery node */
+ olpc_dt_interpret(\ /battery@0\ find-device
+\ olpc,xo1-battery\ +compatible
+device-end);
+
+ board_rev = olpc_dt_get_board_revision();
+ if (!board_rev)
+ return;
+
+ if (board_rev = olpc_board_pre(0xd0)) {
+ /* XO-1.5: add dcon device */
+ olpc_dt_interpret(\ /pci/display@1\ find-device
+new-device
+\ dcon\ device-name \ olpc,xo1-dcon\ +compatible
+finish-device device-end);
+ } else {
+ /* XO-1: add dcon device, mark RTC as olpc,xo1-rtc */
+ olpc_dt_interpret(\ /pci/display@1,1\ find-device
+new-device
+\ dcon\ device-name \ olpc,xo1-dcon\ +compatible
+finish-device device-end
+\ /rtc\ find-device
+\ olpc,xo1-rtc\ +compatible
+device-end);
+ }
+}
+
void __init olpc_dt_build_devicetree(void)
{
phandle root;
@@ -172,6 +273,8 @@ void __init olpc_dt_build_devicetree(void)
if (!olpc_ofw_is_installed())
return;
+ olpc_dt_fixup();
+
root = olpc_dt_getsibling(0);
if (!root) {
pr_err(PROM: unable to get root node from OFW!\n);
--
1.7.5.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 10/11] x86, olpc: Add XO-1 RTC driver
Add a driver to configure the XO-1 RTC via CS5536 MSRs, to be used as a
system wakeup source via olpc-xo1-pm.
Device detection is based on finding the relevant device tree node.
Signed-off-by: Daniel Drake d...@laptop.org
Acked-by: Andres Salomon dilin...@queued.net
Acked-by: Grant Likely grant.lik...@secretlab.ca
Reviewed-by: Sebastian Andrzej Siewior bige...@linutronix.de
Cc: devicetree-discuss@lists.ozlabs.org
---
.../devicetree/bindings/rtc/olpc-xo1-rtc.txt |5 +
arch/x86/Kconfig |7 ++
arch/x86/platform/olpc/Makefile|1 +
arch/x86/platform/olpc/olpc-xo1-rtc.c | 82
include/linux/cs5535.h |5 +
5 files changed, 100 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt
create mode 100644 arch/x86/platform/olpc/olpc-xo1-rtc.c
diff --git a/Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt
b/Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt
new file mode 100644
index 000..a2891ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt
@@ -0,0 +1,5 @@
+OLPC XO-1 RTC
+~
+
+Required properties:
+ - compatible : olpc,xo1-rtc
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 267a887..d8a6952 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2079,6 +2079,13 @@ config OLPC_XO1_PM
---help---
Add support for poweroff and suspend of the OLPC XO-1 laptop.
+config OLPC_XO1_RTC
+ bool OLPC XO-1 Real Time Clock
+ depends on OLPC_XO1_PM RTC_DRV_CMOS
+ ---help---
+ Add support for the XO-1 real time clock, which can be used as a
+ programmable wakeup source.
+
config OLPC_XO1_SCI
bool OLPC XO-1 SCI extras
depends on OLPC OLPC_XO1_PM POWER_SUPPLY
diff --git a/arch/x86/platform/olpc/Makefile b/arch/x86/platform/olpc/Makefile
index 1ec5ade..8922b9b 100644
--- a/arch/x86/platform/olpc/Makefile
+++ b/arch/x86/platform/olpc/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_OLPC) += olpc.o olpc_ofw.o olpc_dt.o
obj-$(CONFIG_OLPC_XO1_PM) += olpc-xo1-pm.o xo1-wakeup.o
+obj-$(CONFIG_OLPC_XO1_RTC) += olpc-xo1-rtc.o
obj-$(CONFIG_OLPC_XO1_SCI) += olpc-xo1-sci.o
diff --git a/arch/x86/platform/olpc/olpc-xo1-rtc.c
b/arch/x86/platform/olpc/olpc-xo1-rtc.c
new file mode 100644
index 000..476cc98
--- /dev/null
+++ b/arch/x86/platform/olpc/olpc-xo1-rtc.c
@@ -0,0 +1,82 @@
+/*
+ * Support for OLPC XO-1 Real Time Clock (RTC)
+ *
+ * Copyright (C) 2011 One Laptop per Child
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/mc146818rtc.h
+#include linux/platform_device.h
+#include linux/rtc.h
+#include linux/of.h
+
+#include asm/msr.h
+#include asm/olpc.h
+
+static void rtc_wake_on(struct device *dev)
+{
+ olpc_xo1_pm_wakeup_set(CS5536_PM_RTC);
+}
+
+static void rtc_wake_off(struct device *dev)
+{
+ olpc_xo1_pm_wakeup_clear(CS5536_PM_RTC);
+}
+
+static struct resource rtc_platform_resource[] = {
+ [0] = {
+ .start = RTC_PORT(0),
+ .end= RTC_PORT(1),
+ .flags = IORESOURCE_IO,
+ },
+ [1] = {
+ .start = RTC_IRQ,
+ .end= RTC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct cmos_rtc_board_info rtc_info = {
+ .rtc_day_alarm = 0,
+ .rtc_mon_alarm = 0,
+ .rtc_century = 0,
+ .wake_on = rtc_wake_on,
+ .wake_off = rtc_wake_off,
+};
+
+static struct platform_device xo1_rtc_device = {
+ .name = rtc_cmos,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(rtc_platform_resource),
+ .dev.platform_data = rtc_info,
+ .resource = rtc_platform_resource,
+};
+
+static int __init xo1_rtc_init(void)
+{
+ int r;
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, olpc,xo1-rtc);
+ if (!node)
+ return 0;
+ of_node_put(node);
+
+ pr_info(olpc-xo1-rtc: Initializing OLPC XO-1 RTC\n);
+ rdmsrl(MSR_RTC_DOMA_OFFSET, rtc_info.rtc_day_alarm);
+ rdmsrl(MSR_RTC_MONA_OFFSET, rtc_info.rtc_mon_alarm);
+ rdmsrl(MSR_RTC_CEN_OFFSET, rtc_info.rtc_century);
+
+ r = platform_device_register(xo1_rtc_device);
+ if (r)
+ return r;
+
+ device_init_wakeup(xo1_rtc_device.dev, 1);
+ return 0;
+}
+arch_initcall(xo1_rtc_init);
+
diff --git a/include/linux/cs5535.h b/include/linux/cs5535.h
index 72954c6..c077aec 100644
--- a/include/linux/cs5535.h
+++ b/include/linux/cs5535.h
@@ -40,6 +40,10 @@
#define MSR_MFGPT_NR 0x51400029
#define MSR_MFGPT_SETUP0x5140002B
+#define
Re: [PATCH] olpc_battery: bind to device tree
On 20 May 2011 16:21, Anton Vorontsov cbouatmai...@gmail.com wrote: I just wondering what happened with this patch?.. I sneakily posted it for review prematurely :) I have a corrected version based upon all received feedback, but this patch actually depends on another patch (for x86 tree) which has been submitted and resubmitted and is still awaiting review: http://marc.info/?l=linux-kernelm=130416849500918w=2 Haven't forgotten, but thanks for the reminder :) Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] OLPC: add missing elements to device tree
In response to new device tree code in the kernel, OLPC will start
using it for probing of certain devices. However, some firmware fixes
are needed to put the devicetree into a usable state.
Retain compatibility with old firmware by fixing up the device tree
at boot-time if it does not contain the new nodes/properties that
we need for probing. This is the same approach taken on PPC platforms.
Signed-off-by: Daniel Drake d...@laptop.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Andres Salomon dilin...@queued.net
---
arch/x86/platform/olpc/olpc_dt.c | 103 ++
1 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index d39f63d..d6ee929 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -165,6 +165,107 @@ static struct of_pdt_ops prom_olpc_ops __initdata = {
.pkg2path = olpc_dt_pkg2path,
};
+static phandle __init olpc_dt_finddevice(const char *path)
+{
+ phandle node;
+ const void *args[] = { path };
+ void *res[] = { node };
+
+ if (olpc_ofw(finddevice, args, res)) {
+ pr_err(olpc_dt: finddevice failed!\n);
+ return 0;
+ }
+
+ if ((s32) node == -1)
+ return 0;
+
+ return node;
+}
+
+static int __init olpc_dt_interpret(const char *words)
+{
+ int result;
+ const void *args[] = { words };
+ void *res[] = { result };
+
+ if (olpc_ofw(interpret, args, res)) {
+ pr_err(olpc_dt: interpret failed!\n);
+ return -1;
+ }
+
+ return result;
+}
+
+/*
+ * Extract board revision directly from OFW device tree.
+ * We can't use olpc_platform_info because that hasn't been set up yet.
+ */
+static u32 __init olpc_dt_get_board_revision(void)
+{
+ phandle node;
+ __be32 rev;
+ int r;
+
+ node = olpc_dt_finddevice(/);
+ if (!node)
+ return 0;
+
+ r = olpc_dt_getproperty(node, board-revision-int,
+ (char *) rev, sizeof(rev));
+ if (r 0)
+ return 0;
+
+ return be32_to_cpu(rev);
+}
+
+void __init olpc_dt_fixup(void)
+{
+ int r;
+ char buf[64];
+ phandle node;
+ u32 board_rev;
+
+ node = olpc_dt_finddevice(/battery@0);
+ if (!node)
+ return;
+
+ /*
+* If the battery node has a compatible property, we are running a new
+* enough firmware and don't have fixups to make.
+*/
+ r = olpc_dt_getproperty(node, compatible, buf, sizeof(buf));
+ if (r 0)
+ return;
+
+ pr_info(PROM DT: Old firmware detected, applying fixes\n);
+
+ /* Add olpc,xo1-battery compatible marker to battery node */
+ olpc_dt_interpret(\ /battery@0\ find-device
+\ olpc,xo1-battery\ +compatible
+device-end);
+
+ board_rev = olpc_dt_get_board_revision();
+ if (!board_rev)
+ return;
+
+ if (board_rev = olpc_board_pre(0xd0)) {
+ /* XO-1.5: add dcon device */
+ olpc_dt_interpret(\ /pci/display@1\ find-device
+new-device
+\ dcon\ device-name \ olpc,xo1-dcon\ +compatible
+finish-device device-end);
+ } else {
+ /* XO-1: add dcon device, mark RTC as olpc,xo1-rtc */
+ olpc_dt_interpret(\ /pci/display@1,1\ find-device
+new-device
+\ dcon\ device-name \ olpc,xo1-dcon\ +compatible
+finish-device device-end
+\ /rtc\ find-device
+\ olpc,xo1-rtc\ +compatible
+device-end);
+ }
+}
+
void __init olpc_dt_build_devicetree(void)
{
phandle root;
@@ -172,6 +273,8 @@ void __init olpc_dt_build_devicetree(void)
if (!olpc_ofw_is_installed())
return;
+ olpc_dt_fixup();
+
root = olpc_dt_getsibling(0);
if (!root) {
pr_err(PROM: unable to get root node from OFW!\n);
--
1.7.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 3/3] olpc-battery: bind to device tree
On 5 March 2011 04:54, Grant Likely grant.lik...@secretlab.ca wrote: I want to see all new compatible properties documented in Documentation/devicetree/bindings. It may not be the best place for binding documentation since it is currently tied to Linux, but it is better than anything else we currently have. Ok, how do you think it should look? Something simple like this? new file at bindings/power_supply/olpc_battery.txt : OLPC battery Required properties: - compatible : olpc,xo1-battery Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC v2] OLPC: add missing elements to device tree
In response to new device tree code in the kernel, OLPC will start
using it for probing of certain devices. However, some firmware fixes
are needed to put the devicetree into a usable state.
Retain compatibility with old firmware by fixing up the device tree
at boot-time if it does not contain the new nodes/properties that
we need for probing.
Signed-off-by: Daniel Drake d...@laptop.org
---
arch/x86/platform/olpc/olpc_dt.c | 104 ++
1 files changed, 104 insertions(+), 0 deletions(-)
v2: ask OpenFirmware to adjust the tree instead of manipulating the tree
on the linux level.
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 24f2598..d6ee929 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -21,6 +21,7 @@
#include linux/of.h
#include linux/of_platform.h
#include linux/of_pdt.h
+#include asm/olpc.h
#include asm/olpc_ofw.h
static phandle __init olpc_dt_getsibling(phandle node)
@@ -164,6 +165,107 @@ static struct of_pdt_ops prom_olpc_ops __initdata = {
.pkg2path = olpc_dt_pkg2path,
};
+static phandle __init olpc_dt_finddevice(const char *path)
+{
+ phandle node;
+ const void *args[] = { path };
+ void *res[] = { node };
+
+ if (olpc_ofw(finddevice, args, res)) {
+ pr_err(olpc_dt: finddevice failed!\n);
+ return 0;
+ }
+
+ if ((s32) node == -1)
+ return 0;
+
+ return node;
+}
+
+static int __init olpc_dt_interpret(const char *words)
+{
+ int result;
+ const void *args[] = { words };
+ void *res[] = { result };
+
+ if (olpc_ofw(interpret, args, res)) {
+ pr_err(olpc_dt: interpret failed!\n);
+ return -1;
+ }
+
+ return result;
+}
+
+/*
+ * Extract board revision directly from OFW device tree.
+ * We can't use olpc_platform_info because that hasn't been set up yet.
+ */
+static u32 __init olpc_dt_get_board_revision(void)
+{
+ phandle node;
+ __be32 rev;
+ int r;
+
+ node = olpc_dt_finddevice(/);
+ if (!node)
+ return 0;
+
+ r = olpc_dt_getproperty(node, board-revision-int,
+ (char *) rev, sizeof(rev));
+ if (r 0)
+ return 0;
+
+ return be32_to_cpu(rev);
+}
+
+void __init olpc_dt_fixup(void)
+{
+ int r;
+ char buf[64];
+ phandle node;
+ u32 board_rev;
+
+ node = olpc_dt_finddevice(/battery@0);
+ if (!node)
+ return;
+
+ /*
+* If the battery node has a compatible property, we are running a new
+* enough firmware and don't have fixups to make.
+*/
+ r = olpc_dt_getproperty(node, compatible, buf, sizeof(buf));
+ if (r 0)
+ return;
+
+ pr_info(PROM DT: Old firmware detected, applying fixes\n);
+
+ /* Add olpc,xo1-battery compatible marker to battery node */
+ olpc_dt_interpret(\ /battery@0\ find-device
+\ olpc,xo1-battery\ +compatible
+device-end);
+
+ board_rev = olpc_dt_get_board_revision();
+ if (!board_rev)
+ return;
+
+ if (board_rev = olpc_board_pre(0xd0)) {
+ /* XO-1.5: add dcon device */
+ olpc_dt_interpret(\ /pci/display@1\ find-device
+new-device
+\ dcon\ device-name \ olpc,xo1-dcon\ +compatible
+finish-device device-end);
+ } else {
+ /* XO-1: add dcon device, mark RTC as olpc,xo1-rtc */
+ olpc_dt_interpret(\ /pci/display@1,1\ find-device
+new-device
+\ dcon\ device-name \ olpc,xo1-dcon\ +compatible
+finish-device device-end
+\ /rtc\ find-device
+\ olpc,xo1-rtc\ +compatible
+device-end);
+ }
+}
+
void __init olpc_dt_build_devicetree(void)
{
phandle root;
@@ -171,6 +273,8 @@ void __init olpc_dt_build_devicetree(void)
if (!olpc_ofw_is_installed())
return;
+ olpc_dt_fixup();
+
root = olpc_dt_getsibling(0);
if (!root) {
pr_err(PROM: unable to get root node from OFW!\n);
--
1.7.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 2/3] OLPC: add missing elements to device tree
In response to new device tree code in the kernel, OLPC will start
using it for probing of certain devices. However, some firmware fixes
are needed to put the devicetree into a usable state.
Retain compatibility with old firmware by fixing up the device tree
at boot-time if it does not contain the new nodes/properties that
we need for probing.
Signed-off-by: Daniel Drake d...@laptop.org
---
arch/x86/platform/olpc/olpc_dt.c | 87 ++
1 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 09cbede..58bba78 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -22,6 +22,7 @@
#include linux/of_platform.h
#include linux/of_pdt.h
#include asm/olpc_ofw.h
+#include asm/olpc.h
static phandle __init olpc_dt_getsibling(phandle node)
{
@@ -164,6 +165,91 @@ static struct of_pdt_ops prom_olpc_ops __initdata = {
.pkg2path = olpc_dt_pkg2path,
};
+static char __init *prom_alloc_string(const char *str, int *len)
+{
+ int _len = strlen(str);
+ char *output = prom_early_alloc(_len + 1);
+
+ strcpy(output, str);
+ if (len)
+ *len = _len;
+ return output;
+}
+
+static void __init prom_alloc_property(struct device_node *node,
+ const char *name, const char *value)
+{
+ struct property *p = prom_early_alloc(sizeof(struct property));
+
+ p-name = prom_alloc_string(name, NULL);
+ p-value = prom_alloc_string(value, p-length);
+ prom_add_property(node, p);
+}
+
+/* Add dcon device as child of display */
+static void __init add_dcon_node(struct device_node *display)
+{
+ struct device_node *node = prom_early_alloc(sizeof(struct device_node));
+ unsigned long flags;
+
+ kref_init(node-kref);
+ node-name = prom_alloc_string(dcon, NULL);
+ node-full_name = (char *) node-name;
+ node-parent = display;
+
+ write_lock_irqsave(devtree_lock, flags);
+ node-sibling = node-parent-child;
+ node-allnext = allnodes;
+ node-parent-child = node;
+ allnodes = node;
+ write_unlock_irqrestore(devtree_lock, flags);
+
+ prom_alloc_property(node, compatible, olpc,xo1-dcon);
+}
+
+static void __init olpc_dt_fixup(void)
+{
+ struct device_node *node;
+
+ /*
+* Use battery's compatible property to determine if we're running a
+* new-enough firmware. If we have this property, no fixups are needed.
+*/
+ node = of_find_node_by_name(NULL, battery);
+ if (node of_get_property(node, compatible, NULL)) {
+ of_node_put(node);
+ return;
+ }
+
+ /*
+* Add compatible property to battery, it was missing from earlier
+* firmware releases.
+*/
+ prom_alloc_property(node, compatible, olpc,xo1-battery);
+ of_node_put(node);
+
+ /*
+* Mark XO-1 RTC as compatible with olpc,xo1-rtc - this was not done in
+* earlier firmware releases.
+*/
+ node = of_find_node_by_name(NULL, rtc);
+ if (olpc_platform_info.boardrev olpc_board_pre(0xd0) node) {
+ struct property *p = of_get_property(node, compatible, NULL);
+ prom_remove_property(node, p);
+ prom_alloc_property(node, compatible, olpc,xo1-rtc);
+ }
+ of_node_put(node);
+
+ /*
+* Add dcon device node, it was missing from earlier firmware
+* releases.
+*/
+ node = of_find_node_by_name(NULL, display);
+ if (node)
+ add_dcon_node(node);
+ of_node_put(node);
+}
+
void __init olpc_dt_build_devicetree(void)
{
phandle root;
@@ -177,6 +263,7 @@ void __init olpc_dt_build_devicetree(void)
return;
}
of_pdt_build_devicetree(root, prom_olpc_ops);
+ olpc_dt_fixup();
pr_info(PROM DT: Built device tree with %u bytes of memory.\n,
prom_early_allocated);
--
1.7.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 1/3] OLPC: Use device tree for platform identification
Make OLPC fully depend on device tree, and use it to identify the OLPC
platform details. Some nodes are exposed as platform devices where we
plan to use device tree for device probing.
Signed-off-by: Daniel Drake d...@laptop.org
---
arch/x86/Kconfig |2 +-
arch/x86/include/asm/olpc_ofw.h |8 +
arch/x86/platform/olpc/Makefile |4 +--
arch/x86/platform/olpc/olpc.c| 51 -
arch/x86/platform/olpc/olpc_dt.c | 15 +++
5 files changed, 47 insertions(+), 33 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b4c2e9c..471221b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2071,7 +2071,7 @@ config OLPC
depends on !X86_PAE
select GPIOLIB
select OF
- select OF_PROMTREE if PROC_DEVICETREE
+ select OF_PROMTREE
---help---
Add support for detecting the unique features of the OLPC
XO hardware.
diff --git a/arch/x86/include/asm/olpc_ofw.h b/arch/x86/include/asm/olpc_ofw.h
index c5d3a5a..a0e24e7 100644
--- a/arch/x86/include/asm/olpc_ofw.h
+++ b/arch/x86/include/asm/olpc_ofw.h
@@ -26,15 +26,11 @@ extern void setup_olpc_ofw_pgd(void);
/* check if OFW was detected during boot */
extern bool olpc_ofw_present(void);
+extern void olpc_dt_build_devicetree(void);
+
#else /* !CONFIG_OLPC */
static inline void olpc_ofw_detect(void) { }
static inline void setup_olpc_ofw_pgd(void) { }
#endif /* !CONFIG_OLPC */
-#ifdef CONFIG_OF_PROMTREE
-extern void olpc_dt_build_devicetree(void);
-#else
-static inline void olpc_dt_build_devicetree(void) { }
-#endif
-
#endif /* _ASM_X86_OLPC_OFW_H */
diff --git a/arch/x86/platform/olpc/Makefile b/arch/x86/platform/olpc/Makefile
index c2a8cab..81c5e21 100644
--- a/arch/x86/platform/olpc/Makefile
+++ b/arch/x86/platform/olpc/Makefile
@@ -1,4 +1,2 @@
-obj-$(CONFIG_OLPC) += olpc.o
+obj-$(CONFIG_OLPC) += olpc.o olpc_ofw.o olpc_dt.o
obj-$(CONFIG_OLPC_XO1) += olpc-xo1.o
-obj-$(CONFIG_OLPC) += olpc_ofw.o
-obj-$(CONFIG_OF_PROMTREE) += olpc_dt.o
diff --git a/arch/x86/platform/olpc/olpc.c b/arch/x86/platform/olpc/olpc.c
index edaf3fe..2ecc98d 100644
--- a/arch/x86/platform/olpc/olpc.c
+++ b/arch/x86/platform/olpc/olpc.c
@@ -18,6 +18,7 @@
#include linux/io.h
#include linux/string.h
#include linux/platform_device.h
+#include linux/of.h
#include asm/geode.h
#include asm/setup.h
@@ -187,41 +188,45 @@ err:
}
EXPORT_SYMBOL_GPL(olpc_ec_cmd);
-static bool __init check_ofw_architecture(void)
+static bool __init check_ofw_architecture(struct device_node *root)
{
- size_t propsize;
- char olpc_arch[5];
- const void *args[] = { NULL, architecture, olpc_arch, (void *)5 };
- void *res[] = { propsize };
+ const char *olpc_arch;
+ int propsize;
- if (olpc_ofw(getprop, args, res)) {
- printk(KERN_ERR ofw: getprop call failed!\n);
- return false;
- }
+ olpc_arch = of_get_property(root, architecture, propsize);
return propsize == 5 strncmp(OLPC, olpc_arch, 5) == 0;
}
-static u32 __init get_board_revision(void)
+static u32 __init get_board_revision(struct device_node *root)
{
- size_t propsize;
- __be32 rev;
- const void *args[] = { NULL, board-revision-int, rev, (void *)4 };
- void *res[] = { propsize };
-
- if (olpc_ofw(getprop, args, res) || propsize != 4) {
- printk(KERN_ERR ofw: getprop call failed!\n);
- return cpu_to_be32(0);
- }
- return be32_to_cpu(rev);
+ int propsize;
+ const __be32 *rev;
+
+ rev = of_get_property(root, board-revision-int, propsize);
+ if (propsize != 4)
+ return 0;
+
+ return be32_to_cpu(*rev);
}
static bool __init platform_detect(void)
{
- if (!check_ofw_architecture())
+ struct device_node *root = of_find_node_by_path(/);
+ bool success;
+
+ if (!root)
return false;
+
+ success = check_ofw_architecture(root);
+ if (!success)
+ goto out;
+
olpc_platform_info.flags |= OLPC_F_PRESENT;
- olpc_platform_info.boardrev = get_board_revision();
- return true;
+ olpc_platform_info.boardrev = get_board_revision(root);
+
+out:
+ of_node_put(root);
+ return success;
}
static int __init add_xo1_platform_devices(void)
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 044bda5..09cbede 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -19,6 +19,7 @@
#include linux/kernel.h
#include linux/bootmem.h
#include linux/of.h
+#include linux/of_platform.h
#include linux/of_pdt.h
#include asm/olpc_ofw.h
@@ -180,3 +181,17 @@ void __init olpc_dt_build_devicetree(void)
pr_info(PROM DT: Built device tree with %u bytes of memory.\n,
prom_early_allocated
Re: [PATCH] of/pdt: allow DT device matching by fixing 'name' brokenness
On 23 February 2011 19:54, Andres Salomon dilin...@queued.net wrote: Wait; why are you binding to a device based on name? Binding by name and/or device_type is strongly discouraged for new code. Use compatible instead. Daniel posted a separate patch showing his code, would you mind commenting on that? I noticed he didn't cc you though, here's the patch: https://patchwork.kernel.org/patch/574901/ It does bind to the name. We don't currently have a compatible property for the battery device. We could fix that with a firmware upgrade, but it would break compatibility with all existing installs. I guess this is still the recommended approach... Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] olpc_battery: bind to device tree
On 25 February 2011 14:19, Daniel Drake d...@laptop.org wrote: /battery@0/compatible property added with value olpc-battery (XO-1 and XO-1.5) /pci/isa@f/rtc@i70/compatible property prepended with olpc-xo1-rtc, That comma at the end should be dropped. I just realised that the separator between different elements in the compatible list is a NULL character. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
