Sanjeev, > -----Original Message----- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev > Sent: Wednesday, October 14, 2009 3:26 AM > To: Kevin Hilman; Menon, Nishanth > Cc: linux-omap@vger.kernel.org > Subject: RE: FEATURES prints > > > > -----Original Message----- > > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > > Sent: Wednesday, October 14, 2009 3:17 AM > > To: Menon, Nishanth > > Cc: Premi, Sanjeev; linux-omap@vger.kernel.org > > Subject: Re: FEATURES prints > > > > Nishanth Menon <n...@ti.com> writes: > > > > > Folks, > > > > > > With the addition of FEATURES in l-o, the following prints: > > > - l2cache : Y > > > - iva : Y > > > - sgx : Y > > > - neon : Y > > > - isp : Y > > > > > > comes up on SDP3430 -> now that we will introduce half a dozen > > > features here and there, we will soon clutter this up. we should > > > introduce a sysfs entry + remove the above noise.. > > > > > > > Like Nishanth, I don't like the multi-line noise here. The patch > > below results in a single line output like this instead > > > > OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp ) > > > > Not sure why we need to dump features that are not there, but if that > > s considered important, maybe prefixing each feature with a '+' or '-' > > would still allow this to be collapsed into a single line. > > > > Even with this, I think adding the display of these features into an > > OMAP-specific section of /proc/cpuinfo would be even better. > > > > [sp] Single line prints look good. We can also add details in cpuinfo.
If you are ok with proc entry then we don't even need this noise at all in the boot. It's just that adding proc entries is discouraged to some extent. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
