On Fri, 20 Mar 2015 10:34:18 +0100 "Dr. H. Nikolaus Schaller"
<hns@xxxxxxxxxxxxx> wrote:
>
> Am 20.03.2015 um 09:54 schrieb NeilBrown <neilb@xxxxxxx>:
> > There needs to be one device-node for each device, and that device-node needs
> > to be a child of the device-node for the device which is the primary
> > connection to the child device.
>
> Then please explain to me nodes like
>
> / {
> compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
>
> cpus {
> cpu@0 {
> cpu0-supply = <&vcc>;
> };
> };
>
> According to the rule you apply here it should be something like
>
> cpu@0 {
> regulator {
> …
> }
>
>
This exactly highlight one of the big problems with device tree as I see it.
Each device can potentially have relationships with a number of other
devices, for the supply of power, reset signalling, interrupt handled, data
transfer, command transfer etc etc etc.
devicetree provides two ways to indicated a relationship between devices.
One way is a parent/child arrangement. The other way is ad-hoc
attribute = <&devicename>
assignments.
Each device can only have one parent, but can have multiple arbitrary
assignments.
I would much rather that the parent/child relationship didn't exist at all.
Each device should stand alone, and list all relationships explicitly. But
that is not the way devicetree works, and we need to live with that.
So we need a clear understanding of what the 'parent' of a given device
should be.
I don't know what the specifications say, if anything, but what I see is that
the parent is in practive a device which can 'address' the child. i.e.
control signalling is the key parent->child relationship.
This is consistent with the fact that many device nodes have a
reg=<xxx>
attribute which gives the address of the node as seen by it's parent.
Given that understanding, a regulator must be a child of the device which can
control it - which can turn it on or off. Not a child of the device which
receives power from it.
In the case of our GPS, it receives control over the serial connection from
the UART, also receives control via a GPIO to the on/off pin, and also needs
a regulator to power the antenna.
So should the parent be the uart, the on/off GPIO, or the regulator?
I would much rather there wasn't a parent, and that each of these were listed
as ad-hoc attribute assignments. But device-tree says there must be a parent
(where possible), and the parent is the thing that is "primarily" in control.
I think the GPS is "primarily" a uart-attached device.
So I propose a device-node which describes the GPS, which is a child of the
UART, and explicitly identifies the GPIO it uses to power on/off, the
regulator it uses to power the antenna, and how it receives "on or off"
status indications from the GPS.
It is arguable that the "antenna" should be treated as a separate device - a
child of the GPS - which controls the regulator and also provides a 'extcon'
which reports whether an external GPS antenna is attached, or whether the
internal on is in use. I haven't made the time to properly explore that
issue yet.
> >>
> >> All the following is very special logic for the w2sg0004 chip which should be
> >> divided out into a separate driver.
> >>
> >> Marek and me already had proposed such a chip specific driver (to be located
> >> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >> specific and present itself as a regulator (because that is its main purpose:
> >> control the LDO regulator inside the w2sg0004 chip).
> >
> > Presenting itself as a regulator would be wrong because it isn’t a regulator.
>
> It has a regulator that can be controlled by a gpio…
Does it? I guess may it does.
Maybe it also has an ARM core and some memory and assorted other bits and
pieces. But we don't really need to describe them to device tree.
The w2sg0004 is primarily a GPS device, so that needs to be stated in the
devices tree description. If there are subcomponents that can usefully be
described as well then there could be a place to describe those subcomponents.
I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
1V8 source based on its 3V3 input. If a board made use of that, it could be
useful to describe the regulator inside the GPS so it could be declare that
some other device which needed 1V8 made use of that regulator....
>
> Another example to think about: the twl4030 is also not a regulator.
> Nevertheless they present some regulator nodes.
The TWL4030 is a multifunction device which contains regulators and GPIOs and
audio codec and USB PHY etc etc etc.
So in device-tree there is a device-node for the TWL4030, and it has
child-nodes for each sub-device. They in turn can provide services to other
devices on the board.
These sub-devices are much more independent of the whole than the regulator
inside the w2sg0004 is.
>
> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
> but has an internal pbias_regulator that needs to be controlled.
I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
device which contains a CPU and multiple other controllers and communicators
and stuff. One of the components in the OMAP3 is this pbias_regulator, and
it has a device-node which is a child of the 'ocp' node - which is the main
interconnect in the OMAP3 I think.
So I'm not against describing the regulator in the w2sg0004, but for
consistency with everything else, it would need to be child-node of a
device-node which describes the w2sg0004 as a whole. I'm not sure that doing
that would gain anything.
Thanks,
NeilBrown
Attachment:
pgp00vjYawaSZ.pgp
Description: OpenPGP digital signature
