Devicetree

* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-04-08  7:18 UTC (permalink / raw)
  To: Rob Herring
  Cc: Jeremy Kerr, Krzysztof Kozlowski,
	andriy.shevchenko@linux.intel.com, Andi Shyti,
	Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
	Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	openbmc@lists.ozlabs.org
In-Reply-To: <20260407204402.GA3641251-robh@kernel.org>

> 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?

^ permalink raw reply