Direct Rendering Infrastructure

DRM depending on `AGP=n' is driving me crazy! How to make CONFIG_DRM not
eligible for selection on platforms that do not have AGP?

Since many of the core DRM files depend on PCI, add a dependency on PCI,
to minimize the damage.

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

--- linux-2.6.12-rc5/drivers/char/drm/Kconfig	2005-05-25 19:37:53.000000000 +0200
+++ linux-m68k-2.6.12-rc5/drivers/char/drm/Kconfig	2005-04-05 10:12:41.000000000 +0200
@@ -6,7 +6,7 @@
 #
 config DRM
 	tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)"
-	depends on AGP || AGP=n
+	depends on (AGP || AGP=n) && PCI
 	help
 	  Kernel-level support for the Direct Rendering Infrastructure (DRI)
 	  introduced in XFree86 4.0. If you say Y here, you need to select

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

On May 28, 2005, at 17:50:05, Dave Jones wrote:
> On Sat, May 28, 2005 at 11:39:00PM +0200, Geert Uytterhoeven wrote:
>>  config DRM
>>      tristate "Direct Rendering Manager (XFree86 4.1.0 and higher  
>> DRI support)"
>> -    depends on AGP || AGP=n
>> +    depends on (AGP || AGP=n) && PCI
>>
>
> The whole dependancy seems like nonsense to me.
> I think
>
>     depends on PCI
>
> is a lot more sensible.

I think the original reasoning was something like this:

If DRM is built-in, then AGP _must_ be built-in or not included at  
all, modular
won't work.  If DRM is modular or not built, then AGP may be built- 
in, modular,
or not built at all.

The "depends on AGP || AGP=n" means that if DRM=y, then AGP=y or  
AGP=n, and if
DRM=m or DRM=n, then AGP=y or AGP=m or AGP=n.

Yes it's unclear and yes it should probably be documented in a  
comment somewhere.



Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$  
r  !y?(-)
------END GEEK CODE BLOCK------

> > >
> >
> > The whole dependancy seems like nonsense to me.
> > I think
> >
> >     depends on PCI
> >
> > is a lot more sensible.
>
> I think the original reasoning was something like this:
>
> If DRM is built-in, then AGP _must_ be built-in or not included at all,
> modular
> won't work.  If DRM is modular or not built, then AGP may be built-in,
> modular,
> or not built at all.
>
> The "depends on AGP || AGP=n" means that if DRM=y, then AGP=y or AGP=n, and if
> DRM=m or DRM=n, then AGP=y or AGP=m or AGP=n.
>
> Yes it's unclear and yes it should probably be documented in a comment
> somewhere.

What Kyle said is the correct answer... we either keep this lovely
construct (I'll add a comment for 2.6.13) or we go back to the old
intermodule or module_get stuff... DRM built-in with modular AGP is always
wrong... or at least I'll get a hundred e-mails less every month if I
say it is ..

Dave.

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

On Sun, May 29, 2005 at 12:25:10AM -0400, Kyle Moffett wrote:
> If DRM is built-in, then AGP _must_ be built-in or not included at  
> all, modular
> won't work.  If DRM is modular or not built, then AGP may be built- 
> in, modular,
> or not built at all.
> 
> The "depends on AGP || AGP=n" means that if DRM=y, then AGP=y or  
> AGP=n, and if
> DRM=m or DRM=n, then AGP=y or AGP=m or AGP=n.
> 
> Yes it's unclear and yes it should probably be documented in a  
> comment somewhere.

could be written easier as depends on AGP if AGP

On Sun, 29 May 2005, Dave Airlie wrote:
> > > The whole dependancy seems like nonsense to me.
> > > I think
> > >
> > >     depends on PCI
> > >
> > > is a lot more sensible.
> >
> > I think the original reasoning was something like this:
> >
> > If DRM is built-in, then AGP _must_ be built-in or not included at all,
> > modular
> > won't work.  If DRM is modular or not built, then AGP may be built-in,
> > modular,
> > or not built at all.
> >
> > The "depends on AGP || AGP=n" means that if DRM=y, then AGP=y or AGP=n, and if
> > DRM=m or DRM=n, then AGP=y or AGP=m or AGP=n.
> >
> > Yes it's unclear and yes it should probably be documented in a comment
> > somewhere.
> 
> What Kyle said is the correct answer... we either keep this lovely
> construct (I'll add a comment for 2.6.13) or we go back to the old
> intermodule or module_get stuff... DRM built-in with modular AGP is always
> wrong... or at least I'll get a hundred e-mails less every month if I
> say it is ..

And what if we don't have AGP at all? Or no PCI?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

On May 29, 2005, at 15:58:10, Geert Uytterhoeven wrote:
>> What Kyle said is the correct answer... we either keep this lovely
>> construct (I'll add a comment for 2.6.13) or we go back to the old
>> intermodule or module_get stuff... DRM built-in with modular AGP  
>> is always
>> wrong... or at least I'll get a hundred e-mails less every month if I
>> say it is ..
>
> And what if we don't have AGP at all? Or no PCI?

Then DRM detects that at configure time and excludes the code that  
requires
AGP.  Basically, the following are valid configurations:

DRM=y AGP=y  # DRM will use AGP
DRM=y AGP=n  # DRM will not use AGP

DRM=m AGP=y  # DRM will use AGP
DRM=m AGP=m  # DRM will use AGP (DRM module depends on AGP module)
DRM=m AGP=n  # DRM will not use AGP

DRM=n AGP=*  # DRM isn't compiled and therefore doesn't care about AGP

The only invalid configuration is DRM=y AGP=m, which seems silly,  
although
theoretically in that case DRM should exclude AGP support.



Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$  
r  !y?(-)
------END GEEK CODE BLOCK------

On Sun, 29 May 2005, Kyle Moffett wrote:
> On May 29, 2005, at 15:58:10, Geert Uytterhoeven wrote:
> > > What Kyle said is the correct answer... we either keep this lovely
> > > construct (I'll add a comment for 2.6.13) or we go back to the old
> > > intermodule or module_get stuff... DRM built-in with modular AGP is always
> > > wrong... or at least I'll get a hundred e-mails less every month if I
> > > say it is ..
> > 
> > And what if we don't have AGP at all? Or no PCI?
> 
> Then DRM detects that at configure time and excludes the code that requires
> AGP.  Basically, the following are valid configurations:

OK. So we still need the dependency on PCI.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

> OK. So we still need the dependency on PCI.
>=20

at the moment yes but I'm think we will have to remove this as soon as
we get the Sparc ffb stuff up and running again, the ffb driver
doesn't do any PCI stuff, we have some code around but we haven't had
any testing done on it and I'm sure its rotting away, if a maintainer
turns up for sparc ffb, then the PCI requirement is gone..

If Christoph is correct I'll clean it up to use the construct he
suggests, no-one came up with that solution when this was asked
originally a few kernels back..

I can add the PCI dependency for now...

Dave.

On Mon, 30 May 2005, Dave Airlie wrote:
> > OK. So we still need the dependency on PCI.
> 
> at the moment yes but I'm think we will have to remove this as soon as
> we get the Sparc ffb stuff up and running again, the ffb driver
> doesn't do any PCI stuff, we have some code around but we haven't had
> any testing done on it and I'm sure its rotting away, if a maintainer
> turns up for sparc ffb, then the PCI requirement is gone..

So you will have to change it to 'PCI || (FB_SBUS && SPARC64)', right?
Simply dropping the PCI requirement is wrong.

> I can add the PCI dependency for now...

Thanks!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

>
> Why is that case invalid?  I may have DRM=y so I get DRM on my
> PCI graphichs card.  Then I might load an agp module in order
> to use agp on *some other* agp card. I have no problem with DRM=y,AGP=m being
> invalid for the common
> single-card setup, but there are multi-card setups too.  Not that
> I need this special case personally - I have two cards but don't use modules.

Yes but the support costs for me of allowing that second case aren't
worth it, if people have a special case they don't lose anything by having
AGP supported DRM in the kernel or AGP in the kernel all the time..
whereas I don't have to answer a load of questions from people whose AGP
cards stop working because they build DRM into the kernel and AGP as a
module...

Dave.

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

Kyle Moffett wrote:

> On May 29, 2005, at 15:58:10, Geert Uytterhoeven wrote:
>
>>> What Kyle said is the correct answer... we either keep this lovely
>>> construct (I'll add a comment for 2.6.13) or we go back to the old
>>> intermodule or module_get stuff... DRM built-in with modular AGP  is 
>>> always
>>> wrong... or at least I'll get a hundred e-mails less every month if I
>>> say it is ..
>>
>>
>> And what if we don't have AGP at all? Or no PCI?
>
>
> Then DRM detects that at configure time and excludes the code that  
> requires
> AGP.  Basically, the following are valid configurations:
>
> DRM=y AGP=y  # DRM will use AGP
> DRM=y AGP=n  # DRM will not use AGP
>
> DRM=m AGP=y  # DRM will use AGP
> DRM=m AGP=m  # DRM will use AGP (DRM module depends on AGP module)
> DRM=m AGP=n  # DRM will not use AGP
>
> DRM=n AGP=*  # DRM isn't compiled and therefore doesn't care about AGP
>
> The only invalid configuration is DRM=y AGP=m, which seems silly,  
> although
> theoretically in that case DRM should exclude AGP support.

Why is that case invalid?  I may have DRM=y so I get DRM on my
PCI graphichs card.  Then I might load an agp module in order
to use agp on *some other* agp card. 

I have no problem with DRM=y,AGP=m being invalid for the common
single-card setup, but there are multi-card setups too.  Not that
I need this special case personally - I have two cards but don't use 
modules.

Helge Hafting