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 | <TY2PPF5CB9A1BE6EAA73D3AD6F75F1ABD53F241A@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 Rob, > > > > I don't think that really addresses Rob's point there. > > > > > > The selection of mode is somewhat a driver implementation decision > > > (and so would not belong in a DT binding) - *except* that there are > > > considerations around the use of hardware DMA channels, as covered > > > in earlier review. > > > > Am I supposed to go read the prior 25 versions? > > Not at all - the next paragraph was my attempt at a recap of those, but Ryan, > please correct me if I am wrong on any of those points. 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/[email protected]/ > > > > [My understanding is that the mode needs to be defined here to > > > select which i2c devices have a DMA channel allocated to them. I > > > also think that byte mode may be useful in some scenarios, but that > > > consideration certainly does not belong in the DT binding spec] > > > > But this is selecting DMA for the bus, not specific devices. I would > > think the decision would be dynamic based on some xfer size. Certainly > > if the xfer is less than the buffer size (32bytes), then there is no > > advantage of DMA. > > > > Or do you mean some instances of the I2C controllers have DMA and some > > do not? > > Yes, some of the controllers may be allocated a DMA channel. A driver > implementation may (or may not) make use of that channel. > > Since the hardware has a limited numbers of DMA channels, Ryan's aim here is > to specify which controllers may consume a channel. Yes, in AST2600 DMA is shared, so it only can enable 1 channel dma, others use buffer mode, and in next generation AST2700, all i2c channel can use dma. > > (in relation to the 'bus' terminology though: there is a 1:1 mapping between > i2c buses and controllers here, plus a small area of global registers which apply > to all controller peripherals) > > > If so, then ... > > [...] > > > > In that case, we would just have a boolean property, like: > > > > > > aspeed,i2c-dma-enabled; > > > > ... yes, this is fine. > > Brilliant, thanks. > > 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? > > Cheers, > > > Jeremy