64-bit 5.4 kernel shows a page_alloc warning in bcm2708_fb if no display attached #3598
Comments
|
The warning is caused by attempting to allocate a zero-sized framebuffer, which gets surprisingly far down the stack. @6by9 This used to result in a sequence like this: which still isn't great, but it's better than a backtrace. Since we have no idea how large to make the image, and there's no way to get the image displayed if a cable is eventually plugged in, I think it's preferable to bail out early (the line numbers will be out because of additional debug code): @@ -1104,10 +1105,9 @@ static int bcm2708_fb_probe(struct platform_device *dev)
* set one display
*/
if (ret || num_displays == 0) {
- num_displays = 1;
dev_err(&dev->dev,
- "Unable to determine number of FB's. Assuming 1\n");
- ret = 0;
+ "Unable to determine number of FBs. Disabling driver.\n");
+ return -ENOENT;
} else {
fbdev->firmware_supports_multifb = 1;
} |
|
This was @JamesH65 's code, but if we have the option of bailing out, then that seems reasonable to me. |
|
Not sure why I defaulted to one, I suspect I either wasn't thinking about the no display at all use case, or I was considering backwards compatibility - ISTR it was one before the changes for multi displays. |
|
We had reverted the patch that did a CMA / dma_alloc_coherent allocation for the frame buffer, and went back to relying on a reloc heap allocation for it. That was part of trying to reduce reloc heap usage, but we didn't resolve what to do should the CMA heap be insufficient for the FB. |
|
For what it is worth, I have noticed this when |
That implies something is wrong in the DT config. Both of those should disable the framebuffer node that loads bcm2708_fb. |
pelwell
added a commit
that referenced
this issue
May 5, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
|
The initial issue should be solved by the commit "video: bcm2708_fb: Disable FB if no displays found". |
|
Apologies. The warning is only shown on 64-bit 5.4 kernel if vc4-fkms-v3d is not loaded. I was mistaken when I said I hadn't altered /boot/config.txt apart from enabling 64-bit mode. |
|
@satmandu Are you sure? I'm not seeing any problem with either vc4-kms-v3d or vc4-fkms-v3d on either 5.4 or 5.6 - only when neither overlay is selected, and that is solved by the recent commit. |
pelwell
added a commit
that referenced
this issue
May 5, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
|
@pelwell With the caveat that this is a slightly modified kernel, the issue was still there as of earlier today: (I'll try with the new commit and see what happens.) |
|
If you don't mind a bit of testing, could you try with vc4-kms-v3d-pi4 instead? I suspect that either your firmware is old or your build system hasn't included overlay_map.dtb in the overlays directory, meaning that it can't load the Pi 4-specific overlay automatically. You can also debug this by reverting the patch and using |
|
Actually, you don't even need to revert my patch - the presence of any bcm2708_fb messages in the log suggests that the vc4-kms-v3d(-pi4) hasn't been applied correctly. |
|
@pelwell Here's my log output: https://paste.ubuntu.com/p/SVbqwbbXSJ/ |
So you've used vc4-kms-v3d-pi4, and the problem has gone away - no mention of the frame buffer, and the v3d driver can be seen initialising. Your firmware is too old to be using vc4-kms-v3d, but vc4-kms-v3d-pi4 is a good substitute until you update. |
|
@pelwell Here's what I see with the current 5.4 kernel8.img on the May 1st Firmware: https://paste.ubuntu.com/p/btwT6StMkj/ With the May 1st Firmware and a newer kernel, I no longer get those issues: https://paste.ubuntu.com/p/YrDRfjptdh/ |
popcornmix
pushed a commit
that referenced
this issue
May 11, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this issue
May 12, 2020
kernel: vc4_hdmi: Add CEC support for 2711 See: raspberrypi/linux#3601 kernel: overlays: Move fixed-clock nodes to the root See: raspberrypi/linux#3607 kernel: bcm2835_isp fixes for constness See: raspberrypi/linux#3592 kernel: video: bcm2708_fb: Disable FB if no displays found See: raspberrypi/linux#3598 kernel: vc4_hdmi_phy: Fix typo in phy_get_cp_current See: raspberrypi/linux#3594 kernel: configs: Add missing TOUCHSCREEN_RASPBERRYPI_FW=m See: Hexxeh/rpi-firmware#223 kernel: configs: Add missing PPS configs See: raspberrypi/linux#3593 kernel: overlays: gpio-keys: Avoid open-drain warnings See: #1381 kernel: overlays: Make the i2c-gpio overlay safe again kernel: ARM: dts: bcm2711: Allow 40-bit DMA for SPI See: raspberrypi/linux#3570 firmware: In KMS mode, prevent use of the firmware rotations firmware: power: Adjust ARM:AXI divider ratio if ARM freq > 1500 MHz firmware: imx477: Remove STILLS flag from 720p mode userland: tvservice: Fix freeze on old firmware
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this issue
May 12, 2020
kernel: vc4_hdmi: Add CEC support for 2711 See: raspberrypi/linux#3601 kernel: overlays: Move fixed-clock nodes to the root See: raspberrypi/linux#3607 kernel: bcm2835_isp fixes for constness See: raspberrypi/linux#3592 kernel: video: bcm2708_fb: Disable FB if no displays found See: raspberrypi/linux#3598 kernel: vc4_hdmi_phy: Fix typo in phy_get_cp_current See: raspberrypi/linux#3594 kernel: configs: Add missing TOUCHSCREEN_RASPBERRYPI_FW=m See: #223 kernel: configs: Add missing PPS configs See: raspberrypi/linux#3593 kernel: overlays: gpio-keys: Avoid open-drain warnings See: raspberrypi/firmware#1381 kernel: overlays: Make the i2c-gpio overlay safe again kernel: ARM: dts: bcm2711: Allow 40-bit DMA for SPI See: raspberrypi/linux#3570 firmware: In KMS mode, prevent use of the firmware rotations firmware: power: Adjust ARM:AXI divider ratio if ARM freq > 1500 MHz firmware: imx477: Remove STILLS flag from 720p mode userland: tvservice: Fix freeze on old firmware
popcornmix
pushed a commit
that referenced
this issue
May 20, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
May 20, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Jun 3, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Jun 3, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Jun 3, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this issue
Jun 8, 2020
Source: kernel.org MR: 103889 Type: Enhancement Disposition: Merged from https://github.com/raspberrypi/linux.git rpi-5.4.y ChangeID: e005a4db95a48e8b14a2017bf56a0e3f3dccfa6d Description: If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: raspberrypi/linux#3598 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Corey Minyard <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Jun 10, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Jun 10, 2020
If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Aug 27, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Aug 30, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Aug 30, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Sep 2, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Sep 6, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Sep 10, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Sep 10, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Sep 12, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Sep 16, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 2, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 2, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 7, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 10, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 10, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 14, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 14, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 17, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 21, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 23, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Oct 28, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 1, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 5, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 6, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 8, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 11, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 18, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 18, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 18, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 25, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
popcornmix
added a commit
that referenced
this issue
Nov 25, 2024
Signed-off-by: popcornmix <[email protected]> bcm2708_fb : Implement blanking support using the mailbox property interface bcm2708_fb: Add pan and vsync controls bcm2708_fb: DMA acceleration for fb_copyarea Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425 Also used Simon's dmaer_master module as a reference for tweaking DMA settings for better performance. For now busylooping only. IRQ support might be added later. With non-overclocked Raspberry Pi, the performance is ~360 MB/s for simple copy or ~260 MB/s for two-pass copy (used when dragging windows to the right). In the case of using DMA channel 0, the performance improves to ~440 MB/s. For comparison, VFP optimized CPU copy can only do ~114 MB/s in the same conditions (hindered by reading uncached source buffer). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: report number of dma copies Add a counter (exported via debugfs) reporting the number of dma copies that the framebuffer driver has done, in order to help evaluate different optimization strategies. Signed-off-by: Luke Diamand <[email protected]> bcm2708_fb: use IRQ for DMA copies The copyarea ioctl() uses DMA to speed things along. This was busy-waiting for completion. This change supports using an interrupt instead for larger transfers. For small transfers, busy-waiting is still likely to be faster. Signed-off-by: Luke Diamand <[email protected]> bcm2708: Make ioctl logging quieter video: fbdev: bcm2708_fb: Don't panic on error No need to panic the kernel if the video driver fails. Just print a message and return an error. Signed-off-by: Noralf Trønnes <[email protected]> fbdev: bcm2708_fb: Add ARCH_BCM2835 support Add Device Tree support. Pass the device to dma_alloc_coherent() in order to get the correct bus address on ARCH_BCM2835. Use the new DMA legacy API header file. Including <mach/platform.h> is not necessary. Signed-off-by: Noralf Trønnes <[email protected]> BCM270x_DT: Add bcm2708-fb device Add bcm2708-fb to Device Tree and don't add the platform device when booting in DT mode. Signed-off-by: Noralf Trønnes <[email protected]> Cleanup of bcm2708_fb file to kernel coding standards Some minor change to function - remove a use of in_atomic, plus replacing various debug messages that manually specify the function name with ("%s",.__func__) Signed-off-by: James Hughes <[email protected]> video: bcm2708_fb: Try allocating on the ARM and passing to VPU Currently the VPU allocates the contiguous buffer for the framebuffer. Try an alternate path first where we use dma_alloc_coherent and pass the buffer to the VPU. Should the VPU firmware not support that path, then free the buffer and revert to the old behaviour of using the VPU allocation. Signed-off-by: Dave Stevenson <[email protected]> Pulled in the multi frame buffer support from the Pi3 repo fbdev: add FBIOCOPYAREA ioctl Based on the patch authored by Ali Gholami Rudi at https://lkml.org/lkml/2009/7/13/153 Provide an ioctl for userspace applications, but only if this operation is hardware accelerated (otherwide it does not make any sense). Signed-off-by: Siarhei Siamashka <[email protected]> bcm2708_fb: Add ioctl for reading gpu memory through dma video: bcm2708_fb: Add compat_ioctl support. When using a 64 bit kernel with 32 bit userspace we need compat ioctl handling for FBIODMACOPY as one of the parameters is a pointer. Signed-off-by: Dave Stevenson <[email protected]> video: fbdev: bcm2708_fb: Use common compat header The definition of compat_ptr is now common for most platforms, but requires the inclusion of <linux/compat.h>. Signed-off-by: Phil Elwell <[email protected]> video: bcm2708_fb: Disable FB if no displays found If the firmware hasn't detected a display, the driver would assume one display was available, but because it had failed to retrieve the display size it would try to allocate a zero-sized buffer. Avoid the allocation failure by bailing out early if no display is found. See: #3598 Signed-off-by: Phil Elwell <[email protected]> bcm2708_fb: Fix a build warning Signed-off-by: Phil Elwell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
64-bit 5.4 kernel shows a __alloc_pages_nodemask warning for invalid order in bcm2708_fb if no display attached. 32-bit 5.4 kernel, forcing HDMI output or attaching a display will avoid this warning.
Size of GPU RAM allocation doesn't affect it. It will give the warning whether you have 16MB or 64MB.
To reproduce
Use 64-bit 5.4 kernel on a Pi 4 with no HDMI display and no hdmi_force_hot_plug=1. Warning shown in dmesg. Comment out dtoverlay=vc4-fkms-v3d in [pi4] and set arm_64bit=1
Expected behaviour
Actual behaviour
System
Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
Raspberry Pi 4 Model B Rev 1.1
Which OS and version (
cat /etc/rpi-issue)?Raspbian Buster
Which firmware version (
vcgencmd version)?Apr 27 2020 22:29:47
Copyright (c) 2012 Broadcom
version 3a8f1793b758d6fb7f375edaa260e069ecd34c88 (clean) (release) (start)
Which kernel version (
uname -a)?Linux zinc 5.4.35-v8+ Pi3B wifi brcmf_sdio_hdparse #1313 SMP PREEMPT Mon Apr 27 22:28:43 BST 2020 aarch64 GNU/Linux
Logs
The text was updated successfully, but these errors were encountered: