[E3-hacking] [RFC][PATCH] ARM: OMAP: McBSP: Use register cache

[Anuj Aggarwal]

On Fri, Sep 4, 2009 at 4:37 PM, Eero
Nurkkala<ext-eero.nurkkala at nokia.com> wrote:
> On Fri, 2009-09-04 at 12:34 +0200, ext Janusz Krzysztofik wrote:
>> in normal (handset) mode, the noise level seems still acceptable. The only
>> missing piece of a puzzle is my patch, that prevents the kernel driver from
>> putting corrupted values into the McBSP control registers.
>>
>> That learned, please reconsider:
>> 1. Can my patch break anything, related or not?
>
> That needs to be investigated in more detail.
>
>> 2. How does it affect performance of otherwise unaffected machines?
>
> Like you already know, shouldn't.
>
>> 3. Is correcting a poorly designed machine behaviour worth of the change?
>>
>> Thanks,
>> Janusz
>
>
> I'd say this is in the right track. All McBSP registers
> (not status etc) will need to be stored in memory. (Now, they're not).
> And all those register contents will need to be written back
> in certain situations. So this is the case when there is an external
> audio chip, that takes audio in in bursts. So once the
> burst is complete, all McBSP clocks will be disabled for a duration.
>
> Then (at least >= 3430) device will hit OFF mode, meaning
> all register contents are lost, also McBSP's. They will
> need to be written back at some point.
Isn't the better way to achieve this thing, at least from the OFF mode
perspective, is to provide similar implementation for McBSP in
omap3_core_save_context () / omap3_core_restore_context(), in
file arch/arm/mach-omap2/pm34xx.c? Code for other core peripherals
is already there and we have to add support for rest of the core-domain
peripherals.
>
> My quick verdict is, that your patch is, going into right
> direction. But the thing is that my words don't count much ;)
>
> (Possibly worth taking the patch in, if guaranteed to not break
>  any others).
>
> - Eero
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Best Regards,
Anuj Aggarwal