Re: [PATCH 08/10] V4L/DVB: tda18271: allow restricting max out to 4 bytes

[Michael Krufky]

On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab
 wrote:
> By default, tda18271 tries to optimize I2C bus by updating all registers
> at the same time. Unfortunately, some devices doesn't support it.
>
> The current logic has a problem when small_i2c is equal to 8, since there
> are some transfers using 11 + 1 bytes.
>
> Fix the problem by enforcing the max size at the right place, and allows
> reducing it to max = 3 + 1.
>
> Signed-off-by: Mauro Carvalho Chehab 

This looks to me as if it is working around a problem on the i2c
master.  I believe that a fix like this really belongs in the i2c
master driver, it should be able to break the i2c transactions down
into transactions that the i2c master can handle.

I wouldn't want to merge this without a better explanation of why it
is necessary in the tda18271 driver.  It seems to be a band-aid to
cover up a problem in the i2c master device driver code.

Regards,

Mike Krufky
--
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 03/10] V4L/DVB: tda18271: Add some hint about what tda18217 reg ID returned

[Michael Krufky]

On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab
 wrote:
> Instead of doing:
>
> [   82.581639] tda18271 4-0060: creating new instance
> [   82.588411] Unknown device detected @ 4-0060, device not supported.
> [   82.594695] tda18271_attach: [4-0060|M] error -22 on line 1272
> [   82.600530] tda18271 4-0060: destroying instance
>
> Print:
> [  468.740392] Unknown device (0) detected @ 4-0060, device not supported.
>
> for the error message, to help detecting what's going wrong with the
> device.
>
> Signed-off-by: Mauro Carvalho Chehab 
>
> diff --git a/drivers/media/common/tuners/tda18271-fe.c 
> b/drivers/media/common/tuners/tda18271-fe.c
> index 7955e49..77e3642 100644
> --- a/drivers/media/common/tuners/tda18271-fe.c
> +++ b/drivers/media/common/tuners/tda18271-fe.c
> @@ -1177,7 +1177,7 @@ static int tda18271_get_id(struct dvb_frontend *fe)
>                break;
>        }
>
> -       tda_info("%s detected @ %d-%04x%s\n", name,
> +       tda_info("%s (%i) detected @ %d-%04x%s\n", name, regs[R_ID] & 0x7f,
>                 i2c_adapter_id(priv->i2c_props.adap),
>                 priv->i2c_props.addr,
>                 (0 == ret) ? "" : ", device not supported.");

A patch like this is fine for testing, but I see no reason for merging
this into the kernel.  Can you provide an explaination as per why this
would be useful?  In general, if you see, "Unknown device detected @
X-00YY, device not supported." then it means that this is not a
tda182x1.

Regards,

Mike Krufky
--
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 09/10] V4L/DVB: tda18271: Add debug message with frequency divisor

[Michael Krufky]

On Tue, Sep 28, 2010 at 2:47 PM, Mauro Carvalho Chehab
 wrote:
> Signed-off-by: Mauro Carvalho Chehab 
>
> diff --git a/drivers/media/common/tuners/tda18271-common.c 
> b/drivers/media/common/tuners/tda18271-common.c
> index 195b30e..7ba3ba3 100644
> --- a/drivers/media/common/tuners/tda18271-common.c
> +++ b/drivers/media/common/tuners/tda18271-common.c
> @@ -549,6 +549,13 @@ int tda18271_calc_main_pll(struct dvb_frontend *fe, u32 
> freq)
>        regs[R_MD1]   = 0x7f & (div >> 16);
>        regs[R_MD2]   = 0xff & (div >> 8);
>        regs[R_MD3]   = 0xff & div;
> +
> +       if (tda18271_debug & DBG_REG) {
> +               tda_reg("MAIN_DIV_BYTE_1    = 0x%02x\n", 0xff & regs[R_MD1]);
> +               tda_reg("MAIN_DIV_BYTE_2    = 0x%02x\n", 0xff & regs[R_MD2]);
> +               tda_reg("MAIN_DIV_BYTE_3    = 0x%02x\n", 0xff & regs[R_MD3]);
> +       }
> +
>  fail:
>        return ret;
>  }


I would actually prefer NOT to merge this - it is redundant.  When
DBG_REG is enabled, the driver will dump the contents of all
registers, including MD1, MD2 and MD3.  With this patch applied, it
would dump this data twice.  I do not believe this is useful at all.

Regards,

Mike Krufky
--
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 08/10] V4L/DVB: tda18271: allow restricting max out to 4 bytes

[Michael Krufky]

On Thu, Sep 30, 2010 at 3:12 PM, Mauro Carvalho Chehab
 wrote:
> Hi Michael,
>
> Em 30-09-2010 15:52, Michael Krufky escreveu:
>> On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab
>>  wrote:
>>> By default, tda18271 tries to optimize I2C bus by updating all registers
>>> at the same time. Unfortunately, some devices doesn't support it.
>>>
>>> The current logic has a problem when small_i2c is equal to 8, since there
>>> are some transfers using 11 + 1 bytes.
>>>
>>> Fix the problem by enforcing the max size at the right place, and allows
>>> reducing it to max = 3 + 1.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab 
>>
>> This looks to me as if it is working around a problem on the i2c
>> master.  I believe that a fix like this really belongs in the i2c
>> master driver, it should be able to break the i2c transactions down
>> into transactions that the i2c master can handle.
>>
>> I wouldn't want to merge this without a better explanation of why it
>> is necessary in the tda18271 driver.  It seems to be a band-aid to
>> cover up a problem in the i2c master device driver code.
>
> In the specific case of cx231xx the hardware don't support any I2C 
> transactions
> with more than 4 bytes. It is common to find this kind of limit on other types
> of hardware as well.
>
> In the specific case of tda18271, the workaround for tda18271 is already 
> there:
>
> enum tda18271_small_i2c {
>        TDA18271_39_BYTE_CHUNK_INIT = 0,
>        TDA18271_16_BYTE_CHUNK_INIT = 1,
>        TDA18271_08_BYTE_CHUNK_INIT = 2,
> };
> (from upstream tda18271.h header)
>
> Yet, it is currently broken. In thesis, if you use small_i2c, it should limit 
> the
> transactions size to a certain value, but, if you try to limit to 8, you'll 
> still
> see some transactions with size=11, since the code that honors small_i2c only 
> works
> for the initial dump of the 39 registers, as there are some cases where 
> writes to
> EP3 registers are done with:
>        tda18271_write_regs(fe, R_EP3, 11);
>
> and the current code for tda18271_write_regs don't check it.
>
> So, if there's a code there that allows limiting small_i2c:
>        1) this code should work for all transactions, not only to the initial 
> init;
>        2) if there is such code, why not allow specifying a max size of 4 
> bytes?
>
> Another aspect is that doing such kind or restriction at the i2c adapter 
> would require
> a very ugly logic, as some devices like tda18271 have only 8 bits registers 
> per i2c address,
> and a write (or read) with length > 1 byte update/read the next consecutive 
> registers,
> while other devices like xc3028 have one single I2C address for multi-byte 
> operations like
> updating the firmware.
>
> If this logic would be moved into the bridge drivers, they would need to have 
> some ugly
> tests, checking for each specific i2c sub-driver at their core drivers.

Hmm... If you don't mind, would you allow me to think about this a
bit, and run some tests of my own?

I have already seen the tda18271 work properly on the cx231xx with 8
byte transactions, the issue that I saw was actually a 12-byte
transaction limit, so the 11 byte transfer didn't cause a problem.
I'd like to test this again myself using the cx231xx device that I
have on hand.

However, this transaction in particular:

tda18271_write_regs(fe, R_EP3, 11);

...is not supposed to be broken down to smaller transaction -- this
particular transaction is supposed to be a one shot change to all 11
regs at once.  Straying from this could result in unpredictable
behavior.

I'd just like to review some other options and retest this before we
merge.  Is that okay with you?

Regards,

Mike Krufky
--
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 03/10] V4L/DVB: tda18271: Add some hint about what tda18217 reg ID returned

[Michael Krufky]

On Thu, Sep 30, 2010 at 3:16 PM, Mauro Carvalho Chehab
 wrote:
> Em 30-09-2010 15:57, Michael Krufky escreveu:
>> On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab
>>  wrote:
>>> Instead of doing:
>>>
>>> [   82.581639] tda18271 4-0060: creating new instance
>>> [   82.588411] Unknown device detected @ 4-0060, device not supported.
>>> [   82.594695] tda18271_attach: [4-0060|M] error -22 on line 1272
>>> [   82.600530] tda18271 4-0060: destroying instance
>>>
>>> Print:
>>> [  468.740392] Unknown device (0) detected @ 4-0060, device not supported.
>>>
>>> for the error message, to help detecting what's going wrong with the
>>> device.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab 
>>>
>>> diff --git a/drivers/media/common/tuners/tda18271-fe.c 
>>> b/drivers/media/common/tuners/tda18271-fe.c
>>> index 7955e49..77e3642 100644
>>> --- a/drivers/media/common/tuners/tda18271-fe.c
>>> +++ b/drivers/media/common/tuners/tda18271-fe.c
>>> @@ -1177,7 +1177,7 @@ static int tda18271_get_id(struct dvb_frontend *fe)
>>>                break;
>>>        }
>>>
>>> -       tda_info("%s detected @ %d-%04x%s\n", name,
>>> +       tda_info("%s (%i) detected @ %d-%04x%s\n", name, regs[R_ID] & 0x7f,
>>>                 i2c_adapter_id(priv->i2c_props.adap),
>>>                 priv->i2c_props.addr,
>>>                 (0 == ret) ? "" : ", device not supported.");
>>
>> A patch like this is fine for testing, but I see no reason for merging
>> this into the kernel.  Can you provide an explaination as per why this
>> would be useful?  In general, if you see, "Unknown device detected @
>> X-00YY, device not supported." then it means that this is not a
>> tda182x1.
>
> cx231xx have 4 I2C buses. The device I'm working with have the tuner at the 
> wrong chip.
> As it doesn't support 0 byte transactions, if you try to read from the wrong 
> i2c, it will
> just return 0 to all read requests.
>
> So, this kind of message can be very useful if someone sends us a report 
> about a new device.
> The changes are small and are printed only in the case of errors, where 
> people will likely
> try to reach the developers. So, I think it is a good idea to have it 
> mainstream.

Mauro,

I think that's a reasonable explanation.  Would you be open to
reworking the patch such that the register contents only show up if
the device is not recognized?  (when ret < 0) . In the case where the
device is correctly identified (ret == 0), I'd rather preserve the
original successful detection message, and not see the ID register
contents.

Thanks & regards,

Mike Krufky
--
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 03/10] V4L/DVB: tda18271: Add some hint about what tda18217 reg ID returned

[Michael Krufky]

On Thu, Sep 30, 2010 at 4:26 PM, Mauro Carvalho Chehab
 wrote:
> Em 30-09-2010 16:27, Michael Krufky escreveu:
>> Mauro,
>>
>> I think that's a reasonable explanation.  Would you be open to
>> reworking the patch such that the register contents only show up if
>> the device is not recognized?  (when ret < 0) . In the case where the
>> device is correctly identified (ret == 0), I'd rather preserve the
>> original successful detection message, and not see the ID register
>> contents.
>
> Patch enclosed.
>
> ---
>
> [PATCH] V4L/DVB: tda18271: Add some hint about what tda18217 reg ID returned
>
> Instead of doing:
>
> [   82.581639] tda18271 4-0060: creating new instance
> [   82.588411] Unknown device detected @ 4-0060, device not supported.
> [   82.594695] tda18271_attach: [4-0060|M] error -22 on line 1272
> [   82.600530] tda18271 4-0060: destroying instance
>
> Print:
> [  468.740392] Unknown device (0) detected @ 4-0060, device not supported.
>
> for the error message, to help detecting what's going wrong with the
> device.
>
> This helps to detect when the driver is using the wrong I2C bus (or have
> the i2g gate switch pointing to the wrong place), on devices like cx231xx
> that just return 0 on reads to a non-existent i2c device.
>
> Signed-off-by: Mauro Carvalho Chehab 
>
> diff --git a/drivers/media/common/tuners/tda18271-fe.c 
> b/drivers/media/common/tuners/tda18271-fe.c
> index 7955e49..3db8727 100644
> --- a/drivers/media/common/tuners/tda18271-fe.c
> +++ b/drivers/media/common/tuners/tda18271-fe.c
> @@ -1156,7 +1156,6 @@ static int tda18271_get_id(struct dvb_frontend *fe)
>        struct tda18271_priv *priv = fe->tuner_priv;
>        unsigned char *regs = priv->tda18271_regs;
>        char *name;
> -       int ret = 0;
>
>        mutex_lock(&priv->lock);
>        tda18271_read_regs(fe);
> @@ -1172,17 +1171,18 @@ static int tda18271_get_id(struct dvb_frontend *fe)
>                priv->id = TDA18271HDC2;
>                break;
>        default:
> -               name = "Unknown device";
> -               ret = -EINVAL;
> -               break;
> +               tda_info("Unknown device (%i) detected @ %d-%04x, device not 
> supported.\n",
> +                        regs[R_ID],
> +                        i2c_adapter_id(priv->i2c_props.adap),
> +                        priv->i2c_props.addr);
> +               return -EINVAL;
>        }
>
> -       tda_info("%s detected @ %d-%04x%s\n", name,
> +       tda_info("%s detected @ %d-%04x\n", name,
>                 i2c_adapter_id(priv->i2c_props.adap),
> -                priv->i2c_props.addr,
> -                (0 == ret) ? "" : ", device not supported.");
> +                priv->i2c_props.addr);
>
> -       return ret;
> +       return 0;
>  }
>
>  static int tda18271_setup_configuration(struct dvb_frontend *fe,
>
>

This looks good to me, although you could concatenate these lines together:


> +               tda_info("Unknown device (%i) detected @ %d-%04x, device not 
> supported.\n",
> +                        regs[R_ID],
> +                        i2c_adapter_id(priv->i2c_props.adap),
> +                        priv->i2c_props.addr);
> +               return -EINVAL;


to be more like this:


> +               tda_info("Unknown device (%i) detected @ %d-%04x, device not 
> supported.\n",
> +                        regs[R_ID], i2c_adapter_id(priv->i2c_props.adap), 
> priv->i2c_props.addr);
> +               return -EINVAL;


...that is, if it fits within an 80-char line.

Anyway,

Reviewed-by: Michael Krufky 

Thank you.

Regards,

Mike Krufky
--
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 08/10] V4L/DVB: tda18271: allow restricting max out to 4 bytes

[Michael Krufky]

On Thu, Sep 30, 2010 at 6:00 PM, Antti Palosaari  wrote:
> On 09/30/2010 09:52 PM, Michael Krufky wrote:
>>
>> On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab
>>   wrote:
>>>
>>> By default, tda18271 tries to optimize I2C bus by updating all registers
>>> at the same time. Unfortunately, some devices doesn't support it.
>>>
>>> The current logic has a problem when small_i2c is equal to 8, since there
>>> are some transfers using 11 + 1 bytes.
>>>
>>> Fix the problem by enforcing the max size at the right place, and allows
>>> reducing it to max = 3 + 1.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab
>>
>> This looks to me as if it is working around a problem on the i2c
>> master.  I believe that a fix like this really belongs in the i2c
>> master driver, it should be able to break the i2c transactions down
>> into transactions that the i2c master can handle.
>>
>> I wouldn't want to merge this without a better explanation of why it
>> is necessary in the tda18271 driver.  It seems to be a band-aid to
>> cover up a problem in the i2c master device driver code.
>
> Yes it is I2C provider limitation, but I think almost all I2C adapters have
> some limit. I suggest to set param for each tuner and demod driver which
> splits reads and writes to len adapter can handle. I did that for tda18218
> write.
>
> But there is one major point you don't see. It is not simple to add this
> splitting limit to the provider. Provider does not have knowledge which is
> meaning of bytes it transfers to the bus. Without knowledge it breaks
> functionality surely in some point. There is commonly seen 1, 2 and 4 byte
> register address and same for register values. Also some chips like to send
> data as register-value pairs.

Yes, I understand.  We will likely merge Mauro's patch, I just want to
test it on my own hardware first, and I'd like to verify the cx231xx
i2c xfer limit issue that Mauro is reporting.  I'll try to get back to
this early next week, or hopefully over this weekend.

Thanks for the input :-)

Regards,

Mike Krufky
--
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: KWorld UB435-Q Support

[Michael Krufky]

Jarod Wilson wrote:

On Nov 15, 2009, at 11:55 PM, Jarod Wilson wrote:


On 11/15/2009 11:46 PM, Jarod Wilson wrote:

On 10/09/2009 09:27 PM, Robert Cicconetti wrote:

On Wed, Oct 7, 2009 at 10:08 PM, Jarod Wilson wrote:

On Oct 7, 2009, at 9:39 PM, Robert Cicconetti wrote:

Okay... I built the tip of the archive linked above. It works with my
UB435-Q fairly well, built against 2.6.28-15-generic #52-Ubuntu SMP
x86_64. I've been able to stream QAM256 content for several hours
reliably. Mythfrontend works somewhat... it'll tune the initial
channel, but fails afterward. I suspect it is timing out while waiting
for the RF tracking filter calibration... it adds about 6 seconds to
every tuning operation.

[ 812.465930] tda18271: performing RF tracking filter calibration
[ 818.572446] tda18271: RF tracking filter calibration complete
[ 818.953946] tda18271: performing RF tracking filter calibration
[ 825.093211] tda18271: RF tracking filter calibration complete

Any suggestions? Further data needed?

Nothing off the top of my head, no. But I've got a UB435-Q of my own
now,
sitting on my desk waiting for me to poke at it... Not sure when I'll
have
time to actually poke at it though. :\

A little further poking yields that RF_CAL_OK in EP1 is 0, which is
why it keeps recalibrating.

I've commented out the part of the code that recalibrates if RF_CAL_OK
is 0; EP1 always seems to be c6... and now mythfrontend is happy. :)

This is not a long term solution, but as ugly hacks go it was pretty
straight forward. :)

Finally got around to poking at this again. Forward-ported the patches
to the current v4l-dvb tip

Meant to include this:

http://wilsonet.com/jarod/junk/kworld-a340-20091115/


, and gave 'em a spin with my own UB435-Q, as
well as a 340U that Doug gave me when he was in town a bit ago. Both are
working just fine with my QAM feed here at the house, albeit with the
same lengthy delay when changing channels you (Robert) mentioned. At a
glance, I was hoping simply setting rf_cal_on_startup for the
card-specific tda18271_config would remove the delay, but neither a 0 or
a 1 seems to particularly help with tuning delays. Hoping maybe Mike has
an idea on this part...

In related news, I actually managed to get my original 340U with the C1
tuner to work briefly as well, and with the same code, no tuning delays.
Seems either the PCB is cracked or the usb connector is just that bad,
and it only works when positioned just so...

I'll give all three sticks I've got here a quick spin with an OTA signal 
tomorrow too. But I think I'm not seeing any significant reason to not move 
forward with trying to get this code finally merged.


All three check out with an OTA signal as well. I'll try to poke at the tuning 
delay thing a bit more tonight, but I'm inclined to send off formal patches 
Real Soon Now.




Jarod,

I havent had time to review this entire email thread yet... but:

> [ 812.465930] tda18271: performing RF tracking filter calibration
> [ 818.572446] tda18271: RF tracking filter calibration complete
> [ 818.953946] tda18271: performing RF tracking filter calibration
> [ 825.093211] tda18271: RF tracking filter calibration complete


If you see this happen more than once consecutively, and there is only 1 
silicon tuner present, then it means something very bad is happening, 
and there is a chance of burning out a part.  I still wouldnt not 
recommend any mainline merge until you can prevent this behavior -- I 
suspect that a GPIO reset is being toggled where it shouldnt be, which 
should be harmless ... but until we fix it, we cant be sure what damage 
might get done...


The RF tracking filter calibration is a procedure that should only 
happen once while the tuner is powered on -- it should *only* be 
repeated if the tuner indicated that calibration is necessary, and that 
would only happen after a hardware reset.


This still looks fishy to me...

-Mike
--
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: Details about DVB frontend API

[Michael Krufky]

On Wed, Nov 18, 2009 at 10:17 AM, Devin Heitmueller
 wrote:
> On Wed, Nov 18, 2009 at 9:04 AM, Mauro Carvalho Chehab
>  wrote:
>> Devin Heitmueller wrote:
>>> On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
>>>  wrote:
 We shouldn't write API's thinking on some specific use case or aplication.
 If there's a problem with zap, the fix should be there, not at the kernel.
>>>
>>> Your response suggests I must have poorly described the problem.  Zap
>>> is just one example where having an "inconsistent" view of the various
>>> performance counters is easily visible.  If you're trying to write
>>> something like an application to control antenna orientation, the fact
>>> that you cannot ask for a single view of all counters can be a real
>>> problem.  Having to make separate ioctl calls for each field can cause
>>> real problems here.
>>>
>>> I disagree strongly with your assertion that we should not considering
>>> specific use cases when writing an API.
>>
>> That's not what I've said (or maybe I haven't said it clear enough).
>> I'm saying that we shouldn't look for one particular use case only.
>> In other words, the API should cover all use cases that makes sense.
>>
>>>In this case, Manu's
>>> approach provides the ability to get a single consistent view of all
>>> the counters (for those drivers which can support it)
>>
>> No. To get all counters, you'll need to call 3 ioctls. The status were
>> grouped around 3 groups of counters on his proposal. I'm sure Manu has some
>> explanation why he thinks that 3 is better then 2 or 4 calls, but the point
>> is: should we really group them on a fixed way?
>>
>> Btw, by using S2API, we'll break it into different commands. Yet, we can
>> call all of them at once, if needed, as the API defines it as:
>>
>> struct dtv_property {
>>        __u32 cmd;
>>        __u32 reserved[3];
>>        union {
>>                __u32 data;
>>                struct {
>>                        __u8 data[32];
>>                        __u32 len;
>>                        __u32 reserved1[3];
>>                        void *reserved2;
>>                } buffer;
>>        } u;
>>        int result;
>> } __attribute__ ((packed));
>>
>> struct dtv_properties {
>>        __u32 num;
>>        struct dtv_property *props;
>> };
>>
>> #define FE_SET_PROPERTY            _IOW('o', 82, struct dtv_properties)
>> #define FE_GET_PROPERTY            _IOR('o', 83, struct dtv_properties)
>>
>> So, all needed commands can be grouped together to provide an atomic read.
>>
 Also, the above mentioned problem can happen even if there's just one API
 call from userspace to kernel or if the driver needs to do separate,
 serialized calls to firmware (or a serialized calculus) to get the
 three measures.
>>>
>>> True, the accuracy in which a given driver can provide accurate data
>>> is tied to the quality of the hardware implementation.  However, for
>>> well engineered hardware, Manu's proposed API affords the ability to
>>> accurately report a consistent view of the information.  The existing
>>> implementation restricts all drivers to working as well as the
>>> worst-case hardware implementation.
>>
>> Imagining that some application will need to retrieve all quality indicators
>> at the same time, as they were grouped into 3 groups, even on a perfect
>> hardware, you won't be able to get all of them at the sime time,
>> since you'll need to call 3 ioctls.
>>
> For what it's worth, we have solved this problem in hwmon driver the
> following way: we cache related values (read from the same register or
> set of registers) for ~1 second. When user-space requests the
> information, if the cache is fresh it is used, otherwise the cache is
> first refreshed. That way we ensure that data returned to nearby
> user-space calls are taken from the same original register value. One
> advantage is that we thus did not have to map the API to the hardware
> register constraints and thus have the guarantee that all hardware
> designs fit.
>
> I don't know if a similar logic would help for DVB.
 This could be an alternative, if implemented at the right way. However,
 I suspect that it would be better to do such things at libdvb.

 For example, caching measures for 1 second may be too much, if userspace is
 doing a scan, while, when streaming, this timeout can be fine.
>>>
>>> Jean's caching approach for hwmon is fine for something like the
>>> chassis temperature, which doesn't change that rapidly.  However, it's
>>> probably not appropriate for things like SNR and strength counters,
>>> where near real-time feedback can be useful in things like controlling
>>> a rotor.
>>
>> I agree.
>>
>> Yet, you won't have this feedback in real-time, since calculating
>> QoS indicators require some time. So, after moving the rotor, you'll need
>> to wait for some time, in order to allow the frontend to recalculate the
>> QoS after the movement

Re: [PATCH] V4L/DVB: Fix test in copy_reg_bits()

[Michael Krufky]

Ah!  Nice catch.  Thank you, Roel.  Mauro / Andrew, can one of you 
please merge this?  The driver hasn't changed, so it should go to Linus' 
current tree and also stable, although it isn't crucial.


Signed-off-by: Michael Krufky 

Roel Kluin wrote:

The reg_pair2[j].reg was tested twice.

Signed-off-by: Roel Kluin 
---
 drivers/media/common/tuners/mxl5007t.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

I think this was intended?

diff --git a/drivers/media/common/tuners/mxl5007t.c 
b/drivers/media/common/tuners/mxl5007t.c
index 2d02698..7eb1bf7 100644
--- a/drivers/media/common/tuners/mxl5007t.c
+++ b/drivers/media/common/tuners/mxl5007t.c
@@ -196,7 +196,7 @@ static void copy_reg_bits(struct reg_pair_t *reg_pair1,
i = j = 0;
 
 	while (reg_pair1[i].reg || reg_pair1[i].val) {

-   while (reg_pair2[j].reg || reg_pair2[j].reg) {
+   while (reg_pair2[j].reg || reg_pair2[j].val) {
if (reg_pair1[i].reg != reg_pair2[j].reg) {
j++;
continue;
--
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: af9015: tuner id:179 not supported, please report!

[Michael Krufky]

On Wed, Dec 2, 2009 at 5:06 PM, Bert Massop  wrote:
> Jan Sundman  aland.net> writes:
>
>>
>> Hi,
>>
>> I just received a usb DVB-T card and have been trying to get it to work
>> under Ubuntu 9.10, but to no avail. dmesg shows the following when
>> plugging in the card:
>>
>> [   35.280024] usb 2-1: new high speed USB device using ehci_hcd and
>> address 4
>> [   35.435978] usb 2-1: configuration #1 chosen from 1 choice
>> [   35.450176] af9015: tuner id:179 not supported, please report!
>> [   35.452891] Afatech DVB-T 2: Fixing fullspeed to highspeed interval:
>> 10 -> 7
>> [   35.453097] input: Afatech DVB-T 2
>> as /devices/pci:00/:00:13.2/usb2/2-1/2-1:1.1/input/input8
>> [   35.453141] generic-usb 0003:15A4:9016.0005: input,hidraw3: USB HID
>> v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:13.2-1/input1
>>
>> lsusb shows:
>> Bus 002 Device 005: ID 15a4:9016
>>
>> and finally lsmod | grep dvb
>> dvb_usb_af9015         37152  0
>> dvb_usb                22892  1 dvb_usb_af9015
>> dvb_core              109716  1 dvb_usb
>>
>> While googling for an answer to my troubles I came across
>> http://ubuntuforums.org/showthread.php?t=606487&page=5 which hints that
>> the card may use the TDA18218HK tuner chip which does not seem to be
>> supported currently.
>>
>> Does anyone have any experience regarding this chip and know what to do
>> to get it working.
>>
>> Best regards,
>>
>> //Jan
>>
>>
>
> Hi Jan,
>
> As stated in the Ubuntuforums thread, there doesn't seem to be any support for
> this chip at the moment. I don't know how hard it is to code support for a
> specific tuner, but I'm looking into that right now.
>
> Hopefully some more experienced coders will join in writing something usable, 
> as
> I don't think I will be able to do it myself.
>
> Please drop a message if anyone finds something useful.
>
> Best regards,
>
> Bert

The TDA18218 is not currently supported under Linux.  I have the
information needed to write a driver to support it, but I do not have
any devices that use it, nor any interest (as of now) to write the
driver on my own time.

For me, it would not be very difficult to get this done, as I have
done work to support a similar family of tuners -- TDA18271 /
TDA18211.  The TDA18218 tuner is not supported by the current driver.

In the past, I would have gone ahead and written a driver for the
sheer enjoyment of doing so... but nowadays, I actually have other
projects of a higher priority that need my attention instead.

If, in the future, any commercial entity has interest in seeing this
tuner silicon supported under Linux, they should contact me -- perhaps
my desire to write this driver can be increased ;-)

Regards,

Mike Krufky
kernellabs.com
--
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

[PULL] http://kernellabs.com/hg/~mkrufky/hcw-ids

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/hcw-ids

for:

- smsusb: add autodetection support for five additional Hauppauge USB IDs

 smsusb.c |   10 ++
 1 file changed, 10 insertions(+)

Regards,

Mike
--
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: V4L1 compatibility broken for VIDIOCGTUNER with radio

[Michael Krufky]

On Thu, Dec 3, 2009 at 8:10 PM, hermann pitton  wrote:
>
> Am Donnerstag, den 03.12.2009, 21:04 -0200 schrieb Herton Ronaldo
> Krzesinski:
>> Em Qui 03 Dez 2009, às 19:54:29, hermann pitton escreveu:
>> > Hi,
>> >
>> > Am Donnerstag, den 03.12.2009, 16:56 -0200 schrieb Herton Ronaldo
>> > Krzesinski:
>> > > Hi,
>> > >
>> > > After commit 9bedc7f ("V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM
>> > > default handlers"), radio software using V4L1 stopped to work on a 
>> > > saa7134
>> > > card, a git bisect pointed to this commit introducing the regression. All
>> > > VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this
>> > > commit.
>> > >
>> > > Investigating the issue, it turns out that v4l1_compat_get_tuner calls
>> > > VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is
>> > > returning -EINVAL to user space applications which are being confused 
>> > > about
>> > > this.
>> > >
>> > > May be VIDIOC_G_STD change in the commit above should be reverted, or
>> > > v4l1_compat_get_tuner changed to not return error with G_STD, or not call
>> > > G_STD ioctl for a radio device?
>> > >
>> > > --
>> > > []'s
>> > > Herton
>> >
>> > it was fixed here.
>> >
>> > http://linuxtv.org/hg/v4l-dvb/rev/58ecda742a70
>>
>> Indeed, thanks for the pointer. I forgot to check latest v4l1-compat.c /o\
>>
>> >
>> > Maybe it was not ported to stable?
>>
>> Not on latest stable (2.6.31.6), perhaps it should be forwarded.
>>
>
> Yes, for sure. It's our fault.
>
> Seems we had an "internal server error" :(
>
> I came across it by accident.
>
>> The only other issue I'm aware of is that radio is broken since guessed
>> 8 weeks on my tuners, only realized when testing on enabling external
>> active antenna voltage for DVB-T on a/some 310i.
>
> I did the bisect with some delay and Hans marked the fix with priority
> "high", but we missed to point Mike at it for stable explicitly.
>
> Mike, please review and forward.
>
> Sorry,
> Hermann

Already done.  It's queued for 2.6.31.7  The delay was due to the
standard bureaucracy ...  nothing we haven't seen before -- hopefully
the distros will take in in once it's merged to stable, which should
probably be within the next week or two.

Thanks,

Mike
--
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: af9015: tuner id:179 not supported, please report!

[Michael Krufky]

On Thu, Dec 3, 2009 at 5:03 PM, Devin Heitmueller
 wrote:
> On Thu, Dec 3, 2009 at 4:47 PM, Bert Massop  wrote:
>> Hi Jan,
>>
>> The datasheet for the TDA18218 can be obtained from NXP:
>> http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf
>>
>> That's all the information I have at the moment, maybe Mike has some
>> other information (like the Application Note mentioned in the
>> datasheet, that claims to contain information on writing drivers, but
>> cannot be found anywhere).
>>
>> Best regards,
>>
>> Bert
>
> Took a quick look at that datasheet.  I would guess between that
> datasheet and a usbsnoop, there is probably enough there to write a
> driver that basically works for your particular hardware if you know
> what you are doing.  The register map is abbreviated, but probably
> good enough...
>
> Devin

The datasheet is missing too much important information needed to
write a fully featured driver for the part, and I wouldn't recommend
using a usbsnoop for this type of tuner, but be my guest and prove me
wrong.

You might be able to get it working, but you'll end up with tons of
binary blobs hardcoded for each frequency, unless you use a
programming guide.  Unfortunately, I don't have one that I can share
:-/

I think you would be much better off purchasing supported hardware, instead.

Good luck, though...

-Mike
--
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: Details about DVB frontend API

[Michael Krufky]

On Fri, Dec 4, 2009 at 3:02 PM, VDR User  wrote:
> No activity in this thread for 2 weeks now.  Has there been any progress?

I think I speak on behalf of most LinuxTV developers, when I say that
nobody wants to spend their free personal time working on something
that might get shot down with such controversy.

I have stated that I like Manu's proposal, but I would prefer that the
get_property (s2api) interface were used, because it totally provides
an interface that is sufficient for this feature.

Manu and I agree that these values should all be read at once.

I think we all (except Mauro) agree that the behavior within the
driver should fetch all statistics at once and return it to userspace
as a single structure with all the information as it all relates to
each other.

Furthermore, I think we all know that we cant just remove the current
structures, and we should do something to normalize the current
reporting values.

The longer this thread gets, the less likely anybody is to do anything about it.

Let me state my opinion again:

I would like to see a solution merged, and I think Manu's solution is
reasonable, although it may be complicated -- if all drivers are
updated to support it, then it will all be worth it.  The question is,
*will* all drivers update to support this?  I don't know.

We have the S2API's set / get property API -- In my opinion, we should
use this API to fetch statistic information and have it return a
single atomic structure.  Applications can use only the information
that they're interested in.

In the meanwhile, as a SEPARATE PROJECT, we should do something to
standardize the values reported by the CURRENT API across the entire
subsystem.  This should not be confused with Manu's initiative to
create a better API -- we cant remove the current API, but it should
be standardized.

I volunteer to work on the standardization of the CURRENT Api, and I
am all for seeing a new API introduced for better statistical
reporting, provided that the get property method is used as an
interface, rather than adding new ioctls.  However, if we add a new
API, we haev to make sure that all the current drivers are updated to
support it -- do we have all the information that we need for this?
Do we have the manpower and the drive to get it done?

My urge to do this work is a strong urge, but I have no desire to do
this if people want to continue arguing about it... In the meanwhile,
I am working on new drivers for new devices, and this is *much* more
interesting that worrying about how strong a signal is for a device
that already works.

When you folks stop talking about this, that's when I will push the
trees containing all the work that I've done already thus far -- we
need to standardize the current API, and that has nothing to do with
Manu's proposal.

We should not confuse standardization the current reporting units with
the introduction of a new API -- both should be done, but the more
arguing there is about it, the less of a chance that anybody will
volunteer their own time to work on it.

...and just to clarify -- I think I said it twice already, but
repeating again -- I (mostly) like Manu's proposal, but if we cant
update the drivers to support it, then is it worth the trouble?

Regards,

Mike Krufky
--
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: Details about DVB frontend API

[Michael Krufky]

On Sat, Dec 5, 2009 at 12:30 PM, Mauro Carvalho Chehab
 wrote:
> Michael Krufky wrote:
>> On Fri, Dec 4, 2009 at 3:02 PM, VDR User  wrote:
>> I have stated that I like Manu's proposal, but I would prefer that the
>> get_property (s2api) interface were used, because it totally provides
>> an interface that is sufficient for this feature.
>>
>> Manu and I agree that these values should all be read at once.
>>
>> I think we all (except Mauro) agree that the behavior within the
>> driver should fetch all statistics at once and return it to userspace
>> as a single structure with all the information as it all relates to
>> each other.
>
> You're contradicting yourself: by using S2API, the userspace API won't
> be using a single structure, since S2API will break them into pairs of
> attributes/values.

Incorrect.  Userspace would issue a get_property call and kernelspace
would return a block of key/value pairs.

> Nothing limits that the in-kernel API will group those values into a struct,
> but the internal API should be smart enough to not return to userspace
> the values that weren't requested by the call.

The call should be generic, something like get_property_signalstats
...  Kernelspace should return all related information, and userspace
should pick out what it needs.

-Mike
--
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] Add support for Zolid Hybrid PCI card

[Michael Krufky]

> 2009/9/14 Michael Krufky :
>> On Wed, Sep 9, 2009 at 11:08 AM, Michael Krufky  
>> wrote:
>>> On Wed, Sep 9, 2009 at 10:01 AM,   wrote:
>>>> On Tue, Sep 08, 2009 at 05:57:12PM -0400, Michael Krufky wrote:
>>>>>
>>>>> Henk,
>>>>>
>>>>> Why do you expect a 8295?  If your board uses the SAA7131, then we
>>>>> would expect an 8290 IF demod.
>>>>>
>>>>> Ah, I just checked the history of this email thread -- I must have
>>>>> read one of your previous emails too quickly.  :-)  Perhaps there is a
>>>>> typo in the document that you read -- tda8290 is correct.
>>>>>
>>>> Just to come back to this point,
>>>>
>>>> Well zolid has a SAA7131E, if you look at the datasheet (botom of page 15)
>>>> http://www.nxp.com/acrobat_download/datasheets/SAA7131E_3.pdf
>>>>
>>>> it says:
>>>> "The SAA7131E is functionally compatible with the SAA7135 audio and video
>>>> broadcast decoder device and the stand-alone low-IF device TDA8295."
>>>>
>>>> So thats why I asked.
>>>>
>>>> Regards,
>>>> Henk
>>>>
>>>
>>> FIX YOUR MAILER!!
>>>
>>> It's a pain to reply to your emails -- I have to insert your actual
>>> email address each time :-(
>>>
>>> Anyway, I am under the impression that it's a typo in the datasheet.
>>> It is actually a tda8290.
>>
>> Henk,
>>
>> Just FYI, I merged your patch to my saa7134 repository last week:
>>
>> http://www.kernellabs.com/hg/~mkrufky/saa7134
>>
>> I thought that I had replied to you already but that message seems to
>> have gotten dropped somewhere :-/
>>
>> I intend to send a pull request to Mauro for this, in addition to some
>> other pending patches after he merges what I have already pending.
>>
>> Thanks again for your work.
>>
>> Regards,
>>
>> Mike Krufky

On Tue, Dec 8, 2009 at 11:10 AM, Sander Pientka  wrote:
> I accidently sent this mail to Michael's private address, I'm sorry for that.
>
> Hi,
>
> I bought the same card a couple of months ago and back then, it just
> wouldn't work. I set up a wiki page, which henk has updated with links
> to patches, to document the card as well as possible. I set up a
> thread on this mailing list
> (http://osdir.com/ml/video4linux-list/2009-05/msg00102.html) on making
> the card work, but that resulted to nothing. I was surprised to find
> this thread when I accidently searched for "Zolid" in my mailbox. I'm
> at my internship at the moment, but I'll try this patch as soon as I
> get home :)
>
> If you need the card for further development/testing: I'm willing to
> send it to you by mail. I just want it back when you're done testing,
> so I can finally watch tv on my computer :)
>
>
> Greetings, Sander Pientka


Please do not top-quote.  The policy on this mailing list is to
include the reply BELOW the quoted text.

Anyway, don't even bother testing any patch -- just use the latest
v4l-dvb tree -- the code is all merged up.

Regards,

Mike
--
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: [GIT PULL for 2.6.32] V4L/DVB updates

[Michael Krufky]

On Thu, Dec 10, 2009 at 10:04 AM, Mauro Carvalho Chehab
 wrote:
> Em Tue, 1 Dec 2009 20:21:52 -0600 (CST)
> Mike Isely  escreveu:
>
>> On Tue, 1 Dec 2009, Mauro Carvalho Chehab wrote:
>>
>> > Mike Isely wrote:
>> > > On Mon, 30 Nov 2009, Mauro Carvalho Chehab wrote:
>> > >
>> > >> Em Sat, 28 Nov 2009 14:33:30 -0600 (CST)
>> > >> Mike Isely  escreveu:
>> > >>
>> > >>> Mauro:
>> > >>>
>> > >>> I had also posted up two high priority pvrusb2 patches that should
>> > >>> really be cherry-picked for 2.6.32.  You've already pulled them into
>> > >>> v4l/dvb and I did mark them as high priority at the time.
>> > >>>
>> > >>> These patches enable use of FX2 microcontroller firmware that is 16KB 
>> > >>> in
>> > >>> size.  Hauppauge is no longer shipping 8KB firmware for HVR-1950 and
>> > >>> HVR-1900 and without these changes then those devices won't work AT ALL
>> > >>> in kernel 2.6.32.
>> > >>>
>> > >>> You can find these within the v4l-dvb Mercurial repository here:
>> > >>>
>> > >>> Changeset 13495:87c3853fe2b3
>> > >>> Subject: pvrusb2: Support 16KB FX2 firmware
>> > >>> http://linuxtv.org/hg/v4l-dvb/rev/87c3853fe2b3
>> > >>>
>> > >>> Changeset 13500:d4c418d4b25c
>> > >>> Subject: pvrusb2: Fix lingering 16KB FX2 Firmware issues
>> > >>> http://linuxtv.org/hg/v4l-dvb/rev/d4c418d4b25c
>> > >>>
>> > >>> I do not believe these patches have any ordering dependencies with 
>> > >>> other
>> > >>> patches, though between the two the second one technically should come
>> > >>> after the first.
>> > >
>> > >
>> > >
>> > >> There are. Picking just those patches broke compilation.
>> > >
>> > > Mauro:
>> > >
>> > > Please forward to me the compilation errors.  Right now I am just not
>> > > seeing how a patch this trivial could have any compilation dependencies.
>> > > And unfortunately I will not be able to reproduce your build setup until
>> > > at least Tuesday night.  I must be blind.
>> > >
>> > >
>> > >> Also, it seemed too late for adding support for newer boards/firmware 
>> > >> when Linus
>> > >> is about to release a kernel.
>> > >
>> > > This is not a new feature.  It's a bug fix due to something that
>> > > Hauppauge recently did.  Hauppauge is NO LONGER officially distributing
>> > > FX2 firmware with their hardware which the driver can use.  This simply
>> > > prevents any new HVR-1950 / HVR-1900 users from working under Linux.
>> > > This fixes breakage for previously working hardware.  The root cause is
>> > > simple - the firmware blob is just larger now - and the fix is trivial.
>> > > It absolutely needs to go in.  In fact, this should go back to a
>> > > 2.6.31.x and a 2.6.27.x release as well, though in those cases I have to
>> > > figure out if driver source code is still close enough for the same
>> > > patches to still work.
>> > >
>> > > I am sorry this is showing up late for you.  There are multiple reasons
>> > > for this.  However I did mark these patches as "high priority",
>> > > following your v4l-dvb changeset process.  I did comment on the pull
>> > > request that these were important but I guess I needed to also
>> > > specifically call these out in the pull request text as well.
>> > >
>> > > If these don't get in now as part of the official 2.6.32 release, these
>> > > absolutely need to be queued for 2.6.32.1.
>> >
>> > We are very late for 2.6.32. I'm not sure if are there still time for it.
>> >
>> > I'll seek for some time during this week to add those patches at the 
>> > upstream
>> > tree and removing them from the development tree and see what compilation
>> > issues arise.
>>
>> Mauro:
>>
>> Thanks.
>>
>> Guess I also really need to get up to speed on git, finally...
>
> Hi Mike,
>
> Unfortunately, 2.6.32 were launched before we had time to rework on it, so, 
> it needs
> to be submitted for 2.6.32.1. The requisite for a patch to go to stable just
> happened: the patch needs to be upstream before going to stable. As Linus 
> already
> merged our changesets, now it is just a matter of sending an email to 
> sta...@kernel.org,
> with the patches.
>
> As I've explained before, the patches apply on the trees, but compilation were
> broken if the order of the changesets changed. I'm not sure if it
> broke happened at upstream+patches or at the devel tree.
>
> So, before submitting the patches, I suggest that you test them against a 
> vanilla 2.6.32.
> Please c/c on the email to stable.
>
> Generally, Mkrufky helps us with stable submissions, but, as I'm not seeing 
> him lately
> on IRC, maybe he is traveling or too busy those days.

I am still handling stable patches, but I don't have as much time
during the day to hang out in IRC.

All developers already know that they should notify me about stable
patches using my email address, mkrufky at linuxtv dot org.  ( i use
this kernellabs.org email mainly for special projects)

No serious business should ever be done on IRC, since the data could
get lost -- email stays in my inbox, so that's the best way to reach
me regarding linux 

[PULL] http://kernellabs.com/hg/~mkrufky/build-fix

[Michael Krufky]

Mauro,

Backwards compat got broken a few weeks ago... Please pull for the fix.

Please pull from:

http://kernellabs.com/hg/~mkrufky/build-fix

for:

- saa7134: fix build against older kernels

 saa7134-input.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cheers,

Mike
--
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] lgdt3305: make one-bit bitfields unsigned

[Michael Krufky]

Thanks -- I'll push this in through the lgdt3305 repository... I'll send 
in a pull request to Mauro shortly.


-Mike

Németh Márton wrote:

From: Márton Németh 

Make one-bit bitfields unsigned which will remove the following
sparse warning messages (see "make C=1"):
 * lgdt3305.h:57:21: error: dubious one-bit signed bitfield
 * lgdt3305.h:60:26: error: dubious one-bit signed bitfield
 * lgdt3305.h:63:19: error: dubious one-bit signed bitfield

Signed-off-by: Márton Németh 
---
diff -r ba8d6bf077aa linux/drivers/media/dvb/frontends/lgdt3305.h
--- a/linux/drivers/media/dvb/frontends/lgdt3305.h  Tue Dec 15 17:40:44 
2009 +0100
+++ b/linux/drivers/media/dvb/frontends/lgdt3305.h  Tue Dec 15 21:47:53 
2009 +0100
@@ -54,13 +54,13 @@
u16 usref_qam256; /* default: 0x2a80 */

/* disable i2c repeater - 0:repeater enabled 1:repeater disabled */
-   int deny_i2c_rptr:1;
+   unsigned int deny_i2c_rptr:1;

/* spectral inversion - 0:disabled 1:enabled */
-   int spectral_inversion:1;
+   unsigned int spectral_inversion:1;

/* use RF AGC loop - 0:disabled 1:enabled */
-   int rf_agc_loop:1;
+   unsigned int rf_agc_loop:1;

enum lgdt3305_mpeg_mode mpeg_mode;
enum lgdt3305_tp_clock_edge tpclk_edge;
  


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

[PULL] http://kernellabs.com/hg/~mkrufky/lgdt3305

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/lgdt3305

for the following:

- lgdt3305: make one-bit bitfields unsigned

 lgdt3305.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Thanks,

Mike

2009/12/15 Michael Krufky :
> Thanks -- I'll push this in through the lgdt3305 repository... I'll send in
> a pull request to Mauro shortly.
>
> -Mike
>
> Németh Márton wrote:
>>
>> From: Márton Németh 
>>
>> Make one-bit bitfields unsigned which will remove the following
>> sparse warning messages (see "make C=1"):
>>  * lgdt3305.h:57:21: error: dubious one-bit signed bitfield
>>  * lgdt3305.h:60:26: error: dubious one-bit signed bitfield
>>  * lgdt3305.h:63:19: error: dubious one-bit signed bitfield
>>
>> Signed-off-by: Márton Németh 
>> ---
>> diff -r ba8d6bf077aa linux/drivers/media/dvb/frontends/lgdt3305.h
>> --- a/linux/drivers/media/dvb/frontends/lgdt3305.h      Tue Dec 15
>> 17:40:44 2009 +0100
>> +++ b/linux/drivers/media/dvb/frontends/lgdt3305.h      Tue Dec 15
>> 21:47:53 2009 +0100
>> @@ -54,13 +54,13 @@
>>        u16 usref_qam256; /* default: 0x2a80 */
>>
>>        /* disable i2c repeater - 0:repeater enabled 1:repeater disabled */
>> -       int deny_i2c_rptr:1;
>> +       unsigned int deny_i2c_rptr:1;
>>
>>        /* spectral inversion - 0:disabled 1:enabled */
>> -       int spectral_inversion:1;
>> +       unsigned int spectral_inversion:1;
>>
>>        /* use RF AGC loop - 0:disabled 1:enabled */
>> -       int rf_agc_loop:1;
>> +       unsigned int rf_agc_loop:1;
>>
>>        enum lgdt3305_mpeg_mode mpeg_mode;
>>        enum lgdt3305_tp_clock_edge tpclk_edge;
>>
>
>
--
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

[PULL] http://kernellabs.com/hg/~mkrufky/tda8295

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/tda8295

for:

- tda8290: add autodetection support for TDA8295c2

 tda8290.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Cheers,

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

[PULL] http://kernellabs.com/hg/~mkrufky/tda8295

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/tda8295

for:

- tda8290: Fix FM radio easy programming standard selection for TDA8295

 tda8290.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Cheers,

Mike
--
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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

[Michael Krufky]

On Wed, Jan 13, 2010 at 8:44 AM, Mauro Carvalho Chehab
 wrote:
> Devin Heitmueller wrote:
>
>> You didn't forget about the em28xx PAL VBI tree, right?  I'm just
>> mentioning it because the PULL has been pending for several weeks and
>> came long before the PULL for the HVR-1600 ALSA changes.
>
> I tried to, but the hgimport script doesn't like https trees:
>
> $ ./hgimport https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2
> Pushing from local directory 
> https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2, 
> tree=em28xx-pal-vbi-2
> abort: repository 
> 'https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2' is not local
> Number of patches: 0
> Diffstat of the imported series:
> /tmp/newpatches/hg_em28xx-pal-vbi-2_*.patch: No such file or directory
> checkpatch.pl: /tmp/newpatches/*.patch: open failed - Arquivo ou diretório 
> não encontrado
> To cherry pick all files, you can do something like:
> for i in /tmp/newpatches/*.patch; do ./mailimport $i || exit; done
> To review all files, you can do something like:
> for i in /tmp/newpatches/*.patch; do ./v4l/scripts/hghead.pl 
> /tmp/newpatches/*.patch && kompare /tmp/newpatches/*.patch; done
> To merge it, the better is to run the merge script:
> ./v4l/scripts/do_merge.pl 
> https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2
>
> If you really want to submit https pull requests, please fix hgimport script 
> to accept (I would fix if I had enough time, but I'm with a big backlog, so 
> it is not my priority). Otherwise, please indicate me an http site for me to 
> pull.
>
> Thanks,
> Mauro

Mauro,

The same tree is also available using http instead of https:

http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2

This should work for you without issue.

Regards,

Mike
--
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: Order of dvb devices

[Michael Krufky]

On Thu, Jan 14, 2010 at 11:09 AM, Devin Heitmueller
 wrote:
> On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse  wrote:
>> yes if there are different drivers I already observed the behaviour that
>> the ordering gets flipped after reboot.
>>
>> But if I assume, that there is only *one* driver that is loaded (e.g.
>> budget_av) for all dvb cards in the system, how is the ordering of these
>> devices determined? How does the driver "search" for available dvb cards?
>
> I believe your assumption is incorrect.  I believe the enumeration
> order is not deterministic even for multiple instances of the same
> driver.  It is not uncommon to hear mythtv users complain that "I have
> two PVR-150 cards installed in my PC and the order sometimes get
> reversed on reboot".
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
> --
> 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
>

If you "modinfo dvb_adapter_driver_foo"  you will see an "adapter_nr"
module option -- you can use this to force your DVB adapter device
minor ordering.

Regards,

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

[HG PULL] http://kernellabs.com/hg/~mkrufky/tda18271-fix

[Michael Krufky]

Mauro,

Thanks for allowing me to continue sending pull requests via
mercurial.  These changes should apply cleanly against both hg and the
git tree.

Please pull from:

http://kernellabs.com/hg/~mkrufky/tda18271-fix

for the following TDA18271c2 RF Calibration fixes & updates:

- tda18271: fix calculation bug in tda18271_rf_tracking_filters_init
- tda18271: prog_cal and prog_tab variables should be s32, not u8
- tda18271: fix bad calculation of main post divider byte
- tda18271: update tda18271_rf_band as per NXP's rev.04 datasheet
- tda18271: update tda18271c2_rf_cal as per NXP's rev.04 datasheet

 tda18271-common.c |   11 +--
 tda18271-fe.c |   29 +++--
 tda18271-maps.c   |   12 ++--
 3 files changed, 22 insertions(+), 30 deletions(-)

Thanks to Stefan Sibiga for pointing out some of these driver bugs
--
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

[GIT PULL] git://sol.kernellabs.com/mk/mercury tveeprom

[Michael Krufky]

Mauro,

Please pull from the tveeprom branch at git://sol.kernellabs.com/mk/mercury:

The following changes since commit d733ed6c34be3aef0517a04e4103eed6b369ec50:

  Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block
(2011-04-16 10:33:41 -0700)

are available in the git repository at:

  git://sol.kernellabs.com/mk/mercury tveeprom

Michael Krufky (2):
  [media] tveeprom: update hauppauge tuner list thru 169
  [media] tveeprom: update hauppauge tuner list thru 174

 drivers/media/video/tveeprom.c |   32 +++-
 1 files changed, 19 insertions(+), 13 deletions(-)

Regards,

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

[PULL] http://linuxtv.org/hg/~mkrufky/k2c2

[Michael Krufky]

Mauro,

Please pull from:

http://linuxtv.org/hg/~mkrufky/k2c2

for the following changesets:

- cx23885: Add generic functions for driving GPIO's
- cx23885: mark functions encoder_on_port[bc] as static inline
- cx23885: Add preliminary support for the HVR1270
- cx23885: add ATSC/QAM tuning support for Hauppauge WinTV-HVR1270
- cx23885: add ATSC/QAM tuning support for Hauppauge WinTV-HVR1275
- cx23885: add ATSC/QAM tuning support for Hauppauge WinTV-HVR1255
- cx23885: add DVB-T tuning support for Hauppauge WinTV-HVR1210
- cx23885: update model matrix for "k2c2" retail boards
- cx23885: clean up struct names for Hauppauge WinTV-HVR127X devices

 Documentation/video4linux/CARDLIST.cx23885  |4
 drivers/media/video/cx23885/cx23885-cards.c |  107 +-
 drivers/media/video/cx23885/cx23885-core.c  |   86 +++-
 drivers/media/video/cx23885/cx23885-dvb.c   |   92 
 drivers/media/video/cx23885/cx23885.h   |   20 +
 5 files changed, 297 insertions(+), 12 deletions(-)

Cheers,

Mike
--
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] [09051_40] Siano - kconfig update

[Michael Krufky]

On Tue, May 19, 2009 at 7:58 AM, Uri Shkolnik  wrote:
>
> # HG changeset patch
> # User Uri Shkolnik 
> # Date 1242734522 -10800
> # Node ID c74502f4c8e97bd9cec9656793bbabc11fb72ab4
> # Parent  315bc4b65b4f527c4f9bc4fe3290e10f07975437
> [09051_40] Siano - kconfig update
>
> From: Uri Shkolnik 
>
> This patches comes to solve the comments on Siano's patch
> 0905_10. It updates the kconfig to support multi-modules build.
> Note that the dependency on dvb_core is for the (sms)dvb module
> alone, since the drivers set may work with another adapter.
>
> Priority: normal
>
> Signed-off-by: Uri Shkolnik 
>
> diff -r 315bc4b65b4f -r c74502f4c8e9 linux/drivers/media/dvb/siano/Kconfig
> --- a/linux/drivers/media/dvb/siano/Kconfig     Sun May 17 12:28:55 2009 +
> +++ b/linux/drivers/media/dvb/siano/Kconfig     Tue May 19 15:02:02 2009 +0300
> @@ -2,25 +2,40 @@
>  # Siano Mobile Silicon Digital TV device configuration
>  #
>
> -config DVB_SIANO_SMS1XXX
> -       tristate "Siano SMS1XXX USB dongle support"
> -       depends on DVB_CORE && USB
> +config SMS_SIANO_MDTV
> +       tristate "Siano SMS1xxx based MDTV receiver"
> +       default m
>        ---help---
> -         Choose Y here if you have a USB dongle with a SMS1XXX chipset.
> +       Choose Y or M here if you have MDTV receiver with a Siano chipset.
>
> -         To compile this driver as a module, choose M here: the
> -         module will be called sms1xxx.
> +       To compile this driver as a module, choose M here
> +       (The modules will be called smsmdtv).
>
> -config DVB_SIANO_SMS1XXX_SMS_IDS
> -       bool "Enable support for Siano Mobile Silicon default USB IDs"
> -       depends on DVB_SIANO_SMS1XXX
> -       default y
> +       Note: All dependents, if selected, will be part of this module.
> +
> +       Further documentation on this driver can be found on the WWW
> +       at http://www.siano-ms.com/
> +
> +if SMS_SIANO_MDTV
> +menu "Siano module components"
> +
> +# Kernel sub systems support
> +config SMS_DVB3_SUBSYS
> +       tristate "DVB v.3 Subsystem support"
> +       depends on DVB_CORE
> +       default m if DVB_CORE
>        ---help---
> -         Choose Y here if you have a USB dongle with a SMS1XXX chipset
> -         that uses Siano Mobile Silicon's default usb vid:pid.
> +       Choose if you would like to have DVB v.3 kernel sub-system support.
>
> -         Choose N here if you would prefer to use Siano's external driver.
> +# Hardware interfaces support
>
> -         Further documentation on this driver can be found on the WWW at
> -         .
> +config SMS_USB_DRV
> +       tristate "USB interface support"
> +       depends on USB
> +       default m if USB
> +       ---help---
> +       Choose if you would like to have Siano's support for USB interface
>
> +
> +endmenu
> +endif # SMS_SIANO_MDTV
>
>
>
>
> --
> 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
>



I have two concerns with this patch...


Issue #1, I dont see why it's important to rename the Kconfig symbol
from DVB_SIANO_SMS1XXX to SMS_SIANO_MDTV -- This will just cause
breakage of "make oldconfig" in the kernel with no real benefit.

Issue #2, a much bigger issue.  This patch implies that the Siano
driver can be built *with* DVB "v3" support, or without it.  Why would
a linux user ever want to built this driver without support for the
DVB API ?  (that's a loaded question) ...  Does Siano intend to push
their proprietary API into the kernel?

-Mike
--
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] [09051_43] Siano: Add new GPIO management interface

[Michael Krufky]

kmalloc(totalLen + SMS_DMA_ALIGNMENT,
> +                       GFP_KERNEL | GFP_DMA);
> +       if (!buffer)
> +               return -ENOMEM;
> +
> +       pMsg = (struct SetGpioMsg *) SMS_ALIGN_ADDRESS(buffer);
> +
> +       pMsg->xMsgHeader.msgSrcId = DVBT_BDA_CONTROL_MSG_ID;
> +       pMsg->xMsgHeader.msgDstId = HIF_TASK;
> +       pMsg->xMsgHeader.msgFlags = 0;
> +       pMsg->xMsgHeader.msgType = MSG_SMS_GPIO_GET_LEVEL_REQ;
> +       pMsg->xMsgHeader.msgLength = (u16) totalLen;
> +       pMsg->msgData[0] = PinNum;
> +       pMsg->msgData[1] = 0;
> +
> +       /* Send message to SMS */
> +       smsendian_handle_tx_message((struct SmsMsgHdr_ST *)pMsg);
> +       rc = smscore_sendrequest_and_wait(coredev, pMsg, totalLen,
> +                       &coredev->gpio_get_level_done);
> +
> +       if (rc != 0) {
> +               if (rc == -ETIME)
> +                       sms_err("smscore_gpio_get_level timeout");
> +               else
> +                       sms_err("smscore_gpio_get_level error");
> +       }
> +       kfree(buffer);
> +
> +       /* Its a race between other gpio_get_level() and the copy of the 
> single
> +        * global 'coredev->gpio_get_res' to  the function's variable 'level'
> +        */
> +       *level = coredev->gpio_get_res;
> +
> +       return rc;
>  }
>
>  static int __init smscore_module_init(void)
> diff -r 08e292f80f37 -r 749c11a362a9 
> linux/drivers/media/dvb/siano/smscoreapi.h
> --- a/linux/drivers/media/dvb/siano/smscoreapi.h        Tue May 19 16:30:40 
> 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/smscoreapi.h        Tue May 19 17:49:30 
> 2009 +0300
> @@ -550,7 +550,7 @@ struct SMSHOSTLIB_I2C_RES_ST {
>  };
>
>
> -struct smscore_gpio_config {
> +struct smscore_config_gpio {
>  #define SMS_GPIO_DIRECTION_INPUT  0
>  #define SMS_GPIO_DIRECTION_OUTPUT 1
>        u8 direction;
> @@ -574,6 +574,48 @@ struct smscore_gpio_config {
>  #define SMS_GPIO_OUTPUTDRIVING_12mA 2
>  #define SMS_GPIO_OUTPUTDRIVING_16mA 3
>        u8 outputdriving;
> +};
> +
> +struct smscore_gpio_config {
> +#define SMS_GPIO_DIRECTION_INPUT  0
> +#define SMS_GPIO_DIRECTION_OUTPUT 1
> +       u8 Direction;
> +
> +#define SMS_GPIO_PULLUPDOWN_NONE     0
> +#define SMS_GPIO_PULLUPDOWN_PULLDOWN 1
> +#define SMS_GPIO_PULLUPDOWN_PULLUP   2
> +#define SMS_GPIO_PULLUPDOWN_KEEPER   3
> +       u8 PullUpDown;
> +
> +#define SMS_GPIO_INPUT_CHARACTERISTICS_NORMAL  0
> +#define SMS_GPIO_INPUT_CHARACTERISTICS_SCHMITT 1
> +       u8 InputCharacteristics;
> +
> +#define SMS_GPIO_OUTPUT_SLEW_RATE_SLOW         1 /* 10xx */
> +#define SMS_GPIO_OUTPUT_SLEW_RATE_FAST         0 /* 10xx */
> +
> +
> +#define SMS_GPIO_OUTPUT_SLEW_RATE_0_45_V_NS    0 /* 11xx */
> +#define SMS_GPIO_OUTPUT_SLEW_RATE_0_9_V_NS     1 /* 11xx */
> +#define SMS_GPIO_OUTPUT_SLEW_RATE_1_7_V_NS     2 /* 11xx */
> +#define SMS_GPIO_OUTPUT_SLEW_RATE_3_3_V_NS     3 /* 11xx */
> +       u8 OutputSlewRate;
> +
> +#define SMS_GPIO_OUTPUT_DRIVING_S_4mA          0 /* 10xx */
> +#define SMS_GPIO_OUTPUT_DRIVING_S_8mA          1 /* 10xx */
> +#define SMS_GPIO_OUTPUT_DRIVING_S_12mA         2 /* 10xx */
> +#define SMS_GPIO_OUTPUT_DRIVING_S_16mA         3 /* 10xx */
> +
> +#define SMS_GPIO_OUTPUT_DRIVING_1_5mA          0 /* 11xx */
> +#define SMS_GPIO_OUTPUT_DRIVING_2_8mA          1 /* 11xx */
> +#define SMS_GPIO_OUTPUT_DRIVING_4mA                    2 /* 11xx */
> +#define SMS_GPIO_OUTPUT_DRIVING_7mA                    3 /* 11xx */
> +#define SMS_GPIO_OUTPUT_DRIVING_10mA                   4 /* 11xx */
> +#define SMS_GPIO_OUTPUT_DRIVING_11mA                   5 /* 11xx */
> +#define SMS_GPIO_OUTPUT_DRIVING_14mA                   6 /* 11xx */
> +#undef SMS_GPIO_OUTPUT_DRIVING_16mA
> +#define SMS_GPIO_OUTPUT_DRIVING_16mA                   7 /* 11xx */
> +       u8 OutputDriving;
>  };
>
>  extern void smscore_registry_setmode(char *devpath, int mode);
> @@ -619,9 +661,18 @@ extern void smscore_putbuffer(struct sms
>  extern void smscore_putbuffer(struct smscore_device_t *coredev,
>                              struct smscore_buffer_t *cb);
>
> +/* old GPIO managment */
>  int smscore_configure_gpio(struct smscore_device_t *coredev, u32 pin,
> -                          struct smscore_gpio_config *pinconfig);
> +                          struct smscore_config_gpio *pinconfig);
>  int smscore_set_gpio(struct smscore_device_t *coredev, u32 pin, int level);
> +
> +/* new GPIO managment */
> +extern int smscore_gpio_configure(struct smscore_device_t *coredev, u8 
> PinNum,
> +               struct smscore_gpio_config *pGpioConfig);
> +extern int smscore_gpio_set_level(struct smscore_device_t *coredev, u8 
> PinNum,
> +               u8 NewLevel);
> +extern int smscore_gpio_get_level(struct smscore_device_t *coredev, u8 
> PinNum,
> +               u8 *level);
>
>  void smscore_set_board_id(struct smscore_device_t *core, int id);
>  int smscore_get_board_id(struct smscore_device_t *core);
>
>
>
>
> --
> 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
>




Mauro,

I am OK with this changeset, since the old GPIO functions were left
intact.  I haven't actually TESTED this patch, but I will do so after
it's merged.

After Uri is done with his changes, I will cleanup the Hauppauge code
for GPIO handling, to remove the duplicated functionality.

It would have been cleaner to simply add the "wait" flag to the new
gpio function, but I cant tell Uri what to do -- this is OK for now.

Acked-by: Michael Krufky 
--
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] [09051_47] Siano: smsdvb - add DVB v3 events

[Michael Krufky]

On Tue, May 19, 2009 at 11:28 AM, Uri Shkolnik  wrote:
>
> # HG changeset patch
> # User Uri Shkolnik 
> # Date 1242747164 -10800
> # Node ID 971d4cc0d4009650bd4752c6a9fc09755ef77baf
> # Parent  98895daafb42f8b0757fd608b29c53c80327520e
> [09051_47] Siano: smsdvb - add DVB v3 events
>
> From: Uri Shkolnik 
>
> Add various DVB-API v3 events, those events will trig
> target (card) events.
>
> Priority: normal
>
> Signed-off-by: Uri Shkolnik 
>
> diff -r 98895daafb42 -r 971d4cc0d400 linux/drivers/media/dvb/siano/smsdvb.c
> --- a/linux/drivers/media/dvb/siano/smsdvb.c    Tue May 19 18:27:38 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/smsdvb.c    Tue May 19 18:32:44 2009 +0300
> @@ -66,6 +66,54 @@ MODULE_PARM_DESC(debug, "set debug level
>  /* Events that may come from DVB v3 adapter */
>  static void sms_board_dvb3_event(struct smsdvb_client_t *client,
>                enum SMS_DVB3_EVENTS event) {
> +
> +       struct smscore_device_t *coredev = client->coredev;
> +       switch (event) {
> +       case DVB3_EVENT_INIT:
> +               sms_debug("DVB3_EVENT_INIT");
> +               sms_board_event(coredev, BOARD_EVENT_BIND);
> +               break;
> +       case DVB3_EVENT_SLEEP:
> +               sms_debug("DVB3_EVENT_SLEEP");
> +               sms_board_event(coredev, BOARD_EVENT_POWER_SUSPEND);
> +               break;
> +       case DVB3_EVENT_HOTPLUG:
> +               sms_debug("DVB3_EVENT_HOTPLUG");
> +               sms_board_event(coredev, BOARD_EVENT_POWER_INIT);
> +               break;
> +       case DVB3_EVENT_FE_LOCK:
> +               if (client->event_fe_state != DVB3_EVENT_FE_LOCK) {
> +                       client->event_fe_state = DVB3_EVENT_FE_LOCK;
> +                       sms_debug("DVB3_EVENT_FE_LOCK");
> +                       sms_board_event(coredev, BOARD_EVENT_FE_LOCK);
> +               }
> +               break;
> +       case DVB3_EVENT_FE_UNLOCK:
> +               if (client->event_fe_state != DVB3_EVENT_FE_UNLOCK) {
> +                       client->event_fe_state = DVB3_EVENT_FE_UNLOCK;
> +                       sms_debug("DVB3_EVENT_FE_UNLOCK");
> +                       sms_board_event(coredev, BOARD_EVENT_FE_UNLOCK);
> +               }
> +               break;
> +       case DVB3_EVENT_UNC_OK:
> +               if (client->event_unc_state != DVB3_EVENT_UNC_OK) {
> +                       client->event_unc_state = DVB3_EVENT_UNC_OK;
> +                       sms_debug("DVB3_EVENT_UNC_OK");
> +                       sms_board_event(coredev, BOARD_EVENT_MULTIPLEX_OK);
> +               }
> +               break;
> +       case DVB3_EVENT_UNC_ERR:
> +               if (client->event_unc_state != DVB3_EVENT_UNC_ERR) {
> +                       client->event_unc_state = DVB3_EVENT_UNC_ERR;
> +                       sms_debug("DVB3_EVENT_UNC_ERR");
> +                       sms_board_event(coredev, 
> BOARD_EVENT_MULTIPLEX_ERRORS);
> +               }
> +               break;
> +
> +       default:
> +               sms_err("Unknown dvb3 api event");
> +               break;
> +       }
>  }
>
>  static int smsdvb_onresponse(void *context, struct smscore_buffer_t *cb)
>
>
>
>
> --
> 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
>



Uri,

I don't understand what prompts you to call these "DVB v3 events" ...
what does this have to do with DVB API v3 at all?  Your idea seems to
be in the right direction, but this "DVBV3" nomenclature is a total
misnomer.

I think something along the lines of SMSBOARD_EVENT_FOO is more appropriate.

Regards,

Mike
--
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] [09051_49] Siano: smscore - upgrade firmware loading engine

[Michael Krufky]

On Tue, May 19, 2009 at 11:43 AM, Uri Shkolnik  wrote:
>
> # HG changeset patch
> # User Uri Shkolnik 
> # Date 1242748115 -10800
> # Node ID 4d75f9d1c4f96d65a8ad312c21e488a212ee58a3
> # Parent  cfb4106f3ceaee9fe8f7e3acc9d4adec1baffe5e
> [09051_49] Siano: smscore - upgrade firmware loading engine
>
> From: Uri Shkolnik 
>
> Upgrade the firmware loading (download and switching) engine.
>
> Priority: normal
>
> Signed-off-by: Uri Shkolnik 
>
> diff -r cfb4106f3cea -r 4d75f9d1c4f9 
> linux/drivers/media/dvb/siano/smscoreapi.c
> --- a/linux/drivers/media/dvb/siano/smscoreapi.c        Tue May 19 18:38:07 
> 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/smscoreapi.c        Tue May 19 18:48:35 
> 2009 +0300
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -36,7 +36,13 @@
>  #include "smscoreapi.h"
>  #include "sms-cards.h"
>  #include "smsir.h"
> -#include "smsendian.h"
> +#define MAX_GPIO_PIN_NUMBER    31
> +
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 10)
> +#define REQUEST_FIRMWARE_SUPPORTED
> +#else
> +#define DEFAULT_FW_FILE_PATH "/lib/firmware"
> +#endif
>
>  static int sms_dbg;
>  module_param_named(debug, sms_dbg, int, 0644);
> @@ -459,8 +465,6 @@ static int smscore_init_ir(struct smscor
>                                msg->msgData[0] = coredev->ir.controller;
>                                msg->msgData[1] = coredev->ir.timeout;
>
> -                               smsendian_handle_tx_message(
> -                                       (struct SmsMsgHdr_ST2 *)msg);
>                                rc = smscore_sendrequest_and_wait(coredev, msg,
>                                                msg->xMsgHeader. msgLength,
>                                                &coredev->ir_init_done);
> @@ -486,12 +490,16 @@ static int smscore_init_ir(struct smscor
>  */
>  int smscore_start_device(struct smscore_device_t *coredev)
>  {
> -       int rc = smscore_set_device_mode(
> -                       coredev, smscore_registry_getmode(coredev->devpath));
> +       int rc;
> +
> +#ifdef REQUEST_FIRMWARE_SUPPORTED
> +       rc = smscore_set_device_mode(coredev, smscore_registry_getmode(
> +                       coredev->devpath));
>        if (rc < 0) {
> -               sms_info("set device mode faile , rc %d", rc);
> +               sms_info("set device mode failed , rc %d", rc);
>                return rc;
>        }
> +#endif
>
>        kmutex_lock(&g_smscore_deviceslock);
>
> @@ -632,11 +640,14 @@ static int smscore_load_firmware_from_fi
>                                           loadfirmware_t loadfirmware_handler)
>  {
>        int rc = -ENOENT;
> +       u8 *fw_buf;
> +       u32 fw_buf_size;
> +
> +#ifdef REQUEST_FIRMWARE_SUPPORTED
>        const struct firmware *fw;
> -       u8 *fw_buffer;
>
> -       if (loadfirmware_handler == NULL && !(coredev->device_flags &
> -                                             SMS_DEVICE_FAMILY2))
> +       if (loadfirmware_handler == NULL && !(coredev->device_flags
> +                       & SMS_DEVICE_FAMILY2))
>                return -EINVAL;
>
>        rc = request_firmware(&fw, filename, coredev->device);
> @@ -645,26 +656,36 @@ static int smscore_load_firmware_from_fi
>                return rc;
>        }
>        sms_info("read FW %s, size=%zd", filename, fw->size);
> -       fw_buffer = kmalloc(ALIGN(fw->size, SMS_ALLOC_ALIGNMENT),
> -                           GFP_KERNEL | GFP_DMA);
> -       if (fw_buffer) {
> -               memcpy(fw_buffer, fw->data, fw->size);
> +       fw_buf = kmalloc(ALIGN(fw->size, SMS_ALLOC_ALIGNMENT),
> +                               GFP_KERNEL | GFP_DMA);
> +       if (!fw_buf) {
> +               sms_info("failed to allocate firmware buffer");
> +               return -ENOMEM;
> +       }
> +       memcpy(fw_buf, fw->data, fw->size);
> +       fw_buf_size = fw->size;
> +#else
> +       if (!coredev->fw_buf) {
> +               sms_info("missing fw file buffer");
> +               return -EINVAL;
> +       }
> +       fw_buf = coredev->fw_buf;
> +       fw_buf_size = coredev->fw_buf_size;
> +#endif
>
> -               rc = (coredev->device_flags & SMS_DEVICE_FAMILY2) ?
> -                     smscore_load_firmware_family2(coredev,
> -                                                   fw_buffer,
> -                                                   fw->size) :
> -                     loadfirmware_handler(coredev->context,
> -                                          fw_buffer, fw->size);
> +       rc = (coredev->device_flags & SMS_DEVICE_FAMILY2) ?
> +               smscore_load_firmware_family2(coredev, fw_buf, fw_buf_size)
> +               : loadfirmware_handler(coredev->context, fw_buf,
> +               fw_buf_size);
>
> -               kfree(fw_buffer);
> -       } else {
> -               sms_info("failed to allocate firmware buffer");
> -               rc = -ENOMEM;
> -       }
> +       kfree(fw_buf);
>
> +#ifdef REQUEST_FIRMWARE_SUPPORTED

Re: [PATCH] [09051_54] Siano: remove obsolete sms_board_setup

[Michael Krufky]

On Tue, May 19, 2009 at 12:15 PM, Uri Shkolnik  wrote:
>
> # HG changeset patch
> # User Uri Shkolnik 
> # Date 1242749967 -10800
> # Node ID 0296b0c436d6deba48c710cfb510988267cea057
> # Parent  dfcfb90798d3a27cb174019b17fffdee9ce7b2b9
> [09051_54] Siano: remove obsolete sms_board_setup
>
> From: Uri Shkolnik 
>
> Remove the target specific sms_board_setup from smsdvb. This
> is handled now via smsdvb and sms-cards events.
>
> Priority: normal
>
> Signed-off-by: Uri Shkolnik 
>
> diff -r dfcfb90798d3 -r 0296b0c436d6 linux/drivers/media/dvb/siano/sms-cards.c
> --- a/linux/drivers/media/dvb/siano/sms-cards.c Tue May 19 19:05:02 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/sms-cards.c Tue May 19 19:19:27 2009 +0300
> @@ -303,28 +303,6 @@ static int sms_set_gpio(struct smscore_d
>        return smscore_set_gpio(coredev, gpio, lvl);
>  }
>
> -int sms_board_setup(struct smscore_device_t *coredev)
> -{
> -       int board_id = smscore_get_board_id(coredev);
> -       struct sms_board *board = sms_get_board(board_id);
> -
> -       switch (board_id) {
> -       case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
> -               /* turn off all LEDs */
> -               sms_set_gpio(coredev, board->led_power, 0);
> -               sms_set_gpio(coredev, board->led_hi, 0);
> -               sms_set_gpio(coredev, board->led_lo, 0);
> -               break;
> -       case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
> -       case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD:
> -               /* turn off LNA */
> -               sms_set_gpio(coredev, board->lna_ctrl, 0);
> -               break;
> -       }
> -       return 0;
> -}
> -EXPORT_SYMBOL_GPL(sms_board_setup);
> -
>  int sms_board_power(struct smscore_device_t *coredev, int onoff)
>  {
>        int board_id = smscore_get_board_id(coredev);
> diff -r dfcfb90798d3 -r 0296b0c436d6 linux/drivers/media/dvb/siano/sms-cards.h
> --- a/linux/drivers/media/dvb/siano/sms-cards.h Tue May 19 19:05:02 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/sms-cards.h Tue May 19 19:19:27 2009 +0300
> @@ -109,8 +109,6 @@ int sms_board_event(struct smscore_devic
>  int sms_board_event(struct smscore_device_t *coredev,
>                enum SMS_BOARD_EVENTS gevent);
>
> -int sms_board_setup(struct smscore_device_t *coredev);
> -
>  #define SMS_LED_OFF 0
>  #define SMS_LED_LO  1
>  #define SMS_LED_HI  2
> diff -r dfcfb90798d3 -r 0296b0c436d6 linux/drivers/media/dvb/siano/smsdvb.c
> --- a/linux/drivers/media/dvb/siano/smsdvb.c    Tue May 19 19:05:02 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/smsdvb.c    Tue May 19 19:19:27 2009 +0300
> @@ -600,7 +600,6 @@ static int smsdvb_hotplug(struct smscore
>        sms_board_dvb3_event(client, DVB3_EVENT_HOTPLUG);
>
>        sms_info("success");
> -       sms_board_setup(coredev);
>
>        return 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
>



NACK.


This changes the behavior of the Hauppauge devices.  Let Uri get all
his other stuff in place first, and THEN we can look at this
separately.

In addition, this changeset was merged WITHOUT my ack:

http://linuxtv.org/hg/v4l-dvb/rev/37969546eee8 - Siano: smscards -
assign gpio to HPG targets

That changeset 37969546eee8 alone does not cause any change in
behavior, but with Uri's patches from today it will change the
Hauppauge device behavior.

That patch should be reverted and dealt with separately, after Uri is
finished with his other changes.

-Mike
--
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] [09051_55] Siano: smscards - merge the binding handling

[Michael Krufky]

On Tue, May 19, 2009 at 12:24 PM, Uri Shkolnik  wrote:
>
> # HG changeset patch
> # User Uri Shkolnik 
> # Date 1242750556 -10800
> # Node ID d92f2dfcb226c5f8b8c3216f7cf96126f7571702
> # Parent  0296b0c436d6deba48c710cfb510988267cea057
> [09051_55] Siano: smscards - merge the binding handling.
>
> From: Uri Shkolnik 
>
> Merge the bind handling into the events switch.
>
> Priority: normal
>
> Signed-off-by: Uri Shkolnik 
>
> diff -r 0296b0c436d6 -r d92f2dfcb226 linux/drivers/media/dvb/siano/sms-cards.c
> --- a/linux/drivers/media/dvb/siano/sms-cards.c Tue May 19 19:19:27 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/sms-cards.c Tue May 19 19:29:16 2009 +0300
> @@ -194,7 +194,13 @@ int sms_board_event(struct smscore_devic
>
>        case BOARD_EVENT_BIND:
>                switch (board_id) {
> +               case SMS1XXX_BOARD_HAUPPAUGE_CATAMOUNT:
> +               case SMS1XXX_BOARD_HAUPPAUGE_OKEMO_A:
> +               case SMS1XXX_BOARD_HAUPPAUGE_OKEMO_B:
> +                       request_module("smsdvb");
> +                       break;
>                case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
> +                       request_module("smsdvb");
>                        smscore_gpio_set_level(coredev,
>                                board->board_cfg.leds_power, 1);
>                        smscore_gpio_set_level(coredev,
> @@ -366,20 +372,3 @@ int sms_board_lna_control(struct smscore
>        return -EINVAL;
>  }
>  EXPORT_SYMBOL_GPL(sms_board_lna_control);
> -
> -int sms_board_load_modules(int id)
> -{
> -       switch (id) {
> -       case SMS1XXX_BOARD_HAUPPAUGE_CATAMOUNT:
> -       case SMS1XXX_BOARD_HAUPPAUGE_OKEMO_A:
> -       case SMS1XXX_BOARD_HAUPPAUGE_OKEMO_B:
> -       case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
> -               request_module("smsdvb");
> -               break;
> -       default:
> -               /* do nothing */
> -               break;
> -       }
> -       return 0;
> -}
> -EXPORT_SYMBOL_GPL(sms_board_load_modules);
>
>
>
>
> --
> 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
>

NACK

Again, let Uri finish his other changesets first, and settle down to a
stable state so that the Hauppauge devices can be tested before and
after these Hauppauge-specific changesets.

This puts the stability of Hauppauge device support in this driver
into jeopardy.

-Mike
--
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] [09051_54] Siano: remove obsolete sms_board_setup

[Michael Krufky]

On Tue, May 19, 2009 at 12:57 PM, Uri Shkolnik  wrote:
>
>
>
> --- On Tue, 5/19/09, Michael Krufky  wrote:
>
>> From: Michael Krufky 
>> Subject: Re: [PATCH] [09051_54] Siano: remove obsolete sms_board_setup
>> To: "Uri Shkolnik" 
>> Cc: "LinuxML" , "Mauro Carvalho Chehab" 
>> 
>> Date: Tuesday, May 19, 2009, 7:31 PM
>> On Tue, May 19, 2009 at 12:15 PM, Uri
>> Shkolnik 
>> wrote:
>> >
>> > # HG changeset patch
>> > # User Uri Shkolnik 
>> > # Date 1242749967 -10800
>> > # Node ID 0296b0c436d6deba48c710cfb510988267cea057
>> > # Parent  dfcfb90798d3a27cb174019b17fffdee9ce7b2b9
>> > [09051_54] Siano: remove obsolete sms_board_setup
>> >
>> > From: Uri Shkolnik 
>> >
>> > Remove the target specific sms_board_setup from
>> smsdvb. This
>> > is handled now via smsdvb and sms-cards events.
>> >
>> > Priority: normal
>> >
>> > Signed-off-by: Uri Shkolnik 
>> >
>> > diff -r dfcfb90798d3 -r 0296b0c436d6
>> linux/drivers/media/dvb/siano/sms-cards.c
>> > --- a/linux/drivers/media/dvb/siano/sms-cards.c Tue
>> May 19 19:05:02 2009 +0300
>> > +++ b/linux/drivers/media/dvb/siano/sms-cards.c Tue
>> May 19 19:19:27 2009 +0300
>> > @@ -303,28 +303,6 @@ static int sms_set_gpio(struct
>> smscore_d
>> >        return smscore_set_gpio(coredev, gpio,
>> lvl);
>> >  }
>> >
>> > -int sms_board_setup(struct smscore_device_t
>> *coredev)
>> > -{
>> > -       int board_id =
>> smscore_get_board_id(coredev);
>> > -       struct sms_board *board =
>> sms_get_board(board_id);
>> > -
>> > -       switch (board_id) {
>> > -       case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
>> > -               /* turn off all LEDs */
>> > -               sms_set_gpio(coredev,
>> board->led_power, 0);
>> > -               sms_set_gpio(coredev,
>> board->led_hi, 0);
>> > -               sms_set_gpio(coredev,
>> board->led_lo, 0);
>> > -               break;
>> > -       case
>> SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
>> > -       case
>> SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD:
>> > -               /* turn off LNA */
>> > -               sms_set_gpio(coredev,
>> board->lna_ctrl, 0);
>> > -               break;
>> > -       }
>> > -       return 0;
>> > -}
>> > -EXPORT_SYMBOL_GPL(sms_board_setup);
>> > -
>> >  int sms_board_power(struct smscore_device_t
>> *coredev, int onoff)
>> >  {
>> >        int board_id =
>> smscore_get_board_id(coredev);
>> > diff -r dfcfb90798d3 -r 0296b0c436d6
>> linux/drivers/media/dvb/siano/sms-cards.h
>> > --- a/linux/drivers/media/dvb/siano/sms-cards.h Tue
>> May 19 19:05:02 2009 +0300
>> > +++ b/linux/drivers/media/dvb/siano/sms-cards.h Tue
>> May 19 19:19:27 2009 +0300
>> > @@ -109,8 +109,6 @@ int sms_board_event(struct
>> smscore_devic
>> >  int sms_board_event(struct smscore_device_t
>> *coredev,
>> >                enum SMS_BOARD_EVENTS gevent);
>> >
>> > -int sms_board_setup(struct smscore_device_t
>> *coredev);
>> > -
>> >  #define SMS_LED_OFF 0
>> >  #define SMS_LED_LO  1
>> >  #define SMS_LED_HI  2
>> > diff -r dfcfb90798d3 -r 0296b0c436d6
>> linux/drivers/media/dvb/siano/smsdvb.c
>> > --- a/linux/drivers/media/dvb/siano/smsdvb.c    Tue
>> May 19 19:05:02 2009 +0300
>> > +++ b/linux/drivers/media/dvb/siano/smsdvb.c    Tue
>> May 19 19:19:27 2009 +0300
>> > @@ -600,7 +600,6 @@ static int smsdvb_hotplug(struct
>> smscore
>> >        sms_board_dvb3_event(client,
>> DVB3_EVENT_HOTPLUG);
>> >
>> >        sms_info("success");
>> > -       sms_board_setup(coredev);
>> >
>> >        return 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
>> >
>>
>>
>>
>> NACK.
>>
>>
>> This changes the behavior of the Hauppauge devices.
>> Let Uri get all
>> his other stuff in place first, and THEN we can look at
>> this
>> separately.
>>
>> In addition, 

Re: [PATCH] [09051_57] Siano: smscards - remove redundant code

[Michael Krufky]

On Tue, May 19, 2009 at 12:46 PM, Uri Shkolnik  wrote:
>
> # HG changeset patch
> # User Uri Shkolnik 
> # Date 1242751824 -10800
> # Node ID fd16bcd8b9f1fffe0b605ca5b3b2138fc920e927
> # Parent  f78cbc153c82ebe58a1bbe82271b91f5a4a90642
> [09051_57] Siano: smscards - remove redundant code
>
> From: Uri Shkolnik 
>
> Remove code that has been duplicate with the new boards events manager
>
> Priority: normal
>
> Signed-off-by: Uri Shkolnik 
>
> diff -r f78cbc153c82 -r fd16bcd8b9f1 linux/drivers/media/dvb/siano/sms-cards.c
> --- a/linux/drivers/media/dvb/siano/sms-cards.c Tue May 19 19:45:05 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/sms-cards.c Tue May 19 19:50:24 2009 +0300
> @@ -281,98 +281,3 @@ int sms_board_event(struct smscore_devic
>        return 0;
>  }
>  EXPORT_SYMBOL_GPL(sms_board_event);
> -
> -static int sms_set_gpio(struct smscore_device_t *coredev, int pin, int 
> enable)
> -{
> -       int lvl, ret;
> -       u32 gpio;
> -       struct smscore_config_gpio gpioconfig = {
> -               .direction            = SMS_GPIO_DIRECTION_OUTPUT,
> -               .pullupdown           = SMS_GPIO_PULLUPDOWN_NONE,
> -               .inputcharacteristics = SMS_GPIO_INPUTCHARACTERISTICS_NORMAL,
> -               .outputslewrate       = SMS_GPIO_OUTPUTSLEWRATE_FAST,
> -               .outputdriving        = SMS_GPIO_OUTPUTDRIVING_4mA,
> -       };
> -
> -       if (pin == 0)
> -               return -EINVAL;
> -
> -       if (pin < 0) {
> -               /* inverted gpio */
> -               gpio = pin * -1;
> -               lvl = enable ? 0 : 1;
> -       } else {
> -               gpio = pin;
> -               lvl = enable ? 1 : 0;
> -       }
> -
> -       ret = smscore_configure_gpio(coredev, gpio, &gpioconfig);
> -       if (ret < 0)
> -               return ret;
> -
> -       return smscore_set_gpio(coredev, gpio, lvl);
> -}
> -
> -int sms_board_power(struct smscore_device_t *coredev, int onoff)
> -{
> -       int board_id = smscore_get_board_id(coredev);
> -       struct sms_board *board = sms_get_board(board_id);
> -
> -       switch (board_id) {
> -       case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
> -               /* power LED */
> -               sms_set_gpio(coredev,
> -                            board->led_power, onoff ? 1 : 0);
> -               break;
> -       case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
> -       case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD:
> -               /* LNA */
> -               if (!onoff)
> -                       sms_set_gpio(coredev, board->lna_ctrl, 0);
> -               break;
> -       }
> -       return 0;
> -}
> -EXPORT_SYMBOL_GPL(sms_board_power);
> -
> -int sms_board_led_feedback(struct smscore_device_t *coredev, int led)
> -{
> -       int board_id = smscore_get_board_id(coredev);
> -       struct sms_board *board = sms_get_board(board_id);
> -
> -       /* dont touch GPIO if LEDs are already set */
> -       if (smscore_led_state(coredev, -1) == led)
> -               return 0;
> -
> -       switch (board_id) {
> -       case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
> -               sms_set_gpio(coredev,
> -                            board->led_lo, (led & SMS_LED_LO) ? 1 : 0);
> -               sms_set_gpio(coredev,
> -                            board->led_hi, (led & SMS_LED_HI) ? 1 : 0);
> -
> -               smscore_led_state(coredev, led);
> -               break;
> -       }
> -       return 0;
> -}
> -EXPORT_SYMBOL_GPL(sms_board_led_feedback);
> -
> -int sms_board_lna_control(struct smscore_device_t *coredev, int onoff)
> -{
> -       int board_id = smscore_get_board_id(coredev);
> -       struct sms_board *board = sms_get_board(board_id);
> -
> -       sms_debug("%s: LNA %s", __func__, onoff ? "enabled" : "disabled");
> -
> -       switch (board_id) {
> -       case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
> -       case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD:
> -               sms_set_gpio(coredev,
> -                            board->rf_switch, onoff ? 1 : 0);
> -               return sms_set_gpio(coredev,
> -                                   board->lna_ctrl, onoff ? 1 : 0);
> -       }
> -       return -EINVAL;
> -}
> -EXPORT_SYMBOL_GPL(sms_board_lna_control);
> diff -r f78cbc153c82 -r fd16bcd8b9f1 linux/drivers/media/dvb/siano/sms-cards.h
> --- a/linux/drivers/media/dvb/siano/sms-cards.h Tue May 19 19:45:05 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/sms-cards.h Tue May 19 19:50:24 2009 +0300
> @@ -110,11 +110,4 @@ int sms_board_event(struct smscore_devic
>  int sms_board_event(struct smscore_device_t *coredev,
>                enum SMS_BOARD_EVENTS gevent);
>
> -#define SMS_LED_OFF 0
> -#define SMS_LED_LO  1
> -#define SMS_LED_HI  2
> -int sms_board_led_feedback(struct smscore_device_t *coredev, int led);
> -int sms_board_power(struct smscore_device_t *coredev, int onoff);
> -int sms_board_lna_control(struct smscore_device_t *coredev, int onoff);
> -
>  #endif /* __SMS_CARDS_H__ */
>
>
>
>
> --
> To unsubscribe from this list: send 

Re: [PATCH] [09051_58] Siano: remove obsolete code

[Michael Krufky]

On Tue, May 19, 2009 at 12:54 PM, Uri Shkolnik  wrote:
>
> # HG changeset patch
> # User Uri Shkolnik 
> # Date 1242752280 -10800
> # Node ID 0c33837206742f128aa033b2c9fb80c725e48dd7
> # Parent  fd16bcd8b9f1fffe0b605ca5b3b2138fc920e927
> [09051_58] Siano: remove obsolete code
>
> From: Uri Shkolnik 
>
> Remove obsolete code - old gpio managment (totaly bogus),
> and its dependent code from cards.
>
> Priority: normal
>
> Signed-off-by: Uri Shkolnik 
>
> diff -r fd16bcd8b9f1 -r 0c3383720674 linux/drivers/media/dvb/siano/sms-cards.c
> --- a/linux/drivers/media/dvb/siano/sms-cards.c Tue May 19 19:50:24 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/sms-cards.c Tue May 19 19:58:00 2009 +0300
> @@ -66,24 +66,17 @@ static struct sms_board sms_boards[] = {
>                .board_cfg.leds_power = 26,
>                .board_cfg.led0 = 27,
>                .board_cfg.led1 = 28,
> -               .led_power = 26,
> -               .led_lo    = 27,
> -               .led_hi    = 28,
>        },
>        [SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD] = {
>                .name   = "Hauppauge WinTV MiniCard",
>                .type   = SMS_NOVA_B0,
>                .fw[DEVICE_MODE_DVBT_BDA] = "sms1xxx-hcw-55xxx-dvbt-02.fw",
> -               .lna_ctrl  = 29,
>                .board_cfg.foreign_lna0_ctrl = 29,
> -               .rf_switch = 17,
> -               .board_cfg.rf_switch_uhf = 17,
>        },
>        [SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2] = {
>                .name   = "Hauppauge WinTV MiniCard",
>                .type   = SMS_NOVA_B0,
>                .fw[DEVICE_MODE_DVBT_BDA] = "sms1xxx-hcw-55xxx-dvbt-02.fw",
> -               .lna_ctrl  = -1,
>        },
>        [SMS1XXX_BOARD_SIANO_NICE] = {
>        /* 11 */
> diff -r fd16bcd8b9f1 -r 0c3383720674 linux/drivers/media/dvb/siano/sms-cards.h
> --- a/linux/drivers/media/dvb/siano/sms-cards.h Tue May 19 19:50:24 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/sms-cards.h Tue May 19 19:58:00 2009 +0300
> @@ -76,9 +76,6 @@ struct sms_board {
>        char *name, *fw[DEVICE_MODE_MAX];
>        struct sms_board_gpio_cfg board_cfg;
>        enum ir_kb_type ir_kb_type;
> -
> -       /* gpios */
> -       int led_power, led_hi, led_lo, lna_ctrl, rf_switch;
>  };
>
>  struct sms_board *sms_get_board(int id);
> diff -r fd16bcd8b9f1 -r 0c3383720674 
> linux/drivers/media/dvb/siano/smscoreapi.c
> --- a/linux/drivers/media/dvb/siano/smscoreapi.c        Tue May 19 19:50:24 
> 2009 +0300
> +++ b/linux/drivers/media/dvb/siano/smscoreapi.c        Tue May 19 19:58:00 
> 2009 +0300
> @@ -74,14 +74,6 @@ void smscore_set_board_id(struct smscore
>  {
>        core->board_id = id;
>  }
> -
> -int smscore_led_state(struct smscore_device_t *core, int led)
> -{
> -       if (led >= 0)
> -               core->led_state = led;
> -       return core->led_state;
> -}
> -EXPORT_SYMBOL_GPL(smscore_set_board_id);
>
>  int smscore_get_board_id(struct smscore_device_t *core)
>  {
> @@ -1451,78 +1443,6 @@ static int smscore_map_common_buffer(str
>  }
>  #endif /* SMS_HOSTLIB_SUBSYS */
>
> -/* old GPIO managments implementation */
> -int smscore_configure_gpio(struct smscore_device_t *coredev, u32 pin,
> -                          struct smscore_config_gpio *pinconfig)
> -{
> -       struct {
> -               struct SmsMsgHdr_ST hdr;
> -               u32 data[6];
> -       } msg;
> -
> -       if (coredev->device_flags & SMS_DEVICE_FAMILY2) {
> -               msg.hdr.msgSrcId = DVBT_BDA_CONTROL_MSG_ID;
> -               msg.hdr.msgDstId = HIF_TASK;
> -               msg.hdr.msgFlags = 0;
> -               msg.hdr.msgType  = MSG_SMS_GPIO_CONFIG_EX_REQ;
> -               msg.hdr.msgLength = sizeof(msg);
> -
> -               msg.data[0] = pin;
> -               msg.data[1] = pinconfig->pullupdown;
> -
> -               /* Convert slew rate for Nova: Fast(0) = 3 / Slow(1) = 0; */
> -               msg.data[2] = pinconfig->outputslewrate == 0 ? 3 : 0;
> -
> -               switch (pinconfig->outputdriving) {
> -               case SMS_GPIO_OUTPUTDRIVING_16mA:
> -                       msg.data[3] = 7; /* Nova - 16mA */
> -                       break;
> -               case SMS_GPIO_OUTPUTDRIVING_12mA:
> -                       msg.data[3] = 5; /* Nova - 11mA */
> -                       break;
> -               case SMS_GPIO_OUTPUTDRIVING_8mA:
> -                       msg.data[3] = 3; /* Nova - 7mA */
> -                       break;
> -               case SMS_GPIO_OUTPUTDRIVING_4mA:
> -               default:
> -                       msg.data[3] = 2; /* Nova - 4mA */
> -                       break;
> -               }
> -
> -               msg.data[4] = pinconfig->direction;
> -               msg.data[5] = 0;
> -       } else /* TODO: SMS_DEVICE_FAMILY1 */
> -               return -EINVAL;
> -
> -       return coredev->sendrequest_handler(coredev->context,
> -                                           &msg, sizeof(msg));
> -}
> -
> -int smscore_set_gpio(struct smscore_device_t *coredev

Re: [PATCH] [09051_47] Siano: smsdvb - add DVB v3 events

[Michael Krufky]

On Tue, May 19, 2009 at 1:05 PM, Uri Shkolnik  wrote:
>
>
>
> --- On Tue, 5/19/09, Michael Krufky  wrote:
>
>> From: Michael Krufky 
>> Subject: Re: [PATCH] [09051_47] Siano: smsdvb - add DVB v3 events
>> To: "Uri Shkolnik" 
>> Cc: "LinuxML" , "Mauro Carvalho Chehab" 
>> 
>> Date: Tuesday, May 19, 2009, 7:18 PM
>> On Tue, May 19, 2009 at 11:28 AM, Uri
>> Shkolnik 
>> wrote:
>> >
>> > # HG changeset patch
>> > # User Uri Shkolnik 
>> > # Date 1242747164 -10800
>> > # Node ID 971d4cc0d4009650bd4752c6a9fc09755ef77baf
>> > # Parent  98895daafb42f8b0757fd608b29c53c80327520e
>> > [09051_47] Siano: smsdvb - add DVB v3 events
>> >
>> > From: Uri Shkolnik 
>> >
>> > Add various DVB-API v3 events, those events will trig
>> > target (card) events.
>> >
>> > Priority: normal
>> >
>> > Signed-off-by: Uri Shkolnik 
>> >
>> > diff -r 98895daafb42 -r 971d4cc0d400
>> linux/drivers/media/dvb/siano/smsdvb.c
>> > --- a/linux/drivers/media/dvb/siano/smsdvb.c    Tue
>> May 19 18:27:38 2009 +0300
>> > +++ b/linux/drivers/media/dvb/siano/smsdvb.c    Tue
>> May 19 18:32:44 2009 +0300
>> > @@ -66,6 +66,54 @@ MODULE_PARM_DESC(debug, "set debug
>> level
>> >  /* Events that may come from DVB v3 adapter */
>> >  static void sms_board_dvb3_event(struct
>> smsdvb_client_t *client,
>> >                enum SMS_DVB3_EVENTS event) {
>> > +
>> > +       struct smscore_device_t *coredev =
>> client->coredev;
>> > +       switch (event) {
>> > +       case DVB3_EVENT_INIT:
>> > +               sms_debug("DVB3_EVENT_INIT");
>> > +               sms_board_event(coredev,
>> BOARD_EVENT_BIND);
>> > +               break;
>> > +       case DVB3_EVENT_SLEEP:
>> > +               sms_debug("DVB3_EVENT_SLEEP");
>> > +               sms_board_event(coredev,
>> BOARD_EVENT_POWER_SUSPEND);
>> > +               break;
>> > +       case DVB3_EVENT_HOTPLUG:
>> > +
>> sms_debug("DVB3_EVENT_HOTPLUG");
>> > +               sms_board_event(coredev,
>> BOARD_EVENT_POWER_INIT);
>> > +               break;
>> > +       case DVB3_EVENT_FE_LOCK:
>> > +               if (client->event_fe_state
>> != DVB3_EVENT_FE_LOCK) {
>> > +
>> client->event_fe_state = DVB3_EVENT_FE_LOCK;
>> > +
>> sms_debug("DVB3_EVENT_FE_LOCK");
>> > +
>> sms_board_event(coredev, BOARD_EVENT_FE_LOCK);
>> > +               }
>> > +               break;
>> > +       case DVB3_EVENT_FE_UNLOCK:
>> > +               if (client->event_fe_state
>> != DVB3_EVENT_FE_UNLOCK) {
>> > +
>> client->event_fe_state = DVB3_EVENT_FE_UNLOCK;
>> > +
>> sms_debug("DVB3_EVENT_FE_UNLOCK");
>> > +
>> sms_board_event(coredev, BOARD_EVENT_FE_UNLOCK);
>> > +               }
>> > +               break;
>> > +       case DVB3_EVENT_UNC_OK:
>> > +               if (client->event_unc_state
>> != DVB3_EVENT_UNC_OK) {
>> > +
>> client->event_unc_state = DVB3_EVENT_UNC_OK;
>> > +
>> sms_debug("DVB3_EVENT_UNC_OK");
>> > +
>> sms_board_event(coredev, BOARD_EVENT_MULTIPLEX_OK);
>> > +               }
>> > +               break;
>> > +       case DVB3_EVENT_UNC_ERR:
>> > +               if (client->event_unc_state
>> != DVB3_EVENT_UNC_ERR) {
>> > +
>> client->event_unc_state = DVB3_EVENT_UNC_ERR;
>> > +
>> sms_debug("DVB3_EVENT_UNC_ERR");
>> > +
>> sms_board_event(coredev, BOARD_EVENT_MULTIPLEX_ERRORS);
>> > +               }
>> > +               break;
>> > +
>> > +       default:
>> > +               sms_err("Unknown dvb3 api
>> event");
>> > +               break;
>> > +       }
>> >  }
>> >
>> >  static int smsdvb_onresponse(void *context, struct
>> smscore_buffer_t *cb)
>> >
>> >
>> >
>> >
>> > --
>> > 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
>> >
>>
>>
>>
>> Uri,
>>
>> I don't understand what prompts you to call these "DVB v3
>> events" ...
>> what does this have to do with DVB API v3 at all?
>> Your idea seems to
>> be in the right direction, but this "DVBV3" nomenclature is
>> a total
>> misnomer.
>>
>> I think something along the lines of SMSBOARD_EVENT_FOO is
>> more appropriate.
>>
>> Regards,
>>
>> Mike
>>
>
> Mike,
>
> Within the DVB version 3 adapter, there is events manager, and the name we 
> put on it is  "dvb3_event", I think its OK
>
> Uri
>
>
>
> --
> 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
>

I disagree.  Your naming implies that these structures are on the
subsystem level, and they have nothing to do with DVB3 anyway -- these
are board related events.  "dvb3_event" is a total misnomer.

-Mike
--
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] [RE-SUBMIT] [09051_58] Siano: remove obsolete code

[Michael Krufky]

On Tue, May 19, 2009 at 3:00 PM, Uri Shkolnik  wrote:
>
> # HG changeset patch
> # User Uri Shkolnik 
> # Date 1242752280 -10800
> # Node ID 0c33837206742f128aa033b2c9fb80c725e48dd7
> # Parent  fd16bcd8b9f1fffe0b605ca5b3b2138fc920e927
> [09051_58] Siano: remove obsolete code
>
> From: Uri Shkolnik 
>
> Remove obsolete code - old gpio managment (totaly bogus),
> and its dependent code from cards.
>
> Priority: normal
>
> Signed-off-by: Uri Shkolnik 
>
> diff -r fd16bcd8b9f1 -r 0c3383720674 linux/drivers/media/dvb/siano/sms-cards.c
> --- a/linux/drivers/media/dvb/siano/sms-cards.c    Tue May 19 19:50:24 2009 
> +0300
> +++ b/linux/drivers/media/dvb/siano/sms-cards.c    Tue May 19 19:58:00 2009 
> +0300
> @@ -66,24 +66,17 @@ static struct sms_board sms_boards[] = {
>        .board_cfg.leds_power = 26,
>        .board_cfg.led0 = 27,
>        .board_cfg.led1 = 28,
> -        .led_power = 26,
> -        .led_lo    = 27,
> -        .led_hi    = 28,
>    },
>    [SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD] = {
>        .name    = "Hauppauge WinTV MiniCard",
>        .type    = SMS_NOVA_B0,
>        .fw[DEVICE_MODE_DVBT_BDA] = "sms1xxx-hcw-55xxx-dvbt-02.fw",
> -        .lna_ctrl  = 29,
>        .board_cfg.foreign_lna0_ctrl = 29,
> -        .rf_switch = 17,
>    },
>    [SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2] = {
>        .name    = "Hauppauge WinTV MiniCard",
>        .type    = SMS_NOVA_B0,
>        .fw[DEVICE_MODE_DVBT_BDA] = "sms1xxx-hcw-55xxx-dvbt-02.fw",
> -        .lna_ctrl  = -1,
>    },
>    [SMS1XXX_BOARD_SIANO_NICE] = {
>    /* 11 */
> diff -r fd16bcd8b9f1 -r 0c3383720674 linux/drivers/media/dvb/siano/sms-cards.h
> --- a/linux/drivers/media/dvb/siano/sms-cards.h    Tue May 19 19:50:24 2009 
> +0300
> +++ b/linux/drivers/media/dvb/siano/sms-cards.h    Tue May 19 19:58:00 2009 
> +0300
> @@ -76,9 +76,6 @@ struct sms_board {
>    char *name, *fw[DEVICE_MODE_MAX];
>    struct sms_board_gpio_cfg board_cfg;
>    enum ir_kb_type ir_kb_type;
> -
> -    /* gpios */
> -    int led_power, led_hi, led_lo, lna_ctrl, rf_switch;
> };
>
> struct sms_board *sms_get_board(int id);
> diff -r fd16bcd8b9f1 -r 0c3383720674 
> linux/drivers/media/dvb/siano/smscoreapi.c
> --- a/linux/drivers/media/dvb/siano/smscoreapi.c    Tue May 19 19:50:24 2009 
> +0300
> +++ b/linux/drivers/media/dvb/siano/smscoreapi.c    Tue May 19 19:58:00 2009 
> +0300
> @@ -74,14 +74,6 @@ void smscore_set_board_id(struct smscore
> {
>    core->board_id = id;
> }
> -
> -int smscore_led_state(struct smscore_device_t *core, int led)
> -{
> -    if (led >= 0)
> -        core->led_state = led;
> -    return core->led_state;
> -}
> -EXPORT_SYMBOL_GPL(smscore_set_board_id);
>
> int smscore_get_board_id(struct smscore_device_t *core)
> {
> @@ -1451,78 +1443,6 @@ static int smscore_map_common_buffer(str
> }
> #endif /* SMS_HOSTLIB_SUBSYS */
>
> -/* old GPIO managments implementation */
> -int smscore_configure_gpio(struct smscore_device_t *coredev, u32 pin,
> -               struct smscore_config_gpio *pinconfig)
> -{
> -    struct {
> -        struct SmsMsgHdr_ST hdr;
> -        u32 data[6];
> -    } msg;
> -
> -    if (coredev->device_flags & SMS_DEVICE_FAMILY2) {
> -        msg.hdr.msgSrcId = DVBT_BDA_CONTROL_MSG_ID;
> -        msg.hdr.msgDstId = HIF_TASK;
> -        msg.hdr.msgFlags = 0;
> -        msg.hdr.msgType  = MSG_SMS_GPIO_CONFIG_EX_REQ;
> -        msg.hdr.msgLength = sizeof(msg);
> -
> -        msg.data[0] = pin;
> -        msg.data[1] = pinconfig->pullupdown;
> -
> -        /* Convert slew rate for Nova: Fast(0) = 3 / Slow(1) = 0; */
> -        msg.data[2] = pinconfig->outputslewrate == 0 ? 3 : 0;
> -
> -        switch (pinconfig->outputdriving) {
> -        case SMS_GPIO_OUTPUTDRIVING_16mA:
> -            msg.data[3] = 7; /* Nova - 16mA */
> -            break;
> -        case SMS_GPIO_OUTPUTDRIVING_12mA:
> -            msg.data[3] = 5; /* Nova - 11mA */
> -            break;
> -        case SMS_GPIO_OUTPUTDRIVING_8mA:
> -            msg.data[3] = 3; /* Nova - 7mA */
> -            break;
> -        case SMS_GPIO_OUTPUTDRIVING_4mA:
> -        default:
> -            msg.data[3] = 2; /* Nova - 4mA */
> -            break;
> -        }
> -
> -        msg.data[4] = pinconfig->direction;
> -        msg.data[5] = 0;
> -    } else /* TODO: SMS_DEVICE_FAMILY1 */
> -        return -EINVAL;
> -
> -    return coredev->sendrequest_handler(coredev->context,
> -                        &msg, sizeof(msg));
> -}
> -
> -int smscore_set_gpio(struct smscore_device_t *coredev, u32 pin, int level)
> -{
> -    struct {
> -        struct SmsMsgHdr_ST hdr;
> -        u32 data[3];
> -    } msg;
> -
> -    if (pin > MAX_GPIO_PIN_NUMBER)
> -        return -EINVAL;
> -
> -    msg.hdr.msgSrcId = DVBT_BDA_CONTROL_MSG_ID;
> -    msg.hdr.msgDstId = HIF_TASK;
> -    msg.hdr.msgFlags = 0;
> -    msg.hdr.msgType  = MSG_SMS_GPIO_SET_LEVEL_REQ;
> -    msg.hdr.msgLength = sizeof(msg);
> -
> -    msg.data[0] = pin;
> -    msg.data[1] = level ? 1 : 0;
> -    msg.data[2] = 0;
> -
> -    re

Re: Hauppauge HVR 1110 and DVB

[Michael Krufky]

On Tue, May 19, 2009 at 6:29 AM, Antonio Beamud Montero
 wrote:
> I have a new hauppauge hvr 1110. Trying to load the lastest modules, all
> seems to load fine, but no dvb-t frontend is created. As I can see this card
> isn't exactly the same hvr 1110 (hvr 1110r3) supported by v4l-dvb.
> The system reports the next info:
>
> # lspci -v
>
> 0b:03.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video
> Broadcast Decoder (rev d1)
> Subsystem: Hauppauge computer works Inc. Unknown device 6707
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-  SERR-  Latency: 32 (21000ns min, 8000ns max)
> Interrupt: pin A routed to IRQ 114
> Region 0: Memory at fc4ff800 (32-bit, non-prefetchable) [size=2K]
> Capabilities: [40] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=1 PME-
>
> # dmesg
>
> ACPI: PCI Interrupt :0f:03.0[A] -> GSI 160 (level, low) -> IRQ 65
> saa7133[0]: found at :0f:03.0, rev: 209, irq: 65, latency: 32, mmio:
> 0xfc4ff800
> saa7133[0]: subsystem: 0070:6707, board: Hauppauge WinTV-HVR1110r3
> [card=156,autodetected]
> saa7133[0]: board init: gpio is 4
> saa7133[0]: i2c eeprom 00: 70 00 07 67 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
> saa7133[0]: i2c eeprom 10: ff ff ff 0e ff 20 ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 20: 01 40 01 32 32 01 01 33 88 ff 00 b0 ff ff ff ff
> saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 40: ff 35 00 c0 96 10 06 32 97 04 00 20 00 ff ff ff
> saa7133[0]: i2c eeprom 50: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom 80: 84 09 00 04 20 77 00 40 08 79 5e f0 73 05 29 00
> saa7133[0]: i2c eeprom 90: 84 08 00 06 89 06 01 00 95 19 8d 72 07 70 73 09
> saa7133[0]: i2c eeprom a0: 23 5f 73 0a f4 9b 72 0b 2f 72 0e 01 72 0f 01 72
> saa7133[0]: i2c eeprom b0: 10 01 72 11 ff 73 13 a2 69 79 1a 00 00 00 00 00
> saa7133[0]: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> tveeprom 0-0050: Hauppauge model 67209, rev C1F5, serial# 6191368
> tveeprom 0-0050: MAC address is 00-0D-FE-5E-79-08
> tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54)
> tveeprom 0-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K)
> ATSC/DVB Digital (eeprom 0xf4)
> tveeprom 0-0050: audio processor is SAA7131 (idx 41)
> tveeprom 0-0050: decoder processor is SAA7131 (idx 35)
> tveeprom 0-0050: has radio, has IR receiver, has no IR transmitter
> saa7133[0]: hauppauge eeprom: model=67209
> tuner 0-004b: chip found @ 0x96 (saa7133[0])
> tda829x 0-004b: setting tuner address to 60
> tda18271 0-0060: creating new instance
> TDA18271HD/C2 detected @ 0-0060
> tda18271: performing RF tracking filter calibration
> tda18271: RF tracking filter calibration complete
> tda829x 0-004b: type set to tda8290+18271
> saa7133[0]: registered device video0 [v4l2]
> saa7133[0]: registered device vbi0
> saa7133[0]: registered device radio0
> saa7134 ALSA driver for DMA sound loaded
> saa7133[0]/alsa: saa7133[0] at 0xfc4ff800 irq 65 registered as card -1
>
> Trying to load manually the saa7134-dvb module reports nothing.
>
> The module seems to recognize the 67209LF rev C1F5 ok.
>
> Hauppauge hvr 1110 Hardware Info:
>
> Decoder: saa7131E/03/G
> Module: TDA10048HN
> (http://www.ecnasiamag.com/article-10192-philipstda10048hnenablesdigitaltvviewingthroughentertainmentdevices-Asia.html)

Hello,

I specifically left out the DVB support for this device.

To be honest, I didn't know that this board was available for purchase
already.  Where did you get it?  (just curious)

I like to add card support for all products as soon as possible.  In
the case of this board, analog works but digital does not yet.

I'm a bit busy at the moment ...  Try again in a few weeks to a month
or so and there should be more progress.

If something happens sooner than that, I'll append another email to this thread.

Regards,

Mike
--
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: Hauppauge HVR 1110 and DVB

[Michael Krufky]

On Wed, May 20, 2009 at 11:42 AM, Antonio Beamud Montero
 wrote:
> Michael Krufky escribió:
>>
>> On Tue, May 19, 2009 at 6:29 AM, Antonio Beamud Montero
>>  Hello,
>>
>> I specifically left out the DVB support for this device.
>>
>> To be honest, I didn't know that this board was available for purchase
>> already.  Where did you get it?  (just curious)
>>
>
> It seems that here in spain is available :)
>
>
>>
>> If something happens sooner than that, I'll append another email to this
>> thread.
>>
>
> Ok, If you need a tester, I'm your man ;)
>
> Thank you.
>
> Greetings.

(i am sending this a second time -- first message got rejected by vger)

You're in luck -- I resolved the problem today...  If you'd like to
test, please try out this repository:

http://kernellabs.com/hg/~mk/hvr1110

Please let me know how this works for you.

Regards,

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

[SAA713X TESTERS WANTED] Fix i2c quirk, may affect saa713x + mt352 combo

[Michael Krufky]

I have discovered a bug in the saa7134 driver inside the function,
"saa7134_i2c_xfer"

In order to communicate with certain i2c clients on the saa713x i2c
bus, a quirk was implemented to prevent failures during read
transactions.

The quirk forces an i2c write/read to a bogus address that is unlikely
to be used by any i2c client.

However, this quirk is not functioning properly.  The reason for the
malfunction is that the i2c address chosen to use as the quirk address
was 0xfd.

The address 0xfd is indeed an i2c address unlikely to be used by any
real i2c client, however, the address itself is invalid!  The address,
0xfd, has the read bit set -- this is problematic for the hardware,
and causes the quirk workaround to fail.

It's a wonder that nobody else has complained up to this point.

I am asking for testers, just to make sure that this doesn't cause any
other strange errors to occur as a side effect.  I don't expect any
new problems, but its always better to be safe than sorry :-)

This change should not fix any of the other issues currently being
discussed with the saa7134 driver -- all I am asking is for people to
test and indicate that the change does not incur any NEW bugs or
unwanted behavior.

Please test the following repository, and send in your feedback as a
reply to this thread.  Please remember to keep the mailing list in cc.

http://kernellabs.com/hg/~mk/saa7134

Thanks,

Mike Krufky
--
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: [SAA713X TESTERS WANTED] Fix i2c quirk, may affect saa713x + mt352 combo

[Michael Krufky]

On Thu, May 21, 2009 at 8:51 AM, Michael Krufky  wrote:
> On Thu, May 21, 2009 at 2:44 AM, Oldrich Jedlicka 
> wrote:
>>
>> Hi Mike,
>>
>> On Wednesday 20 of May 2009 at 21:57:15, Michael Krufky wrote:
>> > I have discovered a bug in the saa7134 driver inside the function,
>> > "saa7134_i2c_xfer"
>> >
>> > In order to communicate with certain i2c clients on the saa713x i2c
>> > bus, a quirk was implemented to prevent failures during read
>> > transactions.
>> >
>> > The quirk forces an i2c write/read to a bogus address that is unlikely
>> > to be used by any i2c client.
>> >
>> > However, this quirk is not functioning properly.  The reason for the
>> > malfunction is that the i2c address chosen to use as the quirk address
>> > was 0xfd.
>> >
>> > The address 0xfd is indeed an i2c address unlikely to be used by any
>> > real i2c client, however, the address itself is invalid!  The address,
>> > 0xfd, has the read bit set -- this is problematic for the hardware,
>> > and causes the quirk workaround to fail.
>> >
>> > It's a wonder that nobody else has complained up to this point.
>>
>> I had a problem with 0xfd quirk already (the presence caused the device
>> not to
>> respond), this is why there is an exception
>>
>>        msgs[i].addr != 0x40
>>
>> I can check if it works with your version (0xfe), but the device behind
>> the
>> address 0x40 (remote control) is very stupid, so I don't think so.
>>
>> I think that better approach would be to use the quirk only for devices
>> (addresses) that really need it, not for all.
>>
>> Cheers,
>> Oldrich.
>>
>> > I am asking for testers, just to make sure that this doesn't cause any
>> > other strange errors to occur as a side effect.  I don't expect any
>> > new problems, but its always better to be safe than sorry :-)
>> >
>> > This change should not fix any of the other issues currently being
>> > discussed with the saa7134 driver -- all I am asking is for people to
>> > test and indicate that the change does not incur any NEW bugs or
>> > unwanted behavior.
>> >
>> > Please test the following repository, and send in your feedback as a
>> > reply to this thread.  Please remember to keep the mailing list in cc.
>> >
>> > http://kernellabs.com/hg/~mk/saa7134
>> >
>> > Thanks,
>> >
>> > Mike Krufky
>> > --
>> > 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
>>
>>
>
>
>
> Thanks for the feedback, guys.  Just to reiterate my original point:
>
> I am not questioning the i2c quirk itself -- this is already in the driver,
> and cards are working already as is.  I am just saying that there is a bug
> based on the address used.  Consider 7-bit i2c addresses --   0xfd is an
> 8-bit address, when converted to a 7-bit address and then back to an 8-bit
> address becomes 0xfc.  I don't know how to explain this properly, but it's
> invalid.  This is a bug in the saa7131 silicon that requires a write to a
> valid i2c address to occur before a read transaction, in order to prevent a
> situation where a read transaction results in no ack from the client.
>
> This is a known errata of the NXP silicon.
>
> The HVR1110r3 cannot perform successful i2c read transactions from the DVB-T
> demodulator without this i2c workaround in place, using a valid address.
>
> And yes, I am aware of David Wong's situation -- I have a changeset in one
> of my repositories that will allow us to disable this i2c quirk on a card by
> card basis, but so far I haven't heard of any card that needs this other
> than his board.
>
> http://linuxtv.org/hg/~mkrufky/dmbth/rev/781ffa6c43d3
>
> We can certainly merge that changeset if required.
>
> All I am asking is for you to test your boards against this tree and confirm
> that this changeset does not cause any *new* problems.
>
> Thanks go out to Hermann and Oldrich so far, as both of you seem to indicate
> that this tree did not cause any new problem on your hardware.
>
> Thanks again for the feedback.
>
> Regards,
>
> Mike
>

(apologies for the double post -- first one got rejected by vger, again)

Thanks for the feedback, guys.  Just to reiterate my original point:

I am not questioning the i2c quirk itself 

Re: Hauppauge HVR 1110 and DVB

[Michael Krufky]

On Thu, May 21, 2009 at 10:13 AM, Antonio Beamud Montero
 wrote:
> Thanks for the patch. Seems to load fine, the problem arises when try load
> the firmware.
[snip]
> DVB: registering new adapter (saa7133[0])
> DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)...
> tda10048_firmware_upload: waiting for firmware upload
> (dvb-fe-tda10048-1.0.fw)...
> tda10048_firmware_upload: firmware read 24878 bytes.
> tda10048_firmware_upload: firmware uploading
> tda10048_firmware_upload: firmware upload failed
> saa7134 ALSA driver for DMA sound loaded
> saa7133[0]/alsa: saa7133[0] at 0xfc4ff800 irq 65 registered as card -1
>
> ---
>
> I've tried to extract the firmware from the windows drivers, but all my
> experiments failed.
> How I can get the correct firmware?

You can get the firmware from here:

http://www.steventoth.net/linux/hvr1200

Regards,

Mike
--
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: Leadtek Winfast DTV-1000S

[Michael Krufky]

On Thu, May 21, 2009 at 10:04 AM, Brad Allen  wrote:
>
>
> --- mkru...@linuxtv.org wrote:
>
> From: Michael Krufky 
> To: bra...@tranceaddict.net
> Subject: Re: Leadtek Winfast DTV-1000S
> Date: Wed, 20 May 2009 18:09:34 -0400
>
> On Tue, May 19, 2009 at 3:50 AM, Brad Allen  wrote:
>> Dear Michael,
>>
>> Ive just bought a Leadtek Winfast DTV-1000S (18271, 14008, 7130 chipset), 
>> believing it would work under Linux as the kernel contains drivers for those 
>> three chips.
>>
>> Upon further investigation neither the SAA7134 or the TDA14008 drivers seem 
>> to support the 18271. The SAA7134 driver does however appear to work 
>> correctly. It just has no tuner to attach to it.
>>
>> I am desperate to get this card working, surely since the drivers for the 
>> chips are written its not a huge task. If you would be so kind as to offer 
>> your assistance with this issue I have basic C skills and am quite competent 
>> in linux so if theres anything at all I can do to assist you please let me 
>> know.
>>
>> Thanks in advance,
>>
>> Brad Allen
>>
>
> Brad,
>
> I pushed support for a similar board today... You may be able to get
> your card up and running by using board configuration #156, if you use
> my latest code, located here:
>
> http://kernellabs.com/hg/~mk/hvr1110
>
> The board I have uses a saa7131, not a saa7130, so there may be some
> minor differences...  Does your board support both analog and DVB-T,
> or just DVB-T ?
>
> If this works for you, please let me know.  If not, I have some ideas.
>
> Good Luck.
>
> -Mike Krufky
>
> Hi Mike,
>
> Thanks for your reply. I have had a few minutes to try your latest code and I 
> have both good and bad news to report.
>
> Firstly all three chips are now correctly detected by the module, previously 
> only the SAA7130 was. The DVB device is also now being created whereas before 
> it wasn't.
>
> The card is a DVB-T and FM tuner.
>
> Here are the problems:
>
> 1) When loading the module I get the error "tuner 1-0060: Tuner has no way to 
> set tv freq"
>
> 2) Trying to tune in channels in mythtv fails, it seems to work but nothing 
> is detected. The signal strength meter works properly.
>
> 3) Attempting to view TV with mplayer fails with the following error:
>
> ERROR OPENING FRONTEND DEVICE /dev/dvb/adapter0/frontend0: ERRNO 
> DVB_SET_CHANNEL2, COULDN'T OPEN DEVICES OF CARD: 0, EXIT
> ERROR, COULDN'T SET CHANNEL  0: Failed to open dvb://.
>
> Here is the relevant part from dmesg:
>
> [    6.453049] Linux video capture interface: v2.00
> [    7.280900] saa7130/34: v4l2 driver version 0.2.15 loaded
> [    7.282274] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
> [    7.282345] PCI: setting IRQ 5 as level-triggered
> [    7.282358] saa7134 :00:0f.0: PCI INT A -> Link[LNKC] -> GSI 5 (level, 
> low) -> IRQ 5
> [    7.282451] saa7130[0]: found at :00:0f.0, rev: 1, irq: 5, latency: 
> 32, mmio: 0xea001000
> [    7.282550] saa7130[0]: subsystem: 107d:6655, board: Hauppauge 
> WinTV-HVR1110r3 DVB-T/Hybrid [card=156,insmod option]
> [    7.282699] saa7130[0]: board init: gpio is 2020009
> [    7.301147] IRQ 5/saa7130[0]: IRQF_DISABLED is not guaranteed on shared 
> IRQs
> [    7.437801] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43 43 a9 1c 
> 55 d2 b2 92
> [    7.438219] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff 
> ff ff ff ff
> [    7.438541] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08 ff 00 8a 
> ff ff ff ff
> [    7.439915] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.440613] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff 04 ff ff 
> ff ff ff ff
> [    7.441307] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.441984] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.442680] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.443374] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.444067] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.444746] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.445441] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.446137] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.446815] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff
> [    7.447511] saa7130[0]: i2c eeprom e

Re: [SAA713X TESTERS WANTED] Fix i2c quirk, may affect saa713x + mt352 combo

[Michael Krufky]

On Thu, May 21, 2009 at 6:30 PM, hermann pitton  wrote:
> Hi,
>
> Am Donnerstag, den 21.05.2009, 08:53 -0400 schrieb Michael Krufky:
>> On Thu, May 21, 2009 at 8:51 AM, Michael Krufky  
>> wrote:
>> > On Thu, May 21, 2009 at 2:44 AM, Oldrich Jedlicka 
>> > wrote:
>> >>
>> >> Hi Mike,
>> >>
>> >> On Wednesday 20 of May 2009 at 21:57:15, Michael Krufky wrote:
>> >> > I have discovered a bug in the saa7134 driver inside the function,
>> >> > "saa7134_i2c_xfer"
>> >> >
>> >> > In order to communicate with certain i2c clients on the saa713x i2c
>> >> > bus, a quirk was implemented to prevent failures during read
>> >> > transactions.
>> >> >
>> >> > The quirk forces an i2c write/read to a bogus address that is unlikely
>> >> > to be used by any i2c client.
>> >> >
>> >> > However, this quirk is not functioning properly.  The reason for the
>> >> > malfunction is that the i2c address chosen to use as the quirk address
>> >> > was 0xfd.
>> >> >
>> >> > The address 0xfd is indeed an i2c address unlikely to be used by any
>> >> > real i2c client, however, the address itself is invalid!  The address,
>> >> > 0xfd, has the read bit set -- this is problematic for the hardware,
>> >> > and causes the quirk workaround to fail.
>> >> >
>> >> > It's a wonder that nobody else has complained up to this point.
>> >>
>> >> I had a problem with 0xfd quirk already (the presence caused the device
>> >> not to
>> >> respond), this is why there is an exception
>> >>
>> >>        msgs[i].addr != 0x40
>> >>
>> >> I can check if it works with your version (0xfe), but the device behind
>> >> the
>> >> address 0x40 (remote control) is very stupid, so I don't think so.
>> >>
>> >> I think that better approach would be to use the quirk only for devices
>> >> (addresses) that really need it, not for all.
>> >>
>> >> Cheers,
>> >> Oldrich.
>> >>
>> >> > I am asking for testers, just to make sure that this doesn't cause any
>> >> > other strange errors to occur as a side effect.  I don't expect any
>> >> > new problems, but its always better to be safe than sorry :-)
>> >> >
>> >> > This change should not fix any of the other issues currently being
>> >> > discussed with the saa7134 driver -- all I am asking is for people to
>> >> > test and indicate that the change does not incur any NEW bugs or
>> >> > unwanted behavior.
>> >> >
>> >> > Please test the following repository, and send in your feedback as a
>> >> > reply to this thread.  Please remember to keep the mailing list in cc.
>> >> >
>> >> > http://kernellabs.com/hg/~mk/saa7134
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Mike Krufky
>> >> > --
>> >> > 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
>> >>
>> >>
>> >
>> >
>> >
>> > Thanks for the feedback, guys.  Just to reiterate my original point:
>> >
>> > I am not questioning the i2c quirk itself -- this is already in the driver,
>> > and cards are working already as is.  I am just saying that there is a bug
>> > based on the address used.  Consider 7-bit i2c addresses --   0xfd is an
>> > 8-bit address, when converted to a 7-bit address and then back to an 8-bit
>> > address becomes 0xfc.  I don't know how to explain this properly, but it's
>> > invalid.  This is a bug in the saa7131 silicon that requires a write to a
>> > valid i2c address to occur before a read transaction, in order to prevent a
>> > situation where a read transaction results in no ack from the client.
>> >
>> > This is a known errata of the NXP silicon.
>> >
>> > The HVR1110r3 cannot perform successful i2c read transactions from the 
>> > DVB-T
>> > demodulator without this i2c workaround in place, using a valid address.
>> >
>> > And

Re: [SAA713X TESTERS WANTED] Fix i2c quirk, may affect saa713x + mt352 combo

[Michael Krufky]

On Fri, May 22, 2009 at 1:10 PM, Oldrich Jedlicka  wrote:
> On Thursday 21 of May 2009 at 14:53:00, Michael Krufky wrote:
>> On Thu, May 21, 2009 at 8:51 AM, Michael Krufky 
> wrote:
>> > On Thu, May 21, 2009 at 2:44 AM, Oldrich Jedlicka 
>> >
>> > wrote:
>> >> Hi Mike,
>> >>
>> >> On Wednesday 20 of May 2009 at 21:57:15, Michael Krufky wrote:
>> >> > I have discovered a bug in the saa7134 driver inside the function,
>> >> > "saa7134_i2c_xfer"
>> >> >
>> >> > In order to communicate with certain i2c clients on the saa713x i2c
>> >> > bus, a quirk was implemented to prevent failures during read
>> >> > transactions.
>> >> >
>> >> > The quirk forces an i2c write/read to a bogus address that is unlikely
>> >> > to be used by any i2c client.
>> >> >
>> >> > However, this quirk is not functioning properly.  The reason for the
>> >> > malfunction is that the i2c address chosen to use as the quirk address
>> >> > was 0xfd.
>> >> >
>> >> > The address 0xfd is indeed an i2c address unlikely to be used by any
>> >> > real i2c client, however, the address itself is invalid!  The address,
>> >> > 0xfd, has the read bit set -- this is problematic for the hardware,
>> >> > and causes the quirk workaround to fail.
>> >> >
>> >> > It's a wonder that nobody else has complained up to this point.
>> >>
>> >> I had a problem with 0xfd quirk already (the presence caused the device
>> >> not to
>> >> respond), this is why there is an exception
>> >>
>> >>        msgs[i].addr != 0x40
>> >>
>> >> I can check if it works with your version (0xfe), but the device behind
>> >> the
>> >> address 0x40 (remote control) is very stupid, so I don't think so.
>> >>
>> >> I think that better approach would be to use the quirk only for devices
>> >> (addresses) that really need it, not for all.
>> >>
>> >> Cheers,
>> >> Oldrich.
>> >>
>> >> > I am asking for testers, just to make sure that this doesn't cause any
>> >> > other strange errors to occur as a side effect.  I don't expect any
>> >> > new problems, but its always better to be safe than sorry :-)
>> >> >
>> >> > This change should not fix any of the other issues currently being
>> >> > discussed with the saa7134 driver -- all I am asking is for people to
>> >> > test and indicate that the change does not incur any NEW bugs or
>> >> > unwanted behavior.
>> >> >
>> >> > Please test the following repository, and send in your feedback as a
>> >> > reply to this thread.  Please remember to keep the mailing list in cc.
>> >> >
>> >> > http://kernellabs.com/hg/~mk/saa7134
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Mike Krufky
>> >> > --
>> >> > 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
>> >
>> > Thanks for the feedback, guys.  Just to reiterate my original point:
>> >
>> > I am not questioning the i2c quirk itself -- this is already in the
>> > driver, and cards are working already as is.  I am just saying that there
>> > is a bug based on the address used.  Consider 7-bit i2c addresses --
>> > 0xfd is an 8-bit address, when converted to a 7-bit address and then back
>> > to an 8-bit address becomes 0xfc.  I don't know how to explain this
>> > properly, but it's invalid.  This is a bug in the saa7131 silicon that
>> > requires a write to a valid i2c address to occur before a read
>> > transaction, in order to prevent a situation where a read transaction
>> > results in no ack from the client.
>> >
>> > This is a known errata of the NXP silicon.
>> >
>> > The HVR1110r3 cannot perform successful i2c read transactions from the
>> > DVB-T demodulator without this i2c workaround in place, using a valid
>> > address.
>> >
>> > And yes, I am aware of David Wong's situation -- I have a changeset in
>> 

Re: [SAA713X TESTERS WANTED] Fix i2c quirk, may affect saa713x + mt352 combo

[Michael Krufky]

On Fri, May 22, 2009 at 4:49 PM, hermann pitton  wrote:
>
> Am Donnerstag, den 21.05.2009, 23:34 -0400 schrieb Michael Krufky:
>> On Thu, May 21, 2009 at 6:30 PM, hermann pitton  
>> wrote:
>> > Hi,
>> >
>> > Am Donnerstag, den 21.05.2009, 08:53 -0400 schrieb Michael Krufky:
>> >> On Thu, May 21, 2009 at 8:51 AM, Michael Krufky  
>> >> wrote:
>> >> > On Thu, May 21, 2009 at 2:44 AM, Oldrich Jedlicka 
>> >> > wrote:
>> >> >>
>> >> >> Hi Mike,
>> >> >>
>> >> >> On Wednesday 20 of May 2009 at 21:57:15, Michael Krufky wrote:
>> >> >> > I have discovered a bug in the saa7134 driver inside the function,
>> >> >> > "saa7134_i2c_xfer"
>> >> >> >
>> >> >> > In order to communicate with certain i2c clients on the saa713x i2c
>> >> >> > bus, a quirk was implemented to prevent failures during read
>> >> >> > transactions.
>> >> >> >
>> >> >> > The quirk forces an i2c write/read to a bogus address that is 
>> >> >> > unlikely
>> >> >> > to be used by any i2c client.
>> >> >> >
>> >> >> > However, this quirk is not functioning properly.  The reason for the
>> >> >> > malfunction is that the i2c address chosen to use as the quirk 
>> >> >> > address
>> >> >> > was 0xfd.
>> >> >> >
>> >> >> > The address 0xfd is indeed an i2c address unlikely to be used by any
>> >> >> > real i2c client, however, the address itself is invalid!  The 
>> >> >> > address,
>> >> >> > 0xfd, has the read bit set -- this is problematic for the hardware,
>> >> >> > and causes the quirk workaround to fail.
>> >> >> >
>> >> >> > It's a wonder that nobody else has complained up to this point.
>> >> >>
>> >> >> I had a problem with 0xfd quirk already (the presence caused the device
>> >> >> not to
>> >> >> respond), this is why there is an exception
>> >> >>
>> >> >>        msgs[i].addr != 0x40
>> >> >>
>> >> >> I can check if it works with your version (0xfe), but the device behind
>> >> >> the
>> >> >> address 0x40 (remote control) is very stupid, so I don't think so.
>> >> >>
>> >> >> I think that better approach would be to use the quirk only for devices
>> >> >> (addresses) that really need it, not for all.
>> >> >>
>> >> >> Cheers,
>> >> >> Oldrich.
>> >> >>
>> >> >> > I am asking for testers, just to make sure that this doesn't cause 
>> >> >> > any
>> >> >> > other strange errors to occur as a side effect.  I don't expect any
>> >> >> > new problems, but its always better to be safe than sorry :-)
>> >> >> >
>> >> >> > This change should not fix any of the other issues currently being
>> >> >> > discussed with the saa7134 driver -- all I am asking is for people to
>> >> >> > test and indicate that the change does not incur any NEW bugs or
>> >> >> > unwanted behavior.
>> >> >> >
>> >> >> > Please test the following repository, and send in your feedback as a
>> >> >> > reply to this thread.  Please remember to keep the mailing list in 
>> >> >> > cc.
>> >> >> >
>> >> >> > http://kernellabs.com/hg/~mk/saa7134
>> >> >> >
>> >> >> > Thanks,
>> >> >> >
>> >> >> > Mike Krufky
>> >> >> > --
>> >> >> > 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
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > Thanks for the feedback, guys.  Just to reiterate my original point:
>&

[PULL] http://www.kernellabs.com/hg/~mkrufky/hvr1110

[Michael Krufky]

Mauro,

Please pull from:

http://www.kernellabs.com/hg/~mkrufky/hvr1110

for the following changesets:

- saa7134: fix quirk in saa7134_i2c_xfer for the saa7131 bridge
- saa7134: enable digital tv support for Hauppauge WinTV-HVR1110r3

 Documentation/video4linux/CARDLIST.saa7134  |2
 drivers/media/video/saa7134/Kconfig |1
 drivers/media/video/saa7134/saa7134-cards.c |4 +
 drivers/media/video/saa7134/saa7134-dvb.c   |   26 ++
 drivers/media/video/saa7134/saa7134-i2c.c   |2
 5 files changed, 32 insertions(+), 3 deletions(-)

The saa7134_i2c_xfer quirk fix was
Tested-by: Hermann Pitton 

Please note, this repository contains changesets from Steven Toth's
"tda10048-merge" repository, which he has already issued a separate
pull request to you.  If you've already pulled his tree by the time
you get to mine, then the changesets outstanding are those above.  If,
however, you'd prefer to just pull them all at once from my own
repository, you will get the following changesets:

- TDA10048: Ensure the I/F changes during DVB-T 6/7/8 bandwidth changes.
- cx23885: Ensure we specify I/F's for all bandwidths
- pvrusb2: Ensure we specify I/F's for all bandwidths
- TDA10048: Missing two I/F's / Pll combinations from the PLL table
- cx23885: fix tda10048 IF frequencies for the Hauppauge WinTV-HVR1210
- saa7134: fix quirk in saa7134_i2c_xfer for the saa7131 bridge
- saa7134: enable digital tv support for Hauppauge WinTV-HVR1110r3

 Documentation/video4linux/CARDLIST.saa7134|2
 drivers/media/dvb/frontends/tda10048.c|  188 ++
 drivers/media/dvb/frontends/tda10048.h|6
 drivers/media/video/cx23885/cx23885-dvb.c |8
 drivers/media/video/pvrusb2/pvrusb2-devattr.c |4
 drivers/media/video/saa7134/Kconfig   |1
 drivers/media/video/saa7134/saa7134-cards.c   |4
 drivers/media/video/saa7134/saa7134-dvb.c |   26 +
 drivers/media/video/saa7134/saa7134-i2c.c |2
 9 files changed, 171 insertions(+), 70 deletions(-)


Please retain the original hashcodes  (avoid cherry-picking, if you
can), as I have some additional test repositories that depend on these
changesets.

Regards,

Mike Krufky
--
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: [PULL] http://www.kernellabs.com/hg/~mkrufky/hvr1110

[Michael Krufky]

On Fri, May 22, 2009 at 5:38 PM, Michael Krufky  wrote:
> Mauro,
>
> Please pull from:
>
> http://www.kernellabs.com/hg/~mkrufky/hvr1110
>
> for the following changesets:
>
> - saa7134: fix quirk in saa7134_i2c_xfer for the saa7131 bridge
> - saa7134: enable digital tv support for Hauppauge WinTV-HVR1110r3
>
>  Documentation/video4linux/CARDLIST.saa7134  |    2
>  drivers/media/video/saa7134/Kconfig         |    1
>  drivers/media/video/saa7134/saa7134-cards.c |    4 +
>  drivers/media/video/saa7134/saa7134-dvb.c   |   26 ++
>  drivers/media/video/saa7134/saa7134-i2c.c   |    2
>  5 files changed, 32 insertions(+), 3 deletions(-)
>
> The saa7134_i2c_xfer quirk fix was
> Tested-by: Hermann Pitton 
>
> Please note, this repository contains changesets from Steven Toth's
> "tda10048-merge" repository, which he has already issued a separate
> pull request to you.  If you've already pulled his tree by the time
> you get to mine, then the changesets outstanding are those above.  If,
> however, you'd prefer to just pull them all at once from my own
> repository, you will get the following changesets:
>
> - TDA10048: Ensure the I/F changes during DVB-T 6/7/8 bandwidth changes.
> - cx23885: Ensure we specify I/F's for all bandwidths
> - pvrusb2: Ensure we specify I/F's for all bandwidths
> - TDA10048: Missing two I/F's / Pll combinations from the PLL table
> - cx23885: fix tda10048 IF frequencies for the Hauppauge WinTV-HVR1210
> - saa7134: fix quirk in saa7134_i2c_xfer for the saa7131 bridge
> - saa7134: enable digital tv support for Hauppauge WinTV-HVR1110r3
>
>  Documentation/video4linux/CARDLIST.saa7134    |    2
>  drivers/media/dvb/frontends/tda10048.c        |  188 ++
>  drivers/media/dvb/frontends/tda10048.h        |    6
>  drivers/media/video/cx23885/cx23885-dvb.c     |    8
>  drivers/media/video/pvrusb2/pvrusb2-devattr.c |    4
>  drivers/media/video/saa7134/Kconfig           |    1
>  drivers/media/video/saa7134/saa7134-cards.c   |    4
>  drivers/media/video/saa7134/saa7134-dvb.c     |   26 +
>  drivers/media/video/saa7134/saa7134-i2c.c     |    2
>  9 files changed, 171 insertions(+), 70 deletions(-)
>
>
> Please retain the original hashcodes  (avoid cherry-picking, if you
> can), as I have some additional test repositories that depend on these
> changesets.
>
> Regards,
>
> Mike Krufky
>

Mauro,

I see that the kernellabs.com www server has been down all weekend.
Unfortunately, there isn't much I can do about that, but in the spirit
of keeping things moving, I have pushed the above repository to
linuxtv.org so that you can merge without having to wait for the
kernellabs.com www server to come back.

Please pull from:

http://linuxtv.org/hg/~mkrufky/saa7134-tda10048

for the following changesets from Steve and I:

- TDA10048: Ensure the I/F changes during DVB-T 6/7/8 bandwidth changes.
- cx23885: Ensure we specify I/F's for all bandwidths
- pvrusb2: Ensure we specify I/F's for all bandwidths
- TDA10048: Missing two I/F's / Pll combinations from the PLL table
- cx23885: fix tda10048 IF frequencies for the Hauppauge WinTV-HVR1210
- saa7134: fix quirk in saa7134_i2c_xfer for the saa7131 bridge
- saa7134: enable digital tv support for Hauppauge WinTV-HVR1110r3

 Documentation/video4linux/CARDLIST.saa7134|2
 drivers/media/dvb/frontends/tda10048.c|  188 ++
 drivers/media/dvb/frontends/tda10048.h|6
 drivers/media/video/cx23885/cx23885-dvb.c |8
 drivers/media/video/pvrusb2/pvrusb2-devattr.c |4
 drivers/media/video/saa7134/Kconfig   |1
 drivers/media/video/saa7134/saa7134-cards.c   |4
 drivers/media/video/saa7134/saa7134-dvb.c |   26 +
 drivers/media/video/saa7134/saa7134-i2c.c |2
 9 files changed, 171 insertions(+), 70 deletions(-)

Cheers,

Mike
--
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 4/6] dvb/dvb-usb: prepare for FIRMWARE_NAME_MAX removal

[Michael Krufky]

On Tue, May 26, 2009 at 1:40 PM, Samuel Ortiz  wrote:
> From: Samuel Ortiz 
> To: Mauro Carvalho Chehab 
>
> We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid any
> firmware name length restriction.
> This patch changes the dvb_usb_device_properties firmware field accordingly.
>
> Signed-off-by: Samuel Ortiz 
>
> ---
>  drivers/media/dvb/dvb-usb/dvb-usb.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h
> ===
> --- iwm-2.6.orig/drivers/media/dvb/dvb-usb/dvb-usb.h    2009-05-26 
> 17:24:36.0 +0200
> +++ iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-05-26 17:25:19.0 
> +0200
> @@ -196,7 +196,7 @@ struct dvb_usb_device_properties {
>  #define CYPRESS_FX2     3
>        int        usb_ctrl;
>        int        (*download_firmware) (struct usb_device *, const struct 
> firmware *);
> -       const char firmware[FIRMWARE_NAME_MAX];
> +       const char *firmware;
>        int        no_reconnect;
>
>        int size_of_priv;
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Samuel,

Your patch makes the following change:

-   const char firmware[FIRMWARE_NAME_MAX];
+   const char *firmware;

Before your change, struct dvb_usb_device_properties actually contains
memory allocated for the firmware filename.  After your change, this
is nothing but a pointer.

This will cause an OOPS.

Regards,

Mike Krufky
--
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 4/6] dvb/dvb-usb: prepare for FIRMWARE_NAME_MAX removal

[Michael Krufky]

On Tue, May 26, 2009 at 2:42 PM, Samuel Ortiz  wrote:
> On Tue, May 26, 2009 at 02:32:45PM -0400, Michael Krufky wrote:
>> On Tue, May 26, 2009 at 1:40 PM, Samuel Ortiz  wrote:
>> > From: Samuel Ortiz 
>> > To: Mauro Carvalho Chehab 
>> >
>> > We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid 
>> > any
>> > firmware name length restriction.
>> > This patch changes the dvb_usb_device_properties firmware field 
>> > accordingly.
>> >
>> > Signed-off-by: Samuel Ortiz 
>> >
>> > ---
>> >  drivers/media/dvb/dvb-usb/dvb-usb.h |    2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > Index: iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h
>> > ===
>> > --- iwm-2.6.orig/drivers/media/dvb/dvb-usb/dvb-usb.h    2009-05-26 
>> > 17:24:36.0 +0200
>> > +++ iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-05-26 
>> > 17:25:19.0 +0200
>> > @@ -196,7 +196,7 @@ struct dvb_usb_device_properties {
>> >  #define CYPRESS_FX2     3
>> >        int        usb_ctrl;
>> >        int        (*download_firmware) (struct usb_device *, const struct 
>> > firmware *);
>> > -       const char firmware[FIRMWARE_NAME_MAX];
>> > +       const char *firmware;
>> >        int        no_reconnect;
>> >
>> >        int size_of_priv;
>> >
>> > --
>> > Intel Open Source Technology Centre
>> > http://oss.intel.com/
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at  http://www.tux.org/lkml/
>> >
>>
>> Samuel,
>>
>> Your patch makes the following change:
>>
>> -       const char firmware[FIRMWARE_NAME_MAX];
>> +       const char *firmware;
>>
>> Before your change, struct dvb_usb_device_properties actually contains
>> memory allocated for the firmware filename.  After your change, this
>> is nothing but a pointer.
>>
>> This will cause an OOPS.
> No, not if it's correctly initialized, as it seems to be for all the
> dvb_usb_device_properties users right now.
> Typically, you'd initialize your dvb_usb_device_properties like this:
>
> static struct dvb_usb_device_properties a800_properties = {
>        .caps = DVB_USB_IS_AN_I2C_ADAPTER,
>
>        .usb_ctrl = CYPRESS_FX2,
>        .firmware = "dvb-usb-avertv-a800-02.fw",
> [...]
>
> And that's fine.

You're right -- there is nothing wrong with the change -- my bad.

I traced though the code after posting that last mail.  It looked
risky when I just looked at the patch, but in the end this is actually
cleaner and much better.

Sorry for the noise.

Acked /
Reviewed-by: Michael Krufky 
--
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: "Unknown symbol __udivdi3" with rev >= 11873

[Michael Krufky]

On Thu, May 28, 2009 at 12:05 AM, David Ward  wrote:
> Revision 11873 (committed earlier today) has broken the cx18 driver for me,
> with the line "cx18: Unknown symbol __udivdi3" appearing in dmesg when the
> module tries to load.  I'm using Ubuntu 8.04.2 which uses kernel 2.6.24 and
> gcc 4.2.4.
>
> I also wanted to express my appreciation to Mauro for fixing the build for
> older kernels today, as it is very desirable for me to use a
> distribution/kernel which has long-term support and updates, but I simply
> need to add a DVB driver that wasn't part of the older kernel.
>
> Thanks so much.
>
> David Ward

Let it be known that this issue only affects 32bit kernels.  I believe
the offending line of code is here:

fsc = u64)sc) * 28636360)/src_decimation) >> 13L;

(cc added to Andy Walls)

-Mike Krufky
--
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: "Unknown symbol __udivdi3" with rev >= 11873

[Michael Krufky]

On Thu, May 28, 2009 at 5:43 PM, David Ward  wrote:
> On 05/28/2009 03:12 PM, Michael Krufky wrote:
>>
>> On Thu, May 28, 2009 at 12:05 AM, David Ward
>>  wrote:
>>
>>>
>>> Revision 11873 (committed earlier today) has broken the cx18 driver for
>>> me,
>>> with the line "cx18: Unknown symbol __udivdi3" appearing in dmesg when
>>> the
>>> module tries to load.  I'm using Ubuntu 8.04.2 which uses kernel 2.6.24
>>> and
>>> gcc 4.2.4.
>>>
>>> I also wanted to express my appreciation to Mauro for fixing the build
>>> for
>>> older kernels today, as it is very desirable for me to use a
>>> distribution/kernel which has long-term support and updates, but I simply
>>> need to add a DVB driver that wasn't part of the older kernel.
>>>
>>> Thanks so much.
>>>
>>> David Ward
>>>
>>
>> Let it be known that this issue only affects 32bit kernels.  I believe
>> the offending line of code is here:
>>
>> fsc = u64)sc) * 28636360)/src_decimation)>>  13L;
>>
>> (cc added to Andy Walls)
>>
>> -Mike Krufky
>>
>
> Some Google searching seems to suggest that the correct thing to do here is
> to use the 'do_div' macro for the division, which is declared in
> :
>
> http://www.captain.at/howto-udivdi3-umoddi3.php
>
> David


Patches welcome :-)

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

[PULL] http://kernellabs.com/hg/~mkrufky/lgdt3305

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/lgdt3305

for:

- lgdt3305: fix 64bit division in function lgdt3305_set_if

 lgdt3305.c |   17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)


Thanks to David Ward, for pointing out that we can use the do_div
macro for 64-bit division to avoid depending on __udivdi3

Regards,

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

[PULL] http://kernellabs.com/hg/~mkrufky/k2c2

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/k2c2

for:

- cx23885: override set_frontend to allow rf input path switching on the HVR1275

 cx23885-dvb.c |   29 +
 cx23885.h |2 ++
 2 files changed, 31 insertions(+)

Hopefully, you can get this into the next merge window with all the
other pending changesets ;-)

Thanks & regards,

Mike
--
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: Leadtek Winfast DTV-1000S

[Michael Krufky]

On Sun, Jun 7, 2009 at 6:39 PM, hermann pitton wrote:
>
> Am Montag, den 08.06.2009, 07:59 +1000 schrieb pau...@planar.id.au:
>> That is fantastic news.  Not only will it be coming soon, but I don't have
>> to do it myself!!
>>
>> How will we know when the test repository is created - will it be
>> announced on this list?
>>
>> Thanks,
>>
>> Paul
>>
>>
>> > Henry Wu did send modified saa7134 files with support for this card on
>> > Tuesday off list.
>>
>> > Mike replied, that he will set up a test repository as soon he gets some
>> > time for doing so.
>
> Paul,
>
> give Mike some time for it.
>
> There are much more variables in question, that can be different on
> devices now seen in the wild for the first time and a proper framework
> must be employed.
>
> If you can't wait, ask Mike do send you the files, seems they are recent
> enough for current v4l-dvb, but better is to wait and start with some
> unified testing base.
>
> Cheers,
> Hermann


Hello all,

Apologies for the delay -- I've been extremely busy over the past few
weeks, but that's nothing new :-P

Anyhow, I pushed up some code almost 2 weeks ago that should cover the
DTV1000S in all variations.  Thanks to Terry Wu for the baseband video
gpio setup.

I haven't had time to ask anybody to test this yet, so I'd appreciate
it if you can provide some general feedback.

This change only adds support for the new card, so I am not interested
in anybody's experience with other boards -- this ONLY relates to the
DTV1000S.

Terry's patches copy the device specific setup from the Hauppauge
HVR1110 -- this is actually dangerous, as the HVR1110 GPIO / LNA setup
could cause problems when used on other boards.

Terry's patches also support a version of the board with a TDA18271c2
-- I don't know if such a board actually exists, but the way that
Terry did it doesn't allow for supporting both variations in a single
kernel.  If the c2 version of the board actually exists, the code that
I pushed will work on board boards.

I'd like to see dmesg output while using my tree -- please include
full device initialization, starting with the line, "Linux video
capture interface: v2.00" up till the end.

I am especially interested to see whether or not the TDA8295 driver
attaches successfully -- I have a feeling that there actually is no
TDA8295 on that board, but I don't know for sure, offhand.

Please test the following tree:

http://kernellabs.com/hg/~mkrufky/dtv1000s

- saa7134: add initial DVB-T support for the Leadtek DTV1000S
- saa7134: add support for baseband video capture on Leadtek DTV1000S

 Documentation/video4linux/CARDLIST.saa7134  |1
 drivers/media/video/saa7134/saa7134-cards.c |   22 +
 drivers/media/video/saa7134/saa7134-dvb.c   |   39 ++
 drivers/media/video/saa7134/saa7134.h   |1
 4 files changed, 63 insertions(+)

Cheers,

Mike Krufky
--
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: [PULL] http://kernellabs.com/hg/~mkrufky/k2c2

[Michael Krufky]

Michael Krufky wrote:

Mauro Carvalho Chehab wrote:

Em Tue, 16 Jun 2009 11:19:29 -0400
Michael Krufky  escreveu:

 

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/k2c2

for:

- cx23885: override set_frontend to allow rf input path switching on 
the HVR1275


 cx23885-dvb.c |   29 +
 cx23885.h |2 ++
 2 files changed, 31 insertions(+)

Hopefully, you can get this into the next merge window with all the
other pending changesets ;-)

Thanks & regards,

Mike




 

Use separate RF input spigots for Antennae and Cable.

Priority: normal

Reviewed-by: Steven Toth 
Signed-off-by: Michael Krufky 

--- a/linux/drivers/media/video/cx23885/cx23885-dvb.cTue May 12 
17:53:47 2009 -0400
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.cFri May 08 
21:39:24 2009 -0400

@@ -417,6 +417,30 @@
 .demod_address = 0x05,
 };
 
+static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,

+struct dvb_frontend_parameters *param)
+{
+struct cx23885_tsport *port = fe->dvb->priv;
+struct cx23885_dev *dev = port->dev;
+
+switch (dev->board) {
+case CX23885_BOARD_HAUPPAUGE_HVR1275:
+switch (param->u.vsb.modulation) {
+case VSB_8:
+cx23885_gpio_clear(dev, GPIO_5);
+break;
+case QAM_64:
+case QAM_256:
+default:
+cx23885_gpio_set(dev, GPIO_5);
+break;
+}
+break;
+}
+return (port->set_frontend_save) ?
+port->set_frontend_save(fe, param) : -ENODEV;
+}
+
 static int dvb_register(struct cx23885_tsport *port)
 {
 struct cx23885_dev *dev = port->dev;
@@ -456,6 +480,11 @@
0x60, &dev->i2c_bus[1].i2c_adap,
&hauppauge_hvr127x_config);
 }
+
+/* define bridge override to set_frontend */
+port->set_frontend_save = fe0->dvb.frontend->ops.set_frontend;
+fe0->dvb.frontend->ops.set_frontend = 
cx23885_dvb_set_frontend;

+
 break;
 case CX23885_BOARD_HAUPPAUGE_HVR1255:
 i2c_bus = &dev->i2c_bus[0];
--- a/linux/drivers/media/video/cx23885/cx23885.hTue May 12 
17:53:47 2009 -0400
+++ b/linux/drivers/media/video/cx23885/cx23885.hFri May 08 
21:39:24 2009 -0400

@@ -288,6 +288,8 @@
 /* Allow a single tsport to have multiple frontends */
 u32num_frontends;
 void   *port_priv;
+int (*set_frontend_save) (struct dvb_frontend *,
+  struct dvb_frontend_parameters *);
 };
 
 struct cx23885_dev {





Argh! this looks like a hack! Don't you have a better approach for it?



I have a better approach that I plan to push for the next kernel.  
This is planned for 2.6.31, for 2.6.32 I have a better method that 
will be genericly used for all drivers.


I plan to post an RFC about the new method after the merge window closes.

Can you merge this for now, and the new, better method can be saved 
for the next devel cycle?


I'd just like to add a point:

The method used in this patch is the same method currently used inside 
the dib0700 driver (grep for set_param_save in struct dib0700_adapter_state)


This is the minimal patch for the current merge window -- I'd like to 
merge this one for now, and when the merge window closes, I will issue 
the RFC for the new, better method, while converting dib0700 and cx23885 
both to use this new better method.


Once that is done, this sort of thing will be much clearer and easier to 
accomplish across other drivers in the susbsystem tree.


I have added a FIXME comment as per your request...

Please pull from:

http://kernellabs.com/hg/~mkrufky/k2c2

for the following:

- cx23885: override set_frontend to allow rf input path switching on the 
HVR1275

- cx23885: add FIXME comment above set_frontend override

cx23885-dvb.c |   30 ++
cx23885.h |4 
2 files changed, 34 insertions(+)

Cheers,

Mike


--
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: [PULL] http://kernellabs.com/hg/~mkrufky/k2c2

[Michael Krufky]

Mauro Carvalho Chehab wrote:

Em Tue, 16 Jun 2009 11:19:29 -0400
Michael Krufky  escreveu:

  

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/k2c2

for:

- cx23885: override set_frontend to allow rf input path switching on the HVR1275

 cx23885-dvb.c |   29 +
 cx23885.h |2 ++
 2 files changed, 31 insertions(+)

Hopefully, you can get this into the next merge window with all the
other pending changesets ;-)

Thanks & regards,

Mike




  

Use separate RF input spigots for Antennae and Cable.

Priority: normal

Reviewed-by: Steven Toth 
Signed-off-by: Michael Krufky 

--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c   Tue May 12 17:53:47 
2009 -0400
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c   Fri May 08 21:39:24 
2009 -0400
@@ -417,6 +417,30 @@
.demod_address = 0x05,
 };
 
+static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,

+   struct dvb_frontend_parameters *param)
+{
+   struct cx23885_tsport *port = fe->dvb->priv;
+   struct cx23885_dev *dev = port->dev;
+
+   switch (dev->board) {
+   case CX23885_BOARD_HAUPPAUGE_HVR1275:
+   switch (param->u.vsb.modulation) {
+   case VSB_8:
+   cx23885_gpio_clear(dev, GPIO_5);
+   break;
+   case QAM_64:
+   case QAM_256:
+   default:
+   cx23885_gpio_set(dev, GPIO_5);
+   break;
+   }
+   break;
+   }
+   return (port->set_frontend_save) ?
+   port->set_frontend_save(fe, param) : -ENODEV;
+}
+
 static int dvb_register(struct cx23885_tsport *port)
 {
struct cx23885_dev *dev = port->dev;
@@ -456,6 +480,11 @@
   0x60, &dev->i2c_bus[1].i2c_adap,
   &hauppauge_hvr127x_config);
}
+
+   /* define bridge override to set_frontend */
+   port->set_frontend_save = fe0->dvb.frontend->ops.set_frontend;
+   fe0->dvb.frontend->ops.set_frontend = cx23885_dvb_set_frontend;
+
break;
case CX23885_BOARD_HAUPPAUGE_HVR1255:
i2c_bus = &dev->i2c_bus[0];
--- a/linux/drivers/media/video/cx23885/cx23885.h   Tue May 12 17:53:47 
2009 -0400
+++ b/linux/drivers/media/video/cx23885/cx23885.h   Fri May 08 21:39:24 
2009 -0400
@@ -288,6 +288,8 @@
/* Allow a single tsport to have multiple frontends */
u32num_frontends;
void   *port_priv;
+   int (*set_frontend_save) (struct dvb_frontend *,
+ struct dvb_frontend_parameters *);
 };
 
 struct cx23885_dev {





Argh! this looks like a hack! Don't you have a better approach for it?



I have a better approach that I plan to push for the next kernel.  This 
is planned for 2.6.31, for 2.6.32 I have a better method that will be 
genericly used for all drivers.


I plan to post an RFC about the new method after the merge window closes.

Can you merge this for now, and the new, better method can be saved for 
the next devel cycle?


Thanks & Regards,

Mike
--
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: [PULL] http://kernellabs.com/hg/~mkrufky/k2c2

[Michael Krufky]

On Tue, Jun 16, 2009 at 7:59 PM, Trent Piepho wrote:
> On Tue, 16 Jun 2009, Mauro Carvalho Chehab wrote:
>> Em Tue, 16 Jun 2009 11:19:29 -0400
>> Michael Krufky  escreveu:
>> > +static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
>> > +                               struct dvb_frontend_parameters *param)
>
> You could make this an HVR1275 specific function and then do away with the
> first case statement.  With a name like cx23885_dvb_set_frontend() it
> appears that all boards will use it, when it is only ever called with an
> HVR1275.

Actually, it *will* be used by other boards.  For now it is
HVR1275-specific.  The other changes will come after the close of the
merge window.


>> > +           switch (param->u.vsb.modulation) {
>> > +           case VSB_8:
>> > +                   cx23885_gpio_clear(dev, GPIO_5);
>> > +                   break;
>> > +           case QAM_64:
>> > +           case QAM_256:
>> > +           default:
>> > +                   cx23885_gpio_set(dev, GPIO_5);
>> > +                   break;
>
> Using the modulation to switch inputs is of course a hack, needed because
> the dvb api lacks a concept of multiple inputs.  I do not know if any still
> exist, but there were cable systems which broadcast with both QAM and VS.

By design on this board, VSB uses one input, QAM uses the other.

Cheers,

Mike
--
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: Leadtek Winfast DTV-1000S

[Michael Krufky]

On Fri, Jun 19, 2009 at 12:51 PM, hermann pitton wrote:
> Hi all,
>
> Am Freitag, den 19.06.2009, 19:12 +0930 schrieb James Moschou:
>> 2009/6/19 Terry Wu :
>> > Hi,
>> >
>> >>>[    9.916022] saa7134 :05:01.0: firmware: requesting 
>> >>>dvb-fe-tda10048-1.0.fw
>> >>>[   10.020209] tda10048_firmware_upload: Upload failed. (file not found?)
>> >
>> > The dvb-fe-tda10048-1.0.fw is needed.
>> > You can get it from the following links:
>> > http://tw1965.myweb.hinet.net/Linux/firmware.tar.gz
>> > http://tw1965.myweb.hinet.net/Linux/Firmware.txt
>> > http://tw1965.myweb.hinet.net/
>>
>> Firmware is copied to /lib/firmware
>>
>> Here is the dmesg:
>>
>> [    8.570412] Linux video capture interface: v2.00
>> [    8.617769] cfg80211: World regulatory domain updated:
>> [    8.617772]        (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [    8.617774]        (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
>> 2000 mBm)
>> [    8.617775]        (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 
>> 2000 mBm)
>> [    8.61]        (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 
>> 2000 mBm)
>> [    8.617778]        (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 
>> 2000 mBm)
>> [    8.617780]        (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 
>> 2000 mBm)
>> [    8.680521] saa7130/34: v4l2 driver version 0.2.15 loaded
>> [    8.680571] saa7134 :05:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 
>> 19
>> [    8.680576] saa7130[0]: found at :05:01.0, rev: 1, irq: 19,
>> latency: 32, mmio: 0xfb002000
>> [    8.680581] saa7130[0]: subsystem: 107d:6655, board: Hauppauge
>
> Mike seems to have the subdevice wrong. He used 107d:6555.
>
> That is why the card is not auto detected.
>
> Please try to force card=169 and _not_ card=156.
>
> Cheers,
> Hermann
>
>
>> WinTV-HVR1110r3 DVB-T/Hybrid [card=156,insmod option]
>> [    8.680606] saa7130[0]: board init: gpio is 22009
>> [    8.827183] HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level,
>> low) -> IRQ 22
>> [    8.827229] HDA Intel :00:1b.0: setting latency timer to 64
>> [    8.860026] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43
>> 43 a9 1c 55 d2 b2 92
>> [    8.860035] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860043] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08
>> ff 00 8a ff ff ff ff
>> [    8.860051] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860059] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff
>> 04 ff ff ff ff ff ff
>> [    8.860067] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860074] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860082] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860089] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860097] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860105] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860112] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860120] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860127] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860135] saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860143] saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
>> ff ff ff ff ff ff ff
>> [    8.860152] tveeprom 0-0050: Encountered bad packet header [ff].
>> Corrupt or not a Hauppauge eeprom.
>> [    8.860154] saa7130[0]: warning: unknown hauppauge model #0
>> [    8.860156] saa7130[0]: hauppauge eeprom: model=0
>> [    8.932026] Chip ID is not zero. It is not a TEA5767
>> [    8.932091] tuner 0-0060: chip found @ 0xc0 (saa7130[0])
>> [    8.976009] tda8290: no gate control were provided!
>> [    8.976079] tuner 0-0060: Tuner has no way to set tv freq
>> [    8.976084] tuner 0-0060: Tuner has no way to set tv freq
>> [    8.976170] saa7130[0]: registered device video0 [v4l2]
>> [    8.976214] saa7130[0]: registered device vbi0
>> [    8.976251] saa7130[0]: registered device radio0
>> [    8.976281] rt2400pci :05:00.0: PCI INT A -> GSI 20 (level,
>> low) -> IRQ 20
>> [    8.983389] phy0: Selected rate control algorithm 'pid'
>> [    9.017796] dvb_init() allocating 1 frontend
>> [    9.036163] saa7134 ALSA driver for DMA sound loaded
>> [    9.036165] saa7130[0]/alsa: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid
>> doesn't support digital audio
>> [    9.068118] Registered led device: rt2400pci-phy0:radio
>> [    9.068149] Registered led device: rt2400pci-phy0:quality
>> [    9.140897] tda18271 0-0060: creating new instance
>> [    9.148509] TDA18271HD/C1 detected @ 0-0060
>> [    9.157831] lp0: using parport0 (interrupt-driven

[PULL] http://kernellabs.com/hg/~mkrufky/bug-fix

[Michael Krufky]

Mauro,

Please note that there are two pull requests in this email.

Please pull from:

http://kernellabs.com/hg/~mkrufky/bug-fix

for the following bug fixes, which should be sent to Linus for 2.6.31.

- tda10048: add missing entry to pll_tab for 3.8 MHz IF
- cx23885: ensure correct IF freq is used on HVR1200 & HVR1700

 dvb/frontends/tda10048.c|1 +
 video/cx23885/cx23885-dvb.c |   10 ++
 2 files changed, 11 insertions(+)


Please also note that a previous pull request is still pending -- I'd
like to see the following change sent to Linus for 2.6.31.  Please
pull from:

http://kernellabs.com/hg/~mkrufky/k2c2

for:

- cx23885: override set_frontend to allow rf input path switching on the HVR1275
- cx23885: add FIXME comment above set_frontend override

 cx23885-dvb.c |   30 ++
 cx23885.h |4 
 2 files changed, 34 insertions(+)

Thanks,

Mike
--
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: Leadtek Winfast DTV-1000S

[Michael Krufky]

(apologies if you've received this email twice -- something is strange
with my kernellabs.com email settings -- I will look into this soon)

On Mon, Jun 22, 2009 at 6:51 AM, James Moschou wrote:
> Using dtv1000s tree revision 21a03349f7f9 and a blank modprobe.conf
>
> I can tune to channels but never all of them in the single run of w_scan.
> Every time I run w_scan it's different channels that say 'filter timeout'.

James,

Unfortunately, I can't say that a driver bug is the cause of your
inconsistency -- perhaps you can aim your antennae a bit better, or
find some other cause of interference.  Bad cabling?

Lets say that you have your channels.conf all set up and ready -- once
you found all your services, do you have trouble keeping a stream?

Regards,

Mike
--
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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?

[Michael Krufky]

On Thu, Jun 25, 2009 at 2:25 PM, Devin
Heitmueller wrote:
> Hans,
>
> I just spoke with mkrufky, and he confirmed the issue does occur with
> the HVR-950.  However, the em28xx driver does not do a printk() when
> the subdev registration fails (I will submit a patch to fix that).
>
> Please let me know if you have any further question.
>
> Thanks for your assistance,

I'd like to add:

Testing against 2.6.24.7: v4l subdev registration fails.
Testing against 2.6.25.20: v4l subdev registration fails.
...
Testing against 2.6.26.8: success!
Testing against 2.6.27.25: success!
Testing against 2.6.28.10: success!
... (I didn't bother testing 2.6.29.y)
Testing against 2.6.30: success!

Regards,

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

[PULL] http://kernellabs.com/hg/~mkrufky/au0828

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/au0828

for the following kernel-compat fix:

- au0828: fix i2c for kernels prior to 2.6.26

 au0828-i2c.c |3 +++
 1 file changed, 3 insertions(+)

Please note that this tree also contains some changesets from Hans
Verkuil's v4l-dvb-misc tree -- Most likely, you will see his pull
request and merge it first before you get to this one.

Please *also* note that I am still waiting for you to merge my pending
changsets from:

http://kernellabs.com/hg/~mkrufky/k2c2

for the following fixes that should be merged into Linus' tree for 2.6.31:

- cx23885: override set_frontend to allow rf input path switching on the HVR1275
- cx23885: add FIXME comment above set_frontend override

 cx23885-dvb.c |   30 ++
 cx23885.h |4 
 2 files changed, 34 insertions(+)

Cheers,

Mike
--
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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?

[Michael Krufky]

On Fri, Jun 26, 2009 at 1:59 PM, Devin
Heitmueller wrote:
> On Fri, Jun 26, 2009 at 1:50 PM, Hans Verkuil wrote:
>> On Thursday 25 June 2009 20:25:31 Devin Heitmueller wrote:
>>> Hans,
>>>
>>> I just spoke with mkrufky, and he confirmed the issue does occur with
>>> the HVR-950.  However, the em28xx driver does not do a printk() when
>>> the subdev registration fails (I will submit a patch to fix that).
>>>
>>> Please let me know if you have any further question.
>>>
>>> Thanks for your assistance,
>>>
>>> Devin
>>>
>>
>> Fixed in my http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc tree.
>>
>> A pull request for this has already been posted, so it should be merged soon
>> I hope.
>>
>> It was a trivial change: originally the new i2c API would be used for kernels
>> 2.6.22 and up, until it was discovered that there was a serious bug in the 
>> i2c
>> core that wasn't fixed until 2.6.26. So I changed it to kernel 2.6.26.
>>
>> Unfortunately, the em28xx driver was still using 2.6.22 as the cut-off point,
>> preventing i2c drivers from being initialized. So em28xx was broken for
>> kernels 2.6.22-2.6.25.
>
> Ok, I will submit a comparable fix for au0828.  I guess maybe it makes
> sense also to audit all the bridges where we set the .class field to
> ensure they all are for 2.6.26.

Thanks Devin and Hans.

I fixed it in the au0828 driver...  Fix and pull request are here:

http://www.spinics.net/lists/linux-media/msg07360.html

Cheers,

Mike
--
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: cx23885, new hardware revision found

[Michael Krufky]

On Mon, Jun 29, 2009 at 9:43 AM, Steven Toth wrote:
>>> cx23885_dev_checkrevision() New hardware revision found 0x0
>>> cx23885_dev_checkrevision() Hardware revision unknown 0x0
>>> cx23885[0]/0: found at :02:00.0, rev: 4, irq: 17, latency: 0,
>>> mmio: 0xfd80
>>> cx23885 :02:00.0: setting latency timer to 64
>>>
>>> I'm pretty sure that is the problem but I don't know how to fix it.  I
>
> The new revision isn't the problem, the above code is for information
> purposes so we can track new revs of the silicon in this mailing list. Most
> likely the demodulators / tuners are not configured correctly. DViCO
> probably changed something.
>
> Double check that the silicon and gpios / settings inside the cx23885 driver
> for the existing card definition match the silicon and configuration for
> this new card you have.
>

It's not a new revision.  Something else is wrong.  I have both
revisions of this board, and they display the same revision
information as Hauppauge cx23885-based products:

m...@codes:~$ dmesg | grep checkrevision
[  136.689267] cx23885_dev_checkrevision() Hardware revision = 0xb0
[  136.914968] cx23885_dev_checkrevision() Hardware revision = 0xb0
[  137.086548] cx23885_dev_checkrevision() Hardware revision = 0xb0

If it was a PCI card I would suggest moving it to another PCI slot,
but I'm not sure that would help at all in the case of PCIe.

DViCO has not updated their Windows driver since April of last year.
I think that Michael Kutyna should confirm that the device works in
windows before anybody proceeds to troubleshoot this any further -- it
might just be a bad board / platform.

-Mike Krufky
--
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: [linux-dvb] Hauppauge HVR-1800 not working at all

[Michael Krufky]

On Tue, Jun 30, 2009 at 1:01 PM, George Czerw wrote:
>
> Using Mandriva 2009.1 with HVR connected directly to analog cable.
> Using 32-bit kernel 2.6.29.3-desktop-1.mnb.
>
> TVtime and xawTV both open but display only snow.  Channel scanning yields
> nothing.
>
> If I boot into Vista and load MediaCenter, open liveTV and watch a channel.
> Then close MediaCenter, exit Vista and boot into linux, TVtime and xawTV (if I
> am lucky) might open-up and perfectly display the TV channel that I was last
> viewing in Vista, but will not change channels to another station no matter
> what I do.
>
> Please see the following outputs below. I would appreciate any
> suggestions to resolve this. Not having hardware problems since WinVista's
> media center works perfectly with this hardware.
>
> Thanks
> George
>
> *
>
> tvtime -v
> Running tvtime 1.0.2.
>
> Reading configuration from /etc/tvtime/tvtime.xml
>
> Reading configuration from /home/george/.tvtime/tvtime.xml
>
> cpuinfo: CPU Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz, family 6,
> model 7, stepping 7.
>
> cpuinfo: CPU measured at 2333.352MHz.
>
> xcommon: Display :0.0, vendor The X.Org Foundation, vendor release 10601000
>
> xfullscreen: Using XINERAMA for dual-head information.
> xfullscreen: Pixels are square.
> xfullscreen: Number of displays is 1.
> xfullscreen: Head 0 at 0,0 with size 1440x900.
> xcommon: Have XTest, will use it to ping the screensaver.
> xcommon: Pixel aspect ratio 1:1.
> xcommon: Pixel aspect ratio 1:1.
> xcommon: Window manager is KWin and is EWMH compliant.
> xcommon: Using EWMH state fullscreen property.
> xcommon: Using EWMH state above property.
> xcommon: Using EWMH state below property.
> xcommon: Pixel aspect ratio 1:1.
> xcommon: Displaying in a 768x576 window inside 768x576 space.
> xvoutput: Using XVIDEO adaptor 280: NV17 Video Texture.
> speedycode: Using MMXEXT optimized functions.
> station: Reading stationlist from /home/george/.tvtime/stationlist.xml
> videoinput: Using video4linux2 driver 'cx23885', card 'Hauppauge
> WinTV-HVR1800' (bus PCIe::03:00.0).
> videoinput: Version is 1, capabilities 5010011.
> videoinput: Maximum input width: 720 pixels.
> tvtime: Sampling input at 720 pixels per scanline.
> xcommon: Pixel aspect ratio 1:1.
> xcommon: Displaying in a 768x576 window inside 768x576 space.
> xcommon: Received a map, marking window as visible (62).
> xcommon: Window fully obscured, marking window as hidden (62).
> xcommon: Window made visible, marking window as visible (62).
> tvtime: Cleaning up.
> Thank you for using tvtime.
>
> 
>
>
> # lspci
> 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM
> Controller (rev
> 02)
> 00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI
> Express Root Port (rev
> 02)
> 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #4 (rev
> 02)
> 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #5 (rev
> 02)
> 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
> Controller #2 (rev
> 02)
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
> Controller (rev
> 02)
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 1 (rev 02)
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 2 (rev 02)
> 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 3 (rev 02)
> 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #1 (rev 02)
> 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #2 (rev 02)
> 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #3 (rev 02)
> 00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #6 (rev 02)
> 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
> Controller #1 (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) 00:1f.0
> ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller
> (rev 02)
> 00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller
> (rev 02)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller
> (rev 02)
> 01:05.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 70) 02:00.0
> Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI
> Express Gigabit Ethernet controller (rev 02) 03:00.0 Multimedia video
> controller: Conexant Systems, Inc. Device 8880 (rev 0f)
> 04:00.0 Network controller: Atheros Communications Inc. AR928X Wireless
> Network Adapter (PCI-Express) (rev 01) 05:00.0 VGA compatible controller:
> nVidia Corporation Device 0644 (rev a1)
>
> ***
>
> # v4l-conf
> v4l-conf: using X11 display :0.0
> dga: version 2.0
> WARNING: No DGA direct video mode for this display. mode: 1440x900,
> depth=24, bpp=32, bpl=5760, base=unknown /dev

Re: [linux-dvb] Hauppauge HVR-1800 not working at all

[Michael Krufky]

George Czerw wrote:

On Tuesday 30 June 2009 13:43:49 you wrote:
  

On Tue, Jun 30, 2009 at 1:01 PM, George Czerw wrote:


Using Mandriva 2009.1 with HVR connected directly to analog cable.
Using 32-bit kernel 2.6.29.3-desktop-1.mnb.

TVtime and xawTV both open but display only snow.  Channel scanning
yields nothing.

If I boot into Vista and load MediaCenter, open liveTV and watch a
channel. Then close MediaCenter, exit Vista and boot into linux, TVtime
and xawTV (if I am lucky) might open-up and perfectly display the TV
channel that I was last viewing in Vista, but will not change channels to
another station no matter what I do.

Please see the following outputs below. I would appreciate any
suggestions to resolve this. Not having hardware problems since
WinVista's media center works perfectly with this hardware.

Thanks
George

*

tvtime -v
Running tvtime 1.0.2.

Reading configuration from /etc/tvtime/tvtime.xml

Reading configuration from /home/george/.tvtime/tvtime.xml

cpuinfo: CPU Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz, family 6,
model 7, stepping 7.

cpuinfo: CPU measured at 2333.352MHz.

xcommon: Display :0.0, vendor The X.Org Foundation, vendor release
10601000

xfullscreen: Using XINERAMA for dual-head information.
xfullscreen: Pixels are square.
xfullscreen: Number of displays is 1.
xfullscreen: Head 0 at 0,0 with size 1440x900.
xcommon: Have XTest, will use it to ping the screensaver.
xcommon: Pixel aspect ratio 1:1.
xcommon: Pixel aspect ratio 1:1.
xcommon: Window manager is KWin and is EWMH compliant.
xcommon: Using EWMH state fullscreen property.
xcommon: Using EWMH state above property.
xcommon: Using EWMH state below property.
xcommon: Pixel aspect ratio 1:1.
xcommon: Displaying in a 768x576 window inside 768x576 space.
xvoutput: Using XVIDEO adaptor 280: NV17 Video Texture.
speedycode: Using MMXEXT optimized functions.
station: Reading stationlist from /home/george/.tvtime/stationlist.xml
videoinput: Using video4linux2 driver 'cx23885', card 'Hauppauge
WinTV-HVR1800' (bus PCIe::03:00.0).
videoinput: Version is 1, capabilities 5010011.
videoinput: Maximum input width: 720 pixels.
tvtime: Sampling input at 720 pixels per scanline.
xcommon: Pixel aspect ratio 1:1.
xcommon: Displaying in a 768x576 window inside 768x576 space.
xcommon: Received a map, marking window as visible (62).
xcommon: Window fully obscured, marking window as hidden (62).
xcommon: Window made visible, marking window as visible (62).
tvtime: Cleaning up.
Thank you for using tvtime.




# lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM
Controller (rev
02)
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI
Express Root Port (rev
02)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #4 (rev
02)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #5 (rev
02)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #2 (rev
02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
Controller (rev
02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #6 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) 00:1f.0
ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller
(rev 02)
00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller
(rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller
(rev 02)
01:05.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 70) 02:00.0
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI
Express Gigabit Ethernet controller (rev 02) 03:00.0 Multimedia video
controller: Conexant Systems, Inc. Device 8880 (rev 0f)
04:00.0 Network controller: Atheros Communications Inc. AR928X Wireless
Network Adapter (PCI-Express) (rev 01) 05:00.0 VGA compatible controller:
nVidia Corporation Device 0644 (rev a1)

***

# v4l-conf
v4l-conf: using X11 display :0.0
dga: version 2.0
WARNING: No DGA direct video mode for this display. mode: 1440x900,
depth=24, bpp=32, bpl=5760, base=unknown /dev/video0 [v4l2]: no overlay
support

***
selected DMESG output:

nvidia: module license 'NVIDIA' taints kernel.

nvidia :05:00.0: PCI INT 

Re: [PULL] http://kernellabs.com/hg/~mkrufky/au0828

[Michael Krufky]

Mauro Carvalho Chehab wrote:

Em Fri, 26 Jun 2009 15:42:43 -0400
Michael Krufky  escreveu:

  

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/au0828

Please *also* note that I am still waiting for you to merge my pending
changsets from:

http://kernellabs.com/hg/~mkrufky/k2c2




Please, only one pull request by email, or otherwise you'll break the way I
handle my job queue.

Thanks,
Mauro.
  

Mauro,

It was a single pull request.  The second one was a reminder, since you 
already agreed to merge it last month.


Can you recommend a better way for us to ping you about missed merge 
requests?


Thanks & regards,

Mike
--
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: [linux-dvb] Hauppauge HVR-1800 not working at all

[Michael Krufky]

George Czerw wrote:

On Tuesday 30 June 2009 15:56:08 Devin Heitmueller wrote:
  

On Tue, Jun 30, 2009 at 3:48 PM, George Czerw wrote:


Devin, thanks for the reply.

Lsmod showed that "tuner" was NOT loaded (wonder why?), a "modprobe
tuner" took care of that and now the HVR-1800 is displaying video
perfectly and the tuning function works.  I guess that I'll have to add
"tuner" into modprobe.preload.d  Now if only I can get the sound
functioning along with the video!

George
  

Admittedly, I don't know why you would have to load the tuner module
manually on the HVR-1800.  I haven't had to do this on other products?

If you are doing raw video capture, then you need to manually tell
applications where to find the ALSA device that provides the audio.
If you're capturing via the MPEG encoder, then the audio will be
embedded in the stream.

Devin



I don't understand why the audio/mpeg ports of the HVR-1800 don't show up in 
output of lspci:


03:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8880 (rev 
0f)
Subsystem: Hauppauge computer works Inc. Device 7801
Flags: bus master, fast devsel, latency 0, IRQ 17   
Memory at f9c0 (64-bit, non-prefetchable) [size=2M] 
Capabilities: [40] Express Endpoint, MSI 00 
Capabilities: [80] Power Management version 2   
Capabilities: [90] Vital Product Data   
Capabilities: [a0] MSI: Mask- 64bit+ Count=1/1 Enable-  
Capabilities: [100] Advanced Error Reporting
Capabilities: [200] Virtual Channel  
Kernel driver in use: cx23885   
Kernel modules: cx23885



even though the dmesg output clearly shows this:

tveeprom 0-0050: decoder processor is CX23887 (idx 37) 
tveeprom 0-0050: audio processor is CX23887 (idx 42)



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





Please try this:

When you have tvtime open and running with video working already, do:

mplayer /dev/video1

(assuming that tvtime is open on video0)

Then, you'll get mplayer complete with both audio and video.

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

[RESEND PULL] http://kernellabs.com/hg/~mkrufky/k2c2

[Michael Krufky]

Mauro,

Resending this pull request for the 4th time.  You've agreed to merge
this last month.

This change should go to Linus for 2.6.31 -- Please send this to him
with your first round of bugfixes for 2.6.31

Please pull from:

http://kernellabs.com/hg/~mkrufky/k2c2

for:

- cx23885: override set_frontend to allow rf input path switching on the HVR1275
- cx23885: add FIXME comment above set_frontend override

 cx23885-dvb.c |   30 ++
 cx23885.h |4 
 2 files changed, 34 insertions(+)


Regards,

Mike
--
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: [RESEND PULL] http://kernellabs.com/hg/~mkrufky/k2c2

[Michael Krufky]

On Wed, Jul 1, 2009 at 9:18 AM, Mauro Carvalho
Chehab wrote:
> Em Wed, 1 Jul 2009 08:04:55 -0400
> Michael Krufky  escreveu:
>
>> Mauro,
>>
>> Resending this pull request for the 4th time.  You've agreed to merge
>> this last month.
>>
>> This change should go to Linus for 2.6.31 -- Please send this to him
>> with your first round of bugfixes for 2.6.31
>>
>> Please pull from:
>>
>> http://kernellabs.com/hg/~mkrufky/k2c2
>
> Argh! I was not noticing that your tree were causing merge conflicts with 
> mine:
>
> $ ./v4l/scripts/do_merge.pl http://kernellabs.com/hg/~mkrufky/k2c2
> Checking if everything is ok, before applying the new tree.
> hg pull http://kernellabs.com/hg/~mkrufky/k2c2
> pulling from http://kernellabs.com/hg/~mkrufky/k2c2
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 2 changesets with 4 changes to 2 files (+1 heads)
> (run 'hg heads' to see heads, 'hg merge' to merge)
> Merging the new changesets
> merging linux/drivers/media/video/cx23885/cx23885-dvb.c
> warning: conflicts during merge.
> merging linux/drivers/media/video/cx23885/cx23885-dvb.c failed!
> merging linux/drivers/media/video/cx23885/cx23885.h
> 0 files updated, 1 files merged, 0 files removed, 1 files unresolved
> use 'hg resolve' to retry unresolved file merges
> hg merge failed. Can't procceed.
> *** ERROR *** Rolling back hg pull http://kernellabs.com/hg/~mkrufky/k2c2
> rolling back last transaction
> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> This probably happened since the first time you sent me the patch. I've 
> patched
> the do_merge.pl script to print a louder error message to be easier for
> noticing when a pull request failed.
>
> What's even more weird is that applying the patches manually work fine. So, I
> suspect that somehow your tree is corrupted. Another possibility is that some
> patches between your patch parent and tip changed something at the same place
> you're touching, and hg couldn't solve the conflict.
>
> To avoid even more troubles with this, I've manually picked the two patches 
> and
> applied with ./mailimport script. Please, re-generate this tree, since the
> hash of the patches has changed.

Thanks for merging it.

There's only one problem now -- I had the patches marked as HIGH
priority, but now it is marked NORMAL -- Can you please make sure to
send this change to Linus for 2.6.31?

Thanks again.

Regards,

Mike
--
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: regression : saa7134 with Pinnacle PCTV 50i (analog) can not tune anymore

[Michael Krufky]

On Tue, Jul 7, 2009 at 4:45 PM, hermann pitton wrote:
> As far I know we did not change the bus speed or anything, but some
> cards need and i2c quirk to work correctly with the clients.
>
> Mike recently changed the old quirk with good reasons and it was widely
> tested, also by me, without any negative effect seen.
>
> Maybe your card is a rare case needing the old quirk.

I've already testes in the Pinnacle board and the quirk did not cause
any new problems.

I mentioned, however, that I saw some frontend issues that should be
looked at.  I dont have time right now to deal with this myself, but
perhaps within the next few weeks I can take a look at it.

Meanwhile, that was with respect to digital reception, only -- I did
not have such problems with analog -- not that I recall, at least.

Also, it does no good to manually modprobe tda8290, tda827x or
tda18271 -- the -dvb bridge driver will attach those modules as
needed, just as the tuner.ko module would as well.

I'd recommend to go back to a stable vanilla kernel, then rebuild
v4l-dvb from linuxtv.org with all options enabled.  If there are still
issues at that point, it should be looked at again.

Sorry I dont have any real answers, but I have my eye on this thread
-- I'll chime in if I can offer any more advice.

Good Luck,

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

[PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Michael Krufky]

Mauro,

Changeset 0842e3bae660 thoroughly breaks all of the Hauppauge devices
that use the sms1xxx driver.  This changeset adds device specific
changes that affect Hauppauge devices, ONLY.  It added no value to the
driver, and only broke its functionality.

I specifically nack'd this particular changeset, but it was merged
anyway.  I believe this was done in error, since it was one patch in
the middle of many others sent in from Uri at that point in time.

This change breaks the Hauppauge devices in such a way that prevents
normal device operation.  The entire concept of board events in this
driver is thoroughly broken, and the only devices currently using it
are the Hauppauge devices.

The patchset removes the board event usage from the Hauppauge-specific
device configuration, replacing with the older mechanism to handle
board events.

The event functions being called in smsdvb.c call into sms-cards.c --
if the device configuration does not have functionality defined for
that event, the driver will simply do nothing and return control back
to the smsdvb.c driver.  These functions are a no-op for non-hauppauge
devices.  Under no circumstances will they cause any harm or any
breakage to any devices supported by this driver.

Personally, I would like to see this board event mechanism within the
driver repaired, so that the Hauppauge devices can use the new
mechanism that Siano has created.  Until that mechanism functions
properly, we will use the older mechanism.  Not doing so would be a
regression, since all of this functionality worked in previous
kernels.

These two changesets must be merged ASAP and sent to Linus for the
2.6.31 kernel.

Please pull from:

http://kernellabs.com/hg/~mkrufky/sms1xxx

for the following fixes:

- sms1xxx: fix broken Hauppauge devices
- sms1xxx: restore GPIO functionality for all Hauppauge devices

 sms-cards.c |  100 
 smsdvb.c|   44 +
 2 files changed, 44 insertions(+), 100 deletions(-)

Cheers,

Mike
--
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] cx23885-417: fix setting tvnorms

[Michael Krufky]

On Thu, Jul 30, 2009 at 9:25 AM, Steven Toth wrote:
> On 7/30/09 1:46 AM, Joseph Yasi wrote:
>>
>> Currently, the VIDIOC_S_STD ioctl just returns -EINVAL regardless of
>> the norm passed.  This patch sets cx23885_mpeg_template.tvnorms and
>> cx23885_mpeg_template.current_norm so that the VIDIOC_S_STD will work.
>>
>> Signed-off-by: Joseph A. Yasi
>
> Joseph, thank you for raising this.
>
> We have this change and a few others already stacked up in this tree:
>
> http://www.kernellabs.com/hg/~mkrufky/cx23885-api/rev/0391fb200be2
>
> The end result is to get MythTV using the HVR1800 analog encoder correctly.
>
> The tree itself is considered experimental but during testing we had noticed
> the same issue, so, again, thank you for raising the same issue. Two people
> reporting the same issue is always better than none.
>
> - Steve

I will break out this patch from the huge patch-mess in my cx23885-api
tree so that it can be merged separately from the other less-obvious
fixes.

Thanks again for pointing it out -- I'll see this fix gets merged
sooner than later ;-)

Cheers,

Mike
--
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: What happen with driver cx23885?

[Michael Krufky]

2009/7/30 
>
> Hi Michael
> I have tv card (Compro VideoMate E800) on cx23885 chipset, it work good
> (only DVB-T part) when i using driver v4l-dvb changeset till 11017
> http://linuxtv.org/hg/v4l-dvb/rev/c2e9ae022ea7, but when I try to update
> for new version changeset 11018 or newly, I can't scan or add channels in
> all TV views or players.when i used  tip . If you know how correct it
> answed me.
>
> P.S. Sorry for my english
>
> My system
> Ubuntu 9.04 x86_64
> Linux 2.6.28-11-generic
>
> Not working can't add new channels with the last v4l-dvb changeset 12345
> http://linuxtv.org/hg/v4l-dvb/rev/ee6cf88cb5d3
> dmesg
> [   14.138166] cx23885 driver version 0.0.2 loaded
> [   14.138769] ACPI: PCI Interrupt Link [APC8] enabled at IRQ 16
> [   14.138785] cx23885 :04:00.0: PCI INT A -> Link[APC8] -> GSI 16
> (level, low) -> IRQ 16
> [   14.138963] CORE cx23885[0]: subsystem: 1858:e800, board: Compro
> VideoMate E650F [card=13,insmod option]
> [   14.227800] synaptics was reset on resume, see synaptics_resume_reset
> if you have trouble on resume
> [   14.322688] HDA Intel :00:09.0: power state changed by ACPI to D0
> [   14.323201] ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22
> [   14.323209] HDA Intel :00:09.0: PCI INT A -> Link[AAZA] -> GSI 22
> (level, low) -> IRQ 22
> [   14.323296] HDA Intel :00:09.0: setting latency timer to 64
> [   14.336415] cx25840 2-0044: cx25  0-21 found @ 0x88 (cx23885[0])
> [   14.340488] cx25840 2-0044: firmware: requesting v4l-cx23885-avcore-01.fw
> [   15.010428] cx25840 2-0044: loaded v4l-cx23885-avcore-01.fw firmware
> (16382 bytes)
> [   15.016339] cx23885_dvb_register() allocating 1 frontend(s)
> [   15.016344] cx23885[0]: cx23885 based dvb card
> [   15.100946] xc2028 1-0061: creating new instance
> [   15.100950] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
> [   15.100956] DVB: registering new adapter (cx23885[0])
> [   15.100960] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353
> DVB-T)...
> [   15.101656] cx23885_dev_checkrevision() Hardware revision = 0xb0
> [   15.101667] cx23885[0]/0: found at :04:00.0, rev: 2, irq: 16,
> latency: 0, mmio: 0xef60
> [   15.101674] cx23885 :04:00.0: setting latency timer to 64
>
> scan -cv
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> WARNING: filter timeout pid 0x0011
> WARNING: filter timeout pid 0x
> dumping lists (0 services)
> Done.
>
> ~/.tzap$ scan metv > channels.conf
> scanning metv
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> initial transponder 63400 0 9 9 6 2 4 4
> initial transponder 65000 0 2 2 3 1 0 0
> initial transponder 71400 0 9 9 6 2 4 4
> initial transponder 81800 0 9 9 6 2 4 4
> >>> tune to:
> 63400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO
> WARNING: filter timeout pid 0x0011
> WARNING: filter timeout pid 0x
> WARNING: filter timeout pid 0x0010
> >>> tune to:
> 65000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> WARNING: filter timeout pid 0x0011
> WARNING: filter timeout pid 0x
> WARNING: filter timeout pid 0x0010
> >>> tune to:
> 71400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO
> WARNING: filter timeout pid 0x0011
> WARNING: filter timeout pid 0x
> WARNING: filter timeout pid 0x0010
> >>> tune to:
> 81800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO
> WARNING: filter timeout pid 0x0011
> WARNING: filter timeout pid 0x
> WARNING: filter timeout pid 0x0010
> dumping lists (0 services)
> Done.
>
> w_scan version 20081106
> Info: using DVB adapter auto detection.
>   Found DVB-T frontend. Using adapter /dev/dvb/adapter0/frontend0
> -_-_-_-_ Getting frontend capabilities-_-_-_-_
> frontend Zarlink ZL10353 DVB-T supports
> INVERSION_AUTO
> QAM_AUTO
> TRANSMISSION_MODE_AUTO
> GUARD_INTERVAL_AUTO
> HIERARCHY_AUTO
> FEC_AUTO
> -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
> 177500:
> 184500:
> 191500:
> 198500:
> 205500:
> 212500:
> 219500:
> 226500:
> 474000:
> 482000:
> 49:
> 498000:
> 506000:
> 514000:
> 522000:
> 53:
> 538000:
> 546000:
> 554000:
> 562000:
> 57:
> 578000:
> 586000:
> 594000:
> 602000:
> 61:
> 618000:
> 626000:
> 634000: signal ok (I999B8C999D999M999T999G999Y999)
> 642000:
> 65: signal ok (I999B8C999D999M999T999G999Y999)
> 658000:
> 666000:
> 674000:
> 682000:
> 69:
> 698000:
> 706000:
> 714000: signal ok (I999B8C999D999M999T999G999Y999)
> 722000:
> 73:
> 738000:
> 746000:
> 754000:
> 762000:
> 77:
> 778000:
> 786000:
> 794000:
> 802000:
> 81:
> 818000: signal ok (I999B8C999D999M999T999G999Y999)
> 826000:
> 834000:
> 842000:
> 85:
> 858000:
> tune to: :634000:I999B8C999D999M999T999G999Y999:T:27500:
> Info: filter timeout pid 0

[PULL] http://kernellabs.com/hg/~mkrufky/au0828-fix

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/au0828-fix

for the following one-liner fix:

- au0828: fix typo: dvb uses bulk xfer, dont say isoc in debug

 au0828-dvb.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cheers,

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

[PULL] http://kernellabs.com/hg/~mkrufky/cx23885

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/cx23885

for the following fix:

- cx23885-417: fix manipulation of tvnorms

 cx23885-417.c |2 ++
 1 file changed, 2 insertions(+)

Cheers,

Mike
--
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: Fw: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Michael Krufky]

> From: Michael Krufky 
>
> Changeset 0842e3bae660 thoroughly breaks all of the Hauppauge devices
> that use the sms1xxx driver.  This changeset adds device specific
> changes that affect Hauppauge devices, ONLY.
>
[snip]
>
> The patchset removes the board event usage from the Hauppauge-specific
> device configuration, replacing with the older mechanism to handle
> board events.
>
[snip]
>
> These two changesets must be merged ASAP and sent to Linus for the
> 2.6.31 kernel.
>
> Please pull from:
>
> http://kernellabs.com/hg/~mkrufky/sms1xxx
>
> for the following fixes:
>
> - sms1xxx: fix broken Hauppauge devices
> - sms1xxx: restore GPIO functionality for all Hauppauge devices
>
>  sms-cards.c |  100 
>  smsdvb.c    |   44 +
>  2 files changed, 44 insertions(+), 100 deletions(-)
>
> Cheers,
>
> Mike

On Thu, Jul 30, 2009 at 7:07 PM, Mauro Carvalho
Chehab wrote:
> Hi Udi,
>
> Could you please review this patch and give your comments at the ML? We should
> avoid any regression on Linux Kernel, so, in principle, this patch should be
> merged. So, if this won't break non-Hauppauge devices, please ack.
>
> Cheers,
> Mauro.

Mauro,

Thank you for considering my pull request -- I agree that it would be
nice to have Udi's input on these changes, however, in reality, my
patchset does not add any new code -- it removes the broken code and
restores previous functionality.

As much as I'd like this to be merged as soon as possible, I do agree
that it would be reasonable to give Udi a chance to review it first.

Considering that the current driver is thoroughly broken, I ask that
while we wait for Udi's review, that you at least merge the first
changeset, that removes the broken code.

To avoid any need for you to do any cherry-picking, I have pushed a
separate repository with the broken code removal patch separately.

Please pull from:

http://kernellabs.com/hg/~mkrufky/sms1xxx-unbreak

for the following URGENT fix:

- sms1xxx: fix broken Hauppauge devices

 sms-cards.c |  100 
 1 file changed, 100 deletions(-)


Please review this patch yourself -- you will see I am simply removing
Hauppauge-specific handling that was incorrectly added by Uri,
resulting in the crippling of these devices under Linux.

I cant stress enough how important it is that this changeset gets
merged upstream to Linus asap.  The 2.6.31-rc kernel is broken without
this change.

Regards,

Mike
--
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: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Michael Krufky]

On Sat, Aug 1, 2009 at 12:40 AM, Mauro Carvalho
Chehab wrote:
> Em Fri, 31 Jul 2009 11:25:55 -0400
> Michael Krufky  escreveu:
>
>> Please review this patch yourself -- you will see I am simply removing
>> Hauppauge-specific handling that was incorrectly added by Uri,
>> resulting in the crippling of these devices under Linux.
>
> Fair enough. I'll apply the patch. Yet, we should address with Udi what else 
> is
> needed in order to sync their tree with ours without breaking support for any
> existing device.
>
>> I cant stress enough how important it is that this changeset gets
>> merged upstream to Linus asap.  The 2.6.31-rc kernel is broken without
>> this change.
>
> I'll add it on my next upstream changeset.


Thanks for applying the fix patch.

Now, at least those devices will work again, but there is still a
regression since the previous kernels supported the LED and LNA
functionality that my next patch restores.

Hopefully we will hear from Udi soon.

Just to be clear, the patch that we'd like Udi's comments on is this one:

http://kernellabs.com/hg/~mkrufky/sms1xxx/rev/tip

As this code is in the smsdvb common code, it calls into sms-cards and
will return harmlessly to the caller on the non-hauppauge devices.
The functionality is only changed for those cards that have this
functionality defined in the sms-cards.c structures.

Hopefully, Udi can agree to merge this into the 2.6.31 kernel, while
we can work on Siano's internal event interface for the next kernel.
Once that is working perfectly, we can remove the patch that I'm
proposing now, and convert the Hauppauge devices to the newer event
interface.

Regards,

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

[PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx-warning

[Michael Krufky]

On Sun, Aug 2, 2009 at 5:29 AM, Hans Verkuil wrote:
> On Saturday 01 August 2009 06:40:01 Patch from Michael Krufky wrote:
>> The patch number 12374 was added via Michael Krufky 
>> to http://linuxtv.org/hg/v4l-dvb master development tree.
>>
> Hi Mike,
>
> The daily build now has this warning:
>
> /marune/build/v4l-dvb-master/v4l/sms-cards.c: In function 'sms_board_event':
> /marune/build/v4l-dvb-master/v4l/sms-cards.c:120: warning: unused variable 
> 'board'
>
> And 'board' is indeed no longer used. Can you make a patch fixing this?
> I suspect that it can just be removed.

Thanks for pointing this out, Hans.  In fact, the entire function is
not being used, but I am under the impression that Siano wants to use
it in the future.

For now I have #if 0'd the extraneous variables.

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/sms1xxx-warning

for:

- sms1xxx: fix build warning: unused variable 'board'

 sms-cards.c |2 ++
 1 file changed, 2 insertions(+)

Thanks again,

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

[PULL] http://kernellabs.com/hg/~mkrufky/hvr11x0

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/hvr11x0

for the following product name fixes:

- saa7134: Use correct product name for Hauppauge WinTV-HVR1150 ATSC/QAM-Hybrid
- saa7134: Use correct product name for Hauppauge WinTV-HVR1120 DVB-T/Hybrid

 Documentation/video4linux/CARDLIST.saa7134  |4 -
 drivers/media/video/saa7134/saa7134-cards.c |   38 +-
 drivers/media/video/saa7134/saa7134-dvb.c   |4 -
 drivers/media/video/saa7134/saa7134.h   |4 -
 4 files changed, 25 insertions(+), 25 deletions(-)

I marked these as high priority, since they are trivial changes that
make a world of a difference for users that want to know what cards
are supported under Linux, but if this doesn't make it into 2.6.31 it
is no big tragedy.

Please merge when you can.

Thanks & regards,

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

[PULL] http://kernellabs.com/hg/~mkrufky/cx23885

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/cx23885

for the following fixes:

- cx23885: Enable mplayer pvr:// usage
- cx23885-417: Support V4L2 controls as well as MPEG controls

 cx23885-417.c   |   36 
 cx23885-video.c |2 +-
 cx23885.h   |1 +
 3 files changed, 38 insertions(+), 1 deletion(-)

Cheers,

Mike
--
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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885

[Michael Krufky]

On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote:
> On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote:
>> Mauro,
>>
>> Please pull from:
>>
>> http://kernellabs.com/hg/~mkrufky/cx23885
>>
>> for the following fixes:
>>
>> - cx23885: Enable mplayer pvr:// usage
>
> I'm not too familiar with mplayer's v4l support, but why not fix
> mplayer rather than adding a fake audio interface to the driver.
> Wouldn't that potentially confuse users or other apps?

Thats a good question, Alex.

The answer, for now, is conformity amongst the v4l2 drivers.

Mplayer has been around for a good long time, and any v4l2 mpeg
encoder that doesnt do this is broken in the vraious userspace
applications.

I agree that we should fix userspace also -- but fix the kernel first,
so that older userspace works as-is.

This is needed for more than just mplayer -- mplayer is just the
biggest, loudest, most obvious one for mention.

Regards,

Mike
--
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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885

[Michael Krufky]

On Tue, Aug 4, 2009 at 3:58 PM, Alex Deucher wrote:
> On Tue, Aug 4, 2009 at 3:50 PM, Michael Krufky wrote:
>> On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote:
>>> On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote:
>>>> Mauro,
>>>>
>>>> Please pull from:
>>>>
>>>> http://kernellabs.com/hg/~mkrufky/cx23885
>>>>
>>>> for the following fixes:
>>>>
>>>> - cx23885: Enable mplayer pvr:// usage
>>>
>>> I'm not too familiar with mplayer's v4l support, but why not fix
>>> mplayer rather than adding a fake audio interface to the driver.
>>> Wouldn't that potentially confuse users or other apps?
>>
>> Thats a good question, Alex.
>>
>> The answer, for now, is conformity amongst the v4l2 drivers.
>>
>> Mplayer has been around for a good long time, and any v4l2 mpeg
>> encoder that doesnt do this is broken in the vraious userspace
>> applications.
>>
>> I agree that we should fix userspace also -- but fix the kernel first,
>> so that older userspace works as-is.
>
> er... yeah, but you are re-enforcing broken behavior, rather than
> "fixing" more drivers, why not submit a mplayer patch and tell users
> they need a newer version of mplayer/etc. to work with their card?
> Otherwise we'll end up with tons of drivers with fake audio interfaces
> and mplayer will never get fixed and users will complain that the
> audio interface doesn't work.

You don't really have the full picture here, Alex.  The applications
expect to see an audio input, and rightfully so.

This particular driver doesn't expose all of the functionality that is
available from the raw video device onto the encoder device.

Little by little, we are fixing up the cx23885-417 driver to fully
expose all featuresets, but in the meanwhile, we do what is needed to
make things work.

The problem is not mplayer, the real problem is incomplete analog
video (and analog audio) support in the cx23885 driver, itself.  As
THAT support improves, you will see small hacks like this disappear.

This should be merged.

Thanks for the feedback.

Regards,

Mike
--
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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885

[Michael Krufky]

On Tue, Aug 4, 2009 at 7:40 PM, Mauro Carvalho
Chehab wrote:
> Em Tue, 4 Aug 2009 16:19:46 -0400
> Michael Krufky  escreveu:
>
>> On Tue, Aug 4, 2009 at 3:58 PM, Alex Deucher wrote:
>> > On Tue, Aug 4, 2009 at 3:50 PM, Michael Krufky 
>> > wrote:
>> >> On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote:
>> >>> On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky 
>> >>> wrote:
>> >>>> Mauro,
>> >>>>
>> >>>> Please pull from:
>> >>>>
>> >>>> http://kernellabs.com/hg/~mkrufky/cx23885
>> >>>>
>> >>>> for the following fixes:
>> >>>>
>> >>>> - cx23885: Enable mplayer pvr:// usage
>> >>>
>> >>> I'm not too familiar with mplayer's v4l support, but why not fix
>> >>> mplayer rather than adding a fake audio interface to the driver.
>> >>> Wouldn't that potentially confuse users or other apps?
>> >>
>> >> Thats a good question, Alex.
>> >>
>> >> The answer, for now, is conformity amongst the v4l2 drivers.
>> >>
>> >> Mplayer has been around for a good long time, and any v4l2 mpeg
>> >> encoder that doesnt do this is broken in the vraious userspace
>> >> applications.
>> >>
>> >> I agree that we should fix userspace also -- but fix the kernel first,
>> >> so that older userspace works as-is.
>> >
>> > er... yeah, but you are re-enforcing broken behavior, rather than
>> > "fixing" more drivers, why not submit a mplayer patch and tell users
>> > they need a newer version of mplayer/etc. to work with their card?
>> > Otherwise we'll end up with tons of drivers with fake audio interfaces
>> > and mplayer will never get fixed and users will complain that the
>> > audio interface doesn't work.
>>
>> You don't really have the full picture here, Alex.  The applications
>> expect to see an audio input, and rightfully so.
>>
>> This particular driver doesn't expose all of the functionality that is
>> available from the raw video device onto the encoder device.
>>
>> Little by little, we are fixing up the cx23885-417 driver to fully
>> expose all featuresets, but in the meanwhile, we do what is needed to
>> make things work.
>>
>> The problem is not mplayer, the real problem is incomplete analog
>> video (and analog audio) support in the cx23885 driver, itself.  As
>> THAT support improves, you will see small hacks like this disappear.
>
> There are some separate issues that came with this patch:
>
> 1) V4L2 API (chapter 1.5) states that:
>
>        Drivers must implement all input ioctls when the device has one
>        or more inputs, all output ioctls when the device has one or more 
> outputs.
>        When the device has any audio inputs or outputs the driver must set the
>        V4L2_CAP_AUDIO flag in the struct v4l2_capability returned by the
>        VIDIOC_QUERYCAP ioctl.
>
> My understanding is that, except for webcams without any audio input, all 
> other
> V4L2 devices should implement VIDIOC_G_AUDIO, VIDIOC_ENUMAUDIO and 
> VIDIOC_S_AUDIO.
>
> So, your patch should have implemented VIDIOC_S_AUDIO as well.
>
> 2) Based on the above understanding, your comments are wrong, since the device
> has one audio input (otherwise, no audio would be streamed).
>
> So, it is not mplayer that requires those functions, but V4L2 API. So, please
> remove the comments. The same fix applies to pvrusb2 comments.
>
> 3) On this piece of code:
>
> + strncpy(vin->name, "CX23885 Audio", 14);
> + vin->capability = V4L2_AUDCAP_STEREO;
>
> the "magic" size above is very ugly. Please find another way for it, like:
>
> #define CX23885_INPUT_NAME "CX23885 Audio"
> strncpy(vin->name, CX23885_INPUT_NAME, sizeof(CX23885_INPUT_NAME) + 1);
>
> 4) mplayer should be fixed to not require audio inputs for devices without
> V4L2_CAP_AUDIO.
>
> I just tested it here with a webcam, where I have this parameter at 
> .mplayer/config:
>
> tv              = 
> "driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast:alsa=1:adevice=hw.1:audiorate=32000:immediatemode=0:amode=1"
>
> With a device without audio cap:
>
> $ v4l2-ctl -D
> Driver info:
>        Driver name   : em28xx
>        Card type     : Silvercrest Webcam 1.3mpix
>        Bus info      : usb-:00:1d.7-7
>        Driver version: 258
>        Capabilities  : 0x0541
>      

Re: lgs8gxx: 64bit division

[Michael Krufky]

On Wed, Aug 5, 2009 at 10:14 AM, David Wong wrote:
> Dear all,
>
>  Someone complains that he cannot compile my lgs8gxx.c on gcc3,
> unknown kernel version.  Compilation
> error at line 249 about the 64-bit division. I have no compilation
> error on my x86_64 system, gcc4,
> linux-2.6.28 kernel. Should the 64-bit division code be changed?
>
>  There is also it 64bit / 32bit division via do_div(), is it correct?

David,

The following changeset illustrates how to use do_div to handle 64bit
division regardless of 32 / 64 bit architecture.

http://linuxtv.org/hg/v4l-dvb/rev/530c2f70dc25

I hope this helps.

Regards,

Mike
--
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: RFC: adding ISDB-T/ISDB-Tsb to DVB-API 5

[Michael Krufky]

On Mon, Aug 3, 2009 at 1:53 PM, Patrick
Boettcher wrote:
> Hi all,
>
> I'd like to request some comments about the extension of the DVB-API 5 to
> support ISDB-T and ISDB-Tsb. Some stubs in frontend.h and friends have been
> there since the beginning and now it's time to have real user-space support
> for that standard.
>
> I hope that we can finish the discussion of this RFC before the merge window
> of 2.6.32, so that it can be included then.
>
> The current version of the patches can be found here:
>
> http://linuxtv.org/hg/~pb/v4l-dvb/rev/eabb8cfcf32a
>
> Changelog:
> This patch increments the DVB-API to version 5.1 in order to reflect the
> addition of ISDB-T and ISDB-Tsb on Linux' DVB-API.
>
> Changes in detail:
> - added a small document to describe how to use the API to tune to an ISDB-T
> or ISDB-Tsb channel
> - added necessary fields to dtv_frontend_cache
> - added a smarter clear-cache function which resets all fields of the
> dtv_frontend_cache
> - added a TRANSMISSION_MODE_4K to fe_transmit_mode_t
>
> I also added a document trying to descibe in short all the needed parameters
> (DTV_CMDs) for ISDB-T(sb) and how to use them. I'm inlining this document,
> as it is the base for the RFC as well:
>
> (Disclaimer: ISDB-T and ISDB-Tsb is relative complex from the parameters
> point of view compared to DVB-T and for me the standard-document was not
> making things very easy for me as a software-writer. Please don't blame me
> for so many additions)
>
> -
> This document describes shortly what are the possible parameters in
> the Linux DVB-API called "S2API" in order to tune an ISDB-T/ISDB-Tsb
> demodulator:
>
> This ISDB-T/ISDB-Tsb API extension should reflect all information
> needed to tune any ISDB-T/ISDB-Tsb hardware. Of course it is possible
> that some very sophisticated devices won't need certain parameters to
> tune.
>
> The information given here should help application writers to know how
> to handle ISDB-T and ISDB-Tsb hardware using the Linux DVB-API.
>
> The details given here about ISDB-T and ISDB-Tsb are just enough to
> basically
> show the dependencies between the needed parameter values, but surely some
> information is left out. For more detailed information see the standard
> document:
> ARIB STD-B31 - "Transmission System for Digital Terrestrial Television
> Broadcasting".
>
> In order to read this document one has to know about the channel
> structure in ISDB-T and ISDB-Tsb. I.e. it has to be known to the
> reader that an ISDB-T channel consists of 13 segments, that it can
> have up to 3 layer sharing those segments, and so on.
>
> Parameters used by ISDB-T and ISDB-Tsb.
>
> Existing parameters
> ===
>
> a) DTV_BANDCOUNT_HZ
>
> Help the front-end, for example, to set up base-band-filters.
>
> Possible values:
>
> For ISDB-T it should be always 600Hz (6MHz)
> For ISDB-Tsb it can vary depending on the number of connected segments
>
> b) DTV_DELIVERY_SYSTEM
>
> Possible values: SYS_ISDBT
>
> c) DTV_TRANSMISSION_MODE
>
> ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called
> 'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K
>
> Possible values: TRANSMISSION_MODE_2K, TRANSMISSION_MODE_8K,
>         TRANSMISSION_MODE_AUTO, TRANSMISSION_MODE_4K
>
> If DTV_TRANSMISSION_MODE is set the TRANSMISSION_MODE_AUTO the
> hardware will try to find the correct FFT-size (if capable) and use
> the TMCC to fill in the missing parameters.
>
> TRANSMISSION_MODE_4K is added at the same time as the other new parameters.
>
> d) DTV_GUARD_INTERVAL
>
> Possible values: GUARD_INTERVAL_1_32, GUARD_INTERVAL_1_16,
> GUARD_INTERVAL_1_8,
>         GUARD_INTERVAL_1_4, GUARD_INTERVAL_AUTO
>
> If DTV_GUARD_INTERVAL is set the GUARD_INTERVAL_AUTO the hardware will
> try to find the correct guard interval (if capable) and use the TMCC to fill
> in the missing parameters.
>
> New parameters
> ==
>
> 1. DTV_ISDBT_PARTIAL_RECEPTION (1b)
>
> If DTV_ISDBT_SOUND_BROADCASTING is '0' this bit-field represents whether
> the channel is in partial reception mode or not.
>
> If '1' DTV_ISDBT_LAYERA_* values are assigned to the center segment and
> DTV_ISDBT_LAYERA_SEGMENT_COUNT has to be '1'.
>
> If in addition DTV_ISDBT_SOUND_BROADCASTING is '1'
> DTV_ISDBT_PARTIAL_RECEPTION represents whether this ISDB-Tsb channel
> is consisting of one segment and layer or three segments and two layers.
>
> Possible values: 0, 1, -1 (AUTO)
>
> 2. DTV_ISDBT_SOUND_BROADCASTING (1b)
>
> This field represents whether the other DTV_ISDBT_*-parameters are
> referring to an ISDB-T and an ISDB-Tsb channel. (See also
> DTV_ISDBT_PARTIAL_RECEPTION).
>
> Possible values: 0, 1, -1 (AUTO)
>
> 3. DTV_ISDBT_SB_SUBCHANNEL_ID
>
> This field only applies if DTV_ISDBT_SOUND_BROADCASTING is '1'.
>
> (Note of the author: This might not be the correct description of the
>  SUBCHANNEL-ID in all details, but it is my understanding of the technical
>  background needed to program a device)

Re: Hauppauge WinTV HVR-900HD support?

[Michael Krufky]

Kaya,

On Thu, Aug 6, 2009 at 7:53 AM, Kaya Saman wrote:
> Hi,
>
> in an earlier post I was responded to that my old WinTV USB 1 Tuner would
> never work under Linux due to bad and complicated coding which (since no one
> uses that tuner anymore) will never be looked at.

I don't think that's true -- I didn't see your earlier post, but I can
only assume that your WinTV USB 1 Tuner uses the NT003 / NT004
chipsets, supported by the usbvision driver -- did you try that?

> So I am in need of a new tuner!

Better off getting a new one anyway, since analog TV will disappear
eventually and DTV is all that will be around.

> This is a dilemma as I need analog TV since I will be using it for
> watching stuff through a satellite receiver but also analog terrestrial TV
> too as where I will be taking it to doesn't have digital TV at best the have
> cable.
>
> I was considering going for the Hauppauge WinTV HVR-900HD. I am not sure if
> it will be compatible though with the global regions I will use it in which
> is UK that I know it has support for as I will buy from here which is PAL I
> but then also Turkey which I think is PAL Beta if I'm not mistaken??
>
> More importantly though is it supported under Linux?? I use KUbuntu 9.04
> which is pretty up to date. I am just a bit worried about this part since
> the site says that as of June 2008 there is no support... of course we are
> in August 2009 so maybe in a year it might have been integrated into the
> later kernels??
> Taken from here:
> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-900H
>
> What's everyone's verdict? Any suggestions would be great!

The HVR-900H is currently *not* supported under Linux, and it does not
seem that it will get such support anytime in the near future,
unfortunately.  Please note, I am only speaking for the HVR-900H ...
other flavors of the HVR900 are fully functional and supported, just
not the "H" version.

If you're looking for a well-supported USB hybrid device, I would
recommend one of the standard "HVR-900" sticks, or even better, the
HVR-1900 .  The HVR1900 is a usb device that does Digital DVB-T and
analog (PAL / NTSC) both.  The analog side has a hardware mpeg encoder
-- this is perfect if you intend to use the device for recordings.
HVR1900 is fully supported under Linux.

I hope this helps.

Regards,

Mike
--
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: Hauppauge WinTV HVR-900HD support?

[Michael Krufky]

On Thu, Aug 6, 2009 at 9:07 AM, Kaya Saman wrote:
> Michael Krufky wrote:
>>
>> Kaya,
>>
>> On Thu, Aug 6, 2009 at 7:53 AM, Kaya Saman wrote:
>>
>>>
>>>
>>
>> I don't think that's true -- I didn't see your earlier post, but I can
>> only assume that your WinTV USB 1 Tuner uses the NT003 / NT004
>> chipsets, supported by the usbvision driver -- did you try that?
>>
>>
>> Better off getting a new one anyway, since analog TV will disappear
>> eventually and DTV is all that will be around.
>>  The HVR-900H is currently *not* supported under Linux, and it does not
>> seem that it will get such support anytime in the near future,
>> unfortunately.  Please note, I am only speaking for the HVR-900H ...
>> other flavors of the HVR900 are fully functional and supported, just
>> not the "H" version.
>>
>> If you're looking for a well-supported USB hybrid device, I would
>> recommend one of the standard "HVR-900" sticks, or even better, the
>> HVR-1900 .  The HVR1900 is a usb device that does Digital DVB-T and
>> analog (PAL / NTSC) both.  The analog side has a hardware mpeg encoder
>> -- this is perfect if you intend to use the device for recordings.
>> HVR1900 is fully supported under Linux.
>>
>> I hope this helps.
>>
>> Regards,
>>
>> Mike
>>
>
> Thanks for the response Mike!
>
> You claim there is a Hauppauge HVR-1900... I am looking on the
> www.hauppauge.co.uk website and all I see is a 1400 which is SMC slot??


HVR1400 is expresscard.

HVR1900 is usb2.  HVR1950 is the NTSC/ATSC/QAM version of the HVR1900.
 (HVR1900 is PAL/DVB-T, but can also do NTSC, and other analog
standards)

HVR1900 is the one I am recommending for you.  Maybe the website
you're looking at needs updating -- the HVR1900 has been available
already for quite some time.

Regards,

Mike
--
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: Hauppauge WinTV HVR-900HD support?

[Michael Krufky]

On Thu, Aug 6, 2009 at 9:33 AM, Kaya Saman wrote:
> Michael Krufky wrote:
>>
>>
>>
>> HVR1400 is expresscard.
>>
>> HVR1900 is usb2.  HVR1950 is the NTSC/ATSC/QAM version of the HVR1900.
>>  (HVR1900 is PAL/DVB-T, but can also do NTSC, and other analog
>> standards)
>>
>> HVR1900 is the one I am recommending for you.  Maybe the website
>> you're looking at needs updating -- the HVR1900 has been available
>> already for quite some time.
>>
>> Regards,
>>
>> Mike
>>
>
> Thanks Mike, I managed to find it finally on Amazon.co.uk which claimed that
> it was available from June 2007!
>
> That might explain why it's not on the Hauppauge website as it is most
> likely getting replaced
>
> I actually expected this to be one of those cute USB keys but this thing
> resembles a set top box :-)
>
> I think the WinTV HVR-900 maybe a better option as it is supported. I am
> guessing that this is the same thing as the H model without the HD support?

No, I recommended the HVR1900 because *IT* is fully supported, and is
*not* getting replaced.  HVR900 got replaced.  HVR1900 is not as large
as a set top box, but it is bigger than the usb sticks, and uses a
power brick, for the mpeg encoder.

It is on the Hauppauge web site, you probably just overlooked it.

-Mike
--
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: Hauppauge WinTV HVR-900HD support?

[Michael Krufky]

On Thu, Aug 6, 2009 at 12:06 PM, Kaya Saman wrote:
>
>>
>> No, I recommended the HVR1900 because *IT* is fully supported, and is
>> *not* getting replaced.  HVR900 got replaced.  HVR1900 is not as large
>> as a set top box, but it is bigger than the usb sticks, and uses a
>> power brick, for the mpeg encoder.
>>
>> It is on the Hauppauge web site, you probably just overlooked it.
>>
>> -Mike
>>
>
> Ok, now I am so sorry and I feel really silly but I can't find it.
>
> I have tried hauppauge.co.uk and under HVR-external all I get is 900HD, 900,
> and 1400:
>
> http://www.hauppauge.co.uk/site/products/prods_hvr_external.html
>
> now, I even did a search for the 1900 and found nothing on hauppauge search
> link??? Sure it came up with the 1950 model but no 1900.
>
> On top of that I tried www.dabs.com and www.misco.co.uk both of which have
> the 900 but no 1900.
>
> am I missing something or have I just totally gone insane over the last few
> hours???

#1) http://www.hauppauge.de/de/index.htm  (scroll down to middle of the page)

#2) http://www.hauppauge.de/de/site/products/data_hvr1900.html

#3) http://www.hauppauge.com/site/press/presspictures/HVR-1900_German_1251.jpg

#4) http://www.hauppauge.com/site/press/presspictures/HVR-1900_4lang_1179.png

#5)  http://www.hauppauge.com/site/support/linux.html

-Mike
--
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: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx

[Michael Krufky]

On Thu, Feb 26, 2009 at 2:13 PM, Mauro Carvalho Chehab
 wrote:
> On Fri, 20 Feb 2009 11:53:51 -0500
> Michael Krufky  wrote:
>
>> Mauro,
>>
>> As you know, there is a large amount of pending changesets from Siano
>> that are waiting for merge.
>>
>> Given the large amount of changes and the impact it has on the
>> driver's current functionality, I am going to make the merge requests
>> in phases.
>>
>> This is the first phase, which merges the first round of changesets
>> from Uri, in addition to codingstyle cleanups and some fixes for some
>> current devices.
>>
>> I am still processing through the remaining changesets, but I think
>> it's important to try to merge some of this now, to reduce the delta
>> of the changes that will need review when all is done and ready.
>>
>> This tree has been tested with the currently supported devices, and it
>> is a step towards merge of the pending Siano changesets.
>>
>> I am sure you will have some comments about these changes -- Let's try
>> to merge what we can now, and all comments will be addressed in future
>> cleanups.  Please post your comments to this thread so that we may
>> hold any review discussions in this public forum.
>>
>> The main objective of these changesets is to break down the sms1xxx
>> module into sub-modules.  Siano doesn't want to load the usb part of
>> the driver into memory unless the usb interface is to be used (which
>> won't always be the case).
>>
>> After these changes are merged, I will send additional merge requests
>> for the later changesets and the addition of the SPI interface.
>>
>> Please pull from:
>>
>> http://linuxtv.org/hg/~mkrufky/sms1xxx
>>
>> for the following changesets:
>>
>> - sms1xxx: enable rf switch on Hauppauge Tiger devices
>> - sms1xxx: move definition of struct smsdvb_client_t into smsdvb.c
>> - sms1xxx: restore smsusb_driver.name to smsusb
>> - sms1xxx: move smsusb_id_table into smsusb.c
>> - import changes from Siano
>> - sms1xxx: fix checkpatch.pl violations introduced by previous changeset
>> - sms1xxx: load smsdvb module automatically based on device id
>>
>>  Makefile     |    4
>>  sms-cards.c  |   92 ++
>>  sms-cards.h  |    7 -
>>  smscoreapi.c |  162 +--
>>  smscoreapi.h |   46 ++-
>>  smsdvb.c     |   66 +--
>>  smsusb.c     |   73 +++--
>>  7 files changed, 304 insertions(+), 146 deletions(-)
>
> Hmm... Why are you adding all those symbols to be exported?
>
> +EXPORT_SYMBOL(smscore_onresponse);
> +EXPORT_SYMBOL(sms_get_board);
> +EXPORT_SYMBOL(sms_debug);
> +EXPORT_SYMBOL(smscore_putbuffer);
> +EXPORT_SYMBOL(smscore_registry_getmode);
> +EXPORT_SYMBOL(smscore_register_device);
> +EXPORT_SYMBOL(smscore_set_board_id);
> +EXPORT_SYMBOL(smscore_start_device);
> +EXPORT_SYMBOL(smscore_unregister_device);
> +EXPORT_SYMBOL(smscore_getbuffer);
> +EXPORT_SYMBOL(smscore_get_device_mode);
> +EXPORT_SYMBOL(smscore_register_client);
> +EXPORT_SYMBOL(smscore_unregister_hotplug);
> +EXPORT_SYMBOL(smsclient_sendrequest);
> +EXPORT_SYMBOL(smscore_unregister_client);
> +EXPORT_SYMBOL(smscore_get_board_id);
> +EXPORT_SYMBOL(smscore_register_hotplug);
>
> Shouldn't all of they be instead EXPORT_SYMBOL_GPL?
>
> Cheers,
> Mauro
>

cc added to Uri @ Siano.

Uri,

Would it be okay with you if we make the above change?  You don't have
to send in a patch for this right now, since I am already in the midst
of merging your patch series.  If you give permission to change these
exports to EXPORT_SYMBOL_GPL, then please provide your sign-off and I
will merge that change for you in the next series merge.

Thanks,

Mike
--
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: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx

[Michael Krufky]

On Thu, Feb 26, 2009 at 3:19 PM, Uri Shkolnik  wrote:
>
>
>
> -Original Message-
> From: mkru...@gmail.com on behalf of Michael Krufky
> Sent: Thu 2/26/2009 9:23 PM
> To: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org; Uri Shkolnik
> Subject: Re: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx
>
> On Thu, Feb 26, 2009 at 2:13 PM, Mauro Carvalho Chehab
>  wrote:
>> On Fri, 20 Feb 2009 11:53:51 -0500
>> Michael Krufky  wrote:
>>
>>> Mauro,
>>>
>>> As you know, there is a large amount of pending changesets from Siano
>>> that are waiting for merge.
>>>
>>> Given the large amount of changes and the impact it has on the
>>> driver's current functionality, I am going to make the merge requests
>>> in phases.
>>>
>>> This is the first phase, which merges the first round of changesets
>>> from Uri, in addition to codingstyle cleanups and some fixes for some
>>> current devices.
>>>
>>> I am still processing through the remaining changesets, but I think
>>> it's important to try to merge some of this now, to reduce the delta
>>> of the changes that will need review when all is done and ready.
>>>
>>> This tree has been tested with the currently supported devices, and it
>>> is a step towards merge of the pending Siano changesets.
>>>
>>> I am sure you will have some comments about these changes -- Let's try
>>> to merge what we can now, and all comments will be addressed in future
>>> cleanups.  Please post your comments to this thread so that we may
>>> hold any review discussions in this public forum.
>>>
>>> The main objective of these changesets is to break down the sms1xxx
>>> module into sub-modules.  Siano doesn't want to load the usb part of
>>> the driver into memory unless the usb interface is to be used (which
>>> won't always be the case).
>>>
>>> After these changes are merged, I will send additional merge requests
>>> for the later changesets and the addition of the SPI interface.
>>>
>>> Please pull from:
>>>
>>> http://linuxtv.org/hg/~mkrufky/sms1xxx
>>>
>>> for the following changesets:
>>>
>>> - sms1xxx: enable rf switch on Hauppauge Tiger devices
>>> - sms1xxx: move definition of struct smsdvb_client_t into smsdvb.c
>>> - sms1xxx: restore smsusb_driver.name to smsusb
>>> - sms1xxx: move smsusb_id_table into smsusb.c
>>> - import changes from Siano
>>> - sms1xxx: fix checkpatch.pl violations introduced by previous changeset
>>> - sms1xxx: load smsdvb module automatically based on device id
>>>
>>>  Makefile     |    4
>>>  sms-cards.c  |   92 ++
>>>  sms-cards.h  |    7 -
>>>  smscoreapi.c |  162 +--
>>>  smscoreapi.h |   46 ++-
>>>  smsdvb.c     |   66 +--
>>>  smsusb.c     |   73 +++--
>>>  7 files changed, 304 insertions(+), 146 deletions(-)
>>
>> Hmm... Why are you adding all those symbols to be exported?
>>
>> +EXPORT_SYMBOL(smscore_onresponse);
>> +EXPORT_SYMBOL(sms_get_board);
>> +EXPORT_SYMBOL(sms_debug);
>> +EXPORT_SYMBOL(smscore_putbuffer);
>> +EXPORT_SYMBOL(smscore_registry_getmode);
>> +EXPORT_SYMBOL(smscore_register_device);
>> +EXPORT_SYMBOL(smscore_set_board_id);
>> +EXPORT_SYMBOL(smscore_start_device);
>> +EXPORT_SYMBOL(smscore_unregister_device);
>> +EXPORT_SYMBOL(smscore_getbuffer);
>> +EXPORT_SYMBOL(smscore_get_device_mode);
>> +EXPORT_SYMBOL(smscore_register_client);
>> +EXPORT_SYMBOL(smscore_unregister_hotplug);
>> +EXPORT_SYMBOL(smsclient_sendrequest);
>> +EXPORT_SYMBOL(smscore_unregister_client);
>> +EXPORT_SYMBOL(smscore_get_board_id);
>> +EXPORT_SYMBOL(smscore_register_hotplug);
>>
>> Shouldn't all of they be instead EXPORT_SYMBOL_GPL?
>>
>> Cheers,
>> Mauro
>>
>
> cc added to Uri @ Siano.
>
> Uri,
>
> Would it be okay with you if we make the above change?  You don't have
> to send in a patch for this right now, since I am already in the midst
> of merging your patch series.  If you give permission to change these
> exports to EXPORT_SYMBOL_GPL, then please provide your sign-off and I
> will merge that change for you in the next series merge.
>
> Thanks,
>
> Mike
>
> --
>
> Mike, Mauro,
>
>
> Please feel free to modify **an

[PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx

[Michael Krufky]

Mauro,

Changeset 85a2b117175e creates the following build warning:

WARNING: "sms_dbg" [/home/mk/v4l-dvb/v4l/smsusb.ko] undefined!
WARNING: "sms_dbg" [/home/mk/v4l-dvb/v4l/smsdvb.ko] undefined!

Please pull the fix from:

http://linuxtv.org/hg/~mkrufky/sms1xxx

for the following:

- Backed out changeset 85a2b117175e
- siano: prevent duplicate variable declaration

 sms-cards.c  |4 
 smscoreapi.c |2 +-
 smscoreapi.h |2 --
 smsdvb.c |6 +-
 smsusb.c |6 +-
 5 files changed, 15 insertions(+), 5 deletions(-)

Thanks,

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

[PULL] http://linuxtv.org/hg/~mkrufky/mxl5007t

[Michael Krufky]

Mauro,

Please pull from:

http://linuxtv.org/hg/~mkrufky/mxl5007t

for the following:

- mxl5007t: remove analog tuning code
- mxl5007t: remove function mxl5007t_check_rf_input_power
- mxl5007t: mxl5007t_get_status should report if tuner is locked
- mxl5007t: warn when unknown revisions are detected
- mxl5007t: fix devname for hybrid_tuner_request_state
- mxl5007t: update driver for MxL 5007T V4

 mxl5007t.c |  445 +
 1 file changed, 146 insertions(+), 299 deletions(-)

Cheers,

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

[PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx

[Michael Krufky]

Mauro,

Please pull from:

http://linuxtv.org/hg/~mkrufky/sms1xxx

for the following:

- smsusb: whitespace cleanups
- smscore: whitespace cleanups
- smsusb: add autodetection for "nice" and "venice" boards

 sms-cards.c  |8 +
 sms-cards.h  |2
 smscoreapi.c |  138 --
 smscoreapi.h |  289 +++
 smsusb.c |   47 +++---
 5 files changed, 242 insertions(+), 242 deletions(-)

Cheers,

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

[PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio

[Michael Krufky]

Mauro,

Please pull from:

http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio

for the following:

- smsusb: whitespace cleanups
- smscore: whitespace cleanups
- smsusb: add autodetection for "nice" and "venice" boards
- smsdvb: whitespace cleanups
- sms-cards: add some more debug
- sms1xxx: update GPIO functionality to support all devices

 sms-cards.c  |   26 ++
 sms-cards.h  |2
 smscoreapi.c |  391 ++-
 smscoreapi.h |  350 ++
 smsdvb.c |   27 +-
 smsusb.c |   49 ++--
 6 files changed, 507 insertions(+), 338 deletions(-)

Cheers,

Mike
--
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: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio

[Michael Krufky]

Uri Shkolnik wrote:

--- On Fri, 3/6/09, Michael Krufky  wrote:

  

From: Michael Krufky 
Subject: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio
To: "Mauro Carvalho Chehab" 
Cc: linux-media@vger.kernel.org
Date: Friday, March 6, 2009, 3:15 PM
Mauro,

Please pull from:

http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio

for the following:

- smsusb: whitespace cleanups
- smscore: whitespace cleanups
- smsusb: add autodetection for "nice" and "venice" boards
- smsdvb: whitespace cleanups
- sms-cards: add some more debug
- sms1xxx: update GPIO functionality to support all
devices

 sms-cards.c  |   26 ++
 sms-cards.h  |2
 smscoreapi.c |  391
++-
 smscoreapi.h |  350
++
 smsdvb.c |   27 +-
 smsusb.c |   49
++--
 6 files changed, 507 insertions(+), 338 deletions(-)

Cheers,

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




Hi Mike,

I reviewed your tree , which is indicated by the email above, and compared it to a tree I built from the v4l 'trunk' repository + Siano's patches. 
I found out two things -

1) The trees are still *very* differ from each other
2) You applied *new* things that are _not_ included in the "old" Siano's 
patches (and some of them even break it).

I'm wondering what is the status of the Siano's patches merge to the main tree, 
and I would like to ask what is the target date for final merge. This is 
critical for us since till now, we told people to download the v4l 'trunk' and 
apply the various patches (which are available to to all on the vger server) on 
it. The current state voids that option, and the result is invalid drivers (I 
tested the your tree, and it fails the very first Siano's QA sanity test).

I would like to ask you to stick with Siano's patches, which are solid, tested thoroughly, and work on multiple devices (including mass production). 
We talked about altering some minor stuff (like the EXPORT_SYMBOL_GPL, external functions calls and indentation) this does not mean that we want to create new set of drivers or alter the drivers architecture. 


If there are substantial changes you think should be applied, first merge all 
previously committed patches, and than submit new patches for review.

Please note that are multiple patches awaiting to be submitted from Siano (and 
some other parties via Siano), that I'm holding till the merge will end. So 
lets keep the order [1] merge old Siano's patches [2] submit review and merge 
pending Siano's (exist) patches [3] Submit new patches for review.
  


Uri,

Plain and simple:

#1 The patches that you submitted break the currently supported devices

#2 The patches that you submitted are not atomic

#3 The patches that you submitted introduce regressions

#4 The patches that you submitted have multiple changes in single patches.

#5 The patches that you submitted are not safe for a git-bisection nor 
hg-bisection


#6 The "codingstyle cleanups" that are intertwined in your patches are 
actually codingstyle regressions rather than cleanups.


When I complained about these problems, you were not willing to 
regenerate your patches.  In the interest of moving forward, I had 
volunteered to clean the changes and separate them into atomic patches 
such that we could avoid any problems caused by the above.


In the last email that you wrote, asking about merge, I explained the 
above to you, and I offered as a compromise for this time, that I would 
separate your patches and merge them one by one and ensure that the 
currently supported Hauppauge devices do not become broken as a result 
of this.


This round of merges contains some of your changes.  I am still working 
on the other parts.


I am in the process of separating your huge patches into smaller 
patches, and I am merging slowly into the master branch little by 
little.  I am IN THE MIDDLE OF THIS PROCESS, but I am merging things 
when I can, so that there are less changes to be reviewed and merged all 
at once, when the entire merge is finally complete.


AS WE AGREED, I am working through your patchset to get everything 
merged.  Again, AS WE AGREED, once everything is merged, that's when you 
and I will sync up and handle the remaining differences.


...

These patches pending in my repository for merge are a SUBSET of the 
patches that you sent to me.  What you sent cannot be applied as-is.  
After merging your GPIO changesets, it broke the Hauppauge devices, 
entirely.


I added some debug to sms-cards.c, and I had to add the "wait" option to 
your gpio functions -- without this "wait" option, the Hauppauge gpio 
functionality is thoroughly broken.


This "wait" option to th