[PATCH 00/13] mmc: bcm2835: more cleanups

[Ulf Hansson]

On 27 January 2017 at 00:37, Gerd Hoffmann <kraxel at redhat.com> wrote:
>   Hi folks,
>
> Continuing bcm283x mmc driver cleanup.  Changes:
>
>  * switch to threaded irq handler.
>  * handle timeouts using delayed work instead of timers.
>
> With these changes most of the driver code runs in
> thread context, which in turn allows to remove the
> work queue and the tasklet.  Also some wait loops can
> be simplified because almost all driver code is allowed
> to sleep now.
>
> Code is also available here:
>   git://git.kraxel.org/linux bcm2837-sdhost-cleanup
>
> Baseline for the patch series is this:
>   git://git.kraxel.org/linux bcm2837-wifi
>
> Tested on raspberry pi 2b only so far.
> PIO mode only, didn't try to enable DMA.
>
> Lots of baby patches for now, to make review
> and (if needed) bisecting easier.  Will all be
> squashed into the bcm283x mmc driver patch later.
>
> cheers,
>   Gerd
>
> Gerd Hoffmann (13):
>   mmc: bcm2835: add bcm2835_read_wait_sdcmd
>   mmc: bcm2835: use bcm2835_read_wait_sdcmd in bcm2835_send_command
>   mmc: bcm2835: add bcm2835_threaded_irq
>   mmc: bcm2835: add bcm2835_check_data_error
>   mmc: bcm2835: call bcm2835_block_irq from irqthread
>   mmc: bcm2835: add bcm2835_check_cmd_error
>   mmc: bcm2835: call bcm2835_busy_irq from irqthread
>   mmc: bcm2835: split bcm2835_data_irq
>   mmc: bcm2835: switch locking to mutex
>   mmc: bcm2835: work queue is dead code now, zap
>   mmc: bcm2835: kill tasklet
>   mmc: bcm2835: move timeout to thread context
>   mmc: bcm2835: use bcm2835_read_wait_sdcmd in bcm2835_finish_command
>
>  drivers/mmc/host/bcm2835.c | 448 ++++++++++++++++++++-------------------------
>  1 file changed, 197 insertions(+), 251 deletions(-)
>
> --
> 1.8.3.1
>

So, I think these kind of incremental changes on top of an old posted
series are just confusing. Please just create a new version of the
original series - and add a nice history of what changes have been
made for each step.

Moreover, I know I have asked before why sdhci-iproc can be extended
for this controller. However, from the responses to some of the
changes in this series it sounds like the controllers are related? Or
are the controllers completely independent designed HW? Please clarify
this once more.

Kind regards
Uffe