On 2/28/2011 3:57 PM, Valkeinen, Tomi wrote:
On Mon, 2011-02-28 at 08:00 -0600, Cousson, Benoit wrote:
On 2/28/2011 1:10 PM, Valkeinen, Tomi wrote:
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/?
This is because you are probably not using omap_device yet. is should
happen when you will change your platform_device to be omap_device.
Hmm. The HW module devices use omap_device. But we have also a
"management" device, omapdss, which is doesn't match directly to any HW
component but manages the HW module drivers. It contains, so to say, the
HW module drivers.
OK, so you will have two different paths. omapdss will be directly below
platform whereas all the omap_device based DSS IPs will be below
platform/omap.
Should this device also be a omap_device? What does omap_device actually
represent? My understanding is that omap_device is a linux device for a
HW block inside OMAP. omapdss doesn't quite match that definition.
Yep, in that case you do not need an omap_device since you do not have
any hwmod to map to.
The only weird thing is the different root paths you will have for the
various devices. But it looks like the only one you have to expose is
the omapdss.
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.
Is that used for debug only?
Unfortunately no. DSS contains many features which cannot be exported to
userspace via the framebuffer device. While I'm not really happy with
the current omapdss sysfs interface, it's the best we've come up with.
OK, then, something you will be able to fix in the DSS3:-)
Benoit
--
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
