Announcement

Collapse
No announcement yet.

VC4 DRM Driver Gets Patched For BCM2711 / Raspberry Pi 4 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • VC4 DRM Driver Gets Patched For BCM2711 / Raspberry Pi 4 Support

    Phoronix: VC4 DRM Driver Gets Patched For BCM2711 / Raspberry Pi 4 Support

    While the Linux 5.5 kernel landed Broadcom BCM2711 SoC and Raspberry Pi 4 enablement, one of the loose ends has been getting the open-source "VC4" DRM driver wired up for the display hardware on this latest Raspberry Pi. Patches are now pending for VC4 DRM to provide that display support and could potentially see it mainlined for Linux 5.7...

    http://www.phoronix.com/scan.php?pag...C4-DRM-Support

  • #2
    It there already possible to compile a *mainline/stable* kernel, and boot it up on rpi4?
    Are there drivers in the mainline kernel for it?

    AFAIK, only the bsp kernels from raspberrypi do the job..

    Comment


    • #3
      Typo:

      Originally posted by phoronix View Post
      With these patches that add around three thousand lines ofn ew driver code and rework another thousand lines,

      Comment


      • #4
        Does the pi4 somehow has it's own closed source drivers different from these? Since it can just boot their own kernel, I assume these drivers are not the same?

        Comment


        • #5
          Originally posted by peterdk View Post
          Does the pi4 somehow has it's own closed source drivers different from these? Since it can just boot their own kernel, I assume these drivers are not the same?
          The impression I get is that they already have open-source patches on offer and this is about getting them cleaned up and into upstream.

          Comment


          • #6
            Originally posted by ssokolow View Post

            The impression I get is that they already have open-source patches on offer and this is about getting them cleaned up and into upstream.
            Seems weird. Everyone knows the RPi has the best open source GPU support when it comes to SBCs.

            Comment


            • #7
              Originally posted by caligula View Post

              Seems weird. Everyone knows the RPi has the best open source GPU support when it comes to SBCs.
              By "cleaned up", I just meant that it's always possible the kernel maintainers will want changes made before accepting them upstream. You can never anticipate everything perfectly.

              Comment


              • #8
                Originally posted by peterdk View Post
                Does the pi4 somehow has it's own closed source drivers different from these? Since it can just boot their own kernel, I assume these drivers are not the same?
                but why you assume those drivers are closed source? you can't have closed source drivers for gpl2 kernel

                Comment


                • #9
                  Originally posted by pal666 View Post
                  but why you assume those drivers are closed source? you can't have closed source drivers for gpl2 kernel
                  well his question makes sense..

                  With the lot of microcode.bin,fixs*,start*.elf present in raspberry pi, and also firmware blobs around, the question is pertinent..
                  If it wasn't that way,
                  You could go to mainline kernel and build a kernel for raspberrypi lets say 4..
                  But something holds you back.. and people have valid questions about it..

                  Also there are a lot of drivers proprietary, Nvidia is one of the company's that usually release them, and besides, nothing holds you back of using a lgpl api to talk to your proprietary code in the backend..
                  If that was the case, we never had proprietary drivers

                  But the real question was about,
                  If Raspberry Pi drivers are open, and if so, why are they not in Mainline Kernel..?

                  Comment


                  • #10
                    Raspberry Pi Trading maintain their own kernel trees. It looks like this works quite well for them. Their trees contain various bits and pieces of code which aren't going to be easily mainline-able, after all. So there simply isn't much pressure to mainline stuff, they do it slowly and incrementally.

                    Comment

                    Working...
                    X