On Mon, Oct 27, 2003 at 06:13:32PM -0800, Linus Torvalds wrote:
..
So the thing should really just have
- discovery and attach/detach
- interrupt event notification (and it can't just be an interrupt
happened - the interrupt driver actually has to know enough to ACK the
interrupt,
On Monday 27 October 2003 16:43, Jeff Garzik wrote:
On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote:
On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
Graphics processors are growing more general, too -- moving towards
generic vector/data processing engines. I bet you'll
I see your point about fbdev not beeing the proper interface here.
But then, what would be the relationchip between that low level stuff
and fbdev ?
My suggestion, as a starting point, is to really think very rudimentary at
first. A truly _minimal_ thing. Minimal partly because that
--- Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
The problem is the same. DMA or not DMA, what we want is arbitration.
When fbdev sets up a mode, the X server mustn't blast 2D engine (either
using PIO or sending DMA commands) etc... So that arbitration module
will have to provide the
On Wed, 2003-10-29 at 09:09, Jon Smirl wrote:
Do we really want arbitration between multiple things (FB, X, DRI, etc) all
trying to control the video hardware at a register level? This is like writing
a multitaking system for device drivers.
Or do we want a single device driver with
On Tue, 28 Oct 2003, James Simmons wrote:
This is good design for DMA based graphics cards. Unfortunely at present
maybe one fbdev driver actaully uses DMA (i810fb). Almost all fbdev drivers
use IO access :-( Sure we could convert as many as possible to DMA, which I was
planning to do
On Tue, Oct 28, 2003 at 02:09:40PM -0800, Jon Smirl wrote:
Another possible solution to the boot time problem would be to write a
disposable device driver. The disposable driver would set the mode/EDID and run
the console until user mode started; then self destruct.
that doesnt sound very
--- Philip Brown [EMAIL PROTECTED] wrote:
On Tue, Oct 28, 2003 at 02:09:40PM -0800, Jon Smirl wrote:
Another possible solution to the boot time problem would be to write a
disposable device driver. The disposable driver would set the mode/EDID and
run
the console until user mode started;
Linus Torvalds wrote:
On Sat, 25 Oct 2003, Egbert Eich wrote:
Speaking of XFree86: when I developed the PCI resource stuff in
XFree86 I was trying to get support from kernel folks to get the
appropriate user space interfaces into the kernel. When I got
nowhere I decided to do everything
Jeff Garzik wrote:
Linus Torvalds wrote:
Quite frankly, I'd much rather see a low-level graphics driver that does
_two_ things, and those things only:
- basic hardware enumeration and setup (and no, basic setup does not
mean mode switching: it literally means things like doing the
Jeff Garzik wrote:
On Mon, Oct 27, 2003 at 03:14:11PM +, Keith Whitwell wrote:
Jeff Garzik wrote:
Thank you for saying it. This is what I have been preaching (quietly)
for years -- command submission and synchronization (and thus, DMA/irq
handling) needs to be in the kernel. Everything
On Mon, Oct 27, 2003 at 03:14:11PM +, Keith Whitwell wrote:
Jeff Garzik wrote:
Thank you for saying it. This is what I have been preaching (quietly)
for years -- command submission and synchronization (and thus, DMA/irq
handling) needs to be in the kernel. Everything else can be in
Linus Torvalds [EMAIL PROTECTED] writes:
On Sat, 25 Oct 2003, Egbert Eich wrote:
Speaking of XFree86: when I developed the PCI resource stuff in
XFree86 I was trying to get support from kernel folks to get the
appropriate user space interfaces into the kernel. When I got
nowhere I
On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote:
On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
Graphics processors are growing more general, too -- moving towards
generic vector/data processing engines. I bet you'll see an optimal
model emerge where you have some sort of
On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
Graphics processors are growing more general, too -- moving towards
generic vector/data processing engines. I bet you'll see an optimal
model emerge where you have some sort of JIT for GPU microcode in
userspace. Multiple apps pipeline
On Mon, 2003-10-27 at 16:40, David Dawes wrote:
On Sat, Oct 25, 2003 at 11:37:05AM -0700, Linus Torvalds wrote:
But I'm _not_ interested in some interfaces to let user mode just bypass
the kernel. Because they will not solve any of the other problems that
clearly _do_ need solving, and if
On Thu, Oct 23, 2003 at 02:31:44PM -0700, Jon Smirl wrote:
I don't think DRM drivers are doing things correctly yet. DRM is missing the
code for marking PCI resources as being in use while DRM is using them. This
could lead to problems with hotplug. XFree is also mapping PCI ROMs in without
David Dawes wrote:
On Sat, Oct 25, 2003 at 11:37:05AM -0700, Linus Torvalds wrote:
But I'm _not_ interested in some interfaces to let user mode just bypass
the kernel. Because they will not solve any of the other problems that
clearly _do_ need solving, and if the X server continues to believe
On Mon, 27 Oct 2003, Ian Romanick wrote:
I'm also baffled by the general animosty shown towards Linux.
I don't think it is animosity vs Linux per se, but I do think that XFree86
tends to have a very strong bias against infrastructure change.
Which is somewhat understandable: I'm a kernel
In other words, I'd keep it so simple that versions don't really matter,
because the low-level driver doesn't do enough complex things that you'd
be forced to upgrade it all the time. I don't think fbdev is at all the
proper interface - I think the proper interface is something that is so
Linus Torvalds wrote:
Quite frankly, I'd much rather see a low-level graphics driver that does
_two_ things, and those things only:
- basic hardware enumeration and setup (and no, basic setup does not
mean mode switching: it literally means things like doing the
pci_enable_device() stuff.
On Fri, Oct 24, 2003 at 11:34:04AM -0700, Jon Smirl wrote:
PCI ROM enabale/disable has come up before on LKML. Russell made this comment
about making the code more portable.
--- Russell King [EMAIL PROTECTED] wrote:
You should use pcibios_resource_to_bus() to convert a resource to a
On Fri, Oct 24, 2003 at 06:57:18PM +0200, Petr Vandrovec wrote:
We need something more sophisticated. Matrox's hardware has bits
31-16 readable/writable only if bit 0 is set to 1 (ROM enabled; you can
(obviously) set bits 31-16 0 in one write). When ROM is disabled,
bits 31-1 are always read
Linus Torvalds writes:
could lead to problems with hotplug. XFree is also mapping PCI ROMs in without
informing the kernel and that can definitely cause problems.
Absolutely. Changing PCI configurations without telling the kernel _will_
cause problems. Especially for hotplug
On Sat, 25 Oct 2003, Egbert Eich wrote:
Speaking of XFree86: when I developed the PCI resource stuff in
XFree86 I was trying to get support from kernel folks to get the
appropriate user space interfaces into the kernel. When I got
nowhere I decided to do everything myself.
There won't
--- Linus Torvalds [EMAIL PROTECTED] wrote:
Quite frankly, I'd much rather see a low-level graphics driver that does
_two_ things, and those things only:
- basic hardware enumeration and setup (and no, basic setup does not
mean mode switching: it literally means things like doing the
Face it, a good graphics driver needs more than just set up the ROM. It
needs DMA access, and the ability to use interrupts. It needs a real
driver.
It basically needs something like what the DRI modules tend to do.
I'd be really happy to have real graphics drivers in the kernel, but
[ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is
there some helper function I missed? ]
On Thu, 23 Oct 2003, Jon Smirl wrote:
I don't think DRM drivers are doing things correctly yet. DRM is missing the
code for marking PCI resources as being in use while DRM is using
On Thu, 2003-10-23 at 16:23, Linus Torvalds wrote:
[ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is
there some helper function I missed? ]
On Thu, 23 Oct 2003, Jon Smirl wrote:
I don't think DRM drivers are doing things correctly yet. DRM is missing the
code for
On Thu, 23 Oct 2003, Jeff Garzik wrote:
The mechanics aren't complicated, but I seem to recall there being a
Real Good Reason why you want to leave it disabled 99% of the time. No,
I don't recall that reason :( But my fuzzy memory seems to think that
enable, grab a slice o 'rom,
Video drivers only enable the ROM long enough to get some values out it and
then disable it. You don't want to leave ROMs enabled because there is some
hardware that uses the same address decoder for ROM and RAM and you can't use
them both at the same time.
--- Jeff Garzik [EMAIL PROTECTED]
On Fri, Oct 24, 2003 at 09:44:38AM -0700, Linus Torvalds wrote:
So wouldn't it be nice if we just had those ten lines as a generic
function like
int pci_enable_rom(struct pci_device *dev)
{
...
int pci_disable_rom(..);
Yes. Agreed,
Jeff
On Fri, 24 Oct 2003, Petr Vandrovec wrote:
It would be nice if it works... For matrox hardware I have to map ROM
over framebuffer (it is solution recommended by datasheet), as there is
no way to get memory range allocated for ROM unless ROM was left enabled
all the time.
That's fine - it
PCI ROM enabale/disable has come up before on LKML. Russell made this comment
about making the code more portable.
--- Russell King [EMAIL PROTECTED] wrote:
You should use pcibios_resource_to_bus() to convert a resource to a
representation suitable for a BAR.
http://lkml.org/lkml/2003/8/19/279
I don't think DRM drivers are doing things correctly yet. DRM is missing the
code for marking PCI resources as being in use while DRM is using them. This
could lead to problems with hotplug. XFree is also mapping PCI ROMs in without
informing the kernel and that can definitely cause problems. I'm
Wouldn't it be better to add ROM enable/disable functions to the PCI driver
than to scatter it out into every driver? All of the framebuffer and DRM
drivers need to do this. I also seem to remember that there are more steps
needed if this is going to work on an ARM chip.
--- Linus Torvalds [EMAIL
Linus Torvalds wrote:
[ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is
there some helper function I missed? ]
The mechanics aren't complicated, but I seem to recall there being a
Real Good Reason why you want to leave it disabled 99% of the time. No,
I don't recall that
37 matches
Mail list logo
