Re: [PATCH 3/6] ASoC: ux500: Drop pinctrl sleep support

[Fabio Baltieri <fabio.baltieri@linaro.org>]

On Wed, May 08, 2013 at 02:54:13PM +0100, Mark Brown wrote:
> On Wed, May 08, 2013 at 03:10:20PM +0200, Fabio Baltieri wrote:
> > On Wed, May 08, 2013 at 01:32:25PM +0100, Mark Brown wrote:
> 
> > > I'm saying that if functions like enable_msp() don't work reliably then
> > > removing some but not all of their functionality isn't an obviously good
> > > approach to fixing that.  Why does the other functionality work well but
> > > not this bit?  It sounds like there's some reference counting bug here
> > > is all...
> 
> > Yes, it started as a reference counting bug, due to the actual counter
> > not being shared between ux500-msp-i2s instances.
> 
> > That said, the actual fork of this driver deployed by STE internally
> > does not handle I2S pin sleep state, and I was not able to find any
> > other ASoC driver that does that, which seems reasonable to me as I
> > can't come up with a reason to put those pins in hi-z anyway.
> 
> But why does the rest of the code work well if the reference counting is
> wrong, it's in the middle of a big block of code?  This all smells like
> this change is papering over a specific symptom of some underlying issue
> - if that's not the case then it needs to be clearer why.

Well, the counting by itself is not wrong, it's just that the same pins
are used by both driver instances (ux500-msp-i2s.1 and ux500-msp-i2s.3)
but the actual counter is specific of each instance
(msp->pinctrl_rxtx_ref, if I'm not mistaken msp is different between the
capture and playback interfaces).

Also, right now the pins are only associated with the first instance,
as in:

DB8500_PIN("GPIO33_AF2", out_lo_slpm_nowkup, "ux500-msp-i2s.1"),

which does not seems to be correct as these are used also by
ux500-msp-i2s.3, hence why I sent the patch to set the pin as a hog.

> > If I understood the problem correctly you do that when you want to cut
> > power completely to some peripherals to avoid spurious current paths,
> > and that should not be the case for the audio codec, especially in this
> > case where it's part of a big multifuntion IC.
> 
> Being a MFD should have nothing to do with this?

Ok, what I'm trying to say is that the codec used in this platform
should be able to handle sleep modes without requiring any
reconfiguration of the digital interface on the SoC side.  In support of
this the fact that the STE fork of the driver does not do that, and the
same goes for all other ASoC drivers currently in mainline.

Fabio

-- 
Fabio Baltieri