Re: [PATCH v2 08/13] ASoC: pxa: remove the dmaengine compat need
On Thu, May 24, 2018 at 09:06:58AM +0200, Robert Jarzmik wrote: > As the pxa architecture switched towards the dmaengine slave map, the > old compatibility mechanism to acquire the dma requestor line number and > priority are not needed anymore. Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature
Applied "media: i2c: tda1997: replace codec to component" to the asoc tree
The patch
media: i2c: tda1997: replace codec to component
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 2d8102cc9a27577ffa4335aaaed4a26060688de2 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <kuninori.morimoto...@renesas.com>
Date: Mon, 23 Apr 2018 02:10:26 +
Subject: [PATCH] media: i2c: tda1997: replace codec to component
Now we can replace Codec to Component. Let's do it.
Note:
xxx_codec_xxx() -> xxx_component_xxx()
.idle_bias_off = 0 -> .idle_bias_on = 1
.ignore_pmdown_time = 0 -> .use_pmdown_time = 1
- -> .endianness = 1
- -> .non_legacy_dai_naming = 1
Signed-off-by: Kuninori Morimoto <kuninori.morimoto...@renesas.com>
Tested-by: Tim Harvey <thar...@gateworks.com>
Acked-by: Tim Harvey <thar...@gateworks.com>
Acked-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>
Signed-off-by: Mark Brown <broo...@kernel.org>
---
drivers/media/i2c/tda1997x.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
index 3021913c28fa..33d7fcf541fc 100644
--- a/drivers/media/i2c/tda1997x.c
+++ b/drivers/media/i2c/tda1997x.c
@@ -2444,7 +2444,7 @@ static int tda1997x_pcm_startup(struct snd_pcm_substream
*substream,
struct snd_soc_dai *dai)
{
struct tda1997x_state *state = snd_soc_dai_get_drvdata(dai);
- struct snd_soc_codec *codec = dai->codec;
+ struct snd_soc_component *component = dai->component;
struct snd_pcm_runtime *rtd = substream->runtime;
int rate, err;
@@ -2452,11 +2452,11 @@ static int tda1997x_pcm_startup(struct
snd_pcm_substream *substream,
err = snd_pcm_hw_constraint_minmax(rtd, SNDRV_PCM_HW_PARAM_RATE,
rate, rate);
if (err < 0) {
- dev_err(codec->dev, "failed to constrain samplerate to %dHz\n",
+ dev_err(component->dev, "failed to constrain samplerate to
%dHz\n",
rate);
return err;
}
- dev_info(codec->dev, "set samplerate constraint to %dHz\n", rate);
+ dev_info(component->dev, "set samplerate constraint to %dHz\n", rate);
return 0;
}
@@ -2479,20 +2479,22 @@ static struct snd_soc_dai_driver tda1997x_audio_dai = {
.ops = _dai_ops,
};
-static int tda1997x_codec_probe(struct snd_soc_codec *codec)
+static int tda1997x_codec_probe(struct snd_soc_component *component)
{
return 0;
}
-static int tda1997x_codec_remove(struct snd_soc_codec *codec)
+static void tda1997x_codec_remove(struct snd_soc_component *component)
{
- return 0;
}
-static struct snd_soc_codec_driver tda1997x_codec_driver = {
- .probe = tda1997x_codec_probe,
- .remove = tda1997x_codec_remove,
- .reg_word_size = sizeof(u16),
+static struct snd_soc_component_driver tda1997x_codec_driver = {
+ .probe = tda1997x_codec_probe,
+ .remove = tda1997x_codec_remove,
+ .idle_bias_on = 1,
+ .use_pmdown_time= 1,
+ .endianness = 1,
+ .non_legacy_dai_naming = 1,
};
static int tda1997x_probe(struct i2c_client *client,
@@ -2737,7 +2739,7 @@ static int tda1997x_probe(struct i2c_client *client,
else
formats = SNDRV_PCM_FMTBIT_S16_LE;
tda1997x_audio_dai.capture.formats = formats;
- ret = snd_soc_register_codec(>client->dev,
+ ret = devm_snd_soc_register_component(>client->dev,
_codec_driver,
_audio_dai, 1);
if (ret) {
@@ -2782,7 +2784,6 @@ static int tda1997x_remove(struct i2c_client *client)
struct tda1997x_platform_data *pdata = >pdata;
if (pdata->audout_format) {
- snd_soc_unregister_codec(>dev);
mutex_destroy(>audio_lock);
}
--
2.17.0
Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component
On Mon, Apr 23, 2018 at 09:44:17AM -0700, Tim Harvey wrote: > Could you add some detail to the commit explaining why we need to > replace codec to component? I don't really know what that means. > Please refer to a commit if the ASoC API is changing in some way we > need to catch up with. This is a big transition in the ASoC API which is nearing completion - this driver is one of the last users of the CODEC struct, we've (well, mainly Morimoto-san) been migrating things away from it to the more general purpose component. There's no one commit to point at really as the two have coexisted for a while and we won't be able to finally remove the CODEC struct until all the drivers have transitioned away. signature.asc Description: PGP signature
Re: [PATCH 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS
On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote: > The first 6 patches can be applied independently by subsystem > maintainers. > The last two patches depend on the first 6 patches, and are thus marked > RFC. Would it not make sense to try to apply everything en masse rather than delaying? I'm happy to apply the subsystem stuff but if it gets things done quicker or more efficiently I'm also happy to have the lot merged as one series. signature.asc Description: PGP signature
Re: [PATCH 08/15] ASoC: pxa: remove the dmaengine compat need
On Mon, Apr 02, 2018 at 04:26:49PM +0200, Robert Jarzmik wrote: > As the pxa architecture switched towards the dmaengine slave map, the > old compatibility mechanism to acquire the dma requestor line number and > priority are not needed anymore. Acked-by: Mark Brown <broo...@kernel.org> If there's no dependency I'm happy to take this for 4.18. signature.asc Description: PGP signature
Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it
On Sun, Dec 03, 2017 at 08:43:47PM +0100, Wolfram Sang wrote: > > It's a bit different in that it's much more likely that a SPI controller > > will actually do DMA than an I2C one since the speeds are higher and > > there's frequent applications that do large transfers so it's more > > likely that people will do the right thing as issues would tend to come > > up if they don't. > Yes, for SPI this is true. I was thinking more of regmap with its > usage of different transport mechanisms. But I guess they should all be > DMA safe because some of them need to be DMA safe? Possibly. Hopefully. I guess we'll find out. signature.asc Description: PGP signature
Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it
On Mon, Nov 27, 2017 at 07:51:16PM +0100, Wolfram Sang wrote: > On Wed, Nov 08, 2017 at 10:50:37PM +0000, Mark Brown wrote: > > We pretty much assume everything is DMA safe already, the majority of > > transfers go to/from kmalloc()ed scratch buffers so actually are DMA > > safe but for bulk transfers we use the caller buffer and there might be > > some problem users. > So, pretty much the situation I2C was in before this patch set: we > pretty much assume DMA safety but there might be problem users. It's a bit different in that it's much more likely that a SPI controller will actually do DMA than an I2C one since the speeds are higher and there's frequent applications that do large transfers so it's more likely that people will do the right thing as issues would tend to come up if they don't. > > I can't really think of a particularly good way of > > handling it off the top of my head, obviously not setting the flag is > > easy but doesn't get the benefit while always using a bounce buffer > > would involve lots of unneeded memcpy(). Doing _dmasafe() isn't > > particularly appealing either but might be what we end up with. > Okay. That sounds you are fine with the approach taken here, in general? It's hard to summon enthusiasm but yes, without changes to the DMA stuff it's probably as good as we can do. signature.asc Description: PGP signature
Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it
On Sat, Nov 04, 2017 at 09:20:00PM +0100, Wolfram Sang wrote: > While previous versions until v3 tried to magically apply bounce buffers when > needed, it became clear that detecting DMA safe buffers is too fragile. This > approach is now opt-in, a DMA_SAFE flag needs to be set on an i2c_msg. The > outcome so far is very convincing IMO. The core additions are simple and easy > to understand. The driver changes for the Renesas IP cores became easy to > understand, too. It would really help a lot of things if there were a way to detect if a given memory block is DMA safe, having to pass the information around causes so much pain. There's the fun with vmalloc() mappings too needing to be handled differently too though that's less likely to bite I2C. > I am still not sure how we can teach regmap this new flag. regmap is a heavy > user of I2C, so broonie's opinion here would be great to have. The rest should > mostly be updating individual drivers which can be done when needed. We pretty much assume everything is DMA safe already, the majority of transfers go to/from kmalloc()ed scratch buffers so actually are DMA safe but for bulk transfers we use the caller buffer and there might be some problem users. I can't really think of a particularly good way of handling it off the top of my head, obviously not setting the flag is easy but doesn't get the benefit while always using a bounce buffer would involve lots of unneeded memcpy(). Doing _dmasafe() isn't particularly appealing either but might be what we end up with. signature.asc Description: PGP signature
Applied "regmap: Avoid namespace collision within macro & tidy up" to the regmap tree
The patch
regmap: Avoid namespace collision within macro & tidy up
has been applied to the regmap tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 780b1350d316fda28d85fcae17854c778d89cbbe Mon Sep 17 00:00:00 2001
From: Ramesh Shanmugasundaram <ramesh.shanmugasunda...@bp.renesas.com>
Date: Mon, 3 Jul 2017 12:04:21 +0100
Subject: [PATCH] regmap: Avoid namespace collision within macro & tidy up
Renamed variable "timeout" to "__timeout" & "pollret" to "__ret" to
avoid namespace collision. Tidy up macro arguments with parentheses.
Signed-off-by: Ramesh Shanmugasundaram <ramesh.shanmugasunda...@bp.renesas.com>
Signed-off-by: Mark Brown <broo...@kernel.org>
---
include/linux/regmap.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index e88649225a60..6e1df5e721a9 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -120,23 +120,24 @@ struct reg_sequence {
*/
#define regmap_read_poll_timeout(map, addr, val, cond, sleep_us, timeout_us) \
({ \
- ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
- int pollret; \
+ ktime_t __timeout = ktime_add_us(ktime_get(), timeout_us); \
+ int __ret; \
might_sleep_if(sleep_us); \
for (;;) { \
- pollret = regmap_read((map), (addr), &(val)); \
- if (pollret) \
+ __ret = regmap_read((map), (addr), &(val)); \
+ if (__ret) \
break; \
if (cond) \
break; \
- if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
- pollret = regmap_read((map), (addr), &(val)); \
+ if ((timeout_us) && \
+ ktime_compare(ktime_get(), __timeout) > 0) { \
+ __ret = regmap_read((map), (addr), &(val)); \
break; \
} \
if (sleep_us) \
- usleep_range((sleep_us >> 2) + 1, sleep_us); \
+ usleep_range(((sleep_us) >> 2) + 1, sleep_us); \
} \
- pollret ?: ((cond) ? 0 : -ETIMEDOUT); \
+ __ret ?: ((cond) ? 0 : -ETIMEDOUT); \
})
#ifdef CONFIG_REGMAP
--
2.13.2
Re: [PATCH v2 14/27] ASoC: blackfin: Convert to the new PCM ops
On Thu, Jun 01, 2017 at 10:58:37PM +0200, Takashi Iwai wrote: > Replace the copy and the silence ops with the new PCM ops. > In AC97 and I2S-TDM mode, we need to convert back to frames, but > otherwise the conversion is pretty straightforward. Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature
Re: [PATCH v2 02/27] ALSA: pcm: Introduce copy_user, copy_kernel and fill_silence ops
On Thu, Jun 01, 2017 at 10:58:25PM +0200, Takashi Iwai wrote: > For supporting the explicit in-kernel copy of PCM buffer data, and > also for further code refactoring, three new PCM ops, copy_user, > copy_kernel and fill_silence, are introduced. The old copy and > silence ops will be deprecated and removed later once when all callers > are converted. Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature
Re: regmap for i2c pages
On Thu, Jun 01, 2017 at 11:37:43PM -0700, Tim Harvey wrote: > I believe this is a very common i2c register mechanism but I'm not > clear what the best way to use i2c regmap for this is. I'm reading > that regmap 'handles register pages' but I'm not clear if that's the > same thing I'm looking for. If so, are there any examples of this? I > see several i2c drivers that reference pages but it looks to me that > each page is a different i2c slave address which is something > different. You're looking for regmap_range (search for window in regmap.h). signature.asc Description: PGP signature
Re: [PATCH 14/16] ASoC: blackfin: Convert to copy_silence ops
On Sun, May 21, 2017 at 10:09:48PM +0200, Takashi Iwai wrote: > Replace the copy and the silence ops with the new merged ops. > The silence is performed only when CONFIG_SND_BF5XX_MMAP_SUPPORT is > set (since copy_silence ops is set only with this config), so in > bf5xx-ac97.c we have a bit tricky macro for a slight optimization. > > Note that we don't need to take in_kernel into account on this > architecture, so the conversion is easy otherwise. Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Mon, Mar 13, 2017 at 10:54:33AM +, Brian Starkey wrote: > On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote: > > Another point is how can we put secure rules (like selinux policy) on > > heaps since all the allocations > > go to the same device (/dev/ion) ? For example, until now, in Android > > we have to give the same > > access rights to all the process that use ION. > > It will become problem when we will add secure heaps because we won't > > be able to distinguish secure > > processes to standard ones or set specific policy per heaps. > > Maybe I'm wrong here but I have never see selinux policy checking an > > ioctl field but if that > > exist it could be a solution. > I might be thinking of a different type of "secure", but... > Should the security of secure heaps be enforced by OS-level > permissions? I don't know about other architectures, but at least on > arm/arm64 this is enforced in hardware; it doesn't matter who has > access to the ion heap, because only secure devices (or the CPU > running a secure process) is physically able to access the memory > backing the buffer. > In fact, in the use-cases I know of, the process asking for the ion > allocation is not a secure process, and so we wouldn't *want* to > restrict the secure heap to be allocated from only by secure > processes. I think there's an orthogonal level of OS level security that can be applied here - it's reasonable for it to want to say things like "only processes that are supposed to be implementing functionality X should be able to try to allocate memory set aside for that functionality". This mitigates against escallation attacks and so on, it's not really directly related to secure memory as such though. signature.asc Description: PGP signature
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote: > No one gave a thing about android in upstream, so Greg KH just dumped it > all into staging/android/. We've discussed ION a bunch of times, recorded > anything we'd like to fix in staging/android/TODO, and Laura's patch > series here addresses a big chunk of that. > This is pretty much the same approach we (gpu folks) used to de-stage the > syncpt stuff. Well, there's also the fact that quite a few people have issues with the design (like Laurent). It seems like a lot of them have either got more comfortable with it over time, or at least not managed to come up with any better ideas in the meantime. signature.asc Description: PGP signature
Re: [RFC simple allocator v2 1/2] Create Simple Allocator module
On Tue, Feb 14, 2017 at 09:59:55PM +0200, Laurent Pinchart wrote: > On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote: > > ADF was probably the best example in this. KMS also took a while until all > > the fbdev wheels have been properly reinvented (some are still the same old > > squeaky onces as fbdev had, e.g. fbcon). > > And I don't think destaging ION is going to be hard, just a bit of > > work (could be a nice gsoc or whatever). > Oh, technically speaking, it would be pretty simple. The main issue is to > decide whether we want to commit to the existing ION API. I don't :-) Right, we need to figure out what people should be doing and let them work on it. At the minute anyone who wants to use this stuff in mainline is kind of stuck as attempts to add ION drivers get pushback https://lkml.org/lkml/2016/11/7/806 but so do attempts to do something different (there was a statement in that thread that new ION drivers could be added if we could ever figure out bindings but I'm not sure there's any prospect of that). There's no clear direction for people to follow if they want to make progress. signature.asc Description: PGP signature
Re: [RFC simple allocator v2 0/2] Simple allocator
On Mon, Feb 13, 2017 at 11:01:14AM -0800, Laura Abbott wrote: > On 02/13/2017 10:18 AM, Mark Brown wrote: > > The software defined networking people seemed to think they had a use > > case for this as well. They're not entirely upstream of course but > > still... > This is the first I've heard of anything like this. Do you have any more > details/reading? No, unfortunately it was in a meeting and I was asking for more details on what specifically the hardware was doing myself. My understanding is that it's very similar to the GPU/video needs. signature.asc Description: PGP signature
Re: [RFC simple allocator v2 0/2] Simple allocator
On Mon, Feb 13, 2017 at 03:45:04PM +0100, Benjamin Gaignard wrote: > An other question is: do we have others memory regions that could be > interested > by this new framework ? I have in mind that some title memory regions could > use > it or replace ION heaps (system, carveout, etc...). > Maybe it only solve CMA allocation issue, in this case there is no need to > create > a new framework but only a dedicated ioctl. The software defined networking people seemed to think they had a use case for this as well. They're not entirely upstream of course but still... signature.asc Description: PGP signature
Re: [PATCH v6 2/2] media: Add a driver for the ov5645 camera sensor.
On Mon, Nov 14, 2016 at 02:18:49PM +0200, Laurent Pinchart wrote: > On Wednesday 26 Oct 2016 12:51:49 Mark Brown wrote: > > Why would this be guaranteed by the API given that it's not documented > > and why would many drivers break? It's fairly rare for devices other > > than SoCs to have strict power on sequencing requirements as it is hard > > to achieve in practical systems. > Is there a reason why the API shouldn't guarantee that regulators are powered > on in the order listed, and powered off in the reverse order ? Looking at the If it ever even did that through implementation it's not been true for a very long time - it does the regulator enables in parallel in order to reduce the overall time to power things up. I keep wanting to come up with code to figure out if we're using multiple enable bits in a single register and hit them all at once though it's likely to be more trouble than it's worth. > implementation that's already the case for regulator_bulk_disable(), but > regulator_bulk_enable() uses async scheduling so doesn't guarantee ordering. > I > wonder whether a synchronous version of regulator_bulk_enable() would be > useful. *Possibly* but I'd be surprised to learn that there's a substantial amount of hardware out there that cares given that a power on reset circuit isn't exactly complex to implement. You do sometimes see a global rail that should come up first (especially if there is an integrated regulator) but I've not seen many cases where the hardware cared outside of SoCs. signature.asc Description: PGP signature
Re: [PATCH v6 2/2] media: Add a driver for the ov5645 camera sensor.
On Wed, Oct 26, 2016 at 02:27:23PM +0300, Todor Tomov wrote: > And using Mark Brown's correct address... This is an *enormous* e-mail quoted to multiple levels with top posting and very little editing which makes it incredibly hard to find any relevant content. > >> I believe it should be an API guarantee, otherwise many drivers using the > >> bulk > >> API would break. Mark, could you please comment on that ? > > Ok, let's wait for a response from Mark. Why would this be guaranteed by the API given that it's not documented and why would many drivers break? It's fairly rare for devices other than SoCs to have strict power on sequencing requirements as it is hard to achieve in practical systems. signature.asc Description: PGP signature
Re: [PATCH 3/4] spi: use sg_alloc_table_from_buf()
On Thu, Mar 31, 2016 at 02:29:43PM +0200, Boris Brezillon wrote: > Replace custom implementation of sg_alloc_table_from_buf() by a call to > sg_alloc_table_from_buf(). Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature
Re: [PATCH v2 4/7] scatterlist: add sg_alloc_table_from_buf() helper
On Wed, Mar 30, 2016 at 08:18:31PM +0200, Boris Brezillon wrote: > BTW, do you see other things that should be added in sg_constraints? It looked to do everything SPI does which is everything I know about. signature.asc Description: PGP signature
Re: [PATCH v2 4/7] scatterlist: add sg_alloc_table_from_buf() helper
On Wed, Mar 30, 2016 at 05:39:51PM +0200, Boris Brezillon wrote: > sg_alloc_table_from_buf() provides an easy solution to create an sg_table > from a virtual address pointer. This function takes care of dealing with > vmallocated buffers, buffer alignment, or DMA engine limitations (maximum > DMA transfer size). This seems nice. Should we also have a further helper on top of this which will get constraints from a dmaengine, it seems like it'd be a common need? signature.asc Description: PGP signature
Re: [PATCH] [media] move media platform data to linux/platform_data/media
On Tue, Nov 17, 2015 at 07:15:59AM -0200, Mauro Carvalho Chehab wrote: > Now that media has its own subdirectory inside platform_data, > let's move the headers that are already there to such subdir. Acked-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature
Re: [PATCH 13/13] ASoC: omap-pcm: Switch to use dma_request_slave_channel_compat_reason()
On Tue, May 26, 2015 at 04:26:08PM +0300, Peter Ujfalusi wrote: dmaengine provides a wrapper function to handle DT and non DT boots when requesting DMA channel. Use that instead of checking for of_node in the platform driver. Acked-by: Mark Brown broo...@kernel.org signature.asc Description: Digital signature
Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
On Wed, May 27, 2015 at 02:15:12PM +0300, Peter Ujfalusi wrote: I have put the maintainers of the relevant subsystems as CC in the commit message and sent the series to all of the mailing lists. This series was touching 7 subsystems and I thought not spamming every maintainer with all the mails might be better. You need to at least include people on the cover letter, otherwise they'll have no idea what's going on. signature.asc Description: Digital signature
Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. Acked-by: Mark Brown broo...@kernel.org signature.asc Description: Digital signature
Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. I've got two patches from a patch series here with no cover letter... I'm guessing there's no interdependencies or anything? Please always ensure that when sending a patch series everyone getting the patches can tell what the series as a whole looks like (if there's no dependencies consider posting as individual patches rather than a series). signature.asc Description: Digital signature
Re: [PATCH 06/10] ASOC: migor: use clkdev_create()
On Mon, Mar 02, 2015 at 05:06:32PM +, Russell King wrote: clkdev_create() is a shorter way to write clkdev_alloc() followed by clkdev_add(). Use this instead. Acked-by: Mark Brown broo...@kernel.org signature.asc Description: Digital signature
Re: [PATCH 21/66] rtl2830: implement own I2C locking
On Tue, Feb 03, 2015 at 08:34:01PM +0200, Antti Palosaari wrote: On 02/03/2015 07:53 PM, Mauro Carvalho Chehab wrote: If latter a better way to lock the I2C mux appears, we can reverse this change. More I am worried about next patch in a serie, which converts all that to regmap API... Same recursive mux register access comes to problem there, which I work-arounded by defining own I2C IO... And in that case I used i2c_lock_adapter/i2c_unlock_adapter so adapter is locked properly. Opne coding the register I/O is a terrible solution, we should allow people to keep this code factored out. signature.asc Description: Digital signature
Re: [PATCHv2 1/2] regmap: add configurable lock class key for lockdep
On Mon, Feb 02, 2015 at 12:31:38PM -0200, Mauro Carvalho Chehab wrote: Antti/Mark, Any news with regards to this? Please don't top post or send content free nags. I can't really remember what this is about but I don't think my review comments were ever addressed. signature.asc Description: Digital signature
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On Thu, Jan 15, 2015 at 08:24:26AM -0600, Rob Herring wrote: On Tue, Jan 13, 2015 at 2:42 AM, Jacek Anaszewski I am aware that it may be tempting to treat LED devices as common regulators, but they have their specific features which gave a reason for introducing LED class for them. Besides, there is already drivers/leds/leds-regulator.c driver for LED devices which support only turning on/off and setting brightness level. In your proposition a separate regulator provider binding would have to be created for each current output and a separate binding for each discrete LED connected to the LED device. It would create unnecessary noise in a dts file. Moreover, using regulator binding implies that we want to treat it as a sheer power supply for our device (which would be a discrete LED element in this case), whereas LED devices provide more features like blinking pattern and for flash LED devices - flash timeout, external strobe and flash faults. Okay, fair enough. Please include some of this explanation in the binding description. Right, the other thing here is that these chips are not normally designed with the goal that the various components be used separately - I've seen devices where the startup and shutdown procedures involve interleaved actions to the boost regulator and current sink for example. Trying to insert an abstraction layer typically just makes life more complex. signature.asc Description: Digital signature
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On Mon, Jan 12, 2015 at 10:55:29AM -0600, Rob Herring wrote: On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski There are however devices that don't fall into this category, i.e. they have many outputs, that can be connected to a single LED or to many LEDs and the driver has to know what is the actual arrangement. We may need to extend the regulator binding slightly and allow for multiple phandles on a supply property, but wouldn't something like this work: led-supply = led-reg0, led-reg1, led-reg2, led-reg3; The shared source is already supported by the regulator binding. What is the reasoning for this? If a single supply is being supplied by multiple regulators then in general those regulators will all know about each other at a hardware level and so from a functional and software point of view will effectively be one regulator. If they don't/aren't then they tend to interfere with each other. signature.asc Description: Digital signature
Re: [PATCHv2 1/2] regmap: add configurable lock class key for lockdep
On Sun, Dec 21, 2014 at 12:34:51AM +0200, Antti Palosaari wrote: Lockdep validator complains recursive locking and deadlock when two different regmap instances are called in a nested order, as regmap groups locks by default. That happens easily for example when both I don't know what regmap groups locks by default means. I2C client and I2C adapter are using regmap. As a solution, add configuration option to pass custom lock class key for lockdep validator. Why is this configurable, how would a device know if the system it is in needs a custom locking class and can safely use one? signature.asc Description: Digital signature
Re: [PATCHv2 1/2] regmap: add configurable lock class key for lockdep
On Mon, Dec 22, 2014 at 02:55:23PM +0200, Antti Palosaari wrote: On 12/22/2014 02:44 PM, Mark Brown wrote: On Sun, Dec 21, 2014 at 12:34:51AM +0200, Antti Palosaari wrote: I2C client and I2C adapter are using regmap. As a solution, add configuration option to pass custom lock class key for lockdep validator. Why is this configurable, how would a device know if the system it is in needs a custom locking class and can safely use one? If RegMap instance is bus master, eg. I2C adapter, then you should define own custom key. If you don't define own key and there will be slave on that bus which uses RegMap too, there will be recursive locking from a lockdep point of view. That doesn't really explain to me why this is configurable, why should drivers have to worry about this? Please also write technical terms like regmap normally. signature.asc Description: Digital signature
Re: [PATCHv2 1/2] regmap: add configurable lock class key for lockdep
On Mon, Dec 22, 2014 at 03:53:10PM +0200, Antti Palosaari wrote: On 12/22/2014 03:31 PM, Mark Brown wrote: Why is this configurable, how would a device know if the system it is in needs a custom locking class and can safely use one? If RegMap instance is bus master, eg. I2C adapter, then you should define own custom key. If you don't define own key and there will be slave on that bus which uses RegMap too, there will be recursive locking from a lockdep point of view. That doesn't really explain to me why this is configurable, why should drivers have to worry about this? Did you read the lockdep documentation I pointed previous mail? No, quite apart from the fact that you pasted a good chunk of it into your mail I don't think it's a good idea to require people to have to reverse engineer everything to figure out if they're supposed to use this, or expect people reviewing code using this feature to do that in order to figure out if it's being used correctly or not. Suggesting that I'm not thinking hard enough isn't helping here; this stuff needs to be clear and easy so that people naturally get it right when they need to and don't break things as a result of confusion or error, requiring people to directly work with infrequently used things like lock classes with minimal explanation doesn't achieve that goal. One possibility is to disable lockdep checking from that driver totally, then drivers do not need to care it about. But I don't think it is proper way. One solution is to use custom regmap locking available already, but Mauro nor me didn't like that hack: You don't seem to be answering any of my questions here... for example, you keep saying that this is something bus masters should do. Why does it make sense for people writing such drivers to have to figure out that they need to do this and how to do it? Are there some bus masters that shouldn't be doing so? Should anything that isn't a bus master have to do it? Please also write technical terms like regmap normally. Lower-case letters? Yes, the way it's written in every place it's used in the kernel except a few I see you've added. signature.asc Description: Digital signature
Re: [PATCHv2 1/2] regmap: add configurable lock class key for lockdep
On Mon, Dec 22, 2014 at 12:23:19PM -0200, Mauro Carvalho Chehab wrote: What this patch does is to offer a way for drivers B and C to define different mutex groups (e. g. different mutex IDs) that will teach the lockdep code to threat regmap mutex on drivers B and C as different mutexes. I hope the above explanation helps. No, not really - even the best explanation on the mailing list isn't going to make the commit clearer (something like this needs to be at least clear in the commit log and ideally the code) and it'd be much better if the interface were improved so it's obvious that users are doing the right thing when they use it. signature.asc Description: Digital signature
Re: [PATCHv2 1/2] regmap: add configurable lock class key for lockdep
On Sun, Dec 21, 2014 at 12:34:51AM +0200, Antti Palosaari wrote: + * @lock_class_key: Custom lock class key for lockdep validator. Use that when + *regmap in question is used for bus master IO in order to avoid + *false lockdep nested locking warning. Valid only when regmap + *default mutex locking is used. Thinking about this further this comment definitely isn't accurate, it's not just bus masters that are potentially affected but also things like clock controllers that might need to be interacted with in order to do I/O. Thinking about those I'm even unsure that a per driver class (which seems to be the idea here) will be enough, it's at least in theory possible that two different instances of the same clock IP (or generic regmap clock controller) will both need to be turned on for this to work. If it was just bus controllers it looks like we can probably just have the clients set a flag saying that's what they are and then define the class in the regmap core but I don't think that's all that's going on here. signature.asc Description: Digital signature
Re: [PATCH] [media] v4l2-pci-skeleton: Only build if PCI is available
On Tue, Aug 26, 2014 at 01:08:39PM -0700, Randy Dunlap wrote: On 08/26/14 12:59, Randy Dunlap wrote: On 08/26/14 12:26, Mark Brown wrote: No, it's not - if it's going to depend on COMPILE_TEST at all it need to be a hard dependency. How about just drop COMPILE_TEST? This code only builds if someone enabled BUILD_DOCSRC. That should be enough (along with PCI and some VIDEO kconfig symbols) to qualify it. I'll add BUILD_DOCSRC to the depends list in the Kconfig file... OK, that symbol probably does the job - I wasn't aware of it previously. signature.asc Description: Digital signature
[PATCH] [media] v4l2-pci-skeleton: Only build if PCI is available
From: Mark Brown broo...@linaro.org Currently arm64 does not support PCI but it does support v4l2. Since the PCI skeleton driver is built unconditionally as a module with no dependency on PCI this causes build failures for arm64 allmodconfig. Fix this by defining a symbol VIDEO_PCI_SKELETON for the skeleton and conditionalising the build on that. Signed-off-by: Mark Brown broo...@linaro.org --- Documentation/video4linux/Makefile | 2 +- drivers/media/v4l2-core/Kconfig| 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/video4linux/Makefile b/Documentation/video4linux/Makefile index d58101e788fc..65a351d75c95 100644 --- a/Documentation/video4linux/Makefile +++ b/Documentation/video4linux/Makefile @@ -1 +1 @@ -obj-m := v4l2-pci-skeleton.o +obj-$(CONFIG_VIDEO_PCI_SKELETON) := v4l2-pci-skeleton.o diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig index 9ca0f8d59a14..2b368f711c9e 100644 --- a/drivers/media/v4l2-core/Kconfig +++ b/drivers/media/v4l2-core/Kconfig @@ -25,6 +25,13 @@ config VIDEO_FIXED_MINOR_RANGES When in doubt, say N. +config VIDEO_PCI_SKELETON + tristate Skeleton PCI V4L2 driver + depends on PCI COMPILE_TEST + ---help--- + Enable build of the skeleton PCI driver, used as a reference + when developign new drivers. + # Used by drivers that need tuner.ko config VIDEO_TUNER tristate -- 2.1.0.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] v4l2-pci-skeleton: Only build if PCI is available
On Tue, Aug 26, 2014 at 06:56:05PM +0200, Hans Verkuil wrote: Against which kernel is this? Documentation/video4linux/Makefile doesn't exist in either the mainline kernel or the media_tree git repo. This is against -next, looks like the bug is in the Documentation tree... signature.asc Description: Digital signature
[PATCH] [media] v4l2-pci-skeleton: Only build if PCI is available
From: Mark Brown broo...@linaro.org Currently arm64 does not support PCI but it does support v4l2. Since the PCI skeleton driver is built unconditionally as a module with no dependency on PCI this causes build failures for arm64 allmodconfig. Fix this by defining a symbol VIDEO_PCI_SKELETON for the skeleton and conditionalising the build on that. Signed-off-by: Mark Brown broo...@linaro.org --- The patch adding the Makefile was added to the Documentation tree, either it should be reverted or something like this added on top. Documentation/video4linux/Makefile | 2 +- drivers/media/v4l2-core/Kconfig| 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/video4linux/Makefile b/Documentation/video4linux/Makefile index d58101e788fc..65a351d75c95 100644 --- a/Documentation/video4linux/Makefile +++ b/Documentation/video4linux/Makefile @@ -1 +1 @@ -obj-m := v4l2-pci-skeleton.o +obj-$(CONFIG_VIDEO_PCI_SKELETON) := v4l2-pci-skeleton.o diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig index 9ca0f8d59a14..2b368f711c9e 100644 --- a/drivers/media/v4l2-core/Kconfig +++ b/drivers/media/v4l2-core/Kconfig @@ -25,6 +25,13 @@ config VIDEO_FIXED_MINOR_RANGES When in doubt, say N. +config VIDEO_PCI_SKELETON + tristate Skeleton PCI V4L2 driver + depends on PCI COMPILE_TEST + ---help--- + Enable build of the skeleton PCI driver, used as a reference + when developign new drivers. + # Used by drivers that need tuner.ko config VIDEO_TUNER tristate -- 2.1.0.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] v4l2-pci-skeleton: Only build if PCI is available
On Tue, Aug 26, 2014 at 12:20:54PM -0700, Randy Dunlap wrote: On 08/26/14 10:25, Mark Brown wrote: index d58101e788fc..65a351d75c95 100644 --- a/Documentation/video4linux/Makefile +++ b/Documentation/video4linux/Makefile @@ -1 +1 @@ -obj-m := v4l2-pci-skeleton.o +obj-$(CONFIG_VIDEO_PCI_SKELETON) := v4l2-pci-skeleton.o diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig +config VIDEO_PCI_SKELETON + tristate Skeleton PCI V4L2 driver + depends on PCI COMPILE_TEST ?? No, don't require COMPILE_TEST. That's a very deliberate choice. There's no reason I can see to build this code other than to check that it builds, it's reference code rather than something that someone is expected to actually use in their system. This seems like a perfect candidate for COMPILE_TEST. However, PCI || COMPILE_TEST would allow it to build on arm64 if COMPILE_TEST is enabled, guaranteeing build errors. Is that what should happen? I suppose so... No, it's not - if it's going to depend on COMPILE_TEST at all it need to be a hard dependency. signature.asc Description: Digital signature
Re: [PATCH][RESEND 7/8] ASoC: davinci: use gen_pool_dma_alloc() in davinci-pcm.c
On Fri, Nov 01, 2013 at 07:48:20PM +0800, Nicolin Chen wrote: Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Acked-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
Re: [PATCH][RESEND 8/8] ASoC: pxa: use gen_pool_dma_alloc() to allocate dma buffer
On Fri, Nov 01, 2013 at 07:48:21PM +0800, Nicolin Chen wrote: Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Acked-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
Re: [PATCH 7/8] ASoC: imx-wm8962: Don't use i2c_client-driver
On Sun, Sep 29, 2013 at 10:51:05AM +0200, Lars-Peter Clausen wrote: The 'driver' field of the i2c_client struct is redundant and is going to be removed. Check i2c_client-dev.driver instead to see if a driver is bound to the device. Acked-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
Re: [PATCH 4/5] ASoC: samsung: Use CONFIG_ARCH_S3C64XX to check for S3C64xx support
On Sat, Sep 28, 2013 at 08:21:36PM +0200, Tomasz Figa wrote: Since CONFIG_PLAT_S3C64XX is going to be removed, this patch modifies the s3c-i2s-v2 driver to use the proper way of checking for S3C64xx support - CONFIG_ARCH_S3C64XX. Acked-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
Re: [PATCH] media: i2c: adv7343: fix the DT binding properties
On Tue, Sep 24, 2013 at 11:44:57AM +0200, Laurent Pinchart wrote: On Monday 23 September 2013 15:33:10 Stephen Warren wrote: So I think you want to make the supply properties mandatory in DT (since some form of supply is mandatory in HW), yet make the driver support broken DTs which don't have those properties, by error-checking the return value from regulator_get(). You might want to put a note into DT saying that a previous version of the binding didn't require those supply properties, so they may be missing from older DTs. Are there such devices in the wild ? From v3.12 on the kernel will stub in a dummy supply if one isn't found when using DT but I wouldn't mention that in the bindings since it's very much fixing up broken DTs rather than a good idea. signature.asc Description: Digital signature
Re: [PATCH] media: i2c: adv7343: fix the DT binding properties
On Mon, Sep 23, 2013 at 01:50:51PM +0200, Laurent Pinchart wrote: Isn't regulator_get_optional() intended for devices that can have supplies unconnected in normal use ? The ADV7343 supplies are mandatory from a hardware point of view, so I think we should use regulator_get(). Otherwise the driver won't be able to tell the difference between a regulator that isn't present yet (for instance because the regulator device/driver hasn't been probed yet), which should result in deferred probing, and an always-on regulator that has been left out. Yes, everything you say here is correct. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote: Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. There's a bunch of non-DT architectures that are in active use (blackfin for example) and I'd really hope that this is useful for some of them. The pushback here was about the fact that the subsystem was doing odd things with selecting device names which is odd in itself, I don't know if that had bled over into the DT bindings but it sounded like it might've done so. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote: I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Well, it seemed like Greg's concerns had already been addressed anyway. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:05AM -0400, Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Okay. Are PHYs _always_ platform devices? They can be i2c, spi or any other device types as well. In those other cases, presumably there is no platform data associated with the PHY since it isn't a platform device. Then how does the kernel know which controller is attached to the PHY? Is this spelled out in platform data associated with the PHY's i2c/spi/whatever parent? Platform data is nothing to do with the platform bus - it's board specific data (ie, data for the platform) and can be done with any device. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote: I fully agree that a simple, single string will not scale even in some, not so uncommon cases, but there is already a lot of existing lookup solutions over the kernel and so there is no point in introducing another one. I'm trying to get _rid_ of lookup solutions and just use a real pointer, as you should. I'll go tackle those other ones after this one is taken care of, to show how the others should be handled as well. What are the problems you are seeing with doing things with lookups? Having to write platform data for everything gets old fast and the code duplication is pretty tedious... signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 11:01:10AM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote: What are the problems you are seeing with doing things with lookups? You don't know the id of the device you are looking up, due to multiple devices being in the system (dynamic ids, look back earlier in this thread for details about that.) I got copied in very late so don't have most of the thread I'm afraid, I did try looking at web archives but didn't see a clear problem statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. Having to write platform data for everything gets old fast and the code duplication is pretty tedious... Adding a single pointer is tedious? Where is the name that you are going to lookup going to come from? That code doesn't write itself... It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 12:44:23PM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. What do you mean by locally? Within themselves - for example a regulator consumer asks for a given supply on the device in terms of the supply names the device has. The problem with the api was that the phy core wanted a id and a name to create a phy, and then later other code was doing a lookup based on the name and id (mushed together), because it knew that this device was the one it wanted. Ah, that sounds like the API is missing a component to link things together. But I could be wrong. What I would expect to see is that the consumer says I want the PHY called X and the PHY driver says I provide this set of PHYs with a layer in between that plugs those together. This would normally involve talking about the parent device rather than the PHY itself. I think, that if you create a device, then just carry around the pointer to that device (in this case a phy) and pass it to whatever other code needs it. No need to do lookups on known names or anything else, just normal pointers, with no problems for multiple devices, busses, or naming issues. I think you're not really talking about the lookup API at all here but rather about one way in which the matching code can be written. What everything *really* wants to do is work in terms of resources namespaced within struct devices since every bit of hardware in the system should have one of those it can use and if you have a struct device you can do useful things like call dev_printk() and find the device tree data to do device tree based lookups. Unfortunately for a number of buses even when statically registering the struct device doesn't get allocated until the device is probed so what everyone fell back on doing was using dev_name() in cases where the struct device wasn't there yet, or just always using it for consistency since for most of the affected buses dev_name() is fixed for human interface reasons. I think this is the issue you're concerned about here since if the dev_name() is dynamically allocated this breaks down. This only affects board files, DT and ACPI can both use their own data structures to do the mapping. I had thought you were talking about picking the names that the consumers use (which isn't actually that big a deal, it's just a bit annoying for the clock API). It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. I agree, so just pass around the pointer to the phy and all is good. No need to worry about DT or ACPI or anything else. No, in practice passing around the pointer gets tricky if you're using something other than board files (or even are doing any kind of dynamic stuff with board files) since the two devices need to find each other and if you're using platform data then the code doing the matching has to know about the platform data for every device it might need to match which is just miserable. Something would need to do something like allocate the PHY objects and then arrange for them to be passed to both provider and consumer devices prior to those being registered, knowing where to place the pointers in the platform data for each device. This is straightforward with board files but not otherwise, people have tried this before. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. The clock api is having problems with multiple names due to dynamic devices from what I was told. I want to prevent the PHY interface from having that same issue. I think the underlying issue here is that we don't have a good enough general way for board files (or other C code but mostly them) to talk about devices prior to their being registered - rather than have the pointer you're talking about be the PHY object itself have the pointer be something which allows us to match the struct device when it's created. This should be transparent to drivers and would be usable by all the existing APIs. signature.asc Description: Digital signature
Re: [alsa-devel] [PATCH] MAINTAINERS: Add linux-samsung-soc list to all related entries
On Mon, Apr 22, 2013 at 03:23:29PM +0900, Kyungmin Park wrote: I don't think it's not required, each tree has each own mailing list. don't need to post all patches to samsung-soc list. It can be useful to get system level input on some stuff, I guess it mostly depends if the people on the generic list mind the extra traffic or if they find it useful. signature.asc Description: Digital signature
Re: [GIT PULL FOR v3.10] Camera sensors patches
On Mon, Apr 22, 2013 at 01:14:07AM +0200, Laurent Pinchart wrote: I think that Mark's point was that the regulators should be provided by platform code (in the generic sense, it could be DT on ARM, board code, or a USB bridge driver for a webcam that uses the mt9p031 sensor) and used by the sensor driver. That's exactly what my mt9p031 patch does. Yes, you understood me perfectly - to a good approximation the matching up should be done by whatever the chip is soldered down to. signature.asc Description: Digital signature
Re: [GIT PULL FOR v3.10] Camera sensors patches
On Mon, Apr 22, 2013 at 09:46:07AM -0300, Mauro Carvalho Chehab wrote: Em 22-04-2013 07:03, Mark Brown escreveu: Yes, you understood me perfectly - to a good approximation the matching up should be done by whatever the chip is soldered down to. That doesn't make any sense to me. I2C devices can be used anywere, as they can be soldered either internally on an USB webcam without any regulators or any other platform code on it or could be soldered to some platform-specific bus. If it's running on Linux on a visible I2C bus it ought to be shown as an I2C bus on Linux and the thing doing that plumbing ought to be worrying about hooking up anything the driver needs. Also, what best describes soldered here is the binding between an I2C driver and the I2C adapter. The I2C adapter is a platform driver on embedded devices, where, on an usual USB camera, it is just a USB-I2C bridge. Sure, but there's no meaningful difference between these things as far as plumbing things together goes. Also, requiring that simple USB cameras to have regulators will prevent its usual usage, as non-platform distros don't set config REGULATOR, and it shouldn't. No problem there, the regulator API stubs itself out if it's not enabled. signature.asc Description: Digital signature
Re: [GIT PULL FOR v3.10] Camera sensors patches
On Tue, Apr 16, 2013 at 08:04:52PM +0200, Sylwester Nawrocki wrote: It's probably more clean to provide a dummy clock/regulator in a host driver (platform) than to add something in a sub-device drivers that would resolve which resources should be requested and which not. Yes, that's the general theory for regulators at least - it allows the device driver to just trundle along and not worry about how the board is hooked up. The other issue it resolves that you didn't mention is that it avoids just ignoring errors which isn't terribly clever. signature.asc Description: Digital signature
Re: [PATCH 07/14] media: soc-camera: support deferred probing of clients
On Wed, Apr 10, 2013 at 09:53:20PM +0800, Barry Song wrote: 2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de: what about another possible way: we let all host and i2c client driver probed in any order, This cannot work, because some I2C devices, e.g. sensors, need a clock signal from the camera interface to probe. Before the bridge driver has completed its probing and registered a suitable clock source with the v4l2-clk framework, sensors cannot be probed. And no, we don't want to fake successful probing without actually being able to talk to the hardware. i'd say same dependency also exists on ASoC. a fake successful probing doesn't mean it should really begin to work if there is no external trigger source. ASoC has successfully done that by a machine driver to connect all DAI. a way is we put all things ready in their places, finally we connect them together and launch the whole hardware flow. In the ASoC case the idea is that drivers should probe as far as they can with just the chip and then register with the core. The machine driver defers probing until all components have probed and then runs through second stage initialisaton which pulls everything together. signature.asc Description: Digital signature
Re: [PATCH v4 6/7] sound/soc/codecs: Convert SI476X codec to use regmap
On Mon, Feb 18, 2013 at 07:59:34PM -0800, Andrey Smirnov wrote: From: Andrey Smirnov andreysm@charmander.(none) The latest radio and MFD drivers for SI476X radio chips use regmap API to provide access to the registers and allow for caching of their Applied, thanks. Always use subject lines appropriate for the subsystem you're submitting against. signature.asc Description: Digital signature
Re: [PATCH v4 7/7] sound/soc/codecs: Cosmetic changes to SI476X codec driver
On Mon, Feb 18, 2013 at 07:59:35PM -0800, Andrey Smirnov wrote: - Add appropriate license header - Change email address in MODULE_AUTHOR - Remove trailing whitespaces Applied, thanks. Always use subject lines appropriate for the subsystem you're submitting against. signature.asc Description: Digital signature
Re: [PATCH v2 1/6] Add header files and Kbuild plumbing for SI476x MFD core
On Tue, Dec 18, 2012 at 07:07:28PM -0800, Andrey Smirnov wrote:
On 12-12-18 11:37 AM, Mauro Carvalho Chehab wrote:
Em Mon, 8 Oct 2012 11:38:01 -0700
Andrey Smirnov andrey.smir...@convergeddevices.net escreveu:
Guys, please delete irrelevant context from mails. I just TL;DRed this
so if there's anything you're expecting from me on this please let me
know.
On 10/08/2012 01:43 AM, Hans Verkuil wrote:
On Sat October 6 2012 03:54:57 Andrey Smirnov wrote:
This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.
The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
functionality to the two other drivers that represent radio and audio
codec subsystems of the chip.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile|3 +
include/linux/mfd/si476x-core.h | 529
+++
include/media/si476x.h | 449 +
4 files changed, 995 insertions(+)
create mode 100644 include/linux/mfd/si476x-core.h
create mode 100644 include/media/si476x.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..3fab06d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -895,6 +895,20 @@ config MFD_WL1273_CORE
driver connects the radio-wl1273 V4L2 module and the wl1273
audio codec.
+config MFD_SI476X_CORE
+ tristate Support for Silicon Laboratories 4761/64/68 AM/FM radio.
+ depends on I2C
+ select MFD_CORE
+ default n
+ help
+ This is the core driver for the SI476x series of AM/FM radio. This MFD
+ driver connects the radio-si476x V4L2 module and the si476x
+ audio codec.
+
+ To compile this driver as a module, choose M here: the
+ module will be called si476x-core.
+
+
config MFD_OMAP_USB_HOST
bool Support OMAP USBHS core driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..942257b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -132,3 +132,6 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o
rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_ANATOP)+= anatop-mfd.o
obj-$(CONFIG_MFD_LM3533)+= lm3533-core.o lm3533-ctrlbank.o
+
+si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
+obj-$(CONFIG_MFD_SI476X_CORE)+= si476x-core.o
diff --git a/include/linux/mfd/si476x-core.h
b/include/linux/mfd/si476x-core.h
new file mode 100644
index 000..eb6f52a
--- /dev/null
+++ b/include/linux/mfd/si476x-core.h
@@ -0,0 +1,529 @@
+/*
+ * include/media/si476x-core.h -- Common definitions for si476x core
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef SI476X_CORE_H
+#define SI476X_CORE_H
+
+#include linux/kfifo.h
+#include linux/atomic.h
+#include linux/i2c.h
+#include linux/mutex.h
+#include linux/mfd/core.h
+#include linux/videodev2.h
+
+#include media/si476x.h
+
+#ifdef DEBUG
+#define DBG_BUFFER(device, header, buffer, bcount)
\
+ do {\
+ dev_info((device), header); \
+ print_hex_dump_bytes(,\
+ DUMP_PREFIX_OFFSET,\
+ buffer, bcount); \
+ } while (0)
+#else
+#define DBG_BUFFER(device, header, buffer, bcount)
\
+ do {} while (0)
+#endif
+
+enum si476x_freq_suppoted_chips {
typo: suppoted - supported
+ SI476X_CHIP_SI4761 = 1,
+ SI476X_CHIP_SI4762,
+ SI476X_CHIP_SI4763,
+ SI476X_CHIP_SI4764,
+ SI476X_CHIP_SI4768,
+ SI476X_CHIP_SI4769,
+};
+
+enum si476x_mfd_cells {
+ SI476X_RADIO_CELL = 0,
+ SI476X_CODEC_CELL,
+ SI476X_MFD_CELLS,
+};
+
+
+/**
+ * enum si476x_power_state - possible power state of the si476x
+ * device.
+ *
+ * @SI476X_POWER_DOWN: In this state all regulators are turned off
+ * and the reset line is pulled low. The device is completely
+ * inactive.
+ * @SI476X_POWER_UP_FULL: In this state all the
Re: [PATCH v3 2/6] Add the main bulk of core driver for SI476x code
On Thu, Oct 25, 2012 at 03:26:02PM -0700, Andrey Smirnov wrote: On 10/25/2012 12:45 PM, Mark Brown wrote: This really makes little sense to me, why are you doing this? Does the device *really* layer a byte stream on top of I2C for sending messages that look like marshalled register reads and writes? The SI476x chips has a concept of a property. Each property having 16-bit address and 16-bit value. At least a portion of a chip configuration is done by modifying those properties. In order to Right, that's what I remembered from previous code. There's no way this should be a regmap bus - a bus is something that gets data serialised by the core into a byte stream, having the data rendered down into a byte stream and then reparsing it is a bit silly. The device should be hooking in before the data gets marshalled which we can't currently do but it shouldn't be too hard to make it so that we can have register read and write functions supplied in the regmap config. Also due to the way the driver uses the chip it is only powered up when the corresponding file in devfs(e.g. /dev/radio0) is opened at least by one user which means that unless there is a user who opened the file all the SET/GET_PROPERTY commands sent to it will be lost. The codec driver for that chip does not have any say in the power management policy(while all the audio configuration is done via properties) if the chip is not powered up the driver has to cache the configuration values it has so that they can be applied later. This is very normal, indeed modern CODEC drivers can leave the chip powered down whenever it's not performing some function. So, since I have to implement a caching functionality in the driver, in order to avoid reinventing the wheel I opted for using 'regmap' API for this. Of course, It is possible that I misunderstood the purpose and capabilities of the 'regmap' framework, which would make my code look very silly indeed. If that is the case I'll just re-implement it using some sort of ad-hoc version of caching. No, what you're doing is totally sensible. It needs a bit of extension to the framework before you can do it though. signature.asc Description: Digital signature
Re: [PATCH v3 2/6] Add the main bulk of core driver for SI476x code
On Tue, Oct 23, 2012 at 11:44:28AM -0700, Andrey Smirnov wrote:
+ core-regmap = devm_regmap_init_si476x(core);
+ if (IS_ERR(core-regmap)) {
This really makes little sense to me, why are you doing this? Does the
device *really* layer a byte stream on top of I2C for sending messages
that look like marshalled register reads and writes?
signature.asc
Description: Digital signature
Re: [PATCH v3 6/6] Add a codec driver for SI476X MFD
On Tue, Oct 23, 2012 at 11:44:32AM -0700, Andrey Smirnov wrote: This commit add a sound codec driver for Silicon Laboratories 476x series of AM/FM radio chips. I already merged a driver for this. If there are any changes you should send incremental updates rather than a full new driver. signature.asc Description: Digital signature
Re: [PATCH 04/14] media: add V4L2 DT binding documentation
On Wed, Oct 10, 2012 at 10:40:06AM +0200, Sascha Hauer wrote: Mark, when do we get the same for aSoC? ;) Well, I'm unlikely to work on it as I don't have any systems which can boot with device tree. The big, big problem you've got doing this is lots of dynamic changes at runtime and in general complicated systems. It's trivial to describe the physical links but they don't provide anything like enough information to use things. Quite frankly I'm not sure device tree is a useful investment of time for advanced audio systems anyway, it's really not solving any problems people actually have. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/14] media: add V4L2 DT binding documentation
On Wed, Oct 10, 2012 at 11:21:15AM +0200, Sascha Hauer wrote: On Wed, Oct 10, 2012 at 05:51:27PM +0900, Mark Brown wrote: Well, I'm unlikely to work on it as I don't have any systems which can boot with device tree. If it's only that I'm sure we could spare a i.MX53 LOCO ;) Well, something with Wolfson hardware would be helpful. The big, big problem you've got doing this is lots of dynamic changes at runtime and in general complicated systems. It's trivial to describe the physical links but they don't provide anything like enough information to use things. Quite frankly I'm not sure device tree is a useful investment of time for advanced audio systems anyway, it's really not solving any problems people actually have. Right now the i.MX audmux binding is only enough to say which ports should be connected, but not which format should be used. Just today Why should that be in DT? For most things it's either fixed by the hardware or makes no odds. we had the problem where a codec has two DAIs and wanted to add the information on which port our SSI unit is connected to the devicetree. There's nothing stopping you doing that right now, the existing DT So I think it's worthwile to do, but that would be a big big task... For simple devices there's already stuff there and it's not hard to add new machine bindings, it's trying to cover the general case that's far too much effort. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] Add the main bulk of core driver for SI476x code
On Fri, Oct 05, 2012 at 06:54:58PM -0700, Andrey Smirnov wrote: + err = regulator_enable(core-supplies.va); + if (err 0) + break; + + err = regulator_enable(core-supplies.vio2); + if (err 0) + goto disable_va; + + err = regulator_enable(core-supplies.vd); + if (err 0) + goto disable_vio2; + + err = regulator_enable(core-supplies.vio1); + if (err 0) + goto disable_vd; If the sequencing is critical here you should have comments explaining what the requirement is, otherwise this looks like a prime candidate for conversion to regulator_bulk_enable() (and similarly for all the other regulator usage, it appears that all the regulators are worked with in a bulk fashion). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/6] Add a codec driver for SI476X MFD
On Fri, Oct 05, 2012 at 06:55:02PM -0700, Andrey Smirnov wrote: This commit add a sound codec driver for Silicon Laboratories 476x series of AM/FM radio chips. Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] media: add a V4L2 OF parser
On Fri, Oct 05, 2012 at 08:30:59PM +0200, Sylwester Nawrocki wrote: The deferred probing was introduced in Linux to resolve resource inter-dependencies in case of FDT based booting AFAIK. It's completely unrelated to FDT, it's a general issue. There's no sane way to use hacks like link ordering to resolve boot time dependencies - start getting things like regulators connected to I2C or SPI controllers which may also use GPIOs for some signals and may be parents for other regulators and mapping out the dependency graph becomes unreasonably complicated. Deferred probing is designed to solve this problem by working things out dynamically at runtime. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add a core driver for SI476x MFD
On Thu, Sep 13, 2012 at 03:40:11PM -0700, Andrey Smirnov wrote:
+ core = kzalloc(sizeof(*core), GFP_KERNEL);
devm_kzalloc()
+ if (!core) {
+ pr_err(si476x-core: failed to allocate \
+'struct si476x_core'\n);
+ return -ENOMEM;
+ }
Splitting error messages over multiple lines like this just makes things
hard to grep for.
+ core-supplies.vio1 = regulator_get(client-dev, vio1);
+ if (IS_ERR_OR_NULL(core-supplies.vio1)) {
+ dev_info(client-dev, No vio1 regulator found\n);
+ core-supplies.vio1 = NULL;
+ }
This and all the usages of the regulator API in the driver are broken,
the driver should treat failures to get the supplies as errors. There
are more than enough ways to stub things out in the core.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] Add a codec driver for SI476X MFD
On Thu, Sep 13, 2012 at 03:40:13PM -0700, Andrey Smirnov wrote:
This commit add a sound codec driver for Silicon Laboratories 476x
series of AM/FM radio chips.
*Always* CC both maintainers and lists on patches. There's a few
problems here, though none of them terribly substantial.
select SND_SOC_UDA1380 if I2C
select SND_SOC_WL1273 if MFD_WL1273_CORE
+ select SND_SOC_SI476X if MFD_SI476X_CORE
select SND_SOC_WM1250_EV1 if I2C
Keep the Makefile and Kconfig sorted.
+struct si476x_codec {
+ struct si476x_core *core;
+};
control_data.
+static int si476x_codec_set_daudio_params(struct snd_soc_codec *codec,
+ int width, int rate)
+{
Just inline this into the one user.
+ int err;
+ u16 digital_io_output_format = \
+ snd_soc_read(codec,
+ SI476X_DIGITAL_IO_OUTPUT_FORMAT);
Throughout the driver you're randomly using \ for no visible reason -
don't do that.
+ if ((rate 32000) || (rate 48000)) {
+ dev_dbg(codec-dev, Rate: %d is not supported\n, rate);
dev_err.
+ digital_io_output_format = SI476X_DIGITAL_IO_OUTPUT_WIDTH_MASK;
+ digital_io_output_format |= (width 11) | (width 8);
+
+ return snd_soc_write(codec, SI476X_DIGITAL_IO_OUTPUT_FORMAT,
+ digital_io_output_format);
snd_soc_update_bits().
+static int si476x_codec_volume_get(struct snd_kcontrol *kcontrol,
+struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+
+ ucontrol-value.integer.value[0] =
+ snd_soc_read(codec, SI476X_AUDIO_VOLUME);
+ return 0;
+}
Why are you open coding this? Looks like a standard register...
+static int si476x_codec_digital_mute(struct snd_soc_dai *codec_dai, int mute)
+{
+ if (mute)
+ snd_soc_write(codec_dai-codec, SI476X_AUDIO_MUTE, 0x3);
+
+ return 0;
+}
This will never disable the mute once it's been activated; are you sure
this code has been tested?
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S8:
+ width = SI476X_PCM_FORMAT_S8;
+ case SNDRV_PCM_FORMAT_S16_LE:
Missing break;
+static int si476x_codec_probe(struct snd_soc_codec *codec)
+{
+ struct si476x_core **core = codec-dev-platform_data;
+ struct si476x_codec *si476x;
+
+ if (!core) {
+ dev_err(codec-dev, Platform data is missing.\n);
+ return -EINVAL;
+ }
You should use dev-parent to find the parent rather than use platform
data like this.
+ si476x = kzalloc(sizeof(*si476x), GFP_KERNEL);
+ if (si476x == NULL) {
devm_kzalloc(), and this should be in the device level probe (as should
the previous check for the core). Though as the struct ought to be
empty now this'll presumably go away.
+static int __init si476x_init(void)
+{
+ return platform_driver_register(si476x_platform_driver);
+}
+module_init(si476x_init);
module_platform_driver()
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support
On Fri, Sep 21, 2012 at 01:26:43AM -0700, Olof Johansson wrote: I'll take a look at merging it tomorrow after I've dealt with smp_ops; if it looks reasonably conflict-free I'll pull it in. We need the sound dependency sorted out (or agreed upon) first though. I guess in the light of the rest of the thread it doesn't much matter for this merge window but I just pushed: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.7 which is signed so can happily be merged elsewhere. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote: The first five branches are scheduled to go through the arm-soc tree, so I'm fine with that. For the sound/for-3.7 branch, I'd like to know when to expect that hitting mainline. If it always gets in very early during the merge window, it's probably ok to put the imx/multi-platform patches into the same branch as the other ones in arm-soc and wait for the sound stuff to hit mainline first, otherwise I'd suggest we start a second next/multiplatform-2 branch for imx and send the first part early on but then wait with the second batch before sound gets in. It's usually pretty early but Takashi will be on holiday this time so I'm not sure if things might be different (he was going to send the pull request from holiday). I also didn't guarantee that it'll be stable yet, can someone please tell me what the depenency is here? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:52:15PM +0800, Shawn Guo wrote: On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote: It's usually pretty early but Takashi will be on holiday this time so I'm not sure if things might be different (he was going to send the pull request from holiday). I also didn't guarantee that it'll be stable yet, can someone please tell me what the depenency is here? We need the patch to have all imx drivers mach/* inclusion free, so that we can enable multi-platform support for imx, which is the whole point of the series. That doesn't answer the question. What is the dependency - what is it about this patch that something else depends on? Your cover letters just say you'd like to do this but don't mention dependencies at all and when I asked the question last night you said the same thing. I've not seen the rest of the series... If your for-3.7 is not stable anyway, I guess the easiest the way It probably *is* stable but I'm not enthused about people pulling unsigned tags. I might rebase, though - I'm going to finalise the tree in the next few days. to do it might be you drop the patch ASoC: mx27vis: retrieve gpio numbers from platform_data from your tree and I have it be part of the series to go via arm-soc tree as a whole. (This is the original plan that I mentioned in v1 cover letter) You just mentioned it as a preference (you said it's something you'd like to do), please if you're doing this sort of cross tree thing be explicit about what the inter-tree relationships are. If things need to go in via the same tree say so explicitly (and ideally say way this is). The main reason I applied it straight away was that Javier mentioned that it was a bug fix and it's near the merge window and these random ARM cleanup serieses never seem to go in quickly. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2012-discuss] [MINI SUMMIT] media mini-summit at KS/2012
On Wed, Aug 01, 2012 at 04:17:07PM -0300, Mauro Carvalho Chehab wrote: The names that came up during our discussions for those panels are: Rob Clark rob.cl...@linaro.org (HDMI CEC, ALSA, ARM) Takashi Iwai ti...@suse.de (ALSA) Catalin Marinas catalin.mari...@arm.com (ARM) Mark Brown broo...@opensource.wolfsonmicro.com (DT) Not sure if they all will be there or if they'll have some time to discuss those things with us. We hope they will ;) I'll be around, though potentially otherwise engaged (depending on when tis is schedled for). I'm also pretty familiar with ARM and ALSA. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] media DT bindings
On Wed, Jul 18, 2012 at 07:00:15PM +0200, Sylwester Nawrocki wrote: One possible solution would be to have host/bridge drivers to register a clkdev entry for I2C client device, so it can acquire the clock through just clk_get(). We would have to ensure the clock is not tried to be accessed before it is registered by a bridge. This would require to add clock handling code to all sensor/encoder subdev drivers though.. If this is done well it could just be a simple callback, and we could probably arrange for the framework to just implement the default behaviour if the driver doesn't do anything explicit. Of couse this is one of those things where we really need the generic clock API to be generally available... -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2012-discuss] Device-tree cross-subsystem binding workshop [was Media system Summit]
On Thu, Jul 12, 2012 at 06:20:27PM -0700, Olof Johansson wrote: On Thu, Jul 12, 2012 at 12:03 PM, Hans Verkuil hverk...@xs4all.nl wrote: I'm not so sure: I think that most decisions that need to be made are quite subsystem specific. Trying to figure out how to implement DT for multiple subsystems in one workshop seems unlikely to succeed, simply because of lack of time. I also don't think there is much overlap between subsystems in this respect, so while the DT implementation for one subsystem is discussed, the representatives of other subsystems are twiddling their thumbs. I'm seeing an awful lot of common patterns in the way the hardware is structured here, we shouldn't be redoing the handling of all these patterns. Obviously there will be subsystem specific stuff too but there's a lot of repetitive boiler plate in the high level hookup. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2012-discuss] Device-tree cross-subsystem binding workshop [was Media system Summit]
On Thu, Jul 12, 2012 at 09:55:07PM -0500, Rob Herring wrote: Perhaps part of the issue is we're trying to put too much into DT? I think this is definitely part of it, at times it feels like people have a shiny new toy so we're jumping into device tree really quickly for things that perhaps don't need to be pulled out of the code. Another part of it (and the big problem with translating platform data directly) is that platform data is easily fungible whereas device tree should in theory be an ABI and hence needs much closer scrutiny. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2012-discuss] Media system Summit
On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: I'd like to add a Common device tree bindings for media devices topic to the agenda for consideration. It'd be nice to get this to join up with ASoC... -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Support for 'Coda' video codec IP.
On Wed, Jun 20, 2012 at 11:01:26AM +0200, Sascha Hauer wrote: On Wed, Jun 20, 2012 at 09:51:32AM +0200, javier Martin wrote: Our platfrom, 'visstrim_m10' doesn't currently support devicetree yet, so it would be highly difficult for us to test it at the moment. Couldn't you add devicetree support in a later patch? I try to motivate people moving to devicetree. At some point I'd like to get rid of the platform based boards in the tree. Adding new platform seems like delaying this instead of working towards a platform board free Kernel. Any other opinions on this? The approach a lot of platforms have been taking is that it's OK to keep on maintaining existing boards using board files (especially for trivial things like adding new devices). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Support for 'Coda' video codec IP.
On Wed, Jun 20, 2012 at 09:09:43PM +0800, Shawn Guo wrote: On Wed, Jun 20, 2012 at 11:00:15AM +0100, Mark Brown wrote: The approach a lot of platforms have been taking is that it's OK to keep on maintaining existing boards using board files (especially for trivial things like adding new devices). I think that's the approach being taken during the transition to device tree. But it's definitely a desirable thing to remove those board files with device tree support at some point, because not having non-DT users will ease platform maintenance and new feature adoption a lot easier, for example linear irqdomain. Moving to irqdomain without DT is really very easy, you just need to select a legacy mapping if a base is provided and otherwise all the code is identical - it just comes down to a field in platform data and an if statement. signature.asc Description: Digital signature
Re: [RFC] Support for 'Coda' video codec IP.
On Wed, Jun 20, 2012 at 09:56:37PM +0800, Shawn Guo wrote: On Wed, Jun 20, 2012 at 02:31:48PM +0100, Mark Brown wrote: Moving to irqdomain without DT is really very easy, you just need to select a legacy mapping if a base is provided and otherwise all the code is identical - it just comes down to a field in platform data and an if statement. Yeah, but I guess what I'm saying is *linear* irqdomain. Sure, but like I say the only code change required for keeping platform data working is the three lines or so required to change to a legacy mapping if you've got an irq_base. All my development systems currently use linear domains for several of the IRQ domains on a totally non-DT system. signature.asc Description: Digital signature
[PATCH] [media] Convert I2C drivers to dev_pm_ops
The legacy I2C PM functions have been deprecated and warning on boot
for over a year, convert the drivers still using them to dev_pm_ops.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/media/video/msp3400-driver.c | 15 +++
drivers/media/video/tuner-core.c | 15 +++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/msp3400-driver.c
b/drivers/media/video/msp3400-driver.c
index 82ce507..aeb22be 100644
--- a/drivers/media/video/msp3400-driver.c
+++ b/drivers/media/video/msp3400-driver.c
@@ -597,19 +597,23 @@ static int msp_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int msp_suspend(struct i2c_client *client, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int msp_suspend(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, suspend\n);
msp_reset(client);
return 0;
}
-static int msp_resume(struct i2c_client *client)
+static int msp_resume(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, resume\n);
msp_wake_thread(client);
return 0;
}
+#endif
/* --- */
@@ -863,6 +867,10 @@ static int msp_remove(struct i2c_client *client)
/* --- */
+static const struct dev_pm_ops msp3400_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(msp_suspend, msp_resume)
+};
+
static const struct i2c_device_id msp_id[] = {
{ msp3400, 0 },
{ }
@@ -873,11 +881,10 @@ static struct i2c_driver msp_driver = {
.driver = {
.owner = THIS_MODULE,
.name = msp3400,
+ .pm = msp3400_pm_ops,
},
.probe = msp_probe,
.remove = msp_remove,
- .suspend= msp_suspend,
- .resume = msp_resume,
.id_table = msp_id,
};
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index a5c6397..3e050e1 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1241,8 +1241,10 @@ static int tuner_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int tuner_suspend(struct i2c_client *c, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int tuner_suspend(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -1254,8 +1256,9 @@ static int tuner_suspend(struct i2c_client *c,
pm_message_t state)
return 0;
}
-static int tuner_resume(struct i2c_client *c)
+static int tuner_resume(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
tuner_dbg(resume\n);
@@ -1266,6 +1269,7 @@ static int tuner_resume(struct i2c_client *c)
return 0;
}
+#endif
static int tuner_command(struct i2c_client *client, unsigned cmd, void *arg)
{
@@ -1310,6 +1314,10 @@ static const struct v4l2_subdev_ops tuner_ops = {
* I2C structs and module init functions
*/
+static const struct dev_pm_ops tuner_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tuner_suspend, tuner_resume)
+};
+
static const struct i2c_device_id tuner_id[] = {
{ tuner, }, /* autodetect */
{ }
@@ -1320,12 +1328,11 @@ static struct i2c_driver tuner_driver = {
.driver = {
.owner = THIS_MODULE,
.name = tuner,
+ .pm = tuner_pm_ops,
},
.probe = tuner_probe,
.remove = tuner_remove,
.command= tuner_command,
- .suspend= tuner_suspend,
- .resume = tuner_resume,
.id_table = tuner_id,
};
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] Convert I2C drivers to dev_pm_ops
The legacy I2C PM functions have been deprecated and warning on boot
for over a year, convert the drivers still using them to dev_pm_ops.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/media/video/msp3400-driver.c | 15 +++
drivers/media/video/tuner-core.c | 15 +++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/msp3400-driver.c
b/drivers/media/video/msp3400-driver.c
index 82ce507..aeb22be 100644
--- a/drivers/media/video/msp3400-driver.c
+++ b/drivers/media/video/msp3400-driver.c
@@ -597,19 +597,23 @@ static int msp_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int msp_suspend(struct i2c_client *client, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int msp_suspend(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, suspend\n);
msp_reset(client);
return 0;
}
-static int msp_resume(struct i2c_client *client)
+static int msp_resume(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, resume\n);
msp_wake_thread(client);
return 0;
}
+#endif
/* --- */
@@ -863,6 +867,10 @@ static int msp_remove(struct i2c_client *client)
/* --- */
+static const struct dev_pm_ops msp3400_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(msp_suspend, msp_resume)
+};
+
static const struct i2c_device_id msp_id[] = {
{ msp3400, 0 },
{ }
@@ -873,11 +881,10 @@ static struct i2c_driver msp_driver = {
.driver = {
.owner = THIS_MODULE,
.name = msp3400,
+ .pm = msp3400_pm_ops,
},
.probe = msp_probe,
.remove = msp_remove,
- .suspend= msp_suspend,
- .resume = msp_resume,
.id_table = msp_id,
};
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index a5c6397..3e050e1 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1241,8 +1241,10 @@ static int tuner_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int tuner_suspend(struct i2c_client *c, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int tuner_suspend(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -1254,8 +1256,9 @@ static int tuner_suspend(struct i2c_client *c,
pm_message_t state)
return 0;
}
-static int tuner_resume(struct i2c_client *c)
+static int tuner_resume(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
tuner_dbg(resume\n);
@@ -1266,6 +1269,7 @@ static int tuner_resume(struct i2c_client *c)
return 0;
}
+#endif
static int tuner_command(struct i2c_client *client, unsigned cmd, void *arg)
{
@@ -1310,6 +1314,10 @@ static const struct v4l2_subdev_ops tuner_ops = {
* I2C structs and module init functions
*/
+static const struct dev_pm_ops tuner_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tuner_suspend, tuner_resume)
+};
+
static const struct i2c_device_id tuner_id[] = {
{ tuner, }, /* autodetect */
{ }
@@ -1320,12 +1328,11 @@ static struct i2c_driver tuner_driver = {
.driver = {
.owner = THIS_MODULE,
.name = tuner,
+ .pm = tuner_pm_ops,
},
.probe = tuner_probe,
.remove = tuner_remove,
.command= tuner_command,
- .suspend= tuner_suspend,
- .resume = tuner_resume,
.id_table = tuner_id,
};
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] Convert I2C drivers to dev_pm_ops
The legacy I2C PM functions have been deprecated and warning on boot
for over a year, convert the drivers still using them to dev_pm_ops.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/media/video/msp3400-driver.c | 13 +
drivers/media/video/tuner-core.c | 13 +
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/msp3400-driver.c
b/drivers/media/video/msp3400-driver.c
index 82ce507..0a55317 100644
--- a/drivers/media/video/msp3400-driver.c
+++ b/drivers/media/video/msp3400-driver.c
@@ -597,15 +597,17 @@ static int msp_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int msp_suspend(struct i2c_client *client, pm_message_t state)
+static int msp_suspend(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, suspend\n);
msp_reset(client);
return 0;
}
-static int msp_resume(struct i2c_client *client)
+static int msp_resume(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, resume\n);
msp_wake_thread(client);
return 0;
@@ -863,6 +865,10 @@ static int msp_remove(struct i2c_client *client)
/* --- */
+static const struct dev_pm_ops msp3400_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(msp3400_suspend, msp3400_resume)
+};
+
static const struct i2c_device_id msp_id[] = {
{ msp3400, 0 },
{ }
@@ -873,11 +879,10 @@ static struct i2c_driver msp_driver = {
.driver = {
.owner = THIS_MODULE,
.name = msp3400,
+ .pm = msp3400_pm_ops,
},
.probe = msp_probe,
.remove = msp_remove,
- .suspend= msp_suspend,
- .resume = msp_resume,
.id_table = msp_id,
};
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index a5c6397..d3de74f 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1241,8 +1241,9 @@ static int tuner_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int tuner_suspend(struct i2c_client *c, pm_message_t state)
+static int tuner_suspend(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -1254,8 +1255,9 @@ static int tuner_suspend(struct i2c_client *c,
pm_message_t state)
return 0;
}
-static int tuner_resume(struct i2c_client *c)
+static int tuner_resume(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
tuner_dbg(resume\n);
@@ -1310,6 +1312,10 @@ static const struct v4l2_subdev_ops tuner_ops = {
* I2C structs and module init functions
*/
+static const struct dev_pm_ops tuner_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tuner_suspend, tuner_resume)
+};
+
static const struct i2c_device_id tuner_id[] = {
{ tuner, }, /* autodetect */
{ }
@@ -1320,12 +1326,11 @@ static struct i2c_driver tuner_driver = {
.driver = {
.owner = THIS_MODULE,
.name = tuner,
+ .pm = tuner_pm_ops,
},
.probe = tuner_probe,
.remove = tuner_remove,
.command= tuner_command,
- .suspend= tuner_suspend,
- .resume = tuner_resume,
.id_table = tuner_id,
};
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] Convert I2C drivers to dev_pm_ops
On Thu, Mar 22, 2012 at 08:34:53PM +, Mark Brown wrote: + .pm = msp3400_pm_ops, Gah, missing s - will resend tomorrow. signature.asc Description: Digital signature
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: On 06.12.2011 15:19, Mark Brown wrote: Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely in line with reality. Did you notice that we're talking about a very particular application? *sigh* VoIP really is totally off-topic. The B in DVB stands for broadcast. There's only one direction in which MPEG payload is to be sent (using RTP for example). You can't just re-encode the data on the fly without loss of information. This is pretty much exactly the case for VoIP some of the time (though obviously bidirectional use cases are rather common there's things like conferencing). I would really expect similar considerations to apply for video content as they certainly do in videoconferencing VoIP applications - if the application knows about the network it can tailor what it's doing to that network. For example, if it is using a network with a guaranteed bandwidth it can assume that bandwidth. If it knows something about the structure of the network it may be able to arrange to work around choke points. Depending on the situation even something lossy may be the answer - if it's the difference between working at all and not working then the cost may be worth it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Wed, Dec 07, 2011 at 03:01:18PM +0100, Andreas Oberritter wrote: Once and for all: We have *not* discussed a generic video streaming application. It's only, I repeat, only about accessing a remote DVB API tuner *as if it was local*. No data received from a satellite, cable or terrestrial DVB network shall be modified by this application! Virtually *every* user of it will use it in a LAN. It can't be so hard to understand. You're talking about a purely software defined thing that goes in the kernel - it pretty much has to be able to scale to other applications even if some of the implementation is left for later. Once things like this get included in the kernel they become part of the ABI and having multiple specific things ends up being a recipie for confusion as users have to work out which of the options is most appropriate for their application. Really this feels like the pattern we've got with audio where we restrict the drivers to driving hardware and there's a userspace which wraps that and can also dispatch to a userspace implementation without applications worrying about it. Perhaps given the current entirely in kernel implementation a simple loopback in the style of FUSE which bounces the kernel APIs up to userspace for virtual drivers would make sense. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: On 05.12.2011 21:55, Alan Cox wrote: The USB case is quite different because your latency is very tightly bounded, your dead device state is rigidly defined, and your loss of device is accurately and immediately signalled. Quite different. How can usbip work if networking and usb are so different and what's so different between vtunerc and usbip, that made it possible to put usbip into drivers/staging? USB-IP is a hack that will only work well on a tightly bounded set of networks - if you run it over a lightly loaded local network it can work adequately. This starts to break down as you vary the network configuration. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: On 05.12.2011 18:39, Mauro Carvalho Chehab wrote: When you put someone via the network, issues like latency, package drops, IP congestion, QoS issues, cryptography, tunneling, etc should be taken into account by the application, in order to properly address the network issues. Are you serious? Lower networking layers should be transparent to the upper layers. You don't implement VPN or say TCP in all of your applications, do you? These are just some more made-up arguments which don't have anything to do with the use cases I explained earlier. For real time applications it does make a big difference - decisions taken at the application level can greatly impact end application performance. For example with VoIP on a LAN you can get great audio quality by using very little compression at the expense of high bandwidth and you can probably use a very small jitter buffer. Try doing that over a longer distance or more congested network which drops packets and it becomes useful to use a more commpressed encoding for your data which may have better features for handling packet loss, or to increase your jitter buffer to cope with the less reliable transmit times. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote: On 06.12.2011 12:21, Mark Brown wrote: On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: Are you serious? Lower networking layers should be transparent to the upper layers. You don't implement VPN or say TCP in all of your applications, do you? These are just some more made-up arguments which don't have anything to do with the use cases I explained earlier. For real time applications it does make a big difference - decisions taken at the application level can greatly impact end application performance. For example with VoIP on a LAN you can get great audio Can you please explain how this relates to the topic we're discussing? Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely in line with reality. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANN] Meeting minutes of the Cambourne meeting
On Tue, Aug 30, 2011 at 12:20:09AM +0200, Guennadi Liakhovetski wrote: On Mon, 29 Aug 2011, Laurent Pinchart wrote: My idea was to let the kernel register all devices based on the DT or board code. When the V4L2 host/bridge driver gets registered, it will then call a V4L2 core function with a list of subdevs it needs. The V4L2 core would store that information and react to bus notifier events to notify the V4L2 host/bridge driver when all subdevs are present. At that point the host/bridge driver will get hold of all the subdevs and call (probably through the V4L2 core) their .registered operation. That's where the subdevs will get access to their clock using clk_get(). Correct me, if I'm wrong, but this seems to be the case of sensor (and other i2c-client) drivers having to succeed their probe() methods without being able to actually access the hardware? The events should only be generated after the probe() has succeeded so if the driver talks to the hardware then it can fail probe() if need be. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANN] Meeting minutes of the Cambourne meeting
On Tue, Aug 30, 2011 at 05:42:55PM +0200, Laurent Pinchart wrote: A dependency system is tempting but will be very complex to implement properly, especially when faced with cyclic dependencies. For instance the OMAP3 ISP driver requires the camera sensor device to be present to proceed, and the camera sensor requires a clock provided by the OMAP3 ISP. To solve this we need to probe the OMAP3 ISP first, have it register its clock devices, and then wait until all sensors become available. With composite devices like that where the borad has sufficient interesting stuff on it representing the board itself as a device (this is what ASoC does). A probe deferral system is probably simpler, but it will have its share of problems as well. In the above example, if the sensor is probed first, the driver can return -EAGAIN in the probe() method as the clock isn't available yet (I'm not sure how to differentiate between not available yet and not present in the system though). However, if the OMAP3 ISP is probed first, returning -EAGAIN in its probe() method won't really help, as we need to register the clock before waiting for the sensor. Having a device for the camera subsystem as a whole breaks this loop as the probe of that device triggers the overall system probe. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANN] Meeting minutes of the Cambourne meeting
On Tue, Aug 30, 2011 at 10:12:30PM +0200, Laurent Pinchart wrote: Would such a device be included in the DT ? My understanding is that the DT should only describe the hardware. For ASoC they will be, the view is that the schematic for the board is sufficiently interesting to count as hardware. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3 v5] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
On Tue, May 17, 2011 at 10:06:23PM +0200, Sylwester Nawrocki wrote: As we have I2C, SPI and platform device v4l subdevs ideally those buses should support Runtime PM. They all do so. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Regulator state after regulator_get
On Thu, Apr 28, 2011 at 09:01:03AM +, kalle.jokini...@nokia.com wrote: If the device driver using the regulator does not enable and disable the regulator after regulator_get, the regulator is left in the state that it was after bootloader. In case of N900 this is a problem as the regulator is left on to leak current. Of course there is the option to let regulator FW disable all unused regulators, but this will break the N900 functionality, as the regulator handling is not in place for many drivers. You should use regulator_full_constraints() if your board has a fully described set of regulators. This will cause the framework to power down any regulators which aren't in use after init has completed. If you have some regulators with no consumers or missing consumers you need to mark them as always_on in their constraints. So reset the regulator on first regulator_get call to make sure that any regulator that has users is not left active needlessly. This would cause lots of breakage, it would mean that all regulators that aren't always_on would get bounced off at least once during startup - that's not going to be great for things like the backlight. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Regulator state after regulator_get
On Thu, Apr 28, 2011 at 09:44:10AM +, kalle.jokini...@nokia.com wrote: Another alternative to the first option you proposed could be to add a flags field to regulator_consumer_supply, and use a flag to recognise regulators which need to be disabled during initialisation. The flag could be set by using a new macro e.g. REGULATOR_SUPPLY_NASTY() when defining the regulator. This sounds like a good option actually. Liam, Mark, any opinions? I'm not sure what supply_nasty would mean? This also doesn't seem like something that we can set up per supply - it's going to affect the whole regulator state, it's not something that only affects a single supply. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Regulator state after regulator_get
On Thu, Apr 28, 2011 at 01:27:46PM +0300, Sakari Ailus wrote: Mark Brown wrote: I'm not sure what supply_nasty would mean? This also doesn't seem like something that we can set up per supply - it's going to affect the whole regulator state, it's not something that only affects a single supply. supply_nasty() would be used to define a regulator which is enabled by the boot loader when it shouldn't be, which is the actual problem. That's *really* not a clear name. How should this regulator be turned off in the boot by the kernel? Have you read my previous mail where I described the existing support for doing this when we have a full set of information on the regualtors in the systems? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
