On Tue, Jul 15, 2008 at 12:02 AM, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> If you believe I've missed something, now is time to be vocal about
> it :-)
I've also got some SPI stuff, but it depends on a commit in another
tree so I'll wait until it's in Linus' tree before I ask you to pul
I've pulled from Kumar, Josh and Grant, along with applying some
patches hand picked from patchworks and build fixes. I've merged in
Linus as of today (minus David Woodhouse firmware patches that have a
build breakage) in order to fix a (fairly trivial) merge conflict.
I've now pushed that to my p
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 Ga
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
> >
On Mon, Jul 14, 2008 at 11:55:51PM -0500, Nathan Lynch wrote:
> sysfs. (e.g. /sys/devices/system/cpu/cpu0/physical_id)
Hmm okay, sysfs is fine if you're gettign all the way up. I guess if we
have problems in that are we can readd the printf().
> The proper place for such a message is in the k
Tony Breeds wrote:
> On Tue, Jul 08, 2008 at 05:36:31PM -0500, Nathan Lynch wrote:
>
> > - 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 ma
Hi Anton,
On Mon, 14 Jul 2008 20:41:14 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> +static int __devinit of_gpio_leds_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + int ret;
> + struct of_gpio_led *led;
> + str
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-of
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.
> - prom_printf("%x : star
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]>
Th
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 inclu
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 3affedc4e1ce837033b6c
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
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:
> >
> >
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 t
From: Grant Likely <[EMAIL PROTECTED]>
Add documentation about how to describe SPI busses in the device tree.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Very nice! I wish all bindings were like this (namely, not overly
terse).
Acked-by: Segher Boessenkool <[EMAIL PROTECTED]>
Segher
On 7/14/08, Timur Tabi <[EMAIL PROTECTED]> 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
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 motherbo
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
> sup
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 ct
>
> 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 suppli
> 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
> libfdt is supposed to easy to embed in projects all and sundry.
> Often, it won't be practical to separate the embedded libfdt's
> namespace from that of the surrounding project. Which means there can
> be namespace conflicts between even libfdt's internal/static functions
> and functions or mac
> Enabling -Wcast-qual warnings in dtc shows up a number of places where
> we are incorrectly discarding a const qualification. There are also
> some places where we are intentionally discarding the 'const', and we
> need an ugly cast through uintptr_t to suppress the warning. However,
> most of
> This patch adjusts the testsuite to run most of the tests for the tree
> checking code on input in dtb form as well as dts form. Some checks
> which only make sense for dts input (like reference handling) are
> excluded, as are those which currently take dtb input because they
> rely on things w
> This patch turns on the -Wpointer-arith option in the dtc Makefile,
> and fixes the resulting warnings due to using (void *) in pointer
> arithmetic. While convenient, pointer arithmetic on void * is not
> portable, so it's better that we avoid it, particularly in libfdt.
>
> Signed-off-by: Dav
> 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 parsin
> 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
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
>> everyo
> Following on from the last patch, which made dtc use the same endian
> conversion functions as libfdt, this patch makes ftdump use these
> functions as well. This brings us down to a single set of endian
> handling functions in all of dtc and libfdt, so just one place to fix
> things.
>
> Signe
> Currently both libfdt and dtc define a set of endian conversion macros
> for accessing the device tree blob which is always big-endian. libfdt
> uses names like cpu_to_fdt32() and dtc uses names like cpu_to_be32 (as
> the Linux kernel). This patch switches dtc over to using the libfdt
> macros
> Currently, dtc defines Linux-like names for various fixed-size integer
> types. There's no good reason to do this; even Linux itself doesn't
> use these names for externally visible things any more. This patch
> replaces these with the C99 standardized type names from stdint.h.
>
> Signed-off-
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 motherboar
> 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
___
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 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 BIO
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 subcomp
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 sa
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.
Andrea
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 co
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
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
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
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'r
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 p
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 r
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 reg
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'
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 wi
Hi
We are looking into switching kernels from 2.6.18 (ppc) to 2.6.25
(powerpc).
I have been trying to run some benchmarks to see how the new kernel
compares to the old one.
So far it is performing worse.
One test I ran was just compiling a 2.6.18 kernel on the system.
The .25 performed 5 to 7 %
Despite leds-gpio and leds-of-gpio similar names and purposes, there
is not much code can be shared between the two drivers (both are mostly
driver bindings anyway).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Kumar, since the dts bindings are split now, please don't bother with
all-in
On Mon, 2008-07-14 at 19:25 +1000, Stephen Rothwell wrote:
> 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
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
>> po
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
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
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 devel
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 framewor
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
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 += sem
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 instant
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/ph
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 diffe
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 (phandl
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/ar
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 wr
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]>
On Sat, Jul 12, 2008 at 02:39:34AM -0600, Grant Likely wrote:
> This is an I2S bus driver for the MPC5200 PSC device. It is probably
> will not be merged as-is because it uses v1 of the ASoC API, but I want
> to get it out there for comments.
Looks basically good. A few things below, plus you p
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 nitpic
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)
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/sta
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
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 requir
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
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 alr
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"
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.
> >>
> >>
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 head
77 matches
Mail list logo
