From: Ido Yariv <ido@wizery.com>
To: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: davinci-linux-open-source@linux.davincidsp.com,
linux-arm-kernel@lists.arm.linux.org.uk,
linux-mmc@vger.kernel.org
Subject: Re: [PATCH 2/5] arm: davinci: Allow EVENTQ_0 as a default queue
Date: Fri, 8 Jul 2011 17:27:17 +0300 [thread overview]
Message-ID: <20110708142717.GG2176@WorkStation> (raw)
In-Reply-To: <4E16DB13.90806@mvista.com>
Hi,
On Fri, Jul 08, 2011 at 02:25:23PM +0400, Sergei Shtylyov wrote:
> On 08-07-2011 1:33, Ido Yariv wrote:
>
> >Davinci platforms may define a default queue for each channel
> >controller. If one is not defined, the default queue is set to EVENTQ_1.
> >However, there's no way to distinguish between an unset default queue to
> >one that is set to EVENTQ_0, as EVENTQ_0 = 0.
>
> >In order to keep existing behaviour on platforms which don't specify a
> >default_queue member, the default_queue member was modified to be a
> >pointer to enum dma_event_q. A NULL value means that this member was not
> >specified.
>
> Mmm, perhaps it's better to drop the default EVENTQ_1 concept and
> explicitly initilaize that field for every SoC. It's also possible
> to offset the event queue number by 1. I don't like the pointer
> solution.
Dropping the default EVENTQ_1 is probably the best solution, but doing
so has the potential of breaking some Davinci platforms (not currently
in mainline) which don't specify this member.
The second option was also considered - modifying the dma_event_q enum,
incrementing all EVENTQ_X constants, and decrementing the value back in
map_dmach_queue. This approach has two minor drawbacks:
* There are other users of this enum, besides the default queue.
However, AFAIK, there's only one function (map_dmach_queue) that
actually cares about the numerical values.
* If someone currently defines a queue numerically, this code could
break. Obviously, defining a queue numerically is not something that
should be done.
If there aren't any objections, we could go for the first option.
Thanks for your review,
Ido.
next prev parent reply other threads:[~2011-07-08 14:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 21:33 [PATCH 0/5] arm: davinci: DA850: wl12xx expansion board Ido Yariv
2011-07-07 21:33 ` [PATCH 1/5] arm: davinci: Fix low level gpio irq handlers' argument Ido Yariv
2011-07-07 21:33 ` [PATCH 2/5] arm: davinci: Allow EVENTQ_0 as a default queue Ido Yariv
2011-07-08 10:25 ` Sergei Shtylyov
2011-07-08 14:27 ` Ido Yariv [this message]
2011-07-07 21:33 ` [PATCH 3/5] arm: davinci: DA850: Set a default queue for CC1 Ido Yariv
2011-07-07 21:33 ` [PATCH 4/5] arm: davinci: mmc: Add support for set_power callback Ido Yariv
2011-07-07 21:33 ` [PATCH 5/5] arm: davinci: DA850: Add wl12xx expansion board support Ido Yariv
2011-07-08 10:39 ` Sergei Shtylyov
2011-07-08 14:27 ` Ido Yariv
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=20110708142717.GG2176@WorkStation \
--to=ido@wizery.com \
--cc=davinci-linux-open-source@linux.davincidsp.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-mmc@vger.kernel.org \
--cc=sshtylyov@mvista.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