Skip to contentSkip to conversation

S2API - Status - Thu Sep 11th

linux-dvb Applied Steven Toth 10 participants 45 messages Sep 12, 2008 – Sep 25, 2008 3 messages not in the archive Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

Hello!

More progress today, 7 new patches were merged - all related to the feedback and suggestions we had.... And a bugfix. :)

The DTV_SET/GET command syntax has been rationalised, as Hans requested. This cleans up the application API nicely. Various internal improvements and code cleanup related to variable length arrays, moving values to/from userspace to the kernel. Interfacing to the demods to allow them to interact with set/get property requests, if they chose to do so. Quite a lot of changes internally and to the user facing API.

If you're planning to test then you'll need the tune-v0.0.5.c to see the different. (steventoth.net/linux/s2/tune-v0.0.5.tgz)

In addition, some related news:

mkrufky spent some time adding S2API isdb-t support to the siano driver, that's working pretty well - tuning via the S2API app.

Two tree here, offering slightly different approaches, one with S2API, one using some spare bits in the DVB-T tuning fields.

http://linuxtv.org/hg/~mkrufky/sms1xxx-s2api-isdbt/
http://linuxtv.org/hg/~mkrufky/sms1xxx-isdbt-as-dvbt/

(See tune-v0.0.5.tgz for example ISDB-T tuning code)

If you're interested in seeing the impact of switching to S2API for this driver, see the set_frontend() func, it's a small change - just a few lines to reference the dtv_frontend_properties cache.

I don't think we're quite ready to announce we've conquered the complete ISDB-T API, so don't assume that this is concrete.... As we experiment with other ISDB-T products we'll probably find reasons to tweak the API a little further as a standard begins to form..... but tuning through a clean API is a great step forward, and its working now, today. Thank you mkrufky :)

Hans Werner sent a large patch for the multifrontend HVR3000/HVR4000 combined DVB-T/DVB-S/S2 support for the S2API tree. (Thanks Hans - this was obviously a lot of manual merge work, it's greatly appreciated.)

What would everyone like to see happen with this patch?

Would you prefer to see this dealt with outside of the S2API discussion, or would you like to see this included and merged? Let me know your thoughts. Andreas also has the multifrontend thread running, so comment here if you would like to see this as part of the S2API patches, or comment on the Andreas thread of you want this as a separate patchset at a later date.

Darron Broad has offered to bring the cx24116.c driver up to date with some additions he has in his repositories. With any luck we may see these merged into the current cx24116 driver within a few days. Thank you Darron.

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm open to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

Igor has been busy patching the szap-s2 tool
(http://liplianindvb.sourceforge.net/hg/szap-s2/) so many thanks to Igor! Gregoire has been running some basic tests and appears to be having some success, that's encouraging. Thank you.

What's next?

Now's probably a good time to start patching dvb-apps. I think the frontend.h changes are close enough for that work to begin. This will probably start Friday, so keep your eyes and open for the stoth/s2api-dvb-apps tree appearing ... and an announcement here.

Thanks again to everyone, your efforts are appreciated!

Regards,

Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#1 lore raw

Le Friday 12 September 2008 07:51:17 Steven Toth, vous avez écrit :

Quoted 74 lines

Hello!

More progress today, 7 new patches were merged - all related to the feedback and suggestions we had.... And a bugfix. :)

The DTV_SET/GET command syntax has been rationalised, as Hans requested. This cleans up the application API nicely. Various internal improvements and code cleanup related to variable length arrays, moving values to/from userspace to the kernel. Interfacing to the demods to allow them to interact with set/get property requests, if they chose to do so. Quite a lot of changes internally and to the user facing API.

If you're planning to test then you'll need the tune-v0.0.5.c to see the different. (steventoth.net/linux/s2/tune-v0.0.5.tgz)

In addition, some related news:

mkrufky spent some time adding S2API isdb-t support to the siano driver, that's working pretty well - tuning via the S2API app.

Two tree here, offering slightly different approaches, one with S2API, one using some spare bits in the DVB-T tuning fields.

http://linuxtv.org/hg/~mkrufky/sms1xxx-s2api-isdbt/
http://linuxtv.org/hg/~mkrufky/sms1xxx-isdbt-as-dvbt/

(See tune-v0.0.5.tgz for example ISDB-T tuning code)

If you're interested in seeing the impact of switching to S2API for this driver, see the set_frontend() func, it's a small change - just a few lines to reference the dtv_frontend_properties cache.

I don't think we're quite ready to announce we've conquered the complete ISDB-T API, so don't assume that this is concrete.... As we experiment with other ISDB-T products we'll probably find reasons to tweak the API a little further as a standard begins to form..... but tuning through a clean API is a great step forward, and its working now, today. Thank you mkrufky :)

Hans Werner sent a large patch for the multifrontend HVR3000/HVR4000 combined DVB-T/DVB-S/S2 support for the S2API tree. (Thanks Hans - this was obviously a lot of manual merge work, it's greatly appreciated.)

What would everyone like to see happen with this patch?

Would you prefer to see this dealt with outside of the S2API discussion, or would you like to see this included and merged? Let me know your thoughts. Andreas also has the multifrontend thread running, so comment here if you would like to see this as part of the S2API patches, or comment on the Andreas thread of you want this as a separate patchset at a later date.

Darron Broad has offered to bring the cx24116.c driver up to date with some additions he has in his repositories. With any luck we may see these merged into the current cx24116 driver within a few days. Thank you Darron.

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm open to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

Igor has been busy patching the szap-s2 tool
(http://liplianindvb.sourceforge.net/hg/szap-s2/) so many thanks to Igor! Gregoire has been running some basic tests and appears to be having some success, that's encouraging. Thank you.

What's next?

Now's probably a good time to start patching dvb-apps. I think the frontend.h changes are close enough for that work to begin. This will probably start Friday, so keep your eyes and open for the stoth/s2api-dvb-apps tree appearing ... and an announcement here.

Quoted 5 lines

Thanks again to everyone, your efforts are appreciated!

Regards,

Steve

Good work.
I've just gave it a try:

First i tried old api (kaffeine)-> everything works as expected. Then i tried new API (with latest tune.c) -> nova-t and nova-s work, cinergyT2 doesn't. I've also noticed that FE_SET_PROPERTY ioctl always return -1, even when success..
Then i tried old api again -> now dvb-s doesn't lock and dvb-t always lock on the freq used in tune.c

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#2 lore raw
Quoted 84 lines · Christophe Thommeret

Le Friday 12 September 2008 07:51:17 Steven Toth, vous avez écrit :

Quoted 74 lines

Hello!

More progress today, 7 new patches were merged - all related to the feedback and suggestions we had.... And a bugfix. :)

The DTV_SET/GET command syntax has been rationalised, as Hans requested. This cleans up the application API nicely. Various internal improvements and code cleanup related to variable length arrays, moving values to/from userspace to the kernel. Interfacing to the demods to allow them to interact with set/get property requests, if they chose to do so. Quite a lot of changes internally and to the user facing API.

If you're planning to test then you'll need the tune-v0.0.5.c to see the different. (steventoth.net/linux/s2/tune-v0.0.5.tgz)

In addition, some related news:

mkrufky spent some time adding S2API isdb-t support to the siano driver, that's working pretty well - tuning via the S2API app.

Two tree here, offering slightly different approaches, one with S2API, one using some spare bits in the DVB-T tuning fields.

http://linuxtv.org/hg/~mkrufky/sms1xxx-s2api-isdbt/
http://linuxtv.org/hg/~mkrufky/sms1xxx-isdbt-as-dvbt/

(See tune-v0.0.5.tgz for example ISDB-T tuning code)

If you're interested in seeing the impact of switching to S2API for this driver, see the set_frontend() func, it's a small change - just a few lines to reference the dtv_frontend_properties cache.

I don't think we're quite ready to announce we've conquered the complete ISDB-T API, so don't assume that this is concrete.... As we experiment with other ISDB-T products we'll probably find reasons to tweak the API a little further as a standard begins to form..... but tuning through a clean API is a great step forward, and its working now, today. Thank you mkrufky :)

Hans Werner sent a large patch for the multifrontend HVR3000/HVR4000 combined DVB-T/DVB-S/S2 support for the S2API tree. (Thanks Hans - this was obviously a lot of manual merge work, it's greatly appreciated.)

What would everyone like to see happen with this patch?

Would you prefer to see this dealt with outside of the S2API discussion, or would you like to see this included and merged? Let me know your thoughts. Andreas also has the multifrontend thread running, so comment here if you would like to see this as part of the S2API patches, or comment on the Andreas thread of you want this as a separate patchset at a later date.

Darron Broad has offered to bring the cx24116.c driver up to date with some additions he has in his repositories. With any luck we may see these merged into the current cx24116 driver within a few days. Thank you Darron.

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm open to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

Igor has been busy patching the szap-s2 tool
(http://liplianindvb.sourceforge.net/hg/szap-s2/) so many thanks to Igor! Gregoire has been running some basic tests and appears to be having some success, that's encouraging. Thank you.

What's next?

Now's probably a good time to start patching dvb-apps. I think the frontend.h changes are close enough for that work to begin. This will probably start Friday, so keep your eyes and open for the stoth/s2api-dvb-apps tree appearing ... and an announcement here.

Quoted 5 lines

Thanks again to everyone, your efforts are appreciated!

Regards,

Steve

Good work.
I've just gave it a try:

Quoted 7 lines

First i tried old api (kaffeine)-> everything works as expected. Then i tried new API (with latest tune.c) -> nova-t and nova-s work, cinergyT2 doesn't. I've also noticed that FE_SET_PROPERTY ioctl always return -1, even when success..
Then i tried old api again -> now dvb-s doesn't lock and dvb-t always lock on the freq used in tune.c

Christophe, thanks for the feedback. I'm not familiar with the cinergyT2 driver so I'll look into this tonight and see what's causing the tuning to fail.

Thanks for highlighting this.

Regards,

Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#3 lore raw

Le Friday 12 September 2008 15:18:38 Steven Toth, vous avez écrit :

Quoted 92 lines
Quoted 84 lines · Christophe Thommeret

Le Friday 12 September 2008 07:51:17 Steven Toth, vous avez écrit :

Quoted 74 lines

Hello!

More progress today, 7 new patches were merged - all related to the feedback and suggestions we had.... And a bugfix. :)

The DTV_SET/GET command syntax has been rationalised, as Hans requested. This cleans up the application API nicely. Various internal improvements and code cleanup related to variable length arrays, moving values to/from userspace to the kernel. Interfacing to the demods to allow them to interact with set/get property requests, if they chose to do so. Quite a lot of changes internally and to the user facing API.

If you're planning to test then you'll need the tune-v0.0.5.c to see the different. (steventoth.net/linux/s2/tune-v0.0.5.tgz)

In addition, some related news:

mkrufky spent some time adding S2API isdb-t support to the siano driver, that's working pretty well - tuning via the S2API app.

Two tree here, offering slightly different approaches, one with S2API, one using some spare bits in the DVB-T tuning fields.

http://linuxtv.org/hg/~mkrufky/sms1xxx-s2api-isdbt/
http://linuxtv.org/hg/~mkrufky/sms1xxx-isdbt-as-dvbt/

(See tune-v0.0.5.tgz for example ISDB-T tuning code)

If you're interested in seeing the impact of switching to S2API for this driver, see the set_frontend() func, it's a small change - just a few lines to reference the dtv_frontend_properties cache.

I don't think we're quite ready to announce we've conquered the complete ISDB-T API, so don't assume that this is concrete.... As we experiment with other ISDB-T products we'll probably find reasons to tweak the API a little further as a standard begins to form..... but tuning through a clean API is a great step forward, and its working now, today. Thank you mkrufky :)

Hans Werner sent a large patch for the multifrontend HVR3000/HVR4000 combined DVB-T/DVB-S/S2 support for the S2API tree. (Thanks Hans - this was obviously a lot of manual merge work, it's greatly appreciated.)

What would everyone like to see happen with this patch?

Would you prefer to see this dealt with outside of the S2API discussion, or would you like to see this included and merged? Let me know your thoughts. Andreas also has the multifrontend thread running, so comment here if you would like to see this as part of the S2API patches, or comment on the Andreas thread of you want this as a separate patchset at a later date.

Darron Broad has offered to bring the cx24116.c driver up to date with some additions he has in his repositories. With any luck we may see these merged into the current cx24116 driver within a few days. Thank you Darron.

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm open to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

Igor has been busy patching the szap-s2 tool
(http://liplianindvb.sourceforge.net/hg/szap-s2/) so many thanks to Igor! Gregoire has been running some basic tests and appears to be having some success, that's encouraging. Thank you.

What's next?

Now's probably a good time to start patching dvb-apps. I think the frontend.h changes are close enough for that work to begin. This will probably start Friday, so keep your eyes and open for the stoth/s2api-dvb-apps tree appearing ... and an announcement here.

Quoted 5 lines

Thanks again to everyone, your efforts are appreciated!

Regards,

Steve

Good work.
I've just gave it a try:

Quoted 6 lines

First i tried old api (kaffeine)-> everything works as expected. Then i tried new API (with latest tune.c) -> nova-t and nova-s work, cinergyT2 doesn't. I've also noticed that FE_SET_PROPERTY ioctl always return -1, even when success..
Then i tried old api again -> now dvb-s doesn't lock and dvb-t always lock on the freq used in tune.c

Quoted 5 lines

Christophe, thanks for the feedback. I'm not familiar with the cinergyT2 driver so I'll look into this tonight and see what's causing the tuning to fail.

Thanks for highlighting this.

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#4 lore raw

Le Friday 12 September 2008 15:29:41 Christophe Thommeret, vous avez écrit :

Quoted 94 lines

Le Friday 12 September 2008 15:18:38 Steven Toth, vous avez écrit :

Quoted 93 lines
Quoted 92 lines · Christophe Thommeret

Le Friday 12 September 2008 07:51:17 Steven Toth, vous avez écrit :

Quoted 76 lines

Hello!

More progress today, 7 new patches were merged - all related to the feedback and suggestions we had.... And a bugfix. :)

The DTV_SET/GET command syntax has been rationalised, as Hans requested. This cleans up the application API nicely. Various internal improvements and code cleanup related to variable length arrays, moving values to/from userspace to the kernel. Interfacing to the demods to allow them to interact with set/get property requests, if they chose to do so. Quite a lot of changes internally and to the user facing API.

If you're planning to test then you'll need the tune-v0.0.5.c to see the different. (steventoth.net/linux/s2/tune-v0.0.5.tgz)

In addition, some related news:

mkrufky spent some time adding S2API isdb-t support to the siano driver, that's working pretty well - tuning via the S2API app.

Two tree here, offering slightly different approaches, one with S2API, one using some spare bits in the DVB-T tuning fields.

http://linuxtv.org/hg/~mkrufky/sms1xxx-s2api-isdbt/
http://linuxtv.org/hg/~mkrufky/sms1xxx-isdbt-as-dvbt/

(See tune-v0.0.5.tgz for example ISDB-T tuning code)

If you're interested in seeing the impact of switching to S2API for this driver, see the set_frontend() func, it's a small change - just a few lines to reference the dtv_frontend_properties cache.

I don't think we're quite ready to announce we've conquered the complete ISDB-T API, so don't assume that this is concrete.... As we experiment with other ISDB-T products we'll probably find reasons to tweak the API a little further as a standard begins to form..... but tuning through a clean API is a great step forward, and its working now, today. Thank you mkrufky :)

Hans Werner sent a large patch for the multifrontend HVR3000/HVR4000 combined DVB-T/DVB-S/S2 support for the S2API tree. (Thanks Hans - this was obviously a lot of manual merge work, it's greatly appreciated.)

What would everyone like to see happen with this patch?

Would you prefer to see this dealt with outside of the S2API discussion, or would you like to see this included and merged? Let me know your thoughts. Andreas also has the multifrontend thread running, so comment here if you would like to see this as part of the S2API patches, or comment on the Andreas thread of you want this as a separate patchset at a later date.

Darron Broad has offered to bring the cx24116.c driver up to date with some additions he has in his repositories. With any luck we may see these merged into the current cx24116 driver within a few days. Thank you Darron.

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm open to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

Igor has been busy patching the szap-s2 tool
(http://liplianindvb.sourceforge.net/hg/szap-s2/) so many thanks to Igor! Gregoire has been running some basic tests and appears to be having some success, that's encouraging. Thank you.

What's next?

Now's probably a good time to start patching dvb-apps. I think the frontend.h changes are close enough for that work to begin. This will probably start Friday, so keep your eyes and open for the stoth/s2api-dvb-apps tree appearing ... and an announcement here.

Quoted 5 lines

Thanks again to everyone, your efforts are appreciated!

Regards,

Steve

Good work.
I've just gave it a try:

First i tried old api (kaffeine)-> everything works as expected. Then i tried new API (with latest tune.c) -> nova-t and nova-s work, cinergyT2 doesn't. I've also noticed that FE_SET_PROPERTY ioctl always return -1, even when success..
Then i tried old api again -> now dvb-s doesn't lock and dvb-t always lock on the freq used in tune.c

Forgot to say that cinergyT2 always work with old api

Quoted 16 lines
Quoted 6 lines

Christophe, thanks for the feedback. I'm not familiar with the cinergyT2 driver so I'll look into this tonight and see what's causing the tuning to fail.

Thanks for highlighting this.

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#5 lore raw
In reply to Christophe Thommeret
Quoted 97 lines · Christophe Thommeret

Le Friday 12 September 2008 15:18:38 Steven Toth, vous avez écrit :

Quoted 90 lines
Quoted 83 lines · Christophe Thommeret

Le Friday 12 September 2008 07:51:17 Steven Toth, vous avez écrit :

Quoted 74 lines

Hello!

More progress today, 7 new patches were merged - all related to the feedback and suggestions we had.... And a bugfix. :)

The DTV_SET/GET command syntax has been rationalised, as Hans requested. This cleans up the application API nicely. Various internal improvements and code cleanup related to variable length arrays, moving values to/from userspace to the kernel. Interfacing to the demods to allow them to interact with set/get property requests, if they chose to do so. Quite a lot of changes internally and to the user facing API.

If you're planning to test then you'll need the tune-v0.0.5.c to see the different. (steventoth.net/linux/s2/tune-v0.0.5.tgz)

In addition, some related news:

mkrufky spent some time adding S2API isdb-t support to the siano driver, that's working pretty well - tuning via the S2API app.

Two tree here, offering slightly different approaches, one with S2API, one using some spare bits in the DVB-T tuning fields.

http://linuxtv.org/hg/~mkrufky/sms1xxx-s2api-isdbt/
http://linuxtv.org/hg/~mkrufky/sms1xxx-isdbt-as-dvbt/

(See tune-v0.0.5.tgz for example ISDB-T tuning code)

If you're interested in seeing the impact of switching to S2API for this driver, see the set_frontend() func, it's a small change - just a few lines to reference the dtv_frontend_properties cache.

I don't think we're quite ready to announce we've conquered the complete ISDB-T API, so don't assume that this is concrete.... As we experiment with other ISDB-T products we'll probably find reasons to tweak the API a little further as a standard begins to form..... but tuning through a clean API is a great step forward, and its working now, today. Thank you mkrufky :)

Hans Werner sent a large patch for the multifrontend HVR3000/HVR4000 combined DVB-T/DVB-S/S2 support for the S2API tree. (Thanks Hans - this was obviously a lot of manual merge work, it's greatly appreciated.)

What would everyone like to see happen with this patch?

Would you prefer to see this dealt with outside of the S2API discussion, or would you like to see this included and merged? Let me know your thoughts. Andreas also has the multifrontend thread running, so comment here if you would like to see this as part of the S2API patches, or comment on the Andreas thread of you want this as a separate patchset at a later date.

Darron Broad has offered to bring the cx24116.c driver up to date with some additions he has in his repositories. With any luck we may see these merged into the current cx24116 driver within a few days. Thank you Darron.

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm open to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

Igor has been busy patching the szap-s2 tool
(http://liplianindvb.sourceforge.net/hg/szap-s2/) so many thanks to Igor! Gregoire has been running some basic tests and appears to be having some success, that's encouraging. Thank you.

What's next?

Now's probably a good time to start patching dvb-apps. I think the frontend.h changes are close enough for that work to begin. This will probably start Friday, so keep your eyes and open for the stoth/s2api-dvb-apps tree appearing ... and an announcement here.

Quoted 5 lines

Thanks again to everyone, your efforts are appreciated!

Regards,

Steve

Good work.
I've just gave it a try:

Quoted 6 lines

First i tried old api (kaffeine)-> everything works as expected. Then i tried new API (with latest tune.c) -> nova-t and nova-s work, cinergyT2 doesn't. I've also noticed that FE_SET_PROPERTY ioctl always return -1, even when success..
Then i tried old api again -> now dvb-s doesn't lock and dvb-t always lock on the freq used in tune.c

Quoted 5 lines

Christophe, thanks for the feedback. I'm not familiar with the cinergyT2 driver so I'll look into this tonight and see what's causing the tuning to fail.

Thanks for highlighting this.

Quoted 11 lines

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Good to know. (I also saw your followup email). I have zero experience with the cinergyT2 but the old api should still be working reliably. I plan to investigate this, sounds like a bug! :)

Regards,

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#6 lore raw
Quoted 7 lines · Steven Toth
Quoted 6 lines · Christophe Thommeret

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

Quoted 7 lines
Quoted 3 lines

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Good to know. (I also saw your followup email). I have zero experience with the cinergyT2 but the old api should still be working reliably. I plan to investigate this, sounds like a bug! :)

Holger was of the opinion that having the demux in dvb-core was stupid for devices which have no hw demux, so he programmed around dvb-core. His plan was to add a mmap-dma-buffers kind of API to the frontend device, but it never got implemented.

Anyway, it's bad if one driver is different than all the others.

Johannes

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#7 lore raw
Quoted 14 lines · Johannes Stezenbach
Quoted 6 lines · Steven Toth
Quoted 5 lines · Christophe Thommeret

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

Quoted 6 lines
Quoted 3 lines

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Good to know. (I also saw your followup email). I have zero experience with the cinergyT2 but the old api should still be working reliably. I plan to investigate this, sounds like a bug! :)

Quoted 7 lines

Holger was of the opinion that having the demux in dvb-core was stupid for devices which have no hw demux, so he programmed around dvb-core. His plan was to add a mmap-dma-buffers kind of API to the frontend device, but it never got implemented.

Anyway, it's bad if one driver is different than all the others.

Hmm, I didn't realize this, good to know.

Now it's peaked my interest, I'll have to look at the code.

The existing API should still work at a bare minimum, if it's not - it needs to.

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#8 lore raw
Quoted 15 lines · Steven Toth
Quoted 14 lines · Johannes Stezenbach
Quoted 6 lines · Steven Toth
Quoted 4 lines · Christophe Thommeret

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Good to know. (I also saw your followup email). I have zero experience with the cinergyT2 but the old api should still be working reliably. I plan to investigate this, sounds like a bug! :)

Holger was of the opinion that having the demux in dvb-core was stupid for devices which have no hw demux, so he programmed around dvb-core. His plan was to add a mmap-dma-buffers kind of API to the frontend device, but it never got implemented.

Quoted 7 lines
Quoted 1 line

Anyway, it's bad if one driver is different than all the others.

Hmm, I didn't realize this, good to know.

Now it's peaked my interest, I'll have to look at the code.

The existing API should still work at a bare minimum, if it's not - it needs to.

So I looked the the cinergyT2 code, that's a complete eye-opener. It has it's own ioctl handler, outside of dvb-core.

It's a good news / bad news thing.

The good news is that this driver will not be effected by the S2API changes, so nothing can break.

The bad news is that this driver will not be effected by the S2API changes, so it doesn't get the benefit.

Regardless of S2API or multiproto, I see no reason why we shouldn't bring this driver back into dvb-core.

I don't have a device to test, but here's a patch (0% tested, with bugs probably) that converts the module back to a regular dvb-core compatible device, so the S2API would work with this. If anyone wants to test this, and finds bugs - I won't get back to this driver for a couple of weeks - so your patches would be welcome. :)

Frankly, is S2API is selected for merge and we have enough users of the current non-dvb-core driver, I'll probably re-write it from the spec.

So much to do, so little time.

- Steve

linux/drivers/media/dvb/cinergyT2/cinergyT2.c +237 -230
Index: s2/linux/drivers/media/dvb/cinergyT2/cinergyT2.c
===================================================================
@@ -36,6 +36,7 @@
 #include "dmxdev.h"
 #include "dvb_demux.h"
 #include "dvb_net.h"
+#include "dvb_frontend.h"
 
 #ifdef CONFIG_DVB_CINERGYT2_TUNING
 	#define STREAM_URB_COUNT (CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT)
@@ -103,29 +104,17 @@
 	uint8_t prev_lock_bits;
 } __attribute__((packed));
 
-static struct dvb_frontend_info cinergyt2_fe_info = {
-	.name = DRIVER_NAME,
-	.type = FE_OFDM,
-	.frequency_min = 174000000,
-	.frequency_max = 862000000,
-	.frequency_stepsize = 166667,
-	.caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 |
-		FE_CAN_FEC_3_4 | FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 |
-		FE_CAN_FEC_AUTO |
-		FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
-		FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO |
-		FE_CAN_HIERARCHY_AUTO | FE_CAN_RECOVER | FE_CAN_MUTE_TS
-};
-
 struct cinergyt2 {
 	struct dvb_demux demux;
 	struct usb_device *udev;
 	struct mutex sem;
 	struct mutex wq_sem;
 	struct dvb_adapter adapter;
-	struct dvb_device *fedev;
 	struct dmxdev dmxdev;
 	struct dvb_net dvbnet;
+	struct dvb_frontend *frontend;
+	struct dmx_frontend fe_hw;
+	struct dmx_frontend fe_mem;
 
 	int streaming;
 	int sleeping;
@@ -501,266 +490,208 @@
 	return tps;
 }
 
-static int cinergyt2_open (struct inode *inode, struct file *file)
+static void cinergyt2_unregister(struct cinergyt2 *cinergyt2)
+{
+	if (cinergyt2->frontend != NULL) {
+		dvb_net_release(&cinergyt2->dvbnet);
+		cinergyt2->demux.dmx.remove_frontend(&cinergyt2->demux.dmx, &cinergyt2->fe_mem);
+		cinergyt2->demux.dmx.remove_frontend(&cinergyt2->demux.dmx, &cinergyt2->fe_hw);
+		dvb_dmxdev_release(&cinergyt2->dmxdev);
+		dvb_dmx_release(&cinergyt2->demux);
+		dvb_unregister_frontend(cinergyt2->frontend);
+		dvb_frontend_detach(cinergyt2->frontend);
+		dvb_unregister_adapter(&cinergyt2->adapter);
+	}
+
+	cinergyt2_free_stream_urbs(cinergyt2);
+	kfree(cinergyt2);
+}
+
+static unsigned int cinergyt2_poll (struct file *file, struct poll_table_struct *wait)
 {
 	struct dvb_device *dvbdev = file->private_data;
 	struct cinergyt2 *cinergyt2 = dvbdev->priv;
-	int err = -EAGAIN;
+	unsigned int mask = 0;
 
 	if (cinergyt2->disconnect_pending)
-		goto out;
-	err = mutex_lock_interruptible(&cinergyt2->wq_sem);
-	if (err)
-		goto out;
-
-	err = mutex_lock_interruptible(&cinergyt2->sem);
-	if (err)
-		goto out_unlock1;
-
-	if ((err = dvb_generic_open(inode, file)))
-		goto out_unlock2;
+		return -EAGAIN;
+	if (mutex_lock_interruptible(&cinergyt2->sem))
+		return -ERESTARTSYS;
 
-	if ((file->f_flags & O_ACCMODE) != O_RDONLY) {
-		cinergyt2_sleep(cinergyt2, 0);
-		schedule_delayed_work(&cinergyt2->query_work, HZ/2);
-	}
+	poll_wait(file, &cinergyt2->poll_wq, wait);
 
-	atomic_inc(&cinergyt2->inuse);
+	if (cinergyt2->pending_fe_events != 0)
+		mask |= (POLLIN | POLLRDNORM | POLLPRI);
 
-out_unlock2:
 	mutex_unlock(&cinergyt2->sem);
-out_unlock1:
-	mutex_unlock(&cinergyt2->wq_sem);
-out:
-	return err;
+
+	return mask;
 }
 
-static void cinergyt2_unregister(struct cinergyt2 *cinergyt2)
+static int cinergyt2_read_status(struct dvb_frontend* fe, fe_status_t* status)
 {
-	dvb_net_release(&cinergyt2->dvbnet);
-	dvb_dmxdev_release(&cinergyt2->dmxdev);
-	dvb_dmx_release(&cinergyt2->demux);
-	dvb_unregister_device(cinergyt2->fedev);
-	dvb_unregister_adapter(&cinergyt2->adapter);
+	struct cinergyt2 *cinergyt2 = fe->demodulator_priv;
+	struct dvbt_get_status_msg *s = &cinergyt2->status;
 
-	cinergyt2_free_stream_urbs(cinergyt2);
-	kfree(cinergyt2);
+	if (0xffff - le16_to_cpu(s->gain) > 30)
+		*status |= FE_HAS_SIGNAL;
+	if (s->lock_bits & (1 << 6))
+		*status |= FE_HAS_LOCK;
+	if (s->lock_bits & (1 << 5))
+		*status |= FE_HAS_SYNC;
+	if (s->lock_bits & (1 << 4))
+		*status |= FE_HAS_CARRIER;
+	if (s->lock_bits & (1 << 1))
+		*status |= FE_HAS_VITERBI;
+
+	return 0;
 }
 
-static int cinergyt2_release (struct inode *inode, struct file *file)
+static int cinergyt2_read_ber(struct dvb_frontend* fe, u32* ber)
 {
-	struct dvb_device *dvbdev = file->private_data;
-	struct cinergyt2 *cinergyt2 = dvbdev->priv;
+	struct cinergyt2 *cinergyt2 = fe->demodulator_priv;
+	struct dvbt_get_status_msg *s = &cinergyt2->status;
 
-	mutex_lock(&cinergyt2->wq_sem);
+	*ber = s->viterbi_error_rate;
 
-	if (!cinergyt2->disconnect_pending && (file->f_flags & O_ACCMODE) != O_RDONLY) {
-		cancel_rearming_delayed_work(&cinergyt2->query_work);
+	return 0;
+}
 
-		mutex_lock(&cinergyt2->sem);
-		cinergyt2_sleep(cinergyt2, 1);
-		mutex_unlock(&cinergyt2->sem);
-	}
+static int cinergyt2_read_signal_strength(struct dvb_frontend* fe, u16* signal_strength)
+{
+	struct cinergyt2 *cinergyt2 = fe->demodulator_priv;
+	struct dvbt_get_status_msg *s = &cinergyt2->status;
 
-	mutex_unlock(&cinergyt2->wq_sem);
+	*signal_strength = 0xffff - le16_to_cpu(s->gain);
 
-	if (atomic_dec_and_test(&cinergyt2->inuse) && cinergyt2->disconnect_pending) {
-		warn("delayed unregister in release");
-		cinergyt2_unregister(cinergyt2);
-	}
+	return 0;
+}
+
+static int cinergyt2_read_snr(struct dvb_frontend* fe, u16* snr)
+{
+	struct cinergyt2 *cinergyt2 = fe->demodulator_priv;
+	struct dvbt_get_status_msg *s = &cinergyt2->status;
 
-	return dvb_generic_release(inode, file);
+	*snr = (s->snr << 8) | s->snr;
+
+	return 0;
 }
 
-static unsigned int cinergyt2_poll (struct file *file, struct poll_table_struct *wait)
+static int cinergyt2_read_ucblocks(struct dvb_frontend* fe, u32* ucblocks)
 {
-	struct dvb_device *dvbdev = file->private_data;
-	struct cinergyt2 *cinergyt2 = dvbdev->priv;
-	unsigned int mask = 0;
+	struct cinergyt2 *cinergyt2 = fe->demodulator_priv;
 
-	if (cinergyt2->disconnect_pending)
-		return -EAGAIN;
 	if (mutex_lock_interruptible(&cinergyt2->sem))
 		return -ERESTARTSYS;
 
-	poll_wait(file, &cinergyt2->poll_wq, wait);
+	*ucblocks = cinergyt2->uncorrected_block_count;
 
-	if (cinergyt2->pending_fe_events != 0)
-		mask |= (POLLIN | POLLRDNORM | POLLPRI);
+	cinergyt2->uncorrected_block_count = 0;
 
 	mutex_unlock(&cinergyt2->sem);
 
-	return mask;
+	/* UNC are already converted to host byte order... */
+
+	return 0;
 }
 
+static int cinergyt2_get_tune_settings(struct dvb_frontend* fe, struct dvb_frontend_tune_settings *tune)
+{
+	tune->min_delay_ms = 1000;
+	return 0;
+}
 
-static int cinergyt2_ioctl (struct inode *inode, struct file *file,
-		     unsigned cmd, unsigned long arg)
+static int cinergyt2_get_frontend(struct dvb_frontend* fe, struct dvb_frontend_parameters *p)
 {
-	struct dvb_device *dvbdev = file->private_data;
-	struct cinergyt2 *cinergyt2 = dvbdev->priv;
-	struct dvbt_get_status_msg *stat = &cinergyt2->status;
-	fe_status_t status = 0;
+	/* Taken from the previous IOCTL handler */
 
-	switch (cmd) {
-	case FE_GET_INFO:
-		return copy_to_user((void __user*) arg, &cinergyt2_fe_info,
-				    sizeof(struct dvb_frontend_info));
-
-	case FE_READ_STATUS:
-		if (0xffff - le16_to_cpu(stat->gain) > 30)
-			status |= FE_HAS_SIGNAL;
-		if (stat->lock_bits & (1 << 6))
-			status |= FE_HAS_LOCK;
-		if (stat->lock_bits & (1 << 5))
-			status |= FE_HAS_SYNC;
-		if (stat->lock_bits & (1 << 4))
-			status |= FE_HAS_CARRIER;
-		if (stat->lock_bits & (1 << 1))
-			status |= FE_HAS_VITERBI;
-
-		return copy_to_user((void  __user*) arg, &status, sizeof(status));
-
-	case FE_READ_BER:
-		return put_user(le32_to_cpu(stat->viterbi_error_rate),
-				(__u32 __user *) arg);
-
-	case FE_READ_SIGNAL_STRENGTH:
-		return put_user(0xffff - le16_to_cpu(stat->gain),
-				(__u16 __user *) arg);
-
-	case FE_READ_SNR:
-		return put_user((stat->snr << 8) | stat->snr,
-				(__u16 __user *) arg);
-
-	case FE_READ_UNCORRECTED_BLOCKS:
-	{
-		uint32_t unc_count;
-
-		if (mutex_lock_interruptible(&cinergyt2->sem))
-			return -ERESTARTSYS;
-		unc_count = cinergyt2->uncorrected_block_count;
-		cinergyt2->uncorrected_block_count = 0;
-		mutex_unlock(&cinergyt2->sem);
-
-		/* UNC are already converted to host byte order... */
-		return put_user(unc_count,(__u32 __user *) arg);
-	}
-	case FE_SET_FRONTEND:
-	{
-		struct dvbt_set_parameters_msg *param = &cinergyt2->param;
-		struct dvb_frontend_parameters p;
-		int err;
-
-		if ((file->f_flags & O_ACCMODE) == O_RDONLY)
-			return -EPERM;
-
-		if (copy_from_user(&p, (void  __user*) arg, sizeof(p)))
-			return -EFAULT;
-
-		if (cinergyt2->disconnect_pending)
-			return -EAGAIN;
-		if (mutex_lock_interruptible(&cinergyt2->sem))
-			return -ERESTARTSYS;
-
-		param->cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
-		param->tps = cpu_to_le16(compute_tps(&p));
-		param->freq = cpu_to_le32(p.frequency / 1000);
-		param->bandwidth = 8 - p.u.ofdm.bandwidth - BANDWIDTH_8_MHZ;
+	/**
+	 *  trivial to implement (see struct dvbt_get_status_msg).
+	 *  equivalent to FE_READ ioctls, but needs
+	 *  TPS -> linux-dvb parameter set conversion. Feel free
+	 *  to implement this and send us a patch if you need this
+	 *  functionality.
+	 */
 
-		stat->lock_bits = 0;
-		cinergyt2->pending_fe_events++;
-		wake_up_interruptible(&cinergyt2->poll_wq);
+	return 0;
+}
 
-		err = cinergyt2_command(cinergyt2,
-					(char *) param, sizeof(*param),
-					NULL, 0);
-
-		mutex_unlock(&cinergyt2->sem);
-
-		return (err < 0) ? err : 0;
-	}
-
-	case FE_GET_FRONTEND:
-		/**
-		 *  trivial to implement (see struct dvbt_get_status_msg).
-		 *  equivalent to FE_READ ioctls, but needs
-		 *  TPS -> linux-dvb parameter set conversion. Feel free
-		 *  to implement this and send us a patch if you need this
-		 *  functionality.
-		 */
-		break;
-
-	case FE_GET_EVENT:
-	{
-		/**
-		 *  for now we only fill the status field. the parameters
-		 *  are trivial to fill as soon FE_GET_FRONTEND is done.
-		 */
-		struct dvb_frontend_event __user *e = (void __user *) arg;
-		if (cinergyt2->pending_fe_events == 0) {
-			if (file->f_flags & O_NONBLOCK)
-				return -EWOULDBLOCK;
-			wait_event_interruptible(cinergyt2->poll_wq,
-						 cinergyt2->pending_fe_events > 0);
-		}
-		cinergyt2->pending_fe_events = 0;
-		return cinergyt2_ioctl(inode, file, FE_READ_STATUS,
-					(unsigned long) &e->status);
-	}
+static int cinergyt2_set_frontend(struct dvb_frontend* fe, struct dvb_frontend_parameters *p)
+{
+	struct cinergyt2 *cinergyt2 = fe->demodulator_priv;
+	struct dvbt_get_status_msg *s = &cinergyt2->status;
+	struct dvbt_set_parameters_msg *param = &cinergyt2->param;
+	int err;
 
-	default:
-		;
-	}
+	if (cinergyt2->disconnect_pending)
+		return -EAGAIN;
+	if (mutex_lock_interruptible(&cinergyt2->sem))
+		return -ERESTARTSYS;
+
+	param->cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
+	param->tps = cpu_to_le16(compute_tps(p));
+	param->freq = cpu_to_le32(p->frequency / 1000);
+	param->bandwidth = 8 - p->u.ofdm.bandwidth - BANDWIDTH_8_MHZ;
 
-	return -EINVAL;
+	s->lock_bits = 0;
+	cinergyt2->pending_fe_events++;
+	wake_up_interruptible(&cinergyt2->poll_wq);
+
+	err = cinergyt2_command(cinergyt2,
+		(char *) param, sizeof(*param),
+		NULL, 0);
+
+	mutex_unlock(&cinergyt2->sem);
+
+	return (err < 0) ? err : 0;
 }
 
-static int cinergyt2_mmap(struct file *file, struct vm_area_struct *vma)
+static int cinergyt2_fe_init(struct dvb_frontend* fe)
 {
-	struct dvb_device *dvbdev = file->private_data;
-	struct cinergyt2 *cinergyt2 = dvbdev->priv;
-	int ret = 0;
+	struct cinergyt2 *cinergyt2 = fe->demodulator_priv;
+        int err = -EAGAIN;
 
-	lock_kernel();
+        if (cinergyt2->disconnect_pending)
+                goto out;
+        err = mutex_lock_interruptible(&cinergyt2->wq_sem);
+        if (err)
+                goto out;
 
-	if (vma->vm_flags & (VM_WRITE | VM_EXEC)) {
-		ret = -EPERM;
-		goto bailout;
-	}
+        err = mutex_lock_interruptible(&cinergyt2->sem);
+        if (err)
+                goto out_unlock1;
 
-	if (vma->vm_end > vma->vm_start + STREAM_URB_COUNT * STREAM_BUF_SIZE) {
-		ret = -EINVAL;
-		goto bailout;
-	}
+	cinergyt2_sleep(cinergyt2, 0);
+	schedule_delayed_work(&cinergyt2->query_work, HZ/2);
 
-	vma->vm_flags |= (VM_IO | VM_DONTCOPY);
-	vma->vm_file = file;
+        atomic_inc(&cinergyt2->inuse);
 
-	ret = remap_pfn_range(vma, vma->vm_start,
-			      virt_to_phys(cinergyt2->streambuf) >> PAGE_SHIFT,
-			      vma->vm_end - vma->vm_start,
-			      vma->vm_page_prot) ? -EAGAIN : 0;
-bailout:
-	unlock_kernel();
-	return ret;
+        mutex_unlock(&cinergyt2->sem);
+out_unlock1:
+        mutex_unlock(&cinergyt2->wq_sem);
+out:
+        return err;
 }
 
-static struct file_operations cinergyt2_fops = {
-	.owner          = THIS_MODULE,
-	.ioctl		= cinergyt2_ioctl,
-	.poll           = cinergyt2_poll,
-	.open           = cinergyt2_open,
-	.release        = cinergyt2_release,
-	.mmap		= cinergyt2_mmap
-};
+static void cinergyt2_release(struct dvb_frontend* fe)
+{
+	struct cinergyt2 *cinergyt2 = fe->demodulator_priv;
 
-static struct dvb_device cinergyt2_fe_template = {
-	.users = ~0,
-	.writers = 1,
-	.readers = (~0)-1,
-	.fops = &cinergyt2_fops
-};
+	mutex_lock(&cinergyt2->wq_sem);
+
+	cancel_rearming_delayed_work(&cinergyt2->query_work);
+
+	mutex_lock(&cinergyt2->sem);
+	cinergyt2_sleep(cinergyt2, 1);
+	mutex_unlock(&cinergyt2->sem);
+
+	mutex_unlock(&cinergyt2->wq_sem);
+
+	if (atomic_dec_and_test(&cinergyt2->inuse) && cinergyt2->disconnect_pending) {
+		warn("delayed unregister in release");
+		cinergyt2_unregister(cinergyt2);
+	}
+}
 
 #ifdef ENABLE_RC
 
@@ -956,6 +887,8 @@
 	mutex_unlock(&cinergyt2->sem);
 }
 
+static struct dvb_frontend_ops cinergyt2_fe_ops;
+
 static int cinergyt2_probe (struct usb_interface *intf,
 		  const struct usb_device_id *id)
 {
@@ -995,6 +928,15 @@
 		return err;
 	}
 
+	/* register frontend */
+        cinergyt2->adapter.priv = cinergyt2;
+	err = dvb_register_frontend(&cinergyt2->adapter, cinergyt2->frontend);
+	if (err < 0) {
+		printk(KERN_ERR "%s: dvb_register_frontend failed "
+			"(errno = %d)\n", DRIVER_NAME, err);
+		goto fail_frontend;
+	}
+
 	cinergyt2->demux.priv = cinergyt2;
 	cinergyt2->demux.filternum = 256;
 	cinergyt2->demux.feednum = 256;
@@ -1006,7 +948,7 @@
 
 	if ((err = dvb_dmx_init(&cinergyt2->demux)) < 0) {
 		dprintk(1, "dvb_dmx_init() failed (err = %d)\n", err);
-		goto bailout;
+		goto fail_dmx;
 	}
 
 	cinergyt2->dmxdev.filternum = cinergyt2->demux.filternum;
@@ -1015,26 +957,60 @@
 
 	if ((err = dvb_dmxdev_init(&cinergyt2->dmxdev, &cinergyt2->adapter)) < 0) {
 		dprintk(1, "dvb_dmxdev_init() failed (err = %d)\n", err);
-		goto bailout;
+		goto fail_dmxdev;
 	}
 
+        cinergyt2->fe_hw.source = DMX_FRONTEND_0;
+        err = cinergyt2->demux.dmx.add_frontend(&cinergyt2->demux.dmx, &cinergyt2->fe_hw);
+        if (err < 0) {
+                printk(KERN_ERR "%s: add_frontend failed "
+                       "(DMX_FRONTEND_0, errno = %d)\n", DRIVER_NAME, err);
+                goto fail_fe_hw;
+        }
+
+        cinergyt2->fe_mem.source = DMX_MEMORY_FE;
+        err = cinergyt2->demux.dmx.add_frontend(&cinergyt2->demux.dmx, &cinergyt2->fe_mem);
+        if (err < 0) {
+                printk(KERN_ERR "%s: add_frontend failed "
+                       "(DMX_MEMORY_FE, errno = %d)\n", DRIVER_NAME, err);
+                goto fail_fe_mem;
+        }
+
+        err = cinergyt2->demux.dmx.connect_frontend(&cinergyt2->demux.dmx, &cinergyt2->fe_hw);
+        if (err < 0) {
+                printk(KERN_ERR "%s: connect_frontend failed (errno = %d)\n",
+                       DRIVER_NAME, err);
+                goto fail_fe_conn;
+        }
+
+	/* Attach the DVB frontend */
+	memcpy(&cinergyt2->frontend->ops, &cinergyt2_fe_ops, sizeof(struct dvb_frontend_ops));
+	cinergyt2->frontend->demodulator_priv = cinergyt2;
+
 	if (dvb_net_init(&cinergyt2->adapter, &cinergyt2->dvbnet, &cinergyt2->demux.dmx))
+		/* ST- Why wouldn't this be mandatory failure? */
 		dprintk(1, "dvb_net_init() failed!\n");
 
-	dvb_register_device(&cinergyt2->adapter, &cinergyt2->fedev,
-			    &cinergyt2_fe_template, cinergyt2,
-			    DVB_DEVICE_FRONTEND);
-
 	err = cinergyt2_register_rc(cinergyt2);
 	if (err)
-		goto bailout;
+		goto fail_net;
 
 	return 0;
 
-bailout:
+fail_net:
 	dvb_net_release(&cinergyt2->dvbnet);
+fail_fe_conn:
+	cinergyt2->demux.dmx.remove_frontend(&cinergyt2->demux.dmx, &cinergyt2->fe_mem);
+fail_fe_mem:
+	cinergyt2->demux.dmx.remove_frontend(&cinergyt2->demux.dmx, &cinergyt2->fe_hw);
+fail_fe_hw:
 	dvb_dmxdev_release(&cinergyt2->dmxdev);
+fail_dmxdev:
 	dvb_dmx_release(&cinergyt2->demux);
+fail_dmx:
+	dvb_unregister_frontend(cinergyt2->frontend);
+fail_frontend:
+	dvb_frontend_detach(cinergyt2->frontend);
 	dvb_unregister_adapter(&cinergyt2->adapter);
 	cinergyt2_free_stream_urbs(cinergyt2);
 	kfree(cinergyt2);
@@ -1119,6 +1095,37 @@
 
 MODULE_DEVICE_TABLE(usb, cinergyt2_table);
 
+static struct dvb_frontend_ops cinergyt2_fe_ops = {
+
+	.info = {
+		.name = DRIVER_NAME,
+		.type = FE_OFDM,
+		.frequency_min = 174000000,
+		.frequency_max = 862000000,
+		.frequency_stepsize = 166667,
+		.caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 |
+			FE_CAN_FEC_3_4 | FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 |
+			FE_CAN_FEC_AUTO |
+			FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
+			FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO |
+			FE_CAN_HIERARCHY_AUTO | FE_CAN_RECOVER | FE_CAN_MUTE_TS
+	},
+
+	.release = cinergyt2_release,
+
+	.init = cinergyt2_fe_init,
+
+	.set_frontend = cinergyt2_set_frontend,
+	.get_frontend = cinergyt2_get_frontend,
+	.get_tune_settings = cinergyt2_get_tune_settings,
+
+	.read_status = cinergyt2_read_status,
+	.read_ber = cinergyt2_read_ber,
+	.read_signal_strength = cinergyt2_read_signal_strength,
+	.read_snr = cinergyt2_read_snr,
+	.read_ucblocks = cinergyt2_read_ucblocks,
+};
+
 static struct usb_driver cinergyt2_driver = {
 	.name	= "cinergyT2",
 	.probe	= cinergyt2_probe,

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#9 lore raw

Le Sunday 14 September 2008 18:47:00 Steven Toth, vous avez écrit :

Quoted 53 lines
Quoted 23 lines · Steven Toth
Quoted 22 lines · Johannes Stezenbach
Quoted 7 lines · Steven Toth
Quoted 6 lines · Christophe Thommeret

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

Quoted 7 lines
Quoted 3 lines

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Good to know. (I also saw your followup email). I have zero experience with the cinergyT2 but the old api should still be working reliably. I plan to investigate this, sounds like a bug! :)

Holger was of the opinion that having the demux in dvb-core was stupid for devices which have no hw demux, so he programmed around dvb-core. His plan was to add a mmap-dma-buffers kind of API to the frontend device, but it never got implemented.

Quoted 8 lines
Quoted 1 line

Anyway, it's bad if one driver is different than all the others.

Hmm, I didn't realize this, good to know.

Now it's peaked my interest, I'll have to look at the code.

The existing API should still work at a bare minimum, if it's not - it needs to.

So I looked the the cinergyT2 code, that's a complete eye-opener. It has it's own ioctl handler, outside of dvb-core.

It's a good news / bad news thing.

The good news is that this driver will not be effected by the S2API changes, so nothing can break.

The bad news is that this driver will not be effected by the S2API changes, so it doesn't get the benefit.

Regardless of S2API or multiproto, I see no reason why we shouldn't bring this driver back into dvb-core.

I don't have a device to test, but here's a patch (0% tested, with bugs probably) that converts the module back to a regular dvb-core compatible device, so the S2API would work with this. If anyone wants to test this, and finds bugs - I won't get back to this driver for a couple of weeks - so your patches would be welcome. :)

Quoted 6 lines

Frankly, is S2API is selected for merge and we have enough users of the current non-dvb-core driver, I'll probably re-write it from the spec.

So much to do, so little time.

- Steve

Steve,

as you expected, it's abit buggy and crashes at load ;) i've searched for the alternative cinergyT2 driver. it's available at: http://linuxtv.org/hg/~tmerle/cinergyT2/

haven't tried it yet but will do (at least several people seems to have it working).

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#10 lore raw

Le Sunday 14 September 2008 20:04:06 Christophe Thommeret, vous avez écrit :

Quoted 62 lines

Le Sunday 14 September 2008 18:47:00 Steven Toth, vous avez écrit :

Quoted 54 lines
Quoted 24 lines · Steven Toth
Quoted 23 lines · Johannes Stezenbach
Quoted 7 lines · Steven Toth
Quoted 6 lines · Christophe Thommeret

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

Quoted 8 lines
Quoted 4 lines

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Good to know. (I also saw your followup email). I have zero experience with the cinergyT2 but the old api should still be working reliably. I plan to investigate this, sounds like a bug! :)

Holger was of the opinion that having the demux in dvb-core was stupid for devices which have no hw demux, so he programmed around dvb-core. His plan was to add a mmap-dma-buffers kind of API to the frontend device, but it never got implemented.

Quoted 8 lines
Quoted 1 line

Anyway, it's bad if one driver is different than all the others.

Hmm, I didn't realize this, good to know.

Now it's peaked my interest, I'll have to look at the code.

The existing API should still work at a bare minimum, if it's not - it needs to.

So I looked the the cinergyT2 code, that's a complete eye-opener. It has it's own ioctl handler, outside of dvb-core.

It's a good news / bad news thing.

The good news is that this driver will not be effected by the S2API changes, so nothing can break.

The bad news is that this driver will not be effected by the S2API changes, so it doesn't get the benefit.

Regardless of S2API or multiproto, I see no reason why we shouldn't bring this driver back into dvb-core.

I don't have a device to test, but here's a patch (0% tested, with bugs probably) that converts the module back to a regular dvb-core compatible device, so the S2API would work with this. If anyone wants to test this, and finds bugs - I won't get back to this driver for a couple of weeks - so your patches would be welcome. :)

Quoted 6 lines

Frankly, is S2API is selected for merge and we have enough users of the current non-dvb-core driver, I'll probably re-write it from the spec.

So much to do, so little time.

- Steve

Quoted 8 lines

Steve,

as you expected, it's abit buggy and crashes at load ;) i've searched for the alternative cinergyT2 driver. it's available at: http://linuxtv.org/hg/~tmerle/cinergyT2/

haven't tried it yet but will do (at least several people seems to have it working).

Have it working, not as good as Holger' one (often fails to lock) but it works, with both old and new api.
So, one problem less :)

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#11 lore raw
Quoted 64 lines · Christophe Thommeret

Le Sunday 14 September 2008 20:04:06 Christophe Thommeret, vous avez écrit :

Quoted 63 lines

Le Sunday 14 September 2008 18:47:00 Steven Toth, vous avez écrit :

Quoted 50 lines
Quoted 22 lines · Steven Toth
Quoted 21 lines · Johannes Stezenbach
Quoted 7 lines · Steven Toth
Quoted 6 lines · Christophe Thommeret

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

Quoted 7 lines
Quoted 4 lines

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Good to know. (I also saw your followup email). I have zero experience with the cinergyT2 but the old api should still be working reliably. I plan to investigate this, sounds like a bug! :)

Holger was of the opinion that having the demux in dvb-core was stupid for devices which have no hw demux, so he programmed around dvb-core. His plan was to add a mmap-dma-buffers kind of API to the frontend device, but it never got implemented.

Quoted 7 lines
Quoted 1 line

Anyway, it's bad if one driver is different than all the others.

Hmm, I didn't realize this, good to know.

Now it's peaked my interest, I'll have to look at the code.

The existing API should still work at a bare minimum, if it's not - it needs to.

So I looked the the cinergyT2 code, that's a complete eye-opener. It has it's own ioctl handler, outside of dvb-core.

It's a good news / bad news thing.

The good news is that this driver will not be effected by the S2API changes, so nothing can break.

The bad news is that this driver will not be effected by the S2API changes, so it doesn't get the benefit.

Regardless of S2API or multiproto, I see no reason why we shouldn't bring this driver back into dvb-core.

I don't have a device to test, but here's a patch (0% tested, with bugs probably) that converts the module back to a regular dvb-core compatible device, so the S2API would work with this. If anyone wants to test this, and finds bugs - I won't get back to this driver for a couple of weeks - so your patches would be welcome. :)

Quoted 6 lines

Frankly, is S2API is selected for merge and we have enough users of the current non-dvb-core driver, I'll probably re-write it from the spec.

So much to do, so little time.

- Steve

Steve,

as you expected, it's abit buggy and crashes at load ;) i've searched for the alternative cinergyT2 driver. it's available at: http://linuxtv.org/hg/~tmerle/cinergyT2/

Quoted 7 lines
Quoted 2 lines

haven't tried it yet but will do (at least several people seems to have it working).

Have it working, not as good as Holger' one (often fails to lock) but it works, with both old and new api.
So, one problem less :)

Good to know Christophe, thanks.

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#12 lore raw

В сообщении от 15 September 2008 06:17:02 Steven Toth написал(а):

Quoted 2 lines
Quoted 1 line · Christophe Thommeret

Le Sunday 14 September 2008 20:04:06 Christophe Thommeret, vous avez

Иcrit :

Quoted 77 lines
Quoted 68 lines
Quoted 68 lines

Le Sunday 14 September 2008 18:47:00 Steven Toth, vous avez Иcrit :

Quoted 54 lines
Quoted 24 lines · Steven Toth
Quoted 23 lines · Johannes Stezenbach
Quoted 7 lines · Steven Toth
Quoted 6 lines · Christophe Thommeret

As far as i understand, the cinergyT2 driver is a bit unusual, e.g. dvb_register_frontend is never called (hence no dtv_* log messages). I don't know if there is others drivers like this, but this has to be investigated cause rewritting all drivers for S2API could be a bit of work :)

Quoted 8 lines
Quoted 4 lines

P.S.
I think there is an alternate driver for cinergyT2 actually in developement but idon't remember where it's located neither its state.

Good to know. (I also saw your followup email). I have zero experience with the cinergyT2 but the old api should still be working reliably. I plan to investigate this, sounds like a bug! :)

Holger was of the opinion that having the demux in dvb-core was stupid for devices which have no hw demux, so he programmed around dvb-core. His plan was to add a mmap-dma-buffers kind of API to the frontend device, but it never got implemented.

Quoted 8 lines
Quoted 1 line

Anyway, it's bad if one driver is different than all the others.

Hmm, I didn't realize this, good to know.

Now it's peaked my interest, I'll have to look at the code.

The existing API should still work at a bare minimum, if it's not - it needs to.

So I looked the the cinergyT2 code, that's a complete eye-opener. It has it's own ioctl handler, outside of dvb-core.

It's a good news / bad news thing.

The good news is that this driver will not be effected by the S2API changes, so nothing can break.

The bad news is that this driver will not be effected by the S2API changes, so it doesn't get the benefit.

Regardless of S2API or multiproto, I see no reason why we shouldn't bring this driver back into dvb-core.

I don't have a device to test, but here's a patch (0% tested, with bugs probably) that converts the module back to a regular dvb-core compatible device, so the S2API would work with this. If anyone wants to test this, and finds bugs - I won't get back to this driver for a couple of weeks - so your patches would be welcome. :)

Quoted 6 lines

Frankly, is S2API is selected for merge and we have enough users of the current non-dvb-core driver, I'll probably re-write it from the spec.

So much to do, so little time.

- Steve

Steve,

as you expected, it's abit buggy and crashes at load ;) i've searched for the alternative cinergyT2 driver. it's available at: http://linuxtv.org/hg/~tmerle/cinergyT2/

Quoted 6 lines
Quoted 2 lines

haven't tried it yet but will do (at least several people seems to have it working).

Have it working, not as good as Holger' one (often fails to lock) but it works, with both old and new api.
So, one problem less :)

Good to know Christophe, thanks.

Quoted 7 lines

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I am working on stv0288 and si2107/08/09/10 frontends and stb6000 silicon tuner to bring the code in S2 tree. This is a lot of work with checkpatch.pl ! Though drivers already works.

Igor M. Liplianin

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#13 lore raw

Hello,

today I checked my twelve diseqc/lnb possibily I have (3 sat, hi/low, v/h) and my HVR-4000 got lock on all with szap-s2 from Igor M. Liplianin with the S2 API :-)

Signature · 7 lines
Grégoire FAVRE  http://gregoire.favre.googlepages.com  http://www.gnupg.org
               http://picasaweb.google.com/Gregoire.Favre

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#14 lore raw

В сообщении от 15 September 2008 23:02:48 Gregoire Favre написал(а):

Quoted 5 lines

Hello,

today I checked my twelve diseqc/lnb possibily I have (3 sat, hi/low, v/h) and my HVR-4000 got lock on all with szap-s2 from Igor M. Liplianin with the S2 API :-)

Great!
It is like holiday for me.

Signature · 6 lines
Igor M. Liplianin

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

A message that is not in the archive (sent off-list or not yet received): [email protected]

#16 lore raw

PATCH 1/1 S2API - Silicon Labs si2109/2110 demodulator support.

Hi Steve,

Send you patch for Silicon Laboratories si2109/2110 demodulator support.

https://www.silabs.com/products/audiovideo/satellitestb/Pages/default.aspx

It is S2API compliant, as of september, 16-th

Igor

# HG changeset patch
# User Igor M. Liplianin <[email protected]>
# Date 1221600071 -10800
# Node ID 0ae7bbdb302efb54ca12a35858699fb36e5d4e58
# Parent 94bd2599004fcd040f41130e95aebd6f9ce1248b Add support for Silicon Laboratories SI2109/2110 demodulators.

From: Igor M. Liplianin <[email protected]>

Add support for Silicon Laboratories SI2109/2110 demodulator and cards with it, such as DvbWorld PCI2002.

linux/drivers/media/dvb/dm1105/Kconfig +1 -0
diff -r 94bd2599004f -r 0ae7bbdb302e linux/drivers/media/dvb/dm1105/Kconfig
@@ -4,6 +4,7 @@
 	select DVB_PLL if !DVB_FE_CUSTOMISE
 	select DVB_STV0299 if !DVB_FE_CUSTOMISE
 	select DVB_CX24116 if !DVB_FE_CUSTOMISE
+	select DVB_SI21XX if !DVB_FE_CUSTOMISE
 	help
 	  Support for cards based on the SDMC DM1105 PCI chip like
 	  DvbWorld 2002
linux/drivers/media/dvb/dm1105/dm1105.c +3 -4
diff -r 94bd2599004f -r 0ae7bbdb302e linux/drivers/media/dvb/dm1105/dm1105.c
@@ -40,8 +40,8 @@
 
 #include "stv0299.h"
 /*#include "stv0288.h"
- *#include "si21xx.h"
  *#include "stb6000.h"*/
+#include "si21xx.h"
 #include "cx24116.h"
 #include "z0194a.h"
 
@@ -608,12 +608,12 @@
 	.min_delay_ms = 100,
 };
 
+#endif /* keep */
 static struct si21xx_config serit_config = {
 	.demod_address = 0x68,
 	.min_delay_ms = 100,
 
 };
-#endif /* keep */
 
 static struct cx24116_config serit_sp2633_config = {
 	.demod_address = 0x55,
@@ -647,7 +647,7 @@
 						&dm1105dvb->i2c_adap);
 			}
 		}
-
+#endif /* keep */
 		if (!dm1105dvb->fe) {
 			dm1105dvb->fe = dvb_attach(
 				si21xx_attach, &serit_config,
@@ -656,7 +656,6 @@
 				dm1105dvb->fe->ops.set_voltage =
 							dm1105dvb_set_voltage;
 		}
-#endif /* keep */
 		break;
 	case PCI_DEVICE_ID_DW2004:
 		dm1105dvb->fe = dvb_attach(
linux/drivers/media/dvb/frontends/Kconfig +7 -0
diff -r 94bd2599004f -r 0ae7bbdb302e linux/drivers/media/dvb/frontends/Kconfig
@@ -98,6 +98,13 @@
 	default m if DVB_FE_CUSTOMISE
 	help
 	  A DVB-S/S2 tuner module. Say Y when you want to support this frontend.
+
+config DVB_SI21XX
+	tristate "Silicon Labs SI21XX based"
+	depends on DVB_CORE && I2C
+	default m if DVB_FE_CUSTOMISE
+	help
+	  A DVB-S tuner module. Say Y when you want to support this frontend.
 
 comment "DVB-T (terrestrial) frontends"
 	depends on DVB_CORE
linux/drivers/media/dvb/frontends/Makefile +1 -0
diff -r 94bd2599004f -r 0ae7bbdb302e linux/drivers/media/dvb/frontends/Makefile
@@ -50,3 +50,4 @@
 obj-$(CONFIG_DVB_S5H1411) += s5h1411.o
 obj-$(CONFIG_DVB_LGS8GL5) += lgs8gl5.o
 obj-$(CONFIG_DVB_CX24116) += cx24116.o
+obj-$(CONFIG_DVB_SI21XX) += si21xx.o
linux/drivers/media/dvb/frontends/si21xx.c new file +1049 -0

1,049 lines not on this page · raw message

linux/drivers/media/dvb/frontends/si21xx.h new file +37 -0
diff -r 94bd2599004f -r 0ae7bbdb302e linux/drivers/media/dvb/frontends/si21xx.h
@@ -0,0 +1,37 @@
+#ifndef SI21XX_H
+#define SI21XX_H
+
+#include <linux/dvb/frontend.h>
+#include "dvb_frontend.h"
+
+struct si21xx_config {
+	/* the demodulator's i2c address */
+	u8 demod_address;
+
+	/* minimum delay before retuning */
+	int min_delay_ms;
+};
+
+#if defined(CONFIG_DVB_SI21XX) || \
+		(defined(CONFIG_DVB_SI21XX_MODULE) && defined(MODULE))
+extern struct dvb_frontend *si21xx_attach(const struct si21xx_config *config,
+						struct i2c_adapter *i2c);
+#else
+static inline struct dvb_frontend *si21xx_attach(
+		const struct si21xx_config *config, struct i2c_adapter *i2c)
+{
+	printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
+	return NULL;
+}
+#endif
+
+static inline int si21xx_writeregister(struct dvb_frontend *fe, u8 reg, u8 val)
+{
+	int r = 0;
+	u8 buf[] = {reg, val};
+	if (fe->ops.write)
+		r = fe->ops.write(fe, buf, 2);
+	return r;
+}
+
+#endif

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#17 lore raw

Re: [linux-dvb] [PATCH] S2API - Add support for USB card modification with si2109/2110 demodulator.

В сообщении от 17 September 2008 00:37:59 Igor M. Liplianin написал(а):

Quoted 9 lines

Hi Steve,

Send you patch for Silicon Laboratories si2109/2110 demodulator support.

https://www.silabs.com/products/audiovideo/satellitestb/Pages/default.aspx

It is S2API compliant, as of september, 16-th

Igor

Add support for USB card modification with si2109/2110 demodulator. It is DvbWorld 2102 and TeVii s600 modification with Serit tuner.

Igor

# HG changeset patch
# User Igor M. Liplianin <[email protected]>
# Date 1221689959 -10800
# Node ID c34ef754e8e02a557b444f3a891d0293e12c2cf3
# Parent 4784f1dc5ad010b2a4c3938e1f732f9b40cca626
Add support for USB card modification with SI2109/2110 demodulator.

From: Igor M. Liplianin <[email protected]>

Add support for USB card modification with SI2109/2110 demodulator.

linux/drivers/media/dvb/dvb-usb/dw2102.c +173 -87
diff -r 4784f1dc5ad0 -r c34ef754e8e0 linux/drivers/media/dvb/dvb-usb/dw2102.c
@@ -11,6 +11,7 @@
 */
 #include <linux/version.h>
 #include "dw2102.h"
+#include "si21xx.h"
 #include "stv0299.h"
 #include "z0194a.h"
 #include "cx24116.h"
@@ -23,8 +24,8 @@
 #define USB_PID_DW2104 0x2104
 #endif
 
-#define DW2102_READ_MSG 0
-#define DW2102_WRITE_MSG 1
+#define DW210X_READ_MSG 0
+#define DW210X_WRITE_MSG 1
 
 #define REG_1F_SYMBOLRATE_BYTE0 0x1f
 #define REG_20_SYMBOLRATE_BYTE1 0x20
@@ -33,10 +34,10 @@
 #define DW2102_VOLTAGE_CTRL (0x1800)
 #define DW2102_RC_QUERY (0x1a00)
 
-struct dw2102_state {
+struct dw210x_state {
 	u32 last_key_pressed;
 };
-struct dw2102_rc_keys {
+struct dw210x_rc_keys {
 	u32 keycode;
 	u32 event;
 };
@@ -48,28 +49,27 @@
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
-static int dw2102_op_rw(struct usb_device *dev, u8 request, u16 value,
+static int dw210x_op_rw(struct usb_device *dev, u8 request, u16 value,
 			u16 index, u8 * data, u16 len, int flags)
 {
 	int ret;
 	u8 u8buf[len];
 
-	unsigned int pipe = (flags == DW2102_READ_MSG) ?
+	unsigned int pipe = (flags == DW210X_READ_MSG) ?
 				usb_rcvctrlpipe(dev, 0) : usb_sndctrlpipe(dev, 0);
-	u8 request_type = (flags == DW2102_READ_MSG) ? USB_DIR_IN : USB_DIR_OUT;
+	u8 request_type = (flags == DW210X_READ_MSG) ? USB_DIR_IN : USB_DIR_OUT;
 
-	if (flags == DW2102_WRITE_MSG)
+	if (flags == DW210X_WRITE_MSG)
 		memcpy(u8buf, data, len);
 	ret = usb_control_msg(dev, pipe, request, request_type | USB_TYPE_VENDOR,
 				value, index , u8buf, len, 2000);
 
-	if (flags == DW2102_READ_MSG)
+	if (flags == DW210X_READ_MSG)
 		memcpy(data, u8buf, len);
 	return ret;
 }
 
 /* I2C */
-
 static int dw2102_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
 		int num)
 {
@@ -89,10 +89,9 @@
 		value = msg[0].buf[0];/* register */
 		for (i = 0; i < msg[1].len; i++) {
 			value = value + i;
-			ret = dw2102_op_rw(d->udev, 0xb5, value, 0,
-					buf6, 2, DW2102_READ_MSG);
+			ret = dw210x_op_rw(d->udev, 0xb5, value, 0,
+					buf6, 2, DW210X_READ_MSG);
 			msg[1].buf[i] = buf6[0];
-
 		}
 		break;
 	case 1:
@@ -102,8 +101,8 @@
 			buf6[0] = 0x2a;
 			buf6[1] = msg[0].buf[0];
 			buf6[2] = msg[0].buf[1];
-			ret = dw2102_op_rw(d->udev, 0xb2, 0, 0,
-					buf6, 3, DW2102_WRITE_MSG);
+			ret = dw210x_op_rw(d->udev, 0xb2, 0, 0,
+					buf6, 3, DW210X_WRITE_MSG);
 			break;
 		case 0x60:
 			if (msg[0].flags == 0) {
@@ -115,29 +114,85 @@
 				buf6[4] = msg[0].buf[1];
 				buf6[5] = msg[0].buf[2];
 				buf6[6] = msg[0].buf[3];
-				ret = dw2102_op_rw(d->udev, 0xb2, 0, 0,
-						buf6, 7, DW2102_WRITE_MSG);
+				ret = dw210x_op_rw(d->udev, 0xb2, 0, 0,
+						buf6, 7, DW210X_WRITE_MSG);
 			} else {
 			/* read from tuner */
-				ret = dw2102_op_rw(d->udev, 0xb5, 0,0,
-						buf6, 1, DW2102_READ_MSG);
+				ret = dw210x_op_rw(d->udev, 0xb5, 0, 0,
+						buf6, 1, DW210X_READ_MSG);
 				msg[0].buf[0] = buf6[0];
 			}
 			break;
 		case (DW2102_RC_QUERY):
-			ret  = dw2102_op_rw(d->udev, 0xb8, 0, 0,
-					buf6, 2, DW2102_READ_MSG);
+			ret  = dw210x_op_rw(d->udev, 0xb8, 0, 0,
+					buf6, 2, DW210X_READ_MSG);
 			msg[0].buf[0] = buf6[0];
 			msg[0].buf[1] = buf6[1];
 			break;
 		case (DW2102_VOLTAGE_CTRL):
 			buf6[0] = 0x30;
 			buf6[1] = msg[0].buf[0];
-			ret = dw2102_op_rw(d->udev, 0xb2, 0, 0,
-					buf6, 2, DW2102_WRITE_MSG);
+			ret = dw210x_op_rw(d->udev, 0xb2, 0, 0,
+					buf6, 2, DW210X_WRITE_MSG);
 			break;
 		}
 
+		break;
+	}
+
+	mutex_unlock(&d->i2c_mutex);
+	return num;
+}
+
+static int dw2102_serit_i2c_transfer(struct i2c_adapter *adap,
+						struct i2c_msg msg[], int num)
+{
+	struct dvb_usb_device *d = i2c_get_adapdata(adap);
+	int ret = 0;
+	u8 buf6[] = {0, 0, 0, 0, 0, 0, 0};
+
+	if (!d)
+		return -ENODEV;
+	if (mutex_lock_interruptible(&d->i2c_mutex) < 0)
+		return -EAGAIN;
+
+	switch (num) {
+	case 2:
+		/* read si2109 register by number */
+		buf6[0] = 0xd0;
+		buf6[1] = msg[0].len;
+		buf6[2] = msg[0].buf[0];
+		ret = dw210x_op_rw(d->udev, 0xc2, 0, 0,
+				buf6, msg[0].len + 2, DW210X_WRITE_MSG);
+		/* read si2109 register */
+		ret = dw210x_op_rw(d->udev, 0xc3, 0xd0, 0,
+				buf6, msg[1].len + 2, DW210X_READ_MSG);
+		memcpy(msg[1].buf, buf6 + 2, msg[1].len);
+
+		break;
+	case 1:
+		switch (msg[0].addr) {
+		case 0x68:
+			/* write to si2109 register */
+			buf6[0] = 0xd0;
+			buf6[1] = msg[0].len;
+			memcpy(buf6 + 2, msg[0].buf, msg[0].len);
+			ret = dw210x_op_rw(d->udev, 0xc2, 0, 0, buf6,
+					msg[0].len + 2, DW210X_WRITE_MSG);
+			break;
+		case(DW2102_RC_QUERY):
+			ret  = dw210x_op_rw(d->udev, 0xb8, 0, 0,
+					buf6, 2, DW210X_READ_MSG);
+			msg[0].buf[0] = buf6[0];
+			msg[0].buf[1] = buf6[1];
+			break;
+		case(DW2102_VOLTAGE_CTRL):
+			buf6[0] = 0x30;
+			buf6[1] = msg[0].buf[0];
+			ret = dw210x_op_rw(d->udev, 0xb2, 0, 0,
+					buf6, 2, DW210X_WRITE_MSG);
+			break;
+		}
 		break;
 	}
 
@@ -164,11 +219,11 @@
 		obuf[0] = 0xaa;
 		obuf[1] = msg[0].len;
 		obuf[2] = msg[0].buf[0];
-		ret = dw2102_op_rw(d->udev, 0xc2, 0, 0,
-				obuf, msg[0].len + 2, DW2102_WRITE_MSG);
+		ret = dw210x_op_rw(d->udev, 0xc2, 0, 0,
+				obuf, msg[0].len + 2, DW210X_WRITE_MSG);
 		/* second read registers */
-		ret = dw2102_op_rw(d->udev, 0xc3, 0xab , 0,
-				ibuf, msg[1].len + 2, DW2102_READ_MSG);
+		ret = dw210x_op_rw(d->udev, 0xc3, 0xab , 0,
+				ibuf, msg[1].len + 2, DW210X_READ_MSG);
 		memcpy(msg[1].buf, ibuf + 2, msg[1].len);
 
 		break;
@@ -187,8 +242,8 @@
 				i = 1;
 				do {
 					memcpy(obuf + 3, msg[0].buf + i, (len > 16 ? 16 : len));
-					ret = dw2102_op_rw(d->udev, 0xc2, 0, 0,
-						obuf, (len > 16 ? 16 : len) + 3, DW2102_WRITE_MSG);
+					ret = dw210x_op_rw(d->udev, 0xc2, 0, 0,
+						obuf, (len > 16 ? 16 : len) + 3, DW210X_WRITE_MSG);
 					i += 16;
 					len -= 16;
 				} while (len > 0);
@@ -198,15 +253,15 @@
 				obuf[0] = 0xaa;
 				obuf[1] = msg[0].len;
 				memcpy(obuf + 2, msg[0].buf, msg[0].len);
-				ret = dw2102_op_rw(d->udev, 0xc2, 0, 0,
-						obuf, msg[0].len + 2, DW2102_WRITE_MSG);
+				ret = dw210x_op_rw(d->udev, 0xc2, 0, 0,
+						obuf, msg[0].len + 2, DW210X_WRITE_MSG);
 			}
 			break;
 		}
 		case(DW2102_RC_QUERY): {
 			u8 ibuf[2];
-			ret  = dw2102_op_rw(d->udev, 0xb8, 0, 0,
-					ibuf, 2, DW2102_READ_MSG);
+			ret  = dw210x_op_rw(d->udev, 0xb8, 0, 0,
+					ibuf, 2, DW210X_READ_MSG);
 			memcpy(msg[0].buf, ibuf , 2);
 			break;
 		}
@@ -214,8 +269,8 @@
 			u8 obuf[2];
 			obuf[0] = 0x30;
 			obuf[1] = msg[0].buf[0];
-			ret = dw2102_op_rw(d->udev, 0xb2, 0, 0,
-					obuf, 2, DW2102_WRITE_MSG);
+			ret = dw210x_op_rw(d->udev, 0xb2, 0, 0,
+					obuf, 2, DW210X_WRITE_MSG);
 			break;
 		}
 		}
@@ -227,29 +282,34 @@
 	return num;
 }
 
-static u32 dw2102_i2c_func(struct i2c_adapter *adapter)
+static u32 dw210x_i2c_func(struct i2c_adapter *adapter)
 {
 	return I2C_FUNC_I2C;
 }
 
 static struct i2c_algorithm dw2102_i2c_algo = {
 	.master_xfer = dw2102_i2c_transfer,
-	.functionality = dw2102_i2c_func,
+	.functionality = dw210x_i2c_func,
+};
+
+static struct i2c_algorithm dw2102_serit_i2c_algo = {
+	.master_xfer = dw2102_serit_i2c_transfer,
+	.functionality = dw210x_i2c_func,
 };
 
 static struct i2c_algorithm dw2104_i2c_algo = {
 	.master_xfer = dw2104_i2c_transfer,
-	.functionality = dw2102_i2c_func,
+	.functionality = dw210x_i2c_func,
 };
 
-static int dw2102_read_mac_address(struct dvb_usb_device *d, u8 mac[6])
+static int dw210x_read_mac_address(struct dvb_usb_device *d, u8 mac[6])
 {
 	int i;
 	u8 ibuf[] = {0, 0};
 	u8 eeprom[256], eepromline[16];
 
 	for (i = 0; i < 256; i++) {
-		if (dw2102_op_rw(d->udev, 0xb6, 0xa0 , i, ibuf, 2, DW2102_READ_MSG) < 0) {
+		if (dw210x_op_rw(d->udev, 0xb6, 0xa0 , i, ibuf, 2, DW210X_READ_MSG) < 0) {
 			err("read eeprom failed.");
 			return -1;
 		} else {
@@ -265,7 +325,7 @@
 	return 0;
 };
 
-static int dw2102_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
+static int dw210x_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
 {
 	static u8 command_13v[1] = {0x00};
 	static u8 command_18v[1] = {0x01};
@@ -287,25 +347,46 @@
 	.mpg_clk_pos_pol = 0x01,
 };
 
+static struct si21xx_config serit_sp1511lhb_config = {
+	.demod_address = 0x68,
+	.min_delay_ms = 100,
+
+};
+
 static int dw2104_frontend_attach(struct dvb_usb_adapter *d)
 {
 	if ((d->fe = dvb_attach(cx24116_attach, &dw2104_config,
 			&d->dev->i2c_adap)) != NULL) {
-		d->fe->ops.set_voltage = dw2102_set_voltage;
+		d->fe->ops.set_voltage = dw210x_set_voltage;
 		info("Attached cx24116!\n");
 		return 0;
 	}
 	return -EIO;
 }
 
+static struct dvb_usb_device_properties dw2102_properties;
+
 static int dw2102_frontend_attach(struct dvb_usb_adapter *d)
 {
-	d->fe = dvb_attach(stv0299_attach, &sharp_z0194a_config,
-		&d->dev->i2c_adap);
-	if (d->fe != NULL) {
-		d->fe->ops.set_voltage = dw2102_set_voltage;
-		info("Attached stv0299!\n");
-		return 0;
+	if (dw2102_properties.i2c_algo == &dw2102_serit_i2c_algo) {
+		/*dw2102_properties.adapter->tuner_attach = NULL;*/
+		d->fe = dvb_attach(si21xx_attach, &serit_sp1511lhb_config,
+					&d->dev->i2c_adap);
+		if (d->fe != NULL) {
+			d->fe->ops.set_voltage = dw210x_set_voltage;
+			info("Attached si21xx!\n");
+			return 0;
+		}
+	}
+	if (dw2102_properties.i2c_algo == &dw2102_i2c_algo) {
+		/*dw2102_properties.adapter->tuner_attach = dw2102_tuner_attach;*/
+		d->fe = dvb_attach(stv0299_attach, &sharp_z0194a_config,
+					&d->dev->i2c_adap);
+		if (d->fe != NULL) {
+			d->fe->ops.set_voltage = dw210x_set_voltage;
+			info("Attached stv0299!\n");
+			return 0;
+		}
 	}
 	return -EIO;
 }
@@ -317,7 +398,7 @@
 	return 0;
 }
 
-static struct dvb_usb_rc_key dw2102_rc_keys[] = {
+static struct dvb_usb_rc_key dw210x_rc_keys[] = {
 	{ 0xf8,	0x0a, KEY_Q },		/*power*/
 	{ 0xf8,	0x0c, KEY_M },		/*mute*/
 	{ 0xf8,	0x11, KEY_1 },
@@ -356,7 +437,7 @@
 
 static int dw2102_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
 {
-	struct dw2102_state *st = d->priv;
+	struct dw210x_state *st = d->priv;
 	u8 key[2];
 	struct i2c_msg msg[] = {
 		{.addr = DW2102_RC_QUERY, .flags = I2C_M_RD, .buf = key,
@@ -366,12 +447,12 @@
 
 	*state = REMOTE_NO_KEY_PRESSED;
 	if (dw2102_i2c_transfer(&d->i2c_adap, msg, 1) == 1) {
-		for (i = 0; i < ARRAY_SIZE(dw2102_rc_keys); i++) {
-			if (dw2102_rc_keys[i].data == msg[0].buf[0]) {
+		for (i = 0; i < ARRAY_SIZE(dw210x_rc_keys); i++) {
+			if (dw210x_rc_keys[i].data == msg[0].buf[0]) {
 				*state = REMOTE_KEY_PRESSED;
-				*event = dw2102_rc_keys[i].event;
+				*event = dw210x_rc_keys[i].event;
 				st->last_key_pressed =
-					dw2102_rc_keys[i].event;
+					dw210x_rc_keys[i].event;
 				break;
 			}
 		st->last_key_pressed = 0;
@@ -418,15 +499,15 @@
 	p = kmalloc(fw->size, GFP_KERNEL);
 	reset = 1;
 	/*stop the CPU*/
-	dw2102_op_rw(dev, 0xa0, 0x7f92, 0, &reset, 1, DW2102_WRITE_MSG);
-	dw2102_op_rw(dev, 0xa0, 0xe600, 0, &reset, 1, DW2102_WRITE_MSG);
+	dw210x_op_rw(dev, 0xa0, 0x7f92, 0, &reset, 1, DW210X_WRITE_MSG);
+	dw210x_op_rw(dev, 0xa0, 0xe600, 0, &reset, 1, DW210X_WRITE_MSG);
 
 	if (p != NULL) {
 		memcpy(p, fw->data, fw->size);
 		for (i = 0; i < fw->size; i += 0x40) {
 			b = (u8 *) p + i;
-			if (dw2102_op_rw(dev, 0xa0, i, 0, b , 0x40,
-					DW2102_WRITE_MSG) != 0x40) {
+			if (dw210x_op_rw(dev, 0xa0, i, 0, b , 0x40,
+					DW210X_WRITE_MSG) != 0x40) {
 				err("error while transferring firmware");
 				ret = -EINVAL;
 				break;
@@ -434,13 +515,13 @@
 		}
 		/* restart the CPU */
 		reset = 0;
-		if (ret || dw2102_op_rw(dev, 0xa0, 0x7f92, 0, &reset, 1,
-					DW2102_WRITE_MSG) != 1) {
+		if (ret || dw210x_op_rw(dev, 0xa0, 0x7f92, 0, &reset, 1,
+					DW210X_WRITE_MSG) != 1) {
 			err("could not restart the USB controller CPU.");
 			ret = -EINVAL;
 		}
-		if (ret || dw2102_op_rw(dev, 0xa0, 0xe600, 0, &reset, 1,
-					DW2102_WRITE_MSG) != 1) {
+		if (ret || dw210x_op_rw(dev, 0xa0, 0xe600, 0, &reset, 1,
+					DW210X_WRITE_MSG) != 1) {
 			err("could not restart the USB controller CPU.");
 			ret = -EINVAL;
 		}
@@ -449,27 +530,32 @@
 		case USB_PID_DW2104:
 		case 0xd650:
 			reset = 1;
-			dw2102_op_rw(dev, 0xc4, 0x0000, 0, &reset, 1,
-					DW2102_WRITE_MSG);
+			dw210x_op_rw(dev, 0xc4, 0x0000, 0, &reset, 1,
+					DW210X_WRITE_MSG);
 			reset = 0;
-			dw2102_op_rw(dev, 0xbf, 0x0040, 0, &reset, 0,
-					DW2102_WRITE_MSG);
+			dw210x_op_rw(dev, 0xbf, 0x0040, 0, &reset, 0,
+					DW210X_WRITE_MSG);
 			break;
 		case USB_PID_DW2102:
-			dw2102_op_rw(dev, 0xbf, 0x0040, 0, &reset, 0,
-					DW2102_WRITE_MSG);
-			dw2102_op_rw(dev, 0xb9, 0x0000, 0, &reset16[0], 2,
-					DW2102_READ_MSG);
+			dw210x_op_rw(dev, 0xbf, 0x0040, 0, &reset, 0,
+					DW210X_WRITE_MSG);
+			dw210x_op_rw(dev, 0xb9, 0x0000, 0, &reset16[0], 2,
+					DW210X_READ_MSG);
+			/* check STV0299 frontend  */
+			dw210x_op_rw(dev, 0xb5, 0, 0, &reset16[0], 2,
+					DW210X_READ_MSG);
+			if (reset16[0] == 0xa1)
+				dw2102_properties.i2c_algo = &dw2102_i2c_algo;
 			break;
 		case 0x2101:
-			dw2102_op_rw(dev, 0xbc, 0x0030, 0, &reset16[0], 2,
-					DW2102_READ_MSG);
-			dw2102_op_rw(dev, 0xba, 0x0000, 0, &reset16[0], 7,
-					DW2102_READ_MSG);
-			dw2102_op_rw(dev, 0xba, 0x0000, 0, &reset16[0], 7,
-					DW2102_READ_MSG);
-			dw2102_op_rw(dev, 0xb9, 0x0000, 0, &reset16[0], 2,
-					DW2102_READ_MSG);
+			dw210x_op_rw(dev, 0xbc, 0x0030, 0, &reset16[0], 2,
+					DW210X_READ_MSG);
+			dw210x_op_rw(dev, 0xba, 0x0000, 0, &reset16[0], 7,
+					DW210X_READ_MSG);
+			dw210x_op_rw(dev, 0xba, 0x0000, 0, &reset16[0], 7,
+					DW210X_READ_MSG);
+			dw210x_op_rw(dev, 0xb9, 0x0000, 0, &reset16[0], 2,
+					DW210X_READ_MSG);
 			break;
 		}
 		msleep(100);
@@ -482,12 +568,12 @@
 	.caps = DVB_USB_IS_AN_I2C_ADAPTER,
 	.usb_ctrl = DEVICE_SPECIFIC,
 	.firmware = "dvb-usb-dw2102.fw",
-	.size_of_priv = sizeof(struct dw2102_state),
+	.size_of_priv = sizeof(struct dw210x_state),
 	.no_reconnect = 1,
 
-	.i2c_algo = &dw2102_i2c_algo,
-	.rc_key_map = dw2102_rc_keys,
-	.rc_key_map_size = ARRAY_SIZE(dw2102_rc_keys),
+	.i2c_algo = &dw2102_serit_i2c_algo,
+	.rc_key_map = dw210x_rc_keys,
+	.rc_key_map_size = ARRAY_SIZE(dw210x_rc_keys),
 	.rc_interval = 150,
 	.rc_query = dw2102_rc_query,
 
@@ -495,7 +581,7 @@
 	/* parameter for the MPEG2-data transfer */
 	.num_adapters = 1,
 	.download_firmware = dw2102_load_firmware,
-	.read_mac_address = dw2102_read_mac_address,
+	.read_mac_address = dw210x_read_mac_address,
 		.adapter = {
 		{
 			.frontend_attach = dw2102_frontend_attach,
@@ -530,12 +616,12 @@
 	.caps = DVB_USB_IS_AN_I2C_ADAPTER,
 	.usb_ctrl = DEVICE_SPECIFIC,
 	.firmware = "dvb-usb-dw2104.fw",
-	.size_of_priv = sizeof(struct dw2102_state),
+	.size_of_priv = sizeof(struct dw210x_state),
 	.no_reconnect = 1,
 
 	.i2c_algo = &dw2104_i2c_algo,
-	.rc_key_map = dw2102_rc_keys,
-	.rc_key_map_size = ARRAY_SIZE(dw2102_rc_keys),
+	.rc_key_map = dw210x_rc_keys,
+	.rc_key_map_size = ARRAY_SIZE(dw210x_rc_keys),
 	.rc_interval = 150,
 	.rc_query = dw2102_rc_query,
 
@@ -543,7 +629,7 @@
 	/* parameter for the MPEG2-data transfer */
 	.num_adapters = 1,
 	.download_firmware = dw2102_load_firmware,
-	.read_mac_address = dw2102_read_mac_address,
+	.read_mac_address = dw210x_read_mac_address,
 	.adapter = {
 		{
 			.frontend_attach = dw2104_frontend_attach,

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

author Applied
#18 lore raw

Re: [linux-dvb] [PATCH] S2API - Add support for USB card modification with si2109/2110 demodulator.

Quoted 5 lines · Igor M. Liplianin

В сообщении от 17 September 2008 00:37:59 Igor M. Liplianin написал(а):

Quoted 4 lines

Hi Steve,

Send you patch for Silicon Laboratories si2109/2110 demodulator support.

Quoted 8 lines
Quoted 5 lines

https://www.silabs.com/products/audiovideo/satellitestb/Pages/default.aspx

It is S2API compliant, as of september, 16-th

Igor

Add support for USB card modification with si2109/2110 demodulator. It is DvbWorld 2102 and TeVii s600 modification with Serit tuner.

Merged, thanks.

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

author Applied
#19 lore raw

Re: [linux-dvb] [PATCH] S2API - Silicon Labs si2109/2110 demodulator support.

In reply to Igor M. Liplianin
Quoted 10 lines · Igor M. Liplianin

Hi Steve,

Send you patch for Silicon Laboratories si2109/2110 demodulator support.

https://www.silabs.com/products/audiovideo/satellitestb/Pages/default.aspx

It is S2API compliant, as of september, 16-th

Igor

Merged, thanks.

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#20 lore raw

PATCH 1/1 S2API - ST stv0288 demodulator support.

In reply to Igor M. Liplianin

Hi,

Send patch for ST stv0288 demodulator support.
Also stb6000 tuner, DvbWorld DW2002 PCI modification with Earda tuner, TeVii s420 PCI cards.
It is S2API compliant ( single frontend )
If somebody have any objections, let me know

Igor

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#21 lore raw

Re: [linux-dvb] [PATCH] S2API - ST stv0288 demodulator support.

В сообщении от 23 September 2008 22:01:06 Igor M. Liplianin написал(а):

Quoted 8 lines

Hi,

Send patch for ST stv0288 demodulator support.
Also stb6000 tuner, DvbWorld DW2002 PCI modification with Earda tuner, TeVii s420 PCI cards.
It is S2API compliant ( single frontend )
If somebody have any objections, let me know

Quoted 6 lines

Igor

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Forget attachment
Need more sleep :-)

Igor

# HG changeset patch
# User Igor M. Liplianin <[email protected]>
# Date 1222195437 -10800
# Node ID ed6ca1a375d437fc57c29decf0a00199795a3e1e # Parent 368768bafa198a07f8ad0c5ee0368f4e58dbf9ba Add support for ST STV0288 demodulator and cards with it.

From: Georg Acher <[email protected]>
From: Igor M. Liplianin <[email protected]>

Add support for ST STV0288 demodulator and cards with it, such as TeVii S420.

Signed-off by: Georg Acher <[email protected]>

linux/drivers/media/dvb/dm1105/dm1105.c +5 -6
diff -r 368768bafa19 -r ed6ca1a375d4 linux/drivers/media/dvb/dm1105/dm1105.c
@@ -39,8 +39,8 @@
 #include "dvb-pll.h"
 
 #include "stv0299.h"
-/*#include "stv0288.h"
- *#include "stb6000.h"*/
+#include "stv0288.h"
+#include "stb6000.h"
 #include "si21xx.h"
 #include "cx24116.h"
 #include "z0194a.h"
@@ -602,13 +602,12 @@
 
 	dm1105dvb_dma_unmap(dm1105dvb);
 }
-#if 0 /* keep */
+
 static struct stv0288_config earda_config = {
 	.demod_address = 0x68,
 	.min_delay_ms = 100,
 };
 
-#endif /* keep */
 static struct si21xx_config serit_config = {
 	.demod_address = 0x68,
 	.min_delay_ms = 100,
@@ -635,7 +634,7 @@
 			dvb_attach(dvb_pll_attach, dm1105dvb->fe, 0x60,
 					&dm1105dvb->i2c_adap, DVB_PLL_OPERA1);
 		}
-#if 0 /* keep */
+
 		if (!dm1105dvb->fe) {
 			dm1105dvb->fe = dvb_attach(
 				stv0288_attach, &earda_config,
@@ -647,7 +646,7 @@
 						&dm1105dvb->i2c_adap);
 			}
 		}
-#endif /* keep */
+
 		if (!dm1105dvb->fe) {
 			dm1105dvb->fe = dvb_attach(
 				si21xx_attach, &serit_config,
linux/drivers/media/dvb/frontends/Kconfig +14 -0
diff -r 368768bafa19 -r ed6ca1a375d4 linux/drivers/media/dvb/frontends/Kconfig
@@ -42,6 +42,20 @@
 	default m if DVB_FE_CUSTOMISE
 	help
 	  A DVB-S tuner module. Say Y when you want to support this frontend.
+
+config DVB_STV0288
+	tristate "ST STV0288 based"
+	depends on DVB_CORE && I2C
+	default m if DVB_FE_CUSTOMISE
+	help
+	  A DVB-S tuner module. Say Y when you want to support this frontend.                  
+
+config DVB_STB6000
+	tristate "ST STB6000 silicon tuner"
+	depends on DVB_CORE && I2C
+	default m if DVB_FE_CUSTOMISE
+	  help
+	  A DVB-S silicon tuner module. Say Y when you want to support this tuner.
 
 config DVB_STV0299
 	tristate "ST STV0299 based"
linux/drivers/media/dvb/frontends/Makefile +2 -0
diff -r 368768bafa19 -r ed6ca1a375d4 linux/drivers/media/dvb/frontends/Makefile
@@ -51,3 +51,5 @@
 obj-$(CONFIG_DVB_LGS8GL5) += lgs8gl5.o
 obj-$(CONFIG_DVB_CX24116) += cx24116.o
 obj-$(CONFIG_DVB_SI21XX) += si21xx.o
+obj-$(CONFIG_DVB_STV0299) += stv0288.o
+obj-$(CONFIG_DVB_STB6000) += stb6000.o
linux/drivers/media/dvb/frontends/stb6000.c new file +255 -0

255 lines not on this page · raw message

linux/drivers/media/dvb/frontends/stb6000.h new file +51 -0

51 lines not on this page · raw message

linux/drivers/media/dvb/frontends/stv0288.c new file +606 -0

606 lines not on this page · raw message

linux/drivers/media/dvb/frontends/stv0288.h new file +65 -0

65 lines not on this page · raw message

linux/drivers/media/dvb/frontends/stv0299.c +2 -0
diff -r 368768bafa19 -r ed6ca1a375d4 linux/drivers/media/dvb/frontends/stv0299.c
@@ -559,6 +559,8 @@
 	int invval = 0;
 
 	dprintk ("%s : FE_SET_FRONTEND\n", __func__);
+	if (state->config->set_ts_params)
+		state->config->set_ts_params(fe, 0);
 
 	// set the inversion
 	if (p->inversion == INVERSION_OFF) invval = 0;
linux/drivers/media/dvb/frontends/stv0299.h +8 -5
diff -r 368768bafa19 -r ed6ca1a375d4 linux/drivers/media/dvb/frontends/stv0299.h
@@ -89,15 +89,18 @@
 	int min_delay_ms;
 
 	/* Set the symbol rate */
-	int (*set_symbol_rate)(struct dvb_frontend* fe, u32 srate, u32 ratio);
+	int (*set_symbol_rate)(struct dvb_frontend *fe, u32 srate, u32 ratio);
+
+	/* Set device param to start dma */
+	int (*set_ts_params)(struct dvb_frontend *fe, int is_punctured);
 };
 
 #if defined(CONFIG_DVB_STV0299) || (defined(CONFIG_DVB_STV0299_MODULE) && defined(MODULE))
-extern struct dvb_frontend* stv0299_attach(const struct stv0299_config* config,
-					   struct i2c_adapter* i2c);
+extern struct dvb_frontend *stv0299_attach(const struct stv0299_config *config,
+					   struct i2c_adapter *i2c);
 #else
-static inline struct dvb_frontend* stv0299_attach(const struct stv0299_config* config,
-					   struct i2c_adapter* i2c)
+static inline struct dvb_frontend *stv0299_attach(const struct stv0299_config *config,
+					   struct i2c_adapter *i2c)
 {
 	printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
 	return NULL;
linux/drivers/media/video/cx88/Kconfig +3 -0
diff -r 368768bafa19 -r ed6ca1a375d4 linux/drivers/media/video/cx88/Kconfig
@@ -59,6 +59,9 @@
 	select MEDIA_TUNER_SIMPLE if !DVB_FE_CUSTOMISE
 	select DVB_S5H1411 if !DVB_FE_CUSTOMISE
 	select DVB_CX24116 if !DVB_FE_CUSTOMISE
+	select DVB_STV0299 if !DVB_FE_CUSTOMISE
+	select DVB_STV0288 if !DVB_FE_CUSTOMISE
+	select DVB_STB6000 if !DVB_FE_CUSTOMISE
 	---help---
 	  This adds support for DVB/ATSC cards based on the
 	  Conexant 2388x chip.
linux/drivers/media/video/cx88/cx88-cards.c +18 -1
diff -r 368768bafa19 -r ed6ca1a375d4 linux/drivers/media/video/cx88/cx88-cards.c
@@ -1769,6 +1769,18 @@
 		} },
 		.mpeg           = CX88_MPEG_DVB,
 	},
+	[CX88_BOARD_TEVII_S420] = {
+		.name           = "TeVii S420 DVB-S",
+		.tuner_type     = UNSET,
+		.radio_type     = UNSET,
+		.tuner_addr     = ADDR_UNSET,
+		.radio_addr     = ADDR_UNSET,
+		.input          = {{
+			.type   = CX88_VMUX_DVB,
+			.vmux   = 0,
+		} },
+		.mpeg           = CX88_MPEG_DVB,
+	},
 	[CX88_BOARD_TEVII_S460] = {
 		.name           = "TeVii S460 DVB-S/S2",
 		.tuner_type     = UNSET,
@@ -2175,7 +2187,11 @@
 		.subdevice = 0x6906,
 		.card      = CX88_BOARD_HAUPPAUGE_HVR4000LITE,
 	}, {
-		.subvendor = 0xD460,
+		.subvendor = 0xd420,
+		.subdevice = 0x9022,
+		.card      = CX88_BOARD_TEVII_S420,
+	}, {
+		.subvendor = 0xd460,
 		.subdevice = 0x9022,
 		.card      = CX88_BOARD_TEVII_S460,
 	}, {
@@ -2767,6 +2783,7 @@
 		cx88_call_i2c_clients(core, TUNER_SET_CONFIG, &tea5767_cfg);
 		break;
 	}
+	case  CX88_BOARD_TEVII_S420:
 	case  CX88_BOARD_TEVII_S460:
 		cx_write(MO_SRST_IO, 0);
 		msleep(100);
linux/drivers/media/video/cx88/cx88-dvb.c +48 -0

66 lines not on this page · raw message

linux/drivers/media/video/cx88/cx88.h +1 -0
diff -r 368768bafa19 -r ed6ca1a375d4 linux/drivers/media/video/cx88/cx88.h
@@ -227,6 +227,7 @@
 #define CX88_BOARD_TEVII_S460              70
 #define CX88_BOARD_OMICOM_SS4_PCI          71
 #define CX88_BOARD_TBS_8920                72
+#define CX88_BOARD_TEVII_S420              73
 
 enum cx88_itype {
 	CX88_VMUX_COMPOSITE1 = 1,

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#22 lore raw

Re: [linux-dvb] [PATCH] S2API - ST stv0288 demodulator support.

Quoted 11 lines · Igor M. Liplianin

В сообщении от 23 September 2008 22:01:06 Igor M. Liplianin написал(а):

Quoted 10 lines

Hi,

Send patch for ST stv0288 demodulator support.
Also stb6000 tuner, DvbWorld DW2002 PCI modification with Earda tuner, TeVii s420 PCI cards.
It is S2API compliant ( single frontend )
If somebody have any objections, let me know

Igor

Quoted 7 lines
Quoted 4 lines

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Forget attachment
Need more sleep :-)

Thanks Igor, I'll look at this tonight.

Regards,

Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

author Applied
#23 lore raw

Re: [linux-dvb] [PATCH] S2API - ST stv0288 demodulator support.

In reply to Igor M. Liplianin
Quoted 11 lines · Igor M. Liplianin

В сообщении от 23 September 2008 22:01:06 Igor M. Liplianin написал(а):

Quoted 10 lines

Hi,

Send patch for ST stv0288 demodulator support.
Also stb6000 tuner, DvbWorld DW2002 PCI modification with Earda tuner, TeVii s420 PCI cards.
It is S2API compliant ( single frontend )
If somebody have any objections, let me know

Igor

Quoted 7 lines
Quoted 4 lines

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Forget attachment
Need more sleep :-)

Merged, thanks.

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#24 lore raw

PATCH 1/1 S2API - Kconfig dependency fixes for cards with stv0288 and si21xx.

In reply to Igor M. Liplianin

Hi,

Patches for Kconfig dependencies for cards with stv0288 and si21xx.

Thanks to Patrick for paying attention.

Igor

# HG changeset patch
# User Igor M. Liplianin <[email protected]>
# Date 1222307333 -10800
# Node ID 8de73c0adc5dee549fd7f9d34f80a2ee40ae347e
# Parent 70b18ec9535dc884fb0e9ff9456aa4f79df14921
Kconfig correction for USB card modification with SI2109/2110 demodulator.

From: Igor M. Liplianin <[email protected]>

Kconfig correction for USB card modification with SI2109/2110 demodulator.

linux/drivers/media/dvb/dvb-usb/Kconfig +1 -0
diff -r 70b18ec9535d -r 8de73c0adc5d linux/drivers/media/dvb/dvb-usb/Kconfig
@@ -252,6 +252,7 @@
 	select DVB_PLL if !DVB_FE_CUSTOMISE
 	select DVB_STV0299 if !DVB_FE_CUSTOMISE
 	select DVB_CX24116 if !DVB_FE_CUSTOMISE
+	select DVB_SI21XX if !DVB_FE_CUSTOMISE
 	help
 	  Say Y here to support the DvbWorld DVB-S/S2 USB2.0 receivers
 	  and the TeVii S650.

# HG changeset patch
# User Igor M. Liplianin <[email protected]>
# Date 1222309107 -10800
# Node ID 5a8329f6c66c8c9a8852245f473ca577a92c602f
# Parent 8de73c0adc5dee549fd7f9d34f80a2ee40ae347e Kconfig dependency fix for DW2002 card with ST STV0288 demodulator.

From: Igor M. Liplianin <[email protected]>

Kconfig dependency fix for DW2002 card with ST STV0288 demodulator.

linux/drivers/media/dvb/dm1105/Kconfig +2 -0
diff -r 8de73c0adc5d -r 5a8329f6c66c linux/drivers/media/dvb/dm1105/Kconfig
@@ -3,6 +3,8 @@
 	depends on DVB_CORE && PCI && I2C
 	select DVB_PLL if !DVB_FE_CUSTOMISE
 	select DVB_STV0299 if !DVB_FE_CUSTOMISE
+	select DVB_STV0288 if !DVB_FE_CUSTOMISE
+	select DVB_STB6000 if !DVB_FE_CUSTOMISE
 	select DVB_CX24116 if !DVB_FE_CUSTOMISE
 	select DVB_SI21XX if !DVB_FE_CUSTOMISE
 	help

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#25 lore raw
In reply to Christophe Thommeret
Quoted 11 lines · Christophe Thommeret

Le Sunday 14 September 2008 20:04:06 Christophe Thommeret, vous avez écrit :

Quoted 7 lines

as you expected, it's abit buggy and crashes at load ;) i've searched for the alternative cinergyT2 driver. it's available at: http://linuxtv.org/hg/~tmerle/cinergyT2/

haven't tried it yet but will do (at least several people seems to have it working).

Have it working, not as good as Holger' one (often fails to lock) but it works, with both old and new api.

Looking at the code, cinergyt2_fe_get_tune_settings() should probably set step_size = max_drift = 0 to defeat dvb_frontend_swzigzag_autotune().
c.f. mt352_get_tune_settings()

HTH,
Johannes

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#26 lore raw

Le Monday 15 September 2008 13:43:00 Johannes Stezenbach, vous avez écrit :

Quoted 2 lines · Christophe Thommeret
Quoted 1 line

Le Sunday 14 September 2008 20:04:06 Christophe Thommeret, vous avez

écrit :

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines

as you expected, it's abit buggy and crashes at load ;) i've searched for the alternative cinergyT2 driver. it's available at: http://linuxtv.org/hg/~tmerle/cinergyT2/

haven't tried it yet but will do (at least several people seems to have it working).

Quoted 7 lines
Quoted 2 lines

Have it working, not as good as Holger' one (often fails to lock) but it works, with both old and new api.

Looking at the code, cinergyt2_fe_get_tune_settings() should probably set step_size = max_drift = 0 to defeat dvb_frontend_swzigzag_autotune().
c.f. mt352_get_tune_settings()

Thanx for the hint, unfortunately it doesn't help.
In fact, if i set a larger timeout (time after which kaffeine gives up and report tuning failure), say 5000ms, it always locks.
The average lock time is about 2000ms, but sometimes it goes up to 4000 and sometimes it's only 200, randomly for all freqs.
If you have any idea, you are welcome :)

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#27 lore raw
Quoted 18 lines · Christophe Thommeret

Le Monday 15 September 2008 13:43:00 Johannes Stezenbach, vous avez écrit :

Quoted 9 lines · Christophe Thommeret
Quoted 8 lines

Le Sunday 14 September 2008 20:04:06 Christophe Thommeret, vous avez écrit :

Quoted 6 lines

as you expected, it's abit buggy and crashes at load ;) i've searched for the alternative cinergyT2 driver. it's available at: http://linuxtv.org/hg/~tmerle/cinergyT2/

haven't tried it yet but will do (at least several people seems to have it working).

Quoted 7 lines
Quoted 2 lines

Have it working, not as good as Holger' one (often fails to lock) but it works, with both old and new api.

Looking at the code, cinergyt2_fe_get_tune_settings() should probably set step_size = max_drift = 0 to defeat dvb_frontend_swzigzag_autotune().
c.f. mt352_get_tune_settings()

Quoted 6 lines

Thanx for the hint, unfortunately it doesn't help.
In fact, if i set a larger timeout (time after which kaffeine gives up and report tuning failure), say 5000ms, it always locks.
The average lock time is about 2000ms, but sometimes it goes up to 4000 and sometimes it's only 200, randomly for all freqs.
If you have any idea, you are welcome :)

Not really and I can't test myself since I don't have any hw.

Holger's cinergyT2 driver sets the FE once (on FE_SET_FRONTEND),
and then queries regularly (every 333ms or CONFIG_DVB_CINERGYT2_QUERY_INTERVAL) for the status. It NEVER retries the tuning like dvb_frontend_swzigzag_autotune() might do, and the step_size = max_drift = 0 is supposed to prevent that, but maybe dvb_frontend_swzigzag_autotune() logic is broken?
A printk in the new cinergyT2 driver should tell.

BTW, the cinergyT2 firmware is Open Source, you can find it in
http://linuxtv.org/cgi-bin/viewcvs.cgi/dvb-hw/dvbusb-fx2/termini/
if you are interested. But there is no magic in the firmware, it just writes mt352 regs on FE_SET_FRONTEND and reads the status reg for FE_READ_STATUS. That's all.

Johannes

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#28 lore raw

[linux-dvb] Siano ISDB [was: Re: S2API - Status - Thu Sep 11th]

In reply to Steven Toth
Quoted 4 lines · Steven Toth

mkrufky spent some time adding S2API isdb-t support to the siano driver, that's working pretty well - tuning via the S2API app.

http://linuxtv.org/hg/~mkrufky/sms1xxx-isdbt-as-dvbt/

Just a first quick feedback, the following will need to be frobbed appropriately:

    204         if (id < DEVICE_MODE_DVBT || id > DEVICE_MODE_DVBT_BDA) {
    205                 sms_err("invalid firmware id specified %d", id);
    206                 return -EINVAL;

In order to enable ISDB modes, one will need to specify module parameter `default_mode=5' or =6, whichever, and, hmmm, looks like I gotta hunt down a firmware too.

Is one or the other mode, that is, BDA driver or not, to be preferred?

Obviously I can't receive anything.

Other comments may appear in personal mail to mkrufky, unless I should keep them here, I think...

thanks,
barry bouwsma

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#30 lore raw

Re: [linux-dvb] Siano ISDB

Quoted 9 lines · barry bouwsma

From: barry bouwsma <[email protected]>
Subject: Re: [linux-dvb] Siano ISDB
To: "linux-dvb" <[email protected]>
Date: Friday, September 12, 2008, 11:24 AM
--- On Fri, 9/12/08, barry bouwsma

Quoted 1 line · <[email protected]> wrote:

hmmm, looks like I gotta hunt down a firmware too.

Quoted 9 lines

Actually, just ignore me. Looks like the SMS1000 chip in my
device doesn't support ISDB (only DAB-related and DVB-T-related)

sorry,
barry bouwsma

True. SMS10xx doesn't support ISDB-T.
Only 11xx and 12xx support it.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

A message that is not in the archive (sent off-list or not yet received): [email protected]

#32 lore raw

Re: [linux-dvb] Siano ISDB [was: Re: S2API - Status - Thu Sep 11th]

Quoted 5 lines · Steven Toth
Quoted 2 lines

module parameter `default_mode=5' or =6,

Correct, that tree expects a module option to load the firmware, you might want to check this code snippet in the other tree. The other detects the delivery system and reloads the firmware on the fly.

Hey, no fair, I think you're answering questions I'm about to ask before I can send them!

Oh heck, here's what I wrote a short while ago, just in case...

=-=#=-=#=-=

In looking at the S2API code for the Siano chipsets, I had a question which I couldn't answer by reading the code.

At present, my card supports DVB-T by default, and I can load a different firmware to get it to (potentially) support alternatives, say, DVB-H.

The answer might be blindingly obvious, but I don't see if this card has the capability of saying, okay, I can give you DVB-T, or DVB-H, or DAB, or T-DMB... Right now, I spit DVB-T. Then an application wanting DVB-H would then be able to initiate a reload of the firmware, and the device would reappear as a DVB-H device.

The ability to do this firmware switch seems to be present within the driver, but I'm wondering if the S2API, or indeed the present APIs, can handle a case like this.

I know that `mplayer' will grab the first available device of the appropriate standard, while my other applications pick a fixed adapter number (or more correctly, device by product). But I can see myself wanting to make both DVB-T and DAB (eventually) use of this one device, without the bother of reloading the kernel module to switch.

I did spend the night looking at the old API, and remember virtually none of it, and the discussion of multifrontend devices and what they mean has made me wonder about this...

thanks,
barry bouwsma

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#33 lore raw

Re: [linux-dvb] Siano ISDB [was: Re: S2API - Status - Thu Sep 11th]

Quoted 10 lines · barry bouwsma
Quoted 5 lines · Steven Toth
Quoted 2 lines

module parameter `default_mode=5' or =6,

Correct, that tree expects a module option to load the firmware, you might want to check this code snippet in the other tree. The other detects the delivery system and reloads the firmware on the fly.

Hey, no fair, I think you're answering questions I'm about to ask before I can send them!

:)

Quoted 19 lines

Oh heck, here's what I wrote a short while ago, just in case...

=-=#=-=#=-=

In looking at the S2API code for the Siano chipsets, I had a question which I couldn't answer by reading the code.

At present, my card supports DVB-T by default, and I can load a different firmware to get it to (potentially) support alternatives, say, DVB-H.

The answer might be blindingly obvious, but I don't see if this card has the capability of saying, okay, I can give you DVB-T, or DVB-H, or DAB, or T-DMB... Right now, I spit DVB-T. Then an application wanting DVB-H would then be able to initiate a reload of the firmware, and the device would reappear as a DVB-H device.

Quoted 3 lines

The ability to do this firmware switch seems to be present within the driver, but I'm wondering if the S2API, or indeed the present APIs, can handle a case like this.

The delivery system is present in the tuning cache. Demod drivers who need these advanced features can check the required delivery type (c->delivery_system) and decide to load the appropriate firmware to satisfy the users needs.

That _should_ work today, but the firmware reload in the siano demod was added late in the evening (thanks mkrufky) so any bugs need to be shaken out of the demod driver. Prior to this we were only testing the isdb-t portion.

What's missing now in tune.c is the GET_PROPERTY example code to show what delivery systems and modulations types these new drivers can support.

Quoted 11 lines

I know that `mplayer' will grab the first available device of the appropriate standard, while my other applications pick a fixed adapter number (or more correctly, device by product). But I can see myself wanting to make both DVB-T and DAB (eventually) use of this one device, without the bother of reloading the kernel module to switch.

I did spend the night looking at the old API, and remember virtually none of it, and the discussion of multifrontend devices and what they mean has made me wonder about this...

Regards,

Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#34 lore raw

Re: [linux-dvb] Siano ISDB [was: Re: S2API - Status - Thu Sep 11th]

Quoted 4 lines · Steven Toth

The delivery system is present in the tuning cache. Demod drivers who need these advanced features can check the required delivery type (c->delivery_system) and decide to load the appropriate firmware to satisfy the users needs.

Sweet. Neat to see how code can be used in practice, when I haven't the faintest idea how it should be used when reading it.

Quoted 2 lines

That _should_ work today, but the firmware reload in the siano demod was added late in the evening (thanks mkrufky) so any bugs need to be shaken

My only concern, and I hope it's not, 'cuz I can't read code worth beans, is the time when the device gets the new firmware, disconnects, and reconnects, that nothing untoward should happen in this time. But then, I'm only eyeballing what happens during asynchronous `insmod' with non-S2API. Gosh -- what if mode=3 for which my device has no firmware is selected, and the device reappears as a generic USB device?

Probably I need not worry.

Carry On Coding.

thanks,
barry bouwsma

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#35 lore raw

Re: [linux-dvb] Siano ISDB [was: Re: S2API - Status - Thu Sep 11th]

In reply to a message not in the archive
Quoted 18 lines · Steven Toth
Quoted 17 lines · barry bouwsma
Quoted 5 lines · Steven Toth

mkrufky spent some time adding S2API isdb-t support to the siano driver, that's working pretty well - tuning via the S2API app.

http://linuxtv.org/hg/~mkrufky/sms1xxx-isdbt-as-dvbt/

Just a first quick feedback, the following will need to be frobbed appropriately:

    204         if (id < DEVICE_MODE_DVBT || id >
DEVICE_MODE_DVBT_BDA) {
    205                 sms_err("invalid firmware id specified %d", id);
    206                 return -EINVAL;
Quoted 8 lines
Quoted 5 lines

In order to enable ISDB modes, one will need to specify module parameter `default_mode=5' or =6, whichever, and, hmmm, looks like I gotta hunt down a firmware too.

Correct, that tree expects a module option to load the firmware, you might want to check this code snippet in the other tree. The other detects the delivery system and reloads the firmware on the fly.

Actually, I did not yet push up the auto-firmware load patch -- I saw a bug here in my tests, so I'll push that one up after I get back and fix it.

-Mike

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#36 lore raw
In reply to Steven Toth

Hi Steve,

Quoted 4 lines · Steven Toth

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm open to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

I attached a patch which adds a DTV_BANDWIDTH_HZ command. That's all. I would like to have the option to pass any bandwidth I want to the frontend.

Also this patch includes some more things and questions around ISDB-T and ISDB-Tsb:

frontend.h renamed from frontend.h.old +22 -2
@@ -258,6 +258,12 @@
  	DTV_FREQUENCY,
  	DTV_MODULATION,
  	DTV_BANDWIDTH,
+
+	/* XXX PB: I would like to have field which describes the
+	 * bandwidth of a channel in Hz or kHz - maybe we can remove the
+	 * DTV_BANDWIDTH now and put a compat layer */
+	DTV_BANDWIDTH_HZ,
+
  	DTV_INVERSION,
  	DTV_DISEQC_MASTER,
  	DTV_SYMBOL_RATE,
@@ -276,18 +282,32 @@
  	/* New commands are always appended */
  	DTV_DELIVERY_SYSTEM,
 
+	/* XXX PB: is DTV_ISDB the good prefix for ISDB-T parameters ? XXX */
+
  	/* ISDB-T */
-	DTV_ISDB_SEGMENT_IDX,
-	DTV_ISDB_SEGMENT_WIDTH,
+	DTV_ISDB_SEGMENT_IDX, /* maybe a duplicate of DTV_ISDB_SOUND_BROADCASTING_SUBCHANNEL_ID ??? to be checked */
+	DTV_ISDB_SEGMENT_WIDTH, /* 1, 3 or 13 ??? */
+
+	DTV_ISDB_PARTIAL_RECEPTION, /* the central segment can be received independently or 1/3 seg in SB-mode */
+	DTV_ISDB_SOUND_BROADCASTING, /* sound broadcasting is used 0 = 13segment, 1 = 1 or 3 see DTV_ISDB_PARTIAL_RECEPTION */
+
+	/* only used in SB */
+	DTV_ISDB_SOUND_BROADCASTING_SUBCHANNEL_ID, /* determines the initial PRBS of the segment (to match with 13seg channel) */
+
  	DTV_ISDB_LAYERA_FEC,
  	DTV_ISDB_LAYERA_MODULATION,
  	DTV_ISDB_LAYERA_SEGMENT_WIDTH,
+	DTV_ISDB_LAYERA_TIME_INTERLEAVER,
+
  	DTV_ISDB_LAYERB_FEC,
  	DTV_ISDB_LAYERB_MODULATION,
  	DTV_ISDB_LAYERB_SEGMENT_WIDTH,
+	DTV_ISDB_LAYERB_TIME_INTERLEAVING,
+
  	DTV_ISDB_LAYERC_FEC,
  	DTV_ISDB_LAYERC_MODULATION,
  	DTV_ISDB_LAYERC_SEGMENT_WIDTH,
+	DTV_ISDB_LAYERC_TIME_INTERLEAVING,
 
  } dtv_cmd_types_t;
 

Sorry for not integrating this into the frontend_cache yet. But I'm really out of time (at work and even at home, working on cx24120) and I will not be able to supply the DiBcom ISDB-T demod-driver (which would use all that) right now.

thanks for all your efforts,
Patrick.

--
Mail: [email protected]
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#37 lore raw
Quoted 7 lines

Sorry for not integrating this into the frontend_cache yet. But I'm really out of time (at work and even at home, working on cx24120) and I will not be able to supply the DiBcom ISDB-T demod-driver (which would use all that) right now.

thanks for all your efforts,
Patrick.

Ahh, now I see what you were referring to.

I'll merge this tonight, along with your ISDBT suggestions.

Thanks for helping, much appreciated, regards,

Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#38 lore raw
In reply to Patrick Boettcher
Quoted 11 lines · Patrick Boettcher

Hi Steve,

Quoted 4 lines · Steven Toth

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm open to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

I attached a patch which adds a DTV_BANDWIDTH_HZ command. That's all. I would like to have the option to pass any bandwidth I want to the frontend.

...

Quoted 5 lines

Sorry for not integrating this into the frontend_cache yet. But I'm really out of time (at work and even at home, working on cx24120) and I will not be able to supply the DiBcom ISDB-T demod-driver (which would use all that) right now.

Great, thanks, I Merged with minor cleanup of comments.

We should discuss the ISDB specifics at plumbers. The LAYER commands are not currently implemented and it would be good to understand atleast two different demodulators so we can abstract their controls into an API - and avoid any device specifics.

Changes to tune.c (v0.0.6) on steventoth.net/linux/s2

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#39 lore raw
Quoted 25 lines
Quoted 4 lines · Patrick Boettcher

Hi Steve,

Quoted 1 line · Steven Toth

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm

open

Quoted 6 lines
Quoted 3 lines

to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

I attached a patch which adds a DTV_BANDWIDTH_HZ command. That's all. I would like to have the option to pass any bandwidth I want to the

frontend.

Quoted 1 line

...

Quoted 5 lines

Sorry for not integrating this into the frontend_cache yet. But I'm really out of time (at work and even at home, working on cx24120) and I will not be able to supply the DiBcom ISDB-T demod-driver (which would use all that) right now.

Great, thanks, I Merged with minor cleanup of comments.

Quoted 8 lines

We should discuss the ISDB specifics at plumbers. The LAYER commands are not currently implemented and it would be good to understand atleast two different demodulators so we can abstract their controls into an API - and avoid any device specifics.

Changes to tune.c (v0.0.6) on steventoth.net/linux/s2

- Steve

The examples in tune 0.0.6 have two extra zeros :

it should be
{ .cmd = DTV_BANDWIDTH_HZ, .u.data = 8000000 },
not
{ .cmd = DTV_BANDWIDTH_HZ, .u.data = 800000000 },

After applying the multifrontend patch I have signal lock working with HVR4000 and S2API on all three delivery systems:
DVB-T (tune -f 1 option)
and
DVB-S/S2 (tune -f 0 option)

The legacy API works too for DVB-T and DVB-S. Darron has a cx24116 patch which I needed to apply.

Hans

Signature · 9 lines
Release early, release often.

GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#40 lore raw
Quoted 36 lines · Hans Werner
Quoted 20 lines
Quoted 4 lines · Patrick Boettcher

Hi Steve,

Quoted 1 line · Steven Toth

Patrick, I haven't looked at your 1.7MHz bandwidth suggestion - I'm

open

Quoted 5 lines
Quoted 3 lines

to ideas on how you think we should do this. Take a look at todays linux/dvb/frontend.h and see if these updates help, or whether you need more changes.

I attached a patch which adds a DTV_BANDWIDTH_HZ command. That's all. I would like to have the option to pass any bandwidth I want to the

frontend.
...

Quoted 4 lines

Sorry for not integrating this into the frontend_cache yet. But I'm really out of time (at work and even at home, working on cx24120) and I will not be able to supply the DiBcom ISDB-T demod-driver (which would use all that) right now.

Great, thanks, I Merged with minor cleanup of comments.

Quoted 8 lines

We should discuss the ISDB specifics at plumbers. The LAYER commands are not currently implemented and it would be good to understand atleast two different demodulators so we can abstract their controls into an API - and avoid any device specifics.

Changes to tune.c (v0.0.6) on steventoth.net/linux/s2

- Steve

The examples in tune 0.0.6 have two extra zeros :

it should be
{ .cmd = DTV_BANDWIDTH_HZ, .u.data = 8000000 },
not
{ .cmd = DTV_BANDWIDTH_HZ, .u.data = 800000000 },

Quoted 8 lines

After applying the multifrontend patch I have signal lock working with HVR4000 and S2API on all three delivery systems:
DVB-T (tune -f 1 option)
and
DVB-S/S2 (tune -f 0 option)

The legacy API works too for DVB-T and DVB-S. Darron has a cx24116 patch which I needed to apply.

Thanks for highlighting this.

Fixed in v0.0.7, available on steventoth.net/linux/s2

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#41 lore raw
In reply to Steven Toth
Quoted 4 lines

Hans Werner sent a large patch for the multifrontend HVR3000/HVR4000 combined DVB-T/DVB-S/S2 support for the S2API tree. (Thanks Hans - this was obviously a lot of manual merge work, it's greatly appreciated.)

Quoted 8 lines

What would everyone like to see happen with this patch?

Would you prefer to see this dealt with outside of the S2API discussion, or would you like to see this included and merged? Let me know your thoughts. Andreas also has the multifrontend thread running, so comment here if you would like to see this as part of the S2API patches, or comment on the Andreas thread of you want this as a separate patchset at a later date.

Some comments for those who have not been following this story closely. I will try to keep this S2API-relevant.

The reason for considering adding multifrontend support to S2API is that S2API will certainly add HVR4000 support, and at that point we need to consider how to handle the multiple frontends of that card. The multifrontend patch is quite orthogonal to the S2API changes, both in the sense that it does not interfere with them, and in the sense that it is quite a different subject from changing the API.

The updates I made bring the patch right up to date so that it can be merged with the head of the S2API repository. It is quite general -- it can support all multifrontend cards (not just HVR3000/4000). It has been around for about 18 months when Steve proposed it. Darron has been maintaining it at dev.kewl.org/hauppauge. I have used it for 9 months or so with (unmodified) Kaffeine. Darron's method for supporting DVB-S2 features is replaced by the more general S2API.

In the end what the application sees is (for the HVR4000):
/dev/dvb/adapter0/frontend0: DVB-S/S2 /dev/dvb/adapter0/frontend1: DVB-T
Andreas' thread is the place to discuss exactly how this should work. Anyway we have here a concrete implementation of one way to do it.

We need to be careful not to confuse the issues to do with the API. The most important thing is to perfect and debug the design of the S2 API. But I hope multifrontend support will go in to the kernel when the HVR4000 support is added. Perhaps we shouldn't be too scared of trying to make progress by putting it in S2API at the most appropriate point in Steve's development schedule.

Regards,
Hans

Signature · 9 lines
Release early, release often.

GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

A message that is not in the archive (sent off-list or not yet received): [email protected]

#43 lore raw

Le Saturday 13 September 2008 21:21:35 Steven Toth, vous avez écrit :

Quoted 8 lines
Quoted 6 lines

First i tried old api (kaffeine)-> everything works as expected. Then i tried new API (with latest tune.c) -> nova-t and nova-s work, cinergyT2 doesn't. I've also noticed that FE_SET_PROPERTY ioctl always return -1, even when success..
Then i tried old api again -> now dvb-s doesn't lock and dvb-t always lock on the freq used in tune.c

Fixed in the current tree.

Indeed, cache bug is now fixed, old api works as expected in all cases. (Exept for the cinergyT2 case off course)

However, i see that GETting DTV_DELIVERY_SYSTEM always returns the cached value, so at first (after modules (re)load) it returns 0. An application really needs to know the delivery system (and others usefull infos) to be able to handle a device, like the old api FE_GET_INFO.

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#44 lore raw

Le Sunday 14 September 2008 16:46:01 Christophe Thommeret, vous avez écrit :

Quoted 1 line

(Exept for the cinergyT2 case off course)

Missworded, cinergyT2 has always worked wit old api.
I menat, all devices work now as expected with both old and new api, except cinergyT2 which only works with old api.

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#45 lore raw
Quoted 7 lines · Christophe Thommeret

Le Sunday 14 September 2008 16:46:01 Christophe Thommeret, vous avez écrit :

Quoted 1 line

(Exept for the cinergyT2 case off course)

Missworded, cinergyT2 has always worked wit old api.
I menat, all devices work now as expected with both old and new api, except cinergyT2 which only works with old api.

I understood what you meant, but thanks for clarifying.

I posted a patch to the list a few mins ago. If S2API is accept we'll debug the patch and get the device withing with the new API. It's an old driver (2004) but it's still being used.... it should probably come back to dvb-core unless anyone has significant reasons why it should not.

Thanks,

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#46 lore raw
In reply to Christophe Thommeret
Quoted 11 lines · Christophe Thommeret

Le Saturday 13 September 2008 21:21:35 Steven Toth, vous avez écrit :

Quoted 7 lines
Quoted 6 lines

First i tried old api (kaffeine)-> everything works as expected. Then i tried new API (with latest tune.c) -> nova-t and nova-s work, cinergyT2 doesn't. I've also noticed that FE_SET_PROPERTY ioctl always return -1, even when success..
Then i tried old api again -> now dvb-s doesn't lock and dvb-t always lock on the freq used in tune.c

Fixed in the current tree.

Indeed, cache bug is now fixed, old api works as expected in all cases. (Exept for the cinergyT2 case off course)

Speaking of which, I looked at this yesterday. I'll post my feedback back to Johannes thread, where I said I'd investigate.

Quoted 6 lines

However, i see that GETting DTV_DELIVERY_SYSTEM always returns the cached value, so at first (after modules (re)load) it returns 0. An application really needs to know the delivery system (and others usefull infos) to be able to handle a device, like the old api FE_GET_INFO.

Yes, talking with Darron we're talking about being able to identify the existence of the API and capabilities.

We have the DTV_FE_CAPABILITY_COUNT and DTV_FE_CAPABILITY (current defined but not connected in dvb-core) which would be the natural place to expose every older (and newer) feature of the demods.

The command you're referring to now does exactly what it's supposed to, it selects your last SET value (or if the demod has provided a .get_proeprty() callback), the demod could chose to answer differently. In principle we could add a one line fix to the cx24116 demod "c->delivery_system = SYS_DVBS2;" to solve your initial problem - but I don't that's the correct approach.

When the phase #1 work is done we'll fill out the capabilities changes in dvb-core and start to expose interesting features, like LNA, diversity, delivery systems, power controls or anything else that the linuxtv community thinks is generalized and useful. We will take these steps carefully.

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#47 lore raw

Le Sunday 14 September 2008 17:01:49 Steven Toth, vous avez écrit :

Quoted 36 lines
Quoted 8 lines · Christophe Thommeret

Le Saturday 13 September 2008 21:21:35 Steven Toth, vous avez écrit :

Quoted 7 lines
Quoted 6 lines

First i tried old api (kaffeine)-> everything works as expected. Then i tried new API (with latest tune.c) -> nova-t and nova-s work, cinergyT2 doesn't. I've also noticed that FE_SET_PROPERTY ioctl always return -1, even when success..
Then i tried old api again -> now dvb-s doesn't lock and dvb-t always lock on the freq used in tune.c

Quoted 4 lines
Quoted 1 line

Fixed in the current tree.

Indeed, cache bug is now fixed, old api works as expected in all cases. (Exept for the cinergyT2 case off course)

Speaking of which, I looked at this yesterday. I'll post my feedback back to Johannes thread, where I said I'd investigate.

Quoted 4 lines

However, i see that GETting DTV_DELIVERY_SYSTEM always returns the cached value, so at first (after modules (re)load) it returns 0. An application really needs to know the delivery system (and others usefull infos) to be able to handle a device, like the old api FE_GET_INFO.

Yes, talking with Darron we're talking about being able to identify the existence of the API and capabilities.

We have the DTV_FE_CAPABILITY_COUNT and DTV_FE_CAPABILITY (current defined but not connected in dvb-core) which would be the natural place to expose every older (and newer) feature of the demods.

The command you're referring to now does exactly what it's supposed to, it selects your last SET value (or if the demod has provided a .get_proeprty() callback), the demod could chose to answer differently. In principle we could add a one line fix to the cx24116 demod "c->delivery_system = SYS_DVBS2;" to solve your initial problem - but I don't that's the correct approach.

Quoted 5 lines

When the phase #1 work is done we'll fill out the capabilities changes in dvb-core and start to expose interesting features, like LNA, diversity, delivery systems, power controls or anything else that the linuxtv community thinks is generalized and useful. We will take these steps carefully.

Ok, good.

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb