On Tue, Oct 2, 2012 at 7:05 AM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > Btw, why do you need to read 16 registers at once, instead of just reading > the needed register? read_extended and write operations are even more evil: > they read/write the full set of 39 registers on each operation. That seems > to be overkill, especially on places like tda18271_get_id(), where > all the driver is doing is to check for the ID register. TDA18271 does not support subaddressing for read operations. The only way to read a register is by dumping full register contents. 16 registers in simple mode, 39 registers in extended mode. > Worse than that, tda18271_get_id() doesn't even check if the read() > operation failed: it assumes that it will always work, letting the > switch(regs[R_ID]) to print a wrong message (device unknown) when > what actually failed where the 16 registers dump. That's a pretty standard operation to be able to read a chip's ID in its driver attach function. You even have some drivers that continue trying to attach frontends and tuners as long as they continue to get an error in the attach() function. If we dont read the chip's ID during attach() then how do we know we're attaching to the correct chip? I'll look at the fact that it doesn't check for a read error -- that can be easily fixed. > Whenever it should be at attach() or later is a good point for discussions. The tda18271 driver supports running multiple tda18271 devices in tandem with one another, including the ability to share xtal input and rf loop thru. In some cases, the order in which we initialize the different tda18271's (when there are multiples) must be carefully controlled, and we do this by attaching them to the bridge driver in the order needed, such as in the saa7164 driver -- we need to be ABLE to initialize the tuner during the attach, but being able to defer it *as an option* is OK with me. Regards, Mike Krufky -- 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
