How-to: Uniquely identify a DT node in the driver?

How-to: Uniquely identify a DT node in the driver?

[Lina Iyer]

Hello,

I am looking to find a way to uniquely identify a device in the driver.
Here is an example -

	big: power-controller@1 {
		compatible = "soc,foo";
		...
	};

	little: power-controller@2 {
		compatible = "soc,foo";
		...
	};


In the driver for the power-controller foo.c, would like to do -

	struct xyz {
		const char *name;
		...
	};

	static struct xyz a = {
		.name = "big"; // To be associated with big device
		...
	};

	static struct xyz b = {
		.name = "little"; // To be associated with little device
		...
	};

What would be the best way to associate the power-controller devices 'big'
and 'little' with 'a' and 'b' respectively? A string comparison would be
ideal but possibly can work with other ways.

I could think of adding compatibles to achieve this, but was hoping to
find something more elegant and appropriate. Or, is compatible the
recommended way to uniquely identify devices by the driver?

Thanks,
Lina
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How-to: Uniquely identify a DT node in the driver?

[Lina Iyer]

On Tue, Jul 28 2015 at 13:38 -0600, Lina Iyer wrote:
>Hello,
>
>I am looking to find a way to uniquely identify a device in the driver.
>Here is an example -
>
>	big: power-controller@1 {

@1 is probably not a good example here. @1 could as well be a SoC
specific phy address that the driver may not really care about.

>		compatible = "soc,foo";
>		...
>	};
>
>	little: power-controller@2 {
>		compatible = "soc,foo";
>		...
>	};
>
>
>In the driver for the power-controller foo.c, would like to do -
>
>	struct xyz {
>		const char *name;
>		...
>	};
>
>	static struct xyz a = {
>		.name = "big"; // To be associated with big device
>		...
>	};
>
>	static struct xyz b = {
>		.name = "little"; // To be associated with little device
>		...
>	};
>
>What would be the best way to associate the power-controller devices 'big'
>and 'little' with 'a' and 'b' respectively? A string comparison would be
>ideal but possibly can work with other ways.
>
>I could think of adding compatibles to achieve this, but was hoping to
>find something more elegant and appropriate. Or, is compatible the
>recommended way to uniquely identify devices by the driver?
>
>Thanks,
>Lina
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How-to: Uniquely identify a DT node in the driver?

[Sudeep Holla]

On 28/07/15 20:38, Lina Iyer wrote:
> Hello,
>
> I am looking to find a way to uniquely identify a device in the driver.
> Here is an example -
>
> 	big: power-controller@1 {
> 		compatible = "soc,foo";
> 		...
> 	};
>
> 	little: power-controller@2 {
> 		compatible = "soc,foo";
> 		...
> 	};
>
>
> In the driver for the power-controller foo.c, would like to do -
>
> 	struct xyz {
> 		const char *name;
> 		...
> 	};
>
> 	static struct xyz a = {
> 		.name = "big"; // To be associated with big device
> 		...
> 	};
>
> 	static struct xyz b = {
> 		.name = "little"; // To be associated with little device
> 		...
> 	};
>
> What would be the best way to associate the power-controller devices 'big'
> and 'little' with 'a' and 'b' respectively? A string comparison would be
> ideal but possibly can work with other ways.
>

Why do you want to distinguish them within the driver ? IIUC each of
these power controller will get instantiated as separate devices with
unique properties.

Assuming the big and little above are related to CPUs, if each of the
CPUs have phandles to their respective power controller, IMO you need
not distinguish between the big and the little power controllers.

I may be missing something here, one possible reason I can think of for
distinguishing them is both power controllers have same set of
properties in DT, but they differ in the way you access them or program
them(e.g. sequence). In that case have different compatible makes sense.

> I could think of adding compatibles to achieve this, but was hoping to
> find something more elegant and appropriate. Or, is compatible the
> recommended way to uniquely identify devices by the driver?
>

If you provide the exact reason for distinguishing them within the
driver, that would help to come up with the solution.

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How-to: Uniquely identify a DT node in the driver?

[Lina Iyer]

On Wed, Jul 29 2015 at 03:44 -0600, Sudeep Holla wrote:
>
>
>On 28/07/15 20:38, Lina Iyer wrote:
>>Hello,
>>
>>I am looking to find a way to uniquely identify a device in the driver.
>>Here is an example -
>>
>>	big: power-controller@1 {
>>		compatible = "soc,foo";
>>		...
>>	};
>>
>>	little: power-controller@2 {
>>		compatible = "soc,foo";
>>		...
>>	};
>>
>>
>>In the driver for the power-controller foo.c, would like to do -
>>
>>	struct xyz {
>>		const char *name;
>>		...
>>	};
>>
>>	static struct xyz a = {
>>		.name = "big"; // To be associated with big device
>>		...
>>	};
>>
>>	static struct xyz b = {
>>		.name = "little"; // To be associated with little device
>>		...
>>	};
>>
>>What would be the best way to associate the power-controller devices 'big'
>>and 'little' with 'a' and 'b' respectively? A string comparison would be
>>ideal but possibly can work with other ways.
>>
>
>Why do you want to distinguish them within the driver ? IIUC each of
>these power controller will get instantiated as separate devices with
>unique properties.
>
>Assuming the big and little above are related to CPUs, if each of the
>CPUs have phandles to their respective power controller, IMO you need
>not distinguish between the big and the little power controllers.
>
>I may be missing something here, one possible reason I can think of for
>distinguishing them is both power controllers have same set of
>properties in DT, but they differ in the way you access them or program
>them(e.g. sequence). In that case have different compatible makes sense.
>
You are right. My reason for distinguishing between these devices is
something of a device specific action.

>>I could think of adding compatibles to achieve this, but was hoping to
>>find something more elegant and appropriate. Or, is compatible the
>>recommended way to uniquely identify devices by the driver?
>>
>
>If you provide the exact reason for distinguishing them within the
>driver, that would help to come up with the solution.
>
I thought the context would be confusing, so just sent the gist of the
problem. Well anyways, here it is -

I am trying to instantiate generic PM domains for different CPU clusters
commonly. Individual platform code may have different actions for
powering down/up the CPU domain. It could be different set of bucks that
they need to talk to or bunch of devices. The common code would like to
provide the opportunity for the platform code to perform their
activities.

CPUs may be organized into 'n' clusters, the common code would create
genpd for each of these clusters. In a multi machine image, to identify
the right platform driver for the cluster, is a challenge. I am trying
to solve it the same way as CPUidle - using __init section tables.  To
uniquely identify a cluster in a SoC, I need a way to match the domain
provider's DT node, with a callback in the driver. Like the 'method'
attribute of the CPUIdle macros. The CPU compatibles are too generic and
could duplicate across SoCs to be used for comparison. For e.g, you
could have two clusters of A53 cores that could use the same compatible
string. Distinguishing the domains for each of these clusters is a pain
(but doable using phandles to the domain referenced by the CPU).

To make it easy for the driver, I could only think of adding an unique
compatible string to the domain node and the platform driver would then
be able to same compatible string to distinguish between domains for the
different clusters.

Alternately, I was exploring a way to use phandles for the device nodes
as unique comparison attributes, but that is more complex and doesnt
provide any better benefit than the compatible.

My RFC post for CPU PM domains is here [1].

Thanks,
Lina

[1].
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352787.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How-to: Uniquely identify a DT node in the driver?

[Mark Rutland]

On Tue, Jul 28, 2015 at 08:38:33PM +0100, Lina Iyer wrote:
> Hello,
> 
> I am looking to find a way to uniquely identify a device in the driver.
> Here is an example -
> 
> 	big: power-controller@1 {
> 		compatible = "soc,foo";
> 		...
> 	};
> 
> 	little: power-controller@2 {
> 		compatible = "soc,foo";
> 		...
> 	};

Ok, so these are two instances of the same block...

> In the driver for the power-controller foo.c, would like to do -
> 
> 	struct xyz {
> 		const char *name;
> 		...
> 	};
> 
> 	static struct xyz a = {
> 		.name = "big"; // To be associated with big device
> 		...
> 	};
> 
> 	static struct xyz b = {
> 		.name = "little"; // To be associated with little device
> 		...
> 	};

... which we're magically assuming things about.

> What would be the best way to associate the power-controller devices 'big'
> and 'little' with 'a' and 'b' respectively? A string comparison would be
> ideal but possibly can work with other ways.
> 
> I could think of adding compatibles to achieve this, but was hoping to
> find something more elegant and appropriate. Or, is compatible the
> recommended way to uniquely identify devices by the driver?

There's no recommended way to uniquely idetnify a device, because in
general it doesn't make sense to do so. Doing so implies intimate
knowledge of a particular board and a lack of hardware description in
the DT (otherwise you wouldn't need to associate additional information
with the instance).

Either you need to describe some characteristic of the device with some
properties on each instance, or you need to derive that form the linkage
to other devices.

It looks like you're trying to give different behviours to "big" and
"little" clusters, which doesn't really fit either case. What do you
want to differ? e.g. is it just the set of OPPs?

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How-to: Uniquely identify a DT node in the driver?

[Lina Iyer]

Hey Mark,

On Wed, Jul 29 2015 at 10:40 -0600, Mark Rutland wrote:
>On Tue, Jul 28, 2015 at 08:38:33PM +0100, Lina Iyer wrote:
>> Hello,
>>
>> I am looking to find a way to uniquely identify a device in the driver.
>> Here is an example -
>>
>> 	big: power-controller@1 {
>> 		compatible = "soc,foo";
>> 		...
>> 	};
>>
>> 	little: power-controller@2 {
>> 		compatible = "soc,foo";
>> 		...
>> 	};
>
>Ok, so these are two instances of the same block...
>
>> In the driver for the power-controller foo.c, would like to do -
>>
>> 	struct xyz {
>> 		const char *name;
>> 		...
>> 	};
>>
>> 	static struct xyz a = {
>> 		.name = "big"; // To be associated with big device
>> 		...
>> 	};
>>
>> 	static struct xyz b = {
>> 		.name = "little"; // To be associated with little device
>> 		...
>> 	};
>
>... which we're magically assuming things about.
>
>> What would be the best way to associate the power-controller devices 'big'
>> and 'little' with 'a' and 'b' respectively? A string comparison would be
>> ideal but possibly can work with other ways.
>>
>> I could think of adding compatibles to achieve this, but was hoping to
>> find something more elegant and appropriate. Or, is compatible the
>> recommended way to uniquely identify devices by the driver?
>
>There's no recommended way to uniquely idetnify a device, because in
>general it doesn't make sense to do so. Doing so implies intimate
>knowledge of a particular board and a lack of hardware description in
>the DT (otherwise you wouldn't need to associate additional information
>with the instance).
>
Fair enough.

>Either you need to describe some characteristic of the device with some
>properties on each instance, or you need to derive that form the linkage
>to other devices.
>
>It looks like you're trying to give different behviours to "big" and
>"little" clusters, which doesn't really fit either case. What do you
>want to differ? e.g. is it just the set of OPPs?
>
I explained the context in my response to Sudeep. Guess our mails
crossed at the same time.

You are right. The differenciation is based on the intimate knowledge of
the hardware characteristics of these individual power-controllers. So,
in a way, compatibles are a better way to describe these devices
uniquely instead of a property.

Thank you for your time.

-- Lina


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How-to: Uniquely identify a DT node in the driver?

[Mark Rutland]

Hi,

Sorry for the corss-talk on my previous reply.

> I am trying to instantiate generic PM domains for different CPU clusters
> commonly. Individual platform code may have different actions for
> powering down/up the CPU domain. It could be different set of bucks that
> they need to talk to or bunch of devices. The common code would like to
> provide the opportunity for the platform code to perform their
> activities.
> 
> CPUs may be organized into 'n' clusters, the common code would create
> genpd for each of these clusters. In a multi machine image, to identify
> the right platform driver for the cluster, is a challenge. I am trying
> to solve it the same way as CPUidle - using __init section tables.  To
> uniquely identify a cluster in a SoC, I need a way to match the domain
> provider's DT node, with a callback in the driver. Like the 'method'
> attribute of the CPUIdle macros. The CPU compatibles are too generic and
> could duplicate across SoCs to be used for comparison. For e.g, you
> could have two clusters of A53 cores that could use the same compatible
> string. Distinguishing the domains for each of these clusters is a pain
> (but doable using phandles to the domain referenced by the CPU).
> 
> To make it easy for the driver, I could only think of adding an unique
> compatible string to the domain node and the platform driver would then
> be able to same compatible string to distinguish between domains for the
> different clusters.
> 
> Alternately, I was exploring a way to use phandles for the device nodes
> as unique comparison attributes, but that is more complex and doesnt
> provide any better benefit than the compatible.

I don't believe using compatible strings is the right thing to do. The
thing which varies per-domain is the relationships of various
components, which should be described with phandles. At the level of the
domain, the interface is identical, and thus they should have the same
compatible string.

Using different compatible strings implies that we have to add new
compatible strings for each new variation that appears, leaving us with
a completely arbitrary set of compatible strings with (likely)
ill-defined semantics. That makes it really difficult to reuse code, and
necessitates adding far more.

The inter-device relationships (and the attibutes of those devices)
should be explicit in the DT.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How-to: Uniquely identify a DT node in the driver?

[Lina Iyer]

On Thu, Jul 30 2015 at 12:53 -0600, Mark Rutland wrote:
>Hi,
>
>Sorry for the corss-talk on my previous reply.
>
>> I am trying to instantiate generic PM domains for different CPU clusters
>> commonly. Individual platform code may have different actions for
>> powering down/up the CPU domain. It could be different set of bucks that
>> they need to talk to or bunch of devices. The common code would like to
>> provide the opportunity for the platform code to perform their
>> activities.
>>
>> CPUs may be organized into 'n' clusters, the common code would create
>> genpd for each of these clusters. In a multi machine image, to identify
>> the right platform driver for the cluster, is a challenge. I am trying
>> to solve it the same way as CPUidle - using __init section tables.  To
>> uniquely identify a cluster in a SoC, I need a way to match the domain
>> provider's DT node, with a callback in the driver. Like the 'method'
>> attribute of the CPUIdle macros. The CPU compatibles are too generic and
>> could duplicate across SoCs to be used for comparison. For e.g, you
>> could have two clusters of A53 cores that could use the same compatible
>> string. Distinguishing the domains for each of these clusters is a pain
>> (but doable using phandles to the domain referenced by the CPU).
>>
>> To make it easy for the driver, I could only think of adding an unique
>> compatible string to the domain node and the platform driver would then
>> be able to same compatible string to distinguish between domains for the
>> different clusters.
>>
>> Alternately, I was exploring a way to use phandles for the device nodes
>> as unique comparison attributes, but that is more complex and doesnt
>> provide any better benefit than the compatible.
>
>I don't believe using compatible strings is the right thing to do. The
>thing which varies per-domain is the relationships of various
>components, which should be described with phandles. At the level of the
>domain, the interface is identical, and thus they should have the same
>compatible string.
>
>Using different compatible strings implies that we have to add new
>compatible strings for each new variation that appears, leaving us with
>a completely arbitrary set of compatible strings with (likely)
>ill-defined semantics. That makes it really difficult to reuse code, and
>necessitates adding far more.
>
Okay.

>The inter-device relationships (and the attibutes of those devices)
>should be explicit in the DT.
>
Alright. That makes sense. My example does not violate this.

I have an established relationship between device nodes in the device
tree - CPUs reference their power-controller handles. I have two
clusters of CPUs. Would compatible strings still be an incorrect use (as
an alternate to property attributes) to distinguish these devices for
the driver?

I am doing something like this (the patches are not on any ML yet) - 

static struct of_arm_pd_ops pd_ops_big __initdata = {
        .init = pd_init_big,
        .power_on = pd_power_on,
        .power_off = pd_power_off,
};
ARM_PD_METHOD_OF_DECLARE(big, "foo,big" , &pd_ops_big);

static struct of_arm_pd_ops pd_ops_little __initdata = {
        .init = pd_init_little,
        .power_on = pd_power_on,
        .power_off = pd_power_off,
};
ARM_PD_METHOD_OF_DECLARE(little, "foo,little" , &pd_ops_little);

The ARM_PD_METHOD_OF_DECLARE is a macro that adds pd_ops_xxx to the
__init section tables, just like cpuidle does. ARM common code issues a
callback to the .init() of the ops at _initcall allowing the platform
code to update the controller properties specific to the platform.
Comparing the compatible read from the device node with that of the ops,
ARM common code knows which platform ops to call. This also allows,
driver to register multiple ops based on different compatibles.

Having these compatibles, eases the driver's work of identifying the
power controller without having to parse through the CPU, to figure out
which power-controller device the .init() callback is referring to.

What do you think? Sorry, if I went into too much specifics. Couldnt
think of a better way to explain.

Thanks,
Lina
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html