Skip to contentSkip to conversation

dvb: add support for plls used by nxt200x

PATCH In review Michael Krufky 6 participants 7 messages Nov 1, 2005 – Nov 4, 2005 Media (V4L/DVB)

lore
Share & tools
lore

Michael Krufky

author
#0 lore raw

PATCH 26/37 dvb: add support for plls used by nxt200x

From: Kirk Lapray <[email protected]>

- Added support for the following:
Philips TUV1236D - ATI HDTV Wonder
ALPS TDHU2 - AverTVHD MCE A180
Samsung TBMV30111IN - Air2PC ATSC - 2nd generation

These will be used in a new NXT200X driver that incorporates the NXT2002 driver and adds support for a couple NXT2004 based cards.

Signed-off-by Kirk Lapray <[email protected]>
Signed-off-by Michael Krufky <[email protected]>
 drivers/media/dvb/frontends/dvb-pll.c |   52 ++++++++++++++++++++++++++++++++++
 drivers/media/dvb/frontends/dvb-pll.h |    4 ++
 2 files changed, 56 insertions(+)
drivers/media/dvb/frontends/dvb-pll.c +52 -0
@@ -292,6 +292,58 @@
 };
 EXPORT_SYMBOL(dvb_pll_tded4);
 
+/* ALPS TDHU2
+ * used in AverTVHD MCE A180
+ */
+struct dvb_pll_desc dvb_pll_tdhu2 = {
+	.name = "ALPS TDHU2",
+	.min = 54000000,
+	.max = 864000000,
+	.count = 4,
+	.entries = {
+		{ 162000000, 44000000, 62500, 0x85, 0x01 },
+		{ 426000000, 44000000, 62500, 0x85, 0x02 },
+		{ 782000000, 44000000, 62500, 0x85, 0x08 },
+		{ 999999999, 44000000, 62500, 0x85, 0x88 },
+	}
+};
+EXPORT_SYMBOL(dvb_pll_tdhu2);
+
+/* Philips TUV1236D
+ * used in ATI HDTV Wonder
+ */
+struct dvb_pll_desc dvb_pll_tuv1236d = {
+	.name  = "Philips TUV1236D",
+	.min   =  57000000,
+	.max   = 864000000,
+	.count = 3,
+	.entries = {
+		{ 157250000, 44000000, 62500, 0xc6, 0x41 },
+		{ 454000000, 44000000, 62500, 0xc6, 0x42 },
+		{ 999999999, 44000000, 62500, 0xc6, 0x44 },
+	},
+};
+EXPORT_SYMBOL(dvb_pll_tuv1236d);
+
+/* Samsung TBMV30111IN
+ * used in Air2PC ATSC - 2nd generation (nxt2002)
+ */
+struct dvb_pll_desc dvb_pll_tbmv30111in = {
+	.name = "Samsung TBMV30111IN",
+	.min = 54000000,
+	.max = 860000000,
+	.count = 4,
+	.entries = {
+		{ 172000000, 44000000, 166666, 0xb4, 0x01 },
+		{ 214000000, 44000000, 166666, 0xb4, 0x02 },
+		{ 467000000, 44000000, 166666, 0xbc, 0x02 },
+		{ 721000000, 44000000, 166666, 0xbc, 0x08 },
+		{ 841000000, 44000000, 166666, 0xf4, 0x08 },
+		{ 999999999, 44000000, 166666, 0xfc, 0x02 },
+	}
+};
+EXPORT_SYMBOL(dvb_pll_tbmv30111in);
+
 /* ----------------------------------------------------------- */
 /* code                                                        */
drivers/media/dvb/frontends/dvb-pll.h +4 -0
@@ -36,6 +36,10 @@
 extern struct dvb_pll_desc dvb_pll_fmd1216me;
 extern struct dvb_pll_desc dvb_pll_tded4;
 
+extern struct dvb_pll_desc dvb_pll_tuv1236d;
+extern struct dvb_pll_desc dvb_pll_tdhu2;
+extern struct dvb_pll_desc dvb_pll_tbmv30111in;
+
 int dvb_pll_configure(struct dvb_pll_desc *desc, u8 *buf,
 		      u32 freq, int bandwidth);
#1 lore raw
Quoted 14 lines · Michael Krufky

+struct dvb_pll_desc dvb_pll_tdhu2 = {
+ .name = "ALPS TDHU2",
+ .min = 54000000,
+ .max = 864000000,
+ .count = 4,
+ .entries = {
+ { 162000000, 44000000, 62500, 0x85, 0x01 },
+ { 426000000, 44000000, 62500, 0x85, 0x02 },
+ { 782000000, 44000000, 62500, 0x85, 0x08 },
+ { 999999999, 44000000, 62500, 0x85, 0x88 },
+ }
+};
+EXPORT_SYMBOL(dvb_pll_tdhu2);

The new driver is to have a GPL license, I assume?

Generally, EXPORT_SYMBOL_GPL seems more appropriate for the DVB subsystem.

#2 lore raw
Quoted 21 lines · Andrew Morton
Quoted 5 lines · Michael Krufky
drivers/media/dvb/frontends/dvb-pll.c +3 -0
+struct dvb_pll_desc dvb_pll_tdhu2 = {
+	.name = "ALPS TDHU2",
+	.min = 54000000,

drivers/media/dvb/frontends/dvb-pll.c line 310

Quoted 10 lines
drivers/media/dvb/frontends/dvb-pll.c +10 -0
+	.max = 864000000,
+	.count = 4,
+	.entries = {
+		{ 162000000, 44000000, 62500, 0x85, 0x01 },
+		{ 426000000, 44000000, 62500, 0x85, 0x02 },
+		{ 782000000, 44000000, 62500, 0x85, 0x08 },
+		{ 999999999, 44000000, 62500, 0x85, 0x88 },
+	}
+};
+EXPORT_SYMBOL(dvb_pll_tdhu2);

The new driver is to have a GPL license, I assume?

Quoted 2 lines

Generally, EXPORT_SYMBOL_GPL seems more appropriate for the DVB subsystem.

Yes, GPL'd of course. But these pll definitions are not strictly tied to nxt200x -- they may very well be used by another frontend module in the future.

Actually, we keep pll info in a separate file (dvb-pll.c) so that the tuner programming can be used by any frontend module, depending on the design..... About EXPORT_SYMBOL, this is how it's done all over dvb-pll.c

If this needs to change, then it should apply to the entire dvb-pll.

I'll wait for Johannes' comments on this.

Michael Krufky

#3 lore raw
Quoted 23 lines · Mike Krufky
Quoted 21 lines · Andrew Morton
Quoted 4 lines · Michael Krufky
drivers/media/dvb/frontends/dvb-pll.c +3 -0
+struct dvb_pll_desc dvb_pll_tdhu2 = {
+    .name = "ALPS TDHU2",
+    .min = 54000000,

drivers/media/dvb/frontends/dvb-pll.c line 310

Quoted 10 lines
drivers/media/dvb/frontends/dvb-pll.c +10 -0
+    .max = 864000000,
+    .count = 4,
+    .entries = {
+        { 162000000, 44000000, 62500, 0x85, 0x01 },
+        { 426000000, 44000000, 62500, 0x85, 0x02 },
+        { 782000000, 44000000, 62500, 0x85, 0x08 },
+        { 999999999, 44000000, 62500, 0x85, 0x88 },
+    }
+};
+EXPORT_SYMBOL(dvb_pll_tdhu2);

The new driver is to have a GPL license, I assume?

Quoted 2 lines
Quoted 2 lines

Generally, EXPORT_SYMBOL_GPL seems more appropriate for the DVB subsystem.

Hello Andrew,

We have in the DVB subsystem most of the exported symbols as EXPORT_SYMBOL itself, rather than EXPORT_SYMBOL_GPL. I think if this needs to be changed, we would require a global change of all symbols to the same to maintain consistency. If you require that change we can have a change but i would think that the discussions be done with the relevant copyright holders too, eventhough probably most of the authors won't have any objection.

Quoted 6 lines

Yes, GPL'd of course. But these pll definitions are not strictly tied to nxt200x -- they may very well be used by another frontend module in the future.

Actually, we keep pll info in a separate file (dvb-pll.c) so that the tuner programming can be used by any frontend module, depending on the design..... About EXPORT_SYMBOL, this is how it's done all over dvb-pll.c

If this needs to change, then it should apply to the entire dvb-pll.

It is not necessary limited to dvb-pll, but the entire dvb-kernel.

Thanks,
Manu

#4 lore raw
Quoted 7 lines · Manu Abraham

We have in the DVB subsystem most of the exported symbols as EXPORT_SYMBOL itself, rather than EXPORT_SYMBOL_GPL. I think if this needs to be changed, we would require a global change of all symbols to the same to maintain consistency. If you require that change we can have a change but i would think that the discussions be done with the relevant copyright holders too, eventhough probably most of the authors won't have any objection.

I don't know if I ever contributed code to the DVB subsystem which is actually exported, but in case I did, then I am against changing the affected EXPORT_SYMBOLs.

This would make it impossible to the use source code of most hardware vendors for embedded products because they usually have different licenses for their "run-on-every-embedded-platform-and-even-on-windows" drivers.

Also I remember people telling on lkml that EXPORT_SYMBOL_GPL was used for new kernel internal code only and I can't see how this applies to dvb-pll or any other part of the dvb subsystem which grew up outside the kernel tree.

Regards,
Andreas

#5 lore raw
Quoted 12 lines · Andreas Oberritter
Quoted 3 lines · Manu Abraham

We have in the DVB subsystem most of the exported symbols as EXPORT_SYMBOL itself, rather than EXPORT_SYMBOL_GPL. I think if this needs to be changed, we would require a global change of all symbols to the same to maintain consistency. If you require that change we can have a change but i would think that the discussions be done with the relevant copyright holders too, eventhough probably most of the authors won't have any objection.

I don't know if I ever contributed code to the DVB subsystem which is actually exported, but in case I did, then I am against changing the affected EXPORT_SYMBOLs.

Since this issue is subject to discussion, i think a consensus can be reached, with a discussion with the relevant owners, _if_ it needs to be changed. I did not imply that it needs to be changed.

I have personally contributed some code which does EXPORT_SYMBOL, but for me changing it to EXPORT_SYMBOL_GPL is acceptable if the general consensus is that way, or if there is a valid reason to go either way. I don't mind either.

Quoted 11 lines

This would make it impossible to the use source code of most hardware vendors for embedded products because they usually have different licenses for their "run-on-every-embedded-platform-and-even-on-windows" drivers.

Also I remember people telling on lkml that EXPORT_SYMBOL_GPL was used for new kernel internal code only and I can't see how this applies to dvb-pll or any other part of the dvb subsystem which grew up outside the kernel tree.

AFAIK, the only hardware that exports EXPORT_SYMBOL_GPL is only the budget core, other than that all of the code uses EXPORT_SYMBOL only.

Regards,
Manu

#6 lore raw
In reply to Andreas Oberritter
Quoted 18 lines · Andreas Oberritter
Quoted 7 lines · Manu Abraham

We have in the DVB subsystem most of the exported symbols as EXPORT_SYMBOL itself, rather than EXPORT_SYMBOL_GPL. I think if this needs to be changed, we would require a global change of all symbols to the same to maintain consistency. If you require that change we can have a change but i would think that the discussions be done with the relevant copyright holders too, eventhough probably most of the authors won't have any objection.

I don't know if I ever contributed code to the DVB subsystem which is actually exported, but in case I did, then I am against changing the affected EXPORT_SYMBOLs.

This would make it impossible to the use source code of most hardware vendors for embedded products because they usually have different licenses for their "run-on-every-embedded-platform-and-even-on-windows" drivers.

Quoted 4 lines

Also I remember people telling on lkml that EXPORT_SYMBOL_GPL was used for new kernel internal code only and I can't see how this applies to dvb-pll or any other part of the dvb subsystem which grew up outside the kernel tree.

AFAIK, the DVB core is also purposely using an LGPL license to allow drivers with other licenses to at least use the DVB includes/calls.

Regards,
Ralph