From: Vinod Koul <vinod.koul@intel.com>
To: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Mark Brown <broonie@kernel.org>,
Doug Anderson <dianders@chromium.org>,
Olof Johansson <olof@lixom.net>,
Sonny Rao <sonnyrao@chromium.org>,
Addy Ke <addy.ke@rock-chips.com>,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, alsa-devel@alsa-project.org,
linux-spi@vger.kernel.org
Subject: Re: [PATCH v5 06/10] dmaengine: add API for getting dma controller's quirk
Date: Wed, 7 Oct 2015 15:32:06 +0100 [thread overview]
Message-ID: <20151007143205.GG3320@vkoul-mobl.iind.intel.com> (raw)
In-Reply-To: <56139289.7000005@rock-chips.com>
On Tue, Oct 06, 2015 at 05:21:13PM +0800, Shawn Lin wrote:
> >>+ int (*device_get_quirks)(struct dma_chan *chan);
> >
> >And why do we want to expose this to users? THis doesnt seem right!
> >
>
> Basically I agree not to expose dma's quirk to slave controllers...But, the
> fact I mentioned on cover letter explain the reasons why I have to let slave
> controllers know that they are working with a broken dma. It's a dilemma
> that if we don't want that to be exposed(let slave controllers' driver get
> the info via a API), we have to add broken quirk for all of them ,here and
> there, which seems to be a disaster:(
>
> I would appreciate it if you could give me some suggestions at your earliest
> convenience. :)
>
> >A quirk may exists but should be handled inside the controller driver and do
> >appropriate action. You don't tell users or expect them to handle these
> >
I laready gave one re-read the above lines.
Anyway I went ahead and read the usage. You are setting the slave parameters
for this. I can see two ways:
1. Have the quirk to driver and based on quirk reset the slave settings when
they are set by client.
2. Put this in DT and set the dma properties based on these quirks and let
driver and cleint be agnostic to it
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Cc: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
Jaroslav Kysela <perex-/Fr2/VpizcU@public.gmane.org>,
Takashi Iwai <tiwai-IBi9RG/b67k@public.gmane.org>,
Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
Sonny Rao <sonnyrao-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Addy Ke <addy.ke-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v5 06/10] dmaengine: add API for getting dma controller's quirk
Date: Wed, 7 Oct 2015 15:32:06 +0100 [thread overview]
Message-ID: <20151007143205.GG3320@vkoul-mobl.iind.intel.com> (raw)
In-Reply-To: <56139289.7000005-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Tue, Oct 06, 2015 at 05:21:13PM +0800, Shawn Lin wrote:
> >>+ int (*device_get_quirks)(struct dma_chan *chan);
> >
> >And why do we want to expose this to users? THis doesnt seem right!
> >
>
> Basically I agree not to expose dma's quirk to slave controllers...But, the
> fact I mentioned on cover letter explain the reasons why I have to let slave
> controllers know that they are working with a broken dma. It's a dilemma
> that if we don't want that to be exposed(let slave controllers' driver get
> the info via a API), we have to add broken quirk for all of them ,here and
> there, which seems to be a disaster:(
>
> I would appreciate it if you could give me some suggestions at your earliest
> convenience. :)
>
> >A quirk may exists but should be handled inside the controller driver and do
> >appropriate action. You don't tell users or expect them to handle these
> >
I laready gave one re-read the above lines.
Anyway I went ahead and read the usage. You are setting the slave parameters
for this. I can see two ways:
1. Have the quirk to driver and based on quirk reset the slave settings when
they are set by client.
2. Put this in DT and set the dma properties based on these quirks and let
driver and cleint be agnostic to it
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 06/10] dmaengine: add API for getting dma controller's quirk
Date: Wed, 7 Oct 2015 15:32:06 +0100 [thread overview]
Message-ID: <20151007143205.GG3320@vkoul-mobl.iind.intel.com> (raw)
In-Reply-To: <56139289.7000005@rock-chips.com>
On Tue, Oct 06, 2015 at 05:21:13PM +0800, Shawn Lin wrote:
> >>+ int (*device_get_quirks)(struct dma_chan *chan);
> >
> >And why do we want to expose this to users? THis doesnt seem right!
> >
>
> Basically I agree not to expose dma's quirk to slave controllers...But, the
> fact I mentioned on cover letter explain the reasons why I have to let slave
> controllers know that they are working with a broken dma. It's a dilemma
> that if we don't want that to be exposed(let slave controllers' driver get
> the info via a API), we have to add broken quirk for all of them ,here and
> there, which seems to be a disaster:(
>
> I would appreciate it if you could give me some suggestions at your earliest
> convenience. :)
>
> >A quirk may exists but should be handled inside the controller driver and do
> >appropriate action. You don't tell users or expect them to handle these
> >
I laready gave one re-read the above lines.
Anyway I went ahead and read the usage. You are setting the slave parameters
for this. I can see two ways:
1. Have the quirk to driver and based on quirk reset the slave settings when
they are set by client.
2. Put this in DT and set the dma properties based on these quirks and let
driver and cleint be agnostic to it
--
~Vinod
next prev parent reply other threads:[~2015-10-07 14:32 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-13 23:45 [PATCH v5 0/10] Fix broken DMAFLUSHP on Rockchips platform Shawn Lin
2015-09-13 23:45 ` Shawn Lin
2015-09-13 23:45 ` Shawn Lin
2015-09-13 23:46 ` [PATCH v5 01/10] DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit Shawn Lin
2015-09-13 23:46 ` Shawn Lin
2015-09-13 23:46 ` Shawn Lin
2015-09-13 23:46 ` [PATCH v5 02/10] Documentation: arm-pl330: add description of arm,pl330-broken-no-flushp Shawn Lin
2015-09-13 23:46 ` [PATCH v5 02/10] Documentation: arm-pl330: add description of arm, pl330-broken-no-flushp Shawn Lin
2015-09-13 23:46 ` [PATCH v5 02/10] Documentation: arm-pl330: add description of arm,pl330-broken-no-flushp Shawn Lin
2015-09-13 23:48 ` [PATCH v5 03/10] DMA: pl330: add quirk for broken no flushp Shawn Lin
2015-09-13 23:48 ` Shawn Lin
2015-09-13 23:48 ` [PATCH v5 04/10] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3288 platform Shawn Lin
2015-09-13 23:48 ` [PATCH v5 04/10] ARM: dts: Add arm, pl330-broken-no-flushp " Shawn Lin
2015-09-13 23:48 ` [PATCH v5 05/10] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3xxx platform Shawn Lin
2015-09-13 23:48 ` [PATCH v5 05/10] ARM: dts: Add arm, pl330-broken-no-flushp " Shawn Lin
2015-09-13 23:48 ` [PATCH v5 06/10] dmaengine: add API for getting dma controller's quirk Shawn Lin
2015-09-13 23:48 ` Shawn Lin
2015-10-05 15:37 ` Vinod Koul
2015-10-05 15:37 ` Vinod Koul
2015-10-06 9:21 ` Shawn Lin
2015-10-06 9:21 ` Shawn Lin
2015-10-06 9:21 ` Shawn Lin
2015-10-07 14:32 ` Vinod Koul [this message]
2015-10-07 14:32 ` Vinod Koul
2015-10-07 14:32 ` Vinod Koul
2015-10-09 11:23 ` Shawn Lin
2015-10-09 11:23 ` Shawn Lin
2015-10-09 11:23 ` Shawn Lin
2015-10-08 8:31 ` [alsa-devel] " Lars-Peter Clausen
2015-10-08 8:31 ` Lars-Peter Clausen
2015-10-08 8:31 ` Lars-Peter Clausen
2015-10-09 11:31 ` [alsa-devel] " Shawn Lin
2015-10-09 11:31 ` Shawn Lin
2015-10-09 11:31 ` Shawn Lin
2015-10-09 11:38 ` Lars-Peter Clausen
2015-10-09 11:38 ` Lars-Peter Clausen
2015-10-14 10:53 ` Vinod Koul
2015-10-14 10:53 ` Vinod Koul
2015-10-14 10:53 ` Vinod Koul
2015-10-14 14:33 ` Shawn Lin
2015-10-14 14:33 ` Shawn Lin
2015-10-14 14:33 ` Shawn Lin
2015-09-13 23:49 ` [PATCH v5 07/10] DMA: pl330: implement dmaengine_get_quirks hook Shawn Lin
2015-09-13 23:49 ` Shawn Lin
2015-09-13 23:49 ` [PATCH v5 08/10] spi: rockchip: modify DMA max burst to 1 Shawn Lin
2015-09-13 23:49 ` Shawn Lin
2015-09-13 23:49 ` [PATCH v5 09/10] snd: dmaengine-pcm: add snd_dmaengine_pcm_get_quirks interface Shawn Lin
2015-09-13 23:49 ` Shawn Lin
2015-09-13 23:49 ` Shawn Lin
2015-09-13 23:49 ` [PATCH v5 10/10] ASoC: rockchip_i2s: modify DMA max burst to 1 Shawn Lin
2015-09-13 23:49 ` Shawn Lin
2015-09-13 23:49 ` Shawn Lin
2015-09-16 19:22 ` Mark Brown
2015-09-16 19:22 ` Mark Brown
2015-09-16 19:22 ` Mark Brown
2015-09-28 1:59 ` [PATCH v5 0/10] Fix broken DMAFLUSHP on Rockchips platform Shawn Lin
2015-09-28 1:59 ` Shawn Lin
2015-09-28 1:59 ` Shawn Lin
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=20151007143205.GG3320@vkoul-mobl.iind.intel.com \
--to=vinod.koul@intel.com \
--cc=addy.ke@rock-chips.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dianders@chromium.org \
--cc=dmaengine@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=olof@lixom.net \
--cc=perex@perex.cz \
--cc=shawn.lin@rock-chips.com \
--cc=sonnyrao@chromium.org \
--cc=tiwai@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.