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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 30, 2018 at 8:32 PM, Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote:
> On Mon, Jul 30, 2018 at 8:14 PM, Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux