Re: [PATCH] ASoC: pxa-ssp: Don't use SSCR0_SerClkDiv and SSCR0_SCR

[Eric Miao <eric.y.miao@gmail.com>]

On Sun, Apr 19, 2009 at 11:03 PM, pHilipp Zabel <philipp.zabel@gmail.com> wrote:
> On Sun, Apr 19, 2009 at 4:01 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Fri, Apr 17, 2009 at 6:22 PM, Mark Brown <broonie@sirena.org.uk> wrote:
>>> On Fri, Apr 17, 2009 at 11:39:38AM +0200, Philipp Zabel wrote:
>>>
>>>> To me, using ssp_dev seems to be cleaner, as all the places where
>>>> ssp_set_scr is called, we already have an ssp_dev *ssp = priv->dev.ssp
>>>> set up, which allows us to call ssp_set_scr(ssp, ...) instead of
>>>> ssp_set_scr(&priv->dev, ...). Same for ssp_get_scr.
>>>
>>> Yeah, the combination of ssp_dev and ssp_device is icky in general and
>>> largely historical as a result of a partially done transition of the
>>> driver to ssp_device.
>>>
>>
>> I'm working on that clean up. A lot of historical and dependency issues
>> indeed.
>
> Glad to hear that. I think once SSP is cleaned up, the single USB
> gadget controller driver is the only problem left for kernels
> supporting both PXA25x/27x at the same time.
>
>> And the patch looks OK. The condition of cpu_is_pxa25x() might not
>> be necessary though, ssp->type == PXA25x_SSP already implies that
>> and is more specific.
>
> Thanks. The idea was that the compiler can remove the PXA25x_SSP
> branch for kernels without PXA25x support this way.
> I guess the savings are negligible here, but it shouldn't hurt
> PXA25x-only kernels either.
>

This is very smart. However, the problem is that cpu_is_pxa25x()
implies pxa21x, pxa250, pxa255, pxa26x at the moment, and that
pxa255/pxa26x has additional ASSP and NSSP which resembles
much the PXA27x_SSP (with additional 4-bit for SCR). I don't think
too much about that optimization, yet I wonder if these cases are
also counted in.