On Thu, Mar 11, 2010 at 1:00 PM, Jean Delvare <kh...@linux-fr.org> wrote: > Hi Alex, > > On Wed, 10 Mar 2010 19:09:08 -0500, Alex Deucher wrote: >> Thanks to Jean for helping me with the i2c stuff. I've attached >> Jean's bit algo patch as my radeon patch depends on it. I'm not sure >> how we want to get that one upstream (either via drm or i2c). > > i2c tree probably. I think I can push it to Linus quickly, it's a small > one, can't cause a regression, and rc2 isn't out yet. >
Excellent. thanks. >> Previously, the radeon drm registered i2c buses using the radeon algo >> which would use either the hw i2c engine or bit banging depending on >> the bus in question (some are hw capable, others are not, some chips >> don't have support for their hw engines yet, etc.). The tricky part >> was that the radeon i2c bit buses require some gpio magic before and >> after a transaction which bit algo didn't previously support. >> Unfortunately, it exposed the internal bit algo bus as well we as the >> radeon algo bus which is bad. With these patches, if the hw engine is >> supported, we use the radeon algo, if not, we use bit algo directly >> with the pre/post_xfer functions to fix up the gpios. > > Looks good. I have one suggestion of possible improvement for the > future. You could turn rec->hw_capable into a function pointer, > pointing to the appropriate r*_hw_i2c_xfer() function. This would be > more efficient that looking up the right function each time > radeon_hw_i2c_xfer() is called. This would also avoid checking the chip > model at registration time, to decide between hardware and software > implementation, as these tests could easily go out of sync with what > is actually implemented, when you add support for newer chips. > I was actually thinking of doing something similar. Adding a hw_i2c_xfer callback to the radeon asic struct and checking that. I just haven't gotten around to it yet. >> I've tested on several radeons, but more tested would be nice. > > I have the following in my machine: > 02:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] > (rev 01) > 02:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] > (Secondary) (rev 01) > > Can I help with testing? I can follow your instructions. Sure. You need a kms-enabled graphics stack. See this for more: http://wiki.x.org/wiki/radeonBuildHowTo Then, make sure you have the latest kernel bits and the patches I posted. Note that some users have reported problems with the hw i2c engine on some r1xx-r3xx boards. I suspect a problematic prescale or a drive problem. If you run into issues, please try the patch I attached to this bug: http://bugs.freedesktop.org/show_bug.cgi?id=26430 Alex ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
