[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
skannan at codeaurora.org
Tue Mar 1 20:19:12 EST 2011
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:
>> 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
>>> 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.
>> 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).
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
More information about the linux-arm-kernel