LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 05/16] ehca: common include files
From: Randy.Dunlap @ 2006-05-15 21:03 UTC (permalink / raw)
  To: Heiko J Schick
  Cc: linux-kernel, openib-general, linuxppc-dev, RAISCH, HNGUYEN,
	MEDER
In-Reply-To: <4468BD5B.1060406@de.ibm.com>

On Mon, 15 May 2006 19:41:47 +0200 Heiko J Schick wrote:

> Signed-off-by: Heiko J Schick <schickhj@de.ibm.com>
> 
> 
>   drivers/infiniband/hw/ehca/ehca_iverbs.h |  181 +++++++++++++
>   drivers/infiniband/hw/ehca/ehca_tools.h  |  411 +++++++++++++++++++++++++++++++
>   2 files changed, 592 insertions(+)
> 
> 
> 
> --- linux-2.6.17-rc2-orig/drivers/infiniband/hw/ehca/ehca_tools.h	1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.17-rc2/drivers/infiniband/hw/ehca/ehca_tools.h	2006-05-03 13:44:15.000000000 +0200
> @@ -0,0 +1,411 @@

> +static inline u64 ehca_edeb_filter(const u32 level,
> +				   const u32 id, const u32 line)
> +{
> +	u64 ret = 0;
> +	u32 filenr = 0;
> +	u32 filter_level = 9;
> +	u32 dynamic_level = 0;
> +
> +	/* This is code written for the gcc -O2 optimizer which should colapse
                                                                    collapse
> +	 * to two single ints filter_level is the first level kicked out by
> +	 * compiler means trace everythin below 6. */
                                everything
plus make a real sentence of that, please.

> +}
> +
> +#ifdef EHCA_USE_HCALL_KERNEL
> +#ifdef CONFIG_PPC_PSERIES
> +
> +#include <asm/paca.h>
> +
> +/**
> + * IS_EDEB_ON - Checks if debug is on for the given level.
> + */
> +#define IS_EDEB_ON(level) \
> +    ((ehca_edeb_filter(level, EDEB_ID_TO_U32(DEB_PREFIX), __LINE__) & 0x100000000L)==0)
> +
> +#elif REAL_HCALL
> +
> +
> +#endif
> +#else
> +
> +#endif
> +
> +/**
> + * EDEB - Trace output macro.
> + * @level tracelevel
> + * @format optional format string, use "" if not desired
> + * @args printf like arguments for trace, use %Lx for u64, %x for u32
> + *       %p for pointer
> + */

Use real kernel-doc format here, please.
Parameters at least need a colon (':') after their names, like:

 * @format: optonal format string, use "" if not desired

and test them...

> +#define EDEB(level,format,args...) \
> +	EDEB_P_GENERIC(level,"",format,##args)
> +#define EDEB_ERR(level,format,args...) \
> +	EDEB_P_GENERIC(level,"HCAD_ERROR ",format,##args)
> +#define EDEB_EN(level,format,args...) \
> +	EDEB_P_GENERIC(level,">>>",format,##args)
> +#define EDEB_EX(level,format,args...) \
> +	EDEB_P_GENERIC(level,"<<<",format,##args)
> +
> +/**
> + * EDEB macro to dump a memory block, whose length is n*8 bytes.
      EDEB_DMP

> + * Each line has the following layout:
> + * <format string> adr=X ofs=Y <8 bytes hex> <8 bytes hex>
> + */
> +#define EDEB_DMP(level,adr,len,format,args...) \
> +	do {				       \
> +		unsigned int x;			      \
> +		unsigned int l = (unsigned int)(len); \
> +		unsigned char *deb = (unsigned char*)(adr);	\
> +		for (x = 0; x < l; x += 16) { \
> +		        EDEB(level, format " adr=%p ofs=%04x %016lx %016lx", \
> +			     ##args, deb, x, *((u64 *)&deb[0]), *((u64 *)&deb[8])); \
> +			deb += 16; \
> +		} \
> +	} while (0)
> +
> +/* define a bitmask, little endian version */
> +#define EHCA_BMASK(pos,length) (((pos)<<16)+(length))
> +/* define a bitmask, the ibm way... */
> +#define EHCA_BMASK_IBM(from,to) (((63-to)<<16)+((to)-(from)+1))
> +/* internal function, don't use */
> +#define EHCA_BMASK_SHIFTPOS(mask) (((mask)>>16)&0xffff)
> +/* internal function, don't use */
> +#define EHCA_BMASK_MASK(mask) (0xffffffffffffffffULL >> ((64-(mask))&0xffff))
> +/* return value shifted and masked by mask\n
> + * variable|=HCA_BMASK_SET(MY_MASK,0x4711) ORs the bits in variable\n
> + * variable&=~HCA_BMASK_SET(MY_MASK,-1) clears the bits from the mask
> + * in variable

What are all of those "\n"s up there?  and below?

> +#define EHCA_BMASK_SET(mask,value) \
> +	((EHCA_BMASK_MASK(mask) & ((u64)(value)))<<EHCA_BMASK_SHIFTPOS(mask))
> +/* extract a parameter from value by mask\n
> + * param=EHCA_BMASK_GET(MY_MASK,value)
> + */
> +#define EHCA_BMASK_GET(mask,value) \
> +	( EHCA_BMASK_MASK(mask)& (((u64)(value))>>EHCA_BMASK_SHIFTPOS(mask)))
> +
> +
> +/**
> + * ehca_adr_bad - Handle to be used for adress translation mechanisms,
> + * currently a placeholder.
> + */

Use proper kernel-doc format.

> +static inline int ehca_adr_bad(void *adr)
> +{
> +	return !adr;
> +}
> +
> +/**
> + * ehca2ib_return_code - Returns ib return code corresponding to the given
> + * ehca return code.
> + */

Ditto.

---
~Randy

^ permalink raw reply

* Re: [PATCH] Fix pSeries identification in prom_init.c
From: Benjamin Herrenschmidt @ 2006-05-15 21:08 UTC (permalink / raw)
  To: Michael Neuling; +Cc: linuxppc-dev list, Paul Mackerras, segher
In-Reply-To: <20060515161810.E633C679EB@ozlabs.org>

> To be safe if we are returned a non terminated string.  I'd not realised
> the case you've mentioned.
> 
> How much we should trust firmware?  With strcpy, should we explicitly
> terminate the string first (I removed one of these originally)?  Patch
> below, compiled not run.

I wouldn't bother. If it returns a non-terminated string there, a lot of
stuff will break anyway including the kernel probe code

Ben.

> The OF trampoline code prom_init.c still needs to identify IBM pSeries
> (PAPR) machines in order to run some platform specific code on them like
> instantiating the TCE tables. The code doing that detection was changed
> recently in 2.6.17 early stages but was done slightly incorrectly. It
> should be testing for an exact match of "chrp" and it currently tests
> for anything that begins with "chrp". That means it will incorrectly
> match with platforms using Maple-like device-trees and have open
> firmware. This fixes it by using strcmp instead of strncmp to match what
> the actual platform detection code does.
> 
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> 
>  arch/powerpc/kernel/prom_init.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6-powerpc/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- linux-2.6-powerpc.orig/arch/powerpc/kernel/prom_init.c
> +++ linux-2.6-powerpc/arch/powerpc/kernel/prom_init.c
> @@ -1636,7 +1636,8 @@ static int __init prom_find_machine_type
>  			   compat, sizeof(compat)-1);
>  	if (len <= 0)
>  		return PLATFORM_GENERIC;
> -	if (strncmp(compat, RELOC("chrp"), 4))
> +	compat[len] = 0;
> +	if (strcmp(compat, RELOC("chrp")))
>  		return PLATFORM_GENERIC;
>  
>  	/* Default to pSeries. We need to know if we are running LPAR */
> 

^ permalink raw reply

* Re: [PATCH 01/16] ehca: module infrastructure
From: Randy.Dunlap @ 2006-05-15 21:14 UTC (permalink / raw)
  To: Heiko J Schick
  Cc: linux-kernel, openib-general, linuxppc-dev, RAISCH, HNGUYEN,
	MEDER
In-Reply-To: <4468BD39.3010008@de.ibm.com>

On Mon, 15 May 2006 19:41:13 +0200 Heiko J Schick wrote:

> Signed-off-by: Heiko J Schick <schickhj@de.ibm.com>
> 
> 
>   drivers/infiniband/hw/ehca/ehca_main.c |  966 +++++++++++++++++++++++++++++++++
>   1 file changed, 966 insertions(+)
> 
> 
> 
> --- linux-2.6.17-rc2-orig/drivers/infiniband/hw/ehca/ehca_main.c	1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.17-rc2/drivers/infiniband/hw/ehca/ehca_main.c	2006-05-15 19:17:26.000000000 +0200

> @@ -0,0 +1,966 @@

> +int ehca_open_aqp1     = 0;
> +int ehca_debug_level   = -1;
> +int ehca_hw_level      = 0;
> +int ehca_nr_ports      = 2;
> +int ehca_use_hp_mr     = 0;
> +int ehca_port_act_time = 30;
> +int ehca_poll_all_eqs  = 1;
> +int ehca_static_rate   = -1;

Don't need to init globals to 0.

---
~Randy

^ permalink raw reply

* Re: [PATCH] remove powerpc bitops infavor of existing generic bitops
From: jschopp @ 2006-05-15 20:42 UTC (permalink / raw)
  To: Jon Mason; +Cc: linuxppc-dev
In-Reply-To: <20060515203815.GC17646@us.ibm.com>

> Ah but here's the trick, there is the same explicit call to ppc
> assembly.  The only function in the file removed is this one you pointed
> out, and the only caller of this function is ext2_ffz.  And the only
> user of ext2_ffz is find_next_zero_le_bit.  
> 
> Now the generic code is very similar to the file removed (`diff -Narup
> arch/powerpc/lib/bitops.c lib/find_next_bit.c` to see for yourself).  In
> the same place where ext2_ffz is called, ffz is called in the generic
> code.  Now if we look at the definition of ffz in
> include/asm-powerpc/bitops.h, we see it calls __ilog2 of that same file.
> __ilog2 is defined as: 
> 
> static __inline__ int __ilog2(unsigned long x)
> {
>         int lz;
> 
>         asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (x));
>         return BITS_PER_LONG - 1 - lz;
> }
> 
> So, its really the same code :)

Good explination.  I'm convinced, so for what it's worth:

Acked-by: Joel Schopp <jschopp@austin.ibm.com>

^ permalink raw reply

* NOT_COHERENT_CACHE: 1. kernel oops in page_add_file_rmap() and 2. crash with HIGHMEM support
From: Gerhard Pircher @ 2006-05-15 22:25 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <3746.1147538916@www086.gmx.net>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 3647 bytes --]

Hi,

I applied the CONFIG_NOT_COHERENT_CACHE option for the AmigaOne, which has a
northbridge with cache coherence problems. Unfortunately the kernel now
crashes when viewing DVD (for example with totem) and when support for
HIGHMEM is compiled in. Kernel version is 2.6.8-16 (debian).

First some infos:
To get NOT_COHERENT_CACHE working on the AmigaOne, I had to limit the PCI
memory and ISA IO/MEM space of the northbridge first and then changed the
CONFIG_CONSISTENT_BASE parameter from 0xFF100000 to 0xF8100000
(CONSISTENT_SIZE is still set to 0x00200000 = 2MB).

The IO/MEM space was previously mapped like this in the platform setup:
io_block_mapping(0xF0000000, 0xF0000000, 0x10000000, _PAGE_IO)

I changed this line to:
io_block_mapping(0xFD000000, 0xFD000000, 0x01000000, _PAGE_IO) -> ISA MEM
and
io_block_mapping(0xFE000000, 0xFE000000, 0x02000000, _PAGE_IO) -> ISA IO/PCI
config space.
These address ranges are mapped by BATs.

The PCI memory normally goes from 0x80000000 to 0xFCFFFFFF, but is limited
to 0xEFFFFFFF in the PCI host controller resource initialization:

amigaone_init_resource(&hose->mem_resources[0], 0x80000000, 0x0xEFFFFFFF,
IORESOURCE_MEM);

With this setup DMA (and UDMA for IDE devices) works without any data
corruption. I tested this with around 500 MD5 checksum tests of three
different files with a file size of at least 100 MB. But when I view a DVD
for example (without HIGHMEM support), the system crashes with the following
kernel oops:

May 12 00:04:17 localhost kernel: kernel BUG in page_add_file_rmap at
mm/rmap.c:387!
May 12 00:04:17 localhost kernel: Oops: Exception in kernel mode, sig: 5
[#1]
May 12 00:04:17 localhost kernel: NIP: C004968C LR: C0044CB8 SP: D2C77E20
REGS: d2c77d70 TRAP: 0700    Not tainted
May 12 00:04:17 localhost kernel: MSR: 00029032 EE: 1 PR: 0 FP: 0 ME: 1
IR/DR: 11
May 12 00:04:17 localhost kernel: TASK = d4918000[2900] 'totem' THREAD:
d2c76000Last syscall: 246
May 12 00:04:17 localhost kernel: GPR00: 00000001 D2C77E20 D4918000 C0D02720
00000000 D27B02A0 02000000 D4FE4400
May 12 00:04:17 localhost kernel: GPR08: C03D0000 38139785 00000000 38139785
24048444 10054698 00000000 10171158
May 12 00:04:17 localhost kernel: GPR16: 00000000 00000000 0EADDD7C 00015F90
000001F6 315B1970 33CA8000 D4D6BBA0
May 12 00:04:17 localhost kernel: GPR24: 00000000 00000000 02000000 D4B7D33C
33CA8000 C0D02720 38139785 D2888220
May 12 00:04:17 localhost kernel: NIP [c004968c] page_add_file_rmap+0x8/0x78
May 12 00:04:17 localhost kernel: LR [c0044cb8] do_no_page+0x1cc/0x37c
May 12 00:04:17 localhost kernel: Call trace:
May 12 00:04:17 localhost kernel:  [c004503c] handle_mm_fault+0xf4/0x174
May 12 00:04:17 localhost kernel:  [c0012100] do_page_fault+0x140/0x398
May 12 00:04:17 localhost kernel:  [c0008178] handle_page_fault+0xc/0x80

Does anybody know how I can debug this crash, or what's happening here? I
don't think that the PCI memory is the cause for this crash, because the
CONSISTENT_BASE address is a virtual address, which is not mapped phyiscally
to the same address (phys = virt)!?

The second problem is HIGHMEM support in combination with
NOT_COHERENT_CACHE. When both options are enabled, the kernel crashes within
kmap_atomic() early in the boot process. kmap_atomic() is called by
__dma_sync_page_highmem(). I guess it should work even, if I have only 512MB
RAM. I moved the PKMAP_BASE to 0xF0000000, because the default address is
again within the ISA MEM space.

Did anyone else experience this problem?

Thanks in advance!

regards,

Gerhard

-- 
Mobile Internet - E-Mail und Internet immer und überall!
GMX zum Mitnehmen: http://www.gmx.net/de/go/pocketweb

^ permalink raw reply

* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-15 22:44 UTC (permalink / raw)
  To: Andrew Morton
  Cc: davej, tony.luck, linuxppc-dev, ak, bob.picco, linux-kernel,
	linux-mm
In-Reply-To: <20060515122728.GA29253@skynet.ie>

> diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc4-mm4-clean/mm/page_alloc.c linux-2.6.17-rc4-mm4-ia64_force_alignment/mm/page_alloc.c
> --- linux-2.6.17-rc4-mm4-clean/mm/page_alloc.c	2006-05-15 10:37:55.000000000 +0100
> +++ linux-2.6.17-rc4-mm4-ia64_force_alignment/mm/page_alloc.c	2006-05-15 13:10:42.000000000 +0100
> @@ -2640,14 +2640,20 @@ void __init free_area_init_nodes(unsigne
> {
> 	unsigned long nid;
> 	int zone_index;
> +	unsigned long lowest_pfn = find_min_pfn_with_active_regions();
> +
> +	lowest_pfn = zone_boundary_align_pfn(lowest_pfn);
> +	arch_max_dma_pfn = zone_boundary_align_pfn(arch_max_dma_pfn);
> +	arch_max_dma32_pfn = zone_boundary_align_pfn(arch_max_dma32_pfn);
> +	arch_max_low_pfn = zone_boundary_align_pfn(arch_max_low_pfn);
> +	arch_max_high_pfn = zone_boundary_align_pfn(arch_max_high_pfn);
>
> 	/* Record where the zone boundaries are */
> 	memset(arch_zone_lowest_possible_pfn, 0,
> 				sizeof(arch_zone_lowest_possible_pfn));
> 	memset(arch_zone_highest_possible_pfn, 0,
> 				sizeof(arch_zone_highest_possible_pfn));
> -	arch_zone_lowest_possible_pfn[ZONE_DMA] =
> -					find_min_pfn_with_active_regions();
> +	arch_zone_lowest_possible_pfn[ZONE_DMA] = lowest_pfn;
> 	arch_zone_highest_possible_pfn[ZONE_DMA] = arch_max_dma_pfn;
> 	arch_zone_highest_possible_pfn[ZONE_DMA32] = arch_max_dma32_pfn;
> 	arch_zone_highest_possible_pfn[ZONE_NORMAL] = arch_max_low_pfn;
>

Ok, this patch is broken in a number of ways. It doesn't help the IA64 
problem at all and two other machine configurations failed with the patch 
applied during regression testing. Please drop and I'll figure out what 
the correct solution is to your IA64 machine not booting.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

^ permalink raw reply

* RE: Routing problem
From: Yang, Steve @ 2006-05-15 16:08 UTC (permalink / raw)
  To: Antonio Di Bacco, linuxppc-embedded

Antonio,

Try this:

  sysctl net.ipv4.ip_forward=3D1=20

Regards,=20
Steve Yang
510-749-4535 Alameda
AIM: steveyang4535

-----Original Message-----
From: linuxppc-embedded-bounces+syang=3Dwindriver.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+syang=3Dwindriver.com@ozlabs.org] On
Behalf Of Antonio Di Bacco
Sent: Friday, May 12, 2006 1:53 PM
To: linuxppc-embedded@ozlabs.org
Subject: Routing problem

Hi all,

I have a board with an MPC880 using the tow FECs as two ethernet
interfaces. I tried to enable the ip forwarding with no success. I have
issued  "echo 1=20
> /proc/sys/net/ipv4/ip_forward", is it sufficient to make Linux work as

> a
router?

Bye,
Antonio.=20
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* [patch]: pmac nvram driver shouldn't be compileable as a module
From: Guido Guenther @ 2006-05-15 23:01 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: paulus

Hi,
currently when selecting CONFIG_NVRAM=m on PPC_PMAC on loading the nvram
module one gets:

nvram: module license 'unspecified' taints kernel.
nvram: Unknown symbol of_address_to_resource
nvram: Unknown symbol __alloc_bootmem
nvram: Unknown symbol pmac_newworld

instead of exporting all these to modules it'd be nice to make the
corresponding CONFIG_NVRAM options bool instead of tristate on PMAC_PPC.
I don't think it's intended to be compiled as a module, since it resides
under arch/powerpc/platforms/powermac and not drivers/macintosh. Is
there an easier way to achive this with the build system than the patch
below? If not, please apply.

--- orig/linux-2.6.17-rc4/drivers/char/Kconfig	2006-05-14 21:57:51.000000000 -0500
+++ linux-2.6.17-rc4/drivers/char/Kconfig	2006-05-15 17:06:10.000000000 -0500
@@ -687,7 +687,7 @@
 
 config NVRAM
 	tristate "/dev/nvram support"
-	depends on ATARI || X86 || ARM || GENERIC_NVRAM
+	depends on ATARI || X86 || ARM || (GENERIC_NVRAM && !PPC_PMAC)
 	---help---
 	  If you say Y here and create a character special file /dev/nvram
 	  with major number 10 and minor number 144 using mknod ("man mknod"),
--- orig/linux-2.6.17-rc4/drivers/macintosh/Kconfig	2006-03-19 23:53:29.000000000 -0600
+++ linux-2.6.17-rc4/drivers/macintosh/Kconfig	2006-05-15 17:14:40.000000000 -0500
@@ -200,4 +200,13 @@
 	tristate "Support for ANS LCD display"
 	depends on ADB_CUDA && PPC_PMAC
 
+config PMAC_NVRAM
+	bool "/dev/nvram support"
+	depends on GENERIC_NVRAM && PPC_PMAC
+	---help---
+	  If you say Y here and create a character special file /dev/nvram with
+	  major number 10 and minor number 144 using mknod ("man mknod"), you
+	  get read and write access to the non-volatile memory of your
+	  machine.
+
 endmenu
diff -u -u orig/linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile
--- orig/linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile	2006-03-19 23:53:29.000000000 -0600
+++ linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile	2006-05-15 17:22:43.000000000 -0500
@@ -6,7 +6,7 @@
 obj-$(CONFIG_PMAC_BACKLIGHT)	+= backlight.o
 obj-$(CONFIG_CPU_FREQ_PMAC)	+= cpufreq_32.o
 obj-$(CONFIG_CPU_FREQ_PMAC64)	+= cpufreq_64.o
-obj-$(CONFIG_NVRAM)		+= nvram.o
+obj-$(CONFIG_PMAC_NVRAM)	+= nvram.o
 # ppc64 pmac doesn't define CONFIG_NVRAM but needs nvram stuff
 obj-$(CONFIG_PPC64)		+= nvram.o
 obj-$(CONFIG_PPC32)		+= bootx_init.o

Singed-Off-By: Guido Guenther <agx@sigxcpu.org>
Cheers,
 -- Guido

^ permalink raw reply

* Re: [patch]: pmac nvram driver shouldn't be compileable as a module
From: Benjamin Herrenschmidt @ 2006-05-15 23:11 UTC (permalink / raw)
  To: Guido Guenther; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060515230115.GA9172@bogon.ms20.nix>

On Mon, 2006-05-15 at 18:01 -0500, Guido Guenther wrote:
> Hi,
> currently when selecting CONFIG_NVRAM=m on PPC_PMAC on loading the nvram
> module one gets:
> 
> nvram: module license 'unspecified' taints kernel.
> nvram: Unknown symbol of_address_to_resource
> nvram: Unknown symbol __alloc_bootmem
> nvram: Unknown symbol pmac_newworld
> 
> instead of exporting all these to modules it'd be nice to make the
> corresponding CONFIG_NVRAM options bool instead of tristate on PMAC_PPC.
> I don't think it's intended to be compiled as a module, since it resides
> under arch/powerpc/platforms/powermac and not drivers/macintosh. Is
> there an easier way to achive this with the build system than the patch
> below? If not, please apply.

Maybe simply not wrapping it with CONFIG_NVRAM ... 

Ben.

> --- orig/linux-2.6.17-rc4/drivers/char/Kconfig	2006-05-14 21:57:51.000000000 -0500
> +++ linux-2.6.17-rc4/drivers/char/Kconfig	2006-05-15 17:06:10.000000000 -0500
> @@ -687,7 +687,7 @@
>  
>  config NVRAM
>  	tristate "/dev/nvram support"
> -	depends on ATARI || X86 || ARM || GENERIC_NVRAM
> +	depends on ATARI || X86 || ARM || (GENERIC_NVRAM && !PPC_PMAC)
>  	---help---
>  	  If you say Y here and create a character special file /dev/nvram
>  	  with major number 10 and minor number 144 using mknod ("man mknod"),
> --- orig/linux-2.6.17-rc4/drivers/macintosh/Kconfig	2006-03-19 23:53:29.000000000 -0600
> +++ linux-2.6.17-rc4/drivers/macintosh/Kconfig	2006-05-15 17:14:40.000000000 -0500
> @@ -200,4 +200,13 @@
>  	tristate "Support for ANS LCD display"
>  	depends on ADB_CUDA && PPC_PMAC
>  
> +config PMAC_NVRAM
> +	bool "/dev/nvram support"
> +	depends on GENERIC_NVRAM && PPC_PMAC
> +	---help---
> +	  If you say Y here and create a character special file /dev/nvram with
> +	  major number 10 and minor number 144 using mknod ("man mknod"), you
> +	  get read and write access to the non-volatile memory of your
> +	  machine.
> +
>  endmenu
> diff -u -u orig/linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile
> --- orig/linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile	2006-03-19 23:53:29.000000000 -0600
> +++ linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile	2006-05-15 17:22:43.000000000 -0500
> @@ -6,7 +6,7 @@
>  obj-$(CONFIG_PMAC_BACKLIGHT)	+= backlight.o
>  obj-$(CONFIG_CPU_FREQ_PMAC)	+= cpufreq_32.o
>  obj-$(CONFIG_CPU_FREQ_PMAC64)	+= cpufreq_64.o
> -obj-$(CONFIG_NVRAM)		+= nvram.o
> +obj-$(CONFIG_PMAC_NVRAM)	+= nvram.o
>  # ppc64 pmac doesn't define CONFIG_NVRAM but needs nvram stuff
>  obj-$(CONFIG_PPC64)		+= nvram.o
>  obj-$(CONFIG_PPC32)		+= bootx_init.o
> 
> Singed-Off-By: Guido Guenther <agx@sigxcpu.org>
> Cheers,
>  -- Guido

^ permalink raw reply

* Re: route problem and simple sniffer
From: Wolfgang Denk @ 2006-05-15 23:29 UTC (permalink / raw)
  To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200605152209.13033.antonio.dibacco@aruba.it>

In message <200605152209.13033.antonio.dibacco@aruba.it> you wrote:
> Anyone knows a lightweight sniffer for linux embedded?

tcpdump ?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
How come everyone's going so slow if it's called rush hour?

^ permalink raw reply

* Re: [patch]: pmac nvram driver shouldn't be compileable as a module
From: Guido Guenther @ 2006-05-15 23:39 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147734713.13588.0.camel@localhost.localdomain>

On Tue, May 16, 2006 at 09:11:53AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2006-05-15 at 18:01 -0500, Guido Guenther wrote:
> > Hi,
> > currently when selecting CONFIG_NVRAM=3Dm on PPC_PMAC on loading the nv=
ram
> > module one gets:
> >=20
> > nvram: module license 'unspecified' taints kernel.
> > nvram: Unknown symbol of_address_to_resource
> > nvram: Unknown symbol __alloc_bootmem
> > nvram: Unknown symbol pmac_newworld
> >=20
> > instead of exporting all these to modules it'd be nice to make the
> > corresponding CONFIG_NVRAM options bool instead of tristate on PMAC_PPC.
> > I don't think it's intended to be compiled as a module, since it resides
> > under arch/powerpc/platforms/powermac and not drivers/macintosh. Is
> > there an easier way to achive this with the build system than the patch
> > below? If not, please apply.
>=20
> Maybe simply not wrapping it with CONFIG_NVRAM ...=20
=2E..which would make it non selectable at all. That's why I introduced
the PMAC_NVRAM.
 -- Guido
>=20
> Ben.
>=20
> > --- orig/linux-2.6.17-rc4/drivers/char/Kconfig	2006-05-14 21:57:51.0000=
00000 -0500
> > +++ linux-2.6.17-rc4/drivers/char/Kconfig	2006-05-15 17:06:10.000000000=
 -0500
> > @@ -687,7 +687,7 @@
> > =20
> >  config NVRAM
> >  	tristate "/dev/nvram support"
> > -	depends on ATARI || X86 || ARM || GENERIC_NVRAM
> > +	depends on ATARI || X86 || ARM || (GENERIC_NVRAM && !PPC_PMAC)
> >  	---help---
> >  	  If you say Y here and create a character special file /dev/nvram
> >  	  with major number 10 and minor number 144 using mknod ("man mknod"),
> > --- orig/linux-2.6.17-rc4/drivers/macintosh/Kconfig	2006-03-19 23:53:29=
=2E000000000 -0600
> > +++ linux-2.6.17-rc4/drivers/macintosh/Kconfig	2006-05-15 17:14:40.0000=
00000 -0500
> > @@ -200,4 +200,13 @@
> >  	tristate "Support for ANS LCD display"
> >  	depends on ADB_CUDA && PPC_PMAC
> > =20
> > +config PMAC_NVRAM
> > +	bool "/dev/nvram support"
> > +	depends on GENERIC_NVRAM && PPC_PMAC
> > +	---help---
> > +	  If you say Y here and create a character special file /dev/nvram wi=
th
> > +	  major number 10 and minor number 144 using mknod ("man mknod"), you
> > +	  get read and write access to the non-volatile memory of your
> > +	  machine.
> > +
> >  endmenu
> > diff -u -u orig/linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefi=
le linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile
> > --- orig/linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile	2006=
-03-19 23:53:29.000000000 -0600
> > +++ linux-2.6.17-rc4/arch/powerpc/platforms/powermac/Makefile	2006-05-1=
5 17:22:43.000000000 -0500
> > @@ -6,7 +6,7 @@
> >  obj-$(CONFIG_PMAC_BACKLIGHT)	+=3D backlight.o
> >  obj-$(CONFIG_CPU_FREQ_PMAC)	+=3D cpufreq_32.o
> >  obj-$(CONFIG_CPU_FREQ_PMAC64)	+=3D cpufreq_64.o
> > -obj-$(CONFIG_NVRAM)		+=3D nvram.o
> > +obj-$(CONFIG_PMAC_NVRAM)	+=3D nvram.o
> >  # ppc64 pmac doesn't define CONFIG_NVRAM but needs nvram stuff
> >  obj-$(CONFIG_PPC64)		+=3D nvram.o
> >  obj-$(CONFIG_PPC32)		+=3D bootx_init.o
> >=20
> > Singed-Off-By: Guido Guenther <agx@sigxcpu.org>
> > Cheers,
> >  -- Guido
>=20

^ permalink raw reply

* Re: route problem and simple sniffer
From: Carlos Munoz @ 2006-05-16  0:11 UTC (permalink / raw)
  To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060515232925.C2F24353B1A@atlas.denx.de>

Wolfgang Denk wrote:

>In message <200605152209.13033.antonio.dibacco@aruba.it> you wrote:
>  
>
>>Anyone knows a lightweight sniffer for linux embedded?
>>    
>>
>
>tcpdump ?
>
>Best regards,
>
>Wolfgang Denk
>
>  
>
Yes, that's what I do. I run the following command on my embedded device:

    tcpdump -i eth2 -s 1500 -w /tmp/tcpdump.log

and then upload the tcpdump.log file to my desktop and view it with 
ethereal.


Carlos

^ permalink raw reply

* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Nick Piggin @ 2006-05-16  0:31 UTC (permalink / raw)
  To: KAMEZAWA Hiroyuki
  Cc: akpm, davej, tony.luck, linuxppc-dev, mel, linux-kernel,
	bob.picco, ak, linux-mm
In-Reply-To: <20060515192918.c3e2e895.kamezawa.hiroyu@jp.fujitsu.com>

KAMEZAWA Hiroyuki wrote:

>On Mon, 15 May 2006 11:19:27 +0100
>Andy Whitcroft <apw@shadowen.org> wrote:
>
>>>
>>>Recently arrived? Over a year ago with the no-buddy-bitmap patches,
>>>right? Just checking because I that's what I'm assuming broke it...
>>>
>>Yep, sorry I forget I was out of the game for 6 months!  And yes that
>>was when the requirements were altered.
>>
>>
>When no-bitmap-buddy patches was included,
>
>1. bad_range() is not covered by CONFIG_VM_DEBUG. It always worked.
>==
>static int bad_range(struct zone *zone, struct page *page)
>{
>        if (page_to_pfn(page) >= zone->zone_start_pfn + zone->spanned_pages)
>                return 1;
>        if (page_to_pfn(page) < zone->zone_start_pfn)
>                return 1;
>==
>And , this code
>==
>                buddy = __page_find_buddy(page, page_idx, order);
>
>                if (bad_range(zone, buddy))
>                        break;
>==
>
>checked whether buddy is in zone and guarantees it to have page struct.
>

Ah, my mistake indeed. Sorry.

>But clean-up/speed-up codes vanished these checks. (I don't know when this occurs)
>Sorry for misses these things.
>

I think if anything they should be moved into page_is_buddy, however 
page_to_pfn
is expensive on some architectures, so it is something we want to be 
able to opt
out of if we do the correct alignment.

--
Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply

* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: KAMEZAWA Hiroyuki @ 2006-05-16  1:34 UTC (permalink / raw)
  To: Nick Piggin
  Cc: akpm, davej, tony.luck, linuxppc-dev, mel, linux-kernel,
	bob.picco, ak, linux-mm
In-Reply-To: <44691D7C.5060208@yahoo.com.au>

On Tue, 16 May 2006 10:31:56 +1000
Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> >But clean-up/speed-up codes vanished these checks. (I don't know when this occurs)
> >Sorry for misses these things.
> >
> 
> I think if anything they should be moved into page_is_buddy, however 
> page_to_pfn
> is expensive on some architectures, so it is something we want to be 
> able to opt
> out of if we do the correct alignment.
> 

yes. It's expensive.
I received following e-Mail from Dave Hansen in past.
==
There are some ppc64 machines which have memory laid out like this:

  0-100 MB Node0
100-200 MB Node1
200-300 MB Node0
==
I didn't imagine above (strange) configration.
So, simple range check will not work for all configration anyway.
(above example is aligned and has no problem.  Moreover, ppc uses SPARSEMEM.)

Andy's page_zone(page) == page_zone(buddy) check is good, I think.

Making alignment is a difficult problem, I think. It complecates many things.
We can avoid above check only when memory layout is ideal.

BTW, How about following patch ?
I don't want to  say "Oh, you have to re-compile your kernel with 
CONFIG_UNALIGNED_ZONE on your new machine. you are unlucky." to users.

==

Index: linux-2.6.17-rc4-mm1/mm/page_alloc.c
===================================================================
--- linux-2.6.17-rc4-mm1.orig/mm/page_alloc.c
+++ linux-2.6.17-rc4-mm1/mm/page_alloc.c
@@ -58,6 +58,7 @@ unsigned long totalhigh_pages __read_mos
 unsigned long totalreserve_pages __read_mostly;
 long nr_swap_pages;
 int percpu_pagelist_fraction;
+int unaligned_zone;
 
 static void __free_pages_ok(struct page *page, unsigned int order);
 
@@ -296,12 +297,12 @@ static inline void rmv_page_order(struct
  *
  * Assumption: *_mem_map is contigious at least up to MAX_ORDER
  */
-static inline struct page *
+static inline long *
 __page_find_buddy(struct page *page, unsigned long page_idx, unsigned int order)
 {
 	unsigned long buddy_idx = page_idx ^ (1 << order);
 
-	return page + (buddy_idx - page_idx);
+	return (buddy_idx - page_idx);
 }
 
 static inline unsigned long
@@ -310,6 +311,23 @@ __find_combined_index(unsigned long page
 	return (page_idx & ~(1 << order));
 }
 
+static inline struct page *
+buddy_in_range(struct zone *zone, struct page *page, long buddy_idx)
+{
+	unsigned long pfn;
+	struct page *buddy;
+	if (!unaligned_zone)
+		return page + buddy_idx;
+	pfn = page_to_pfn(page);
+	if (!pfn_valid(pfn + buddy_idx))
+		return NULL;
+	buddy = page + buddy_idx;
+	if (page_zone_id(page) != page_zone_id(buddy))
+		return NULL;
+	return buddy;
+}
+
+
 /*
  * This function checks whether a page is free && is the buddy
  * we can do coalesce a page and its buddy if
@@ -326,15 +344,10 @@ __find_combined_index(unsigned long page
 static inline int page_is_buddy(struct page *page, struct page *buddy,
 								int order)
 {
-#ifdef CONFIG_HOLES_IN_ZONE
+#if defined(CONFIG_HOLES_IN_ZONE)
 	if (!pfn_valid(page_to_pfn(buddy)))
 		return 0;
 #endif
-#ifdef CONFIG_UNALIGNED_ZONE_BOUNDRIES
-	if (page_zone_id(page) != page_zone_id(buddy))
-		return 0;
-#endif
-
 	if (PageBuddy(buddy) && page_order(buddy) == order) {
 		BUG_ON(page_count(buddy) != 0);
 		return 1;
@@ -383,10 +396,14 @@ static inline void __free_one_page(struc
 	zone->free_pages += order_size;
 	while (order < MAX_ORDER-1) {
 		unsigned long combined_idx;
+		long buddy_idx;
 		struct free_area *area;
 		struct page *buddy;
 
-		buddy = __page_find_buddy(page, page_idx, order);
+		buddy_idx = __page_find_buddy(page, page_idx, order);
+		buddy = buddy_in_zone(zone, page, buddy_idx);
+		if (unlikely(!buddy))
+			break;
 		if (!page_is_buddy(page, buddy, order))
 			break;		/* Move the buddy up one level. */
 
@@ -2434,10 +2451,9 @@ static void __meminit free_area_init_cor
 		struct zone *zone = pgdat->node_zones + j;
 		unsigned long size, realsize;
 
-		if (zone_boundary_align_pfn(zone_start_pfn) != zone_start_pfn)
-			printk(KERN_CRIT "node %d zone %s missaligned "
-				"start pfn, enable UNALIGNED_ZONE_BOUNDRIES\n",
-							nid, zone_names[j]);
+		if (zone_boundary_align_pfn(zone_start_pfn) != zone_start_pfn) {
+			unaligned_zone = 1;
+		}
 
 		size = zone_present_pages_in_node(nid, j, zones_size);
 		realsize = size - zone_absent_pages_in_node(nid, j,
Index: linux-2.6.17-rc4-mm1/include/linux/mmzone.h
===================================================================
--- linux-2.6.17-rc4-mm1.orig/include/linux/mmzone.h
+++ linux-2.6.17-rc4-mm1/include/linux/mmzone.h
@@ -399,11 +399,7 @@ static inline int is_dma(struct zone *zo
 
 static inline unsigned long zone_boundary_align_pfn(unsigned long pfn)
 {
-#ifdef CONFIG_UNALIGNED_ZONE_BOUNDRIES
-	return pfn;
-#else
 	return pfn & ~((1 << MAX_ORDER) - 1);
-#endif
 }
 
 /* These two functions are used to setup the per zone pages min values */

^ permalink raw reply

* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Nick Piggin @ 2006-05-16  2:11 UTC (permalink / raw)
  To: KAMEZAWA Hiroyuki
  Cc: akpm, davej, tony.luck, linuxppc-dev, mel, linux-kernel,
	bob.picco, ak, linux-mm
In-Reply-To: <20060516103415.ad964bdf.kamezawa.hiroyu@jp.fujitsu.com>

KAMEZAWA Hiroyuki wrote:

>
>Andy's page_zone(page) == page_zone(buddy) check is good, I think.
>
>Making alignment is a difficult problem, I think. It complecates many things.
>We can avoid above check only when memory layout is ideal.
>
>BTW, How about following patch ?
>I don't want to  say "Oh, you have to re-compile your kernel with 
>CONFIG_UNALIGNED_ZONE on your new machine. you are unlucky." to users.
>

No, this is a function of the architecture code, not the specific
machine it is running on.

So if the architecture ensures alignment and no holes, then they don't
need the overhead of CONFIG_UNALIGNED_ZONE or CONFIG_HOLES_IN_ZONE.

If they do not ensure correct alignment, then they must enable
CONFIG_UNALIGNED_ZONE, even if there may be actual systems which do
result in aligned zones.
--

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply

* Re: ppc32 kernel boot problem (pmu related?)
From: Nathan Pilatzke @ 2006-05-16  4:06 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1147658309.21291.73.camel@localhost.localdomain>

Ok, here is the new log:

time_init: processor frequency =3D 700.000000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7,524288 bytes)
Inode-cache hash table entries: 65536 (order: 6,262144 bytes)
Memory: 643456k/655360k available (2908k kernel code, 11564k reserved,
272k data, 131k bss, 156k init)
Mount-cache hash table entries: 512
device-tree: Duplicate name in /cpus/PowerPC,G4@0, renamed to "l2-cache#1"
NET: Registered protocol family 16

KeyWest i2c @0xf8001003 irq 42 /uni-n@f8000000/i2c@f8001000
 channel 0 bus <multibus>
 channel 1 bus <multibus>
KeyWest i2c @0x80018000 irq 26 /pci@f2000000/mac-io@17/i2c@18000
 channel 0 bus <multibus>
PMU i2c /pci@f2000000/mac-io@17/via-pmu@16000/pmu-i2c
 channel 1 bus <multibus>
 channel 2 bus <multibus>
PCI: Probing PCI hardware

And that's where is locks hard.  Just as an alternative I tried
compiling without i2c support, but the kernel locks hard at the exact
same point.  Compiling without the pmu code is the only way I can get
the kernel to boot.  There are some kernel messages missing from a
kernel compiled with pmu versus a kernel without pmu, namely:

On node 0 total pages: 163840
 DMA zone: 163840 pages, LIFO batch: 31

and

Calibrating delay loop... 49.79 BogoMIPS (lpj=3D99584)

but they do not seem to be anything serious.  Where to go from here?
Thanks for the debugging suggestions so far, keep them coming please.


On 5/14/06, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Hrm... that's pretty much when console_init() gets called, which means
> no message until the fbdev kicks in, thus we just "miss" the messages
> from there to the crash.... Can you edit arch/powerpc/kernel/udbg.c,
> there is a function called disable_early_printk() which contains a #if
> 1, turn that into #if 0 and tell me if you get a more useful log after
> the time_init thing. Thanks !
>
>
>

^ permalink raw reply

* Re: ppc32 kernel boot problem (pmu related?)
From: Benjamin Herrenschmidt @ 2006-05-16  4:43 UTC (permalink / raw)
  To: Nathan Pilatzke; +Cc: linuxppc-dev
In-Reply-To: <98889dd30605152106m9090ba3ga1a4c7706aace3ef@mail.gmail.com>


> And that's where is locks hard.  Just as an alternative I tried
> compiling without i2c support, but the kernel locks hard at the exact
> same point.  Compiling without the pmu code is the only way I can get
> the kernel to boot.  There are some kernel messages missing from a
> kernel compiled with pmu versus a kernel without pmu, namely:
> 
> On node 0 total pages: 163840
>  DMA zone: 163840 pages, LIFO batch: 31
> 
> and
> 
> Calibrating delay loop... 49.79 BogoMIPS (lpj=99584)
> 
> but they do not seem to be anything serious.  Where to go from here?
> Thanks for the debugging suggestions so far, keep them coming please.

Can you try editing arch/powerpc/platforms/powermac/low_i2c.c, in
function pmac_i2c_init(), comment out the call to pmac_i2c_devscan() and
tell me if that makes a difference.

Thanks,
Ben.

^ permalink raw reply

* Re: ppc32 kernel boot problem (pmu related?)
From: Benjamin Herrenschmidt @ 2006-05-16  4:44 UTC (permalink / raw)
  To: Nathan Pilatzke; +Cc: linuxppc-dev
In-Reply-To: <98889dd30605152106m9090ba3ga1a4c7706aace3ef@mail.gmail.com>

Oh and also send me a tarball of /proc/device-tree

Ben.

^ permalink raw reply

* "Need help to configure DNS on the Embedded system"
From: nreddy @ 2006-05-16 12:10 UTC (permalink / raw)
  To: linuxppc-embedded

Hi All,

 I am working on implementing wget future on my Embedded device.
 So i downloaded free wget sources (version 1.10.2) and compiled for my
system.
My system is walnut based one(IBM405EP processor). But wget is working if
i specify IP when i try to download some file from my support site(i gave
IP of support site), but when i specify like www.support.netenrich.com, it
is not able to resolve.

 I Modified /etc/resolve.conf, but still it says unable to resolve .

 I am using MontaVista Linux Kernel 2.4.20.

can some one let me know how to configure the DNS on any embedded systems.
I have gone through some of the meterial available on the net, but could
not resolve it.

Thanks in Advance,
Nagi Reddy.C

^ permalink raw reply

* [RFC] alsa integer control ranges
From: Johannes Berg @ 2006-05-16 12:02 UTC (permalink / raw)
  To: ALSA development; +Cc: linuxppc-dev list

Apparently all alsa userspace programs including alsamixer suck. Hence,
this patch is required to make them work properly. Why is it so hard to
do these additions/subtractions in the program or maybe even in the alsa
library? The alsa libraries already think they know better and mess up
all kinds of things.

What are your opinions on this? Should this be required? And if so, why
do we even have the value.integer.min when we can't use it anyway? 

The code this patch applies against is in
http://johannes.sipsolutions.net/snd-aoa.git/ but that isn't all too
relevant, the patch serves just as an illustration of what is wrong
here.

Thanks,
johannes

--- snd-aoa.orig/aoa/codecs/onyx/snd-aoa-codec-onyx.c	2006-05-16 12:13:39.663950213 +0200
+++ snd-aoa/aoa/codecs/onyx/snd-aoa-codec-onyx.c	2006-05-16 12:14:13.698643898 +0200
@@ -102,8 +102,8 @@ static int onyx_snd_vol_info(struct snd_
 {
 	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
 	uinfo->count = 2;
-	uinfo->value.integer.min = -128;
-	uinfo->value.integer.max = -1;
+	uinfo->value.integer.min = -128+128;
+	uinfo->value.integer.max = -1+128;
 	return 0;
 }
 
@@ -115,8 +115,8 @@ static int onyx_snd_vol_get(struct snd_k
 
 	onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, &l);
 	onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, &r);
-	ucontrol->value.integer.value[0] = l;
-	ucontrol->value.integer.value[1] = r;
+	ucontrol->value.integer.value[0] = l+128;
+	ucontrol->value.integer.value[1] = r+128;
 	return 0;
 }
 
@@ -125,8 +125,8 @@ static int onyx_snd_vol_put(struct snd_k
 {
 	struct onyx *onyx = snd_kcontrol_chip(kcontrol);
 
-	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]);
-	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]);
+	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]-128);
+	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]-128);
 	/* FIXME: we could be checking if anything changed */
 	return 1;
 }
@@ -145,8 +145,8 @@ static int onyx_snd_inputgain_info(struc
 {
 	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
 	uinfo->count = 1;
-	uinfo->value.integer.min = 3;
-	uinfo->value.integer.max = 28;
+	uinfo->value.integer.min = 3-3;
+	uinfo->value.integer.max = 28-3;
 	return 0;
 }
 
@@ -157,7 +157,7 @@ static int onyx_snd_inputgain_get(struct
 	u8 ig;
 
 	onyx_read_register(onyx, ONYX_REG_ADC_CONTROL, &ig);
-	ucontrol->value.integer.value[0] = ig & ONYX_ADC_PGA_GAIN_MASK;
+	ucontrol->value.integer.value[0] = (ig & ONYX_ADC_PGA_GAIN_MASK)-3;
 	return 0;
 }
 
@@ -169,7 +169,7 @@ static int onyx_snd_inputgain_put(struct
 
 	onyx_read_register(onyx, ONYX_REG_ADC_CONTROL, &val);
 	val &= ~ONYX_ADC_PGA_GAIN_MASK;
-	val |= ucontrol->value.integer.value[0] & ONYX_ADC_PGA_GAIN_MASK;
+	val |= (ucontrol->value.integer.value[0]+3) & ONYX_ADC_PGA_GAIN_MASK;
 	onyx_write_register(onyx, ONYX_REG_ADC_CONTROL, val);
 	return 1;
 }

^ permalink raw reply

* Re: [Alsa-devel] [RFC] alsa integer control ranges
From: Takashi Iwai @ 2006-05-16 12:27 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linuxppc-dev list, ALSA development
In-Reply-To: <1147780945.29795.110.camel@johannes>

At Tue, 16 May 2006 14:02:20 +0200,
Johannes Berg wrote:
> 
> Apparently all alsa userspace programs including alsamixer suck. Hence,
> this patch is required to make them work properly. Why is it so hard to
> do these additions/subtractions in the program or maybe even in the alsa
> library? The alsa libraries already think they know better and mess up
> all kinds of things.

It's a pretty stupid question to ask why you are stupid :)

I don't think it's alsa-lib that prevents the negative or non-zero
integer range.  The fact amixer works implies that it's an
app-specific bug.  But I'm not 100% sure and need more
inside-looking.

> What are your opinions on this? Should this be required? And if so, why
> do we even have the value.integer.min when we can't use it anyway? 

Right now, the range 0-max would make your life easier, I guess.

The min value is an API definition, and implemented and worked once.
But no drivers used yet.  So, there might be a breakage.  It's of
course to be fixed.


Takashi

^ permalink raw reply

* please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-05-16 12:35 UTC (permalink / raw)
  To: torvalds; +Cc: linuxppc-dev

Linus,

Please do a pull from the "merge" branch of

git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git

Two more small bug-fixes for powerpc.  I have put the full commit
messages and patches below.

Thanks,
Paul.

commit 3de620e8394406fd01f450b8c6e3e74464e81a78
Author: Anton Blanchard <anton@samba.org>
Date:   Wed May 10 13:05:54 2006 +1000

    [PATCH] powerpc: fix kernel version display on pseries boxes
    
    We are displaying the wrong thing on the operator panel (2x40
    character LCD).  This got broken in commit cebb21b5, when UTS_RELEASE
    got changed to system_utsname.version.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Paul Mackerras <paulus@samba.org>

diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 5eb55ef..5f79f01 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -255,7 +255,7 @@ static int __init pSeries_init_panel(voi
 {
 	/* Manually leave the kernel version on the panel. */
 	ppc_md.progress("Linux ppc64\n", 0);
-	ppc_md.progress(system_utsname.version, 0);
+	ppc_md.progress(system_utsname.release, 0);
 
 	return 0;
 }

commit cb6b2eb9bcf2f61e84dc0b55ef7e3d4923842313
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Mon May 15 15:46:03 2006 +1000

    [PATCH] Fix pSeries identification in prom_init.c
    
    The OF trampoline code prom_init.c still needs to identify IBM pSeries
    (PAPR) machines in order to run some platform specific code on them like
    instanciating the TCE tables. The code doing that detection was changed
    recently in 2.6.17 early stages but was done slightly incorrectly. It
    should be testing for an exact match of "chrp" and it currently tests
    for anything that begins with "chrp". That means it will incorrectly
    match with platforms using Maple-like device-trees and have open
    firmware. This fixes it by using strcmp instead of strncmp to match what
    the actual platform detection code does.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Paul Mackerras <paulus@samba.org>

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 078fb55..2d80653 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1636,7 +1636,7 @@ #ifdef CONFIG_PPC64
 			   compat, sizeof(compat)-1);
 	if (len <= 0)
 		return PLATFORM_GENERIC;
-	if (strncmp(compat, RELOC("chrp"), 4))
+	if (strcmp(compat, RELOC("chrp")))
 		return PLATFORM_GENERIC;
 
 	/* Default to pSeries. We need to know if we are running LPAR */

^ permalink raw reply related

* Re: [Alsa-devel] [RFC] alsa integer control ranges
From: Jaroslav Kysela @ 2006-05-16 12:31 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linuxppc-dev list, ALSA development
In-Reply-To: <1147780945.29795.110.camel@johannes>

On Tue, 16 May 2006, Johannes Berg wrote:

> Apparently all alsa userspace programs including alsamixer suck. Hence,
> this patch is required to make them work properly. Why is it so hard to
> do these additions/subtractions in the program or maybe even in the alsa
> library? The alsa libraries already think they know better and mess up
> all kinds of things.

It's better to fix apps, if they are broken.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

^ permalink raw reply

* Re: "Need help to configure DNS on the Embedded system"
From: Eberhard Stoll @ 2006-05-16 13:36 UTC (permalink / raw)
  Cc: linuxppc-embedded
In-Reply-To: <34616.61.95.208.2.1147781429.squirrel@61.95.208.2>

Which C library do you use?
Did you setup /etc/hosts.conf correctly?
It should look like this:
---
   order hosts, bind
   multi on
---

If you use glibc you shold add 'dns' to /etc/nsswitch.conf file like that:
---
   ...
   hosts: files dns
   networks: files dns
   ...
---
This will tell glibc to look for hostnames in /etc/hosts and via dns.
Additionally glibc needs the two libraries libresolv and libnss_dns for
this setting to work!

Good luck
Eberhard

^ permalink raw reply

* Re: [Alsa-devel] [RFC] alsa integer control ranges
From: Johannes Berg @ 2006-05-16 14:55 UTC (permalink / raw)
  To: Lee Revell; +Cc: linuxppc-dev list, ALSA development
In-Reply-To: <1147791186.13948.109.camel@mindpipe>

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Tue, 2006-05-16 at 10:53 -0400, Lee Revell wrote:

> Ummm... what problem is this patch fixing?

The problems that
(a) kmix, gnome-alsamixer, gnome-volume-control and others can't
    properly use the playback volume control because it has a range
    that doesn't start at 0
and
(b) alsamixer can't properly control the capture volume control for
    apparently the same reason

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox