Many people are trying to use stk1160 on low memory devices.
Instead of failing if one allocation fails, we allow the driver
to continue working if fewer transfer buffers are available.
Signed-off-by: Ezequiel Garcia
---
drivers/media/usb/stk1160/stk1160-video.c | 23 +--
d
(CCed Steven Toth and Devin Heitmueller)
On Tue, Oct 23, 2012 at 7:16 PM, Andy Walls wrote:
> On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
>> This kind of memcpy() is error-prone. Its replacement with a struct
>> assignment is prefered because it's type-safe and much easier to read.
On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia wrote:
> This kind of memcpy() is error-prone. Its replacement with a struct
> assignment is prefered because it's type-safe and much easier to read.
>
> Found by coccinelle. Hand patched and reviewed.
> Tested by compilation only.
>
> A simplified
Hey Andy,
On Tue, Oct 23, 2012 at 7:08 PM, Andy Walls wrote:
> On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
>> This kind of memcpy() is error-prone. Its replacement with a struct
>> assignment is prefered because it's type-safe and much easier to read.
>
> This one is a code maintena
On Tue, 2012-10-23 at 11:44 -0700, 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.
[]
> +#ifdef DEBUG
> +#define DBG_BUFFER(device, header, buffer, bcount)
Hi Sakari,
Thanks for the patches.
On Tuesday 23 October 2012 18:42:32 Sakari Ailus wrote:
> Hi,
>
> Here's a few SMIA++ patches from me and Laurent.
>
> The set consists of cleanups, PLL calculator improvements and parallel bus
> support for the PLL calculator.
For the whole series,
Acked-by
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
> This kind of memcpy() is error-prone. Its replacement with a struct
> assignment is prefered because it's type-safe and much easier to read.
>
> Found by coccinelle. Hand patched and reviewed.
> Tested by compilation only.
>
> A simplifi
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
> This kind of memcpy() is error-prone. Its replacement with a struct
> assignment is prefered because it's type-safe and much easier to read.
>
> Found by coccinelle. Hand patched and reviewed.
> Tested by compilation only.
>
> A simplifi
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
> This kind of memcpy() is error-prone. Its replacement with a struct
> assignment is prefered because it's type-safe and much easier to read.
>
> Found by coccinelle. Hand patched and reviewed.
> Tested by compilation only.
>
> A simplifi
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
> This kind of memcpy() is error-prone. Its replacement with a struct
> assignment is prefered because it's type-safe and much easier to read.
>
> Found by coccinelle. Hand patched and reviewed.
> Tested by compilation only.
>
> A simplifi
On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
> This kind of memcpy() is error-prone. Its replacement with a struct
> assignment is prefered because it's type-safe and much easier to read.
This one is a code maintenance win. :)
See my comments at the end for the difference in assemble
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
Hi Laurent and others,
On Wed, Oct 17, 2012 at 01:55:10AM +0200, Laurent Pinchart wrote:
> On Monday 15 October 2012 10:20:00 Hans Verkuil wrote:
> > On Sat October 13 2012 22:08:29 Sylwester Nawrocki wrote:
> > > On 09/21/2012 02:26 PM, Hans Verkuil wrote:
> > > > On Tue September 18 2012 17:06:5
On 10/23/2012 12:24 PM, Mark Brown wrote:
> 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 increme
Hi Sylwester,
On Tue, Oct 16, 2012 at 11:45:59PM +0200, Sylwester Nawrocki wrote:
> On 10/14/2012 08:30 PM, Sakari Ailus wrote:
> > Currently the flash control reference states that "The V4L2 flash controls
> > are intended to provide generic access to flash controller devices. Flash
> > controlle
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date:Tue Oct 23 19:00:22 CEST 2012
git hash:74df06daf632ce2d321d01cb046004768352efc4
gcc version: i686-linux-gcc (GC
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
Hi,
Am 21.10.2012 21:13, schrieb Devin Heitmueller:
> Hi Frank,
>
> On Sun, Oct 21, 2012 at 12:52 PM, Frank Schäfer
> wrote:
>> This patch series adds support for USB bulk transfers to the em28xx driver.
> This is a welcome change that some users have been asking about for a while.
Yes, I know..
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.
Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.
A simplified version of the semantic match that finds this problem is as
follows:
Hello everyone,
This is a large patchset that replaces struct memcpy with struct assignment,
whenever possible at drivers/media.
The patches are hand applied and every change has been thoroughly reviewed.
However, to avoid regressions and angry users we'd like to have Acks
from maintainers.
A si
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
This patch adds code related to manipulation of the properties of
SI476X chips.
Signed-off-by: Andrey Smirnov
---
drivers/mfd/si476x-prop.c | 257 +
1 file changed, 257 insertions(+)
create mode 100644 drivers/mfd/si476x-prop.c
diff --git a/drivers/
This patch adds main part(out of three) of the I2C driver for the
"core" of MFD device.
Signed-off-by: Andrey Smirnov
---
drivers/mfd/si476x-i2c.c | 966 ++
1 file changed, 966 insertions(+)
create mode 100644 drivers/mfd/si476x-i2c.c
diff --git a/d
This patch adds all the functions used for exchanging commands with
the chip.
Signed-off-by: Andrey Smirnov
---
drivers/mfd/si476x-cmd.c | 1546 ++
1 file changed, 1546 insertions(+)
create mode 100644 drivers/mfd/si476x-cmd.c
diff --git a/drivers/mf
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 ot
This commit add a sound codec driver for Silicon Laboratories 476x
series of AM/FM radio chips.
Signed-off-by: Andrey Smirnov
---
sound/soc/codecs/Kconfig |4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/si476x.c | 259 +
3 files change
This is a third version of the patchset originaly posted here:
https://lkml.org/lkml/2012/9/13/590
Second version of the patch was posted here:
https://lkml.org/lkml/2012/10/5/598
To save everyone's time I'll repost the original description of it:
This patchset contains a driver for a Silicon La
This commit adds a driver that exposes all the radio related
functionality of the Si476x series of chips via the V4L2 subsystem.
Signed-off-by: Andrey Smirnov
---
drivers/media/radio/Kconfig| 17 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-si476x.c | 1549 +
Usage of TSTAMP_* macros has gone in 2010 in 730947bc (V4L/DVB: vivi:
clean up and a major overhaul) but the macros remain. Say goodbye to
them.
Cc: Hans Verkuil
Signed-off-by: Kirill Smelkov
---
drivers/media/platform/vivi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/media
The smiapp pll calculator assumed that the minimum pre-pll divisor was
perfect. That may not always be the case, so let's try the others, too.
Typically there are just a few alternatives.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp-pll.c | 131 ++
The input values for PLL configuration are mostly static. So set them when
the sensor is registered.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/media/i2c/smiapp/s
Support sensors with parallel interface.
Make smiapp_pll.flags also 8-bit so it fits nicely into two 32-bit words
with the other 8-bit fields.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp-pll.c | 19 +++
drivers/media/i2c/smiapp-pll.h | 26 +++
From: Laurent Pinchart
OP and VT limits have identical fields, create a shared structure for
both.
Signed-off-by: Laurent Pinchart
---
drivers/media/i2c/smiapp-pll.c | 54
drivers/media/i2c/smiapp-pll.h | 30 --
drivers/media
From: Laurent Pinchart
The limits are input parameters and should not be modified by the
smiapp_pll_calculate() function. Make them const.
Signed-off-by: Laurent Pinchart
---
drivers/media/i2c/smiapp-pll.c | 35 +--
drivers/media/i2c/smiapp-pll.h |3 ++-
2
Unsigned.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp-pll.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index 169f305..e92dc46 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/me
Hi,
Here's a few SMIA++ patches from me and Laurent.
The set consists of cleanups, PLL calculator improvements and parallel bus
support for the PLL calculator.
Regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "
On Tue, Oct 23, 2012 at 08:40:04AM +0200, Hans Verkuil wrote:
> On Mon October 22 2012 19:01:40 Kirill Smelkov wrote:
> > On Mon, Oct 22, 2012 at 04:16:14PM +0200, Hans Verkuil wrote:
> > > On Mon October 22 2012 15:54:44 Kirill Smelkov wrote:
> > > > I was testing my video-over-ethernet subsystem
From: Lad, Prabhakar
Warnings were generated because of the following commit changed data type for
address pointer
195bbca ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors
add __iomem annotation to fix following warnings
drivers/media/platform/davinci/vpbe_osd.c: In funct
From: Lad, Prabhakar
This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
Cc: Sekhar Nori
Cc: Sergei Shtylyov
---
Changes for v2:
1: fixed code a
Support both grayscale (Y8) and Bayer (SBGGR8, SGBRG8, SGRBG8 and
SRGGB8) formats.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/omap3isp/isppreview.c | 40 ++
1 files changed, 28 insertions(+), 12 deletions(-)
Changes since v1:
- Handle V4L2_MBUS_FMT_Y8_
Hi Hans, Laurent,
On 10/23/2012 12:22 PM, Laurent Pinchart wrote:
> On Tuesday 23 October 2012 08:46:21 Hans Verkuil wrote:
>> On Tue October 23 2012 03:03:35 Laurent Pinchart wrote:
>>> On Monday 22 October 2012 14:06:06 Hans Verkuil wrote:
On Mon October 22 2012 13:18:46 Laurent Pinchart wr
Support both grayscale (Y8) and Bayer (SBGGR8, SGBRG8, SGRBG8 and
SRGGB8) formats.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/omap3isp/isppreview.c | 37 ++---
1 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/omap3isp/i
Hi Laurent,
On Mon, Oct 22, 2012 at 5:53 PM, Laurent Pinchart
wrote:
> Hi Prabhakar,
>
> On Monday 22 October 2012 17:47:51 Prabhakar Lad wrote:
>> From: Lad, Prabhakar
>>
>> Warnings were generated because of the following commit changed data type
>> for address pointer
>>
>> 195bbca ARM: 7500/
Hi Hans,
On Tuesday 23 October 2012 08:46:21 Hans Verkuil wrote:
> On Tue October 23 2012 03:03:35 Laurent Pinchart wrote:
> > On Monday 22 October 2012 14:06:06 Hans Verkuil wrote:
> > > On Mon October 22 2012 13:18:46 Laurent Pinchart wrote:
> > > > On Monday 22 October 2012 12:53:02 Sylwester N
Hi Sergei,
On Tue, Oct 23, 2012 at 3:18 PM, Sergei Shtylyov wrote:
> Hello.
>
>
> On 22-10-2012 16:12, Prabhakar Lad wrote:
>
>> From: Lad, Prabhakar
>
>
>> This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
>> V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
>> ou
Hello.
On 22-10-2012 16:12, Prabhakar Lad wrote:
From: Lad, Prabhakar
This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
Cc: Sekhar Nori
--
See following thread for rationale:
http://www.spinics.net/lists/linux-media/msg52462.html
Tested by compilation only.
Signed-off-by: Nicolas Thery
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-co
67 matches
Mail list logo
