On Tue, Dec 11, 2018 at 03:15:35PM -0700, Nathan Chancellor wrote:
> On Tue, Dec 11, 2018 at 10:06:20PM +0000, Mark Brown wrote:
> > in ddbridge-ci.c and some other media files. This is because
> > ddbridge.h includes asm/irq.h but that does not directly include headers
>
On Tue, Dec 11, 2018 at 07:38:33PM +, Build bot for Mark Brown wrote:
Today's -next fails to build an arm allmodconfig due to:
> arm-allmodconfig
> ../arch/arm/include/asm/irq.h:35:50: error: unknown type name 'cpumask_t'
> ../arch/arm/include/asm/irq.h:36:9:
one decisions based on the coherent_dma_mask.
Signed-off-by: Christoph Hellwig
Signed-off-by: Mark Brown
---
drivers/spi/spi-pic32-sqi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-pic32-sqi.c b/drivers/spi/spi-pic32-sqi.c
index 62e6bf1f50b1..d7e4e18ec3df
one decisions based on the coherent_dma_mask.
Signed-off-by: Christoph Hellwig
Reviewed-by: Takashi Iwai
Signed-off-by: Mark Brown
---
sound/soc/intel/common/sst-firmware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/common/sst-firmware.c
b/sound/soc/int
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
signature.asc
De
.non_legacy_dai_naming = 1
Signed-off-by: Kuninori Morimoto
Tested-by: Tim Harvey
Acked-by: Tim Harvey
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Mark Brown
---
drivers/media/i2c/tda1997x.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drive
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
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 th
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
If there's no
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
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
> &
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
quot;timeout" to "__timeout" & "pollret" to "__ret" to
avoid namespace collision. Tidy up macro arguments with parentheses.
Signed-off-by: Ramesh Shanmugasundaram
Signed-off-by: Mark Brown
---
include/linux/regmap.h | 17 +
1 file changed, 9 in
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
signature.asc
De
e deprecated and removed later once when all callers
> are converted.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
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.
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
signature.asc
Description: PGP signature
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, unti
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
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
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...
>
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
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
>
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
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
signature.asc
Description: PGP signature
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
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 t
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
signature.asc
Description: PGP signature
Acked-by: Mark Brown
signature.asc
Description: Digital signature
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
signature.asc
Description
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
>
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 tw
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
signature.asc
Description: Digital signature
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...
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
Descriptio
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. B
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
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. Va
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.
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 Re
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 optio
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
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.
> &
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-
From: Mark Brown
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
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
Descr
From: Mark Brown
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
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
signature.asc
Description: Digital signature
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
signature.asc
Description: Digital signature
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
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
signature.asc
Description
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
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
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
> poi
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 t
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
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
>
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 kern
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 th
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 gen
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 ma
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 th
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 gen
On Wed, Apr 10, 2013 at 09:53:20PM +0800, Barry Song wrote:
> 2013/4/10 Guennadi Liakhovetski :
> >> 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 came
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
Descripti
On Mon, Feb 18, 2013 at 07:59:34PM -0800, Andrey Smirnov wrote:
> From: Andrey Smirnov
>
> 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 sub
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 escreveu:
Guys, please delete irrelevant context from mails. I just TL;DRed this
so if there's anything you're expecting fro
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 lik
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
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.
sig
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
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 genera
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
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
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 orde
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.
> se
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;
> +
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 res
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
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
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 (HDMI CEC, ALSA, ARM)
> Takashi Iwai (ALSA)
> Catalin Marinas (ARM)
> Mark Brown (DT)
> Not sur
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
> accesse
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'
On Thu, Jul 12, 2012 at 06:20:27PM -0700, Olof Johansson wrote:
> On Thu, Jul 12, 2012 at 12:03 PM, Hans Verkuil 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 o
On Thu, Jul 12, 2012 at 09:48:23AM -0700, Olof Johansson wrote:
> There's a handful of various subsystems that have similar topics,
> maybe slice it the other way and do a device-tree/ACPI breakout that
> cuts across the various areas instead?
> Communication really needs to be two-way: Crafting
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-medi
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
> > i
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
&g
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 device
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
---
drivers/media/video/msp3400-driver.c | 15 +++
drivers/media/video/tuner-core.c | 15 +++
2
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
---
drivers/media/video/msp3400-driver.c | 15 +++
drivers/media/video/tuner-core.c | 15 +++
2
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
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
---
drivers/media/video/msp3400-driver.c | 13 +
drivers/media/video/tuner-core.c | 13 +
2 files
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
> terrestria
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 i
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
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
>
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 signa
On Tue, Aug 30, 2011 at 10:37:21PM +0200, Laurent Pinchart wrote:
> On Tuesday 30 August 2011 22:35:59 Grant Likely wrote:
> > Yes. Aggregate devices are sufficiently complex that there is a strong
> > argument for using a node to describe one.
> Is there any document or sample implementation ?
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 hardwar
1 - 100 of 149 matches
Mail list logo
