This patch moves the dtc code for checking the device tree its
processing into a new checks.c. The tree accessor functions from
livetree.c which the checks use are exported and added to dtc.h.
Another small step towards a flexible checking architecture.
Signed-off-by: David Gibson <[EMAIL PROTEC
On Wed, 2007-10-31 at 13:45 -0600, Chris Friesen wrote:
> Hi all,
>
> We've got some kernel code that monitors which pages have been dirtied
> by an application.
>
> The pages are locked in memory, and the system has no swap. Initially
> we mark the pages clean using ptep_clear_flush_dirty(),
> -Original Message-
> From: Anton Vorontsov [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 01, 2007 5:59 AM
> To: Li Yang-r58472
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] ucc_geth: add support for netpoll
>
> On Mon, Oct 29, 2007
On Wed, 31 Oct 2007 14:55:03 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-10-31 at 14:11 -0800, Badari Pulavarty wrote:
> >
> > Well, We don't need arch-specific remove_memory() for ia64 and ppc64.
> > x86_64, I don't know. We will know, only when some one does the
> > verification
Currently all the read/write functions in libfdt require that the
given tree be v17, and further, that the tree has the memory
reservation block, structure block and strings block stored in that
physical order.
This patch eases these constraints, by making fdt_open_int() reorder
the blocks, and/or
On Thu, Nov 01, 2007 at 01:55:30AM -0500, Kumar Gala wrote:
>
> On Oct 30, 2007, at 6:40 PM, David Gibson wrote:
>
> > On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote:
> >> Jon Loeliger wrote:
> >>> So, like, the other day Kumar Gala mumbled:
> Jon,
>
> It seems lik
On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote:
>
> > > I think what we should do is keep device_type, including
> > > permitting new uses of it in a limited way-- only permitting
> > > the use of device_type when there is an official binding
> > > (like in the power.org ePAP
This patch contains the scheduled removal of legacy I2C RTC drivers with
replacement drivers.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Documentation/feature-removal-schedule.txt |7
arch/powerpc/platforms/83xx/mpc832x_mds.c | 24 -
arch/powerpc/platforms/83xx/mpc834x_mds.c |
Make sure that at least cmpxchg64_local is available on all architectures to use
for unsigned long long values.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
CC: linuxppc-dev@ozlabs.org
---
include/asm-powerpc/system.h | 18 --
On Mon, Oct 29, 2007 at 03:17:44PM +0300, Anton Vorontsov wrote:
[...]
> > Oops. The original patch happened to hit the Junk mail box. :(
>
> That one as well? http://lkml.org/lkml/2007/10/11/128
>
> > I think
> > the patch is good to merge after the cosmetic change. I can do it in
> > next pul
On Wed, 2007-10-31 at 14:11 -0800, Badari Pulavarty wrote:
>
> Well, We don't need arch-specific remove_memory() for ia64 and ppc64.
> x86_64, I don't know. We will know, only when some one does the
> verification. I don't need arch_remove_memory() hook also at this
> time.
I wasn't being very cl
Badari Pulavarty wrote:
> On Thu, 2007-11-01 at 01:26 -0500, Kumar Gala wrote:
> > On Oct 31, 2007, at 11:49 AM, Badari Pulavarty wrote:
> >
> > > Supply arch specific remove_memory() for PPC64. There is nothing
> > > ppc specific code here and its exactly same as ia64 version.
> > > For now, lets
On Wed, 2007-10-31 at 13:45 -0700, Dave Hansen wrote:
> On Wed, 2007-10-31 at 08:49 -0800, Badari Pulavarty wrote:
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +int remove_memory(u64 start, u64 size)
> > +{
> > + unsigned long start_pfn, end_pfn;
> > + unsigned long timeout = 120 * HZ;
> > + int r
On Wed, 2007-10-31 at 13:45 -0700, Dave Hansen wrote:
> On Wed, 2007-10-31 at 08:49 -0800, Badari Pulavarty wrote:
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +int remove_memory(u64 start, u64 size)
> > +{
> > + unsigned long start_pfn, end_pfn;
> > + unsigned long timeout = 120 * HZ;
> > + int r
On Wed, 2007-10-31 at 08:49 -0800, Badari Pulavarty wrote:
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int remove_memory(u64 start, u64 size)
> +{
> + unsigned long start_pfn, end_pfn;
> + unsigned long timeout = 120 * HZ;
> + int ret;
> + start_pfn = start >> PAGE_SHIFT;
> + end_pfn =
On Thu, 2007-11-01 at 01:26 -0500, Kumar Gala wrote:
> On Oct 31, 2007, at 11:49 AM, Badari Pulavarty wrote:
>
> > Supply arch specific remove_memory() for PPC64. There is nothing
> > ppc specific code here and its exactly same as ia64 version.
> > For now, lets keep it arch specific - so each arc
Hi all,
We've got some kernel code that monitors which pages have been dirtied
by an application.
The pages are locked in memory, and the system has no swap. Initially
we mark the pages clean using ptep_clear_flush_dirty(), then when
requested by the app we scanning through the pages and che
Michael Ellerman <[EMAIL PROTECTED]> wrote on 30.10.2007 23:50:36:
>
> On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
> >
> > Michael Ellerman <[EMAIL PROTECTED]> wrote on 28.10.2007 23:32:17:
> > Hope I didn't miss anything here...
>
> Perhaps. When we kdump the kernel does not call t
On Oct 30, 2007, at 6:40 PM, David Gibson wrote:
> On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote:
>> Jon Loeliger wrote:
>>> So, like, the other day Kumar Gala mumbled:
Jon,
It seems like have libfdt as a unique git repo that is a
submodule of
the thin
On Oct 30, 2007, at 11:49 PM, David Gibson wrote:
> On Tue, Oct 30, 2007 at 11:37:15PM -0500, Kumar Gala wrote:
>>
>> On Oct 30, 2007, at 10:24 PM, David Gibson wrote:
>>
>>> These two patches are a respin of my previous patch to merge a
>>> copy of
>>> dtc into the kernel tree, so that kernel
On Oct 31, 2007, at 11:49 AM, Badari Pulavarty wrote:
> Supply arch specific remove_memory() for PPC64. There is nothing
> ppc specific code here and its exactly same as ia64 version.
> For now, lets keep it arch specific - so each arch can add
> its own special things if needed.
>
> Signed-off-b
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, October 31, 2007 12:06 PM
> To: Yoder Stuart-B08248
> Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>
> On Wed, Oct 31, 2007 at 08:31:02AM -0
Could you redo the patch with just this bit and send it again?
josh
Ok - this one is based off the Linus tree, and follows your style of one
interrupt per line, with a comment indicating which one it is.
Signed-off-by: Steve Falco
diff --git a/arch/powerpc/boot/dts/walnut.dts b/arch/
[powerpc] update xmon slb code
This adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size, (1T or 256M) and displaying the LLP bits. This supresses the
output for any slb entries that contain only z
On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote:
> This works...but certainly is weaker with respect to
> standardization. My previous argument had the assumption
> that something like "mac-address" in a network node was
> _required_, and thus needed a class id of some sort to
On Wed, 31 Oct 2007 08:02:40 -0800
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Paul's concern is, since we didn't need it so far - why we need this
> for hotplug memory remove to work ? It might break API for *unknown*
> applications. Its unfortunate that, hotplug memory add updates
> /proc/iome
Supply arch specific remove_memory() for PPC64. There is nothing
ppc specific code here and its exactly same as ia64 version.
For now, lets keep it arch specific - so each arch can add
its own special things if needed.
Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
---
arch/powerpc/mm/mem.c
walk_memory_resource() verifies if there are holes in a given
memory range, by checking against /proc/iomem. On x86/ia64
system memory is represented in /proc/iomem. On PPC64, we
don't show system memory as IO resource in /proc/iomem - instead
its maintained in /proc/device-tree.
This patch provi
Enable hotplug memory remove for ppc64.
Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig |3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6.23/arch/powerpc/Kconfig
===
--- linux-2.6.23.orig/arch
Hi Paul/Andrew,
Here are few minor fixes needed to get hotplug memory remove working
on ppc64. Could you please consider them for -mm ?
[PATCH 1/3] Add remove_memory() for ppc64
[PATCH 2/3] Enable hotplug memory remove for ppc64
[PATCH 3/3] Add arch-specific walk_memory_re
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf Of Grant Likely
> Sent: Monday, October 15, 2007 11:09 AM
> To: linuxppc-dev; [EMAIL PROTECTED]
> Subject: Refactor booting-without-of.txt
>
> Adding the Linux expected device tree bindings to
> boo
> > I think what we should do is keep device_type, including
> > permitting new uses of it in a limited way-- only permitting
> > the use of device_type when there is an official binding
> > (like in the power.org ePAPR) defined.
>
> That's what I was thinking when we first started defining
On Wed, 2007-10-31 at 14:28 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 30 Oct 2007 11:19:11 -0800
> Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> > Hi KAME,
> >
> > As I mentioned while ago, ppc64 does not export information about
> > "system RAM" in /proc/iomem. Looking at the code and usage
>
> > 1. There are types of nodes that don't have a programming
> > inteface per se and thus no compatible.
> > "cpu", "memory", "cache" are 3 that come to mind.
>
> Well, yes, this is why I suggested treating these "fundamental" nodes
> as a special case in an earlier mail.
Given your st
On Wed, 2007-10-31 at 14:34 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 31 Oct 2007 14:28:46 +0900
> KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> > ioresource was good structure for remembering "which memory is conventional
> > memory" and i386/x86_64/ia64 registered conventional memory as "Syst
> "Grant" == Grant Likely <[EMAIL PROTECTED]> writes:
Hi,
Grant> From: Grant Likely <[EMAIL PROTECTED]>
Grant> Change the wait_tx routine to call cpu_relax() instead of udelay() to
Grant> reduce console output latency and test for the TXFULL bit instead of
Grant> TXEMPTY. That way the FI
Hello.
Paul Mackerras wrote:
> If I take out the removed lines in the rest of your patch, I get:
>>+*/
>> #if defined(CONFIG_40x)
>> mtspr(SPRN_PIT, val);
>>+#else
>>+#if !defined(CONFIG_BOOKE)
>>+ val = val ? val - 1 : 0;
>>+#endif
>>+#if defined(CONFIG_8xx_CPU6)
>>
David Gibson wrote:
> On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote:
>> Jon Loeliger wrote:
>>> So, like, the other day Kumar Gala mumbled:
Jon,
It seems like have libfdt as a unique git repo that is a submodule of
the things that need it (dtc, u-boot, etc.)
On Wed, 31 Oct 2007 15:21:13 +0300
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> Josh Boyer wrote:
> > On Tue, 30 Oct 2007 19:45:11 +0300
> > Valentine Barshak <[EMAIL PROTECTED]> wrote:
> >
> >> The following patches add PowerPC 440GRx Rainier board support.
> >> The board is almost identical t
Olof Johansson wrote:
> On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
>> On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
>>> PowerPC 440GRx Rainier DTS.
>> [snip]
>>> + SDRAM0: sdram {
>>> + device_type = "memory-controller";
>> How man
Stephen Rothwell wrote:
> On Tue, 30 Oct 2007 19:57:39 +0300 Valentine Barshak <[EMAIL PROTECTED]>
> wrote:
>> +++ linux-2.6/arch/powerpc/platforms/44x/rainier.c 2007-10-30
>> 18:00:15.0 +0300
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#inclu
Josh Boyer wrote:
> On Tue, 30 Oct 2007 19:45:11 +0300
> Valentine Barshak <[EMAIL PROTECTED]> wrote:
>
>> The following patches add PowerPC 440GRx Rainier board support.
>> The board is almost identical to Sequoia, but doesn't have USB
>> and FPU is not supported.
>
> So why do we need anything
The decrementer in Book E and 4xx processors interrupts on the
transition from 1 to 0, rather than on the 0 to -1 transition as on
64-bit server and 32-bit "classic" (6xx/7xx/7xxx) processors. At the
moment we subtract 1 from the count of how many decrementer ticks are
required before the next int
Sergei Shtylyov writes:
> + /*
> +* The "classic" decrementer interrupts at 0 to -1 transition, while
> +* 40x and book E decrementers interrupt at 1 to 0 transition.
Funky spacing . : )
If I take out the removed lines in the rest of your patch, I get:
> +*/
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = <10d40 14 10d60 14>; // mdc: 0x10d40, mdio: 0x10d60
or
reg = <10d40 14>; // mdc and mdio have the same offset 10d40
The approach was taken from o
45 matches
Mail list logo
