On Sun, 14 Oct 2007, Anton Blanchard wrote:
Hi Arnd,
The code looks correct, but I think it would be nicer to change
hrtimer_nanosleep to take a kernel pointer and have all three
callers (common_nsleep, sys_nanosleep and compat_sys_nanosleep)
do the copy_to_user/put_compat_timespec in
On Sun, Oct 14, 2007 at 03:23:21PM -0600, Grant Likely wrote:
On 10/14/07, Sven Luther [EMAIL PROTECTED] wrote:
On Sun, Oct 14, 2007 at 02:22:16PM -0600, Grant Likely wrote:
On 10/14/07, Sven Luther [EMAIL PROTECTED] wrote:
On Sat, Oct 13, 2007 at 10:42:05PM -0600, Grant Likely wrote:
Hi Thomas,
Thanks for the review, updates to follow.
Anton
--
Pull the copy_to_user out of hrtimer_nanosleep and into the callers
(common_nsleep, sys_nanosleep) in preparation for converting
compat_sys_nanosleep to use hrtimers.
Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
---
diff
Now we have high res timers on ppc64 I thought Id test them. It turns
out compat_sys_nanosleep hasnt been converted to the hrtimer code and so
is limited to HZ resolution.
The follow patch converts compat_sys_nanosleep to use high res timers.
Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
This is 2 patches, one from Christoph Hellwig that adds the backtrace support,
and one from Johannes Berg modified by me that adds the irq tracing support.
This successfully boots a POWER5 pSeries machine. I'm going to run some more
tests in the upcoming few days, so this is not an official
From: Christoph Hellwig [EMAIL PROTECTED]
I recently tried to work on lockdep for powerpc. I have preliminary
version of the stacktrace code, but had to give up on trace irqflags
support because I'm not that knowledgeable on lowlevel ppc details.
Maybe someone more faimilar with the code wants
This adds the low level irq tracing hooks to the powerpc architecture
needed to enable full lockdep functionality
Some rework from Johannes initial version, removing the asm trampoline that
isn't needed (thus improving perfs) and fixing a couple of bugs such as
incorrect initial preempt_count on
On Monday 15 October 2007, Anton Blanchard wrote:
Pull the copy_to_user out of hrtimer_nanosleep and into the callers
(common_nsleep, sys_nanosleep) in preparation for converting
compat_sys_nanosleep to use hrtimers.
Looks good, except for two micro-optimization:
Signed-off-by: Anton
On Mon, 2007-10-15 at 17:28 +1000, Benjamin Herrenschmidt wrote:
This adds the low level irq tracing hooks to the powerpc architecture
needed to enable full lockdep functionality
Some rework from Johannes initial version, removing the asm trampoline that
isn't needed (thus improving perfs)
--- linux-work.orig/include/asm-powerpc/irqflags.h 2007-10-15
17:10:12.0 +1000
+++ linux-work/include/asm-powerpc/irqflags.h 2007-10-15
17:11:09.0 +1000
/*
- * Do the CPU's IRQ-state tracing from assembly code. We call a
- * C function, so save all the
Now that dcr_host_t contains the base address, we can use that in the
ibm_newemac code, rather than storing it separately.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/mal.c |9 +
drivers/net/ibm_newemac/mal.h |5 ++---
2 files changed, 7
This requires us to do a sort-of fake dcr_map(), so that base is set
properly. This will be fixed/removed when the device-tree-aware emac driver
is merged.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
drivers/net/ibm_emac/ibm_emac_mal.c |5 -
drivers/net/ibm_emac/ibm_emac_mal.h
Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we
can save them the trouble and do it in dcr_read()/dcr_write().
As some background to why we just went through all this jiggery-pokery,
benh sayeth:
Initially the goal of the dcr_read/dcr_write routines was to operate like
With the base stored in dcr_host_t, there's no need for callers to pass
the dcr_n into dcr_unmap(). In fact this removes the possibility of them
passing the incorrect value, which would then be iounmap()'ed.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/sysdev/dcr.c|
-Original Message-
From: Medve Emilian-EMMEDVE1
Sent: Saturday, October 13, 2007 7:26 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Li
Yang-r58472; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Cc: Medve Emilian-EMMEDVE1
Subject: [PATCH] [POWERPC] ucc_geth: Fix build break
Hello Arnd,
Thanks for your comments and feedback.
Actually, for PowerPC platforms iowrite32/ioread32 internally call
writel/readl, which are again mapped to out_le32/in_le32,
therefore we will modify our code to use of_iomap() to combine
functionalities of both of_address_to_resource()
On Monday 15 October 2007, Kalra Ashish-B00888 wrote:
Thanks for your comments and feedback.
Actually, for PowerPC platforms iowrite32/ioread32 internally call
writel/readl, which are again mapped to out_le32/in_le32,
This is correct on 6xx and e500 for now, but it's a little more
My nits:
Grant Likely wrote:
From: Sylvain Munaut [EMAIL PROTECTED]
+static int __devinit
+bcom_engine_init(void)
Why bcom and not bestcomm?
+ /* Disable COMM Bus Prefetch, apparently it's not reliable yet */
+ /* FIXME: This should be done on 5200 and not 5200B ... */
+
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Arnd Bergmann
Sent: Friday, October 12, 2007 10:34 PM
To: linuxppc-dev@ozlabs.org
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: Re: [PATCH v3 3/9] add Freescale SerDes PHY support
On
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-ibm_iic.c | 192 +++---
drivers/i2c/busses/i2c-ibm_iic.h |8 +-
2 files changed, 100 insertions(+), 100 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
Hello Friends,
what is the reasonable can-driver for a mpc5200b?
I have seen for the peak-3.17 driver a port for the mpc5200 from denx on their
website, but with kernel 2.6.23 I dont have a chance to use this?
greetings,
Silvio Fricke
--
-- S. Fricke - MAILTO:[EMAIL
So, like, the other day David Gibson mumbled:
At present, the fdt_subnode_offset() and fdt_path_offset() functions
in libfdt require the exact name of the nodes in question be passed,
including unit address.
This is contrary to traditional OF-like finddevice() behaviour, which
allows the
This patch reworks existing ibm-iic driver to support of_platform_device
and enables it to talk to device tree directly. The old OCP interface
for arch/ppc is still supported via #ifdef's and shall be removed when
arch/ppc is gone in a few months.
This is done to enable I2C support for the PPC4xx
So, like, the other day David Gibson mumbled:
Here's a corrected version.
dtc: Refactor Makefiles
This patch makes a number of Makefile cleanups and improvements:
- We use more generic rules to invoke flex and bison, which is
useful for some of the other changes.
- We use
So, like, the other day David Gibson mumbled:
This patch adds functions to libfdt for accessing the memory
reservation map section of a device tree blob. fdt_num_mem_rsv()
retreives the number of reservation entries in a dtb, and
fdt_get_mem_rsv() retreives a specific reservation entry.
On Oct 13, 2007, at 11:41 PM, Grant Likely wrote:
From: Sylvain Munaut [EMAIL PROTECTED]
Instead of having in the makefile all the option that
requires rheap, we define a configuration symbol
and when needed we make sure it's selected.
Signed-off-by: Sylvain Munaut [EMAIL PROTECTED]
drivers/net/ucc_geth.c: In function 'ucc_geth_rx':
drivers/net/ucc_geth.c:3483: error: 'dev' undeclared (first use in this
function)
drivers/net/ucc_geth.c:3483: error: (Each undeclared identifier is reported
only once
drivers/net/ucc_geth.c:3483: error: for each function it appears in.)
On 10/15/07, Kumar Gala [EMAIL PROTECTED] wrote:
On Oct 13, 2007, at 11:41 PM, Grant Likely wrote:
From: Sylvain Munaut [EMAIL PROTECTED]
Instead of having in the makefile all the option that
requires rheap, we define a configuration symbol
and when needed we make sure it's selected.
On Oct 15, 2007, at 8:55 AM, Grant Likely wrote:
On 10/15/07, Kumar Gala [EMAIL PROTECTED] wrote:
On Oct 13, 2007, at 11:41 PM, Grant Likely wrote:
From: Sylvain Munaut [EMAIL PROTECTED]
Instead of having in the makefile all the option that
requires rheap, we define a configuration
On 10/15/07, Matt Sealey [EMAIL PROTECTED] wrote:
My nits:
Grant Likely wrote:
From: Sylvain Munaut [EMAIL PROTECTED]
+static int __devinit
+bcom_engine_init(void)
Why bcom and not bestcomm?
I can type 'bcom' twice as fast. :-) bcom is a suitable shortening;
I'm not concerned about
On Monday 15 October 2007, Li Yang-r58472 wrote:
I'd like to but of_iomap() couldn't provide the physical address of the
device used as identification.
It looks like you only use the physical address for a single printk,
so you could change that to print the full-name of the device node
-Original Message-
From: Medve Emilian-EMMEDVE1
Sent: Monday, October 15, 2007 9:44 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Li
Yang-r58472; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Cc: Medve Emilian-EMMEDVE1
Subject: [PATCH v2] [POWERPC] ucc_geth: Fix build break
On 10/15/07, Kumar Gala [EMAIL PROTECTED] wrote:
(Comments just on SRAM code)
I think this should be made generic and be utility functionality to
rheap.
CPM, CPM2, QE, L2 SRAM, etc can all use this. I'd rather we didn't
have 3 ways to do the exact same functionality. (cpm_dpalloc,
On 10/15/07, Kumar Gala [EMAIL PROTECTED] wrote:
On Oct 15, 2007, at 8:55 AM, Grant Likely wrote:
On 10/15/07, Kumar Gala [EMAIL PROTECTED] wrote:
On Oct 13, 2007, at 11:41 PM, Grant Likely wrote:
From: Sylvain Munaut [EMAIL PROTECTED]
Instead of having in the makefile all the
Grant Likely wrote:
On 10/15/07, Kumar Gala [EMAIL PROTECTED] wrote:
(Comments just on SRAM code)
I think this should be made generic and be utility functionality to
rheap.
CPM, CPM2, QE, L2 SRAM, etc can all use this. I'd rather we didn't
have 3 ways to do the exact same functionality.
The SerDes(serializer/deserializer) PHY block is a new SoC block used
in Freescale chips to support multiple serial interfaces, such as PCI
Express, SGMII, SATA.
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/platforms/Kconfig |3 +
arch/powerpc/sysdev/Makefile |1 +
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8377_mds.dts | 281 +++
arch/powerpc/boot/dts/mpc8378_mds.dts | 263 +
arch/powerpc/boot/dts/mpc8379_mds.dts | 299 +
3 files changed,
PA6T has a bug where the slbie instruction does not honor the large
segment bit. As a result, we have to always use slbia when switching
context.
We don't have to worry about changing the slbie's during fault processing,
since they should never be replacing one VSID with another using the
same
Kumar Gala wrote:
I don't see why we can't let users select it (saying that
differently, we should let users have this ability)
If you turn on the QE but don't turn on RHEAP, the build will fail. Do we
want to allow that?
--
Timur Tabi
Linux Kernel Developer @ Freescale
On Oct 15, 2007, at 9:53 AM, Timur Tabi wrote:
Kumar Gala wrote:
I don't see why we can't let users select it (saying that
differently, we should let users have this ability)
If you turn on the QE but don't turn on RHEAP, the build will
fail. Do we want to allow that?
nope.
- k
On Monday 15 October 2007, Li Yang wrote:
The SerDes(serializer/deserializer) PHY block is a new SoC block used
in Freescale chips to support multiple serial interfaces, such as PCI
Express, SGMII, SATA.
looks good now
Signed-off-by: Li Yang [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL
Kumar Gala wrote:
If you turn on the QE but don't turn on RHEAP, the build will fail.
Do we want to allow that?
nope.
Is there any way to force RHEAP to be selected when it's a user-selectable
option?
--
Timur Tabi
Linux Kernel Developer @ Freescale
On 10/15/07, Domen Puncer [EMAIL PROTECTED] wrote:
On 14/10/07 16:05 -0600, Grant Likely wrote:
On 10/14/07, Domen Puncer [EMAIL PROTECTED] wrote:
PHY part of the driver for mpc5200(b) ethernet.
Assuming I understand correctly, this comment is not correct and this
patch just adds an
On 10/15/07, Timur Tabi [EMAIL PROTECTED] wrote:
Kumar Gala wrote:
If you turn on the QE but don't turn on RHEAP, the build will fail.
Do we want to allow that?
nope.
Is there any way to force RHEAP to be selected when it's a user-selectable
option?
Yes, you just add menu text line
This patch creates localbus node, moves bcsr into it, and adds
localbus to the probe path.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Patch is against galak/powerpc.git master branch.
arch/powerpc/boot/dts/mpc8568mds.dts | 14 +++---
MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Patch is against galak/powerpc.git master branch.
arch/powerpc/boot/dts/mpc8568mds.dts | 35 +-
1 files changed, 34 insertions(+), 1
Oddly, a recent kernel (23fd50450a34f2558070ceabb0bfebc1c9604af5) stops
booting at windfarm: Drive bay control loop started., while previously
windfarm: CPUs control loops started was displayed a long time, i.e.
Backside took very long to start.
Haven't had a chance to look into it yet, any
Anton Vorontsov wrote:
This patch creates localbus node, moves bcsr into it, and adds
localbus to the probe path.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index 5439437..296adc3 100644
---
From: Grant Likely [EMAIL PROTECTED]
Here's my second version of xilinx device tree bindings. Please review
and comment. I'd like to push these out to Paulus in the next couple
of days.
Cheers,
g.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt
Adding the Linux expected device tree bindings to
booting-without-of.txt seems to be getting a little unwieldy. Plus
with more than one arch using the device tree (powerpc, sparc
microblaze) the device tree bindings aren't necessarily powerpc only
(the Xilinx devices certainly fall in this
This patch creates localbus node, moves bcsr into it, and adds
localbus to the probe path.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Notice that localbus control registers are in the soc address
space, but ranges are not. Just the same situation as with PCI
nodes.
Patch is against
MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Patch is against galak/powerpc.git master branch.
arch/powerpc/boot/dts/mpc8568mds.dts | 35 +-
1 files changed, 34 insertions(+), 1
On Mon, Oct 15, 2007 at 03:29:11PM +0200, Stefan Roese wrote:
snip
+#ifdef CONFIG_PPC_MERGE
+static int device_idx = -1;
+#endif
+
snip
+ dev-idx = ++device_idx;
+ adap-nr = dev-idx;
Hmm, this doesn't look right. That mighty powerpc device everybody
was so excited about for the
On 10/15/07, Stefan Roese [EMAIL PROTECTED] wrote:
This patch reworks existing ibm-iic driver to support of_platform_device
and enables it to talk to device tree directly. The old OCP interface
for arch/ppc is still supported via #ifdef's and shall be removed when
arch/ppc is gone in a few
On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
Adding the Linux expected device tree bindings to
booting-without-of.txt seems to be getting a little unwieldy. Plus
with more than one arch using the device tree (powerpc, sparc
microblaze) the device tree bindings aren't
From: Benjamin Herrenschmidt
In fact, I'm not sure what is your problem with the DEC
proper as the TB
will be used ultimately and thus it shouldn't drift more than the TB
does. Can your part use an externally clocked TB ?
If not, and you still have a drift despite calibration, you can
On 10/15/07, Eugene Surovegin [EMAIL PROTECTED] wrote:
On Mon, Oct 15, 2007 at 03:29:11PM +0200, Stefan Roese wrote:
snip
+#ifdef CONFIG_PPC_MERGE
+static int device_idx = -1;
+#endif
+
snip
+ dev-idx = ++device_idx;
+ adap-nr = dev-idx;
Hmm, this doesn't look right.
On 10/15/07, Olof Johansson [EMAIL PROTECTED] wrote:
On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
Adding the Linux expected device tree bindings to
booting-without-of.txt seems to be getting a little unwieldy. Plus
with more than one arch using the device tree (powerpc,
On Fri, 12 Oct 2007 17:03:05 +0400
Valentine Barshak [EMAIL PROTECTED] wrote:
This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
and adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC440EPx boards.
The PHY code is based on
Anton Vorontsov wrote:
MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index 8e15dba..1198363 100644
---
Hi,
On Mon, Oct 15, 2007 at 11:14:44AM -0600, Grant Likely wrote:
On 10/15/07, Olof Johansson [EMAIL PROTECTED] wrote:
The flat device tree is, in spite of what some people would like it to be,
not open firmware, nor is it the same as their bindings. So I think we'd
be doing ourselves a
Hello.
Tony Breeds wrote:
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
I don't see my own signoff or at least a reference to my prior work in
this patch or even at -rt patch -- despite this code ha clearly borrowed from
it. And I'm not sure why this crippled version (lacking 40x/ Book E
For anyone using my git tree I've rebased it now that the merge
window for 2.6.24 is ongoing and removed all branches.
The master/HEAD now is in sync with Linus's tree. I'll be starting
of a fixes-2.6.24 branch at some point as well as for-2.6.25 branch.
I'll try to keep the master branch
On Oct 15, 2007, at 12:33 PM, Sergei Shtylyov wrote:
Anton Vorontsov wrote:
MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/
boot/dts/mpc8568mds.dts
Hello.
Thomas Gleixner wrote:
No wonder here: the -rt patch already has much of this code since around
2.6.21. They have been submitted by me, mostly... and this patchset is
against the Linus' tree.
That would explain it ;-)
I was searching the linux-rt-users mailing list for any patches,
Benjamin Herrenschmidt wrote:
I'm about to release a new -rt patch based on -rc8. This patch series
blew up totally in trying to get it applied. I'm leaving it out, so after
I release the next series, could you update these patches.
No wonder here: the -rt patch already has much of this code
This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/platforms/44x/Kconfig |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
--- linux.orig/arch/powerpc/platforms/44x/Kconfig 2007-07-30
Valentine Barshak wrote:
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Signed-off-by:
Hello, I wrote:
@@ -797,6 +796,53 @@ void __init clocksource_init(void)
clock-name, clock-mult, clock-shift);
}
+static int decrementer_set_next_event(unsigned long evt,
+ struct clock_event_device *dev)
+{
+ set_dec(evt);
I'd use (evt -
Michael Ellerman wrote:
Now that dcr_host_t contains the base address, we can use that in the
ibm_newemac code, rather than storing it separately.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/mal.c |9 +
drivers/net/ibm_newemac/mal.h |5
On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
Is the entity described as localbus indeed so *board* specific?
That's what booting-without-of.txt gives as an example.
The board should have been left out of
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Valentine Barshak wrote:
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese [EMAIL
Emil Medve wrote:
drivers/net/ucc_geth.c: In function 'ucc_geth_rx':
drivers/net/ucc_geth.c:3483: error: 'dev' undeclared (first use in this
function)
drivers/net/ucc_geth.c:3483: error: (Each undeclared identifier is reported
only once
drivers/net/ucc_geth.c:3483: error: for each function
Josh Boyer wrote:
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Valentine Barshak wrote:
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by
On Mon, 15 Oct 2007 14:53:26 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Seems sane to me -- ACK -- but we have multiple people sending me
patches for a single driver. That's normal for janitorial cleanups
across the whole tree, but discouraged when multiple people are actively
working
On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
Segher is recommending that we use an aliases node as per the open
firmware example for this. I think in this case it would look
something like this (but I'm not the expert):
aliases {
IIC0 = /path/to/bus/[EMAIL PROTECTED];
Josh Boyer wrote:
On Mon, 15 Oct 2007 14:53:26 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Seems sane to me -- ACK -- but we have multiple people sending me
patches for a single driver. That's normal for janitorial cleanups
across the whole tree, but discouraged when multiple people are
Domen Puncer wrote:
Hello!
If there are no objections, I would like to get this merged
when bestcomm goes in (any time now?).
It's split into four parts:
1 - device tree
2 - small bestcomm change
3 - the actual driver
4 - phy part of the driver
patches #3 and #4 need to be combined
On Oct 15, 2007, at 1:47 PM, Scott Wood wrote:
On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
Is the entity described as localbus indeed so *board* specific?
That's what booting-without-of.txt gives as an
Kumar Gala wrote:
On Oct 15, 2007, at 1:47 PM, Scott Wood wrote:
On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
Is the entity described as localbus indeed so *board* specific?
That's what
On Mon, Oct 15, 2007 at 01:53:40PM -0500, Scott Wood wrote:
Though, I don't see what the problem with the original approach is, as long
as the numbers are chosen in the same way when registering i2c clients based
on the children of the adapter node. There's no concept in the hardware
itself
On 10/15/07, Scott Wood [EMAIL PROTECTED] wrote:
On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
Segher is recommending that we use an aliases node as per the open
firmware example for this. I think in this case it would look
something like this (but I'm not the expert):
On 10/15/07, Eugene Surovegin [EMAIL PROTECTED] wrote:
On Mon, Oct 15, 2007 at 01:53:40PM -0500, Scott Wood wrote:
Though, I don't see what the problem with the original approach is, as long
as the numbers are chosen in the same way when registering i2c clients based
on the children of the
On 10/15/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Domen Puncer wrote:
Hello!
If there are no objections, I would like to get this merged
when bestcomm goes in (any time now?).
It's split into four parts:
1 - device tree
2 - small bestcomm change
3 - the actual driver
4 - phy
On Monday 15 October 2007, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
Here's my second version of xilinx device tree bindings. Please review
and comment. I'd like to push these out to Paulus in the next couple
of days.
There are a few more properties that I can imagine you
Eugene Surovegin wrote:
On Mon, Oct 15, 2007 at 01:53:40PM -0500, Scott Wood wrote:
Though, I don't see what the problem with the original approach is,
as long as the numbers are chosen in the same way when registering
i2c clients based on the children of the adapter node. There's no
concept
Grant Likely wrote:
On 10/15/07, Scott Wood [EMAIL PROTECTED] wrote:
On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
Segher is recommending that we use an aliases node as per the open
firmware example for this. I think in this case it would look
something like this (but I'm not
On 10/15/07, Scott Wood [EMAIL PROTECTED] wrote:
Grant Likely wrote:
On 10/15/07, Scott Wood [EMAIL PROTECTED] wrote:
On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
Segher is recommending that we use an aliases node as per the open
firmware example for this. I think in
On 10/15/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Monday 15 October 2007, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
Here's my second version of xilinx device tree bindings. Please review
and comment. I'd like to push these out to Paulus in the next couple
of days.
Grant Likely wrote:
On 10/15/07, Scott Wood [EMAIL PROTECTED] wrote:
For associating a device node with a human readable label, I'd
prefer a label property in the device node, rather than doing it
backwards with aliases.
Here the corresponding problem; having to scan every device node to
From: Grant Likely [EMAIL PROTECTED]
USB support for the 8349itx got added a while back; but the defconfig
never got updated. This patch updates defconfig and adds the appropriate
USB config options.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
CC: Scott Wood [EMAIL PROTECTED]
CC: Kumar Gala
Hi Stefan,
On Mon, 15 Oct 2007 15:28:54 +0200, Stefan Roese wrote:
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-ibm_iic.c | 192
+++---
drivers/i2c/busses/i2c-ibm_iic.h |8 +-
2 files changed, 100 insertions(+), 100
On 10/15/07, Scott Wood [EMAIL PROTECTED] wrote:
Grant Likely wrote:
On 10/15/07, Scott Wood [EMAIL PROTECTED] wrote:
For associating a device node with a human readable label, I'd
prefer a label property in the device node, rather than doing it
backwards with aliases.
Here the
Grant Likely wrote:
On 10/15/07, Matt Sealey [EMAIL PROTECTED] wrote:
My nits:
Grant Likely wrote:
From: Sylvain Munaut [EMAIL PROTECTED]
+static int __devinit
+bcom_engine_init(void)
Why bcom and not bestcomm?
I can type 'bcom' twice as fast. :-) bcom is a suitable shortening;
I'm
Matt Sealey wrote:
call a PSC, we wouldn't be making structures called
mpc52xx_programmable_serial_controller,
that's redundant, I don't think calling it bestcomm (which is it's name)
over
bcom (which isn't) works to anyone's advantage here.
Disadvantage, even. Damn autocorrecting :(
--
On Mon, 2007-10-15 at 14:34 -0400, Jeff Garzik wrote:
Michael Ellerman wrote:
Now that dcr_host_t contains the base address, we can use that in the
ibm_newemac code, rather than storing it separately.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
On Mon, 2007-10-15 at 11:49 -0500, Rune Torgersen wrote:
The main couse is that our main bus frequency cannort be divided into
1kHz evently by the decrementer.
Main bus freq = 99532800 Hz.
Decrementer then becomes 24883, which gives us 91.9624485600nsec
per
jiffy.
That is not a
On Fri, 2007-10-12 at 17:03 +0400, Valentine Barshak wrote:
This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
and adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC440EPx boards.
The PHY code is based on the previous work by
On Mon, 2007-10-15 at 12:26 -0500, Josh Boyer wrote:
On Fri, 12 Oct 2007 17:03:05 +0400
Valentine Barshak [EMAIL PROTECTED] wrote:
This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
and adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips
On Fri, 2007-10-12 at 17:04 +0400, Valentine Barshak wrote:
Fix build RGMII error: use of_device_is_compatible()
insteadof now deprecated device_is_compatible() function.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
1 - 100 of 140 matches
Mail list logo
