* Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
From: Scott Wood @ 2007-09-06 17:24 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070906170547.GA12432@iram.es>
On Thu, Sep 06, 2007 at 07:05:47PM +0200, Gabriel Paubert wrote:
> On Thu, Sep 06, 2007 at 12:01:23PM -0500, Scott Wood wrote:
> > On Thu, Sep 06, 2007 at 06:55:35PM +0200, Gabriel Paubert wrote:
> > > So who will be in charge of updating the RTC now? The update
> > > every 11 min is there to stay on x86(-64) it seems.
> >
> > Put something in crontab to run hwclock periodically.
>
> I have many machines on which cron is not even installed.
OK, so use something else that waits in a loop and periodically updates
the clock. It shouldn't be the kernel's responsibility.
-Scott
^ permalink raw reply
* Re: Support a new platform in arch/ppc or in arch/powerpc ?
From: Josh Boyer @ 2007-09-06 17:42 UTC (permalink / raw)
To: CHAVENT Paul; +Cc: linuxppc-embedded
In-Reply-To: <631F24C6E5322142A5BDEFA2E8518080297862@tls01.criltechnology.net>
On Thu, 6 Sep 2007 18:53:54 +0200
"CHAVENT Paul" <Paul.CHAVENT@alyotech.fr> wrote:
> Good morning.
>
> I would like to port a bsp (for the motorola MVME5500 sbc) to the current (2.6.22.6) kernel.
>
> Should i implement it in arch/powerpc ?
Yes. arch/ppc is bug fix only at this point.
> If i should do it in arch/powerpc, can i copy some code i need in arch/ppc ? For example, with kernel 2.6.18.1 i used arch/ppc/syslib/todc_time and arch/ppc/syslib/pci_auto, but perhaps i don't need it anymore ?
I'm not sure those will work well in arch/powerpc. But obviously some
code porting is expected.
josh
^ permalink raw reply
* [PATCH 0/3] powerpc: whitespace cleanup, grammar corrections
From: Linas Vepstas @ 2007-09-06 17:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
These popped out at me while I was reading code.
Its all janitorial.
--linas
^ permalink raw reply
* [PATCH 2/3] powerpc: prom whitespace cleanup
From: Linas Vepstas @ 2007-09-06 17:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
In-Reply-To: <20070906174521.GA21800@austin.ibm.com>
Whitespace cleanup: badly indented lines.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/kernel/prom.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/prom.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/kernel/prom.c 2007-08-29 14:14:12.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/kernel/prom.c 2007-08-29 14:15:10.000000000 -0500
@@ -782,13 +782,13 @@ static int __init early_init_dt_scan_cho
#endif
#ifdef CONFIG_KEXEC
- lprop = (u64*)of_get_flat_dt_prop(node, "linux,crashkernel-base", NULL);
- if (lprop)
- crashk_res.start = *lprop;
-
- lprop = (u64*)of_get_flat_dt_prop(node, "linux,crashkernel-size", NULL);
- if (lprop)
- crashk_res.end = crashk_res.start + *lprop - 1;
+ lprop = (u64*)of_get_flat_dt_prop(node, "linux,crashkernel-base", NULL);
+ if (lprop)
+ crashk_res.start = *lprop;
+
+ lprop = (u64*)of_get_flat_dt_prop(node, "linux,crashkernel-size", NULL);
+ if (lprop)
+ crashk_res.end = crashk_res.start + *lprop - 1;
#endif
early_init_dt_check_for_initrd(node);
^ permalink raw reply
* [PATCH 1/3] powerpc: prom_init whitespace cleanup, typo fix.
From: Linas Vepstas @ 2007-09-06 17:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
In-Reply-To: <20070906174416.GW4584@austin.ibm.com>
Whitespace cleanup: badly indented lines.
Typo in comment.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/kernel/prom_init.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/kernel/prom_init.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/kernel/prom_init.c 2007-08-28 16:40:26.000000000 -0500
@@ -1197,7 +1197,7 @@ static void __init prom_initialize_tce_t
if ((type[0] == 0) || (strstr(type, RELOC("pci")) == NULL))
continue;
- /* Keep the old logic in tack to avoid regression. */
+ /* Keep the old logic intact to avoid regression. */
if (compatible[0] != 0) {
if ((strstr(compatible, RELOC("python")) == NULL) &&
(strstr(compatible, RELOC("Speedwagon")) == NULL) &&
@@ -2224,7 +2224,7 @@ static void __init fixup_device_tree(voi
static void __init prom_find_boot_cpu(void)
{
- struct prom_t *_prom = &RELOC(prom);
+ struct prom_t *_prom = &RELOC(prom);
u32 getprop_rval;
ihandle prom_cpu;
phandle cpu_pkg;
@@ -2244,7 +2244,7 @@ static void __init prom_find_boot_cpu(vo
static void __init prom_check_initrd(unsigned long r3, unsigned long r4)
{
#ifdef CONFIG_BLK_DEV_INITRD
- struct prom_t *_prom = &RELOC(prom);
+ struct prom_t *_prom = &RELOC(prom);
if (r3 && r4 && r4 != 0xdeadbeef) {
unsigned long val;
@@ -2277,7 +2277,7 @@ unsigned long __init prom_init(unsigned
unsigned long pp,
unsigned long r6, unsigned long r7)
{
- struct prom_t *_prom;
+ struct prom_t *_prom;
unsigned long hdr;
unsigned long offset = reloc_offset();
@@ -2336,8 +2336,8 @@ unsigned long __init prom_init(unsigned
/*
* Copy the CPU hold code
*/
- if (RELOC(of_platform) != PLATFORM_POWERMAC)
- copy_and_flush(0, KERNELBASE + offset, 0x100, 0);
+ if (RELOC(of_platform) != PLATFORM_POWERMAC)
+ copy_and_flush(0, KERNELBASE + offset, 0x100, 0);
/*
* Do early parsing of command line
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 17:50 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070906141620.GB16353@ld0162-tx32.am.freescale.net>
>>> + model = "Analogue & Micro Adder MPC875";
>>
>> This should probably be just "MPC875".
>
> There's more than one board with an MPC875 on it.
"model" is the model name the vendor uses. It isn't supposed to
be unique globally, nor does it say what CPU is on the board.
Segher
^ permalink raw reply
* [PATCH 3/3] powerpc: setup_64 comment cleanup.
From: Linas Vepstas @ 2007-09-06 17:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
In-Reply-To: <20070906174615.GB21800@austin.ibm.com>
Gramatical corrections to comments.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/kernel/prom.c | 8 +++++---
arch/powerpc/kernel/setup_64.c | 6 +++---
2 files changed, 8 insertions(+), 6 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/setup_64.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/kernel/setup_64.c 2007-09-04 17:29:36.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/kernel/setup_64.c 2007-09-05 14:12:23.000000000 -0500
@@ -181,9 +181,9 @@ void __init early_setup(unsigned long dt
DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
/*
- * Do early initializations using the flattened device
- * tree, like retreiving the physical memory map or
- * calculating/retreiving the hash table size
+ * Do early initialization using the flattened device
+ * tree, such as retrieving the physical memory map or
+ * calculating/retrieving the hash table size.
*/
early_init_devtree(__va(dt_ptr));
Index: linux-2.6.22-git2/arch/powerpc/kernel/prom.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/kernel/prom.c 2007-09-05 14:23:06.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/kernel/prom.c 2007-09-05 14:24:49.000000000 -0500
@@ -433,9 +433,11 @@ static int __init early_parse_mem(char *
}
early_param("mem", early_parse_mem);
-/*
- * The device tree may be allocated below our memory limit, or inside the
- * crash kernel region for kdump. If so, move it out now.
+/**
+ * move_device_tree - move tree to an unused area, if needed.
+ *
+ * The device tree may be allocated beyond our memory limit, or inside the
+ * crash kernel region for kdump. If so, move it out of the way.
*/
static void move_device_tree(void)
{
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 18:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <f26578467468e38345e795ea5f1f7c42@kernel.crashing.org>
On Thu, Sep 06, 2007 at 07:50:32PM +0200, Segher Boessenkool wrote:
> >>>+ model = "Analogue & Micro Adder MPC875";
> >>
> >>This should probably be just "MPC875".
> >
> >There's more than one board with an MPC875 on it.
>
> "model" is the model name the vendor uses. It isn't supposed to
> be unique globally, nor does it say what CPU is on the board.
The name the vendor uses is "Adder MPC875". The name of the vendor is
"Analogue & Micro", which seems useful to include, even if it's not
mandatory that it be globally unique.
-Scott
^ permalink raw reply
* Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
From: Paul Mackerras @ 2007-09-06 18:20 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20070906165535.GA11420@iram.es>
Gabriel Paubert writes:
> On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> > This changes PowerPC to use the generic time infrastructure for
> > gettimeofday et al. We register a clocksource which uses the timebase
> > register, or the RTC on the 601.
> >
> > It also gets rid of the RTC update stuff. IIRC we discussed removing
> > this some time ago but never actually did it.
>
> So who will be in charge of updating the RTC now? The update
> every 11 min is there to stay on x86(-64) it seems.
I had an impression that ntpd would do it, but that seems to be wrong.
I also have been unable to find where in the kernel source there is
code for x86[-64] to do the RTC updates. Do you know where it is?
Doing the updates from timer_interrupt will no longer really be
suitable since it is not called at regular intervals any more. The
best thing would be for the ntp code to set up a timer when it reaches
synchronization.
> Removing this will have strange side effects: as an example,
> your laptop clock will be good if it synchronized on NTP,
> then you put it to sleep, disconnect the network and RTC read
> on wake up returns a wrong value, giving wrong timestamps.
No, the suspend/resume code reads the RTC on both suspend and resume,
and advances xtime by the difference between the two readings. So the
time might be out by up to a second after resume, but it shouldn't be
way off, assuming that your RTC is advancing at the right speed.
> As someone who has a network of tens of machines using
> NTP for synchornisation I think it is a very bad idea
> unless we have a replacement.
OK, but I think that doing it in timer_interrupt is the wrong place.
Paul.
^ permalink raw reply
* finding out the processor frequency
From: Leisner, Martin @ 2007-09-06 18:24 UTC (permalink / raw)
To: linuxppc-embedded
What exactly do we mean by "timebase"?
There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the
processor frequency (derived from the dts). But its not exported.
There's also ppc_tb_freq.
marty
^ permalink raw reply
* Kernel Debug on Virtex4-FX
From: Robert Woodworth @ 2007-09-06 18:32 UTC (permalink / raw)
To: linuxppc-embedded
Is it possible to debug the kernel via Xilinx JTAG Platform USB cable?
If so, how?
I can debug through the embedded-config.c and boot loader, but once the
kernel boots, (VM on) I cannot debug anymore.
Or do I have to use kgdb through serial?
Rob.
^ permalink raw reply
* RE: Kernel Debug on Virtex4-FX
From: Stephen Neuendorffer @ 2007-09-06 18:37 UTC (permalink / raw)
To: Robert Woodworth, linuxppc-embedded
In-Reply-To: <1189103551.6185.66.camel@PisteOff>
It believe it should work fine:
You just need to set breakpoints in the kernel proper=20
using virtual memory addresses.
I've never actually tried tracing through the enabling of the MMU,
however...
Steve
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of Robert Woodworth
> Sent: Thursday, September 06, 2007 11:33 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Kernel Debug on Virtex4-FX
>=20
> Is it possible to debug the kernel via Xilinx JTAG Platform USB cable?
>=20
> If so, how?
> I can debug through the embedded-config.c and boot loader,=20
> but once the
> kernel boots, (VM on) I cannot debug anymore. =20
>=20
>=20
> Or do I have to use kgdb through serial?=20
>=20
>=20
>=20
>=20
> Rob.
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* RE: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Stephen Neuendorffer @ 2007-09-06 18:39 UTC (permalink / raw)
To: Thomas Gerlach; +Cc: linuxppc-embedded
In-Reply-To: <20070904213339.D3DB7788046@mail56-fra.bigfish.com>
=20
You can also build a ppc405 toolchain using Crosstool, and it works
fine..
http://kegel.com/crosstool
Steve
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of Wolfgang Reissnegger
> Sent: Tuesday, September 04, 2007 2:33 PM
> To: Thomas Gerlach
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Newbie on embedded linux on PPC: error: cannot=20
> find boot.o
>=20
> Hi Thomas,
>=20
> Xilinx is building the tools in the EDK to work with VxWorks=20
> and for Standalone systems. In order to compile a Linux=20
> kernel you need to get a toolchain from one of the Third=20
> Party vendors, such as MontaVista. They have the correct=20
> linker scripts for building a kernel.
>=20
> Cheers,
> Wolfgang
>=20
> Thomas Gerlach wrote:
> > hi folks,
> >=20
> >=20
> > my name is thomas trying to make embedded linux run on a=20
> powerpc, but
> > we've got special boards here, although we use a xilinx virtex4
> > fpga...
> >=20
> > as you said in the nabble-thread (see subject), i set up edk9.1
> > software platform settings und ran libgen to get the xparameters*
> > files. i copied those bsp files into the kernel tree (i use your
> > kernel linux-2.6-virtex from git.secretlabs.ca/git). after
> > configuring the kernel settigs, i try
> >=20
> > $ make ARCH=3Dppc CROSS_COMPILE=3Dpowerpc-eabi-
> >=20
> > what i get is the following output:
> >=20
> >> CHK include/linux/version.h
> >> CHK include/linux/utsrelease.h
> >> CALL scripts/checksyscalls.sh
> >> CHK include/linux/compile.h
> >> LD init/mounts.o
> >> powerpc-eabi-ld: cannot find boot.o
> >> make[1]: *** [init/mounts.o] Error 1
> >> make: *** [init] Error 2
> >=20
> > so, i searched for boot.o (it exists) and even copied it=20
> into several
> > dirs of the linux kernel tree (where i thought i would make sense),
> > but the problem still remains.
> >=20
> > googling results in
> >=20
> >=20
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=3D1&g
etPagePath=3D17462&BV_SessionID=3D@@@@1197140711.1188909240>
@@@@&BV_EngineID=3Dcccgaddllgmfkflcefeceihdffhdfkf.0
> >=20
> >=20
> > and this, too, doesn't take me further in solving the problem.
> >=20
> > i hope you can help me.
> >=20
> > many thanks in advance,
> >=20
> > kind regards
> > thomas gerlach
> >=20
> >=20
> >=20
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* Re: finding out the processor frequency
From: Scott Wood @ 2007-09-06 18:43 UTC (permalink / raw)
To: Leisner, Martin; +Cc: linuxppc-embedded
In-Reply-To: <556445368AFA1C438794ABDA8901891C06460054@USA0300MS03.na.xerox.net>
On Thu, Sep 06, 2007 at 02:24:30PM -0400, Leisner, Martin wrote:
> What exactly do we mean by "timebase"?
>
> There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the
> processor frequency (derived from the dts). But its not exported.
>
> There's also ppc_tb_freq.
The timebase is the rate at which the timebase and decrementer registers
tick. It is not the same as the CPU core frequency.
-Scott
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 18:48 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070906180922.GA18750@ld0162-tx32.am.freescale.net>
>>>>> + model = "Analogue & Micro Adder MPC875";
>>>>
>>>> This should probably be just "MPC875".
>>>
>>> There's more than one board with an MPC875 on it.
>>
>> "model" is the model name the vendor uses. It isn't supposed to
>> be unique globally, nor does it say what CPU is on the board.
>
> The name the vendor uses is "Adder MPC875". The name of the vendor is
> "Analogue & Micro", which seems useful to include, even if it's not
> mandatory that it be globally unique.
So it should be "Adder MPC875", then :-)
Segher
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 19:12 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <598e0baf0dc1ca63b91f2a80ec8abe19@kernel.crashing.org>
On Thu, Sep 06, 2007 at 08:48:12PM +0200, Segher Boessenkool wrote:
> >>>>>+ model = "Analogue & Micro Adder MPC875";
> >>>>
> >>>>This should probably be just "MPC875".
> >>>
> >>>There's more than one board with an MPC875 on it.
> >>
> >>"model" is the model name the vendor uses. It isn't supposed to
> >>be unique globally, nor does it say what CPU is on the board.
> >
> >The name the vendor uses is "Adder MPC875". The name of the vendor is
> >"Analogue & Micro", which seems useful to include, even if it's not
> >mandatory that it be globally unique.
>
> So it should be "Adder MPC875", then :-)
Any particular reason to leave out potentially useful information in a
field that is for human consumption?
Other than Because Segher Says So(tm). :-)
-Scott
^ permalink raw reply
* Re: [RFC/PATCH 2/2] Generic clockevents and no-idle-HZ for PowerPC
From: Olof Johansson @ 2007-09-06 19:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18144.4702.673658.336384@cargo.ozlabs.ibm.com>
Hi,
Nice! I've been looking forward to these patches. Should help keep power
consumption down on machines with powersavings support for idle.
On Fri, Sep 07, 2007 at 12:44:46AM +1000, Paul Mackerras wrote:
> @@ -749,6 +805,8 @@ void __init clocksource_init(void)
> printk(KERN_INFO "clocksource: %s mult[%x] shift[%d] registered\n",
> clocksource_timebase.name,
> clocksource_timebase.mult, clocksource_timebase.shift);
> +
> + init_decrementer_clockevent();
> }
>
> /* This function is only called on the boot processor */
> @@ -874,8 +932,7 @@ void __init time_init(void)
> /* Register the clocksource */
> clocksource_init();
>
> - /* Not exact, but the timer interrupt takes care of this */
> - set_dec(tb_ticks_per_jiffy);
> + set_dec(DECREMENTER_MAX);
> }
I don't think that set_dec() is needed any more. I get a very long
delay during "Calibrating delay loop..." with it there.
Looks like decrementer_set_next_event() already sets a reasonable
decementer value, it's called through the notify chain set off
from register_decrementer_clockevent() -> ... -> tick_notify() ->
tick_setup_periodic() -> clockevents_program_event().
-Olof
^ permalink raw reply
* PCI target implementation on AMCC PPC CPUs
From: Leonid @ 2007-09-06 19:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070906184308.GA22380@ld0162-tx32.am.freescale.net>
Hi:
Does somebody have any experience of using AMCC PPC chips (such as
PPC440ep) or any other PPC at all as PCI target (slave)? PPC440ep has
PCI-PLB bridge which certainly can be configured as slave. CPU will need
to do configuration and then I assume another CPU (PCI host) will be
able to access all memories via the bridge including peripherals'
controllers. Slave CPU involvement would be minimal then.
Can anybody point me to design like this or to that end to any SW design
where PPC CPU works as PCI slave?
Thanks,
Leonid.
^ permalink raw reply
* Re: finding out the processor frequency
From: Josh Boyer @ 2007-09-06 19:15 UTC (permalink / raw)
To: Scott Wood; +Cc: Leisner, Martin, linuxppc-embedded
In-Reply-To: <20070906184308.GA22380@ld0162-tx32.am.freescale.net>
On Thu, 6 Sep 2007 13:43:08 -0500
Scott Wood <scottwood@freescale.com> wrote:
> On Thu, Sep 06, 2007 at 02:24:30PM -0400, Leisner, Martin wrote:
> > What exactly do we mean by "timebase"?
> >
> > There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the
> > processor frequency (derived from the dts). But its not exported.
> >
> > There's also ppc_tb_freq.
>
> The timebase is the rate at which the timebase and decrementer registers
> tick. It is not the same as the CPU core frequency.
Unless your timebase and decrementer clock source is tied to the CPU
clock. :)
So it depends on the board, and it can even depend on how the board is
initialized. Some boards can change the timebase clock source on the
fly.
josh
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 19:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20070906191255.GA22663@ld0162-tx32.am.freescale.net>
On Thu, Sep 06, 2007 at 02:12:55PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 08:48:12PM +0200, Segher Boessenkool wrote:
> > So it should be "Adder MPC875", then :-)
>
> Any particular reason to leave out potentially useful information in a
> field that is for human consumption?
>
> Other than Because Segher Says So(tm). :-)
BTW, IEEE1275 seems to disagree:
"model"
Standard property name to define a manufacturer's model number.
prop-encoded-array:
Text string, encoded with encode-string.
A manufacturer-dependent string that generally specifies the model name
and number (including revision level) for this device. The format of
the text string is arbitrary, although in conventional usage the string
begins with the name of the device's manufacturer as with the name
property.
Although there is no standard interpretation for the value of the model
property, a specific device driver might use it to learn, for instance,
the revision level of its particular device.
See also: property, model.
Used as: " XYZCO,1416-02" encode-string " model" property
-Scott
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 19:32 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070906191255.GA22663@ld0162-tx32.am.freescale.net>
>>>>>>> + model = "Analogue & Micro Adder MPC875";
>>>>>>
>>>>>> This should probably be just "MPC875".
>>>>>
>>>>> There's more than one board with an MPC875 on it.
>>>>
>>>> "model" is the model name the vendor uses. It isn't supposed to
>>>> be unique globally, nor does it say what CPU is on the board.
>>>
>>> The name the vendor uses is "Adder MPC875". The name of the vendor
>>> is
>>> "Analogue & Micro", which seems useful to include, even if it's not
>>> mandatory that it be globally unique.
>>
>> So it should be "Adder MPC875", then :-)
>
> Any particular reason to leave out potentially useful information in a
> field that is for human consumption?
Because it isn't for human consumption (only), and has well-defined
semantics (although slightly fuzzy).
> Other than Because Segher Says So(tm). :-)
"Because the OF standard says so" :-)
Segher
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 19:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070906192025.GA22775@ld0162-tx32.am.freescale.net>
> BTW, IEEE1275 seems to disagree:
No it doesn't.
> A manufacturer-dependent string that generally specifies the model
> name
> and number (including revision level) for this device. The format of
> the text string is arbitrary, although in conventional usage the
> string
> begins with the name of the device's manufacturer as with the name
> property.
That would be "0ABCDEF,Adder MPC875" or "VWXYZ,Adder MPC875" --
not "some random string without a comma Adder MPC875".
> Although there is no standard interpretation for the value of the
> model
> property, a specific device driver might use it to learn, for
> instance,
> the revision level of its particular device.
i.e., it is machine readable.
Segher
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 19:56 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <43ad9218d498e2d01922a57ebfee2327@kernel.crashing.org>
On Thu, Sep 06, 2007 at 09:36:07PM +0200, Segher Boessenkool wrote:
> >BTW, IEEE1275 seems to disagree:
>
> No it doesn't.
"...in conventional usage the string begins with the name of the device's
manufacturer". Even if you want to quibble about the manner in which the
manufacturer is specified, that's quite different from leaving it out.
> > A manufacturer-dependent string that generally specifies the model
> >name
> > and number (including revision level) for this device. The format of
> > the text string is arbitrary, although in conventional usage the
> >string
> > begins with the name of the device's manufacturer as with the name
> > property.
>
> That would be "0ABCDEF,Adder MPC875" or "VWXYZ,Adder MPC875" --
> not "some random string without a comma Adder MPC875".
"the text string is arbitrary" and "conventional usage".
That "random string" is more useful for the intended purpose than the
first half of a MAC address.
> > Although there is no standard interpretation for the value of the
> >model
> > property, a specific device driver might use it to learn, for
> >instance,
> > the revision level of its particular device.
>
> i.e., it is machine readable.
No, it *can* be machine usable in certain circumstances. I'm 100% sure
that there is no code out there that cares what's in the model field of
this board's device tree, other than to pass it to /proc/cpuinfo (i.e.
human consumption).
-Scott
^ permalink raw reply
* Re: [RFC/PATCH 2/2] Generic clockevents and no-idle-HZ for PowerPC
From: Olof Johansson @ 2007-09-06 20:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20070906191516.GA20090@lixom.net>
Hi again,
On Thu, Sep 06, 2007 at 02:15:16PM -0500, Olof Johansson wrote:
> I don't think that set_dec() is needed any more. I get a very long
> delay during "Calibrating delay loop..." with it there.
>
> Looks like decrementer_set_next_event() already sets a reasonable
> decementer value, it's called through the notify chain set off
> from register_decrementer_clockevent() -> ... -> tick_notify() ->
> tick_setup_periodic() -> clockevents_program_event().
One more problem for at least PA6T is that we'll keep taking decrementer
exceptions as long as DEC contains a negative value, and there seems
to be cases where this happens, i.e. it's not reset for other reasons.
I ended up adding a set_dec(DECREMENTER_MAX) at the start of
timer_interrupt() to avoid the case where none of the code paths through
timer_interrupt() resets the decrementer. I didn't have time to fully
dig down and figure out what paths causes this and why, so I suppose it's
more of a workaround than a solution.
I think 970 behaves the same, but I haven't verified.
-Olof
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-06 20:15 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C022417D2@ehost011-3.exch011.intermedia.net>
Hi Leonid,
> Does somebody have any experience of using AMCC PPC chips (such as
> PPC440ep) or any other PPC at all as PCI target (slave)? PPC440ep has
> PCI-PLB bridge which certainly can be configured as slave. CPU will need
> to do configuration and then I assume another CPU (PCI host) will be
> able to access all memories via the bridge including peripherals'
> controllers. Slave CPU involvement would be minimal then.
>
> Can anybody point me to design like this or to that end to any SW design
> where PPC CPU works as PCI slave?
I have an application where I want to communicate with up
to 20 cPCI slaves per cPCI chassis, where the slave devices
each use a PowerPC based processor. (The masters happen
to be x86 CPUs; because I have them).
I looked at the 440EP using the Yosemite board
http://www.ovro.caltech.edu/~dwh/powerpc_440ep.pdf
and the Freescale MPC8349E
http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
I had some trouble the with AMCC chips; the DMA controller
operation was weird, and AMCC tech support was pretty
much useless.
Freescale's technical (design) support is great, and they
(the software developers; Kim, Timur, etc) are actively
maintaining/contributing to git trees for u-boot and Linux.
If you can change processors, I'd recommend any Freescale
part over an AMCC part.
I'm working on a cPCI board design at the moment, you're
welcome to look at the design;
* PowerPC
* Altera Stratix II FPGAs
* dual 8-bit 1GHz ADCs
http://www.ovro.caltech.edu/~dwh/carma_board/
Regards,
Dave
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox