Re: [PATCH v7 3/6] dt-bindings: mailbox: imx-mu: add generic MU channel support

[Oleksij Rempel <o.rempel@pengutronix.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3101 bytes --]

On Mon, Jul 30, 2018 at 09:48:35PM +0530, Jassi Brar wrote:
> On Mon, Jul 30, 2018 at 8:32 PM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > On Mon, Jul 30, 2018 at 8:14 PM, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> >> On Mon, Jul 30, 2018 at 06:34:56PM +0530, Jassi Brar wrote:
> >>> On Mon, Jul 30, 2018 at 1:05 PM, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> >>> > Hi Aishen, Jassie,
> >>> >
> >>> > i'm lost in this discussion. Please, as soon as I need to add some
> >>> > changes to my patches, notify me. Preferably on top for email.
> >>> >
> >>> I am ok with however you choose to implement, 8 unidirectional or 4
> >>> bidirectional channels or whatever.
> >>>
> >>> We just can't have protocol specific s/w modes in the controller drivers.
> >>>
> >>> The best solution is to fix the SCU firmware. If that is _really_
> >>> impossible, I provided a solution (3 cells work around). If you have a
> >>> better idea please feel free to propose and implement that.
> >>>
> >>> It will also help if you could share the user code of "scu-mode". If
> >>> there is no such code (and we know the driver doesn't respect the
> >>> "scu-mode" property) why do we even have that binding? Maybe drop it.
> >>
> >> Tomorrow I have a time slot to address your generic iMX MU suggestions.
> >> So, what is better, uni- or bi-directional channels?
> >>
> > The datasheet indicates there are 4 tx and 4 rx channels. So 8
> > uni-directional channels (which allow more fine-grained/efficient
> > resource allocation btw).
> >
> >> Should I implement
> >> *all* (4TX+FIFO, 4RX+FIFO, 4TX-simple, 4RX-simple) channels in this run?
> >>
> > From datasheet, each of 8 channels should be defined as signal+data
> > i.e, IRQ + TX/RX_Reg.
> > The rest 4 GP channels are doorbells (irq only).
> >
> > So we can have 2-cells.
> >     First cell is 0->Tx, 1->RX, 2->Doorbell
> >     Second cell is index of the channel {0,3}
> >
> > Now you may implement only RX+TX, and leave 'doorbell' out for future.
> > Thats ok, because we wouldn't have to change bindings then.
> >
> > However, if SCU (in its current form) must be supported. We may need
> > to add the third cell (irq enable or not) or some better way, right
> > now.
> >
> Looking at imx_mu_scu_send_data(), which simply polls on the tx, I
> think we don't even need third cell for scu client. A simple 2-cell, 8
> uni-dir channel setup should work.
> If I see the scu client driver, I could confirm how it would work.
> 
> So, lets please do the 8 uni-directional, 2 cells implementation.

Just in case.. to avoid confusion (or add more...). There are 4 GIP (General Interrupt Request n
Pending bits) or RX-doorbell and 4 GIR (General Interrupt Request bits)
or TX-doorbell.

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel