From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "Matti J. Aaltonen" <matti.j.aaltonen@nokia.com>
Cc: alsa-devel@alsa-project.org, sameo@linux.intel.com,
ext Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.
Date: Fri, 14 Jan 2011 12:22:50 +0000 [thread overview]
Message-ID: <20110114122250.GC20846@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1294990984.6390.81.camel@masi.mnp.nokia.com>
On Fri, Jan 14, 2011 at 09:43:04AM +0200, Matti J. Aaltonen wrote:
> On Thu, 2011-01-13 at 17:12 +0000, ext Mark Brown
> > This is something that should really have been brought up when making
> > changes. It's really bad to just go and make other bits of the kernel
> > fail to build.
> I'm not exactly sure what you mean here... It's easy to say now - when
> looking back that - the whole driver should have been handled more as a
> whole. An ACK from you and an ACK from Samuel to the media guys etc...
If you're making an incompatible change in an API used by code that is
already part of the kernel then you need to make sure that that code is
updated as part of introducing the new API.
> > While looking at this I also notice that it's surprisingly difficult to
> > actually build any of this stuff - the MFD core can't be enabled
> > directly, it's only available if you enable the V4L driver, and the core
> > V4L build appears to be rather large adding a noticable amount of time
> > to the build needed to get coverage of the CODECs. It'd be good if you
> > could fix this to remove the dependency, I'd really expect the MFD to be
> > able to build by itself.
> The codec can already be built alone, I can't see what benefit would
> building the empty MFD driver offer. With the current structure nothing
> can actually be done without the V4L2 driver. But if there's something I
> don't get right now, I'll be happy make changes.
As things stand the only way the CODEC driver can be built is if V4L is
enabled, which like I say isn't a trivial build. This isn't ideal when
trying to get build coverage of the CODEC drivers for work on the core,
it adds noticable additional delay.
next prev parent reply other threads:[~2011-01-14 12:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 13:22 [PATCH] ASoC: WL1273 FM radio: Access I2C IO functions through pointers Matti J. Aaltonen
2011-01-13 13:34 ` Mark Brown
2011-01-13 13:35 ` Liam Girdwood
2011-01-13 14:17 ` Matti J. Aaltonen
2011-01-13 15:01 ` Mark Brown
2011-01-13 16:18 ` Matti J. Aaltonen
2011-01-13 17:12 ` Mark Brown
2011-01-14 7:43 ` Matti J. Aaltonen
2011-01-14 12:22 ` Mark Brown [this message]
2011-01-17 8:52 ` Matti J. Aaltonen
2011-01-17 13:56 ` Mark Brown
2011-01-17 14:58 ` Matti J. Aaltonen
2011-01-17 15:15 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110114122250.GC20846@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=lrg@slimlogic.co.uk \
--cc=matti.j.aaltonen@nokia.com \
--cc=sameo@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).