On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote: > Hi Tomi, > > On 2/28/2011 8:19 AM, Valkeinen, Tomi wrote: > > On Mon, 2011-02-28 at 01:09 -0600, Taneja, Archit wrote: > >> Hi, > >> > >> On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote: > >>> On Thu, 2011-02-24 at 03:27 -0600, Tomi Valkeinen wrote: > >>>> Hi, > >>>> > >>>> On Mon, 2011-01-24 at 11:51 +0530, ext Sumit Semwal wrote: > >>>>> From: Senthilvadivu Guruswamy<svadivu@xxxxxx> > >>>>> > >>>>> Change the driver name from omapdss to omap_display as the driver takes care of > >>>>> the display devices ie number of panels, type of panels available in the > >>>>> platform. Change the device name in the board files and 2420,2430,3xxx clock > >>>>> files from omapdss to omap_display to match the driver name. > >>>> > >>>> I just realized that changing the driver name will break all scripts and > >>>> applications using omapdss sysfs files. > >>>> > >>>> How does this sound: > >>>> > >>>> Let's leave the omapdss device name as it is. It represents a "super" > >>>> device, containing the dss sysfs files and upper level dss management. > > This is the case for all the drivers migrated to omap_device anyway due > to the change in the top level hierarchy. Everything is below > platform/omap now. The HW module drivers are under platform/omap/, but omapdss is in platform/. Do you mean that omapdss should also be under platform/omap/? The reason I'm unwilling to change omapdss name, or location, is that omapdss directory contains lots of DSS configuration files, used by scripts and programs. > That's why we are using that opportunity to clean and provide a > consistent naming for all devices. > > >>>> Name the HW module platform drivers as: omapdss_dss, omapdss_venc, > >>>> omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, > >>>> and would also prevent any possible name conflict if there would happen > >>>> to be a, say, "dsi" block in some other HW component. > > Cannot you use a device hierarchy then to do that? > omap_dss/core > omap_dss/dsi > omap_dss/venc > > This is moreover the way the HW is done. Hmm, how would that work? The devices are platform devices, and they have a unique global name, which is used to match the driver for the device. > > >>> Any comments on this? > >> > >> I also think we need to stick to the older name, "omapdss_dss" sounds a > >> bit confusing, and I think one of the previous versions had something > >> like "dss_dss" in it and it wasn't approved. Does something like > >> "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading? > > > > It is confusing, but so is the hardware naming =). There is a DSS module > > inside the omap display subsystem. That's why I would like to name it > > "dss", not "core", so it's clear it refers to this DSS module. > > > > "dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly > > better in the sense that it doesn't repeat the same "dss", and there is > > an "omapdss" device, which acts like "manager" for these module devices. > > But yes, I wouldn't call it perfect either. > > > > "omapdss_dss_core" is one option. But then again, TRM doesn't speak of > > "core". > > We should not maintain silly names just because they are in the TRM, we > should just fix the TRM. This is exactly what we are going to do for > most HW names we introduced in OMAP4. > > So if we all agree that this name will avoid confusion and is much > better than the current one, we can change it right now with a comment > to explain the change and give the pointer to the current TRM naming. True. But I don't think there's a huge difference with omapdss_dss or omapdss_core. The name is used in only a few places inside the kernel, and never from userspace, so we can change that also later. The main issue I had was changing the omapdss device name, which would break the userspace. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html