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
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
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 da...@hardeman.nu 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
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 da...@hardeman.nu wrote:
On Thu, Nov 11, 2010 at 02:00:38PM -0200, Mauro Carvalho Chehab wrote:
A good exercise would be to port
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 da...@hardeman.nu wrote:
On Thu, Nov 11, 2010 at 02:00:38PM -0200, Mauro Carvalho
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
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
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,
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
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
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 bugs
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
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() /
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 wondering if
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
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
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)
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,
...
} cr;
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 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 jimmy.ru...@stericsson.com
Acked-by: Linus Walleij
On Fri, Nov 12, 2010 at 8:18 AM, Jimmy RUBIN jimmy.ru...@stericsson.com 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
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
needed
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_CW;
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 media-bus
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 need a
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
only
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.
Like
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
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,
Your media-bus
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
On Fri, Nov 12, 2010 at 11:46 AM, Marcus LORENTZON
marcus.xm.lorent...@stericsson.com 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
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:
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
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 best
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 appears to be the
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
-
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 saagui...@ti.com
---
drivers/media/video/isp/ispccdc.c |2 ++
1 files changed,
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
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
+++
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
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
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
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
---
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
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 +-
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 saagui...@ti.com
---
drivers/media/video/isp/isp.c | 49 ++---
1 files changed, 7 insertions(+), 42
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
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
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
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
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
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
---
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 saagui...@ti.com
---
drivers/media/video/isp/ispccdc.c | 12 +---
1
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
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
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
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
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
publishing
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 created.
52 matches
Mail list logo
