the Blackfin defconfigs refer to an input driver for the PCF8574, not
the I2C client driver
Yup, I am aware of that. With the exception of:
blackfin/configs/PNAV-10_defconfig:773:CONFIG_SENSORS_PCF8574=m
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang
Michael Ellerman reported stack-frame size warnings being produced
for power_check_constraints(), which uses an 8*8 array of u64 and
two 8*8 arrays of unsigned long, which are currently allocated on the
stack, along with some other smaller variables. These arrays come
to 1.5kB on 64-bit or 1kB on
On Thu, 2009-09-10 at 16:28 +1000, Paul Mackerras wrote:
Michael Ellerman reported stack-frame size warnings being produced
for power_check_constraints(), which uses an 8*8 array of u64 and
two 8*8 arrays of unsigned long, which are currently allocated on the
stack, along with some other
On Thu, Sep 10, 2009 at 02:26, Wolfram Sang wrote:
the Blackfin defconfigs refer to an input driver for the PCF8574, not
the I2C client driver
Yup, I am aware of that. With the exception of:
blackfin/configs/PNAV-10_defconfig:773:CONFIG_SENSORS_PCF8574=m
thanks for double checking. i'm not
This patch creates the dts files for each core and splits the devices between
the two cores for P2020RDB.
core0 has memory, L2, i2c, spi, dma1, usb, eth0, eth1, crypto, global-util, pci0
core1 has L2, dma2, eth0, pci1, msi.
MPIC is shared between two cores but each core will protect its
On Wed, 2009-09-09 at 13:43 -0500, Scott Wood wrote:
On Wed, Sep 09, 2009 at 01:16:07PM +0200, Kenneth Johansson wrote:
On Tue, 2009-09-08 at 13:48 +0800, Li Tao-B22598 wrote:
Dear all,
I have a problem in MPC5121 sleep mode. As you know MPC5121 use e300c4
core. When I make the
On Thu, Sep 10, 2009 at 02:27:11PM +0530, Poonam Aggrwal wrote:
This patch creates the dts files for each core and splits the devices between
the two cores for P2020RDB.
core0 has memory, L2, i2c, spi, dma1, usb, eth0, eth1, crypto, global-util,
pci0
core1 has L2, dma2, eth0, pci1, msi.
On Wed, Sep 9, 2009 at 11:22 PM, Wolfram Sang w.s...@pengutronix.de wrote:
The pcf8575-driver in drivers/i2c/chips which just exports its register to
sysfs is superseeded by drivers/gpio/pcf857x.c which properly uses the
gpiolib.
As this driver has been deprecated for more than a year,
Hi Wolfram,
On Wed, 9 Sep 2009 23:22:47 +0200, Wolfram Sang wrote:
continuing the quest to clean up and ultimately remove the drivers/i2c/chips
directory, this patch series removes three drivers for GPIO-expanders which
are
obsoleted and marked as deprecated for more than a year. The newer
This patch removes the documentation file
Documentation/i2c/chips/pcf8575 while there is no documentation under
Documentation/ for the drivers/gpio/pcf857x.c driver. Shouldn't proper
documentation for the pcf857x driver be added to the kernel tree
before the pcf8575 driver is removed ?
I
Not sure about the patch to drivers/gpio/pcf857x.c, as there is no gpio
tree and no maintainer either AFAIK, I guess I shall pick it too?
I'd say so. An Ack from David Brownell would be nice, though.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang
Hi Johansson,
Thanks for your response
在 2009-09-10四的 11:09 +0200，Kenneth Johansson写道：
On Wed, 2009-09-09 at 13:43 -0500, Scott Wood wrote:
On Wed, Sep 09, 2009 at 01:16:07PM +0200, Kenneth Johansson wrote:
On Tue, 2009-09-08 at 13:48 +0800, Li Tao-B22598 wrote:
Dear all,
I
Hi Scott Wood,
Thanks for your response
在 2009-09-09三的 13:43 -0500，Scott Wood写道：
On Wed, Sep 09, 2009 at 01:16:07PM +0200, Kenneth Johansson wrote:
On Tue, 2009-09-08 at 13:48 +0800, Li Tao-B22598 wrote:
Dear all,
I have a problem in MPC5121 sleep mode. As you know MPC5121 use e300c4
Anton Vorontsov wrote:
We'll need ugeth_disable() and ugeth_enable() calls earlier in the
file, so rearrange some code to avoid forward declarations.
The patch doesn't contain any functional changes.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
Acked-by: Timur Tabi
* Scott Wood | 2009-09-09 13:28:57 [-0500]:
That's why you always have an offset of 16 between every internal
interupt source number in the MPC855ERM document and those weired
numbers in the device tree :)
This seems to be a common point of confusion -- we should probably put
something in the
The 'fsl5200-clocking'-property was dropped since
0d1cde235874b00905bce23f659690d060ebf475. Remove all occurences in dts-files.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/boot/dts/cm5200.dts |1 -
On Thu, Sep 10, 2009 at 8:55 AM, Wolfram Sang w.s...@pengutronix.de wrote:
The 'fsl5200-clocking'-property was dropped since
0d1cde235874b00905bce23f659690d060ebf475. Remove all occurences in dts-files.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Grant Likely
-Original Message-
From: Gabriel Paubert [mailto:paub...@iram.es]
Sent: Thursday, September 10, 2009 3:03 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org
Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for each
core in CAMPmode for P2020RDB
On Thu, Sep 10, 2009 at
Li Tao wrote:
Hi Scott Wood,
Thanks for your response
在 2009-09-09三的 13:43 -0500，Scott Wood写道：
The decrementer stops ticking when the core goes to sleep. However, if a
decrementer was already pending (but masked with MSR[EE]) before you
enter sleep mode, it will cause a wakeup.
To avoid
On Thu, Sep 10, 2009 at 08:48:38PM +0530, Aggrwal Poonam-B10812 wrote:
-Original Message-
From: Gabriel Paubert [mailto:paub...@iram.es]
Sent: Thursday, September 10, 2009 3:03 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org
Subject: Re: [PATCH][v1] powerpc/85xx:
Hello,
I'm trying to get a Linux distro such as Debian in the following system
System:
mpc8572ds HW
u-boot programmed on flash memory
vanillia linux installed on sata disk
Restrictions:
i have not apt-get resident on system
I have tried the following ways with no succeful results:
I tried to
On Thu, Sep 10, 2009 at 05:01:53PM +0200, Isaac Gomez Morales wrote:
Hello,
I'm trying to get a Linux distro such as Debian in the following system
System:
mpc8572ds HW
The 8572 does not have classic PowerPC floating point. The Debian
binaries use this, so they cannot run without
Now, I'm writing a DMA driver on powerpc
440gx platform(2.6.26.5), as the only way to set up DMA Controller is
to access it's dcr registers with 'mfdcr' and 'mtdcr'.
I've found some dma code in Linux kernel 2.6.26.5, so I copy the code
u wrote to my driver module directory, and include them, but
Do you have floating point emulation turned on in the kernel?
- k
On Sep 10, 2009, at 10:01 AM, Isaac Gomez Morales wrote:
Hello,
I'm trying to get a Linux distro such as Debian in the following
system
System:
mpc8572ds HW
u-boot programmed on flash memory
vanillia linux installed on
MPC8360 QE UCC ethernet controllers hang when changing link duplex
under a load (a bit of NFS activity is enough).
PHY: m...@e0102120:00 - Link is Up - 1000/Full
sh-3.00# ethtool -s eth0 speed 100 duplex half autoneg off
PHY: m...@e0102120:00 - Link is Down
PHY: m...@e0102120:00 - Link is
Anton Vorontsov wrote:
MPC8360 QE UCC ethernet controllers hang when changing link duplex
under a load (a bit of NFS activity is enough).
PHY: m...@e0102120:00 - Link is Up - 1000/Full
sh-3.00# ethtool -s eth0 speed 100 duplex half autoneg off
PHY: m...@e0102120:00 - Link is Down
PHY:
On Thu, Sep 10, 2009 at 01:04:32PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
MPC8360 QE UCC ethernet controllers hang when changing link duplex
under a load (a bit of NFS activity is enough).
PHY: m...@e0102120:00 - Link is Up - 1000/Full
sh-3.00# ethtool -s eth0 speed 100 duplex
Hi,
Thank you everyone for your help.
I've been looking into the other dma/pci API calls (dma_alloc_coherent,
pci_alloc_consistent). I don't see how either of these return memory
mapped to a TLB with the I bit set to 1 in kernel 2.6.24. In our kernel
code, the only use of the PPC44x_TLB_I
Tom Burns wrote
Hi,
Thank you everyone for your help.
I've been looking into the other dma/pci API calls
(dma_alloc_coherent,
pci_alloc_consistent). I don't see how either of these return memory
mapped to a TLB with the I bit set to 1 in kernel 2.6.24. In our
kernel
code, the only
On Thu, Sep 10, 2009 at 11:40:53PM +0400, Anton Vorontsov wrote:
On Thu, Sep 10, 2009 at 01:04:32PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
MPC8360 QE UCC ethernet controllers hang when changing link duplex
under a load (a bit of NFS activity is enough).
PHY: m...@e0102120:00
MPC8360 QE UCC ethernet controllers hang when changing link duplex
under a load (a bit of NFS activity is enough).
PHY: m...@e0102120:00 - Link is Up - 1000/Full
sh-3.00# ethtool -s eth0 speed 100 duplex half autoneg off
PHY: m...@e0102120:00 - Link is Down
PHY: m...@e0102120:00 - Link is
* Sebastian Andrzej Siewior | 2009-09-10 15:15:44 [+0200]:
* Scott Wood | 2009-09-09 13:28:57 [-0500]:
That's why you always have an offset of 16 between every internal
interupt source number in the MPC855ERM document and those weired
numbers in the device tree :)
something in the dts
Sebastian Andrzej Siewior wrote:
So the split is a FSL thing.
What do you thing about making this clear? Adding into every .dts a
comment right on top or maybe in
Documentation/powerpc/dts-bindings/fsl/?
Add an fsl/mpic.txt binding that describes this and any other
pecularities above and
The OF helpers look like nanodoc but are missing the header. Fix this and a
typo (s/nad/and/) while we are here.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/irq.h |7 ---
1 files changed, 4
Starting with version 4.5, GCC has a new built-in function called
__builtin_unreachable(). The function tells the compiler that control
flow will never reach that point. Currently we trick the compiler by
putting in for(;;); but this has the disadvantage that extra code is
emitted for an
Starting with version 4.5, GCC has a new built-in function
__builtin_unreachable() that can be used in places like the kernel's
BUG() where inline assembly is used to transfer control flow. This
eliminated the need for an endless loop in these places.
The patch adds a new macro 'unreachable()'
Use the new unreachable() macro instead of for(;;);
Signed-off-by: David Daney dda...@caviumnetworks.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: linuxppc-...@ozlabs.org
---
arch/powerpc/include/asm/bug.h |2 +-
1 files changed, 1
On 09/10/2009 04:56 PM, David Daney wrote:
+#ifndef unreachable
+# define unreachable() do { for (;;) ; } while (0)
+#endif
#define unreachable() do { } while (1)
r~
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Wed, 2009-09-09 at 10:10 -0400, Tom Burns wrote:
Hi Mikhail,
Sorry, this DMA code is in a tasklet. Are you suggesting the processor
is in supervisor mode at that time? Calling pci_dma_sync_sg_for_cpu()
from the tasklet context is what generates the OOPS. The entire oops is
as
On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
Hi Tom,
In my case __dma_sync() calls flush_dcache_range() (it's due to
alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of
dcbi - that's the difference as dcbf is not privileged.
What it calls depends on
On Thu, 2009-09-10 at 15:53 -0400, Tom Burns wrote:
Hi,
Thank you everyone for your help.
I've been looking into the other dma/pci API calls (dma_alloc_coherent,
pci_alloc_consistent). I don't see how either of these return memory
mapped to a TLB with the I bit set to 1 in kernel
On Thu, 2009-09-10 at 13:30 -0700, Pravin Bathija wrote:
There is also a patch that was submitted for 440EPX a couple of years
back. The 440EPX SOC causes hangs with Memory Read Multiple (MRM)
commands. Whether MRM is used or not depends on the value of
PCI_CACHE_LINE_SIZE register. I see
On Thu, 2009-09-10 at 11:02 +0530, Sachin Sant wrote:
Steven Rostedt wrote:
Ah, seems the bug happens to be in the module handling. Does the call
back always have .mod_return_to_handler?
Yes. Every time it ends up in .mod_return_to_handler
BTW, do you have CONFIG_IRQSTACK set?
--
Now, I'm writing a DMA driver on powerpc
440gx platform(2.6.26.5), as the only way to set up DMA Controller is
to access it's dcr registers with 'mfdcr' and 'mtdcr'.
I've found some dma code in Linux kernel 2.6.26.5, so I copy the code
u wrote to my driver module directory, and include them, but
Steven Rostedt wrote:
On Thu, 2009-09-10 at 11:02 +0530, Sachin Sant wrote:
Steven Rostedt wrote:
Ah, seems the bug happens to be in the module handling. Does the call
back always have .mod_return_to_handler?
Yes. Every time it ends up in .mod_return_to_handler
BTW,
On Wed, Aug 19, 2009 at 03:00:34PM +1000, Benjamin Herrenschmidt wrote:
This is an attempt at cleaning up a bit the way we handle execute
permission on powerpc. _PAGE_HWEXEC is gone, _PAGE_EXEC is now only
defined by CPUs that can do something with it, and the myriad of
#ifdef's in the I$/D$
On Friday 11 September 2009 04:44:34 Benjamin Herrenschmidt wrote:
On Thu, 2009-09-10 at 13:30 -0700, Pravin Bathija wrote:
There is also a patch that was submitted for 440EPX a couple of years
back. The 440EPX SOC causes hangs with Memory Read Multiple (MRM)
commands. Whether MRM is used
On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
It's already there. See commit:
5ce4b59653b2c2053cd9a011918ac1e4747f24cc
powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
Ok, that's another way to do it. Will catch nasty drivers who
try to write directly rather than clear
On Friday 11 September 2009 07:17:50 Benjamin Herrenschmidt wrote:
On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
It's already there. See commit:
5ce4b59653b2c2053cd9a011918ac1e4747f24cc
powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
Ok, that's another way to do it.
On Fri, Sep 11, 2009 at 12:14:55PM +0800, g r1x wrote:
Now, I'm writing a DMA driver on powerpc
440gx platform(2.6.26.5), as the only way to set up DMA Controller is
to access it's dcr registers with 'mfdcr' and 'mtdcr'.
I've found some dma code in Linux kernel 2.6.26.5, so I copy the code
That code uses dma_mapping_error() with a NULL device, which is
a bad idea :-) The proper fix might be to start using some kind
of pseudo device for all these low level mappings with the
hypervisor but that will be for another day. Since it directly
calls into the low level iommu code, I see no
On Thu, 2009-09-10 at 22:35 -0700, Pravin Bathija wrote:
Thanks Stefan. The whole intention of the patch/hack (or whatever one
might call it :) ) was to avoid rogue drivers from setting
pci_cache_line_size to non-zero value even though the underlying
hardware doesn't support MRM calls.
52 matches
Mail list logo
