From: Marc Leeman <marc.leeman@barco•com>
To: Jeff Angielski <jeff@theptrgroup•com>
Cc: linuxppc-dev@lists•linuxppc.org
Subject: Re: PCI Memory mapping
Date: Thu, 1 Apr 2004 14:33:40 +0200 [thread overview]
Message-ID: <20040401123340.GA6085@smtp.barco.com> (raw)
In-Reply-To: <20040331155625.GB28919@smtp.barco.com>
> I'll masking PICR2 with this tomorrow...
I have obtained some results by setting some 8245 registers at bootup.
I tested the following:
. enabling NO_SNOOP_EN (27 in PICR2): nfs does not boot anymore
. increasing the snoop and address wait cycles to 5 (default ppc bootup),
no real change.
. disable speculative reads (2 in PICR1): doesn't boot nfs anymore
(via eepro100?)
No real success, until I came accross the PCMBCR register which defines
the number of PCI to Local Memory Read and Write Buffers. When I set
both to 1 ( & 0xF0), the data copy back is no longer needed to assure
data consistency between the PPC and DSP (default is 4 32 byte buffers).
include/mpc824x.h:
#define PCMBCR 0x800000e1 /* PCI/Memory Buffer Configuration
Register */
cpu/mpc824x/cpu_init.c:
CONFIG_READ_BYTE(PCMBCR,val);
CONFIG_WRITE_BYTE(PCMBCR,(val | 0xF0));
Double checking this by setting both on 4 again (during cpu_init of
ppcboot) resulted in severe MPEG data corruption. These results at least
seems to point in the direction you suggested.
This is the only way I seem to be able to assure data consistency (the
kernel copy back is no longer required), but the documentation also
suggests that (obviously) this degrades performance and is mainly used
for debugging.0
Still, when reading the explanations that could case this behaviour
(copy back buffer and filling the PCMRBs) , they point to cache
operations, which, I thought, were disabled in the linux kernel for
these particular PCI mapped buffers.
By adding __asm__ __volatile__("eieio"); in user and kernel space,
which lets the CCU buffers to be flushed, no change is observed (sect.
5.4.3.1; CCU Responses to the Processor Transactions).
It looks to me as if I should disable the bus snooping, but as mentioned
before, initialising this in ppc boot inhibits the NFS boot process.
Can this be disabled at runtime (possibly with re-enabling it) and if
so, is this a good practice to do so?
marc.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-04-01 12:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-16 11:40 PCI Memory mapping Marc Leeman
2004-03-16 16:39 ` Jeff Angielski
2004-03-22 7:48 ` Marc Leeman
2004-03-22 11:02 ` Marc Leeman
2004-03-23 11:17 ` Marc Leeman
2004-03-23 16:01 ` Marc Leeman
2004-03-24 2:04 ` Michael R. Zucca
2004-03-24 0:04 ` Benjamin Herrenschmidt
2004-03-24 12:26 ` Marc Leeman
2004-03-24 14:25 ` Marc Leeman
2004-03-24 17:08 ` linas
2004-03-25 15:48 ` Marc Leeman
2004-03-25 16:34 ` linas
2004-03-25 16:45 ` linas
2004-03-26 8:00 ` Marc Leeman
2004-03-30 19:49 ` Jeff Angielski
2004-03-31 15:56 ` Marc Leeman
2004-03-31 16:02 ` Marc Leeman
2004-04-01 12:33 ` Marc Leeman [this message]
2004-04-04 22:53 ` Benjamin Herrenschmidt
2004-04-05 8:46 ` Adrian Cox
[not found] ` <20040402140130.GG22365@smtp.barco.com>
[not found] ` <1081175362.20952.30.camel@localhost.localdomain>
2004-04-06 6:21 ` Marc Leeman
-- strict thread matches above, loose matches on Subject: below --
2004-04-07 7:15 Marc Leeman
2011-04-15 5:44 koteswararaom
2011-04-15 6:32 ` David Hawkins
2011-04-15 6:48 ` Michael Neuling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040401123340.GA6085@smtp.barco.com \
--to=marc.leeman@barco$(echo .)com \
--cc=jeff@theptrgroup$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox