From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH dtc] C-based DT schema checker integrated into dtc
Date: Tue, 5 Nov 2013 13:14:43 +0100 [thread overview]
Message-ID: <201311051314.43629.arnd@arndb.de> (raw)
In-Reply-To: <20131104222135.GA10711@obsidianresearch.com>
On Monday 04 November 2013, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2013 at 02:43:00PM -0700, Stephen Warren wrote:
> > For DMA, it does look like Arnd's code was requesting it too, but that
> > should also be fine; as long as no transactions are actually issued
> > against that DMA slave channel, then the HW state shouldn't matter?
>
> TBH, I'm not really familiar with how the DMA slave API works.
>
> As long as the API and HW guarantees that the channel cannot do any
> DMAs no matter what the connected IP does, it is obviously fine..
Right, to initiate a DMA, you need to at least request a channel,
configure it, and submit a descriptor. This does only the first
step, so I'm pretty it's ok.
> But not all DMA is like that, eg bus master DMA in PCI requires
> drivers to call pci_enable_device only after they disable DMA in the
> device, which is why I mentioned it..
Yes, a DMA bus master device is different here and needs to be
handled as you exlain.
> It would be nice to see a general API like this unambiguously make
> clear the steps required:
>
> - Gain access to registers
> - Gain control of the device
> - Enable DMA, bind interrupts, etc
> - Finalize device setup
> - Make the device visible to the rest of the system
>
> I've seen lots of drivers where the above is just not done right.
I agree this would be nice, but it's probably out of scope of what
we're trying to do here, unless you have better ideas for how to
structure it.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Jon Loeliger <jdl@jdl.com>,
khilman@linaro.org, Stephen Warren <swarren@nvidia.com>,
s.nawrocki@samsung.com, pawel.moll@arm.com,
Stephen Warren <swarren@wwwdotorg.org>,
Tomasz Figa <t.figa@samsung.com>,
Tomasz Figa <tomasz.figa@gmail.com>,
rob.herring@calxeda.com, Grant Likely <grant.likely@secretlab.ca>,
fparent@baylibre.com, a.hajda@samsung.com,
Benoit Cousson <bcousson@baylibre.com>,
galak@codeaurora.org, olof@lixom.net, Alison_Chaiken@mentor.com,
linux-arm-kernel@lists.infradead.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH dtc] C-based DT schema checker integrated into dtc
Date: Tue, 5 Nov 2013 13:14:43 +0100 [thread overview]
Message-ID: <201311051314.43629.arnd@arndb.de> (raw)
In-Reply-To: <20131104222135.GA10711@obsidianresearch.com>
On Monday 04 November 2013, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2013 at 02:43:00PM -0700, Stephen Warren wrote:
> > For DMA, it does look like Arnd's code was requesting it too, but that
> > should also be fine; as long as no transactions are actually issued
> > against that DMA slave channel, then the HW state shouldn't matter?
>
> TBH, I'm not really familiar with how the DMA slave API works.
>
> As long as the API and HW guarantees that the channel cannot do any
> DMAs no matter what the connected IP does, it is obviously fine..
Right, to initiate a DMA, you need to at least request a channel,
configure it, and submit a descriptor. This does only the first
step, so I'm pretty it's ok.
> But not all DMA is like that, eg bus master DMA in PCI requires
> drivers to call pci_enable_device only after they disable DMA in the
> device, which is why I mentioned it..
Yes, a DMA bus master device is different here and needs to be
handled as you exlain.
> It would be nice to see a general API like this unambiguously make
> clear the steps required:
>
> - Gain access to registers
> - Gain control of the device
> - Enable DMA, bind interrupts, etc
> - Finalize device setup
> - Make the device visible to the rest of the system
>
> I've seen lots of drivers where the above is just not done right.
I agree this would be nice, but it's probably out of scope of what
we're trying to do here, unless you have better ideas for how to
structure it.
Arnd
next prev parent reply other threads:[~2013-11-05 12:14 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-24 21:51 [RFC PATCH dtc] C-based DT schema checker integrated into dtc Stephen Warren
2013-10-24 21:51 ` Stephen Warren
2013-10-24 23:43 ` Grant Likely
2013-10-24 23:43 ` Grant Likely
2013-10-25 4:00 ` Kumar Gala
2013-10-25 4:00 ` Kumar Gala
2013-10-25 14:44 ` Stephen Warren
2013-10-25 14:44 ` Stephen Warren
2013-10-25 15:21 ` Jon Loeliger
2013-10-25 15:21 ` Jon Loeliger
2013-10-25 17:38 ` Rob Herring
2013-10-25 17:38 ` Rob Herring
2013-10-25 23:11 ` David Gibson
2013-10-25 23:11 ` David Gibson
2013-11-03 23:15 ` Tomasz Figa
2013-11-03 23:15 ` Tomasz Figa
2013-11-03 23:26 ` Tomasz Figa
2013-11-03 23:26 ` Tomasz Figa
2013-11-04 9:28 ` Arnd Bergmann
2013-11-04 9:28 ` Arnd Bergmann
2013-11-04 12:31 ` Tomasz Figa
2013-11-04 12:31 ` Tomasz Figa
2013-11-04 16:37 ` Stephen Warren
2013-11-04 16:37 ` Stephen Warren
2013-11-04 18:57 ` Olof Johansson
2013-11-04 18:57 ` Olof Johansson
2013-11-04 20:43 ` Arnd Bergmann
2013-11-04 20:43 ` Arnd Bergmann
2013-11-04 21:29 ` Jason Gunthorpe
2013-11-04 21:29 ` Jason Gunthorpe
2013-11-04 21:43 ` Stephen Warren
2013-11-04 21:43 ` Stephen Warren
2013-11-04 22:21 ` Jason Gunthorpe
2013-11-04 22:21 ` Jason Gunthorpe
2013-11-05 12:14 ` Arnd Bergmann [this message]
2013-11-05 12:14 ` Arnd Bergmann
2013-11-05 8:39 ` Arnd Bergmann
2013-11-05 8:39 ` Arnd Bergmann
2013-11-05 18:03 ` Jason Gunthorpe
2013-11-05 18:03 ` Jason Gunthorpe
2013-11-05 18:48 ` Arnd Bergmann
2013-11-05 18:48 ` Arnd Bergmann
2013-11-05 19:12 ` Jason Gunthorpe
2013-11-05 19:12 ` Jason Gunthorpe
2013-11-05 19:34 ` Arnd Bergmann
2013-11-05 19:34 ` Arnd Bergmann
2013-11-05 19:58 ` Jason Gunthorpe
2013-11-05 19:58 ` Jason Gunthorpe
2013-11-05 20:17 ` Arnd Bergmann
2013-11-05 20:17 ` Arnd Bergmann
2013-11-05 20:36 ` Jason Gunthorpe
2013-11-05 20:36 ` Jason Gunthorpe
2013-11-04 21:50 ` Stephen Warren
2013-11-04 21:50 ` Stephen Warren
2013-11-05 8:22 ` Arnd Bergmann
2013-11-05 8:22 ` Arnd Bergmann
2013-11-06 12:17 ` Thierry Reding
2013-11-06 12:17 ` Thierry Reding
2013-11-04 14:28 ` David Gibson
2013-11-04 14:28 ` David Gibson
2013-11-04 16:42 ` Stephen Warren
2013-11-04 16:42 ` Stephen Warren
2013-10-28 10:17 ` David Gibson
2013-10-28 10:17 ` David Gibson
2013-10-31 21:13 ` Stephen Warren
2013-10-31 21:13 ` Stephen Warren
2013-11-01 13:24 ` David Gibson
2013-11-01 13:24 ` David Gibson
2013-10-25 23:29 ` David Gibson
2013-10-25 23:29 ` David Gibson
2013-10-31 21:11 ` Stephen Warren
2013-10-31 21:11 ` Stephen Warren
2013-11-10 11:00 ` David Gibson
2013-11-10 11:00 ` David Gibson
2013-11-12 22:06 ` Stephen Warren
2013-11-12 22:06 ` Stephen Warren
2013-11-13 0:33 ` David Gibson
2013-11-13 0:33 ` David Gibson
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=201311051314.43629.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.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 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.