lkml.org 
[lkml]   [2013]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCHv3 00/14] drivers: mailbox: framework creation
    From
    Hi

    On 29 April 2013 21:30, Suman Anna <s-anna@ti.com> wrote:
    > Hi Jassi,
    >
    > On 04/26/2013 11:51 PM, Jassi Brar wrote:

    >>> OK, I didn't think of a no RTR interrupt-based controller. I would thing
    >>> that such a controller is very rudimentary. I wonder if there are any
    >>> controllers like this out there.
    >>>
    >> One of my controllers is like that :)
    >
    > I hope it does have a status register atleast, and not the "neither
    > report nor sense RTR" type.
    >
    Actually the status is not set by the h/w, but the remote's firmware
    implementation makes sure it sets a marker in the status register
    after accepting data. So with some other firmware, we might not even
    have the status read facility and the client will have to solely run
    the TX ticker.

    >> If the controller h/w absolutely can not tell the remote(sender) of a
    >> received packet (as seems to be your case), its driver shouldn't even
    >> try to demux the received messages. The client driver must know which
    >> remotes could send it a message and how to discern them on the
    >> platform. Some 'server' RX client is needed here.
    >
    > No demuxing, deliver the message to the different clients. It is a
    > protocol agreement between the clients on what the message means. Think
    > of this scenario akin to shared interrupts.
    >
    Please re-read. That's what I said - No demuxing by the controller driver :)

    >
    > The notify mechanism was the top-half on the interrupt handling. The
    > faith part is coming from the fact that you expect all the clients to do
    > the equivalent of the bottom-half (which would mean some duplication in
    > the different clients), the OMAP scenario is such that all the different
    > link interrupts (both rx & tx) are mapped onto a single physical
    > interrupt. I think this may not be applicable to your usecase, wherein
    > you probably expect a response back before proceeding.
    >
    Simply put - the RX by notifier method will fail should a client is
    speed critical.
    The api might provide it optionally, but direct handover should be the
    default option.

    Btw, I did put up an almost tested version of an API implementing most
    of the features we agree upon
    http://www.spinics.net/lists/kernel/msg1523873.html
    http://www.spinics.net/lists/kernel/msg1523874.html

    cheers.


    \
     
     \ /
      Last update: 2013-04-29 19:41    [W:3.599 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site