[i2c] Question on ds1339's oscillator

[David Brownell]

On Saturday 16 June 2007, Rodolfo Giometti wrote:
> On Fri, Jun 15, 2007 at 09:24:33AM -0700, David Brownell wrote:
> > 
> > Erm, not at all.  The oscillator is what drives the RTC
> > clock ... you know, the tick/tock/tick/tock/... part.
> > RTCs just count oscillator cycles.  If no oscillator is
> > running, the reported time will never change.
> > 
> > The square wave output is a different thing entirely.
> > Oscillator output may optionally be sent out on one pin
> > of many RTCs (probably divided down) ... maybe the board
> > needs a 32 kiHz signal to drive another circuit.
> 
> If so, why does my RTC work even if the bit EOSC is off?

Go back and read the chip specs again.  The bit name is "nEOSC",
indicating by the "n" that it's active low.  So nEOSC low means
EOSC high, and thus the oscillator is OK...


> > > I think that we should force IRQ output if the board configuration
> > > define an irq line otherwise we can the square wave form as outout.
> > 
> > And when the Linux configuration was a mistake, and then the
> > circuit which needed that clock stops working correctly ...?
> > 
> > If the board setup provides an IRQ and the chip is configured
> > to generate square wave output, that's clearly a bug somewhere.
> > 
> > Issuing a warning is clearly appropriate.  Reconfiguring the
> > hardware, on the assumption that the Linux config is right,
> > seems dangerous to me.  That's not a good way to fix bugs in
> > the production line (including the bootloader).
> 
> I don't agree.

Yet ... you didn't address my question.  You're suggesting that
Linux ignore information it's been given, and change system config
in a way that could *break* something.  Plus, why force square wave
output for IRQ-less configs?  That costs power, among other things,
and the pin isn't necessarily intended to host such a signal.


> 1) If you are the kernel programmer you MUST to know what you are
> doing, so if you select the IRQ line this means that your board MUST
> use the IRQ line and NOT the square wave.

That would explain why the kernel never has bugs to fix.
Oh, wait a second ... it's huge, and DOES have lots of bugs
to fix.  Scratch that, then.  Your assumption is wrong.

I've seen lots of folk just copy'n'paste code from one platform
into another, even when a simple check of the schematics would
show that's clearly wrong.  (Maybe they didn't have schematics
right then, or were in a hurry, or ...)

In this case the hardware configuration can tell us if the
kernel config doesn't match the hardware.  But there's no way
to tell how to resolve the mismatch without schematics.


> 2) The boot loader should init the board JUST for the boot, then the
> kernel should configure the whole system for proper use.

Which is way I said this is normally a manufacturing role,
just like setting the clock in the first place.  Remember
these particular values don't get reset at boot.  Most of
the time, bootloaders have no reason to look at any RTC.
They just set up some pin configuration, memory timings,
and load the kernel.

- Dave