On 12/17/2010 12:22 PM, Arnd Bergmann wrote: >>> * When I talk about a bus, I mean 'struct bus_type', which identifies >>> 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. >>> >>> >> Correct, I refer to the device, not type or driver. I used a bus type >> 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. >> > 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. > > Will do. > >> We are now taking a step back and start "all over". We were almost as >> 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). >> > 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. > > I will look at it, we might still post a fb->mcde_hw first though, since it's so little work. > >>>> DSS give access to all display devices probed on the virtual mcde >>>> 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. >>>> >>>> >>> The way you describe it, I would picture it differently: >>> >>> +----------+ +----+-----+-----+ +-------+ >>> | 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? >>> >>> >> Hmm, mcde_hw does not link to dss. It should be FB->DSS->Display >> 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. >> > 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. > > 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.
> 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. > > They are the same module, just split into two files. > >> The other "issue" is the usual, 3D vendors don't upstream their drivers. >> 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. >> > 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 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? > >>>>> What does the v4l2 driver do? In my simple world, displays are for >>>>> output >>>>> and v4l is for input, so I must have missed something here. >>>>> >>>>> >>>> Currently nothing, since it is not finished. But the idea (and >>>> 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 ... >>>> >>>> >>> I still don't understand, sorry for being slow. Why does a camera >>> use a display? >>> >>> >> Sorry, camera _application_ use V4L2 overlays for pushing YUV camera >> 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. >> > 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. > 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, ...)". /BR /Marcus
