Picon

Work Witk Us!!

We are interested in employing company to serves as company representative, to work with us .forward your
company info. EMail:chinanoffoilcorp03 <at> yahoo.com

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Helge Deller | 2 Feb 2009 00:24
Picon
Picon

[PATCH] parisc: define SRCARCH=parisc for parisc64 builds

The parisc64 target (HP PARISC, 64bit kernel) is similar to the sparc64 or 
m68knommu targets, as it shares all sources for 32- and 64-bit in one single
source path which is arch/parisc/.
This patch now allows one to use ARCH=parisc64 and just directly build the
64bit kernel without creating symlinks in arch/ and include/asm-* manually
the same way as it's done for sparc64 and m68knommu.

Signed-off-by: Helge Deller <deller <at> gmx.de>

diff --git a/Makefile b/Makefile
index cf9e20d..3582985 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -210,6 +210,11  <at>  <at>  ifeq ($(ARCH),sparc64)
        SRCARCH := sparc
 endif

+# Additional ARCH settings for parisc
+ifeq ($(ARCH),parisc64)
+       SRCARCH := parisc
+endif
+
 # Where to locate arch specific headers
 hdr-arch  := $(SRCARCH)

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Stephen Rothwell | 2 Feb 2009 01:11
Picon
Picon

linux-next: manual merge of the driver-core tree with the parisc tree

Hi Greg,

Today's linux-next merge of the driver-core tree got conflicts in
drivers/char/agp/parisc-agp.c, drivers/parisc/gsc.c and
drivers/parisc/sba_iommu.c between commit
a130bf34da4b64d7b289e2358530ef5d4ab27efd ("parisc: remove klist
iterators") from the parisc tree and commit
135bd8a5aeed90af407aeeede9587ee99c5606b2 ("parisc: don't touch driver
core internals") from the driver-core tree.

These two commits seem to be trying to do similar things.  I have used
the versions from the parisc tree.  Greg, I guess you need to check to
see if you agree and if so, then just remove the driver-core tree patch.

James, Kyle, the one thing I took from Greg's patch was the removal of
the include of linux/klist.h from drivers/char/agp/parisc-agp.c.

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Greg KH | 2 Feb 2009 05:41
Gravatar

Re: linux-next: manual merge of the driver-core tree with the parisc tree

On Mon, Feb 02, 2009 at 11:11:12AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got conflicts in
> drivers/char/agp/parisc-agp.c, drivers/parisc/gsc.c and
> drivers/parisc/sba_iommu.c between commit
> a130bf34da4b64d7b289e2358530ef5d4ab27efd ("parisc: remove klist
> iterators") from the parisc tree and commit
> 135bd8a5aeed90af407aeeede9587ee99c5606b2 ("parisc: don't touch driver
> core internals") from the driver-core tree.
> 
> These two commits seem to be trying to do similar things.  I have used
> the versions from the parisc tree.  Greg, I guess you need to check to
> see if you agree and if so, then just remove the driver-core tree patch.

Yes, the parisc version is fine.

> James, Kyle, the one thing I took from Greg's patch was the removal of
> the include of linux/klist.h from drivers/char/agp/parisc-agp.c.

That would be good as well.

I'll fix up my tree tomorrow.

thanks,

greg k-h
Stephen Rothwell | 2 Feb 2009 06:04
Picon
Picon

Re: linux-next: manual merge of the driver-core tree with the parisc tree

Hi Greg,

On Sun, 1 Feb 2009 20:41:44 -0800 Greg KH <greg <at> kroah.com> wrote:
>
> > These two commits seem to be trying to do similar things.  I have used
> > the versions from the parisc tree.  Greg, I guess you need to check to
> > see if you agree and if so, then just remove the driver-core tree patch.
> 
> Yes, the parisc version is fine.
> 
> > James, Kyle, the one thing I took from Greg's patch was the removal of
> > the include of linux/klist.h from drivers/char/agp/parisc-agp.c.
> 
> That would be good as well.
> 
> I'll fix up my tree tomorrow.

Thanks for checking.

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Helge Deller | 5 Feb 2009 00:06
Picon
Picon

[PATCH] parisc: allow to build with 16k default kernel page size

Introduce new convert_for_tlb_insert20 macro and use it to replace assembler
statements with hardcoded constants.
This change allows the parisc64 kernel to boot with 16kb default kernel page size, 
aka CONFIG_PARISC_PAGE_SIZE_16KB=y.

Signed-off-by: Helge Deller <deller <at> gmx.de>

diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index 0f7ff93..4e9dd15 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
 <at>  <at>  -505,6 +505,18  <at>  <at> 
 	STREG		\pte,0(\ptep)
 	.endm

+	/* bitshift difference between a PFN (based on kernel's PAGE_SIZE)
+	 * to a CPU TLB 4k PFN (4k => 12 bits to shift) */
+	#define PAGE_ADD_SHIFT  (PAGE_SHIFT-12)
+
+	/* Drop prot bits and convert to page addr for iitlbt and idtlbt */
+	.macro		convert_for_tlb_insert20 pte
+	extrd,u		\pte,(63-ASM_PFN_PTE_SHIFT)+(63-58)+PAGE_ADD_SHIFT,\
+				64-PAGE_SHIFT-PAGE_ADD_SHIFT,\pte
+	depdi		_PAGE_SIZE_ENCODING_DEFAULT,63,\
+				(63-58)+PAGE_ADD_SHIFT,\pte
+	.endm
+
 	/* Convert the pte and prot to tlb insertion values.  How
 	 * this happens is quite subtle, read below */
 	.macro		make_insert_tlb	spc,pte,prot
(Continue reading)

Helge Deller | 6 Feb 2009 21:50
Picon
Picon

[PATCH] parisc: add LATENCYTOP_SUPPORT and CONFIG_STACKTRACE_SUPPORT

Signed-off-by: Helge Deller <deller <at> gmx.de>

diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index aacf11d..4866e2f 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
 <at>  <at>  -75,6 +75,9  <at>  <at>  config GENERIC_HARDIRQS
 config GENERIC_IRQ_PROBE
 	def_bool y

+config HAVE_LATENCYTOP_SUPPORT
+        def_bool y
+
 config IRQ_PER_CPU
 	bool
 	default y
 <at>  <at>  -83,6 +86,9  <at>  <at>  config IRQ_PER_CPU
 config PM
 	bool

+config STACKTRACE_SUPPORT
+	def_bool y
+
 config ISA_DMA_API
 	bool

diff --git a/arch/parisc/kernel/Makefile b/arch/parisc/kernel/Makefile
index 016d3fc..a7ba8cd 100644
--- a/arch/parisc/kernel/Makefile
+++ b/arch/parisc/kernel/Makefile
(Continue reading)

Kyle McMartin | 6 Feb 2009 22:32
Favicon

Re: [PATCH] parisc: add LATENCYTOP_SUPPORT and CONFIG_STACKTRACE_SUPPORT

On Fri, Feb 06, 2009 at 09:50:39PM +0100, Helge Deller wrote:
> +#include <asm/unwind.h>
> +
> +static void dump_trace(struct task_struct *task, struct stack_trace *trace)
> +{
> +	struct unwind_frame_info info;
> +
> +	/* initialize unwind info */
> +	if (task == current) {
> +		unsigned long sp;
> +		struct pt_regs r;
> +HERE:
> +		asm volatile ("copy %%r30, %0" : "=r"(sp));
> +		memset(&r, 0, sizeof(struct pt_regs));
> +		r.iaoq[0] = (unsigned long)&&HERE;
> +		r.gr[2] = (unsigned long)__builtin_return_address(0);
> +		r.gr[30] = sp;
> +		unwind_frame_init(&info, task, &r);
> +	} else {
> +		unwind_frame_init_from_blocked_task(&info, task);
> +	}
> +

applied, with a clean up that takes this to a forced inline to share
between here and traps.c.

cheers, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Helge Deller | 7 Feb 2009 02:19
Picon
Picon

FUNCTION_TRACER and parisc kernel

Hi Carlos, Dave & parisc-linux mailing list,

I just started looking into implementing function tracer functionality 
into the parisc kernel (http://cateee.net/lkddb/web-lkddb/FUNCTION_TRACER.html).

While doing so, I noticed that gcc issues lots of warnings like this one:
  CC      arch/parisc/lib/iomap.o
cc1: warning: -ffunction-sections disabled; it makes profiling impossible

So it seems that this statement in arch/parisc/Makefile:
# Without this, "ld -r" results in .text sections that are too big
# (> 0x40000) for branches to reach stubs.
cflags-y        += -ffunction-sections

breaks with the -pg compile option which is needed for function tracing.

Some searching with google brought up this thread:
http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html
and esp. this answer:
http://gcc.gnu.org/ml/gcc-help/2008-11/msg00141.html

Or this thread:
http://osdir.com/ml/linux.debian.ports.hppa/2005-06/msg00045.html

Since it's late I felt too tired to look deeply into glibc and gcc myself and
just thought I should ask here: Do you see any chance that -pg and -ffunction-sections
could work together on hppa/linux?

Helge

(Continue reading)

John David Anglin | 7 Feb 2009 04:25
Picon

Re: FUNCTION_TRACER and parisc kernel

> Hi Carlos, Dave & parisc-linux mailing list,
> 
> I just started looking into implementing function tracer functionality 
> into the parisc kernel (http://cateee.net/lkddb/web-lkddb/FUNCTION_TRACER.html).
> 
> While doing so, I noticed that gcc issues lots of warnings like this one:
>   CC      arch/parisc/lib/iomap.o
> cc1: warning: -ffunction-sections disabled; it makes profiling impossible
> 
> So it seems that this statement in arch/parisc/Makefile:
> # Without this, "ld -r" results in .text sections that are too big
> # (> 0x40000) for branches to reach stubs.
> cflags-y        += -ffunction-sections
> 
> breaks with the -pg compile option which is needed for function tracing.
> 
> Some searching with google brought up this thread:
> http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html
> and esp. this answer:
> http://gcc.gnu.org/ml/gcc-help/2008-11/msg00141.html

Hmmm, we killed named section support on the HP-UX SOM port several years
ago because it wasn't very useful.  Jeff did it...  So, at this time, only
Solaris is an issue.  Of course, changing the code in toplev.c affects all
targets.  So, a change to remove this would have to go into 4.5 quite
early.

There was some work on the profiling implementation for both HP-UX and
Linux after the removal of named section support on HP-UX, so the label
issue may not be a problem.  Remove the code disabling function sections
(Continue reading)


Gmane