[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e5140426-7e69-41b0-858f-16f83eed871a@ti.com>
Date: Mon, 19 Aug 2024 14:02:31 +0530
From: Vignesh Raghavendra <vigneshr@...com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>, Andrew Davis <afd@...com>
CC: Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Nishanth Menon <nm@...com>,
Tero Kristo <kristo@...nel.org>,
Philipp Zabel
<p.zabel@...gutronix.de>,
Hari Nagalla <hnagalla@...com>, <linux-remoteproc@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for
M4F subsystem
[...]
Hi Mathieu
On 16/08/24 20:06, Mathieu Poirier wrote:
>>> +/*
>>> + * Attach to a running M4 remote processor (IPC-only mode)
>>> + *
>>> + * The remote processor is already booted, so there is no need to issue any
>>> + * TI-SCI commands to boot the M4 core. This callback is used only in IPC-only
>>> + * mode.
>>> + */
>>> +static int k3_m4_rproc_attach(struct rproc *rproc)
>>> +{
>>> + struct k3_m4_rproc *kproc = rproc->priv;
>>> + int ret;
>>> +
>>> + ret = k3_m4_rproc_ping_mbox(kproc);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * Detach from a running M4 remote processor (IPC-only mode)
>>> + *
>>> + * This rproc detach callback performs the opposite operation to attach
>>> + * callback, the M4 core is not stopped and will be left to continue to
>>> + * run its booted firmware. This callback is invoked only in IPC-only mode.
>>> + */
>>> +static int k3_m4_rproc_detach(struct rproc *rproc)
>>> +{
>>> + return 0;
>>> +}
>> Please remove.
> Forget this comment since it would cause an error in __rproc_detach().
>
>> Other than the above I'm good with this driver. That said I can't move forward
>> without a nod from the DT crew. I also noticed a fair amount of code
>> duplication with the k3_r5 and k3_dsp drivers. Dealing with that should not be
>> part of the current work but will need to be done before another k3 driver can
>> be merged.
>>
> The above still apply though.
Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
driver patches are merged. Feel free to ignore those but queue
dt-bindings (already has DT maintainers ack) and driver patches via
rproc tree.
--
Regards
Vignesh
Powered by blists - more mailing lists