All of lore.kernel.org
 help / color / mirror / Atom feed
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/6] mailbox: Add support for ST's Mailbox IP
Date: Tue, 21 Jul 2015 18:48:51 +0100	[thread overview]
Message-ID: <20150721174851.GP3061@x1> (raw)
In-Reply-To: <CABb+yY1oKJKJGnn345uzE1mnVk5kCaGTO0b4zzqojN39m2OMyg@mail.gmail.com>

On Tue, 21 Jul 2015, Jassi Brar wrote:

> On Tue, Jul 21, 2015 at 9:22 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Tue, 21 Jul 2015, Jassi Brar wrote:
> >
> >> >
> >> >> > +static int sti_mbox_send_data(struct mbox_chan *chan, void *data)
> >> >> > +{
> >> >> > +       struct sti_channel *chan_info = chan->con_priv;
> >> >> > +       struct sti_mbox_device *mdev = chan_info->mdev;
> >> >> > +       struct sti_mbox_pdata *pdata = dev_get_platdata(mdev->dev);
> >> >> > +       unsigned int instance = chan_info->instance;
> >> >> > +       unsigned int channel = chan_info->channel;
> >> >> > +       void __iomem *base;
> >> >> > +
> >> >> > +       if (!sti_mbox_tx_is_ready(chan))
> >> >> > +               return -EBUSY;
> >> >> This is the first thing I look out for in every new driver :)  this
> >> >> check is unnecessary.
> >> >
> >> > In what way?  What if the channel is disabled or there is an IRQ
> >> > already pending?
> >> >
> >> API calls send_data() only if last_tx_done() returned true.
> >
> > I know for a fact that the 'catchers' in sti_mbox_tx_is_ready() to
> > fire, because I have triggered them.  I'd really rather keep this
> > harmless check in.
> >
> If you put some printk in send_data() and last_tx_done() you'll see
> what I mean :)
> 
> >> >> > +static const struct sti_mbox_pdata mbox_stih407_pdata = {
> >> >> > +       .num_inst       = 4,
> >> >> > +       .num_chan       = 32,
> >> >> > +       .irq_val        = 0x04,
> >> >> > +       .irq_set        = 0x24,
> >> >> > +       .irq_clr        = 0x44,
> >> >> > +       .ena_val        = 0x64,
> >> >> > +       .ena_set        = 0x84,
> >> >> > +       .ena_clr        = 0xa4,
> >> >> >
> >> >> Register offsets are parameters of the controller
> >> >
> >> > And this is a controller driver?  Not sure I get the point.
> >> >
> >> Platform_data usually carries board/platform specific parameters.
> >> Register offset "properties" are as fixed as the behavior of the
> >> controller, so they should stay inside the code, not come via
> >> platform_data.
> >
> > That's not the case for this controller.  There is nothing preventing
> > these values from changing on a new board revisions.
> >
> Hmm ... interesting! Can't see how enable/disable channel and irq
> set/clear could be effected by writing to random, but agreed upon,
> location between two processors. There ought to be some controller
> listening there?  Now I am more interested in knowing this IP :)

High level
----------

          MB0       MB1       MB2       MB3       MB4
      +---------+---------+---------+---------+---------+
INST0 |         |         |         |         |         |
      +---------+---------+---------+---------+---------+
INST1 |         |         |         |         |         |
      +---------+---------+---------+---------+---------+
INST2 |         |         |         |         |         |
      +---------+---------+---------+---------+---------+
INST3 |         |         |         |         |         |
      +---------+---------+---------+---------+---------+

Low level [each box above looks like this)
------------------------------------------

         1                                                             32        
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IRQ_VAL | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IRQ_SET | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IRQ_CLR | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ENB_VAL | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ENB_SET | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ENB_CLR | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That's it.  That's the entirety of the "IP".

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	kernel@stlinux.com, Devicetree List <devicetree@vger.kernel.org>
Subject: Re: [PATCH 3/6] mailbox: Add support for ST's Mailbox IP
Date: Tue, 21 Jul 2015 18:48:51 +0100	[thread overview]
Message-ID: <20150721174851.GP3061@x1> (raw)
In-Reply-To: <CABb+yY1oKJKJGnn345uzE1mnVk5kCaGTO0b4zzqojN39m2OMyg@mail.gmail.com>

On Tue, 21 Jul 2015, Jassi Brar wrote:

> On Tue, Jul 21, 2015 at 9:22 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Tue, 21 Jul 2015, Jassi Brar wrote:
> >
> >> >
> >> >> > +static int sti_mbox_send_data(struct mbox_chan *chan, void *data)
> >> >> > +{
> >> >> > +       struct sti_channel *chan_info = chan->con_priv;
> >> >> > +       struct sti_mbox_device *mdev = chan_info->mdev;
> >> >> > +       struct sti_mbox_pdata *pdata = dev_get_platdata(mdev->dev);
> >> >> > +       unsigned int instance = chan_info->instance;
> >> >> > +       unsigned int channel = chan_info->channel;
> >> >> > +       void __iomem *base;
> >> >> > +
> >> >> > +       if (!sti_mbox_tx_is_ready(chan))
> >> >> > +               return -EBUSY;
> >> >> This is the first thing I look out for in every new driver :)  this
> >> >> check is unnecessary.
> >> >
> >> > In what way?  What if the channel is disabled or there is an IRQ
> >> > already pending?
> >> >
> >> API calls send_data() only if last_tx_done() returned true.
> >
> > I know for a fact that the 'catchers' in sti_mbox_tx_is_ready() to
> > fire, because I have triggered them.  I'd really rather keep this
> > harmless check in.
> >
> If you put some printk in send_data() and last_tx_done() you'll see
> what I mean :)
> 
> >> >> > +static const struct sti_mbox_pdata mbox_stih407_pdata = {
> >> >> > +       .num_inst       = 4,
> >> >> > +       .num_chan       = 32,
> >> >> > +       .irq_val        = 0x04,
> >> >> > +       .irq_set        = 0x24,
> >> >> > +       .irq_clr        = 0x44,
> >> >> > +       .ena_val        = 0x64,
> >> >> > +       .ena_set        = 0x84,
> >> >> > +       .ena_clr        = 0xa4,
> >> >> >
> >> >> Register offsets are parameters of the controller
> >> >
> >> > And this is a controller driver?  Not sure I get the point.
> >> >
> >> Platform_data usually carries board/platform specific parameters.
> >> Register offset "properties" are as fixed as the behavior of the
> >> controller, so they should stay inside the code, not come via
> >> platform_data.
> >
> > That's not the case for this controller.  There is nothing preventing
> > these values from changing on a new board revisions.
> >
> Hmm ... interesting! Can't see how enable/disable channel and irq
> set/clear could be effected by writing to random, but agreed upon,
> location between two processors. There ought to be some controller
> listening there?  Now I am more interested in knowing this IP :)

High level
----------

          MB0       MB1       MB2       MB3       MB4
      +---------+---------+---------+---------+---------+
INST0 |         |         |         |         |         |
      +---------+---------+---------+---------+---------+
INST1 |         |         |         |         |         |
      +---------+---------+---------+---------+---------+
INST2 |         |         |         |         |         |
      +---------+---------+---------+---------+---------+
INST3 |         |         |         |         |         |
      +---------+---------+---------+---------+---------+

Low level [each box above looks like this)
------------------------------------------

         1                                                             32        
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IRQ_VAL | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IRQ_SET | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IRQ_CLR | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ENB_VAL | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ENB_SET | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ENB_CLR | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That's it.  That's the entirety of the "IP".

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2015-07-21 17:48 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-17 12:04 [PATCH 0/6] Mailbox: Provide support STi based platforms Lee Jones
2015-07-17 12:04 ` Lee Jones
2015-07-17 12:04 ` [PATCH 1/6] mailbox: dt: Supply bindings for ST's Mailbox IP Lee Jones
2015-07-17 12:04   ` Lee Jones
2015-07-17 12:04   ` Lee Jones
2015-07-17 12:04 ` [PATCH 2/6] mailbox: dt-bindings: Add shared [driver <=> device tree] defines Lee Jones
2015-07-17 12:04   ` Lee Jones
2015-07-17 12:04 ` [PATCH 3/6] mailbox: Add support for ST's Mailbox IP Lee Jones
2015-07-17 12:04   ` Lee Jones
2015-07-21 14:41   ` Jassi Brar
2015-07-21 14:41     ` Jassi Brar
2015-07-21 14:41     ` Jassi Brar
2015-07-21 15:06     ` Lee Jones
2015-07-21 15:06       ` Lee Jones
2015-07-21 15:29       ` Jassi Brar
2015-07-21 15:29         ` Jassi Brar
2015-07-21 15:52         ` Lee Jones
2015-07-21 15:52           ` Lee Jones
2015-07-21 15:52           ` Lee Jones
2015-07-21 16:09           ` Jassi Brar
2015-07-21 16:09             ` Jassi Brar
2015-07-21 17:48             ` Lee Jones [this message]
2015-07-21 17:48               ` Lee Jones
2015-07-21 18:36               ` Jassi Brar
2015-07-21 18:36                 ` Jassi Brar
2015-07-21 18:36                 ` Jassi Brar
2015-07-23  8:29     ` Lee Jones
2015-07-23  8:29       ` Lee Jones
2015-07-23  8:29       ` Lee Jones
2015-07-23 16:31       ` Jassi Brar
2015-07-23 16:31         ` Jassi Brar
2015-07-24  9:36         ` Lee Jones
2015-07-24  9:36           ` Lee Jones
2015-07-24 17:34           ` Jassi Brar
2015-07-24 17:34             ` Jassi Brar
2015-07-23 17:23   ` Alexey Klimov
2015-07-23 17:23     ` Alexey Klimov
2015-07-23 17:23     ` Alexey Klimov
2015-07-24  9:52     ` Lee Jones
2015-07-24  9:52       ` Lee Jones
2015-07-17 12:04 ` [PATCH 4/6] ARM: STi: stih407-family: Add nodes for Mailbox Lee Jones
2015-07-17 12:04   ` Lee Jones
2015-07-17 12:04 ` [PATCH 5/6] mailbox: Add generic mechanism for testing Mailbox Controllers Lee Jones
2015-07-17 12:04   ` Lee Jones
2015-07-17 12:04   ` Lee Jones
2015-07-17 12:04 ` [PATCH 6/6] ARM: STi: DT: STiH407: Enable Mailbox testing facility Lee Jones
2015-07-17 12:04   ` Lee Jones

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=20150721174851.GP3061@x1 \
    --to=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.