Re: [PATCH v10 07/11] drm/etnaviv: Add support for the dma coherent device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 2023/6/22 00:12, Lucas Stach wrote:
Am Mittwoch, dem 21.06.2023 um 23:41 +0800 schrieb Sui Jingfeng:
On 2023/6/21 23:23, Lucas Stach wrote:
Am Mittwoch, dem 21.06.2023 um 22:44 +0800 schrieb Sui Jingfeng:
Hi,

On 2023/6/21 18:00, Lucas Stach wrote:
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 9cd72948cfad..644e5712c050 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -46,6 +46,12 @@ struct etnaviv_drm_private {
    	struct xarray active_contexts;
    	u32 next_context_id;
+ /*
+	 * If true, the GPU is capable of snooping cpu cache. Here, it
+	 * also means that cache coherency is enforced by the hardware.
+	 */
+	bool dma_coherent;
+
No need for this, I think. Just use dev_is_dma_coherent() where you
need to know this.

No, we want this value cached by the driver.

Why? dev_is_dma_coherent() is a header-only function with a single
pointer chasing operation. Your cache is also a single pointer chasing
access, just that we now need storage for this information in both
struct device and struct etnaviv_gpu.

You don't need store it in struct etnaviv_gpu.

As this variable is shared across the device, so it is better to be put
in the struct etnaviv_drm_private.

I don't think another 4 bytes allocation is something what we can't pay for.


My patch doesn't mentioned that it need to store it inside of struct
etnaviv_gpu, do I?
You are right, I was mistaken about the etnaviv struct this is added
to. However there is still the fundamental question: what's the gain of
this cache?

Clearness and short

you approach need to de-reference the pointer struct device *dev every time you need to fetch its value.

my name is short, typing it is less time-consuming

  The information is already available in struct device and
will be accessed with the same amount of loads if you care that much
about micro-optimization.

I don't want call it everywhere, its too long.

What if the function you recommend get expanded by some programmer someday?

Regards,
Lucas

--
Jingfeng




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux