Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

BTW, should this discussion not be moved to linuxppc mailing lists ?

On Wed, Dec 17, 2003 at 06:27:37PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2003-12-17 at 18:17, Lee Braiden wrote:
> > On Wednesday 17 Dec 2003 6:24 am, Benjamin Herrenschmidt wrote:
> > > CONFIG_RTC will definitely break a pmac
> >
> > I think I heard something about clock/timer problems on PPC a long time ago,
> > but could never track down an issue.  Wouldn't it be best to remove RTC on
> > PPC or document the problem with a (read help) or something?
> >
> > Is the PPC RTC (as opposed to GENERIC_RTC) stuff automatically in there, or
> > something?  Or is it this PPC_RTC that's broken?
>
> Well... CONFIG_RTC enables the "PC style" RTC driver that taps IO ports
> to look for an RTC chip of the kind found in x86 machines. Such a chip
> doesn't exist on powermac and this random IO port tapping can actually
> crash the machine.

And i guess that this PC style RTC is found on the southbridge, right ?
Let me check the VIA docs. Yep, it indeed is there, and i doubt that
there is another clock on the system. Not sure though.

> CONFIG_PPC_RTC/CONFIG_GENERIC_RTC is a different driver that provides
> the /dev/rtc interface but relies on hooks provided by the platform
> code for actually getting/setting the RTC content. The PowerMac platform
> provides hooks for the different kind of RTC chips found on Macs (that
> is basically  access to the RTC via via-cuda or via-pmu). CHRP or

Mmm, these are external via chips on mac hardware used for clocks ?

> PReP machines should provide their own hooks, it's possible that what
> CHRP provides doesn't work properly on the Pegasos, in which case we'd
> have to fix this.

Another solution would be to :

  1) build a pegasos specific config with CONFIG_RTC, but not the other
  two. <= Not good, since it would mean over one hour compil more, and
  one more binary packages. Already like that the ftp-masters are not
  happy.

  2) build all RTC stuff as modules, and let userland choose the one it
  needs.

  3) have CONFIG_RTC check the subarch or something and not work if it
  recognize hardware it doesn't know about or something.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Geert Uytterhoeven]

On Wed, 17 Dec 2003, Sven Luther wrote:
> On Wed, Dec 17, 2003 at 06:27:37PM +1100, Benjamin Herrenschmidt wrote:
> > CONFIG_PPC_RTC/CONFIG_GENERIC_RTC is a different driver that provides
> > the /dev/rtc interface but relies on hooks provided by the platform
> > code for actually getting/setting the RTC content. The PowerMac platform
> > provides hooks for the different kind of RTC chips found on Macs (that
> > is basically  access to the RTC via via-cuda or via-pmu). CHRP or
>
> Mmm, these are external via chips on mac hardware used for clocks ?

No, that's VIA as in Versatile Interface Adapter, not as in VIA Technologies.
It used to be a separate chip in the old 68000 days, but now it's integrated in
some Mac fabric (e.g. Mac I/O).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Segher Boessenkool]

> No, that's VIA as in Versatile Interface Adapter, not as in VIA
> Technologies.
> It used to be a separate chip in the old 68000 days, but now it's
> integrated in
> some Mac fabric (e.g. Mac I/O).

Actually, there is no RTC chip _at all_ in NewWorld Macs.  The PMU
itself keeps the time (from a 32768Hz clock).


Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Geert Uytterhoeven]

On Wed, 17 Dec 2003, Segher Boessenkool wrote:
> > No, that's VIA as in Versatile Interface Adapter, not as in VIA
> > Technologies.
> > It used to be a separate chip in the old 68000 days, but now it's
> > integrated in
> > some Mac fabric (e.g. Mac I/O).
>
> Actually, there is no RTC chip _at all_ in NewWorld Macs.  The PMU
> itself keeps the time (from a 32768Hz clock).

So from a technical point of view, the PMU is the RTC chip, right?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Segher Boessenkool]

>> Actually, there is no RTC chip _at all_ in NewWorld Macs.  The PMU
>> itself keeps the time (from a 32768Hz clock).
>
> So from a technical point of view, the PMU is the RTC chip, right?

Not really, it's a very different mechanism.  But you could say it
is yeah, if you don't mind being sloppy ;-)


Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Tom Rini]

On Wed, Dec 17, 2003 at 10:51:39AM +0100, Sven Luther wrote:
> BTW, should this discussion not be moved to linuxppc mailing lists ?
>
> On Wed, Dec 17, 2003 at 06:27:37PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2003-12-17 at 18:17, Lee Braiden wrote:
> > > On Wednesday 17 Dec 2003 6:24 am, Benjamin Herrenschmidt wrote:
> > > > CONFIG_RTC will definitely break a pmac
> > >
> > > I think I heard something about clock/timer problems on PPC a long time ago,
> > > but could never track down an issue.  Wouldn't it be best to remove RTC on
> > > PPC or document the problem with a (read help) or something?
> > >
> > > Is the PPC RTC (as opposed to GENERIC_RTC) stuff automatically in there, or
> > > something?  Or is it this PPC_RTC that's broken?
> >
> > Well... CONFIG_RTC enables the "PC style" RTC driver that taps IO ports
> > to look for an RTC chip of the kind found in x86 machines. Such a chip
> > doesn't exist on powermac and this random IO port tapping can actually
> > crash the machine.
>
> And i guess that this PC style RTC is found on the southbridge, right ?
> Let me check the VIA docs. Yep, it indeed is there, and i doubt that
> there is another clock on the system. Not sure though.
>
> > CONFIG_PPC_RTC/CONFIG_GENERIC_RTC is a different driver that provides
> > the /dev/rtc interface but relies on hooks provided by the platform
> > code for actually getting/setting the RTC content. The PowerMac platform
> > provides hooks for the different kind of RTC chips found on Macs (that
> > is basically  access to the RTC via via-cuda or via-pmu). CHRP or
>
> Mmm, these are external via chips on mac hardware used for clocks ?
>
> > PReP machines should provide their own hooks, it's possible that what
> > CHRP provides doesn't work properly on the Pegasos, in which case we'd
> > have to fix this.
>
> Another solution would be to :
>
>   1) build a pegasos specific config with CONFIG_RTC, but not the other
>   two. <= Not good, since it would mean over one hour compil more, and
>   one more binary packages. Already like that the ftp-masters are not
>   happy.
>
>   2) build all RTC stuff as modules, and let userland choose the one it
>   needs.
>
>   3) have CONFIG_RTC check the subarch or something and not work if it
>   recognize hardware it doesn't know about or something.

4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> 4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
> is that chrp_get_rtc_time is 'funky' and not quite right for anything
> other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
> looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.

Ok, thanks, i will look into it.

But then, remember, this is for the debian powerpc kernel, and has to be
2.4.x still for now.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Tom Rini]

On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
>
> On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> > 4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
> > is that chrp_get_rtc_time is 'funky' and not quite right for anything
> > other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
> > looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> > into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
>
> Ok, thanks, i will look into it.
>
> But then, remember, this is for the debian powerpc kernel, and has to be
> 2.4.x still for now.

Yes.  The code in <asm-generic/rtc.h> is taken right from
drivers/char/rtc.c.  It just didn't get sent to 2.4 for some reason.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
> On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
> >
> > On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> > > 4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
> > > is that chrp_get_rtc_time is 'funky' and not quite right for anything
> > > other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
> > > looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> > > into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
> >
> > Ok, thanks, i will look into it.
> >
> > But then, remember, this is for the debian powerpc kernel, and has to be
> > 2.4.x still for now.
>
> Yes.  The code in <asm-generic/rtc.h> is taken right from
> drivers/char/rtc.c.  It just didn't get sent to 2.4 for some reason.

Ok, will do this tomorrow, thanks for your help.

BTW, in this case, would it make sense to hide the CONFIG_RTC on powerpc ?

Amicalement,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Tom Rini]

On Wed, Dec 17, 2003 at 06:10:52PM +0100, Sven Luther wrote:

>
> On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
> > On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
> > >
> > > On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> > > > 4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
> > > > is that chrp_get_rtc_time is 'funky' and not quite right for anything
> > > > other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
> > > > looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> > > > into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
> > >
> > > Ok, thanks, i will look into it.
> > >
> > > But then, remember, this is for the debian powerpc kernel, and has to be
> > > 2.4.x still for now.
> >
> > Yes.  The code in <asm-generic/rtc.h> is taken right from
> > drivers/char/rtc.c.  It just didn't get sent to 2.4 for some reason.
>
> Ok, will do this tomorrow, thanks for your help.
>
> BTW, in this case, would it make sense to hide the CONFIG_RTC on powerpc ?

iff we get it working on chrp properly and someone adds the alarm
functionality, it shouldn't be objectionable.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
>
> On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
> >
> > On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> > > 4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
> > > is that chrp_get_rtc_time is 'funky' and not quite right for anything
> > > other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
> > > looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> > > into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
> >
> > Ok, thanks, i will look into it.
> >
> > But then, remember, this is for the debian powerpc kernel, and has to be
> > 2.4.x still for now.
>
> Yes.  The code in <asm-generic/rtc.h> is taken right from
> drivers/char/rtc.c.  It just didn't get sent to 2.4 for some reason.

Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
set_rtc_time function.

BTW, what exactly should i do in 'chrp_get_rtc_time' and
'chrp_set_rtc_time' ? Just replace the existing code, or make a new
function, and set it depending on machine type who needs it in
chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
have to set ppc_md.set_rtc_time accordyingly.

This is still with the 2.4.x code base.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Tom Rini]

On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
> On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
> >
> > On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
> > >
> > > On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> > > > 4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
> > > > is that chrp_get_rtc_time is 'funky' and not quite right for anything
> > > > other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
> > > > looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> > > > into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
> > >
> > > Ok, thanks, i will look into it.
> > >
> > > But then, remember, this is for the debian powerpc kernel, and has to be
> > > 2.4.x still for now.
> >
> > Yes.  The code in <asm-generic/rtc.h> is taken right from
> > drivers/char/rtc.c.  It just didn't get sent to 2.4 for some reason.
>
> Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
> set_rtc_time function.

Nope, that's why I suggested 2.6's <asm-generic/rtc.h> :)

> BTW, what exactly should i do in 'chrp_get_rtc_time' and
> 'chrp_set_rtc_time' ? Just replace the existing code, or make a new
> function, and set it depending on machine type who needs it in
> chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
> have to set ppc_md.set_rtc_time accordyingly.

My preferance would be to replace, and then see if it breaks some other
chrp machines (it really shouldn't).

Something that just dawned on me again (sorry) is that I've really really
intended to try and kill both prep_time.c and chrp_time.c (since both of
those machine subtypes have PC-style RTC chips) and make them use
todc_time.c (see arch/ppc/kernel/todc_time.c).  I've got patches to do
half of this, against 2.6 (which was a trivial forward port of older
2.4-based patches I had, there is nothing 2.6-specific about these
patches).  You would want to look at:
006-redo_inb_inw_inl_outb_outw_outl.patch
007-make_out_8_and_friends_synchronous.patch
008-todc_warning.patch
009-prep_time_death-GNU.patch
from http://stop.crashing.org:16080/~trini/

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Fri, Dec 19, 2003 at 09:28:00AM -0700, Tom Rini wrote:
>
> On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
> > On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
> > >
> > > On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
> > > >
> > > > On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> > > > > 4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
> > > > > is that chrp_get_rtc_time is 'funky' and not quite right for anything
> > > > > other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
> > > > > looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> > > > > into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
> > > >
> > > > Ok, thanks, i will look into it.
> > > >
> > > > But then, remember, this is for the debian powerpc kernel, and has to be
> > > > 2.4.x still for now.
> > >
> > > Yes.  The code in <asm-generic/rtc.h> is taken right from
> > > drivers/char/rtc.c.  It just didn't get sent to 2.4 for some reason.
> >
> > Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
> > set_rtc_time function.
>
> Nope, that's why I suggested 2.6's <asm-generic/rtc.h> :)

Ok.

> > BTW, what exactly should i do in 'chrp_get_rtc_time' and
> > 'chrp_set_rtc_time' ? Just replace the existing code, or make a new
> > function, and set it depending on machine type who needs it in
> > chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
> > have to set ppc_md.set_rtc_time accordyingly.
>
> My preferance would be to replace, and then see if it breaks some other
> chrp machines (it really shouldn't).

Ok, fine, altough i don't have an idea about the other chrp machine
types out there. From what i know from Geert, generic RTC is already not working
for its box anyway.

> Something that just dawned on me again (sorry) is that I've really really
> intended to try and kill both prep_time.c and chrp_time.c (since both of
> those machine subtypes have PC-style RTC chips) and make them use
> todc_time.c (see arch/ppc/kernel/todc_time.c).  I've got patches to do
> half of this, against 2.6 (which was a trivial forward port of older
> 2.4-based patches I had, there is nothing 2.6-specific about these
> patches).  You would want to look at:
> 006-redo_inb_inw_inl_outb_outw_outl.patch
> 007-make_out_8_and_friends_synchronous.patch
> 008-todc_warning.patch
> 009-prep_time_death-GNU.patch
> from http://stop.crashing.org:16080/~trini/

Mmm, i am somewhat confused now on what to do.

If i understood things tight, you either want to :

  1) replace ppc.md chrp time stuff with similar code than what
  asm-generic/rtc.h is doing.

  2) use todc.h for all of prep/chrp.

In the first case, i guess that is easy, and may break some chrp boxes
not using a compatible clock, which may or may not exist.

In the second case, well, the todc code makes use of nvram_write, which
unless i am wrong, is not defined on chrp. the RTC code uses CMOS_WRITE,
so maybe i should define a chrp_write wrapping this one.

Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said to be called VT82887, altough i have no docs of
those, but the header files found in 2.6 concord. But i seem to have
some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
found int the MC146818 header file.

So, what did you have in mind for this.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Tom Rini]

On Mon, Dec 22, 2003 at 02:45:04PM +0100, Sven Luther wrote:

> On Fri, Dec 19, 2003 at 09:28:00AM -0700, Tom Rini wrote:
> >
> > On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
> > > On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
> > > >
> > > > On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
> > > > >
> > > > > On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> > > > > > 4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
> > > > > > is that chrp_get_rtc_time is 'funky' and not quite right for anything
> > > > > > other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
> > > > > > looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> > > > > > into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
> > > > >
> > > > > Ok, thanks, i will look into it.
> > > > >
> > > > > But then, remember, this is for the debian powerpc kernel, and has to be
> > > > > 2.4.x still for now.
> > > >
> > > > Yes.  The code in <asm-generic/rtc.h> is taken right from
> > > > drivers/char/rtc.c.  It just didn't get sent to 2.4 for some reason.
> > >
> > > Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
> > > set_rtc_time function.
> >
> > Nope, that's why I suggested 2.6's <asm-generic/rtc.h> :)
>
> Ok.
>
> > > BTW, what exactly should i do in 'chrp_get_rtc_time' and
> > > 'chrp_set_rtc_time' ? Just replace the existing code, or make a new
> > > function, and set it depending on machine type who needs it in
> > > chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
> > > have to set ppc_md.set_rtc_time accordyingly.
> >
> > My preferance would be to replace, and then see if it breaks some other
> > chrp machines (it really shouldn't).
>
> Ok, fine, altough i don't have an idea about the other chrp machine
> types out there. From what i know from Geert, generic RTC is already not working
> for its box anyway.
>
> > Something that just dawned on me again (sorry) is that I've really really
> > intended to try and kill both prep_time.c and chrp_time.c (since both of
> > those machine subtypes have PC-style RTC chips) and make them use
> > todc_time.c (see arch/ppc/kernel/todc_time.c).  I've got patches to do
> > half of this, against 2.6 (which was a trivial forward port of older
> > 2.4-based patches I had, there is nothing 2.6-specific about these
> > patches).  You would want to look at:
> > 006-redo_inb_inw_inl_outb_outw_outl.patch
> > 007-make_out_8_and_friends_synchronous.patch
> > 008-todc_warning.patch
> > 009-prep_time_death-GNU.patch
> > from http://stop.crashing.org:16080/~trini/
>
> Mmm, i am somewhat confused now on what to do.
>
> If i understood things tight, you either want to :
>
>   1) replace ppc.md chrp time stuff with similar code than what
>   asm-generic/rtc.h is doing.
>
>   2) use todc.h for all of prep/chrp.
>
> In the first case, i guess that is easy, and may break some chrp boxes
> not using a compatible clock, which may or may not exist.
>
> In the second case, well, the todc code makes use of nvram_write, which
> unless i am wrong, is not defined on chrp. the RTC code uses CMOS_WRITE,
> so maybe i should define a chrp_write wrapping this one.
>
> Also, the todc code knows about many RTC chips, among them, the MC146818
> seems to be the one used by the rtc.h stuff, and seems to be a generic
> legacy RTC chip or something. he one i have, builtin the VIA VT8231
> southbridge is said to be called VT82887, altough i have no docs of
> those, but the header files found in 2.6 concord. But i seem to have
> some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
> found int the MC146818 header file.

I appologize since I ramble a bit too much.  For 2.4, the best fix is
(1) above.  For 2.6 however, it should be possible to remove chrp_time.c
and use todc_time.c instead (it is self-contained, wrt nvram read/write,
iirc) and do some sub-casing to pick the right RTC chip code to use.
For example on PReP we still case between the two different chips, and
just call todc_init (iirc) with a different param.  Or something along
those lines.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
> > Also, the todc code knows about many RTC chips, among them, the MC146818
> > seems to be the one used by the rtc.h stuff, and seems to be a generic
> > legacy RTC chip or something. he one i have, builtin the VIA VT8231
> > southbridge is said to be called VT82887, altough i have no docs of
> > those, but the header files found in 2.6 concord. But i seem to have
> > some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
> > found int the MC146818 header file.
>
> I appologize since I ramble a bit too much.  For 2.4, the best fix is
> (1) above.  For 2.6 however, it should be possible to remove chrp_time.c
> and use todc_time.c instead (it is self-contained, wrt nvram read/write,
> iirc) and do some sub-casing to pick the right RTC chip code to use.
> For example on PReP we still case between the two different chips, and
> just call todc_init (iirc) with a different param.  Or something along
> those lines.

Ok, i have looked more, and the MC146818 is ok for my box. don't know
about other chrp boxes though.

There is also the todc code in the 2.4 tree though, so it should also be
possible to do it this way, or would it not ?

Anyway, i will submit a patch against 2.4.23 (from linuxppc_2_4, but it
may also include the pegasos patches Ben has had no time to checkin)
tomorrow.

Next thing i need is a solution for builtin initrd's of bigger sizes.
1.4Mo seem to work, but 2.2Mo break somehow (no init found, but if the
initrd is uncompressed to some partition, it work fine).

Either that or support for standalone initrd on the disk.

Any idea on how to do this ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Tom Rini]

On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:

> On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
> > > Also, the todc code knows about many RTC chips, among them, the MC146818
> > > seems to be the one used by the rtc.h stuff, and seems to be a generic
> > > legacy RTC chip or something. he one i have, builtin the VIA VT8231
> > > southbridge is said to be called VT82887, altough i have no docs of
> > > those, but the header files found in 2.6 concord. But i seem to have
> > > some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
> > > found int the MC146818 header file.
> >
> > I appologize since I ramble a bit too much.  For 2.4, the best fix is
> > (1) above.  For 2.6 however, it should be possible to remove chrp_time.c
> > and use todc_time.c instead (it is self-contained, wrt nvram read/write,
> > iirc) and do some sub-casing to pick the right RTC chip code to use.
> > For example on PReP we still case between the two different chips, and
> > just call todc_init (iirc) with a different param.  Or something along
> > those lines.
>
> Ok, i have looked more, and the MC146818 is ok for my box. don't know
> about other chrp boxes though.
>
> There is also the todc code in the 2.4 tree though, so it should also be
> possible to do it this way, or would it not ?

It would be possible, but it would be more intrusive for a stable
series.

> Anyway, i will submit a patch against 2.4.23 (from linuxppc_2_4, but it
> may also include the pegasos patches Ben has had no time to checkin)
> tomorrow.
>
> Next thing i need is a solution for builtin initrd's of bigger sizes.
> 1.4Mo seem to work, but 2.2Mo break somehow (no init found, but if the
> initrd is uncompressed to some partition, it work fine).

which code subset under arch/ppc/boot does pegasos use?  Does it really
have OpenFirmware?  I've booted large ramdisks in the past from the
arch/ppc/boot/simple/ stuff (And prep/) but I believe that chrp/pmac
place the initrd at a location high in memory, have holes to deal with,
etc, etc, while simple/ and prep/ (more or less) just ignore the
firmware once it's up.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Mon, Dec 22, 2003 at 09:33:15AM -0700, Tom Rini wrote:
> On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
>
> > On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
> > > > Also, the todc code knows about many RTC chips, among them, the MC146818
> > > > seems to be the one used by the rtc.h stuff, and seems to be a generic
> > > > legacy RTC chip or something. he one i have, builtin the VIA VT8231
> > > > southbridge is said to be called VT82887, altough i have no docs of
> > > > those, but the header files found in 2.6 concord. But i seem to have
> > > > some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
> > > > found int the MC146818 header file.
> > >
> > > I appologize since I ramble a bit too much.  For 2.4, the best fix is
> > > (1) above.  For 2.6 however, it should be possible to remove chrp_time.c
> > > and use todc_time.c instead (it is self-contained, wrt nvram read/write,
> > > iirc) and do some sub-casing to pick the right RTC chip code to use.
> > > For example on PReP we still case between the two different chips, and
> > > just call todc_init (iirc) with a different param.  Or something along
> > > those lines.
> >
> > Ok, i have looked more, and the MC146818 is ok for my box. don't know
> > about other chrp boxes though.
> >
> > There is also the todc code in the 2.4 tree though, so it should also be
> > possible to do it this way, or would it not ?
>
> It would be possible, but it would be more intrusive for a stable
> series.

Ok, i will do it the rtc.h way then, and see what happens.

> > Anyway, i will submit a patch against 2.4.23 (from linuxppc_2_4, but it
> > may also include the pegasos patches Ben has had no time to checkin)
> > tomorrow.
> >
> > Next thing i need is a solution for builtin initrd's of bigger sizes.
> > 1.4Mo seem to work, but 2.2Mo break somehow (no init found, but if the
> > initrd is uncompressed to some partition, it work fine).
>
> which code subset under arch/ppc/boot does pegasos use?

it is mostly a chrp, except for a few lines patch needed for things as
pci indirection and other such.

> Does it really have OpenFirmware?

Yeah, and i even have the source of it (not free software though). OF
coding is a nightmare though.

> I've booted large ramdisks in the past from the
> arch/ppc/boot/simple/ stuff (And prep/) but I believe that chrp/pmac

Ok.

> place the initrd at a location high in memory, have holes to deal with,

Mmm, indeed the initrd is moved to RAM_END - initrd_size by
arch/ppc/boot/chrp/main.c:chrpboot, where RAM_END is defined as 64<<20
(which is 64Mo and i have 128Mo). the pmac chrp boot uses only 16<<20.

Mmm, maybe arch/ppc/kernel/setup.c:plafrom_init does contain only stuff
for prep, not chrp, not sure, chrp_init.c in chrp_setup.c does use r6
and r7 for determining the initrd location and size.

Actually, i don't really know enough about this to fix this issue alone,
i have no knowledge of the holes you speak about for example :((

Time for more kernel source reading then :))

> etc, etc, while simple/ and prep/ (more or less) just ignore the
> firmware once it's up.

Mmm I didn't know about simple, what subarches use that one exactly ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Tom Rini]

On Mon, Dec 22, 2003 at 05:48:22PM +0100, Sven Luther wrote:
> On Mon, Dec 22, 2003 at 09:33:15AM -0700, Tom Rini wrote:
> > On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
> >
> > > On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
> > > > > Also, the todc code knows about many RTC chips, among them, the MC146818
> > > > > seems to be the one used by the rtc.h stuff, and seems to be a generic
> > > > > legacy RTC chip or something. he one i have, builtin the VIA VT8231
> > > > > southbridge is said to be called VT82887, altough i have no docs of
> > > > > those, but the header files found in 2.6 concord. But i seem to have
> > > > > some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
> > > > > found int the MC146818 header file.
> > > >
> > > > I appologize since I ramble a bit too much.  For 2.4, the best fix is
> > > > (1) above.  For 2.6 however, it should be possible to remove chrp_time.c
> > > > and use todc_time.c instead (it is self-contained, wrt nvram read/write,
> > > > iirc) and do some sub-casing to pick the right RTC chip code to use.
> > > > For example on PReP we still case between the two different chips, and
> > > > just call todc_init (iirc) with a different param.  Or something along
> > > > those lines.
> > >
> > > Ok, i have looked more, and the MC146818 is ok for my box. don't know
> > > about other chrp boxes though.
> > >
> > > There is also the todc code in the 2.4 tree though, so it should also be
> > > possible to do it this way, or would it not ?
> >
> > It would be possible, but it would be more intrusive for a stable
> > series.
>
> Ok, i will do it the rtc.h way then, and see what happens.
>
> > > Anyway, i will submit a patch against 2.4.23 (from linuxppc_2_4, but it
> > > may also include the pegasos patches Ben has had no time to checkin)
> > > tomorrow.
> > >
> > > Next thing i need is a solution for builtin initrd's of bigger sizes.
> > > 1.4Mo seem to work, but 2.2Mo break somehow (no init found, but if the
> > > initrd is uncompressed to some partition, it work fine).
> >
> > which code subset under arch/ppc/boot does pegasos use?
>
> it is mostly a chrp, except for a few lines patch needed for things as
> pci indirection and other such.
>
> > Does it really have OpenFirmware?
>
> Yeah, and i even have the source of it (not free software though). OF
> coding is a nightmare though.
>
> > I've booted large ramdisks in the past from the
> > arch/ppc/boot/simple/ stuff (And prep/) but I believe that chrp/pmac
>
> Ok.
>
> > place the initrd at a location high in memory, have holes to deal with,
>
> Mmm, indeed the initrd is moved to RAM_END - initrd_size by
> arch/ppc/boot/chrp/main.c:chrpboot, where RAM_END is defined as 64<<20
> (which is 64Mo and i have 128Mo). the pmac chrp boot uses only 16<<20.

Which introduces a (potential) problem of the initrd growing down into
the kernel, for very large initrds.  I don't recall why it's done this
way here.

> Mmm, maybe arch/ppc/kernel/setup.c:plafrom_init does contain only stuff
> for prep, not chrp, not sure, chrp_init.c in chrp_setup.c does use r6
> and r7 for determining the initrd location and size.

One potential problem is that perhaps chrp hasn't been updated to prefer
(or the boot/ code updated) to use BI_INITRD stuff, ala simple/ and
prep/, and perhaps there's still someone assuming that it's being passed
in start/end, not start/size information.

> Actually, i don't really know enough about this to fix this issue alone,
> i have no knowledge of the holes you speak about for example :((

The holes would be in OF itself.  IIRC this is true of some oldworld
pmacs for example.

> > etc, etc, while simple/ and prep/ (more or less) just ignore the
> > firmware once it's up.
>
> Mmm I didn't know about simple, what subarches use that one exactly ?

Everything that's not a pmac or a chrp (I've used it on a non-OF PReP
before, and the code is awful close).

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Mark Guertin]

On 22-Dec-03, at 11:48 AM, Sven Luther wrote:

>> Does it really have OpenFirmware?
>
> Yeah, and i even have the source of it (not free software though). OF
> coding is a nightmare though.

It's not really OpenFirmware ... it's SmartFirmware is it not?  it's
sort of an open firmware/openboot derivative...

Slightly OT, but Sven, is there access to /dev/nvram available yet on
pegasos?  I've still got a forth bootloader menu somewhere here that I
made for the pegasos, which I've never been able to load (without
massive typing at SF prompt)...but my pegasos is non functional so I
may find it this week and email the file to you to fight with :)

Gerk


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Mon, Dec 22, 2003 at 12:02:43PM -0500, Mark Guertin wrote:
>
> On 22-Dec-03, at 11:48 AM, Sven Luther wrote:
>
> >>Does it really have OpenFirmware?
> >
> >Yeah, and i even have the source of it (not free software though). OF
> >coding is a nightmare though.
>
> It's not really OpenFirmware ... it's SmartFirmware is it not?  it's

Yes, it is based on SmartFirmware.

> Slightly OT, but Sven, is there access to /dev/nvram available yet on

No, there is no /dev/nvram, i don't believe there ever will be, not
sure. I think there is no physical nvram for such a device in the
hardware.

> pegasos?  I've still got a forth bootloader menu somewhere here that I
> made for the pegasos, which I've never been able to load (without
> massive typing at SF prompt)...but my pegasos is non functional so I
> may find it this week and email the file to you to fight with :)

Well, my own solution to this, is to implement the boot loader thingy
directly in the OS/SF/whatever. My plan is to have a function to read a
file on disk, which would contain a grub like format (i like it more
than yaboot/lilo like format) and construct a boot-loader menu from
this.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Mon, Dec 22, 2003 at 09:33:15AM -0700, Tom Rini wrote:
>
> On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
>
> > On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
> > > > Also, the todc code knows about many RTC chips, among them, the MC146818
> > > > seems to be the one used by the rtc.h stuff, and seems to be a generic
> > > > legacy RTC chip or something. he one i have, builtin the VIA VT8231
> > > > southbridge is said to be called VT82887, altough i have no docs of
> > > > those, but the header files found in 2.6 concord. But i seem to have
> > > > some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
> > > > found int the MC146818 header file.
> > >
> > > I appologize since I ramble a bit too much.  For 2.4, the best fix is
> > > (1) above.  For 2.6 however, it should be possible to remove chrp_time.c
> > > and use todc_time.c instead (it is self-contained, wrt nvram read/write,
> > > iirc) and do some sub-casing to pick the right RTC chip code to use.
> > > For example on PReP we still case between the two different chips, and
> > > just call todc_init (iirc) with a different param.  Or something along
> > > those lines.
> >
> > Ok, i have looked more, and the MC146818 is ok for my box. don't know
> > about other chrp boxes though.
> >
> > There is also the todc code in the 2.4 tree though, so it should also be
> > possible to do it this way, or would it not ?
>
> It would be possible, but it would be more intrusive for a stable
> series.

BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.

Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence of a pmac in the CONFIG_RTC code, and abort
if one is found ?

If so, what would be the best way to test for a pmac subarch in the
drivers/char/rtc.c code ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Benjamin Herrenschmidt]

> BTW, i didn't manage to get the generic RTC code working on my pegasos,
> and i am actually a bit pressed for time.
>
> Do you think a workaround, for the debian powerpc packages, would be to
> add a test for the presence of a pmac in the CONFIG_RTC code, and abort
> if one is found ?
>
> If so, what would be the best way to test for a pmac subarch in the
> drivers/char/rtc.c code ?

will the kernel let you build both drivers in ?

then you can do, in 2.4, something ugly like that:

#ifdef CONFIG_ALL_PPC
if (_machine == _MACH_Pmac)
	return -ENODEV;
#endif

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
>
> > BTW, i didn't manage to get the generic RTC code working on my pegasos,
> > and i am actually a bit pressed for time.
> >
> > Do you think a workaround, for the debian powerpc packages, would be to
> > add a test for the presence of a pmac in the CONFIG_RTC code, and abort
> > if one is found ?
> >
> > If so, what would be the best way to test for a pmac subarch in the
> > drivers/char/rtc.c code ?
>
> will the kernel let you build both drivers in ?

Yes, sure. But naturally they die horribly on pmac hardware, or so i am
told.

> then you can do, in 2.4, something ugly like that:
>
> #ifdef CONFIG_ALL_PPC
> if (_machine == _MACH_Pmac)
> 	return -ENODEV;
> #endif

Ok, cool, will try that out.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
>
> > BTW, i didn't manage to get the generic RTC code working on my pegasos,
> > and i am actually a bit pressed for time.
> >
> > Do you think a workaround, for the debian powerpc packages, would be to
> > add a test for the presence of a pmac in the CONFIG_RTC code, and abort
> > if one is found ?
> >
> > If so, what would be the best way to test for a pmac subarch in the
> > drivers/char/rtc.c code ?
>
> will the kernel let you build both drivers in ?
>
> then you can do, in 2.4, something ugly like that:
>
> #ifdef CONFIG_ALL_PPC
> if (_machine == _MACH_Pmac)
> 	return -ENODEV;
> #endif

Mmm, two questions :

 1) could a #ifdef __powerpc__ not be enough ?

 2) The other failures in rtc_init return -EIO, not -ENODEV.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Benjamin Herrenschmidt]

>  1) could a #ifdef __powerpc__ not be enough ?

No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)

>  2) The other failures in rtc_init return -EIO, not -ENODEV.

Well, in this case, -ENODEV makes more sense, though nothing really
cares except the kind of error message the user will get when using
it as a module.

> Friendly,
>
> Sven Luther
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
>
> >  1) could a #ifdef __powerpc__ not be enough ?
>
> No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)

Ok. I suppose it doesn't make sense also to include the #ifdef
CONFIG_ALL_PPC in a #ifdef __powerpc__ ?

> >  2) The other failures in rtc_init return -EIO, not -ENODEV.
>
> Well, in this case, -ENODEV makes more sense, though nothing really
> cares except the kind of error message the user will get when using
> it as a module.

I think i will keep it as the others for the debian package.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Benjamin Herrenschmidt]

On Wed, 2004-01-07 at 20:53, Sven Luther wrote:
> On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
> >
> > >  1) could a #ifdef __powerpc__ not be enough ?
> >
> > No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)
>
> Ok. I suppose it doesn't make sense also to include the #ifdef
> CONFIG_ALL_PPC in a #ifdef __powerpc__ ?

Yup, useless to stack them.

> > >  2) The other failures in rtc_init return -EIO, not -ENODEV.
> >
> > Well, in this case, -ENODEV makes more sense, though nothing really
> > cares except the kind of error message the user will get when using
> > it as a module.
>
> I think i will keep it as the others for the debian package.

Why ? The error is definitely not an IO error :) Nothing really relies
on this error code anyway...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Wed, Jan 07, 2004 at 09:44:28PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2004-01-07 at 20:53, Sven Luther wrote:
> > On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
> > >
> > > >  1) could a #ifdef __powerpc__ not be enough ?
> > >
> > > No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)
> >
> > Ok. I suppose it doesn't make sense also to include the #ifdef
> > CONFIG_ALL_PPC in a #ifdef __powerpc__ ?
>
> Yup, useless to stack them.
>
> > > >  2) The other failures in rtc_init return -EIO, not -ENODEV.
> > >
> > > Well, in this case, -ENODEV makes more sense, though nothing really
> > > cares except the kind of error message the user will get when using
> > > it as a module.
> >
> > I think i will keep it as the others for the debian package.
>
> Why ? The error is definitely not an IO error :) Nothing really relies
> on this error code anyway...

So, would it be meaningfull to change all the others to NODEV too ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Benjamin Herrenschmidt]

>
> So, would it be meaningfull to change all the others to NODEV too ?

You are beeing anal or what ? :)

Who cares about that legacy driver in 2.4 anyway :)

If you really want, I suppose the failure on request_region could
return -EBUSY, not sure about the best error to return from failures
on request_irq...

Nobody really cares about those codes though. At least not in this driver.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Wed, Jan 07, 2004 at 10:47:37PM +1100, Benjamin Herrenschmidt wrote:
>
> >
> > So, would it be meaningfull to change all the others to NODEV too ?
>
> You are beeing anal or what ? :)
>
> Who cares about that legacy driver in 2.4 anyway :)
>
> If you really want, I suppose the failure on request_region could
> return -EBUSY, not sure about the best error to return from failures
> on request_irq...
>
> Nobody really cares about those codes though. At least not in this driver.

Ok, i will return whatever you want, and we don't really care about the
code, provided it boots ok, doesn't hang the powermacs at hwclock
invocation time, and clock works for them.

Still in search for a volunteer.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Tom Rini]

On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
>
> >  1) could a #ifdef __powerpc__ not be enough ?
>
> No. _machine is only defined for the "multiarch" config (PREP/CHRP/PMAC)

Technically it's '0' on !CONFIG_ALL_PPC, but (for the sake of fullness)
I don't know if ppc64 defines __powerpc__ :)

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Ethan Benson]

On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
>
> > BTW, i didn't manage to get the generic RTC code working on my
> > pegasos, and i am actually a bit pressed for time.
> >
> > Do you think a workaround, for the debian powerpc packages, would be
> > to add a test for the presence of a pmac in the CONFIG_RTC code, and
> > abort if one is found ?
> >
> > If so, what would be the best way to test for a pmac subarch in the
> > drivers/char/rtc.c code ?
>
> will the kernel let you build both drivers in ?

yes, which will cause all powermacs to hang on bootup when hwclock is run.

> then you can do, in 2.4, something ugly like that:
>
> #ifdef CONFIG_ALL_PPC
> if (_machine == _MACH_Pmac)
> 	return -ENODEV;
> #endif

which im betting will instead cause hwclock to fail on all powermacs
with: hwclock: /dev/rtc: No such device

but i could be missing something obvious with your suggestion.

--
Ethan Benson
http://www.alaska.net/~erbenson/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Volunteer needed : Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Tue, Jan 06, 2004 at 10:51:51PM -0900, Ethan Benson wrote:
> On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
> >
> > > BTW, i didn't manage to get the generic RTC code working on my pegasos,
> > > and i am actually a bit pressed for time.
> > >
> > > Do you think a workaround, for the debian powerpc packages, would be to
> > > add a test for the presence of a pmac in the CONFIG_RTC code, and abort
> > > if one is found ?
> > >
> > > If so, what would be the best way to test for a pmac subarch in the
> > > drivers/char/rtc.c code ?
> >
> > will the kernel let you build both drivers in ?
>
> yes, which will cause all powermacs to hang on bootup when hwclock is run.

Yeah, that i know, and want to workaround.

> > then you can do, in 2.4, something ugly like that:
> >
> > #ifdef CONFIG_ALL_PPC
> > if (_machine == _MACH_Pmac)
> > 	return -ENODEV;
> > #endif
>
> which im betting will instead cause hwclock to fail on all powermacs
> with: hwclock: /dev/rtc: No such device

Mmm, notice that this is the rtc_init code, not the rtc ioctl's
themself. In my understanding this is launched when the kernel is
loaded, and is used to setup the rtc clock. If it fails, then no harm
should be done, since the generic rtc driver should take over, not sure
though.

> but i could be missing something obvious with your suggestion.

Maybe. i need someone who would like to test this. Do you volunteer ?

Below is my current patch. Please someone with pmac hardware, please
build a kernel with this applied and the CONFIG_RTC enabled in the
character driver section and report back to me. It would be nice if i
could upload a package which includes this fix today yet.

------------------- patch ------------------------
--- drivers/char/rtc.c.orig	2003-11-29 18:54:39.000000000 +0100
+++ drivers/char/rtc.c	2004-01-07 08:59:28.000000000 +0100
@@ -707,6 +707,12 @@
 #endif
 #endif

+#ifdef CONFIG_ALL_PPC
+	/* This driver will make pmac hardware die horribly */
+	if (_machine == _MACH_Pmac)
+		return -EIO;
+#endif
+
 #ifdef __sparc__
 	for_each_ebus(ebus) {
 		for_each_ebusdev(edev, ebus) {
------------------- patch ------------------------

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Volunteer needed : Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Ethan Benson]

On Wed, Jan 07, 2004 at 12:27:26PM +0100, Sven Luther wrote:
>
> Mmm, notice that this is the rtc_init code, not the rtc ioctl's
> themself. In my understanding this is launched when the kernel is
> loaded, and is used to setup the rtc clock. If it fails, then no harm
> should be done, since the generic rtc driver should take over, not sure
> though.

sounds iffy to me.  especially if both are compiled as modules, in
which case the rtc module will be loaded, fail and im betting the
whole thing stops right there.

debian used to ship kernels with both PPC_RTC and RTC as modules,
hoping the right one would magically load and work on the right
hardware, of couse this was not the case, RTC was always loaded, and
broke powermacs.

> > but i could be missing something obvious with your suggestion.
>
> Maybe. i need someone who would like to test this. Do you volunteer ?

i don't have time, sorry.

> Below is my current patch. Please someone with pmac hardware, please
> build a kernel with this applied and the CONFIG_RTC enabled in the
> character driver section and report back to me. It would be nice if i
> could upload a package which includes this fix today yet.
>
> ------------------- patch ------------------------
> --- drivers/char/rtc.c.orig	2003-11-29 18:54:39.000000000 +0100
> +++ drivers/char/rtc.c	2004-01-07 08:59:28.000000000 +0100
> @@ -707,6 +707,12 @@
>  #endif
>  #endif
>
> +#ifdef CONFIG_ALL_PPC
> +	/* This driver will make pmac hardware die horribly */
> +	if (_machine == _MACH_Pmac)
> +		return -EIO;
> +#endif
> +
>  #ifdef __sparc__
>  	for_each_ebus(ebus) {
>  		for_each_ebusdev(edev, ebus) {
> ------------------- patch ------------------------
>
> Friendly,
>
> Sven Luther
>

--
Ethan Benson
http://www.alaska.net/~erbenson/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Volunteer needed : Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Wed, Jan 07, 2004 at 03:28:28AM -0900, Ethan Benson wrote:
>
> On Wed, Jan 07, 2004 at 12:27:26PM +0100, Sven Luther wrote:
> >
> > Mmm, notice that this is the rtc_init code, not the rtc ioctl's
> > themself. In my understanding this is launched when the kernel is
> > loaded, and is used to setup the rtc clock. If it fails, then no harm
> > should be done, since the generic rtc driver should take over, not sure
> > though.
>
> sounds iffy to me.  especially if both are compiled as modules, in
> which case the rtc module will be loaded, fail and im betting the
> whole thing stops right there.

Yeah, not sure also, need a volunteer to test it.

> debian used to ship kernels with both PPC_RTC and RTC as modules,
> hoping the right one would magically load and work on the right
> hardware, of couse this was not the case, RTC was always loaded, and
> broke powermacs.

Yeah, but this was because the RTC driver does some rtc register probing
the pmac hardware does not like. If the RTC clock detects it is a pmac,
it will fail to initialize before causing damage.

The worse that can happen is the GENERIC_RTC driver not being
initialized because linux believes the RTC driver should be ok.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Volunteer needed : Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Ethan Benson]

On Wed, Jan 07, 2004 at 03:47:44PM +0100, Sven Luther wrote:
>
> The worse that can happen is the GENERIC_RTC driver not being
> initialized because linux believes the RTC driver should be ok.

which breaks hwclock, not acceptable.

--
Ethan Benson
http://www.alaska.net/~erbenson/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Volunteer needed : Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Tom Rini]

On Wed, Jan 07, 2004 at 10:27:33PM -0900, Ethan Benson wrote:

> On Wed, Jan 07, 2004 at 03:47:44PM +0100, Sven Luther wrote:
> >
> > The worse that can happen is the GENERIC_RTC driver not being
> > initialized because linux believes the RTC driver should be ok.
>
> which breaks hwclock, not acceptable.

This is getting _much_ uglier, but how about:
1) Modify genrtc.c and rtc.c so that they do _not_ initalize on their
own.
2) Create a 'dummy_rtc.c' driver that just tests _machine and calls
rtc.c's init bits on chrp (or just pegasos) and genrtc's bits otherwise.

And again, this is ugly ugly ugly, and I disavow any knowledge of
typing the above.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Volunteer needed : Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Thu, Jan 08, 2004 at 08:53:31AM -0700, Tom Rini wrote:
>
> On Wed, Jan 07, 2004 at 10:27:33PM -0900, Ethan Benson wrote:
>
> > On Wed, Jan 07, 2004 at 03:47:44PM +0100, Sven Luther wrote:
> > >
> > > The worse that can happen is the GENERIC_RTC driver not being
> > > initialized because linux believes the RTC driver should be ok.

This doesn't work anyway, it stops pmacs from hanging but still there is
a long wait, which you can ^C interrupt.

I believe this is because since there is the RTC clock, the GENERIC_RTC
code will not be called or something.

> > which breaks hwclock, not acceptable.
>
> This is getting _much_ uglier, but how about:
> 1) Modify genrtc.c and rtc.c so that they do _not_ initalize on their
> own.
> 2) Create a 'dummy_rtc.c' driver that just tests _machine and calls
> rtc.c's init bits on chrp (or just pegasos) and genrtc's bits otherwise.
>
> And again, this is ugly ugly ugly, and I disavow any knowledge of
> typing the above.

That would be a solution, but i think i will look again at my previous
effort.

Anyway, on pegasos 2, i have the problem that CONFIG_RTC works fine, and
the clock is set, but only _later_. This has as result that the clock is
wrong when it is the time for filesystem checks, and thus filesystems
are checked each time.

Strange.

Friendly,

Sven Luther


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Volunteer needed : Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Benjamin Herrenschmidt]

>
> Anyway, on pegasos 2, i have the problem that CONFIG_RTC works fine, and
> the clock is set, but only _later_. This has as result that the clock is
> wrong when it is the time for filesystem checks, and thus filesystems
> are checked each time.

Your arch code should set an initial UTC time in the kernel
that is correct, which is why you really want to properly
implement working ppc_md.{get,set_rtc_time}, that will get you
this functionality along with working GENERIC_RTC

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Volunteer needed : Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Fri, Jan 09, 2004 at 08:53:07AM +1100, Benjamin Herrenschmidt wrote:
>
> >
> > Anyway, on pegasos 2, i have the problem that CONFIG_RTC works fine, and
> > the clock is set, but only _later_. This has as result that the clock is
> > wrong when it is the time for filesystem checks, and thus filesystems
> > are checked each time.
>
> Your arch code should set an initial UTC time in the kernel
> that is correct, which is why you really want to properly
> implement working ppc_md.{get,set_rtc_time}, that will get you
> this functionality along with working GENERIC_RTC

Yep, that is what i thought to.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/