All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Antonino A. Daplas" <adaplas@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Dennis Munsie <dmunsie@cecropia.com>
Subject: Re: soliciting feedback/direction on DDC support
Date: Thu, 15 Jun 2006 05:44:50 +0800	[thread overview]
Message-ID: <44908352.9090704@gmail.com> (raw)
In-Reply-To: <12A94EEB-565A-4220-81B0-6A43EA732A14@cecropia.com>

Dennis Munsie wrote:
> hi everyone,
> 
> now that I have the I2C bus support in the intelfb driver, I would  
> like to use it for the reading the EDID block.  And actually, I've  
> tested it and it works just fine.
> 
> but... the way it does it is basically the same as the aty driver.   
> Which leads to an ugly mess of copy and pasting code from one driver  
> to another.  Not ideal at all.
> 
> So, I was thinking of making it generic and sticking it in fbmon.c  
> (or someplace similar).  But, to do it properly, I need to fiddle  
> with fields in the i2c_algo_bit_data struct.  Ideally, I would want  
> to make sure that the adapter that's passed in is using the i2c-algo- 
> bit algorithm.  But, to do this would require exposing functionality  
> from the i2c algorithm, which seems dirty.
> 
> Normally I wouldn't need to do this, but it looks like the aty code  
> was accommodating older monitors that might not have implemented  
> everything to spec.  And therefore, it looks like they took to do a  
> little bit banging themselves.
> 
> I've managed to make the aty functionality generic to a point -- it  
> doesn't fiddle the registers directly, but uses the routines defined  
> for that purpose -- but not as generic as I would ideally like.
> 
> At this point, I'll probably still separate out the functionality,  
> but I won't feel comfortable submitting it upstream until the issues  
> of being safe and completely generic are resolved.
> 
> I really don't want this functionality to drop on the floor or be  
> implemented directly (like the other drivers) in the intelfb driver,  
> so any feedback would be greatly appreciated.  It might just be that  
> I'm completely missing something here.

I don't see a problem making this generic.  For drivers such as radeonfb,
we can add addtional hooks such as

fb_ddc_pre_read() - hack before probing
fb_ddc_post_read() - hack after probing
fb_ddc_stop_read() - hack after everything is done

to accommodate the hacks.

Tony

  reply	other threads:[~2006-06-14 21:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-14 21:04 soliciting feedback/direction on DDC support Dennis Munsie
2006-06-14 21:44 ` Antonino A. Daplas [this message]
2006-06-15  0:30   ` Dennis Munsie
2006-06-17 17:29     ` Luca

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=44908352.9090704@gmail.com \
    --to=adaplas@gmail.com \
    --cc=dmunsie@cecropia.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.