[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130508090025.GC1526@balto.lan>
Date: Wed, 8 May 2013 11:00:25 +0200
From: Fabio Baltieri <fabio.baltieri@...aro.org>
To: Lee Jones <lee.jones@...aro.org>
Cc: Mark Brown <broonie@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>,
Ola Lilja <ola.o.lilja@...ricsson.com>
Subject: Re: [PATCH 3/6] ASoC: ux500: Drop pinctrl sleep support
On Wed, May 08, 2013 at 09:48:46AM +0100, Lee Jones wrote:
> On Wed, 08 May 2013, Fabio Baltieri wrote:
>
> > On Wed, May 08, 2013 at 09:07:08AM +0100, Lee Jones wrote:
> > > On Wed, 08 May 2013, Fabio Baltieri wrote:
> > >
> > > > Drop pinctrl default/sleep state switching code, as it was breaking the
> > > > capture interface by putting the I2S pins in hi-z mode regardless of its
> > > > usage status, and not giving any real benefit.
> > > >
> > > > Pinctrl default mode configuration is already managed automatically by a
> > > > specific pinctrl hog.
> > >
> > > I'm sure we should support pinctrl though shouldn't we?
> > >
> > > Is there no way of fixing the implementation instead of ripping it out?
> >
> > Yes, but requesting the default pinctrl configuration should be enough,
> > and as those pins are shared with multiple device ids, a "hog"
> > configuration should be the cleanest.
> >
> > Actually I asked Linus an opinion before doing this, so maybe he can ack
> > this patch or suggest a better way of doing this, such as declaring the
> > same pins for multiple device ids, but I'm not sure that would work as
> > expected.
>
> Linus is on vacation at the moment, but I agree he should have the
> final say on this. Better wait until he returns.
Sounds good, I'll send the pinctrl patch in the meantime. There should
be no dependency issues regardless of merging order so I'll keep that
one on its own.
Fabio
--
Fabio Baltieri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists