From: Mark Brown <broonie@kernel.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
linux-spi@vger.kernel.org, Eric Anholt <eric@anholt.net>,
linux-rpi-kernel@lists.infradead.org, kernel@martin.sperl.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V2 5/6] spi: bcm2835: make the lower limit for dma mode configurable
Date: Wed, 8 May 2019 17:42:05 +0900 [thread overview]
Message-ID: <20190508084205.GD14916@sirena.org.uk> (raw)
In-Reply-To: <20190424070712.hh6ozvhkvkxhwak3@wunner.de>
[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]
On Wed, Apr 24, 2019 at 09:07:12AM +0200, Lukas Wunner wrote:
> Indeed I'd prefer if another bit is added to "mode" in struct device
> to represent the need for another clock cycle in-between bytes.
> The SPI core could then reduce the clock speed based on this flag
> and the problem would be solved for everyone.
> Influencing this behavior with a module parameter feels a bit like a
> kludge and I fear may stay indefinitely even if a better solution
> is implemented later.
This does feel like we know enough to have a more advanced function in
the driver given a bit of information about the client device
requireemnts. Though it's going to be complex to express them,
especially with the ATMega case where we want fast individual clocks but
lots of dead space in between bytes (is the controller capable of adding
that dead space itself in DMA mode BTW?).
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-08 8:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 20:15 [PATCH V2 0/6] spi: bcm2835: improvements kernel
[not found] ` <20190423201513.8073-1-kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
2019-04-23 20:15 ` [PATCH V2 1/6] spi: bcm2835: bcm2835_spi_transfer_one_poll remove unnecessary argument kernel-TqfNSX0MhmxHKSADF0wUEw
2019-05-08 8:26 ` Mark Brown
[not found] ` <20190423201513.8073-2-kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
2019-05-08 9:08 ` Applied "spi: bcm2835: bcm2835_spi_transfer_one_poll remove unnecessary argument" to the spi tree Mark Brown
2019-04-23 20:15 ` [PATCH V2 3/6] spi: bcm2835: added comment about different bus behaviour of DMA mode kernel-TqfNSX0MhmxHKSADF0wUEw
2019-05-08 9:08 ` Applied "spi: bcm2835: added comment about different bus behaviour of DMA mode" to the spi tree Mark Brown
2019-04-23 20:15 ` [PATCH V2 4/6] spi: bcm2835: make the polling duration limits configurable kernel-TqfNSX0MhmxHKSADF0wUEw
2019-05-08 9:08 ` Applied "spi: bcm2835: make the polling duration limits configurable" to the spi tree Mark Brown
2019-04-23 20:15 ` [PATCH V2 5/6] spi: bcm2835: make the lower limit for dma mode configurable kernel-TqfNSX0MhmxHKSADF0wUEw
[not found] ` <20190424070712.hh6ozvhkvkxhwak3@wunner.de>
2019-05-08 8:42 ` Mark Brown [this message]
[not found] ` <20190508084205.GD14916-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2019-05-08 10:55 ` kernel-TqfNSX0MhmxHKSADF0wUEw
2019-04-23 20:15 ` [PATCH V2 6/6] spi: bcm2835: add driver stats to debugfs kernel-TqfNSX0MhmxHKSADF0wUEw
2019-05-08 9:08 ` Applied "spi: bcm2835: add driver stats to debugfs" to the spi tree Mark Brown
2019-04-23 20:15 ` [PATCH V2 2/6] spi: bcm2835: Avoid 64-bit arithmetic in xfer len calc kernel
2019-05-08 9:08 ` Applied "spi: bcm2835: Avoid 64-bit arithmetic in xfer len calc" to the spi tree Mark Brown
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=20190508084205.GD14916@sirena.org.uk \
--to=broonie@kernel.org \
--cc=eric@anholt.net \
--cc=kernel@martin.sperl.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=stefan.wahren@i2se.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;
as well as URLs for NNTP newsgroup(s).