Re: AverMedia A306 (cx23385, xc3028, af9013) (A577 too ?)

2011-06-04 Thread Daniel Gimpelevich 
On Sat, 2011-06-04 at 17:37 +0200, wal...@free.fr wrote:
> A307 may be close to the A306 board. I've found the following chips: cx23385,
> xc[34]?, lg3303). The demodulator is not the same, and follows the ATSC 
> standard
> (The A306 is DVB-T compatible).
> Coordinating our works may be helpful, for example for the initialization and
> the proper reset of the I2C chips. By email that will be OK.
> 
> Wallak.

We can take this discussion off-list whenever you are ready. The card is
in the machine on which I am typing this, so I cannot remove it and look
on the underside at this time, but IIRC there indeed is an LG chip
there. The markings on the tuner chip are covered by a thermal compound,
so I cannot read them at all, but my best guess based on the card's
specs is that it is an XC5000. I would like there to be some way to
identify the tuner programmatically, though. However, before beginning
work on the card, I would strongly prefer to verify the functionality of
its baseband inputs, and I lack the cable to attach to the baseband
connector on the card. Can you by any chance determine the pinout, so
that I could have such a cable made? Thank you.


signature.asc
Description: This is a digitally signed message part

Re: AverMedia A306 (cx23385, xc3028, af9013) (A577 too ?)

2011-06-03 Thread Daniel Gimpelevich 
On Thu, 2011-05-19 at 23:13 +0200, wal...@free.fr wrote:
> I've tried to use my A306 board on my system. All the main chips are
> fully
> supported by linux.

I have the A307 (product ID 0xc939) and I'd like to coordinate with you
regarding adapting your A306 support for it. If you use IRC at all, just
tell me when to be in #linuxtv, and if not, we'll keep this on-list.


--
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] Support for the Geniatech/Mygica A680B (05e1:0480)

2010-05-28 Thread Daniel Gimpelevich 
On Wed, 26 May 2010 01:08:51 -0300, Mauro Carvalho Chehab wrote:

> It would be nice to have Michael ack, if you're using part of his code
> on your patch.

Quite.

> It is a very bad idea to use a counter in seconds, especially since your
> expected delay is of one second. This means that you may way from 0 to 1
> seconds. The better way would be to do something like:
> 
> #define LOCK_DELAY 500/* time in miliseconds */ state-
>lock_time =
> jiffies + msecs_to_jiffies(LOCK_DELAY);

I considered doing something of this nature but thought it was not 
important enough for the delay to be that exact to do anything special to 
track it, but I think I do like your suggestion better than what I did.

> Note that I've defined 500 ms, as it is the mean time between 0 and 1
> seconds. I suspect that you may use a lower delay time, since 500 ms
> seems a very long time to let the frontend lock.

I was experimenting with different delays from 500 to 2000, and based on 
what I saw, I don't think any delay below 750 would be useful, if not 
1250.

> I would also add a comment that this is a workaround, since we currently
> don't know any way to read the signal lock (since the right procedure
> would be to, instead, read some register value to be sure that the demod
> has locked).

I operated under the assumption that this demod is not equipped with any 
mechanism to detect a lock as opposed to sync, and would therefore have 
nothing to report. This assumption was not based on anything, and if it's 
incorrect, then yes, this workaround is pointless.

> Also, the better is to split the "flakiness" patch from the geniatech
> board addition, as they are two different logical changes.

There are a couple more logical changes, and I thought the board addition 
too trivial without them to split off. The entire patch is pretty small; 
is splitting it that important?

> Wouldn't be better to add instead a "lock_delay" parameter, with the
> lock delay time, in milliseconds? Of course, you need to validate if the
> time is between an allowed range (for example, from -1 to 2000 ms).

I had thought of doing that, but I put it in the per-board demod 
configuration because I cannot test its effect on other boards, which may 
need different delays, if any. However, since the ultimate purpose of 
this parameter is to test which boards may or may not benefit from a 
delay in their demod configuration, it may indeed be a better idea to 
specify the delay in the parameter.

--
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] Support for the Geniatech/Mygica A680B (05e1:0480)

2010-05-07 Thread Daniel Gimpelevich 
Some time ago, Michael Krufky started a mercurial tree for this device
and related ones. I began this patch from his changes, but all that
remains from them are the (largely non-applicable) tuner-attaching code
and identifier names. I have been very careful to make sure the chip
driver changes in this patch are no-ops on already supported devices,
which I can't test; I recommend those who can test them to enable those
changes as appropriate.

I had hoped to include IR support in this patch, but the IR core does
not currently build against the .31 kernel with which I am testing, so
that will need to be a second patch when more feasible. To review, every
100ms, bit 4 is set in register 0xe0 in the AU8524 demod, register 0xe1
is read, and if bit 4 is on in it, 0x28 bytes are read from 0xe3.
Signed-off-by: Daniel Gimpelevich 
diff --git a/drivers/media/dvb/frontends/au8522.h b/drivers/media/dvb/frontends/au8522.h
index 565dcf3..c798919 100644
--- a/drivers/media/dvb/frontends/au8522.h
+++ b/drivers/media/dvb/frontends/au8522.h
@@ -58,6 +58,7 @@ struct au8522_config {
 
 	enum au8522_if_freq vsb_if;
 	enum au8522_if_freq qam_if;
+	int flakiness;
 };
 
 #if defined(CONFIG_DVB_AU8522) || \
diff --git a/drivers/media/dvb/frontends/au8522_dig.c b/drivers/media/dvb/frontends/au8522_dig.c
index 44390e2..6ca878f 100644
--- a/drivers/media/dvb/frontends/au8522_dig.c
+++ b/drivers/media/dvb/frontends/au8522_dig.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "dvb_frontend.h"
 #include "au8522.h"
@@ -36,6 +37,7 @@ static int debug;
 static LIST_HEAD(hybrid_tuner_instance_list);
 static DEFINE_MUTEX(au8522_list_mutex);
 
+#define LOCK_DELAY 1
 #define dprintk(arg...)\
 	do { if (debug)\
 		printk(arg);\
@@ -606,6 +608,7 @@ static int au8522_set_frontend(struct dvb_frontend *fe,
 		return ret;
 
 	state->current_frequency = p->frequency;
+	state->lock_time = get_seconds() + LOCK_DELAY;
 
 	return 0;
 }
@@ -623,6 +626,7 @@ int au8522_init(struct dvb_frontend *fe)
 	   chip, so that when it gets powered back up it won't think
 	   that it is already tuned */
 	state->current_frequency = 0;
+	state->lock_time = (unsigned long)-1L;
 
 	au8522_writereg(state, 0xa4, 1 << 5);
 
@@ -736,6 +740,7 @@ int au8522_sleep(struct dvb_frontend *fe)
 	au8522_writereg(state, 0xa4, 1 << 5);
 
 	state->current_frequency = 0;
+	state->lock_time = (unsigned long)-1L;
 
 	return 0;
 }
@@ -752,15 +757,20 @@ static int au8522_read_status(struct dvb_frontend *fe, fe_status_t *status)
 		dprintk("%s() Checking VSB_8\n", __func__);
 		reg = au8522_readreg(state, 0x4088);
 		if ((reg & 0x03) == 0x03)
-			*status |= FE_HAS_LOCK | FE_HAS_SYNC | FE_HAS_VITERBI;
+			*status |= FE_HAS_SYNC | FE_HAS_VITERBI;
 	} else {
 		dprintk("%s() Checking QAM\n", __func__);
 		reg = au8522_readreg(state, 0x4541);
 		if (reg & 0x80)
 			*status |= FE_HAS_VITERBI;
 		if (reg & 0x20)
-			*status |= FE_HAS_LOCK | FE_HAS_SYNC;
+			*status |= FE_HAS_SYNC;
 	}
+	if (*status & FE_HAS_SYNC && (!state->config->flakiness || (*status &
+			FE_HAS_VITERBI && state->lock_time < get_seconds(
+		*status |= FE_HAS_LOCK;
+	else if (~(*status | ~(FE_HAS_SYNC | FE_HAS_VITERBI)))
+		state->lock_time = get_seconds() + LOCK_DELAY;
 
 	switch (state->config->status_mode) {
 	case AU8522_DEMODLOCKING:
@@ -786,7 +796,7 @@ static int au8522_read_status(struct dvb_frontend *fe, fe_status_t *status)
 	}
 	state->fe_status = *status;
 
-	if (*status & FE_HAS_LOCK)
+	if (*status & FE_HAS_SYNC)
 		/* turn on LED, if it isn't on already */
 		au8522_led_ctrl(state, -1);
 	else
diff --git a/drivers/media/dvb/frontends/au8522_priv.h b/drivers/media/dvb/frontends/au8522_priv.h
index 609cf04..30611f6 100644
--- a/drivers/media/dvb/frontends/au8522_priv.h
+++ b/drivers/media/dvb/frontends/au8522_priv.h
@@ -53,6 +53,7 @@ struct au8522_state {
 	struct dvb_frontend frontend;
 
 	u32 current_frequency;
+	unsigned long lock_time;
 	fe_modulation_t current_modulation;
 
 	u32 fe_status;
diff --git a/drivers/media/video/au0828/au0828-cards.c b/drivers/media/video/au0828/au0828-cards.c
index 57dd919..fd70c90 100644
--- a/drivers/media/video/au0828/au0828-cards.c
+++ b/drivers/media/video/au0828/au0828-cards.c
@@ -116,6 +116,15 @@ struct au0828_board au0828_boards[] = {
 		.tuner_addr = ADDR_UNSET,
 		.i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
 	},
+	[AU0828_BOARD_SYNTEK_TELEDONGLE] = {
+		.name = "Syntek Teledongle [EXPERIMENTAL]",
+		.tuner_type = UNSET,
+		.tuner_addr = ADDR_UNSET,
+		.joined_rx = 1,
+		.i2c_clk_divider = 0x4,
+		.i2c_clk_divider_tx = 0x8,
+		.i2c_clk_divider_rx = 0x20,
+	},
 };
 
 /* Tuner callback function for au0828 boards. Currently only needed
@@ -292,6 +301,22 @@ void au0828_gpio_setup(struct au0828_dev *dev)
 		au0828_write(dev, REG_000, 0xa0);
 		msleep(250);
 		break;
+	case AU

Linux kernel development for the Geniatech/Mygica A680B (AU0828/AU8524/TDA18271)

2010-05-03 Thread Daniel Gimpelevich 
I am writing to the three of you to ask whether you have any uncommitted
code for the au0828 and/or au8522 drivers so that I do not reinvent the
wheel. I am CC'ing the mailing list for posterity and the ODM contact
that came forward a year ago here:


I have begun by forward-porting the changes from the mercurial tree at
 to the mercurial tree at
, and I found the result _mostly_ works,
but the demodulator has trouble providing a stream after some tuning
attempts and not others. It seems to be more successful if the Windows
driver first initializes the device in a VM. The Usbsnoop report shows
that a different, shorter initialization sequence is used. First of all,
the 0x600 register in the AU0828 is not touched, but instead, 0x1 is
written to 0x601. Instead of the AU0828's GPIO setup registers being put
in a reset state and then taken out, they are written once, with 0x0 to
0x003 and 0x001, 0xec to 0x002, and 0xe0 to 0x000. Prior to DVB use, 0x5
is written to 0x601. Rather than blindly replacing the existing sequence
with this (which does not create a noticeable change), I ask the
significance of register 0x601 and the relevant GPIO setup bits, based
on your knowledge of the chips involved, and maybe the CC'ed ODM might
say how this device in particular uses them, as well as how to
differentiate among different similar Geniatech devices. Also, the
Usbsnoop report shows that the 0x202 clock divider register is set to
0x4, 0x8, and 0x20, in different contexts.

It seems most supported AU0828 devices have an IR receiver, so I am
wondering whether any code has already been written for it. I don't know
about other AU0828 devices, but the Usbsnoop report for this one reveals
a pretty straightforward protocol:

The AU8524 demodulator has a GPIO control register (0xe0), a GPIO status
register (0xe1), and a GPIO data register (0xe2). An access cycle of
read-modify-write-verify sets bit 4 in the control register and then the
status register is read. Rinse and repeat 100ms later.

Is this at all typical of other AU0828 devices with IR?

--
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: Reponse from Geniatech Re: X8000A and KWorld ATSC 120

2010-05-02 Thread Daniel Gimpelevich 
In the past year and a half, my personal life took turns for the crazier 
and crazier. some time prior to that, I had near perfect support working 
for all functions of this card, including IR, but it never made it into 
mercurial due to a disagreement with Mauro about what I saw as 
fundamental changes needed to the cx88 driver design. However, this 
vendor support offer has my attention for a different reason: Having 
successfully added support for the AVerMedia Volar A868R, I've been asked 
to see what I can do about Geniatech's MyGica A680B stick. There is 
already a wiki entry on it:
http://www.linuxtv.org/wiki/index.php/Sabrent_TV-USBHD
If what Fang offered for the X8000A he can provide for the A680B, the 
longstanding issues could be resolved regarding this tree:
http://linuxtv.org/hg/~mkrufky/teledongle
Since it has been so long since the quoted message, I thought it best to 
ask this list whether there was any further communication. Has there been?

On Mon, 13 Apr 2009 17:42:17 -0500, Vanessa Ezekowitz wrote:

> Hi all.  As a follow-up to the remote control support issue for the
> Kworld ATSC 120, Geniatech sent me a very encouraging reply today.
> 
> Anyone want to take Fang up on his offer?
> 
> 
> --  Forwarded Message  --
> 
> Subject: 答复: Technical request regarding the HDTV Thriller X8000A Date:
> Monday 13 April 2009
> From: "Fang" 
> To: "'Vanessa Ezekowitz'" 
> 
> Dear Vanessa Ezekowitz:
> 
> 
> Thanks for your inquiry.
> 
> My name is Fang, product manager of Geniatech.
> 
> 1st, we can provide you the remote decoder IC information, including I2C
> address, r/w API, it is simple, read I2C address every 150ms, and you
> can get the the key stroke decoding value.
> 
> 2nd, we have step products and both follow this protocol, so it is
> useful for all our products.
> 
> 3rd, we'd like to support you directly from the Geniatech, that card is
> designed by us.
> 
> Finnally,  I'd like to ask you if you can port more linux drivers if we
> send you samples and tech informations for our other 2 ATSC products:
> X8350 and X8550.
> 
> I will send you more detailed tech information to you about the remote
> IC whatever your answer is.
> 
> Best Regards
> Fang
> 
> -邮件原件-
> 发件人: Vanessa Ezekowitz [mailto:vanessaezekow...@gmail.com] 发送时间:
> 2009年4月10日 5:36
> 收件人: supp...@geniatech.com
> 主题: Technical request regarding the HDTV Thriller X8000A
> 
> THIS IS NOT A USER SUPPORT OR DRIVER REQUEST - WE ALREADY HAVE DRIVERS.
> 
> THIS IS A PROGRAMMER'S REQUEST FOR TECHNICAL INFORMATION.
> 
> To whom it may concern,
> 
> Some time back, I wrote you asking about technical information regarding
> the Thriller X8000A board.  I never received a reply, so I am writing
> again.
> 
> I own a card that is a chip-for-chip, wire-for-wire clone of the
> Thriller X8000A, the Kworld HD PCI 120 (also called the "ATSC 120" for
> short) - it is programmatically indistinguishable from your card.  My
> apologies in advance if I have mistaken which company first made this
> particular card.
> 
> Anyway...  The manufacturer of my card is refusing to answer my
> question, claiming that the data I request has been outright lost and
> can't even be communicated between departments within the company.
> 
> So now, I turn to you, as the maker of a 100% compatible card.
> 
> We of the Linux community have successfully written open-source drivers
> for most of the ATSC120/X8000A's  features, except for one:  we wish to
> add support for this card's remote control unit.
> 
> The Linux Community, whom I am sure you are aware represents a very
> large, rapidly growing market, cannot in good conscience recommend any
> cards, Geniatech or otherwise, which lack complete programming
> information.
> 
> QUESTION:
> 
> On my particular card, this appears to be a 20 pin SMD IC near the IR
> sensor connector.  the manufacturer of my cloned card has deliberately
> removed all the markings from the chip, save for a single green dot of
> paint, and users who own your card have reported similar circumstances.
> 
> Is this mystery chip the remote decoder/receiver chip as I suspect?
> 
> What is the part number of this chip?
> 
> What I2C address does it occupy?
> 
> Where can I acquire a datasheet for it?
> 
> I await your reply.
> 
> --
> "There are some things in life worth obsessing over.  Most things
> aren't, and when you learn that, life improves."
> http://starbase.globalpc.net/~vanessa/ Vanessa Ezekowitz
> 

--
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