Thread (38 messages) 38 messages, 10 authors, 2011-03-03

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

From: Maxime Coquelin <hidden>
Date: 2011-03-02 08:23:03
Also in: linux-arm-msm, linux-omap

On 03/02/2011 03:55 AM, Saravana Kannan wrote:
On 03/01/2011 06:41 PM, Ryan Mallon wrote:
quoted
On 03/02/2011 03:23 PM, Saravana Kannan wrote:
quoted
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?
quoted
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 at nokia.com[off-list ref]  since I
keep getting delivery failure emails.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help