I'm still waiting for the request to have both drivers handle interrupts. I'm
sure that will be fun to implement. The correct solution is to take the source
for FB and DRM, copy them to the same directory and edit until everything works
in a single driver. That single driver may end up shipping st
>
> You could still generate a string to help with debug. Something like "Radeon QX"
> by converting the PCI ID to ASCII. Later when you get the family you could
> generate "Radeon R250 QX" for the string.
well if someone builds their kernel with pci strings turned off I persume
they know what the
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> so Linux no longer carries the device name around with it, it uses the
> kernel to get if support is there if not you get blank string,
You could still generate a string to help with debug. Something like "Radeon QX"
by converting the PCI ID to ASCII. L
>
> The patch looks good. However, doesn't drm_pci_id_list need to be updated for
> BSD to add the 2 new fields? Other than that, it looks good to me.
nope that's why there are two scripts, the bsd generates the info bsd
wants, the linux one generates the info linux wants..
so Linux no longer c
On Maw, 2004-04-20 at 18:26, Jon Smirl wrote:
> The kernel provides symbols for all of the PCI ID constants via pci_ids.h. The
> strings describing the hardware are duplicated against drivers/pci/pci.ids. How
pci.ids isnt used by 2.6, its primarily used by lspci in user space, and
the name stuff h
The kernel provides symbols for all of the PCI ID constants via pci_ids.h. The
strings describing the hardware are duplicated against drivers/pci/pci.ids. How
do the kernel people feel about us not using their symbols and strings? We're
creating duplicate definitions for these items. I seem to reca
Dave Airlie wrote:
simple behaviour is different, no idea if anyone relies on it ..
modprobe radeon
modprobe radeonfb
will not longer work the same with the new system, be it stupid/broken
etc,, there is potential difference in a stable kernel series, what
happens if I build both into the kernel?
Dave Airlie wrote:
http://freedesktop.org/~airlied/drm_pci_ids.diff
Same as last patch except now it uses the Linux PCI structures in the DRM,
it still doesn't do any of the other stuff,
again I want to have this stuff in nice clean steps so breakage is
obvious,
I believe this is a good first step
http://freedesktop.org/~airlied/drm_pci_ids.diff
Same as last patch except now it uses the Linux PCI structures in the DRM,
it still doesn't do any of the other stuff,
again I want to have this stuff in nice clean steps so breakage is
obvious,
I believe this is a good first step to satisfying t
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> simple behaviour is different, no idea if anyone relies on it ..
>
> modprobe radeon
> modprobe radeonfb
>
> will not longer work the same with the new system, be it stupid/broken
> etc,, there is potential difference in a stable kernel series, what
>
> > > already loaded and has the PCI ID registered.
> > >
> > > You want to use the kernel probe scheme first. If the kernel probe suceeds
> > it
> > > will mark the hardware in use. The fallback scheme is a trick to use the
> > > hardware without informing the kernel.
> >
> > yes but it is also th
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> > the Linux probe failed did I fallback to the manual scheme. A parallel
> method
> > could be used on BSD. The only reason you need the manual scheme is if FB is
> > already loaded and has the PCI ID registered.
> >
> > You want to use the kernel probe
> These PCI changes duplicate things that are in framebuffer. Shouldn't we be
> having a giant argument about them? I would think that is worse that DRM is is
> duplicating something in FB. The two IOCTLs I needed for reset don't exist in
> either FB or DRM. Anyway I think these changes need to go
On Mon, 2004-04-19 at 18:00, Jon Smirl wrote:
> These PCI changes duplicate things that are in framebuffer. Shouldn't we be
> having a giant argument about them? I would think that is worse that DRM is is
> duplicating something in FB. The two IOCTLs I needed for reset don't exist in
> either FB or
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > These PCI changes duplicate things that are in framebuffer. Shouldn't
> we be
> > having a giant argument about them? I would think that is worse that
> DRM is is
>
> Heh...you sure do like to start fights, don't you? :)
>
> >
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> For the 2D side I don't think its an ioctl problem as it is driven
> by the power management hooks. For 3D I can see it being relevant since
> you may want to reset the 3D engine from user space when the X server
> decides we have a failure, either by doing
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Can you elaborate? I'm not super familiar with this part of the DRM, so
> I just need a clarification. We're just talking about device
> initialization (i.e., PCI mapping) that the X-server currently does, right?
I'm not proprosing bringing any fam
On Llu, 2004-04-19 at 17:00, Jon Smirl wrote:
> These PCI changes duplicate things that are in framebuffer. Shouldn't we be
> having a giant argument about them? I would think that is worse that DRM is is
> duplicating something in FB. The two IOCTLs I needed for reset don't exist in
> either FB or
Jon Smirl wrote:
These PCI changes duplicate things that are in framebuffer. Shouldn't we be
having a giant argument about them? I would think that is worse that DRM is is
Heh...you sure do like to start fights, don't you? :)
duplicating something in FB. The two IOCTLs I needed for reset don't ex
These PCI changes duplicate things that are in framebuffer. Shouldn't we be
having a giant argument about them? I would think that is worse that DRM is is
duplicating something in FB. The two IOCTLs I needed for reset don't exist in
either FB or DRM. Anyway I think these changes need to go in. The
Dave Airlie wrote:
Okay I've come up with a method for generating the pci ids stuff for the
DRM for Linux and BSD,
put a txt file in shared or the format
[cardname]
vendid devid "namestring"
have two scripts in the scripts directory ones to create a linux
drm_pciids.h file of the format
#define ca
> Then we can submit the generated header file to the kernel, and I can
> modify the Linux code to grab a PCI name if they are compiled in and
> switched on, so to add a new ID, you just edit the text file, we can run
> the scripts as part of the make or if people think we need it we can just
> che
Okay I've come up with a method for generating the pci ids stuff for the
DRM for Linux and BSD,
put a txt file in shared or the format
[cardname]
vendid devid "namestring"
have two scripts in the scripts directory ones to create a linux
drm_pciids.h file of the format
#define cardname_PCI_IDS \
23 matches
Mail list logo
