[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201207031401.36262.arnd@arndb.de>
Date: Tue, 3 Jul 2012 14:01:35 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc: Lee Jones <lee.jones@...aro.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linus.walleij@...ricsson.com, sameo@...ux.intel.com
Subject: Re: [PATCH 1/1] mfd: Fix runtime warning caused by duplicate device registration
On Tuesday 03 July 2012, Mark Brown wrote:
> > Before, when we probed each device from Device Tree we came up
> > against some fairly major limitations of the Device Tree. As a
> > result, Arnd and I agreed that this was the way to go.
>
> I'm really unconvinced that instnatiating the MFD cells from device tree
> is in general a good idea.
In general it's not, e.g. it makes no sense when the MFD is just
a bunch of registers that are mapped to various distinct Linux
devices. The two mfd devices on ux500 (prcmu and ab8500) are really
buses by themselves that happen to be implemented using the MFD
framework on Linux.
I don't see how we would get around representing the buses in
the device tree because we have to refer to nodes under them
from off-chip devices. Simplified we have something like
db9500 {
prcmu {
opp@1 {
};
regulator@2 {
};
watchdog@4 {
};
ab8500@5 {
regulator@3 {
};
regulator@4 {
};
adc@a {
};
rtc@f {
};
irq@e {
};
gpio@10 {
};
};
};
};
Most of the stuff on the board is connected to the ab8500 regulators and
gpio pins, which are also used as interrupts. In order to hook up
the external devices in the device tree, we need to have something that
we can point to as their interrupt-parent or the phandle in the gpio
description.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists