From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jassi Brar Subject: Re: [PATCH v7 3/6] dt-bindings: mailbox: imx-mu: add generic MU channel support Date: Mon, 30 Jul 2018 21:48:35 +0530 Message-ID: References: <20180730144435.srxgohwgdhrmw2rz@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Oleksij Rempel Cc: "A.s. Dong" , Mark Rutland , Devicetree List , Rob Herring , ", linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, srv_heupstream" ", linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, srv_heupstream" , ", Sascha Hauer" , Fabio Estevam , Shawn Guo , Vladimir Zapolskiy , dl-linux-imx List-Id: devicetree@vger.kernel.org On Mon, Jul 30, 2018 at 8:32 PM, Jassi Brar wrote: > On Mon, Jul 30, 2018 at 8:14 PM, Oleksij Rempel 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: jassisinghbrar@gmail.com (Jassi Brar) Date: Mon, 30 Jul 2018 21:48:35 +0530 Subject: [PATCH v7 3/6] dt-bindings: mailbox: imx-mu: add generic MU channel support In-Reply-To: References: <20180730144435.srxgohwgdhrmw2rz@pengutronix.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jul 30, 2018 at 8:32 PM, Jassi Brar wrote: > On Mon, Jul 30, 2018 at 8:14 PM, Oleksij Rempel 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 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.