lkml.org 
[lkml]   [2016]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v13 0/4] Mediatek MT8173 CMDQ support
    From
    Date
    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 <hs.liao@mediatek.com> wrote:
    [...]
    > >> 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).
    >
    > > 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

    \
     
     \ /
      Last update: 2016-09-17 09:58    [W:2.294 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site