Hi Malcolm,
I was really surprised someone has had interest to test that stuff at
that phase as I did not even advertised it yet :) It is likely happen
next Monday or so as there is some issues I would like to check / solve.
On 06/14/2012 01:24 AM, Malcolm Priestley wrote:
Hi antti
There some issues with dvb_usb_v2 with the lmedm04 driver.
The first being this patch, no return value from dvb_usb_download_firmware
causes system wide dead lock with COLD disconnect as system attempts to continue
to warm state.
Hmm, I did not understand what you mean. What I looked lmedm04 driver I
think it uses single USB ID (no cold + warm IDs). So it downloads
firmware and then reconnects itself from the USB bus?
For that scenario you should "return RECONNECTS_USB;" from the driver
.download_firmware().
I tested it using one non-public Cypress FX2 device - it was changing
USB ID after the FX download, but from the driver perspective it does
not matter. It is always new device if it reconnects USB.
PS. as I looked that driver I saw many different firmwares. That is now
supported and you should use .get_firmware_name() (maybe you already did
it).
The second is to do with d->props.bInterfaceNumber in patch 2.
See the other mail.
In get_usb_stream_config there no handing of the struct dvb_frontend.
...
int (*get_usb_stream_config) (struct dvb_frontend *,
struct usb_data_stream_properties *);
...
I wonder if it would be better to use adapter instead?
That was something I think many times how to implement. The motivation
of whole callback is mainly from the MFE. You have one stream (per
adapter) which is needed to configure dynamically per use case. I left
still old static stream configuration as it was, but moved it to the
adapter property. So if you need only one stream configuration use old
style as it looks simpler.
But back to actual question. It is simple - we need to know used
frontend that we could return correct settings. Imagine MFE device, FE0
uses bulk stream and FE1 uses isochronous. Knowing frontend makes it
possible to reconfigure.
There is one "hack" I did intentionally. At the attach() it is called
frontend == NULL to signal we need to get maximum buffer size in order
to alloc big enough USB DMA buffers. Maybe I will add macro for that,
like BUFFERS(count, size) to clear. Or even add another callback.
I also have a draft patch to use delayed work.
Regards
Malcolm
Signed-off-by: Malcolm Priestley<tvboxspy@xxxxxxxxx>
---
drivers/media/dvb/dvb-usb/dvb_usb_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb/dvb-usb/dvb_usb_init.c b/drivers/media/dvb/dvb-usb/dvb_usb_init.c
index 60aa944..c16a28a 100644
--- a/drivers/media/dvb/dvb-usb/dvb_usb_init.c
+++ b/drivers/media/dvb/dvb-usb/dvb_usb_init.c
@@ -61,7 +61,7 @@ static int dvb_usb_download_firmware(struct dvb_usb_device *d)
if (ret< 0)
goto err;
- return 0;
+ return ret;
err:
pr_debug("%s: failed=%d\n", __func__, ret);
return ret;
Thank you for the comments and testing, I am happy to answer other
questions too.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
