diff for duplicates of <20240228-nifty-flashy-shrew-905edc@houat> diff --git a/a/1.txt b/N1/1.txt index 1f4380d..80ad36c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,32 +1,40 @@ -Hi, +On Tue, Feb 27, 2024 at 07:45:01PM -0300, Maíra Canal wrote: +> Hi Maxime, +> +> On 2/27/24 10:02, Maxime Ripard wrote: +> > Hi Maíra, +> > +> > Thanks for you reviews! +> > +> > On Mon, Feb 26, 2024 at 09:29:32AM -0300, Maíra Canal wrote: +> > > On 2/22/24 15:14, Maxime Ripard wrote: +> > > > The vc4_dummy_plane structure is an exact equivalent to vc4_plane, so we +> > > +> > > Maybe I understood incorrectly, but isn't the vc4_dummy_plane structure +> > > equivalent to drm_plane? +> > +> > Both statements are true :) +> > +> > vc4 itself uses vc4_plane to holds its plane-related content, but it +> > turns out that there's nothing in that structure anymore and vc4_plane +> > == drm_plane. +> > +> > In our mock driver, we have another structure meant to store the +> > mock-plane-related content which doesn't have anything in it anymore, +> > and is thus equivalent to vc4_plane. +> > +> > So, basically, vc4_dummy_plane == vc4_plane == drm_plane. +> > +> > This patch is only about getting rid of vc4_dummy_plane though. +> > +> > Is it clearer? +> > +> +> Yeah, with that pointed out, you can add my: -I'm currently working on a platform that seems to have togglable RAM ECC -support. Enabling ECC reduces the memory capacity and memory bandwidth, -so while it's a good idea to protect most of the system, it's not worth -it for things like framebuffers that won't really be affected by a -bitflip. +I'll rephrase for the next version then -It's currently setup by enabling ECC on the entire memory, and then -having a region of memory where ECC is disabled and where we're supposed -to allocate from for allocations that don't need it. - -My first thought to support this was to create a reserved memory region -for the !ECC memory, and to create a heap to allocate buffers from that -region. That would leave the system protected by ECC, while enabling -userspace to be nicer to the system by allocating buffers from the !ECC -region if it doesn't need it. - -However, this creates basically a new combination compared to the one we -already have (ie, physically contiguous vs virtually contiguous), and we -probably would want to throw in cacheable vs non-cacheable too. - -If we had to provide new heaps for each variation, we would have 8 heaps -(and 6 new ones), which could be fine I guess but would still increase -quite a lot the number of heaps we have so far. - -Is it something that would be a problem? If it is, do you see another -way to support those kind of allocations (like providing hints through -the ioctl maybe?)? +> Reviewed-by: Maíra Canal <mcanal@igalia.com> Thanks! Maxime diff --git a/a/2.bin b/N1/2.bin index 4028e4b..340531c 100644 --- a/a/2.bin +++ b/N1/2.bin @@ -1,7 +1,7 @@ -----BEGIN PGP SIGNATURE----- -iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZd9P2AAKCRDj7w1vZxhR -xcseAQDNXhfizqmm5H2uN2EY4Je+TYwTRgFflpibGSH+mgadZQEA/ztn8Tq2H8na -rgGnZua3Ci5jMoTbhctf8Hh0oDZuOw4= -=pw5E +iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZd9ccAAKCRDj7w1vZxhR +xQ/aAQDzU4vVfau883o71TzEeE+lysJ38XPUbtp9Q818fxbvSAD/TfNo9QsQjVLO +TjOhPuL8arGdUmexXtTS6jTunClBzAA= +=6H0O -----END PGP SIGNATURE----- diff --git a/a/content_digest b/N1/content_digest index 8758c17..24f3672 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,46 +1,71 @@ - "From\0Maxime Ripard <mripard@redhat.com>\0" - "Subject\0ECC memory semantics for heaps\0" - "Date\0Wed, 28 Feb 2024 16:23:05 +0100\0" - "To\0Sumit Semwal <sumit.semwal@linaro.org>" - Benjamin Gaignard <benjamin.gaignard@collabora.com> - Brian Starkey <Brian.Starkey@arm.com> - John Stultz <jstultz@google.com> - T.J. Mercier <tjmercier@google.com> - " Christian K\303\266nig <christian.koenig@amd.com>\0" - "Cc\0linux-media@vger.kernel.org" + "ref\020240222-kms-hdmi-connector-state-v7-0-8f4af575fce2@kernel.org\0" + "ref\020240222-kms-hdmi-connector-state-v7-29-8f4af575fce2@kernel.org\0" + "ref\0244fe6b9-f295-4c85-908a-014ada0033fa@igalia.com\0" + "ref\0y7mxj2i56h7bcnonywjdf2eirdqil66k32drw3wb3z7juqr3ph@4u24mlrvxslc\0" + "ref\02693770c-0d27-4186-87e1-e55a0a5f17a5@igalia.com\0" + "From\0Maxime Ripard <mripard@kernel.org>\0" + "Subject\0Re: [PATCH v7 29/36] drm/vc4: tests: Remove vc4_dummy_plane structure\0" + "Date\0Wed, 28 Feb 2024 17:16:48 +0100\0" + "To\0Ma\303\255ra Canal <mcanal@igalia.com>\0" + "Cc\0Maarten Lankhorst <maarten.lankhorst@linux.intel.com>" + Thomas Zimmermann <tzimmermann@suse.de> + David Airlie <airlied@gmail.com> + Daniel Vetter <daniel@ffwll.ch> + Jonathan Corbet <corbet@lwn.net> + Sandy Huang <hjc@rock-chips.com> + " Heiko St\303\274bner <heiko@sntech.de>" + Chen-Yu Tsai <wens@csie.org> + Jernej Skrabec <jernej.skrabec@gmail.com> + Samuel Holland <samuel@sholland.org> + Hans Verkuil <hverkuil@xs4all.nl> + Sebastian Wick <sebastian.wick@redhat.com> + " Ville Syrj\303\244l\303\244 <ville.syrjala@linux.intel.com>" dri-devel@lists.freedesktop.org - " linaro-mm-sig@lists.linaro.org\0" + linux-arm-kernel@lists.infradead.org + linux-doc@vger.kernel.org + linux-kernel@vger.kernel.org + linux-media@vger.kernel.org + linux-rockchip@lists.infradead.org + " linux-sunxi@lists.linux.dev\0" "\01:1\0" "b\0" - "Hi,\n" + "On Tue, Feb 27, 2024 at 07:45:01PM -0300, Ma\303\255ra Canal wrote:\n" + "> Hi Maxime,\n" + "> \n" + "> On 2/27/24 10:02, Maxime Ripard wrote:\n" + "> > Hi Ma\303\255ra,\n" + "> > \n" + "> > Thanks for you reviews!\n" + "> > \n" + "> > On Mon, Feb 26, 2024 at 09:29:32AM -0300, Ma\303\255ra Canal wrote:\n" + "> > > On 2/22/24 15:14, Maxime Ripard wrote:\n" + "> > > > The vc4_dummy_plane structure is an exact equivalent to vc4_plane, so we\n" + "> > > \n" + "> > > Maybe I understood incorrectly, but isn't the vc4_dummy_plane structure\n" + "> > > equivalent to drm_plane?\n" + "> > \n" + "> > Both statements are true :)\n" + "> > \n" + "> > vc4 itself uses vc4_plane to holds its plane-related content, but it\n" + "> > turns out that there's nothing in that structure anymore and vc4_plane\n" + "> > == drm_plane.\n" + "> > \n" + "> > In our mock driver, we have another structure meant to store the\n" + "> > mock-plane-related content which doesn't have anything in it anymore,\n" + "> > and is thus equivalent to vc4_plane.\n" + "> > \n" + "> > So, basically, vc4_dummy_plane == vc4_plane == drm_plane.\n" + "> > \n" + "> > This patch is only about getting rid of vc4_dummy_plane though.\n" + "> > \n" + "> > Is it clearer?\n" + "> > \n" + "> \n" + "> Yeah, with that pointed out, you can add my:\n" "\n" - "I'm currently working on a platform that seems to have togglable RAM ECC\n" - "support. Enabling ECC reduces the memory capacity and memory bandwidth,\n" - "so while it's a good idea to protect most of the system, it's not worth\n" - "it for things like framebuffers that won't really be affected by a\n" - "bitflip.\n" + "I'll rephrase for the next version then\n" "\n" - "It's currently setup by enabling ECC on the entire memory, and then\n" - "having a region of memory where ECC is disabled and where we're supposed\n" - "to allocate from for allocations that don't need it.\n" - "\n" - "My first thought to support this was to create a reserved memory region\n" - "for the !ECC memory, and to create a heap to allocate buffers from that\n" - "region. That would leave the system protected by ECC, while enabling\n" - "userspace to be nicer to the system by allocating buffers from the !ECC\n" - "region if it doesn't need it.\n" - "\n" - "However, this creates basically a new combination compared to the one we\n" - "already have (ie, physically contiguous vs virtually contiguous), and we\n" - "probably would want to throw in cacheable vs non-cacheable too.\n" - "\n" - "If we had to provide new heaps for each variation, we would have 8 heaps\n" - "(and 6 new ones), which could be fine I guess but would still increase\n" - "quite a lot the number of heaps we have so far.\n" - "\n" - "Is it something that would be a problem? If it is, do you see another\n" - "way to support those kind of allocations (like providing hints through\n" - "the ioctl maybe?)?\n" + "> Reviewed-by: Ma\303\255ra Canal <mcanal@igalia.com>\n" "\n" "Thanks!\n" Maxime @@ -49,10 +74,10 @@ "b\0" "-----BEGIN PGP SIGNATURE-----\n" "\n" - "iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZd9P2AAKCRDj7w1vZxhR\n" - "xcseAQDNXhfizqmm5H2uN2EY4Je+TYwTRgFflpibGSH+mgadZQEA/ztn8Tq2H8na\n" - "rgGnZua3Ci5jMoTbhctf8Hh0oDZuOw4=\n" - "=pw5E\n" + "iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZd9ccAAKCRDj7w1vZxhR\n" + "xQ/aAQDzU4vVfau883o71TzEeE+lysJ38XPUbtp9Q818fxbvSAD/TfNo9QsQjVLO\n" + "TjOhPuL8arGdUmexXtTS6jTunClBzAA=\n" + "=6H0O\n" "-----END PGP SIGNATURE-----\n" -21db7a64efbc198797e47ab83cea4efcf4aa74647aab4cf4c802586d8c195761 +ef9dcfe7501bdcb1addbb5090e11d1d83bc6e7cf032a89fffe19bb0a701d75fb
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox