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
>>> c
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 har
> 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
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 bar
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 ([EMA
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 cv
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 driv
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 describ
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 define
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 alre
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_w
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 "br
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
include/linux
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 +
arch/powerpc/platforms/86xx/mp
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
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 rec
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 usi
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 +
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 rec
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
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: c00
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
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 thei
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 s
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 har
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 boo
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
> > > ar
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
> Sign
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-
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 w
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 mig
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 node
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]>
> ---
> driver
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.
Sec
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 imple
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
/home/bunk/linux/kernel-2.6/git/linux-2.
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
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__((
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 arch
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,
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 wi
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
> > res
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 hos
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 sho
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 ?
> > > >
> > > >
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 signific
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 (l
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
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 st
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 th
[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
> CONFIG_KERNEL
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 wel
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
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 benc
+#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 obv
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
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-
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
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
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
> arch/p
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 a
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 sour
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_KE
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]. E
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
> >
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
CONFIG_LOWM
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 s
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
> CONFIG_KE
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
Linuxppc-dev@ozlab
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 until
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(-)
dif
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 values
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 sour
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, 2008-
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. "stw;
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 inter
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 di
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 chip
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 la
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
> lo
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
KE
including of 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 ---
1 files ch
> I would think there would be a different REQUEST value to mean "set a
> hardware breakpoint". Roland McGrath (cc'd) might be able to tell us
> what other architectures do.
Other architectures don't give a good model to follow. (If anything,
they just trivally virtualize their own idiosyncratic
98 matches
Mail list logo
