Thread (11 messages) 11 messages, 3 authors, 2016-09-02

Re: [PATCH v13 0/4] Mediatek MT8173 CMDQ support

From: Horng-Shyang Liao <hidden>
Date: 2016-09-02 08:51:20
Also in: linux-arm-kernel, linux-mediatek, lkml

Hi Jassi,

On Wed, 2016-08-31 at 14:15 +0530, Jassi Brar wrote:
On Wed, Aug 31, 2016 at 1:43 PM, Horng-Shyang Liao [off-list ref] wrote:
[...]
quoted
quoted
Platforms that need shared access to a channel, implement a 'server'
driver that serialise (which is needed still) the access to common
channel. If you think you don't need mutual exclusion and don't care
about replies, simply share the mailbox handle among different
clients.
Thank you for your kindly reply.
We would like to discuss further with you on this topic.

Our requirement is
(1) cmdq task cannot be split, and
(2) cmdq thread can have multiple cmdq tasks from different clients.

According to your comment "implement a 'server' driver that serialise
the access to common channel", do you mean we should implement cmdq
client (mailbox client) as a server and other clients call the functions
of cmdq client?

clients --> cmdq client (mailbox client) --> cmdq (mailbox controller)

If so, could you please tell us the benefit of using mailbox framework?
You don't have to reinvent 80% of the wheel and reuse the mailbox.c
core that supports many features and is tested on many platforms. Your
implementation is going to be quite similar, only you clump all the
code in one file and you use different terminology.

You said "we will acquire gce thread for client dynamically by
internal policy in cmdq driver"
On mailbox api, this maps to simply sharing the channel/thread handle,
protected by a lock, among clients on some basis (like FCFS or
whatever you internal policy is). So your server driver could be very
thin. And all your clients could follow the mailbox api (which is good
from the point of reusability/portability).
quoted
Our original plan is to let cmdq driver manage cmdq thread internally.
Cmdq driver can choose a suitable cmdq thread to execute a flushed cmdq
task dynamically, and client doesn't need to know the existence of cmdq
thread.


Could you also please tell us the purpose of putting all mailbox
driver into mailbox folder?
We know that some other drivers also follow this rule, and just want
to know more details.
Any driver that implements the Mailbox API should live in
drivers/mailbox/.  And why you should implement mailbox api, is
explained above.
Thank you for your explanation.
I will move cmdq driver to mailbox folder in the next version.

Thanks,
HS

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help