Hi Stefano, Thanks for your reply.
> > From my site I promise I will get a look at it. At the moment I have a > big question. I see your code is quite similar to other ones > (fsl_pmic.c is what I know better..). I remember there was already a > discussion about another pmic, whose patch reassembled some drivers > in u-boot. > > My big question is: if we have a similar mechanism to access the PMICs > (SPI/I2C), should we not to found a way to generalize it ? This kind > of driver has only some pmic_read/pmic_write functions. > > Maybe getting rid of special manufacturer names as fsl_pmic, > max_pmic... and using a general access for this kind of chips ? From > code your patch is not very distant from what we currently have. Any > opinion about this ? Yes, you are right. I've looked to the fsl_pmic driver when I was preparing patch for MAX8998. As you have written, dealing with those two PMICs boils down to reading/writing their internal registers via I2C by i2c.h API. We can think of a common PMIC framework, which is consisting of methods for reading/writing internal registers, enabling outputs of those devices. PMIC specific data (like register map, I2C addresses) can be stored in *.h files. I can prepare some common framework and post proposition on the mailing list. On the beginning I'll focus on MAX8998 and FSL. Any comments/ideas are welcome. > > > > BTW. On the "u-boot Custodians" page I haven't found anyone > > responsible for driver/misc. > > You are right. > > > Is there appropriate person for this, or shall it be > > addressed to Wolfgang? > > I do not know - however, your driver is not strictly related to a > specific SOC, and could be used by any architecture. We can consider > it as general code, and I added Wolfgang in CC to ask his opinion. > > Best regards, > Stefano Babic > -- Best regards, Lukasz Majewski Samsung Poland R&D Center Platform Group _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot