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 [email protected] <[email protected]> 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.
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
[email protected] 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
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.
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
[email protected] 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
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.
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
[email protected] 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