Will do.One solution that I like is to write a module with the common code as* When I talk about a bus, I mean 'struct bus_type', which identifiesCorrect, I refer to the device, not type or driver. I used a bus type
all devices with a uniform bus interface to their parent device
(think: PCI, USB, I2C). You seem to think of a bus as a specific
instance of that bus type, i.e. the device that is the parent of
all the connected devices. If you have only one instance of a bus
in any system, and they are all using the same driver, do not add
a bus_type for it.
A good reason to add a bus_type would be e.g. if the "display"
driver uses interfaces to the dss that are common among multiple
dss drivers from different vendors, but the actual display drivers
are identical. This does not seem to be the case.
since it allowed me to setup a default implementation for each driver
callback. So all drivers get generic implementation by default, and
override when that is not enough. Meybe you have a better way of getting
the same behavior.
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.
I will look at it, we might still post a fb->mcde_hw first though, since it's so little work.
We are now taking a step back and start "all over". We were almost asOk, sounds great! I'm also starting a 3 week vacation, but will be at the
fresh on this HW block as you are now when we started implementing the
driver earlier this year. I think all of us benefit from now having a
better understanding of customer requirements and the HW itself, there
are some nice quirks ;). Anyway, we will restart the patches and RFC
only the MCDE HW part of the driver, implementing basic fb support for
one display board as you suggested initially. It's a nice step towards
making the patches easier to review and give us some time to prepare the
DSS stuff. That remake was done today, so I think the patch will be sent
out soon. (I'm going on vacation for 3 weeks btw).
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.
DSS does not have a static dependency on display drivers. DSS is just a "convenience library" for handling the correct display driver call sequences, instead of each user (fbdev/KMS/V4L2) having to duplicate this code.
I don't think it makes any sense to have the DSS sit on top of theHmm, mcde_hw does not link to dss. It should be FB->DSS->DisplayDSS give access to all display devices probed on the virtual mcdeThe way you describe it, I would picture it differently:
dss bus, or platform bus with specific type of devices if you like.
All calls to DSS operate on a display device, like create an
overlay(=framebuffer), request an update, set power mode, etc.
All calls to DSS related to display itself and not only framebuffer
scanout, will be passed on to the display driver of the display
device in question. All calls DSS only related to overlays, like
buffer pointers, position, rotation etc is handled directly by DSS
calling mcde_hw.
You could see mcde_hw as a physical level driver and mcde_dss closer
to a logical driver, delegating display specific decisions to the
display driver. Another analogy is mcde_hw is host driver and display
drivers are client device drivers. And DSS is a collection of logic
to manage the interaction between host and client devices.
+----------+ +----+-----+-----+ +-------+
| mcde_hw | | fb | kms | v4l | | displ |
+----+----------------------------------+
| HW | mcde_dss |
+----+----------------------------------+
In this model, the dss is the core module that everything else
links to. The hw driver talks to the actual hardware and to the
dss. The three front-ends only talk to the dss, but not to the
individual display drivers or to the hw code directly (i.e. they
don't use their exported symbols or internal data structures.
The display drivers only talk to the dss, but not to the front-ends
or the hw drivers.
Would this be a correct representation of your modules?
driver->MCDE_HW->HW IO (+ DSS->MCDE_HW). My picture is how code should
be used. Anything else you find in code is a violation of that layering.
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 andThey are the same module, just split into two files.
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.
I see this as a side effect of DRM putting a dependency between 3D HW and KMS HW driver. In most embedded systems, these two are no more coupled than any other HW block on the SoC. So by "fixing" this _possible_ flaw. I see no reason why a KMS driver can't stand on it's own. There's no reason not to support display in the kernel just because there's no 3D HW driver, right?
The other "issue" is the usual, 3D vendors don't upstream their drivers.This will be a lot tougher for you. External modules are generally
Which means we have to integrate with drivers not in mainline kernel ...
and we still want to open all our drivers, even if some external IPs
don't.
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 ;-)
Sure, but that is currently up to board init code. Just as for frame buffers, mcde_fb_create(display, ...), we will have a "createV4L2device(display, ...)".
Ok, I'm starting to remember this from the 90's when I used bttv on theSorry, camera _application_ use V4L2 overlays for pushing YUV cameraI still don't understand, sorry for being slow. Why does a cameraWhat does the v4l2 driver do? In my simple world, displays are forCurrently nothing, since it is not finished. But the idea (and
output
and v4l is for input, so I must have missed something here.
requirement) is that normal graphics will use framebuffer and
video/camera overlays will use v4l2 overlays. Both using same
mcde channel and display. Some users might also configure their
board to use two framebuffers instead. Or maybe only use KMS etc ...
use a display?
preview or video buffers to screen composition in MCDE. V4L2 have output
devices too, it's not only for capturing, even if that is what most
desktops use it for.
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.