[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50115961.6060509@linaro.org>
Date: Thu, 26 Jul 2012 15:51:13 +0100
From: Lee Jones <lee.jones@...aro.org>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
STEricsson_nomadik_linux@...t.st.com, linus.walleij@...ricsson.com,
arnd@...db.de, sameo@...ux.intel.com, olalilja@...oo.se,
ola.o.lilja@...ricsson.com, alsa-devel@...a-project.org, lrg@...com
Subject: Re: [PATCH 07/21] ASoC: io: Prevent use of regmap if request fails
On 26/07/12 12:42, Mark Brown wrote:
> On Thu, Jul 26, 2012 at 12:38:17PM +0100, Lee Jones wrote:
>> On 26/07/12 12:32, Mark Brown wrote:
>
>>> Again, this makes no sense. If we're explicitly being asked to use
>>> regmap then we should be using regmap or just failing to set up I/O
>>> (which is obviously a catastrophic failure).
>
>> How much work is there involved in regmap:ing a device, so that
>> dev_get_regmap() doesn't fail?
>
> Trivial if it's on a supported bus, otherwise you just need to write the
> bus. But why do you care if dev_get_regmap() fails? We only try to use
> regmap if the driver asked for regmap I/O (or doesn't have registers at
> all in which case it doesn't matter since we never do any I/O). What
> you appear to be saying here is that you're using regmap on a device
> which doesn't have a regmap set up which is clearly never going to work
> terribly well...
I don't think we want to use regmap at all, but we're forced to by
soc-core. How do we over-ride that behavior? By writing some nonsense
into codec->control_data?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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