Dennis Noordsij wrote:
This would be ok. I would suggest something like this in dvb_proc.h:Create lets say dvb_proc.c and .h. Define a struct dvb_proc_fe struct in dvb_proc.h and place all the required proc var things inside this struct. Then add this struct to the frontend struct, wrapped by #ifdef DVB_PROC_FS. So you blow up the fe_struct just by 3 lines.Next move all the register unregister proc code to the dvb_proc.c and in the fe_register just call dvb_proc_register_frontend(&fe) (again wrapped by ifdef DVB_RPOC_FS) Maybe it's a good idea to put the proc register/unregister hooks inside the dvb_device_register. Since it will become generic and you get proc infos for all device, not just the fe's. But i haven't checked this idea yet. Hope that helps a bit, Florian
That's a good idea actually :-) Holger, is it ok to blow up a few functions and structures by those 3 lines, if I keep everything else in proc_fs files? This is sufficient for exposing all driver functionality to /proc, but there is also the case of allowing more low level adjustments, which are not otherwise made public in the driver.
#ifdef DVB_PROC_FS
extern dvb_proc_register_frontend(...);
/*...*/
#else
#define dvb_proc_register_frontend(...)
#define dvb_proc_unregister_frontend(...)
#endif
Then you need the ifdef's only in one place and make the code in dvb_frontend.c looking better.
For example the PWM and ves1820 register values, for these I need to do a bit more work. I will still try to move it all to proc_fs specific source file(s), and keep the modifications to the actual driver very small.What about a writeable complete register dump for each dvb_i2c device? Then you don't have to reimplement this for every new frontend driver.
Holger, in the write_proc function, for example for /proc/.../frequency, I just fire off a new frontend_set_parameters with the frequency changed, and the other parameters the same, is that OK ?Yes, to make it simple you can add a two proc files: one that takes a binary dvb_frontend_parameters struct and one that takes one in ascii format like generated by the scan utility and czap/tzap.
Those lines look like this:
DVB-S: "11837000:INVERSION_OFF:27500000:FEC_AUTO"
DVB-C: "346000000:INVERSION_OFF:6900000:FEC_AUTO:QAM_64"
DVB-T: "714000000:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_2_3:FEC_NONE:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE"
The dump and parser code you can take from czap.c, tzap.c and scan/dump.c
Holger
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
