Subject: Re: [PATCH 1/14] FRV: Fujitsu FR-V CPU arch implementation - msg#00013

List: linux.uclinux.devel

Date: Prev Next Index Thread: Prev Next Index

dhowells@xxxxxxxxxx wrote:
>
> The attached patch provides an architecture implementation for the Fujitsu
> FR-V
> CPU series, configurably as Linux or uClinux.

Who developed this?

Who is maintaining it, and via what mailing list?

I didn't notice a MAINTAINERS record. Was there one?

How widespread is the usage of this architecture?

Please convince us that this is not a piece of code which nobody will use
and which will fall into an unmaintained lump.

Thanks.

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Re: [PATCH 6/14] FRV: IDE fixes

On Llu, 2004-11-01 at 19:30, dhowells@xxxxxxxxxx wrote: > memset(&hwif->hw, 0, sizeof(hwif->hw)); > +#ifndef IDE_ARCH_OBSOLETE_INIT > + ide_std_init_ports(&hwif->hw, base, (ctl | 2)); > + hwif->hw.io_ports[IDE_IRQ_OFFSET] = 0; > +#else > ide_init_hwif_ports(&hwif->hw, base, (ctl | 2), NULL); > +#endif Do you really need this, and if so please why ?

Next Message by Date: click to view message preview

Re: [PATCH 12/14] FRV: Generate more useful debug info

dhowells@xxxxxxxxxx wrote: > > The attached patch permits the generation of more useful debugging information > by reducing the optimisation level and by telling the assembler to produce > debug info too. Generates rejects against Sam's tree and appears to be unrelated to FRV, yes? I'd prefer that this be worked through Sam's tree as a separate enhancement please. +ifdef CONFIG_DEBUG_INFO +CFLAGS += -g -O1 +AFLAGS += -Wa,--gdwarf2 +ASFLAGS += -Wa,--gdwarf2 +else Are you sure that all architectures want this? And that their toolchains will continue to work correctly? And that it doesn't break older gcc's and that kgdb will continue to work correctly, etc? I'm not...

Previous Message by Thread: click to view message preview

[PATCH 5/14] FRV: Fork fixes

The attached patch fixes fork to get rid of the assumption that THREAD_SIZE >= PAGE_SIZE (on the FR-V the smallest available page size is 16KB). Signed-Off-By: dhowells@xxxxxxxxxx --- diffstat frv-fork-2610rc1bk10.diff fork.c | 5 +++++ 1 files changed, 5 insertions(+) diff -uNr /warthog/kernels/linux-2.6.10-rc1-bk10/kernel/fork.c linux-2.6.10-rc1-bk10-frv/kernel/fork.c --- /warthog/kernels/linux-2.6.10-rc1-bk10/kernel/fork.c 2004-11-01 11:45:34.740160149 +0000 +++ linux-2.6.10-rc1-bk10-frv/kernel/fork.c 2004-11-01 11:47:05.153633406 +0000 @@ -118,7 +118,12 @@ * value: the thread structures can take up at most half * of memory. */ +#if THREAD_SIZE >= PAGE_SIZE max_threads = mempages / (THREAD_SIZE/PAGE_SIZE) / 8; +#else + max_threads = mempages / 8; +#endif + /* * we need to allow at least 20 threads to boot a system */

Next Message by Thread: click to view message preview

FRV and CPU frequency scaling

While reading through the FRV Documentation patch I stumbled across the file "clock.txt" file which says: + (*) clock.txt + + A description of the CPU clock scaling interface. + Could you use the generic cpufreq core (drivers/cpufreq/) for this, please? And could you explain the difference between p0, cm and cmode settings to me, and how they can be combined, please? Or is the following assumption correct? The CPU core frequency can only be modified on FR405 CPUs, while p0 and cm are available on all CPUs and allow for modification of the frequency of some sort of external busses. Thanks, Dominik

Loading Comments...