Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
> Hello Eduardo,
>
> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>> Eduardo, what has happened to this patchset?
>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
> I propose to refactor your patchset, moving from procfs to sysfs.

>>> Do you want help in picking it up and try to polish it up?
>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>> was that we should not mess with /proc. So, maybe moving back
 >> to something under sysfs. Perhaps /sys/devices/soc or so?
> About the location of this new sysfs entry, where do you think it should
> be?
> I propose to create a new directory named "soc" in /sys/devices/system/.
>
> As platform vendors have several/different kind of IDs to export to
> sysfs, I propose each vendor to create file entries related to their IDs
> (eg. /sys/devices/system/soc/idcode for OMAP platforms).

I think the path /sys/devices/system/soc/ will work for the MSM too. I 
would have ideally liked it to be /sys/devices/system/soc/msm, 
/sys/devices/system/soc/omap, etc, but we can't get to pick names for 
devices under a class. So, we can make do with /sys/devices/system/soc/.

> However, I think we should have a common file entry to export the unique
> ID of the platforms. Indeed, user-space applications should have a
> unified way to get this kind of ID, regardless of the platform (eg.
> /sys/devices/system/soc/unique_id).

I like the idea of have a common file across all implementations that 
will let user space identify what implementation is exporting the other 
files and how to interpret them.

I would like to propose an "arch" file to identify the arch the soc info 
file are for. I'm guessing within an arch, the soc files would mostly be 
the same? If there are other minor differences, we can let the arch 
specific code deal with how the files are interpreted.

Does "arch" work for everyone?

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Andrei Warkentin]

On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
<skannan@codeaurora.org> wrote:
> On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
>>
>> Hello Eduardo,
>>
>> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>>>
>>>> Eduardo, what has happened to this patchset?
>>>
>>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
>>
>> I propose to refactor your patchset, moving from procfs to sysfs.
>
>>>> Do you want help in picking it up and try to polish it up?
>>>
>>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>>> was that we should not mess with /proc. So, maybe moving back
>
>>> to something under sysfs. Perhaps /sys/devices/soc or so?
>>
>> About the location of this new sysfs entry, where do you think it should
>> be?
>> I propose to create a new directory named "soc" in /sys/devices/system/.
>>
>> As platform vendors have several/different kind of IDs to export to
>> sysfs, I propose each vendor to create file entries related to their IDs
>> (eg. /sys/devices/system/soc/idcode for OMAP platforms).
>
> I think the path /sys/devices/system/soc/ will work for the MSM too. I would
> have ideally liked it to be /sys/devices/system/soc/msm,
> /sys/devices/system/soc/omap, etc, but we can't get to pick names for
> devices under a class. So, we can make do with /sys/devices/system/soc/.
>
>> However, I think we should have a common file entry to export the unique
>> ID of the platforms. Indeed, user-space applications should have a
>> unified way to get this kind of ID, regardless of the platform (eg.
>> /sys/devices/system/soc/unique_id).
>
> I like the idea of have a common file across all implementations that will
> let user space identify what implementation is exporting the other files and
> how to interpret them.
>
> I would like to propose an "arch" file to identify the arch the soc info
> file are for. I'm guessing within an arch, the soc files would mostly be the
> same? If there are other minor differences, we can let the arch specific
> code deal with how the files are interpreted.
>
> Does "arch" work for everyone?
>

Sorry to butt in, but what kind of info are you guys talking about?
Like SOC revision, serial numbers, etc...?

What would an "arch" file mean? The name of the soc platform?

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
> <skannan@codeaurora.org>  wrote:
>> On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
>>>
>>> Hello Eduardo,
>>>
>>> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>>>>
>>>>> Eduardo, what has happened to this patchset?
>>>>
>>>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
>>>
>>> I propose to refactor your patchset, moving from procfs to sysfs.
>>
>>>>> Do you want help in picking it up and try to polish it up?
>>>>
>>>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>>>> was that we should not mess with /proc. So, maybe moving back
>>
>>>> to something under sysfs. Perhaps /sys/devices/soc or so?
>>>
>>> About the location of this new sysfs entry, where do you think it should
>>> be?
>>> I propose to create a new directory named "soc" in /sys/devices/system/.
>>>
>>> As platform vendors have several/different kind of IDs to export to
>>> sysfs, I propose each vendor to create file entries related to their IDs
>>> (eg. /sys/devices/system/soc/idcode for OMAP platforms).
>>
>> I think the path /sys/devices/system/soc/ will work for the MSM too. I would
>> have ideally liked it to be /sys/devices/system/soc/msm,
>> /sys/devices/system/soc/omap, etc, but we can't get to pick names for
>> devices under a class. So, we can make do with /sys/devices/system/soc/.
>>
>>> However, I think we should have a common file entry to export the unique
>>> ID of the platforms. Indeed, user-space applications should have a
>>> unified way to get this kind of ID, regardless of the platform (eg.
>>> /sys/devices/system/soc/unique_id).
>>
>> I like the idea of have a common file across all implementations that will
>> let user space identify what implementation is exporting the other files and
>> how to interpret them.
>>
>> I would like to propose an "arch" file to identify the arch the soc info
>> file are for. I'm guessing within an arch, the soc files would mostly be the
>> same? If there are other minor differences, we can let the arch specific
>> code deal with how the files are interpreted.
>>
>> Does "arch" work for everyone?
>>
>
> Sorry to butt in, but what kind of info are you guys talking about?

Please do butt in :-), that's what a community discussion is for.

> Like SOC revision, serial numbers, etc...?

Like SOC type (to identify different chipsets), revision, etc.

> What would an "arch" file mean? The name of the soc platform?

The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or 
similar paths. If that info is already available elsewhere, then that 
file is not needed. I proposed using the arch since that will remove the 
need to maintain some database of unique/reserved names/numbers for each 
implementation of socinfo (like the machinetypes list we have).

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 02:19 PM, Saravana Kannan wrote:
> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>> <skannan@codeaurora.org>  wrote:

<snip>

>> What would an "arch" file mean? The name of the soc platform?
> 
> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
> similar paths. If that info is already available elsewhere, then that
> file is not needed. I proposed using the arch since that will remove the
> need to maintain some database of unique/reserved names/numbers for each
> implementation of socinfo (like the machinetypes list we have).

/proc/cpuinfo already tells you what the CPU is, which gives more
information than just the architecture name.

Why is the arch information even required by userspace?

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 05:27 PM, Ryan Mallon wrote:
> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>> <skannan@codeaurora.org>   wrote:
>
> <snip>
>
>>> What would an "arch" file mean? The name of the soc platform?
>>
>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>> similar paths. If that info is already available elsewhere, then that
>> file is not needed. I proposed using the arch since that will remove the
>> need to maintain some database of unique/reserved names/numbers for each
>> implementation of socinfo (like the machinetypes list we have).
>
> /proc/cpuinfo already tells you what the CPU is, which gives more
> information than just the architecture name.
>
> Why is the arch information even required by userspace?

The socinfo exported by each soc is different. If userspace is trying to 
make decisions based on socinfo, it will need to know what type of soc 
(really what type of socinfo implementation) it is before trying to 
interpret the rest of the socinfo files. Keep in mind that cpuinfo is 
different from socinfo -- the cpu is just a small part of a soc.

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 02:39 PM, Saravana Kannan wrote:
> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>> <skannan@codeaurora.org>   wrote:
>>
>> <snip>
>>
>>>> What would an "arch" file mean? The name of the soc platform?
>>>
>>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>>> similar paths. If that info is already available elsewhere, then that
>>> file is not needed. I proposed using the arch since that will remove the
>>> need to maintain some database of unique/reserved names/numbers for each
>>> implementation of socinfo (like the machinetypes list we have).
>>
>> /proc/cpuinfo already tells you what the CPU is, which gives more
>> information than just the architecture name.
>>
>> Why is the arch information even required by userspace?
> 
> The socinfo exported by each soc is different. If userspace is trying to
> make decisions based on socinfo, it will need to know what type of soc
> (really what type of socinfo implementation) it is before trying to
> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
> different from socinfo -- the cpu is just a small part of a soc.

I understand that having a socinfo file for obtaining information about
a particular SoC would be useful. A similar discussion came up a few
years ago when we talked about having a socinfo file for exposing the
ep93xx Maverick crunch id, but nothing ever came out of it.

What I don't understand is why you want the 'arch' file (ie the
mach-xxxx) name. /proc/cpuinfo already gives you more information than
an 'arch' file would. I also can't think of a particularly good
situation why userspace would need to know at runtime what the
architecture is.

Have a socinfo file to expose implementation details of the particular
SoC I am fine with (assuming those details are useful to userspace),
having an 'arch' file to expose the architecture I am against.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 05:51 PM, Ryan Mallon wrote:
> On 03/02/2011 02:39 PM, Saravana Kannan wrote:
>> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>>> <skannan@codeaurora.org>    wrote:
>>>
>>> <snip>
>>>
>>>>> What would an "arch" file mean? The name of the soc platform?
>>>>
>>>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>>>> similar paths. If that info is already available elsewhere, then that
>>>> file is not needed. I proposed using the arch since that will remove the
>>>> need to maintain some database of unique/reserved names/numbers for each
>>>> implementation of socinfo (like the machinetypes list we have).
>>>
>>> /proc/cpuinfo already tells you what the CPU is, which gives more
>>> information than just the architecture name.
>>>
>>> Why is the arch information even required by userspace?
>>
>> The socinfo exported by each soc is different. If userspace is trying to
>> make decisions based on socinfo, it will need to know what type of soc
>> (really what type of socinfo implementation) it is before trying to
>> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
>> different from socinfo -- the cpu is just a small part of a soc.
>
> I understand that having a socinfo file for obtaining information about
> a particular SoC would be useful. A similar discussion came up a few
> years ago when we talked about having a socinfo file for exposing the
> ep93xx Maverick crunch id, but nothing ever came out of it.
>
> What I don't understand is why you want the 'arch' file (ie the
> mach-xxxx) name. /proc/cpuinfo already gives you more information than
> an 'arch' file would. I also can't think of a particularly good
> situation why userspace would need to know at runtime what the
> architecture is.
>
> Have a socinfo file to expose implementation details of the particular
> SoC I am fine with (assuming those details are useful to userspace),
> having an 'arch' file to expose the architecture I am against.

You probably already understood this, but just to be sure, when I say 
"socinfo implementation" I mean the various ways the socinfo data should 
be interpreted by userspace. "socid" of 1 would mean a different thing 
depending on whether it's for omap, msm, kirkwood, etc.

I don't have any attachment to the "arch" file suggestion. If there is a 
better solution to identify the different implementations of socinfo 
without having to maintain some "unique id" list in the kernel, then I'm 
all for it. But cpuinfo is not it.

Which data listed in cpuinfo do you think will let you identify the 
socinfo implementation in a unique manner? The only thing that's even 
remotely possible is vendor_id, but I'm not sure what it's supposed to 
be if the CPU core is licensed from some vendor and used in a SOC by 
another vendor. What is a Samsung with an ARM11 core supposed to list 
for vendor_id? What if the another Samsung SOC has a Samsung's own CPU 
core? What about non-ARM architectures? I would rather not add implicit 
dependency on cpuinfo that's hard to maintain or guarantee and instead 
have the socinfo implementation explicitly exported.

The "arch" filename and what it's supposed to contain was just a 
suggestion. Another alternative might be to call it soc-family and the a 
general guideline to keep it as close as possible to the mach-xxxx name. 
For example, omap3 and omap4 might not care for having different socinfo 
implementations and can decide to use the socfamily name of "omap".

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 03:23 PM, Saravana Kannan wrote:
> On 03/01/2011 05:51 PM, Ryan Mallon wrote:
>> On 03/02/2011 02:39 PM, Saravana Kannan wrote:
>>> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>>>> <skannan@codeaurora.org>    wrote:
>>>>
>>>> <snip>
>>>>
>>>>>> What would an "arch" file mean? The name of the soc platform?
>>>>>
>>>>> The arch file would pretty much be the "xxxx" from
>>>>> arch/arm/mach-xxxx or
>>>>> similar paths. If that info is already available elsewhere, then that
>>>>> file is not needed. I proposed using the arch since that will
>>>>> remove the
>>>>> need to maintain some database of unique/reserved names/numbers for
>>>>> each
>>>>> implementation of socinfo (like the machinetypes list we have).
>>>>
>>>> /proc/cpuinfo already tells you what the CPU is, which gives more
>>>> information than just the architecture name.
>>>>
>>>> Why is the arch information even required by userspace?
>>>
>>> The socinfo exported by each soc is different. If userspace is trying to
>>> make decisions based on socinfo, it will need to know what type of soc
>>> (really what type of socinfo implementation) it is before trying to
>>> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
>>> different from socinfo -- the cpu is just a small part of a soc.
>>
>> I understand that having a socinfo file for obtaining information about
>> a particular SoC would be useful. A similar discussion came up a few
>> years ago when we talked about having a socinfo file for exposing the
>> ep93xx Maverick crunch id, but nothing ever came out of it.
>>
>> What I don't understand is why you want the 'arch' file (ie the
>> mach-xxxx) name. /proc/cpuinfo already gives you more information than
>> an 'arch' file would. I also can't think of a particularly good
>> situation why userspace would need to know at runtime what the
>> architecture is.
>>
>> Have a socinfo file to expose implementation details of the particular
>> SoC I am fine with (assuming those details are useful to userspace),
>> having an 'arch' file to expose the architecture I am against.
> 
> You probably already understood this, but just to be sure, when I say
> "socinfo implementation" I mean the various ways the socinfo data should
> be interpreted by userspace. "socid" of 1 would mean a different thing
> depending on whether it's for omap, msm, kirkwood, etc.
> 
> I don't have any attachment to the "arch" file suggestion. If there is a
> better solution to identify the different implementations of socinfo
> without having to maintain some "unique id" list in the kernel, then I'm
> all for it. But cpuinfo is not it.

Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
file makes a bit more sense, but should probably be called 'mach' rather
than 'arch' to avoid this confusion :-).

I still think it is a solution in search of a problem though. What
userspace programs need to know what specific SoC they are on? My
feeling is that if userspace needs to know this information, then it is
probably dicking around with things that should be managed by the
kernel. Differences in available peripherals, etc can be determined by
looking at existing sysfs files.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 06:41 PM, Ryan Mallon wrote:
> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>> I don't have any attachment to the "arch" file suggestion. If there is a
>> better solution to identify the different implementations of socinfo
>> without having to maintain some "unique id" list in the kernel, then I'm
>> all for it. But cpuinfo is not it.
>
> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
> file makes a bit more sense, but should probably be called 'mach' rather
> than 'arch' to avoid this confusion :-).

Sorry for the confusion. Sure, I don't care much for the filename as 
long as we can all agree on it. I care more about the content of the 
file (using names very close to xxxx in mach-xxxx). I like "soc-family" 
better since it's generic enough to not force, say omap3 and omap4, to 
report different values.

Linus Walleij, Eduardo, Maxime, Andrei,

Would like to hear your opinion on the file name (soc-family vs. mach vs 
<somethingelse>) and the path /sys/devices/system/soc/.

If we settle on this, may be it would be easier to get this through.

> I still think it is a solution in search of a problem though. What
> userspace programs need to know what specific SoC they are on? My
> feeling is that if userspace needs to know this information, then it is
> probably dicking around with things that should be managed by the
> kernel. Differences in available peripherals, etc can be determined by
> looking at existing sysfs files.

I certainly have seen several use cases. Couple of easy examples:

* A lot of test scripts would find this very useful. For example, some 
clock (present is all/most MSMs) shouldn't be tested on some SOCs as it 
would lock up the system if you try to turn it off while the CPU is running.

* Some of the user space tools might want to report different "product 
id/type" (nothing to do with USB, etc) depending on what SOC it is 
running on.

Thank,
Saravana
P.S: Removed felipe.balbi@nokia.com <felipe.balbi@nokia.com> since I 
keep getting delivery failure emails.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 03:55 PM, Saravana Kannan wrote:
> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>> better solution to identify the different implementations of socinfo
>>> without having to maintain some "unique id" list in the kernel, then I'm
>>> all for it. But cpuinfo is not it.
>>
>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>> file makes a bit more sense, but should probably be called 'mach' rather
>> than 'arch' to avoid this confusion :-).
> 
> Sorry for the confusion. Sure, I don't care much for the filename as
> long as we can all agree on it. I care more about the content of the
> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
> better since it's generic enough to not force, say omap3 and omap4, to
> report different values.
> 
> Linus Walleij, Eduardo, Maxime, Andrei,
> 
> Would like to hear your opinion on the file name (soc-family vs. mach vs
> <somethingelse>) and the path /sys/devices/system/soc/.

'family' sounds good. I don't think we need the 'soc-' prefix on
filenames if they are already in /sys/devices/system/soc/.

> 
> If we settle on this, may be it would be easier to get this through.
> 
>> I still think it is a solution in search of a problem though. What
>> userspace programs need to know what specific SoC they are on? My
>> feeling is that if userspace needs to know this information, then it is
>> probably dicking around with things that should be managed by the
>> kernel. Differences in available peripherals, etc can be determined by
>> looking at existing sysfs files.
> 
> I certainly have seen several use cases. Couple of easy examples:
> 
> * A lot of test scripts would find this very useful. For example, some
> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
> would lock up the system if you try to turn it off while the CPU is
> running.

I don't follow here. Do you mean a struct clk clock or something else?
Why is userspace allowed to disable a clock which will effectively hang
the system? :-).

> * Some of the user space tools might want to report different "product
> id/type" (nothing to do with USB, etc) depending on what SOC it is
> running on.

This makes more sense. It would actually be useful for custom USB
devices (gadget) which can be done from user space.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 07:11 PM, Ryan Mallon wrote:
> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>>> better solution to identify the different implementations of socinfo
>>>> without having to maintain some "unique id" list in the kernel, then I'm
>>>> all for it. But cpuinfo is not it.
>>>
>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>> file makes a bit more sense, but should probably be called 'mach' rather
>>> than 'arch' to avoid this confusion :-).
>>
>> Sorry for the confusion. Sure, I don't care much for the filename as
>> long as we can all agree on it. I care more about the content of the
>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>> better since it's generic enough to not force, say omap3 and omap4, to
>> report different values.
>>
>> Linus Walleij, Eduardo, Maxime, Andrei,
>>
>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>> <somethingelse>) and the path /sys/devices/system/soc/.
>
> 'family' sounds good. I don't think we need the 'soc-' prefix on
> filenames if they are already in /sys/devices/system/soc/.

Makes sense. We can drop the soc- prefix. So the contenders left: family 
vs <somethingelse>. Would still be nice if the other folks chime in.

>> If we settle on this, may be it would be easier to get this through.
>>
>>> I still think it is a solution in search of a problem though. What
>>> userspace programs need to know what specific SoC they are on? My
>>> feeling is that if userspace needs to know this information, then it is
>>> probably dicking around with things that should be managed by the
>>> kernel. Differences in available peripherals, etc can be determined by
>>> looking at existing sysfs files.
>>
>> I certainly have seen several use cases. Couple of easy examples:
>>
>> * A lot of test scripts would find this very useful. For example, some
>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>> would lock up the system if you try to turn it off while the CPU is
>> running.
>
> I don't follow here. Do you mean a struct clk clock or something else?
> Why is userspace allowed to disable a clock which will effectively hang
> the system? :-).

Ah, sorry. Didn't give enough details. To give some context, I manage 
the clock stuff for MSM. The MSM clock driver exports clock control thru 
debugfs. We have test scripts that bang the clocks to test them. Each 
SoC has a different set of "touch me and you die" clocks that the test 
script shouldn't mess with. This socinfo would be useful for those test 
cases.

>> * Some of the user space tools might want to report different "product
>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>> running on.
>
> This makes more sense. It would actually be useful for custom USB
> devices (gadget) which can be done from user space.

Hmm... didn't know USB devices/gadgets could be handled from userspace.

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 04:21 PM, Saravana Kannan wrote:
> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>>> I don't have any attachment to the "arch" file suggestion. If there
>>>>> is a
>>>>> better solution to identify the different implementations of socinfo
>>>>> without having to maintain some "unique id" list in the kernel,
>>>>> then I'm
>>>>> all for it. But cpuinfo is not it.
>>>>
>>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>>> file makes a bit more sense, but should probably be called 'mach'
>>>> rather
>>>> than 'arch' to avoid this confusion :-).
>>>
>>> Sorry for the confusion. Sure, I don't care much for the filename as
>>> long as we can all agree on it. I care more about the content of the
>>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>>> better since it's generic enough to not force, say omap3 and omap4, to
>>> report different values.
>>>
>>> Linus Walleij, Eduardo, Maxime, Andrei,
>>>
>>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>>> <somethingelse>) and the path /sys/devices/system/soc/.
>>
>> 'family' sounds good. I don't think we need the 'soc-' prefix on
>> filenames if they are already in /sys/devices/system/soc/.
> 
> Makes sense. We can drop the soc- prefix. So the contenders left: family
> vs <somethingelse>. Would still be nice if the other folks chime in.
> 
>>> If we settle on this, may be it would be easier to get this through.
>>>
>>>> I still think it is a solution in search of a problem though. What
>>>> userspace programs need to know what specific SoC they are on? My
>>>> feeling is that if userspace needs to know this information, then it is
>>>> probably dicking around with things that should be managed by the
>>>> kernel. Differences in available peripherals, etc can be determined by
>>>> looking at existing sysfs files.
>>>
>>> I certainly have seen several use cases. Couple of easy examples:
>>>
>>> * A lot of test scripts would find this very useful. For example, some
>>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>>> would lock up the system if you try to turn it off while the CPU is
>>> running.
>>
>> I don't follow here. Do you mean a struct clk clock or something else?
>> Why is userspace allowed to disable a clock which will effectively hang
>> the system? :-).
> 
> Ah, sorry. Didn't give enough details. To give some context, I manage
> the clock stuff for MSM. The MSM clock driver exports clock control thru
> debugfs. We have test scripts that bang the clocks to test them. Each
> SoC has a different set of "touch me and you die" clocks that the test
> script shouldn't mess with. This socinfo would be useful for those test
> cases.

Ah, okay. This is still within a single SoC family though since we don't
yet (AFAIK) support mutliple SoCs in a single kernel.

>>> * Some of the user space tools might want to report different "product
>>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>>> running on.
>>
>> This makes more sense. It would actually be useful for custom USB
>> devices (gadget) which can be done from user space.
> 
> Hmm... didn't know USB devices/gadgets could be handled from userspace.

The gadgetfs driver allows for writing custom usb device
implementations. The SoC info could be used to set the USB
vendor/product id. Again, I see this more useful within the SoC family
(ie at91sam9260 vs at91sam9263) rather than between families. From an
embedded perspective at least, I think it is unlikely for an application
to need to work on multiple SoC families.

The only real objection I have to adding the SoC family information is
basically to discourage it being abused by userspace. I can see it being
useful in debug situations, but I can also see stupid userspace
applications explicitly testing for some particular SoC, rather than
more correctly (IMHO) checking for presence of certain drivers etc.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 07:35 PM, Ryan Mallon wrote:
> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>>>> I don't have any attachment to the "arch" file suggestion. If there
>>>>>> is a
>>>>>> better solution to identify the different implementations of socinfo
>>>>>> without having to maintain some "unique id" list in the kernel,
>>>>>> then I'm
>>>>>> all for it. But cpuinfo is not it.
>>>>>
>>>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>>>> file makes a bit more sense, but should probably be called 'mach'
>>>>> rather
>>>>> than 'arch' to avoid this confusion :-).
>>>>
>>>> Sorry for the confusion. Sure, I don't care much for the filename as
>>>> long as we can all agree on it. I care more about the content of the
>>>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>>>> better since it's generic enough to not force, say omap3 and omap4, to
>>>> report different values.
>>>>
>>>> Linus Walleij, Eduardo, Maxime, Andrei,
>>>>
>>>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>>>> <somethingelse>) and the path /sys/devices/system/soc/.
>>>
>>> 'family' sounds good. I don't think we need the 'soc-' prefix on
>>> filenames if they are already in /sys/devices/system/soc/.
>>
>> Makes sense. We can drop the soc- prefix. So the contenders left: family
>> vs<somethingelse>. Would still be nice if the other folks chime in.
>>
>>>> If we settle on this, may be it would be easier to get this through.
>>>>
>>>>> I still think it is a solution in search of a problem though. What
>>>>> userspace programs need to know what specific SoC they are on? My
>>>>> feeling is that if userspace needs to know this information, then it is
>>>>> probably dicking around with things that should be managed by the
>>>>> kernel. Differences in available peripherals, etc can be determined by
>>>>> looking at existing sysfs files.
>>>>
>>>> I certainly have seen several use cases. Couple of easy examples:
>>>>
>>>> * A lot of test scripts would find this very useful. For example, some
>>>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>>>> would lock up the system if you try to turn it off while the CPU is
>>>> running.
>>>
>>> I don't follow here. Do you mean a struct clk clock or something else?
>>> Why is userspace allowed to disable a clock which will effectively hang
>>> the system? :-).
>>
>> Ah, sorry. Didn't give enough details. To give some context, I manage
>> the clock stuff for MSM. The MSM clock driver exports clock control thru
>> debugfs. We have test scripts that bang the clocks to test them. Each
>> SoC has a different set of "touch me and you die" clocks that the test
>> script shouldn't mess with. This socinfo would be useful for those test
>> cases.
>
> Ah, okay. This is still within a single SoC family though since we don't
> yet (AFAIK) support mutliple SoCs in a single kernel.

Yes, my example was within a single SoC family. But since this is user 
space example, it doesn't matter if a single kernel can support multiple 
SoCs/SoC families. We could still have one userspace code that might 
want to support multiple SoC families.

Anyway, I think we are in agreement here. So, will stop discussing this 
point.

>>>> * Some of the user space tools might want to report different "product
>>>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>>>> running on.
>>>
>>> This makes more sense. It would actually be useful for custom USB
>>> devices (gadget) which can be done from user space.
>>
>> Hmm... didn't know USB devices/gadgets could be handled from userspace.
>
> The gadgetfs driver allows for writing custom usb device
> implementations. The SoC info could be used to set the USB
> vendor/product id. Again, I see this more useful within the SoC family
> (ie at91sam9260 vs at91sam9263) rather than between families. From an
> embedded perspective at least, I think it is unlikely for an application
> to need to work on multiple SoC families.
>
> The only real objection I have to adding the SoC family information is
> basically to discourage it being abused by userspace. I can see it being
> useful in debug situations, but I can also see stupid userspace
> applications explicitly testing for some particular SoC, rather than
> more correctly (IMHO) checking for presence of certain drivers etc.

True, but so many other things could be misused by stupid userspace 
programs. When there are legitimate usecases, I think we shouldn't 
prevent them just because we think a stupid userspace program could 
misuse it.

Again, although you might not be gung-ho about this, I think I have at 
least made you indifferent/mildly supportive to adding socinfo. If you 
don't mind, I would like to wait for others to chime in before 
continuing this discussion.

-Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 04:46 PM, Saravana Kannan wrote:
> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:

<snip>

>> The only real objection I have to adding the SoC family information is
>> basically to discourage it being abused by userspace. I can see it being
>> useful in debug situations, but I can also see stupid userspace
>> applications explicitly testing for some particular SoC, rather than
>> more correctly (IMHO) checking for presence of certain drivers etc.
> 
> True, but so many other things could be misused by stupid userspace
> programs. When there are legitimate usecases, I think we shouldn't
> prevent them just because we think a stupid userspace program could
> misuse it.
> 
> Again, although you might not be gung-ho about this, I think I have at
> least made you indifferent/mildly supportive to adding socinfo. If you
> don't mind, I would like to wait for others to chime in before
> continuing this discussion.

Agreed.

In general I am in support of having the SoC information exposed
somewhere. I think we just want to be careful that it doesn't become a
dumping ground for anything and everything SoC related whether the
information is useful or not. I think each piece of exposed information
should have a genuine use case, not just "because we can".

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

On 03/02/2011 03:55 AM, Saravana Kannan wrote:
> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>> better solution to identify the different implementations of socinfo
>>> without having to maintain some "unique id" list in the kernel, then I'm
>>> all for it. But cpuinfo is not it.
>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>> file makes a bit more sense, but should probably be called 'mach' rather
>> than 'arch' to avoid this confusion :-).
> Sorry for the confusion. Sure, I don't care much for the filename as
> long as we can all agree on it. I care more about the content of the
> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
> better since it's generic enough to not force, say omap3 and omap4, to
> report different values.
>
> Linus Walleij, Eduardo, Maxime, Andrei,
>
> Would like to hear your opinion on the file name (soc-family vs. mach vs
> <somethingelse>) and the path /sys/devices/system/soc/.
>
> If we settle on this, may be it would be easier to get this through.
>

I think we should have a tree like this :

/sys/devices/system/soc/
/sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
/sys/devices/system/soc/mach/
/sys/devices/system/soc/mach/name<- Name of the mach
/sys/devices/system/soc/mach/foo_id
/sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs to export (IDCODE for OMAP, Production ID...)

Linus, do you agree?

>> I still think it is a solution in search of a problem though. What
>> userspace programs need to know what specific SoC they are on? My
>> feeling is that if userspace needs to know this information, then it is
>> probably dicking around with things that should be managed by the
>> kernel. Differences in available peripherals, etc can be determined by
>> looking at existing sysfs files.
> I certainly have seen several use cases. Couple of easy examples:
>
> * A lot of test scripts would find this very useful. For example, some
> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
> would lock up the system if you try to turn it off while the CPU is running.
>
> * Some of the user space tools might want to report different "product
> id/type" (nothing to do with USB, etc) depending on what SOC it is
> running on.
>

For example, we have some user-space tools which need to have serial 
number to write it in logs.

> Thank,
> Saravana
> P.S: Removed felipe.balbi@nokia.com<felipe.balbi@nokia.com>  since I
> keep getting delivery failure emails.
>

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

On 03/02/2011 04:54 AM, Ryan Mallon wrote:
> On 03/02/2011 04:46 PM, Saravana Kannan wrote:
>> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>>> The only real objection I have to adding the SoC family information is
>>> basically to discourage it being abused by userspace. I can see it being
>>> useful in debug situations, but I can also see stupid userspace
>>> applications explicitly testing for some particular SoC, rather than
>>> more correctly (IMHO) checking for presence of certain drivers etc.
>> True, but so many other things could be misused by stupid userspace
>> programs. When there are legitimate usecases, I think we shouldn't
>> prevent them just because we think a stupid userspace program could
>> misuse it.
>>
>> Again, although you might not be gung-ho about this, I think I have at
>> least made you indifferent/mildly supportive to adding socinfo. If you
>> don't mind, I would like to wait for others to chime in before
>> continuing this discussion.
> Agreed.
>
> In general I am in support of having the SoC information exposed
> somewhere. I think we just want to be careful that it doesn't become a
> dumping ground for anything and everything SoC related whether the
> information is useful or not. I think each piece of exposed information
> should have a genuine use case, not just "because we can".
I definitely agree we should not export every SoC-related information 
just because we can do it.
The first goal of this interface was to export some SoCs IDs, as we need 
this kind of information for some user-space tools.
Does someone need to export other information than the mach name and 
some IDs?

As proposed in my previous mail, do you agree to have a unified file for 
all vendors, which exports the unique silicon ID of the chip?

Regards,
Maxime

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Linus Walleij]

On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
<maxime.coquelin-nonst@stericsson.com> wrote:

> I think we should have a tree like this :
>
> /sys/devices/system/soc/
> /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs

Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
etc.

Should we say it's a hex string of 64 bits?

> /sys/devices/system/soc/mach/
> /sys/devices/system/soc/mach/name<- Name of the mach
> /sys/devices/system/soc/mach/foo_id
> /sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs
> to export (IDCODE for OMAP, Production ID...)

For Ux500 we can export the stuff we print today in mach-ux500/id.c,
put in place earlier by Rabin, I'd prefer if you hook in the new ID stuff
there as well, since it's so little platform code, and a logical place to
have it in.

> Linus, do you agree?

Yeah, sounds good.

Yours,
Linus Walleij

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

On 03/02/2011 11:36 AM, Linus Walleij wrote:
> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
> <maxime.coquelin-nonst@stericsson.com>  wrote:
>
>> I think we should have a tree like this :
>>
>> /sys/devices/system/soc/
>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
> etc.

Yes, here is the difficulty. For example, in our case, the SoC unique ID 
is 160 bits long.
Maybe it would be a better solution to get rid of this unified file, and 
keep only mach specific entries? I mean :

/sys/devices/system/soc/
/sys/devices/system/soc/mach_name
/sys/devices/system/soc/foo_id
/sys/devices/system/soc/bar_id


> Should we say it's a hex string of 64 bits?
>
>> /sys/devices/system/soc/mach/
>> /sys/devices/system/soc/mach/name<- Name of the mach
>> /sys/devices/system/soc/mach/foo_id
>> /sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs
>> to export (IDCODE for OMAP, Production ID...)
> For Ux500 we can export the stuff we print today in mach-ux500/id.c,
> put in place earlier by Rabin, I'd prefer if you hook in the new ID stuff
> there as well, since it's so little platform code, and a logical place to
> have it in.

I agree.

Regards,
Maxime

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Jamie Iles]

On Wed, Mar 02, 2011 at 11:36:38AM +0100, Linus Walleij wrote:
> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
> <maxime.coquelin-nonst@stericsson.com> wrote:
> 
> > I think we should have a tree like this :
> >
> > /sys/devices/system/soc/
> > /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
> 
> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
> etc.
> 
> Should we say it's a hex string of 64 bits?

Could we provide hooks for the platform that takes the buffer and length 
and let the platform do the snprintf()?  Our devices have a 128-bit 
serial number and I'm sure there must be others.

> > /sys/devices/system/soc/mach/
> > /sys/devices/system/soc/mach/name<- Name of the mach
> > /sys/devices/system/soc/mach/foo_id
> > /sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs
> > to export (IDCODE for OMAP, Production ID...)

Do we need a way to allow platforms to specify additional attributes to 
co into the socinfo?  For our devices we can boot in different modes and 
how we boot determines how the firmware is upgraded.  In the case above 
the platform could specify that it needs foo_id and bar_id and the 
callbacks to fill them in.

Jamie

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

On 03/02/2011 12:38 PM, Jamie Iles wrote:
> On Wed, Mar 02, 2011 at 11:36:38AM +0100, Linus Walleij wrote:
>> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
>> <maxime.coquelin-nonst@stericsson.com>  wrote:
>>
>>> I think we should have a tree like this :
>>>
>>> /sys/devices/system/soc/
>>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
>> etc.
>>
>> Should we say it's a hex string of 64 bits?
> Could we provide hooks for the platform that takes the buffer and length
> and let the platform do the snprintf()?  Our devices have a 128-bit
> serial number and I'm sure there must be others.

This is one possibility, another one is to let the platform specify how 
it exports this serial, as you proposed bellow.

>>> /sys/devices/system/soc/mach/
>>> /sys/devices/system/soc/mach/name<- Name of the mach
>>> /sys/devices/system/soc/mach/foo_id
>>> /sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs
>>> to export (IDCODE for OMAP, Production ID...)
> Do we need a way to allow platforms to specify additional attributes to
> co into the socinfo?  For our devices we can boot in different modes and
> how we boot determines how the firmware is upgraded.  In the case above
> the platform could specify that it needs foo_id and bar_id and the
> callbacks to fill them in.

Yes it was what I thought with the foo and bar IDs exports.

Maxime

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Linus Walleij]

2011/3/2 Jamie Iles <jamie@jamieiles.com>:

>> > /sys/devices/system/soc/
>> > /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
>>
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
>> etc.
>>
>> Should we say it's a hex string of 64 bits?
>
> Could we provide hooks for the platform that takes the buffer and length
> and let the platform do the snprintf()?  Our devices have a 128-bit
> serial number and I'm sure there must be others.

Isn't it better to just make it 64-bit so that apps can always parse it,
and then you can have your high-res numbers under mach?

If there is no solid ABI for this there is no point to make it
generic under /soc/unique_id at all.

/soc/name is another useful thing to have I think.

Apart from this we are now en route to the same color of
bikeshed discussion this patchset saw earlier, Maxime please
just implement something that works for you/us so others
can patch in whatever they need on top later.

Yours,
Linus Walleij

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Jamie Iles]

On Wed, Mar 02, 2011 at 03:42:33PM +0100, Linus Walleij wrote:
> 2011/3/2 Jamie Iles <jamie@jamieiles.com>:
> 
> >> > /sys/devices/system/soc/
> >> > /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
> >>
> >> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
> >> etc.
> >>
> >> Should we say it's a hex string of 64 bits?
> >
> > Could we provide hooks for the platform that takes the buffer and length
> > and let the platform do the snprintf()?  Our devices have a 128-bit
> > serial number and I'm sure there must be others.
> 
> Isn't it better to just make it 64-bit so that apps can always parse it,
> and then you can have your high-res numbers under mach?
> 
> If there is no solid ABI for this there is no point to make it
> generic under /soc/unique_id at all.

I guess I'd argue that a arbitrary length hex string could be considered 
as a solid ABI but you're right that it's probably more important to get 
something out there and I'm probably being too picky, so apologies!

Jamie

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 09:50 PM, Maxime Coquelin wrote:
> On 03/02/2011 04:54 AM, Ryan Mallon wrote:
>> On 03/02/2011 04:46 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>>>> The only real objection I have to adding the SoC family information is
>>>> basically to discourage it being abused by userspace. I can see it
>>>> being
>>>> useful in debug situations, but I can also see stupid userspace
>>>> applications explicitly testing for some particular SoC, rather than
>>>> more correctly (IMHO) checking for presence of certain drivers etc.
>>> True, but so many other things could be misused by stupid userspace
>>> programs. When there are legitimate usecases, I think we shouldn't
>>> prevent them just because we think a stupid userspace program could
>>> misuse it.
>>>
>>> Again, although you might not be gung-ho about this, I think I have at
>>> least made you indifferent/mildly supportive to adding socinfo. If you
>>> don't mind, I would like to wait for others to chime in before
>>> continuing this discussion.
>> Agreed.
>>
>> In general I am in support of having the SoC information exposed
>> somewhere. I think we just want to be careful that it doesn't become a
>> dumping ground for anything and everything SoC related whether the
>> information is useful or not. I think each piece of exposed information
>> should have a genuine use case, not just "because we can".
> I definitely agree we should not export every SoC-related information
> just because we can do it.
> The first goal of this interface was to export some SoCs IDs, as we need
> this kind of information for some user-space tools.
> Does someone need to export other information than the mach name and
> some IDs?
> 
> As proposed in my previous mail, do you agree to have a unified file for
> all vendors, which exports the unique silicon ID of the chip?

As mentioned earlier, on ep93xx we would like to export the Maverick
Crunch ID, which is a unique identifier for the chip.

I think the ABI should specify a minimum set of values which are
guaranteed to be provided on all SoCs, but allow individual SoCs to
provide additional information as necessary.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/02/2011 02:53 AM, Maxime Coquelin wrote:
> On 03/02/2011 11:36 AM, Linus Walleij wrote:
>> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
>> <maxime.coquelin-nonst@stericsson.com> wrote:
>>
>>> I think we should have a tree like this :
>>>
>>> /sys/devices/system/soc/
>>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for
>>> all machs
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have
>> 32-bit
>> etc.
>
> Yes, here is the difficulty. For example, in our case, the SoC unique ID
> is 160 bits long.
> Maybe it would be a better solution to get rid of this unified file, and
> keep only mach specific entries? I mean :
>
> /sys/devices/system/soc/
> /sys/devices/system/soc/mach_name
> /sys/devices/system/soc/foo_id
> /sys/devices/system/soc/bar_id

Sorry for the late reply guys. Got wrapped up is some other stuff.

I'm with Maxime on getting rid of the unique id file. It's not as if 
it's unique across all machs and archs. Any user space caring to look at 
the id will anyway have to check the mach/family first. So, there is no 
point in having this unique id file. It just adds more weirdness and 
complexity to deal with the different formats or ways each family wants 
to export the id. Actually, in the case of MSM, we don't have any need 
to export unique id. We just want to export what type of soc it is 
within the MSM family.

As for the path, it's not clear we have settled on the final path. I see 
us ping-pong between /sys/devices/system/soc/ and 
/sys/devices/system/soc/mach/. Can we drop the "mach" subdir? Seems 
pointless.

The mandatory file, I would like to call it "family", since "mach" is 
too specific (omap3 and omap4 is my usual example -- they can have one 
implementation of socinfo and report the family as "omap"). We don't 
want people to misunderstand "mach" to be an accurate representation of 
the xxxx in mach-xxxx.

The patch that adds this should probably allow each socinfo 
implementation to specify the family name and an array of attributes 
(struct attribute *) that can be used to expose whatever else they want 
to export.

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.