From: Beleswar Prasad Padhi <b-padhi@ti.com>
To: Andrew Davis <afd@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: Fri, 10 Jan 2025 20:26:25 +0530 [thread overview]
Message-ID: <932ab43c-8766-422c-b73e-0929fd18253e@ti.com> (raw)
In-Reply-To: <da80e039-bcea-41a3-83ec-e10ffb4b0c46@ti.com>
Hi Andrew,
On 08/01/25 20:33, Andrew Davis wrote:
> 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 a lot for suggesting this detailed plan! I agree with your
assessment, and I will post a series addressing this.
Thanks,
Beleswar
>
> 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
>>
prev parent reply other threads:[~2025-01-10 14:56 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
2025-01-10 14:56 ` Beleswar Prasad Padhi [this message]
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=932ab43c-8766-422c-b73e-0929fd18253e@ti.com \
--to=b-padhi@ti.com \
--cc=afd@ti.com \
--cc=andersson@kernel.org \
--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).