On Thursday 16 December 2010 19:26:37 Marcus Lorentzon wrote:
Much better now, just remember to leave empty lines around your replies
and to trim the lines that you are not replying to.
One solution that I like is to write a module with the common code as
a library, exporting all the default actions. The specific drivers
can then fill their operations structure by listing the defaults
or by providing their own functions to replace them, which in turn
can call the default functions. This is e.g. what libata does.
Fair enough. We will have to fix it some day so Greg can go on with
his plan to disallow static devices, but for now I'm not going to
stop you. I would use platform_device_register_simple anyway, but feel
free to do whatever fits your need here.
Ok, sounds great! I'm also starting a 3 week vacation, but will be at the
Linaro sprint in Dallas.
My feeling now, after understanding about it some more, is that it would
actually be better to start with a KMS implementation instead of a classic
frame buffer. Ideally you wouldn't even need the frame buffer driver or
the multiplexing between the two then, but still get all the benefits
from the new KMS infrastructure.
Ok, cool!
I don't think it makes any sense to have the DSS sit on top of the
display drivers, since that means it has to know about all of them
and loading the DSS module would implicitly have to load all the
display modules below it, even for the displays that are not present.
Moreover, I don't yet see the reason for the split between mcde_hw and
dss. If dss is the only user of the hardware module (aside from stuff
using dss), and dss is written against the hw module as a low-level
implementation, they can simply be the same module.
Ok. I'd have to look into this in more detail myself to see how
severe this is, or how to solve it. The problem seems obvious
enough that you should see no resistance to a patch for this.
This will be a lot tougher for you. External modules are generally
not accepted as a reason for designing code one way vs. another.
Whatever the solution is, you have to convince people that it would
still make sense if all drivers were part of the kernel itself.
Bonus points to you if you define it in a way that forces the 3d driver
people to put their code under the GPL in order to work with yours ;-)
I have no idea what this means, but I trust that you and others
can come up with a solution.
Remember that with ioctls, you can always add new ones if you need
them, though you cannot remove or change them in incompatible ways.
If you need the ioctl commands to do something they can't do today,
try defining new commands in a way that will also work with future
extensions without making the interface more complex than what you
need to do. It takes some experience to get this right and the first
versions will probably get rejected, but that doesn't mean people
are opposed to extending the interface.
Yes.
It can change at runtime in theory, but that's highly discouraged
because it tends to break user space programs working with the
path names.
Using a flatter structure indeed sounds better in that case,
showing only the displays.
It still sounds to me like it only needs to be one device for
the display then. The device can have properties for the wires and
for the settings, but since it's a one-to-one relationship, I would
represent it as a single object in the device tree.
There is a problem in the object life time rules if you instantiate
all the devices at boot time: It means that the devices lower in the
hierarchy can get used before the parent devices are fully initialized.
You can do the main mcde device as a static platform device if you
insist, but registering a hierarchy of static platform devices
is asking for trouble.
Ok, makes sense.
I see. This needs to be solved more generally though, since everyone
has the same requirements. If we conclude that we should do everything
with KMS infrastructure, we should also make sure that it works
for all the relevant users. That might be something worth discussing
in the Linaro graphics workgroup as well.
Ok, I'm starting to remember this from the 90's when I used bttv on the
console framebuffer ;-).
Could you simply define a v4l overlay device for every display device,
even if you might not want to use it?
That might simplify the setup considerably.
Arnd
--
