Re: [PATCH 3/6] spi: bcm2835: fill FIFO before enabling interrupts to

[Martin Sperl <kernel@xxxxxxxxxxxxxxxx>]

> On 08.04.2015, at 04:01, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> 
> Can you fill the FIFO as step 1? That way, you could presumably write to
> that CS-REG just once, with all the desired bits set in one go.
Actually the "manual" says that you first need to enable TA - even for a
polling driver and then you can fill the FIFO.

But I have also tried it - it does not work, as the TA flag not only 
initiates the transfer but also activates/deactivates the whole SPI block
(and probably also all the registers). So the data filled into the FIFOs
is lost when TA is inactive.

> That sounds pretty typical for a 32-bit/dword-wide FIFO containing 8-bit
> data. Surely DMA isn't relevant here; every dword write will put 4 bytes
> into the FIFO irrespective of whether the write comes from the CPU or a
> DMA engine. Generally, the HW will pull dword-sized values out of the
> FIFO, and ignore any extra bytes that are packed into the dword beyond
> whatever the programmed transfer length is. Doesn't the bcm283x SPI HW
> do that too?
As the HW can do LoSSI (=9 bit) with the corresponding "command" parsing
where some commands trigger 8 bit reads, others 24 and others 32 bit
reads, it seems as if it reads as many byte from the fifo as necessary
for the specific transfer.

> That sounds pretty unusual. Have you tried not cleaning out the FIFO and
> seeing if the next transfer does in fact only transfer the data you
> write next, not the extra/stale bytes from the previous transfer?
I remember having tried this more than a year ago, but then you get the
"missing" data from the last word transfer (when using DMA).

As I am planning on implementing DMA I guess I will get there.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html