Compiling ppc64_defconfig with gcc 4.3 gives thes warnings:
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_get_priority':
arch/powerpc/sysdev/mpic.c:1351: warning: 'is_ipi' may be used uninitialized in
this function
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority':
Michael Ellerman wrote:
Since commit 85xx: Add support for relocatable kernel (and
booting at non-zero) (37dd2badcfcec35f5e21a0926968d77a404f03c3),
PHYSICAL_START is #defined as kernstart_addr if RELOCATABLE
and FLATMEM is enabled.
PHYSICAL_START is used in prom_init.c and so kernstart_addr
Trent Piepho [EMAIL PROTECTED] writes:
On Wed, 21 May 2008, Andreas Schwab wrote:
Trent Piepho [EMAIL PROTECTED] writes:
It's the _le versions that have a problem, since we can't get gcc to just
use
the register indexed mode. It seems like an obvious thing to have a
constraint for, but I
Initialize I2C pins on boards with CPM1/CPM2 controllers.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 39 ++
arch/powerpc/boot/dts/mpc8272ads.dts | 11 +++
arch/powerpc/boot/dts/mpc866ads.dts
This driver uses the port of 2.4 code from Vitaly Bordug
[EMAIL PROTECTED] and the actual algorithm used by the i2c
driver of the DBox code on cvs.tuxboc.org from Felix Domke
([EMAIL PROTECTED]) and Gillem ([EMAIL PROTECTED]) converted to an
of_platform_driver. Tested on CPM1 (MPC823 on dbox2
Depends on what you define as necessary. It's seem clear that I/O accessors
_no not_ need to be strictly ordered with respect to normal memory accesses,
by what's defined in memory-barriers.txt. So if by necessary you mean what
the Linux standard for I/O accessors requires (and what other
On Tue, 2008-05-20 at 15:55 -0700, Trent Piepho wrote:
here doesn't appear to be any barriers to use for coherent dma other than
mb() and wmb().
Correct me if I'm wrong, but I think the sync isn't actually _required_ (by
memory-barriers.txt's definitions), and it would be enough to use
Hi,
I'm sure I've sent these patches before, but I can't remember why they
weren't merged. They still seem obviously correct to me.
--
lwsync is explicitly defined not to have any effect on the ordering of
accesses to device memory, so it cannot be used for rmb(). sync appears
to be the only
lwsync is the recommended method of store/store ordering on caching enabled
memory. For those subarchs which have lwsync, use it rather than eieio for
smp_wmb.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/asm-powerpc/system.h
Hi Jochen,
On Wed, May 21, 2008 at 12:43:22PM +0200, Jochen Friedrich wrote:
This driver uses the port of 2.4 code from Vitaly Bordug
[EMAIL PROTECTED] and the actual algorithm used by the i2c
driver of the DBox code on cvs.tuxboc.org from Felix Domke
([EMAIL PROTECTED]) and Gillem ([EMAIL
On Wed, 21 May 2008 16:33:07 +0200, Wolfram Sang wrote:
Hi Jochen,
On Wed, May 21, 2008 at 12:43:22PM +0200, Jochen Friedrich wrote:
This driver uses the port of 2.4 code from Vitaly Bordug
[EMAIL PROTECTED] and the actual algorithm used by the i2c
driver of the DBox code on
On Wed, May 21, 2008 at 12:31:40PM +0200, Jochen Friedrich wrote:
+ - linux,i2c-index : Can be used to hard code an i2c bus nummer.
s/nummer/number/
Why do we need this?
+ - linux,i2c-class : Can be used to override the i2c class. The class is
used
+ by old style i2c device drivers
On Fri, May 16, 2008 at 01:36:13PM -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
This patch adds support for populating an SPI bus based on data in the
OF device tree. This is useful for powerpc platforms which use the
device tree instead of discrete code for describing
On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote:
lwsync is the recommended method of store/store ordering on caching enabled
memory. For those subarchs which have lwsync, use it rather than eieio for
smp_wmb.
Yuck... existence of lwsync depends on the processor at boot time...
Ben.
On Wed, 2008-05-21 at 16:10 +0200, Nick Piggin wrote:
Hi,
I'm sure I've sent these patches before, but I can't remember why they
weren't merged. They still seem obviously correct to me.
We should already do all that's needed in our IO accessors no ?
--
lwsync is explicitly defined not
On Wed, May 21, 2008 at 11:27:03AM -0400, Benjamin Herrenschmidt wrote:
On Wed, 2008-05-21 at 16:10 +0200, Nick Piggin wrote:
Hi,
I'm sure I've sent these patches before, but I can't remember why they
weren't merged. They still seem obviously correct to me.
We should already do all
On Wed, May 21, 2008 at 11:26:32AM -0400, Benjamin Herrenschmidt wrote:
On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote:
lwsync is the recommended method of store/store ordering on caching enabled
memory. For those subarchs which have lwsync, use it rather than eieio for
smp_wmb.
Hi all,
This is just a bait for further discussion of OF/SPI, chip-selects,
e.t.c.
I've converted the spi_mpc83xx to the OF driver (using Grant's
SPI_MASTER_OF work + some additions), and implemented MMC-over-SPI
bindings. This stuff extensively using GPIOs, and I think this will
work for the
Dedicated (usually the ones that need to fill platform data) constructors
will create board info, so SPI core will probe them as normal SPI devices.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/spi/spi_of.c | 67
This patch converts the driver to speak OF directly. FSL SPI controllers
do not use internal chip-select machines, so boards must use GPIOs for
these purposes.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt |1 +
drivers/spi/Kconfig
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 24 +
drivers/of/Kconfig |6 ++
drivers/of/Makefile |1 +
drivers/of/spi_mmc.c | 122
This patch implements support for PIXIS' GPIOs and adds appropriate
nodes to support MMC-over-SPI.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 32
arch/powerpc/platforms/86xx/Kconfig|2 +
On Wed, 2008-05-21 at 17:34 +0200, Nick Piggin wrote:
On Wed, May 21, 2008 at 11:26:32AM -0400, Benjamin Herrenschmidt wrote:
On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote:
lwsync is the recommended method of store/store ordering on caching
enabled
memory. For those
On Wed, 2008-05-21 at 17:32 +0200, Nick Piggin wrote:
We should already do all that's needed in our IO accessors no ?
More than one device driver does raw/relaxed io accessors and expects
the
*mb functions to order them.
That's fishy... ok.
Ben.
On Wed, May 21, 2008 at 11:43:00AM -0400, Benjamin Herrenschmidt wrote:
On Wed, 2008-05-21 at 17:34 +0200, Nick Piggin wrote:
On Wed, May 21, 2008 at 11:26:32AM -0400, Benjamin Herrenschmidt wrote:
On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote:
lwsync is the recommended
On Wed, 21 May 2008, Anton Vorontsov wrote:
This is just a bait for further discussion of OF/SPI, chip-selects,
e.t.c.
I've converted the spi_mpc83xx to the OF driver (using Grant's
SPI_MASTER_OF work + some additions), and implemented MMC-over-SPI
bindings. This stuff extensively using
On Wed, 21 May 2008, Anton Vorontsov wrote:
Dedicated (usually the ones that need to fill platform data) constructors
will create board info, so SPI core will probe them as normal SPI devices.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/spi/spi_of.c | 67
On Wed, May 21, 2008 at 05:54:20PM +0200, Guennadi Liakhovetski wrote:
On Wed, 21 May 2008, Anton Vorontsov wrote:
This is just a bait for further discussion of OF/SPI, chip-selects,
e.t.c.
I've converted the spi_mpc83xx to the OF driver (using Grant's
SPI_MASTER_OF work + some
On Wed, May 21, 2008 at 11:43:00AM -0400, Benjamin Herrenschmidt wrote:
On Wed, 2008-05-21 at 17:34 +0200, Nick Piggin wrote:
On Wed, May 21, 2008 at 11:26:32AM -0400, Benjamin Herrenschmidt wrote:
On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote:
lwsync is the recommended
On Wed, 2008-05-21 at 17:47 +0200, Nick Piggin wrote:
OK, but I just don't understand what the problem is... your synch.h
has
#ifdef __powerpc64__
#define __SUBARCH_HAS_LWSYNC
#endif
#ifdef __SUBARCH_HAS_LWSYNC
#define LWSYNC lwsync
#else
#define LWSYNC sync
Is this a known problem?
Thx, Luke
0:mon x
Unable to handle kernel paging request for data at address 0x0170
Faulting instruction address: 0xc00d8f70
cpu 0x0: Vector: 300 (Data Access) at [c07c3500]
pc: c00d8f70: .kmem_cache_alloc+0x3c/0xd0
lr:
On Wed, May 21, 2008 at 05:56:33PM +0200, Guennadi Liakhovetski wrote:
On Wed, 21 May 2008, Anton Vorontsov wrote:
Dedicated (usually the ones that need to fill platform data) constructors
will create board info, so SPI core will probe them as normal SPI devices.
Signed-off-by: Anton
Hi Scott,
+ - linux,i2c-index : Can be used to hard code an i2c bus number.
+ - linux,i2c-class : Can be used to override the i2c class.
Why do we need this?
There are still a bunch of i2c drivers using the old API (mainly v4l and dvb
stuff)
which are slowly being converted by their
On Wed, 21 May 2008, Anton Vorontsov wrote:
On Wed, May 21, 2008 at 05:56:33PM +0200, Guennadi Liakhovetski wrote:
Hm, I might well misunderstand something here, but it looks to me like you
are again trying to use both OF _and_ platform (spi_board_info) bindings
for your SPI setup?
Initialize I2C pins on boards with CPM1/CPM2 controllers.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 42 ++
arch/powerpc/boot/dts/mpc8272ads.dts | 11 +++
arch/powerpc/boot/dts/mpc866ads.dts
This driver uses the port of 2.4 code from Vitaly Bordug
[EMAIL PROTECTED] and the actual algorithm used by the i2c
driver of the DBox code on cvs.tuxboc.org from Felix Domke
([EMAIL PROTECTED]) and Gillem ([EMAIL PROTECTED]) converted to an
of_platform_driver. Tested on CPM1 (MPC823 on dbox2
Geoff Levand wrote:
A change was made to walk_memory_resource() in commit
4b119e21d0c66c22e8ca03df05d9de623d0eb50f that added a
check of find_lmb(). Add the coresponding lmb_add()
call to ps3_mm_add_memory() so that that check will
succeed.
This fixes the condition where the PS3 boots up
On Wed, May 21, 2008 at 06:24:58PM +0200, Guennadi Liakhovetski wrote:
On Wed, 21 May 2008, Anton Vorontsov wrote:
On Wed, May 21, 2008 at 05:56:33PM +0200, Guennadi Liakhovetski wrote:
Hm, I might well misunderstand something here, but it looks to me like
you
are again trying
On Wed, May 21, 2008 at 9:41 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
This patch converts the driver to speak OF directly. FSL SPI controllers
do not use internal chip-select machines, so boards must use GPIOs for
these purposes.
Mostly this looks good to me, but I didn't look
On Wed, May 21, 2008 at 9:41 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
Hi all,
This is just a bait for further discussion of OF/SPI, chip-selects,
e.t.c.
I've converted the spi_mpc83xx to the OF driver (using Grant's
SPI_MASTER_OF work + some additions), and implemented MMC-over-SPI
On Wed, May 21, 2008 at 10:50:02AM -0600, Grant Likely wrote:
[..]
+
+ master-num_chipselect = of_num_children(np);
This assumes that there are no gaps in the assigned CS numbers of
child nodes, or that the child nodes are an exhaustive list of
attached devices, neither of which may
On Wed, May 21, 2008 at 10:48 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 06:24:58PM +0200, Guennadi Liakhovetski wrote:
On Wed, 21 May 2008, Anton Vorontsov wrote:
On Wed, May 21, 2008 at 05:56:33PM +0200, Guennadi Liakhovetski wrote:
Hm, I might well
On Wed, May 21, 2008 at 11:05 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 10:50:02AM -0600, Grant Likely wrote:
[..]
+
+ master-num_chipselect = of_num_children(np);
This assumes that there are no gaps in the assigned CS numbers of
child nodes, or that the
On Wed, May 21, 2008 at 9:41 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
Dedicated (usually the ones that need to fill platform data) constructors
will create board info, so SPI core will probe them as normal SPI devices.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
On Wed, May 21, 2008 at 9:41 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
Hi all,
This is just a bait for further discussion of OF/SPI, chip-selects,
e.t.c.
BTW; [EMAIL PROTECTED] should probably be CC'd
on the next posting of this series.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret
Hi,
This is a patch that has been sitting idle for quite some time. I
decided to move it further because it is something useful. It was
originally written by Michel Darneille, based off of 2.6.16.
The original patch, though, was not compatible with the current DABR
logic. DABR's are used to
This patch corrects the names of two CONFIG_ variables.
Note that the CONFIG_MPC86XADS fix uncovers another bug
(with mpc866_ads_defconfig) that will require fixing:
-- snip --
...
arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/mpc866ads.dtb -b 0
On Wed, 21 May 2008, Grant Likely wrote:
I concede that sometimes platform code just has to pass data to the
driver that cannot be described in the device tree. callback pointers
being the most significant example and we do need a sane way to do so.
Sorry, I just cannot understand. So far my
On Fri, 2008-04-18 at 16:44 +1000, Benjamin Herrenschmidt wrote:
so what
about the patch below ?
I like it, but the compiler won't ;)
If you're ok, I'll re-send with appropriate sob
adapted powerpc part.
Sure.
+void __init __attribute__((weak)
Hi
I am trying to enable 1 GB of lowmem on a Freescale 8280.
In arch/ppc this was easilly done by:
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe00
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x4000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xa000
This does not work in
Paul Mackerras wrote:
Benjamin Herrenschmidt writes:
When you do an lmb_add you should probably also do an lmb_analyze to
update the total memory count etc...
That leads to some interesting issues such as the LMB stuff wasn't
really meant to be dynamically modified after boot, and thus
As pointed out by Adrian Bunk.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/boot/wrapper |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d6c96d9..3b59e33 100755
--- a/arch/powerpc/boot/wrapper
On Wed, 21 May 2008 13:56:25 -0400 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
On Fri, 2008-04-18 at 16:44 +1000, Benjamin Herrenschmidt wrote:
so what
about the patch below ?
I like it, but the compiler won't ;)
If you're ok, I'll re-send with appropriate sob
On Sat, May 17, 2008 at 01:36:33PM +0200, Pierre Ossman wrote:
On Fri, 16 May 2008 20:50:57 +0400
Anton Vorontsov [EMAIL PROTECTED] wrote:
Some boards do not use interrupts on the CD line, so we want to poll
the CD and see if there was a change. 1 second poll interval seems
resonable.
Some hosts (and boards that use mmc_spi) do not use interrupts on the CD
line, so they can't trigger mmc_detect_change. We want to poll the card
and see if there was a change. 1 second poll interval seems resonable.
This patch also implements .get_cd() host operation, that could be used
by the
If platform_data lacks init() callback (solely used to request
card-detect interrupt), we mark the host as MMC_CAP_NEEDS_POLL.
get_cd() host operation provided to optimize polling.
p.s. Since mmc_host_ops no longer the same for every instance of
mmc_spi, struct mmc_host_ops can't be const and
On Wed, May 21, 2008 at 11:41:47AM -0700, Andrew Morton wrote:
On Wed, 21 May 2008 13:56:25 -0400 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
On Fri, 2008-04-18 at 16:44 +1000, Benjamin Herrenschmidt wrote:
so what
about the patch below ?
I like it, but the
On Wed, May 21, 2008 at 11:51 AM, Guennadi Liakhovetski
[EMAIL PROTECTED] wrote:
On Wed, 21 May 2008, Grant Likely wrote:
I concede that sometimes platform code just has to pass data to the
driver that cannot be described in the device tree. callback pointers
being the most significant
Ok, elegance apart:-) You can use the SPI-bridge construct to also
describe simple SPI-chipselect configurations. But is it really a good
idea? Wouldn't it be better to handle these two cases separately?
It would be best to handle all these things that are specific to
a certain SPI controller
On Wed, 21 May 2008, Grant Likely wrote:
If some behaviour is entirely board specific and doesn't have any
possibility of being duplicated on other boards, then it makes sense
for the code implementing that behaviour to live with the platform
code.
Exactly - entirely board specific and
On Wed, May 21, 2008 at 1:11 PM, Segher Boessenkool
[EMAIL PROTECTED] wrote:
Ok, elegance apart:-) You can use the SPI-bridge construct to also
describe simple SPI-chipselect configurations. But is it really a good
idea? Wouldn't it be better to handle these two cases separately?
It would be
On Wed, 21 May 2008, Benjamin Herrenschmidt wrote:
Depends on what you define as necessary. It's seem clear that I/O accessors
_no not_ need to be strictly ordered with respect to normal memory accesses,
by what's defined in memory-barriers.txt. So if by necessary you mean what
the Linux
On Wed, May 21, 2008 at 1:20 PM, Guennadi Liakhovetski
[EMAIL PROTECTED] wrote:
On Wed, 21 May 2008, Grant Likely wrote:
If some behaviour is entirely board specific and doesn't have any
possibility of being duplicated on other boards, then it makes sense
for the code implementing that
[EMAIL PROTECTED] wrote:
Hi
I am trying to enable 1 GB of lowmem on a Freescale 8280.
In arch/ppc this was easilly done by:
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe00
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x4000
CONFIG_KERNEL_START_BOOL=y
On Wed, 21 May 2008, Grant Likely wrote:
On Wed, May 21, 2008 at 1:20 PM, Guennadi Liakhovetski
[EMAIL PROTECTED] wrote:
Right again - _rare_ corner cases. Whereas we are talking about _all_ SPI
busses, maybe apart from those, where the controller itself switches CSs
in a well-defined
On Wed, May 21, 2008 at 2:00 PM, Guennadi Liakhovetski
[EMAIL PROTECTED] wrote:
On Wed, 21 May 2008, Grant Likely wrote:
On Wed, May 21, 2008 at 1:20 PM, Guennadi Liakhovetski
[EMAIL PROTECTED] wrote:
Right again - _rare_ corner cases. Whereas we are talking about _all_ SPI
busses, maybe
From memory, I measured lwsync is 5 times faster than eieio on
a dual G5. This was on a simple microbenchmark that made use of
smp_wmb for store ordering, but it did not involve any IO access
(which presumably would disadvantage eieio further).
This is very much specific to your particular
+#ifdef __SUBARCH_HAS_LWSYNC
+#define SMPWMB lwsync
+#else
+#define SMPWMB eieio
+#endif
+
#define smp_mb() mb()
#define smp_rmb() rmb()
-#define smp_wmb() eieio()
+#define smp_wmb() __asm__ __volatile__ (__stringify(SMPWMB) : :
:memory)
SMPWMB is used only
On Wed, 21 May 2008, Andreas Schwab wrote:
Trent Piepho [EMAIL PROTECTED] writes:
On Wed, 21 May 2008, Andreas Schwab wrote:
Trent Piepho [EMAIL PROTECTED] writes:
It's the _le versions that have a problem, since we can't get gcc to just use
the register indexed mode. It seems like an
On Wed, 2008-05-21 at 11:41 -0700, Andrew Morton wrote:
yup, gcc bug. Discussed recently on lkml, Subject: Re: huge gcc
4.1.{0,1} __weak problem. I don't think anything ended up happening
about it though.
Hrm... do you think we should work around ? ie. move the stubs to a
separate .c file
On Wed, 2008-05-21 at 21:06 +0200, Sam Ravnborg wrote:
It was discussed to add some run-time checks for this issue.
But the examples given were a bit fluffy so I never integrated
anything
i kbuild to detect this.
As this is only a bug for const weak functions they could be made
non-const
On Wed, 2008-05-21 at 12:44 -0700, Trent Piepho wrote:
Someone should update memory-barriers.txt, because it doesn't say
that, and
all I/O accessors for all the arches, because none of them are.
There have been long discussions about that. The end result was that
being too weakly ordered is
On Wed, 2008-05-21 at 22:12 +0200, Segher Boessenkool wrote:
No idea about POWER6; for CBE, the backend works similar to the
970 one.
Given that the architecture says to use lwsync for cases like this,
it would be very surprising if it performed (much) worse than eieio,
eh? ;-) So I think
On Wed, 2008-05-21 at 16:24 +1000, Stephen Rothwell wrote:
Compiling ppc64_defconfig with gcc 4.3 gives thes warnings:
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_get_priority':
arch/powerpc/sysdev/mpic.c:1351: warning: 'is_ipi' may be used uninitialized
in this function
This is mostly useless then since lwsync is just a sync to a processor
that doesn't know it (it's a sync with a reservd bit set) :-) Or it's
just to make gas happy if you specify a processor type that doesn't
have
lwsync ?
GAS doesn't care (I tried with -Wa,-m405). Support for this insn
was
Some chips (like the SoCs from Freescale) report the wrong value in NIRQ
and this causes issues if its doesn't match or exceed the value of
irq_count.
Add a flag that board code can set to just use irq_count instead of
FRR[NIRQ]. Eventually we'll add a device tree property with the number
of
Rune Torgersen wrote:
[EMAIL PROTECTED] wrote:
Hi
I am trying to enable 1 GB of lowmem on a Freescale 8280.
In arch/ppc this was easilly done by:
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe00
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x4000
CONFIG_KERNEL_START_BOOL=y
On Wed, 2008-05-21 at 15:59 -0500, Kumar Gala wrote:
Some chips (like the SoCs from Freescale) report the wrong value in NIRQ
and this causes issues if its doesn't match or exceed the value of
irq_count.
Add a flag that board code can set to just use irq_count instead of
FRR[NIRQ].
On Wed, 21 May 2008 15:44:41 -0400
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Wed, 2008-05-21 at 11:41 -0700, Andrew Morton wrote:
yup, gcc bug. Discussed recently on lkml, Subject: Re: huge gcc
4.1.{0,1} __weak problem. I don't think anything ended up happening
about it
On May 21, 2008, at 3:55 PM, Rune Torgersen wrote:
Rune Torgersen wrote:
[EMAIL PROTECTED] wrote:
Hi
I am trying to enable 1 GB of lowmem on a Freescale 8280.
In arch/ppc this was easilly done by:
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe00
CONFIG_LOWMEM_SIZE_BOOL=y
Kumar Gala wrote:
On May 21, 2008, at 3:55 PM, Rune Torgersen wrote:
Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it
works in both vaniulla an d RT kernel.
We should really add some sanity check on CONFIG_TASK_SIZE vs
KERNEL_START.
Something like this?
Wording sould
On Wed, 2008-05-21 at 13:00 -0500, Rune Torgersen wrote:
Hi
I am trying to enable 1 GB of lowmem on a Freescale 8280.
In arch/ppc this was easilly done by:
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe00
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x4000
Two real quick notes.
Take a look at:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/055745.html
and can you try and post the patch inline next time. Hard to provide
review comments on it :)
- k
___
Linuxppc-dev mailing list
I spent a little time getting the new isp1760 driver to work on my ppc64
board with an ISP1761. There were two main problems I encountered:
- Driver wrote to the PORT 1 control register which is actually
the OTG control register on the ISP1761. This needs to be skipped
on ISP1761
This fixes the bogus io mem 0x message printed
during driver init due to hcd-rsrc_start being assigned after
the call to usb_add_hcd().
Signed-off-by: Nate Case [EMAIL PROTECTED]
---
drivers/usb/host/isp1760-hcd.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff
This adds support for hardware configurations that don't match the
chip default register settings (e.g., 16-bit data bus, DACK and
DREQ pulled down instead of up, analog overcurrent mode).
These settings are passed in via the OF device tree. The PCI
interface still assumes the same default
Some chips (like the SoCs from Freescale) report the wrong value in NIRQ
and this causes issues if its doesn't match or exceed the value of
irq_count.
Add a flag that board code can set to just use irq_count instead of
FRR[NIRQ]. Eventually we'll add a device tree property with the number
of
Thanks for the inlining tip. It should be now. :-)
So, basically we are looking at a cleaner and much better interface to
set such hardware features? That's something that would greatly improve
the communication from, say, GDB to the kernel regarding these
facilities.
Regards,
Luis
On Wed,
The main question is do we care if the downgrade to sync on power3
hurts
performances (and does it ?) and what do we do for 32 bits as
currently,
no 32 bits implementation has lwsync afaik (though that might not be
true for long).
Some time ago, I benchmarked (*) a loop of stw;sync vs.
On Wed, May 21, 2008 at 03:57:55PM -0500, Kumar Gala wrote:
Some chips (like the SoCs from Freescale) report the wrong value in NIRQ
and this causes issues if its doesn't match or exceed the value of
irq_count.
Is it really wrong, or just not accounting for the gap between external
and
Roland McGrath wrote:
Ok. That looks like a bug in the older binutils (objcopy) you are using.
It is confused by the empty .rela.dyn section right next to the .dynamic
section. Current binutils don't seem to have a problem with this.
I haven't tried to get an old binutils running to reproduce
On Wed, May 21, 2008 at 10:12:03PM +0200, Segher Boessenkool wrote:
From memory, I measured lwsync is 5 times faster than eieio on
a dual G5. This was on a simple microbenchmark that made use of
smp_wmb for store ordering, but it did not involve any IO access
(which presumably would
On Tue, May 20, 2008 at 09:38:08AM -0700, Remi Machet wrote:
On Tue, 2008-05-20 at 11:13 +1000, David Gibson wrote:
On Mon, May 19, 2008 at 05:00:23PM -0700, Remi Machet wrote:
Support for the C2K cPCI Single Board Computer from GEFanuc
(PowerPC MPC7448 with a Marvell MV64460 chipset)
On May 21, 2008, at 5:11 PM, Scott Wood wrote:
On Wed, May 21, 2008 at 03:57:55PM -0500, Kumar Gala wrote:
Some chips (like the SoCs from Freescale) report the wrong value in
NIRQ
and this causes issues if its doesn't match or exceed the value of
irq_count.
Is it really wrong, or just not
On Friday 16 May 2008, Grant Likely wrote:
This patch splits the allocation and registration portions of code out
of spi_new_device() and creates three new functions; spi_alloc_device(),
spi_register_device(), and spi_device_release().
I have no problem with the first two, but why the last?
On Friday 16 May 2008, Grant Likely wrote:
In my mind; platform_data and the device tree are all about the same
thing: representation. In other words, how to describe the
configuration of the hardware independent of the driver itself.
Platform_data isn't what I'd call independent of drivers.
Luis Machado writes:
This is a patch that has been sitting idle for quite some time. I
decided to move it further because it is something useful. It was
originally written by Michel Darneille, based off of 2.6.16.
The original patch, though, was not compatible with the current DABR
logic.
On May 21, 2008, at 4:24 PM, Rune Torgersen wrote:
Kumar Gala wrote:
On May 21, 2008, at 3:55 PM, Rune Torgersen wrote:
Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it
works in both vaniulla an d RT kernel.
We should really add some sanity check on CONFIG_TASK_SIZE vs
including of asm/mpc85xx.h causes build problems since it doesn't exist.
Also removed warning:
drivers/edac/mpc85xx_edac.c:45: warning: 'mpc85xx_ctl_name' defined but not used
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
This is a fix for 2.6.26.
- k
drivers/edac/mpc85xx_edac.c |3 ---
99 matches
Mail list logo
