[opensuse-arm] RPi 3 video requires CMA memory which is not automatically configures
Hello, for testing I installed stable and master kernel on Leap 42.3 E20 image. Initially it would work fine but later I would have to add cma=256MB (some random value found on a forum) to kernel commandline for video output to work. Has the cma requirement changed as a result of recent vc4 changes? Can the kernel allocate the required size automatically? The vc4 has probably some configuration in devicetree. As I understand it the devicetree is taken from some place other than the kernel. Is this devicetree ever updated after copying the image to the SD card? Thanks Michal -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25.12.17 18:36, Michal Suchánek wrote:
Hello,
for testing I installed stable and master kernel on Leap 42.3 E20 image.
Initially it would work fine but later I would have to add cma=256MB (some random value found on a forum) to kernel commandline for video output to work.
Has the cma requirement changed as a result of recent vc4 changes?
No, it's always been there. In the early days we had a default CMA size of 64MB IIRC, but given that a good number of platforms don't need any CMA space at all, it seemed like a wasted allocation. For the RPi, we added a CMA command line parameter to the kiwi file to override the default 0MB allocation. Maybe something went wrong and that change never happened in Leap 42.3?
Can the kernel allocate the required size automatically?
Yes, if you tell it on the kernel command line :). Really, CMA is all about reserving a range of memory space for contiguous allocations, so all allocations happening inside that range have to be movable and can be forced to move at any given point in time. I'm not quite sure what the kernel should do more automatically than it already does.
The vc4 has probably some configuration in devicetree. As I understand it the devicetree is taken from some place other than the kernel.
By default we take the device tree from U-Boot. I have changes in progress that would take them one step higher up from the RPi firmware even, so that changes to config.txt actually get populated into the Linux device tree.
Is this devicetree ever updated after copying the image to the SD card?
Yes, it comes from the U-Boot package right now. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon, 25 Dec 2017 22:18:45 +0100 Alexander Graf <agraf@suse.de> wrote:
On 25.12.17 18:36, Michal Suchánek wrote:
Hello,
for testing I installed stable and master kernel on Leap 42.3 E20 image.
Initially it would work fine but later I would have to add cma=256MB (some random value found on a forum) to kernel commandline for video output to work.
Has the cma requirement changed as a result of recent vc4 changes?
No, it's always been there. In the early days we had a default CMA size of 64MB IIRC, but given that a good number of platforms don't need any CMA space at all, it seemed like a wasted allocation.
For the RPi, we added a CMA command line parameter to the kiwi file to override the default 0MB allocation. Maybe something went wrong and that change never happened in Leap 42.3?
Maybe 42.3 dose not really need it because it does not have the driver in the kernel or still has the 64MB default.
Can the kernel allocate the required size automatically?
Yes, if you tell it on the kernel command line :).
I do not have to tell the kernel I have an integrated Intel graphics card and it can still allocate its buffers just fine.
Really, CMA is all about reserving a range of memory space for contiguous allocations, so all allocations happening inside that range have to be movable and can be forced to move at any given point in time.
I'm not quite sure what the kernel should do more automatically than it already does.
Just allocate the buffer whenever there is a vc4 card :) Thanks Michal -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 28.12.2017 um 16:29 schrieb Michal Suchánek:
On Mon, 25 Dec 2017 22:18:45 +0100 Alexander Graf <agraf@suse.de> wrote:
On 25.12.17 18:36, Michal Suchánek wrote:
Hello,
for testing I installed stable and master kernel on Leap 42.3 E20 image.
Initially it would work fine but later I would have to add cma=256MB (some random value found on a forum) to kernel commandline for video output to work.
Has the cma requirement changed as a result of recent vc4 changes?
No, it's always been there. In the early days we had a default CMA size of 64MB IIRC, but given that a good number of platforms don't need any CMA space at all, it seemed like a wasted allocation.
For the RPi, we added a CMA command line parameter to the kiwi file to override the default 0MB allocation. Maybe something went wrong and that change never happened in Leap 42.3?
Maybe 42.3 dose not really need it because it does not have the driver in the kernel or still has the 64MB default.
Can the kernel allocate the required size automatically?
Yes, if you tell it on the kernel command line :).
I do not have to tell the kernel I have an integrated Intel graphics card and it can still allocate its buffers just fine.
Really, CMA is all about reserving a range of memory space for contiguous allocations, so all allocations happening inside that range have to be movable and can be forced to move at any given point in time.
I'm not quite sure what the kernel should do more automatically than it already does.
Just allocate the buffer whenever there is a vc4 card :)
The RPi does not have an IOMMU, so it needs to pre-allocate a contiguous hunk of memory, unlike other Intel or Arm based systems. HTE, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Thu, 28 Dec 2017 16:35:51 +0100 Andreas Färber <afaerber@suse.de> wrote:
Am 28.12.2017 um 16:29 schrieb Michal Suchánek:
On Mon, 25 Dec 2017 22:18:45 +0100 Alexander Graf <agraf@suse.de> wrote:
On 25.12.17 18:36, Michal Suchánek wrote:
Can the kernel allocate the required size automatically?
Yes, if you tell it on the kernel command line :).
I do not have to tell the kernel I have an integrated Intel graphics card and it can still allocate its buffers just fine.
Really, CMA is all about reserving a range of memory space for contiguous allocations, so all allocations happening inside that range have to be movable and can be forced to move at any given point in time.
I'm not quite sure what the kernel should do more automatically than it already does.
Just allocate the buffer whenever there is a vc4 card :)
The RPi does not have an IOMMU, so it needs to pre-allocate a contiguous hunk of memory, unlike other Intel or Arm based systems.
AFAIK the iommu feature on Intel has the marketing name VT-d and there are many Intel systems with perfectly working integrated graphics that don't support VT-d. Also the Intel boards with integraded graphics tend to have a BIOS setting for something like "memory reserved for on-board graphics" and the IGP is not enabled unless some memory is allocated for it. On RPi3 the memory map is fabricated somewhere between u-boot and Linux kernel so is completely under control. Which is of course the excuse to not allocate the IGP buffer and leave that to user configureation. The wonders of fully opensource implementation. It's so customizable that it's even unthinkable to suply a working default :-> So yes, I insist that the buffer for the IGP is allocated even in the case there is no proprietary BIOS and there is only opensource software involved in defining the memory map. Is that too much to ask? Thanks Michal -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Michal, I don't know much about Intel graphics. Am 01.01.2018 um 22:45 schrieb Michal Suchánek:
So yes, I insist that the buffer for the IGP is allocated even in the case there is no proprietary BIOS and there is only opensource software involved in defining the memory map. Is that too much to ask?
You're asking the wrong people! It's not some setting that we're disabling on the openSUSE side. You'll need to speak to upstream Linux, U-Boot and possibly Raspberry Pi Foundation - and I doubt they'll care about what you insist on. As you say, most of it is Open Source, so if you need a feature, you can contribute it yourself instead of asking other people to do it for you. config.txt has some memory reservation settings, but I guess they get ignored somewhere - figuring out where might be a first step. And keep in mind that the RPi3 only has 1 GB RAM in whole, so whatever you reserve upfront will not be available for applications and will require/cause swapping. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Monday, January 1, 2018 10:45:24 PM CET Michal Suchánek wrote:
On Thu, 28 Dec 2017 16:35:51 +0100
Andreas Färber <afaerber@suse.de> wrote:
Am 28.12.2017 um 16:29 schrieb Michal Suchánek:
On Mon, 25 Dec 2017 22:18:45 +0100
Alexander Graf <agraf@suse.de> wrote:
On 25.12.17 18:36, Michal Suchánek wrote:
Can the kernel allocate the required size automatically?
Yes, if you tell it on the kernel command line :).
I do not have to tell the kernel I have an integrated Intel graphics card and it can still allocate its buffers just fine.
Really, CMA is all about reserving a range of memory space for contiguous allocations, so all allocations happening inside that range have to be movable and can be forced to move at any given point in time.
I'm not quite sure what the kernel should do more automatically than it already does.
Just allocate the buffer whenever there is a vc4 card :)
The RPi does not have an IOMMU, so it needs to pre-allocate a contiguous hunk of memory, unlike other Intel or Arm based systems.
AFAIK the iommu feature on Intel has the marketing name VT-d and there are many Intel systems with perfectly working integrated graphics that don't support VT-d.
Although a platform IOMMU is quite recent for Intel x86, address translation for graphics has been around for much longer. From https://bwidawsk.net/blog/index.php/2014/06/the-global-gtt-part-1/ --- What are the Global Graphics Translation Table The graphics translation tables provide the address mapping from the GPU’s virtual address space to a physical address. The GTT is somewhat a relic of the AGP days ( GART) with the distinction being that the GTT as it pertains to Intel GEN GPUs has logic that is contained within the GPU, and does not act as a platform IOMMU. I believe (and wikipedia seems to agree) that GTT and GART were used interchangeably in the AGP days. ---
Also the Intel boards with integraded graphics tend to have a BIOS setting for something like "memory reserved for on-board graphics" and the IGP is not enabled unless some memory is allocated for it. On RPi3 the memory map is fabricated somewhere between u-boot and Linux kernel so is completely under control. Which is of course the excuse to not allocate the IGP buffer and leave that to user configureation. The wonders of fully opensource implementation. It's so customizable that it's even unthinkable to suply a working default :->
There is no working default. Some people use the RPI3 headless and need no graphics memory at all, while others use it as a gaming console and need 256 MB. Contrary to other current systems, the memory has to be contigous and can not be freed after allocation.
So yes, I insist that the buffer for the IGP is allocated even in the case there is no proprietary BIOS and there is only opensource software involved in defining the memory map. Is that too much to ask?
IMHO your tone is too much. If you want something, provide patches. If you are not able to do that, ask kindly. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
participants (4)
-
Alexander Graf -
Andreas Färber -
Michal Suchánek -
Stefan Brüns