RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma 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 <TY2PPF5CB9A1BE604170FEFB84227925F09F25BA@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
> 
> On Tue, Mar 31, 2026 at 07:30:58AM +0000, Ryan Chen wrote:
> > > Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add
> > > global-regs and enable-dma properties
> > >
> > > Hi Ryan,
> > >
> > > > > Sounds reasonable, but before you do so, how are you planning to
> > > > > manage the allocation of DMA channels across multiple i2c
> peripherals?
> > > > >
> > > > The AST2600 I2C hardware has only one can use DMA at a time.
> > > > To avoid the complexity of managing DMA channel contention, I plan
> > > > to use buffer mode by default for all controllers, which still
> > > > provides better performance than byte mode without requiring DMA
> > > > channel
> > > allocation.
> > >
> > > OK, but your wording there ("by default") implies that DMA is still
> > > selectable for one controller peripheral. In which case: you still
> > > have the problem of managing DMA channel contention, but now it's at
> runtime instead.
> > >
> > > So my question still stands: how are you planning to enforce that
> > > DMA is only enabled for one controller?
> > >
> > > Or are you planning to disable I2C DMA entirely on AST2600?
> > Yes, This is my intent to do.
> > Disable I2C DMA entirely on AST2600.
> > If I remove DMA, should can I keep byte and buffer for sysfs?
> 

> 28 versions and it's still not clear when you need what mode. Sigh. The only
> thing better about sysfs then it's not my problem, but that really doesn't sound
> much better.
> 
> DMA is only going to be useful for transfers above a certain size. If you are
> doing the typical SMBus style register accesses, then DMA is completely
> useless. The setup DMA overhead is going to be greater than just directly
> reading/writing the I2C controller FIFOs.

Sorry, why you think DMA overhead is greater than read/write FIFO?
When enable DMA, all dma allocate will be initial in probe.
And the DMA mode data is going to dram, that will be read/write data from
dram. Compare with buffer mode, data is from FIFO register to read/write.
So DMA will not have overhead.

> What's the size that makes DMA
> useful? 16, 32, 64 bytes? 
The i2c ast2600 can be 4096 byte for each tx/rx dma,
buffer mode is 32byte (16 byte for TX, 16 byte for RX).

>Something greater than the max size in buffer mode
> probably. Really, provide some data that DMA gives better performance
> and/or less CPU usage. 
In general i2c transfer len < buffer size. dma did not gain. 
But if large than buffer size (16 byte), it will reduce the cpu interrupt latency.
For example, mctp transfer : 
https://github.com/torvalds/linux/blob/master/drivers/net/mctp/mctp-i2c.c#L29
mctp max len is 256, that will 1 interrupt for each package transfer.
But in fifo mode will be 256/16 = 16 interrupts.
Compare the smbus I2C_SMBUS_BLOCK_MAX is 32 byte + 2
https://github.com/torvalds/linux/blob/master/include/uapi/linux/i2c.h#L145
That is only (32 + 2)/16 = 2~3 interrupts. It may not gain more. 

>If you set some minimum size and request DMA only
> above that size, is there really that much contention?
Sorry, I don't know your point here, could you give more your statement?

> If there's some specific
> device that really needs DMA, then make that device's driver request it and
> reserve it.
> 
> For byte mode, there's not a clear need nor description of why. Someone once
> long ago asked for it... Who cares, if they really want it, then the issue needs to
> be described. If a certain device requires certain timing that byte mode
> provides, then that should be some property the driver for the device
> communicates to the controller. No need for DT nor sysfs in that case.
> 
I agree with your point.
My proposal will remove byte mode. And keep dma/buffer. And remove sysfs for 
transfer mode selection, default will be buffer mode. And keep properties
aspeed,enable-dma, which indicate the channel have DMA capability to use.
And if dts add aspeed,enable-dma, the i2c will use DMA otherwise will keep buffer
transfer, is it ok?
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.