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

[Du, Alek]

On Thu, 16 Jun 2011 22:00:03 +0800
"Tang, Feng" <feng.tang@xxxxxxxxx> wrote:

> Hi Dirk,
> 
> On Thu, 16 Jun 2011 01:23:06 +0800
> "dirk.brandewie@xxxxxxxxx" <dirk.brandewie@xxxxxxxxx> wrote:
> 
> > From: Dirk Brandewie <dirk.brandewie@xxxxxxxxx>
> >
> > NOTE: patch created git format-patch --break-rewrites=/50%
> >
> > This patch reworks the message pump worker thread function to run
> > until all messages queued to the driver have been handled. The
> > function to handle individual spi_transfers is now a synchronus
> > function the tasklet to handle spi_transfers has been removed. Work
> > for the worker thread is only queued in host controller transfer
> > function.
> >
> > Psuedo code for new thread function:
> >   message = get_message()
> >   while (message){
> >     for_each_transfer_in_msg(message){
> >       transfer_setup(transfer)
> >       do_transfer()
> >     }
> >     complete_message()
> >     message = get_message()
> >   }
> >
> > Changes that fell out of the message thread changes:
> > Non-DMA transfers that are larger than the size of the controller FIFO
> > are handled as interrupt driven transfers.
> >
> > Common FIFO handling functions shared PIO and interrupt transfers.
> >
> > Simplified queue stop/start funcitons.
> >
> > Cleanup fixes:
> > Changed exported all exported function names to have dw_spi_ prefix
> >
> > Removed support for registering chip select control function. Setting
> > the slave chip select is handled by setting the SER (Slave enable
> > register)
> >

Removing this, you already break the TI spi BT module which requires that it
controls the chip select instead of controller.

When TX FIFO empty (means TX draining fast) the CS pin will de-assert.
In order to support those spi slaves that cannot stand this, the chip
select control function callback was added to this driver. Please don't
break previous contribution please.

And again, it is meaningless to enable both TX and RX fifo threshold interrupts,
since they are connected in hardware.

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