[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170626211957.GH18666@tuxbook>
Date: Mon, 26 Jun 2017 14:19:57 -0700
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: Suman Anna <s-anna@...com>
Cc: Ohad Ben-Cohen <ohad@...ery.com>, Rob Herring <robh+dt@...nel.org>,
Santosh Shilimkar <ssantosh@...nel.org>,
Mark Rutland <mark.rutland@....com>,
linux-remoteproc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, "Andrew F. Davis" <afd@...com>,
Sam Nelson <sam.nelson@...com>,
Grygorii Strashko <grygorii.strashko@...com>
Subject: Re: [PATCH v3 2/3] remoteproc/keystone: Add a remoteproc driver for
Keystone 2 DSPs
On Mon 26 Jun 13:20 PDT 2017, Suman Anna wrote:
> On 06/26/2017 03:06 PM, Bjorn Andersson wrote:
> > On Mon 26 Jun 08:54 PDT 2017, Suman Anna wrote:
> >> On 06/25/2017 03:15 PM, Bjorn Andersson wrote:
[..]
> > I still would like to have resources allocated at probe() time, so I
> > would appreciate a follow up patch moving the request_irq()s to probe,
> > per above comment (but we can take that after v4.13).
>
> OK thanks. This is a common theme across all the remoteproc drivers
> supporting rpmsg, and I definitely need to disable them in probe since
> the boot or the virtio/rpmsg devices are not guaranteed to be present in
> the probe.
>
We have a consistent struct rproc after rproc_alloc(). So before the
virtio device (rpmsg in your case) calls virtio_find_vqs() rvring->vq
will be NULL and rproc_vq_interrupt() is a nop.
So AFAICT it should be fine to register this at probe time and leave it
enabled...but there's a lot of moving parts involved here, so it's
possible that I'm missing something.
But in for both interrupts it's important to disable them before calling
rproc_free(), as this will free the memory passed to the interrupt
handler.
Regards,
Bjorn
Powered by blists - more mailing lists