Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Paul Burton <paul.burton@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	James Hogan <james.hogan@imgtec.com>, <linux-mips@linux-mips.org>
Subject: Re: [PATCH 1/2] MIPS: malta-time: Don't switch RTC to BCD mode
Date: Fri, 15 May 2015 19:14:13 +0100	[thread overview]
Message-ID: <20150515181413.GA30774@NP-P-BURTON> (raw)
In-Reply-To: <20150515180351.GE2322@linux-mips.org>

On Fri, May 15, 2015 at 08:03:51PM +0200, Ralf Baechle wrote:
> >  I'd prefer RTC state not to be touched at all if its state is sane.  
> > That is read Register B, check for the only valid divider setting 
> > (32kHz), and if so then exit right away, and otherwise initialise the 
> > chip from scratch.  Consistency with YAMON might be a good idea in that 
> > initialisation, but I have no strong feeling towards that.  If you think 
> > there's value in having the chip set to the BCD mode, then feel free to 
> > keep that option.
> > 
> >  Note that any inhibition of the RTC previously initialised by 
> > temporarily setting the SET bit in Register B during bootstrap will 
> > disturb timekeeping that the system may carry over reset using 
> > adjtimex(8).
> 
> So you're instead suggesting to revoke a87ea88d8f6c ?
> 
> If YAMON and U-Boot are differing in RTC handling then I suggest to
> treat that as a U-Boot bug. YAMON was there first.

That would be fair enough, and is why I added RTC handling to Malta
U-boot at all. I could see logic in suggesting U-boot be changed to use
the binary mode instead of BCD. But...

> However these Malta kernels are also frequently booted without firmware
> in Qemu. No idea how Qemu initializes the RTC.

...kernels can also be booted on real Malta boards with minimal prodding
over JTAG, and the RTC is one more thing that you need to prod if the
kernel doesn't ensure it's running. That's what motivated a87ea88d8f6c
and the other patches from the same series at all.

Thanks,
    Paul

WARNING: multiple messages have this Message-ID (diff)
From: Paul Burton <paul.burton@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	James Hogan <james.hogan@imgtec.com>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH 1/2] MIPS: malta-time: Don't switch RTC to BCD mode
Date: Fri, 15 May 2015 19:14:13 +0100	[thread overview]
Message-ID: <20150515181413.GA30774@NP-P-BURTON> (raw)
Message-ID: <20150515181413.ZIXf1X8OEsd8C-lLkmZr7U1sb_CdrLgaTvthnLJLs3U@z> (raw)
In-Reply-To: <20150515180351.GE2322@linux-mips.org>

On Fri, May 15, 2015 at 08:03:51PM +0200, Ralf Baechle wrote:
> >  I'd prefer RTC state not to be touched at all if its state is sane.  
> > That is read Register B, check for the only valid divider setting 
> > (32kHz), and if so then exit right away, and otherwise initialise the 
> > chip from scratch.  Consistency with YAMON might be a good idea in that 
> > initialisation, but I have no strong feeling towards that.  If you think 
> > there's value in having the chip set to the BCD mode, then feel free to 
> > keep that option.
> > 
> >  Note that any inhibition of the RTC previously initialised by 
> > temporarily setting the SET bit in Register B during bootstrap will 
> > disturb timekeeping that the system may carry over reset using 
> > adjtimex(8).
> 
> So you're instead suggesting to revoke a87ea88d8f6c ?
> 
> If YAMON and U-Boot are differing in RTC handling then I suggest to
> treat that as a U-Boot bug. YAMON was there first.

That would be fair enough, and is why I added RTC handling to Malta
U-boot at all. I could see logic in suggesting U-boot be changed to use
the binary mode instead of BCD. But...

> However these Malta kernels are also frequently booted without firmware
> in Qemu. No idea how Qemu initializes the RTC.

...kernels can also be booted on real Malta boards with minimal prodding
over JTAG, and the RTC is one more thing that you need to prod if the
kernel doesn't ensure it's running. That's what motivated a87ea88d8f6c
and the other patches from the same series at all.

Thanks,
    Paul

  reply	other threads:[~2015-05-15 18:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 12:17 [PATCH 0/2] MIPS: malta-time: Take seconds into account James Hogan
2015-05-13 12:17 ` James Hogan
2015-05-13 12:17 ` [PATCH 1/2] MIPS: malta-time: Don't switch RTC to BCD mode James Hogan
2015-05-13 12:17   ` James Hogan
2015-05-13 18:03   ` Maciej W. Rozycki
2015-05-13 22:19     ` James Hogan
2015-05-13 22:19       ` James Hogan
2015-05-14  8:44       ` Paul Burton
2015-05-14  8:44         ` Paul Burton
2015-05-14 10:00         ` James Hogan
2015-05-14 10:00           ` James Hogan
2015-05-14 10:53           ` Maciej W. Rozycki
2015-05-15 18:03             ` Ralf Baechle
2015-05-15 18:14               ` Paul Burton [this message]
2015-05-15 18:14                 ` Paul Burton
2015-05-15 21:13                 ` Maciej W. Rozycki
2015-05-16  8:49                   ` Joshua Kinard
2015-05-13 12:17 ` [PATCH 2/2] MIPS: malta-time: Take seconds into account James Hogan
2015-05-13 12:17   ` James Hogan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150515181413.GA30774@NP-P-BURTON \
    --to=paul.burton@imgtec.com \
    --cc=james.hogan@imgtec.com \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox