Re: [spi-devel-general] Re: SPI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux