[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 at 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.