On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote:
> > Von: "Michel Dänzer"
> > On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote:
> > > > Von: "Michel Dänzer"
> > > > On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote:
> > > > > Michel Dänzer writes:
> > > > >
> > > > > >
On Mon, 2012-04-16 at 14:13 -0600, Grant Likely wrote:
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c
> b/arch/powerpc/platforms/cell/axon_msi.c
> index d09f3e8..fc9df1a 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -276,9 +276,6
On Wed, 18 Apr 2012, Valentin Ilie wrote:
> Fixed some checkpatch warnings. (review)
> Last patch didn't compile.
>
> Signed-off-by: Valentin Ilie
I'm wondering why you don't address the last 4 warnings and 2 errors from
checkpatch while you are at it...
But, the changes you make here look fi
On Wed, 2012-04-18 at 15:07 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 21:23 +1000, Benjamin Herrenschmidt wrote:
> >
> > Right, we might be able to easily port my old code over by simply making
> > it ppc specific. In radeonfb, it's also used for some thinkpads among
> > others but KMS
On Wed, 2012-04-18 at 09:28 -0500, Kumar Gala wrote:
> On Apr 17, 2012, at 11:42 PM, Anton Blanchard wrote:
>
> >
> > Older versions of gcc had issues with using -maltivec together with
> > -mcpu of a non altivec capable CPU. We work around it by specifying
> > -mcpu=970, but the logic is complic
Huang Changming-R66093 wrote:
> But, I observed the Call Trace, but the partition can be parsed correctly.
> Maybe your patch can fix this Call Trace.
Can you post the call trace?
I think the reason this patch works is because the localbus node is not
already probed by mpc85xx_common_publish_devi
Change the EDAC internal representation to work with non-csrow
based memory controllers.
There are lots of those memory controllers nowadays, and more
are coming. So, the EDAC internal representation needs to be
changed, in order to work with those memory controllers, while
preserving backward com
The number of pages is a dimm property. Move it to the dimm struct.
After this change, it is possible to add sysfs nodes for the DIMM's that
will properly represent the DIMM stick properties, including its size.
A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
the memory co
On Mon, 2012-04-16 at 17:38 -0300, Mauro Carvalho Chehab wrote:
> Kernel kobjects have rigid rules: each container object should be
> dynamically allocated, and can't be allocated into a single kmalloc.
>
> EDAC never obeyed this rule: it has a single malloc function that
> allocates all needed da
On 04/18/2012 09:15 AM, Kumar Gala wrote:
>
> On Apr 17, 2012, at 5:17 PM, Scott Wood wrote:
>
>> On 04/17/2012 04:39 PM, York Sun wrote:
>>> The timebase synchronization is only necessary if we need to reset a
>>> separate core. Currently only KEXEC and CPU hotplug require resetting
>>> a singl
Original-Nachricht
> Datum: Wed, 18 Apr 2012 18:06:36 +0200
> Von: "Michel Dänzer"
> An: Gerhard Pircher
> CC: linuxppc-dev@lists.ozlabs.org, sch...@linux-m68k.org,
> ojordan12...@hotmail.co.uk
> Betreff: Re: PowerPC radeon KMS - is it possible?
> On Mit, 2012-04-18 at 17:49
On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote:
> > Von: "Michel Dänzer"
> > On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote:
> > > Michel Dänzer writes:
> > >
> > > > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote:
> > > >> Michel Dänzer writes:
> > > >>
> > > >>
Original-Nachricht
> Datum: Wed, 18 Apr 2012 17:01:20 +0200
> Von: "Michel Dänzer"
> An: Andreas Schwab
> CC: o jordan , linuxppc-dev@lists.ozlabs.org
> Betreff: Re: PowerPC radeon KMS - is it possible?
> On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote:
> > Michel Dän
Time for which the hrtimer is started for decrementer emulation is calculated
using tb_ticks_per_usec. While hrtimer uses the clockevent for DEC
reprogramming (if needed) and which calculate timebase ticks using the
multiplier and shifter mechanism implemented within clockevent layer. It was
ob
FWIW, I just got a GPU lockup also in PCI mode, but at least it isn't as
fatal (system still up apart from the unusable X display).
radeon :00:10.0: GPU lockup CP stall for more than 1msec
GPU lockup (waiting for 0x0C3C last fence id 0x0C34)
Failed to wait GUI idle while programmin
On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote:
> Michel Dänzer writes:
>
> > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote:
> >> Michel Dänzer writes:
> >>
> >> > Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or
> >> > radeon.test=1? (See commit 52f072c
Michel Dänzer writes:
> On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote:
>> Michel Dänzer writes:
>>
>> > Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or
>> > radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
>>
>> Neither changes anything.
>
>
On Apr 17, 2012, at 11:45 PM, Anton Blanchard wrote:
>
> Add a menu to select various 64-bit CPU targets for gcc. We
> default to -mtune=power7 and if gcc doesn't understand that we
> fallback to -mtune=power4.
>
> Signed-off-by: Anton Blanchard
> ---
Can you add a target for e5500 cpu.
- k
On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote:
> Michel Dänzer writes:
>
> > Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or
> > radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
>
> Neither changes anything.
How small aperture sizes have you t
Michel Dänzer writes:
> Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or
> radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
Neither changes anything.
> You might be able to get more information via netconsole.
This *is* netconsole.
Andreas.
--
Andreas
On Apr 17, 2012, at 11:42 PM, Anton Blanchard wrote:
>
> Older versions of gcc had issues with using -maltivec together with
> -mcpu of a non altivec capable CPU. We work around it by specifying
> -mcpu=970, but the logic is complicated.
>
> In preparation for adding more -mcpu targets, remove
On Apr 17, 2012, at 5:17 PM, Scott Wood wrote:
> On 04/17/2012 04:39 PM, York Sun wrote:
>> The timebase synchronization is only necessary if we need to reset a
>> separate core. Currently only KEXEC and CPU hotplug require resetting
>> a single core. The following code should be in the conditio
Michel Dänzer writes:
> On Mit, 2012-04-18 at 15:22 +0200, Andreas Schwab wrote:
>> Michel Dänzer writes:
>>
>> > You do understand that 'prevent the radeon driver from initializing at
>> > all' means direct rendering won't work at all, even with older Mesa
>> > drivers?
>>
>> Until radeondrm
On Mit, 2012-04-18 at 13:30 +0200, Andreas Schwab wrote:
> Michel Dänzer writes:
> > On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote:
> >> Michel Dänzer writes:
>
> This was a test with agpmode=1:
>
> Linux agpgart interface v0.103
> agpgart-uninorth :00:0b.0: Apple UniNorth 2 chi
On Apr 17, 2012, at 4:39 PM, York Sun wrote:
> The timebase synchronization is only necessary if we need to reset a
> separate core. Currently only KEXEC and CPU hotplug require resetting
> a single core. The following code should be in the condition of
> CONFIG_KEXEC or CONFIG_HOTPLUG_CPU
>
>
On Mit, 2012-04-18 at 21:17 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote:
> > On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2012-04-18 at 10:02 +0200, Michel Dänzer wrote:
> > > >
> > > > > GPU lockup appears to be
On Mit, 2012-04-18 at 15:22 +0200, Andreas Schwab wrote:
> Michel Dänzer writes:
>
> > You do understand that 'prevent the radeon driver from initializing at
> > all' means direct rendering won't work at all, even with older Mesa
> > drivers?
>
> Until radeondrmfb has suspend support, this is w
Michel Dänzer writes:
> You do understand that 'prevent the radeon driver from initializing at
> all' means direct rendering won't work at all, even with older Mesa
> drivers?
Until radeondrmfb has suspend support, this is what I want.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On Mit, 2012-04-18 at 21:19 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-04-18 at 12:44 +0200, Michel Dänzer wrote:
> > On Mit, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote:
> > > On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:
> > > >
> > > > I suspect there's a funda
On Mit, 2012-04-18 at 21:23 +1000, Benjamin Herrenschmidt wrote:
>
> Right, we might be able to easily port my old code over by simply making
> it ppc specific. In radeonfb, it's also used for some thinkpads among
> others but KMS does that with the BIOS on these no ? (ie. D2 state).
KMS doesn't
On Mit, 2012-04-18 at 13:25 +0200, Andreas Schwab wrote:
> Michel Dänzer writes:
>
> > On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote:
> >> Michel Dänzer writes:
> >>
> >> > Not sure it's a good idea to set both of these =y: It will prevent the
> >> > radeon driver from initializing
Em 17-04-2012 18:40, Borislav Petkov escreveu:
> On Tue, Apr 17, 2012 at 04:28:49PM -0300, Mauro Carvalho Chehab wrote:
>> Ok. well, we can either multiply nr_pages by channel_count or to let it
>> clear that this is per channel. I prefer the last option (see the enclosed
>> patch).
>>
@@ -215
Michel Dänzer writes:
> -#define map_page_into_agp(page)
> +#define map_page_into_agp(page) \
> + flush_dcache_range((unsigned long)page_address(page), \
> +(unsigned long)page_address(page) + PAGE_SIZE)
That didn't help.
Andreas.
--
Andreas Schwab, sch...@lin
Remove CONFIG_POWER4_ONLY, the option is badly named and only does two
things:
- It wraps the MMU segment table code. With feature fixups there is
little downside to compiling this in.
- It uses the newer mtocrf instruction in various assembly functions.
Instead of making this a compile opti
Michel Dänzer writes:
> On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote:
>> Michel Dänzer writes:
>>
>> > Probably not (AGP is flaky in general, but in particular with older
>> > UniNorth bridges), but it might be interesting to see some kernel output
>> > from booting without agpmode=
Michel Dänzer writes:
> On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote:
>> Michel Dänzer writes:
>>
>> > Not sure it's a good idea to set both of these =y: It will prevent the
>> > radeon driver from initializing at all by default if radeonfb is active.
>>
>> You can say video=radeon
On Wed, 2012-04-18 at 12:54 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 20:37 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> > > > Benjamin Herrenschmidt writes:
> >
On Wed, 2012-04-18 at 12:44 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote:
> > On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:
> > >
> > > I suspect there's a fundamental design issue with apple bridge in that
> > > the CPU to memory path i
On Wed, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-04-18 at 10:02 +0200, Michel Dänzer wrote:
> > >
> > > > GPU lockup appears to be a common problem with the radeon driver.
> > >
> > > It's what happens whe
On Mit, 2012-04-18 at 20:37 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> > > Benjamin Herrenschmidt writes:
> > >
> > > > Note also that KMS doesn't afaik have the power mana
On Mit, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:
> >
> > I suspect there's a fundamental design issue with apple bridge in that
> > the CPU to memory path isn't coherent at all with the GPU to memory path
> > ie. even vs.
On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> > Benjamin Herrenschmidt writes:
> >
> > > Note also that KMS doesn't afaik have the power management code that
> > > radeonfb has for those old Mac chipsets, so suspend/r
On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt writes:
>
> > Note also that KMS doesn't afaik have the power management code that
> > radeonfb has for those old Mac chipsets, so suspend/resume won't work.
>
> How hard would it be to add it?
The code itself is
On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-04-18 at 10:02 +0200, Michel Dänzer wrote:
> >
> > > GPU lockup appears to be a common problem with the radeon driver.
> >
> > It's what happens when anything goes wrong with the GPU. If it doesn't
> > happen with ag
On Wed, 2012-04-18 at 10:02 +0200, Michel Dänzer wrote:
>
> > GPU lockup appears to be a common problem with the radeon driver.
>
> It's what happens when anything goes wrong with the GPU. If it doesn't
> happen with agpmode=-1, it's probably an AGP related coherency issue.
I had some success h
Fixed some checkpatch warnings. (review)
Last patch didn't compile.
Signed-off-by: Valentin Ilie
---
drivers/ps3/ps3av.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
index a409fa0..636e618 100644
--- a/drivers/ps3/ps3av.
But, I observed the Call Trace, but the partition can be parsed correctly.
Maybe your patch can fix this Call Trace.
Best Regards
Jerry Huang
> -Original Message-
> From: linuxppc-dev-bounces+r66093=freescale@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+r66093=freescale@lists.
On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote:
> Michel Dänzer writes:
>
> > Probably not (AGP is flaky in general, but in particular with older
> > UniNorth bridges), but it might be interesting to see some kernel output
> > from booting without agpmode=-1. If you can't get it via ssh
Michel Dänzer writes:
> Probably not (AGP is flaky in general, but in particular with older
> UniNorth bridges), but it might be interesting to see some kernel output
> from booting without agpmode=-1. If you can't get it via ssh, maybe you
> can via netconsole or so.
While logging into KDE:
ra
On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote:
> Michel Dänzer writes:
>
> > Not sure it's a good idea to set both of these =y: It will prevent the
> > radeon driver from initializing at all by default if radeonfb is active.
>
> You can say video=radeonfb:off.
I know, I'm referring t
Yes, I tested with the latest Linux kernel, with my patch, the NOR and NAND MTD
can work well.
Best Regards
Jerry Huang
> -Original Message-
> From: Tabi Timur-B04825
> Sent: Wednesday, April 18, 2012 2:10 AM
> To: Huang Changming-R66093
> Cc: linuxppc-dev@lists.ozlabs.org; Kumar Gala
>
Benjamin Herrenschmidt writes:
> Note also that KMS doesn't afaik have the power management code that
> radeonfb has for those old Mac chipsets, so suspend/resume won't work.
How hard would it be to add it?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53
Michel Dänzer writes:
> Not sure it's a good idea to set both of these =y: It will prevent the
> radeon driver from initializing at all by default if radeonfb is active.
You can say video=radeonfb:off.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B
53 matches
Mail list logo
