Hi Anton,
On Wed, 8 Dec 2010 16:58:17 +1100 Anton Blanchard wrote:
>
> The popcnt instructions went into binutils relatively recently. As with a
> number of other instructions, create macros and hardcode them.
>
> Signed-off-by: Anton Blanchard
That certainly fixes the build issue for me (test
The popcnt instructions went into binutils relatively recently. As with a
number of other instructions, create macros and hardcode them.
Signed-off-by: Anton Blanchard
---
Index: powerpc.git/arch/powerpc/include/asm/ppc-opcode.h
==
On Sat, Dec 04, 2010 at 09:23:47AM +0100, Heiko Schocher wrote:
> - add binding to OF, compatible name "smi,sm501"
>
> - add read/write functions for using this driver
> also on powerpc plattforms
>
> - add commandline options:
> sm501.fb_mode:
> Specify resolution as "x[-][@]"
> sm501.
On 12/07/2010 10:04 PM, Dave Kleikamp wrote:
On Tue, 2010-12-07 at 14:48 +0800, xufeng zhang wrote:
Hi Dave,
I have a question with the below patch you made before:
powerpc/booke: Add support for advanced debug registers
From: Dave Kleikamp
Based o
On Mon, 2010-12-06 at 15:44 +0100, Guillaume Dargaud wrote:
> Hello all,
>
> > OK, that should be all pretty straight forward, and covered by the
> > material in LDD and similar references. You just need to get your device
> > probed.
>
> I'm not sure what you mean with that term: simply identif
On Tue, 7 Dec 2010 18:24:45 -0500
Mark Mason wrote:
> Scott Wood wrote:
>
> > On Mon, 6 Dec 2010 22:15:54 -0500
> > Mark Mason wrote:
> >
> > > What I found, though, was that the NAND did not inherently assert BUSY
> > > as part of the erase - BUSY was asserted because the driver polled for
>
On Tue, 2010-12-07 at 13:46 +0100, Guillaume Dargaud wrote:
> Michael,
> in your example, when is foo_driver_probe() actually called ?
> It's not being called when I do an insmod.
It should be called when the driver core finds a device that matches
your match table.
When you register your driver
Right now its difficult to see which device is running out of iommu space:
iommu_alloc failed, tbl c0076e096660 vaddr c00768806600 npages 1
Use dev_info() so we get the device name and location:
ipr :00:01.0: iommu_alloc failed, tbl c0076e096660 vaddr
c00768806600 npages 1
Scott Wood wrote:
> On Mon, 6 Dec 2010 22:15:54 -0500
> Mark Mason wrote:
>
> > A few months ago I ran into some performance problems involving
> > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > found a solution for this, which worked well, at least with the
> > hardwar
On Mon, 6 Dec 2010 22:15:54 -0500
Mark Mason wrote:
> A few months ago I ran into some performance problems involving
> UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> found a solution for this, which worked well, at least with the
> hardware I was working with. I suspect t
On 12/01/2010 12:20 PM, Stephen Boyd wrote:
> Definitely for TX since it seems like a redundant loop, but I agree RX
> code has changed. Instead of
>
> If RX buffer full
> Poll for RX buffer full
> Read character from RX buffer
>
> we would have
>
> If RX buffer full
> Read character from RX buffer
David Laight wrote:
> > The problem cropped up when there was a lot of traffic to the NAND
> > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > a video chip that needed constant and prompt attention.
> >
> > What I would see is that, as the writes happened, the erases wo
On Tue, 2010-12-07 at 14:48 +0800, xufeng zhang wrote:
> Hi Dave,
>
> I have a question with the below patch you made before:
>
> powerpc/booke: Add support for advanced debug registers
>
> From: Dave Kleikamp
>
> Based on patches originally written by T
Michael,
in your example, when is foo_driver_probe() actually called ?
It's not being called when I do an insmod.
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
On Tue, 2010-12-07 at 13:41 +0200, Risto Suominen wrote:
> 2010/12/7, Johannes Berg :
> >
> > Right, normally we don't need any special handling since the DT has the
> > right names ... this machine just needs an override for the GPIO names
> > (gpio15/16 rather than the proper detect names).
> >
>
2010/12/7, Johannes Berg :
>
> Right, normally we don't need any special handling since the DT has the
> right names ... this machine just needs an override for the GPIO names
> (gpio15/16 rather than the proper detect names).
>
And setting the active-state manually to 1.
Risto
___
On Tue, 2010-12-07 at 13:27 +0200, Risto Suominen wrote:
> > Can you hack the file I previously pointed out and see if that helps?
> >
> Well, I could try. Actually, I don't own a machine to test with.
Oh, ok... I thought you did.
> So, as far as I can see, you don't have any special handling fo
2010/12/7, Johannes Berg :
>
> Oh, so the change to "gpio1" was intended to be some wildcard?
>
Yes. I know, not very pretty.
>
> Can you hack the file I previously pointed out and see if that helps?
>
Well, I could try. Actually, I don't own a machine to test with.
So, as far as I can see, you do
On Tue, 2010-12-07 at 10:51 +0200, Risto Suominen wrote:
> 2010/12/5, Johannes Berg :
> >
> >> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p15.diff
> >> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p16.diff
> >
> > These patches are odd -- the first one adds something the s
> The problem cropped up when there was a lot of traffic to the NAND
> (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> a video chip that needed constant and prompt attention.
>
> What I would see is that, as the writes happened, the erases would
> wind up batched and issu
2010/12/5, Johannes Berg :
>
>> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p15.diff
>> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p16.diff
>
> These patches are odd -- the first one adds something the second
> removes? Am I supposed to look at the combination?
>
Not real
21 matches
Mail list logo
