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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.