Re: [PATCH] SPI: BCM2835: clock divider can be a multiple of 2

["Noralf Trønnes" <noralf-L59+Z2yzLopAfugRpC6u6w@public.gmane.org>]

Den 20.03.2015 08:04, skrev Martin Sperl:
>> On 20.03.2015, at 06:06, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>>
>> On 03/19/2015 03:01 AM, kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org wrote:
>>> From: Martin Sperl <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
>>>
>>> The official documentation is wrong in this respect.
>>> Has been tested empirically for dividers 2-1024
>> Do you have a link to a confirmation of this from the RPi Foundation or
>> Broadcom, even a forum post or something? How does the RPI Foundation's
>> downstream kernel restrict the divider?
> Unfortunately there are no official errata by the foundation.
>
> Here the argument by a foundation official (Gordon Hollingworth)
> why they do not (want to) provide updates:
> http://www.raspberrypi.org/forums/viewtopic.php?p=447724#p447724
>
> That is in a slightly different context, but still it also applies to
> errata in general.
>
> The foundation spi-bcm2708 driver also relies on the power-of 2 rule
> following to the letter the documentation they provide.
>
> For some more infos of experience please look here:
> https://github.com/notro/spi-bcm2708/wiki
> http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=43442
> http://elinux.org/BCM2835_datasheet_errata#p156
>
> Notro and I have been running an out of tree driver for a long time
> and that never showed any issues with this multiple of 2.
>
> Some of these kernels/drivers have been shared with lots of people
> for the use with TFT displays or CAN controllers.
>
> I have measured this empirically for every divider between 2 to 1024
> by doing some transfers, and measuring them with a SALEAE logic analyzer.
>
> See here: for the analysis:
> https://github.com/msperl/spi-bcm2835/issues/8
>
> You can also fetch the raw data and csv exports here:
> https://github.com/msperl/spi-bcm2835/blob/patch_the_upstream/images/
>
> Note that the descriptions of how to do polled, interrupt driven and
> DMA driven SPI transfers (page 158) is also not completely accurate.
> It seems to show some "procedures", but these are not optimized and
> some are inconsistent: e.g: this limitation of 16/12 byte transfers
> while the register documentation says 16 words not bytes - which means
> 64 bytes can enter the FIFO buffer (which is also the limit when
> the HW signals that it is full via BCM2835_SPI_CS_TXD)
>
> This will be one of the next patches for improvement of the driver.

The out-of-tree github.com/notro/spi-bcm2708.c is used in numerous
installations since may 2013. I just heard of a 50,000 order for a
particular SPI TFT display.
This driver has no restriction on CDIV except for boundary checking:
         cdiv = DIV_ROUND_UP(bus_hz, hz);

Many of these displays also have a touch controller on the same bus.
AFAIK the most common default speeds used with displays are: 
16,24,32,48,64,80,128MHz
Default transmit buffer size is 4k. The touch controller is set to 2MHz.
I haven't heard any reports of this driver being used for reading large 
buffers.

To my knowledge there hasn't been any issues with lifting this CDIV 
restriction.


Regards,
Noralf Trønnes