On 06/29/2009 09:26 AM, ashish kalra wrote:
Split sata_fsl_softreset() into hard and soft resets to make
error-handling more efficient & device and PMP detection more reliable.
Also includes fix for PMP support, driver tested with Sil3726, Sil4726 &
Exar PMP controllers.
Signed-off-by: Ashish K
Hi ~
Can anybody tell me what the RMO is ?? in the linux kernel.
(arch/powerpc/kernel/prom_init.c)
Through googling and guessing, I found "Read Memory Only" and "Relaxed
Memory Order".
But none of these are not properly understood in the context.
Thanks in advance.
HongWoo.
> Stefan Roese wrote:
> Correct. IIRC, some PATA driver as Pravin already mentioned.
> Cheers,
> Stefan
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 underly
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. None
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 pro
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 co
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 wa
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 c
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
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
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, do
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 w
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?
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 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 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 o
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 09:43 -0400, Tom Burns wrote:
> Hi,
>
> With the default config for the Sequoia board on 2.6.24, calling
> pci_dma_sync_sg_for_cpu() results in executing
> invalidate_dcache_range() in arch/ppc/kernel/misc.S from __dma_sync().
> This OOPses on PPC440 since it tries to call
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
https://lists.ozlabs.or
Use the new unreachable() macro instead of for(;;);
Signed-off-by: David Daney
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: linuxppc-...@ozlabs.org
---
arch/powerpc/include/asm/bug.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/bug.h b
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()' th
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 endless
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
Cc: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/irq.h |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/
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 beyon
* 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
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
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.
> 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, t
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 d
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 1
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: m.
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
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 sata
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 w
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 em
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 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]
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 this,
> -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,
On Thu, Sep 10, 2009 at 8:55 AM, Wolfram Sang wrote:
> The 'fsl5200-clocking'-property was dropped since
> 0d1cde235874b00905bce23f659690d060ebf475. Remove all occurences in dts-files.
>
> Signed-off-by: Wolfram Sang
> Cc: Grant Likely
Looks good to me. I'll pick it up.
g.
> ---
> arch/powe
The 'fsl5200-clocking'-property was dropped since
0d1cde235874b00905bce23f659690d060ebf475. Remove all occurences in dts-files.
Signed-off-by: Wolfram Sang
Cc: Grant Likely
---
arch/powerpc/boot/dts/cm5200.dts |1 -
arch/powerpc/boot/dts/digsy_mtc.dts |1 -
arch/powerpc/boot/dts/li
* 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
>somethin
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
Acked-by: Timur Tabi
I'm generally not qualified t
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
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,
> >
> 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
> 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 ?
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 new
On Wed, Sep 9, 2009 at 11:22 PM, Wolfram Sang 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, finally remove it.
>
>
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, ms
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
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
interrupt
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.
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 sm
54 matches
Mail list logo