remove pxa ssp driver???

remove pxa ssp driver???

[Chao Xie]

hi
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
port?

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.)

remove pxa ssp driver???

[Daniel Mack]

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
> port?

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:

  https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/

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?


Thanks,
Daniel

remove pxa ssp driver???

[Chao Xie]

On Wed, Aug 21, 2013 at 5:00 PM, Daniel Mack <zonque@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
>> port?
>
> 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:
>
>   https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/
>
> 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?

>
> Thanks,
> Daniel
>

remove pxa ssp driver???

[Daniel Mack]

On 22.08.2013 05:13, Chao Xie wrote:
> On Wed, Aug 21, 2013 at 5:00 PM, Daniel Mack <zonque@gmail.com> wrote:

>> 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?

No, not yet. The patch to do this is part of a big series that needs a
lot more testing. Unfortunately, I haven't got much feedback yet from
people who use PXA platforms. If you could give it a try, please do:

  https://github.com/zonque/linux/tree/pxa-dma-v2

Some parts of this series have been extracted and merged, but only such
patches that don't break the current DMA implementation.


Thanks,
Daniel