build error in powerpc tree
Hi Ben,
Commit ef3d3246a0d06be622867d21af25f997aeeb105f (powerpc/mm: Add Strong
Access Ordering support) in the powerpc/{next,master} tree caused the
following in a powerpc allmodconfig build:
usr/include/asm/mman.h requires linux/mm.h, which does not exist in exported
headers
Also, that header file is now using CONFIG_PPC64 which we should not do
in the unprotected (by #ifdef __KERNEL__) part an exported header file,
we should use __powerpc64__ instead.
I suspect all the CONFIG_PPC64 part of the file could be surrounded by
#ifdef __KERNEL__ and the include of linux/mm.h could be moved to this
section. The file should then be changed to unifdef-y from header-y in
the Kbuild file. (Might have been easier to send a patch :-))
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp9QCh0N9abh.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
On Sun, 13 Jul 2008 15:26:56 -0600, David Hubbard wrote: Hi Hans, I propose writing a subsystem driver. (Is that properly called The SuperIO Bus Driver?) If no one thinks it's a really bad idea I will put together some code and submit it for review, and maintain it. Some hwmon chips have odd / unique probe sequences. IMHO this is where the design needs to be inspected. One of those is the w83627ehf, which Jean and Hans are familiar enough with to check my work. Thoughts? I'm afraid that making this a bus will be a bit overkill. Jim's patches are quite simple and seem todo the job. Also keep in mind that most users will be platform devices which just want to use the superio registers to find out the baseaddress of their logical device, a whole bus seems overkill for this, would the hwmon driver then need to be a superio_driver (as well as an platform_driver) or can the bus be queried / used without having to be a bustype-driver? I think that's a valid point. I am willing to keep it small, but I would prefer to follow the pattern set in other subsystems. It may be my lack of experience in designing a subsystem showing here! What are some alternative ways to implement it? In other words, Jim's patches are a good start, but maybe I am misunderstanding them. I see it as the superio-locks module, a driver that other drivers would depend on / auto-load. Is that something other subsystems also do? Well, there are two approaches to the problem. The first approach (which I think Jim took in his patches? I don't really remember) is to simply solve the problem of concurrent I/O access to the Super-I/O configuration ports (typically 0x2e/0x2f or 0x4e/0x4f). That would be a simple driver requesting the ports in question and exporting an API for other drivers to access them in a safe way. The second approach is to make it a whole subsystem, as David is suggesting. The Super-I/O driver would then not only request the I/O ports, it would also identify which Super-I/O is there, and it would create devices (in the Linux device driver model sense of the term) for every logical device we are interested in (amongst which the hwmon ones.) The hwmon drivers would have to be converted from platform drivers to superio drivers. Each approach has its advantages. The first one is rather simple and also very generic in nature. It could be reused for other purposes. The second one offers automatic loading of hwmon drivers, which would be nice to have. There's probably a middle way which would keep the simplicity of the first approach while still allowing for driver auto-loading, without changing the bus type of all drivers. It would probably take some research though. Me, I don't really care which path we choose, given that I am not the one who will take care of it. All I have to say is that this has been discussed several times over the past 2 years and nothing came out of it (as far as the mainline kernel is concerned, at least) so whatever is done now, what really matters is that it makes it into the kernel quickly. We have some drivers missing features because of this (for example real-time reading of VID pin values.) This should also not prevent us from fixing the drivers now so that they temporarily request the Super-I/O ports they are using, as Milton suggested. Not only we don't know when we will have something better to offer, but it might also help us find conflicts between drivers, so that we know which drivers should make use of the future superio driver. This could also reveal conflicts with PNP BIOS reservations, etc. Milton, will you write a patch? -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc/master: build failure
Hi Kumar, A build of today's powerpc/master tree for mpc85xx_defconfig fails like this: DTC: dts-dtb on file arch/powerpc/boot/dts/ksi8560.dts ERROR (phandle_references): Reference to non-existent node or label mpic ERROR (phandle_references): Reference to non-existent node or label mpic ERROR (phandle_references): Reference to non-existent node or label mpic ERROR (phandle_references): Reference to non-existent node or label mpic ERROR: Input tree has errors, aborting (use -f to force output) make[2]: *** [arch/powerpc/boot/ksi8560.dtb] Error 2 Probably commit dee805532a30183c4462305b4614e58bd83a7bc1 (powerpc: Add dma nodes to 83xx, 85xx and 86xx boards). -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpF71bVKajZo.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
On Monday 14 July 2008 04:02:41 am Paul Mackerras wrote:
Below attached patch defines this macro for powerpc arch. Please let
me know your comments on this.
+#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)-thread.regs)
The cast is unnecessary since tsk-thread.regs is already a struct
pt_regs *.
True.
Also note that tsk-thread.regs will be NULL for a kernel
thread.
Yes, users of task_pt_regs will verify for NULL. Updated patch attached
below.
Signed-off-by: Srinivasa DS [EMAIL PROTECTED]
---
include/asm-powerpc/processor.h |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6.26-rc9/include/asm-powerpc/processor.h
===
--- linux-2.6.26-rc9.orig/include/asm-powerpc/processor.h
+++ linux-2.6.26-rc9/include/asm-powerpc/processor.h
@@ -214,6 +214,8 @@ struct thread_struct {
#define thread_saved_pc(tsk)\
((tsk)-thread.regs? (tsk)-thread.regs-nip: 0)
+#define task_pt_regs(tsk) (tsk)-thread.regs
+
unsigned long get_wchan(struct task_struct *p);
#define KSTK_EIP(tsk) ((tsk)-thread.regs? (tsk)-thread.regs-nip: 0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Updates to powerpc.git
On Mon, 2008-07-14 at 15:49 +1000, Stephen Rothwell wrote: Hi Ben, On Mon, 14 Jul 2008 15:32:36 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: -next and -merge are now both to the same level, which is the same I think you meant -master (not -merge). Yup, typo, sorry. -merge will be updated to that level if -next is happy. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: build error in powerpc tree
On Mon, 2008-07-14 at 17:03 +1000, Stephen Rothwell wrote:
Hi Ben,
Commit ef3d3246a0d06be622867d21af25f997aeeb105f (powerpc/mm: Add Strong
Access Ordering support) in the powerpc/{next,master} tree caused the
following in a powerpc allmodconfig build:
usr/include/asm/mman.h requires linux/mm.h, which does not exist in exported
headers
Also, that header file is now using CONFIG_PPC64 which we should not do
in the unprotected (by #ifdef __KERNEL__) part an exported header file,
we should use __powerpc64__ instead.
I suspect all the CONFIG_PPC64 part of the file could be surrounded by
#ifdef __KERNEL__ and the include of linux/mm.h could be moved to this
section. The file should then be changed to unifdef-y from header-y in
the Kbuild file. (Might have been easier to send a patch :-))
I'll dbl check tomorrow. PROT_SAO must be exported always but everything
else should pretty much be under __KERNEL__. Interesting that this
hasn't shown up in Paulus test build scripts that I used.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: mman.h export fixups
Commit ef3d3246a0d06be622867d21af25f997aeeb105f (powerpc/mm: Add Strong
Access Ordering support) in the powerpc/{next,master} tree caused the
following in a powerpc allmodconfig build:
usr/include/asm/mman.h requires linux/mm.h, which does not exist in exported
headers
We should not use CONFIG_PPC64 in an unprotected (by __KERNEL__)
section of an exported include file and linux/mm.h is not exported. So
protect the whole section that is CONFIG_PPC64 with __KERNEL__ and put
the two introduced includes in there as well.
CC: Benjamin Herrenschmidt [EMAIL PROTECTED]
CC: Dave Kleikamp [EMAIL PROTECTED]
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
include/asm-powerpc/Kbuild |2 +-
include/asm-powerpc/mman.h |8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
I have included this patch in today's linux-next tree.
diff --git a/include/asm-powerpc/Kbuild b/include/asm-powerpc/Kbuild
index 34a0a8d..329ecfd 100644
--- a/include/asm-powerpc/Kbuild
+++ b/include/asm-powerpc/Kbuild
@@ -2,7 +2,6 @@ include include/asm-generic/Kbuild.asm
header-y += auxvec.h
header-y += ioctls.h
-header-y += mman.h
header-y += sembuf.h
header-y += siginfo.h
header-y += stat.h
@@ -28,6 +27,7 @@ unifdef-y += byteorder.h
unifdef-y += cputable.h
unifdef-y += elf.h
unifdef-y += nvram.h
+unifdef-y += mman.h
unifdef-y += param.h
unifdef-y += posix_types.h
unifdef-y += ptrace.h
diff --git a/include/asm-powerpc/mman.h b/include/asm-powerpc/mman.h
index f8a32e2..9209f75 100644
--- a/include/asm-powerpc/mman.h
+++ b/include/asm-powerpc/mman.h
@@ -1,9 +1,7 @@
#ifndef _ASM_POWERPC_MMAN_H
#define _ASM_POWERPC_MMAN_H
-#include asm/cputable.h
#include asm-generic/mman.h
-#include linux/mm.h
/*
* This program is free software; you can redistribute it and/or
@@ -28,7 +26,12 @@
#define MAP_POPULATE 0x8000 /* populate (prefault) pagetables */
#define MAP_NONBLOCK 0x1 /* do not block on IO */
+#ifdef __KERNEL__
#ifdef CONFIG_PPC64
+
+#include asm/cputable.h
+#include linux/mm.h
+
/*
* This file is included by linux/mman.h, so we can't use cacl_vm_prot_bits()
* here. How important is the optimization?
@@ -56,4 +59,5 @@ static inline int arch_validate_prot(unsigned long prot)
#define arch_validate_prot(prot) arch_validate_prot(prot)
#endif /* CONFIG_PPC64 */
+#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MMAN_H */
--
1.5.6.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: powerpc/generic-ipi tree build failure
Hi all, Today's linux-next build (powerpc allmodconfig) failed like this: ERROR: .save_stack_trace [tests/backtracetest.ko] undefined! But save_stack_trace is exported in arch/powerpc/kernel/stacktrace.c I couldn't figure it out until I noticed these earlier warnings: arch/powerpc/kernel/stacktrace.c:47: warning: data definition has no type or storage class arch/powerpc/kernel/stacktrace.c:47: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/powerpc/kernel/stacktrace.c:47: warning: parameter names (without types) in function declaration I applied the patch below. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ From 91ec767c487ff260455e416fee161015a8bdb0c5 Mon Sep 17 00:00:00 2001 From: Stephen Rothwell [EMAIL PROTECTED] Date: Mon, 14 Jul 2008 19:45:59 +1000 Subject: [PATCH] powerpc/stacktrace: EXPORT SYMBOL_GPL needs module.h Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/kernel/stacktrace.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c index 9861f17..3cf0d94 100644 --- a/arch/powerpc/kernel/stacktrace.c +++ b/arch/powerpc/kernel/stacktrace.c @@ -12,6 +12,7 @@ #include linux/sched.h #include linux/stacktrace.h +#include linux/module.h #include asm/ptrace.h /* -- 1.5.6.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
On Mon, 2008-07-14 at 14:01 +0530, Srinivasa D S wrote: On Monday 14 July 2008 04:02:41 am Paul Mackerras wrote: Below attached patch defines this macro for powerpc arch. Please let me know your comments on this. +#define task_pt_regs(tsk)((struct pt_regs *)(tsk)-thread.regs) The cast is unnecessary since tsk-thread.regs is already a struct pt_regs *. True. Also note that tsk-thread.regs will be NULL for a kernel thread. Yes, users of task_pt_regs will verify for NULL. Updated patch attached below. Signed-off-by: Srinivasa DS [EMAIL PROTECTED] Can you send a cleanup patch against powerpc.git instead ? Thanks ! Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
On Sat, Jul 12, 2008 at 02:39:39AM -0600, Grant Likely wrote:
ASoC Codec driver for the TLV320AIC26 device. This driver uses the ASoC
v1 API, so I don't expect it to get merged as-is, but I want to get it
out there for review.
This looks basically good - most of the issues below are nitpicky.
+ /* Configure PLL */
+ pval = 1;
+ jval = (fsref == 44100) ? 7 : 8;
+ dval = (fsref == 44100) ? 5264 : 1920;
+ qval = 0;
+ reg = 0x8000 | qval 11 | pval 8 | jval 2;
+ aic26_reg_write(codec, AIC26_REG_PLL_PROG1, reg);
+ reg = dval 2;
+ aic26_reg_write(codec, AIC26_REG_PLL_PROG2, reg);
Does the PLL configuration not depend on the input clock frequency? You
have a set_sysclk() method to configure the MCLK supplied but the driver
never appears to reference the value anywhere.
+ /* Power up CODEC */
+ aic26_reg_write(codec, AIC26_REG_POWER_CTRL, 0);
As discussed this should probably just be removed from hw_params().
+static int aic26_set_fmt(struct snd_soc_codec_dai *codec_dai, unsigned int
fmt)
+{
+ /* interface format */
+ switch (fmt SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_I2S: aic26-datfm = AIC26_DATFM_I2S; break;
+ case SND_SOC_DAIFMT_DSP_A: aic26-datfm = AIC26_DATFM_DSP; break;
+ case SND_SOC_DAIFMT_RIGHT_J: aic26-datfm = AIC26_DATFM_RIGHTJ; break;
+ case SND_SOC_DAIFMT_LEFT_J: aic26-datfm = AIC26_DATFM_LEFTJ; break;
+ default: dev_dbg(aic26-spi-dev, bad format\n); return -EINVAL;
+ }
I'm having a hard time liking this indentation style. It's not an
obstacle to merging but it doesn't really help legibility - there's not
enough white space and once you have a non-standard line like the
default: one.
+static const char *aic26_capture_src_text[] = {Mic, Aux};
+static const struct soc_enum aic26_capture_src_enum =
+ SOC_ENUM_SINGLE(AIC26_REG_AUDIO_CTRL1, 12,2, aic26_capture_src_text);
checkpatch complains about the 12,2 here and a bunch of other stuff -
ALSA is generally very strict about that.
+ SOC_SINGLE(Keyclick activate, AIC26_REG_AUDIO_CTRL2, 15, 0x1, 0),
+ SOC_SINGLE(Keyclick amplitude, AIC26_REG_AUDIO_CTRL2, 12, 0x7, 0),
+ SOC_SINGLE(Keyclick frequency, AIC26_REG_AUDIO_CTRL2, 8, 0x7, 0),
+ SOC_SINGLE(Keyclick period, AIC26_REG_AUDIO_CTRL2, 4, 0xf, 0),
This configuration is also exposed via a sysfs file, including some of
the configurability. Exposing the information via sysfs isn't a
particular problem but allowing it to be written to without going
through ALSA seems wrong.
+static ssize_t aic26_regs_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
As discussed this is replicating the existing codec register display
sysfs file.
+#if defined(CONFIG_SND_SOC_OF)
+ /* Tell the of_soc helper about this codec */
+ of_snd_soc_register_codec(aic26_soc_codec_dev, aic26, aic26_dai,
+ spi-dev.archdata.of_node);
+#endif
CONFIG_SND_SOC_OF could be a module - this needs to also check for it
being a module.
+#define AIC26_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |\
+ SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 |\
+ SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |\
+ SNDRV_PCM_RATE_48000)
+#define AIC26_FORMATS(SNDRV_PCM_FMTBIT_S8 |
SNDRV_PCM_FMTBIT_S16_BE |\
+ SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE)
These are usually kept in the driver code.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: rework FSL Book-E PTE access and TLB miss
This converts the FSL Book-E PTE access and TLB miss handling to match with the recent changes to 44x that introduce support for non-atomic PTE operations in pgtable-ppc32.h and removes write back to the PTE from the TLB miss handlers. In addition, the DSI interrupt code no longer tries to fixup write permission, this is left to generic code, and _PAGE_HWWRITE is gone. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- This will go via my powerpc-next tree. arch/powerpc/kernel/head_fsl_booke.S | 168 +- include/asm-powerpc/pgtable-ppc32.h | 15 +-- 2 files changed, 48 insertions(+), 135 deletions(-) diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index c426850..7d55496 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -483,90 +483,16 @@ interrupt_base: /* Data Storage Interrupt */ START_EXCEPTION(DataStorage) - mtspr SPRN_SPRG0, r10 /* Save some working registers */ - mtspr SPRN_SPRG1, r11 - mtspr SPRN_SPRG4W, r12 - mtspr SPRN_SPRG5W, r13 - mfcrr11 - mtspr SPRN_SPRG7W, r11 - - /* -* Check if it was a store fault, if not then bail -* because a user tried to access a kernel or -* read-protected page. Otherwise, get the -* offending address and handle it. -*/ - mfspr r10, SPRN_ESR - andis. r10, r10, [EMAIL PROTECTED] - beq 2f - - mfspr r10, SPRN_DEAR /* Get faulting address */ - - /* If we are faulting a kernel address, we have to use the -* kernel page tables. -*/ - lis r11, [EMAIL PROTECTED] - cmplw 0, r10, r11 - bge 2f - - /* Get the PGD for the current thread */ -3: - mfspr r11,SPRN_SPRG3 - lwz r11,PGDIR(r11) -4: - FIND_PTE - - /* Are _PAGE_USER _PAGE_RW set _PAGE_HWWRITE not? */ - andi. r13, r11, _PAGE_RW|_PAGE_USER|_PAGE_HWWRITE - cmpwi 0, r13, _PAGE_RW|_PAGE_USER - bne 2f /* Bail if not */ - - /* Update 'changed'. */ - ori r11, r11, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE - stw r11, PTE_FLAGS_OFFSET(r12) /* Update Linux page table */ - - /* MAS2 not updated as the entry does exist in the tlb, this - fault taken to detect state transition (eg: COW - DIRTY) -*/ - andi. r11, r11, _PAGE_HWEXEC - rlwimi r11, r11, 31, 27, 27/* SX - _PAGE_HWEXEC */ - ori r11, r11, (MAS3_UW|MAS3_SW|MAS3_UR|MAS3_SR)@l /* set static perms */ - - /* update search PID in MAS6, AS = 0 */ - mfspr r12, SPRN_PID0 - slwir12, r12, 16 - mtspr SPRN_MAS6, r12 - - /* find the TLB index that caused the fault. It has to be here. */ - tlbsx 0, r10 - - /* only update the perm bits, assume the RPN is fine */ - mfspr r12, SPRN_MAS3 - rlwimi r12, r11, 0, 20, 31 - mtspr SPRN_MAS3,r12 - tlbwe - - /* Done...restore registers and get out of here. */ - mfspr r11, SPRN_SPRG7R - mtcrr11 - mfspr r13, SPRN_SPRG5R - mfspr r12, SPRN_SPRG4R - mfspr r11, SPRN_SPRG1 - mfspr r10, SPRN_SPRG0 - rfi /* Force context change */ - -2: - /* -* The bailout. Restore registers to pre-exception conditions -* and call the heavyweights to help us out. -*/ - mfspr r11, SPRN_SPRG7R - mtcrr11 - mfspr r13, SPRN_SPRG5R - mfspr r12, SPRN_SPRG4R - mfspr r11, SPRN_SPRG1 - mfspr r10, SPRN_SPRG0 - b data_access + NORMAL_EXCEPTION_PROLOG + mfspr r5,SPRN_ESR /* Grab the ESR, save it, pass arg3 */ + stw r5,_ESR(r11) + mfspr r4,SPRN_DEAR/* Grab the DEAR, save it, pass arg2 */ + andis. r10,r5,(ESR_ILK|ESR_DLK)@h + bne 1f + EXC_XFER_EE_LITE(0x0300, handle_page_fault) +1: + addir3,r1,STACK_FRAME_OVERHEAD + EXC_XFER_EE_LITE(0x0300, CacheLockingException) /* Instruction Storage Interrupt */ INSTRUCTION_STORAGE_EXCEPTION @@ -645,15 +571,30 @@ interrupt_base: lwz r11,PGDIR(r11) 4: + /* Mask of required permission bits. Note that while we +* do copy ESR:ST to _PAGE_RW position as trying to write +* to an RO page is pretty common, we don't do it with +* _PAGE_DIRTY. We could do it, but it's a fairly rare +* event so I'd rather take the overhead when it happens +* rather than adding an instruction here. We should measure +* whether the whole thing is worth it in the first place +* as we could avoid loading SPRN_ESR completely in the first +* place... +* +* TODO: Is it worth doing that mfspr rlwimi in the first +* place or can
[PATCH 3/3] powerpc/fsl: Minor TLBSYNC cleanup for FSL Book-E
Use the TLBSYNC macro defined in ppc_asm.h rather than our own ifdefs. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- this will go via my powerpc-next tree. - k arch/powerpc/kernel/head_fsl_booke.S | 19 --- 1 files changed, 4 insertions(+), 15 deletions(-) diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 7d55496..3cb52fa 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -151,16 +151,11 @@ skpinv: addir6,r6,1 /* Increment */ /* Invalidate TLB0 */ li r6,0x04 tlbivax 0,r6 -#ifdef CONFIG_SMP - tlbsync -#endif + TLBSYNC /* Invalidate TLB1 */ li r6,0x0c tlbivax 0,r6 -#ifdef CONFIG_SMP - tlbsync -#endif - msync + TLBSYNC /* 3. Setup a temp mapping and jump to it */ andi. r5, r3, 0x1 /* Find an entry not used and is non-zero */ @@ -238,10 +233,7 @@ skpinv:addir6,r6,1 /* Increment */ /* Invalidate TLB1 */ li r9,0x0c tlbivax 0,r9 -#ifdef CONFIG_SMP - tlbsync -#endif - msync + TLBSYNC /* 6. Setup KERNELBASE mapping in TLB1[0] */ lis r6,0x1000 /* Set MAS0(TLBSEL) = TLB1(1), ESEL = 0 */ @@ -283,10 +275,7 @@ skpinv:addir6,r6,1 /* Increment */ /* Invalidate TLB1 */ li r9,0x0c tlbivax 0,r9 -#ifdef CONFIG_SMP - tlbsync -#endif - msync + TLBSYNC /* Establish the interrupt vector offsets */ SET_IVOR(0, CriticalInput); -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/master: build failure
On Jul 14, 2008, at 3:21 AM, Stephen Rothwell wrote: Hi Kumar, A build of today's powerpc/master tree for mpc85xx_defconfig fails like this: DTC: dts-dtb on file arch/powerpc/boot/dts/ksi8560.dts ERROR (phandle_references): Reference to non-existent node or label mpic ERROR (phandle_references): Reference to non-existent node or label mpic ERROR (phandle_references): Reference to non-existent node or label mpic ERROR (phandle_references): Reference to non-existent node or label mpic ERROR: Input tree has errors, aborting (use -f to force output) make[2]: *** [arch/powerpc/boot/ksi8560.dtb] Error 2 Probably commit dee805532a30183c4462305b4614e58bd83a7bc1 (powerpc: Add dma nodes to 83xx, 85xx and 86xx boards). I have fixes, just need benh to pull them. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 5/5] powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver
On 7/12/08, Grant Likely [EMAIL PROTECTED] wrote: From: Grant Likely [EMAIL PROTECTED] Adds support for the dedicated SPI device on the Freescale MPC5200(b) SoC. Can you adjust the existing PSC based SPI driver to use this device tree code? It will be confusing if there are two different ways to do SPI on the mpc5200. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Fix copper/fiber auto-selection for 88e1111
On Jul 9, 2008, at 9:14 PM, Wang Jian wrote: The 27.15 bit (MII_M_HWCFG_FIBER_COPPER_AUTO) is disable bit. When set to 1, copper/fiber auto selection is disabled. The current code to enable but actually disable auto selection. Signed-off-by: Wang Jian [EMAIL PROTECTED] --- drivers/net/phy/marvell.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) These should really get cc'd to the netdev list. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
Simple utility layer for creating ASoC machine instances based on data
in the OpenFirmware device tree. OF aware platform drivers and codec
drivers register themselves with this framework and the framework
automatically instantiates a machine driver.
Ideally someone from the PowerPC community would sign off on this -
given the nature and volume of discussion people obviously have very
strong opinions about how machine drivers should be done so I'd really
like to see some community buy in for something like this. From an ASoC
point of view if this works it's fine.
This is most likely temporary glue code to work around limitations in
the ASoC v1 framework. I expect ASoC v2 won't need this.
It will need some way of providing a machine driver, generic (like this
one) or otherwise.
+static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
+{
+ struct platform_device *pdev;
+ int rc;
+
+ /* Only register the device if both the codec and platform have
+ * been registered */
+ if ((!of_soc-device.codec_data) || (!of_soc-platform_node))
+ return;
+
+ pr_info(platform--codec match achieved; registering machine\n);
So what this does is add an extremely simple machine driver which
matches up the first DAI on a single codec and platform with no facility
for setting up any configurable clocking or anything? This is fine in
so far as it goes but it's going to work for very few systems as it is -
most codecs will need some additional configuration. This could be
added later, though.
Given this it might be worth renaming it to something less generic and
perhaps pushing it down into an of directory below the main ASoC
directory to parallel existing machine drivers. I'm happy with the code
from an ASoC point of view.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: mman.h export fixups
On Monday 14 July 2008, Stephen Rothwell wrote: index 34a0a8d..329ecfd 100644 --- a/include/asm-powerpc/Kbuild +++ b/include/asm-powerpc/Kbuild @@ -2,7 +2,6 @@ include include/asm-generic/Kbuild.asm header-y += auxvec.h header-y += ioctls.h -header-y += mman.h header-y += sembuf.h header-y += siginfo.h header-y += stat.h @@ -28,6 +27,7 @@ unifdef-y += byteorder.h unifdef-y += cputable.h unifdef-y += elf.h unifdef-y += nvram.h +unifdef-y += mman.h unifdef-y += param.h unifdef-y += posix_types.h unifdef-y += ptrace.h mman.h is already listed as unifdef-y in include/asm-generic/Kbuild.asm, so you can probably just drop it here. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On 7/14/08, Mark Brown [EMAIL PROTECTED] wrote:
On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
Simple utility layer for creating ASoC machine instances based on data
in the OpenFirmware device tree. OF aware platform drivers and codec
drivers register themselves with this framework and the framework
automatically instantiates a machine driver.
Ideally someone from the PowerPC community would sign off on this -
given the nature and volume of discussion people obviously have very
strong opinions about how machine drivers should be done so I'd really
like to see some community buy in for something like this. From an ASoC
point of view if this works it's fine.
Grant is one of the core PowerPC developers. There's no big
disagreement on the driver model, there just isn't a clean solution
for building a PowerPC ASoC driver under ASoC v1. The ASoC v1 driver
model is simply not compatible with the PowerPC device tree model.
That's why all of this glue code is needed.
Hopefully we can get the driver model sorted out in v2. If the ASoC
driver model is fixed all of this glue code disappears.
The PowerPC side isn't without fault too. PowerPC still doesn't have a
good way to load the fabric/machine driver.
Which are we going to call it, fabric or machine? I had been working
on the Apple code in sound/aoa. It is called fabric in that code. The
equivalent driver is called machine in ASoC v1.
This is most likely temporary glue code to work around limitations in
the ASoC v1 framework. I expect ASoC v2 won't need this.
It will need some way of providing a machine driver, generic (like this
one) or otherwise.
+static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
+{
+ struct platform_device *pdev;
+ int rc;
+
+ /* Only register the device if both the codec and platform have
+ * been registered */
+ if ((!of_soc-device.codec_data) || (!of_soc-platform_node))
+ return;
+
+ pr_info(platform--codec match achieved; registering machine\n);
So what this does is add an extremely simple machine driver which
matches up the first DAI on a single codec and platform with no facility
for setting up any configurable clocking or anything? This is fine in
so far as it goes but it's going to work for very few systems as it is -
most codecs will need some additional configuration. This could be
added later, though.
Given this it might be worth renaming it to something less generic and
perhaps pushing it down into an of directory below the main ASoC
directory to parallel existing machine drivers. I'm happy with the code
from an ASoC point of view.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
Simple utility layer for creating ASoC machine instances based on data
in the OpenFirmware device tree. OF aware platform drivers and codec
drivers register themselves with this framework and the framework
automatically instantiates a machine driver.
This is most likely temporary glue code to work around limitations in
the ASoC v1 framework. I expect ASoC v2 won't need this.
---
[...]
--- /dev/null
+++ b/sound/soc/soc-of.c
It's quite inconvenient to spread the firmware-specific bits over the
whole kernel source tree. So, can we place this in driver/of/, just as
we did for i2c, spi and gpio?
@@ -0,0 +1,171 @@
+/*
+ * OF helpers for ALSA SoC Layer
+ *
+ * Copyright (C) 2008, Secret Lab Technologies Ltd.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/bitops.h
+#include linux/platform_device.h
+#include linux/of.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-of.h
+#include sound/initval.h
+
+MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(ALSA SoC OpenFirmware bindings);
+
+static DEFINE_MUTEX(of_snd_soc_mutex);
+static LIST_HEAD(of_snd_soc_device_list);
+static int of_snd_soc_next_index;
+
+struct of_snd_soc_device {
+ int id;
+ struct list_head list;
+ struct snd_soc_device device;
+ struct snd_soc_machine machine;
+ struct snd_soc_dai_link dai_link;
+ struct platform_device *pdev;
+ struct device_node *platform_node;
+ struct device_node *codec_node;
+};
+
+static struct snd_soc_ops of_snd_soc_ops = {
+};
+
+static struct of_snd_soc_device *
+of_snd_soc_get_device(struct device_node *codec_node)
+{
+ struct of_snd_soc_device *of_soc;
+
+ list_for_each_entry(of_soc, of_snd_soc_device_list, list) {
+ if (of_soc-codec_node == codec_node)
+ return of_soc;
+ }
+
+ of_soc = kzalloc(sizeof(struct of_snd_soc_device), GFP_KERNEL);
+ if (!of_soc)
+ return NULL;
+
+ /* Initialize the structure and add it to the global list */
+ of_soc-codec_node = codec_node;
+ of_soc-id = of_snd_soc_next_index++;
+ of_soc-machine.dai_link = of_soc-dai_link;
+ of_soc-machine.num_links = 1;
+ of_soc-device.machine = of_soc-machine;
+ of_soc-dai_link.ops = of_snd_soc_ops;
+ list_add(of_soc-list, of_snd_soc_device_list);
+
+ return of_soc;
+}
+
+static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
+{
+ struct platform_device *pdev;
+ int rc;
+
+ /* Only register the device if both the codec and platform have
+ * been registered */
+ if ((!of_soc-device.codec_data) || (!of_soc-platform_node))
+ return;
+
+ pr_info(platform--codec match achieved; registering machine\n);
+
+ pdev = platform_device_alloc(soc-audio, of_soc-id);
+ if (!pdev) {
+ pr_err(of_soc: platform_device_alloc() failed\n);
+ return;
+ }
+
+ pdev-dev.platform_data = of_soc;
+ platform_set_drvdata(pdev, of_soc-device);
+ of_soc-device.dev = pdev-dev;
+
+ /* The ASoC device is complete; register it */
+ rc = platform_device_add(pdev);
+ if (rc) {
+ pr_err(of_soc: platform_device_add() failed\n);
+ return;
+ }
+
+}
+
+int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
+ void *codec_data, struct snd_soc_codec_dai *dai,
+ struct device_node *node)
+{
+ struct of_snd_soc_device *of_soc;
+ int rc = 0;
+
+ pr_info(registering ASoC codec driver: %s\n, node-full_name);
+
+ mutex_lock(of_snd_soc_mutex);
+ of_soc = of_snd_soc_get_device(node);
+ if (!of_soc) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ /* Store the codec data */
+ of_soc-device.codec_data = codec_data;
+ of_soc-device.codec_dev = codec_dev;
+ of_soc-dai_link.name = node-name;
+ of_soc-dai_link.stream_name = node-name;
+ of_soc-dai_link.codec_dai = dai;
+
+ /* Now try to register the SoC device */
+ of_snd_soc_register_device(of_soc);
+
+ out:
+ mutex_unlock(of_snd_soc_mutex);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(of_snd_soc_register_codec);
+
+int of_snd_soc_register_platform(struct snd_soc_platform *platform,
+ struct device_node *node,
+ struct snd_soc_cpu_dai *cpu_dai)
+{
+ struct of_snd_soc_device *of_soc;
+ struct device_node *codec_node;
+ const phandle *handle;
+ int len, rc = 0;
+
+ pr_info(registering ASoC platform driver: %s\n, node-full_name);
+
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 10:13:14AM -0400, Jon Smirl wrote: On 7/14/08, Mark Brown [EMAIL PROTECTED] wrote: Ideally someone from the PowerPC community would sign off on this - given the nature and volume of discussion people obviously have very Grant is one of the core PowerPC developers. There's no big OK, fair enough... Hopefully we can get the driver model sorted out in v2. If the ASoC driver model is fixed all of this glue code disappears. The PowerPC side isn't without fault too. PowerPC still doesn't have a good way to load the fabric/machine driver. I'm finding it difficult to square these two statements - from an ASoC point of view the main thing this patch is doing is adding a machine driver and that's not something that's going to go away. With version 2 you will get the wait for all components to come on-line logic that's implemented here from the ASoC core but that doesn't remove the need for a machine driver to tell the core what to wait for and arrange any machine specific things like clocking. It's this debate about machine drivers that makes me nervous here. Like I say, from an ASoC point of view it's not an issue and the current approach is fine. Which are we going to call it, fabric or machine? I had been working on the Apple code in sound/aoa. It is called fabric in that code. The equivalent driver is called machine in ASoC v1. ASoC has always called it a machine driver. This is most likely temporary glue code to work around limitations in the ASoC v1 framework. I expect ASoC v2 won't need this. It will need some way of providing a machine driver, generic (like this one) or otherwise. [BTW, it'd be helpful if you could delete unreferenced quotes when you reply - it makes things much easier to read, especially when reviewing lengthy patches. Unfortunately the GMail UI encourages doing this :(] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Jon Smirl wrote: Which are we going to call it, fabric or machine? Fabric. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Mark Brown wrote: The PowerPC side isn't without fault too. PowerPC still doesn't have a good way to load the fabric/machine driver. I'm finding it difficult to square these two statements - from an ASoC point of view the main thing this patch is doing is adding a machine driver and that's not something that's going to go away. Jon's concern is that there is no straightforward way to build a kernel with multiple fabric drivers and have the right one chosen via the device tree. This is just a limitation of the device tree model, and no one has come up with a good solution yet. The problem still exists in ASoC V2. However, it's not anything that ASoC itself needs to be concerned with. It's purely a PowerPC problem. Which are we going to call it, fabric or machine? I had been working on the Apple code in sound/aoa. It is called fabric in that code. The equivalent driver is called machine in ASoC v1. ASoC has always called it a machine driver. Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, it should be called a fabric driver because we already have machine drivers. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 10:14 AM, Timur Tabi [EMAIL PROTECTED] wrote: Mark Brown wrote: The PowerPC side isn't without fault too. PowerPC still doesn't have a good way to load the fabric/machine driver. I'm finding it difficult to square these two statements - from an ASoC point of view the main thing this patch is doing is adding a machine driver and that's not something that's going to go away. Jon's concern is that there is no straightforward way to build a kernel with multiple fabric drivers and have the right one chosen via the device tree. This is just a limitation of the device tree model, and no one has come up with a good solution yet. The problem still exists in ASoC V2. However, it's not anything that ASoC itself needs to be concerned with. It's purely a PowerPC problem. It's purely an *OF Device Tree* problem. PowerPC isn't the only platform using the device tree. :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: kbuild tree build failure
Hi Roman. I saw your reply on the list archives but can not find it in my inbox. On Sun Jul 13 at 09:21:08 EST 2008, Roman Zippel wrote: On Sat, 12 Jul 2008, Milton Miller wrote: (1) #define PAGE_OFFSET(ASM_CONST(CONFIG_PAGE_OFFSET) 32) It creates unreadable code, where two defines with almost the same name (the only difference being the CONFIG_ prefix, which is often ignored when scanning) contains radically different values. (2) #define PAGE_OFFSETASM_CONST(CONFIG_PAGE_OFFSET) Giving it different names is not really difficult. Any objections to CONFIG_PAGE_HIGH_OFFSET? Once you remove the symmetry and add the ifdef to page.h, we need to reevaluate its presence in Kconfig. I can't think of a reason to have a partial value, and therefore would instead say take out the config variable on PPC64 as the PPC32 address split reason is moot. On a seperate note, config PINT3_ASSIGN hex PINT3_ASSIGN depends on PINTx_REASSIGN - default 0x02020303 + default 0x2020303 is harder to read. The value is a list of 4 1 byte values, but you have hidden the first nibble making parsing the rest of the value hard. Sam mentioned that already, but that's a situation where the warning can be relaxed. The warning can be relaxed? What are you talking about? I was trying to make a case for leading zeros without actually stating what I was asking for. You changes did s/(0x)?0*/0x/, y/A-F/a-f/ -- that is you made all hex constants conform to 0x%x. I was arguing for 0x%8.8x, or just leaving them as formatted. If you are worried about users tring to set values that are too high, then make the types be hex8, hex16, hex32, and hex64. It's not this, I value consistency as much as you and the values are sometimes used as integers, so a working range is needed. Using simple integers keeps things much simpler and as the ASM_CONST example shows any bigger values are not necessarily directly usable anyway. How many places want to range check hex numbers? Is it just setting the number of digits input? If strtoull is to hard, can we just do the check as strings of digits? If we keep this new restriction on hex numbers, it needs to be in the Documentation, even if its prefixed by currently. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 11:14:41AM -0500, Timur Tabi wrote: Mark Brown wrote: I'm finding it difficult to square these two statements - from an ASoC point of view the main thing this patch is doing is adding a machine driver and that's not something that's going to go away. Jon's concern is that there is no straightforward way to build a kernel with multiple fabric drivers and have the right one chosen via the device tree. This is just a limitation of the device tree model, and no one has come up with a good solution yet. Indeed - I understand what the problem you guys have is, I just want to make sure that there is a reasonable consensus among the PowerPC people that this approach is OK to go in and won't create ructions. The lack of resolution on this issue makes me nervous about any proposed solution where I haven't seen any explicit indication that the community is OK with it. Incidentally, nobody ever really commented on my suggestion to do something DMI-like - you've already got the board type information present in the device trees (in the model and compatible information in the root nodes), all that's needed is an API to allow matching on it. The problem still exists in ASoC V2. However, it's not anything that ASoC itself needs to be concerned with. It's purely a PowerPC problem. Right, I just want to be clear that you guys all understand what this code does and that there won't be too many complaints after the fact. ASoC has always called it a machine driver. Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, it should be called a fabric driver because we already have machine drivers. I don't mind - you can call it what you like inside PowerPC-specific code. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 7:49 AM, Mark Brown
[EMAIL PROTECTED] wrote:
On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
+static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
+{
+ struct platform_device *pdev;
+ int rc;
+
+ /* Only register the device if both the codec and platform have
+ * been registered */
+ if ((!of_soc-device.codec_data) || (!of_soc-platform_node))
+ return;
+
+ pr_info(platform--codec match achieved; registering machine\n);
So what this does is add an extremely simple machine driver which
matches up the first DAI on a single codec and platform with no facility
for setting up any configurable clocking or anything? This is fine in
so far as it goes but it's going to work for very few systems as it is -
most codecs will need some additional configuration. This could be
added later, though.
Yes, that is pretty much exactly what it is. When I wrote this my
goal was just to get something working that had some semblance of
cleanliness. Since it is now looking like something that could get
merged, I'll clean up the documentation describing exactly what it is
and what the limitations are. I fully expect that if others find it
useful then they will need to extend it to extract additional
configuration information out of the device tree.
That being said, I expect this code to be completely rewritten when
ASoC v2 hits mainline. Most of the code is devoted to matching
platforms with codecs. The mechanism will be completely different
when the ASoC layer handles making sure all devices are present before
setting up the machine driver. I expect that some machines can be
handled with some form of generic of-asoc driver, while more complex
ones will need custom code.
Given this it might be worth renaming it to something less generic and
perhaps pushing it down into an of directory below the main ASoC
directory to parallel existing machine drivers. I'm happy with the code
from an ASoC point of view.
I'm okay with that. How about fsl/mpc5200-of-machine.c for now?
(only the mpc5200 i2s driver uses it at the moment). It can always be
renamed if other folks want to use it for other chips.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
On Jul 14, 2008, at 2:59 AM, Jean Delvare wrote: On Sun, 13 Jul 2008 15:26:56 -0600, David Hubbard wrote: Hi Hans, I propose writing a subsystem driver. (Is that properly called The SuperIO Bus Driver?) If no one thinks it's a really bad idea I will put together some code and submit it for review, and maintain it. Some hwmon chips have odd / unique probe sequences. IMHO this is where the design needs to be inspected. One of those is the w83627ehf, which Jean and Hans are familiar enough with to check my work. Thoughts? I'm afraid that making this a bus will be a bit overkill. Jim's patches are quite simple and seem todo the job. Also keep in mind that most users will be platform devices which just want to use the superio registers to find out the baseaddress of their logical device, a whole bus seems overkill for this, would the hwmon driver then need to be a superio_driver (as well as an platform_driver) or can the bus be queried / used without having to be a bustype-driver? I think that's a valid point. I am willing to keep it small, but I would prefer to follow the pattern set in other subsystems. It may be my lack of experience in designing a subsystem showing here! What are some alternative ways to implement it? In other words, Jim's patches are a good start, but maybe I am misunderstanding them. I see it as the superio-locks module, a driver that other drivers would depend on / auto-load. Is that something other subsystems also do? Well, there are two approaches to the problem. The first approach (which I think Jim took in his patches? I don't really remember) is to simply solve the problem of concurrent I/O access to the Super-I/O configuration ports (typically 0x2e/0x2f or 0x4e/0x4f). That would be a simple driver requesting the ports in question and exporting an API for other drivers to access them in a safe way. The second approach is to make it a whole subsystem, as David is suggesting. The Super-I/O driver would then not only request the I/O ports, it would also identify which Super-I/O is there, and it would create devices (in the Linux device driver model sense of the term) for every logical device we are interested in (amongst which the hwmon ones.) The hwmon drivers would have to be converted from platform drivers to superio drivers. Each approach has its advantages. The first one is rather simple and also very generic in nature. It could be reused for other purposes. The second one offers automatic loading of hwmon drivers, which would be nice to have. There's probably a middle way which would keep the simplicity of the first approach while still allowing for driver auto-loading, without changing the bus type of all drivers. It would probably take some research though. I haven't done the research, but it might be keep superio as a platform driver, and keep the clients as platform drivers. Only have the superio driver probe and discover the subcomponent addresses and then create the platform devices as children instead of having each driver create its own platform device. (This all assumes they are all platform devices in sysfs, I have not looked). This is all because in the platform bus the bus driver does not discover the addresses but relies on drivers or platform setup code. Me, I don't really care which path we choose, given that I am not the one who will take care of it. All I have to say is that this has been discussed several times over the past 2 years and nothing came out of it (as far as the mainline kernel is concerned, at least) so whatever is done now, what really matters is that it makes it into the kernel quickly. We have some drivers missing features because of this (for example real-time reading of VID pin values.) This should also not prevent us from fixing the drivers now so that they temporarily request the Super-I/O ports they are using, as Milton suggested. Not only we don't know when we will have something better to offer, but it might also help us find conflicts between drivers, so that we know which drivers should make use of the future superio driver. This could also reveal conflicts with PNP BIOS reservations, etc. Milton, will you write a patch? Well, that is the second time you asked me, so I guess I should respond. While I it is possible for me to write this patch, my schedule and priority list predict it would not be before the merge window closes. In fact, I'm not sure when it would come out. It might be argued it could go in early -rc, but I would fear somebody's chip will not be detected with the additional check. For example, the port may reserved as mother board resources or something. Also, I have no hardware to test any proposed patch, so it would be compile check only. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 8:16 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote: --- /dev/null +++ b/sound/soc/soc-of.c It's quite inconvenient to spread the firmware-specific bits over the whole kernel source tree. So, can we place this in driver/of/, just as we did for i2c, spi and gpio? This isn't any more specific than say how device drivers are specific for particular devices. This is an ASoC machine driver and should live with all the other ASoC machine drivers. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 11:06:34AM -0600, Grant Likely wrote: I'm okay with that. How about fsl/mpc5200-of-machine.c for now? (only the mpc5200 i2s driver uses it at the moment). It can always be renamed if other folks want to use it for other chips. That seems reasonable so long as you're happy with it, though it does seem to be going to the other extreme in terms of broadness :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 10:53 AM, Mark Brown [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 11:14:41AM -0500, Timur Tabi wrote: Mark Brown wrote: I'm finding it difficult to square these two statements - from an ASoC point of view the main thing this patch is doing is adding a machine driver and that's not something that's going to go away. Jon's concern is that there is no straightforward way to build a kernel with multiple fabric drivers and have the right one chosen via the device tree. This is just a limitation of the device tree model, and no one has come up with a good solution yet. Indeed - I understand what the problem you guys have is, I just want to make sure that there is a reasonable consensus among the PowerPC people that this approach is OK to go in and won't create ructions. The lack of resolution on this issue makes me nervous about any proposed solution where I haven't seen any explicit indication that the community is OK with it. Incidentally, nobody ever really commented on my suggestion to do something DMI-like I'm feeling stupid; what does DMI stand for? - you've already got the board type information present in the device trees (in the model and compatible information in the root nodes), all that's needed is an API to allow matching on it. Yes, we have APIs for matching against device trees. Personally, I'm leaning towards having the powerpc platform code (arch/powerpc/platforms/* stuff; not ASoC platform stuff) register a platform device for the machine driver and let as many machine drivers as needed be written. Hopefully we'll be able to do at least one generic machine driver that will be usable by most PowerPC boards, but I don't think it is a requirement or even realistic to shoehorn all powerpc sound circuits into a single driver. The problem still exists in ASoC V2. However, it's not anything that ASoC itself needs to be concerned with. It's purely a PowerPC problem. Right, I just want to be clear that you guys all understand what this code does and that there won't be too many complaints after the fact. Shouldn't be. I'm certainly not pushing this as the end-all be-all powerpc sound machine driver. ASoC has always called it a machine driver. Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, it should be called a fabric driver because we already have machine drivers. I don't mind - you can call it what you like inside PowerPC-specific code. Oh help! Don't tell us that! Otherwise we'll always be talking across purposes. When ambiguous, let's just be sure to always refer to them as ASoC machine drivers. :-) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 11:16 AM, Mark Brown [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 11:06:34AM -0600, Grant Likely wrote: I'm okay with that. How about fsl/mpc5200-of-machine.c for now? (only the mpc5200 i2s driver uses it at the moment). It can always be renamed if other folks want to use it for other chips. That seems reasonable so long as you're happy with it, though it does seem to be going to the other extreme in terms of broadness :) heh; I don't care. This stuff is all going to be in flux anyway, so change is inevitable whatever is chosen now. :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
Srinivasa D S wrote: +#define task_pt_regs(tsk)(tsk)-thread.regs Shouldn't this be: #define task_pt_regs(tsk) ((tsk)-thread.regs) just to be safe? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
Milton Miller wrote: On Jul 14, 2008, at 2:59 AM, Jean Delvare wrote: On Sun, 13 Jul 2008 15:26:56 -0600, David Hubbard wrote: Hi Hans, I propose writing a subsystem driver. (Is that properly called The SuperIO Bus Driver?) If no one thinks it's a really bad idea I will put together some code and submit it for review, and maintain it. Some hwmon chips have odd / unique probe sequences. IMHO this is where the design needs to be inspected. One of those is the w83627ehf, which Jean and Hans are familiar enough with to check my work. Thoughts? I'm afraid that making this a bus will be a bit overkill. Jim's patches are quite simple and seem todo the job. Also keep in mind that most users will be platform devices which just want to use the superio registers to find out the baseaddress of their logical device, a whole bus seems overkill for this, would the hwmon driver then need to be a superio_driver (as well as an platform_driver) or can the bus be queried / used without having to be a bustype-driver? I think that's a valid point. I am willing to keep it small, but I would prefer to follow the pattern set in other subsystems. It may be my lack of experience in designing a subsystem showing here! What are some alternative ways to implement it? In other words, Jim's patches are a good start, but maybe I am misunderstanding them. I see it as the superio-locks module, a driver that other drivers would depend on / auto-load. Is that something other subsystems also do? Well, there are two approaches to the problem. The first approach (which I think Jim took in his patches? I don't really remember) is to simply solve the problem of concurrent I/O access to the Super-I/O configuration ports (typically 0x2e/0x2f or 0x4e/0x4f). That would be a simple driver requesting the ports in question and exporting an API for other drivers to access them in a safe way. The second approach is to make it a whole subsystem, as David is suggesting. The Super-I/O driver would then not only request the I/O ports, it would also identify which Super-I/O is there, and it would create devices (in the Linux device driver model sense of the term) for every logical device we are interested in (amongst which the hwmon ones.) The hwmon drivers would have to be converted from platform drivers to superio drivers. Each approach has its advantages. The first one is rather simple and also very generic in nature. It could be reused for other purposes. The second one offers automatic loading of hwmon drivers, which would be nice to have. There's probably a middle way which would keep the simplicity of the first approach while still allowing for driver auto-loading, without changing the bus type of all drivers. It would probably take some research though. I haven't done the research, but it might be keep superio as a platform driver, and keep the clients as platform drivers. Only have the superio driver probe and discover the subcomponent addresses and then create the platform devices as children instead of having each driver create its own platform device. (This all assumes they are all platform devices in sysfs, I have not looked). This is all because in the platform bus the bus driver does not discover the addresses but relies on drivers or platform setup code. This sounds like a good plan, rather then add a new bus type add a superio platform driver which does superio probing and registering of platform devices for discovered logical devices. This superio platform driver then needs to also export some functions of those few logical devices which need access to the superio registers for more then just finding out their own base address. I guess that it then would be best to load this superio driver by default on most systems. How does this all mix and match with isapnp, it feels to me we're doing somewhat the same as isapnp here. Regards, Hans ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
Timur Tabi [EMAIL PROTECTED] writes: Srinivasa D S wrote: +#define task_pt_regs(tsk) (tsk)-thread.regs Shouldn't this be: #define task_pt_regs(tsk) ((tsk)-thread.regs) just to be safe? Both - and . have already highest precedence as postfix operators. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] of: i2c: improve last resort compatible entry selection
Currently of_i2c will select first compatible property as a last resort
option. This isn't best choice though, because generic compatible entries
are listed last, not first. For example, two compatible entries given for
the MCU node:
fsl,mc9s08qg8-mpc837xrdb, fsl,mcu-mpc8349emitx;
Since no sane driver will ever match specific devices, what we want is
to select most generic option (last). Then driver may call
of_device_is_compatible() if it is really interested in details.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Other options are: start filling the exceptions list, or add linux,...
compatible entry to the device tree.
drivers/of/of_i2c.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..0d35a0a 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -29,6 +29,7 @@ static int of_find_i2c_driver(struct device_node *node,
int i, cplen;
const char *compatible;
const char *p;
+ const char *last_wcomma = NULL;
/* 1. search for exception list entry */
for (i = 0; i ARRAY_SIZE(i2c_devices); i++) {
@@ -45,7 +46,7 @@ static int of_find_i2c_driver(struct device_node *node,
if (!compatible)
return -ENODEV;
- /* 2. search for linux,i2c-type entry */
+ /* 2. search for linux,i2c-type entry, or remember last w/ comma */
p = compatible;
while (cplen 0) {
if (!strncmp(p, linux,, 6)) {
@@ -54,6 +55,12 @@ static int of_find_i2c_driver(struct device_node *node,
I2C_NAME_SIZE) = I2C_NAME_SIZE)
return -ENOMEM;
return 0;
+ } else {
+ const char *comma;
+
+ comma = strchr(p, ',');
+ if (comma)
+ last_wcomma = comma + 1;
}
i = strlen(p) + 1;
@@ -61,12 +68,10 @@ static int of_find_i2c_driver(struct device_node *node,
cplen -= i;
}
- /* 3. take fist compatible entry and strip manufacturer */
- p = strchr(compatible, ',');
- if (!p)
+ /* 3. take last compatible entry w/ comma, manufacturer stripped */
+ if (!last_wcomma)
return -ENODEV;
- p++;
- if (strlcpy(info-type, p, I2C_NAME_SIZE) = I2C_NAME_SIZE)
+ if (strlcpy(info-type, last_wcomma, I2C_NAME_SIZE) = I2C_NAME_SIZE)
return -ENOMEM;
return 0;
}
--
1.5.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
Hi Hans, On Mon, Jul 14, 2008 at 11:30 AM, Hans de Goede [EMAIL PROTECTED] wrote: Milton Miller wrote: I haven't done the research, but it might be keep superio as a platform driver, and keep the clients as platform drivers. Only have the superio driver probe and discover the subcomponent addresses and then create the platform devices as children instead of having each driver create its own platform device. (This all assumes they are all platform devices in sysfs, I have not looked). This is all because in the platform bus the bus driver does not discover the addresses but relies on drivers or platform setup code. This sounds like a good plan, rather then add a new bus type add a superio platform driver which does superio probing and registering of platform devices for discovered logical devices. This superio platform driver then needs to also export some functions of those few logical devices which need access to the superio registers for more then just finding out their own base address. I guess that it then would be best to load this superio driver by default on most systems. How does this all mix and match with isapnp, it feels to me we're doing somewhat the same as isapnp here. Is there any way to use lspci and start at the LPC bridge, then find the SuperIO chip's IO address? What about ACPI tables? Perhaps probing logic could look for an LPC bridge before probing certain IO addresses even if the addresses are not in the LPC bridge config. A superio platform driver is a good way to go -- it fits with the way the platform bus does things. Also, Jim's patches are almost there already. Thanks, David ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 11:21:12AM -0600, Grant Likely wrote: On Mon, Jul 14, 2008 at 10:53 AM, Mark Brown Incidentally, nobody ever really commented on my suggestion to do something DMI-like I'm feeling stupid; what does DMI stand for? Desktop Management Interface, a standard BIOS interface for getting system data on x86 class hardware. Of particular interest here is the fact that it contains various ID strings for things like motherboard and chassis - on Linux drivers can be automatically loaded based on these strings. See drivers/misc/thinkpad_acpi.c for an example of a driver that does this. Note that it's *not* binding a driver, it just provides the hooks to enable the modules to be automatically loaded and to let drivers query information in DMI. Yes, we have APIs for matching against device trees. Personally, I'm leaning towards having the powerpc platform code (arch/powerpc/platforms/* stuff; not ASoC platform stuff) register a platform device for the machine driver and let as many machine drivers as needed be written. Hopefully we'll be able to do at least one That would be what I'd expected initially - it is, after all, what other platforms are doing here. generic machine driver that will be usable by most PowerPC boards, but I don't think it is a requirement or even realistic to shoehorn all powerpc sound circuits into a single driver. Yes, that'd be completely unrealistic. I don't mind - you can call it what you like inside PowerPC-specific code. Oh help! Don't tell us that! Otherwise we'll always be talking across purposes. When ambiguous, let's just be sure to always refer to them as ASoC machine drivers. :-) Feh, from now on I shall me naming all new concepts with pwgen :) . ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Mark Brown wrote: Desktop Management Interface, a standard BIOS interface for getting system data on x86 class hardware. Of particular interest here is the fact that it contains various ID strings for things like motherboard and chassis - on Linux drivers can be automatically loaded based on these strings. See drivers/misc/thinkpad_acpi.c for an example of a driver that does this. The only problem with this is that the OF probing code in the kernel binds drivers to device tree nodes. So when a driver claims a node, no other driver will be probed with it. So we can't have generic nodes that classify the motherboard and just let everyone get probed on it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Testcase for /include/ directive
This patch adds a testcase for the /include/ directive. It assembles a sample dts file with many /include/ directives at a variety of different lexical / grammatical contexts. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 01:40:24PM -0500, Timur Tabi wrote: Mark Brown wrote: Desktop Management Interface, a standard BIOS interface for getting system data on x86 class hardware. Of particular interest here is the fact that it contains various ID strings for things like motherboard and chassis - on Linux drivers can be automatically loaded based on these strings. See drivers/misc/thinkpad_acpi.c for an example of a driver that does this. The only problem with this is that the OF probing code in the kernel binds drivers to device tree nodes. So when a driver claims a node, no other driver will be probed with it. So we can't have generic nodes that classify the motherboard and just let everyone get probed on it. My suggestion is that you change this for the root node. It's already got the information required in there, it's just there's no way to use it to load modules at the minute. You could presumably read the information out of the device tree using existing APIs to check you're running on the right board once code is loaded? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Mark Brown wrote: The only problem with this is that the OF probing code in the kernel binds drivers to device tree nodes. So when a driver claims a node, no other driver will be probed with it. So we can't have generic nodes that classify the motherboard and just let everyone get probed on it. My suggestion is that you change this for the root node. That's an interesting idea. It's already got the information required in there, it's just there's no way to use it to load modules at the minute. Correct. You could presumably read the information out of the device tree using existing APIs to check you're running on the right board once code is loaded? Yes. The driver - node binding is only for probing. Any driver can scan the entire tree at any time. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Address an assortment of portability problems
I've recently worked with a FreeBSD developer, getting dtc and libfdt
working on FreeBSD. This showed up a number of portability problems
in the dtc package which this patch addresses. Changes are as
follows:
- the parent_offset and supernode_atdepth_offset testcases
used the glibc extension functions strchrnul() and strndupa(). Those
are removed, using slightly longer coding with standard C functions
instead.
- some other testcases had a #define _GNU_SOURCE for no
particular reason. This is removed.
- run_tests.sh has bash specific constructs removed, and the
interpreter changed to /bin/sh. This apparently now runs fine on
FreeBSD's /bin/sh, and I've also tested it with both ash and dash.
- convert-dtsv0-lexer.l has some extra #includes added. These
must have been included indirectly with Linux and glibc, but aren't on
FreeBSD.
- the endian handling functions in libfdt_env.h, based on
endian.h and byteswap.h are replaced with some portable open-coded
versions. Unfortunately, these result in fairly crappy code when
compiled, but as far as I can determine there doesn't seem to be any
POSIX, SUS or de facto standard way of determining endianness at
compile time, nor standard names for byteswapping functions.
- some more endian handling, from testdata.h using the
problematic endian.h is simply removed, since it wasn't actually being
used anyway.
Signed-off-by: David Gibson [EMAIL PROTECTED]
This patch didn't apply directly.
The problem appeared to be the mysterious and suspect exit 99
in the middle of the following context. I whacked on the patch
directly by-hand, and managed to get it to apply.
Obligatory Not using git grumble.
Applied after all.
jdl
Index: dtc/tests/run_tests.sh
===
--- dtc.orig/tests/run_tests.sh 2008-06-26 10:40:59.0 +1000
+++ dtc/tests/run_tests.sh2008-06-26 10:43:21.0 +1000
@@ -15,19 +15,19 @@
tot_strange=0
base_run_test() {
-tot_tests=$[tot_tests + 1]
+tot_tests=$((tot_tests + 1))
if VALGRIND=$VALGRIND $@; then
- tot_pass=$[tot_pass + 1]
+ tot_pass=$((tot_pass + 1))
else
ret=$?
if [ $ret == 1 ]; then
- tot_config=$[tot_config + 1]
+ tot_config=$((tot_config + 1))
elif [ $ret == 2 ]; then
- tot_fail=$[tot_fail + 1]
+ tot_fail=$((tot_fail + 1))
elif [ $ret == $VGCODE ]; then
- tot_vg=$[tot_vg + 1]
+ tot_vg=$((tot_vg + 1))
else
- tot_strange=$[tot_strange + 1]
+ tot_strange=$((tot_strange + 1))
fi
exit 99
fi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Clean up lexing of include files
Currently we scan the /include/ directive as two tokens, the
/include/ keyword itself, then the string giving the file name to
include. We use a special scanner state to keep the two linked
together, and use the scanner state stack to keep track of the
original state while we're parsing the two /include/ tokens.
This does mean that we need to enable the 'stack' option in flex,
which results in a not-easily-suppressed warning from the flex
boilerplate code. This is mildly irritating.
However, this two-token scanning of the /include/ directive also has
some extremely strange edge cases, because there are a variety of
tokens recognized in all scanner states, including INCLUDE. For
example the following strange dts file:
/include/ /dts-v1/;
/ {
/* ... */
};
Will be processed successfully with the /include/ being effectively
ignored: the '/dts-v1/' and ';' are recognized even in INCLUDE state,
then the ';' transitions us to PROPNODENAME state, throwing away
INCLUDE, and the previous state is never popped off the stack. Or
for another example this construct:
foo /include/ = somefile.dts
will be parsed as though it were:
foo = /include/ somefile.dts
Again, the '=' is scanned without leaving INCLUDE state, then the next
string triggers the include logic.
And finally, we use a different regexp for the string with the
included filename than the normal string regexpt, which is also
potentially weird.
This patch, therefore, cleans up the lexical handling of the /include/
directive. Instead of the INCLUDE state, we instead scan the whole
include directive, both keyword and filename as a single token. This
does mean a bit more complexity in extracting the filename out of
yytext, but I think it's worth it to avoid the strageness described
above. It also means it's no longer possible to put a comment between
the /include/ and the filename, but I'm really not very worried about
breaking files using such a strange construct.
Applied.
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] libfdt: Improve documentation in libfdt.h
Fix a few typos and mistakes. Signed-off-by: Wolfram Sang [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Increase namespace-pollution paranoia
My (DTC) plan is to apply the single patch with some include file fixes, and release that. I'll line the slew of patches up for the following release. jdl And that's not at all what happened. One of David's patches (BSD portability) was a superset of the include-file fixes supplied as a point-solution in a different patch. So I applied David's more-general patch. In fact, I applied all of David's outstanding patches and have tagged it v1.2.0-rc2 and pushed it out now. Please let me know if you have other fixes before I make and release a non -rc version. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 82xx performance
On Monday 14 July 2008, Rune Torgersen wrote: Context switching - times in microseconds - smaller is better Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw - - -- -- -- -- -- --- --- 9919_unit Linux 2.6.25 20.6 86.2 28.5 103.8 38.7 111.8 57.4 9919_unit Linux 2.6.18 5.3300 63.2 17.9 73.4 23.174.9 26.2 This is certainly significant, but a lot has happened between the two versions. I few ideas: * compare some of the key configuration options: # CONFIG_DEBUG_* # CONFIG_PREEMPT* # CONFIG_NO_HZ # CONFIG_HZ * Try looking at where the time is spent, using oprofile or readprofile * Try setting /proc/sys/kernel/compat/sched_yield to 1, to get the legacy behaviour of the scheduler. * Maybe there is a kernel version that supports your hardware in both arch/ppc/ and arch/powerpc. In that case, you could see if the platform change had an impact. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/16 v3] powerpc: Do not probe PCI buses or eBus devices if CMO is enabled
Ben,
Please drop this patch from the series. After further discussion, this patch
is not required and has actually been causing problems.
Thanks,
Brian
Robert Jennings wrote:
From: Brian King [EMAIL PROTECTED]
The Cooperative Memory Overcommit (CMO) on System p does not currently
support native PCI devices or eBus devices when enabled. Prevent
PCI bus probe and eBus device probe if the feature is enabled.
Signed-off-by: Brian King [EMAIL PROTECTED]
Signed-off-by: Robert Jennings [EMAIL PROTECTED]
---
arch/powerpc/kernel/ibmebus.c |6 ++
arch/powerpc/platforms/pseries/setup.c |4
2 files changed, 10 insertions(+)
Index: b/arch/powerpc/kernel/ibmebus.c
===
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -45,6 +45,7 @@
#include linux/of_platform.h
#include asm/ibmebus.h
#include asm/abs_addr.h
+#include asm/firmware.h
static struct device ibmebus_bus_device = { /* fake parent device */
.bus_id = ibmebus,
@@ -332,6 +333,11 @@ static int __init ibmebus_bus_init(void)
{
int err;
+ if (firmware_has_feature(FW_FEATURE_CMO)) {
+ printk(KERN_WARNING Not probing eBus since CMO is enabled\n);
+ return 0;
+ }
+
printk(KERN_INFO IBM eBus Device Driver\n);
err = of_bus_type_init(ibmebus_bus_type, ibmebus);
Index: b/arch/powerpc/platforms/pseries/setup.c
===
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -539,6 +539,10 @@ static void pseries_shared_idle_sleep(vo
static int pSeries_pci_probe_mode(struct pci_bus *bus)
{
+ if (firmware_has_feature(FW_FEATURE_CMO)) {
+ dev_warn(bus-dev, Not probing PCI bus since CMO is
enabled\n);
+ return PCI_PROBE_NONE;
+ }
if (firmware_has_feature(FW_FEATURE_LPAR))
return PCI_PROBE_DEVTREE;
return PCI_PROBE_NORMAL;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Mikrotik RouterBoard 333
Its firmware apparently provides a flattened device tree to the OS. And while this step towards world domination is flattering, it's an example of what I feared when people first got enthusiastic about the idea of including flattened device trees in firmwares. The tree has not, AFAIK, been past this list, and has apparently not been reviewed by someone knowledgeable about device trees. In short, it's crap, and now that it's embedded in the firware we can't really fix it. Can't you build a kernel with a blob that overrides the firmware-provided blob? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Address an assortment of portability problems
On Mon, Jul 14, 2008 at 01:54:41PM -0500, Jon Loeliger wrote: I've recently worked with a FreeBSD developer, getting dtc and libfdt working on FreeBSD. This showed up a number of portability problems in the dtc package which this patch addresses. Changes are as follows: - the parent_offset and supernode_atdepth_offset testcases used the glibc extension functions strchrnul() and strndupa(). Those are removed, using slightly longer coding with standard C functions instead. - some other testcases had a #define _GNU_SOURCE for no particular reason. This is removed. - run_tests.sh has bash specific constructs removed, and the interpreter changed to /bin/sh. This apparently now runs fine on FreeBSD's /bin/sh, and I've also tested it with both ash and dash. - convert-dtsv0-lexer.l has some extra #includes added. These must have been included indirectly with Linux and glibc, but aren't on FreeBSD. - the endian handling functions in libfdt_env.h, based on endian.h and byteswap.h are replaced with some portable open-coded versions. Unfortunately, these result in fairly crappy code when compiled, but as far as I can determine there doesn't seem to be any POSIX, SUS or de facto standard way of determining endianness at compile time, nor standard names for byteswapping functions. - some more endian handling, from testdata.h using the problematic endian.h is simply removed, since it wasn't actually being used anyway. Signed-off-by: David Gibson [EMAIL PROTECTED] This patch didn't apply directly. The problem appeared to be the mysterious and suspect exit 99 in the middle of the following context. I whacked on the patch directly by-hand, and managed to get it to apply. Sod. When working I usually have an extra patch in my stack that adds that exit 99 - it's easier to find and fix testsuite failures when it bombs out after the first one. Obviously, I forgot to double check that it didn't leak into the context :(. Sorry. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
On Wed, 2008-07-09 at 21:35 +0530, Chirag Jog wrote:
Hi,
This patch fixes various paths in the -rt kernel on powerpc64 where per_cpu
variables are accessed in a preempt unsafe way.
When a power box with -rt kernel is booted, multiple BUG messages are
generated BUG: init:1 task might have lost a preemption check!.
After booting a kernel with these patches applied, these messages
don't appear.
Also I ran the realtime tests from ltp to ensure the stability.
That sounds bad tho...
IE. You are changing the code to lock/unlock on all those TLB batching
operations, but seem to miss the core reason why it was done that way:
ie, the code assumes that it will not change CPU -between- those calls,
since the whole stuff should be already have been within a per-cpu
locked section at the caller level.
As for the TCE code, well, it lived on the assumption that the upper
level spinlock did the job of preventing preempt, I suppose that's not
the case anymore. So that part of the patch sounds ok.
Ben.
Signed-Off-By: Chirag [EMAIL PROTECTED]
arch/powerpc/mm/tlb_64.c | 31 ---
arch/powerpc/platforms/pseries/iommu.c | 14 ++
include/asm-powerpc/tlb.h |5 ++---
3 files changed, 28 insertions(+), 22 deletions(-)
Index: linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c
===
--- linux-2.6.25.8-rt7.orig/arch/powerpc/mm/tlb_64.c 2008-07-09
21:29:21.0 +0530
+++ linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c 2008-07-09
21:30:37.0 +0530
@@ -38,7 +38,6 @@
* include/asm-powerpc/tlb.h file -- tgall
*/
DEFINE_PER_CPU_LOCKED(struct mmu_gather, mmu_gathers);
-DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
unsigned long pte_freelist_forced_free;
struct pte_freelist_batch
@@ -48,7 +47,7 @@
pgtable_free_t tables[0];
};
-DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
+DEFINE_PER_CPU_LOCKED(struct pte_freelist_batch *, pte_freelist_cur);
unsigned long pte_freelist_forced_free;
#define PTE_FREELIST_SIZE \
@@ -92,24 +91,21 @@
void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf)
{
- /*
- * This is safe since tlb_gather_mmu has disabled preemption.
- * tlb-cpu is set by tlb_gather_mmu as well.
- */
+ int cpu;
cpumask_t local_cpumask = cpumask_of_cpu(tlb-cpu);
- struct pte_freelist_batch **batchp = __get_cpu_var(pte_freelist_cur);
+ struct pte_freelist_batch **batchp =
get_cpu_var_locked(pte_freelist_cur, cpu);
if (atomic_read(tlb-mm-mm_users) 2 ||
cpus_equal(tlb-mm-cpu_vm_mask, local_cpumask)) {
pgtable_free(pgf);
- return;
+ goto cleanup;
}
if (*batchp == NULL) {
*batchp = (struct pte_freelist_batch
*)__get_free_page(GFP_ATOMIC);
if (*batchp == NULL) {
pgtable_free_now(pgf);
- return;
+ goto cleanup;
}
(*batchp)-index = 0;
}
@@ -118,6 +114,9 @@
pte_free_submit(*batchp);
*batchp = NULL;
}
+
+ cleanup:
+ put_cpu_var_locked(pte_freelist_cur, cpu);
}
/*
@@ -253,13 +252,15 @@
void pte_free_finish(void)
{
- /* This is safe since tlb_gather_mmu has disabled preemption */
- struct pte_freelist_batch **batchp = __get_cpu_var(pte_freelist_cur);
+ int cpu;
+ struct pte_freelist_batch **batchp =
get_cpu_var_locked(pte_freelist_cur, cpu);
- if (*batchp == NULL)
- return;
- pte_free_submit(*batchp);
- *batchp = NULL;
+ if (*batchp) {
+ pte_free_submit(*batchp);
+ *batchp = NULL;
+ }
+
+ put_cpu_var_locked(pte_freelist_cur, cpu);
}
/**
Index: linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h
===
--- linux-2.6.25.8-rt7.orig/include/asm-powerpc/tlb.h 2008-07-09
21:29:21.0 +0530
+++ linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h 2008-07-09
21:29:41.0 +0530
@@ -40,18 +40,17 @@
static inline void tlb_flush(struct mmu_gather *tlb)
{
- struct ppc64_tlb_batch *tlbbatch = __get_cpu_var(ppc64_tlb_batch);
+ struct ppc64_tlb_batch *tlbbatch = get_cpu_var(ppc64_tlb_batch);
/* If there's a TLB batch pending, then we must flush it because the
* pages are going to be freed and we really don't want to have a CPU
* access a freed page because it has a stale TLB
*/
if (tlbbatch-index) {
- preempt_disable();
__flush_tlb_pending(tlbbatch);
- preempt_enable();
}
+ put_cpu_var(ppc64_tlb_batch);
pte_free_finish();
}
Index: linux-2.6.25.8-rt7/arch/powerpc/platforms/pseries/iommu.c
Re: linux-next: manual merge of the powerpc tree
On Mon, 14 Jul 2008, Stephen Rothwell wrote: Hi Paul, Ben, Today's linux-next merge of the powerpc tree got a conflict in arch/powerpc/Kconfig between commit 4e491d14f2506b218d678935c25a7027b79178b1 (ftrace: support for PowerPC) from the ftrace tree and commit 3affedc4e1ce837033b6c5e9289d2ce2f5a62d31 (powerpc/dma: implement new dma_*map*_attrs() interfaces) from the powerpc tree. The former commit moved the select HAVE_OPROFILE to the bottom of the config PPC list (for no reason that I can fathom) while the latter added another select. Simple fixup. I can carry it. I heard someone mention that they try to keep the configs in alphabetical order. I did the move of OPROFILE for just that reason. I should have said so in the change log. Oh well. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Mikrotik RouterBoard 333
On Tue, Jul 15, 2008 at 02:17:36AM +0200, Segher Boessenkool wrote: Its firmware apparently provides a flattened device tree to the OS. And while this step towards world domination is flattering, it's an example of what I feared when people first got enthusiastic about the idea of including flattened device trees in firmwares. The tree has not, AFAIK, been past this list, and has apparently not been reviewed by someone knowledgeable about device trees. In short, it's crap, and now that it's embedded in the firware we can't really fix it. Can't you build a kernel with a blob that overrides the firmware-provided blob? Sorry, my phrasing was slightly unclear. Certainly we can work around a firmware with a crap device tree by replacing it, if necessary. Basically that's just treating the firmware as though it's one of these old-style jobs which provides its tiny handful of necessary bits of information (memory size, maybe a few others) in a format that happens to resemble a device tree. But it seems kind of silly for firmware to go to the trouble of providing a device tree just for us to ignore it and substitute our own. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] kill useless SMT code in prom_hold_cpus
On Tue, 2008-07-08 at 17:36 -0500, Nathan Lynch wrote:
I think this code that counts SMT threads and compares against NR_CPUS
is an artifact of pre-powerpc-merge ppc64. We care about starting
only primary threads in the OF client code.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
That looks good. I'm not merging it right now because I want to dbl
check that it's allright on all SMT machines. IE. We compare reg[0]
against _prom-cpu now instead of interrupt_server[0] and I thus
want to ensure it's the same everywhere.
Cheers,
Ben.
arch/powerpc/kernel/prom_init.c | 39
+++
1 files changed, 3 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1ea8c8d..b1dd86c 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -205,8 +205,6 @@ static int __initdata mem_reserve_cnt;
static cell_t __initdata regbuf[1024];
-#define MAX_CPU_THREADS 2
-
/*
* Error results ... some OF calls will return -1 on error, some
* will return 0, some will return either. To simplify, here are
@@ -1332,10 +1330,6 @@ static void __init prom_hold_cpus(void)
unsigned int reg;
phandle node;
char type[64];
- int cpuid = 0;
- unsigned int interrupt_server[MAX_CPU_THREADS];
- unsigned int cpu_threads, hw_cpu_num;
- int propsize;
struct prom_t *_prom = RELOC(prom);
unsigned long *spinloop
= (void *) LOW_ADDR(__secondary_hold_spinloop);
@@ -1379,7 +1373,6 @@ static void __init prom_hold_cpus(void)
reg = -1;
prom_getprop(node, reg, reg, sizeof(reg));
- prom_debug(\ncpuid= 0x%x\n, cpuid);
prom_debug(cpu hw idx = 0x%x\n, reg);
/* Init the acknowledge var which will be reset by
@@ -1388,28 +1381,9 @@ static void __init prom_hold_cpus(void)
*/
*acknowledge = (unsigned long)-1;
- propsize = prom_getprop(node, ibm,ppc-interrupt-server#s,
- interrupt_server,
- sizeof(interrupt_server));
- if (propsize 0) {
- /* no property. old hardware has no SMT */
- cpu_threads = 1;
- interrupt_server[0] = reg; /* fake it with phys id */
- } else {
- /* We have a threaded processor */
- cpu_threads = propsize / sizeof(u32);
- if (cpu_threads MAX_CPU_THREADS) {
- prom_printf(SMT: too many threads!\n
- SMT: found %x, max is %x\n,
- cpu_threads, MAX_CPU_THREADS);
- cpu_threads = 1; /* ToDo: panic? */
- }
- }
-
- hw_cpu_num = interrupt_server[0];
- if (hw_cpu_num != _prom-cpu) {
+ if (reg != _prom-cpu) {
/* Primary Thread of non-boot cpu */
- prom_printf(%x : starting cpu hw idx %x... , cpuid,
reg);
+ prom_printf(starting cpu hw idx %x... , reg);
call_prom(start-cpu, 3, 0, node,
secondary_hold, reg);
@@ -1424,17 +1398,10 @@ static void __init prom_hold_cpus(void)
}
#ifdef CONFIG_SMP
else
- prom_printf(%x : boot cpu %x\n, cpuid, reg);
+ prom_printf(boot cpu hw idx %x\n, reg);
#endif /* CONFIG_SMP */
-
- /* Reserve cpu #s for secondary threads. They start later. */
- cpuid += cpu_threads;
}
- if (cpuid NR_CPUS)
- prom_printf(WARNING: maximum CPUs ( __stringify(NR_CPUS)
- ) exceeded: ignoring extras\n);
-
prom_debug(prom_hold_cpus: end...\n);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] kill useless SMT code in prom_hold_cpus
On Tue, Jul 08, 2008 at 05:36:31PM -0500, Nathan Lynch wrote: I think this code that counts SMT threads and compares against NR_CPUS is an artifact of pre-powerpc-merge ppc64. We care about starting only primary threads in the OF client code. snip - prom_printf(%x : starting cpu hw idx %x... , cpuid, reg); + prom_printf(starting cpu hw idx %x... , reg); If we remove this, where else can we see the mapping of hardware IDs to logical cpu IDs? This is useful on POWER4 (at least where they can be different). snip - if (cpuid NR_CPUS) - prom_printf(WARNING: maximum CPUs ( __stringify(NR_CPUS) - ) exceeded: ignoring extras\n); - I think this printf() is valuable, if your boot a 128 thread machine on a kernel with NR_CPUS=64, this is the only messaage you get to indicate that you're wasting 64 threads, and how to resolve it. Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] kill useless SMT code in prom_hold_cpus
On Mon, 2008-07-14 at 21:24 -0500, Nathan Lynch wrote: Benjamin Herrenschmidt wrote: On Tue, 2008-07-08 at 17:36 -0500, Nathan Lynch wrote: I think this code that counts SMT threads and compares against NR_CPUS is an artifact of pre-powerpc-merge ppc64. We care about starting only primary threads in the OF client code. Signed-off-by: Nathan Lynch [EMAIL PROTECTED] That looks good. I'm not merging it right now because I want to dbl check that it's allright on all SMT machines. IE. We compare reg[0] against _prom-cpu now instead of interrupt_server[0] and I thus want to ensure it's the same everywhere. Thanks. Looks like prom_find_boot_cpu is setting _prom-cpu to reg (or 0), so I think it should be fine... a system where reg differed from interrupt_server[0] would have been broken before this patch anyway, I think? I tend to agree, just didn't have time to look closely / test before I get to prepare my batch of patches for Linus, I'll stick it in the next one. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: Fix pte_update for CONFIG_PTE_64BIT and !PTE_ATOMIC_UPDATES
On Mon, 2008-07-14 at 08:08 -0500, Kumar Gala wrote: Because the pte is now 64-bits the compiler was optimizing the update to always clear the upper 32-bits of the pte. We need to ensure the clr mask is treated as an unsigned long long to get the proper behavior. Signed-off-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Josh Boyer [EMAIL PROTECTED] Putting that one into my tree. I'll let you put the 2 others in yours. Cheers, Ben. --- include/asm-powerpc/pgtable-ppc32.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-powerpc/pgtable-ppc32.h b/include/asm-powerpc/pgtable-ppc32.h index 11eede4..73015f0 100644 --- a/include/asm-powerpc/pgtable-ppc32.h +++ b/include/asm-powerpc/pgtable-ppc32.h @@ -624,7 +624,7 @@ static inline unsigned long long pte_update(pte_t *p, : cc ); #else /* PTE_ATOMIC_UPDATES */ unsigned long long old = pte_val(*p); - *p = __pte((old ~clr) | set); + *p = __pte((old ~(unsigned long long)clr) | set); #endif /* !PTE_ATOMIC_UPDATES */ #ifdef CONFIG_44x ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
