Re: PowerPC radeon KMS - is it possible?
On Die, 2012-04-17 at 20:49 +0100, o jordan wrote: I've been trying to get Kernel Mode Setting working on my iBook with Ubuntu 12.04. I can only get it working by forcing PCI mode (agpmode=-1). Setting agpmode=1 or a higher number just results in freezing and a flashing screen. At which point? When radeon KMS initializes, or only when X starts? I've tried the Debian experimental kernel with the same results. I notice with Fedora 16 they also recommend setting agpmode=-1 with a radeon card. So I'm guessing there is no easy fix?? 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. With Userspace Mode Setting there is nolonger any 3D hardware acceleration (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/946677 ) From the Mesa upstream POV, the drivers from the 7.11 branch could be used for this. CONFIG_DRM_RADEON_KMS=y CONFIG_FB_RADEON=y 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. If you want CONFIG_FB_RADEON=y, I'd suggest leaving CONFIG_DRM_RADEON_KMS disabled. KMS can always be enabled at boot time with radeon.modeset=1. CONFIG_FB_ATY128=y CONFIG_FB_ATY=y There's no KMS for pre-Radeon ATI cards yet, so these are not directly related. I'm not sure if CONFIG_AGP_UNINORTH should be compiled as a module or built in. I think it would only need to be built in if the radeon driver was built in, which is not recommended. P.S. The dri-devel list at freedesktop.org might be better for this, at least in addition to linuxppc-dev. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
On Wed, 2012-04-18 at 14:46 +1000, Anton Blanchard wrote: + ALT_FTR_SECTION_END_NESTED_IFCLR((CPU_FTR_PPCAS_ARCH_V2), 487) So if I remember properly, this means you key off if both CPU_FTR_NOEXECUTE and CPU_FTR_NODISRALIGN are clear... is there a point ? You make the patch simpler by only keying on NO_EXECUTE which afaik is a power4 or later only feature no ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
Hi Ben, So if I remember properly, this means you key off if both CPU_FTR_NOEXECUTE and CPU_FTR_NODISRALIGN are clear... is there a point ? You make the patch simpler by only keying on NO_EXECUTE which afaik is a power4 or later only feature no ? Was going to do that, but noticed ARCH_V2 was used elsewhere: arch/powerpc/kernel/sysfs.c: if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2)) I'm ok either way, should I respin to use CPU_FTR_NO_EXECUTE? Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
On Wed, 2012-04-18 at 16:51 +1000, Anton Blanchard wrote: arch/powerpc/kernel/sysfs.c: if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2)) I'm ok either way, should I respin to use CPU_FTR_NO_EXECUTE? Yeah, that sysfs bit will be true if -either- of the two bits is true, which is yet another different logic, better avoid it I think. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Tue, 2012-04-17 at 20:49 +0100, o jordan wrote: Hi list, Firstly let me say thanks for the great work you do!!! I've been trying to get Kernel Mode Setting working on my iBook with Ubuntu 12.04. I can only get it working by forcing PCI mode (agpmode=-1). Setting agpmode=1 or a higher number just results in freezing and a flashing screen. Does anybody know how to get it working fully with agp? 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. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Michel Dänzer mic...@daenzer.net 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 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Benjamin Herrenschmidt b...@kernel.crashing.org 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 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
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
Subject: Re: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds
flash
On Tue, Apr 17, 2012 at 4:15 AM, chang-ming.hu...@freescale.com wrote:
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index e74b7cd..0db3a7e 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -463,6 +463,7 @@ static void __init p1022_ds_setup_arch(void)
static struct of_device_id __initdata p1022_ds_ids[] = {
/* So that the DMA channel nodes can be probed individually: */
{ .compatible = fsl,eloplus-dma, },
+ { .compatible = fsl,p1022-elbc, },
{},
};
Have you actually tested this with an upstream kernel? p1022_ds_ids[] is
broken upstream, so adding a new line won't work.
Take a look at http://patchwork.ozlabs.org/patch/128533/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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 to the default behaviour without any relevant kernel command line options. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Michel Dänzer mic...@daenzer.net 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: radeon :00:10.0: GPU lockup CP stall for more than 10064msec GPU lockup (waiting for 0x03EE last fence id 0x03ED) radeon: wait for empty RBBM fifo failed ! Bad things might happen. Failed to wait GUI idle while programming pipes. Bad things might happen. radeon :00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137 radeon :00:10.0: GPU reset succeed radeon :00:10.0: GPU reset succeed radeon :00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137 radeon :00:10.0: GPU reset succeed radeon: wait for empty RBBM fifo failed ! Bad things might happen. Failed to wait GUI idle while programming pipes. Bad things might happen. After that is is dead. GPU lockup appears to be a common problem with the radeon driver. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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: radeon :00:10.0: GPU lockup CP stall for more than 10064msec GPU lockup (waiting for 0x03EE last fence id 0x03ED) radeon: wait for empty RBBM fifo failed ! Bad things might happen. Failed to wait GUI idle while programming pipes. Bad things might happen. radeon :00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137 radeon :00:10.0: GPU reset succeed radeon :00:10.0: GPU reset succeed radeon :00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137 radeon :00:10.0: GPU reset succeed radeon: wait for empty RBBM fifo failed ! Bad things might happen. Failed to wait GUI idle while programming pipes. Bad things might happen. That's even with agpmode=1? Note that I'm interested in seeing the full dmesg or at least all agp/drm/radeon related messages. After that is is dead. The whole machine? That's probably due to something going wrong (e.g. an MCE) while trying to reset the GPU. I fixed one such problem recently, but it's still not as reliable as on x86 unfortunately. 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
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.ozlabs.org] On
Behalf Of Huang Changming-R66093
Sent: Wednesday, April 18, 2012 3:47 PM
To: Tabi Timur-B04825
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds
flash
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
Subject: Re: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for
p1022ds flash
On Tue, Apr 17, 2012 at 4:15 AM, chang-ming.hu...@freescale.com
wrote:
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index e74b7cd..0db3a7e 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -463,6 +463,7 @@ static void __init p1022_ds_setup_arch(void)
static struct of_device_id __initdata p1022_ds_ids[] = {
/* So that the DMA channel nodes can be probed individually:
*/
{ .compatible = fsl,eloplus-dma, },
+ { .compatible = fsl,p1022-elbc, },
{},
};
Have you actually tested this with an upstream kernel? p1022_ds_ids[]
is broken upstream, so adding a new line won't work.
Take a look at http://patchwork.ozlabs.org/patch/128533/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Drivers: ps3: ps3av.c: fixed checkpatch warnings
Fixed some checkpatch warnings. (review)
Last patch didn't compile.
Signed-off-by: Valentin Ilie valentin.i...@gmail.com
---
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.c
+++ b/drivers/ps3/ps3av.c
@@ -338,7 +338,7 @@ int ps3av_do_pkt(u32 cid, u16 send_len, size_t usr_buf_size,
mutex_unlock(ps3av-mutex);
return 0;
- err:
+err:
mutex_unlock(ps3av-mutex);
printk(KERN_ERR %s: failed cid:%x res:%d\n, __func__, cid, res);
return res;
@@ -477,7 +477,6 @@ int ps3av_set_audio_mode(u32 ch, u32 fs, u32 word_bits, u32
format, u32 source)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_audio_mode);
static int ps3av_set_videomode(void)
@@ -870,21 +869,18 @@ int ps3av_set_video_mode(int id)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_video_mode);
int ps3av_get_auto_mode(void)
{
return ps3av_auto_videomode(ps3av-av_hw_conf);
}
-
EXPORT_SYMBOL_GPL(ps3av_get_auto_mode);
int ps3av_get_mode(void)
{
return ps3av ? ps3av-ps3av_mode : 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_get_mode);
/* get resolution by video_mode */
@@ -902,7 +898,6 @@ int ps3av_video_mode2res(u32 id, u32 *xres, u32 *yres)
*yres = video_mode_table[id].y;
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mode2res);
/* mute */
@@ -911,7 +906,6 @@ int ps3av_video_mute(int mute)
return ps3av_set_av_video_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mute);
/* mute analog output only */
@@ -935,7 +929,6 @@ int ps3av_audio_mute(int mute)
return ps3av_set_audio_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_audio_mute);
static int __devinit ps3av_probe(struct ps3_system_bus_device *dev)
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 hacking the DRM to do an in_le32 from the ring head after writing it. Just a gross hack but it seemed to help on a G5. 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. cache flush instructions (ie buffers in the memory controllers can still be out of sync). Darwin does some gross hacks to work around that, some of them visible in the AGP drivers, some burried in the Apple driver, I don't know for sure. It's possible that they end up mapping all AGP memory as cache inhibited, but we can't do that because of our linear mapping. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 agpmode=-1, it's probably an AGP related coherency issue. I had some success hacking the DRM to do an in_le32 from the ring head after writing it. Just a gross hack but it seemed to help on a G5. AFAICT radeon_ring_commit() does that already: DRM_MEMORYBARRIER(); WREG32(ring-wptr_reg, (ring-wptr ring-ptr_reg_shift) ring-ptr_reg_mask); (void)RREG32(ring-wptr_reg); We added the readback about a decade ago. :) 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. cache flush instructions (ie buffers in the memory controllers can still be out of sync). Darwin does some gross hacks to work around that, some of them visible in the AGP drivers, some burried in the Apple driver, I don't know for sure. It's possible that they end up mapping all AGP memory as cache inhibited, but we can't do that because of our linear mapping. We are doing that though... -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote: Benjamin Herrenschmidt b...@kernel.crashing.org 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 relatively self contained, but the KMS power management side is a bit ... messy :-) So the real deal is to figure out how best to hook it up there. There's some duplication Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 b...@kernel.crashing.org 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 relatively self contained, but the KMS power management side is a bit ... messy :-) So the real deal is to figure out how best to hook it up there. There's some duplication Argh... bloody x220 touchpad... So I was saying, there's also some duplication in the area of dynamic clocks configuration. Some of this could be an issue as afaik, to work reliably, the suspend/resume code really wants the stuff to be setup exactly the way the code in radeon_pm does But it's definitely worth trying to port it over. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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. cache flush instructions (ie buffers in the memory controllers can still be out of sync). Darwin does some gross hacks to work around that, some of them visible in the AGP drivers, some burried in the Apple driver, I don't know for sure. It's possible that they end up mapping all AGP memory as cache inhibited, but we can't do that because of our linear mapping. We are doing that though... This reminded me, I've been running with the patch below, but I'm not sure it makes any difference. Maybe Andreas or Jordan can try it. diff --git a/arch/powerpc/include/asm/agp.h b/arch/powerpc/include/asm/agp.h index 416e12c..eb34fa5 100644 --- a/arch/powerpc/include/asm/agp.h +++ b/arch/powerpc/include/asm/agp.h @@ -2,9 +2,12 @@ #define _ASM_POWERPC_AGP_H #ifdef __KERNEL__ +#include asm/cacheflush.h #include asm/io.h -#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) #define unmap_page_from_agp(page) #define flush_agp_cache() mb() -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 b...@kernel.crashing.org 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 relatively self contained, but the KMS power management side is a bit ... messy :-) That's an interesting way to put it, given the hacks to make it work between radeonfb and uninorth_agp. :) (Which are complicating making at least hibernation work with KMS on uninorth_agp) In contrast, radeon KMS uses the standard Linux device suspend/resume hooks. So the real deal is to figure out how best to hook it up there. There's some duplication Argh... bloody x220 touchpad... So I was saying, there's also some duplication in the area of dynamic clocks configuration. Some of this could be an issue as afaik, to work reliably, the suspend/resume code really wants the stuff to be setup exactly the way the code in radeon_pm does Are you referring to radeon_pm in radeonfb or radeon KMS? Most of the latter isn't used on PPC laptops because it relies on an x86 video BIOS. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 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 hacking the DRM to do an in_le32 from the ring head
after writing it. Just a gross hack but it seemed to help on a G5.
AFAICT radeon_ring_commit() does that already:
DRM_MEMORYBARRIER();
WREG32(ring-wptr_reg, (ring-wptr ring-ptr_reg_shift)
ring-ptr_reg_mask);
(void)RREG32(ring-wptr_reg);
We added the readback about a decade ago. :)
Hrm, I have a different hack in that old tree I was playing with a while
back, let me see...
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -2245,6 +2245,9 @@ void radeon_commit_ring(drm_radeon_private_t
*dev_priv)
DRM_MEMORYBARRIER();
GET_RING_HEAD( dev_priv );
+#ifdef CONFIG_PPC
+ in_be32(dev_priv-ring.start);
+#endif
if ((dev_priv-flags RADEON_FAMILY_MASK) = CHIP_R600) {
I think that my rational was to ensure that all previous stores to
AGP (indirect buffers etc...) were pushed out ordered vs the ring
wptr update or something like that, bcs I think those path aren't well
ordered in HW. In fact I suspect we might even need a bigger hammer than
that in_be32().
Another hack I had around was removing the SBA reset from agp-uninorth
completely on binding new pages, it seemed to cause hangs.
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. cache flush instructions (ie buffers in the memory
controllers can still be out of sync).
Darwin does some gross hacks to work around that, some of them visible
in the AGP drivers, some burried in the Apple driver, I don't know for
sure. It's possible that they end up mapping all AGP memory as cache
inhibited, but we can't do that because of our linear mapping.
We are doing that though...
Are we really ? I thought we were taking existing cachable RAM objects
and mapping them into the AGP gart. Are we replacing both kernel user
mappings for those objects with an equivalent cache inhibited mapping ?
I'm not -that- familiar with how ttm works here. In any case it can
cause bus checkstops because the same pages can be prefetched into the
cache via the linear mapping which is covered by BATs (unless you make
your graphic objects HIGHMEM only but good luck with that :-)
To make that work reliably we should disable the BAT mapping so the
linear mapping can then be controlled on a per-page basis (on 32-bit)
and this is complicated we have code that more/less relies on the
BAT mapping being there elsewhere. On 64-bit it's even nastier because
we use 16M pages for the linear mapping.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 isn't coherent at all with the GPU to memory path ie. even vs. cache flush instructions (ie buffers in the memory controllers can still be out of sync). Darwin does some gross hacks to work around that, some of them visible in the AGP drivers, some burried in the Apple driver, I don't know for sure. It's possible that they end up mapping all AGP memory as cache inhibited, but we can't do that because of our linear mapping. We are doing that though... This reminded me, I've been running with the patch below, but I'm not sure it makes any difference. Maybe Andreas or Jordan can try it. It certainly is something we need to do, provided we also know there will be no subsequent access to that page via a cachable mapping until it's removed from AGP. Cheers, Ben. diff --git a/arch/powerpc/include/asm/agp.h b/arch/powerpc/include/asm/agp.h index 416e12c..eb34fa5 100644 --- a/arch/powerpc/include/asm/agp.h +++ b/arch/powerpc/include/asm/agp.h @@ -2,9 +2,12 @@ #define _ASM_POWERPC_AGP_H #ifdef __KERNEL__ +#include asm/cacheflush.h #include asm/io.h -#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) #define unmap_page_from_agp(page) #define flush_agp_cache() mb() ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 b...@kernel.crashing.org 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 relatively self contained, but the KMS power management side is a bit ... messy :-) That's an interesting way to put it, given the hacks to make it work between radeonfb and uninorth_agp. :) (Which are complicating making at least hibernation work with KMS on uninorth_agp) Oh, I forgot about the AGP hooks indeed... but even that, it's in arch code so it's not necessarily a huge deal to move it over. IE. It's just a function pointer to call at the right time that's exported by the arch. In contrast, radeon KMS uses the standard Linux device suspend/resume hooks. Well, as radeonfb does. The hack with AGP is so that radeonfb gets to control when the AGP is suspended/restored as it needs to be done in a specific order and the device model doesn't provide the right ordering (they are sibling devices). There's also an early-wakeup hack but that's orthogonal, it's mostly useful for debugging and doesn't necessarily need to be ported over. Argh... bloody x220 touchpad... So I was saying, there's also some duplication in the area of dynamic clocks configuration. Some of this could be an issue as afaik, to work reliably, the suspend/resume code really wants the stuff to be setup exactly the way the code in radeon_pm does Are you referring to radeon_pm in radeonfb or radeon KMS? radeonfb. Most of the latter isn't used on PPC laptops because it relies on an x86 video BIOS. 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). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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 to the default behaviour without any relevant kernel command line options. Which is exactly the right behaviour for me. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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: radeon :00:10.0: GPU lockup CP stall for more than 10064msec GPU lockup (waiting for 0x03EE last fence id 0x03ED) radeon: wait for empty RBBM fifo failed ! Bad things might happen. Failed to wait GUI idle while programming pipes. Bad things might happen. radeon :00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137 radeon :00:10.0: GPU reset succeed radeon :00:10.0: GPU reset succeed radeon :00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137 radeon :00:10.0: GPU reset succeed radeon: wait for empty RBBM fifo failed ! Bad things might happen. Failed to wait GUI idle while programming pipes. Bad things might happen. That's even with agpmode=1? Yes. Note that I get pretty far into the login process until the lockup happens. Note that I'm interested in seeing the full dmesg or at least all agp/drm/radeon related messages. This was a test with agpmode=1: Linux agpgart interface v0.103 agpgart-uninorth :00:0b.0: Apple UniNorth 2 chipset agpgart-uninorth :00:0b.0: configuring for size idx: 64 agpgart-uninorth :00:0b.0: AGP aperture is 256M @ 0x0 [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. radeon :00:10.0: enabling device (0006 - 0007) [drm] initializing kernel modesetting (RV350 0x1002:0x4E56 0x1002:0x4E56). [drm] register mmio base: 0x9000 [drm] register mmio size: 65536 radeon :00:10.0: Invalid ROM contents radeon :00:10.0: Invalid ROM contents [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM [drm] Using device-tree clock info [drm] AGP mode requested: 1 agpgart-uninorth :00:0b.0: putting AGP V2 device into 1x mode radeon :00:10.0: putting AGP V2 device into 1x mode radeon :00:10.0: GTT: 256M 0x - 0x0FFF [drm] Generation 2 PCI interface, using max accessible memory radeon :00:10.0: VRAM: 128M 0x9800 - 0x9FFF (32M used) [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 384080 kiB [TTM] Zone highmem: Available graphics memory: 515152 kiB [TTM] Initializing pool allocator [drm] radeon: 32M of VRAM memory ready [drm] radeon: 256M of GTT memory ready. [drm] radeon: ib pool ready. [drm] radeon: 1 quad pipes, 1 Z pipes initialized. radeon :00:10.0: WB disabled [drm] fence driver on ring 0 use gpu addr 0x and cpu addr 0xf1086000 [drm] Loading R300 Microcode [drm] radeon: ring at 0x1000 [drm] ring test succeeded in 2 usecs [drm] ib test succeeded in 0 usecs [drm] Connector Table: 2 (ibook) [drm] No panel info found in BIOS [drm] Panel info derived from registers [drm] Panel Size 1024x768 [drm] radeon legacy LVDS backlight initialized [drm] No TV DAC info found in BIOS After that is is dead. The whole machine? No pings any more. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
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 option just do it at runtime via a feature fixup. Signed-off-by: Anton Blanchard an...@samba.org --- v2: Use CPU_FTR_NOEXECUTE to select the newer mtocrf Index: linux-build/arch/powerpc/configs/g5_defconfig === --- linux-build.orig/arch/powerpc/configs/g5_defconfig 2012-04-18 22:12:59.292790202 +1000 +++ linux-build/arch/powerpc/configs/g5_defconfig 2012-04-18 22:13:13.029035714 +1000 @@ -1,5 +1,4 @@ CONFIG_PPC64=y -CONFIG_POWER4_ONLY=y CONFIG_ALTIVEC=y CONFIG_SMP=y CONFIG_NR_CPUS=4 Index: linux-build/arch/powerpc/configs/maple_defconfig === --- linux-build.orig/arch/powerpc/configs/maple_defconfig 2012-04-18 22:12:59.264789702 +1000 +++ linux-build/arch/powerpc/configs/maple_defconfig2012-04-18 22:13:13.029035714 +1000 @@ -1,5 +1,4 @@ CONFIG_PPC64=y -CONFIG_POWER4_ONLY=y CONFIG_SMP=y CONFIG_NR_CPUS=4 CONFIG_EXPERIMENTAL=y Index: linux-build/arch/powerpc/configs/pasemi_defconfig === --- linux-build.orig/arch/powerpc/configs/pasemi_defconfig 2012-04-18 22:12:59.280789988 +1000 +++ linux-build/arch/powerpc/configs/pasemi_defconfig 2012-04-18 22:13:13.029035714 +1000 @@ -1,5 +1,4 @@ CONFIG_PPC64=y -CONFIG_POWER4_ONLY=y CONFIG_ALTIVEC=y # CONFIG_VIRT_CPU_ACCOUNTING is not set CONFIG_SMP=y Index: linux-build/arch/powerpc/kernel/exceptions-64s.S === --- linux-build.orig/arch/powerpc/kernel/exceptions-64s.S 2012-04-18 22:12:59.252789487 +1000 +++ linux-build/arch/powerpc/kernel/exceptions-64s.S2012-04-18 22:13:13.029035714 +1000 @@ -94,12 +94,10 @@ machine_check_pSeries_1: data_access_pSeries: HMT_MEDIUM SET_SCRATCH0(r13) -#ifndef CONFIG_POWER4_ONLY BEGIN_FTR_SECTION b data_access_check_stab data_access_not_stab: END_MMU_FTR_SECTION_IFCLR(MMU_FTR_SLB) -#endif EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, data_access_common, EXC_STD, KVMTEST, 0x300) @@ -301,7 +299,6 @@ machine_check_fwnmi: EXC_STD, KVMTEST, 0x200) KVM_HANDLER_SKIP(PACA_EXMC, EXC_STD, 0x200) -#ifndef CONFIG_POWER4_ONLY /* moved from 0x300 */ data_access_check_stab: GET_PACA(r13) @@ -328,7 +325,6 @@ do_stab_bolted_pSeries: GET_SCRATCH0(r10) std r10,PACA_EXSLB+EX_R13(r13) EXCEPTION_PROLOG_PSERIES_1(.do_stab_bolted, EXC_STD) -#endif /* CONFIG_POWER4_ONLY */ KVM_HANDLER_SKIP(PACA_EXGEN, EXC_STD, 0x300) KVM_HANDLER_SKIP(PACA_EXSLB, EXC_STD, 0x380) Index: linux-build/arch/powerpc/platforms/Kconfig.cputype === --- linux-build.orig/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 22:12:59.312790560 +1000 +++ linux-build/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 22:13:13.029035714 +1000 @@ -116,15 +116,6 @@ config PPC_BOOK3E def_bool y depends on PPC_BOOK3E_64 -config POWER4_ONLY - bool Optimize for POWER4 - depends on PPC64 PPC_BOOK3S - default n - ---help--- - Cause the compiler to optimize for POWER4/POWER5/PPC970 processors. - The resulting binary will not work on POWER3 or RS64 processors - when compiled with binutils 2.15 or later. - config 6xx def_bool y depends on PPC32 PPC_BOOK3S Index: linux-build/arch/powerpc/include/asm/asm-compat.h === --- linux-build.orig/arch/powerpc/include/asm/asm-compat.h 2012-04-18 22:12:59.236789201 +1000 +++ linux-build/arch/powerpc/include/asm/asm-compat.h 2012-04-18 22:13:13.033035785 +1000 @@ -29,18 +29,9 @@ #define PPC_LLARX(t, a, b, eh) PPC_LDARX(t, a, b, eh) #define PPC_STLCX stringify_in_c(stdcx.) #define PPC_CNTLZL stringify_in_c(cntlzd) +#define PPC_MTOCRF(FXM, RS) MTOCRF((FXM), (RS)) #define PPC_LR_STKOFF 16 #define PPC_MIN_STKFRM 112 - -/* Move to CR, single-entry optimized version. Only available - * on POWER4 and later. - */ -#ifdef CONFIG_POWER4_ONLY -#define PPC_MTOCRF stringify_in_c(mtocrf) -#else -#define PPC_MTOCRF stringify_in_c(mtcrf) -#endif - #else /* 32-bit */ /* operations for longs and pointers */ Index: linux-build/arch/powerpc/lib/copyuser_64.S === --- linux-build.orig/arch/powerpc/lib/copyuser_64.S 2012-04-18 22:12:59.180788200 +1000 +++ linux-build/arch/powerpc/lib/copyuser_64.S 2012-04-18
Re: PowerPC radeon KMS - is it possible?
Michel Dänzer mic...@daenzer.net 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...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
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).
@@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
int i, j, empty = 1;
enum mem_type mtype;
enum edac_type edac_mode;
+ int nr_pages;
amd64_read_pci_cfg(pvt-F3, NBCFG, val);
@@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
i, pvt-mc_node_id);
empty = 0;
- csrow-nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
+ nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
get_cs_base_and_mask(pvt, i, 0, base, mask);
/* 8 bytes of resolution */
mtype = amd64_determine_memory_type(pvt, i);
debugf1( for MC node %d csrow %d:\n, pvt-mc_node_id, i);
- debugf1(nr_pages: %u\n, csrow-nr_pages);
+ debugf1(nr_pages: %u\n, nr_pages);
/*
* determine whether CHIPKILL or JUST ECC or NO ECC is operating
@@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
for (j = 0; j pvt-channel_count; j++) {
csrow-channels[j].dimm-mtype = mtype;
csrow-channels[j].dimm-edac_mode = edac_mode;
+ csrow-channels[j].dimm-nr_pages = nr_pages;
I'm guessing you want to accumulate the nr_pages for all channels here
and dump it properly?
As you've requested to not move the debugf0() to be after the loop, it is
easier to just multiply it at the printk. As an advantage, when the kernel
is compiled without debug, no code will be produced.
IMO, the best way to solve it is with this small patch. If you're ok, I'll
fold it with this one and add your ack.
Regards,
Mauro
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 8804ac8..6d6ec68 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2127,7 +2127,7 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt,
u8 dct, int csrow_nr)
nr_pages = pvt-ops-dbam_to_cs(pvt, dct, cs_mode) (20 - PAGE_SHIFT);
debugf0( (csrow=%d) DBAM map index= %d\n, csrow_nr, cs_mode);
-debugf0(nr_pages= %u channel-count = %d\n,
+debugf0(nr_pages/channel= %u channel-count = %d\n,
nr_pages, pvt-channel_count);
return nr_pages;
@@ -2176,7 +2176,7 @@ static int init_csrows(struct mem_ctl_info *mci)
mtype = amd64_determine_memory_type(pvt, i);
debugf1( for MC node %d csrow %d:\n, pvt-mc_node_id, i);
-debugf1(nr_pages: %u\n, nr_pages);
+debugf1(nr_pages: %u\n, nr_pages * pvt-channel_count);
/*
* determine whether CHIPKILL or JUST ECC or NO ECC is operating
Yeah, this is basically what the code did anyway, so yes, please fold it
in and you can add my ACK. I'll continue reviewing the rest tomorrow.
Thanks!
Mauro
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 13:25 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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 to the default behaviour without any relevant kernel command line options. Which is exactly the right behaviour for me. 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? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 have any non-BIOS suspend/resume code yet, so it's either that or no suspend/resume. :) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 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. cache flush instructions (ie buffers in the memory controllers can still be out of sync). Darwin does some gross hacks to work around that, some of them visible in the AGP drivers, some burried in the Apple driver, I don't know for sure. It's possible that they end up mapping all AGP memory as cache inhibited, but we can't do that because of our linear mapping. We are doing that though... This reminded me, I've been running with the patch below, but I'm not sure it makes any difference. Maybe Andreas or Jordan can try it. It certainly is something we need to do, provided we also know there will be no subsequent access to that page via a cachable mapping until it's removed from AGP. TTM should take care of that. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Michel Dänzer mic...@daenzer.net 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 fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 15:22 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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. Then you could disable CONFIG_DRM_RADEON, or prevent the radeon module from loading. *shrug* -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 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 hacking the DRM to do an in_le32 from the ring head
after writing it. Just a gross hack but it seemed to help on a G5.
AFAICT radeon_ring_commit() does that already:
DRM_MEMORYBARRIER();
WREG32(ring-wptr_reg, (ring-wptr ring-ptr_reg_shift)
ring-ptr_reg_mask);
(void)RREG32(ring-wptr_reg);
We added the readback about a decade ago. :)
Hrm, I have a different hack in that old tree I was playing with a while
back, let me see...
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
Note that radeon_cp.c is UMS code, for KMS you need to look at
radeon_ring.c.
@@ -2245,6 +2245,9 @@ void radeon_commit_ring(drm_radeon_private_t
*dev_priv)
DRM_MEMORYBARRIER();
GET_RING_HEAD( dev_priv );
+#ifdef CONFIG_PPC
+ in_be32(dev_priv-ring.start);
+#endif
if ((dev_priv-flags RADEON_FAMILY_MASK) = CHIP_R600) {
I think that my rational was to ensure that all previous stores to
AGP (indirect buffers etc...) were pushed out ordered vs the ring
wptr update or something like that, bcs I think those path aren't well
ordered in HW. In fact I suspect we might even need a bigger hammer than
that in_be32().
Probably wouldn't hurt trying something like that in the KMS code as
well.
Another hack I had around was removing the SBA reset from agp-uninorth
completely on binding new pages, it seemed to cause hangs.
You mean like commit 5613beb46d54da6ef7f1c4589e9f2e60eeb10721? :)
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. cache flush instructions (ie buffers in the memory
controllers can still be out of sync).
Darwin does some gross hacks to work around that, some of them visible
in the AGP drivers, some burried in the Apple driver, I don't know for
sure. It's possible that they end up mapping all AGP memory as cache
inhibited, but we can't do that because of our linear mapping.
We are doing that though...
Are we really ? I thought we were taking existing cachable RAM objects
and mapping them into the AGP gart.
No, the radeon driver has always mapped memory uncacheable to the CPU
while it's bound into the AGP GART.
Are we replacing both kernel user mappings for those objects with an
equivalent cache inhibited mapping ?
I'm not -that- familiar with how ttm works here.
I'm hardly more familiar with how it all works than you. :)
In any case it can cause bus checkstops because the same pages can be
prefetched into the cache via the linear mapping which is covered by
BATs
So you've been saying for about a decade. :) But I've never seen any
problems tracked down to that.
(unless you make your graphic objects HIGHMEM only but good luck with
that :-)
FWIW I think TTM indeed prefers highmem pages for GPU access. The radeon
driver normally doesn't need kernel mappings for them.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Add back condition for smp
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
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
This doesn't explain why you are putting the #ifdef back, only under what
conditions it applies.
Signed-off-by: York Sun york...@freescale.com
Acked-by: Li Yang le...@freescale.com
---
arch/powerpc/platforms/85xx/smp.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 56942af..868c6d7 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -192,8 +192,10 @@ struct smp_ops_t smp_85xx_ops = {
.cpu_disable= generic_cpu_disable,
.cpu_die= generic_cpu_die,
#endif
+#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
+#endif
};
#ifdef CONFIG_KEXEC
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 13:30 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: This was a test with agpmode=1: Linux agpgart interface v0.103 agpgart-uninorth :00:0b.0: Apple UniNorth 2 chipset agpgart-uninorth :00:0b.0: configuring for size idx: 64 agpgart-uninorth :00:0b.0: AGP aperture is 256M @ 0x0 Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c) After that is is dead. The whole machine? No pings any more. You might be able to get more information via netconsole. That's how I tracked down and fixed one cause of MCEs during the GPU reset. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 15:22 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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. Then you could disable CONFIG_DRM_RADEON, or prevent the radeon module from loading. *shrug* I have it built-in for easier testing. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Add back condition for smp
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 condition of
CONFIG_KEXEC or CONFIG_HOTPLUG_CPU
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
Signed-off-by: York Sun york...@freescale.com
Acked-by: Li Yang le...@freescale.com
---
arch/powerpc/platforms/85xx/smp.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 56942af..868c6d7 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -192,8 +192,10 @@ struct smp_ops_t smp_85xx_ops = {
.cpu_disable= generic_cpu_disable,
.cpu_die= generic_cpu_die,
#endif
+#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
+#endif
};
#ifdef CONFIG_KEXEC
Note that this is only a temporary fix, that assumes the environments
where tbsync is problematic[1] (virtualization and simulation) do not
enable CONFIG_KEXEC or CONFIG_HOTPLUG_CPU. Eventually the sync should
be done via CCSR like in U-Boot, and the decision on whether to do it
should be runtime.
Is the thinking with the CCSR like u-boot sync after boot would resync to some
non-zero TB value?
I'm guessing the idea is doing such a rsync w/TB stopped in the system is quick
enough that the freezing of it will not be noticed. One should measure this
and see what it looks like in core cycles and how it scales based on # of
cores. (could use alternate TB as a counter to measure).
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc: Require gcc 4.0 on 64-bit
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 the workaround and just require gcc 4.0 for 64-bit builds. Signed-off-by: Anton Blanchard an...@samba.org --- 4.0 came out in 2005 and the gcc on RHEL5 and SLES10 looks to be 4.1. I highly doubt a ppc64 kernel will build these days on either RHEL4 or SLES9. Anything else we have to worry about? There are probably embedded customers that might utilize older compilers, so this concerns me a little. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Michel Dänzer mic...@daenzer.net 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 Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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 tried? The purpose of radeon.test=1 isn't to change anything but to catch problems transferring data between system memory bound via AGP GART and video RAM. Does it pass for the whole AGP aperture? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] powerpc: Add 64-bit CPU targets for gcc
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 an...@samba.org --- Can you add a target for e5500 cpu. - k Index: linux-build/arch/powerpc/Makefile === --- linux-build.orig/arch/powerpc/Makefile2012-04-18 14:31:31.614666419 +1000 +++ linux-build/arch/powerpc/Makefile 2012-04-18 14:37:08.680708678 +1000 @@ -69,6 +69,16 @@ LDFLAGS_vmlinux:= $(LDFLAGS_vmlinux-y) CFLAGS-$(CONFIG_PPC64):= -mminimal-toc -mtraceback=no -mcall-aixdesc CFLAGS-$(CONFIG_PPC32):= -ffixed-r2 -mmultiple + +CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,-mtune=power4) +CFLAGS-$(CONFIG_CELL_CPU) += $(call cc-option,-mcpu=cell) +CFLAGS-$(CONFIG_POWER4_CPU) += $(call cc-option,-mcpu=power4) +CFLAGS-$(CONFIG_POWER5_CPU) += $(call cc-option,-mcpu=power5) +CFLAGS-$(CONFIG_POWER6_CPU) += $(call cc-option,-mcpu=power6) +CFLAGS-$(CONFIG_POWER7_CPU) += $(call cc-option,-mcpu=power7) + +CFLAGS-$(CONFIG_TUNE_CELL) += $(call cc-option,-mtune=cell) + KBUILD_CPPFLAGS += -Iarch/$(ARCH) KBUILD_AFLAGS += -Iarch/$(ARCH) KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y) @@ -76,22 +86,11 @@ CPP = $(CC) -E $(KBUILD_CFLAGS) CHECKFLAGS+= -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__ -ifeq ($(CONFIG_PPC64),y) -ifeq ($(CONFIG_POWER4_ONLY),y) - KBUILD_CFLAGS += $(call cc-option,-mcpu=power4) -else - KBUILD_CFLAGS += $(call cc-option,-mtune=power4) -endif -endif - KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o -ifeq ($(CONFIG_TUNE_CELL),y) - KBUILD_CFLAGS += $(call cc-option,-mtune=cell) -endif - -# No AltiVec instruction when building kernel +# No AltiVec or VSX instructions when building kernel KBUILD_CFLAGS += $(call cc-option,-mno-altivec) +KBUILD_CFLAGS += $(call cc-option,-mno-vsx) # No SPE instruction when building kernel # (We use all available options to help semi-broken compilers) Index: linux-build/arch/powerpc/platforms/Kconfig.cputype === --- linux-build.orig/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 14:31:25.134549903 +1000 +++ linux-build/arch/powerpc/platforms/Kconfig.cputype2012-04-18 14:36:40.576207829 +1000 @@ -78,6 +78,36 @@ config PPC_BOOK3E_64 endchoice +choice + prompt CPU selection + depends on PPC64 + default GENERIC_CPU + help + This will create a kernel which is optimised for a particular CPU. + The resulting kernel may not run on other CPUs, so use this with care. + + If unsure, select Generic. + +config GENERIC_CPU + bool Generic + +config CELL_CPU + bool Cell Broadband Engine + +config POWER4_CPU + bool POWER4 + +config POWER5_CPU + bool POWER5 + +config POWER6_CPU + bool POWER6 + +config POWER7_CPU + bool POWER7 + +endchoice + config PPC_BOOK3S def_bool y depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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 tried? 32M. With the old UMS driver 3D once worked fine ... The purpose of radeon.test=1 isn't to change anything but to catch problems transferring data between system memory bound via AGP GART and video RAM. Does it pass for the whole AGP aperture? AFAICT yes. For the default 256M it printed [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset for every other offset from 0x201000 to 0xfe01000. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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 tried? 32M. With the old UMS driver 3D once worked fine ... That doesn't necessarily mean much per se, as with UMS memory is only statically mapped into the AGP GART once (so most of those 32M are wasted at least most of the time), whereas with KMS it's dynamically (un)mapped on demand. The purpose of radeon.test=1 isn't to change anything but to catch problems transferring data between system memory bound via AGP GART and video RAM. Does it pass for the whole AGP aperture? AFAICT yes. For the default 256M it printed [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset for every other offset from 0x201000 to 0xfe01000. Okay, so apparently there's at least no obvious problem with 256M on your UniNorth revision either. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 programming pipes. Bad things might happen. radeon :00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x84110140 radeon :00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x80010140 radeon :00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x0140 radeon :00:10.0: GPU reset succeed radeon :00:10.0: GPU reset succeed [drm] radeon: 1 quad pipes, 1 Z pipes initialized. [drm] PCIE GART of 512M enabled (table at 0x02C0). radeon :00:10.0: WB enabled [drm] fence driver on ring 0 use gpu addr 0x7800 and cpu addr 0xefac7000 [drm] radeon: ring at 0x78001000 [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEA [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). radeon :00:10.0: failed initializing CP (-22). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4] KVM: PPC Use clockevent multiplier and shifter for decrementer
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
observed that this conversion (timebase-time-timebase) are not correct
because the mechanism are not consistent. In our setup it adds 2% jitter.
With this patch clockevent multiplier and shifter mechanism are used when
starting hrtimer for decrementer emulation. Now the jitter is 0.5%.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v4:
- Added comment in emulate.c
arch/powerpc/include/asm/time.h |1 +
arch/powerpc/kernel/time.c |3 ++-
arch/powerpc/kvm/emulate.c |9 +++--
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 7eb10fb..b3c7959 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -28,6 +28,7 @@
extern unsigned long tb_ticks_per_jiffy;
extern unsigned long tb_ticks_per_usec;
extern unsigned long tb_ticks_per_sec;
+extern struct clock_event_device decrementer_clockevent;
struct rtc_time;
extern void to_tm(int tim, struct rtc_time * tm);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 567dd7c..4f7a285 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -105,7 +105,7 @@ static int decrementer_set_next_event(unsigned long evt,
static void decrementer_set_mode(enum clock_event_mode mode,
struct clock_event_device *dev);
-static struct clock_event_device decrementer_clockevent = {
+struct clock_event_device decrementer_clockevent = {
.name = decrementer,
.rating = 200,
.irq= 0,
@@ -113,6 +113,7 @@ static struct clock_event_device decrementer_clockevent = {
.set_mode = decrementer_set_mode,
.features = CLOCK_EVT_FEAT_ONESHOT,
};
+EXPORT_SYMBOL(decrementer_clockevent);
DEFINE_PER_CPU(u64, decrementers_next_tb);
static DEFINE_PER_CPU(struct clock_event_device, decrementers);
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index afc9154..550a058 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -23,6 +23,7 @@
#include linux/types.h
#include linux/string.h
#include linux/kvm_host.h
+#include linux/clockchips.h
#include asm/reg.h
#include asm/time.h
@@ -104,8 +105,12 @@ void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
*/
dec_time = vcpu-arch.dec;
- dec_time *= 1000;
- do_div(dec_time, tb_ticks_per_usec);
+ /*
+* Guest timebase ticks at the same frequency as host decrementer.
+* So use the host decrementer calculations for decrementer emulation.
+*/
+ dec_time = dec_time decrementer_clockevent.shift;
+ do_div(dec_time, decrementer_clockevent.mult);
dec_nsec = do_div(dec_time, NSEC_PER_SEC);
hrtimer_start(vcpu-arch.dec_timer,
ktime_set(dec_time, dec_nsec), HRTIMER_MODE_REL);
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Original-Nachricht Datum: Wed, 18 Apr 2012 17:01:20 +0200 Von: Michel Dänzer mic...@daenzer.net An: Andreas Schwab sch...@linux-m68k.org CC: o jordan ojordan12...@hotmail.co.uk, 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änzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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 tried? 32M. With the old UMS driver 3D once worked fine ... That doesn't necessarily mean much per se, as with UMS memory is only statically mapped into the AGP GART once (so most of those 32M are wasted at least most of the time), whereas with KMS it's dynamically (un)mapped on demand. That may be a stupid question, but is it allowed (for a DRM client or whatever does the mapping) to change the content of a page mapped into the AGP GART or is it necessary to explicitly unmap the page, change its content and map it again? I would say it's necessary to unmap the page first (sounds more like the pci_[un]map_page() approach) - at least when it should work with non-coherent architectures, too. Gerhard PS: Sorry for hijacking the thread. :-) -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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 tried? 32M. With the old UMS driver 3D once worked fine ... That doesn't necessarily mean much per se, as with UMS memory is only statically mapped into the AGP GART once (so most of those 32M are wasted at least most of the time), whereas with KMS it's dynamically (un)mapped on demand. That may be a stupid question, but is it allowed (for a DRM client or whatever does the mapping) to change the content of a page mapped into the AGP GART or is it necessary to explicitly unmap the page, change its content and map it again? The former. I would say it's necessary to unmap the page first (sounds more like the pci_[un]map_page() approach) - at least when it should work with non-coherent architectures, too. I'm afraid non-coherent platforms haven't really been a concern yet for KMS, and always doing the above dance would probably have a significant performance impact on coherent platforms. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Original-Nachricht Datum: Wed, 18 Apr 2012 18:06:36 +0200 Von: Michel Dänzer mic...@daenzer.net An: Gerhard Pircher gerhard_pirc...@gmx.net 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 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net 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 tried? 32M. With the old UMS driver 3D once worked fine ... That doesn't necessarily mean much per se, as with UMS memory is only statically mapped into the AGP GART once (so most of those 32M are wasted at least most of the time), whereas with KMS it's dynamically (un)mapped on demand. That may be a stupid question, but is it allowed (for a DRM client or whatever does the mapping) to change the content of a page mapped into the AGP GART or is it necessary to explicitly unmap the page, change its content and map it again? The former. I know that the uninorth AGPGART driver does a cache flushing for newly mapped pages, but is there any code in the driver that handles the former case (or isn't this necessary on PPC Macs)? I would say it's necessary to unmap the page first (sounds more like the pci_[un]map_page() approach) - at least when it should work with non-coherent architectures, too. I'm afraid non-coherent platforms haven't really been a concern yet for KMS, and always doing the above dance would probably have a significant performance impact on coherent platforms. Are there any plans for a page flushing API? I suppose that wouldn't have such a big performance impact on coherent platforms (but probably an impact on the userspace API). Thanks! Gerhard -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Add back condition for smp
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 single core. The following code should be in the condition of
CONFIG_KEXEC or CONFIG_HOTPLUG_CPU
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
Signed-off-by: York Sun york...@freescale.com
Acked-by: Li Yang le...@freescale.com
---
arch/powerpc/platforms/85xx/smp.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 56942af..868c6d7 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -192,8 +192,10 @@ struct smp_ops_t smp_85xx_ops = {
.cpu_disable= generic_cpu_disable,
.cpu_die= generic_cpu_die,
#endif
+#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
+#endif
};
#ifdef CONFIG_KEXEC
Note that this is only a temporary fix, that assumes the environments
where tbsync is problematic[1] (virtualization and simulation) do not
enable CONFIG_KEXEC or CONFIG_HOTPLUG_CPU. Eventually the sync should
be done via CCSR like in U-Boot, and the decision on whether to do it
should be runtime.
Is the thinking with the CCSR like u-boot sync after boot would resync to
some non-zero TB value?
Yes, while all timebases are stopped, the core coming out of reset will
be set to the timebase value of the other cores.
I'm guessing the idea is doing such a rsync w/TB stopped in the
system is quick enough that the freezing of it will not be noticed.
Quick enough is relative, but remember that the context is things like
kexec and deep sleep, which are already quite timing-intrusive.
One should measure this and see what it looks like in core cycles and
how it scales based on # of cores. (could use alternate TB as a
counter to measure).
I have a hard time imagining it being slower than the generic tbsync,
but in any case it's really the only sane option we have in cases where
we must reset individual cores -- I'm not sure how relevant such
benchmarking would be, other than nice to know.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [EDAC ABI v13 24/25] edac: change the mem allocation scheme to make Documentation/kobject.txt happy
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 data into a single kzalloc.
As this is not accepted anymore, change the allocation schema of the
EDAC *_info structs to enforce this Kernel standard.
[]
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
[]
@@ -2228,9 +2228,9 @@ static int init_csrows(struct mem_ctl_info *mci)
edac_mode = EDAC_NONE;
for (j = 0; j pvt-channel_count; j++) {
- csrow-channels[j].dimm-mtype = mtype;
- csrow-channels[j].dimm-edac_mode = edac_mode;
- csrow-channels[j].dimm-nr_pages = nr_pages;
+ csrow-channels[j]-dimm-mtype = mtype;
+ csrow-channels[j]-dimm-edac_mode = edac_mode;
+ csrow-channels[j]-dimm-nr_pages = nr_pages;
It might be better to use an automatic for
typeof foo dimm = csrow-channels[j]-dimm;
dimm-mtype = mtype;
etc...
[]
@@ -293,39 +286,56 @@ struct mem_ctl_info *edac_mc_alloc(unsigned edac_index,
mci-mem_is_per_rank = per_rank;
/*
- * Fills the csrow struct
+ * Alocate and fill the csrow/channels structs
*/
+ mci-csrows = kzalloc(sizeof(*mci-csrows) * tot_csrows, GFP_KERNEL);
kcalloc
[]
+ csr-channels = kzalloc(sizeof(*csr-channels) * tot_cschannels,
+ GFP_KERNEL);
here too
@@ -391,7 +401,31 @@ struct mem_ctl_info *edac_mc_alloc(unsigned edac_index,
trace_hw_event_init(edac, (unsigned)edac_index);
+ debugf1(EDAC MCI allocated\n);
return mci;
+
+error:
+ debugf1(Failed to allocate one or more EDAC MCI structs\n);
Generally, it's not necessary to have specific OOM messages
as allocations without GFP_NOWARN do dump_stack()s
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] edac: move nr_pages to dimm struct
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 controller represents the memory via chip select rows.
Reviewed-by: Aristeu Rozanski aroza...@redhat.com
Acked-by: Borislav Petkov borislav.pet...@amd.com
Cc: Doug Thompson nor...@yahoo.com
Cc: Mark Gross mark.gr...@intel.com
Cc: Jason Uhlenkott juhle...@akamai.com
Cc: Tim Small t...@buttersideup.com
Cc: Ranganathan Desikan r...@jetztechnologies.com
Cc: Arvind R. arvin...@gmail.com
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Michal Marek mma...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Joe Perches j...@perches.com
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
v14: Fix two debug messages to properly report the number of pages
drivers/edac/amd64_edac.c | 14 ---
drivers/edac/amd76x_edac.c |6 ++--
drivers/edac/cell_edac.c |8 --
drivers/edac/cpc925_edac.c |8 --
drivers/edac/e752x_edac.c |6 +++-
drivers/edac/e7xxx_edac.c |5 ++-
drivers/edac/edac_mc.c | 16 -
drivers/edac/edac_mc_sysfs.c | 47
drivers/edac/i3000_edac.c |6 +++-
drivers/edac/i3200_edac.c |3 +-
drivers/edac/i5000_edac.c | 14 ++-
drivers/edac/i5100_edac.c | 22 +++---
drivers/edac/i5400_edac.c |9 ++-
drivers/edac/i7300_edac.c | 22 +-
drivers/edac/i7core_edac.c | 10 ++--
drivers/edac/i82443bxgx_edac.c |2 +-
drivers/edac/i82860_edac.c |2 +-
drivers/edac/i82875p_edac.c|5 ++-
drivers/edac/i82975x_edac.c| 11 ++--
drivers/edac/mpc85xx_edac.c|3 +-
drivers/edac/mv64x60_edac.c|3 +-
drivers/edac/pasemi_edac.c | 14 ++--
drivers/edac/ppc4xx_edac.c |5 ++-
drivers/edac/r82600_edac.c |3 +-
drivers/edac/sb_edac.c |8 +-
drivers/edac/tile_edac.c |2 +-
drivers/edac/x38_edac.c|4 +-
include/linux/edac.h |8 --
28 files changed, 145 insertions(+), 121 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 0be3f29..6d6ec68 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2126,14 +2126,8 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt,
u8 dct, int csrow_nr)
nr_pages = pvt-ops-dbam_to_cs(pvt, dct, cs_mode) (20 - PAGE_SHIFT);
- /*
-* If dual channel then double the memory size of single channel.
-* Channel count is 1 or 2
-*/
- nr_pages = (pvt-channel_count - 1);
-
debugf0( (csrow=%d) DBAM map index= %d\n, csrow_nr, cs_mode);
- debugf0(nr_pages= %u channel-count = %d\n,
+ debugf0(nr_pages/channel= %u channel-count = %d\n,
nr_pages, pvt-channel_count);
return nr_pages;
@@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
int i, j, empty = 1;
enum mem_type mtype;
enum edac_type edac_mode;
+ int nr_pages;
amd64_read_pci_cfg(pvt-F3, NBCFG, val);
@@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
i, pvt-mc_node_id);
empty = 0;
- csrow-nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
+ nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
get_cs_base_and_mask(pvt, i, 0, base, mask);
/* 8 bytes of resolution */
mtype = amd64_determine_memory_type(pvt, i);
debugf1( for MC node %d csrow %d:\n, pvt-mc_node_id, i);
- debugf1(nr_pages: %u\n, csrow-nr_pages);
+ debugf1(nr_pages: %u\n, nr_pages * pvt-channel_count);
/*
* determine whether CHIPKILL or JUST ECC or NO ECC is operating
@@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
for (j = 0; j pvt-channel_count; j++) {
csrow-channels[j].dimm-mtype = mtype;
csrow-channels[j].dimm-edac_mode = edac_mode;
+ csrow-channels[j].dimm-nr_pages = nr_pages;
}
}
diff --git a/drivers/edac/amd76x_edac.c b/drivers/edac/amd76x_edac.c
index 2a63ed0..1532750 100644
---
[PATCH] edac: Change internal representation to work with layers
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 compatibility with the old ones. The edac core were written with the idea that memory controllers are able to directly access csrows, and that the channels are used inside a csrows select. This is not true for FB-DIMM and RAMBUS memory controllers. Also, some recent advanced memory controllers don't present a per-csrows view. Instead, they view memories as DIMM's, instead of ranks, accessed via csrow/channel. So, change the allocation and error report routines to allow them to work with all types of architectures. This will allow the removal of several hacks on FB-DIMM and RAMBUS memory controllers on the next patches. Also, several tests were done on different platforms using different x86 drivers. TODO: a multi-rank DIMM's are currently represented by multiple DIMM entries at struct dimm_info. That means that changing a label for one rank won't change the same label for the other ranks at the same dimm. Such bug is there since the beginning of the EDAC, so it is not a big deal. However, on several drivers, it is possible to fix this issue, but it should be a per-driver fix, as the csrow = DIMM arrangement may not be equal for all. So, don't try to fix it here yet. PS.: I tried to make this patch as short as possible, preceding it with several other patches that simplified the logic here. Yet, as the internal API changes, all drivers need changes. The changes are generally bigger on the drivers for FB-DIMM's. FIXME: while the FB-DIMMs are not converted to use the new design, uncorrected errors will show just one channel. In the past, all changes were on a big patch with about 150K. As it needed to be split, in order to be accepted by the EDAC ML at vger, we've opted to have this small drawback. As an advantage, it is now easier to review the patch series. Cc: Aristeu Rozanski aroza...@redhat.com Cc: Doug Thompson nor...@yahoo.com Cc: Borislav Petkov borislav.pet...@amd.com Cc: Mark Gross mark.gr...@intel.com Cc: Jason Uhlenkott juhle...@akamai.com Cc: Tim Small t...@buttersideup.com Cc: Ranganathan Desikan r...@jetztechnologies.com Cc: Arvind R. arvin...@gmail.com Cc: Olof Johansson o...@lixom.net Cc: Egor Martovetsky e...@pasemi.com Cc: Chris Metcalf cmetc...@tilera.com Cc: Michal Marek mma...@suse.cz Cc: Jiri Kosina jkos...@suse.cz Cc: Joe Perches j...@perches.com Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Hitoshi Mitake h.mit...@gmail.com Cc: Andrew Morton a...@linux-foundation.org Cc: Niklas Söderlund niklas.soderl...@ericsson.com Cc: Shaohui Xie shaohui@freescale.com Cc: Josh Boyer jwbo...@gmail.com Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- v14: Contextual changes fix drivers/edac/edac_core.h | 92 ++- drivers/edac/edac_mc.c | 682 -- include/linux/edac.h | 40 ++- 3 files changed, 526 insertions(+), 288 deletions(-) diff --git a/drivers/edac/edac_core.h b/drivers/edac/edac_core.h index e48ab31..7201bb1 100644 --- a/drivers/edac/edac_core.h +++ b/drivers/edac/edac_core.h @@ -447,8 +447,13 @@ static inline void pci_write_bits32(struct pci_dev *pdev, int offset, #endif /* CONFIG_PCI */ -extern struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows, - unsigned nr_chans, int edac_index); +struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows, + unsigned nr_chans, int edac_index); +struct mem_ctl_info *new_edac_mc_alloc(unsigned edac_index, + unsigned n_layers, + struct edac_mc_layer *layers, + bool rev_order, + unsigned sz_pvt); extern int edac_mc_add_mc(struct mem_ctl_info *mci); extern void edac_mc_free(struct mem_ctl_info *mci); extern struct mem_ctl_info *edac_mc_find(int idx); @@ -467,24 +472,80 @@ extern int edac_mc_find_csrow_by_page(struct mem_ctl_info *mci, * reporting logic and function interface - reduces conditional * statement clutter and extra function arguments. */ -extern void edac_mc_handle_ce(struct mem_ctl_info *mci, + +void edac_mc_handle_error(const enum hw_event_mc_err_type type, + struct mem_ctl_info *mci, + const unsigned long page_frame_number, + const unsigned long offset_in_page, + const unsigned long syndrome, + const int layer0, + const int layer1, + const int
Re: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
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_devices().
mpc85xx_common_publish_devices() has this line in it:
{ .name = localbus, },
But this does not work any more, because all of our 85xx localbus nodes
are now called localbus@ffe05000.
I'm beginning to hate mpc85xx_common_publish_devices() now. Not only
because it's broken for the P1022DS, but also because it's not
set-in-stone like everyone thought.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc: Require gcc 4.0 on 64-bit
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 complicated. In preparation for adding more -mcpu targets, remove the workaround and just require gcc 4.0 for 64-bit builds. Signed-off-by: Anton Blanchard an...@samba.org --- 4.0 came out in 2005 and the gcc on RHEL5 and SLES10 looks to be 4.1. I highly doubt a ppc64 kernel will build these days on either RHEL4 or SLES9. Anything else we have to worry about? There are probably embedded customers that might utilize older compilers, so this concerns me a little. For 64-bit ? I doubt it ... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
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 does that with the BIOS on these no ? (ie. D2 state). KMS doesn't have any non-BIOS suspend/resume code yet, so it's either that or no suspend/resume. :) Sure, my point is I don't know what happens on those old thinkpads, ie, what does the BIOS provides to KMS and whether it's a good enough alternative to the hand made D2 approach radeonfb used on them. But heh, I'm happy to just ignore those, that would make things easier, in which case we can just have a non-bios pair of suspend/resume calls provided as empty weak functions, and have a radeon_mac_pm.c providing more/less the existing radeonfb code for power macs overriding those weak functions. If it's mac-only it's going to be easier to deal with. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Drivers: ps3: ps3av.c: fixed checkpatch warnings
On Wed, 18 Apr 2012, Valentin Ilie wrote: Fixed some checkpatch warnings. (review) Last patch didn't compile. Signed-off-by: Valentin Ilie valentin.i...@gmail.com 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 fine to me in any case. Reviewed-by: Jesper Juhl j...@chaosbits.net -- Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] irqdomain/powerpc: Fix broken NR_IRQ references
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 @@ static int axon_msi_setup_msi_irqs(struct pci_dev *dev,
int nvec, int type)
if (rc)
return rc;
- /* We rely on being able to stash a virq in a u16 */
Would be nice to move the comment to the hunk below rather than just
deleting it. Otherwise the 65536 looks a bit random.
- BUILD_BUG_ON(NR_IRQS 65536);
-
list_for_each_entry(entry, dev-msi_list, list) {
virq = irq_create_direct_mapping(msic-irq_domain);
if (virq == NO_IRQ) {
@@ -392,7 +389,7 @@ static int axon_msi_probe(struct platform_device *device)
}
memset(msic-fifo_virt, 0xff, MSIC_FIFO_SIZE_BYTES);
- msic-irq_domain = irq_domain_add_nomap(dn, 0, msic_host_ops, msic);
+ msic-irq_domain = irq_domain_add_nomap(dn, 65536, msic_host_ops,
msic);
if (!msic-irq_domain) {
printk(KERN_ERR axon_msi: couldn't allocate irq_domain for
%s\n,
dn-full_name);
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
