linux-kernel - Re: [PATCH 3/5] dw_spi: rework message processing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Jun 2011 12:52:29 -0700
From:	Dirk Brandewie <dirk.brandewie@...il.com>
To:	Grant Likely <grant.likely@...retlab.ca>
CC:	Feng Tang <feng.tang@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"spi-devel-general@...ts.sourceforge.net" 
	<spi-devel-general@...ts.sourceforge.net>, alan@...ux.intel.com,
	alek.du@...el.com
Subject: Re: [PATCH 3/5] dw_spi: rework message processing

On 06/16/2011 10:38 AM, Grant Likely wrote:
> On Thu, Jun 16, 2011 at 11:28 AM, Dirk Brandewie
> <dirk.brandewie@...il.com>  wrote:
>> On 06/16/2011 07:00 AM, Feng Tang wrote:
>>>
>>> 4. I saw you enable both TX/RX interrupt when doing interrupt transfer,
>>> spi
>>>     devices' TX/RX are born to be simutaneous, when one word is sent over
>>>     TX line, a RX word will be received from RX line, so both the orignal
>>>     interrupt transfer handling written by me and the later optimization
>>>     from Alek Du only enable TX interrupt, which will only generate half of
>>>     IRQs comparing to enble both TX/RX, this is huge when the data rate is
>>>     several Mb per second
>>
>> I the current driver the txfltr register is set to 0 (FIFO empty) in the
>> interrupt transfer case which will drop chip select every FIFO length bytes.
>>
>> In my transfer setup the RX FIFO interrupt is set to a value lower than the
>> TX threshold which will keep both interrupts from firing at the same time.
>>
>> The TX interrupt will drive the transfer until there are less than
>> tx_threshold bytes left to transfer then by the RX interrupt to drive the
>> remainder of the transfer without dropping chip select.
>
> Be careful here.  Can you guarantee that the kernel will process the
> IRQ before the FIFO drains?  If not, then you'll need something more
> reliable.

I can't guarantee when IRQ are processed :-)

Without actual control over when chip is de-asserted I don't think we guarantee 
that chip select will be not dropped, chip select is dropped when the TX fifo 
goes empty.

With a sufficiently high bitrate client, heavily loaded system and fixed size 
fifo we are domed at some point.  As tx_threshold approaches fifo depth you give 
yourself a bigger buffer in time but increase the number of interrupts you need 
to deal with increasing the system load.

For high bitrate devices the client driver should be using DMA IMHO to work 
around this limitation in the designware IP.  Of course this doesn't solve the 
problem of chip select dropping between transfers in the same message.

I took a SWAG at tx_threshold in my changes to try to limit the number of 
interrupts it will need tuning for a reasonable default and likely the addition 
of a module parameter or platform data to set it for any given SOC/system.

--Dirk

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/