On Mon, Jul 30, 2018 at 10:19 PM, Oleksij Rempel
<o.rempel@xxxxxxxxxxxxxx> wrote:
> 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@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.
>
> 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.
>
Ok. But the approach remains the same.
thanks.
--
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
