Rational for having CONFIG_FB_RADEON=m

Rational for having CONFIG_FB_RADEON=m

[Mathieu Malaterre]

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

[Michael Ellerman]

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

[Mathieu Malaterre]

Hi Michael,

On Tue, Jun 14, 2016 at 5:26 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> 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.

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

[Benjamin Herrenschmidt]

On Tue, 2016-06-14 at 13:26 +1000, Michael Ellerman wrote:
> 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-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

Fwd: Rational for having CONFIG_FB_RADEON=m

[Mathieu Malaterre]

[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]

Hi Ben,

On Tue, Jun 14, 2016 at 1:15 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2016-06-14 at 13:26 +1000, Michael Ellerman wrote:
>> 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-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

Thanks I do have it.

What I was trying to say in my broken fr-english is that I would like
to patch `drivers/video/fbdev/aty/radeon_base.c` the same way you did
`drivers/gpu/drm/radeon/radeon_drv.c` a long time ago.

So that there is no possible confusion, I am attaching my WIP. I know
you must be very busy, but I would really appreciate if you could
review this patch and give me some clue(s) as to why
`pci_request_region` still fails even if the call to
`radeon_kick_out_firmware_fb` succeeds in kicking out `offb` (I am
left with an empty /proc/fb).

In this case dmesg properly reveals that OFfb was kicked out but still
the `radeonfb` could not succeed:

[...]
 bus: 'pci': add driver radeonfb
 bus: 'pci': driver_probe_device: matched device 0000:00:10.0 with
driver radeonfb
 bus: 'pci': really_probe: probing driver radeonfb with device 0000:00:10.0
 devices_kset: Moving 0000:00:10.0 to end of list
 radeonfb_pci_register BEGIN
 checking generic (9c008000 96000) vs hw (98000000 8000000)
 fb: switching to radeonfb from OFfb ATY,RockHo
 Console: switching to colour dummy device 80x25
 device: 'fb0': device_unregister
 PM: Removing info for No Bus:fb0
 device: 'fb0': device_create_release
 radeonfb 0000:00:10.0: enabling device (0006 -> 0007)
 device: 'vtcon1': device_unregister
 PM: Removing info for No Bus:vtcon1
 device: 'vtcon1': device_create_release
 radeonfb 0000:00:10.0: BAR 0: can't reserve [mem 0x98000000-0x9fffffff pref]
 radeonfb (0000:00:10.0): cannot request region 0.
 radeonfb: probe of 0000:00:10.0 failed with error -16
[...]

The only way I found to load `radeonfb` is to use offb:off in yaboot.

Regards and thanks for your time,

[-- Attachment #2: radeonfp.patch --]
[-- Type: text/x-patch, Size: 1131 bytes --]

diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index 218339a..1a91feb 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2259,6 +2259,22 @@ static struct bin_attribute edid2_attr = {
 	.read	= radeon_show_edid2,
 };
 
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+	struct apertures_struct *ap;
+
+	ap = alloc_apertures(1);
+	if (!ap)
+		return -ENOMEM;
+
+	ap->ranges[0].base = pci_resource_start(pdev, 0);
+	ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+	remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+	kfree(ap);
+
+	return 0;
+}
 
 static int radeonfb_pci_register(struct pci_dev *pdev,
 				 const struct pci_device_id *ent)
@@ -2314,6 +2330,10 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
 	rinfo->fb_base_phys = pci_resource_start (pdev, 0);
 	rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
 
+	ret = radeon_kick_out_firmware_fb(pdev);
+	if (ret)
+		return ret;
+
 	/* request the mem regions */
 	ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
 	if (ret < 0) {