From: Ian Romanick <idr@us.ibm.com>
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: fb-devel <linux-fbdev-devel@lists.sourceforge.net>,
dri-devel <dri-devel@lists.sourceforge.net>
Subject: Re: [Dri-devel] Two Linux framebuffer patches, Radeon and Rage128
Date: Sun, 10 Aug 2003 15:44:21 -0700 [thread overview]
Message-ID: <3F36CAC5.7060504@us.ibm.com> (raw)
In-Reply-To: <20030810213238.95434.qmail@web14905.mail.yahoo.com>
Jon Smirl wrote:
> These add all known Radeon and Rage128 PCI IDs to
> their respective framebuffer drivers. It also updates
> linux/pci_ids.h with these IDs.
>
> Both drivers will display pretty_name if
> CONFIG_PCI_NAMES is enabled, otherwise a name is
> generated.
>
> Please check over the chip family definitions in the
> framebuffer files. The Radeon ones are more likely to
> be wrong. I also made the Radeon FB claim secondary
> adapters but not do anything with them. This will make
> them display in /proc as being owned by the driver.
> For this to work right the devices ID have to be in
> the correct secondary family. I may not have these all
> right since I don't have the doc.
>
> I removed about 15 definitions from pci_ids.h that
> were wrong.
>
> The rage128 patch is newer than the last one. I had a
> typo in an IFDEF. Rage128 add PCI IDs and fixes bug
> when modprobe didn't work.
Did you see a very similar patch that I sent to dri-devel a week or two
ago? Isn't pci_ids.h generated automatically from drivers/pci/pci.ids?
The patch that I sent to dri-devel updates / cleans-up
drivers/pci/pci.ids and had a Python script to generate a table that
looks very similar to the radeonfb_pci_table. It seems that
automatically generating that data from pci.ids is a better solution
that doing it by hand.
I think using something more like my PCI ID structure would help cut out
some code in the Radeon FB driver because instead of just having an enum
in the table, you could have a pointer to a structure (such as the
correct entry in the radeon_chip_info table) that would eliminate some
of those extra switch-statements.
My changes only cover the Radeon family. Once that much got into DRI I
had plans to make similar changes for the Rage128 and MGA families of chips.
Check:
http://marc.theaimsgroup.com/?l=dri-devel&m=105979521324026&w=2
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
next prev parent reply other threads:[~2003-08-10 22:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-09 20:41 [Dri-devel] Linux kernel PCI IDs vs Xfree Alexander Stohr
2003-08-10 4:20 ` Jon Smirl
2003-08-10 6:00 ` More Linux kernel PCI IDs vs Xfree - Radeon Jon Smirl
2003-08-10 21:32 ` Two Linux framebuffer patches, Radeon and Rage128 Jon Smirl
2003-08-10 22:44 ` Ian Romanick [this message]
2003-08-11 3:57 ` [Dri-devel] " Jon Smirl
2003-08-12 7:08 ` Jon Smirl
2003-08-10 14:07 ` [Dri-devel] Linux kernel PCI IDs vs Xfree Dave Jones
2003-08-10 15:07 ` Jon Smirl
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=3F36CAC5.7060504@us.ibm.com \
--to=idr@us.ibm.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=jonsmirl@yahoo.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 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).