remove pxa ssp driver???
xiechao.mail at gmail.com
Wed Aug 21 23:13:03 EDT 2013
On Wed, Aug 21, 2013 at 5:00 PM, Daniel Mack <zonque at gmail.com> wrote:
> Hi Chao,
> On 21.08.2013 05:19, Chao Xie wrote:
>> In arch/arm/plat-pxa, there is a ssp driver named ssp.c.
>> The ssp driver will probe all the ssp devices one by one, and linked
>> them into a list.
>> The driver also provides two APIs pxa_request_pxa() and pxa_ssp_free().
>> So why we will have ssp.c driver? The only thing the driver will do is
>> linked all the ssp devices into a list, and then provides APIs to
>> others to allocate and free the ssp ports.
>> The ssp connection is defined by board, and it is fixed. So for a
>> single board, i do not think the port will be allocated or freed
>> dynamically. Is there any case that will two drivers will share same
> It's really just to simplify the ssp port users, so they don't have to
> duplicate the resource allocation logic in their probe() implementation.
> However, that code is quite old, and with new ideas like devres
> allocation, probe functions can very small, so I agree with the idea of
> getting rid of that extra layer.
> However, I prepared some patches to provide device-tree functions to the
> ssp driver, and they are queued by Mark in the for-next branch of his
> ASoC tree:
> The approach there is now different, and the asoc ssp driver references
> the 'upstream' ssp port by phandle. But that API can't yet be fully used
> before the pxa-DMA bits go in, we can still change it I'd say.
>> If the two APIs are not needed. Then we can remove the driver, and
>> lets other drivers, for example, spi-pxa.c and sound/soc/pxa/pxa-ssp.c
>> to directly handle the ssp resources(get irq number, iomap the
>> register and etc.)
> Yes, I agree, but I'd like to schedule that for after the 3.12 merge
> window has settled. Is that ok for you?
That is fine.
You have submited the patches for removing the old pxa DMA driver, what is the
status for that?
More information about the linux-arm-kernel