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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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]
---
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
--
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
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
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
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
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
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 :
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
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
56 matches
Mail list logo
