Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

On Tue, Feb 13, 2018 at 1:05 PM, Bartlomiej Zolnierkiewicz
 wrote:
> On Saturday, February 10, 2018 01:48:55 PM Mathieu Malaterre wrote:
>>  Hi,
>>
>> On Thu, Feb 8, 2018 at 2:28 PM, Bartlomiej Zolnierkiewicz
>>  wrote:
>> > On Wednesday, January 31, 2018 08:51:23 PM Mathieu Malaterre wrote:
>> >> Bartlomiej,
>> >>
>> >> On Wed, Jan 31, 2018 at 12:57 PM, Bartlomiej Zolnierkiewicz
>> >>  wrote:
>> >> > On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
>> >> >> Bartlomiej,
>> >> >>
>> >> >> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
>> >> >>  wrote:
>> >> >> >
>> >> >> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
>> >> >> >> When the linux kernel is build with (typical kernel ship with Debian
>> >> >> >> installer):
>> >> >> >>
>> >> >> >> CONFIG_FB_OF=y
>> >> >> >> CONFIG_VT_HW_CONSOLE_BINDING=y
>> >> >> >> CONFIG_FB_RADEON=m
>> >> >> >>
>> >> >> >> The offb driver takes precedence over module radeonfb. It is then
>> >> >> >> impossible to load the module, error reported is:
>> >> >> >>
>> >> >> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> >> >> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
>> >> >> >> 0x9800-0x9fff pref]
>> >> >> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
>> >> >> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
>> >> >> >>
>> >> >> >> This patch reproduce the behavior of the module radeon, so as to 
>> >> >> >> make it
>> >> >> >> possible to load radeonfb when offb is first loaded.
>> >> >> >>
>> >> >> >> It should be noticed that `offb_destroy` is never called which 
>> >> >> >> explain the
>> >> >> >> need to skip error detection on the radeon side.
>> >> >> >
>> >> >> > This still needs to be explained more, from my last mail:
>> >> >> >
>> >> >> > "The last put_fb_info() on fb_info should call ->fb_destroy
>> >> >> > (offb_destroy in our case) and remove_conflicting_framebuffers()
>> >> >> > is calling put_fb_info() so there is some extra reference on
>> >> >> > fb_info somewhere preventing it from going away.
>> >> >> >
>> >> >> > Please look into fixing this."
>> >> >>
>> >> >> I am not familiar with the fb stuff internals but here is what I see:
>> >> >>
>> >> >> # modprobe radeonfb
>> >> >>
>> >> >> leads to:
>> >> >>
>> >> >> [   52.058546] bus: 'pci': add driver radeonfb
>> >> >> [   52.058588] bus: 'pci': driver_probe_device: matched device
>> >> >> :00:10.0 with driver radeonfb
>> >> >> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
>> >> >> device :00:10.0
>> >> >> [   52.058608] devices_kset: Moving :00:10.0 to end of list
>> >> >> [   52.058613] radeonfb_pci_register BEGIN
>> >> >> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> >> >> 
>> >> >> [   52.058666] checking generic (9c008000 96000) vs hw (9800 
>> >> >> 800)
>> >> >> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
>> >> >> [   52.058844] Console: switching to colour dummy device 80x25
>> >> >> [   52.058860] device: 'fb0': device_unregister
>> >> >> [   52.058956] PM: Removing info for No Bus:fb0
>> >> >> [   52.059014] device: 'fb0': device_create_release
>> >> >> 
>> >> >> 
>> >> >> [   52.059048] device: 'vtcon1': device_unregister
>> >> >> [   52.059076] PM: Removing info for No Bus:vtcon1
>> >> >> [   52.059091] device: 'vtcon1': device_create_release
>> >> >> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
>> >> >> 0x9800-0x9fff pref]
>> >> >> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
>> >> >> to: a000
>> >> >> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
>> >> >> wide videoram
>> >> >>
>> >> >> I can confirm that offb_destroy is never called (not sure exactly
>> >> >> why), but in any case the call to radeon_kick_out_firmware_fb happen
>> >> >> much earlier, at least before the put_fb_info.
>> >> >
>> >> > It is okay, put_fb_info() is called indirectly by 
>> >> > radeon_kick_out_firmware_fb()
>> >> >
>> >> > radeon_kick_out_firmware_fb()
>> >> > remove_conflicting_framebuffers()
>> >> > do_remove_conflicting_framebuffers()
>> >> > do_unregister_framebuffer()
>> >> > put_fb_info()
>> >> >
>> >> > offb_destroy() is not called because there is an extra reference on old
>> >> > fb_info (->count == 2):
>> >> >
>> >> > static void put_fb_info(struct fb_info *fb_info)
>> >> > {
>> >> > if (!atomic_dec_and_test(_info->count))
>> >> > return;
>> >> > if (fb_info->fbops->fb_destroy)
>> >> > fb_info->fbops->fb_destroy(fb_info);
>> >> > }
>> >> >
>> >> > The question is why there is an extra reference, probably user-space
>> >> > is still holding the fb_info reference 

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Bartlomiej Zolnierkiewicz]

On Saturday, February 10, 2018 01:48:55 PM Mathieu Malaterre wrote:
>  Hi,
> 
> On Thu, Feb 8, 2018 at 2:28 PM, Bartlomiej Zolnierkiewicz
>  wrote:
> > On Wednesday, January 31, 2018 08:51:23 PM Mathieu Malaterre wrote:
> >> Bartlomiej,
> >>
> >> On Wed, Jan 31, 2018 at 12:57 PM, Bartlomiej Zolnierkiewicz
> >>  wrote:
> >> > On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
> >> >> Bartlomiej,
> >> >>
> >> >> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
> >> >>  wrote:
> >> >> >
> >> >> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
> >> >> >> When the linux kernel is build with (typical kernel ship with Debian
> >> >> >> installer):
> >> >> >>
> >> >> >> CONFIG_FB_OF=y
> >> >> >> CONFIG_VT_HW_CONSOLE_BINDING=y
> >> >> >> CONFIG_FB_RADEON=m
> >> >> >>
> >> >> >> The offb driver takes precedence over module radeonfb. It is then
> >> >> >> impossible to load the module, error reported is:
> >> >> >>
> >> >> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> >> >> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
> >> >> >> 0x9800-0x9fff pref]
> >> >> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
> >> >> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
> >> >> >>
> >> >> >> This patch reproduce the behavior of the module radeon, so as to 
> >> >> >> make it
> >> >> >> possible to load radeonfb when offb is first loaded.
> >> >> >>
> >> >> >> It should be noticed that `offb_destroy` is never called which 
> >> >> >> explain the
> >> >> >> need to skip error detection on the radeon side.
> >> >> >
> >> >> > This still needs to be explained more, from my last mail:
> >> >> >
> >> >> > "The last put_fb_info() on fb_info should call ->fb_destroy
> >> >> > (offb_destroy in our case) and remove_conflicting_framebuffers()
> >> >> > is calling put_fb_info() so there is some extra reference on
> >> >> > fb_info somewhere preventing it from going away.
> >> >> >
> >> >> > Please look into fixing this."
> >> >>
> >> >> I am not familiar with the fb stuff internals but here is what I see:
> >> >>
> >> >> # modprobe radeonfb
> >> >>
> >> >> leads to:
> >> >>
> >> >> [   52.058546] bus: 'pci': add driver radeonfb
> >> >> [   52.058588] bus: 'pci': driver_probe_device: matched device
> >> >> :00:10.0 with driver radeonfb
> >> >> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
> >> >> device :00:10.0
> >> >> [   52.058608] devices_kset: Moving :00:10.0 to end of list
> >> >> [   52.058613] radeonfb_pci_register BEGIN
> >> >> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
> >> >> 
> >> >> [   52.058666] checking generic (9c008000 96000) vs hw (9800 
> >> >> 800)
> >> >> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
> >> >> [   52.058844] Console: switching to colour dummy device 80x25
> >> >> [   52.058860] device: 'fb0': device_unregister
> >> >> [   52.058956] PM: Removing info for No Bus:fb0
> >> >> [   52.059014] device: 'fb0': device_create_release
> >> >> 
> >> >> 
> >> >> [   52.059048] device: 'vtcon1': device_unregister
> >> >> [   52.059076] PM: Removing info for No Bus:vtcon1
> >> >> [   52.059091] device: 'vtcon1': device_create_release
> >> >> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
> >> >> 0x9800-0x9fff pref]
> >> >> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
> >> >> to: a000
> >> >> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
> >> >> wide videoram
> >> >>
> >> >> I can confirm that offb_destroy is never called (not sure exactly
> >> >> why), but in any case the call to radeon_kick_out_firmware_fb happen
> >> >> much earlier, at least before the put_fb_info.
> >> >
> >> > It is okay, put_fb_info() is called indirectly by 
> >> > radeon_kick_out_firmware_fb()
> >> >
> >> > radeon_kick_out_firmware_fb()
> >> > remove_conflicting_framebuffers()
> >> > do_remove_conflicting_framebuffers()
> >> > do_unregister_framebuffer()
> >> > put_fb_info()
> >> >
> >> > offb_destroy() is not called because there is an extra reference on old
> >> > fb_info (->count == 2):
> >> >
> >> > static void put_fb_info(struct fb_info *fb_info)
> >> > {
> >> > if (!atomic_dec_and_test(_info->count))
> >> > return;
> >> > if (fb_info->fbops->fb_destroy)
> >> > fb_info->fbops->fb_destroy(fb_info);
> >> > }
> >> >
> >> > The question is why there is an extra reference, probably user-space
> >> > is still holding the fb_info reference obtained in fb_open() call and
> >> > fb_release() is never called. Besides not calling fbops->fb_destroy()
> >> > this also causes missing call of fbops->fb_release() (in fb_release())
> >> > which some 

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

 Hi,

On Thu, Feb 8, 2018 at 2:28 PM, Bartlomiej Zolnierkiewicz
 wrote:
> On Wednesday, January 31, 2018 08:51:23 PM Mathieu Malaterre wrote:
>> Bartlomiej,
>>
>> On Wed, Jan 31, 2018 at 12:57 PM, Bartlomiej Zolnierkiewicz
>>  wrote:
>> > On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
>> >> Bartlomiej,
>> >>
>> >> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
>> >>  wrote:
>> >> >
>> >> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
>> >> >> When the linux kernel is build with (typical kernel ship with Debian
>> >> >> installer):
>> >> >>
>> >> >> CONFIG_FB_OF=y
>> >> >> CONFIG_VT_HW_CONSOLE_BINDING=y
>> >> >> CONFIG_FB_RADEON=m
>> >> >>
>> >> >> The offb driver takes precedence over module radeonfb. It is then
>> >> >> impossible to load the module, error reported is:
>> >> >>
>> >> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> >> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
>> >> >> 0x9800-0x9fff pref]
>> >> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
>> >> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
>> >> >>
>> >> >> This patch reproduce the behavior of the module radeon, so as to make 
>> >> >> it
>> >> >> possible to load radeonfb when offb is first loaded.
>> >> >>
>> >> >> It should be noticed that `offb_destroy` is never called which explain 
>> >> >> the
>> >> >> need to skip error detection on the radeon side.
>> >> >
>> >> > This still needs to be explained more, from my last mail:
>> >> >
>> >> > "The last put_fb_info() on fb_info should call ->fb_destroy
>> >> > (offb_destroy in our case) and remove_conflicting_framebuffers()
>> >> > is calling put_fb_info() so there is some extra reference on
>> >> > fb_info somewhere preventing it from going away.
>> >> >
>> >> > Please look into fixing this."
>> >>
>> >> I am not familiar with the fb stuff internals but here is what I see:
>> >>
>> >> # modprobe radeonfb
>> >>
>> >> leads to:
>> >>
>> >> [   52.058546] bus: 'pci': add driver radeonfb
>> >> [   52.058588] bus: 'pci': driver_probe_device: matched device
>> >> :00:10.0 with driver radeonfb
>> >> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
>> >> device :00:10.0
>> >> [   52.058608] devices_kset: Moving :00:10.0 to end of list
>> >> [   52.058613] radeonfb_pci_register BEGIN
>> >> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> >> 
>> >> [   52.058666] checking generic (9c008000 96000) vs hw (9800 800)
>> >> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
>> >> [   52.058844] Console: switching to colour dummy device 80x25
>> >> [   52.058860] device: 'fb0': device_unregister
>> >> [   52.058956] PM: Removing info for No Bus:fb0
>> >> [   52.059014] device: 'fb0': device_create_release
>> >> 
>> >> 
>> >> [   52.059048] device: 'vtcon1': device_unregister
>> >> [   52.059076] PM: Removing info for No Bus:vtcon1
>> >> [   52.059091] device: 'vtcon1': device_create_release
>> >> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
>> >> 0x9800-0x9fff pref]
>> >> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
>> >> to: a000
>> >> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
>> >> wide videoram
>> >>
>> >> I can confirm that offb_destroy is never called (not sure exactly
>> >> why), but in any case the call to radeon_kick_out_firmware_fb happen
>> >> much earlier, at least before the put_fb_info.
>> >
>> > It is okay, put_fb_info() is called indirectly by 
>> > radeon_kick_out_firmware_fb()
>> >
>> > radeon_kick_out_firmware_fb()
>> > remove_conflicting_framebuffers()
>> > do_remove_conflicting_framebuffers()
>> > do_unregister_framebuffer()
>> > put_fb_info()
>> >
>> > offb_destroy() is not called because there is an extra reference on old
>> > fb_info (->count == 2):
>> >
>> > static void put_fb_info(struct fb_info *fb_info)
>> > {
>> > if (!atomic_dec_and_test(_info->count))
>> > return;
>> > if (fb_info->fbops->fb_destroy)
>> > fb_info->fbops->fb_destroy(fb_info);
>> > }
>> >
>> > The question is why there is an extra reference, probably user-space
>> > is still holding the fb_info reference obtained in fb_open() call and
>> > fb_release() is never called. Besides not calling fbops->fb_destroy()
>> > this also causes missing call of fbops->fb_release() (in fb_release())
>> > which some fb drivers are implementing (but not offb.c).
>> >
>> >> Could you describe a bit more the chain of calls you were thinking of ?
>> >
>> > Please add WARN_ON(1) to get_fb_info() and put_fb_info() so we can check
>> > from the stacktrace if it is actually fb_open() that holds the extra
>> > old 

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Bartlomiej Zolnierkiewicz]

On Wednesday, January 31, 2018 08:51:23 PM Mathieu Malaterre wrote:
> Bartlomiej,
> 
> On Wed, Jan 31, 2018 at 12:57 PM, Bartlomiej Zolnierkiewicz
>  wrote:
> > On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
> >> Bartlomiej,
> >>
> >> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
> >>  wrote:
> >> >
> >> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
> >> >> When the linux kernel is build with (typical kernel ship with Debian
> >> >> installer):
> >> >>
> >> >> CONFIG_FB_OF=y
> >> >> CONFIG_VT_HW_CONSOLE_BINDING=y
> >> >> CONFIG_FB_RADEON=m
> >> >>
> >> >> The offb driver takes precedence over module radeonfb. It is then
> >> >> impossible to load the module, error reported is:
> >> >>
> >> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> >> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
> >> >> 0x9800-0x9fff pref]
> >> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
> >> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
> >> >>
> >> >> This patch reproduce the behavior of the module radeon, so as to make it
> >> >> possible to load radeonfb when offb is first loaded.
> >> >>
> >> >> It should be noticed that `offb_destroy` is never called which explain 
> >> >> the
> >> >> need to skip error detection on the radeon side.
> >> >
> >> > This still needs to be explained more, from my last mail:
> >> >
> >> > "The last put_fb_info() on fb_info should call ->fb_destroy
> >> > (offb_destroy in our case) and remove_conflicting_framebuffers()
> >> > is calling put_fb_info() so there is some extra reference on
> >> > fb_info somewhere preventing it from going away.
> >> >
> >> > Please look into fixing this."
> >>
> >> I am not familiar with the fb stuff internals but here is what I see:
> >>
> >> # modprobe radeonfb
> >>
> >> leads to:
> >>
> >> [   52.058546] bus: 'pci': add driver radeonfb
> >> [   52.058588] bus: 'pci': driver_probe_device: matched device
> >> :00:10.0 with driver radeonfb
> >> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
> >> device :00:10.0
> >> [   52.058608] devices_kset: Moving :00:10.0 to end of list
> >> [   52.058613] radeonfb_pci_register BEGIN
> >> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
> >> 
> >> [   52.058666] checking generic (9c008000 96000) vs hw (9800 800)
> >> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
> >> [   52.058844] Console: switching to colour dummy device 80x25
> >> [   52.058860] device: 'fb0': device_unregister
> >> [   52.058956] PM: Removing info for No Bus:fb0
> >> [   52.059014] device: 'fb0': device_create_release
> >> 
> >> 
> >> [   52.059048] device: 'vtcon1': device_unregister
> >> [   52.059076] PM: Removing info for No Bus:vtcon1
> >> [   52.059091] device: 'vtcon1': device_create_release
> >> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
> >> 0x9800-0x9fff pref]
> >> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
> >> to: a000
> >> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
> >> wide videoram
> >>
> >> I can confirm that offb_destroy is never called (not sure exactly
> >> why), but in any case the call to radeon_kick_out_firmware_fb happen
> >> much earlier, at least before the put_fb_info.
> >
> > It is okay, put_fb_info() is called indirectly by 
> > radeon_kick_out_firmware_fb()
> >
> > radeon_kick_out_firmware_fb()
> > remove_conflicting_framebuffers()
> > do_remove_conflicting_framebuffers()
> > do_unregister_framebuffer()
> > put_fb_info()
> >
> > offb_destroy() is not called because there is an extra reference on old
> > fb_info (->count == 2):
> >
> > static void put_fb_info(struct fb_info *fb_info)
> > {
> > if (!atomic_dec_and_test(_info->count))
> > return;
> > if (fb_info->fbops->fb_destroy)
> > fb_info->fbops->fb_destroy(fb_info);
> > }
> >
> > The question is why there is an extra reference, probably user-space
> > is still holding the fb_info reference obtained in fb_open() call and
> > fb_release() is never called. Besides not calling fbops->fb_destroy()
> > this also causes missing call of fbops->fb_release() (in fb_release())
> > which some fb drivers are implementing (but not offb.c).
> >
> >> Could you describe a bit more the chain of calls you were thinking of ?
> >
> > Please add WARN_ON(1) to get_fb_info() and put_fb_info() so we can check
> > from the stacktrace if it is actually fb_open() that holds the extra
> > old fb_info reference.
> >
> > drivers/video/fbdev/core/fbmem.c:
> >
> > static struct fb_info *get_fb_info(unsigned int idx)
> > {
> > struct fb_info *fb_info;
> >
> > if (idx >= FB_MAX)
> > 

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

Bartlomiej,

On Wed, Jan 31, 2018 at 12:57 PM, Bartlomiej Zolnierkiewicz
 wrote:
> On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
>> Bartlomiej,
>>
>> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
>>  wrote:
>> >
>> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
>> >> When the linux kernel is build with (typical kernel ship with Debian
>> >> installer):
>> >>
>> >> CONFIG_FB_OF=y
>> >> CONFIG_VT_HW_CONSOLE_BINDING=y
>> >> CONFIG_FB_RADEON=m
>> >>
>> >> The offb driver takes precedence over module radeonfb. It is then
>> >> impossible to load the module, error reported is:
>> >>
>> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
>> >> 0x9800-0x9fff pref]
>> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
>> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
>> >>
>> >> This patch reproduce the behavior of the module radeon, so as to make it
>> >> possible to load radeonfb when offb is first loaded.
>> >>
>> >> It should be noticed that `offb_destroy` is never called which explain the
>> >> need to skip error detection on the radeon side.
>> >
>> > This still needs to be explained more, from my last mail:
>> >
>> > "The last put_fb_info() on fb_info should call ->fb_destroy
>> > (offb_destroy in our case) and remove_conflicting_framebuffers()
>> > is calling put_fb_info() so there is some extra reference on
>> > fb_info somewhere preventing it from going away.
>> >
>> > Please look into fixing this."
>>
>> I am not familiar with the fb stuff internals but here is what I see:
>>
>> # modprobe radeonfb
>>
>> leads to:
>>
>> [   52.058546] bus: 'pci': add driver radeonfb
>> [   52.058588] bus: 'pci': driver_probe_device: matched device
>> :00:10.0 with driver radeonfb
>> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
>> device :00:10.0
>> [   52.058608] devices_kset: Moving :00:10.0 to end of list
>> [   52.058613] radeonfb_pci_register BEGIN
>> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> 
>> [   52.058666] checking generic (9c008000 96000) vs hw (9800 800)
>> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
>> [   52.058844] Console: switching to colour dummy device 80x25
>> [   52.058860] device: 'fb0': device_unregister
>> [   52.058956] PM: Removing info for No Bus:fb0
>> [   52.059014] device: 'fb0': device_create_release
>> 
>> 
>> [   52.059048] device: 'vtcon1': device_unregister
>> [   52.059076] PM: Removing info for No Bus:vtcon1
>> [   52.059091] device: 'vtcon1': device_create_release
>> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
>> 0x9800-0x9fff pref]
>> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
>> to: a000
>> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
>> wide videoram
>>
>> I can confirm that offb_destroy is never called (not sure exactly
>> why), but in any case the call to radeon_kick_out_firmware_fb happen
>> much earlier, at least before the put_fb_info.
>
> It is okay, put_fb_info() is called indirectly by 
> radeon_kick_out_firmware_fb()
>
> radeon_kick_out_firmware_fb()
> remove_conflicting_framebuffers()
> do_remove_conflicting_framebuffers()
> do_unregister_framebuffer()
> put_fb_info()
>
> offb_destroy() is not called because there is an extra reference on old
> fb_info (->count == 2):
>
> static void put_fb_info(struct fb_info *fb_info)
> {
> if (!atomic_dec_and_test(_info->count))
> return;
> if (fb_info->fbops->fb_destroy)
> fb_info->fbops->fb_destroy(fb_info);
> }
>
> The question is why there is an extra reference, probably user-space
> is still holding the fb_info reference obtained in fb_open() call and
> fb_release() is never called. Besides not calling fbops->fb_destroy()
> this also causes missing call of fbops->fb_release() (in fb_release())
> which some fb drivers are implementing (but not offb.c).
>
>> Could you describe a bit more the chain of calls you were thinking of ?
>
> Please add WARN_ON(1) to get_fb_info() and put_fb_info() so we can check
> from the stacktrace if it is actually fb_open() that holds the extra
> old fb_info reference.
>
> drivers/video/fbdev/core/fbmem.c:
>
> static struct fb_info *get_fb_info(unsigned int idx)
> {
> struct fb_info *fb_info;
>
> if (idx >= FB_MAX)
> return ERR_PTR(-ENODEV);
>
> mutex_lock(_lock);
> fb_info = registered_fb[idx];
> if (fb_info)
> atomic_inc(_info->count);
>
> if (fb_info)
> WARN_ON(1);
>
> mutex_unlock(_lock);
>
> return fb_info;
> }
>
> static void put_fb_info(struct fb_info *fb_info)

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Bartlomiej Zolnierkiewicz]

On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
> Bartlomiej,
> 
> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
>  wrote:
> >
> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
> >> When the linux kernel is build with (typical kernel ship with Debian
> >> installer):
> >>
> >> CONFIG_FB_OF=y
> >> CONFIG_VT_HW_CONSOLE_BINDING=y
> >> CONFIG_FB_RADEON=m
> >>
> >> The offb driver takes precedence over module radeonfb. It is then
> >> impossible to load the module, error reported is:
> >>
> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
> >> 0x9800-0x9fff pref]
> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
> >>
> >> This patch reproduce the behavior of the module radeon, so as to make it
> >> possible to load radeonfb when offb is first loaded.
> >>
> >> It should be noticed that `offb_destroy` is never called which explain the
> >> need to skip error detection on the radeon side.
> >
> > This still needs to be explained more, from my last mail:
> >
> > "The last put_fb_info() on fb_info should call ->fb_destroy
> > (offb_destroy in our case) and remove_conflicting_framebuffers()
> > is calling put_fb_info() so there is some extra reference on
> > fb_info somewhere preventing it from going away.
> >
> > Please look into fixing this."
> 
> I am not familiar with the fb stuff internals but here is what I see:
> 
> # modprobe radeonfb
> 
> leads to:
> 
> [   52.058546] bus: 'pci': add driver radeonfb
> [   52.058588] bus: 'pci': driver_probe_device: matched device
> :00:10.0 with driver radeonfb
> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
> device :00:10.0
> [   52.058608] devices_kset: Moving :00:10.0 to end of list
> [   52.058613] radeonfb_pci_register BEGIN
> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
> 
> [   52.058666] checking generic (9c008000 96000) vs hw (9800 800)
> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
> [   52.058844] Console: switching to colour dummy device 80x25
> [   52.058860] device: 'fb0': device_unregister
> [   52.058956] PM: Removing info for No Bus:fb0
> [   52.059014] device: 'fb0': device_create_release
> 
> 
> [   52.059048] device: 'vtcon1': device_unregister
> [   52.059076] PM: Removing info for No Bus:vtcon1
> [   52.059091] device: 'vtcon1': device_create_release
> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
> 0x9800-0x9fff pref]
> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
> to: a000
> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
> wide videoram
> 
> I can confirm that offb_destroy is never called (not sure exactly
> why), but in any case the call to radeon_kick_out_firmware_fb happen
> much earlier, at least before the put_fb_info.

It is okay, put_fb_info() is called indirectly by radeon_kick_out_firmware_fb()

radeon_kick_out_firmware_fb()
remove_conflicting_framebuffers()
do_remove_conflicting_framebuffers()
do_unregister_framebuffer()
put_fb_info()

offb_destroy() is not called because there is an extra reference on old
fb_info (->count == 2):

static void put_fb_info(struct fb_info *fb_info)
{
if (!atomic_dec_and_test(_info->count))
return;
if (fb_info->fbops->fb_destroy)
fb_info->fbops->fb_destroy(fb_info);
}

The question is why there is an extra reference, probably user-space
is still holding the fb_info reference obtained in fb_open() call and
fb_release() is never called. Besides not calling fbops->fb_destroy()
this also causes missing call of fbops->fb_release() (in fb_release())
which some fb drivers are implementing (but not offb.c).

> Could you describe a bit more the chain of calls you were thinking of ?

Please add WARN_ON(1) to get_fb_info() and put_fb_info() so we can check
from the stacktrace if it is actually fb_open() that holds the extra
old fb_info reference.

drivers/video/fbdev/core/fbmem.c:

static struct fb_info *get_fb_info(unsigned int idx)
{
struct fb_info *fb_info;

if (idx >= FB_MAX)
return ERR_PTR(-ENODEV);

mutex_lock(_lock);
fb_info = registered_fb[idx];
if (fb_info)
atomic_inc(_info->count);

if (fb_info)
WARN_ON(1);

mutex_unlock(_lock);

return fb_info;
}

static void put_fb_info(struct fb_info *fb_info)
{
WARN_ON(1);

if (!atomic_dec_and_test(_info->count))
return;
if (fb_info->fbops->fb_destroy)
fb_info->fbops->fb_destroy(fb_info);
}

> >> Signed-off-by: Mathieu Malaterre 
> >> Link: 

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

Bartlomiej,

On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
 wrote:
>
> On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
>> When the linux kernel is build with (typical kernel ship with Debian
>> installer):
>>
>> CONFIG_FB_OF=y
>> CONFIG_VT_HW_CONSOLE_BINDING=y
>> CONFIG_FB_RADEON=m
>>
>> The offb driver takes precedence over module radeonfb. It is then
>> impossible to load the module, error reported is:
>>
>> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
>> 0x9800-0x9fff pref]
>> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
>> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
>>
>> This patch reproduce the behavior of the module radeon, so as to make it
>> possible to load radeonfb when offb is first loaded.
>>
>> It should be noticed that `offb_destroy` is never called which explain the
>> need to skip error detection on the radeon side.
>
> This still needs to be explained more, from my last mail:
>
> "The last put_fb_info() on fb_info should call ->fb_destroy
> (offb_destroy in our case) and remove_conflicting_framebuffers()
> is calling put_fb_info() so there is some extra reference on
> fb_info somewhere preventing it from going away.
>
> Please look into fixing this."

I am not familiar with the fb stuff internals but here is what I see:

# modprobe radeonfb

leads to:

[   52.058546] bus: 'pci': add driver radeonfb
[   52.058588] bus: 'pci': driver_probe_device: matched device
:00:10.0 with driver radeonfb
[   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
device :00:10.0
[   52.058608] devices_kset: Moving :00:10.0 to end of list
[   52.058613] radeonfb_pci_register BEGIN
[   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)

[   52.058666] checking generic (9c008000 96000) vs hw (9800 800)
[   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
[   52.058844] Console: switching to colour dummy device 80x25
[   52.058860] device: 'fb0': device_unregister
[   52.058956] PM: Removing info for No Bus:fb0
[   52.059014] device: 'fb0': device_create_release


[   52.059048] device: 'vtcon1': device_unregister
[   52.059076] PM: Removing info for No Bus:vtcon1
[   52.059091] device: 'vtcon1': device_create_release
[   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
0x9800-0x9fff pref]
[   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
to: a000
[   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
wide videoram

I can confirm that offb_destroy is never called (not sure exactly
why), but in any case the call to radeon_kick_out_firmware_fb happen
much earlier, at least before the put_fb_info.

Could you describe a bit more the chain of calls you were thinking of ?

>> Signed-off-by: Mathieu Malaterre 
>> Link: https://bugs.debian.org/826629#57
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
>> Suggested-by: Lennart Sorensen 
>> ---
>> v2: Only fails when CONFIG_PCC is not set
>> v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since 
>> the conflicts in region is due to OFfb explicitly refers to it.
>
> It seems that there may still be configurations when this is
> incorrect -> when offb drives primary (non-radeon) card and radeonfb
> drives secondary (radeon) card..
>
>>  drivers/video/fbdev/aty/radeon_base.c | 26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/aty/radeon_base.c 
>> b/drivers/video/fbdev/aty/radeon_base.c
>> index 4d77daeecf99..221879196531 100644
>> --- a/drivers/video/fbdev/aty/radeon_base.c
>> +++ b/drivers/video/fbdev/aty/radeon_base.c
>> @@ -2259,6 +2259,22 @@ static const 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)
>> @@ -2312,19 +2328,27 @@ 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");
>>   

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

Hi Bartlomiej,

On Wed, Jan 3, 2018 at 4:23 PM, Lennart Sorensen
 wrote:
> On Wed, Jan 03, 2018 at 03:47:35PM +0100, Bartlomiej Zolnierkiewicz wrote:
>> On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
>> > When the linux kernel is build with (typical kernel ship with Debian
>> > installer):
>> >
>> > CONFIG_FB_OF=y
>> > CONFIG_VT_HW_CONSOLE_BINDING=y
>> > CONFIG_FB_RADEON=m
>> >
>> > The offb driver takes precedence over module radeonfb. It is then
>> > impossible to load the module, error reported is:
>> >
>> > [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> > [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
>> > 0x9800-0x9fff pref]
>> > [   96.551531] radeonfb (:00:10.0): cannot request region 0.
>> > [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
>> >
>> > This patch reproduce the behavior of the module radeon, so as to make it
>> > possible to load radeonfb when offb is first loaded.
>> >
>> > It should be noticed that `offb_destroy` is never called which explain the
>> > need to skip error detection on the radeon side.
>>
>> This still needs to be explained more, from my last mail:
>>
>> "The last put_fb_info() on fb_info should call ->fb_destroy
>> (offb_destroy in our case) and remove_conflicting_framebuffers()
>> is calling put_fb_info() so there is some extra reference on
>> fb_info somewhere preventing it from going away.
>>
>> Please look into fixing this."
>
> My impression of that problem is that the offb driver is in use because
> it is running the console, and until the radeonfb driver is loaded and
> ready to take over, you can't stop using the offb driver, but you can't
> currently load the radeonfb because offb is holding resources it wants.
>
> Maybe I have misunderstood what the code is doing, but that seems to be
> the problem.
>
> On an x86 PC you could drop one fb and go to text mode then start another
> fb driver.  PPC doesn't have that option since there is no text mode.

For reference my patch was inspired by commit:

https://github.com/torvalds/linux/commit/a56f7428d7534f162fbb089c5c79012bf38a7c29

While doing the search, I discover my patch is incorrect, I need to
integrate change from:

https://github.com/torvalds/linux/commit/44adece57e2604cec8527a499b48e4d584ab53b8#diff-767fb253c0135686111755f394d64199

So I'll submit a v4 anyway.

Thanks all,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Lennart Sorensen]

On Wed, Jan 03, 2018 at 03:47:35PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
> > When the linux kernel is build with (typical kernel ship with Debian
> > installer):
> > 
> > CONFIG_FB_OF=y
> > CONFIG_VT_HW_CONSOLE_BINDING=y
> > CONFIG_FB_RADEON=m
> > 
> > The offb driver takes precedence over module radeonfb. It is then
> > impossible to load the module, error reported is:
> > 
> > [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> > [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
> > 0x9800-0x9fff pref]
> > [   96.551531] radeonfb (:00:10.0): cannot request region 0.
> > [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
> > 
> > This patch reproduce the behavior of the module radeon, so as to make it
> > possible to load radeonfb when offb is first loaded.
> > 
> > It should be noticed that `offb_destroy` is never called which explain the
> > need to skip error detection on the radeon side.
> 
> This still needs to be explained more, from my last mail:
> 
> "The last put_fb_info() on fb_info should call ->fb_destroy
> (offb_destroy in our case) and remove_conflicting_framebuffers()
> is calling put_fb_info() so there is some extra reference on
> fb_info somewhere preventing it from going away.
> 
> Please look into fixing this."

My impression of that problem is that the offb driver is in use because
it is running the console, and until the radeonfb driver is loaded and
ready to take over, you can't stop using the offb driver, but you can't
currently load the radeonfb because offb is holding resources it wants.

Maybe I have misunderstood what the code is doing, but that seems to be
the problem.

On an x86 PC you could drop one fb and go to text mode then start another
fb driver.  PPC doesn't have that option since there is no text mode.

-- 
Len Sorensen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Bartlomiej Zolnierkiewicz]

On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
> When the linux kernel is build with (typical kernel ship with Debian
> installer):
> 
> CONFIG_FB_OF=y
> CONFIG_VT_HW_CONSOLE_BINDING=y
> CONFIG_FB_RADEON=m
> 
> The offb driver takes precedence over module radeonfb. It is then
> impossible to load the module, error reported is:
> 
> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
> 0x9800-0x9fff pref]
> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
> 
> This patch reproduce the behavior of the module radeon, so as to make it
> possible to load radeonfb when offb is first loaded.
> 
> It should be noticed that `offb_destroy` is never called which explain the
> need to skip error detection on the radeon side.

This still needs to be explained more, from my last mail:

"The last put_fb_info() on fb_info should call ->fb_destroy
(offb_destroy in our case) and remove_conflicting_framebuffers()
is calling put_fb_info() so there is some extra reference on
fb_info somewhere preventing it from going away.

Please look into fixing this."

> Signed-off-by: Mathieu Malaterre 
> Link: https://bugs.debian.org/826629#57
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
> Suggested-by: Lennart Sorensen 
> ---
> v2: Only fails when CONFIG_PCC is not set
> v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since 
> the conflicts in region is due to OFfb explicitly refers to it.

It seems that there may still be configurations when this is
incorrect -> when offb drives primary (non-radeon) card and radeonfb
drives secondary (radeon) card..

>  drivers/video/fbdev/aty/radeon_base.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/video/fbdev/aty/radeon_base.c 
> b/drivers/video/fbdev/aty/radeon_base.c
> index 4d77daeecf99..221879196531 100644
> --- a/drivers/video/fbdev/aty/radeon_base.c
> +++ b/drivers/video/fbdev/aty/radeon_base.c
> @@ -2259,6 +2259,22 @@ static const 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)
> @@ -2312,19 +2328,27 @@ 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) {
> +#ifndef CONFIG_FB_OF
>   printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
>   pci_name(rinfo->pdev));
>   goto err_release_fb;
> +#endif
>   }
>  
>   ret = pci_request_region(pdev, 2, "radeonfb mmio");
>   if (ret < 0) {
> +#ifndef CONFIG_FB_OF
>   printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
>   pci_name(rinfo->pdev));
>   goto err_release_pci0;
> +#endif
>   }
>  
>   /* map the regions */
> @@ -2509,10 +2533,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
>   iounmap(rinfo->mmio_base);
>  err_release_pci2:
>   pci_release_region(pdev, 2);
> +#ifndef CONFIG_FB_OF
>  err_release_pci0:
>   pci_release_region(pdev, 0);
>  err_release_fb:
>  framebuffer_release(info);
> +#endif
>  err_disable:
>  err_out:
>   return ret;

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

When the linux kernel is build with (typical kernel ship with Debian
installer):

CONFIG_FB_OF=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_FB_RADEON=m

The offb driver takes precedence over module radeonfb. It is then
impossible to load the module, error reported is:

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

This patch reproduce the behavior of the module radeon, so as to make it
possible to load radeonfb when offb is first loaded.

It should be noticed that `offb_destroy` is never called which explain the
need to skip error detection on the radeon side.

Signed-off-by: Mathieu Malaterre 
Link: https://bugs.debian.org/826629#57
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
Suggested-by: Lennart Sorensen 
---
v2: Only fails when CONFIG_PCC is not set
v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since 
the conflicts in region is due to OFfb explicitly refers to it.

 drivers/video/fbdev/aty/radeon_base.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/video/fbdev/aty/radeon_base.c 
b/drivers/video/fbdev/aty/radeon_base.c
index 4d77daeecf99..221879196531 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2259,6 +2259,22 @@ static const 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)
@@ -2312,19 +2328,27 @@ 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) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
goto err_release_fb;
+#endif
}
 
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
goto err_release_pci0;
+#endif
}
 
/* map the regions */
@@ -2509,10 +2533,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
iounmap(rinfo->mmio_base);
 err_release_pci2:
pci_release_region(pdev, 2);
+#ifndef CONFIG_FB_OF
 err_release_pci0:
pci_release_region(pdev, 0);
 err_release_fb:
 framebuffer_release(info);
+#endif
 err_disable:
 err_out:
return ret;
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel