Anton's commit enabling the use of the lwsync fixup mechanism on 64-bit
breaks modules. The lwsync fixup section uses .long instead of the
FTR_ENTRY_OFFSET macro used by other fixups sections, and thus will
generate 32-bit relocations that our module loader cannot resolve.
This changes it to use t
The current setting for SECTION_SIZE_BITS is quite small compared to
everyone else:
arch/powerpc/include/asm/sparsemem.h:#define SECTION_SIZE_BITS 24
arch/sparc/include/asm/sparsemem.h:#define SECTION_SIZE_BITS30
arch/ia64/include/asm/sparsemem.h:#define SECTION_SIZE_BITS (30)
arch/s390
Hi,
A new hcall H_EM_GET_PARMS as been added to obtain power mode data
from the platform. This data can be used by user space administrative
tools for better power management.
The following patch add data from this new hcall into the lparcfg
driver and exports to user space along with other exis
>-Original Message-
>From: Anton Vorontsov [mailto:avoront...@ru.mvista.com]
>Sent: Friday, February 26, 2010 8:45 AM
>To: Paul Gortmaker
>Cc: Martyn Welch; linuxppc-dev list; net...@vger.kernel.org;
>linux-ker...@vger.kernel.org; Kumar Gopalpet-B05799;
>da...@davemloft.net; Kumar Gal
On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
[...]
> I was able to reproduce it on an 8641D and bisected it down to this:
>
> ---
> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
> Author: Anton Vorontsov
> Date: Tue Nov 10 14:11:10 2009 +
>
> gianfar: Reviv
I'm recently porting Linux 2.6.32 to our custom board with MPC8247. We have a
NAND flash connected using GPCM mode of local bus. But after I search
through the Linux
source, there is no compatible like "fsl,gpcm-nand". And I can not
find any driver
that seems works for our scene.
Does Linux 2.6.32
On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
> The 'name' field here is actually a legacy inherited from x86 code. It
> is part of x86's arch-specific hw-breakpoint structure since:
> - inspired by the kprobe implementation which accepts symbol name as
> input.
> - kallsyms_lookup_na
On Thu, Feb 25, 2010 at 12:49 PM, Anton Vorontsov
wrote:
> On Thu, Feb 25, 2010 at 07:51:41PM +0300, Anton Vorontsov wrote:
>> On Thu, Feb 25, 2010 at 04:46:54PM +, Martyn Welch wrote:
>> [...]
>> > > nfs: server 192.168.0.1 not responding, still trying
>> > >
>> >
>> > Further testing has sho
On Thu, Feb 25, 2010 at 06:04:33PM -0600, Scott Wood wrote:
> It's also useful for software events, as well as future support for
> other types of hardware counters.
>
> Signed-off-by: Scott Wood
Acked-by: Paul Mackerras
___
Linuxppc-dev mailing list
This implements perf_event support for the Freescale embedded performance
monitor, based on the existing perf_event.c that supports server/classic
chips.
Some limitations:
- Performance monitor interrupts are regular EE interrupts, and thus you
can't profile places with interrupts disabled. We
Micha Nelissen wrote:
>
> Alexandre Bounine wrote:
> > /**
> > + * rio_em_set_ops- Sets Error Managment operations for a particular
vendor switch
> > + * @rdev: RIO device
> > + *
> > + * Searches the RIO EM ops table for known switch types. If the vid
> > + * and did match a switch table entry,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Commit 0119536c, which added the assembly version of strncmp to
powerpc, mentions that it adds two instructions to the version from
boot/string.S to allow it to handle len=0. Unfortunately, it doesn't
always return 0 when that is the case. The leng
Micha Nelissen wrote:
>
> Alexandre Bounine wrote:
> > + /* Attempt to acquire device lock */
> > + rio_mport_write_config_32(port, destid,
> > + hopcount,
> > +
RIO_HOST_DID_LOCK_CSR,
> > +
por
Micha Nelissen wrote:
> Alexandre Bounine wrote:
> > @@ -369,6 +380,10 @@ static struct rio_dev __devinit *rio_set
> > rdev->rswitch->switchid);
> > rio_route_set_ops(rdev);
> >
> > + if (do_enum && rdev->rswitch->clr_table)
> > + rde
Did you check your power on reset resistor values to make sure the
correct phy management interface is selected?
On Feb 25, 2010, at 1:21 AM, "Hillery, Nathan"
wrote:
> I have a system with an SGMII interface on an MPC8536E, attached to
> a Marvel 88E6152 Ethernet switch chip. I can acc
It's also useful for software events, as well as future support for
other types of hardware counters.
Signed-off-by: Scott Wood
---
arch/powerpc/kernel/Makefile |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
Gary Thomas wrote:
On 02/25/2010 02:24 PM, Scott Wood wrote:
Gary Thomas wrote:
On 02/25/2010 02:03 PM, Scott Wood wrote:
Gary, can you check that the MMIO addresses are going to the PCI bus
as-is, and aren't being translated down to zero? I.e. POTARn should
equal POBARn, and likewise in the
On 02/25/2010 02:24 PM, Scott Wood wrote:
Gary Thomas wrote:
On 02/25/2010 02:03 PM, Scott Wood wrote:
Gary, can you check that the MMIO addresses are going to the PCI bus as-is, and
aren't being translated down to zero? I.e. POTARn should equal POBARn, and
likewise in the device
tree's pci n
On Thu, 2010-02-25 at 15:03 -0600, Scott Wood wrote:
>
> It can, but I don't see how that would help, if the problem is that the
> video card doesn't like the low 30 bits of its MMIO address being zero.
My idea was the video card, if it's an old piece of shit, may not be
decoding all address bit
Gary Thomas wrote:
On 02/25/2010 02:03 PM, Scott Wood wrote:
Gary, can you check that the MMIO addresses are going to the PCI bus
as-is, and aren't being translated down to zero? I.e. POTARn should
equal POBARn, and likewise in the device
tree's pci node's ranges.
Hmm, that doesn't match wit
On 02/25/2010 02:03 PM, Scott Wood wrote:
Benjamin Herrenschmidt wrote:
On Thu, 2010-02-25 at 07:25 -0700, Gary Thomas wrote:
I may have been too hasty pronouncing this fixed. Indeed, the
SATA interface now works, but my video card (Fujitsu Coral-P)
does not work when it's mapped at the bottom
Benjamin Herrenschmidt wrote:
On Thu, 2010-02-25 at 07:25 -0700, Gary Thomas wrote:
I may have been too hasty pronouncing this fixed. Indeed, the
SATA interface now works, but my video card (Fujitsu Coral-P)
does not work when it's mapped at the bottom of the PCI space :-(
With the bridge mapp
Bounine, Alexandre wrote:
Micha Nelissen wrote:
Alexandre Bounine wrote:
/**
+ * rio_em_set_ops- Sets Error Managment operations for a particular
vendor switch
+ * @rdev: RIO device
+ *
+ * Searches the RIO EM ops table for known switch types. If the vid
+ * and did match a switch table entr
On Thu, 2010-02-25 at 07:25 -0700, Gary Thomas wrote:
> I may have been too hasty pronouncing this fixed. Indeed, the
> SATA interface now works, but my video card (Fujitsu Coral-P)
> does not work when it's mapped at the bottom of the PCI space :-(
>
> With the bridge mapped, the video ends up a
I tried building a kernel using mpc85xx_smp_defconfig, but with all
platforms but p4080ds removed. This was the result:
LD .tmp_vmlinux1
sound/built-in.o: In function `claim_dma_lock':
/home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179:
undefined reference to `dma_sp
fsl_dma_update_completed_cookie() appears to calculate the last completed
cookie incorrectly in the corner case where DMA on cookie 1 is in progress
just following a cookie wrap.
Signed-off-by: Steven J. Magnani
---
diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
--- a/drivers/dma/fsldma
fsl_dma_tx_submit() only sets the cookie on the first descriptor of a
transaction. It should set the cookie on all.
Signed-off-by: Steven J. Magnani
---
diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
--- a/drivers/dma/fsldma.c 2010-02-22 11:16:36.0 -0600
+++ b/drivers/dma/f
On Mon, Feb 22, 2010 at 11:40:31AM -0600, Steven J. Magnani wrote:
> fsl_dma_tx_submit() only sets the cookie on the first descriptor of a
> transaction. It should set the cookie on all.
>
> Signed-off-by: Steven J. Magnani
> ---
> diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> --- a/
Bounine, Alexandre wrote:
Hi Micha,
I tested it on my setup - it works.
Maybe Thomas may give more details on this change.
Did you (for fun) try once to decrease the maintenance window to say, 4
kB? Then you really need these "high" bits to work properly.
Or did you try with some register a
On Mon, Feb 22, 2010 at 09:26:13PM +0100, Guennadi Liakhovetski wrote:
> On Mon, 22 Feb 2010, Steven J. Magnani wrote:
>
> > diff -uprN a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > --- a/include/linux/dmaengine.h 2010-02-22 11:18:11.0 -0600
> > +++ b/include/linux/dmaeng
Bounine, Alexandre wrote:
Micha Nelissen wrote:
Alexandre Bounine wrote:
+ mport->host_deviceid = RIO_GET_DID(mport->sys_size,
This fixes something else, should be a separate patch.
This sets an ID used for locking during discovery. On a startup only
enumerator's ID is set to t
On Feb 25, 2010, at 10:46 AM, Martyn Welch wrote:
>
> Further testing has shown that this isn't restricted to warm reboots, it
> happens from cold as well. In addition, the exact timing of the failure
> seems to vary, some boots have got further before failing.
what mechanism do you use for war
Hi Linus,
Here is a bunch of device tree rework. This has also been simmering
in linux-next for a while now. Most of this is merging PowerPC &
Microblaze code with a sprinkling of SPARC changes, although there is
a small bit of minor rework throughout the drivers tree, all pretty
much powerpc sp
On Thu, Feb 25, 2010 at 04:46:54PM +, Martyn Welch wrote:
[...]
> > nfs: server 192.168.0.1 not responding, still trying
> >
>
> Further testing has shown that this isn't restricted to warm reboots, it
> happens from cold as well. In addition, the exact timing of the failure
> seems to vary
Martyn Welch wrote:
> Martyn Welch wrote:
>
>> I have recently attempted to boot an 8641D based board from an NFS root.
>> The boot process grinds to a halt not long after the first access of the
>> NFS root and I receive multiple "nfs: server 192.168.0.1 not responding,
>> still trying" message
On 02/24/2010 04:08 PM, Gary Thomas wrote:
On 02/24/2010 03:25 PM, Kumar Gala wrote:
On Feb 24, 2010, at 4:14 PM, Gary Thomas wrote:
On 02/24/2010 01:51 PM, Anton Vorontsov wrote:
On Wed, Feb 24, 2010 at 02:26:20PM -0600, Scott Wood wrote:
Gary Thomas wrote:
Yes, I'm using the exact same k
Martyn Welch wrote:
> I have recently attempted to boot an 8641D based board from an NFS root.
> The boot process grinds to a halt not long after the first access of the
> NFS root and I receive multiple "nfs: server 192.168.0.1 not responding,
> still trying" messages. Wireshark suggests that ther
37 matches
Mail list logo
