...@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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
(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
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
(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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
62 matches
Mail list logo
