LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Maxime Ripard <email@example.com> To: Paul Kocialkowski <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Mauro Carvalho Chehab <firstname.lastname@example.org>, Rob Herring <email@example.com>, Mark Rutland <firstname.lastname@example.org>, Chen-Yu Tsai <email@example.com>, Pawel Osciak <firstname.lastname@example.org>, Marek Szyprowski <email@example.com>, Kyungmin Park <firstname.lastname@example.org>, Hans Verkuil <email@example.com>, Sakari Ailus <firstname.lastname@example.org>, Philipp Zabel <email@example.com>, Arnd Bergmann <firstname.lastname@example.org>, Alexandre Courbot <email@example.com>, Tomasz Figa <firstname.lastname@example.org> Subject: Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes Date: Fri, 4 May 2018 17:44:06 +0200 [thread overview] Message-ID: <20180504154406.djxq6wqil3dwutvw@flea> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 5142 bytes --] On Fri, May 04, 2018 at 03:57:48PM +0200, Paul Kocialkowski wrote: > On Fri, 2018-05-04 at 15:40 +0200, Maxime Ripard wrote: > > On Fri, May 04, 2018 at 02:04:38PM +0200, Paul Kocialkowski wrote: > > > On Fri, 2018-05-04 at 11:15 +0200, Maxime Ripard wrote: > > > > On Fri, May 04, 2018 at 10:47:44AM +0200, Paul Kocialkowski wrote: > > > > > > > > > + reg = <0x01c0e000 0x1000>; > > > > > > > > > + memory-region = <&ve_memory>; > > > > > > > > > > > > > > > > Since you made the CMA region the default one, you don't > > > > > > > > need > > > > > > > > to > > > > > > > > tie > > > > > > > > it to that device in particular (and you can drop it being > > > > > > > > mandatory > > > > > > > > from your binding as well). > > > > > > > > > > > > > > What if another driver (or the system) claims memory from > > > > > > > that > > > > > > > zone > > > > > > > and > > > > > > > that the reserved memory ends up not being available for the > > > > > > > VPU > > > > > > > anymore? > > > > > > > > > > > > > > Acccording to the reserved-memory documentation, the > > > > > > > reusable > > > > > > > property > > > > > > > (that we need for dmabuf) puts a limitation that the device > > > > > > > driver > > > > > > > owning the region must be able to reclaim it back. > > > > > > > > > > > > > > How does that work out if the CMA region is not tied to a > > > > > > > driver > > > > > > > in > > > > > > > particular? > > > > > > > > > > > > I'm not sure to get what you're saying. You have the property > > > > > > linux,cma-default in your reserved region, so the behaviour > > > > > > you > > > > > > described is what you explicitly asked for. > > > > > > > > > > My point is that I don't see how the driver can claim back (part > > > > > of) > > > > > the > > > > > reserved area if the area is not explicitly attached to it. > > > > > > > > > > Or is that mechanism made in a way that all drivers wishing to > > > > > use > > > > > the > > > > > reserved memory area can claim it back from the system, but > > > > > there is > > > > > no > > > > > priority (other than first-come first-served) for which drivers > > > > > claims > > > > > it back in case two want to use the same reserved region (in a > > > > > scenario > > > > > where there isn't enough memory to allow both drivers)? > > > > > > > > This is indeed what happens. Reusable is to let the system use the > > > > reserved memory for things like caches that can easily be dropped > > > > when > > > > a driver wants to use the memory in that reserved area. Once that > > > > memory has been allocated, there's no claiming back, unless that > > > > memory segment was freed of course. > > > > > > Thanks for the clarification. So in our case, perhaps the best fit > > > would > > > be to make that area the default CMA pool so that we can be ensured > > > that > > > the whole 96 MiB is available for the VPU and that no other consumer > > > of > > > CMA will use it? > > > > The best fit for what use case ? We already discussed this, and I > > don't see any point in having two separate CMA regions. If you have a > > reasonably sized region that will accomodate for both the VPU and > > display engine, why would we want to split them? > > The use case I have in mind is boilerplate use of the VPU with the > display engine, say with DMAbuf. > > It wasn't exactly clear in my memory whether we had decided that the CMA > pool we use for the VPU should also be used for other CMA consumers (I > realize that this is what we've been doing all along by having > linux,cma-default; though). > > The fact that the memory region will accomodate for both the display > engine and the VPU is not straightforward IMO and I think this has to be > an explicit choice that we take. I was under the impression that we > chose the 96 MiB because that's what the Allwinner reference code does. > Does the reference code also use this pool for display? Yes > I liked the idea of having 96 MiB fully reserved to the VPU because it > allows us to provide a limit on the use case, such as "this guarantees N > buffers for resolution foo in format bar". If the display engine also > uses it, then the limit also depends on how many GEM buffers are > allocated (unless I'm missing something). This also guarantees that you take away a fifth of the RAM on some boards. If we had yet another CMA pool of 64MB as is the multi_v7 defconfig, that's a third of your RAM that's gone, possibly for no particular reason. If we make the math, let's say that we are running a system with 4 planes used in 1080p, with 4 Bpp, in double buffering (which is already an unlikely setup). Let's add on top of that that we're decoding a 1080p video with 8 buffers pre-allocated with 2Bpp (in YUV422). Which really seems extreme now :) And we're at 80MB. My guess is that your memory bus is going to be dead before you need to use all that memory. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-05-04 15:44 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-19 15:41 [PATCH v2 00/10] Sunxi-Cedrus driver for the Allwinner Video Engine, using media requests Paul Kocialkowski 2018-04-19 15:41 ` [PATCH v2 01/10] media: v4l2-ctrls: Add missing v4l2 ctrl unlock Paul Kocialkowski 2018-04-20 7:23 ` Maxime Ripard 2018-04-20 13:38 ` Hans Verkuil 2018-04-19 15:41 ` [PATCH v2 02/10] media-request: Add a request complete operation to allow m2m scheduling Paul Kocialkowski 2018-04-20 7:38 ` Alexandre Courbot 2018-04-20 13:48 ` Hans Verkuil 2018-04-24 8:28 ` Sakari Ailus 2018-05-04 8:03 ` Paul Kocialkowski 2018-04-19 15:41 ` [PATCH v2 03/10] videobuf2-core: Add helper to get buffer private data from media request Paul Kocialkowski 2018-04-20 13:43 ` Hans Verkuil 2018-04-24 8:37 ` Sakari Ailus 2018-05-04 8:03 ` Paul Kocialkowski 2018-04-19 15:41 ` [PATCH v2 04/10] media: vim2m: Implement media request complete op to schedule m2m run Paul Kocialkowski 2018-04-19 15:45 ` [PATCH v2 05/10] media: v4l: Add definitions for MPEG2 frame format and header metadata Paul Kocialkowski 2018-04-20 9:51 ` Tomasz Figa 2018-05-04 8:24 ` Paul Kocialkowski 2018-04-20 13:57 ` Hans Verkuil 2018-05-04 8:22 ` Paul Kocialkowski 2018-04-20 14:00 ` Hans Verkuil 2018-04-24 9:01 ` Sakari Ailus 2018-05-04 8:21 ` Paul Kocialkowski 2018-05-04 8:48 ` Paul Kocialkowski 2018-04-19 15:45 ` [PATCH v2 06/10] media: v4l: Add definition for Allwinner's MB32-tiled NV12 format Paul Kocialkowski 2018-04-20 13:59 ` Hans Verkuil 2018-05-04 7:58 ` Paul Kocialkowski 2018-04-19 15:45 ` [PATCH v2 07/10] media: platform: Add Sunxi-Cedrus VPU decoder driver Paul Kocialkowski 2018-04-24 9:13 ` Sakari Ailus 2018-05-04 7:57 ` Paul Kocialkowski 2018-04-19 15:45 ` [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver Paul Kocialkowski 2018-04-19 16:04 ` Philipp Zabel 2018-04-20 1:31 ` Tomasz Figa 2018-04-20 7:22 ` Paul Kocialkowski 2018-04-27 3:04 ` Rob Herring 2018-05-04 7:56 ` Paul Kocialkowski 2018-05-04 8:12 ` Maxime Ripard 2018-04-27 3:06 ` Rob Herring 2018-04-19 15:45 ` [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes Paul Kocialkowski 2018-04-20 7:39 ` Maxime Ripard 2018-05-04 7:49 ` Paul Kocialkowski 2018-05-04 8:40 ` Maxime Ripard 2018-05-04 8:47 ` Paul Kocialkowski 2018-05-04 8:54 ` Paul Kocialkowski 2018-05-04 9:15 ` Maxime Ripard 2018-05-04 12:04 ` Paul Kocialkowski 2018-05-04 13:40 ` Maxime Ripard 2018-05-04 13:57 ` Paul Kocialkowski 2018-05-04 15:44 ` Maxime Ripard [this message] 2018-04-19 15:45 ` [PATCH v2 10/10] ARM: dts: sun8i-a33: " Paul Kocialkowski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180504154406.djxq6wqil3dwutvw@flea \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).