public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Ryan Chen <ryan_chen@aspeedtech.com>
Cc: Jeremy Kerr <jk@codeconstruct.com.au>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	"andriy.shevchenko@linux.intel.com"
	<andriy.shevchenko@linux.intel.com>,
	Andi Shyti <andi.shyti@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
	Andrew Jeffery <andrew@codeconstruct.com.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
Date: Tue, 7 Apr 2026 15:44:02 -0500	[thread overview]
Message-ID: <20260407204402.GA3641251-robh@kernel.org> (raw)
In-Reply-To: <TY2PPF5CB9A1BE64B7988CD85A7189164E1F253A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>

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. What's the size 
that makes DMA useful? 16, 32, 64 bytes? Something greater than the max 
size in buffer mode probably. Really, provide some data that DMA gives 
better performance and/or less CPU usage. If you set some minimum size 
and request DMA only above that size, is there really that much 
contention? 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.

Rob

  reply	other threads:[~2026-04-07 20:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30  8:21 [PATCH v28 0/4] Add ASPEED AST2600 I2C controller driver Ryan Chen
2026-03-30  8:21 ` [PATCH v28 1/4] dt-bindings: i2c: Split AST2600 binding into a new YAML Ryan Chen
2026-03-30  8:21 ` [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties Ryan Chen
2026-03-31  6:47   ` Krzysztof Kozlowski
2026-03-31  6:58     ` Ryan Chen
2026-03-31  7:00       ` Jeremy Kerr
2026-03-31  7:09         ` Ryan Chen
2026-03-31  7:17           ` Jeremy Kerr
2026-03-31  7:30             ` Ryan Chen
2026-04-07 20:44               ` Rob Herring [this message]
2026-04-08  7:18                 ` Ryan Chen
2026-03-30  8:21 ` [PATCH v28 3/4] i2c: ast2600: Add controller driver for AST2600 new register set Ryan Chen
2026-03-30  8:21 ` [PATCH v28 4/4] i2c: ast2600: Add target mode support Ryan Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260407204402.GA3641251-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=andi.shyti@kernel.org \
    --cc=andrew@codeconstruct.com.au \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jk@codeconstruct.com.au \
    --cc=joel@jms.id.au \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=p.zabel@pengutronix.de \
    --cc=ryan_chen@aspeedtech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox