[PATCH] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable

[PATCH] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable

[Bjørn Mork]

Thanks to Ozan ?a?layan <ozan@pardus.org.tr> for pointing it out

From: Manu Abraham <abraham.manu@gmail.com>

Signed-off-by: Manu Abraham <manu@linuxtv.org>
[bjorn@mork.no: imported from http://jusst.de/hg/mantis-v4l-dvb/raw-rev/3731f71ed6bf]
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable@kernel.org
---
This patch is so obviously correct that I do not know how to write it differently.

It is copied from the mercurial repostory at http://jusst.de/hg/mantis-v4l-dvb/
where it has been resting for more than 4 months. I certainly hope everyone is
OK with me just forwarding it like this...  My only agenda is a fully functional
mantis driver in the kernel.

This patch does nothing but add all the relevant device id's for these two drivers, so
I consider it material for stable as well.

Bjørn

 drivers/media/dvb/mantis/hopper_cards.c |    2 ++
 drivers/media/dvb/mantis/mantis_cards.c |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/mantis/hopper_cards.c b/drivers/media/dvb/mantis/hopper_cards.c
index d073c61..1bf03ac 100644
--- a/drivers/media/dvb/mantis/hopper_cards.c
+++ b/drivers/media/dvb/mantis/hopper_cards.c
@@ -250,6 +250,8 @@ static struct pci_device_id hopper_pci_table[] = {
 	{ }
 };
 
+MODULE_DEVICE_TABLE(pci, hopper_pci_table);
+
 static struct pci_driver hopper_pci_driver = {
 	.name		= DRIVER_NAME,
 	.id_table	= hopper_pci_table,
diff --git a/drivers/media/dvb/mantis/mantis_cards.c b/drivers/media/dvb/mantis/mantis_cards.c
index 16f1708..64970cf 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -280,6 +280,8 @@ static struct pci_device_id mantis_pci_table[] = {
 	{ }
 };
 
+MODULE_DEVICE_TABLE(pci, mantis_pci_table);
+
 static struct pci_driver mantis_pci_driver = {
 	.name		= DRIVER_NAME,
 	.id_table	= mantis_pci_table,
-- 
1.7.1

Re: [PATCH] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable

[VDR User]

2010/6/21 Bjørn Mork <bjorn@mork.no>:
> Thanks to Ozan ?a?layan <ozan@pardus.org.tr> for pointing it out
>
> From: Manu Abraham <abraham.manu@gmail.com>
>
> Signed-off-by: Manu Abraham <manu@linuxtv.org>
> [bjorn@mork.no: imported from http://jusst.de/hg/mantis-v4l-dvb/raw-rev/3731f71ed6bf]
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> Cc: stable@kernel.org
> ---
> This patch is so obviously correct that I do not know how to write it differently.
>
> It is copied from the mercurial repostory at http://jusst.de/hg/mantis-v4l-dvb/
> where it has been resting for more than 4 months. I certainly hope everyone is
> OK with me just forwarding it like this...  My only agenda is a fully functional
> mantis driver in the kernel.

Instead of copy&paste patches from Manu's tree, maybe it's better to
just wait for him to push all the changes into v4l.  There have been
many bug fixes & improvements Manu has done that haven't been pushed
into v4l yet and I think it's better to sync the entire driver instead
of cherry picking patches here & there.

-Derek

Re: [PATCH] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable

[Bjørn Mork]

VDR User <user.vdr@gmail.com> writes:

> Instead of copy&paste patches from Manu's tree, maybe it's better to
> just wait for him to push all the changes into v4l.  

I certainly agree that having him push all the changes would be much
better. And nothing would please me more than seeing this happen.

But I do *not* agree that "just wait" is better.  We have waited for 4
months.  It did not work.  Why do you think that waiting more will work
better? 

> There have been
> many bug fixes & improvements Manu has done that haven't been pushed
> into v4l yet

I guess there is.  I only know of the two now 4 months old bug fixes in
http://jusst.de/hg/mantis-v4l-dvb but there can of course be much more
happening without me knowing.  There could be other trees.  But without
pointers (we have a perfectly good MAINTAINERS for this), it's very hard
to find such things.

In fact, I do have some problems getting oriented in the V4L/DVB world.
There seem to be a number of dead development trees scattered all
around.  But I guess that's to be expected, since there have been major
reorganisations lately.  To the better, IMHO.  I'm looking forward to
having Linus' kernel track the V4L/DVB development more closely, and not
having to replace a whole subsystem every time I want to test a new
driver.

> and I think it's better to sync the entire driver instead
> of cherry picking patches here & there.

Yes.  And I did hesitate to do this.  But this one patch is really
wanted to make the driver fully functional (users do expect PCI drivers
to autoload nowadays). It could have been in 2.6.34.  As it looks now,
it won't make 2.6.35...

Why wait?  What's the point of collecting a large number (or small
number for that sake) of patches in some development tree only very few
developers even know exists?  Push them upstream as soon as possible.
The initial driver development is of course something else.  I
appreciate the need to develop something working before pushing it. But
simple fixes like this one?  Just push it.




Bjørn

Re: [PATCH] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable

[Marko Ristola]

21.06.2010 19:51, Bjørn Mork wrote:
> VDR User<user.vdr@gmail.com>  writes:
>
>    
>> Instead of copy&paste patches from Manu's tree, maybe it's better to
>> just wait for him to push all the changes into v4l.
>>      
>    

I'm Manu sorry about trying to put patches directly into v4-dvb, if 
those should go onto your branch first.

So, what Manu do you think about my DMA patch or other patches I sent 
into linux-media mailing list this weekend?
Is it okay to generate one interrupt once per 16k bytes,
or are the interrupts too rare?

At least VDR reads the DVB stream rarely, so I think
that it is enough if the DVB card has always something
to be delivered when VDR or MythTV asks more data,
so if the number of DMA transfer IRQs is twice than the
number of times VDR or MythTV asks more data per second,
then the context switches are in balance.

Understandable DMA RISC programming should be easier to maintain, and it 
removes the initial garbage from the stream too.

How about the tasklet enable/disable patch I wrote?

What needs to be done for these patches to be accepted?

Best regards,
Marko