Re: [PATCH 2/2] spi: Add Analog Devices AXI SPI Engine controller support

[Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>]

On 02/05/2016 04:32 PM, Andy Shevchenko wrote:
> On Fri, Feb 5, 2016 at 4:30 PM, Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> wrote:
>>>> +       clk_div = DIV_ROUND_UP(clk_get_rate(spi_engine->ref_clk),
>>>> +               xfer->speed_hz * 2);
>>>
>>>> +       if (clk_div > 255)
>>>> +               clk_div = 255;
>>>> +       else if (clk_div > 0)
>>>> +               clk_div -= 1;
>>>
>>> 255 is okay, 254 is not, 253- is okay. Why 254 is so special?
>>
>> I don't see that. The condition is > 255, so everything greater or equal
>> than 256 gets mapped to 255. Everything else to x - 1, so 255 to 254, 254 to
>> 253.
> 
> Ah, you are right.
> 
>>>> +               for (i = 0; i < m; i++)
>>>> +                       writel_relaxed(buf[i], addr);
>>>
>>> writesl() ?
>>
>> Hm, maybe. Does it really have the same semantics?
> 
> It's a loop inside, so it has a count parameter. Otherwise it should be similar.

It seems to have different semantics in terms of endianness and ordering.

> 
>>>> +static int spi_engine_transfer_one_message(struct spi_master *master,
>>>> +       struct spi_message *msg)
>>>
>>> And you are not using transfer_one() because of..?
>>
>> transfer_one() does flow control in software. Execution is passed back to
>> software after each transfer and it also takes care of handling the chip
>> select assertion/deassertion as well as the delays. It's useful for hardware
>> which does not support hardware flow control. In this case the hardware
>> supports flow control including chip-select logic as well as delays. Making
>> use of this generates far less context switches per message and also has
>> predictable timings between transfers within a message.
> 
> Maybe the hardware flow control implementation is needed?

But wouldn't that be transfer_one_message?


--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html