From: Suman Anna <s-anna@ti.com>
To: Ohad Ben-Cohen <ohad@wizery.com>, Dave Gerlach <d-gerlach@ti.com>
Cc: linux-arm <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Kevin Hilman <khilman@linaro.org>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API
Date: Mon, 11 May 2015 10:09:56 -0500 [thread overview]
Message-ID: <5550C644.4040005@ti.com> (raw)
In-Reply-To: <CAK=WgbZCqnMPEnU2992gkOp07BaCP5NJNRO-hLCAdOtUXZGRnQ@mail.gmail.com>
Hi Ohad,
On 05/09/2015 02:39 AM, Ohad Ben-Cohen wrote:
> Hi Dave,
>
> On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Allow users of remoteproc the ability to get a handle to an rproc by
>> passing a phandle supplied in the user's device tree node. This is
>> useful in situations that require manual booting of the rproc.
>>
>> This patch uses the code removed by commit 40e575b1d0b3 ("remoteproc:
>> remove the get_by_name/put API") for the ref counting a rproc klist
>> code but has rproc_get_by_name replaced with an rproc_get_by_phandle API.
>
> The general idea makes sense to me, but I'm not sure we really do need
> a klist here, since the usage profile of this list is expected to be
> super simple: very small number of accessors, looking for small number
> of list members a small number of times, and probably never do need to
> modify the list while accessing it.
>
> I suspect that the code would be simpler to maintain, debug and
> understand if we just use a simple list with a simple locking
> methodology here.
The klist usage is something that we restored from previous remoteproc
core code as used by the rproc_get_by_name() API. This was removed in
commit 40e575b1d0b3 ("remoteproc: remove the get_by_name/put API"). We
chose to use the code that had been present before rather than inventing
something new all over again. If you feel that a regular list is the way
to go forward, we can make the switch.
regards
Suman
WARNING: multiple messages have this Message-ID (diff)
From: s-anna@ti.com (Suman Anna)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API
Date: Mon, 11 May 2015 10:09:56 -0500 [thread overview]
Message-ID: <5550C644.4040005@ti.com> (raw)
In-Reply-To: <CAK=WgbZCqnMPEnU2992gkOp07BaCP5NJNRO-hLCAdOtUXZGRnQ@mail.gmail.com>
Hi Ohad,
On 05/09/2015 02:39 AM, Ohad Ben-Cohen wrote:
> Hi Dave,
>
> On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Allow users of remoteproc the ability to get a handle to an rproc by
>> passing a phandle supplied in the user's device tree node. This is
>> useful in situations that require manual booting of the rproc.
>>
>> This patch uses the code removed by commit 40e575b1d0b3 ("remoteproc:
>> remove the get_by_name/put API") for the ref counting a rproc klist
>> code but has rproc_get_by_name replaced with an rproc_get_by_phandle API.
>
> The general idea makes sense to me, but I'm not sure we really do need
> a klist here, since the usage profile of this list is expected to be
> super simple: very small number of accessors, looking for small number
> of list members a small number of times, and probably never do need to
> modify the list while accessing it.
>
> I suspect that the code would be simpler to maintain, debug and
> understand if we just use a simple list with a simple locking
> methodology here.
The klist usage is something that we restored from previous remoteproc
core code as used by the rproc_get_by_name() API. This was removed in
commit 40e575b1d0b3 ("remoteproc: remove the get_by_name/put API"). We
chose to use the code that had been present before rather than inventing
something new all over again. If you feel that a regular list is the way
to go forward, we can make the switch.
regards
Suman
next prev parent reply other threads:[~2015-05-11 15:09 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-01 19:37 [PATCH v3 0/4] remoteproc: Introduce wkup_m3_rproc driver Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
[not found] ` <1427917039-43206-2-git-send-email-d-gerlach-l0cyMroinI0@public.gmane.org>
2015-05-09 7:39 ` Ohad Ben-Cohen
2015-05-09 7:39 ` Ohad Ben-Cohen
2015-05-09 7:39 ` Ohad Ben-Cohen
2015-05-11 15:09 ` Suman Anna [this message]
2015-05-11 15:09 ` Suman Anna
2015-05-16 7:18 ` Ohad Ben-Cohen
2015-05-16 7:18 ` Ohad Ben-Cohen
2015-05-18 14:33 ` Dave Gerlach
2015-05-18 14:33 ` Dave Gerlach
2015-04-01 19:37 ` [PATCH v3 2/4] remoteproc: add a rproc ops for performing address translation Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-05-09 7:54 ` Ohad Ben-Cohen
2015-05-09 7:54 ` Ohad Ben-Cohen
2015-05-11 14:55 ` Suman Anna
2015-05-11 14:55 ` Suman Anna
2015-04-01 19:37 ` [PATCH v3 3/4] Documentation: dt: add bindings for TI Wakeup M3 processor Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
[not found] ` <1427917039-43206-4-git-send-email-d-gerlach-l0cyMroinI0@public.gmane.org>
2015-05-11 17:28 ` Tony Lindgren
2015-05-11 17:28 ` Tony Lindgren
2015-05-11 17:28 ` Tony Lindgren
2015-04-01 19:37 ` [PATCH v3 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3 Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-05-09 8:42 ` Ohad Ben-Cohen
2015-05-09 8:42 ` Ohad Ben-Cohen
2015-05-11 15:01 ` Suman Anna
2015-05-11 15:01 ` Suman Anna
[not found] ` <5550C43F.3070507-l0cyMroinI0@public.gmane.org>
2015-05-16 8:43 ` Ohad Ben-Cohen
2015-05-16 8:43 ` Ohad Ben-Cohen
2015-05-16 8:43 ` Ohad Ben-Cohen
[not found] ` <1427917039-43206-1-git-send-email-d-gerlach-l0cyMroinI0@public.gmane.org>
2015-04-29 16:05 ` [PATCH v3 0/4] remoteproc: Introduce wkup_m3_rproc driver Suman Anna
2015-04-29 16:05 ` Suman Anna
2015-04-29 16:05 ` Suman Anna
2015-05-02 8:45 ` Ohad Ben-Cohen
2015-05-02 8:45 ` Ohad Ben-Cohen
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=5550C644.4040005@ti.com \
--to=s-anna@ti.com \
--cc=d-gerlach@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=tony@atomide.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.