All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	"Daniele Ceraolo Spurio" <daniele.ceraolospurio@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Christian König" <christian.koenig@amd.com>,
	"John Harrison" <John.C.Harrison@intel.com>
Subject: Re: [PATCH v2 02/18] iosys-map: Add a few more helpers
Date: Tue, 8 Feb 2022 22:43:13 -0800	[thread overview]
Message-ID: <20220209064313.ithagwtjztcf4jfb@ldmartin-desk2> (raw)
In-Reply-To: <863e61f9-2888-11a2-271b-a443f4681987@suse.de>

On Wed, Feb 09, 2022 at 07:23:04AM +0100, Thomas Zimmermann wrote:
>Hi
>
>Am 08.02.22 um 11:45 schrieb Lucas De Marchi:
>>First the simplest ones:
>>
>>	- iosys_map_memset(): when abstracting system and I/O memory,
>>	  just like the memcpy() use case, memset() also has dedicated
>>	  functions to be called for using IO memory.
>>	- iosys_map_memcpy_from(): we may need to copy data from I/O
>>	  memory, not only to.
>>
>>In certain situations it's useful to be able to read or write to an
>>offset that is calculated by having the memory layout given by a struct
>>declaration. Usually we are going to read/write a u8, u16, u32 or u64.
>>
>>As a pre-requisite for the implementation, add iosys_map_memcpy_from()
>>to be the equivalent of iosys_map_memcpy_to(), but in the other
>>direction. Then add 2 pairs of macros:
>>
>>	- iosys_map_rd() / iosys_map_wr()
>>	- iosys_map_rd_field() / iosys_map_wr_field()
>>
>>The first pair takes the C-type and offset to read/write. The second
>>pair uses a struct describing the layout of the mapping in order to
>>calculate the offset and size being read/written.
>>
>>We could use readb, readw, readl, readq and the write* counterparts,
>>however due to alignment issues this may not work on all architectures.
>>If alignment needs to be checked to call the right function, it's not
>>possible to decide at compile-time which function to call: so just leave
>>the decision to the memcpy function that will do exactly that.
>>
>>Finally, in order to use the above macros with a map derived from
>>another, add another initializer: IOSYS_MAP_INIT_OFFSET().
>>
>>v2:
>>   - Rework IOSYS_MAP_INIT_OFFSET() so it doesn't rely on aliasing rules
>>     within the union
>>   - Add offset to both iosys_map_rd_field() and iosys_map_wr_field() to
>>     allow the struct itself to be at an offset from the mapping
>>   - Add documentation to iosys_map_rd_field() with example and expected
>>     memory layout
>>
>>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>>Cc: Christian König <christian.koenig@amd.com>
>>Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
>>Cc: dri-devel@lists.freedesktop.org
>>Cc: linux-kernel@vger.kernel.org
>>Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>>---
>>  include/linux/iosys-map.h | 202 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 202 insertions(+)
>>
>>diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
>>index edd730b1e899..c6b223534b21 100644
>>--- a/include/linux/iosys-map.h
>>+++ b/include/linux/iosys-map.h
>>@@ -6,6 +6,7 @@
>>  #ifndef __IOSYS_MAP_H__
>>  #define __IOSYS_MAP_H__
>>+#include <linux/kernel.h>
>>  #include <linux/io.h>
>>  #include <linux/string.h>
>
>Alphabetically sorted, please.
>
>What requires kernel.h? Can this be reduced to another include 
>statement? Maybe stddef.h for offsetof() ?

Humn... I believe it was something in the previous implementation that
is not there anymore. Because this builds fine without the include now
and I don't think it is something being included by the headers already
here.  So this additional include can just be removed.

Lucas De Marchi

WARNING: multiple messages have this Message-ID (diff)
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "Matthew Brost" <matthew.brost@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	"Daniele Ceraolo Spurio" <daniele.ceraolospurio@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Christian König" <christian.koenig@amd.com>,
	"John Harrison" <John.C.Harrison@intel.com>
Subject: Re: [PATCH v2 02/18] iosys-map: Add a few more helpers
Date: Tue, 8 Feb 2022 22:43:13 -0800	[thread overview]
Message-ID: <20220209064313.ithagwtjztcf4jfb@ldmartin-desk2> (raw)
In-Reply-To: <863e61f9-2888-11a2-271b-a443f4681987@suse.de>

On Wed, Feb 09, 2022 at 07:23:04AM +0100, Thomas Zimmermann wrote:
>Hi
>
>Am 08.02.22 um 11:45 schrieb Lucas De Marchi:
>>First the simplest ones:
>>
>>	- iosys_map_memset(): when abstracting system and I/O memory,
>>	  just like the memcpy() use case, memset() also has dedicated
>>	  functions to be called for using IO memory.
>>	- iosys_map_memcpy_from(): we may need to copy data from I/O
>>	  memory, not only to.
>>
>>In certain situations it's useful to be able to read or write to an
>>offset that is calculated by having the memory layout given by a struct
>>declaration. Usually we are going to read/write a u8, u16, u32 or u64.
>>
>>As a pre-requisite for the implementation, add iosys_map_memcpy_from()
>>to be the equivalent of iosys_map_memcpy_to(), but in the other
>>direction. Then add 2 pairs of macros:
>>
>>	- iosys_map_rd() / iosys_map_wr()
>>	- iosys_map_rd_field() / iosys_map_wr_field()
>>
>>The first pair takes the C-type and offset to read/write. The second
>>pair uses a struct describing the layout of the mapping in order to
>>calculate the offset and size being read/written.
>>
>>We could use readb, readw, readl, readq and the write* counterparts,
>>however due to alignment issues this may not work on all architectures.
>>If alignment needs to be checked to call the right function, it's not
>>possible to decide at compile-time which function to call: so just leave
>>the decision to the memcpy function that will do exactly that.
>>
>>Finally, in order to use the above macros with a map derived from
>>another, add another initializer: IOSYS_MAP_INIT_OFFSET().
>>
>>v2:
>>   - Rework IOSYS_MAP_INIT_OFFSET() so it doesn't rely on aliasing rules
>>     within the union
>>   - Add offset to both iosys_map_rd_field() and iosys_map_wr_field() to
>>     allow the struct itself to be at an offset from the mapping
>>   - Add documentation to iosys_map_rd_field() with example and expected
>>     memory layout
>>
>>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>>Cc: Christian König <christian.koenig@amd.com>
>>Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
>>Cc: dri-devel@lists.freedesktop.org
>>Cc: linux-kernel@vger.kernel.org
>>Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>>---
>>  include/linux/iosys-map.h | 202 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 202 insertions(+)
>>
>>diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
>>index edd730b1e899..c6b223534b21 100644
>>--- a/include/linux/iosys-map.h
>>+++ b/include/linux/iosys-map.h
>>@@ -6,6 +6,7 @@
>>  #ifndef __IOSYS_MAP_H__
>>  #define __IOSYS_MAP_H__
>>+#include <linux/kernel.h>
>>  #include <linux/io.h>
>>  #include <linux/string.h>
>
>Alphabetically sorted, please.
>
>What requires kernel.h? Can this be reduced to another include 
>statement? Maybe stddef.h for offsetof() ?

Humn... I believe it was something in the previous implementation that
is not there anymore. Because this builds fine without the include now
and I don't think it is something being included by the headers already
here.  So this additional include can just be removed.

Lucas De Marchi

WARNING: multiple messages have this Message-ID (diff)
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH v2 02/18] iosys-map: Add a few more helpers
Date: Tue, 8 Feb 2022 22:43:13 -0800	[thread overview]
Message-ID: <20220209064313.ithagwtjztcf4jfb@ldmartin-desk2> (raw)
In-Reply-To: <863e61f9-2888-11a2-271b-a443f4681987@suse.de>

On Wed, Feb 09, 2022 at 07:23:04AM +0100, Thomas Zimmermann wrote:
>Hi
>
>Am 08.02.22 um 11:45 schrieb Lucas De Marchi:
>>First the simplest ones:
>>
>>	- iosys_map_memset(): when abstracting system and I/O memory,
>>	  just like the memcpy() use case, memset() also has dedicated
>>	  functions to be called for using IO memory.
>>	- iosys_map_memcpy_from(): we may need to copy data from I/O
>>	  memory, not only to.
>>
>>In certain situations it's useful to be able to read or write to an
>>offset that is calculated by having the memory layout given by a struct
>>declaration. Usually we are going to read/write a u8, u16, u32 or u64.
>>
>>As a pre-requisite for the implementation, add iosys_map_memcpy_from()
>>to be the equivalent of iosys_map_memcpy_to(), but in the other
>>direction. Then add 2 pairs of macros:
>>
>>	- iosys_map_rd() / iosys_map_wr()
>>	- iosys_map_rd_field() / iosys_map_wr_field()
>>
>>The first pair takes the C-type and offset to read/write. The second
>>pair uses a struct describing the layout of the mapping in order to
>>calculate the offset and size being read/written.
>>
>>We could use readb, readw, readl, readq and the write* counterparts,
>>however due to alignment issues this may not work on all architectures.
>>If alignment needs to be checked to call the right function, it's not
>>possible to decide at compile-time which function to call: so just leave
>>the decision to the memcpy function that will do exactly that.
>>
>>Finally, in order to use the above macros with a map derived from
>>another, add another initializer: IOSYS_MAP_INIT_OFFSET().
>>
>>v2:
>>   - Rework IOSYS_MAP_INIT_OFFSET() so it doesn't rely on aliasing rules
>>     within the union
>>   - Add offset to both iosys_map_rd_field() and iosys_map_wr_field() to
>>     allow the struct itself to be at an offset from the mapping
>>   - Add documentation to iosys_map_rd_field() with example and expected
>>     memory layout
>>
>>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>>Cc: Christian König <christian.koenig@amd.com>
>>Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
>>Cc: dri-devel@lists.freedesktop.org
>>Cc: linux-kernel@vger.kernel.org
>>Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>>---
>>  include/linux/iosys-map.h | 202 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 202 insertions(+)
>>
>>diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
>>index edd730b1e899..c6b223534b21 100644
>>--- a/include/linux/iosys-map.h
>>+++ b/include/linux/iosys-map.h
>>@@ -6,6 +6,7 @@
>>  #ifndef __IOSYS_MAP_H__
>>  #define __IOSYS_MAP_H__
>>+#include <linux/kernel.h>
>>  #include <linux/io.h>
>>  #include <linux/string.h>
>
>Alphabetically sorted, please.
>
>What requires kernel.h? Can this be reduced to another include 
>statement? Maybe stddef.h for offsetof() ?

Humn... I believe it was something in the previous implementation that
is not there anymore. Because this builds fine without the include now
and I don't think it is something being included by the headers already
here.  So this additional include can just be removed.

Lucas De Marchi

  reply	other threads:[~2022-02-09  6:43 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 10:45 [PATCH v2 00/18] drm/i915/guc: Refactor ADS access to use iosys_map Lucas De Marchi
2022-02-08 10:45 ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 01/18] iosys-map: Add offset to iosys_map_memcpy_to() Lucas De Marchi
2022-02-08 10:45   ` Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 02/18] iosys-map: Add a few more helpers Lucas De Marchi
2022-02-08 10:45   ` Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 22:53   ` Matt Atwood
2022-02-09  6:14   ` Mauro Carvalho Chehab
2022-02-09  6:14     ` Mauro Carvalho Chehab
2022-02-09  6:14     ` [Intel-gfx] " Mauro Carvalho Chehab
2022-02-09  6:23   ` Thomas Zimmermann
2022-02-09  6:23     ` [Intel-gfx] " Thomas Zimmermann
2022-02-09  6:43     ` Lucas De Marchi [this message]
2022-02-09  6:43       ` Lucas De Marchi
2022-02-09  6:43       ` Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 03/18] drm/i915/gt: Add helper for shmem copy to iosys_map Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 23:08   ` Matt Atwood
2022-02-08 10:45 ` [PATCH v2 04/18] drm/i915/guc: Keep iosys_map of ads_blob around Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-10 22:56   ` Matt Atwood
2022-02-08 10:45 ` [Intel-gfx] [PATCH v2 05/18] drm/i915/guc: Add read/write helpers for ADS blob Lucas De Marchi
2022-02-08 10:45   ` Lucas De Marchi
2022-02-10 23:00   ` [Intel-gfx] " Matt Atwood
2022-02-08 10:45 ` [PATCH v2 06/18] drm/i915/guc: Convert golden context init to iosys_map Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-10 23:07   ` Matt Atwood
2022-02-08 10:45 ` [PATCH v2 07/18] drm/i915/guc: Convert policies update " Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-10 23:56   ` Matt Atwood
2022-02-08 10:45 ` [PATCH v2 08/18] drm/i915/guc: Convert engine record " Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-15 23:28   ` Matt Atwood
2022-02-08 10:45 ` [PATCH v2 09/18] drm/i915/guc: Convert guc_ads_private_data_reset " Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 10/18] drm/i915/guc: Convert golden context prep " Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 11/18] drm/i915/guc: Replace check for golden context size Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 12/18] drm/i915/guc: Convert mapping table to iosys_map Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 13/18] drm/i915/guc: Convert capture list " Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 14/18] drm/i915/guc: Prepare for error propagation Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 15/18] drm/i915/guc: Use a single pass to calculate regset Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [Intel-gfx] [PATCH v2 16/18] drm/i915/guc: Convert guc_mmio_reg_state_init to iosys_map Lucas De Marchi
2022-02-08 10:45   ` Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 17/18] drm/i915/guc: Convert __guc_ads_init " Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 10:45 ` [PATCH v2 18/18] drm/i915/guc: Remove plain ads_blob pointer Lucas De Marchi
2022-02-08 10:45   ` [Intel-gfx] " Lucas De Marchi
2022-02-08 11:18 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Refactor ADS access to use iosys_map (rev2) Patchwork
2022-02-08 11:20 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-02-08 11:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-02-08 13:07 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=20220209064313.ithagwtjztcf4jfb@ldmartin-desk2 \
    --to=lucas.demarchi@intel.com \
    --cc=John.C.Harrison@intel.com \
    --cc=christian.koenig@amd.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=mchehab@kernel.org \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.