From: Vinod Koul <vinod.koul@intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, patchwork-lst@pengutronix.de,
kernel@pengutronix.de, peter.seiderer.ext@zeiss.com,
dmaengine@vger.kernel.org, Lucas Stach <l.stach@pengutronix.de>,
LW@KARO-electronics.de
Subject: Re: [PATCH] dmaengine: imx-sdma: advertise all supported slave bus widths
Date: Mon, 16 Oct 2017 11:58:36 +0530 [thread overview]
Message-ID: <20171016062836.GJ30097@localhost> (raw)
In-Reply-To: <20171013171303.ardykpvxg5tm5q3v@sirena.co.uk>
On Fri, Oct 13, 2017 at 06:13:03PM +0100, Mark Brown wrote:
> On Fri, Oct 13, 2017 at 04:50:01PM +0200, Lucas Stach wrote:
> > Am Freitag, den 13.10.2017, 15:39 +0100 schrieb Mark Brown:
>
> > > ...I'm talking about the constraints supported on the DMA side. I would
> > > not expect the DMA side to be accepting things it said it didn't support.
>
> > AFAIR the caps for the supported slave bus width were introduced later
> > than other caps and not all drivers did implement them properly, so
> > validation at the core level at this time would probably have broken a
> > lot of existing users.
>
> > That said the dmaengine core warns since kernel 4.0 if a driver doesn't
> > set those caps, so it's probably fine if we cook up a patch to do the
> > validation now.
>
> That can should be able to be handled cleanly by enforcing any caps that
> are advertised but if the driver doesn't declare anything at all then
> just accepting anything and leaving it up to the driver to cope.
well DMAengine core cannot guess what hardware supports, but if not provided
we may want to go back to a saner default values which people might support.
But then, not doing this helps people find issues and fix them :)
So which is a better deal?
--
~Vinod
next prev parent reply other threads:[~2017-10-16 6:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 10:43 [PATCH] dmaengine: imx-sdma: advertise all supported slave bus widths Lucas Stach
2017-10-13 11:23 ` Lothar Waßmann
2017-10-13 11:25 ` Mark Brown
2017-10-13 11:35 ` Lucas Stach
2017-10-13 14:39 ` Mark Brown
2017-10-13 14:50 ` Lucas Stach
2017-10-13 17:13 ` Mark Brown
2017-10-16 6:28 ` Vinod Koul [this message]
2017-10-16 9:19 ` Mark Brown
2017-10-16 6:51 ` Vinod Koul
2017-10-16 7:26 ` Lucas Stach
2017-10-31 12:13 ` Vinod Koul
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=20171016062836.GJ30097@localhost \
--to=vinod.koul@intel.com \
--cc=LW@KARO-electronics.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=patchwork-lst@pengutronix.de \
--cc=peter.seiderer.ext@zeiss.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).