--- 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 s
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 a
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 t
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 mul
--- 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
>Unfortunely most fbdev drivers set the hardware in IO access mode. Plus
> some of the devices lack any kind of DMA support. In this case seperating
> out the parts of the driver that program the "high level" stuff leaves
> almost nothing left. Would it still be wise to seperate it out as y
> > 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 bec
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
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
>inter
On Tue, 28 Oct 2003, Benjamin Herrenschmidt wrote:
>
> 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 t
> 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
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
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 t
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
>in
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,
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 that
>it can jus
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 pipeli
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
>
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 s
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
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 el
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
pci_
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 myself.
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() stuf
> 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,
--- 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 doi
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 wo
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 s
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
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 09:44:38AM -0700, Linus Torvalds wrote:
>
> On Thu, 23 Oct 2003, Jeff Garzik wrote:
>
> > /* Assign space for ROM resource if not already assigned. Ugly. */
> > if (!pci_resource_start(dev, PCI_ROM_RESOURCE))
> > if (pci_assign_resource(dev, PCI_R
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/
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 -
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
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]> wrot
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, d
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
> > c
[ 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
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
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
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
41 matches
Mail list logo