On Thu, 10 Nov 2011 01:01:57 +0200, Antti Palosaari wrote: > Hello > After today discussion I think at least following configuration options > could be possible: > > address len, for format msg > register value len, for format msg > max write len, for splitting > max read len, for splitting > option for repeated start, for splitting > conditional error logging > callback for I2C-mux (I2C-gate) > general functions implemented: wr_regs, rd_regs, wr_reg, rd_reg, > wr_reg_mask, wr_reg_bits, rd_reg_bits > support for register banks? > > That's full list of ideas I have as now. At least in first phase I think > only basic register reads and writes are enough. Yes, I suggest starting simple, and adding things later on as they become needed. I also suggest spelling out "read" and "write", and also don't forget to prefix your public function names to avoid namespace collisions. > I wonder if Jean could be as main leader of development since he has > surely best knowledge about I2C and all possible users. Otherwise, I > think I could do it only as linux-media common functionality, because I > don't have enough knowledge about other users. If you want it to happen fast, then I suggest that you drive development yourself, and indeed implement it as a common linux-media functionality for now. Later on, once the code has been in place for some time with success, if other subsystems need something similar then we can consider moving the code to i2c-core or some generic i2c helper module. If you count on me to drive it, I am afraid it will take months, given my current workload and various tasks with a much higher priority than this. I will however be happy to help with code review. -- Jean Delvare -- 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
