From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Tue, 29 Jul 2008 15:23:11 +0200 Subject: [U-Boot-Users] [PATCH] mpc85xx: fix upmconfig In-Reply-To: Your message of "Tue, 15 Jul 2008 10:49:56 +0200." <20080715084956.GA30428@www.tglx.de> Message-ID: <20080729132312.0558F248EC@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Andy, in message <20080715084956.GA30428@www.tglx.de> Sebastian Siewior wrote: > * Andy Fleming | 2008-07-14 19:32:56 [-0500]: ... > >This looks pretty good to me, but I'm not very familiar with this > >code. Could you explain a little more deeply what is wrong with the > >old way, and why the new way is better? I think I understand the > >problem with the BA_SHIFT (actually, it alarms me, a bit), but I'm not > the first part, changes the computation of the dummy address. The spec > [1] chap 14.4.4.2 referes to the dummy address as "...by a (dummy) write > transaction to the relevant UPM assigned bank." The address is assigned > in the relevant BRx[BA] register (bits 0-16 if not used extened > addresses) and therefore shift is wrong, logical and is correct. > > >so sure about using MSEL on one side of the ==, and not the other. > BRx[MSEL] specifies the machines used (table 14-4, pdf page 631 in my > document). MSEL is the mask while upmmask (UPMC, UPMB, or UPMB) is the > content of the register. For instance, if your BR[MSEL] register would > have all bits set (what is reserved / not legal) than the old compare > method would match UPMA, UPMB & UPMC where is the new method would skip > it. Any comment about the state of this patch? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Many aligators will be slain, but the swamp will remain.