Re: pca9665

[Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1634 bytes --]

Hello Marco,

sorry for the late reply, I had to work on other parts first.

On Wed, Sep 17, 2008 at 12:30:29PM -0300, Marco Aurelio da Costa wrote:

> I looked into the code for i2c-algo-pca.c and, if I don't want to 
> implement the buffered mode (I can live without it for a while),

But it may be worth to already get a rough idea if the buffered mode
will fit into this algorithm at all.

> only changes I need to do are:
> 1. Implement the reset via parallel bus.

I can't see this point right now. The algorithm expects a reset routine
from the driver using the algorithm; this should be flexible enough, no?
Or do you mean you also want to share i2c-pca-platform.c among those two
chips. Then it's correct to change it there. Otherwise, please enlighten
me, it's been some time :)

> 2. Change the way the i2c clock rate is treated, by passing the 
> frequency directly instead of an index.

Yup, this has to be generalized between these two.

> After this, this module could handle both chips. I need your advice:
> Should I just duplicate all code and make the changes to this new algo 
> or should I add a chip_type field to i2c_algo_pca_data and handle the 
> chip on the existing algo code?

Concerning the algorithm, I'd really go for the latter. It is easier to
maintain if there will be bugfixes to the state-machine, for example.
And they seem to be similar enough (perhaps modulo the buffered mode,
which I didn't look at so far).

All the best,

   Wolfram

-- 
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c