From: Umang Jain <umang.jain@ideasonboard.com>
To: linux-staging@lists.linux.dev
Cc: Dan Carpenter <error27@gmail.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
Phil Elwell <phil@raspberrypi.com>, Greg KH <greg@kroah.com>,
Stefan Wahren <wahrenst@gmx.net>,
Umang Jain <umang.jain@ideasonboard.com>
Subject: [PATCH v4 03/11] staging: vc04_services: vchiq_arm: Drop g_cache_line_size
Date: Thu, 28 Mar 2024 23:41:25 +0530 [thread overview]
Message-ID: <20240328181134.1548799-4-umang.jain@ideasonboard.com> (raw)
In-Reply-To: <20240328181134.1548799-1-umang.jain@ideasonboard.com>
The cache-line-size is cached in struct vchiq_platform_info.
There is no need to cache this again via g_cache_line_size
and use it. Instead use the value from vchiq_platform_info directly.
While at it, move the comment about L2 cache line size in the kerneldoc
block of struct vchiq_platform_info.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
.../interface/vchiq_arm/vchiq_arm.c | 34 ++++++++-----------
.../interface/vchiq_arm/vchiq_arm.h | 15 ++++++++
2 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 9273767f25df..0dffc36dccd7 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -131,17 +131,6 @@ struct vchiq_pagelist_info {
};
static void __iomem *g_regs;
-/* This value is the size of the L2 cache lines as understood by the
- * VPU firmware, which determines the required alignment of the
- * offsets/sizes in pagelists.
- *
- * Modern VPU firmware looks for a DT "cache-line-size" property in
- * the VCHIQ node and will overwrite it with the actual L2 cache size,
- * which the kernel must then respect. That property was rejected
- * upstream, so we have to use the VPU firmware's compatibility value
- * of 32.
- */
-static unsigned int g_cache_line_size = 32;
static unsigned int g_fragments_size;
static char *g_fragments_base;
static char *g_free_fragments;
@@ -212,6 +201,7 @@ static struct vchiq_pagelist_info *
create_pagelist(struct vchiq_instance *instance, char *buf, char __user *ubuf,
size_t count, unsigned short type)
{
+ struct vchiq_drv_mgmt *drv_mgmt;
struct pagelist *pagelist;
struct vchiq_pagelist_info *pagelistinfo;
struct page **pages;
@@ -226,6 +216,8 @@ create_pagelist(struct vchiq_instance *instance, char *buf, char __user *ubuf,
if (count >= INT_MAX - PAGE_SIZE)
return NULL;
+ drv_mgmt = dev_get_drvdata(instance->state->dev->parent);
+
if (buf)
offset = (uintptr_t)buf & (PAGE_SIZE - 1);
else
@@ -368,9 +360,9 @@ create_pagelist(struct vchiq_instance *instance, char *buf, char __user *ubuf,
/* Partial cache lines (fragments) require special measures */
if ((type == PAGELIST_READ) &&
- ((pagelist->offset & (g_cache_line_size - 1)) ||
+ ((pagelist->offset & (drv_mgmt->info->cache_line_size - 1)) ||
((pagelist->offset + pagelist->length) &
- (g_cache_line_size - 1)))) {
+ (drv_mgmt->info->cache_line_size - 1)))) {
char *fragments;
if (down_interruptible(&g_free_fragments_sema)) {
@@ -396,12 +388,15 @@ static void
free_pagelist(struct vchiq_instance *instance, struct vchiq_pagelist_info *pagelistinfo,
int actual)
{
+ struct vchiq_drv_mgmt *drv_mgmt;
struct pagelist *pagelist = pagelistinfo->pagelist;
struct page **pages = pagelistinfo->pages;
unsigned int num_pages = pagelistinfo->num_pages;
dev_dbg(instance->state->dev, "arm: %pK, %d\n", pagelistinfo->pagelist, actual);
+ drv_mgmt = dev_get_drvdata(instance->state->dev->parent);
+
/*
* NOTE: dma_unmap_sg must be called before the
* cpu can touch any of the data/pages.
@@ -417,10 +412,10 @@ free_pagelist(struct vchiq_instance *instance, struct vchiq_pagelist_info *pagel
g_fragments_size;
int head_bytes, tail_bytes;
- head_bytes = (g_cache_line_size - pagelist->offset) &
- (g_cache_line_size - 1);
+ head_bytes = (drv_mgmt->info->cache_line_size - pagelist->offset) &
+ (drv_mgmt->info->cache_line_size - 1);
tail_bytes = (pagelist->offset + actual) &
- (g_cache_line_size - 1);
+ (drv_mgmt->info->cache_line_size - 1);
if ((actual >= 0) && (head_bytes != 0)) {
if (head_bytes > actual)
@@ -435,8 +430,8 @@ free_pagelist(struct vchiq_instance *instance, struct vchiq_pagelist_info *pagel
(tail_bytes != 0))
memcpy_to_page(pages[num_pages - 1],
(pagelist->offset + actual) &
- (PAGE_SIZE - 1) & ~(g_cache_line_size - 1),
- fragments + g_cache_line_size,
+ (PAGE_SIZE - 1) & ~(drv_mgmt->info->cache_line_size - 1),
+ fragments + drv_mgmt->info->cache_line_size,
tail_bytes);
down(&g_free_fragments_mutex);
@@ -479,8 +474,7 @@ static int vchiq_platform_init(struct platform_device *pdev, struct vchiq_state
if (err < 0)
return err;
- g_cache_line_size = drv_mgmt->info->cache_line_size;
- g_fragments_size = 2 * g_cache_line_size;
+ g_fragments_size = 2 * drv_mgmt->info->cache_line_size;
/* Allocate space for the channels in coherent memory */
slot_mem_size = PAGE_ALIGN(TOTAL_SLOTS * VCHIQ_SLOT_SIZE);
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
index 04683d98cd00..378415b205ef 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
@@ -27,6 +27,21 @@ enum USE_TYPE_E {
USE_TYPE_VCHIQ
};
+/**
+ * struct vchiq_platform_info - Platform information related to
+ * underlying hardware.
+ *
+ * @cache_line_size: value of L2 cache line
+ *
+ * cache_line_size is the size of the L2 cache lines as understood by the
+ * VPU firmware, which determines the required alignment of the offsets/sizes
+ * in pagelists.
+ *
+ * Modern VPU firmware looks for a DT "cache-line-size" property in the
+ * VCHIQ node and will overwrite it with the actual L2 cache size, which
+ * the kernel must then respect. That property was rejected upstream, so
+ * we use a value derived from the compatible string.
+ */
struct vchiq_platform_info {
unsigned int cache_line_size;
};
--
2.43.0
next prev parent reply other threads:[~2024-03-28 18:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-28 18:11 [PATCH v4 00/11] staging: vc04_services: Drop non-essential global members Umang Jain
2024-03-28 18:11 ` [PATCH v4 01/11] staging: vc04_services: Drop g_once_init global variable Umang Jain
2024-03-28 18:11 ` [PATCH v4 02/11] staging: vc04_services: vchiq_arm: Split driver static and runtime data Umang Jain
2024-03-28 22:33 ` Laurent Pinchart
2024-03-28 18:11 ` Umang Jain [this message]
2024-03-28 18:11 ` [PATCH v4 04/11] staging: vc04_services: Move variables for tracking connections Umang Jain
2024-03-28 22:38 ` Laurent Pinchart
2024-03-28 18:11 ` [PATCH v4 05/11] staging: vc04_services: Drop vchiq_connected.[ch] files Umang Jain
2024-03-28 22:52 ` Laurent Pinchart
2024-03-28 18:11 ` [PATCH v4 06/11] staging: vc04_services: Move global variables tracking allocated pages Umang Jain
2024-03-28 22:59 ` Laurent Pinchart
2024-03-28 23:04 ` Laurent Pinchart
2024-04-01 5:00 ` Umang Jain
2024-03-28 18:11 ` [PATCH v4 07/11] staging: vc04_services: Move global memory mapped pointer Umang Jain
2024-03-28 23:01 ` Laurent Pinchart
2024-03-28 18:11 ` [PATCH v4 08/11] staging: vc04_services: Move spinlocks to vchiq_state Umang Jain
2024-03-28 18:11 ` [PATCH v4 09/11] staging: vc04_services: vchiq_mmal: Rename service_callback() Umang Jain
2024-03-28 23:03 ` Laurent Pinchart
2024-03-28 18:11 ` [PATCH v4 10/11] staging: vc04_services: Move global g_state vchiq_state pointer Umang Jain
2024-03-28 18:11 ` [PATCH v4 11/11] staging: vc04_services: Drop completed TODO item Umang Jain
2024-04-09 15:46 ` [PATCH v4 00/11] staging: vc04_services: Drop non-essential global members Greg KH
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=20240328181134.1548799-4-umang.jain@ideasonboard.com \
--to=umang.jain@ideasonboard.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=error27@gmail.com \
--cc=greg@kroah.com \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-staging@lists.linux.dev \
--cc=phil@raspberrypi.com \
--cc=wahrenst@gmx.net \
/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 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 read-only IMAP folder(s) and NNTP newsgroup(s).