[PATCHES] radeon drm kms i2c fixes

[PATCHES] radeon drm kms i2c fixes

[Alex Deucher]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

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).
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.  I've tested on
several radeons, but more tested would be nice.

Alex

[-- Attachment #2: 0001-i2c-algo-bit-Add-pre-and-post-xfer-hooks.patch --]
[-- Type: application/mbox, Size: 1847 bytes --]

[-- Attachment #3: 0002-drm-radeon-kms-use-new-pre-post_xfer-i2c-bit-algo-h.patch --]
[-- Type: application/mbox, Size: 9604 bytes --]

[-- Attachment #4: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
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

[-- Attachment #5: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCHES] radeon drm kms i2c fixes

[Jean Delvare]

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.

> 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'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.

-- 
Jean Delvare

------------------------------------------------------------------------------
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
--

Re: [PATCHES] radeon drm kms i2c fixes

[Alex Deucher]

On Thu, Mar 11, 2010 at 1:00 PM, Jean Delvare <khali@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&#174; 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
--

Re: [PATCHES] radeon drm kms i2c fixes

[Alex Deucher]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

On Wed, Mar 10, 2010 at 7:09 PM, Alex Deucher <alexdeucher@gmail.com> 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).
> 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.  I've tested on
> several radeons, but more tested would be nice.

Updated patch based on Jean's new version of the pre/post_xfer patch
(also attached) which he plans to push upstream via the i2c tree.

Alex

[-- Attachment #2: 0001-i2c-algo-bit-Add-pre-and-post-xfer-hooks.patch --]
[-- Type: application/mbox, Size: 1864 bytes --]

[-- Attachment #3: 0002-drm-radeon-kms-use-new-pre-post_xfer-i2c-bit-algo-h.patch --]
[-- Type: application/mbox, Size: 9566 bytes --]

[-- Attachment #4: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; 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

[-- Attachment #5: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCHES] radeon drm kms i2c fixes

[Jean Delvare]

On Sun, 14 Mar 2010 11:37:02 -0500, Alex Deucher wrote:
> On Wed, Mar 10, 2010 at 7:09 PM, Alex Deucher <alexdeucher@gmail.com> 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).
> > 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.  I've tested on
> > several radeons, but more tested would be nice.
> 
> Updated patch based on Jean's new version of the pre/post_xfer patch
> (also attached) which he plans to push upstream via the i2c tree.

FYI, the pre/post-xfer patch is upstream now:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0a9c14751377a1407f5e35791e13651d2fc7801c

-- 
Jean Delvare

------------------------------------------------------------------------------
Download Intel&#174; 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

Re: [PATCHES] radeon drm kms i2c fixes

[Jean Delvare]

On Thu, 11 Mar 2010 13:35:47 -0500, Alex Deucher wrote:
> On Thu, Mar 11, 2010 at 1:00 PM, Jean Delvare <khali@linux-fr.org> wrote:
> > 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

Huuu, looks a little too time consuming, I'm afraid. Anything requiring
rebuilding Xorg isn't an option for me. I'm running openSUSE 11.1, it
has Xorg 7.4, I guess it's too old... And openSUSE 11.2 has Xorg 7.4
too, I don't think is is KMS-enabled, so I guess upgrading won't help.
I will probably have to wait for openSUSE 11.3 before I can do any
testing, sorry.

-- 
Jean Delvare

------------------------------------------------------------------------------
Download Intel&#174; 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
--

Re: [PATCHES] radeon drm kms i2c fixes

[Johannes Engel]

AFAIK recompiling the Xorg driver should be enough in openSUSE 11.2.

Cheers, Johannes

2010/3/15 Jean Delvare <khali@linux-fr.org>:
> On Thu, 11 Mar 2010 13:35:47 -0500, Alex Deucher wrote:
>> On Thu, Mar 11, 2010 at 1:00 PM, Jean Delvare <khali@linux-fr.org> wrote:
>> > 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
>
> Huuu, looks a little too time consuming, I'm afraid. Anything requiring
> rebuilding Xorg isn't an option for me. I'm running openSUSE 11.1, it
> has Xorg 7.4, I guess it's too old... And openSUSE 11.2 has Xorg 7.4
> too, I don't think is is KMS-enabled, so I guess upgrading won't help.
> I will probably have to wait for openSUSE 11.3 before I can do any
> testing, sorry.
>
> --
> Jean Delvare
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>

------------------------------------------------------------------------------
Download Intel&#174; 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