| Message ID | 20180302090948.6399-1-linus.walleij@linaro.org |
|---|---|
| Headers | show |
| Series | drm/pl111: RealView and Versatile Express | expand |
Hi Linus, On 02/03/18 09:09, Linus Walleij wrote: > This is the base for finally getting RealView and Versatile > Express supported in the PL111 DRM driver. > > We have then moved all the way up from the first ARM > Integrator versions to the last Versatile Express reference > designs using PL111. > > After this, forked hardware such as Nomadik and SPEAr > remains to be moved over. > > Some infrastructure for adjusting depth (ARGB5551) etc > on the Integrator and some bridge fixups are still needed > but this is the core of the support for these platforms > and the rest can be done on top before switching over. > > Also the Versatile Express CLCD on the motherboard has > a dedicated video memory, and cannot use CMA (ha! complex!) > and I will need to figure out a way to work around that. > The CLCDs synthesized on the core tiles for CA9 work > fine with this though. Out of curiosity, what's the issue with declaring the VRAM as a CMA region? That's certainly worked for stuff like local RAM on FPGA tiles in the past, and I can't think offhand of any way in which VExpress is wildly different (but I am of course open to being wrong...) Robin. > Linus Walleij (4): > drm/pl111: Make the default BPP a per-variant variable > drm/pl111: Use max memory bandwidth for resolution > drm/pl111: Handle the RealView variant separately > drm/pl111: Support the Versatile Express > > drivers/gpu/drm/pl111/Makefile | 1 + > drivers/gpu/drm/pl111/pl111_display.c | 36 +++++++++++ > drivers/gpu/drm/pl111/pl111_drm.h | 6 +- > drivers/gpu/drm/pl111/pl111_drv.c | 10 ++- > drivers/gpu/drm/pl111/pl111_versatile.c | 80 +++++++++++++++++++++++- > drivers/gpu/drm/pl111/pl111_vexpress.c | 106 ++++++++++++++++++++++++++++++++ > drivers/gpu/drm/pl111/pl111_vexpress.h | 22 +++++++ > 7 files changed, 258 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c > create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h >
On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.murphy@arm.com> wrote: > On 02/03/18 09:09, Linus Walleij wrote: >> Also the Versatile Express CLCD on the motherboard has >> a dedicated video memory, and cannot use CMA (ha! complex!) >> and I will need to figure out a way to work around that. >> The CLCDs synthesized on the core tiles for CA9 work >> fine with this though. > > Out of curiosity, what's the issue with declaring the VRAM as a CMA region? > That's certainly worked for stuff like local RAM on FPGA tiles in the past, > and I can't think offhand of any way in which VExpress is wildly different > (but I am of course open to being wrong...) There is nothing wrong with that apart from my ignorance of that solution. So thanks! :D My experience with CMA is limited to using the 7 areas that are defined by default in Kconfig and the DRM helpers just plugging in on the front. Do you have some pointers? Is this something I can handily just set up in the device tree? Yours, Linus Walleij
On 02/03/18 12:37, Linus Walleij wrote: > On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.murphy@arm.com> wrote: >> On 02/03/18 09:09, Linus Walleij wrote: > >>> Also the Versatile Express CLCD on the motherboard has >>> a dedicated video memory, and cannot use CMA (ha! complex!) >>> and I will need to figure out a way to work around that. >>> The CLCDs synthesized on the core tiles for CA9 work >>> fine with this though. >> >> Out of curiosity, what's the issue with declaring the VRAM as a CMA region? >> That's certainly worked for stuff like local RAM on FPGA tiles in the past, >> and I can't think offhand of any way in which VExpress is wildly different >> (but I am of course open to being wrong...) > > There is nothing wrong with that apart from my ignorance > of that solution. So thanks! :D > > My experience with CMA is limited to using the 7 areas > that are defined by default in Kconfig and the DRM helpers > just plugging in on the front. > > Do you have some pointers? Is this something I can > handily just set up in the device tree? It should be - the inner workings of dma-{coherent,contiguous} are a maze of twisty little passages, all alike, and it'll take me a while to page the details back in, but IIRC it's mostly just a case of having a reserved-memory node covering the VRAM with the right combination of magic properties for rmem_dma_setup() to pick up, such that it gets assigned as the CLCD's private region. The subsequent "just plugging in" aspect doesn't change, it just makes allocations start taking this route under the covers: drm_gem_cma_create() dma_alloc_wc() dma_alloc_attrs() dma_alloc_from_dev_coherent() I could have sworn I've exchanged relevant FPGA DT fragments with Liviu in the past, but now I can't seem to find one to refer back to :( Robin.
On Fri, Mar 02, 2018 at 01:50:20PM +0000, Robin Murphy wrote: > On 02/03/18 12:37, Linus Walleij wrote: > > On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.murphy@arm.com> wrote: > > > On 02/03/18 09:09, Linus Walleij wrote: > > > > > > Also the Versatile Express CLCD on the motherboard has > > > > a dedicated video memory, and cannot use CMA (ha! complex!) > > > > and I will need to figure out a way to work around that. > > > > The CLCDs synthesized on the core tiles for CA9 work > > > > fine with this though. > > > > > > Out of curiosity, what's the issue with declaring the VRAM as a CMA region? > > > That's certainly worked for stuff like local RAM on FPGA tiles in the past, > > > and I can't think offhand of any way in which VExpress is wildly different > > > (but I am of course open to being wrong...) > > > > There is nothing wrong with that apart from my ignorance > > of that solution. So thanks! :D > > > > My experience with CMA is limited to using the 7 areas > > that are defined by default in Kconfig and the DRM helpers > > just plugging in on the front. > > > > Do you have some pointers? Is this something I can > > handily just set up in the device tree? > > It should be - the inner workings of dma-{coherent,contiguous} are a maze of > twisty little passages, all alike, and it'll take me a while to page the > details back in, but IIRC it's mostly just a case of having a > reserved-memory node covering the VRAM with the right combination of magic > properties for rmem_dma_setup() to pick up, such that it gets assigned as > the CLCD's private region. The subsequent "just plugging in" aspect doesn't > change, it just makes allocations start taking this route under the covers: > > drm_gem_cma_create() > dma_alloc_wc() > dma_alloc_attrs() > dma_alloc_from_dev_coherent() > > I could have sworn I've exchanged relevant FPGA DT fragments with Liviu in > the past, but now I can't seem to find one to refer back to :( Maybe something line this: https://github.com/ARM-software/linux/blob/development/malidp/arch/arm64/boot/dts/arm/juno-base.dtsi#L792 And look at line 855 for the possible use of it. That is how we currently make CMA allocate buffers in FPGA for the Mali DP "hardware" (bitstream on FPGA) that we have in Juno. Best regards, Liviu > > Robin.