2009-03-18 21:10:04 +00:00
|
|
|
|
|
|
|
/*
|
2009-03-19 22:00:35 +00:00
|
|
|
* Hauppauge HD PVR USB driver
|
2009-03-18 21:10:04 +00:00
|
|
|
*
|
|
|
|
* Copyright (C) 2008 Janne Grunau (j@jannau.net)
|
|
|
|
*
|
2010-12-29 01:46:13 +00:00
|
|
|
* IR device registration code is
|
|
|
|
* Copyright (C) 2010 Andy Walls <awalls@md.metrocast.net>
|
|
|
|
*
|
2009-03-18 21:10:04 +00:00
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
|
|
|
|
|
2009-03-18 21:10:04 +00:00
|
|
|
#include <linux/i2c.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2011-08-01 19:26:38 +00:00
|
|
|
#include <linux/export.h>
|
2009-03-18 21:10:04 +00:00
|
|
|
|
|
|
|
#include "hdpvr.h"
|
|
|
|
|
|
|
|
#define CTRL_READ_REQUEST 0xb8
|
|
|
|
#define CTRL_WRITE_REQUEST 0x38
|
|
|
|
|
|
|
|
#define REQTYPE_I2C_READ 0xb1
|
|
|
|
#define REQTYPE_I2C_WRITE 0xb0
|
|
|
|
#define REQTYPE_I2C_WRITE_STATT 0xd0
|
|
|
|
|
2010-12-29 01:46:13 +00:00
|
|
|
#define Z8F0811_IR_TX_I2C_ADDR 0x70
|
|
|
|
#define Z8F0811_IR_RX_I2C_ADDR 0x71
|
|
|
|
|
|
|
|
|
2011-01-19 21:10:14 +00:00
|
|
|
struct i2c_client *hdpvr_register_ir_tx_i2c(struct hdpvr_device *dev)
|
|
|
|
{
|
|
|
|
struct IR_i2c_init_data *init_data = &dev->ir_i2c_init_data;
|
|
|
|
struct i2c_board_info hdpvr_ir_tx_i2c_board_info = {
|
|
|
|
I2C_BOARD_INFO("ir_tx_z8f0811_hdpvr", Z8F0811_IR_TX_I2C_ADDR),
|
|
|
|
};
|
|
|
|
|
|
|
|
init_data->name = "HD-PVR";
|
|
|
|
hdpvr_ir_tx_i2c_board_info.platform_data = init_data;
|
2010-12-29 01:46:13 +00:00
|
|
|
|
2011-01-19 21:10:14 +00:00
|
|
|
return i2c_new_device(&dev->i2c_adapter, &hdpvr_ir_tx_i2c_board_info);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct i2c_client *hdpvr_register_ir_rx_i2c(struct hdpvr_device *dev)
|
2010-12-29 01:46:13 +00:00
|
|
|
{
|
|
|
|
struct IR_i2c_init_data *init_data = &dev->ir_i2c_init_data;
|
2011-01-19 21:10:14 +00:00
|
|
|
struct i2c_board_info hdpvr_ir_rx_i2c_board_info = {
|
|
|
|
I2C_BOARD_INFO("ir_rx_z8f0811_hdpvr", Z8F0811_IR_RX_I2C_ADDR),
|
|
|
|
};
|
2010-12-29 01:46:13 +00:00
|
|
|
|
|
|
|
/* Our default information for ir-kbd-i2c.c to use */
|
2011-01-24 15:18:48 +00:00
|
|
|
init_data->ir_codes = RC_MAP_HAUPPAUGE;
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
|
|
|
|
init_data->type = RC_TYPE_RC5;
|
2011-01-19 21:10:14 +00:00
|
|
|
init_data->name = "HD-PVR";
|
2011-03-04 20:31:11 +00:00
|
|
|
init_data->polling_interval = 405; /* ms, duplicated from Windows */
|
2011-01-19 21:10:14 +00:00
|
|
|
hdpvr_ir_rx_i2c_board_info.platform_data = init_data;
|
2010-12-29 01:46:13 +00:00
|
|
|
|
2011-01-19 21:10:14 +00:00
|
|
|
return i2c_new_device(&dev->i2c_adapter, &hdpvr_ir_rx_i2c_board_info);
|
2010-12-29 01:46:13 +00:00
|
|
|
}
|
|
|
|
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
static int hdpvr_i2c_read(struct hdpvr_device *dev, int bus,
|
2011-03-02 16:23:52 +00:00
|
|
|
unsigned char addr, char *wdata, int wlen,
|
|
|
|
char *data, int len)
|
2009-03-18 21:10:04 +00:00
|
|
|
{
|
|
|
|
int ret;
|
2011-01-14 19:40:32 +00:00
|
|
|
|
2011-03-02 16:23:52 +00:00
|
|
|
if ((len > sizeof(dev->i2c_buf)) || (wlen > sizeof(dev->i2c_buf)))
|
2011-01-14 19:40:32 +00:00
|
|
|
return -EINVAL;
|
2009-03-18 21:10:04 +00:00
|
|
|
|
2011-03-02 16:23:52 +00:00
|
|
|
if (wlen) {
|
|
|
|
memcpy(&dev->i2c_buf, wdata, wlen);
|
|
|
|
ret = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
|
|
|
|
REQTYPE_I2C_WRITE, CTRL_WRITE_REQUEST,
|
|
|
|
(bus << 8) | addr, 0, &dev->i2c_buf,
|
|
|
|
wlen, 1000);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
|
2009-03-18 21:10:04 +00:00
|
|
|
REQTYPE_I2C_READ, CTRL_READ_REQUEST,
|
2011-01-14 19:40:32 +00:00
|
|
|
(bus << 8) | addr, 0, &dev->i2c_buf, len, 1000);
|
2009-03-18 21:10:04 +00:00
|
|
|
|
|
|
|
if (ret == len) {
|
2011-01-14 19:40:32 +00:00
|
|
|
memcpy(data, &dev->i2c_buf, len);
|
2009-03-18 21:10:04 +00:00
|
|
|
ret = 0;
|
|
|
|
} else if (ret >= 0)
|
|
|
|
ret = -EIO;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
static int hdpvr_i2c_write(struct hdpvr_device *dev, int bus,
|
|
|
|
unsigned char addr, char *data, int len)
|
2009-03-18 21:10:04 +00:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2011-01-14 19:40:32 +00:00
|
|
|
if (len > sizeof(dev->i2c_buf))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
memcpy(&dev->i2c_buf, data, len);
|
2011-03-02 16:23:52 +00:00
|
|
|
ret = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
|
2009-03-18 21:10:04 +00:00
|
|
|
REQTYPE_I2C_WRITE, CTRL_WRITE_REQUEST,
|
2011-01-14 19:40:32 +00:00
|
|
|
(bus << 8) | addr, 0, &dev->i2c_buf, len, 1000);
|
2009-03-18 21:10:04 +00:00
|
|
|
|
|
|
|
if (ret < 0)
|
2011-01-14 19:40:32 +00:00
|
|
|
return ret;
|
2009-03-18 21:10:04 +00:00
|
|
|
|
2011-03-02 16:23:52 +00:00
|
|
|
ret = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
|
2009-03-18 21:10:04 +00:00
|
|
|
REQTYPE_I2C_WRITE_STATT, CTRL_READ_REQUEST,
|
2011-01-14 19:40:32 +00:00
|
|
|
0, 0, &dev->i2c_buf, 2, 1000);
|
2009-03-18 21:10:04 +00:00
|
|
|
|
2011-01-14 19:40:32 +00:00
|
|
|
if ((ret == 2) && (dev->i2c_buf[1] == (len - 1)))
|
2009-03-18 21:10:04 +00:00
|
|
|
ret = 0;
|
|
|
|
else if (ret >= 0)
|
|
|
|
ret = -EIO;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hdpvr_transfer(struct i2c_adapter *i2c_adapter, struct i2c_msg *msgs,
|
|
|
|
int num)
|
|
|
|
{
|
|
|
|
struct hdpvr_device *dev = i2c_get_adapdata(i2c_adapter);
|
2011-03-02 16:23:52 +00:00
|
|
|
int retval = 0, addr;
|
2009-03-18 21:10:04 +00:00
|
|
|
|
|
|
|
if (num <= 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
mutex_lock(&dev->i2c_mutex);
|
|
|
|
|
2011-03-02 16:23:52 +00:00
|
|
|
addr = msgs[0].addr << 1;
|
2009-03-18 21:10:04 +00:00
|
|
|
|
2011-03-02 16:23:52 +00:00
|
|
|
if (num == 1) {
|
|
|
|
if (msgs[0].flags & I2C_M_RD)
|
|
|
|
retval = hdpvr_i2c_read(dev, 1, addr, NULL, 0,
|
|
|
|
msgs[0].buf, msgs[0].len);
|
2009-03-18 21:10:04 +00:00
|
|
|
else
|
2011-03-02 16:23:52 +00:00
|
|
|
retval = hdpvr_i2c_write(dev, 1, addr, msgs[0].buf,
|
|
|
|
msgs[0].len);
|
|
|
|
} else if (num == 2) {
|
|
|
|
if (msgs[0].addr != msgs[1].addr) {
|
|
|
|
v4l2_warn(&dev->v4l2_dev, "refusing 2-phase i2c xfer "
|
|
|
|
"with conflicting target addresses\n");
|
|
|
|
retval = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((msgs[0].flags & I2C_M_RD) || !(msgs[1].flags & I2C_M_RD)) {
|
|
|
|
v4l2_warn(&dev->v4l2_dev, "refusing complex xfer with "
|
|
|
|
"r0=%d, r1=%d\n", msgs[0].flags & I2C_M_RD,
|
|
|
|
msgs[1].flags & I2C_M_RD);
|
|
|
|
retval = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write followed by atomic read is the only complex xfer that
|
|
|
|
* we actually support here.
|
|
|
|
*/
|
|
|
|
retval = hdpvr_i2c_read(dev, 1, addr, msgs[0].buf, msgs[0].len,
|
|
|
|
msgs[1].buf, msgs[1].len);
|
|
|
|
} else {
|
|
|
|
v4l2_warn(&dev->v4l2_dev, "refusing %d-phase i2c xfer\n", num);
|
2009-03-18 21:10:04 +00:00
|
|
|
}
|
|
|
|
|
2011-03-02 16:23:52 +00:00
|
|
|
out:
|
2009-03-18 21:10:04 +00:00
|
|
|
mutex_unlock(&dev->i2c_mutex);
|
|
|
|
|
|
|
|
return retval ? retval : num;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u32 hdpvr_functionality(struct i2c_adapter *adapter)
|
|
|
|
{
|
|
|
|
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct i2c_algorithm hdpvr_algo = {
|
|
|
|
.master_xfer = hdpvr_transfer,
|
|
|
|
.functionality = hdpvr_functionality,
|
|
|
|
};
|
|
|
|
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
static struct i2c_adapter hdpvr_i2c_adapter_template = {
|
|
|
|
.name = "Hauppage HD PVR I2C",
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.algo = &hdpvr_algo,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int hdpvr_activate_ir(struct hdpvr_device *dev)
|
|
|
|
{
|
2011-03-04 20:31:11 +00:00
|
|
|
char buffer[2];
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
|
|
|
|
mutex_lock(&dev->i2c_mutex);
|
|
|
|
|
2011-03-02 16:23:52 +00:00
|
|
|
hdpvr_i2c_read(dev, 0, 0x54, NULL, 0, buffer, 1);
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
|
|
|
|
buffer[0] = 0;
|
|
|
|
buffer[1] = 0x8;
|
|
|
|
hdpvr_i2c_write(dev, 1, 0x54, buffer, 2);
|
|
|
|
|
|
|
|
buffer[1] = 0x18;
|
|
|
|
hdpvr_i2c_write(dev, 1, 0x54, buffer, 2);
|
|
|
|
|
|
|
|
mutex_unlock(&dev->i2c_mutex);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-03-18 21:10:04 +00:00
|
|
|
int hdpvr_register_i2c_adapter(struct hdpvr_device *dev)
|
|
|
|
{
|
|
|
|
int retval = -ENOMEM;
|
|
|
|
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
hdpvr_activate_ir(dev);
|
2009-03-18 21:10:04 +00:00
|
|
|
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
memcpy(&dev->i2c_adapter, &hdpvr_i2c_adapter_template,
|
|
|
|
sizeof(struct i2c_adapter));
|
|
|
|
dev->i2c_adapter.dev.parent = &dev->udev->dev;
|
2009-03-18 21:10:04 +00:00
|
|
|
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
i2c_set_adapdata(&dev->i2c_adapter, dev);
|
2009-03-18 21:10:04 +00:00
|
|
|
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
retval = i2c_add_adapter(&dev->i2c_adapter);
|
2009-03-18 21:10:04 +00:00
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
[media] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-01-14 19:25:21 +00:00
|
|
|
|
|
|
|
#endif
|