From: Andrew Davis <afd@ti.com>
To: Beleswar Padhi <b-padhi@ti.com>, <andersson@kernel.org>,
<mathieu.poirier@linaro.org>
Cc: <hnagalla@ti.com>, <u-kumar1@ti.com>, <p.zabel@pengutronix.de>,
<jan.kiszka@siemens.com>, <christophe.jaillet@wanadoo.fr>,
<jkangas@redhat.com>, <eballetbo@redhat.com>,
<linux-remoteproc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 00/20] Refactor TI K3 DSP and M4 Drivers
Date: Wed, 8 Jan 2025 09:03:16 -0600 [thread overview]
Message-ID: <da80e039-bcea-41a3-83ec-e10ffb4b0c46@ti.com> (raw)
In-Reply-To: <20250103101231.1508151-1-b-padhi@ti.com>
On 1/3/25 4:12 AM, Beleswar Padhi wrote:
> This series refactors a lot of functions & callbacks from ti_k3_dsp_remoteproc.c
> and ti_k3_m4_remoteproc.c drivers. This is the third and final series as part of
> the refactoring of K3 remoteproc drivers. The patches for internal refactoring
> and bug fixes of TI K3 R5 remoteproc driver has been already posted[0][1]. Since
> the R5 driver has worked out separate data structures and reset logic than the
> DSP/M4 drivers, I have excluded R5 from this refactoring.
>
Diffstat looks great, 765 (+), 1164 (-), good to see all that duplicated code
factored away. But R5 is the largest of the 3 drivers and really needs it the
most.
Looking at the data structure in R5 preventing this I see what should be
the normal "struct k3_rproc" structure is really split into two,
"struct k3_r5_rproc" and "struct k3_r5_core". The first containing a single
instance of the latter. There is no reason for this split I can see, just
combine the two structs.
Next, there are some members of the struct that we don't need, such as
atcm_enable and the others that are only used in probe (or functions
called as part of probe). We only use these as a way to collect this
info in one function, and use in a later one. Instead you could either
fetch this info at the time of use. Or move these members into the
cluster level "struct k3_r5_cluster".
Speaking of "struct k3_r5_cluster", it is silly for cluster to keep a list
of cores. There are two, and will only ever be two. No clue why a list was
chosen as the data structure to hold two pointers, switch this two an array
of size two, or even just two pointers. This also cleans up a bunch of the
weird "list_for_each" logic and loops that have to then check if they have
found with core0 or core1. Instead, just directly access core0 or core1.
That gets rid of member "struct list_head" from the combined struct,
and would you look at that, the struct now matches DSP/M4 :)
I'd suggest doing the above fixups to R5 first, then you can do
this series here after that and include R5.
Thanks,
Andrew
> NOTE:
> This series is _dependent_ upon the [PATCH 2/3] of below series:
> https://lore.kernel.org/all/20241224091457.1050233-3-b-padhi@ti.com/
>
> Testing Done:
> 1. Tested boot of C66x DSPs, C71x DSPs across Jacinto J7* devices in Remoteproc
> mode and IPC-Only mode.
> 2. Tested boot of M4F core _only_ in _AM62xx SK_ board in Remoteproc mode and
> IPC-Only mode.
> 3. Tested Core stop and detach operations from sysfs for C66x DSPs, C71x DSPs
> and M4F.
> 4. Tested device removal paths by executing 'modprobe -r ti_k3_dsp_remoteproc'
> and 'modprobe -r ti_k3_m4_remoteproc'.
> 5. Tested usecases where firmware not available at device probe time, but later
> in sysfs, able to load firmware into a remotecore and start it. [C66x, C71x, M4]
> 6. Tested that each patch in this series generates no new warnings/errors.
>
> v8: Changelog:
> 1. Broken down refactoring into patches, each patch dealing with one function
> for ease in review. [Andrew]
>
> Links to older versions:
> v7: https://lore.kernel.org/all/20240202175538.1705-1-hnagalla@ti.com/
> v6: https://lore.kernel.org/all/20230913111644.29889-1-hnagalla@ti.com/
> v5: https://lore.kernel.org/all/20230808044529.25925-1-hnagalla@ti.com/
> v4: https://lore.kernel.org/all/20230801141117.2559-1-hnagalla@ti.com/
> v3: https://lore.kernel.org/all/20230302171450.1598576-1-martyn.welch@collabora.com/
> v2: https://lore.kernel.org/all/20230301111323.1532479-4-martyn.welch@collabora.com/
> v1: https://lore.kernel.org/all/20220110040650.18186-1-hnagalla@ti.com/
>
> Thanks,
> Beleswar
>
> [0]: https://lore.kernel.org/all/20241219110545.1898883-1-b-padhi@ti.com/
> [1]: https://lore.kernel.org/all/20241224091457.1050233-1-b-padhi@ti.com/
>
> Beleswar Padhi (20):
> remoteproc: k3-m4: Prevent Mailbox level IPC with detached core
> remoteproc: k3: Refactor shared data structures
> remoteproc: k3: Refactor mailbox rx_callback functions into common
> driver
> remoteproc: k3: Refactor .kick rproc ops into common driver
> remoteproc: k3-m4: Use k3_rproc_mem_data structure for memory info
> remoteproc: k3: Refactor rproc_reset() implementation into common
> driver
> remoteproc: k3: Refactor rproc_release() implementation into common
> driver
> remoteproc: k3: Refactor rproc_request_mbox() implementations into
> common driver
> remoteproc: k3: Refactor .prepare rproc ops into common driver
> remoteproc: k3: Refactor .unprepare rproc ops into common driver
> remoteproc: k3: Refactor .start rproc ops into common driver
> remoteproc: k3: Refactor .stop rproc ops into common driver
> remoteproc: k3: Refactor .attach rproc ops into common driver
> remoteproc: k3: Refactor .detach rproc ops into common driver
> remoteproc: k3: Refactor .get_loaded_rsc_table ops into common driver
> remoteproc: k3: Refactor .da_to_va rproc ops into common driver
> remoteproc: k3: Refactor of_get_memories() functions into common
> driver
> remoteproc: k3: Refactor mem_release() functions into common driver
> remoteproc: k3: Refactor reserved_mem_init() functions into common
> driver
> remoteproc: k3: Refactor release_tsp() functions into common driver
>
> drivers/remoteproc/Makefile | 4 +-
> drivers/remoteproc/ti_k3_common.c | 586 ++++++++++++++++++++
> drivers/remoteproc/ti_k3_common.h | 113 ++++
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 643 +---------------------
> drivers/remoteproc/ti_k3_m4_remoteproc.c | 583 ++------------------
> 5 files changed, 765 insertions(+), 1164 deletions(-)
> create mode 100644 drivers/remoteproc/ti_k3_common.c
> create mode 100644 drivers/remoteproc/ti_k3_common.h
>
next prev parent reply other threads:[~2025-01-08 15:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 10:12 [PATCH v8 00/20] Refactor TI K3 DSP and M4 Drivers Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 01/20] remoteproc: k3-m4: Prevent Mailbox level IPC with detached core Beleswar Padhi
2025-01-08 8:49 ` Beleswar Prasad Padhi
2025-01-03 10:12 ` [PATCH v8 02/20] remoteproc: k3: Refactor shared data structures Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 03/20] remoteproc: k3: Refactor mailbox rx_callback functions into common driver Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 04/20] remoteproc: k3: Refactor .kick rproc ops " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 05/20] remoteproc: k3-m4: Use k3_rproc_mem_data structure for memory info Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 06/20] remoteproc: k3: Refactor rproc_reset() implementation into common driver Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 07/20] remoteproc: k3: Refactor rproc_release() " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 08/20] remoteproc: k3: Refactor rproc_request_mbox() implementations " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 09/20] remoteproc: k3: Refactor .prepare rproc ops " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 10/20] remoteproc: k3: Refactor .unprepare " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 11/20] remoteproc: k3: Refactor .start " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 12/20] remoteproc: k3: Refactor .stop " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 13/20] remoteproc: k3: Refactor .attach " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 14/20] remoteproc: k3: Refactor .detach " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 15/20] remoteproc: k3: Refactor .get_loaded_rsc_table " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 16/20] remoteproc: k3: Refactor .da_to_va rproc " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 17/20] remoteproc: k3: Refactor of_get_memories() functions " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 18/20] remoteproc: k3: Refactor mem_release() " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 19/20] remoteproc: k3: Refactor reserved_mem_init() " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 20/20] remoteproc: k3: Refactor release_tsp() " Beleswar Padhi
2025-01-03 10:50 ` [PATCH v8 00/20] Refactor TI K3 DSP and M4 Drivers Beleswar Prasad Padhi
2025-01-08 15:03 ` Andrew Davis [this message]
2025-01-10 14:56 ` Beleswar Prasad Padhi
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=da80e039-bcea-41a3-83ec-e10ffb4b0c46@ti.com \
--to=afd@ti.com \
--cc=andersson@kernel.org \
--cc=b-padhi@ti.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=eballetbo@redhat.com \
--cc=hnagalla@ti.com \
--cc=jan.kiszka@siemens.com \
--cc=jkangas@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=u-kumar1@ti.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: 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).