David Brownell wrote:
By the way Vitaly ... I'm still not getting responses directly from you.
Are you pruning me off CC lists, or is there something between us that's
filtering out posts? It's certainly hard to respond to comments of yours
when I can only find them by going through some list archive I wouldn't
normally read...
No, definitely I'm not. I'm just responding with "Reply All" button in
my Thunderbird, if you wanna know the details.
And I'm quite surprised to hear about the kind of problems you have as
you're the only one who's having them.
So for example one way you know that (c) is well met is that it's the same
approach used in USB (both host and peripheral/gadget sides); that's been
working well for quite a few years now. (Despite comments from Dmitry
and Vitaly to the contrary.)
Lemme point you out that if somehting is "working" on a limited number
of platforms within the limited number of use cases, that's not
necessarily a correct implementation.
No, but it's a good indication :).
And I'm not sure what a "limited number of platforms" etc is supposed
to suggest. In terms of platforms supporting USB on Linux, there are
surely more of them than there are for PCI ... since every PCI platform
can support USB, and many non-PCI platforms do also. A better word
for that DMA support would seem to be "extensive", not "limited".
In fact, the support for non-PCI platforms was one of the things that
led to the last DMA-related reworks for USB. The PCI calls wouldn't
work (of course), but USB needs things like DMA-coherent buffers (for
transfer and queue head descriptors, used by most controllers) as well
as bus-neutral DMA operations. And it even works for things like
scatterlist merging through IOMMU mappings ... that wide portability
is **very much** a good indication that (c) is a non-issue with the
framework I've assembled.
Vitaly, you're really going to have to come up with some facts if you
keep claiming the SPI framework I've posted doesn't support DMA.
(I'm not going to let you pull a SCO on us here.) For that matter,
you might want to consider the fact that Stephen's pxa2xx_spi
driver disproves your arguments (it includes DMA support).
Again, a single working driver cannot disapprove anything.
Evidently enough for anyone more or less familiar with logic, if one
claims that something is working, he should prove it's working
everywhere not somewhere; on the other hand, to disapprove this
statement it's enough to give one example.
However, your latest core should be working on the problematic target as
opposed to the previous one. I didn't try that but I think it'll work.
The thing is that what we do in the core to provide DMA capabilities
should be implemented in controller driver in your case.
I can agree that it might be considered an addition to the core and not
directly included in it, but leaving rather standard operations to the
controller driver degrades the added value of the core.
- (A) has some assumptions on buffers that are passed down to spi
functions.
Make that "requirements"; FWIW they're the same ones that apply to all
other kernel driver frameworks I've seen: that buffers be DMA-safe.
It would not be helpful (IMO) to define different rules; that's also
called the "Principle of Least Astonishment". :)
Yeah within this requirement it's correct. But that requirement may
really make the SPI controller driver a lot more complex if
- it has to send something received from the userland
Controller drivers don't deal with userland addresses. That's the
responsibility of the layers on top ... e.g. the filesystem or driver
code that accepts them. Most just copy to/from userspace, but some
pay the costs to support direct I/O.
Oh no, you've got me wrong. I was tryng to say that an upper level
driver which copies the data from the userspace should be copying it to
GFP_DMA buffer, otherwise it won't work or will force the controller
driver to allocate/copy.
And putting a requirement on the upper level driver to always do GFP_DMA
kmalloc's might put too high restrictions on the memory usage.
Basically the upper level driver shouldn't give a damn whether the
buffers should be DMA-able or not since it might be used on different
platforms w/ and w/o DMA capabilities. Thus, it's going to be either a
requirement for the upper level drivers that implies the SPI core not
being transparent to the upper level, or a requirement for each
controller driver that might be handling this situation to implement the
same thing we did in the core. Neither of these seems reasonable to me.
- it needs to timely send some credentials (what is the case for the
WLAN driver, for instance).
Again, not the responsibility of the lowest level driver. A WLAN driver
layered on top could, of course. That's the way such things are done in
other driver stacks.
Are you seriously suggesting that an SPI controller driver should have any
clue whatever about credentials?? Which of the dozens of schemes should
become that "special", then ... and why??
I'm afraid that you were not reading my response attentively.
Credentials are stored in a staic-allocated buffer in the upper level
driver. Then they are passed down to the SPI core which will fail to
send the buffer containing the credentials if it's not copied to DMAable
memory somewhere in between.
Vitaly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
