Re: TechnoTrend TT-TVStick CT2-4400v2 no firmware load
The si2168 and si2157 firmware is loaded when you try to use the tuner for the first time, not at the time of module load or device plugin. Cheers, -olli On 8 February 2015 at 22:17, "Sebastian Süsens" wrote: > Hello, > I use kernel 3.13.0 and the media_build > "4e1a67e4a6c8ab71f416ea32059c92171407ba5d". > > I get following messages by dmesg: > > [ 1543.444128] usb 2-4: new high-speed USB device number 4 using ehci-pci > [ 1543.577069] usb 2-4: New USB device found, idVendor=0b48, idProduct=3014 > [ 1543.577088] usb 2-4: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 1543.577098] usb 2-4: Product: TechnoTrend USB-Stick > [ 1543.577106] usb 2-4: Manufacturer: CityCom GmbH > [ 1543.577114] usb 2-4: SerialNumber: 20131128 > [ 1543.764126] usb 2-4: dvb_usb_v2: found a 'TechnoTrend TVStick CT2-4400' in > warm state > [ 1543.764317] usb 2-4: dvb_usb_v2: will pass the complete MPEG2 transport > stream to the software demuxer > [ 1543.764387] DVB: registering new adapter (TechnoTrend TVStick CT2-4400) > [ 1543.765811] usb 2-4: dvb_usb_v2: MAC address: bc:ea:2b:44:02:7c > [ 1543.772724] i2c i2c-2: Added multiplexed i2c bus 3 > [ 1543.772734] si2168 2-0064: Silicon Labs Si2168 successfully attached > [ 1543.777532] si2157 3-0060: Silicon Labs Si2147/2148/2157/2158 successfully > attached > [ 1543.777579] usb 2-4: DVB: registering adapter 0 frontend 0 (Silicon Labs > Si2168)... > [ 1543.777824] Registered IR keymap rc-tt-1500 > [ 1543.778051] input: TechnoTrend TVStick CT2-4400 as > /devices/pci:00/:00:13.2/usb2/2-4/rc/rc0/input18 > [ 1543.778368] rc0: TechnoTrend TVStick CT2-4400 as > /devices/pci:00/:00:13.2/usb2/2-4/rc/rc0 > [ 1543.778382] usb 2-4: dvb_usb_v2: schedule remote query interval to 300 > msecs > [ 1543.778396] usb 2-4: dvb_usb_v2: 'TechnoTrend TVStick CT2-4400' > successfully initialized and connected > > I see no message about the firmware loading is this correct? > -- > 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 -- 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
Re: [PATCH] media:firewire:Remove unneeded function definition,avc_tuner_host2ca in firedtv-avc.c
On Feb 08 nick wrote: > On 2015-02-08 06:55 PM, Stefan Richter wrote: > > I still am missing research on the question whether or not the Common > > Interface serving part of the driver needs to send Host2CA commands. If > > yes, we implement it and use the function. If not, we remove the > > function. As long as we are not sure, I prefer to leave the #if-0'd code > > where it is. It documents how the command is formed, and we don't have > > any other documentation (except perhaps the git history). [...] > Stefan, > I looked in the history with git log -p 154907957f939 and all I got > for this function was > Wed Feb 11 21:21:04 CET 2009 > firedtv: avc: header file cleanup > > Remove unused constants and declarations. > Move privately used constants into .c files. The function was added a few commits before this one, by "firesat: update isochronous interface, add CI support". > Clearly this states to remove unused declarations and avc_tuner_host2ca is > unused. > Can you explain to me then why it's still needed to be around if there no > callers > of it? See above; in this instance #if 0 dead code #endif stands in for /* * pseudo code */ -- Stefan Richter -=-= --=- -=--= http://arcgraph.de/sr/ -- 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
cron job: media_tree daily build: WARNINGS
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: Mon Feb 9 04:00:15 CET 2015 git branch: test git hash: 4bad5d2d25099a42e146d7b18d2b98950ed287f5 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-5.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17.8-i686: OK linux-3.18-i686: OK linux-3.19-rc4-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18-x86_64: OK linux-3.19-rc4-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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
Fwd: divide error: 0000 in the gspca_topro
I got this, and it certainly seems relevant,.
It would seem that that whole 'quality' thing needs some range
checking, it should presumably be in the range [1..100] in order to
avoid negative 'sc' values or the divide-by-zero.
Hans, Mauro?
Linus
-- Forwarded message --
From: Peter Kovář
Date: Sun, Feb 8, 2015 at 2:18 PM
Subject: divide error: in the gspca_topro
To: Linus Torvalds
Hi++ Linus!
There is a trivial bug in the gspca_topro webcam driver.
/* set the JPEG quality for sensor soi763a */
static void jpeg_set_qual(u8 *jpeg_hdr,
int quality)
{
int i, sc;
if (quality < 50)
sc = 5000 / quality;
else
sc = 200 - quality * 2;
Crash can be reproduced by setting JPEG quality to zero in the guvcview
application.
Cheers,
Peter Kovář
50 65 74 65 72 20 4B 6F 76 C3 A1 C5 99
--
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
Re: [PATCH] media:firewire:Remove unneeded function definition,avc_tuner_host2ca in firedtv-avc.c
On Feb 08 Nicholas Krause wrote:
> Removes the unneeded function defintion,avc_tuner_host2ca in the file,
> firedtv-avc. This
> function should have been removed during the refactoring of the firetv code
> base during
> commit id,154907957f939 due to us removing unneeded definitions of functions
> not called
> when moving private function defintions from firedtv-avc.h to the
> file,firedtv-avc.c
> for the driver supporting firedtv enabled hardware respectfully.
>
> Signed-off-by: Nicholas Krause
I still am missing research on the question whether or not the Common
Interface serving part of the driver needs to send Host2CA commands. If
yes, we implement it and use the function. If not, we remove the
function. As long as we are not sure, I prefer to leave the #if-0'd code
where it is. It documents how the command is formed, and we don't have
any other documentation (except perhaps the git history).
On a more general note, as others told you before, please stop sending
patches that were created without any research on your part. Thank you.
> ---
> drivers/media/firewire/firedtv-avc.c | 31 ---
> 1 file changed, 31 deletions(-)
>
> diff --git a/drivers/media/firewire/firedtv-avc.c
> b/drivers/media/firewire/firedtv-avc.c
> index 251a556..a7f2617 100644
> --- a/drivers/media/firewire/firedtv-avc.c
> +++ b/drivers/media/firewire/firedtv-avc.c
> @@ -912,37 +912,6 @@ void avc_remote_ctrl_work(struct work_struct *work)
> avc_register_remote_control(fdtv);
> }
>
> -#if 0 /* FIXME: unused */
> -int avc_tuner_host2ca(struct firedtv *fdtv)
> -{
> - struct avc_command_frame *c = (void *)fdtv->avc_data;
> - int ret;
> -
> - mutex_lock(&fdtv->avc_mutex);
> -
> - c->ctype = AVC_CTYPE_CONTROL;
> - c->subunit = AVC_SUBUNIT_TYPE_TUNER | fdtv->subunit;
> - c->opcode = AVC_OPCODE_VENDOR;
> -
> - c->operand[0] = SFE_VENDOR_DE_COMPANYID_0;
> - c->operand[1] = SFE_VENDOR_DE_COMPANYID_1;
> - c->operand[2] = SFE_VENDOR_DE_COMPANYID_2;
> - c->operand[3] = SFE_VENDOR_OPCODE_HOST2CA;
> - c->operand[4] = 0; /* slot */
> - c->operand[5] = SFE_VENDOR_TAG_CA_APPLICATION_INFO; /* ca tag */
> - clear_operands(c, 6, 8);
> -
> - fdtv->avc_data_length = 12;
> - ret = avc_write(fdtv);
> -
> - /* FIXME: check response code? */
> -
> - mutex_unlock(&fdtv->avc_mutex);
> -
> - return ret;
> -}
> -#endif
> -
> static int get_ca_object_pos(struct avc_response_frame *r)
> {
> int length = 1;
--
Stefan Richter
-=-= --=- -=--=
http://arcgraph.de/sr/
--
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
Re: [PATCH] rtl2832: remove compiler warning
On Sun, Feb 08, 2015 at 10:44:22PM +, Luis de Bethencourt wrote: > Cleaning the following compiler warning: > rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function > > Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set > tmp, this line would never run because we go to err. It is still nice to avoid > compiler warnings. > > Signed-off-by: Luis de Bethencourt > --- > drivers/media/dvb-frontends/rtl2832.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/dvb-frontends/rtl2832.c > b/drivers/media/dvb-frontends/rtl2832.c > index 5d2d8f4..ad36d1c 100644 > --- a/drivers/media/dvb-frontends/rtl2832.c > +++ b/drivers/media/dvb-frontends/rtl2832.c > @@ -685,7 +685,7 @@ static int rtl2832_read_status(struct dvb_frontend *fe, > fe_status_t *status) > struct rtl2832_dev *dev = fe->demodulator_priv; > struct i2c_client *client = dev->client; > int ret; > - u32 tmp; > + u32 tmp = 0; > > dev_dbg(&client->dev, "\n"); > > -- > 2.1.0 > Hello all :) This warning can be seen in: http://hverkuil.home.xs4all.nl/logs/Saturday.log Thank you Hans for the daily build and logs. Luis -- 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
[PATCH] rtl2832: remove compiler warning
Cleaning the following compiler warning: rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set tmp, this line would never run because we go to err. It is still nice to avoid compiler warnings. Signed-off-by: Luis de Bethencourt --- drivers/media/dvb-frontends/rtl2832.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c index 5d2d8f4..ad36d1c 100644 --- a/drivers/media/dvb-frontends/rtl2832.c +++ b/drivers/media/dvb-frontends/rtl2832.c @@ -685,7 +685,7 @@ static int rtl2832_read_status(struct dvb_frontend *fe, fe_status_t *status) struct rtl2832_dev *dev = fe->demodulator_priv; struct i2c_client *client = dev->client; int ret; - u32 tmp; + u32 tmp = 0; dev_dbg(&client->dev, "\n"); -- 2.1.0 -- 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
[PATCH] media: bcm2048: remove unused return of function
Integer return of bcm2048_parse_rds_rt () is never used, changing the return
type to void.
Signed-off-by: Luis de Bethencourt
---
drivers/staging/media/bcm2048/radio-bcm2048.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 5382506..7f3d528 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -1579,7 +1579,7 @@ static void bcm2048_parse_rt_match_d(struct
bcm2048_device *bdev, int i,
bcm2048_parse_rds_rt_block(bdev, i, index+2, crc);
}
-static int bcm2048_parse_rds_rt(struct bcm2048_device *bdev)
+static void bcm2048_parse_rds_rt(struct bcm2048_device *bdev)
{
int i, index = 0, crc, match_b = 0, match_c = 0, match_d = 0;
@@ -1615,8 +1615,6 @@ static int bcm2048_parse_rds_rt(struct bcm2048_device
*bdev)
match_b = 1;
}
}
-
- return 0;
}
static void bcm2048_parse_rds_ps_block(struct bcm2048_device *bdev, int i,
--
2.1.0
--
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
[PATCH] media: cxd2099: move pre-init values out of init()
Improve code readability by moving out all pre-init values from the init
function.
Signed-off-by: Luis de Bethencourt
---
drivers/staging/media/cxd2099/cxd2099.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/cxd2099/cxd2099.c
b/drivers/staging/media/cxd2099/cxd2099.c
index 657ea48..bafe36f 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -300,7 +300,6 @@ static int init(struct cxd *ci)
int status;
mutex_lock(&ci->lock);
- ci->mode = -1;
do {
status = write_reg(ci, 0x00, 0x00);
if (status < 0)
@@ -420,7 +419,6 @@ static int init(struct cxd *ci)
status = write_regm(ci, 0x09, 0x08, 0x08);
if (status < 0)
break;
- ci->cammode = -1;
cam_mode(ci, 0);
} while (0);
mutex_unlock(&ci->lock);
@@ -711,6 +709,8 @@ struct dvb_ca_en50221 *cxd2099_attach(struct cxd2099_cfg
*cfg,
ci->en = en_templ;
ci->en.data = ci;
+ ci->mode = -1;
+ ci->cammode = -1;
init(ci);
dev_info(&i2c->dev, "Attached CXD2099AR at %02x\n", ci->cfg.adr);
return &ci->en;
--
2.1.0
--
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
TechnoTrend TT-TVStick CT2-4400v2 no firmware load
Hello, I use kernel 3.13.0 and the media_build "4e1a67e4a6c8ab71f416ea32059c92171407ba5d". I get following messages by dmesg: [ 1543.444128] usb 2-4: new high-speed USB device number 4 using ehci-pci [ 1543.577069] usb 2-4: New USB device found, idVendor=0b48, idProduct=3014 [ 1543.577088] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1543.577098] usb 2-4: Product: TechnoTrend USB-Stick [ 1543.577106] usb 2-4: Manufacturer: CityCom GmbH [ 1543.577114] usb 2-4: SerialNumber: 20131128 [ 1543.764126] usb 2-4: dvb_usb_v2: found a 'TechnoTrend TVStick CT2-4400' in warm state [ 1543.764317] usb 2-4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 1543.764387] DVB: registering new adapter (TechnoTrend TVStick CT2-4400) [ 1543.765811] usb 2-4: dvb_usb_v2: MAC address: bc:ea:2b:44:02:7c [ 1543.772724] i2c i2c-2: Added multiplexed i2c bus 3 [ 1543.772734] si2168 2-0064: Silicon Labs Si2168 successfully attached [ 1543.777532] si2157 3-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 1543.777579] usb 2-4: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)... [ 1543.777824] Registered IR keymap rc-tt-1500 [ 1543.778051] input: TechnoTrend TVStick CT2-4400 as /devices/pci:00/:00:13.2/usb2/2-4/rc/rc0/input18 [ 1543.778368] rc0: TechnoTrend TVStick CT2-4400 as /devices/pci:00/:00:13.2/usb2/2-4/rc/rc0 [ 1543.778382] usb 2-4: dvb_usb_v2: schedule remote query interval to 300 msecs [ 1543.778396] usb 2-4: dvb_usb_v2: 'TechnoTrend TVStick CT2-4400' successfully initialized and connected I see no message about the firmware loading is this correct? -- 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
Re: STK1160 driver connected to usb hub
(Ccing the media ML) See my reply below. On Fri, Feb 6, 2015 at 4:36 AM, Yin Ling wrote: > Hi Ezequiel Garcia, > > Sorry for this bother. We are researcher at University and working on > STK1160 usb connection related solusion. As our system needs multiple > STK1160 to input video data, we plan to use usb Hub to connect > multiple STK1160. Nevertheless, currently only one STK1160 with driver > can be operated by one usb Hub host from the information below, > http://www.linuxtv.org/wiki/index.php/Stk1160_based_USB_2.0_video_and_audio_capture_devices#Known_issues > It wrote that "To one root hub port can connect only one device. Can > connect multiple, but at the same time only one operate. This not an > power supply issue, since the device consumes only 200mA in operation > mode. Number of devices that can simultaneously connect to PC depends > on the amount root hub ports." > > If try to operate multiple STK1160 by one usb Hub, is it possible? > Could you help to provide any hints or technological ways to achieve > this goal? > As far as I can recall, the only constraint is the USB host controller isochronous bandwidth. Given the stk1160 chip streams raw video, and given I have found no way to implement frame size in-chip reduction, your USB host must be able to deal with raw full frames. Roughly speaking you need as much as 20 MB/s for each stk1160 video input. Such throughput is more or less close, to USB2.0 maximum throughput. I hope someone can jump in and correct me if I'm wrong here. > Additionally, if this way is not feasible, we have to work on > capturing 4 channel video data from one STK1160 at the same time. We > have to switch channel to capture each specific channel video data. We > found that if we switch channel with the frequency as 1s, the quality > of images are not well. Do you know how we can capture 4 channel good > quality video data, lower switch frequency? How much it could be? > I think this is a hardware limitation. The stk1160 is not able to capture from the multiple channels simultaneously. I honestly don't recall how it performs when fast switching between channels, but I wouldn't expect much. > As we are very busy with the system, and are confusing with these > problems at this period, we are highly looking forward to receiving > your information. or else, if anyone may knows the solution, could you > help to provide to us as well? > Maybe you can get yourself a video capture device that can stream compressed video? That will certainly reduce the USB bandwidth requirement. Hope this helps! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- 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
Re: [PATCH] media:firewire:Remove unneeded function definition,avc_tuner_host2ca
On Feb 08 Nicholas Krause wrote:
> Removes the function,avc_tuner_host2ca and the ifdef marco statements
> around this function as there are no more callers of this function
> and therefor no need for it's definition anymore.
>
> Signed-off-by: Nicholas Krause
Your changelog is incorrect. If you had checked the history, you would
have learned that the function was added without callers in the first
place and never gained any callers since then.
How about first checking what the Host2CA AV/C command is for, and then
deciding on whether to add proper usage of it or to drop its implementation
from the source for good.
> ---
> drivers/media/firewire/firedtv-avc.c | 31 ---
> 1 file changed, 31 deletions(-)
>
> diff --git a/drivers/media/firewire/firedtv-avc.c
> b/drivers/media/firewire/firedtv-avc.c
> index 251a556..a7f2617 100644
> --- a/drivers/media/firewire/firedtv-avc.c
> +++ b/drivers/media/firewire/firedtv-avc.c
> @@ -912,37 +912,6 @@ void avc_remote_ctrl_work(struct work_struct *work)
> avc_register_remote_control(fdtv);
> }
>
> -#if 0 /* FIXME: unused */
> -int avc_tuner_host2ca(struct firedtv *fdtv)
> -{
> - struct avc_command_frame *c = (void *)fdtv->avc_data;
> - int ret;
> -
> - mutex_lock(&fdtv->avc_mutex);
> -
> - c->ctype = AVC_CTYPE_CONTROL;
> - c->subunit = AVC_SUBUNIT_TYPE_TUNER | fdtv->subunit;
> - c->opcode = AVC_OPCODE_VENDOR;
> -
> - c->operand[0] = SFE_VENDOR_DE_COMPANYID_0;
> - c->operand[1] = SFE_VENDOR_DE_COMPANYID_1;
> - c->operand[2] = SFE_VENDOR_DE_COMPANYID_2;
> - c->operand[3] = SFE_VENDOR_OPCODE_HOST2CA;
> - c->operand[4] = 0; /* slot */
> - c->operand[5] = SFE_VENDOR_TAG_CA_APPLICATION_INFO; /* ca tag */
> - clear_operands(c, 6, 8);
> -
> - fdtv->avc_data_length = 12;
> - ret = avc_write(fdtv);
> -
> - /* FIXME: check response code? */
> -
> - mutex_unlock(&fdtv->avc_mutex);
> -
> - return ret;
> -}
> -#endif
> -
> static int get_ca_object_pos(struct avc_response_frame *r)
> {
> int length = 1;
--
Stefan Richter
-=-= --=- -=---
http://arcgraph.de/sr/
--
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
