Re: [PATCH v26 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and transfer-mode properties
Jeremy Kerr <[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 | <9dec962eb510d947a458fd2318a3812d58b3553a.camel@codeconstruct.com.au> |
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. Cheers, Jeremy