[PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API

[Biju Das]

Hi Wolfram,

> Subject: RE: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
> 
> 
> Hi Wolfram,
> 
> > Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device
> > API
> >
> > Hi all,
> >
> > sorry for not being able to chime in earlier.
> >
> > > In Biju's particular use case, the i2c device responds to two
> > > addresses, which is the standard i2c ancillary use case.  However,
> > > what's special
> >
> > Not quite. ancillary is used when a *driver* needs to take care of two
> > addresses. We already have devices bundling two features into the same
> > chip. I recall at least RTC + EEPROM somewhere. And so far, we have
> > been handling this by creating two nodes in DT and have proper binding
> docs.
> > I think this is cleaner. First, you can see in DT already what the
> > compound device really consists of. In this case, which RTC and RTC
> > driver is exactly needed. Second, the code added here adds complexity
> > to the I2C core with another layer of inderection for dummy devices.
> 
> FYI, please see [1] and [2]
> 
> As per DT maintainers, most of PMICs are described with one node, even
> though RTC is on separate address. According to them the DT schema allows
> multiple addresses for children.
> But currently we lacks implementation for that. The enhancement to this
> API allows that.
> 
> 
> >
> > > As some resources are shared (knowledge about the clocks), splitting
> > > this in two distinct devices in DT (which is what Biju's initial
> > > patch series did) would need phandles to link both nodes together.
> > >
> > > Do you have a better idea how to represent this?
> >
> > Not sure if I understood this chip correctly, but maybe: The PMIC
> > driver exposes a clock gate which can be consumed by the RTC driver?

Let me give me some details of this PMIC chip.

PMIC device has 2 addresses "0x12:- PMIC" , "0x6f"- rtc. 

It has XIN, XOUT, INT# pins and a register for firmware revisions.

Based on the system design,

If XIN and XOUT is connected to external crystal, Internal oscillator is enabled for RTC.
In this case we need to set the oscillator bit to "0".

If XIN is connected to external clock source, Internal oscillator is disabled for RTC.
In this case we need to set the oscillator bit to "1".

If XIN and XOUT not connected RTC operation not possible.

IRQ# (optional) functionality is shared between PMIC and RTC. (PMIC fault for various bucks/LDOs/WDT/OTP/NVM or alarm condition).

The board, I have doesn't populate IRQ# pin. If needed some customers can populate IRQ# pin and use it for PMIC fault or RTC alarm.

Also, currently my board has PMIC rev a0 where oscillator bit is inverted and internal oscillator is enabled (ie: XIN and XOUT is connected to external crystal)

Cheers,
Biju