Rational for having CONFIG_FB_RADEON=m

4 messages, 3 authors, 2016-06-14 · open the first message on its own page

Rational for having CONFIG_FB_RADEON=m

From: Mathieu Malaterre <hidden>
Date: 2016-06-13 15:46:26

Dear all,

Debian decided to switch to using CONFIG_FB_RADEON=m (Mach64 and
Rage128 are still built-in). Since CONFIG_FB_OF=y and can never be a
module,  this means for PowerMac+radeon users that Open Firmware is
always the implementation taken from the Frame Buffer:

[    0.740726] Using unsupported 800x600 ATY,RockHopper2_A at
9c008000, depth=8, pitch=1024
[    0.750458] Console: switching to colour frame buffer device 100x37
[    0.759850] fb0: Open Firmware frame buffer device on
/pci@f0000000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0

And:

$ cat /proc/fb
0 OFfb ATY,RockHo

Since also `radeonfb` is not capable of kicking out `offb` this means
I cannot `modprobe radeonfb`:

[   96.551486] radeonfb 0000:00:10.0: enabling device (0006 -> 0007)
[   96.551526] radeonfb 0000:00:10.0: BAR 0: can't reserve [mem
0x98000000-0x9fffffff pref]
[   96.551531] radeonfb (0000:00:10.0): cannot request region 0.
[   96.551545] radeonfb: probe of 0000:00:10.0 failed with error -16

So I have two options:

1. Try to convince debian-kernel team to switch back to
CONFIG_FB_RADEON=y (this will conflict with results from:
https://bugs.debian.org/614221)
2. Try to fix `radeonfb` so that it is able to kick offb out of the
way. Eg: https://lists.freedesktop.org/archives/dri-devel/2010-August/002907.html
From my understanding it would make sense to go for (2), since it
would allow for proper support for CONFIG_FB_RADEON=m on PowerMac. In
this case, would such patch be accepted ?

Thanks

Re: Rational for having CONFIG_FB_RADEON=m

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2016-06-14 03:26:11

On Mon, 2016-06-13 at 17:46 +0200, Mathieu Malaterre wrote:
2. Try to fix `radeonfb` so that it is able to kick offb out of the
way. Eg: https://lists.freedesktop.org/archives/dri-devel/2010-August/002907.html

From my understanding it would make sense to go for (2), since it
would allow for proper support for CONFIG_FB_RADEON=m on PowerMac. In
this case, would such patch be accepted ?
Sounds like the right fix to me. Ben's patch above was merged, so it's supposed
to kick out offb AFAICS, the fact that it can't seems like a bug.

cheers

Re: Rational for having CONFIG_FB_RADEON=m

From: Mathieu Malaterre <hidden>
Date: 2016-06-14 06:06:14

Hi Michael,

On Tue, Jun 14, 2016 at 5:26 AM, Michael Ellerman [off-list ref] wrote:
On Mon, 2016-06-13 at 17:46 +0200, Mathieu Malaterre wrote:
quoted
2. Try to fix `radeonfb` so that it is able to kick offb out of the
way. Eg: https://lists.freedesktop.org/archives/dri-devel/2010-August/002907.html

From my understanding it would make sense to go for (2), since it
would allow for proper support for CONFIG_FB_RADEON=m on PowerMac. In
this case, would such patch be accepted ?
Sounds like the right fix to me. Ben's patch above was merged, so it's supposed
to kick out offb AFAICS, the fact that it can't seems like a bug.
I can do a `modprobe radeon` just fine, thanks to this patch. A
similar patch needs to be applied for `radeonfb` now. I'll work on it
ASAP.

-M

Re: Rational for having CONFIG_FB_RADEON=m

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2016-06-14 11:15:29

On Tue, 2016-06-14 at 13:26 +1000, Michael Ellerman wrote:
On Mon, 2016-06-13 at 17:46 +0200, Mathieu Malaterre wrote:
quoted
2. Try to fix `radeonfb` so that it is able to kick offb out of the
way. Eg: https://lists.freedesktop.org/archives/dri-devel/2010-Augu
st/002907.html

From my understanding it would make sense to go for (2), since it
would allow for proper support for CONFIG_FB_RADEON=m on PowerMac.
In
this case, would such patch be accepted ?
Sounds like the right fix to me. Ben's patch above was merged, so
it's supposed
to kick out offb AFAICS, the fact that it can't seems like a
Make sure you have CONFIG_VT_HW_CONSOLE_BINDING=y

Ben.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help