On Mon, Jul 30, 2018 at 09:48:35PM +0530, Jassi Brar wrote:

On Mon, Jul 30, 2018 at 8:32 PM, Jassi Brar [off-list ref] wrote:

quoted

On Mon, Jul 30, 2018 at 8:14 PM, Oleksij Rempel [off-list ref] wrote:

quoted

On Mon, Jul 30, 2018 at 06:34:56PM +0530, Jassi Brar wrote:

quoted

On Mon, Jul 30, 2018 at 1:05 PM, Oleksij Rempel [off-list ref] wrote:

quoted

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).

quoted

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 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180730/d16bec26/attachment.sig>