On Tue, Feb 15, 2011 at 16:20, Grant Likely wrote:
> On Tue, Jan 11, 2011 at 02:22:05PM -0500, Mike Frysinger wrote:
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index 1906840..95ba5fe 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -66,6 +66,15 @@ config SPI_BFIN
>>       help
>>         This is the SPI controller master driver for Blackfin 5xx processor.
>>
>> +config SPI_BFIN_SPORT
>> +     tristate "SPI bus via Blackfin SPORT"
>> +     depends on BLACKFIN
>> +     help
>> +       Enable support for a SPI bus via the Blackfin SPORT peripheral.
>> +
>> +       This driver can also be built as a module.  If so, the module
>> +       will be called bfin_sport_spi.
>> +
>
> This list is pseudo-alphabetized; place this hunk accordingly

it is.  blame the AU1550 guys for screwing it up and putting their
entry after the existing SPI_BFIN.

>> +     /* init messages workqueue */
>> +     INIT_WORK(&drv_data->pump_messages, bfin_sport_spi_pump_messages);
>> +     drv_data->workqueue =
>> +         
>> create_singlethread_workqueue(dev_name(drv_data->master->dev.parent));
>> +     if (drv_data->workqueue == NULL)
>> +             return -EBUSY;
>
> Hmmm... since this is basically a state machine, why cannot both
> messages and transfers be handled with the same deferred work
> mechanism?  pump_messages should be fast, and it looks like it cannot
> sleep.  Having two separate deferred work mechanisms makes it harder
> to track who is doing what and when.

the driver design simply comes down to copying what worked.  we knew
the spi_bfin5xx.c driver worked, so we copied that and tweaked things
to work on the SPORT.  as for why spi_bfin5xx.c does things that way,
the answer is the same ... we copied pxa2xx_spi.c which was known to
work and then replaced the arm stuff with our own.

i wouldnt be surprised if we couldnt kick a lot of this to the curb in
favor of a different design, but i'm pretty sure that would take quite
a rewrite of the whole driver.  which honestly isnt going to happen
any time soon, and we know the existing driver works ...
-mike

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
spi-devel-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Reply via email to