All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jassi Brar <jassisinghbrar@gmail.com>
To: "A.s. Dong" <aisheng.dong@nxp.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Devicetree List <devicetree@vger.kernel.org>,
	Oleksij Rempel <o.rempel@pengutronix.de>,
	Rob Herring <robh+dt@kernel.org>, ",
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	srv_heupstream" <linux-arm-kernel@lists.infradead.org>, ",
	Sascha Hauer" <kernel@pengutronix.de>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	Shawn Guo <shawnguo@kernel.org>,
	Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH v8 4/4] mailbox: Add support for i.MX7D messaging unit
Date: Wed, 1 Aug 2018 15:15:08 +0530	[thread overview]
Message-ID: <CABb+yY1pWAUDa33AvHy9LiPjp+r__F3v8w_z0uPJ-4eJ4nzuFA@mail.gmail.com> (raw)
In-Reply-To: <AM0PR04MB42118C26A7C5F80FD46FBB9B802D0@AM0PR04MB4211.eurprd04.prod.outlook.com>

On Wed, Aug 1, 2018 at 1:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
>> -----Original Message-----
>> From: Jassi Brar [mailto:jassisinghbrar@gmail.com]
>
> [...]
>
>> > +
>> > +static void imx_mu_txdb_work(struct work_struct *work) {
>> > +       struct imx_mu_con_priv *cp =
>> > +                       container_of(work, struct imx_mu_con_priv, work);
>> > +       mbox_chan_txdone(cp->chan, 0); }
>> >
>> The api assumes a controller have same type of channels. So we are having
>> to do this here.
>> I am not sure, but would declaring two mailbox controllers (one with
>> doorbells and the other data channels) work?
>> If not, at least we could use a tasklet instead of a work queue?
>>
>
> I'm also a bit curious what the meaning of calling mbox_chan_txdone
> for a doorbell mailbox?
>
> Is there any recommended way to use it?
>
The framework submits a message (a signal with or without data) for
controller to transmit. Obviously, it has to know when the transfer
completes (so that it can submit the next message).

Depending on the controller h/w design, there can be three ways.

a) Controller has some irq that fires when the signal is consumed by
the other end. Like MU does. So upon TX-IRQ, the controller driver
calls mbox_chan_txdone() to tell the framework that the last submitted
transfer has completed. This is indicated by setting only  txdone_irq
= true

b) Controller does not have any tx-irq, but it can read some register
to know the status. That is it has to be polled. The framework calls
last_tx_done() periodically to check the status. This is indicated by
setting only  txdone_poll = true.

c) Controller has neither irq, nor any status register. This is
indicated by setting only  txdone_irq = false and  txdone_poll =
false.   In this case, the protocol/client has to tell the framework
(using some protocol level indicator like some ack packet reception)
when the last submitted message was transferred, by calling
mbox_client_txdone()

A 'doorbell' is  (c) type channel -- just an irq raised at other end
without any ack irq or status bit to check. So, the client would
simply do
                mbox_send_message(chan, msg);
                mbox_client_txdone(chan, 0);

WARNING: multiple messages have this Message-ID (diff)
From: jassisinghbrar@gmail.com (Jassi Brar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 4/4] mailbox: Add support for i.MX7D messaging unit
Date: Wed, 1 Aug 2018 15:15:08 +0530	[thread overview]
Message-ID: <CABb+yY1pWAUDa33AvHy9LiPjp+r__F3v8w_z0uPJ-4eJ4nzuFA@mail.gmail.com> (raw)
In-Reply-To: <AM0PR04MB42118C26A7C5F80FD46FBB9B802D0@AM0PR04MB4211.eurprd04.prod.outlook.com>

On Wed, Aug 1, 2018 at 1:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
>> -----Original Message-----
>> From: Jassi Brar [mailto:jassisinghbrar at gmail.com]
>
> [...]
>
>> > +
>> > +static void imx_mu_txdb_work(struct work_struct *work) {
>> > +       struct imx_mu_con_priv *cp =
>> > +                       container_of(work, struct imx_mu_con_priv, work);
>> > +       mbox_chan_txdone(cp->chan, 0); }
>> >
>> The api assumes a controller have same type of channels. So we are having
>> to do this here.
>> I am not sure, but would declaring two mailbox controllers (one with
>> doorbells and the other data channels) work?
>> If not, at least we could use a tasklet instead of a work queue?
>>
>
> I'm also a bit curious what the meaning of calling mbox_chan_txdone
> for a doorbell mailbox?
>
> Is there any recommended way to use it?
>
The framework submits a message (a signal with or without data) for
controller to transmit. Obviously, it has to know when the transfer
completes (so that it can submit the next message).

Depending on the controller h/w design, there can be three ways.

a) Controller has some irq that fires when the signal is consumed by
the other end. Like MU does. So upon TX-IRQ, the controller driver
calls mbox_chan_txdone() to tell the framework that the last submitted
transfer has completed. This is indicated by setting only  txdone_irq
= true

b) Controller does not have any tx-irq, but it can read some register
to know the status. That is it has to be polled. The framework calls
last_tx_done() periodically to check the status. This is indicated by
setting only  txdone_poll = true.

c) Controller has neither irq, nor any status register. This is
indicated by setting only  txdone_irq = false and  txdone_poll =
false.   In this case, the protocol/client has to tell the framework
(using some protocol level indicator like some ack packet reception)
when the last submitted message was transferred, by calling
mbox_client_txdone()

A 'doorbell' is  (c) type channel -- just an irq raised at other end
without any ack irq or status bit to check. So, the client would
simply do
                mbox_send_message(chan, msg);
                mbox_client_txdone(chan, 0);

  reply	other threads:[~2018-08-01  9:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31 14:11 [PATCH v8 0/4] add mailbox support for i.MX7D Oleksij Rempel
2018-07-31 14:11 ` Oleksij Rempel
2018-07-31 14:11 ` [PATCH v8 1/4] dt-bindings: arm: fsl: add mu binding doc Oleksij Rempel
2018-07-31 14:11   ` Oleksij Rempel
2018-07-31 14:11 ` [PATCH v8 2/4] dt-bindings: mailbox: imx-mu: add generic MU channel support Oleksij Rempel
2018-07-31 14:11   ` Oleksij Rempel
2018-07-31 15:58   ` Jassi Brar
2018-07-31 15:58     ` Jassi Brar
2018-08-01  5:05     ` Oleksij Rempel
2018-08-01  5:05       ` Oleksij Rempel
2018-08-02 10:07       ` A.s. Dong
2018-08-02 10:07         ` A.s. Dong
2018-08-02 14:09       ` Rob Herring
2018-08-02 14:09         ` Rob Herring
2018-08-01  8:58     ` A.s. Dong
2018-08-01  8:58       ` A.s. Dong
2018-08-01  9:58       ` Jassi Brar
2018-08-01  9:58         ` Jassi Brar
2018-08-02  3:37         ` A.s. Dong
2018-08-02  3:37           ` A.s. Dong
2018-07-31 19:09   ` Rob Herring
2018-07-31 19:09     ` Rob Herring
2018-07-31 14:11 ` [PATCH v8 3/4] ARM: dts: imx7s: add i.MX7 messaging unit support Oleksij Rempel
2018-07-31 14:11   ` Oleksij Rempel
2018-07-31 14:11 ` [PATCH v8 4/4] mailbox: Add support for i.MX7D messaging unit Oleksij Rempel
2018-07-31 14:11   ` Oleksij Rempel
2018-07-31 16:21   ` Jassi Brar
2018-07-31 16:21     ` Jassi Brar
2018-08-01  5:31     ` Oleksij Rempel
2018-08-01  5:31       ` Oleksij Rempel
2018-08-01  7:02       ` Jassi Brar
2018-08-01  7:02         ` Jassi Brar
2018-08-01  7:44     ` A.s. Dong
2018-08-01  7:44       ` A.s. Dong
2018-08-01  9:45       ` Jassi Brar [this message]
2018-08-01  9:45         ` Jassi Brar
2018-08-02  3:03         ` A.s. Dong
2018-08-02  3:03           ` A.s. Dong
2018-08-01  7:52   ` A.s. Dong
2018-08-01  7:52     ` A.s. Dong
2018-08-01  8:00     ` Oleksij Rempel
2018-08-01  8:00       ` Oleksij Rempel

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=CABb+yY1pWAUDa33AvHy9LiPjp+r__F3v8w_z0uPJ-4eJ4nzuFA@mail.gmail.com \
    --to=jassisinghbrar@gmail.com \
    --cc=aisheng.dong@nxp.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fabio.estevam@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=mark.rutland@arm.com \
    --cc=o.rempel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=vladimir_zapolskiy@mentor.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.