Thanks for writing it!
Reviewed-by: Corbin Simpson <mostawesomed...@gmail.com>
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 10:39 AM, "Tormod Volden" <lists.tor...@gmail.com> wrote:
> On Sun, Nov 6, 2011 at 4:37 PM, Corbin Simpson
> <mostawesomed...@gmail.com> wrote:
> > Trusting the spec worries me; could this break anybody?
>
> It will allow the user to override possibly safer default settings. If
> a user has specified, say, 2x in his xorg.conf and this was not
> honored because the card only reported 4x, this patch would finally
> give him the 2x he is asking for. If 2x turns out to not work, he will
> suddenly have problems. But the solution would be to fix his
> xorg.conf. Up till now he might be thinking 2x works fine, while he
> was actually getting another rate.
>
> Generally, the default rate is defined by the DDX and the patch does
> not change these policies. However, with the patch we may actually
> apply the default value, instead of an undefined "0x" (i.e. the case
> when the DDX sets 1x or 2x by default, but the card says only 4x). The
> spec (I have checked section 6.1.10) does not say anything about
> writing a zero rate, and I don't know what the silicon does. I don't
> know of any way to read out the resulting speed. Is there any simple
> agp benchmarking tools?
>
> Of course, it would be good if more people who currently see "0x" in
> dmesg would try this patch.
>
> Note that Dave Jones did the same for bridges in
> 28af24bb8470c7d0573b703a2955548b73a6c066 to get rid of "0x" cases.
>
> >
> > Is there any reason to use the not-so-magic numbers instead of the named
> > constants?
>
> I followed the style of the surrounding code. I can follow up with a
> patch using named constants everywhere if that would be desired.
>
> Thanks for looking at it!
> Tormod
>
>
> >
> > Sending from a mobile, pardon my terseness. ~ C.
> >
> > On Nov 6, 2011 7:03 AM, "Tormod Volden" <lists.tor...@gmail.com> wrote:
> >>
> >> From: Tormod Volden <debian.tor...@gmail.com>
> >>
> >> Some cards report that they support only 4x, in which case they
> >> should support 2x and 1x as well, according to the AGP spec.
> >>
> >> Otherwise a requested 1x or 2x rate will result in 0 being set:
> >>
> >> agpgart-via 0000:00:00.0: putting AGP V2 device into 0x mode
> >>
> >> For instance ProSavage KN133 [5333:8d02] only reports 4x.
> >>
> >> Signed-off-by: Tormod Volden <debian.tor...@gmail.com>
> >> ---
> >> drivers/char/agp/generic.c | 18 ++++++++++++++++++
> >> 1 files changed, 18 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
> >> index b072648..c5d04e5 100644
> >> --- a/drivers/char/agp/generic.c
> >> +++ b/drivers/char/agp/generic.c
> >> @@ -526,6 +526,24 @@ static void agp_v2_parse_one(u32 *requested_mode,
> u32
> >> *bridge_agpstat, u32 *vga_
> >> break;
> >> }
> >>
> >> + /* Some graphic cards report they only support 4x, however the
> AGP
> >> 2.0 spec
> >> + * (section 4.1.1) says components must support the lower speeds
> >> as well.
> >> + */
> >> + switch (*vga_agpstat & 7) {
> >> + case 4:
> >> + *vga_agpstat |= (AGPSTAT2_2X | AGPSTAT2_1X);
> >> + printk(KERN_INFO PFX "Graphics card claims to only
> support
> >> x4 rate. "
> >> + "Fixing up support for x2 & x1\n");
> >> + break;
> >> + case 2:
> >> + *vga_agpstat |= AGPSTAT2_1X;
> >> + printk(KERN_INFO PFX "Graphics card claims to only
> support
> >> x2 rate. "
> >> + "Fixing up support for x1\n");
> >> + break;
> >> + default:
> >> + break;
> >> + }
> >> +
> >> /* Check the speed bits make sense. Only one should be set. */
> >> tmp = *requested_mode & 7;
> >> switch (tmp) {
> >> --
> >> 1.7.5.4
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
