linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: Sven Luther <luther@dpt-info.u-strasbg.fr>,
	Fredrik Noring <noring@nocrew.org>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Vertical retrace interrupts?
Date: 02 Feb 2003 00:50:10 +0800	[thread overview]
Message-ID: <1044118163.3906.29.camel@localhost.localdomain> (raw)
In-Reply-To: <1044114349.4294.15.camel@thor>

On Sat, 2003-02-01 at 23:45, Michel Dänzer wrote:
[snip]
> > 
> > The fbdev driver will automatically load the DRM module when it refers
> > to any exportable symbol of DRM.  We can also make the fbdev drivers
> > specifically depend on DRM in Kconfig so users don't accidentally
> > compile fbdev without its DRM counterpart.
> 
> I wonder if people will like having to build the DRM for a framebuffer
> device... a solution where one component uses the other if it's there,
> but works without it otherwise, might be better.
> 
Yes, your suggestion is better.  I did browse the dri code, and my
feeling is drm is coded for userspace clients without any usable hooks
for clients residing in kernel space. I'm still wondering how to access
DRM services from kernel space.  

> > The aim is not to avoid code duplication, although that is a plus, it's
> > two independent handlers clashing and locking up the machine.
> 
> I'm not sure it would be that bad, but certainly suboptimal. :)
> 

It will be bad.  The handler that gets loaded first will receive the
interrupt signal first.  It will, by necessity, clear the registers of
the event it's watching for to reenable the interrupt.  So when it's the
second handler's turn, and if it is also watching for the same event,
then it will falsely assume that the event never happened.  At worst,
the second handler will wait indefinitely for an event that will never
arrive, at best it will time out and send false information.

> 
> > > Could it not be that the fbdev sort of minimally intialize the DRM when
> > > it is not already active ? After all, the fbdev knows as much, if not
> > > more, than the X driver about the graphic chips state, especially if the
> > > X driver is using the fbdev.
> > 
> > I was wondering about this to.  How much initialization is required?  Is
> > it not enough to just load the DRM module?
> 
> No. The DRM_INST_HANDLER ioctl needs to be called to make the IRQs work,
> and I suspect more needs to be done before that.
> 

Yes, I also realized that.  My feeling is if James or Geert do agree to
add support for this, fbdev will just have to duplicate the code, taking
care that another handler may exist, or DRM will be rewritten so the
interrupt handling can be shared or made available to other modules, as
you suggested.

> > Also, we have fbdev drivers that are incompatible with DRM, so having
> > fbdev load DRM is like telling it to commit suicide :-)
> 
> Out of curiosity, is that about i8xx?
> 

No, the i810fb driver is compatible with X and DRM.  

Tony




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

  reply	other threads:[~2003-02-01 17:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-26  1:51 Vertical retrace interrupts? Fredrik Noring
2003-01-28 19:21 ` James Simmons
2003-01-30  2:34   ` Antonino Daplas
2003-01-30 11:45     ` Michel Dänzer
2003-01-30 23:22       ` Antonino Daplas
2003-01-31  0:16         ` Fredrik Noring
2003-01-31  1:35           ` Antonino Daplas
2003-01-31 11:24         ` Michel Dänzer
2003-01-31 11:55           ` Ville Syrjälä
2003-01-31 18:35           ` Antonino Daplas
2003-01-31 19:12             ` Michel Dänzer
2003-01-31 21:32               ` Sven Luther
2003-01-31 23:34                 ` Antonino Daplas
2003-02-01 15:45                   ` Michel Dänzer
2003-02-01 16:50                     ` Antonino Daplas [this message]
2003-02-12 20:21                       ` James Simmons
2003-02-12 20:08       ` James Simmons

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1044118163.3906.29.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=luther@dpt-info.u-strasbg.fr \
    --cc=michel@daenzer.net \
    --cc=noring@nocrew.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).