Re: [RFCv1] DVB-USB improvements [alternative 2]
On 21.05.2012 06:50, Mauro Carvalho Chehab wrote:
Em 20-05-2012 17:55, Antti Palosaari escreveu:
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing old functionality that new
one goes much more deeper.
As a basic rule I designed it to reduce stuff from the current struct
dvb_usb_device_properties. Currently there is many nested structs introducing same
callbacks. For that one I dropped all frontend and adapter level callbacks to device
level. Currently struct contains 2 adapters and 3 frontends - which means we have 2 * 3 =
6 similar callbacks and only 1 is used. It wastes some space since devices
having more than one adapter or frontend are rather rare. Making callback selection
inside individual driver is very trivial even without a designated callback. Here is
common example from the use of .frontend_attach() callback in case of only one callback
used:
static int frontend_attach(struct dvb_usb_adapter *adap)
{
if (adap-id == 0)
return frontend_attach_1();
else
return frontend_attach_2();
}
Functionality enhancement mentioned earlier RFC are valid too:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html
As I was a little bit lazy I wrote only quick skeleton code to represent new simplified
struct dvb_usb_device_properties:
struct dvb_usb_device_properties = {
/* download_firmware() success return values to signal what happens next */
#define RECONNECTS_USB (1 0)
#define RECONNECTS_USB_USING_NEW_ID (1 1)
.size_of_priv = sizeof(struct 'state'),
/* firmware download */
.identify_state(struct dvb_usb_device *d, int *cold),
.get_firmware_name(struct dvb_usb_device *d, char *firmware_name),
.download_firmware(struct dvb_usb_device *d, const struct firmware *fw),
.allow_dynamic_id = true,
.power_ctrl(struct dvb_usb_device *d, int onoff),
.read_config(struct dvb_usb_device *d, u8 mac[6]),
.get_adapter_count(struct dvb_usb_device *d, int *count),
.frontend_attach(struct dvb_usb_adapter *adap),
.tuner_attach(struct dvb_usb_adapter *adap),
.init(struct dvb_usb_device *d),
.get_rc(struct dvb_rc *),
.i2c_algo = (struct i2c_algorithm),
.frontend_ctrl(struct dvb_frontend *fe, int onoff),
.get_stream_props(struct usb_data_stream_properties *),
.streaming_ctrl(struct dvb_usb_adapter *adap, int onoff),
.generic_bulk_ctrl_endpoint = (int),
.generic_bulk_ctrl_endpoint_response = (int),
.devices = (struct dvb_usb_device)[],
};
struct dvb_usb_device dvb_usb_devices {
char *name = name,
.rc_map = RC_MAP_EMPTY,
.device_id = (struct usb_device_id),
}
It looks OK to me. It may make sense to add an optional
per-device field, to allow drivers to add more board-specific
information, if they need, in order to avoid duplicating
things there.
Another option would be for the drivers to do:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
int foo;
long bar;
...
}
And, inside the core, use the container_of() macro to go from
the device-specific table to struct dvb_usb_device.
This way, simple drivers can do just:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
}
And complex drivers can add more stuff there.
I have now implemented some basic stuff. Most interesting is new way of
map device id and properties for it. I found that I can use .driver_info
field from the (struct usb_device_id) to carry pointer. I used it to
carry all the other data to the DVB USB core. Thus that one big issue is
now resolved. It reduces something like 8-9 kB of binary size which is
huge improvement. Same will happen for every driver using multiple
(struct dvb_usb_device_properties) - for more you are used more you save.
Here is 3 example drivers I have converted to that new style:
http://palosaari.fi/linux/v4l-dvb/dvb-usb-2012-05-25/
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
On 25.05.2012 20:44, Antti Palosaari wrote: I have now implemented some basic stuff. Most interesting is new way of map device id and properties for it. I found that I can use .driver_info field from the (struct usb_device_id) to carry pointer. I used it to carry all the other data to the DVB USB core. Thus that one big issue is now resolved. It reduces something like 8-9 kB of binary size which is huge improvement. Same will happen for every driver using multiple (struct dvb_usb_device_properties) - for more you are used more you save. Argh, reduces 8-9kB from the *af9015* as it was defining three (struct dvb_usb_device_properties). Also line count reduces 350 lines and will reduce some more after all those planned callbacks are done. Here is 3 example drivers I have converted to that new style: http://palosaari.fi/linux/v4l-dvb/dvb-usb-2012-05-25/ Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
Em 25-05-2012 14:44, Antti Palosaari escreveu:
On 21.05.2012 06:50, Mauro Carvalho Chehab wrote:
Em 20-05-2012 17:55, Antti Palosaari escreveu:
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing old functionality that
new one goes much more deeper.
As a basic rule I designed it to reduce stuff from the current struct
dvb_usb_device_properties. Currently there is many nested structs
introducing same callbacks. For that one I dropped all frontend and adapter
level callbacks to device level. Currently struct contains 2 adapters and 3
frontends - which means we have 2 * 3 = 6 similar callbacks and only 1 is
used. It wastes some space since devices having more than one adapter or
frontend are rather rare. Making callback selection inside individual
driver is very trivial even without a designated callback. Here is common
example from the use of .frontend_attach() callback in case of only one
callback used:
static int frontend_attach(struct dvb_usb_adapter *adap)
{
if (adap-id == 0)
return frontend_attach_1();
else
return frontend_attach_2();
}
Functionality enhancement mentioned earlier RFC are valid too:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html
As I was a little bit lazy I wrote only quick skeleton code to represent
new simplified struct dvb_usb_device_properties:
struct dvb_usb_device_properties = {
/* download_firmware() success return values to signal what happens next
*/
#define RECONNECTS_USB (1 0)
#define RECONNECTS_USB_USING_NEW_ID (1 1)
.size_of_priv = sizeof(struct 'state'),
/* firmware download */
.identify_state(struct dvb_usb_device *d, int *cold),
.get_firmware_name(struct dvb_usb_device *d, char *firmware_name),
.download_firmware(struct dvb_usb_device *d, const struct firmware *fw),
.allow_dynamic_id = true,
.power_ctrl(struct dvb_usb_device *d, int onoff),
.read_config(struct dvb_usb_device *d, u8 mac[6]),
.get_adapter_count(struct dvb_usb_device *d, int *count),
.frontend_attach(struct dvb_usb_adapter *adap),
.tuner_attach(struct dvb_usb_adapter *adap),
.init(struct dvb_usb_device *d),
.get_rc(struct dvb_rc *),
.i2c_algo = (struct i2c_algorithm),
.frontend_ctrl(struct dvb_frontend *fe, int onoff),
.get_stream_props(struct usb_data_stream_properties *),
.streaming_ctrl(struct dvb_usb_adapter *adap, int onoff),
.generic_bulk_ctrl_endpoint = (int),
.generic_bulk_ctrl_endpoint_response = (int),
.devices = (struct dvb_usb_device)[],
};
struct dvb_usb_device dvb_usb_devices {
char *name = name,
.rc_map = RC_MAP_EMPTY,
.device_id = (struct usb_device_id),
}
It looks OK to me. It may make sense to add an optional
per-device field, to allow drivers to add more board-specific
information, if they need, in order to avoid duplicating
things there.
Another option would be for the drivers to do:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
int foo;
long bar;
...
}
And, inside the core, use the container_of() macro to go from
the device-specific table to struct dvb_usb_device.
This way, simple drivers can do just:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
}
And complex drivers can add more stuff there.
I have now implemented some basic stuff. Most interesting is new way of map
device id and properties for it. I found that I can use .driver_info field
from the (struct usb_device_id) to carry pointer. I used it to carry all the
other data to the DVB USB core. Thus that one big issue is now resolved. It
reduces something like 8-9 kB of binary size which is huge improvement. Same
will happen for every driver using multiple (struct
dvb_usb_device_properties) - for more you are used more you save.
Here is 3 example drivers I have converted to that new style:
http://palosaari.fi/linux/v4l-dvb/dvb-usb-2012-05-25/
It will be better if you inline a diff at the email, instead of pointing
to the changed files.
Also, instead of doing:
static struct usb_device_id af9015_usb_table[] = {
{ USB_DEVICE(USB_VID_AFATECH, USB_PID_AFATECH_AF9015_9015),
.driver_info = (kernel_ulong_t) ((struct dvb_usb_driver_info) {
.name = Afatech AF9015 reference design,
.props = af9015_properties })},
I suggest you to add a macro for it, converting the above to something similar
to:
DVB_USB_DRIVER_INFO(Afatech AF9015 reference design,
af9015_properties),
or, even better, to:
DVB_USB_DEVICE(USB_VID_AFATECH,
USB_PID_AFATECH_AF9015_9015,
Afatech AF9015 reference design,
af9015_properties),
Btw, I still think that you should move things like
Re: [RFCv1] DVB-USB improvements [alternative 2]
Em 25-05-2012 15:32, Mauro Carvalho Chehab escreveu:
Em 25-05-2012 14:44, Antti Palosaari escreveu:
On 21.05.2012 06:50, Mauro Carvalho Chehab wrote:
Em 20-05-2012 17:55, Antti Palosaari escreveu:
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing old functionality that
new one goes much more deeper.
As a basic rule I designed it to reduce stuff from the current struct
dvb_usb_device_properties. Currently there is many nested structs
introducing same callbacks. For that one I dropped all frontend and
adapter level callbacks to device level. Currently struct contains 2
adapters and 3 frontends - which means we have 2 * 3 = 6 similar
callbacks and only 1 is used. It wastes some space since devices having
more than one adapter or frontend are rather rare. Making callback
selection inside individual driver is very trivial even without a
designated callback. Here is common example from the use of
.frontend_attach() callback in case of only one callback used:
static int frontend_attach(struct dvb_usb_adapter *adap)
{
if (adap-id == 0)
return frontend_attach_1();
else
return frontend_attach_2();
}
Functionality enhancement mentioned earlier RFC are valid too:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html
As I was a little bit lazy I wrote only quick skeleton code to represent
new simplified struct dvb_usb_device_properties:
struct dvb_usb_device_properties = {
/* download_firmware() success return values to signal what happens
next */
#define RECONNECTS_USB (1 0)
#define RECONNECTS_USB_USING_NEW_ID (1 1)
.size_of_priv = sizeof(struct 'state'),
/* firmware download */
.identify_state(struct dvb_usb_device *d, int *cold),
.get_firmware_name(struct dvb_usb_device *d, char *firmware_name),
.download_firmware(struct dvb_usb_device *d, const struct firmware *fw),
.allow_dynamic_id = true,
.power_ctrl(struct dvb_usb_device *d, int onoff),
.read_config(struct dvb_usb_device *d, u8 mac[6]),
.get_adapter_count(struct dvb_usb_device *d, int *count),
.frontend_attach(struct dvb_usb_adapter *adap),
.tuner_attach(struct dvb_usb_adapter *adap),
.init(struct dvb_usb_device *d),
.get_rc(struct dvb_rc *),
.i2c_algo = (struct i2c_algorithm),
.frontend_ctrl(struct dvb_frontend *fe, int onoff),
.get_stream_props(struct usb_data_stream_properties *),
.streaming_ctrl(struct dvb_usb_adapter *adap, int onoff),
.generic_bulk_ctrl_endpoint = (int),
.generic_bulk_ctrl_endpoint_response = (int),
.devices = (struct dvb_usb_device)[],
};
struct dvb_usb_device dvb_usb_devices {
char *name = name,
.rc_map = RC_MAP_EMPTY,
.device_id = (struct usb_device_id),
}
It looks OK to me. It may make sense to add an optional
per-device field, to allow drivers to add more board-specific
information, if they need, in order to avoid duplicating
things there.
Another option would be for the drivers to do:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
int foo;
long bar;
...
}
And, inside the core, use the container_of() macro to go from
the device-specific table to struct dvb_usb_device.
This way, simple drivers can do just:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
}
And complex drivers can add more stuff there.
I have now implemented some basic stuff. Most interesting is new way of map
device id and properties for it. I found that I can use .driver_info field
from the (struct usb_device_id) to carry pointer. I used it to carry all the
other data to the DVB USB core. Thus that one big issue is now resolved. It
reduces something like 8-9 kB of binary size which is huge improvement. Same
will happen for every driver using multiple (struct
dvb_usb_device_properties) - for more you are used more you save.
Here is 3 example drivers I have converted to that new style:
http://palosaari.fi/linux/v4l-dvb/dvb-usb-2012-05-25/
It will be better if you inline a diff at the email, instead of pointing
to the changed files.
Also, instead of doing:
static struct usb_device_id af9015_usb_table[] = {
{ USB_DEVICE(USB_VID_AFATECH, USB_PID_AFATECH_AF9015_9015),
.driver_info = (kernel_ulong_t) ((struct dvb_usb_driver_info) {
.name = Afatech AF9015 reference design,
.props = af9015_properties })},
I suggest you to add a macro for it, converting the above to something
similar to:
DVB_USB_DRIVER_INFO(Afatech AF9015 reference design,
af9015_properties),
or, even better, to:
DVB_USB_DEVICE(USB_VID_AFATECH,
USB_PID_AFATECH_AF9015_9015,
Afatech AF9015 reference design,
Re: [RFCv1] DVB-USB improvements [alternative 2]
On 25.05.2012 21:32, Mauro Carvalho Chehab wrote:
Em 25-05-2012 14:44, Antti Palosaari escreveu:
On 21.05.2012 06:50, Mauro Carvalho Chehab wrote:
Em 20-05-2012 17:55, Antti Palosaari escreveu:
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing old functionality that new
one goes much more deeper.
As a basic rule I designed it to reduce stuff from the current struct
dvb_usb_device_properties. Currently there is many nested structs introducing same
callbacks. For that one I dropped all frontend and adapter level callbacks to device
level. Currently struct contains 2 adapters and 3 frontends - which means we have 2 * 3 =
6 similar callbacks and only 1 is used. It wastes some space since devices
having more than one adapter or frontend are rather rare. Making callback selection
inside individual driver is very trivial even without a designated callback. Here is
common example from the use of .frontend_attach() callback in case of only one callback
used:
static int frontend_attach(struct dvb_usb_adapter *adap)
{
if (adap-id == 0)
return frontend_attach_1();
else
return frontend_attach_2();
}
Functionality enhancement mentioned earlier RFC are valid too:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html
As I was a little bit lazy I wrote only quick skeleton code to represent new simplified
struct dvb_usb_device_properties:
struct dvb_usb_device_properties = {
/* download_firmware() success return values to signal what happens next */
#define RECONNECTS_USB (1 0)
#define RECONNECTS_USB_USING_NEW_ID (1 1)
.size_of_priv = sizeof(struct 'state'),
/* firmware download */
.identify_state(struct dvb_usb_device *d, int *cold),
.get_firmware_name(struct dvb_usb_device *d, char *firmware_name),
.download_firmware(struct dvb_usb_device *d, const struct firmware *fw),
.allow_dynamic_id = true,
.power_ctrl(struct dvb_usb_device *d, int onoff),
.read_config(struct dvb_usb_device *d, u8 mac[6]),
.get_adapter_count(struct dvb_usb_device *d, int *count),
.frontend_attach(struct dvb_usb_adapter *adap),
.tuner_attach(struct dvb_usb_adapter *adap),
.init(struct dvb_usb_device *d),
.get_rc(struct dvb_rc *),
.i2c_algo = (struct i2c_algorithm),
.frontend_ctrl(struct dvb_frontend *fe, int onoff),
.get_stream_props(struct usb_data_stream_properties *),
.streaming_ctrl(struct dvb_usb_adapter *adap, int onoff),
.generic_bulk_ctrl_endpoint = (int),
.generic_bulk_ctrl_endpoint_response = (int),
.devices = (struct dvb_usb_device)[],
};
struct dvb_usb_device dvb_usb_devices {
char *name = name,
.rc_map = RC_MAP_EMPTY,
.device_id = (struct usb_device_id),
}
It looks OK to me. It may make sense to add an optional
per-device field, to allow drivers to add more board-specific
information, if they need, in order to avoid duplicating
things there.
Another option would be for the drivers to do:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
int foo;
long bar;
...
}
And, inside the core, use the container_of() macro to go from
the device-specific table to struct dvb_usb_device.
This way, simple drivers can do just:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
}
And complex drivers can add more stuff there.
I have now implemented some basic stuff. Most interesting is new way of map
device id and properties for it. I found that I can use .driver_info field from
the (struct usb_device_id) to carry pointer. I used it to carry all the other
data to the DVB USB core. Thus that one big issue is now resolved. It reduces
something like 8-9 kB of binary size which is huge improvement. Same will
happen for every driver using multiple (struct dvb_usb_device_properties) - for
more you are used more you save.
Here is 3 example drivers I have converted to that new style:
http://palosaari.fi/linux/v4l-dvb/dvb-usb-2012-05-25/
It will be better if you inline a diff at the email, instead of pointing
to the changed files.
Also, instead of doing:
static struct usb_device_id af9015_usb_table[] = {
{ USB_DEVICE(USB_VID_AFATECH, USB_PID_AFATECH_AF9015_9015),
.driver_info = (kernel_ulong_t)((struct dvb_usb_driver_info) {
.name = Afatech AF9015 reference design,
.props =af9015_properties })},
I suggest you to add a macro for it, converting the above to something similar
to:
DVB_USB_DRIVER_INFO(Afatech AF9015 reference
design,af9015_properties),
or, even better, to:
DVB_USB_DEVICE(USB_VID_AFATECH,
USB_PID_AFATECH_AF9015_9015,
Afatech AF9015 reference design,
af9015_properties),
Using macro you will save mostly one line but it looks
[RFCv1] DVB-USB improvements [alternative 2]
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing old functionality that
new one goes much more deeper.
As a basic rule I designed it to reduce stuff from the current struct
dvb_usb_device_properties. Currently there is many nested structs
introducing same callbacks. For that one I dropped all frontend and
adapter level callbacks to device level. Currently struct contains 2
adapters and 3 frontends - which means we have 2 * 3 = 6 similar
callbacks and only 1 is used. It wastes some space since devices having
more than one adapter or frontend are rather rare. Making callback
selection inside individual driver is very trivial even without a
designated callback. Here is common example from the use of
.frontend_attach() callback in case of only one callback used:
static int frontend_attach(struct dvb_usb_adapter *adap)
{
if (adap-id == 0)
return frontend_attach_1();
else
return frontend_attach_2();
}
Functionality enhancement mentioned earlier RFC are valid too:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html
As I was a little bit lazy I wrote only quick skeleton code to represent
new simplified struct dvb_usb_device_properties:
struct dvb_usb_device_properties = {
/* download_firmware() success return values to signal what happens
next */
#define RECONNECTS_USB (1 0)
#define RECONNECTS_USB_USING_NEW_ID (1 1)
.size_of_priv = sizeof(struct 'state'),
/* firmware download */
.identify_state(struct dvb_usb_device *d, int *cold),
.get_firmware_name(struct dvb_usb_device *d, char *firmware_name),
.download_firmware(struct dvb_usb_device *d, const struct firmware *fw),
.allow_dynamic_id = true,
.power_ctrl(struct dvb_usb_device *d, int onoff),
.read_config(struct dvb_usb_device *d, u8 mac[6]),
.get_adapter_count(struct dvb_usb_device *d, int *count),
.frontend_attach(struct dvb_usb_adapter *adap),
.tuner_attach(struct dvb_usb_adapter *adap),
.init(struct dvb_usb_device *d),
.get_rc(struct dvb_rc *),
.i2c_algo = (struct i2c_algorithm),
.frontend_ctrl(struct dvb_frontend *fe, int onoff),
.get_stream_props(struct usb_data_stream_properties *),
.streaming_ctrl(struct dvb_usb_adapter *adap, int onoff),
.generic_bulk_ctrl_endpoint = (int),
.generic_bulk_ctrl_endpoint_response = (int),
.devices = (struct dvb_usb_device)[],
};
struct dvb_usb_device dvb_usb_devices {
char *name = name,
.rc_map = RC_MAP_EMPTY,
.device_id = (struct usb_device_id),
}
It is likely Wednesday I am going to start implementing that one unless
some big issues are raised. Making simple test code as a
proof-of-concept should not be very many days of work.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
On Sun, May 20, 2012 at 1:55 PM, Antti Palosaari cr...@iki.fi wrote: I did some more planning and made alternative RFC. As the earlier alternative was more like changing old functionality that new one goes much more deeper. Functionality enhancement mentioned earlier RFC are valid too: http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html One thing I didn't see mentioned in your post or the one your linked is the rc dependency for _all_ usb devices, whether they even have rc capability or not. It makes sense that is dvb usb is going to get overhauled, that rc functionality be at the very least optional rather than forced it on all usb devices. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
On Sun, May 20, 2012 at 6:30 PM, VDR User user@gmail.com wrote: On Sun, May 20, 2012 at 1:55 PM, Antti Palosaari cr...@iki.fi wrote: I did some more planning and made alternative RFC. As the earlier alternative was more like changing old functionality that new one goes much more deeper. Functionality enhancement mentioned earlier RFC are valid too: http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html One thing I didn't see mentioned in your post or the one your linked is the rc dependency for _all_ usb devices, whether they even have rc capability or not. It makes sense that is dvb usb is going to get overhauled, that rc functionality be at the very least optional rather than forced it on all usb devices. If you think this is important, then you should feel free to submit patches to Antti's tree. Otherwise, this is the sort of optimization that brings so little value as to not really be worth the engineering effort. The time is better spent working on problems that *actually* have a visible effect to users (and a few extra modules being loaded does not fall into this category). I think you'll find after spending a few hours trying to abstract out the logic and the ugly solution that results that it *really* isn't worth it. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
On Sun, May 20, 2012 at 4:10 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: If you think this is important, then you should feel free to submit patches to Antti's tree. Otherwise, this is the sort of optimization that brings so little value as to not really be worth the engineering effort. The time is better spent working on problems that *actually* have a visible effect to users (and a few extra modules being loaded does not fall into this category). I think you'll find after spending a few hours trying to abstract out the logic and the ugly solution that results that it *really* isn't worth it. So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
On 21.05.2012 03:36, VDR User wrote: On Sun, May 20, 2012 at 4:10 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: If you think this is important, then you should feel free to submit patches to Antti's tree. Otherwise, this is the sort of optimization that brings so little value as to not really be worth the engineering effort. The time is better spent working on problems that *actually* have a visible effect to users (and a few extra modules being loaded does not fall into this category). I think you'll find after spending a few hours trying to abstract out the logic and the ugly solution that results that it *really* isn't worth it. So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. I am not sure what you trying to say. Do you mean I should try to get remote controller totally optional module which can be left out? How much memory will be saved if remote can be left out as unloaded? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
On Sun, May 20, 2012 at 7:22 PM, Antti Palosaari cr...@iki.fi wrote: So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. I am not sure what you trying to say. Do you mean I should try to get remote controller totally optional module which can be left out? I am saying it's a dependency that is currently forced onto every usb device whether the device even supports rc or not. This is clearly poor design. For that matter, the whole usb handling must be poor design if it needs to be overhauled. How much memory will be saved if remote can be left out as unloaded? I don't know. I'm merely pointing out just one of the issues that should be resolved if the idea is to fix things that are wrong with usb handling. If nobody cares, doesn't think it matters, or simply doesn't want to bother, so be it. I guess I'm crazy but when I'm facing an overhaul, especially when there's no rush, I compile a list of _everything_ that's wrong and make sure the overhaul fixes it all. I guess there's quite a difference between my idea of what an overhaul should be, and other peoples. If you really want, there's probably people who deal with embedded systems where every wasted byte counts, that would agree cleaning up the waste is a good idea. Since nobody thinks it should be fixed, just pretend I didn't even bring it up. Problem solved. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
ma 21.5.2012 5:42 VDR User kirjoitti: On Sun, May 20, 2012 at 7:22 PM, Antti Palosaari cr...@iki.fi wrote: So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. I am not sure what you trying to say. Do you mean I should try to get remote controller totally optional module which can be left out? I am saying it's a dependency that is currently forced onto every usb device whether the device even supports rc or not. This is clearly poor design. For that matter, the whole usb handling must be poor design if it needs to be overhauled. How much memory will be saved if remote can be left out as unloaded? I don't know. I'm merely pointing out just one of the issues that should be resolved if the idea is to fix things that are wrong with usb handling. If nobody cares, doesn't think it matters, or simply doesn't want to bother, so be it. I guess I'm crazy but when I'm facing an overhaul, especially when there's no rush, I compile a list of _everything_ that's wrong and make sure the overhaul fixes it all. I guess there's quite a difference between my idea of what an overhaul should be, and other peoples. If you really want, there's probably people who deal with embedded systems where every wasted byte counts, that would agree cleaning up the waste is a good idea. Since nobody thinks it should be fixed, just pretend I didn't even bring it up. Problem solved. There is quite few devices that are shipped without remote. I agree that it could be better and more modular. And it is asked multiple times during these years. But my main motivation is to fix problems first and then do enhancements. I will look if I can found some time for that too. regards Antti -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
Em 21-05-2012 00:20, Antti Palosaari escreveu: ma 21.5.2012 5:42 VDR User kirjoitti: On Sun, May 20, 2012 at 7:22 PM, Antti Palosaari cr...@iki.fi wrote: So you think that it makes more sense to ignore existing issues rather than fix them. Isn't fixing issues flaws the whole point of an overhaul/redesign? Yes, it is. I do get the point you're trying to make -- there are bigger fish to fry. But this is not an urgent project and I disagree with the attitude to just disregard whatever you deem unimportant. If you're going to do it, do it right. I am not sure what you trying to say. Do you mean I should try to get remote controller totally optional module which can be left out? I am saying it's a dependency that is currently forced onto every usb device whether the device even supports rc or not. This is clearly poor design. For that matter, the whole usb handling must be poor design if it needs to be overhauled. How much memory will be saved if remote can be left out as unloaded? I don't know. I'm merely pointing out just one of the issues that should be resolved if the idea is to fix things that are wrong with usb handling. If nobody cares, doesn't think it matters, or simply doesn't want to bother, so be it. I guess I'm crazy but when I'm facing an overhaul, especially when there's no rush, I compile a list of _everything_ that's wrong and make sure the overhaul fixes it all. I guess there's quite a difference between my idea of what an overhaul should be, and other peoples. If you really want, there's probably people who deal with embedded systems where every wasted byte counts, that would agree cleaning up the waste is a good idea. Since nobody thinks it should be fixed, just pretend I didn't even bring it up. Problem solved. There is quite few devices that are shipped without remote. I agree that it could be better and more modular. And it is asked multiple times during these years. But my main motivation is to fix problems first and then do enhancements. I will look if I can found some time for that too. I see two separate issues here: 1) the dvb_usb properties struct needs to point if the device has RC or not. It could be possible to optimize it if the remote code is not enabled, but provided that the structure is properly designed, the only per-device information is the RC keytable. Optimizing it when IR is not compiled will save just a few bytes per card. Not worth, IMHO. 2) Remove the RC dependency from dvb-usb, and making the dvb-usb-remote code as a module. This can bring some savings, as the RC core and IR decoders won't be loaded. I think (2) is valuable to do, but this can be done latter with a likely simple patch, and won't require any changes at the DVB structures. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements [alternative 2]
Em 20-05-2012 17:55, Antti Palosaari escreveu:
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing old functionality that new
one goes much more deeper.
As a basic rule I designed it to reduce stuff from the current struct
dvb_usb_device_properties. Currently there is many nested structs introducing
same callbacks. For that one I dropped all frontend and adapter level
callbacks to device level. Currently struct contains 2 adapters and 3
frontends - which means we have 2 * 3 = 6 similar callbacks and only 1 is
used. It wastes some space since devices having more than one adapter or
frontend are rather rare. Making callback selection inside individual driver
is very trivial even without a designated callback. Here is common example
from the use of .frontend_attach() callback in case of only one callback used:
static int frontend_attach(struct dvb_usb_adapter *adap)
{
if (adap-id == 0)
return frontend_attach_1();
else
return frontend_attach_2();
}
Functionality enhancement mentioned earlier RFC are valid too:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html
As I was a little bit lazy I wrote only quick skeleton code to represent new
simplified struct dvb_usb_device_properties:
struct dvb_usb_device_properties = {
/* download_firmware() success return values to signal what happens next */
#define RECONNECTS_USB (1 0)
#define RECONNECTS_USB_USING_NEW_ID (1 1)
.size_of_priv = sizeof(struct 'state'),
/* firmware download */
.identify_state(struct dvb_usb_device *d, int *cold),
.get_firmware_name(struct dvb_usb_device *d, char *firmware_name),
.download_firmware(struct dvb_usb_device *d, const struct firmware *fw),
.allow_dynamic_id = true,
.power_ctrl(struct dvb_usb_device *d, int onoff),
.read_config(struct dvb_usb_device *d, u8 mac[6]),
.get_adapter_count(struct dvb_usb_device *d, int *count),
.frontend_attach(struct dvb_usb_adapter *adap),
.tuner_attach(struct dvb_usb_adapter *adap),
.init(struct dvb_usb_device *d),
.get_rc(struct dvb_rc *),
.i2c_algo = (struct i2c_algorithm),
.frontend_ctrl(struct dvb_frontend *fe, int onoff),
.get_stream_props(struct usb_data_stream_properties *),
.streaming_ctrl(struct dvb_usb_adapter *adap, int onoff),
.generic_bulk_ctrl_endpoint = (int),
.generic_bulk_ctrl_endpoint_response = (int),
.devices = (struct dvb_usb_device)[],
};
struct dvb_usb_device dvb_usb_devices {
char *name = name,
.rc_map = RC_MAP_EMPTY,
.device_id = (struct usb_device_id),
}
It looks OK to me. It may make sense to add an optional
per-device field, to allow drivers to add more board-specific
information, if they need, in order to avoid duplicating
things there.
Another option would be for the drivers to do:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
int foo;
long bar;
...
}
And, inside the core, use the container_of() macro to go from
the device-specific table to struct dvb_usb_device.
This way, simple drivers can do just:
struct dvb_usb_drive_foo dvb_usb_driver_foo {
struct dvb_usb_device dvb_usb_devices dvb_usb_dev;
}
And complex drivers can add more stuff there.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements
Em 08-05-2012 10:12, Antti Palosaari escreveu: Factors behind the changes are mostly coming from the fact current struct dvb_usb_device_properties contains so many static configuration options. You cannot change single dvb_usb_device_properties easily (safely) at runtime since it is usually driver global struct and thus shared between all the DVB USB driver instances. That fits just fine for the traditional devices where all configuration is same for the devices having single USB ID. Nowadays we have more and more devices that are based of chipset vendor reference designs - even using just single USB ID chipset vendor have given for that chipset. These reference designs still varies much about used chips and configurations. Configuring different base chips, USB-bridge, demod, tuner, and also peripheral properties like dual tuners, remotes and CI is needed to do runtime because of single USB ID is used for that all. Drivers waste lots of space with dvb_usb_device_properties, as this struct is HUGE. Also, the structure index number need to match the USB ID table index, which causes merge troubles from time to time, breaking existing cards when new ones are added. Also, if the remote controller is different, a series of data needs to be duplicated into a separate entry. IMHO, it would be better to re-design it to avoid wasting space without need. My personal innovator behind all these is problems I met when developing AF9015 and AF9035 drivers. Also RTL2831U and RTL2832U are kinda similar and have given some more motivation. Here is small list what I am planning to do. It is surely so much work that everything is not possible, but lets try to select most important and easiest as a higher priority. resume / suspend support --- * very important feature * crashes currently when DVB USB tries to download firmware when resuming from suspend read_config1 --- * new callback to do initial tweaks * very first callback * is that really needed? Calling it as read_config1 is not nice, as 1 has no strong meaning. It would be better to name it as read_config_early, if this is needed. read_mac_address = read_config2 --- * rename it read_config2 or read_config if read_config1 is not implemented at all read_config seems a good name for it. * rename old callback and extend it usage as a more general * only 8 devices use currently * when returned mac != 0 = print mac address as earlier, otherwise work as a general callback Please, don't do that. Different behaviors if mac is filled (or not) is a very bad idea. new callback init() --- * called after tuner attach to initialize rest of device * good place to do some general settings - configure endpoints - configure remote controller - configure + attach CI change DVB-USB to dynamic debug --- * use Kernel new dynamic debugs instead of own proprietary system download_firmware --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback identify_state --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback IMO, all callbacks should use the same argument (either usb_device or dvb_usb_device). attach all given adapter frontends as once --- * for the MFE devices attach all frontends as once We should first clean-up the bad/legacy MFE drivers, as most use MFE to implement a single FE chipset that supports more than one delivery system. * deregister all frontends if error returned * small effect only for MFE attach all given adapter tuners as once --- * deregister all frontends if error returned * small effect only for MFE make remote dynamically configurable --- The first step here is to remove rc.legacy stuff. * default keytable mapped same level with USB-ID device name etc. * there is generally 3 things that could be mapped to USB ID - USB IDs (cold + warm) - device name - remote controller keytable - all the others could be resolved configured dynamically * it is not only keytable but whole remote should be changed dynamically configurable The issue with IR is because of the issue with struct dvb_usb_device_properties. If you take a look at em28xx implementation, for example, there's just one parameter for the IR keytables that determine if a device will be loaded with or without IR: the RC keytable. re-designing dvb_usb_device_properties should fix it. make stream dynamically configurable --- * we need change stream parameters in certain situations - there is multiple endpoints but shared MFE - need to set params according to stream bandwidth (USB1.1, DVB-T, DVB-C2 in same device) - leave old static configrations as those are but
Re: [RFCv1] DVB-USB improvements
On Thu, May 10, 2012 at 10:14 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: In order to add analog support, it is likely simpler to take em28xx (mainly em28xx-video) as an example on how things are implemented on analog side. The gspca implementation may also help a lot, but it doesn't contain the tuner bits. Antti, If you do decide to take on analog in dvb-usb and use em28xx as a model, bear in mind that the locking between analog and digital is *totally* broken. You can open both the analog and digital devices simultaneously, causing completely unpredictable behavior. I'm just mentioning this because this is something you should *not* model after em28xx, and because it's a huge headache for real users (lack of locking causes all sorts of end-user problems in MythTV and other applications that support both analog and digital). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements
On 10.05.2012 17:14, Mauro Carvalho Chehab wrote: Em 08-05-2012 10:12, Antti Palosaari escreveu: Factors behind the changes are mostly coming from the fact current struct dvb_usb_device_properties contains so many static configuration options. You cannot change single dvb_usb_device_properties easily (safely) at runtime since it is usually driver global struct and thus shared between all the DVB USB driver instances. That fits just fine for the traditional devices where all configuration is same for the devices having single USB ID. Nowadays we have more and more devices that are based of chipset vendor reference designs - even using just single USB ID chipset vendor have given for that chipset. These reference designs still varies much about used chips and configurations. Configuring different base chips, USB-bridge, demod, tuner, and also peripheral properties like dual tuners, remotes and CI is needed to do runtime because of single USB ID is used for that all. Drivers waste lots of space with dvb_usb_device_properties, as this struct is HUGE. Also, the structure index number need to match the USB ID table index, which causes merge troubles from time to time, breaking existing cards when new ones are added. Also, if the remote controller is different, a series of data needs to be duplicated into a separate entry. Yes, that was one thing what I have keep in my mind. Due to I planned to move remote keytable same place as a device name and USB-IDs are (as later in that RFC was defined). IMHO, it would be better to re-design it to avoid wasting space without need. Could be clearer situation but also much more work. Implementing all issues mentioned by this RFC should reduce used space a lot, I think likely 50% or so. My personal innovator behind all these is problems I met when developing AF9015 and AF9035 drivers. Also RTL2831U and RTL2832U are kinda similar and have given some more motivation. Here is small list what I am planning to do. It is surely so much work that everything is not possible, but lets try to select most important and easiest as a higher priority. resume / suspend support --- * very important feature * crashes currently when DVB USB tries to download firmware when resuming from suspend read_config1 --- * new callback to do initial tweaks * very first callback * is that really needed? Calling it as read_config1 is not nice, as 1 has no strong meaning. It would be better to name it as read_config_early, if this is needed. I think I will drop that, after all I think it is not much needed. The idea for that was something like probe chipset version for firmware select as there is some chipset selecting firmware according to chip revision. But such small decisions are better to made inside firmware download callback. Also due to that static firmware name should be replaced by callback that selects firmware. read_mac_address = read_config2 --- * rename it read_config2 or read_config if read_config1 is not implemented at all read_config seems a good name for it. * rename old callback and extend it usage as a more general * only 8 devices use currently * when returned mac != 0 = print mac address as earlier, otherwise work as a general callback Please, don't do that. Different behaviors if mac is filled (or not) is a very bad idea. Actually look it like a extended behaviour (MAC address is extended behaviour of read_config). MAC address is read from the eeprom and so it device configuration on many cases. There was only 8 devices using MAC address so own callback for it is waste of space. For my eyes returning MAC address as a .read_config() parameter is something like very good idea. new callback init() --- * called after tuner attach to initialize rest of device * good place to do some general settings - configure endpoints - configure remote controller - configure + attach CI change DVB-USB to dynamic debug --- * use Kernel new dynamic debugs instead of own proprietary system download_firmware --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback identify_state --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback IMO, all callbacks should use the same argument (either usb_device or dvb_usb_device). YES! That is the reason I am changing it :) All callbacks inside DVB-USB should get pointer to dvb_usb_device or some other pointer which is deeper than dvb_usb_device (like ptr to FE). The requirement of changing that is coming from the fact there is some values needed to store to the state (like USB message sequence numbers). For example AF9015/AF9035/IT9135/IT9137... fortunately those still works currently since firmware never checks sequence counter validly. attach
[RFCv1] DVB-USB improvements
Factors behind the changes are mostly coming from the fact current struct dvb_usb_device_properties contains so many static configuration options. You cannot change single dvb_usb_device_properties easily (safely) at runtime since it is usually driver global struct and thus shared between all the DVB USB driver instances. That fits just fine for the traditional devices where all configuration is same for the devices having single USB ID. Nowadays we have more and more devices that are based of chipset vendor reference designs - even using just single USB ID chipset vendor have given for that chipset. These reference designs still varies much about used chips and configurations. Configuring different base chips, USB-bridge, demod, tuner, and also peripheral properties like dual tuners, remotes and CI is needed to do runtime because of single USB ID is used for that all. My personal innovator behind all these is problems I met when developing AF9015 and AF9035 drivers. Also RTL2831U and RTL2832U are kinda similar and have given some more motivation. Here is small list what I am planning to do. It is surely so much work that everything is not possible, but lets try to select most important and easiest as a higher priority. resume / suspend support --- * very important feature * crashes currently when DVB USB tries to download firmware when resuming from suspend read_config1 --- * new callback to do initial tweaks * very first callback * is that really needed? read_mac_address = read_config2 --- * rename it read_config2 or read_config if read_config1 is not implemented at all * rename old callback and extend it usage as a more general * only 8 devices use currently * when returned mac != 0 = print mac address as earlier, otherwise work as a general callback new callback init() --- * called after tuner attach to initialize rest of device * good place to do some general settings - configure endpoints - configure remote controller - configure + attach CI change DVB-USB to dynamic debug --- * use Kernel new dynamic debugs instead of own proprietary system download_firmware --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback identify_state --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback attach all given adapter frontends as once --- * for the MFE devices attach all frontends as once * deregister all frontends if error returned * small effect only for MFE attach all given adapter tuners as once --- * deregister all frontends if error returned * small effect only for MFE make remote dynamically configurable --- * default keytable mapped same level with USB-ID device name etc. * there is generally 3 things that could be mapped to USB ID - USB IDs (cold + warm) - device name - remote controller keytable - all the others could be resolved configured dynamically * it is not only keytable but whole remote should be changed dynamically configurable make stream dynamically configurable --- * we need change stream parameters in certain situations - there is multiple endpoints but shared MFE - need to set params according to stream bandwidth (USB1.1, DVB-T, DVB-C2 in same device) - leave old static configrations as those are but add callbacks to get new values at runtime dynamically growing device list in dvb_usb_device_properties --- * currently number of devices are limited statically * there is devices having ~50 or more IDs which means multiple dvb_usb_device_properties are needed dynamic USB ID support --- * currently not supported by DVB USB analog support for the DVB USB --- * currently not supported by DVB USB * I have no experience * em28xx can be converted? -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements
On Tue, May 8, 2012 at 3:12 PM, Antti Palosaari cr...@iki.fi wrote: Factors behind the changes are mostly coming from the fact current struct dvb_usb_device_properties contains so many static configuration options. You cannot change single dvb_usb_device_properties easily (safely) at runtime since it is usually driver global struct and thus shared between all the DVB USB driver instances. That fits just fine for the traditional devices where all configuration is same for the devices having single USB ID. Nowadays we have more and more devices that are based of chipset vendor reference designs - even using just single USB ID chipset vendor have given for that chipset. These reference designs still varies much about used chips and configurations. Configuring different base chips, USB-bridge, demod, tuner, and also peripheral properties like dual tuners, remotes and CI is needed to do runtime because of single USB ID is used for that all. My personal innovator behind all these is problems I met when developing AF9015 and AF9035 drivers. Also RTL2831U and RTL2832U are kinda similar and have given some more motivation. Here is small list what I am planning to do. It is surely so much work that everything is not possible, but lets try to select most important and easiest as a higher priority. resume / suspend support --- * very important feature * crashes currently when DVB USB tries to download firmware when resuming from suspend read_config1 --- * new callback to do initial tweaks * very first callback * is that really needed? read_mac_address = read_config2 --- * rename it read_config2 or read_config if read_config1 is not implemented at all * rename old callback and extend it usage as a more general * only 8 devices use currently * when returned mac != 0 = print mac address as earlier, otherwise work as a general callback new callback init() --- * called after tuner attach to initialize rest of device * good place to do some general settings - configure endpoints - configure remote controller - configure + attach CI change DVB-USB to dynamic debug --- * use Kernel new dynamic debugs instead of own proprietary system download_firmware --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback identify_state --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback attach all given adapter frontends as once --- * for the MFE devices attach all frontends as once * deregister all frontends if error returned * small effect only for MFE attach all given adapter tuners as once --- * deregister all frontends if error returned * small effect only for MFE make remote dynamically configurable --- * default keytable mapped same level with USB-ID device name etc. * there is generally 3 things that could be mapped to USB ID - USB IDs (cold + warm) - device name - remote controller keytable - all the others could be resolved configured dynamically * it is not only keytable but whole remote should be changed dynamically configurable make stream dynamically configurable --- * we need change stream parameters in certain situations - there is multiple endpoints but shared MFE - need to set params according to stream bandwidth (USB1.1, DVB-T, DVB-C2 in same device) - leave old static configrations as those are but add callbacks to get new values at runtime dynamically growing device list in dvb_usb_device_properties --- * currently number of devices are limited statically * there is devices having ~50 or more IDs which means multiple dvb_usb_device_properties are needed dynamic USB ID support --- * currently not supported by DVB USB analog support for the DVB USB --- * currently not supported by DVB USB * I have no experience * em28xx can be converted? You might also work on a dvb library, just like libv4l has right now, that might satisfy the streaming requests which have been made on this mailinglist :-) BR, Markus -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1] DVB-USB improvements
On 08.05.2012 20:55, Markus Rechberger wrote: You might also work on a dvb library, just like libv4l has right now, that might satisfy the streaming requests which have been made on this mailinglist :-) I want first fix general DVB issues I has met during these years. Maybe library can be done next year or so :] Actually library has been on my mind few times, but what I see it useful is for example implementing channel scanner. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
