(no subject)

[Dave Airlie]

Hi Linus/Andrew,

I'd like to merge up the DRM tree to the stable branch, these patches have
been in -mm since I added them, they include a new i915 drm from Tungsten
Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
(it falls back if framebuffer is enabled...), the next DRM changes are
lined up on a CVS branch - they start detemplating the DRM...

Please do a

	bk pull bk://drm.bkbits.net/drm-2.6

This will include the latest DRM changes and will update the following files:

 drivers/char/drm/Kconfig         |   17
 drivers/char/drm/Makefile        |    2
 drivers/char/drm/drm.h           |    4
 drivers/char/drm/drmP.h          |   18
 drivers/char/drm/drm_bufs.h      |    1
 drivers/char/drm/drm_drv.h       |  188 ++++++---
 drivers/char/drm/drm_ioctl.h     |    2
 drivers/char/drm/drm_os_linux.h  |    4
 drivers/char/drm/drm_pciids.h    |    8
 drivers/char/drm/drm_proc.h      |   17
 drivers/char/drm/drm_stub.h      |  201 +++++++---
 drivers/char/drm/gamma_old_dma.h |   69 ++-
 drivers/char/drm/i810_dma.c      |    7
 drivers/char/drm/i830_dma.c      |   12
 drivers/char/drm/i915.h          |   95 ++++
 drivers/char/drm/i915_dma.c      |  760 +++++++++++++++++++++++++++++++++++++++
 drivers/char/drm/i915_drm.h      |  162 ++++++++
 drivers/char/drm/i915_drv.c      |   31 +
 drivers/char/drm/i915_drv.h      |  228 +++++++++++
 drivers/char/drm/i915_irq.c      |  173 ++++++++
 drivers/char/drm/i915_mem.c      |  361 ++++++++++++++++++
 drivers/char/drm/sis_mm.c        |    7
 22 files changed, 2194 insertions(+), 173 deletions(-)

through these ChangeSets:

<airlied@starflyer.(none)> (04/08/02 1.1823)
   Fix up multiple devices issues with creating /proc/dri/

   From: Jon Smirl
   Approved-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/08/02 1.1822)
   add hotplug support function

   From: Jon Smirl
   Approved-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/08/02 1.1821)
   fixup prototype..

<airlied@starflyer.(none)> (04/07/31 1.1820)
   switch to using i915_dma_cleanup as this conflicts on BSD builds..

<airlied@starflyer.(none)> (04/07/31 1.1819)
   sparse: use of user space pointer in kernel...

   Approved-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/07/31 1.1818)
   sparse: 0->NULL conversions.

   From: Dave Airlie

<airlied@starflyer.(none)> (04/07/31 1.1817)
   the patch below optimises the drm code to not do put_user() on memory the
   kernel allocated and then mmap-installed to userspace, but instead makes it
   use the kernel virtual address directly instead.

   From: Arjan van de Ven <arjanv@redhat.com>
   Approved-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/07/26 1.1816)
   ATI Rage 128 and Radeon DRM unconditionally depend on PCI

   Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

<airlied@starflyer.(none)> (04/07/26 1.1815)
   Correct a couple of packet length calculations. - keithw

<airlied@starflyer.(none)> (04/07/25 1.1814)
   define user if not already.. this isn't needed in kernel but for building against the kernel headers it is ...

<airlied@starflyer.(none)> (04/07/25 1.1813)
   sync up device/driver tracking with CVS,

   Approved-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/07/25 1.1812)
   fix whitespace on tabbing

<airlied@starflyer.(none)> (04/07/25 1.1811)
   add some annotations Als patch missed
   add annotations for i915 driver

<airlied@starflyer.(none)> (04/07/25 1.1810)
   add missing prototype

<airlied@starflyer.(none)> (04/07/25 1.1809)
   fixup annotation

<airlied@starflyer.(none)> (04/07/25 1.1808)
   patch from Tom Arbuckle for missing bus_address

   Approved-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/07/20 1.1807)
   use NULLs instead of 0s

   Approved-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/07/20 1.1806)
   fixup drm_stub so it works with two-headed cards properly...

   Approved-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/07/15 1.1784.4.6)
   Add new i915 driver from Tungsten Graphics Inc. This driver covers the i830
   chipsets also, a new X 2D + 3D driver are needed to use this but they have
   been integrated into at least the X.org tree at this point and I think the
   XFree86 tree. There are probably a few cleanups necessary for this driver.

   From: Keith Whitwell <keith@tungstengraphics.com>
   Approved-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/07/15 1.1784.4.5)
   Fix issue with keeping count of registered DRMs with new driver model

   Submitted-by: Dave Airlie <airlied@linux.ie>

<airlied@starflyer.(none)> (04/07/06 1.1784.4.4)
   changes for better hotplug and proper PCI device support from Jon Smirl and
   Dave Airlie, along with a big fix from Paul Mackerras.

   Note: these are complex due to the need for the DRM to fallback if the
   framebuffer driver has already taken the device.

   These changes have been in the DRM CVS tree for about 3 months, style
   comments are appreciated...


-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: your mail

[Christoph Hellwig]

On Sun, Aug 15, 2004 at 01:19:31PM +0100, Dave Airlie wrote:
> Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
> (it falls back if framebuffer is enabled...),

Can you explain what this means?

Re: your mail

[Dave Airlie]

> On Sun, Aug 15, 2004 at 01:19:31PM +0100, Dave Airlie wrote:
> > Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
> > (it falls back if framebuffer is enabled...),
>
> Can you explain what this means?
>

Probably should say PCI APIs properly, it now does enable/disable devices
and registers the DRM as owning the memory regions, does proper PCI
probing .. in cases where the fb is loaded on the card already it falls
back to the old ways (evil direct register writing.. ), this change will
stop you loading the fb driver adter the drm driver but this shouldn't be
a common case at all..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: your mail

[Christoph Hellwig]

On Mon, Aug 16, 2004 at 12:40:43AM +0100, Dave Airlie wrote:
> Probably should say PCI APIs properly, it now does enable/disable devices
> and registers the DRM as owning the memory regions, does proper PCI
> probing .. in cases where the fb is loaded on the card already it falls
> back to the old ways (evil direct register writing.. ), this change will
> stop you loading the fb driver adter the drm driver but this shouldn't be
> a common case at all..

Eeek, doing different styles of probing is even worse than what you did
before.  Please revert to pci_find_device() util you havea proper common
driver ready.

Re: your mail

[Dave Airlie]

>
> Eeek, doing different styles of probing is even worse than what you did
> before.  Please revert to pci_find_device() util you havea proper common
> driver ready.

There was nothing wrong with what we did before it just happened to work
like 2.4. we are now acting like real 2.6 drivers, which we need to do for
sysfs and hotplug to work, Jon Smirl is working on a proper minor device
support (like USB does I think)... we need to get this work done before we
can have proper common drivers and I don't want to do all this work in
hiding and then have it refused because we told no-one,

The DRM will flux a lot over the next while (while we get this common
drm/fb stuff together) and as long as we can keep the changes from
actually breaking it I think people should be able to live with it ...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: your mail

[Christoph Hellwig]

On Mon, Aug 16, 2004 at 10:30:55AM +0100, Dave Airlie wrote:
> >
> > Eeek, doing different styles of probing is even worse than what you did
> > before.  Please revert to pci_find_device() util you havea proper common
> > driver ready.
> 
> There was nothing wrong with what we did before it just happened to work
> like 2.4. we are now acting like real 2.6 drivers,

no, now you're acting like an even more broken driver, preventing a fbdev
driver to be loaded afterwards and doing all kinds of funny things.  Please
revert to the old method until you have a common pci_driver for fbdev and dri.

Re: your mail

[Dave Airlie]

>
> no, now you're acting like an even more broken driver, preventing a fbdev
> driver to be loaded afterwards and doing all kinds of funny things.  Please
> revert to the old method until you have a common pci_driver for fbdev and dri.
>

the options we have are
1) move the DRM to be a real PCI driver now - stop fb from working on same
card

2) move the DRM to act like a real PCI driver when fb isn't loaded, when
we merge we rip the code out..

the other option is not going to happen unless Linus/Andrew/Alan tell us
to go away do it that away and will then unconditionally merge a
mega-patch when I'm finished - you can't have it both ways we fix things
step-by-step or we leave it as is and nobody fixes it, so Christoph I
repsect your opinion but unless you care about this enough to do the work
on it, the way we are going seems to be the best way to avoid breaking
things and I'm leaving the decision on whether to merge this stuff or not
to Linus/Andrew - btw in case anyone wants to look the patch is whats at:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc4/2.6.8-rc4-mm1/broken-out/bk-drm.patch

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: your mail

[Christoph Hellwig]

On Mon, Aug 16, 2004 at 11:29:48AM +0100, Dave Airlie wrote:
> 1) move the DRM to be a real PCI driver now - stop fb from working on same
> card
> 
> 2) move the DRM to act like a real PCI driver when fb isn't loaded, when
> we merge we rip the code out..

3) stop making broken changes.

	You do stop fb from beeing loaded after drm
and thus break perfectly working setups during stable series.  And you
introduce indeterministic behaviour, and although I haven't looked at the
code because unlike every guideline tells you you didn't post it to do the
list, probably horribly broken code.

If you want pci_driver semantics - and apparently you do - move fbdev
and drm into a common driver or introduce a stub.  This was discussed to
death and all kinds of list and Kernel Summit and now please follow what
was agreed on instead of introducing subtile hacks.

Re: your mail

[Dave Airlie]

>
> 3) stop making broken changes.

The current system is broken in way more subtle ways...

> 	You do stop fb from beeing loaded after drm
> and thus break perfectly working setups during stable series.  And you

I doubt anyone has a system that does it and they should have a broken one
if they do it.. drm has also said you should load fb before it.. and
having both fb and drm loaded on the same hardware is a hack anyways..

> introduce indeterministic behaviour, and although I haven't looked at the
> code because unlike every guideline tells you you didn't post it to do the
> list, probably horribly broken code.

I just did post it, it's been in the DRM CVS tree for 3-6 mths now, it's
been in -mm for 1.5 mths, I've followed what Andrew and Linus told me to
do to get the DRM maintained... the link I posted in the last mail to the
broken out patch in the -mm tree, the only file to change is really
drm_drv.h and some bits in drm_stub.h... the current code is we have
discovered horribly broken in a lot of cases.. I've gotten nothing back to
say this code is any worse....

> If you want pci_driver semantics - and apparently you do - move fbdev
> and drm into a common driver or introduce a stub.  This was discussed to
> death and all kinds of list and Kernel Summit and now please follow what
> was agreed on instead of introducing subtile hacks.

Yes and that is the final goal but you are dodging the point we cannot
jump to a fully finished state in one simple transition, it is great to
hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
it must be simple, well its not and we are taking the route that should
affect the least people, I'm majorly involved in the discussion and I was
the one to agree to carry out the maintenance paths between DRM and LK,
this code is needed for us to move forward with the merged drivers - if
Linus/Andrew decide not to merge it I'll go back to the DRM team and it'll
be reworked until they do accept it, but we have to stop the fb from
loading after the DRM at some stage and it may as well be earlier.. (if
2.7 was going to happen I'd wait but kernel development seems to be
changing...)

You seem to want us to go down the finished unmergeable mega-patch road
to avoid breaking something that is broken and might work, the benefits
don't outweight the costs.. so it makes no sense..

Again if Linus/Andrew bounce this we will have to rework it but something
like this has to go in at some stage...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: your mail

[Christoph Hellwig]

On Mon, Aug 16, 2004 at 12:02:15PM +0100, Dave Airlie wrote:
> > 	You do stop fb from beeing loaded after drm
> > and thus break perfectly working setups during stable series.  And you
> 
> I doubt anyone has a system that does it and they should have a broken one
> if they do it.. drm has also said you should load fb before it.. and
> having both fb and drm loaded on the same hardware is a hack anyways..

So fix it properly instead of making it even more broken.

> Yes and that is the final goal but you are dodging the point we cannot
> jump to a fully finished state in one simple transition, it is great to
> hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
> it must be simple, well its not and we are taking the route that should

It _is+ simple.  Look at drivers/message/fusion/ for a driver doing multiple
protocol on a single pci_driver.  I don't demand full-blown memory management
integration or anything pother fancy.  Just get your crap sorted out.

ou could propably have done a prototype in the time you wasted arguing here.

> You seem to want us to go down the finished unmergeable mega-patch road
> to avoid breaking something that is broken and might work, the benefits
> don't outweight the costs.. so it makes no sense..

I want you a) to back out this particular broken change in your current
mega-patch.  and b) submit small reviewable changes in the future, as every
other driver maintainer does.

Re: your mail

[Alan Cox]

On Llu, 2004-08-16 at 12:08, Christoph Hellwig wrote:
> I want you a) to back out this particular broken change in your current
> mega-patch.  and b) submit small reviewable changes in the future, as every
> other driver maintainer does.

DRI is done as small reviewable changes. If you want to be involved then
follow the DRI list too or ask for the entire list to be gated to
linux-kernel for your pleasure...

Re: your mail

[Dave Airlie]

> > Yes and that is the final goal but you are dodging the point we cannot
> > jump to a fully finished state in one simple transition, it is great to
> > hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
> > it must be simple, well its not and we are taking the route that should
>
> It _is+ simple.  Look at drivers/message/fusion/ for a driver doing multiple
> protocol on a single pci_driver.  I don't demand full-blown memory management
> integration or anything pother fancy.  Just get your crap sorted out.
>
> ou could propably have done a prototype in the time you wasted arguing here.

we could write one quick enough for one card but now make it work on
combinations of mach64/i810/radeon/r128/i830/i915/mga cards and tested so
that it doesn't break current setups, its just not going to happen, this
change doesn't break near as many setups (I'd be surprised if it broke any
real world setups at all...) I don't have the hardware to test this on all
those cards, the hope is to get the DRM into a state that we can start
proving the shared idea on one card.. it will also make changes to fb
drivers which I'm not comfortable with doing and will cause more hassles..

> I want you a) to back out this particular broken change in your current
> mega-patch.  and b) submit small reviewable changes in the future, as every
> other driver maintainer does.

I'm considering your argument and have taken it on-board, I await Linus's
decision for now, I'll start looking into the info you've given me and
I'll talk to the DRM people actually doing the work (not one line of this
is orignally from me!!..)

All DRM changes are available in small chunks in DRM CVS and DRM bk trees,
the -mm tree picks up the DRM changes and I fix the bugs that come up in
the -mm tree and then I submit the bk tree to Linus, I thought this was
how kernel development worked these days,

The patch you are against is
http://drm.bkbits.net:8080/drm-2.6/patch@1.1784.4.4?nav=index.html|tags|ChangeSet@1.1722.154.18..|cset@1.1784.4.4

with a couple of bugfixes on top of it from testing in -mm.. if I'm
missing the kernel development process somehow please inform me.. I'm new
to this maintainer job and the drm hasn't been maintained in years so I'm
not starting from a good place...

Thanks,
Dave.

Re: your mail

[Alan Cox]

On Llu, 2004-08-16 at 10:50, Christoph Hellwig wrote:
> no, now you're acting like an even more broken driver, preventing a fbdev
> driver to be loaded afterwards and doing all kinds of funny things.  Please
> revert to the old method until you have a common pci_driver for fbdev and dri.

fbdev and DRI are not functional together in the general case. They
sometimes happen to work by luck. fbdev and X for that matter are
generally incompatible except unaccelerated.

Re: your mail

[Christoph Hellwig]

On Mon, Aug 16, 2004 at 12:12:00PM +0100, Alan Cox wrote:
> On Llu, 2004-08-16 at 10:50, Christoph Hellwig wrote:
> > no, now you're acting like an even more broken driver, preventing a fbdev
> > driver to be loaded afterwards and doing all kinds of funny things.  Please
> > revert to the old method until you have a common pci_driver for fbdev and dri.
> 
> fbdev and DRI are not functional together in the general case. They
> sometimes happen to work by luck. fbdev and X for that matter are
> generally incompatible except unaccelerated.

Works fine on all my pmacs here.  In fact X works only on fbdev for
full features.

Re: your mail

[Dave Airlie]

>
> Works fine on all my pmacs here.  In fact X works only on fbdev for
> full features.

I think Alan would classify that as luck rathar than design... and I would
tend to agree, does it work if you load the driver modules in any order?
or do you always to fb then drm? or the other way around?

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: your mail

[Christoph Hellwig]

On Mon, Aug 16, 2004 at 01:24:30PM +0100, Dave Airlie wrote:
> >
> > Works fine on all my pmacs here.  In fact X works only on fbdev for
> > full features.
> 
> I think Alan would classify that as luck rathar than design... and I would

All the fbdev handling code in X is also an accident?

Really, why do you even push for this change if the better fix isn't that
far away.  Send the i915 driver and the other misc cleanups to Linus now
and get a proper graphics stub driver done, it's not that much work.  I'll
hack up the fbdev side once I'll get a little time, but the drm code is
far to disgusting to touch, sorry.

Re: your mail

[Dave Airlie]

>
> All the fbdev handling code in X is also an accident?

I've no idea I've nothing to do with X... but the fact that graphics work
at all with fb/drm/X is by no fault of any design it is pure hack ...

> Really, why do you even push for this change if the better fix isn't that
> far away.  Send the i915 driver and the other misc cleanups to Linus now
> and get a proper graphics stub driver done, it's not that much work.  I'll
> hack up the fbdev side once I'll get a little time, but the drm code is
> far to disgusting to touch, sorry.

It means writing 6 or 7 stub drivers, for cards we don't have, it means
making PCI probing different for some fbdev drivers and some DRM drivers
(e.g. the i915 doesn't have a framebuffer driver in 2.6 so do I write a
stub on the chance that someone writes an fb driver for it? -  why do this
when the DRM will start encompassing the fb soon..) it is a lot of work
that we intend throwing away, the final solution is not to merge DRM/fb
via a stub, it is to create a single driver for each card, what happens
when the DRM starts doing memory management and 2d stuff.. we won't want
fb to be able to load anymore as it will break the DRM...I see Jon Smirl
has found the thread, please discuss with him as he was the one doing all
the legwork at the kernel summit...

again this doesn't break any real setups, it is the path of least
resistance as it doesn't affect fb drivers, why should DRM be a second
class citizen, when it is clearly going to have to be a first class 2.6
driver to do its job... if you can find someone with a real world setup
that this breaks I'll consider it a really bad idea... but I think Jon has
made his point far better than I...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person