lkml.org 
[lkml]   [2006]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: OpenGL-based framebuffer concepts
    Date
    On Sunday 28 May 2006 03:27, Jon Smirl wrote:
    > On 5/27/06, D. Hazelton <dhazelton@enter.net> wrote:
    > > > > Fully merging fbdev with DRM would really create some problems for
    > > > > the embedded people. If the design of using the fbdev driver as a
    > > > > base layer and the DRM drivers as an acceleration layer works then
    > > > > that's all that's truly needed. Merging the DRM and fbdev code bases
    > > > > would create a situation where the embedded people would have to
    > > > > configure *out* the DRM code that has been merged into the fbdev
    > > > > drivers. Not only would such a thing create potential bugs in the
    > > > > system, it is a step that could create problems with people
    > > > > maintaining the .config's for those systems.
    > > >
    > > > It may cause problems for some embedded people but I wouldn't worry
    > > > about them right now. If they don't like something I'm sure we'll hear
    > > > from them. Most people don't go to the expense of putting a DRM
    > > > capable chip into a system and then not use all of its capabilities.
    > > > Remember, only 8 out of the 60 fbdev drivers have DRM modules.
    > > >
    > > > Worst thing that can happen is that they lose 50K of memory. Don't
    > > > spend a lot of effort worrying about this especially if no one is
    > > > complaining. Issues like this can be addressed later.
    > >
    > > Yes, however, I don't think a lot of embedded people are putting DRM
    > > capable chips in their machines. And I will worry about that at all
    > > points, to great length - I will actually fight to keep a complete merger
    > > from happening. For exactly the reasons I stated above.
    >
    > For a specific DRM chip there are currently four modules:
    > fbdev-core
    > fbdev-chip depends on fbdev-core
    > drm-core
    > drm-chip depends on drm-core
    > RIght now drm and fbdev can be loaded independently.
    >
    > I would always keep fbdev-core and drm-core as separate modules. But
    > drm-core may become dependent on fbdev-core.

    yeah, that could work. Have fbdev-core handle all PCI interactions and
    drm-core uses those functions.

    > So after merging, drivers without DRM would still load exactly what
    > they load today. They wouldn't need to load the dependent drm-core
    > module. These non-DRM modules are essentially unchanged.
    > fbdev-core
    > fbdev-chip depends on fbdev-core
    >
    > Merged DRM drivers can end up in one of two configurations
    > fbdev-core
    > fbdev-chip depends on fbdev-core
    > drm-core depends on fbdev-core
    > drm-chip depends on fbdev-chip, drm-core, fbdev-core

    Not exactly. drm-chip would depend on fbdev-chip and drm-core, which both
    depend on fbdev-core -- not a direct dependency. However, the layering model
    you present would likely keep the embedded people happy. Provided the
    drm-chip and fbdev-chip interfaces are kept seperate. Such a seperation need
    only hold true for the current generation of fbdev drivers. New drivers added
    at a later date could be unified drm/fbdev-chip modules or split, as the
    creator determines.

    > fbdev-core
    > drm-core depends on fbdev-core
    > merged-chip depends on drm-core, fbdev-core
    >
    > I'm saying don't worry too much if it is more efficient to create
    > merged-chip for somthing like the Radeon instead of keeping fbdev-chip
    > and drm-chip. It is more important to get a stable functioning driver
    > working. If someone really complains the driver can be broken back up
    > at a later date (they can always use the old fbdev driver in the
    > meanwhile). If you spend all of your time worrying about 10K of memory
    > for some embedded system that may or may not use the driver, you won't
    > be spending enough time on getting the basic driver right.

    Okay. That works. I wasn't going to worry about the embedded stuff, so much as
    try to keep a clean division of things so stuff the embedded people don't
    need isn't used.

    > In the new model you won't be able to load standalone DRM. That's
    > becuase both of those modules are now dependent on their fbdev counter
    > parts.
    > drm-core - standalone disallowed
    > drm-chip - standalone disallowed


    DRH
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-05-28 07:14    [W:4.717 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site