From: http://www.spinics.net/lists/linux-media/msg20440.html This patch add support for the CI of the TT CT-3650. Jose Alberto Signed-off-by: Jose Alberto Reguero <jareguero <at> telefonica.net>
* Mauro Carvalho Chehab wrote: > Em 04-08-2011 04:14, Thierry Reding escreveu: > > The TM6010 supports much larger I2C transfers than currently specified. > > In fact the Windows driver seems to use 81 bytes per packet by default. > > This commit improves the speed of firmware loading a bit. > > --- > > drivers/staging/tm6000/tm6000-cards.c | 1 + > > drivers/staging/tm6000/tm6000-i2c.c | 2 +- > > 2 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c > > index c3b84c9..a5d2a71 100644 > > --- a/drivers/staging/tm6000/tm6000-cards.c > > +++ b/drivers/staging/tm6000/tm6000-cards.c > > <at> <at> -929,6 +929,7 <at> <at> static void tm6000_config_tuner(struct tm6000_core *dev) > > memset(&ctl, 0, sizeof(ctl)); > > > > ctl.demod = XC3028_FE_ZARLINK456; > > + ctl.max_len = 81; > > > > xc2028_cfg.tuner = TUNER_XC2028; > > xc2028_cfg.priv = &ctl; > > diff --git a/drivers/staging/tm6000/tm6000-i2c.c b/drivers/staging/tm6000/tm6000-i2c.c > > index 21cd9f8..2cb7573 100644 > > --- a/drivers/staging/tm6000/tm6000-i2c.c > > +++ b/drivers/staging/tm6000/tm6000-i2c.c > > <at> <at> -50,7 +50,7 <at> <at> static int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr, > > unsigned int i2c_packet_limit = 16; > > > > if (dev->dev_type == TM6010)(Continue reading)
* Mauro Carvalho Chehab wrote:
> Em 04-08-2011 04:14, Thierry Reding escreveu:
> > In radio mode, no frequency offset is needed. While at it, split off the
> > frequency offset computation for digital TV into a separate function.
>
> Nah, it is better to keep the offset calculation there. there is already
> a set_freq for DVB. breaking the frequency logic even further seems to
> increase the driver's logic. Also, patch is simpler and easier to review.
Okay, no problem. Feel free to replace the patch with yours.
> The patch bellow seems to be better. On a quick review, I think that the
> send_seq(priv, {0x00, 0x00})
> sequence may be wrong. I suspect that the device is just discarding that,
> but changing it needs more testing.
I ran across that as well, but I didn't dare touch it because I wasn't sure
what the broader impact would be.
Thierry
* Mauro Carvalho Chehab wrote: > Em 04-08-2011 04:14, Thierry Reding escreveu: > > --- > > drivers/staging/tm6000/tm6000-core.c | 3 --- > > 1 files changed, 0 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c > > index e14bd3d..2c156dd 100644 > > --- a/drivers/staging/tm6000/tm6000-core.c > > +++ b/drivers/staging/tm6000/tm6000-core.c > > <at> <at> -86,9 +86,6 <at> <at> int tm6000_read_write_usb(struct tm6000_core *dev, u8 req_type, u8 req, > > } > > > > kfree(data); > > - > > - msleep(5); > > - > > return ret; > > } > > > > This delay is needed by some tm5600/6000 devices. Maybe it is due to > some specific chipset revision, but I can't remember anymore what > device(s) were affected. > > The right thing to do seems to whitelist the devices that don't need > any delay there. This was actually the first thing I patched because I couldn't see any need for it (the Cinergy Hybrid USB Stick worked fine without) and it made the(Continue reading)
* Mauro Carvalho Chehab wrote: > Em 04-08-2011 04:14, Thierry Reding escreveu: > > Instead of selecting the default interface setting when preparing > > isochronous transfers, select it on the first call to open() to make > > sure it is available earlier. > > Hmm... I fail to see what this is needed earlier. The ISOC endpont is used > only when the device is streaming. > > Did you get any bug related to it? If so, please describe it better. I'm not sure whether this really fixes a bug, but it seems a little wrong to me to selecting the interface so late in the process when in fact the device is already being configured before (video standard, audio mode, firmware upload, ...). Thinking about it, this may actually be part of the fix for the "device hangs sometimes for inexplicable reasons" bug that this whole patch series seems to fix. Thierry
* Mauro Carvalho Chehab wrote:
> Em 31-08-2011 17:53, Mauro Carvalho Chehab escreveu:
> > Em 04-08-2011 04:14, Thierry Reding escreveu:
> >> When the last user closes the device, perform a lightweight reset of the
> >> device to bring it into a well-known state.
> >>
> >> Note that this is not always enough with the TM6010, which sometimes
> >> needs a hard reset to get into a working state again.
> >> ---
> >> drivers/staging/tm6000/tm6000-core.c | 43 +++++++++++++++++++++++++++++++++
> >> drivers/staging/tm6000/tm6000-video.c | 8 +++++-
> >> drivers/staging/tm6000/tm6000.h | 1 +
> >> 3 files changed, 51 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c
> >> index 317ab7e..58c1399 100644
> >> --- a/drivers/staging/tm6000/tm6000-core.c
> >> +++ b/drivers/staging/tm6000/tm6000-core.c
> >> <at> <at> -597,6 +597,49 <at> <at> int tm6000_init(struct tm6000_core *dev)
> >> return rc;
> >> }
> >>
> >> +int tm6000_reset(struct tm6000_core *dev)
> >> +{
> >> + int pipe;
> >> + int err;
> >> +
> >> + msleep(500);
> >> +
> >> + err = usb_set_interface(dev->udev, dev->isoc_in.bInterfaceNumber, 0);
(Continue reading)
Em 01-09-2011 02:13, Thierry Reding escreveu: > * Mauro Carvalho Chehab wrote: >> Em 04-08-2011 04:14, Thierry Reding escreveu: >>> --- >>> drivers/staging/tm6000/tm6000-core.c | 3 --- >>> 1 files changed, 0 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c >>> index e14bd3d..2c156dd 100644 >>> --- a/drivers/staging/tm6000/tm6000-core.c >>> +++ b/drivers/staging/tm6000/tm6000-core.c >>> <at> <at> -86,9 +86,6 <at> <at> int tm6000_read_write_usb(struct tm6000_core *dev, u8 req_type, u8 req, >>> } >>> >>> kfree(data); >>> - >>> - msleep(5); >>> - >>> return ret; >>> } >>> >> >> This delay is needed by some tm5600/6000 devices. Maybe it is due to >> some specific chipset revision, but I can't remember anymore what >> device(s) were affected. >> >> The right thing to do seems to whitelist the devices that don't need >> any delay there. > > This was actually the first thing I patched because I couldn't see any need(Continue reading)
Em 01-09-2011 02:19, Thierry Reding escreveu: > * Mauro Carvalho Chehab wrote: >> Em 04-08-2011 04:14, Thierry Reding escreveu: >>> Instead of selecting the default interface setting when preparing >>> isochronous transfers, select it on the first call to open() to make >>> sure it is available earlier. >> >> Hmm... I fail to see what this is needed earlier. The ISOC endpont is used >> only when the device is streaming. >> >> Did you get any bug related to it? If so, please describe it better. > > I'm not sure whether this really fixes a bug, but it seems a little wrong to > me to selecting the interface so late in the process when in fact the device > is already being configured before (video standard, audio mode, firmware > upload, ...). Some applications may open the device just to change the controls. All other drivers only set alternates/interfaces when the streaming is requested, as alternates/interfaces are needed only there. > Thinking about it, this may actually be part of the fix for the "device hangs > sometimes for inexplicable reasons" bug that this whole patch series seems to > fix. It is unlikely, except if the firmware inside the chip is broken (unfortunately, we have serious reasons to believe that the internal firmware on this chipset has serious bugs). I prefer to not apply this patch, except if we have a good reason for that,(Continue reading)
* Mauro Carvalho Chehab wrote: > Em 01-09-2011 02:19, Thierry Reding escreveu: > > * Mauro Carvalho Chehab wrote: > >> Em 04-08-2011 04:14, Thierry Reding escreveu: > >>> Instead of selecting the default interface setting when preparing > >>> isochronous transfers, select it on the first call to open() to make > >>> sure it is available earlier. > >> > >> Hmm... I fail to see what this is needed earlier. The ISOC endpont is used > >> only when the device is streaming. > >> > >> Did you get any bug related to it? If so, please describe it better. > > > > I'm not sure whether this really fixes a bug, but it seems a little wrong to > > me to selecting the interface so late in the process when in fact the device > > is already being configured before (video standard, audio mode, firmware > > upload, ...). > > Some applications may open the device just to change the controls. All other drivers > only set alternates/interfaces when the streaming is requested, as alternates/interfaces > are needed only there. Okay, I didn't know that it was only necessary for streaming. > > Thinking about it, this may actually be part of the fix for the "device hangs > > sometimes for inexplicable reasons" bug that this whole patch series seems to > > fix. > > It is unlikely, except if the firmware inside the chip is broken (unfortunately, > we have serious reasons to believe that the internal firmware on this chipset has(Continue reading)
Some devices support fast access to registers using the USB interface
while others require a certain delay after each operation. This commit
adds a quirk that can be enabled by devices that don't need the delay.
Signed-off-by: Thierry Reding <thierry.reding <at> avionic-design.de>
---
drivers/staging/tm6000/tm6000-core.c | 3 ++-
drivers/staging/tm6000/tm6000.h | 6 ++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c
index 64fc1c6..93a0772 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
<at> <at> -89,7 +89,8 <at> <at> int tm6000_read_write_usb(struct tm6000_core *dev, u8 req_type, u8 req,
kfree(data);
- msleep(5);
+ if ((dev->quirks & TM6000_QUIRK_NO_USB_DELAY) == 0)
+ msleep(5);
mutex_unlock(&dev->usb_lock);
return ret;
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index dac2063..0e35812 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
<at> <at> -169,6 +169,10 <at> <at> struct tm6000_endpoint {
unsigned maxsize;
(Continue reading)
RSS Feed530 | |
|---|---|
955 | |
1177 | |
834 | |
1327 | |
759 | |
952 | |
1291 | |
1382 | |
1327 | |
1192 | |
1130 | |
1344 | |
1008 | |
1082 | |
792 | |
1244 | |
1356 | |
1146 | |
815 | |
1187 | |
1079 | |
1070 | |
1436 | |
1229 | |
773 | |
1024 | |
843 | |
1069 | |
1056 | |
1048 | |
976 | |
909 | |
639 | |
846 | |
667 | |
1045 | |
767 | |
1034 | |
1236 | |
1028 | |
906 | |
1318 | |
835 | |
1097 | |
1050 | |
930 | |
1318 | |
1083 | |
1117 | |
1685 | |
1187 | |
1105 |
