Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
Posted here for review. Patch exists in my for-2.6.24 branch. Removed
defconfig to reduce patch review size.
arch/powerpc/boot/dts/mpc8572ds.dts |
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
Seems to me that this timer will only get started on platforms that say
they don't want it?
kernel/time/ntp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: working/kernel/time/ntp.c
With these functions implemented we cooperate better with the generic
timekeeping code. This obsoletes the need for the timer sysdev as a bonus.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
* Compile tested for arch/powerpc/configs/*_defconfig
* Booted on pSeries, iSeries, Cell and PS3
*
From: Tony Breeds [EMAIL PROTECTED]
Implement {read,update}_persistent_clock.
With these functions implemented we cooperate better with the generic
timekeeping code. This obsoletes the need for the timer sysdev as a bonus.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
Functionally is the
On Tue, Sep 11, 2007 at 05:49:17PM +1000, Tony Breeds wrote:
With these functions implemented we cooperate better with the generic
timekeeping code. This obsoletes the need for the timer sysdev as a bonus.
Looks fine, there is still the problem that most PPC RTC
seem to prefer update on the
On Tue, 2007-09-11 at 17:46 +1000, Tony Breeds wrote:
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
Seems to me that this timer will only get started on platforms that say
they don't want it?
Hell, yes. Good catch !
tglx
kernel/time/ntp.c |2 +-
1 file changed, 1
Hello,
I have developed a device driver and use the sysFS to export some
registers to userspace. I opened the sysFS File for one register and did
some reads from this File, but I alwas becoming the same value from the
register, whats not OK, because they are changing. So I found out that
the
Hi,
--- /dev/null
+++ b/drivers/dma/fsldma.c
@@ -0,0 +1,995 @@
Thanks for using kernel-doc notation. However, ...
+/**
+ * fsl_dma_alloc_descriptor - Allocate descriptor from
channel's DMA pool.
Function parameters need to be listed described here.
See
I'll merge them.
Thanks!
- zw
-Original Message-
From: David Gibson [mailto:[EMAIL PROTECTED]
Sent: Monday, September 10, 2007 11:28 AM
To: Zhang Wei-r63237
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2/5] Add Freescale DMA engine driver maintainer.
On
If this is experimental, perhaps you should mark the depends line as
such
depends on on DMA_ENGINE PPC EXPERIMENTAL
I'll add EXPERIMENTAL for MPC83xx only.
[...]
+
+fsl_dma_memcpy_issue_pending(chan);
+while (fsl_dma_is_complete(chan, cookie, NULL, NULL)
+
Hi, Dan,
Does I have followed your new API? :-)
---
Greetings,
Please copy me on any updates to this driver, drivers/dma, or
crypto/async_tx.
Ok.
Below are a few review comments...
Regards,
Dan
+/**
+ * fsl_dma_alloc_descriptor - Allocate descriptor from
channel's DMA
Dear Linux-enthusiasts,
I'm still at the same problem.
I have now implemented a irq_chip for the hardwired IRQ2. Now I have:
--==
volatile static struct mpc52xx_intr __iomem *intr;
unsigned long flags;
static DEFINE_SPINLOCK(my_irq_controller_lock);
/*
* HELPER-Function
*/
static inline
Here are some fresh eHCA driver features and fixes for your reviewing
pleasure. They have passed internal testing and checkpatch.pl, so we think
they are ready for inclusion.
[01/12] adds userspace support for small QPs
[02/12] changes a nit in firmware communication
[03/12] adds support for more
From: Stefan Roscher [EMAIL PROTECTED]
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/hcp_if.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/hcp_if.c
b/drivers/infiniband/hw/ehca/hcp_if.c
index
From: Stefan Roscher [EMAIL PROTECTED]
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_qp.c |7 +++
drivers/infiniband/hw/ehca/ipz_pt_fn.c |1 +
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
From: Hoang-Nam Nguyen [EMAIL PROTECTED]
Use Paul's new remap_4k_pfn() function to map our 4K firmware contexts into
user space on 64K-page machines without exposing neighboring firmware
contexts. Return the context's offset within a 64K page to user space so it
can determine the proper virtual
Change hvcall trace output towards better readability: reg numbers instead
of argument numbers, return code as signed decimal instead of unsigned hex.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/hcp_if.c | 57 ++
1 files
...because -12 is easier to read than FFF4.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_cq.c | 14 +++---
drivers/infiniband/hw/ehca/ehca_hca.c|2 +-
drivers/infiniband/hw/ehca/ehca_main.c | 24 +-
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_tools.h |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h
b/drivers/infiniband/hw/ehca/ehca_tools.h
index 57c77a7..f9b264b 100644
---
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h
b/drivers/infiniband/hw/ehca/ehca_tools.h
index f9b264b..863f972 100644
---
Rectify some modify_qp() issues related to path migration.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_irq.c |4 +-
drivers/infiniband/hw/ehca/ehca_qp.c | 90 -
2 files changed, 68 insertions(+), 26 deletions(-)
diff
Nobody needed the SVNEHCA_ prefix anyway.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_main.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c
b/drivers/infiniband/hw/ehca/ehca_main.c
On Tue, Sep 11, 2007 at 12:35:56AM -0500, Kumar Gala wrote:
On Aug 28, 2007, at 3:16 PM, Scott Wood wrote:
1. Fix get_immrbase() to use ranges, rather than reg.
It is not always the case that the SoC's first reg property points
to the beginning of the entire SoC block.
when is this
On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts
b/arch/powerpc/boot/dts/mpc8572ds.dts
new file mode 100644
index 000..9d23561
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -0,0 +1,378 @@
+/*
+ * MPC8572 DS
Hi,
On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
On Tue, Sep 11, 2007 at 06:01:39PM +0800, Zhang Wei-r63237 wrote:
On Fri, Sep 07, 2007 at 04:43:35PM +0200, Segher Boessenkool wrote:
+ l) Freescale DMA
+- compatible : Should be fsl,dma.
Please choose some more specific name. fsl,mpc8540-dma would
be a
On 9/11/07, S. Fricke [EMAIL PROTECTED] wrote:
Dear Linux-enthusiasts,
I'm still at the same problem.
I have now implemented a irq_chip for the hardwired IRQ2. Now I have:
--==
volatile static struct mpc52xx_intr __iomem *intr;
unsigned long flags;
static
On Tue, Sep 11, 2007 at 06:10:53PM +0800, Zhang Wei-r63237 wrote:
+
+ fsl_dma_memcpy_issue_pending(chan);
+ while (fsl_dma_is_complete(chan, cookie, NULL, NULL)
+ != DMA_SUCCESS);
Again, is it possible to hang your thread here?
[...]
I'll add msleep here.
I
Zhang Wei-r63237 wrote:
+/**
+ * fsl_chan_xfer_ld_queue -- Transfer the link descriptors
in channel
+ * ld_queue.
The function's short description (unfortunately) must be on only one
line. E.g.:
* fsl_chan_xfer_ld_queue - Transfer link descriptors in
channel
Hi,
Joachim Fenkes wrote:
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h
b/drivers/infiniband/hw/ehca/ehca_tools.h
From: Scott Wood [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 11, 2007 7:20 AM
To: Zhang Wei-r63237
Cc: Nelson, Shannon; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.org; Williams, Dan J; [EMAIL PROTECTED]
Subject: Re: [PATCH 5/5] Add DMA engine driver for Freescale
MPC85xx processors.
On Tue,
On Sep 11, 2007, at 8:57 AM, Scott Wood wrote:
On Tue, Sep 11, 2007 at 12:35:56AM -0500, Kumar Gala wrote:
On Aug 28, 2007, at 3:16 PM, Scott Wood wrote:
1. Fix get_immrbase() to use ranges, rather than reg.
It is not always the case that the SoC's first reg property points
to the
On Sep 11, 2007, at 9:18 AM, Olof Johansson wrote:
Hi,
On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor
mode.
---
diff --git
The initialization of the QE's GUEMR register is overly complicated, involving
multiple functions and a redundant ucc_common structure. This patch removes
struct ucc_common, merges ucc_init_guemr() into ucc_set_type() (every caller
of ucc_init_guemr() also calls ucc_set_type() immediately
Kumar Gala wrote:
Yep. However, after some discussion with Segher on this for
83xx/85xx/86xx I think we want to keep the reg prop and have it cover
the initial soc registers [size on 83xx is 0x100, size on 85xx/86xx
would be 0x1000].
What we need is a saner way to determine immr on 82xx
On Tue, Sep 11, 2007 at 10:50:18AM -0500, Kumar Gala wrote:
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 3a5c3c4..1e2eba8 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -181,6
On Sep 11, 2007, at 9:17 AM, Scott Wood wrote:
On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/
boot/dts/mpc8572ds.dts
new file mode 100644
index 000..9d23561
--- /dev/null
+++
On Sep 11, 2007, at 10:55 AM, Olof Johansson wrote:
On Tue, Sep 11, 2007 at 10:50:18AM -0500, Kumar Gala wrote:
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 3a5c3c4..1e2eba8 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
Take two, with my clean ups to the device tree as commented by Scott and
fixing my copy/paste foobar with pci_ids.h.
arch/powerpc/boot/dts/mpc8572ds.dts
On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
Kumar Gala wrote:
Yep. However, after some discussion with Segher on this for 83xx/
85xx/86xx I think we want to keep the reg prop and have it cover
the initial soc registers [size on 83xx is 0x100, size on 85xx/
86xx would be 0x1000].
On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
Kumar Gala wrote:
On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
Any particular reason to special-case it, when we already need
code to do it the other way for every other fsl soc?
If you suggest a sane way of getting the value let me know.
Kumar Gala wrote:
On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
I propose we do it by defining the first (and ideally only, but
that's another argument) entry in ranges as the immr, and getting
rid of /soc/reg.
I disagree.
I'm shocked. :-)
I don't think we want to start overloading
On Tue, 11 Sep 2007 12:03:31 -0500
Scott Wood [EMAIL PROTECTED] wrote:
It'd probably be more efficient to discuss this in person; can you stop
by my cube sometime when you're around and not in a meeting?
Please be sure to post a summary of the discussion if you do that so the
other people
On 9/11/07, Michal Simek [EMAIL PROTECTED] wrote:
Hi Grant,
(Adding linuxppc-dev mailing list to CC list because we're discussing
FDT issues)
I made EDK repository file for generation dts file from Xilinx design. I sent
it to Wolfgang and Steve this week.
It is in the same config file as I
Paul and Kumar,
It turns out that I have a bunch more QE library code clean-up, so please
ignore this patch. I'll submit a more comprehensive one later this week.
Timur Tabi wrote:
The initialization of the QE's GUEMR register is overly complicated, involving
multiple functions and a
On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 10:55 AM, Olof Johansson wrote:
On Tue, Sep 11, 2007 at 10:50:18AM -0500, Kumar Gala wrote:
How different are these boards really? Could you just detect
MPC85xxDS
and have a generic platform for them,
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
well the ifdefs are orthogonal. We don't have a way of knowing
primary from the device tree today.
How about something like fsl,primary-phb in the bus device node? I don't
know, maybe it's already been
On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
well the ifdefs are orthogonal. We don't have a way of knowing
primary from the device tree today.
How about something like fsl,primary-phb
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
well the ifdefs are orthogonal. We don't have a way of knowing
primary from the device tree today.
How about something like
On Sep 11, 2007, at 12:03 PM, Scott Wood wrote:
Kumar Gala wrote:
On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
I propose we do it by defining the first (and ideally only, but
that's another argument) entry in ranges as the immr, and getting
rid of /soc/reg.
I disagree.
I'm
On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
well the ifdefs are orthogonal. We don't have a way of knowing
primary from
Hi,
I am using the kernel 2.6.23-rc3, when i try to boot the kernel i got
following messages.
Booting image at 0020 ...
Image Name: Linux-2.6.23-rc3
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1487259 Bytes = 1.4 MB
Load Address:
Entry
On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8544ds.dts| 88 --
Hello,
[...]
intr = mpc52xx_find_and_map(mpc52xx-pic);
if(!intr) {
panic(__FILE__ : mpc52xx-pic - MAP failed);
}
set_irq_chip(MPC52xx_IRQ2, my_irq_chip);
You probably don't want to do this (unless you are cascading IRQs to
custom external hardware). All
On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
On Sep 11, 2007, at 12:09 PM, Timur Tabi wrote:
Paul and Kumar,
It turns out that I have a bunch more QE library code clean-up, so
please ignore this patch. I'll submit a more comprehensive one
later this week.
Timur Tabi wrote:
The initialization of the QE's GUEMR register is
On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
Signed-off-by:
On Sep 11, 2007, at 1:43 PM, Becky Bruce wrote:
On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
On Fri, Aug 17, 2007 at
On 9/11/07, S. Fricke [EMAIL PROTECTED] wrote:
Hello,
[...]
intr = mpc52xx_find_and_map(mpc52xx-pic);
if(!intr) {
panic(__FILE__ : mpc52xx-pic - MAP failed);
}
set_irq_chip(MPC52xx_IRQ2, my_irq_chip);
You probably don't want to do this (unless you
On Tue, Sep 11, 2007 at 01:43:59PM -0500, Becky Bruce wrote:
Maybe it would make more sense for you guys to slice the platforms
differently, and have a common platform for the eval boards you have
with ULi on them instead of grouping it by core used by the processor
on the board.
(In
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
Rev 3 -- updates to the device tree based on discussion on how we want
to handle memory busses going forward.
arch/powerpc/boot/dts/mpc8572ds.dts |
On Tue, Sep 11, 2007 at 02:22:21PM -0500, Becky Bruce wrote:
I'm also guilty of not noticing the original patch - my apologies.
maybe we should just have a platforms/fsl for all boards from
freescale. Not having things broken up by which processor family
they are for.
What do
Paul Mackerras wrote:
It might be better to use hard_irq_disable rather than
local_irq_disable here, since I think we will need that on 64-bit (and
on 32-bit if we ever do lazy irq disabling there).
OK.
+/* Overrides the weak version in kernel/power/main.c */
+void
Scott Wood writes:
The e300 core (and probably most other 6xx chips) can only come out of
sleep mode with an interrupt. However, interrupts are logically disabled
by the power management layer.
This hack extends the existing doze/nap hack to also suppress the running
of the interrupt
Paul Mackerras wrote:
Scott Wood writes:
The e300 core (and probably most other 6xx chips) can only come out of
sleep mode with an interrupt. However, interrupts are logically disabled
by the power management layer.
This hack extends the existing doze/nap hack to also suppress the running
We are having 2 different instances of pci_process_bridge_OF_ranges(),
which makes describing 64-bit physical addresses in non PPC64 case
impossible.
This approach inherits pci space parsing, but has a new way to behave
equally good in both 32bit and 64bit environments. This approach uses
On Wednesday 12 September 2007, Vitaly Bordug wrote:
We are having 2 different instances of pci_process_bridge_OF_ranges(),
which makes describing 64-bit physical addresses in non PPC64 case
impossible.
This approach inherits pci space parsing, but has a new way to behave
equally good in
On Wed, 12 Sep 2007 00:57:17 +0200
Arnd Bergmann wrote:
On Wednesday 12 September 2007, Vitaly Bordug wrote:
We are having 2 different instances of
pci_process_bridge_OF_ranges(), which makes describing 64-bit
physical addresses in non PPC64 case impossible.
This approach inherits
On Wed, 12 Sep 2007, Michael Neuling wrote:
The tty: termios locking functions break with new termios type patch
(f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
Really?
It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
on the architecture
On Tue, Sep 11, 2007 at 07:17:42PM -0700, Linus Torvalds wrote:
Really?
It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
on the architecture having a define for TCGETS2, and I think they match
up. I see:
[EMAIL PROTECTED] linux]$ git grep -l
On Wed, 12 Sep 2007, Michael Neuling wrote:
The tty: termios locking functions break with new termios type patch
(f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
Really?
It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
on the
On Tue, Sep 11, 2007 at 12:59:22PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
well the
On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
Rev 3 -- updates to the device tree based on discussion on how we want
to handle memory
On Wed, 2007-09-12 at 12:05 +1000, David Gibson wrote:
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
Hello,
I have developed a device driver and use the sysFS to export some
registers to userspace. I opened the sysFS File for one register and did
some reads from this
On Sep 11, 2007, at 10:11 PM, David Gibson wrote:
On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor
mode.
---
Rev 3 -- updates to the device tree
On Sep 11, 2007, at 10:00 PM, David Gibson wrote:
On Tue, Sep 11, 2007 at 12:59:22PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
Olof Johansson wrote:
On Tue, Sep 11, 2007 at
On Tue, Sep 11, 2007 at 10:35:01PM -0500, Kumar Gala wrote:
In the meantime, couldn't the code still be merged, using an explicit
test of the root node's 'compatible' or 'model' properties to decide
on the right primary bus.
I will be, I'm not going to wait on having some device tree spec
On Tue, Sep 11, 2007 at 10:35:01PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 10:00 PM, David Gibson wrote:
On Tue, Sep 11, 2007 at 12:59:22PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
Olof Johansson wrote:
On Tue, Sep 11, 2007 at 12:21:30PM -0500,
Make the define_machine() block for mpc885_ads more greppable and consistent
with other examples in tree.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
Index:
This is a copy of an older patch that is in rc3-mm1. It's needed
to allow the remaining patches to integrate correctly.
Signed-off-by: Mike Travis [EMAIL PROTECTED]
---
arch/x86_64/kernel/genapic.c |2 --
arch/x86_64/kernel/genapic_flat.c |1 -
arch/x86_64/kernel/smpboot.c |
Fix four instances where cpu_to_node is referenced
by array instead of via the cpu_to_node macro. This
is preparation to moving it to the per_cpu data area.
Signed-off-by: Mike Travis [EMAIL PROTECTED]
---
arch/x86_64/kernel/vsyscall.c |2 +-
arch/x86_64/mm/numa.c |4 ++--
Note:
This patch consolidates all the previous patches regarding
the conversion of static arrays sized by NR_CPUS into per_cpu
data arrays and is referenced against 2.6.23-rc6 .
v1 Intro:
In x86_64 and i386 architectures most arrays that are sized
using NR_CPUS lay in local memory on node 0.
Convert cpu_sibling_map to a per_cpu cpumask_t array for the sparc64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
Note: these changes have not been built nor tested.
Signed-off-by: Mike Travis [EMAIL PROTECTED]
---
This is from an earlier message from 'Christoph Lameter':
cpu_core_map is currently an array defined using NR_CPUS. This means that
we overallocate since we will rarely really use maximum configured cpu.
If we put the cpu_core_map into the per cpu area then it will be allocated
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ia64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
There was one access to cpu_sibling_map before the per_cpu data
area was created, so that step was moved to after the
This patch converts the x86_cpu_to_apicid array to be a per
cpu variable. This saves sizeof(apicid) * NR unused cpus.
Access is mostly from startup and CPU HOTPLUG functions.
MP_processor_info() is one of the functions that require access
to the x86_cpu_to_apicid array before the per_cpu data
Convert cpu_sibling_map from a static array sized by NR_CPUS to a
per_cpu variable. This saves sizeof(cpumask_t) * NR unused cpus.
Access is mostly from startup and CPU HOTPLUG functions.
Signed-off-by: Mike Travis [EMAIL PROTECTED]
---
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c |2 -
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ppc64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
Note: these changes have not been built nor tested.
Signed-off-by: Mike Travis [EMAIL PROTECTED]
---
This is from an earlier message from Christoph Lameter:
processor_core.c currently tries to determine the apicid by special casing
for IA64 and x86. The desired information is readily available via
cpu_physical_id()
on IA64, i386 and x86_64.
Signed-off-by: Christoph
On Tue, Sep 11, 2007 at 09:34:13AM -0500, Milton Miller wrote:
Previously we called ppc_md.get_boot_time at most once. How about
moving the check for it into the if (first) block?
Yup on investigatiion it looks like moving it inside the if (fist) is
safe.
Have you tested with a platform
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
I have developed a device driver and use the sysFS to export some
registers to userspace.
Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
not to play around with registers from userspace.
I opened the
91 matches
Mail list logo
