Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

[Gerhard Pircher]

Am 09.04.20 um 10:54 schrieb Benjamin Herrenschmidt:
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
>> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
>>> If this code was broken for non-coherent caches a crude powerpc hack
>>> isn't going to help anyone else.  Remove the hack as it is the last
>>> user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
>>
>> Well Ben added this to make stuff work on ppc, ofc the home grown dma
>> layer in drm from back then isn't going to work in other places. I guess
>> should have at least an ack from him, in case anyone still cares about
>> this on ppc. Adding Ben to cc.
>
> This was due to some drivers (radeon ?) trying to use vmalloc pages for
> coherent DMA, which means on those 4xx powerpc's need to be non-cached.
>
> There were machines using that (440 based iirc), though I honestly
> can't tell if anybody still uses any of it.
The first-gen amigaone platform (6xx/book32s) uses the radeon driver
together with non-coherent DMA. However this only ever worked reliably
for DRI1.

br,
Gerhard

> Cheers,
> Ben.
>
>> -Daniel
>>
>>>
>>> Signed-off-by: Christoph Hellwig 
>>> ---
>>>  drivers/gpu/drm/drm_scatter.c | 11 +--
>>>  1 file changed, 1 insertion(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
>>> index ca520028b2cb..f4e6184d1877 100644
>>> --- a/drivers/gpu/drm/drm_scatter.c
>>> +++ b/drivers/gpu/drm/drm_scatter.c
>>> @@ -43,15 +43,6 @@
>>>
>>>  #define DEBUG_SCATTER 0
>>>
>>> -static inline void *drm_vmalloc_dma(unsigned long size)
>>> -{
>>> -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
>>> -   return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
>>> -#else
>>> -   return vmalloc_32(size);
>>> -#endif
>>> -}
>>> -
>>>  static void drm_sg_cleanup(struct drm_sg_mem * entry)
>>>  {
>>> struct page *page;
>>> @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void 
>>> *data,
>>> return -ENOMEM;
>>> }
>>>
>>> -   entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
>>> +   entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
>>> if (!entry->virtual) {
>>> kfree(entry->busaddr);
>>> kfree(entry->pagelist);
>>> --
>>> 2.25.1
>>>
>>
>>
>

Re: [PATCH 7/8] powerpc/dma: split the two __dma_alloc_coherent implementations

[Gerhard Pircher]

Am 2018-12-17 um 08:35 schrieb Christoph Hellwig:
> On Mon, Dec 17, 2018 at 07:51:05AM +0100, Christophe Leroy wrote:
>>
>>
>> Le 16/12/2018 à 18:19, Christoph Hellwig a écrit :
>>> The implemementation for the CONFIG_NOT_COHERENT_CACHE case doesn't share
>>> any code with the one for systems with coherent caches.  Split it off
>>> and merge it with the helpers in dma-noncoherent.c that have no other
>>> callers.
>>>
>>> Signed-off-by: Christoph Hellwig 
>>> Acked-by: Benjamin Herrenschmidt 
>>> ---
>>>   arch/powerpc/include/asm/dma-mapping.h |  5 -
>>>   arch/powerpc/kernel/dma.c  | 14 ++
>>
>> Instead of all the ifdefs in dma.c, couldn't we split it
>> in two files, ie dma.c for common parts and dma-coherence.c for specific 
>> stuff ?
> 
> The end goal is to kill dma.c and keep dma-noncoherent.c only with most
> of the code moving to common code.  Here is the current state of that:
> 
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.5
> 
> But it still has issues on two tested platforms and isn't ready yet.
I hope that I can give this a try on one of my AmigaOne machines over
Christmas. Unfortunately my main local AmigaOne machine is out of order
and the other one is only remotely accessible, which makes kernel testing
a bit hard. :-)

Gerhard

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

[Gerhard Pircher]

On Tue, 2016-06-28 at 14:01 +0200, Benjamin Herrenschmidt wrote:
> On Tue, 2016-06-28 at 13:42 +0200, Gerhard Pircher wrote:
> > The question is, if a compile time option that simply clear ?s
> > CPU_FTR_NEED_COHERENT after identify_cpu() would be acceptable. And
> > then I still wonder why KVM needs its own similar fix to work on the
> > AmigaOne. I specifically had to remove/clear the PTE_M bit
> > inarch/powerpc/kvm/book3s_32_mmu_host.c for th
> 
> No we could just add something to early_init_devtree that does clear
> that bit if it sees the relevant piece of broken HW, it's not the AmigaOne 
> per-se, it's the northbridge right ?
Does that work for CPU_FTR_NEED_COHERENT, given that the feature fixups
are done right after identify_cpu() and instructions within BEGIN_FTR_SECTION
and END_FTR_SECTION* are patched out (if I understand this mechanism
correctly) !?
But yes, the specific northbridge is the problem here.

> We could also make non-coherent cache a runtime option if we really
> wanted, it's just more churn ...
Yeah, I remember a discussion or two about this topic and I always wondered
how driver code would differentiate then between non-coherent and coherent
DMA, given that they sometimes require different handling of the DMA addresses
(e.g. if I look at /sound/core/pcm_native.c or the DRM code).

> > > Do we know where the lockups come from btw ? A problem with the
> > > northbridge ?
> > Yes, it's a problem with the northbridge...as usual. :-(
> 
> Marvell ?
No, the one with the dreaded "A" name: MAI Logic's "Articia S" :-)

BR,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

[Gerhard Pircher]

On Mon, 2016-06-27 at 23:40 +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2016-06-27 at 22:42 +0200, Gerhard Pircher wrote:
> > This patch series reminds me of a long-standing issue with the
> > AmigaOne platform code, which would have to clear the coherence
> > (M) flag for every memory mapping to avoid lockups (especially
> > on G4 CPUs) - as you can read in the comment below your patch
> > above.
> > 
> > Now the follow-up code in amigaone/setup.c to clear the
> > corresponding CPU feature flag is essentially dead code (it used
> > to work with a second call of do_feature_fixups() before the
> > handling of the CPU_FTR_NEED_COHERENT flag was changed/inverted
> > somewhere around v2.6.30). Also it doesn't seem to fix all
> > deadlocks, as e.g. KVM virtual machines can still inject memory
> > mappings with the M flag set AFAICT.
> > 
> > Now I wonder, if there is a reasonably clean way to clear the M
> > flag in all hardware page table and BAT entries without defacing
> > generic kernel code too much. Any ideas?
> 
> Other than a compile time option ?
Well, I guess a runtime option would always be preferable, but I don't
see how this could be implemented without moving probe_machine() in
front of identify_cpu() (which doesn't look easy either). On the other
side the AmigaOne also requires CONFIG_NOT_COHERENT_CACHE set and this
one is still a compile time option, too.
The question is, if a compile time option that simply clears
CPU_FTR_NEED_COHERENT after identify_cpu() would be acceptable. And
then I still wonder why KVM needs its own similar fix to work on the
AmigaOne. I specifically had to remove/clear the PTE_M bit in
arch/powerpc/kvm/book3s_32_mmu_host.c for this:

206 pteg0 = ((eaddr & 0x0fff) >> 22) | (vsid << 7) | PTE_V |
207 (primary ? 0 : PTE_SEC);
208 pteg1 = hpaddr | PTE_M | PTE_R | PTE_C;
 ^

> Do we know where the lockups come from btw ? A problem with the
> northbridge ?
Yes, it's a problem with the northbridge...as usual. :-(

> Cheers,
> Ben.

Thanks!

BR,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

[Gerhard Pircher]

Am 2016-06-27 um 13:29 schrieb Benjamin Herrenschmidt:
> This converts all the 32-bit platforms to use the expanded device-tree
> which is a pretty mechanical change. Unlike 64-bit, the 32-bit kernel
> didn't rely on platform initializations to setup the MMU since it
> sets it up entirely before probe_machine() so the move has comparatively
> less consequences though it's a bigger patch.
> 
> Signed-off-by: Benjamin Herrenschmidt 

[...]

> diff --git a/arch/powerpc/platforms/amigaone/setup.c 
> b/arch/powerpc/platforms/amigaone/setup.c
> index 2fe1204..a030d3b 100644
> --- a/arch/powerpc/platforms/amigaone/setup.c
> +++ b/arch/powerpc/platforms/amigaone/setup.c
> @@ -143,9 +143,7 @@ void amigaone_restart(char *cmd)
>  
>  static int __init amigaone_probe(void)
>  {
> - unsigned long root = of_get_flat_dt_root();
> -
> - if (of_flat_dt_is_compatible(root, "eyetech,amigaone")) {
> + if (of_machine_is_compatible("eyetech,amigaone")) {
>   /*
>* Coherent memory access cause complete system lockup! Thus
>* disable this CPU feature, even if the CPU needs it.
This patch series reminds me of a long-standing issue with the
AmigaOne platform code, which would have to clear the coherence
(M) flag for every memory mapping to avoid lockups (especially
on G4 CPUs) - as you can read in the comment below your patch
above.

Now the follow-up code in amigaone/setup.c to clear the
corresponding CPU feature flag is essentially dead code (it used
to work with a second call of do_feature_fixups() before the
handling of the CPU_FTR_NEED_COHERENT flag was changed/inverted
somewhere around v2.6.30). Also it doesn't seem to fix all
deadlocks, as e.g. KVM virtual machines can still inject memory
mappings with the M flag set AFAICT.

Now I wonder, if there is a reasonably clean way to clear the M
flag in all hardware page table and BAT entries without defacing
generic kernel code too much. Any ideas?

BR,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PowerPC agpmode issues

[Gerhard Pircher]

> On 9 Feb 2016 03:27, "Mike"  wrote:
> Ok, so its quirks to be added then? Something not implemented in KMS
> that was in UMS?
> Reports are that the same issue exsist on PPC Amiga Ones with a VIA
> chipset, and the Pegasos 2 with the Artica s chipset, i posted a
> mail from detailiing that.
Just to avoid some confusion:
Old long story short: the issues for AmigaOnes and the Pegasos _1_ with
ArticiaS northbridge and VIA southbridge are that:
1. the AGP controller corrupts data transfers in AGP mode (also depending
on the AGP HW request queue size). So there is no official AGP driver that
would require radeon.agpmode=-1. The microA1 is supposed to have a fix
for this HW data corruption, but I yet have to dig out my ArticiaS AGP
driver code for some test runs...
2. At least the AmigaOne with ArticiaS chip need non-coherent DMA
allocations and/or proper cache flushes to avoid corrupted DMA transfers.

Nonetheless I had DRI1 working _only_ on my A1SE under Debian Squeeze (i.e.
glxgears could run on the desktop with hardware acceleration), but DRI2
with its very dynamic GART mapping is a no-go on every first-gen AmigaOne
machine, even if the GART driver test (radeon.test=1) runs through in
PCIGART mode (could it be that it uses a more or less static GART mapping
for the test?).

> Sure that might be it, but i get different results trying agpmode=1-2-4,
> 2 gave a noisy screen before the hard crash. i find it rather impossible
> to debug at all as the crash happens so fast no logs seem to be written..
> I think i would need serial...
> I'd personally love nothing more then to see support restored and a
> default as expected working condition ought be the minimum requirement.
> I use a powerbook a1106, 5,6. With a 5,8 on the way. Those are the last
> two revision powerbooks in the 15" series. In swrast they become useless,
> impossible to use for any productivity. Most people trying to use linux
> on ppc for personal use come in macs, with the exception of the Amiga PPC
> crowd now running their amcc 440/460ex or e600 based x500/5000, all of
> which have of course pci-e more cores and more threads. Yet struggle even
> with regressions left and right to keep up with the single core performance
> of the G4's. Sure it's pushing 10 years , but it's the only alternative
> if one wishes to remain mobile.
swrast definitely isn't fun on 10 years old PPC machines. Current Firefox
is already slow enough on these machines... :-)

> On 9 Feb 2016 02:41, "Michel Dänzer"  wrote:
> > On 08.02.2016 22:28, Mike wrote:
> > Certainly 750~800 fps in glxgears vs 3000+ in debian squeeze, i cant
> > bring myself to say that it's an acceptable situation no matter how
> > tired i am of the problem knowing how well the setup could do. It's
> > clear that the implementation is broken for everything but x86, [...]
> 
> Why is that? It was working fine on my last-gen PowerBook. AFAIK Darwin
> / OS X never used anything but a static AGP GART mapping though, so it
> seems very likely that the issues with older UniNorth revisions are
> simply due to the hardware being unable to support the usage patterns of
> modern GPU drivers.
> 
> That said, if you guys have specific suggestions for a "proper"
> solution, nobody's standing in your way.
I have to admit that I lack the knowledge of the inner workings of the
TTM/radeon code (and its TTM AGP backend) to do any useful work here.
I was hoping that the TMA DMA allocator could be of any help at least for
non-cache coherent machines given that (IIRC) ARM is using it together
with the nuoveau driver on the TEGRA platform, but I guess that would need
some modifications also on the powerpc architecture side (maybe a new
non-coherent DMA allocator that is not limited to 2M virtual address space
for mappings). Thus I guess a lot of things could be improved/fixed, but
nowadays Linux code doesn't seem to be something for the "occasional hobby
hacker". :-)

regards,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFT PATCH] powerpc: convert amigaone_defconfig to use libata PATA drivers

[Gerhard Pircher]

Am 2016-02-03 um 16:50 schrieb Bartlomiej Zolnierkiewicz:
> IDE subsystem has been deprecated since 2009 and the majority
> (if not all) of Linux distributions have switched to use
> libata for ATA support exclusively.  However there are still
> some users (mostly old or/and embedded non-x86 systems) that
> have not converted from using IDE subsystem to libata PATA
> drivers.  This doesn't seem to be good thing in the long-term
> for Linux as while there is less and less PATA systems left
> in use:
> 
> * testing efforts are divided between two subsystems
> 
> * having duplicate drivers for same hardware confuses users
> 
> This patch converts amigaone_defconfig to use libata PATA
> drivers.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
> Build tested only.
> If you have affected hardware please test.  Thank you.
> 
>  arch/powerpc/configs/amigaone_defconfig | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/configs/amigaone_defconfig 
> b/arch/powerpc/configs/amigaone_defconfig
> index 84f1b41..55a4929 100644
> --- a/arch/powerpc/configs/amigaone_defconfig
> +++ b/arch/powerpc/configs/amigaone_defconfig
> @@ -46,12 +46,6 @@ CONFIG_PARPORT_PC_FIFO=y
>  CONFIG_BLK_DEV_FD=y
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_BLK_DEV_RAM=y
> -CONFIG_IDE=y
> -CONFIG_BLK_DEV_IDECD=y
> -# CONFIG_IDEPCI_PCIBUS_ORDER is not set
> -CONFIG_BLK_DEV_GENERIC=y
> -CONFIG_BLK_DEV_SIIMAGE=y
> -CONFIG_BLK_DEV_VIA82CXXX=y
>  CONFIG_SCSI=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_CHR_DEV_ST=y
> @@ -62,6 +56,10 @@ CONFIG_SCSI_CONSTANTS=y
>  CONFIG_SCSI_SYM53C8XX_2=y
>  CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
>  # CONFIG_SCSI_SYM53C8XX_MMIO is not set
> +CONFIG_ATA=y
> +CONFIG_PATA_SIL680=y
> +CONFIG_PATA_VIA=y
> +CONFIG_ATA_GENERIC=y
>  CONFIG_NETDEVICES=y
>  CONFIG_VORTEX=y
>  CONFIG_8139CP=y
> 
Thanks for cleaning up the defconfig file!

libata drivers work fine on the amigaone platform (tested on all three
first-gen AmigaOne machines). BTW: could it be that CONFIG_ATA_SFF=y
and CONFIG_ATA_BMDMA=y are missing in the patch?

br,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Problems with Kernels 3.17-rc1 and onwards on Acube Sam460 AMCC 460ex board

[Gerhard Pircher]

Am 2015-02-24 um 12:08 schrieb Julian Margetson:
 Problems with  the Gib bisect
 Kernel wont compile after 10th bisect .
You can try git bisect skip to select another commit for testing.
Hopefully that one compiles fine then.

Gerhard

 drivers/built-in.o: In function `drm_mode_atomic_ioctl':
 (.text+0x865dc): undefined reference to `__get_user_bad'
 make: *** [vmlinux] Error 1
 root@julian-VirtualBox:/usr/src/linux# git bisect log
 git bisect start
 # bad: [c517d838eb7d07bbe9507871fab3931deccff539] Linux 4.0-rc1
 git bisect bad c517d838eb7d07bbe9507871fab3931deccff539
 # good: [bfa76d49576599a4b9f9b7a71f23d73d6dcff735] Linux 3.19
 git bisect good bfa76d49576599a4b9f9b7a71f23d73d6dcff735
 # good: [02f1f2170d2831b3233e91091c60a66622f29e82] kernel.h: remove ancient 
 __FUNCTION__ hack
 git bisect good 02f1f2170d2831b3233e91091c60a66622f29e82
 # bad: [796e1c55717e9a6ff5c81b12289ffa1ffd919b6f] Merge branch 'drm-next' of 
 git://people.freedesktop.org/~airlied/linux
 git bisect bad 796e1c55717e9a6ff5c81b12289ffa1ffd919b6f
 # good: [9682ec9692e5ac11c6caebd079324e727b19e7ce] Merge tag 
 'driver-core-3.20-rc1' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
 git bisect good 9682ec9692e5ac11c6caebd079324e727b19e7ce
 # good: [a9724125ad014decf008d782e60447c811391326] Merge tag 'tty-3.20-rc1' 
 of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
 git bisect good a9724125ad014decf008d782e60447c811391326
 # good: [f43dff0ee00a259f524ce17ba4f8030553c66590] Merge tag 
 'drm-amdkfd-next-fixes-2015-01-25' of 
 git://people.freedesktop.org/~gabbayo/linux into drm-next
 git bisect good f43dff0ee00a259f524ce17ba4f8030553c66590
 # bad: [cffe1e89dc9bf541a39d9287ced7c5addff07084] drm: sti: HDMI add audio 
 infoframe
 git bisect bad cffe1e89dc9bf541a39d9287ced7c5addff07084
 # good: [2f5b4ef15c60bc5292a3f006c018acb3da53737b] Merge tag 
 'drm/tegra/for-3.20-rc1' of git://anongit.freedesktop.org/tegra/linux into 
 drm-next
 git bisect good 2f5b4ef15c60bc5292a3f006c018acb3da53737b
 # bad: [86588ce80ccd714793e9ba4140d7ae214229] drm/udl: optimize 
 udl_compress_hline16 (v2)
 git bisect bad 86588ce80ccd714793e9ba4140d7ae214229
 # bad: [d47df63393ed81977e0f6435988d9cbd70c867f7] drm/panel: simple: Add AVIC 
 TM070DDH03 panel support
 git bisect bad d47df63393ed81977e0f6435988d9cbd70c867f7
 # bad: [9469244d869623e8b54d9f3d4d00737e377af273] drm/atomic: Fix potential 
 use of state after free
 git bisect bad 9469244d869623e8b54d9f3d4d00737e377af273
 root@julian-VirtualBox:/usr/src/linux# 
 
 
 
 On 02/24/2015, you wrote:
 
 On Fri, 2015-02-20 at 15:25 -0400, Julian Margetson wrote:
 On 2/18/2015 11:25 PM, Julian Margetson wrote:

  re PPC4XX PCI(E) MSI support.
 https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-November/087273.html

 Hmm, I think all those comments were addressed before it was merged.

 I tried to get a 4xx board going here last week, but it doesn't seem happy. I
 can get a bit of uboot but then it hangs, might be overheating.

 cheers


 
 
 ___
 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] powerpc: kvm: Set M flag for KVM PTE depending on CPU_FTR_NEED_COHERENT

[Gerhard Pircher]

Usually page table entries only have the M (coherence) flag set, if the
kernel is in SMP mode or to avoid data corruption due to CPU bugs (e.g.
some 74xx CPUs). KVM on book3s_32 however always sets the M flag for a
PTE, which locks up machines based on the amigaone platform when running
QEMU or MoL.
Setting the M flag depending on CPU_FTR_NEED_COHERENT also makes KVM work
on this platform and aligns the PTE setup to the rest of the kernel.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
With this patch I could successfully run a Debian Wheezy installation
inside QEMU started with --enable-kvm on my AmigaOneG3SE.

 arch/powerpc/kvm/book3s_32_mmu_host.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c 
b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 2035d16..935c7d0 100644
--- a/arch/powerpc/kvm/book3s_32_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
@@ -204,7 +204,10 @@ next_pteg:
 
pteg0 = ((eaddr  0x0fff)  22) | (vsid  7) | PTE_V |
(primary ? 0 : PTE_SEC);
-   pteg1 = hpaddr | PTE_M | PTE_R | PTE_C;
+   pteg1 = hpaddr | PTE_R | PTE_C;
+
+   if (cpu_has_feature(CPU_FTR_NEED_COHERENT))
+   pteg1 |= PTE_M;
 
if (orig_pte-may_write  writable) {
pteg1 |= PP_RWRW;
-- 
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [git pull] Please pull powerpc.git merge branch

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 02 Jul 2012 14:57:39 +1000
 Von: Benjamin Herrenschmidt b...@kernel.crashing.org
 An: Linus Torvalds torva...@linux-foundation.org
 CC: linuxppc-dev list linuxppc-...@ozlabs.org, Andrew Morton 
 a...@linux-foundation.org, Linux Kernel list linux-ker...@vger.kernel.org
 Betreff: [git pull] Please pull powerpc.git merge branch

 Hi Linus 
 
 Here are two more fixes that I missed when scrubbing patchwork last
 week which are worth still having in 3.5.

What about this fix:?

http://patchwork.ozlabs.org/patch/166346/

At least I can't see it in the log...

br,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 24 Apr 2012 16:15:00 +0200
 Von: Michel Dänzer mic...@daenzer.net
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: linuxppc-dev@lists.ozlabs.org
 Betreff: Re: PowerPC radeon KMS - is it possible?

 On Mon, 2012-04-23 at 18:45 +0200, Gerhard Pircher wrote:
   Von: Michel Dänzer mic...@daenzer.net
   On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote: 
 Von: Michel Dänzer mic...@daenzer.net
 [...] 
  Could it be that the memory is finally mapped uncacheable by
  radeon_bo_kmap()/ttm_bo_kmap()/..some other TTM
  functions../vmap()?
 
 Yeah, AFAICT, basically ttm_io_prot() defines the mapping
 attributes, and vmap() is used to enforce them for kernel
 mappings.
Okay, that sounds like the approach used by arch/powerpc/mm/dma-
noncoherent.c in my (green) ears. What about the PCIGART mode?
Is the driver free to use cached memory in this mode?
   
   Yes, it assumes PCI(e) GART to be CPU cache coherent.
  Okay. I guess it should be possible to modify it so that it makes use
  of uncacheable memory - just for testing!?
 
 Sure. Just set man-available_caching and man-default_caching as in the
 AGP case in radeon_init_mem_type(). 
Thanks for the info! I'll play around with it.

  PCIGART was working somehow on my platform up to the ~2.6.39 kernel,
  i.e. I could login to GNOME and open a program until the machine
  locked-up. :-)
 
 But it's worse with newer kernels?
Yes, it's worse. But that's surely the fault of the buggy northbridge.
I believe the bridge doesn't like some of the code that the driver uses
to avoid ordering issues. But I still have to find out where the lockups
exactly happen.

  BTW: I see that the uninorth driver defines needs_scratch_page. What
  is this actually good for?
 
 It causes the code in drivers/char/agp/backend.c to allocate a scratch
 page (bridge-scratch_page) which the driver can use for unused GART
 entries.
Okay, so it would make sense to set this for my platform's AGP bridge,
which doesn't seem to support a GATT entry valid bit.

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: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 23 Apr 2012 11:56:06 +0200
 Von: Michel Dänzer mic...@daenzer.net
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: linuxppc-dev@lists.ozlabs.org
 Betreff: Re: PowerPC radeon KMS - is it possible?

 On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote: 
   Von: Michel Dänzer mic...@daenzer.net
   On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote: 
 Von: Michel Dänzer mic...@daenzer.net
 On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: 
  
  The former case is an explanation, why I see data corruption
  with my AGPGART driver (more or less a copy of the uninorth
  driver) on my non-coherent platform. There are no cache
  flushes done for writes to already mapped pages.
 
 As I said, the radeon driver always maps AGP memory uncacheable
 for the CPU, so no such CPU cache flushes should be necessary.
I know. We also discussed this topic over two years ago. :-)

What I didn't understand yet is how this uncacheable memory is
allocated (well, I never took the time to look at this again). The
functions in ttm_page_alloc.c seem to allocate normal cacheable
memory and try to set the page flags with set_pages_array_uc(),
which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on
the other side is only used with SWIOTLB!?
   [...] 
Could it be that the memory is finally mapped uncacheable by
   radeon_bo_kmap()/
ttm_bo_kmap()/..some other TTM functions../vmap()?
   
   Yeah, AFAICT, basically ttm_io_prot() defines the mapping
   attributes, and vmap() is used to enforce them for kernel mappings.
  Okay, that sounds like the approach used by arch/powerpc/mm/dma-
  noncoherent.c in my (green) ears. What about the PCIGART mode?
  Is the driver free to use cached memory in this mode?
 
 Yes, it assumes PCI(e) GART to be CPU cache coherent.
Okay. I guess it should be possible to modify it so that it makes use
of uncacheable memory - just for testing!?
PCIGART was working somehow on my platform up to the ~2.6.39 kernel,
i.e. I could login to GNOME and open a program until the machine
locked-up. :-)

[5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM-GTT copy 
0: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf148-0xf158)
   [...]
The VRAM-GTT copy totally puzzles me, as it returns a wrong page
address, but the offset is fine!?
   
   Maybe it's still the values from the GTT-VRAM test, i.e. either
   the GPU writes didn't make it to the memory mapped into the AGP
That's indeed the case. I changed the code so that gtt_map is
reinitialized with some magic value before the VRAM-GTT copy and the
debug output shows that the GPU writes don't make it to the memory -
or they are going to the wrong memory location, but that's harder to
track.

   GART (some AGP bridges are known to have issues with that) or the
   CPU doesn't see it.
  What is the workaround for such an AGP bridge? If there is one at
  all...
 
 The only workaround short of not using AGP would be not doing GPU-AGP
 transfers, but that's not implemented or even planned at all.
Okay.

   BTW, does your driver set cant_use_aperture, or is the linear
   aperture accessible by the CPU?
  The driver sets cant_use_aperture. I couldn't get it working at all
  without it.
 
 Does the hardware really not allow the CPU to access the linear aperture
 though? Because if it does, I wonder if that might be more reliable.
I'm afraid no, but I could try it out again.

BTW: I see that the uninorth driver defines needs_scratch_page. What
is this actually good for?

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: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 19 Apr 2012 14:41:16 +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 Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: 
   Von: Michel Dänzer mic...@daenzer.net
   On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: 
 Von: Michel Dänzer mic...@daenzer.net
 On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: 
  
  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)?
   
   If by 'former case' you mean userspace modifying memory mapped into
   the AGP GART, then no, this generally doesn't require special
   treatment on PowerMacs. (Ignoring the potential issue mentioned by
   Ben in this thread)
  I guess you refer to the ordering issue here.
 
 Yeah.
 
  The former case is an explanation, why I see data corruption with my
  AGPGART driver (more or less a copy of the uninorth driver) on my
  non-coherent platform. There are no cache flushes done for writes to
  already mapped pages.
 
 As I said, the radeon driver always maps AGP memory uncacheable for the
 CPU, so no such CPU cache flushes should be necessary.
I know. We also discussed this topic over two years ago. :-)

What I didn't understand yet is how this uncacheable memory is allocated
(well, I never took the time to look at this again). The functions in
ttm_page_alloc.c seem to allocate normal cacheable memory and try to set
the page flags with set_pages_array_uc(), which is more or less a no-op
on powerpc. ttm_page_alloc_dma.c on the other side is only used with
SWIOTLB!?

  I tested this with radeon.test=1, but I'm not even sure if this code
  changes already mapped pages [...]
 
 It does. radeon_bo_pin(..., RADEON_GEM_DOMAIN_GTT, ...) binds the buffer
 memory into the AGP GART, and the test only maps it to the CPU after
 that.
Could it be that the memory is finally mapped uncacheable by radeon_bo_kmap()/
ttm_bo_kmap()/..some other TTM functions../vmap()?

 I take it the test fails for you? How exactly?
I didn't work on the driver for a long time. It looks like I did the last
tests with a 2.6.39 kernel, where I changed the radeon test routine to not
stop on a failed copy. This way I could check for a pattern in the failed
copies.

Here is an excerpt of the 2.6.39 kernel log. IIRC the testing code changed
in the meantime so I guess it would make sense to repeat it with a newer
kernel version.

[5.185619] calling  agp_init+0x0/0x5c @ 1
[5.189816] Linux agpgart interface v0.103
[5.193993] initcall agp_init+0x0/0x5c returned 0 after 4076 usecs
[5.200359] calling  agp_articias_init+0x0/0x58 @ 1
[5.205411] agpgart-articias :00:00.0: MAI Logic Articia S chipset
[5.213555] agpgart-articias :00:00.0: configuring for size idx: 6
[5.220996] agpgart-articias :00:00.0: AGP aperture is 128M @ 0xc000
[5.228557] initcall agp_articias_init+0x0/0x58 returned 0 after 22629 usecs
[5.235791] calling  drm_core_init+0x0/0x16c @ 1
[5.240839] [drm] Initialized drm 1.1.0 20060810
[5.245623] initcall drm_core_init+0x0/0x16c returned 0 after 4937 usecs
[5.252510] calling  ttm_init+0x0/0x8c @ 1
[5.256908] initcall ttm_init+0x0/0x8c returned 0 after 197 usecs
[5.263172] calling  radeon_init+0x0/0x11c @ 1
[5.267731] [drm] radeon kernel modesetting enabled.
[5.274683] [drm] initializing kernel modesetting (RV280 0x1002:0x5960).
[5.281657] [drm] register mmio base: 0x8800
[5.286397] [drm] register mmio size: 65536
[5.327510] [drm] AGP mode requested: 1
[5.331485] agpgart-articias :00:00.0: AGP 1.0 bridge
[5.337071] agpgart-articias :00:00.0: putting AGP V2 device into 1x mode
[5.30] radeon :01:00.0: putting AGP V2 device into 1x mode
[5.350865] radeon :01:00.0: GTT: 128M 0xC000 - 0xC7FF
[5.357197] [drm] Generation 2 PCI interface, using max accessible memory
[5.364111] radeon :01:00.0: VRAM: 256M 0x8000 - 
0x8FFF (256M used)
[5.373060] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[5.379815] [drm] Driver supports precise vblank timestamp query.
[5.386068] [drm] radeon: irq initialized.
[5.390264] [drm] Detected VRAM RAM=256M, BAR=128M
[5.395177] [drm] RAM width 128bits DDR
[5.399322] [TTM] Zone  kernel: Available graphics memory: 380684 kiB.
[5.406047] [TTM] Zone highmem

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Fri, 20 Apr 2012 15:18:16 +0200
 Von: Michel Dänzer mic...@daenzer.net
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: linuxppc-dev@lists.ozlabs.org
 Betreff: Re: PowerPC radeon KMS - is it possible?

 On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote: 
   Von: Michel Dänzer mic...@daenzer.net
   On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: 

The former case is an explanation, why I see data corruption
with my AGPGART driver (more or less a copy of the uninorth
driver) on my non-coherent platform. There are no cache flushes
done for writes to already mapped pages.
   
   As I said, the radeon driver always maps AGP memory uncacheable for
   the CPU, so no such CPU cache flushes should be necessary.
  I know. We also discussed this topic over two years ago. :-)
  
  What I didn't understand yet is how this uncacheable memory is
  allocated (well, I never took the time to look at this again). The
  functions in ttm_page_alloc.c seem to allocate normal cacheable
  memory and try to set the page flags with set_pages_array_uc(),
  which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on
  the other side is only used with SWIOTLB!?
 [...] 
  Could it be that the memory is finally mapped uncacheable by
 radeon_bo_kmap()/
  ttm_bo_kmap()/..some other TTM functions../vmap()?
 
 Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes,
 and vmap() is used to enforce them for kernel mappings.
Okay, that sounds like the approach used by arch/powerpc/mm/dma-
noncoherent.c in my (green) ears. What about the PCIGART mode?
Is the driver free to use cached memory in this mode?

  Here is an excerpt of the 2.6.39 kernel log. IIRC the testing code
  changed in the meantime so I guess it would make sense to repeat it
  with a newer kernel version.
 
 I was going to suggest that. :)
As expected. :-)

  [5.490569] [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: 
  Got 0xf13268c0, expected 0xf1326160 (GTT map 0xf1326000-0xf1426000)
  [5.503397] [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: 
  Got 0xf13268c4, expected 0xf1326164 (GTT map 0xf1326000-0xf1426000)
  [5.516202] [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: 
  Got 0xf13268c0, expected 0xf1326168 (GTT map 0xf1326000-0xf1426000)
  [5.528993] [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: 
  Got 0xf13268c4, expected 0xf132616c (GTT map 0xf1326000-0xf1426000)
 [...] 
  [5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM-GTT copy 0: 
  Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf148-0xf158)
 
  For the GTT-VRAM copy it looks like the AGPGART driver at least
  gets the graphics aperture translation table right, as both the
  returned and expected values are within a page. But the page offset
  of the returned values (0x8c0, 0x8c4) makes me wonder whether I'm
  fooled by a hardware bug or a cache coherency problem.
 
 Hard to say... at least it managed to transfer the first 352 bytes
 correctly. ;)
Better than nothing! :-)

  The VRAM-GTT copy totally puzzles me, as it returns a wrong page
  address, but the offset is fine!?
 
 Maybe it's still the values from the GTT-VRAM test, i.e. either the GPU
 writes didn't make it to the memory mapped into the AGP GART (some AGP
Good point. Maybe I should explicitly clear the gtt_map before the
VRAM-GTT copy test is executed.

 bridges are known to have issues with that) or the CPU doesn't see it.
What is the workaround for such an AGP bridge? If there is one at all...

 BTW, does your driver set cant_use_aperture, or is the linear aperture
 accessible by the CPU?
The driver sets cant_use_aperture. I couldn't get it working at all
without it.

regards,
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: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 19 Apr 2012 08:32:51 +0200
 Von: Michel Dänzer mic...@daenzer.net
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: ojordan12...@hotmail.co.uk, sch...@linux-m68k.org, 
 linuxppc-dev@lists.ozlabs.org
 Betreff: Re: PowerPC radeon KMS - is it possible?

 On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: 
   Von: Michel Dänzer mic...@daenzer.net
   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,
 
 Ah, right, that probably explains why the map_page_into_agp change
 doesn't make any difference.
 
 
  but is there any code in the driver that handles the former case (or
  isn't this necessary on PPC Macs)?
 
 If by 'former case' you mean userspace modifying memory mapped into the
 AGP GART, then no, this generally doesn't require special treatment on
 PowerMacs. (Ignoring the potential issue mentioned by Ben in this
 thread)
I guess you refer to the ordering issue here.

The former case is an explanation, why I see data corruption with my
AGPGART driver (more or less a copy of the uninorth driver) on my
non-coherent platform. There are no cache flushes done for writes to
already mapped pages.
I tested this with radeon.test=1, but I'm not even sure if this code
changes already mapped pages (all of this makes it hard to tell for
me whether I stumble over a severe hardware error and/or a simple
coherency problem).

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).
 
 Not that I know of.
 
 Note that this isn't necessarily the only possible approach for
 addressing this problem. The driver knows which memory buffers are used
 by a GPU command stream sequence, so it should be able to take any
 measures necessary to ensure the device sees their contents as of when
 the command stream was submitted.
Good to hear! Anyway the TTM backend and the KMS drivers are a way
too complex for me so that I can only hope there will be a solution
for non-coherent platforms someday. :-)

Thanks for the clarification!

Gerhard
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!  

Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PowerPC radeon KMS - is it possible?

[Gerhard Pircher]

 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?

[Gerhard Pircher]

 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 00/14] Sort out i8253 and PC speaker locking and headers

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Fri, 3 Jun 2011 19:00:38 +0100
 Von: Ralf Baechle r...@linux-mips.org
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: linux-m...@linux-mips.org, linuxppc-dev@lists.ozlabs.org, 
 linux-al...@vger.kernel.org, linux-a...@vger.kernel.org, 
 linux-ker...@vger.kernel.org, Thomas Gleixner t...@linutronix.de, Benjamin 
 Herrenschmidt b...@kernel.crashing.org
 Betreff: Re: [patch 00/14] Sort out i8253 and PC speaker locking and headers

 On Thu, Jun 02, 2011 at 09:11:19PM +0200, Gerhard Pircher wrote:
 
   #if defined(CONFIG_MIPS) || defined(CONFIG_X86)
   /* Use the global PIT lock ! */
   #include asm/i8253.h
   #else
   #include asm/8253pit.h
   static DEFINE_RAW_SPINLOCK(i8253_lock);
   #endif
   
   sound/drivers/pcsp/pcsp.h:
   
   #if defined(CONFIG_MIPS) || defined(CONFIG_X86)
   /* Use the global PIT lock ! */
   #include asm/i8253.h
   #else
   #include asm/8253pit.h
   static DEFINE_RAW_SPINLOCK(i8253_lock);
   
   $ git grep -F pcsp.h sound/drivers/pcsp
   sound/drivers/pcsp/pcsp.c:#include pcsp.h
   sound/drivers/pcsp/pcsp_input.c:#include pcsp.h
   sound/drivers/pcsp/pcsp_lib.c:#include pcsp.h
   sound/drivers/pcsp/pcsp_mixer.c:#include pcsp.h
   $ git grep -w i8253_lock sound/drivers/pcsp/
   sound/drivers/pcsp/pcsp.h:static DEFINE_RAW_SPINLOCK(i8253_lock);
   sound/drivers/pcsp/pcsp_input.c:   
 raw_spin_lock_irqsave(i8253_lock,
   flags
   sound/drivers/pcsp/pcsp_input.c:   
   raw_spin_unlock_irqrestore(i8253_lock, 
   sound/drivers/pcsp/pcsp_lib.c: 
 raw_spin_lock_irqsave(i8253_lock,
   flags
   sound/drivers/pcsp/pcsp_lib.c: 
   raw_spin_unlock_irqrestore(i8253_lock, 
   sound/drivers/pcsp/pcsp_lib.c:  raw_spin_lock(i8253_lock);
   sound/drivers/pcsp/pcsp_lib.c:  raw_spin_unlock(i8253_lock);
   sound/drivers/pcsp/pcsp_lib.c:  raw_spin_lock(i8253_lock);
   sound/drivers/pcsp/pcsp_lib.c:  raw_spin_unlock(i8253_lock);
   
   Locks are great, everybody should have their own lock!
   
   $ find . -name 8253pit.h
   ./arch/powerpc/include/asm/8253pit.h
   ./arch/alpha/include/asm/8253pit.h
   $ cat arch/*/include/asm/8253pit.h
   /*
* 8253/8254 Programmable Interval Timer
*/
   /*
* 8253/8254 Programmable Interval Timer
*/
   $
   
   Eh...
   
   $ git grep -w PCSPKR_PLATFORM 
   arch/mips/Kconfig:  select PCSPKR_PLATFORM
   arch/mips/Kconfig:  select PCSPKR_PLATFORM
   arch/mips/Kconfig:  select PCSPKR_PLATFORM
   arch/powerpc/platforms/amigaone/Kconfig:select PCSPKR_PLATFORM
   drivers/input/misc/Kconfig: depends on PCSPKR_PLATFORM
   init/Kconfig:config PCSPKR_PLATFORM
   sound/drivers/Kconfig:  depends on PCSPKR_PLATFORM  X86 
   HIGH_RES_TIMERS
   
   So the status is:
   
Alpha:   There is no PCSPKR_PLATFORM so while a platform device is
 being installed no drivers will be built.  I don't know
 which Alpha platforms or even if all of Alpha should be
 doing a PCSPKR_PLATFORM so I haven't even tried to sort
 this.
ARM: No PC speaker supported, yeah :)
PowerPC: Should compile but the locking is wrong but only the 
 AmigaOne platforms should be affected.
  The Kconfig dependencies cleanup patch for CHRP, PSERIES, etc. should
  also apply to the AmigaOne. Can you resend it with a fix for the
  AmigaOne, or should I send a patch?
 
 I can sort that; it's easy enough.
Thanks a lot!

  I'll check next week, if the PC speaker is still working on my
  AmigaOne.
 
 I can't imagine that it's going to break - the code is sorta simple ;-)
That's true, but testing the most recent Linux kernel on the AmigaOne is
never wrong. :-)

 One obscurity I noticed is this bit in the amigaone.dts:
 
 timer@40 {
 // Also adds pcspkr to platform devices.
 compatible = pnpPNP,100;
 reg = 1 0x0040 0x0020;
 };
 
 Shouldn't that rather be something like the following?
 
 pcspeaker@61 {
 device_type = sound;
 compatible = pnpPNP,800;
 reg = 1 0x61 1;
 };
 
 pnpPNP,100 is the i8253 timer as I understand and pnpPNP,800 the PC
 speaker.
 If you interpret pnpPNP,100 to imply the presence of a PC speaker you
 can't express a system that has a i8253 but no PCspeaker in a DT so
 maybe amigaone.dts and arch/powerpc/kernel/setup-common.c should be
 changed to use pnpPNP,800 instead?

That would be cleaner, but I guess it would break CHRP and PSERIES.
These platforms probably only provide a pnpPNP,100 entry in the device
tree (at least that's the case on the Pegasos2 CHRP machine AFAICT).

Gerhard
-- 
NEU: FreePhone - kostenlos mobil telefonieren!  
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch 00/14] Sort out i8253 and PC speaker locking and headers

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 01 Jun 2011 19:04:56 +0100
 Von: r...@linux-mips.org
 An: linux-ker...@vger.kernel.org, linux-a...@vger.kernel.org, 
 linux-al...@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
 linux-m...@linux-mips.org
 Betreff: [patch 00/14] Sort out i8253 and PC speaker locking and headers

 No longer terribly relevant these days but still broken and just an
 eyesore mess of neglience just as I've already raised it a few days 
 ago.  Time to sort this.
 
 drivers/input/misc/pcspkr.c:
 
 #if defined(CONFIG_MIPS) || defined(CONFIG_X86)
 /* Use the global PIT lock ! */
 #include asm/i8253.h
 #else
 #include asm/8253pit.h
 static DEFINE_RAW_SPINLOCK(i8253_lock);
 #endif
 
 sound/drivers/pcsp/pcsp.h:
 
 #if defined(CONFIG_MIPS) || defined(CONFIG_X86)
 /* Use the global PIT lock ! */
 #include asm/i8253.h
 #else
 #include asm/8253pit.h
 static DEFINE_RAW_SPINLOCK(i8253_lock);
 
 $ git grep -F pcsp.h sound/drivers/pcsp
 sound/drivers/pcsp/pcsp.c:#include pcsp.h
 sound/drivers/pcsp/pcsp_input.c:#include pcsp.h
 sound/drivers/pcsp/pcsp_lib.c:#include pcsp.h
 sound/drivers/pcsp/pcsp_mixer.c:#include pcsp.h
 $ git grep -w i8253_lock sound/drivers/pcsp/
 sound/drivers/pcsp/pcsp.h:static DEFINE_RAW_SPINLOCK(i8253_lock);
 sound/drivers/pcsp/pcsp_input.c:raw_spin_lock_irqsave(i8253_lock,
 flags
 sound/drivers/pcsp/pcsp_input.c:   
 raw_spin_unlock_irqrestore(i8253_lock, 
 sound/drivers/pcsp/pcsp_lib.c:  raw_spin_lock_irqsave(i8253_lock,
 flags
 sound/drivers/pcsp/pcsp_lib.c: 
 raw_spin_unlock_irqrestore(i8253_lock, 
 sound/drivers/pcsp/pcsp_lib.c:  raw_spin_lock(i8253_lock);
 sound/drivers/pcsp/pcsp_lib.c:  raw_spin_unlock(i8253_lock);
 sound/drivers/pcsp/pcsp_lib.c:  raw_spin_lock(i8253_lock);
 sound/drivers/pcsp/pcsp_lib.c:  raw_spin_unlock(i8253_lock);
 
 Locks are great, everybody should have their own lock!
 
 $ find . -name 8253pit.h
 ./arch/powerpc/include/asm/8253pit.h
 ./arch/alpha/include/asm/8253pit.h
 $ cat arch/*/include/asm/8253pit.h
 /*
  * 8253/8254 Programmable Interval Timer
  */
 /*
  * 8253/8254 Programmable Interval Timer
  */
 $
 
 Eh...
 
 $ git grep -w PCSPKR_PLATFORM 
 arch/mips/Kconfig:  select PCSPKR_PLATFORM
 arch/mips/Kconfig:  select PCSPKR_PLATFORM
 arch/mips/Kconfig:  select PCSPKR_PLATFORM
 arch/powerpc/platforms/amigaone/Kconfig:select PCSPKR_PLATFORM
 drivers/input/misc/Kconfig: depends on PCSPKR_PLATFORM
 init/Kconfig:config PCSPKR_PLATFORM
 sound/drivers/Kconfig:  depends on PCSPKR_PLATFORM  X86 
 HIGH_RES_TIMERS
 
 So the status is:
 
  Alpha:   There is no PCSPKR_PLATFORM so while a platform device is
   being installed no drivers will be built.  I don't know
   which Alpha platforms or even if all of Alpha should be
   doing a PCSPKR_PLATFORM so I haven't even tried to sort
   this.
  ARM: No PC speaker supported, yeah :)
  PowerPC: Should compile but the locking is wrong but only the 
   AmigaOne platforms should be affected.
The Kconfig dependencies cleanup patch for CHRP, PSERIES, etc. should
also apply to the AmigaOne. Can you resend it with a fix for the
AmigaOne, or should I send a patch?
I'll check next week, if the PC speaker is still working on my AmigaOne.

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: Implement dma_mmap_coherent()

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Fri, 25 Mar 2011 17:50:06 +1100
 Von: Benjamin Herrenschmidt b...@kernel.crashing.org
 An: linuxppc-dev linuxppc-dev@lists.ozlabs.org
 CC: Takashi Iwai ti...@suse.de
 Betreff: [PATCH] powerpc: Implement dma_mmap_coherent()

 This is used by Alsa to mmap buffers allocated with dma_alloc_coherent()
 into userspace. We need a special variant to handle machines with
 non-coherent DMAs as those buffers have special virt addresses and
 require non-cachable mappings
 
 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
 ---
 
 Dunno if anybody with CONFIG_NOT_COHERENT_CACHE has some audio device
 that uses dma buffers (ie not usb-audio) and wants to try that out...
 should fix a long standing problem.

Compilation fails here with these error messages:

   CC  arch/powerpc/mm/dma-noncoherent.o
 arch/powerpc/mm/dma-noncoherent.c: In function ‘__dma_get_coherent_pfn’:
 arch/powerpc/mm/dma-noncoherent.c:413: error: invalid operands to binary  
 (have ‘void *’ and ‘int’)
 cc1: warnings being treated as errors
 arch/powerpc/mm/dma-noncoherent.c:414: error: passing argument 2 of 
 ‘pud_offset’ makes integer from pointer without a cast
 arch/powerpc/mm/dma-noncoherent.c:415: error: passing argument 2 of 
 ‘pmd_offset’ makes integer from pointer without a cast
 arch/powerpc/mm/dma-noncoherent.c:416: error: invalid operands to binary  
 (have ‘void *’ and ‘int’)
 make[1]: *** [arch/powerpc/mm/dma-noncoherent.o] Fehler 1
 make: *** [arch/powerpc/mm] Fehler 2

Anyway, it compiles with explicit type casts and I could test it on my
semi-noncoherent AmigaOne. So far it works just fine with the VIA onboard
sound and a Soundblaster Live PCI card.

Thanks a lot for the fix!

regards,
Gerhard

-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!   
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: any chance to use a modern linux kernel on Pegasos1 G3 ?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 17 Mar 2011 00:39:00 +0100
 Von: nello martuscielli ppc.ad...@gmail.com
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: acrux...@libero.it, linuxppc-dev@lists.ozlabs.org
 Betreff: Re: any chance to use a modern linux kernel on Pegasos1 G3 ?

 hi all,
 
 here instead the log from serial debug console booting the last
 working kernel i.e. linux-2.16.62 compiled with arch=ppc .
 
 
 [...]
 do_load: dev=/ide/disk:0 dlen=11 args=CRUX root=/dev/hdb
 video=radeonfb:800x600 alen=41
 do_load: alstr=
 try_load: dev=/ide/disk:0 dlen=11 args=CRUX root=/dev/hdb
 video=radeonfb:800x600 alen=41
 create_well_formed_chain: pkg=0xFD57D58 parent=0xFD53B90
 currpkg=0xFD53B90 inst=0xFE6EE50
 pkg=/pci@8000 parent=/ currpkg=/ currinst=/
 create_well_formed_chain: pkg=0xFD53B90 parent=0x0 currpkg=0xFD53B90
 inst=0xFE6EE50
 pkg=/ parent= currpkg=/ currinst=/
 pkg=0xFD57D58:/pci@8000 parent=0xFE6EE50:/
 inst=0xFE6EEA8:/pci@8000 instparent=0xFE6EE50
 ata_disk_open: pkg=0xFD5B870 parent=0xFD5B2C8
 ata_disk_open: CTLR=0x0 ID=0x0
 ata_disk_open: args=0
 deblocker open
 ata_disk_max_transfer: 512
 deblocker open: block-size=0x200 max-transfer=0x200
 deblocker open: return 0
 open-package: ret=0:no error r=-1
 ata_disk_open: $open-package deblocker ret=0
 ata_disk_open: deblocker=0xFE6EFC8
 disk-label open
 disk-label open: self=0xFE702B0 s-buf=0xFE71000
 disk-label open: return 0
 open-package: ret=0:no error r=-1
 ata_disk_open: $open-package disk-label ret=0
 ata_disk_open: disklabel=0xFE70258
 disk-label load: addr=0x40 loadargs=CRUX root=/dev/hdb
 video=radeonfb:800x600 args=0,CRUX root=/dev/hdb
 video=radeonfb:800x600
 file_system: e=0xFD8 disk=0xFE6EF58 loc=0x0 start=0x0
 path=0xFE703C0 buf=0xFE71000 size=512
 file_system: probing filesys dos-partition
 
 dos_partition: enter
 dos-partition: boot_sect_sig0/1=0x55.0xAA jump=0x0 boot_signature=0x0
 drive_number=0x0
 dos_partition: partition=0 size=0x32F8E start=0x3F typ=0x6
 flag=0x80 shd=0x1 ssect=0x1 scyl=0x0 ehd=0xFE esect=0x3F ecyl=0xC
 file_system: e=0xFD8 disk=0xFE6EF58 loc=0x7E00 start=0x3F
 path=0xFE703C2 buf=0xFE71000 size=512
 file_system: probing filesys dos-partition
 file_system: probing filesys dos-fat
 file_system: return end (-4089)
 file_system: return end (-4089)
 disk-label return len=1782093 ret=end (-4089)
 ata_disk_close
 disk-label close:
 checking exec type Fcode
 fcode_is_exec: load=0x40 loadlen=1782093
 checking exec type Forth
 checking exec type ELF
 f_go:
 checking exec type Fcode
 fcode_is_exec: load=0x40 loadlen=1782093
 checking exec type Forth
 checking exec type ELF
 alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
 alloc_constrained: min 0x0, max 0x, align 0x1000, mask
 0x, size 0x7E, addr 0x30
 alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
 0xFD54910 u2 0xFD54914 u3 0xFD54918
 alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x30
 size 0xFD0
 alloc_constrained: fsblock 0x0
 alloc_constrained: addr[] 0x30
 alloc_constrained: bsize[] 0xFD0
 alloc_constrained: passed min check
 alloc_constrained: addr 0x30, align 0xFFF, off 0x69696969
 sum 0x0
 alloc_constrained: passed align check
 alloc_constrained: passed max check
 alloc_constrained: passed mask check
 alloc_constrained: passed full size check
 alloc_constrained: passed size check
 
 
 i'm not an expert but from a quick logs comparison I saw two times the
 alloc_aligned,alloc_constrained section instead in the working one i
 see it only one time.
 Maybe it's an usefull observation.

Well, I never put my hands on an OpenFirmware machine, but I could
imagine that this is an image loading problem.
Various PPC Linux related websites suggest to set a different load base
for the kernel image on Pegasos machines:

setenv load-base 0x400

Does that work on the Pegasos1?

BTW do you get any debug output from a recent kernel on serial port
(with udbg)?

regards,
Gerhard
-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!   
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: any chance to use a modern linux kernel on Pegasos1 G3 ?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 15 Mar 2011 17:44:49 +0100
 Von: nello martuscielli ppc.ad...@gmail.com
 An: 
 CC: linuxppc-dev@lists.ozlabs.org, acrux @ cruxppc acrux...@libero.it
 Betreff: Re: any chance to use a modern linux kernel on Pegasos1 G3 ?

 ok, it seems that no one is interested to fix Pegasos1 G3 600MHz
 support.
 
 But if someone is capable (i don't have this skill) here what it
 happens reading from serial debug console untill it freezes with
 linux-2.6.36.4
 
 Pegasos Boot Strap (c) 2002 bplan GmbH
 Running on CPU PVR:00083311
 PLL setting : 0001
 Enable L1 ICache...   
 Done.
 Setting ROM Defaults...   
 Done.
 Configuring SDRAM...
 0800
 1000
 Delaying...Done.
 RAMSIZE = 1800
 0004
 Reading W83194 : 00FF 
 Done.
 Setting Front Side Bus to 100MHz...   
 Done.
 Releasing IDE reset ...   
 Done.
 Configuring Legacy Devices
 Initializing KBD...   
 Done.
 PLL setting : 0003
 1000
 Done.
 
 BIOS: Stage 2 entered arg(FFFC,,1800)
 BIOS: MachineInfo at 0E68
 BIOS: set MemPool limit to BAT size (old=1800 new=1000)
 BIOS: 0F6FFFE8 bytes added to mempool
 LoadFromRFS: starting
 LoadFromRFS: lib module 00 has abs load adr at 00C0
 CopyModule: start
 CopyModule: load address : 00C0
 CopyModule: copy module to ram...done
 ModuleCopy: expanding... done
 LoadFromRFS: 0001 modules out of 0001 loaded
 InitLib: start
 InitLib: call module as OF
 allocated g_e=0xFD8 (len=19232)
 install_root: pkg=0xFD53B90
 after init_environ e=0xFD8
 running nvramrc...
 after running nvramrc
 no/bad nvramrc - performing default startup script
 Bus addresses:
253@2
 I/O addresses:
   7936@FE002100
 Memory addresses:
   127M@8804
   1.3G@9800
 Prefetchable memory addresses:
 install_ata_disk_driver: reg=0x1000
 init_drive: reset controller 0x1000/0x100E
 init_drive: allow 4-bits for heads
 init_drive: select drive 0
 init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x0 cyl_hi=0x0
 init_drive: error=0x1 status=0x50 status2=0x50
 init_drive: identify drive: atapi=0
 install_ata_disk_driver: return no error (0)
 install_ata_disk_driver: reg=0x1000
 init_drive: allow 4-bits for heads
 init_drive: select drive 1
 init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x14 cyl_hi=0xEB
 init_drive: error=0x1 status=0x0 status2=0x0
 init_drive: identify drive: atapi=1
 atapi_cmd: cmdlen=12
 atapi_cmd: inlen=8 len=65534
 install_ata_disk_driver: return no error (0)
 install_ata_disk_driver: reg=0x1010
 init_drive: reset controller 0x1010/0x101E
 init_drive: allow 4-bits for heads
 init_drive: select drive 0
 init_drive: seccnt=0x20 sector=0x20 cyl_lo=0x20 cyl_hi=0x20
 init_drive: error=0x20 status=0x20 status2=0x20
 ATA-wait-ready: timeout: status=0x20
 init_drive: failed
 install_ata_disk_driver: reg=0x1010
 init_drive: allow 4-bits for heads
 init_drive: select drive 1
 init_drive: seccnt=0x30 sector=0x30 cyl_lo=0x30 cyl_hi=0x30
 init_drive: error=0x30 status=0x30 status2=0x30
 ATA-wait-ready: timeout: status=0x30
 init_drive: failed
 Bus addresses:
254@2
 I/O addresses:
  8@FE001038
   3072@FE001400
48K@FE004000
 Memory addresses:
   1792@A100
   1.2G@A0001000
 Prefetchable memory addresses:
12M@FD40
 F_INSTALL_CONSOLE: BEGIN
 F_INSTALL_CONSOLE: ALIASING SCREEN
 F_INSTALL_CONSOLE: ALIASING KBD
 EMULATION INT HANDLER ENTERED WITH:
 INT NO: 15
 
 EAX=0003 EBX= ECX= EDX= ESP= EBP= ESI= EDI=
  AX=4E08  BX=C505  CX=0003  DX=202A  SP=6CAA  BP=  SI=5CF9  DI=
  DS=C000  ES=BAD0  SS=C000  CS=F000  IP=FE15   NV UP -- PL ZR NA PE NC
 CS:IP = F4  C558 C000 0244 3000  01B4 AC63 0200
 UNHANDLED INT 10 FUNCTION 0007 WITHIN EMULATION
 F_INSTALL_CONSOLE: END
 auto-booting...
 do_load: dev= dlen=0 args= alen=0
 do_load: alstr=
 do_load: path doesn't start with /
 do_load: diag-device == eth
 do_load: no args..use the default
 do_load: diag-file == diag
 try_load: dev=eth dlen=3 args=diag alen=4
 entering main read/eval loop...
 
 [...]
 atapi_cmd: cmdlen=12
 atapi_cmd: inlen=2048 len=2048
 iso_walk: read: name=zImage.chrp extent=0x44FD size=0x337272 ret=no
 error
 iso9660: return R_END
 file_system: return end (-4089)
 disk-label return len=3371634 ret=end (-4089)
 ata_disk_close
 disk-label close:
 checking exec type Fcode
 fcode_is_exec: load=0x40 loadlen=3371634
 checking exec type Forth
 checking exec type ELF
 f_go:
 checking exec type Fcode
 fcode_is_exec: load=0x40 loadlen=3371634
 checking exec type Forth
 checking exec type ELF
 alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
 alloc_constrained: min 

Re: any chance to use a modern linux kernel on Pegasos1 G3 ?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 15 Mar 2011 18:49:24 +0100
 Von: Sven Luther s...@z-innov.com
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: nello martuscielli ppc.ad...@gmail.com, linuxppc-dev@lists.ozlabs.org, 
 acrux...@libero.it
 Betreff: Re: any chance to use a modern linux kernel on Pegasos1 G3 ?

 On Tue, Mar 15, 2011 at 06:14:48PM +0100, Gerhard Pircher wrote:
[...]

  On the other side you mentioned this workaround in
  arch/ppc/kernel/prom_init.c to me some time ago:
  
  unsigned long __init prom_init(int r3, int r4, prom_entry pp) :
  node = call_prom(finddevice, 1, 1, /);
  rc = call_prom(getprop, 4, 1, node, model, model,
 sizeof(model));
  if (rc  0  !strncmp (model, Pegasos, 7)
   strncmp (model, Pegasos2, 8)) {
  /* Pegasos 1 has a broken translate method in the OF,
   * and furthermore the BATs are mapped 1:1 so the phys
   * address calculated above is correct, so let's use
   * it directly.
   */
  } else if (offset == 0) {
  /* If we are already running at 0xc000, we assume
 we were
   * loaded by an OF bootloader which did set a BAT for
 us.
   * This breaks OF translate so we force phys to be 0.
   */
  prom_print((already at 0xc000) phys=0\n);
  phys = 0;
  } else if (call_prom(getprop, 4, 1, prom_chosen, mmu,
   prom_mmu, sizeof(prom_mmu)) = 0) {
  prom_print( no MMU found\n);
  } else if (call_prom_ret(call-method, 4, 4, result,
 translate,
   prom_mmu, _stext, 1) != 0) {
  prom_print( (translate failed)\n);
  } else {
  /* We assume the phys. address size is 3 cells */
  phys = result[2];
  }
  
  Can anybody comment, if this broken translate method in the OF would
  still be needed for arch/powerpc?
 
 Well, since this is long dead hardware not produced anymore, i don't see
 how the OF could have unbroken itself by moving to powerpc.
 
 It has been age since i looked into this, but to the best of my knowledge
 (and i wrote the above code or at least the earlier versions) it should
 be still broken.
Any idea then, how the workaround can be ported to arch/powerpc/ or if
there is a better one available?

regards,
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 1/2] powerpc/boot/dts: Install dts from the right directory

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Sun, 09 Jan 2011 00:24:01 +
 Von: Ben Hutchings b...@decadent.org.uk
 An: Benjamin Herrenschmidt b...@kernel.crashing.org, Paul Mackerras 
 pau...@samba.org
 CC: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-dev@lists.ozlabs.org
 Betreff: [PATCH 1/2] powerpc/boot/dts: Install dts from the right directory

 The dts-installed variable is initialised using a wildcard path that
 will be expanded relative to the build directory.  Use the existing
 variable dtstree to generate an absolute wildcard path that will work
 when building in a separate directory.

Wouldn't this patch be a good candidate for the stable kernel series?

 Reported-by: Gerhard Pircher gerhard_pirc...@gmx.net
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 Tested-by: Gerhard Pircher gerhard_pirc...@gmx.net [against 2.6.32]
 ---
  arch/powerpc/boot/Makefile |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
 index 96deec6..8917816 100644
 --- a/arch/powerpc/boot/Makefile
 +++ b/arch/powerpc/boot/Makefile
 @@ -368,7 +368,7 @@ INSTALL := install
  extra-installed  := $(patsubst $(obj)/%, 
 $(DESTDIR)$(WRAPPER_OBJDIR)/%,
 $(extra-y))
  hostprogs-installed  := $(patsubst %, $(DESTDIR)$(WRAPPER_BINDIR)/%,
 $(hostprogs-y))
  wrapper-installed:= $(DESTDIR)$(WRAPPER_BINDIR)/wrapper
 -dts-installed:= $(patsubst $(obj)/dts/%, 
 $(DESTDIR)$(WRAPPER_DTSDIR)/%,
 $(wildcard $(obj)/dts/*.dts))
 +dts-installed:= $(patsubst $(dtstree)/%, 
 $(DESTDIR)$(WRAPPER_DTSDIR)/%,
 $(wildcard $(dtstree)/*.dts))
  
  all-installed:= $(extra-installed) $(hostprogs-installed)
 $(wrapper-installed) $(dts-installed)
  
 -- 
 1.7.2.3

Gerhard

-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!   
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Pegasos i8042 broken again

[Gerhard Pircher]

On Sat, 2010-10-09 at 20:37 -0500, pac...@kosh.dhis.org wrote:
 Pegasos has no keyboard again. I blame commit
 540c6c392f01887dcc96bef0a41e63e6c1334f01, which tries to find i8042 IRQs
 inthe device-tree but doesn't fall back to the old hardcoded 1 and 12 in
 all failure cases.
 
 Specifically, the case where the device-tree contains nothing matching
 pnpPNP,303 or pnpPNP,f03 doesn't seem to be handled well. It sort of
 falls through to the old code, but leaves the IRQs set to 0.
 
 The last time something like this happened, I submitted a patch:
 http://lists.ozlabs.org/pipermail/linuxppc-dev/2007-July/039988.html
 which got committed, but afterward I was scolded for working around a
 bug instead of fixing it in nvramrc.
 
 This time I just won't send my workaround patch, at least until it's
 decided that the kernel should be made to understand the device-tree as
 is.
 If it's decided instead that the firmware should be patched... well I
 just don't feel comfortable inventing my own patch for nvramrc, since
 it's written in a language I don't know and presumably could brick the
 machine if I get it wrong. Also I'm not even sure what the kernel is
 expecting to find there.

Is this a Pegasos 1 or Pegasos 2? I'm just curious, because some Pegasos 1
users told me that newer Linux kernels don't even boot on their machines.

regards,

Gerhard
-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: ALSA fixes for non-coherent ppc32 again

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 08 Jul 2009 16:13:10 +0200
 Von: Takashi Iwai ti...@suse.de
 An: Benjamin Herrenschmidt b...@kernel.crashing.org
 CC: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-...@ozlabs.org
 Betreff: Re: ALSA fixes for non-coherent ppc32 again

 At Wed, 08 Jul 2009 13:01:50 +1000,
 Benjamin Herrenschmidt wrote:
  
  On Mon, 2009-06-22 at 08:34 +1000, Benjamin Herrenschmidt wrote:
   On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote:
Hi,

Takashi Iwai posted patches to make ALSA work on non-coherent
PPC32 systems (almost exactly) a year ago. See here:
   
http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027

As far as I can see these patches never went upstream. Where
there any objections or did we just forget about them? It would
be cool, if the patches could be merged now, as at least two
platforms need this bugfix (namely Sam440 and AmigaOne).
   
   I definitely forgot about those... But I'm fine with what Takashi
   did for now, I can always make the powerpc helper for
   dma_mmap_coherent() smarter later on if necessary.
  
  BTW. Can you guys send a final patch for adding mmap_coherent to
  powerpc ? Please make so that the dma_mmap_coherent() function doesn't
  explose if dma_ops-mmap_coherent is NULL though (either fail
  gracefully or fallback to some standard mmap).
 
 The attached is the revised patch.  It falls backs to the standard
 mmap.
 
 The whole patch series are found in test/dma-fix branch of sound git
 tree below:
   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
 test/dma-fix
 
 I had no time to play cross-build yet, so it'd be helpful if someone
 can test it...
 (BTW, any good minimal gcc and binutils package for kernel builds for
  PPC32?)
Okay, I cross-build it on a x86 machine and tested it on my AmigaOne with
the VIA686 onboard sound and a Soundblaster 5.1. It worked fine after I
applied the ALSA: Fix SG-buffer DMA with non-coherent architectures
patch.

Thanks!

Gerhard

-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

How to correctly reassign PCI BARs

[Gerhard Pircher]

Hi,

I'm trying to implement some PCI quirks for the AmigaOne, as the
firmware puts PCI devices with 16 bit BARs too high in the PCI I/O
space (above 64k). Currently I'm just writing new values to the BARs
before the PCI layer actually probes and allocates them:

static void quirk_vt82c686_sound_iobases(struct pci_dev *dev)
{
if (!machine_is(amigaone))
return;

pci_write_config_dword(dev, 0x10, 0xdc00);
pci_write_config_dword(dev, 0x14, 0xe000);
pci_write_config_dword(dev, 0x18, 0x0330);
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, 
quirk_vt82c686_sound_iobases);

I wonder, if there is a better way to reassign PCI resources. Using
ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC) seems to be an alternative,
but it also relocates the BARs of the IDE controller, which operates
in compatible mode (I would like to keep it in this mode).
Is there a way to take out some PCI devices from the reassignment?

Gerhard

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: ALSA fixes for non-coherent ppc32 again

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 24 Jun 2009 11:47:13 +0200
 Von: Takashi Iwai ti...@suse.de
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: b...@kernel.crashing.org, linuxppc-...@ozlabs.org
 Betreff: Re: ALSA fixes for non-coherent ppc32 again

 At Wed, 24 Jun 2009 10:46:01 +0200,
 Gerhard Pircher wrote:
  
  
   Original-Nachricht 
   Datum: Tue, 23 Jun 2009 23:42:24 +0200
   Von: Gerhard Pircher gerhard_pirc...@gmx.net
   An: b...@kernel.crashing.org, ti...@suse.de
   CC: linuxppc-...@ozlabs.org
   Betreff: Re: ALSA fixes for non-coherent ppc32 again
  
   Okay, that's wrong. I somehow messed up the .config file. It doesn't
   compile, too.
  I got it to compile now and it seems to work fine. I overlooked a typo
  in sound/core/Makefile first (ifndef CONFIG_SND_NONCOHERNT_DMA.)
 
 Gah, thanks, fixed now on the git tree too.

The Kconfig option still needs to be fixed, otherwise SND_COHERENT_DMA
isn't selected for my PPC32  NOT_COHERENT_CACHE machine.

config SND_NONCOHERENT_DMA
def_bool n  -- should be y
depends on (PPC32  NOT_COHERENT_CACHE)...

BTW: Can you put me on CC: please, if you bring up this topic on
linux-arch or so?

Gerhard

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: ALSA fixes for non-coherent ppc32 again

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 23 Jun 2009 23:42:24 +0200
 Von: Gerhard Pircher gerhard_pirc...@gmx.net
 An: b...@kernel.crashing.org, ti...@suse.de
 CC: linuxppc-...@ozlabs.org
 Betreff: Re: ALSA fixes for non-coherent ppc32 again

 Okay, that's wrong. I somehow messed up the .config file. It doesn't
 compile, too.
I got it to compile now and it seems to work fine. I overlooked a typo
in sound/core/Makefile first (ifndef CONFIG_SND_NONCOHERNT_DMA.)
^
I vote for a merge, if the config option and the typo is fixed. Ben,
should I resend a properly formatted patch for the dma_mmap_coherent
implementation or can we take the patch I already sent?

Thanks!

Gerhard

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: ALSA fixes for non-coherent ppc32 again

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 22 Jun 2009 09:12:35 +0200
 Von: Takashi Iwai ti...@suse.de
 An: Benjamin Herrenschmidt b...@kernel.crashing.org
 CC: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-...@ozlabs.org
 Betreff: Re: ALSA fixes for non-coherent ppc32 again

 But, it'd be helpful if someone can test the patches above beforehand,
 of course :)
Okay, I checked out your test/dma-fix branch and reformatted your
dma_mmap_coherent for powerpc patch ( 
http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
 ) to
adapt it for dma_mapping_ops (please take a look at the patch below).
I also had to change def_bool n to def_bool y for SND_NONCOHERENT_DMA
to actually enable it.

Unfortunately the build process stops with these error messages here
(but compiles fine, if SND_COHERENT_DMA is not selected):

  CC [M]  sound/core/memalloc.o
  CC [M]  sound/core/sgbuf.o
sound/core/sgbuf.c: In function ‘snd_free_sgbuf_pages’:
sound/core/sgbuf.c:46: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:47: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:48: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:50: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:51: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:52: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:56: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:57: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c: In function ‘snd_malloc_sgbuf_pages’:
sound/core/sgbuf.c:78: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:81: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:82: error: implicit declaration of function 
‘snd_sgbuf_aligned_pages’
sound/core/sgbuf.c:83: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:84: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:84: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:87: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:88: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:91: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:103: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:107: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:112: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:113: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:115: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:116: error: increment of pointer to unknown structure
sound/core/sgbuf.c:116: error: arithmetic on pointer to an incomplete type
sound/core/sgbuf.c:121: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:127: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:128: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:128: error: dereferencing pointer to incomplete type
sound/core/sgbuf.c:132: error: dereferencing pointer to incomplete type

I also tried to compile it with the orginal dma_mmap_coherent for
powerpc patch, but that doesn't make a difference.

As the next step I applied the reformatted dma_mmap_coherent patch and
the following patches from your test/dma-fix branch to a 2.6.30-rc8
branch:
- ALSA: Remove old DMA-mmap code from arm/devdma.c
- ALSA: Fix SG-buffer DMA with non-coherent architectures
- ALSA: Fix mapping of DMA buffers

This one compiled fine, but ALSA didn't work. No kernel oops, just the
sound of silence. :)

Any idea what's wrong here or if I did something wrong?

Thanks!

Gerhard

---
 arch/powerpc/include/asm/dma-mapping.h |   14 ++
 arch/powerpc/kernel/dma.c  |   21 +
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/dma-mapping.h 
b/arch/powerpc/include/asm/dma-mapping.h
index 3d9e887..6fbeafe 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -89,6 +89,8 @@ struct dma_mapping_ops {
 struct dma_attrs *attrs);
 int(*addr_needs_map)(struct device *dev, dma_addr_t addr,
 size_t size);
+int(*mmap_coherent)(struct device *dev, struct vm_area_struct *vma,
+void *cpu_addr, dma_addr_t handle, size_t size);
 #ifdef CONFIG_PPC_NEED_DMA_SYNC_OPS
 void(*sync_single_range_for_cpu)(struct device *hwdev,
 dma_addr_t dma_handle, unsigned long offset,
@@ -301,6 +303,18 @@ static inline void dma_unmap_sg(struct device *dev, struct 
scatterlist *sg,
 dma_unmap_sg_attrs(dev, sg, nhwentries, direction, NULL);
 }
 
+static inline int dma_mmap_coherent(struct device *dev,
+struct vm_area_struct *vma,
+void *cpu_addr, dma_addr_t handle,
+size_t size

Re: ALSA fixes for non-coherent ppc32 again

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 23 Jun 2009 10:55:54 +0200
 Von: Gerhard Pircher gerhard_pirc...@gmx.net
 An: Takashi Iwai ti...@suse.de, b...@kernel.crashing.org
 CC: linuxppc-...@ozlabs.org
 Betreff: Re: ALSA fixes for non-coherent ppc32 again

 
  Original-Nachricht 
  Datum: Mon, 22 Jun 2009 09:12:35 +0200
  Von: Takashi Iwai ti...@suse.de
  An: Benjamin Herrenschmidt b...@kernel.crashing.org
  CC: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-...@ozlabs.org
  Betreff: Re: ALSA fixes for non-coherent ppc32 again
 
  But, it'd be helpful if someone can test the patches above beforehand,
  of course :)
 Okay, I checked out your test/dma-fix branch and reformatted your
 dma_mmap_coherent for powerpc patch (
 http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
  ) to
 adapt it for dma_mapping_ops (please take a look at the patch below).
 I also had to change def_bool n to def_bool y for SND_NONCOHERENT_DMA
 to actually enable it.
 
 Unfortunately the build process stops with these error messages here
 (but compiles fine, if SND_COHERENT_DMA is not selected):
 
   CC [M]  sound/core/memalloc.o
   CC [M]  sound/core/sgbuf.o
 sound/core/sgbuf.c: In function ‘snd_free_sgbuf_pages’:
 sound/core/sgbuf.c:46: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:47: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:48: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:50: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:51: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:52: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:56: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:57: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c: In function ‘snd_malloc_sgbuf_pages’:
 sound/core/sgbuf.c:78: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:81: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:82: error: implicit declaration of function
 ‘snd_sgbuf_aligned_pages’
 sound/core/sgbuf.c:83: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:84: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:84: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:87: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:88: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:91: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:103: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:107: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:112: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:113: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:115: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:116: error: increment of pointer to unknown structure
 sound/core/sgbuf.c:116: error: arithmetic on pointer to an incomplete type
 sound/core/sgbuf.c:121: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:127: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:128: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:128: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:132: error: dereferencing pointer to incomplete type
 
 I also tried to compile it with the orginal dma_mmap_coherent for
 powerpc patch, but that doesn't make a difference.
 
 As the next step I applied the reformatted dma_mmap_coherent patch and
 the following patches from your test/dma-fix branch to a 2.6.30-rc8
 branch:
 - ALSA: Remove old DMA-mmap code from arm/devdma.c
 - ALSA: Fix SG-buffer DMA with non-coherent architectures
 - ALSA: Fix mapping of DMA buffers
 
 This one compiled fine, but ALSA didn't work. No kernel oops, just the
 sound of silence. :)
Okay, that's wrong. I somehow messed up the .config file. It doesn't
compile, too.

Gerhard

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: ALSA fixes for non-coherent ppc32 again

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 22 Jun 2009 09:12:35 +0200
 Von: Takashi Iwai ti...@suse.de
 An: Benjamin Herrenschmidt b...@kernel.crashing.org
 CC: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-...@ozlabs.org
 Betreff: Re: ALSA fixes for non-coherent ppc32 again

 At Mon, 22 Jun 2009 08:34:38 +1000,
 Benjamin Herrenschmidt wrote:
  
  On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote:
   Hi,
   
   Takashi Iwai posted patches to make ALSA work on non-coherent PPC32
   systems (almost exactly) a year ago. See here:
  
   http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
   
   As far as I can see these patches never went upstream. Where there
   any objections or did we just forget about them? It would be cool,
   if the patches could be merged now, as at least two platforms need
   this bugfix (namely Sam440 and AmigaOne).
  
  I definitely forgot about those...
 
 Me, too, almost... :)
:)

  But I'm fine with what Takashi did
  for now, I can always make the powerpc helper for dma_mmap_coherent()
  smarter later on if necessary.
 
 I updated the patch series for 2.6.31, including sparc32, parisc, mips
 and sh support.  The patches are found in test/dma-fix branch of sound
 git tree:
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
 test/dma-fix
Thanks!

 The old patches for 2.6.30 is found at history/dma-fix-2.6.30 branch
 there, too.
 
 
 For merging to the upstream, we'll need definitely discussions on
 linux-arch ML or so, as once James Bottomley suggested.  I'll try to
 make it up once after the merge window.
 
 But, it'd be helpful if someone can test the patches above beforehand,
 of course :)
Sure, I'll give it a try until tomorrow.

Gerhard

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

ALSA fixes for non-coherent ppc32 again

[Gerhard Pircher]

Hi,

Takashi Iwai posted patches to make ALSA work on non-coherent PPC32
systems (almost exactly) a year ago. See here:
http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027

As far as I can see these patches never went upstream. Where there any
objections or did we just forget about them? It would be cool, if the
patches could be merged now, as at least two platforms need this bugfix
(namely Sam440 and AmigaOne).

Thanks!

Gerhard

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: killing use of ppc_md.init

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 18 Jun 2009 09:38:50 -0500
 Von: Kumar Gala ga...@kernel.crashing.org
 An: Gerhard Pircher gerhard_pirc...@gmx.net, Benjamin Herrenschmidt 
 b...@kernel.crashing.org
 CC: linuxppc-dev list linuxppc-...@ozlabs.org
 Betreff: killing use of ppc_md.init

 ppc_md.init only exists on ppc32 and seems like its pretty useless  
 today.  The users seem to fall into two classes:
 
 1. called to do of_platform_bus_probe() - most platforms use  
 machine_device_initcall() for this
 2. some platform init code which seems like it could move into  
 setup_arch().
 
 The second one seems to only be on amigaone and chrp.  Anyone know if  
 there is any harm in moving the amigaone_init() into  
 amigaone_setup_arch() and similarly on chrp chrp_init2() into  
 chrp_setup_arch().
I guess converting amigaone_init() to a machine_device_initcall() is the
easiest approach. I'll send a patch soon.

Gerhard

-- 
GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss
für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/amigaone: Convert amigaone_init() to a machine_device_initcall()

[Gerhard Pircher]

This allows to remove the ppc_md.init() hook in the setup code.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/platforms/amigaone/setup.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/amigaone/setup.c 
b/arch/powerpc/platforms/amigaone/setup.c
index e8bea5e..ca65d86 100644
--- a/arch/powerpc/platforms/amigaone/setup.c
+++ b/arch/powerpc/platforms/amigaone/setup.c
@@ -111,13 +111,16 @@ void __init amigaone_init_IRQ(void)
irq_set_default_host(i8259_get_host());
 }
 
-void __init amigaone_init(void)
+static int __init request_isa_regions(void)
 {
request_region(0x00, 0x20, dma1);
request_region(0x40, 0x20, timer);
request_region(0x80, 0x10, dma page reg);
request_region(0xc0, 0x20, dma2);
+
+   return 0;
 }
+machine_device_initcall(amigaone, request_isa_regions);
 
 void amigaone_restart(char *cmd)
 {
@@ -162,7 +165,6 @@ define_machine(amigaone) {
.name   = AmigaOne,
.probe  = amigaone_probe,
.setup_arch = amigaone_setup_arch,
-   .init   = amigaone_init,
.show_cpuinfo   = amigaone_show_cpuinfo,
.init_IRQ   = amigaone_init_IRQ,
.restart= amigaone_restart,
-- 
1.5.6.5

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/amigaone: Limit ISA I/O range to 4k in the device tree

[Gerhard Pircher]

The kernel reserves the I/O address space from 0x0 to 0xfff for legacy
ISA devices. Change the ranges property for the PCI2ISA bridge to match
the kernels behavior, even if the ranges property isn't used for now.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/boot/dts/amigaone.dts |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/amigaone.dts 
b/arch/powerpc/boot/dts/amigaone.dts
index 26549fc..49ac36b 100644
--- a/arch/powerpc/boot/dts/amigaone.dts
+++ b/arch/powerpc/boot/dts/amigaone.dts
@@ -70,8 +70,8 @@
devsel-speed = 0x0001;
min-grant = 0;
max-latency = 0;
-   /* First 64k for I/O at 0x0 on PCI mapped to 0x0 on 
ISA. */
-   ranges = 0x0001 0 0x0100 0 0x 
0x0001;
+   /* First 4k for I/O at 0x0 on PCI mapped to 0x0 on ISA. 
*/
+   ranges = 0x0001 0 0x0100 0 0x 
0x1000;
interrupt-parent = i8259;
#interrupt-cells = 2;
#address-cells = 2;
-- 
1.5.6.5

-- 
GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss
für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: Enable additional BAT registers in setup_745x_specifics()

[Gerhard Pircher]

Currently the kernel expects the additional four IBAT and DBAT registers
to be available, but doesn't enable these registers on 745x CPUs, which
have them disabled after reset. Thus set the HIGH_BAT_EN bit in HID0
register, if the corresponding MMU feature is defined.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/kernel/cpu_setup_6xx.S |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S 
b/arch/powerpc/kernel/cpu_setup_6xx.S
index 54f767e..1e9949e 100644
--- a/arch/powerpc/kernel/cpu_setup_6xx.S
+++ b/arch/powerpc/kernel/cpu_setup_6xx.S
@@ -239,6 +239,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_L3CR)
ori r11,r11,HID0_SGE | HID0_FOLD | HID0_BHTE
ori r11,r11,HID0_LRSTK | HID0_BTIC
orisr11,r11,hid0_...@h
+BEGIN_MMU_FTR_SECTION
+   orisr11,r11,hid0_high_...@h
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_USE_HIGH_BATS)
 BEGIN_FTR_SECTION
xorir11,r11,HID0_BTIC
 END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC)
-- 
1.5.6.5

-- 
GMX FreeDSL mit DSL 6.000 Flatrate und Telefonanschluss nur 17,95 Euro/mtl.!
http://dslspecial.gmx.de/freedsl-aktionspreis/?ac=OM.AD.PD003K11308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: DTS file PCI / i8259 for Xilinx ML510

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Sun, 15 Mar 2009 09:38:26 +0100
 Von: Roderick Colenbrander thunderbir...@gmx.net
 An: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-dev@ozlabs.org
 Betreff: Re: DTS file PCI / i8259 for Xilinx ML510

   At some point in the file they create some (dummy?) pcie section in
   which they define a uli1575, an isa bus and attached to that isa bus
   a i8259. Is this the correct way of doing things? The i8259 driver
   seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also
   defined below but how are those mapped to the south bridge? I have
   seen some code in kernel/isa-bridge, is that code indeed responsible
   for setting up these ports?
  Yes, the pcie node is the PCI host bridge node and the uli1571 node
  acts as PCI2ISA bridge node. AFAIK their ranges properties are parsed
  by pci_process_bridge_OF_ranges().
  IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only
  for now. The I/O addresses for the i8259 PIC are currently hardcoded
  and setup (request_resource()) in sysdev/i8259.c.
 
 I got the i8259 south bridge working now after adding an io_base_virt
 offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
 the troubles to add ppc32 support to isa-bridge.c? The whole point of
 the code is basically to remap the io memory to low addresses for these
 64-bit ppc systems (mainly freescale boards with a i8259 and pseries
 systems with a i8259).
pci_process_bridge_OF_ranges() should ioremap io_base_virt for you,
if your board has only one PCI I/O space. It also sets isa_io_base to
io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
PCI I/O address 0x0. Isn't that the case for your board?

 As far as I have seen it is only needed for i8259 interrupt controllers.
 Personally I think it would be better to pass a io base offset to
 i8259_setup or so. Or perhaps do some dts file parsing in i8259.c.
 I'm not sure what the proper layout would be for this in the dts file
 though.
I think adding an io base offset parameter to i8259_setup isn't the
right way to do it. I would expect other problems too, if ISA I/O space
isn't mapped 1:1 to PCI I/O space on a PPC32 system. Maybe a more
experienced kernel developer can comment on this?

 With those changes I mentioned to i8259.c I got some PCI devices of my
 ali m1553 south bridge working. The code is ugly and I need to do
 cleanups. When it is done I will submit some patches.
IMHO that doesn't matter, as long as it helps people to understand your
problem. :-)

regards,

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: DTS file PCI / i8259 for Xilinx ML510

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Sun, 15 Mar 2009 12:00:17 +0100
 Von: Roderick Colenbrander thunderbir...@gmx.net
 An: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-dev@ozlabs.org
 Betreff: Re: DTS file PCI / i8259 for Xilinx ML510

   I got the i8259 south bridge working now after adding an io_base_virt
   offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
   the troubles to add ppc32 support to isa-bridge.c? The whole point of
   the code is basically to remap the io memory to low addresses for
   these 64-bit ppc systems (mainly freescale boards with a i8259 and
   pseries systems with a i8259).
  pci_process_bridge_OF_ranges() should ioremap io_base_virt for you,
  if your board has only one PCI I/O space. It also sets isa_io_base to
  io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
  PCI I/O address 0x0. Isn't that the case for your board?
  
 
 Ah then perhaps that is my problem. I'm using my own pci implementation
 for Xilinx their plbv46 soft core. The soft core might be compatible
 with a generic ibm plb-pci bridge (sysdev/ppc44x_pci.c). Basically I'm
 doing something like which is done in powermac/pci.c e.g. creating the
 pci_controller and filling it with cfg_addr / cfg_data pointers, io
 ranges, resource ranges and so on. The data is obtained from the dts
 file but from some xilinx generated fields and doesn't have the generic
 ranges fields and some others. I guess it is time to fix this part of
 the DTS file.
I don't know much about this plb2pci bridge, but if you take a look at 
ppc4xx_probe_pci_bridge() in sysdev/ppc4xx_pci.c, you'll see that it
calls pci_process_bridge_OF_ranges() too. Thus the ranges properties
are required to setup PCI correctly.

 Some other issue I had which might be related to my DTS file bugs is
 some i/o port conflict. The M1553 south bridge is just a peripheral on
 the ML510 primary pci bus there are no PCI slots connected to it. There
 are four other pci slots of which two are directly connected to the fpga
 (they are on the same bus as the M1553) and two are connected using a
 pci-to-pci bridge because they use 5V instead of 3.3V. The bridge chip
 wanted 0x0-0xfff while some south bridge devices wanted low addresses
 (if I remember correctly the IDE controller wants 0x1f0-0x1f1 and some
 0x3** ports). This generated some Cannot allocate resource region ..
The I/O ports within 0x0-0xfff are somehow reserved for legacy ISA
devices (in the M1553 southbridge), if I remember the PCI spec correctly.
That will conflict with the PCI2PCI bridge anyway, if both claim PCI I/O
transactions for this range. I guess you have to relocate the PCI I/O
window of the PCI2PCI bridge.

 will remap messages from kernel/pci-common.c. This remapping didn't
 happen. Should a proper DTS file prevent this issue? If not where is the
 remapping done (I didn't see it). For that reason I'm ignoring the
 pci-to-pci bridge for now.
AFAIK bridge windows are not relocated. The firmware should setup them
correctly. Also, you don't have to add the PCI2PCI bridge to the DTS,
if the bridge uses the standardized register set to define the I/O and
memory windows. A general rule (for PCI) is to only define the
information that cannot be probed by the kernel itself.

regards,

Gerhard
-- 
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: DTS file PCI / i8259 for Xilinx ML510

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 12 Mar 2009 11:32:19 +0100
 Von: Roderick Colenbrander thunderbir...@gmx.net
 An: linuxppc-dev@ozlabs.org
 Betreff: DTS file PCI / i8259 for Xilinx ML510

 ...
 The freescale boards define the pci bus like below and connect ULI M1575
 peripherals to the i8259 controller. Regarding the entries in the pci
 interrupt-map what does the fourth column mean? According to source code
 it means 'interrupt specifier' but what does it mean? In a lot of cases
 it is 1.
IIRC the fourth column is the PCI interrupt line (INTA..D = 1..4). The
Freescale boards may have a number of onboard PCI devices, which are
usually connected to a single PCI interrupt line only (INTA). In this
case a PCI unit address (1. column) is specified only once within the
interrupt-map table and the corresponding interrupt specifier is set
to 1 for INTA.
On the other side PCI slots can have up to four entries (INTA..D) for a
specific PCI unit address.

Please take a look at this document here:
http://playground.sun.com/1275/practice/imap/imap0_9d.html

 Further I believe in this case the entries behind 'mpic' correspond to
 the inta/b/c/d lines, is that correct? On my board inta is connected to
 interrupt 5 (intb=4, intc=3, intd=2) of the xilinx intc, so I would need
 to use those numbers there for my board?
No, the last two columns specify the real interrupt (IRQ line, level or
edge triggered). They're values depend on the type of interrupt
controller and its #interrupt-cells property.

   pci0: p...@f8008000
   {
   device_type = pci;
   #interrupt-cells = 1;
   #size-cells = 2;
   #address-cells = 3;
   ..
   ..
   interrupt-map-mask = 0xff00 0 0 7;
   interrupt-map = 
   /* IDSEL 0x11 func 0 - PCI slot 1 */
   0x8800 0 0 1 mpic 2 1
   0x8800 0 0 2 mpic 3 1
   0x8800 0 0 3 mpic 4 1
   0x8800 0 0 4 mpic 1 1
   ..
   ..
   // IDSEL 0x1c  USB
   0xe000 0 0 1 i8259 12 2
   0xe100 0 0 2 i8259 9 2
   ;
 
 At some point in the file they create some (dummy?) pcie section in
 which they define a uli1575, an isa bus and attached to that isa bus a
 i8259. Is this the correct way of doing things? The i8259 driver seems
 to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also defined
 below but how are those mapped to the south bridge? I have seen some
 code in kernel/isa-bridge, is that code indeed responsible for setting
 up these ports?
Yes, the pcie node is the PCI host bridge node and the uli1571 node acts
as PCI2ISA bridge node. AFAIK their ranges properties are parsed by
pci_process_bridge_OF_ranges().
IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only
for now. The I/O addresses for the i8259 PIC are currently hardcoded and
setup (request_resource()) in sysdev/i8259.c.

   p...@0 {
   reg = 0 0 0 0 0;
   #size-cells = 2;
   #address-cells = 3;
   device_type = pci;
   ranges = 0x0200 0x0 0x8000
 0x0200 0x0 0x8000
 0x0 0x2000
 
 0x0100 0x0 0x
 0x0100 0x0 0x
 0x0 0x0010;
   uli1...@0 {
   reg = 0 0 0 0 0;
   #size-cells = 2;
   #address-cells = 3;
   ranges = 0x0200 0x0 0x8000
 0x0200 0x0 0x8000
 0x0 0x2000
 0x0100 0x0 0x
 0x0100 0x0 0x
 0x0 0x0010;
   i...@1e {
   device_type = isa;
   #interrupt-cells = 2;
   #size-cells = 1;
   #address-cells = 2;
   reg = 0xf000 0 0 0 0;
   ranges = 1 0 0x0100 0 0
 0x1000;
   interrupt-parent = i8259;
 
   i8259: interrupt-control...@20 {
   reg = 1 0x20 2
  1 0xa0 2
  1 0x4d0 2;
   

Re: NFS problems on a MPC5200-based board

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 12 Mar 2009 08:39:26 +1100
 Von: Benjamin Herrenschmidt b...@kernel.crashing.org
 An: Bartłomiej Sięka t...@semihalf.com
 CC: linuxppc-dev@ozlabs.org, gerhard_pirc...@gmx.net, Grant Likely 
 grant.lik...@secretlab.ca
 Betreff: Re: NFS problems on a MPC5200-based board

 On Wed, 2009-03-11 at 16:08 +0100, Bartłomiej Sięka wrote:
  Hi,
  
  This is a follow-up on NFS problems on an MPC5200-based board reported  
  here a while back:
  
 
 http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-to21750004.html#a21792612
  
  To recap: while using NFS, especially while mounting the root  
  filesystem over NFS, the system is really slow and displays a bunch of  
  nfs: server 192.168.1.1 not responding, still trying messages.  
  Sometimes it is able to get to the login prompt, sometimes not. In  
  cases where the login is successful, the system is still extremely  
  sluggish (console hangs for tens of seconds and longer).
  
  git bisect narrows down the troublesome commit as:
 
 Maybe you need to set CPU_FTR_NEED_COHERENT for the 5200 ?
I would say the same, as the patch just replicates the
CPU_FTR_NEED_COHERENT handling of the hash page table code.

regards,

Gerhard

  commit 4c456a67f501b8b15542c7c21c28812bf88f484b
  Author: Gerhard Pircher gerhard_pirc...@gmx.net
  Date:   Fri Jan 23 06:51:28 2009 +
  
  powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code
  
  _PAGE_COHERENT is now always set in _PAGE_RAM resp. PAGE_KERNEL.
  Thus it has to be masked out, if the BAT mapping should be non
  cacheable or CPU_FTR_NEED_COHERENT is not set.
  
  This will work on normal SMP setups because we force-set
  CPU_FTR_NEED_COHERENT as part of CPU_FTR_COMMON on SMP.
  
  Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
  Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
  
  
  We have tested recent mainline kernel (past 2.6.29-rc7) with the  
  4c456a6...
  commit reverted and NFS problems went away.
  
  Other people have also reported similar problems (original posters on  
  Cc):
 
 http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792825.html
 
 http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792612.html
  
  The commit in question does not look directly related to NFS/ 
  networking; moreover it is a fix for some other problem, so just  
  reverting it is not an option, it seems (?). So how do we go about  
  having NFS operational again? Any comments?
  
  Regards,
  Bartlomiej Sieka

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Does DRI/DRM still work on non-coherent DMA platforms?

[Gerhard Pircher]

Hi,

I heard rumors that DRI doesn't work on SAM440EP (onboard Radeon GPU)
boards. I had DRI halfway working on my AmigaOne (Radeon 9250) with an
early release candidate of the 2.6.25 kernel and IIRC this patch here
(manually applied):
http://kerneltrap.org/index.php?q=mailarchive/git-commits-head/2008/3/30/1301044

I just tested DRI again on my A1 (I don't have a SAM board) with
v2.6.29-rc6 and the machine looks up while starting the X server.
Curiously DRI seems to work, if I specify udbg-immortal on the
kernel command line and enable DRM debugging.
Did anyone try out DRI on a non-coherent DMA PPC platform and can
confirm that it still works?

best regards,

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v3 2/4] powerpc: Generic device tree for all AmigaOne boards

[Gerhard Pircher]

This device tree does not provide the correct CPU name, as various CPU
models and revisions are used in AmigaOnes. Also the PCI root node does
not contain a interrupt mapping property, as all boards have different
interrupt routing. However the kernel can do a 1:1 mapping of all PCI
interrupts, as only i8259 legacy interrupts are used.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/boot/dts/amigaone.dts |  173 
 1 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/amigaone.dts

diff --git a/arch/powerpc/boot/dts/amigaone.dts 
b/arch/powerpc/boot/dts/amigaone.dts
new file mode 100644
index 000..26549fc
--- /dev/null
+++ b/arch/powerpc/boot/dts/amigaone.dts
@@ -0,0 +1,173 @@
+/*
+ * AmigaOne Device Tree Source
+ *
+ * Copyright 2008 Gerhard Pircher (gerhard_pirc...@gmx.net)
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+   model = AmigaOne;
+   compatible = eyetech,amigaone;
+   coherency-off;
+   #address-cells = 1;
+   #size-cells = 1;
+
+   cpus {
+   #cpus = 1;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   c...@0 {
+   device_type = cpu;
+   reg = 0;
+   d-cache-line-size = 32;   // 32 bytes
+   i-cache-line-size = 32;   // 32 bytes
+   d-cache-size = 32768; // L1, 32K
+   i-cache-size = 32768; // L1, 32K
+   timebase-frequency = 0;   // 33.3 MHz, from U-boot
+   clock-frequency = 0;  // From U-boot
+   bus-frequency = 0;// From U-boot
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0 0;// From U-boot
+   };
+
+   p...@8000 {
+   device_type = pci;
+   compatible = mai-logic,articia-s;
+   bus-frequency = ;
+   bus-range = 0 0xff;
+   ranges = 0x0100 0 0x 0xfe00 0 0x00c0   
// PCI I/O
+ 0x0200 0 0x8000 0x8000 0 0x7d00   
// PCI memory
+ 0x0200 0 0x 0xfd00 0 0x0100; 
// PCI alias memory (ISA)
+   // Configuration address and data register.
+   reg = 0xfec00cf8 4
+  0xfee00cfc 4;
+   8259-interrupt-acknowledge = 0xfef0;
+   // Do not define a interrupt-parent here, if there is no
+   // interrupt-map property.
+   #address-cells = 3;
+   #size-cells = 2;
+
+   i...@7 {
+   device_type = isa;
+   compatible = pciclass,0601;
+   vendor-id = 0x1106;
+   device-id = 0x0686;
+   revision-id = 0x0010;
+   class-code = 0x00060100;
+   subsystem-id = 0;
+   subsystem-vendor-id = 0;
+   devsel-speed = 0x0001;
+   min-grant = 0;
+   max-latency = 0;
+   /* First 64k for I/O at 0x0 on PCI mapped to 0x0 on 
ISA. */
+   ranges = 0x0001 0 0x0100 0 0x 
0x0001;
+   interrupt-parent = i8259;
+   #interrupt-cells = 2;
+   #address-cells = 2;
+   #size-cells = 1;
+
+   dma-control...@0 {
+   compatible = pnpPNP,200;
+   reg = 1 0x 0x0020
+  1 0x0080 0x0010
+  1 0x00c0 0x0020;
+   };
+
+   i8259: interrupt-control...@20 {
+   device_type = interrupt-controller;
+   compatible = pnpPNP,000;
+   interrupt-controller;
+   reg = 1 0x0020 0x0002
+  1 0x00a0 0x0002
+  1 0x04d0 0x0002;
+   reserved-interrupts = 2;
+   #interrupt-cells = 2;
+   };
+
+   ti...@40 {
+   // Also adds pcspkr to platform devices.
+   compatible = pnpPNP,100

[PATCH v3 3/4] powerpc: Bootwrapper and serial console support for AmigaOne

[Gerhard Pircher]

This adds the bootwrapper for the cuImage target and a compatible property
check for pnpPNP,501 to the generic serial console support code.
The default link address for the cuImage target is set to 0x80. This
allows to boot the kernel with AmigaOS4's second level bootloader, which
always loads a uImage at 0x50.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/boot/Makefile  |5 -
 arch/powerpc/boot/cuboot-amigaone.c |   35 +++
 arch/powerpc/boot/serial.c  |3 ++-
 arch/powerpc/boot/wrapper   |3 +++
 4 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/boot/cuboot-amigaone.c

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e84df33..e4b1b97 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -70,7 +70,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c 
cuboot-85xx.c holly.c
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c 
\
virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
-   cuboot-acadia.c
+   cuboot-acadia.c cuboot-amigaone.c
 src-boot := $(src-wlib) $(src-plat) empty.c
 
 src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -274,6 +274,9 @@ image-$(CONFIG_STORCENTER)  += cuImage.storcenter
 image-$(CONFIG_MPC7448HPC2)+= cuImage.mpc7448hpc2
 image-$(CONFIG_PPC_C2K)+= cuImage.c2k
 
+# Board port in arch/powerpc/platform/amigaone/Kconfig
+image-$(CONFIG_AMIGAONE)   += cuImage.amigaone
+
 # For 32-bit powermacs, build the COFF and miboot images
 # as well as the ELF images.
 ifeq ($(CONFIG_PPC32),y)
diff --git a/arch/powerpc/boot/cuboot-amigaone.c 
b/arch/powerpc/boot/cuboot-amigaone.c
new file mode 100644
index 000..d502967
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-amigaone.c
@@ -0,0 +1,35 @@
+/*
+ * Old U-boot compatibility for AmigaOne
+ *
+ * Author: Gerhard Pircher (gerhard_pirc...@gmx.net)
+ *
+ *   Based on cuboot-83xx.c
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include stdio.h
+#include cuboot.h
+
+#include ppcboot.h
+
+static bd_t bd;
+
+static void platform_fixups(void)
+{
+   dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+   dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+   unsigned long r6, unsigned long r7)
+{
+   CUBOOT_INIT();
+   fdt_init(_dtb_start);
+   serial_console_init();
+   platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index 8b3607c..f2156f0 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -117,7 +117,8 @@ int serial_console_init(void)
if (devp == NULL)
goto err_out;
 
-   if (dt_is_compatible(devp, ns16550))
+   if (dt_is_compatible(devp, ns16550) ||
+   dt_is_compatible(devp, pnpPNP,501))
rc = ns16550_console_init(devp, serial_cd);
else if (dt_is_compatible(devp, marvell,mv64360-mpsc))
rc = mpsc_console_init(devp, serial_cd);
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 965c237..6170bbf 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -186,6 +186,9 @@ cuboot*)
 *-mpc85*|*-tqm85*|*-sbc85*)
 platformo=$object/cuboot-85xx.o
 ;;
+*-amigaone)
+link_address='0x80'
+;;
 esac
 ;;
 ps3)
-- 
1.5.3.4


-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v3 4/4] powerpc: Default config for AmigaOne boards

[Gerhard Pircher]

CONFIG_CC_OPTIMIZE_FOR_SIZE is selected, because otherwise the kernel
wouldn't boot. The AmigaOne's U-boot firmware seems to have a problem
loading uImages bigger than 1.8 MB.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/configs/amigaone_defconfig | 1636 +++
 1 files changed, 1636 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/configs/amigaone_defconfig

diff --git a/arch/powerpc/configs/amigaone_defconfig 
b/arch/powerpc/configs/amigaone_defconfig
new file mode 100644
index 000..b63cc38
--- /dev/null
+++ b/arch/powerpc/configs/amigaone_defconfig
@@ -0,0 +1,1636 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.29-rc3
+# Sun Feb  1 14:22:42 2009
+#
+# CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+CONFIG_6xx=y
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_8xx is not set
+# CONFIG_40x is not set
+# CONFIG_44x is not set
+# CONFIG_E200 is not set
+CONFIG_PPC_FPU=y
+CONFIG_ALTIVEC=y
+CONFIG_PPC_STD_MMU=y
+CONFIG_PPC_STD_MMU_32=y
+# CONFIG_PPC_MM_SLICES is not set
+# CONFIG_SMP is not set
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_CHECK_CACHE_COHERENCY=y
+CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
+# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
+CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_HARDIRQS=y
+# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
+CONFIG_IRQ_PER_CPU=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+CONFIG_OF=y
+CONFIG_PPC_UDBG_16550=y
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_GENERIC_BUG=y
+CONFIG_DEFAULT_UIMAGE=y
+# CONFIG_PPC_DCR_NATIVE is not set
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_AUDIT is not set
+
+#
+# RCU Subsystem
+#
+CONFIG_CLASSIC_RCU=y
+# CONFIG_TREE_RCU is not set
+# CONFIG_PREEMPT_RCU is not set
+# CONFIG_TREE_RCU_TRACE is not set
+# CONFIG_PREEMPT_RCU_TRACE is not set
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=15
+# CONFIG_GROUP_SCHED is not set
+# CONFIG_CGROUPS is not set
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
+# CONFIG_RELAY is not set
+CONFIG_NAMESPACES=y
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_USER_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL=y
+# CONFIG_EMBEDDED is not set
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_PCSPKR_PLATFORM=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_AIO=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_PCI_QUIRKS=y
+CONFIG_SLUB_DEBUG=y
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
+# CONFIG_SLOB is not set
+# CONFIG_PROFILING is not set
+CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
+CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
+CONFIG_HAVE_IOREMAP_PROT=y
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_ARCH_TRACEHOOK=y
+# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_BLOCK=y
+CONFIG_LBD=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BLK_DEV_INTEGRITY is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED=anticipatory
+# CONFIG_FREEZER is not set
+
+#
+# Platform support
+#
+CONFIG_PPC_MULTIPLATFORM=y
+CONFIG_CLASSIC32=y
+# CONFIG_PPC_CHRP is not set
+# CONFIG_MPC5121_ADS is not set
+# CONFIG_MPC5121_GENERIC is not set
+# CONFIG_PPC_MPC52xx is not set
+# CONFIG_PPC_PMAC is not set
+# CONFIG_PPC_CELL

[RFC] Error handling in *_add/find_bridges()

[Gerhard Pircher]

Hi!

I have a minor question about the error handling in the various 
*_add/find_bridges functions, which are used to detect and initialize
PHBs. AFAIK all of them return an error code that is never checked in
the platform setup code (e.g. when there is no memory for the
pci_controller struct).
Shouldn't the kernel panic (BUG();), when it can't initialize the PHB
for whatever reason and the platform depends on a working PCI bus?

Thanks!

regards,

Gerhard
-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

AmigaOne platform patches v2

[Gerhard Pircher]

Hi!

I updated the patches for the AmigaOne platform based on your comments.
The following changes were made compared to v1:

setup.c:
- replaced model entry in /proc/cpuinfo with a vendor entry
- replaced cache flushing code in amigaone_restart() with call to
__flush_disable_L1()
- removed feature fixup code in amigaone_probe(): only AmigaOnes with
G3 can run an unmodified kernel for now, until the PPC32 startup code
is reorganized to do the feature fixup after probe_machine()

amigaone.dts:
- removed nodes for probeable PCI devices
- removed device_type properties that are not used by the kernel

I didn't add an interrupt-map property yet. I would have to make 3
versions of the dts, if this is required.

Thanks!

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v2 3/4] Bootwrapper and serial console support for AmigaOne

[Gerhard Pircher]

This adds the bootwrapper for the cuImage target and a compatible property
check for pnpPNP,501 to the generic serial console support code.
The default link address for the cuImage target is set to 0x80. This
allows to boot the kernel with AmigaOS4's second level bootloader, which
always loads a uImage at 0x50.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/boot/Makefile  |5 -
 arch/powerpc/boot/cuboot-amigaone.c |   35 +++
 arch/powerpc/boot/serial.c  |3 ++-
 arch/powerpc/boot/wrapper   |3 +++
 4 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/boot/cuboot-amigaone.c

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e84df33..e4b1b97 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -70,7 +70,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c 
cuboot-85xx.c holly.c
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c 
\
virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
-   cuboot-acadia.c
+   cuboot-acadia.c cuboot-amigaone.c
 src-boot := $(src-wlib) $(src-plat) empty.c
 
 src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -274,6 +274,9 @@ image-$(CONFIG_STORCENTER)  += cuImage.storcenter
 image-$(CONFIG_MPC7448HPC2)+= cuImage.mpc7448hpc2
 image-$(CONFIG_PPC_C2K)+= cuImage.c2k
 
+# Board port in arch/powerpc/platform/amigaone/Kconfig
+image-$(CONFIG_AMIGAONE)   += cuImage.amigaone
+
 # For 32-bit powermacs, build the COFF and miboot images
 # as well as the ELF images.
 ifeq ($(CONFIG_PPC32),y)
diff --git a/arch/powerpc/boot/cuboot-amigaone.c 
b/arch/powerpc/boot/cuboot-amigaone.c
new file mode 100644
index 000..d502967
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-amigaone.c
@@ -0,0 +1,35 @@
+/*
+ * Old U-boot compatibility for AmigaOne
+ *
+ * Author: Gerhard Pircher (gerhard_pirc...@gmx.net)
+ *
+ *   Based on cuboot-83xx.c
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include stdio.h
+#include cuboot.h
+
+#include ppcboot.h
+
+static bd_t bd;
+
+static void platform_fixups(void)
+{
+   dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+   dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+   unsigned long r6, unsigned long r7)
+{
+   CUBOOT_INIT();
+   fdt_init(_dtb_start);
+   serial_console_init();
+   platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index 8b3607c..f2156f0 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -117,7 +117,8 @@ int serial_console_init(void)
if (devp == NULL)
goto err_out;
 
-   if (dt_is_compatible(devp, ns16550))
+   if (dt_is_compatible(devp, ns16550) ||
+   dt_is_compatible(devp, pnpPNP,501))
rc = ns16550_console_init(devp, serial_cd);
else if (dt_is_compatible(devp, marvell,mv64360-mpsc))
rc = mpsc_console_init(devp, serial_cd);
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 965c237..6170bbf 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -186,6 +186,9 @@ cuboot*)
 *-mpc85*|*-tqm85*|*-sbc85*)
 platformo=$object/cuboot-85xx.o
 ;;
+*-amigaone)
+link_address='0x80'
+;;
 esac
 ;;
 ps3)
-- 
1.5.3.4


-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v2 4/4] Default config for AmigaOne boards

[Gerhard Pircher]

CONFIG_CC_OPTIMIZE_FOR_SIZE is selected, because otherwise the kernel
wouldn't boot. The AmigaOne's U-boot firmware seems to have a problem
loading uImages bigger than 1.8 MB.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/configs/amigaone_defconfig | 1636 +++
 1 files changed, 1636 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/configs/amigaone_defconfig

diff --git a/arch/powerpc/configs/amigaone_defconfig 
b/arch/powerpc/configs/amigaone_defconfig
new file mode 100644
index 000..b63cc38
--- /dev/null
+++ b/arch/powerpc/configs/amigaone_defconfig
@@ -0,0 +1,1636 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.29-rc3
+# Sun Feb  1 14:22:42 2009
+#
+# CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+CONFIG_6xx=y
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_8xx is not set
+# CONFIG_40x is not set
+# CONFIG_44x is not set
+# CONFIG_E200 is not set
+CONFIG_PPC_FPU=y
+CONFIG_ALTIVEC=y
+CONFIG_PPC_STD_MMU=y
+CONFIG_PPC_STD_MMU_32=y
+# CONFIG_PPC_MM_SLICES is not set
+# CONFIG_SMP is not set
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_CHECK_CACHE_COHERENCY=y
+CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
+# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
+CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_HARDIRQS=y
+# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
+CONFIG_IRQ_PER_CPU=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+CONFIG_OF=y
+CONFIG_PPC_UDBG_16550=y
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_GENERIC_BUG=y
+CONFIG_DEFAULT_UIMAGE=y
+# CONFIG_PPC_DCR_NATIVE is not set
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_AUDIT is not set
+
+#
+# RCU Subsystem
+#
+CONFIG_CLASSIC_RCU=y
+# CONFIG_TREE_RCU is not set
+# CONFIG_PREEMPT_RCU is not set
+# CONFIG_TREE_RCU_TRACE is not set
+# CONFIG_PREEMPT_RCU_TRACE is not set
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=15
+# CONFIG_GROUP_SCHED is not set
+# CONFIG_CGROUPS is not set
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
+# CONFIG_RELAY is not set
+CONFIG_NAMESPACES=y
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_USER_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL=y
+# CONFIG_EMBEDDED is not set
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_PCSPKR_PLATFORM=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_AIO=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_PCI_QUIRKS=y
+CONFIG_SLUB_DEBUG=y
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
+# CONFIG_SLOB is not set
+# CONFIG_PROFILING is not set
+CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
+CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
+CONFIG_HAVE_IOREMAP_PROT=y
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_ARCH_TRACEHOOK=y
+# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_BLOCK=y
+CONFIG_LBD=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BLK_DEV_INTEGRITY is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED=anticipatory
+# CONFIG_FREEZER is not set
+
+#
+# Platform support
+#
+CONFIG_PPC_MULTIPLATFORM=y
+CONFIG_CLASSIC32=y
+# CONFIG_PPC_CHRP is not set
+# CONFIG_MPC5121_ADS is not set
+# CONFIG_MPC5121_GENERIC is not set
+# CONFIG_PPC_MPC52xx is not set
+# CONFIG_PPC_PMAC is not set
+# CONFIG_PPC_CELL

[PATCH] powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code

[Gerhard Pircher]

_PAGE_COHERENT is now always set in _PAGE_RAM resp. PAGE_KERNEL.
Thus it has to be masked out, if the BAT mapping should be non
cacheable or CPU_FTR_NEED_COHERENT is not set.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/mm/ppc_mmu_32.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 45d9253..fe65c40 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -123,9 +123,9 @@ void __init setbat(int index, unsigned long virt, 
phys_addr_t phys,
int wimgxpp;
struct ppc_bat *bat = BATS[index];
 
-   if (((flags  _PAGE_NO_CACHE) == 0) 
-   cpu_has_feature(CPU_FTR_NEED_COHERENT))
-   flags |= _PAGE_COHERENT;
+   if ((flags  _PAGE_NO_CACHE) ||
+   (cpu_has_feature(CPU_FTR_NEED_COHERENT) == 0))
+   flags = ~_PAGE_COHERENT;
 
bl = (size  17) - 1;
if (PVR_VER(mfspr(SPRN_PVR)) != 1) {
-- 
1.5.3.4


-- 
NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 19 Jan 2009 19:28:35 +0100
 Von: Bartlomiej Zolnierkiewicz bzoln...@gmail.com
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: Benjamin Herrenschmidt b...@kernel.crashing.org, 
 linux-...@vger.kernel.org, linuxppc-dev@ozlabs.org, grant.lik...@secretlab.ca
 Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne 
 boards

 The following patchset fixes core IDE PCI code to always use
 pci_get_legacy_ide_irq() and ide_pci_is_in_compatibility_mode():
 
 http://lkml.org/lkml/2009/1/19/163
 
 so via82cxxx specific solution is no longer necessary.
 
 [ IOW I'll keep your previous patch and the #ifdef issue will
   solve itself after the above patchset is merged. ]
Thanks a lot! That's much better than the simple fix I had planned.

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 9/10] powerpc/mm: Rework usage of _PAGE_COHERENT/NO_CACHE/GUARDED v2

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Fri, 19 Dec 2008 16:13:51 +1100
 Von: Benjamin Herrenschmidt b...@kernel.crashing.org
 An: Paul Mackerras pau...@samba.org
 CC: linuxppc-dev@ozlabs.org, Kumar Gala kumar.g...@freescale.com
 Betreff: [PATCH 9/10] powerpc/mm: Rework usage of 
 _PAGE_COHERENT/NO_CACHE/GUARDED v2

 Currently, we never set _PAGE_COHERENT in the PTEs, we just OR it in
 in the hash code based on some CPU feature bit. We also manipulate
 _PAGE_NO_CACHE and _PAGE_GUARDED by hand in all sorts of places.
 
 This changes the logic so that instead, the PTE now contains
 _PAGE_COHERENT for all normal RAM pages thay have I = 0 on platforms
 that need it. The hash code clears it if the feature bit is not set.
This somehow breaks Linux on my AmigaOne, as its northbridge doesn't like pages
marked as coherent. I removed the CPU_FTR_NEED_COHERENT feature bit
in setup_32.c before the fixups are done, but the system still locks up (doing 
the
fixup in the platform code is too late). It only works stable, if I remove the
_PAGE_COHERENT flag in pgtable-ppc32.h below.

 +#if defined(CONFIG_SMP) || defined(CONFIG_PPC_STD_MMU)
 +#define _PAGE_BASE   (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT)

  BEGIN_FTR_SECTION
 - ori r8,r8,_PAGE_COHERENT/* set M (coherence required) */
 -END_FTR_SECTION_IFSET(CPU_FTR_NEED_COHERENT)
 + rlwinm  r8,r8,0,~_PAGE_COHERENT /* clear M (coherence not required) */
 +END_FTR_SECTION_IFCLR(CPU_FTR_NEED_COHERENT)
I'm pretty sure that the hack for setup_32.c above protects this code in 
hash_low_32.S/
create_hpte() from being overwritten with nops. But I wonder which other paths 
exists
in the memory management code to set the coherent flag in PTEs? Any ideas how I
can get it to work without removing _PAGE_COHERENT from _PAGE_BASE?

Thanks!

Gerhard
-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 9/10] powerpc/mm: Rework usage of _PAGE_COHERENT/NO_CACHE/GUARDED v2

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 19 Jan 2009 06:55:06 +1100
 Von: Benjamin Herrenschmidt b...@kernel.crashing.org
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: pau...@samba.org, kumar.g...@freescale.com, linuxppc-dev@ozlabs.org
 Betreff: Re: [PATCH 9/10] powerpc/mm: Rework usage of 
 _PAGE_COHERENT/NO_CACHE/GUARDED v2

 On Sun, 2009-01-18 at 20:43 +0100, Gerhard Pircher wrote:
  I'm pretty sure that the hack for setup_32.c above protects this code in 
  hash_low_32.S/
  create_hpte() from being overwritten with nops. But I wonder which other 
  paths exists
  in the memory management code to set the coherent flag in PTEs? Any ideas 
  how I
  can get it to work without removing _PAGE_COHERENT from _PAGE_BASE?
 
 I'll have a look, could be something with the BAT setup too, and I
 haven't modified the 603 code, are you using a 603 ?
No, it's a 7455 (which has CPU_FTR_NEED_COHERENT set in its CPU features).

Thanks!

Gerhard
-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 13 Jan 2009 16:01:42 +1100
 Von: Benjamin Herrenschmidt b...@kernel.crashing.org
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: linuxppc-dev@ozlabs.org, grant.lik...@secretlab.ca
 Betreff: Re: [PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards

  I think I throw away the IDE controller node for now, as libata just
  reads the PCI register settings (progif) and I guess the IDE subsystem
  will do the same in the future.
 
 Well... if all AmigaOne use a 8259, they probably use the same interrupt
 routing except for PCI slots. In which case, I would -still- prefer if
 you had a proper interrupt tree, and at runtime or boot-wrapper time,
 fixed up the PCI host interrupt-map property to contain the right
 values for a given board.
That would be the ideal solution. But there is no reliable way to identify,
if the board is an AmigaOneSE, AmigaOneXE or an uA1. AFAIK the firmware
checks for a specifc onboard PCI sound chip to differentiate between an A1XE
and the uA1, but this sound chip is also used on various PCI sound cards.
I don't really like that approach.

 I'm not going to include the new platform in .29, it's way too late
 anyway (it should have been published a couple of weeks before the merge
 window at least I'd say) so we have some time til .30 to polish things a
 bit.
Okay. Some months more don't matter after all these years. :-)

 Another area to look at is to cleanup the non-coherent DMA thingy. The
 config option should just enable a set of non-coherent backend ops, but
 we should still be able to decide which ones to use (coherent vs.
 non-coherent) at runtime.
What about drivers that need to handle non coherent DMA differently
(e.g. because they map DMA memory to userspace)? Will the
#ifdef CONFIG_NOT_COHERENT_CACHE be replaced with calls to
dma_is_consistent()? (for example in the radeon driver, that you fixed for
non coherent DMA platforms in 2.6.25).
If I may express a wish: a reworked CPU feature fixup code for PPC32 will
avoid bigger problems with the AmigaOne platform in the future.

Thanks a lot!

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/5] powerpc: Add platform support for AmigaOne

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 12 Jan 2009 16:08:07 +1100
 Von: Benjamin Herrenschmidt b...@kernel.crashing.org
 An: Scott Wood scottw...@freescale.com
 CC: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-dev@ozlabs.org
 Betreff: Re: [PATCH 1/5] powerpc: Add platform support for AmigaOne

 
   + /* Flush and disable I/D cache. */
   + __asm__ __volatile__ (mfspr3, 1008::: r3);
   + __asm__ __volatile__ (ori  5, 5, 0xcc00   ::: r5);
   + __asm__ __volatile__ (ori  4, 3, 0xc00::: r4);
   + __asm__ __volatile__ (andc 5, 3, 5::: r5);
  
  Don't do this; instead, have one multi-line asm statement (or better
 yet,
  just use mfspr()/mtspr()/sync()/isync()).
  
  GCC is perfectly free to trash your registers in between statements.
 
 Also there's already some code around to properly flush  disable the
 caches on those processors.
Ouch! I searched through all assembler files in arch/powerpc/kernel/ for
such a function, but I have missed flush_disable_L1 in l2cr_6xx.S.
Thanks for the hint!

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 12 Jan 2009 16:12:18 +1100
 Von: Benjamin Herrenschmidt b...@kernel.crashing.org
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: Grant Likely grant.lik...@secretlab.ca, linuxppc-dev@ozlabs.org
 Betreff: Re: [PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards

 The code in the kernel that retreives the interrupt that way is clearly
 marked as a fishy workaround for bogus firmwares :-)
bogus applies a little bit to the PCI init code of the A1 firmware. ;-)

 But I'm not going to reject things based on that, it will work for
 simple board using really only legacy interrupts like yours...
Thanks!

   For the flattened device tree, I think we've settled on the convention
   that every node with an IRQ connection should have both the
   interrupt-parent and interrupts properties.  (ie. don't rely on the
   parent node's interrupt-parent property.)
  Even for ISA devices?
 
 I disagree with Grant here. Especially in simple ISA cases like that,
 there's really no point in bloating the device-tree.
Okay, so I leave it as it is.

   Can this PCI device be probed?  Typically PCI devices don't get added
   to the flattened device tree because PCI is a probeable bus.
  Yes, it can be probed. I thought it would be a good idea to include it,
  because the IDE controller operates in legacy mode. I planned to specify
  the two legacy interrupts in this node (as you can see), but the kernel
  didn't like them.
 
 Well, the kernel just didn't make use of them I'd say :-) But that can
 probably be fixed with the appropriate hacks. 
I think I throw away the IDE controller node for now, as libata just reads
the PCI register settings (progif) and I guess the IDE subsystem will do
the same in the future.

Gerhard

-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 12 Jan 2009 18:55:55 +0100
 Von: Bartlomiej Zolnierkiewicz bzoln...@gmail.com
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: linux-...@vger.kernel.org, linuxppc-dev@ozlabs.org, 
 grant.lik...@secretlab.ca
 Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne 
 boards

   checking if IDE_HFLAG_FORCE_LEGACY_IRQS should be set.
  Wouldn't it be better, if I clean this up now? (I have to resend my
  AmigaOne platform patches anyway).
 
 Replacement patch instead of incremental one is also fine with me -- given
 that it can wait for 2.6.30.
Yes, it can wait.
Although I would like to know from the powerpc maintainer, if my platform
patches could still go in 2.6.29, if I resend them in the next days? I guess 
it's
too late, right?

  Okay, so the change shouldn't break IDE for Pegasos machines (I don't
  have a Pegasos for testing).
 
 Yes but there may be some other platforms (not necessarily powerpc ones)
 that may be affected (i.e. they can depend indirectly on IRQ auto-probing
 during IDE probe) so cleanup patch needs to spend some time in linux-next.
I think the VIA libata driver simply checks the progif register, too. I guess 
you
don't like the idea of a #ifdef PPC32 or so around the
ide_pci_is_in_compatibility_mode() check?

Thanks!

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Sun, 11 Jan 2009 17:51:55 +0100
 Von: Bartlomiej Zolnierkiewicz bzoln...@gmail.com
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: Grant Likely grant.lik...@secretlab.ca, linuxppc-dev@ozlabs.org, 
 linux-...@vger.kernel.org
 Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne 
 boards

 On Wednesday 07 January 2009, Gerhard Pircher wrote:
  
   Original-Nachricht 
   Datum: Wed, 7 Jan 2009 08:13:06 -0700
   Von: Grant Likely grant.lik...@secretlab.ca
   An: Gerhard Pircher gerhard_pirc...@gmx.net
   CC: linuxppc-dev@ozlabs.org, bzoln...@gmail.com
   Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for
 AmigaOne boards
  
   On Wed, Jan 7, 2009 at 7:12 AM, Gerhard Pircher
 gerhard_pirc...@gmx.net
   wrote:
The AmigaOne uses the onboard VIA IDE controller in legacy mode
   (like the Pegasos).
   
Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 drivers/ide/via82cxxx.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)
   
   This patch needs to also be posted on the linux-ide mailing list.
  Ouch, I only sent it to the maintainer. I'll fix that.
 
 [ Please also keep all previous recipients on cc: when doing so. ]
Okay, I'll keep that in mind.

diff --git a/drivers/ide/via82cxxx.c b/drivers/ide/via82cxxx.c
index 2a812d3..086f476 100644
--- a/drivers/ide/via82cxxx.c
+++ b/drivers/ide/via82cxxx.c
@@ -450,6 +450,11 @@ static int __devinit via_init_one(struct
 pci_dev
   *dev, const struct pci_device_i
   d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS;
 #endif
   
+#ifdef CONFIG_AMIGAONE
+   if (machine_is(amigaone))
+   d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS;
+#endif
+
   
   I know you're just following the example of the PEGASOS workaround
   immediately above; but the #defines are really ugly.  I wonder if
   there is there a cleaner way to manipulate the flags.
  AFAIK the via82cxxx driver doesn't make use of the
  pci_get_legacy_ide_irq approach.
 
 I applied your patch for 2.6.29 but for 2.6.30 I would ask you to clean
 up #ifdefs by using ide_pci_is_in_compatibility_mode() helper instead for
 checking if IDE_HFLAG_FORCE_LEGACY_IRQS should be set.
Wouldn't it be better, if I clean this up now? (I have to resend my AmigaOne
platform patches anyway).

 [ Some time ago Pegasos got PCI quirk to put controller in the legacy mode
   (arch/powerpc/platforms/chrp/pci.c) so it is OK to also remove Pegasos'
   special case while at it. ]
Okay, so the change shouldn't break IDE for Pegasos machines (I don't have
a Pegasos for testing).

Thanks!

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 3/5] powerpc: Bootwrapper and serial console support for AmigaOne

[Gerhard Pircher]

This adds the bootwrapper for the cuImage target and a compatible property
check for pnpPNP,501 to the generic serial console support code.
The default link address for the cuImage target is set to 0x80. This
allows to boot the kernel with AmigaOS4's second level bootloader, which
always loads a uImage at 0x50.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/boot/Makefile  |5 -
 arch/powerpc/boot/cuboot-amigaone.c |   35 +++
 arch/powerpc/boot/serial.c  |3 ++-
 arch/powerpc/boot/wrapper   |3 +++
 4 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/boot/cuboot-amigaone.c

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index f328299..d5ec22a 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -70,7 +70,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c 
cuboot-85xx.c holly.c
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c 
\
virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
-   cuboot-acadia.c
+   cuboot-acadia.c cuboot-amigaone.c
 src-boot := $(src-wlib) $(src-plat) empty.c
 
 src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -274,6 +274,9 @@ image-$(CONFIG_STORCENTER)  += cuImage.storcenter
 image-$(CONFIG_MPC7448HPC2)+= cuImage.mpc7448hpc2
 image-$(CONFIG_PPC_C2K)+= cuImage.c2k
 
+# Board port in arch/powerpc/platform/amigaone/Kconfig
+image-$(CONFIG_AMIGAONE)   += cuImage.amigaone
+
 # For 32-bit powermacs, build the COFF and miboot images
 # as well as the ELF images.
 ifeq ($(CONFIG_PPC32),y)
diff --git a/arch/powerpc/boot/cuboot-amigaone.c 
b/arch/powerpc/boot/cuboot-amigaone.c
new file mode 100644
index 000..d502967
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-amigaone.c
@@ -0,0 +1,35 @@
+/*
+ * Old U-boot compatibility for AmigaOne
+ *
+ * Author: Gerhard Pircher (gerhard_pirc...@gmx.net)
+ *
+ *   Based on cuboot-83xx.c
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include stdio.h
+#include cuboot.h
+
+#include ppcboot.h
+
+static bd_t bd;
+
+static void platform_fixups(void)
+{
+   dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+   dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+   unsigned long r6, unsigned long r7)
+{
+   CUBOOT_INIT();
+   fdt_init(_dtb_start);
+   serial_console_init();
+   platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index 8b3607c..f2156f0 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -117,7 +117,8 @@ int serial_console_init(void)
if (devp == NULL)
goto err_out;
 
-   if (dt_is_compatible(devp, ns16550))
+   if (dt_is_compatible(devp, ns16550) ||
+   dt_is_compatible(devp, pnpPNP,501))
rc = ns16550_console_init(devp, serial_cd);
else if (dt_is_compatible(devp, marvell,mv64360-mpsc))
rc = mpsc_console_init(devp, serial_cd);
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 965c237..6170bbf 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -186,6 +186,9 @@ cuboot*)
 *-mpc85*|*-tqm85*|*-sbc85*)
 platformo=$object/cuboot-85xx.o
 ;;
+*-amigaone)
+link_address='0x80'
+;;
 esac
 ;;
 ps3)
-- 
1.5.6.5


-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards

[Gerhard Pircher]

This device tree does not provide the correct CPU name, as various CPU
models and revisions are used in AmigaOnes. Also the PCI root node does
not contain a interrupt mapping property, as all boards have different
interrupt routing. However the kernel can do a 1:1 mapping of all PCI
interrupts, as only i8259 legacy interrupts are used.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/boot/dts/amigaone.dts |  233 
 1 files changed, 233 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/amigaone.dts

diff --git a/arch/powerpc/boot/dts/amigaone.dts 
b/arch/powerpc/boot/dts/amigaone.dts
new file mode 100644
index 000..9794bbc
--- /dev/null
+++ b/arch/powerpc/boot/dts/amigaone.dts
@@ -0,0 +1,233 @@
+/*
+ * AmigaOne Device Tree Source
+ *
+ * Copyright 2008 Gerhard Pircher (gerhard_pirc...@gmx.net)
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+   model = AmigaOne;
+   compatible = eyetech,amigaone,mai-logic,teron;
+   coherency-off;
+   #address-cells = 1;
+   #size-cells = 1;
+
+   cpus {
+   #cpus = 1;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   c...@0 {
+   device_type = cpu;
+   reg = 0;
+   d-cache-line-size = 32;   // 32 bytes
+   i-cache-line-size = 32;   // 32 bytes
+   d-cache-size = 32768; // L1, 32K
+   i-cache-size = 32768; // L1, 32K
+   timebase-frequency = 0;   // 33.3 MHz, from U-boot
+   clock-frequency = 0;  // From U-boot
+   bus-frequency = 0;// From U-boot
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0 0;// From U-boot
+   };
+
+   p...@8000 {
+   device_type = pci;
+   compatible = mai-logic,articia-s;
+   bus-frequency = ;
+   bus-range = 0 0xff;
+   ranges = 0x0100 0 0x 0xfe00 0 0x00c0   
// PCI I/O
+ 0x0200 0 0x8000 0x8000 0 0x7d00   
// PCI memory
+ 0x0200 0 0x 0xfd00 0 0x0100; 
// PCI alias memory (ISA)
+   8259-interrupt-acknowledge = 0xfef0;
+   /* Do not define a interrupt-parent here, if there is no 
interrupt-map property. */
+   #address-cells = 3;
+   #size-cells = 2;
+
+   h...@0 {
+   compatible = pciclass,0600;
+   vendor-id = 0x10cc;
+   device-id = 0x0660;
+   revision-id = 0x0001;
+   class-code = 0x0006;
+   subsystem-id = 0;
+   subsystem-vendor-id = 0;
+   devsel-speed = 0x0001;
+   66mhz-capable;
+   min-grant = 0;
+   max-latency = 0;
+   // AGP aperture is unset.
+// reg = 0x4210 0 0x 0 0x0040;
+// assigned-addresses = 0x4210 0 0x 0 
0x0040;
+   };
+
+   i...@7 {
+   device_type = isa;
+   compatible = pciclass,0601;
+   vendor-id = 0x1106;
+   device-id = 0x0686;
+   revision-id = 0x0010;
+   class-code = 0x00060100;
+   subsystem-id = 0;
+   subsystem-vendor-id = 0;
+   devsel-speed = 0x0001;
+   min-grant = 0;
+   max-latency = 0;
+   /* First 64k for I/O at 0x0 on PCI mapped to 0x0 on 
ISA. */
+   ranges = 0x0001 0 0x0100 0 0x 
0x0001;
+   interrupt-parent = i8259;
+   #interrupt-cells = 2;
+   #address-cells = 2;
+   #size-cells = 1;
+
+   dma-control...@0 {
+   device_type = dma-controller;
+   compatible = pnpPNP,200;
+   reg = 1 0x 0x0020
+  1 0x0080 0x0010
+  1 0x00c0 0x0020;
+   /* Channel 4 reserverd, cascade mode, 2x32k 
transfer/counter

[PATCH 4/5] powerpc: Default config for AmigaOne boards

[Gerhard Pircher]

CONFIG_CC_OPTIMIZE_FOR_SIZE is selected, because otherwise the kernel
wouldn't boot. The AmigaOne's U-boot firmware seems to have a problem
loading uImages bigger than 1.8 MB.

Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
 arch/powerpc/configs/amigaone_defconfig | 1613 +++
 1 files changed, 1613 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/configs/amigaone_defconfig

diff --git a/arch/powerpc/configs/amigaone_defconfig 
b/arch/powerpc/configs/amigaone_defconfig
new file mode 100644
index 000..dc57b21
--- /dev/null
+++ b/arch/powerpc/configs/amigaone_defconfig
@@ -0,0 +1,1613 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.28
+# Tue Jan  6 12:35:06 2009
+#
+# CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+CONFIG_6xx=y
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_8xx is not set
+# CONFIG_40x is not set
+# CONFIG_44x is not set
+# CONFIG_E200 is not set
+CONFIG_PPC_FPU=y
+CONFIG_ALTIVEC=y
+CONFIG_PPC_STD_MMU=y
+CONFIG_PPC_STD_MMU_32=y
+# CONFIG_PPC_MM_SLICES is not set
+# CONFIG_SMP is not set
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_CHECK_CACHE_COHERENCY=y
+CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
+# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
+CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_HARDIRQS=y
+# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
+CONFIG_IRQ_PER_CPU=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+CONFIG_OF=y
+CONFIG_PPC_UDBG_16550=y
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_GENERIC_BUG=y
+CONFIG_DEFAULT_UIMAGE=y
+# CONFIG_PPC_DCR_NATIVE is not set
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_AUDIT is not set
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=15
+# CONFIG_CGROUPS is not set
+# CONFIG_GROUP_SCHED is not set
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
+# CONFIG_RELAY is not set
+CONFIG_NAMESPACES=y
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_USER_NS is not set
+# CONFIG_PID_NS is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL=y
+# CONFIG_EMBEDDED is not set
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_PCSPKR_PLATFORM=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_AIO=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_PCI_QUIRKS=y
+CONFIG_SLUB_DEBUG=y
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
+# CONFIG_SLOB is not set
+# CONFIG_PROFILING is not set
+CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
+CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
+CONFIG_HAVE_IOREMAP_PROT=y
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_ARCH_TRACEHOOK=y
+# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
+CONFIG_BLOCK=y
+CONFIG_LBD=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BLK_DEV_INTEGRITY is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED=anticipatory
+CONFIG_CLASSIC_RCU=y
+# CONFIG_TREE_RCU is not set
+# CONFIG_PREEMPT_RCU is not set
+# CONFIG_TREE_RCU_TRACE is not set
+# CONFIG_PREEMPT_RCU_TRACE is not set
+# CONFIG_FREEZER is not set
+
+#
+# Platform support
+#
+CONFIG_PPC_MULTIPLATFORM=y
+CONFIG_CLASSIC32=y
+# CONFIG_PPC_CHRP is not set
+# CONFIG_MPC5121_ADS is not set
+# CONFIG_MPC5121_GENERIC is not set
+# CONFIG_PPC_MPC52xx is not set
+# CONFIG_PPC_PMAC is not set
+# CONFIG_PPC_CELL is not set

Re: [PATCH 3/5] powerpc: Bootwrapper and serial console support for AmigaOne

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 7 Jan 2009 08:07:14 -0700
 Von: Grant Likely grant.lik...@secretlab.ca
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: [PATCH 3/5] powerpc: Bootwrapper and serial console support for 
 AmigaOne

 On Wed, Jan 7, 2009 at 7:03 AM, Gerhard Pircher gerhard_pirc...@gmx.net
 wrote:
  diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
  index 8b3607c..f2156f0 100644
  --- a/arch/powerpc/boot/serial.c
  +++ b/arch/powerpc/boot/serial.c
  @@ -117,7 +117,8 @@ int serial_console_init(void)
 if (devp == NULL)
 goto err_out;
 
  -   if (dt_is_compatible(devp, ns16550))
  +   if (dt_is_compatible(devp, ns16550) ||
  +   dt_is_compatible(devp, pnpPNP,501))
 rc = ns16550_console_init(devp, serial_cd);
 
 Why not just claim ns16550 compatibility in the device tree node?
It was suggested that I should use PNP identifiers for all ISA devices, as
these are part of a real PCI2ISA bridge (when I sent the previous version
or these patches).

Gerhard

-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 7 Jan 2009 08:13:06 -0700
 Von: Grant Likely grant.lik...@secretlab.ca
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: linuxppc-dev@ozlabs.org, bzoln...@gmail.com
 Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne 
 boards

 On Wed, Jan 7, 2009 at 7:12 AM, Gerhard Pircher gerhard_pirc...@gmx.net
 wrote:
  The AmigaOne uses the onboard VIA IDE controller in legacy mode (like
 the
  Pegasos).
 
  Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
  ---
   drivers/ide/via82cxxx.c |5 +
   1 files changed, 5 insertions(+), 0 deletions(-)
 
 This patch needs to also be posted on the linux-ide mailing list.
Ouch, I only sent it to the maintainer. I'll fix that.

  diff --git a/drivers/ide/via82cxxx.c b/drivers/ide/via82cxxx.c
  index 2a812d3..086f476 100644
  --- a/drivers/ide/via82cxxx.c
  +++ b/drivers/ide/via82cxxx.c
  @@ -450,6 +450,11 @@ static int __devinit via_init_one(struct pci_dev
 *dev, const struct pci_device_i
 d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS;
   #endif
 
  +#ifdef CONFIG_AMIGAONE
  +   if (machine_is(amigaone))
  +   d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS;
  +#endif
  +
 
 I know you're just following the example of the PEGASOS workaround
 immediately above; but the #defines are really ugly.  I wonder if
 there is there a cleaner way to manipulate the flags.
AFAIK the via82cxxx driver doesn't make use of the pci_get_legacy_ide_irq
approach.

Gerhard

-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/5] powerpc: Add platform support for AmigaOne

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 7 Jan 2009 13:07:18 -0600
 Von: Scott Wood scottw...@freescale.com
 An: Gerhard Pircher gerhard_pirc...@gmx.net
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: [PATCH 1/5] powerpc: Add platform support for AmigaOne

 On Wed, Jan 07, 2009 at 02:54:57PM +0100, Gerhard Pircher wrote:
  +void amigaone_show_cpuinfo(struct seq_file *m)
  +{
  +   struct device_node *root;
  +   const char *model = ;
  +
  +   root = of_find_node_by_path(/);
  +   if (root)
  +   model = of_get_property(root, model, NULL);
  +   seq_printf(m, machine\t\t: %s\n, model);
  +
  +   of_node_put(root);
  +   return;
 
 This is already printed by the generic cpuinfo.
I'll remove that. Is a vendor or machine entry actually required?
IIRC the debian-installer parses the machine entry.

  +void __init amigaone_setup_arch(void)
  +{
  +   struct device_node *np;
  +
  +   /* Initialization until calibrate_delay() runs. */
  +   loops_per_jiffy = 5000/HZ;
 
 Is this really necessary?
Don't think so. It's a leftover from the CHRP setup code.

  +   /* Flush and disable I/D cache. */
  +   __asm__ __volatile__ (mfspr3, 1008::: r3);
  +   __asm__ __volatile__ (ori  5, 5, 0xcc00   ::: r5);
  +   __asm__ __volatile__ (ori  4, 3, 0xc00::: r4);
  +   __asm__ __volatile__ (andc 5, 3, 5::: r5);
 
 Don't do this; instead, have one multi-line asm statement (or better yet,
 just use mfspr()/mtspr()/sync()/isync()).
 
 GCC is perfectly free to trash your registers in between statements.
Okay, I'll try to rewrite it with mfspr() and friends (I don't understand gcc's
assembler syntax yet).

Thanks!

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] bootwrapper: support u-boot multi component images

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Fri, 19 Sep 2008 10:50:10 +0200
 Von: Peter Korsgaard [EMAIL PROTECTED]
 An: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
 Betreff: [PATCH v2] bootwrapper: support u-boot multi component images

 From: peter Korsgaard [EMAIL PROTECTED]
 
 Support uImage.platform, which are U-Boot multi component images
 containing a kernel, dtb and possibly an initrd.
Just out of interest: Do you intend to replace the code for building
cuImage.platform (zImage target) with this new build target?

regards,

Gerhard

-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 0/3] ALSA fixes for non-coherent ppc32

[Gerhard Pircher]

Hi,

 Original-Nachricht 
 Datum: Wed, 18 Jun 2008 12:38:31 +0200
 Von: Takashi Iwai [EMAIL PROTECTED]
 An: [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
 Betreff: [PATCH 0/3] ALSA fixes for non-coherent ppc32

 Hi,
 
 I've tried to renew the fixes of ALSA issues about non-coherent DMA
 memories.  The last patch worked for SG-buffers somehow but would
 result in a problem if many pages are allocated because of
 dma_alloc_coherent() handling.  Now, I chose a more simpler
 workaround: the SG-buffers are handled as simple continuous buffers.
 
 This time I split the patches to several parts.  The first patch
 contains a very lazy dma_mmap_coherent() implementation for ppc32.
 The next patch adds the call of dma_mmap_coherent() for the default
 mmap of ALSA PCM.  And the last one is to add the conversion of
 SG-buffer handling as above.
 
 The patches are created against the latest ALSA tree, and the last
 patch won't be applicable fully to 2.6.26-rc6.  But, it's only for
 snd-hda-intel and there is no PPC32 hardware supporting this, AFAIK.
 So just ignore the reject.
 
 The patches are found also on my git tree, dma-fix branch of
 git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
 
 Any comments and test reports are appreciated, especially about
 dma_mmap_coherent() addition.
I know this answer comes a little bit late, but my PPC machine was not
working for two weeks due to a hardware failure. I tested the patch on
2.6.26-rc9 and it seems to work fine so far with my emu10k soundcard.
I just had to add #include linux/dma-mapping.h to pcm_native.c.
Otherwise it wouldn't compile.

Thanks!

regards,

Gerhard

-- 
Pt! Schon das coole Video vom GMX MultiMessenger gesehen?
Der Eine für Alle: http://www.gmx.net/de/go/messenger03
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH/RFC] powerpc: prevent memory corruption due to cache invalidation of unaligned DMA buffer

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 26 Jun 2008 17:29:05 +0800
 Von: Andrew Lewis [EMAIL PROTECTED]
 An: linuxppc-dev@ozlabs.org
 CC: \'Andrew Lewis\' [EMAIL PROTECTED], [EMAIL PROTECTED]
 Betreff: [PATCH/RFC] powerpc: prevent memory corruption due to cache  
 invalidation of unaligned DMA buffer

 On PowerPC processors with non-coherent cache architectures the DMA
 subsystem calls invalidate_dcache_range() before performing a DMA read
 operation.  If the address and length of the DMA buffer are not aligned
 to a cache-line boundary this can result in memory outside of the DMA
 buffer being invalidated in the cache.  If this memory has an
 uncommitted store then the data will be lost and a subsequent read of
 that address will result in an old value being returned from main memory.
 
 Only when the DMA buffer starts on a cache-line boundary and is an exact
 mutiple of the cache-line size can invalidate_dcache_range() be called,
 otherwise flush_dcache_range() must be called.  flush_dcache_range()
 will first flush uncommitted writes, and then invalidate the cache.
I have a similar problem, but with a network driver (which uses cacheable
skbuffers as DMA memory). The SLUB allocator should return cache line
aligned memory, but that doesn't prevent data corruption. I fixed it by
setting NET_SKB_PAD (default 16)  to L1_CACHE_BYTES (32 on my 7455
non coherent DMA system).
It looks like your patch could solve my problem without changing
NET_SKB_PAD. I'll have to try that out.

regards,

Gerhard
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: BUG() in current git, __dma_alloc_coherent, Beige G3

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 16 Jun 2008 14:50:38 +1000
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Joseph Fannin [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: BUG() in current git, __dma_alloc_coherent, Beige G3

  This is 100% reproducable.  I can't really recall the last kernel I
  built and booted successfully on this box -- the best I can say is
  that the 2.6.24-ish kernel Ubuntu ships works.
  
  I should probably mention that I've been having a little trouble with
  the IDE drive in this machine -- but the drive isn't the problem:
  
  * This is 100% reproducible with the current git kernel, and
doesn't happen w/the Ubuntu kernel
  * The traceback and dump does not vary between boots
  * The kernel BUGs out well before the disks are detected (and it's
a _drive_ problem)
  
  ... etc.  :-)  I don't want to send anyone on a wild goose chase, but
  yeah, it's not the hardware.  ;-)
  
  So, what can I do to help find the problem here?  Git says no one's
  touched that file in a while, and tracing through this problem is
  above my skill level here.  I'll attach my .config, and put the
  vmlinux up:
I discovered this bug some time ago and reported it on the list.
See here for more info:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056128.html
Anyway I don't think your machine needs dma-noncoherent.

best regards,

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 14 May 2008 14:26:53 +0200
 Von: Takashi Iwai [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
 linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
 Betreff: ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)

 At Tue, 06 May 2008 11:16:22 +0200,
 Gerhard Pircher wrote:
  
  Naturally I can do some tests, if you or Takashi come up with a new
  patch.
 
 OK, here is another patch for testing.  Since I lost my old patch
 somewhere (and it's not worth to dig the archive), I wrote it up
 quickly from scratch.  This version should cover both SG and non-SG
 buffers.  It's against the latest git tree.
Thanks a lot! I'll test it tonight, if I can get the lastest kernel
version running on my A1 (2.6.26-rc1 oopsed already on startup and
Kumar's fixmap patch for highmem seems to break dma-noncoherent.c).

regards,

Gerhard

-- 
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 14 May 2008 14:26:53 +0200
 Von: Takashi Iwai [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
 linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
 Betreff: ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)

 At Tue, 06 May 2008 11:16:22 +0200,
 Gerhard Pircher wrote:
  
  Naturally I can do some tests, if you or Takashi come up with a new
  patch.
 
 OK, here is another patch for testing.  Since I lost my old patch
 somewhere (and it's not worth to dig the archive), I wrote it up
 quickly from scratch.  This version should cover both SG and non-SG
 buffers.  It's against the latest git tree.
 
 The patch adds a hackish verison of dma_mmap_coherent() for some
 architectures in sound/core/pcm_native.c.  I'm not sure whether this
 works.  I just tested it on X86.  It'd be appreciated if someone can
 test this.
 
 Also, this disables HDSPM driver for non-X86/IA64 since the driver has
 own copy and silence methods that are incompatible with the new
 SG-buffer data.
 
 
 And, yes, I know we need to clean up huge messes in ALSA memory
 handling routines.  But, let's fix obvious bugs before starting a big
 rewrite...
Okay, it seems to work fine so far. No lock-ups or kernel oopses. Tested
with kernel v2.6.26-rc2 and a Soundblaster 5.1/EMU10k1 device (which was
not working with the old patch) on my non cache coherent G4 system.

Thanks again!

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Patch [Port fixmap from x86 and use for kmap_atomic] breaks dma_noncoherent.c

[Gerhard Pircher]

Hi,

The commit [POWERPC] Port fixmap from x86 and use for kmap_atomic breaks
dma-noncoherent.c, if highmem is enabled.

 --- a/arch/powerpc/mm/pgtable_32.c
 +++ b/arch/powerpc/mm/pgtable_32.c
 @@ -387,3 +388,25 @@ void kernel_map_pages(struct page *page, int numpages, 
 int enable)
 change_page_attr(page, numpages, enable ? PAGE_KERNEL : __pgprot(0));
  }
  #endif /* CONFIG_DEBUG_PAGEALLOC */
 +
 +static int fixmaps;
 +unsigned long FIXADDR_TOP = 0xf000;
 +EXPORT_SYMBOL(FIXADDR_TOP);
 +
The address defined for FIXADDR_TOP seems to conflict with the address
defined by CONSISTENT_START (default 0xff10). It triggers the
BUG_ON(!pte_none(*pte)) statement in __dma_alloc_coherent().

regards,

Gerhard

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Sam440ep support

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 06 May 2008 09:44:18 +1000
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: Kumar Gala [EMAIL PROTECTED], [EMAIL PROTECTED], linuxppc-dev@ozlabs.org
 Betreff: Re: [PATCH] Sam440ep support

 
 On Mon, 2008-05-05 at 21:50 +0200, Gerhard Pircher wrote:
  This is a (bad) hack that I also use on the AmigaOne to get the ALSA
  sound drivers working with DMA, because ALSA doesn't work with
  dma-noncoherent.c. The problem is the nopage mechanism, which fails
  with non coherent DMA allocations due to their own virtual address
  space (correct me, if I'm wrong).
  
  See this thread for more info:
  http://readlist.com/lists/vger.kernel.org/linux-kernel/45/226541.html
  
  This is a general problem that affects all powerpc boards that use
  dma-noncoherent.c with ALSA PCI drivers.
 
 The link above doesn't provide any useful information on the problem and
 it contains itself a non working link...
Sorry, I didn't check the embedded link. This one should work:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0406.2/0801.html

IIRC the problem is the mmaping of non coherent DMA allocations, as you
already know. The link above points to a very old (from 2004) and quite
long thread where the correct DMA API for mmaping DMA allocations was
discussed.

 Can somebody explains exactly what's going on ? That shouldn't be hard
 to fix. I can't believe the problem has been around for 2 years and
 nobody actually bothered fixing it properly.
Takashi Iwai posted a preliminary patch a long time ago. I tested it on my
machine and it failed with non coherent scatter-gather DMA allocations
(I guess almost all ALSA PCI drivers use SG DMA?).

Thanks!

Gerhard

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/2] [POWERPC] rtc_cmos_setup: assign interrupts only if there is i8259 PIC

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 5 May 2008 22:55:38 +0400
 Von: Anton Vorontsov [EMAIL PROTECTED]
 An: Kumar Gala [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: [PATCH 1/2] [POWERPC] rtc_cmos_setup: assign interrupts only if  
 there is i8259 PIC

 Sometimes (particularly on MPC8610HPCD) we want IRQ-less CMOS RTC for
 the boards without (or disabled) i8259 PICs.
 
 We lookup the device tree for chrp,iic compatible devices, and if not
 found we do not assign RTC IRQ.
 
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
 ---
  arch/powerpc/sysdev/rtc_cmos_setup.c |   21 +++--
  1 files changed, 15 insertions(+), 6 deletions(-)
 
 diff --git a/arch/powerpc/sysdev/rtc_cmos_setup.c
 b/arch/powerpc/sysdev/rtc_cmos_setup.c
 index c09ddc0..e5d0bcb 100644
 --- a/arch/powerpc/sysdev/rtc_cmos_setup.c
 +++ b/arch/powerpc/sysdev/rtc_cmos_setup.c
 @@ -21,6 +21,7 @@ static int  __init add_rtc(void)
   struct device_node *np;
   struct platform_device *pd;
   struct resource res[2];
 + unsigned int num_res = 1;
   int ret;
  
   memset(res, 0, sizeof(res));
 @@ -41,14 +42,22 @@ static int  __init add_rtc(void)
   if (res[0].start != RTC_PORT(0))
   return -EINVAL;
  
 - /* Use a fixed interrupt value of 8 since on PPC if we are using this
 -  * its off an i8259 which we ensure has interrupt numbers 0..15. */
 - res[1].start = 8;
 - res[1].end = 8;
 - res[1].flags = IORESOURCE_IRQ;
 + np = of_find_compatible_node(NULL, NULL, chrp,iic);
Could you add a check for pnpPNP,000 (PNP ID for i8259), as not all
platforms use the CHRP names?

Gerhard

-- 
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Sam440ep support

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 06 May 2008 18:48:39 +1000
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org, Takashi Iwai [EMAIL PROTECTED], [EMAIL 
 PROTECTED], [EMAIL PROTECTED]
 Betreff: Re: [PATCH] Sam440ep support

 
 On Tue, 2008-05-06 at 09:51 +0200, Gerhard Pircher wrote:
  Takashi Iwai posted a preliminary patch a long time ago. I tested it
  on my machine and it failed with non coherent scatter-gather DMA
  allocations (I guess almost all ALSA PCI drivers use SG DMA?).
 
 How does Alsa allocate such SG ?
I can't answer this question. *ducked* :-) Takashi?

FYI: I posted the results of the test with Takashi's dma_mmap_coherent
patch here:
http://ozlabs.org/pipermail/linuxppc-dev/2006-June/024078.html

On the other side it looks like this problem does not only affect ALSA.
As far as I can tell also some V4L(2) drivers have a problem with mmaping
non coherent DMA allocations, but I'm not sure (it's a long time since I
did some tests with video cards on my AmigaOne).

Naturally I can do some tests, if you or Takashi come up with a new
patch.

Thanks!

Gerhard

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Strange build error in boot/wrapper script

[Gerhard Pircher]

Hi,

I get a rather strange error here with kernel v2.6.26-rc1 and gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (cross compile version).
This is the output of the build process:

 $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage
   CHK include/linux/version.h
   CHK include/linux/utsrelease.h
   CALLscripts/checksyscalls.sh
   CHK include/linux/compile.h
   CALLarch/powerpc/kernel/systbl_chk.sh
   CALLarch/powerpc/kernel/prom_init_check.sh
   WRAParch/powerpc/boot/uImage
 Image Name:   Linux-2.6.26-rc1
 Created:  Tue May  6 22:43:54 2008
 Image Type:   PowerPC Linux Kernel Image (gzip compressed)
 Data Size:1780300 Bytes = 1738.57 kB = 1.70 MB
 Load Address: 0x
 Entry Point:  0x
 arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/amigaone.dtb -b 0  
 /home/geri/AmigaOne/Linux/linux-2.6.26/arch/powerpc/boot/dts/amigaone.dts
 DTC: dts-dtb  on file 
 /home/geri/AmigaOne/Linux/linux-2.6.26/arch/powerpc/boot/dts/amigaone.dts
   WRAParch/powerpc/boot/cuImage.amigaone
 powerpc-linux-gnu-objcopy: Warning: could not locate './vmlinux.strip'. 
 reason: The value is too big for the defined data type (translated to English)
 Image Name:   Linux-2.6.26-rc1
 Created:  Tue May  6 22:43:54 2008
 Image Type:   PowerPC Linux Kernel Image (gzip compressed)
 Data Size:21675 Bytes = 21.17 kB = 0.02 MB
 Load Address: 0x0040
 Entry Point:  0x00400444
 rm arch/powerpc/boot/amigaone.dtb

As you can see, the wrapper script generates an incomplete cuImage. The
vmlinux.strip file is there, but I wonder why it is so big:

 -rw-r--r--  3225085348 2008-05-06 21:58 vmlinux.strip

Any ideas what is going wrong here? Broken compiler?

Thanks!

regards,

Gerhard

-- 
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Sam440ep support

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 5 May 2008 13:27:28 -0500
 Von: Kumar Gala [EMAIL PROTECTED]
 An: Giuseppe Coviello [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: [PATCH] Sam440ep support

 
 On May 5, 2008, at 1:23 PM, Giuseppe Coviello wrote:
 
  This patch adds the support for the sam440ep board.
 
  arch/powerpc/boot/Makefile  |5 +-
  arch/powerpc/boot/cuboot-sam440ep.c |   35 +
  arch/powerpc/boot/dts/sam440ep.dts  |  292 ++
  arch/powerpc/boot/sam440ep.c|   53 +
  arch/powerpc/configs/44x/sam440ep_defconfig | 1429 ++ 
  +
  arch/powerpc/platforms/44x/Kconfig  |9 +
  arch/powerpc/platforms/44x/Makefile |1 +
  arch/powerpc/platforms/44x/sam440ep.c   |   66 ++
  arch/powerpc/sysdev/Makefile|1 +
  arch/powerpc/sysdev/sam440ep.c  |  112 +++
  include/asm-powerpc/dma-mapping.h   |   30 +
  sound/core/memalloc.c   |   31 +-
 
 The changes to dma-mapping.h and sound/core/memalloc.c need to be  
 explained and odds are will not go in as is.
This is a (bad) hack that I also use on the AmigaOne to get the ALSA sound
drivers working with DMA, because ALSA doesn't work with dma-noncoherent.c.
The problem is the nopage mechanism, which fails with non coherent DMA
allocations due to their own virtual address space (correct me, if I'm
wrong).

See this thread for more info:
http://readlist.com/lists/vger.kernel.org/linux-kernel/45/226541.html

This is a general problem that affects all powerpc boards that use
dma-noncoherent.c with ALSA PCI drivers.

Gerhard
-- 
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: FW: SKB corruption on heavy traffic

[Gerhard Pircher]

Hi,

I think I have the same problem here with all versions of the 2.6.x kernel
series (tested with kernel v2.6.8/14/16/18/25 on a PPC7455 machine with
different PCI network cards by transferring a big file over NFS/SCP). Data
corruption occurs under high load, but I don't get any kernel oops.

regards,

Gerhard

 Original-Nachricht 
 Datum: Wed, 30 Apr 2008 10:07:15 +0100
 Von: Franca, Jose (NSN - PT/Portugal - MiniMD) [EMAIL PROTECTED]
 An: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
 Betreff: FW: SKB corruption on heavy traffic

 From our latest debugs we found that the problem occurs mainly on skbuff
 code. After some variable time kfree or kalloc result in kernel oops.
 
 -Original Message-
 From: Franca, Jose (NSN - PT/Portugal - MiniMD) 
 Sent: quarta-feira, 30 de Abril de 2008 9:44
 To: 'ext Scott Wood'
 Cc:   
 Subject: RE: SKB corruption on heavy traffic
 
 Hello!
 
   Thank you for replying!
   It't quite dificult to say if the problem exists without our
 changes, since the all software is dependent on this changes so to work
 with the hardware. I can't answer to that right now on that, but I forgot 
 to add one thing: we have ring buffer full problems on our fcc_enet
 driver from time to time. So, I think the problem could be on linux
 configurations (related to hw) because there is a lot of posts on the web 
 related to problems similar to this (none of them has really solved the
 bottom problem). 
 
 Regards,
 Filipe 
 
 -Original Message-
 From: ext Scott Wood [mailto:[EMAIL PROTECTED] 
 Sent: terça-feira, 29 de Abril de 2008 20:15
 To: Franca, Jose (NSN - PT/Portugal - MiniMD)
 Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
 Subject: Re: SKB corruption on heavy traffic
 
 On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal
 - MiniMD) wrote:
  We are developing a MPC8247 based telecom board (512MB), using
  linux 2.4 with some proprietary changes on IP stack and we are facing
  some problems when we have heavy traffic on our Ethernet interfaces...
 
 Do you see these problems without the proprietary changes, and with a
 current kernel?
 
 -Scott


-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Port fixmap from x86 and use for kmap_atomic

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 17 Apr 2008 21:57:05 -0500 (CDT)
 Von: Kumar Gala [EMAIL PROTECTED]
 An: Paul Mackerras [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: [PATCH] [POWERPC] Port fixmap from x86 and use for kmap_atomic

 The fixmap code from x86 allows us to have compile time virtual addresses
 that we change the physical addresses of at run time.
...
 +/*
 + * Here we define all the compile-time 'special' virtual
 + * addresses. The point is to have a constant address at
 + * compile time, but to set the physical address only
 + * in the boot process. We allocate these special addresses
 + * from the end of virtual memory (0xf000) backwards.
 + * Also this lets us do fail-safe vmalloc(), we
 + * can guarantee that these special addresses and
 + * vmalloc()-ed addresses never overlap.
I don't understand how highmem works, but I'm just interested to know, if
this implementation could conflict somehow with the non coherent DMA
implementation in dma-noncoherent.c (which uses address space from
0xff10 to 0xff30 for DMA memory).
On the other side could dma-noncoherent.c benefit from fixmaps so that it
isn't necessary to configure a start address for DMA allocations?

Thanks!

best regards,

Gerhard
-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: 7448/2.6.20 problems (double boots or hangs)

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 19 Mar 2008 17:52:16 -0400
 Von: Leisner, Martin [EMAIL PROTECTED]
 An: linuxppc-dev@ozlabs.org
 CC: Lund, Nathan \\([EMAIL PROTECTED]) [EMAIL PROTECTED]
 Betreff: 7448/2.6.20 problems (double boots or hangs)

 My taiga board is now dead -- on our development board (with a taiga
 kernel
 and a custom modified dts) we see either
 
 
 1) it hangs at the same point (PID has table entries)
or
 2) it boots but it seems to restart the boot process after the PID hash
 table entries line
I observed the same behavior on my AmigaOne, if the PAGE_COHERENT flag was
set for page mappings by CPU_FTR_NEED_COHERENT. The 7448 CPU doesn't need
CPU_FTR_NEED_COHERENT to be set (no CPU bug that needs to be worked
around), but there is no define for the 7448 in arch/powerpc/cputable.h in
kernel v2.6.20 (but it's in v2.6.22!). Thus I guess it is detected as a
744[0|5|7], which have this flag set.
On the other side my hardware is _very_ buggy, so it's unlikely that this
could be the problem on your hardware.

Gerhard
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 03 Mar 2008 09:56:09 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL 
 PROTECTED]
 Betreff: Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC

 Bah, I think I found the problem:
 
 +static inline void *drm_vmalloc_dma(unsigned long size)
 +{
 +#if defined(__powerpc__)  defined(CONFIG_NOT_COHERENT_CACHE)
 +   return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM,
 +PAGE_KERNEL | _PAGE_NO_CACHE);
 +#else
 +   return vmalloc_32(size);
 +#endif
 +}
 +
 
 Remove the GFP_HIGHMEM from the above. It looks like our cache
 flushing isn't going to work for highmem, it would need some
 kmap's for that.
Yes, it looks like this was the problem. No kernel oops anymore.
The machine locks up anyway (which is a well known hardware problem).
It doesn't lock up with CPPIOMode=true, but probably only because the
initialization of DRI fails with BAD cp_mode (f000)!.

Gerhard
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 04 Mar 2008 07:44:11 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
 linuxppc-dev@ozlabs.org
 Betreff: Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC

 On Mon, 2008-03-03 at 20:51 +0100, Gerhard Pircher wrote:
   Remove the GFP_HIGHMEM from the above. It looks like our cache
   flushing isn't going to work for highmem, it would need some
   kmap's for that.
 
  Yes, it looks like this was the problem. No kernel oops anymore.
  The machine locks up anyway (which is a well known hardware problem).
  It doesn't lock up with CPPIOMode=true, but probably only because the
  initialization of DRI fails with BAD cp_mode (f000)!.
 
 Damn, I wonder why you insist trying to make that machine work :-) The
 hardware is just totally busted.
Because it's a challenge! :) Or because the OS4 developers say that
PCIGART works.

Gerhard
-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.web.de/de/entertainment/games/free
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: How to dynamically disable/enable CPU features?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Sat, 23 Feb 2008 09:32:01 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: Milton Miller [EMAIL PROTECTED], linuxppc-dev@ozlabs.org
 Betreff: Re: How to dynamically disable/enable CPU features?

  The flag is in POSSIBLE. I now use this code in the platform probe
  function to nop out the code affected by the flag:
  
  cur_cpu_spec-cpu_features = ~CPU_FTR_NEED_COHERENT;
  /* Patch out unwanted feature. */
  do_feature_fixups(cur_cpu_spec-cpu_features,
PTRRELOC(__start___ftr_fixup),
PTRRELOC(__stop___ftr_fixup));
  
  It seems to work so far, but I would like to know if this is the right
  way to do it, or if calling do_feature_fixups() more than once can have
  any side effects.
 
 It's a bit hairy... Things -could- have been nop'ed out by the first
 call as a result of CPU_FTR_NEED_COHERENT being set and the second
 call will not be able to put them back in... now that may not be the
 case (depends what kind of patching is done with that flag) and so
 'happen' to work for this specific bit but it isn't a nice solution...
I checked this now. Looks like it only needs to nop out some code (mainly
in the hash table code).

 A better long term approach is to look at moving the fixup to after
 the machine probe() after carefully checking whether that can cause
 any problem...
Well, that's a job for an more experienced kernel developer. :)

Thanks!

Gerhard
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: How to dynamically disable/enable CPU features?

[Gerhard Pircher]

Hi,

 Original-Nachricht 
 Datum: Fri, 22 Feb 2008 11:24:38 -0600
 Von: Milton Miller [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: ppcdev linuxppc-dev@ozlabs.org
 Betreff: Re: How to dynamically disable/enable CPU features?

 We handle cpu features in a couple of ways:
 (1) we replace assembly instructions with nop early in the kernel boot
I'm pretty sure that is the problem.

 (2) we test the feature flags in c code
 
 In (2), we form two expressions for features that are
 (a) always set
 (b) never set
 so that the compiler can eliminate the test based on the config.
 
 To change a flag, you must make sure its in POSSIBLE but not ALWAYS, 
 and also set it before it is used, either to nop out instructions (see 
 early_init in setup-32.c for 32 bit), or tested by c code (in this 
 case, maybe the initial_mmu setup is testing NEED_COHERENT, which is 
 between early_init and probe). The code path is a bit different for 64
 bit.
The flag is in POSSIBLE. I now use this code in the platform probe
function to nop out the code affected by the flag:

cur_cpu_spec-cpu_features = ~CPU_FTR_NEED_COHERENT;
/* Patch out unwanted feature. */
do_feature_fixups(cur_cpu_spec-cpu_features,
  PTRRELOC(__start___ftr_fixup),
  PTRRELOC(__stop___ftr_fixup));

It seems to work so far, but I would like to know if this is the right
way to do it, or if calling do_feature_fixups() more than once can have
any side effects.

regards,

Gerhard
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

How to dynamically disable/enable CPU features?

[Gerhard Pircher]

Hi,

I'm wondering how to disable or enable CPU features based on the board the
kernel is running on. In my case I want to disable the
CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the machine.
I tried to clear the flag in the platform's *_probe() function with the
following code:

cur_cpu_spec-cpu_features = ~CPU_FTR_NEED_COHERENT;

First I thought that this works fine, because the kernel booted once till
the console login prompt (and died afterwards). Therefore I suspected that
another change or bug in the kernel conflicts with my hardware (usually
the machine died much earlier on older kernels, if the flag wasn't
cleared).
Now I removed all CPU_FTR_NEED_COHERENT entries from the cputable.h file
and the kernel boots just fine without any lockups (reproducable).
I don't quite understand the difference between dynamically clearing the
flag in the platform setup code and removing the flag for all CPU
defines in cputable.h. I can only suspect that clearing the flag in the
platform probe function is too late, as the MMU and BATs may already be
set up.

Can anybody confirm my suspicion or give me a hint how to implement it
correctly? (I don't want to tinker with cputable.h)

Thanks!

regards,

Gerhard
-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.web.de/de/entertainment/games/free
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Question about PPC_NATIVE/hash_native_64.c

[Gerhard Pircher]

Hi,

I'm a little bit confused about the hash_native_64.c file, which is compiled
in the kernel, if PPC_NATIVE is defined. PPC_NATIVE seems to be defined also
for 32bit platforms (CHRP, PREP, etc.), but the name of the hash_native_64.c
file and the Makefile suggest that it is for 64bit platforms only.
What is hash_native_64.c actually good for on 32bit platforms and which cpus
can make use of it?

Thanks!

regards,

Gerhard
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Commit for mm/page_alloc.c breaks boot process on my machine

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 4 Feb 2008 10:42:32 +
 Von: Mel Gorman [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED], linuxppc-dev@ozlabs.org
 Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine

 2. Any chance of seeing a dmesg log?
That's a little bit of a problem. The kernel log in memory doesn't
show any kernel oops, but is also fragmented (small fragments seem
to have been overwritten with 0x0).
   
   err, that doesn't sound very healthy.
 
  Yeah, I know. But the platform code hasn't changed much when porting it
  from arch/ppc to arch/powerpc. That's why I'm a little bit lost in this
  case. :-)
  
 
 I'm at a bit of a loss to guess what might have changed in powerpc code
 that would explain this. I've added the linuxppc-dev mailing list in
 case they can make a guess.
Yes, I'll try to get some comments on the linuxppc-dev mailing list.

 I think you are also going to need to start bisecting searching
 specifically for the patch that causes these overwrites.
I think I had a similar problem with kernel v2.6.23, too and therefore
waited for kernel 2.6.24. So the problem may exist since a long time.

 It's a virtual address so it depends on the value of CONFIG_KERNEL_START
 as to whether this is a user program address or not.
AFAIK start_kernel() is called very early in the boot process, were no
user or kernel thread is active. I also wonder why the kernel crashes when
the mem boot option is used. Let's see what the linuxppc-dev people say.

Thanks for your help!

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: hangs after Freeing unused kernel memory

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 15 Nov 2007 16:00:09 -0800
 Von: Siva Prasad [EMAIL PROTECTED]
 An: [EMAIL PROTECTED], linuxppc-dev@ozlabs.org
 Betreff: hangs after Freeing unused kernel memory

 Hi,
 
 This sounds like a familiar problem, but could not get answers in posts
 that came up in google search.
Yes, this is a familiar problem, at least for me. :-)

 My system hangs after printing the message Freeing unused kernel
 memory. It should execute init after that, but not sure what exactly is
 happening. Appreciate if some one can throw few ideas to try out.
 
 Seems it is actually hanging when it makes the call 
 run_init_process(ramdisk_execute_command) in init/main.c
On my machine it hangs after returning from kernel_execve()/do_execve(),
which is called by run_init_process(/sbin/init). So the problem can be
almost anywhere. The problem appeared first on kernel 2.6.17. 2.6.16
worked fine on my machine.
I'm going to try out git-bisect on these two kernel revisions, now that I
figured out what people mean when they talk about bisecting. :-) I just
have to figure out how to merge my patches with every branch that is
checked out by git-bisect.

Gerhard

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Kernel locks up after calling kernel_execve()

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Thu, 15 Nov 2007 08:54:32 +1100
 Von: Paul Mackerras [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED], linuxppc-dev@ozlabs.org
 Betreff: Re: Kernel locks up after calling kernel_execve()

 No it's not just for ppc64.  We had a patch that went in some time ago
 to ensure that the M bit was set on various 32-bit platforms because
 otherwise we got data corruption (due to a small cache in the
 northbridge not being kept coherent with the processor cache).
Ah, I thought this was due to a CPU errata, where L2 cache prefetching
causes data corruption with the coherent bit set to 0.

Gerhard
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Hardware debuggers for PPC74xx G4 CPUs

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 14 Nov 2007 12:17:09 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: Jon Smirl [EMAIL PROTECTED], [EMAIL PROTECTED], linuxppc-dev@ozlabs.org
 Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs

 
 On Tue, 2007-11-13 at 23:21 +0100, Gerhard Pircher wrote:
   Original-Nachricht 
   Datum: Tue, 13 Nov 2007 17:10:29 -0500
   Von: Jon Smirl [EMAIL PROTECTED]
   An: Grant Likely [EMAIL PROTECTED]
   CC: Gerhard Pircher [EMAIL PROTECTED],
 linuxppc-dev@ozlabs.org
   Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs
   
   Here are the choices:
   http://www.macraigor.com/cpus.htm
  Looks like the Abatron BDI-2000 is the cheapest hardware debugger that
  supports 74xx G4 CPUs. :-(
 
 Do you have the appropriate connector for it on the motherboard as
 well ? If not, then you are out of luck...
 
 Ben.
Yes, the connector is on the CPU module.

Gerhard
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Kernel locks up after calling kernel_execve()

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 14 Nov 2007 10:37:52 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: Kernel locks up after calling kernel_execve()

 Add printk's to things :-) It's a UP kernel so there should be no
 spinlocks anyway.
 
 Best is to try to get a 100% reprocase and printk your way toward the
 origin of the problem if you don't have a HW debugger. Unless you manage
 to sneak in an irq to xmon but if you are totally locked up, you
 probably can't.
Also xmon seems to lockup the machine. I was able to active it through the
magic sysrq key, but the machine died afterwards.

 Could also be something you do that your buggy northbridge doesn't like.
 For example, maybe it dislikes M bit in the hash table and you end up
 with it set due to other reasons (I know we had changes in this area).
Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
prefetch engines (I don't care about the performance loss).
I couldn't find any other code that sets the M bit, except for huge TLB
page support, but isn't that only for PPC64?

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Kernel locks up after calling kernel_execve()

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 14 Nov 2007 21:04:57 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: Kernel locks up after calling kernel_execve()

 On Wed, 2007-11-14 at 10:39 +0100, Gerhard Pircher wrote:
  Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
  masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
  prefetch engines (I don't care about the performance loss).
  I couldn't find any other code that sets the M bit, except for huge
  TLB
  page support, but isn't that only for PPC64?
 
 Right, it's only 64 bits. You've double checked nothing broke the M bit
 thing ? In which case, I don't know what else...
Yes, I did. Otherwise the machine dies much earlier in the boot process.

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Kernel locks up after calling kernel_execve()

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Sun, 11 Nov 2007 14:55:40 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: Kernel locks up after calling kernel_execve()

 
 On Sat, 2007-11-10 at 18:11 +0100, Gerhard Pircher wrote:
   Original-Nachricht 
   Datum: Fri, 09 Nov 2007 18:50:29 +1100
   Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
   An: Gerhard Pircher [EMAIL PROTECTED]
   CC: linuxppc-dev@ozlabs.org
   Betreff: Re: Kernel locks up after calling kernel_execve()
 
  Is there a way to debug it without a hardware debugger or can you
  recommend a cheap hardware debugger?
 
 There are ways, sure, which probably involve adding prink's all over the
 place to figure it out... could be some DMA issue for example, could be
 pretty much anything. Have you tried booting an initrd with no disk
 access ?
I tried to boot with a ramdisk, but that didn't help much. I still locks up
while loading an init program or after entering some commands in
sh shell. Looks like the problem is hidden deep in the kernel.

Thanks!

Gerhard

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Hardware debuggers for PPC74xx G4 CPUs

[Gerhard Pircher]

I'm trying to debug a kernel lockup that occurs on my machine with all kernel
versions 2.6.16. I don't have a clue what the root cause of this lockup is,
thus I'm thinking about using a hardware debugger. Can anybody recommend a
reasonably cheap hardware debugger that works with G4 CPUs and can interact
with GDB/DDD?

regards,

Gerhard
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Kernel locks up after calling kernel_execve()

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Wed, 14 Nov 2007 08:43:38 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: Kernel locks up after calling kernel_execve()

 Well, at least the above tells is it's not DMA related.
 
 I don't know of any deeply hidden problem, so you are probably hitting
 something else ... if you have disabled idle, then it may be useful to
 try instrumenting locks or irq enable/disable.
Well, I only disabled power saving with powersave=off. Are there any other
ways to disable idle? What do you mean with instrumenting locks or
irq enable/disable?

 Also, did you try booting with all kernel debug options enabled ?
I compiled in almost all kernel debugging options and booted the kernel
with driver_debug, initcall_debug and debug. I didn't notice any serious
error messages so far. Not sure however, if I missed a debug option.

 Finally, since the problem seem to have started around a specific kernel
 version, can you try to bisect the patch that causes it ?
Hmm, I'm not sure how to do this (only worked on platform code so far).
I guess you think about checking out a kernel version from the git
repository, which doesn't contain the patch for kernel_execve().
I still suspect the kernel_execve() function (which was introduced in
2.6.17) because the kernel locks up after starting the first user program.
AFAIK kernel threads should be running much earlier.

Thanks!

regards,

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Hardware debuggers for PPC74xx G4 CPUs

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 13 Nov 2007 17:10:29 -0500
 Von: Jon Smirl [EMAIL PROTECTED]
 An: Grant Likely [EMAIL PROTECTED]
 CC: Gerhard Pircher [EMAIL PROTECTED], linuxppc-dev@ozlabs.org
 Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs

 On 11/13/07, Grant Likely [EMAIL PROTECTED] wrote:
  On 11/13/07, Grant Likely [EMAIL PROTECTED] wrote:
   Abatron BDI-2000.
 
  Oops, but that's not all that cheap.  ($2750USD).  You might try
  looking at the Macraigor Wiggler
  (http://www.macraigor.com/wiggler.htm), but it has limited powerpc
  support.
 
 Here are the choices:
 http://www.macraigor.com/cpus.htm
Looks like the Abatron BDI-2000 is the cheapest hardware debugger that
supports 74xx G4 CPUs. :-(

Thanks!

Gerhard
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: pcspkr device, pnpPNP,100

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Mon, 12 Nov 2007 14:57:13 +0100 (CET)
 Von: Geert Uytterhoeven [EMAIL PROTECTED]
 An: Jon Smirl [EMAIL PROTECTED]
 CC: PowerPC dev list Linuxppc-dev@ozlabs.org
 Betreff: Re: pcspkr device, pnpPNP,100

 On Mon, 12 Nov 2007, Jon Smirl wrote:
  On 11/12/07, Geert Uytterhoeven [EMAIL PROTECTED] wrote:
   On Mon, 12 Nov 2007, Benjamin Herrenschmidt wrote:
On Sun, 2007-11-11 at 19:18 -0500, Jon Smirl wrote:
   
Run a poll :-) I suppose at least chrp/prep/pegasos
  
   And definitely not Amiga/APUS ;-)
  
  I found this device tree that has the pnpPNP,100 device for an Amiga.
 
 http://www.nabble.com/Re:-Problem-with-OF-interrupt-parsing-code-p12988017.html
 
 Ah yes, the AmigaOne. That's more a rebranded CHRP box...
 Has nothing to do with CONFIG_AMIGA.
Right. And it's not even officially supported in the kernel yet
(unfortunately).

regards,

Gerhard

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Kernel locks up after calling kernel_execve()

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Fri, 09 Nov 2007 18:50:29 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: Kernel locks up after calling kernel_execve()

 
  I tried to use /bin/sh as init program and was able to enter a command,
  but then the machine locked up, too.
  Could that be a problem with a CPU sleeping/idle code?
 
 That's possibly an issue, try disabling power save if any for that CPU
 type. If it worked and broke, you may have to bisect tho.
I disabled the powersaving code by adding powersave=off to the kernel's
command line, but it didn't help. It seems to lockup whenever it tries to
access a filesystem.
Is there a way to debug it without a hardware debugger or can you
recommend a cheap hardware debugger?

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Kernel locks up after calling kernel_execve()

[Gerhard Pircher]

Hi,

I tested my patches for the AmigaOne platform with the lastest 2.6.24-rc2
kernel snapshot. The kernel runs through all initcalls, but locks up
completely after calling INIT (/sbin/init) by kernel_execve(). Thus I
couldn't capture any kernel oops or panic output. Also the magic sysrq
key doesn't work. Enabling debug code for soft lockups and spinlock
debugging didn't reveal any information.
I'm not sure, but I think it is the same problem I had with all kernels
= 2.6.17. All of these kernels lock up shortly before or right at calling
the init program (resp. as soon as the kernel forks some kernel theads).
Any suggestions on how to track down this problem?

regards,

Gerhard

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Kernel locks up after calling kernel_execve()

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Fri, 09 Nov 2007 10:20:17 +1100
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: Kernel locks up after calling kernel_execve()

 
 On Thu, 2007-11-08 at 22:47 +0100, Gerhard Pircher wrote:
  Hi,
  
  I tested my patches for the AmigaOne platform with the lastest
  2.6.24-rc2 kernel snapshot. The kernel runs through all initcalls, but
  locks up completely after calling INIT (/sbin/init) by kernel_execve().
  Thus I couldn't capture any kernel oops or panic output. Also the magic 
  sysrq key doesn't work. Enabling debug code for soft lockups and
  spinlock debugging didn't reveal any information.
  I'm not sure, but I think it is the same problem I had with all kernels
  = 2.6.17. All of these kernels lock up shortly before or right at
  calling the init program (resp. as soon as the kernel forks some kernel
  theads).
  Any suggestions on how to track down this problem?
 
 You don't have a HW debugger or anything like that ?
 
 Ben.
Unfortunately, no. A BDI2000 is too costly for me.

I tried to use /bin/sh as init program and was able to enter a command,
but then the machine locked up, too.
Could that be a problem with a CPU sleeping/idle code?

Gerhard

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Problem with OF interrupt parsing code

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Tue, 02 Oct 2007 07:39:47 +1000
 Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: Problem with OF interrupt parsing code

 Part of your problem is that interrupt-parent property. You shouldn't
 have such a property in a PCI host bridge. It's not technically illegal,
 but it's triggering the loop you've been experiencing.
Okay, I'll remove this one.

 If you want the parsing to fail for PCI devices (to get the fallback to
 config space values), you need to make sure it does fail. 
 
 Another option is to put an empty interrupt-map in there. That will
 guarantee failure.
 
 But that's all very ugly. I don't understand why you don't setup a
 proper map either from your bootloader, zImage wrapper or even prom_init
 or platform code.
I know that it's ugly, but the problem is how to distinguish the boards.
The only real difference I know of is the PCI interrupt mapping. The
northbridges chip revision for example is always the same, but CPU type,
amount of memory and PCI devices can appear in all possible combinations.
The firmware doesn't tell me, which board the kernel is runnning on, so I
would like to rely on this fall back here until I get the chance to
update the firmware (which is beyond my control).

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev