RE: [PATCH v26 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and transfer-mode properties
Ryan Chen <[email protected]>
| Newsgroups | org.ozlabs.lists.openbmc,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-i2c,org.kernel.vger.linux-kernel,org.ozlabs.lists.linux-aspeed |
|---|---|
| Message-ID | <TY2PPF5CB9A1BE6D9A83DFAA004E795A5FCF241A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com> |
> Subject: Re: [PATCH v26 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs > and transfer-mode properties > > Hi Ryan, > > > Your understanding is correct; the byte and buffer mode is mostly the > > same. And also mode should be decided before xfer, due to the > > controller/target both use the same xfer mode, not decide by transfer > > time. The original my submit is only buffer mode and dma mode, and use > > only one Boolean property, aspeed,i2c-dma-enabled, but someone suggest > > add byte mode select, so I start to add at v17. I can drop the byte > > mode, if this is confused. > > > > byte mode request: > > https://lore.kernel.org/all/010e55e9-d58b-444c-ab57- > > [email protected]/ > > OK, that sounds like more driver configuration than hardware description > though. > > > > Ryan: I think this gives us a much cleaner approach to the binding. > > Thanks the feedback, do you mean, just one boolean property for mode > > selection, Am I right? > > It's less about "mode selection" (which is a driver implementation > consideration) and more about "hardware capability", which I think the > boolean property better represents. > > The driver implementation could do whatever it likes with the information > about whether a DMA channel is allocated (and select a suitable mode > depending on that, and/or other runtime data). > > This property only seems to be applicable to 2600 though, as there is no need > for it on 2700, if all controllers are DMA-capable. > Thanks the input, I will modify support boolean property aspeed,i2c-dma-enabled, Yes, ast2700 all controller support DMA.