On Fri, 2010-11-12 at 22:54 -0500, Steven Rostedt wrote:
> Or we just don't test for define(MODULE). If either CONFIG_DVB_DIB3000MC
> or CONFIG_DVB_DIB3000MC_MODULE are defined, the code must be there,
> because, if this code is built as both a module and builtin, only the
> builtin will be create
Sorry for the late reply, but KS and LPC got in the way.
Also added kbuild to the Cc.
On Tue, 2010-10-26 at 09:37 -0200, Mauro Carvalho Chehab wrote:
> Hi Steven,
>
> Em 26-10-2010 02:15, Steven Rostedt escreveu:
> > I'm currently finishing up an automated test program (that I will be
> > publis
Something I failed to notice while testing the mceusb RLE buffer
decoding simplification patches was that we were getting an extra event
from the previously pressed key.
As was pointed out to me on irc by Maxim, this is actually due to using
ir_raw_event_store_with_filter without having set up a t
Something I failed to notice while testing the mceusb RLE buffer
decoding simplification patches was that we were getting an extra event
from the previously pressed key.
As was pointed out to me on irc by Maxim, this is actually due to using
ir_raw_event_store_with_filter without having set up a t
In strict NEC extended IR protocol, a 32-bit signal consists of address,
not address, command and not command, and checksums are performed
between these two pairs of components. Currently, our NEC protocol
decoder strictly enforces these checks, and only uses 24 bits (address,
not address and comma
Mauro,
Please pull the following changes.
The following changes since commit 5ed5d45da807a6d0d1d06bfe45b3623f97ce2797:
Steven Toth (1):
[media] saa7164: Checkpatch compliance cleanup
are available in the git repository at:
git://kernellabs.com/stoth/saa7164-dev.git master
gitweb ac
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/devices.c | 27 ---
1 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c2275d3..c9fc732 100644
--- a/arch/arm/mach-omap2/devices.c
+++
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/isp.c |8
drivers/media/video/isp/ispccp2.c |2 +-
drivers/media/video/isp/ispreg.h |3 ---
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/isp/isp.c b/drivers/media/video/isp/is
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/isp.c|2 --
drivers/media/video/isp/isp.h|1 -
drivers/media/video/isp/ispreg.h | 25 -
3 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/isp/isp.c b/drivers/media
This takes into account the input format to select the
adequate configuration for SYNC mode.
Also, change bitmask ISPCCDC_SYN_MODE_INPMOD_MASK to be
more consistent with other bitmasks.
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/ispccdc.c | 12 +---
1 files changed, 9 i
Signed-off-by: Sergio Aguirre
---
arch/arm/plat-omap/include/mach/isp_user.h | 636
drivers/media/video/isp/ispccdc.h |2 +-
drivers/media/video/isp/isph3a.h |2 +-
drivers/media/video/isp/isphist.h |2 +-
drivers/media/video/i
1. Get rid of CSI2 / CCP2 power settings, as they are controlled
in the receivers code anyways.
2. Avoid code duplication.
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/isp.c | 49 ++---
1 files changed, 7 insertions(+), 42 deletions(-)
diff
We were just supporting RAW10 formats, and we really support more
options.
Strictly speaking, CCDC needs at least to distinguish between RAW
and YUV formats for proper configuration.
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/ispccdc.c |2 ++
1 files changed, 2 insertions(+),
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/devices.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c9fc732..897ce82 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/de
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/ispccp2.c |3 +--
drivers/media/video/isp/ispreg.h | 14 --
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/isp/ispccp2.c
b/drivers/media/video/isp/ispccp2.c
index fa23394..3127a74 100
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/ispreg.h | 43 --
1 files changed, 0 insertions(+), 43 deletions(-)
diff --git a/drivers/media/video/isp/ispreg.h b/drivers/media/video/isp/ispreg.h
index 9b0d3ad..af4ddaa 100644
--- a/drivers/media/v
Hi,
First of all, these patches are based on Laurent's tree:
URL: git://linuxtv.org/pinchartl/media.git
Branch: media-0004-omap3isp (Commit d0c5b0e4: OMAP3 ISP driver)
I had these patches in my queue for some time, which:
- Add YUV support to CCDC
- Cleans up platform device MEM resources
- Rem
On Fri, Nov 12, 2010 at 12:23:56PM -0200, Mauro Carvalho Chehab wrote:
>Em 12-11-2010 12:14, David Härdeman escreveu:
>> Mauro,
>>
>> as far as I could tell, you wrote the initial support for
>> SAA7134_BOARD_ENCORE_ENLTV_FM53 in
>> drivers/media/video/saa7134/saa7134-input.c, right?
>>
>> It app
On Fri, Nov 12, 2010 at 11:28:38AM -0200, Mauro Carvalho Chehab wrote:
>There are several fields on rc_dev that drivers can benefit. Allow drivers
>to pass it as a parameter to the driver.
>
>For now, the rc_dev parameter is optional. If drivers don't pass it, create
>them internally. However, the
Hi,
I have same issue with two different af9015 cards made by 2 different
manufacturers with 2 different frontends.
When card is used with tvheadend software which constantly does idle scanning,
after 1-2 days it starts showing following dmesgs:
[342924.332308] tda18218: i2c wr failed ret:-1
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Fri Nov 12 19:00:11 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 15167:abd3aac6644e
git master:
On Fri, Nov 12, 2010 at 11:46 AM, Marcus LORENTZON
wrote:
> Hi Alex,
> Do you have any idea of how we should use KMS without being a "real" drm 3D
> device? Do you mean that we should use the KMS ioctls on for display driver?
> Or do you mean that we should expose a /dev/drmX device only capable
I think I found the firmware.
http://rapidshare.com/files/430422366/fw64.zip
--
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
Hi Manjunath,
On Friday 12 November 2010 17:00:36 Hadli, Manjunath wrote:
> On Thu, Nov 11, 2010 at 22:17:23, Laurent Pinchart wrote:
> > On Thursday 11 November 2010 16:32:02 Guennadi Liakhovetski wrote:
> > > On Wed, 10 Nov 2010, Hadli, Manjunath wrote:
> > > > Hello Guennadi,
> > > >
> > > >
Hi Alex,
Do you have any idea of how we should use KMS without being a "real" drm 3D
device? Do you mean that we should use the KMS ioctls on for display driver? Or
do you mean that we should expose a /dev/drmX device only capable of KMS and no
GEM?
What if we were to add a drm driver for 3D la
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for the MCDE, Memory-to-display controller,
> found in the ST-Ericsson ux500 products.
>
> This patch adds a display subsystem framework that can be used
> by a frame buffer device driver to control a display and MCDE.
Li
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> +
> +static struct platform_device mcde_fb_device = {
> + .name = "mcde_fb",
> + .id = -1,
> +};
Do not introduce new static devices. We are trying to remove them and
they will stop working. Why do you even need a device here if there is
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for the MCDE, Memory-to-display controller,
> found in the ST-Ericsson ux500 products.
>
> This patch adds the necessary build files for MCDE and the bus that
> all displays are connected to.
>
Can you explain why you ne
On Fri, 12 Nov 2010, Hadli, Manjunath wrote:
> On Thu, Nov 11, 2010 at 22:17:23, Laurent Pinchart wrote:
> > Hi Guennadi,
> >
> > On Thursday 11 November 2010 16:32:02 Guennadi Liakhovetski wrote:
> > > On Wed, 10 Nov 2010, Hadli, Manjunath wrote:
> > > > Hello Guennadi,
> > > >
> > > >Your
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> +
> + if (ddev->id == PRIMARY_DISPLAY_ID && rotate_main) {
> + swap(width, height);
> +#ifdef CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_ROTATE_180_DEGREES
> + rotate = FB_ROTATE_CCW;
> +#else
> + rotate = FB_ROTATE
On Thu, Nov 11, 2010 at 22:17:23, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Thursday 11 November 2010 16:32:02 Guennadi Liakhovetski wrote:
> > On Wed, 10 Nov 2010, Hadli, Manjunath wrote:
> > > Hello Guennadi,
> > >
> > >Your media-bus enumerations capture the formats quite well. I
> >
On Fri, Nov 12, 2010 at 8:18 AM, Jimmy RUBIN wrote:
> Hi Alex,
>
> Good point, we are looking at this for possible future improvements but for
> the moment we feel like
> the structure of drm does not add any simplifications for our driver. We have
> the display manager (MCDE DSS = KMS) and the
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for MCDE, Memory-to-display controller
> found in the ST-Ericsson ux500 products.
>
> This patch adds pixel processing registers found in MCDE.
>
> Signed-off-by: Jimmy Rubin
> Acked-by: Linus Walleij
The same comments
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for MCDE, Memory-to-display controller
> found in the ST-Ericsson ux500 products.
Hi Jimmy,
I haven't looked at what this device does, but I've tried to do
a review based on coding style and common practices. I hope this
On Fri, Nov 12, 2010 at 04:14:51PM +0100, Arnd Bergmann wrote:
> Some people prefer to express all this in C instead of macros:
>
> struct mcde_registers {
> enum {
> mcde_cr_dsicmd2_en = 0x0001,
> mcde_cr_dsicmd1_en = 0x0002,
> ...
> }
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for MCDE, Memory-to-display controller
> found in the ST-Ericsson ux500 products.
>
> This patch adds the configuration registers found in MCDE.
> +
> +#define MCDE_VAL2REG(__reg, __fld, __val) \
> + (((__val) << __re
03:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02)
Subsystem: LeadTek Research Inc. Device [107d:6f21]
Physical Slot: 0-1
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at fe80 (64
Hello,
I've been waiting for this list of patchwork patches to be included for
quite a while, and have now taken the liberty to clean them up as
necessary and add them to a git tree, based on the current media_tree
for_v2.6.38 branch, with exceptions as noted below:
> == mantis pat
Em 12-11-2010 12:14, David Härdeman escreveu:
> Mauro,
>
> as far as I could tell, you wrote the initial support for
> SAA7134_BOARD_ENCORE_ENLTV_FM53 in
> drivers/media/video/saa7134/saa7134-input.c, right?
>
> It appears to be the only user of ir-functions.c left in that driver and
> I'm wonder
Em 12-11-2010 12:08, David Härdeman escreveu:
> On Fri, Nov 12, 2010 at 10:56:34AM -0200, Mauro Carvalho Chehab wrote:
>> Em 12-11-2010 10:12, David Härdeman escreveu:
>>> Shouldn't platform_data be const? And you'll break the refcounting
>>> done in rc_allocate_device() and rc_free_device() /
>>>
Mauro,
as far as I could tell, you wrote the initial support for
SAA7134_BOARD_ENCORE_ENLTV_FM53 in
drivers/media/video/saa7134/saa7134-input.c, right?
It appears to be the only user of ir-functions.c left in that driver and
I'm wondering if it could be converted to use raw_decode with a patch
si
On Fri, Nov 12, 2010 at 10:56:34AM -0200, Mauro Carvalho Chehab wrote:
>Em 12-11-2010 10:12, David Härdeman escreveu:
>> Shouldn't platform_data be const? And you'll break the refcounting
>> done in rc_allocate_device() and rc_free_device() /
>> rc_unregister_device(). Not to mention the silent bu
Thank you Jason,
I had stumbled on the TBS website while looking for receiver cards, but had not
considered them because I was looking
for something supported by the mainstream kernel.
We expect a low volume for the positioner controllers (at least in the
beginning), so we want to use as much
o
Those two patches fix cx231xx-input, for I2C-based IR devices. They basically
allow caller drivers to pass a rc_dev pointer via platform_data, making it
possible to set other fields that are needed to be set by caller drivers.
Mauro Carvalho Chehab (2):
[media] ir-kbd-i2c: add rc_dev as a parame
There are several fields on rc_dev that drivers can benefit. Allow drivers
to pass it as a parameter to the driver.
For now, the rc_dev parameter is optional. If drivers don't pass it, create
them internally. However, the best is to create rc_dev inside the drivers,
in order to fill other fields,
There was a bug at cx231xx-input, where it were registering the remote
controls twice, one via ir-kbd-i2c and another directly.
Also, the patch that added rc_register_device() broke compilation for it.
This patch fixes cx231xx-input by fixing the depends on, to point to the
new symbol, and initial
Hi Alex,
Good point, we are looking at this for possible future improvements but for the
moment we feel like
the structure of drm does not add any simplifications for our driver. We have
the display manager (MCDE DSS = KMS) and the memory manager (HWMEM = GEM) that
could be migrated to drm fra
Em 12-11-2010 10:12, David Härdeman escreveu:
> On Fri, Nov 12, 2010 at 02:00:55AM -0200, Mauro Carvalho Chehab wrote:
>> Em 11-11-2010 21:40, Jarod Wilson escreveu:
>>> On Thu, Nov 11, 2010 at 3:35 PM, David Härdeman wrote:
On Thu, Nov 11, 2010 at 02:00:38PM -0200, Mauro Carvalho Chehab wrot
On Fri, Nov 12, 2010 at 02:00:55AM -0200, Mauro Carvalho Chehab wrote:
>Em 11-11-2010 21:40, Jarod Wilson escreveu:
>> On Thu, Nov 11, 2010 at 3:35 PM, David Härdeman wrote:
>>> On Thu, Nov 11, 2010 at 02:00:38PM -0200, Mauro Carvalho Chehab wrote:
A good exercise would be to port lirc-zilog
On Thu, Nov 11, 2010 at 06:40:42PM -0500, Jarod Wilson wrote:
>On Thu, Nov 11, 2010 at 3:35 PM, David Härdeman wrote:
>> On Thu, Nov 11, 2010 at 02:00:38PM -0200, Mauro Carvalho Chehab wrote:
>>>I like the idea of having an inlined function (like
>>>usb_fill_control_urb), to be sure that all manda
Hello
I am using Prof 7301 PCI card.
After converting cx88 driver to ir-core (thank you very much for your
work, David) the table rc-tbs-nec (for bundled remote) has incorrect
values.
I was comparing the results and there is a regularity (constant offset):
If i add 0x80 (128 decimal) value to ever
Dish motor does not work with this card under linux budget-ci driver, even
compiled from newest source from project page. What should I post here to help
solve that problem? Under MS Windows everything work's fine, with bt8xx card
also, this is drivers fault only. Please help me:(
--
To unsubscr
52 matches
Mail list logo
