[lkml]   [2011]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
    On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
    > On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
    > <> 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).


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

     \ /
      Last update: 2011-03-02 02:21    [W:0.026 / U:0.840 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site