linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jassi Brar <jassisinghbrar@gmail.com>
To: Vinod Koul <vkoul@infradead.org>
Cc: "pratyush.anand@st.com" <pratyush.anand@st.com>,
	"rajeev-dlh.kumar@st.com" <rajeev-dlh.kumar@st.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"armando.visconti@st.com" <armando.visconti@st.com>,
	"bhupesh.sharma@st.com" <bhupesh.sharma@st.com>,
	vinod.koul@intel.com, Linus Walleij <linus.walleij@linaro.org>,
	"vipin.kumar@st.com" <vipin.kumar@st.com>,
	"grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
	"shiraz.hashim@st.com" <shiraz.hashim@st.com>,
	"Amit.VIRDI@st.com" <Amit.VIRDI@st.com>,
	"vipulkumar.samar@st.com" <vipulkumar.samar@st.com>,
	"viresh.linux@gmail.com" <viresh.linux@gmail.com>,
	"deepak.sikri@st.com" <deepak.sikri@st.com>,
	"bhavna.yadav@st.com" <bhavna.yadav@st.com>,
	"spi-devel-general@lists.sourceforge.net"
	<spi-devel-general@lists.sourceforge.net>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"linux-arm-kernel@lists.infradead.org" <linux-a
Subject: Re: [PATCH V2 6/6] spi/spi-pl022: Request/free DMA channels as and when required.
Date: Thu, 11 Aug 2011 00:29:01 +0530	[thread overview]
Message-ID: <CABb+yY0Hy9DcHf+D0OrrGjxkR=V8sa4Q-Kvd1iH01oChnoEE6w@mail.gmail.com> (raw)
In-Reply-To: <1313009883.1603.25.camel@vkoul-udesk3>

On Thu, Aug 11, 2011 at 2:28 AM, Vinod Koul <vkoul@infradead.org> wrote:
>> > The lookup of a device DMA channel should follow the
>> > design pattern set by regulators and clocks.
>> Nopes. It depends upon the subsystem.
>> We should strive towards making this scheme as 'standalone' as
>> possible.
>> Client having to specify the device it wants a channel for, is a
>> waste - otherwise we don't fully get rid of platform assistance for
>> channel selection!
> On one of the platforms I work on we have 3 DMACs, peripheral 1, 2 and 3
> can only use channels from controller 1, and the peripherals 4, 5 from
> controller 2 and so on. They _absolutely_ need channel from specific
> controller, so above suits it :).
> Btw all three controllers _have_exactly_same_caps_ so dma engine will
> not see any difference in channels. They don't know which peripherals
> are connected to them, that's platform information which this scheme
> seems to be suited to...
> Can you tell me how your scheme will work in this case?
Actually the setup is quite simple.
Say, the Peri-4 is the UART which could only be reached from DMAC-2.

DMAENGINE should simply manage a pool of total channels in the platform,
disregarding the dmacs they come from.

Each channel in the common pool will have a 'capability-tag' of u32 type - which
specifies various capabilities of the channel expressed in bit-fields.
It is the job of
platform (via dmac driver) to set 'tag' of each channel appropriately.
Among others, a channel's reach to a particular device is a
'capability' (expressed
in 7-bits DEV_TYPE field-mask of the 'tag')

In your case, while setting up channels before adding them to the common pool,
the platform (via dmac driver) will ensure exactly the channel which
can reach UART
has set DEV_UART value in the DEV_TYPE field of its capability-tag.

After all the dmac instances have been probed, _exactly_ one channel in the pool
will have the 'UART' capability mentioned in the DEV_TYPE field.

The serial driver(client), will simply specify 'Ability to reach UART'
as one of its
requirements to the core - by setting the DEV_TYPE field with DEV_UART value
of the 'request-tag' (a u32 number, say).

While searching for appropriate channel for the serial client, the core will
iterate over the pool and, of course, only one channel will have DEV_TYPE
field set to DEV_UART - the one which platform decided!

Please have a look at the end of  https://lkml.org/lkml/2011/7/29/211
(esp the helpers) to get an idea of data structures involved.


*******************************
UART(client) driver snippet :-
*******************************
struct dma_chan *chan_rx;
u32 req_cap;

/* Reset the requirement list */
DCH_RESET_CAP(req_cap);

/* Specify ability to reach UART as a requirement */
DCH_REQCAP_DEV(req_cap, DCHAN_TODEV_UART);

/* Specify we require to Read from UART */
DCH_REQCAP_P2M(req_cap);

/* ...... specify other requirements */

/* Ask for the channel */
chan_rx = dma_request_channel(req_cap);



***************
dmaengine.c
***************
struct dma_chan *dma_request_channel(u32 req_cap)  // typedef u32 to
look nice ;)
{
 struct dma_chan *ch;

           /* !!! Not final implementation !!! */
 list_for_each_entry(ch, &channel_pool, chan_node) {
      if (GET_DEVTYPE(req_cap) != GET_DEVTYPE(ch->tag))
          continue;

      if ((IS_DCH_M2M(req_cap) && !IS_DCH_M2M(ch->tag))
         continue;

      if ((IS_DCH_M2P(req_cap) && !IS_DCH_M2P(ch->tag))
         continue;

      if ((IS_DCH_P2M(req_cap) && !IS_DCH_P2M(ch->tag))
         continue;

      if ((IS_DCH_P2P(req_cap) && !IS_DCH_P2P(ch->tag))
         continue;

      /* weed out channels that don't have further capabilities required */

      /* At the end of checks this channel meets every requirement */
      return ch;
  }
  /* Will never reach here in a bug-free platform */
  return NULL;
}


**************************************
DMAC <- PLATFORM <- BOARD
***************************************
Well, that is between dmac and platform and out of scope of DMAENGINE API.
They can decide upon any data structure to pass the info needed.

But at some point someone must set :-
  _Only_ for the channel of DMAC-2 that could talk to the UART.

{
DCH_RESET_CAP(ch->tag);

/* Declare 'capability' to talk to UART */
SET_DEVTYPE(ch->tag, DCHAN_TODEV_UART);

/* Declare 'capability' to do RX i.e, P->M */
SET_DCHDIR(ch->tag,  0, 0, 1, 0);

/* Declare other 'capabilities' of the channel */

/* Add enough dmac's private data to channel so as to be able
  to later figure out the ReqSig, DMAC etc associated with it */

/* Add the channel to the global pool in dmaengine.c */
}

Please have a look at the end of  https://lkml.org/lkml/2011/7/29/211
(esp the helpers) to get an idea of data structures involved.

  reply	other threads:[~2011-08-10 18:59 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10  8:50 [PATCH V2 0/6] spi/spi-pl022 fixes Viresh Kumar
2011-08-10  8:50 ` [PATCH V2 1/6] spi/spi-pl022: Resolve formatting issues Viresh Kumar
2011-09-20 17:17   ` Grant Likely
     [not found] ` <cover.1312965741.git.viresh.kumar-qxv4g6HH51o@public.gmane.org>
2011-08-10  8:50   ` [PATCH V2 2/6] spi/spi-pl022: Use GFP_ATOMIC for allocation from tasklet Viresh Kumar
2011-08-10  8:50   ` [PATCH V2 3/6] spi/spi-pl022: Don't allocate more sg than required Viresh Kumar
2011-08-10  8:54     ` Russell King - ARM Linux
2011-08-10  9:05       ` viresh kumar
2011-08-10 11:42     ` Sergei Shtylyov
2011-08-10 11:46       ` viresh kumar
2011-08-10  8:50   ` [PATCH V2 4/6] spi/spi-pl022: calculate_effective_freq() must set rate <= requested rate Viresh Kumar
2011-08-10  8:50   ` [PATCH V2 5/6] spi/spi-pl022: Call pl022_dma_remove(pl022) only if enable_dma is true Viresh Kumar
2011-08-10  8:50 ` [PATCH V2 6/6] spi/spi-pl022: Request/free DMA channels as and when required Viresh Kumar
2011-08-10  9:00   ` Russell King - ARM Linux
2011-08-10  9:29     ` viresh kumar
2011-08-10 10:01       ` Koul, Vinod
     [not found]         ` <438BB0150E931F4B9CE701519A4463010871804A15-qq4HA3s+46oFyVwBAnZdSLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2011-08-10 10:14           ` viresh kumar
2011-08-10 10:32             ` Russell King - ARM Linux
2011-08-10 16:53               ` Koul, Vinod
2011-08-10 10:29         ` Russell King - ARM Linux
2011-08-10 10:31         ` Jassi Brar
2011-08-10 10:40           ` Russell King - ARM Linux
2011-08-10 11:24             ` Jassi Brar
2011-08-10 11:54               ` Linus Walleij
2011-08-10 13:16                 ` Jassi Brar
2011-08-10 20:58                   ` Vinod Koul
2011-08-10 18:59                     ` Jassi Brar [this message]
2011-08-16 11:55                       ` Koul, Vinod
2011-08-16 14:51                         ` Jassi Brar
2011-08-19 13:49                           ` Koul, Vinod
2011-08-11 12:55                   ` Linus Walleij
2011-08-11 14:22                     ` Jassi Brar
2011-08-11 14:48                       ` Linus Walleij
     [not found]                         ` <CAKnu2MptC8HWCNo6W+X9rawn6MCwAe3DB3B5UcHD1tCD9tA2cg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-08-11 17:05                           ` Jassi Brar
2011-08-11 22:35                         ` Koul, Vinod
2011-08-10 10:09       ` Jassi Brar
     [not found]         ` <CABb+yY0Qvuhrn+FUhWDHMwUjv=nR4MOfLeDfTzG17HXEuu2pmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-08-10 10:30           ` Russell King - ARM Linux
2011-08-10 10:48             ` Jassi Brar
2011-08-10 11:42 ` [PATCH V3 3/6] spi/spi-pl022: Don't allocate more sg than required Viresh Kumar
2011-09-01 10:04 ` [PATCH V2 0/6] spi/spi-pl022 fixes Viresh Kumar
2011-09-01 10:56   ` Linus Walleij
     [not found]     ` <CACRpkdYeq9in+U_tyvb=yVuX2t5TnkUSsO+BozUGVJwZVh+4Ag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-20 11:16       ` Viresh Kumar
2011-09-20 17:23         ` Grant Likely

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='CABb+yY0Hy9DcHf+D0OrrGjxkR=V8sa4Q-Kvd1iH01oChnoEE6w@mail.gmail.com' \
    --to=jassisinghbrar@gmail.com \
    --cc=Amit.VIRDI@st.com \
    --cc=armando.visconti@st.com \
    --cc=bhavna.yadav@st.com \
    --cc=bhupesh.sharma@st.com \
    --cc=dan.j.williams@intel.com \
    --cc=deepak.sikri@st.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linus.walleij@linaro.org \
    --cc=linux@arm.linux.org.uk \
    --cc=pratyush.anand@st.com \
    --cc=rajeev-dlh.kumar@st.com \
    --cc=shiraz.hashim@st.com \
    --cc=spi-devel-general@lists.sourceforge.net \
    --cc=vinod.koul@intel.com \
    --cc=vipin.kumar@st.com \
    --cc=vipulkumar.samar@st.com \
    --cc=viresh.linux@gmail.com \
    --cc=vkoul@infradead.org \
    /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).