* Question on USB gadget device driver for mpc 8272 on linux 2.6.14.
From: Jonathan Qiang @ 2006-01-27 0:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
Hi, all
Currently, I am doing on the USB gadget device driver for mpc8272, I
already got some packets on interruption route when my board in which
mpc82xx settled connect to Host.
But the SOF is always generated as the first interruption source. When
plugged USB cable in HOST, the USB controller will be set to reset
(USBER is [0x308]), and after reset, the interruption source event
changes its status to [0x108], which means running on IDLE and SOF. Why
It is not IN token?
I already disabled Frame timer when I probe the USB gadget controller.
[-- Attachment #2: Type: text/html, Size: 4483 bytes --]
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: David Hawkins @ 2006-01-27 0:10 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200601261120.48251.sr@denx.de>
>>I haven't looked for it yet, but do you know if there is a driver
>>for the Yosemite board I2C temperature sensor already written?
>
> The Analog Devices AD7414 is used on Yosemite/Yellowstone and it doesn't seem
> to be supported from the lm-sensors project right now. Shouldn't be that
> difficult to write a driver for it though.
Thanks Stefan, I'll take a shot at it then.
Dave
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Russell King @ 2006-01-26 23:03 UTC (permalink / raw)
To: Grant Grundler
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Linus Torvalds, Ivan Kokshaysky, Akinobu Mita, Chris Zankel,
dev-etrax, ultralinux, linux-m68k, linux-kernel, linuxsh-dev,
linux390, parisc-linux
In-Reply-To: <20060126230443.GC13632@colo.lackof.org>
On Thu, Jan 26, 2006 at 04:04:43PM -0700, Grant Grundler wrote:
> On Thu, Jan 26, 2006 at 04:40:21PM +0000, Russell King wrote:
> > Ok, I can see I'm going to lose this, but what the hell.
>
> Well, we agree. As Richard Henderson just pointed out, parisc
> is among those that can't load large immediate values either.
>
> > Let's compare the implementations, which are:
> ...
> > int arm_ffs(unsigned long word)
> > {
> > int k = 31;
> > if (word & 0x0000ffff) { k -= 16; word <<= 16; }
> > if (word & 0x00ff0000) { k -= 8; word <<= 8; }
> > if (word & 0x0f000000) { k -= 4; word <<= 4; }
> > if (word & 0x30000000) { k -= 2; word <<= 2; }
> > if (word & 0x40000000) { k -= 1; }
> > return k;
> > }
>
> Of those suggested, arm_ffs() is closest to what parisc
> currently has in assembly (see include/asm-parisc/bitops.h:__ffs()).
> But given how unobvious the parisc instruction nullification works,
> the rough equivalent in "C" (untested!) would look something like:
>
> unsigned int k = 31;
> if (word & 0x0000ffff) { k -= 16;} else { word >>= 16; }
> if (word & 0x000000ff) { k -= 8;} else { word >>= 8; }
> if (word & 0x0000000f) { k -= 4;} else { word >>= 4; }
> if (word & 0x00000003) { k -= 2;} else { word >>= 2; }
> if (word & 0x00000001) { k -= 1;}
> return k;
>
> I doubt that's better for arm but am curious how it compares.
> You have time to try it?
This is essentially the same as arm_ffs():
grundler_ffs:
mov r3, r0, asl #16
mov r3, r3, lsr #16
cmp r3, #0
moveq r0, r0, lsr #16
mov r3, #31
movne r3, #15
tst r0, #255
moveq r0, r0, lsr #8
subne r3, r3, #8
tst r0, #15
moveq r0, r0, lsr #4
subne r3, r3, #4
tst r0, #3
moveq r0, r0, lsr #2
subne r3, r3, #2
tst r0, #1
subne r3, r3, #1
mov r0, r3
mov pc, lr
only that the shifts, immediate values and the sense of some of the
conditional instructions have changed. Therefore, the parisc rough
equivalent looks like it would be suitable for ARM as well.
> > Clearly the smallest of the lot with the smallest register pressure,
> > being the best candidate out of the lot, whether we inline it or not.
>
> Agreed. But I expect parisc will have to continue using it's asm
> sequence and ignore the generic version. AFAIK, the compiler isn't that
> good with instruction nullification and I have other issues I'd
> rather work on.
Me too - already solved this problem once. However, I'd rather not
needlessly take a step backwards in the name of generic bitops.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Grant Grundler @ 2006-01-26 23:04 UTC (permalink / raw)
To: Grant Grundler, Akinobu Mita, linux-kernel, Ivan Kokshaysky,
Ian Molton, dev-etrax, David Howells, Yoshinori Sato,
Linus Torvalds, linux-ia64, Hirokazu Takata, linux-m68k,
Greg Ungerer, linux-mips, parisc-linux, linuxppc-dev, linux390,
linuxsh-dev, linuxsh-shmedia-dev, sparclinux, ultralinux,
Miles Bader, Andi Kleen, Chris Zankel
In-Reply-To: <20060126164020.GA27222@flint.arm.linux.org.uk>
On Thu, Jan 26, 2006 at 04:40:21PM +0000, Russell King wrote:
> Ok, I can see I'm going to lose this, but what the hell.
Well, we agree. As Richard Henderson just pointed out, parisc
is among those that can't load large immediate values either.
> Let's compare the implementations, which are:
...
> int arm_ffs(unsigned long word)
> {
> int k = 31;
> if (word & 0x0000ffff) { k -= 16; word <<= 16; }
> if (word & 0x00ff0000) { k -= 8; word <<= 8; }
> if (word & 0x0f000000) { k -= 4; word <<= 4; }
> if (word & 0x30000000) { k -= 2; word <<= 2; }
> if (word & 0x40000000) { k -= 1; }
> return k;
> }
Of those suggested, arm_ffs() is closest to what parisc
currently has in assembly (see include/asm-parisc/bitops.h:__ffs()).
But given how unobvious the parisc instruction nullification works,
the rough equivalent in "C" (untested!) would look something like:
unsigned int k = 31;
if (word & 0x0000ffff) { k -= 16;} else { word >>= 16; }
if (word & 0x000000ff) { k -= 8;} else { word >>= 8; }
if (word & 0x0000000f) { k -= 4;} else { word >>= 4; }
if (word & 0x00000003) { k -= 2;} else { word >>= 2; }
if (word & 0x00000001) { k -= 1;}
return k;
I doubt that's better for arm but am curious how it compares.
You have time to try it?
If not, no worries.
> 19 instructions. 2 registers. 0 register based shifts. More reasonable
> for inlining.
Yeah, about the same for parisc.
> Clearly the smallest of the lot with the smallest register pressure,
> being the best candidate out of the lot, whether we inline it or not.
Agreed. But I expect parisc will have to continue using it's asm
sequence and ignore the generic version. AFAIK, the compiler isn't that
good with instruction nullification and I have other issues I'd
rather work on.
cheers,
grant
^ permalink raw reply
* Re: [PATCH] Add support for lite5200b board.
From: John Rigby @ 2006-01-26 21:29 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Txema Lopez, John Rigby, linuxppc-embedded
In-Reply-To: <43D807E0.1090206@246tNt.com>
[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]
On 1/25/06, Sylvain Munaut <tnt@246tnt.com> wrote:
>
>
>
> Should apply fine on vanilla. My suggestion for now is take vanilla,
> apply this patch, then the 2-3 patch from Andrey for BestComm and stuff.
I was working on getting bestcomm and fec working, but forward porting
my old 2.6.10 code to current is turning out to be more difficult than I
expected.
If you already have working code then I'll stop working on them.
Where are these patches? I'm new to this list so I don't have much history.
Would I find these patches in the archive?
I haven't gotten around setup a git tree ... anyone know a good tutorial
> not only on how to checkout stuff but how to well manage a remote
> repository for publishing ?
>
>
> >> Looks good. But two comments :
> >>
> >> * Isn't a modif to the arch/ppc/platform/Makefile missing ?
> >> * What's the "cs-1" you turn on there :
> >>
> >>
> >>
> >>>
> >>> +#ifdef CONFIG_LITE5200B
> >>> + /* turn on cs1 */
> >>> + port_config |= 0x80000000;
> >>> +#endif
> >>>
> > What fix this ?
>
> It's to activate the second bank of DDR-SDRAM. However, I find that's
> the job of the bootloader. Fully initializing the memory subsystem is
> one of the few things the kernel expects, so I probably won't include
> this.
I agree completely.
My politics (at least for the 5200 stuff) is the boot loader should :
> * Init memory stuff like it wants (at least boot flash & all dynamic
> mem). The init of some static chipselect could be done in platform init.
> * Put the pin muxes & stuff to the "safest" mode (that is for example
> GPIO Input) execpt for what it requires for boot (like a console PSC and
> ethernet). All other pin mux (defnitive one) should be done in platform
> init depending on the board.
>
>
> >> I couldn't find the schema / real-doc of the Lite5200b,
> >> is this available somewhere on-line ?
> >>
> > Sylvain, I don't know if there are some Lite5200b doc on line, but I
> > have the schematics and could send to you or to anyone who want it.
>
> Yes, please, I'd appreciate an early copy.
> John sent the link to the User Manual but the latter hasn't the full
> schematic.
>
>
>
> Sylvain
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 3366 bytes --]
^ permalink raw reply
* mpc8260 fcc enet transmit time out
From: Hunter, David @ 2006-01-26 20:58 UTC (permalink / raw)
To: linuxppc-embedded
One day, hubert.loewenguth at thales-bm.com wrote:
> Everything works fine, but, if I do successive plugs/unplugs during=20
> important data transfert, The driver enter into an infinite loop:
> ...
> Is there anybody having encounter the same problem?
> Is there anybody having done some test of numerous plug/unplug
during=20
> important data transfert with a half-duplex connection on mpc8260?
> Is there anybody having an idea to help me ?
I have seen many symptoms involving the "NETDEV WATCHDOG: eth0: transmit
timed out" message, but so far I do not have a code fix for any of them.
:(
We (my employer) use an MPC8270 (mask 2K49M) and LXT971A PHY, with Linux
2.4.18. In our case we do have MII PHY interrupt. Like you, when I get
the transmit timeout, it repeats forever. But I do not see the problem
when doing successive plugs/unplugs of the Ethernet cable. Instead, I
get timeout during normal board operation, without human interaction.
In one customer site where our MPC8270 board is used, the customer uses
100 Mb half duplex Ethernet. During many weeks of normal operation,
several times the board did experience transmit timeout. One of the
times, this was output:
<-------- DUMP STARTS HERE ---------->
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c01aa380 (full) cur_rx c01aa220.
Tx @base c01aa308 :
9c00 0051 070f79a2
1c00 0056 070f7da2
1c00 0056 070f7ea2
1c00 0051 070f7ba2
1c80 003f 070f51c2
9c00 0056 070f50c2
9c00 0051 070f52c2
9c00 0056 070f53c2
9c00 0056 070f55c2
9c00 0051 070f54c2
dc00 0038 070f56c2
9c00 0056 070f57c2
9c00 0051 070f58c2
9c00 0056 070f59c2
9c00 0056 070f5ac2
bc00 0056 070f7ca2
Rx @base c01aa208 :
9c00 0040 0046f000
<--- snip: BD status are all 9c00 -->
9c00 0040 00461000
9c00 0040 00461800
9c00 0040 00460000
bc00 0040 00460800
<---------- DUMP ENDS HERE ---------->
Note that one TxBD has the status 0x1c80, indicating late collision
(BD_ENET_TX_LC). This is an unusual condition in Ethernet, but recovery
should still be possible. Like you, I suspect errata CPM 119, but I
have not tried the patch yet. (Development schedules and all that
jazz.)
As a workaround, we placed a 10/100 Mb hub between the board and the
customer's network, which negotiated the PHY up to 100 Mb full duplex.
The transmit timeout problem has not been seen since (to the best of my
knowledge.)
Back in the lab I have been able to reproduce the transmit timeout on a
100 Mb full duplex network. Like you, I added printk output where
fcc_enet_interrupt tests each BD_ENET_TX_* flag. In one case, I saw
this:
<-------- DUMP STARTS HERE ---------->
eth0: BDP=3Dc01aa370: Carrier lost
eth0: BDP=3Dc01aa370: Carrier lost
eth0: BDP=3Dc01aa330: Carrier lost
eth0: BDP=3Dc01aa360: Carrier lost
eth0: BDP=3Dc01aa348: Carrier lost
eth0: BDP=3Dc01aa310: Carrier lost
eth0: BDP=3Dc01aa318: Carrier lost
<---- Carrier lost repeats 61 more times, random BDP ---->
eth0: BDP=3Dc01aa348: Underrun
eth0: Restarting transmitter!!!
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
<-------- DUMP ENDS HERE ---------->
The Underrun message means TxBD status bit BD_ENET_TX_UN (0x0002) was
set. The last Tx ring data dump in your post shows the same thing.
That scares me, mainly because I don't know what it means. Does it mean
the SDMA transfer didn't end on time? I dunno. And what the heck is
carrier lost during TX in full duplex mode? It makes sense for half
duplex mode like your situation, but I can't make sense of it for full
duplex. Further, the underrun case has only happened once; in most
other cases, I get a transmit timeout wih absolutely no TxBD error bits
whatsoever, and no indication that a TX restart was even attempted.
That's even scarier. I also did try repeated plug/unplug of Ethernet
during peak normal operation (probably 5-10 Mb traffic) on the 100 Mb
full duplex network, but after 11 successive plugs I did not see any
timeouts.
I'm starting to wonder if I have a cache coherency problem. The buffer
descriptors are in main RAM and the data cache is turned on... Its just
a thought I picked up reading some prior posts that I can't rightly
recall.
I noted that the MPC8280 manual (online from Freescale) does now detail
the transmitter recovery procedure (section 30.10.1 FCC Transmit
Errors), and it's not nearly as simple as what fcc_enet.c implements in
any kernel version. Despite CPM37, they don't toggle GFMR[ENT] in
combination with the RESTART_TX command. Also, in 30.12.1 FCC
Transmitter Full Sequence, a command (either RESTART_TX or INIT_TRX)
must be issued after GFMR[ENT] is cleared but _before_ it is set. You
might try changing fcc_enet_interrupt to do this:
if (must_restart) {
volatile cpm8260_t *cp;
cep->fccp->fcc_gfmr &=3D ~FCC_GFMR_ENT;
cp =3D cpmp;
cp->cp_cpcr =3D
mk_cr_cmd(cep->fip->fc_cpmpage,
cep->fip->fc_cpmblock,
0x0c, CPM_CR_RESTART_TX) | CPM_CR_FLG;
while (cp->cp_cpcr & CPM_CR_FLG);
cep->fccp->fcc_gfmr |=3D FCC_GFMR_ENT;
}
I've not been able to work on the problem for some time (development
schedules and all that jazz), but I'll post my solution if I find one.
-Dave
DISCLAIMER:
Important Notice *************************************************
This e-mail may contain information that is confidential, privileged or =
otherwise protected from disclosure. If you are not an intended =
recipient of this e-mail, do not duplicate or redistribute it by any =
means. Please delete it and any attachments and notify the sender that =
you have received it in error. Unintended recipients are prohibited from =
taking action on the basis of information in this e-mail.E-mail messages =
may contain computer viruses or other defects, may not be accurately =
replicated on other systems, or may be intercepted, deleted or =
interfered with without the knowledge of the sender or the intended =
recipient. If you are not comfortable with the risks associated with =
e-mail messages, you may decide not to use e-mail to communicate with =
IPC. IPC reserves the right, to the extent and under circumstances =
permitted by applicable law, to retain, monitor and intercept e-mail =
messages to and from its systems.
^ permalink raw reply
* Re: [PATCH 1/6] {set,clear,test}_bit() related cleanup
From: Paul Jackson @ 2006-01-26 19:14 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-mips, linux-m68k, linux-ia64, spyro, ak, dhowells,
linuxppc-dev, gerg, sparclinux, uclinux-v850, ysato, takata,
linuxsh-shmedia-dev, torvalds, ink, rth, mita, chris, dev-etrax,
ultralinux, linux-kernel, linuxsh-dev, linux390, rmk,
parisc-linux
In-Reply-To: <20060126161426.GA1709@elf.ucw.cz>
Pavel wrote:
> cpu_set sounds *very* ambiguous. We have thing called cpusets,
Hmmm ... you're right. I've worked for quite some time on both
of these, and hadn't noticed this similarity before.
Oh well. Such is the nature of naming things. Sometimes nice
names resemble other nice names in unexpected ways.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* mpc82xx USB host driver
From: Dubb, Benjamin @ 2006-01-26 17:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
I'm unable to find a 2.4 usb host driver for the pq3/pq2. Can someone post a patch here or point me to it, please.
Thanks,
- Ben
DISCLAIMER:
Important Notice *************************************************
This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.
[-- Attachment #2: Type: text/html, Size: 1758 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Richard Henderson @ 2006-01-26 17:30 UTC (permalink / raw)
To: Edgar Toernig
Cc: linux-mips, linux-m68k, linux-ia64, Ian Molton, Andi Kleen,
David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Linus Torvalds, Ivan Kokshaysky, Akinobu Mita, Chris Zankel,
dev-etrax, ultralinux, linux-kernel, linuxsh-dev, linux390,
parisc-linux
In-Reply-To: <20060126053412.0da7f505.froese@gmx.de>
On Thu, Jan 26, 2006 at 05:34:12AM +0100, Edgar Toernig wrote:
> Why shift at all?
Becuase that *is* a valid architecture tuning knob. Most risc
machines can't AND with arbitrary constants like that, and loading
the constant might bulk things up more than just using the shift.
r~
^ permalink raw reply
* Re: [PATCH 1/6] {set,clear,test}_bit() related cleanup
From: Russell King @ 2006-01-26 16:47 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Linus Torvalds, Ivan Kokshaysky, Richard Henderson, Akinobu Mita,
Chris Zankel, dev-etrax, ultralinux, linux-m68k, linux-kernel,
linuxsh-dev, linux390, parisc-linux
In-Reply-To: <20060126161426.GA1709@elf.ucw.cz>
On Thu, Jan 26, 2006 at 05:14:27PM +0100, Pavel Machek wrote:
> > Index: 2.6-git/include/asm-x86_64/mmu_context.h
> > ===================================================================
> > --- 2.6-git.orig/include/asm-x86_64/mmu_context.h 2006-01-25 19:07:15.000000000 +0900
> > +++ 2.6-git/include/asm-x86_64/mmu_context.h 2006-01-25 19:13:59.000000000 +0900
> > @@ -34,12 +34,12 @@
> > unsigned cpu = smp_processor_id();
> > if (likely(prev != next)) {
> > /* stop flush ipis for the previous mm */
> > - clear_bit(cpu, &prev->cpu_vm_mask);
> > + cpu_clear(cpu, prev->cpu_vm_mask);
> > #ifdef CONFIG_SMP
> > write_pda(mmu_state, TLBSTATE_OK);
> > write_pda(active_mm, next);
> > #endif
> > - set_bit(cpu, &next->cpu_vm_mask);
> > + cpu_set(cpu, next->cpu_vm_mask);
> > load_cr3(next->pgd);
> >
> > if (unlikely(next->context.ldt != prev->context.ldt))
>
> cpu_set sounds *very* ambiguous. We have thing called cpusets, for
> example. I'd not guess that is set_bit in cpu endianity (is it?).
That's a problem for the cpusets folk - cpu_set predates them by a
fair time - it's part of the cpumask API. See include/linux/cpumask.h
Also, since cpu_vm_mask is a cpumask_t, the above change to me looks
like a bug fix in its own right.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Russell King @ 2006-01-26 16:40 UTC (permalink / raw)
To: Grant Grundler
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Linus Torvalds, Ivan Kokshaysky, Akinobu Mita, Chris Zankel,
dev-etrax, ultralinux, linux-m68k, linux-kernel, linuxsh-dev,
linux390, parisc-linux
In-Reply-To: <20060126161849.GA13632@colo.lackof.org>
On Thu, Jan 26, 2006 at 09:18:49AM -0700, Grant Grundler wrote:
> On Thu, Jan 26, 2006 at 08:55:41AM +0000, Russell King wrote:
> > Unfortunately that's not correct. You do not appear to have checked
> > the compiler output like I did - this code does _not_ generate
> > constant shifts.
>
> Russell,
> By "written stupidly", I thought Richard meant they could have
> used constants instead of "s". e.g.:
> if (word << 16 == 0) { b += 16; word >>= 16); }
> if (word << 24 == 0) { b += 8; word >>= 8); }
> if (word << 28 == 0) { b += 4; word >>= 4); }
>
> But I prefer what Edgar Toernig suggested.
Ok, I can see I'm going to lose this, but what the hell.
Firstly though, an out of line function call on ARM clobbers six out
of 11 CPU registers.
Let's compare the implementations, which are:
int toernig_ffs(unsigned long word)
{
int bit = 0;
word &= -word; // only keep the lsb.
if (word & 0xffff0000) bit |= 16;
if (word & 0xff00ff00) bit |= 8;
if (word & 0xf0f0f0f0) bit |= 4;
if (word & 0xcccccccc) bit |= 2;
if (word & 0xaaaaaaaa) bit |= 1;
return bit;
}
toernig_ffs:
rsb r3, r0, #0
and r0, r0, r3
mov r3, r0, lsr #16
bic r2, r0, #16711680
str lr, [sp, #-4]!
mov r3, r3, asl #16
ldr lr, .L7
ldr r1, .L7+4
ldr ip, .L7+8
cmp r3, #0
bic r2, r2, #255
and lr, r0, lr
and r1, r0, r1
and ip, r0, ip
movne r0, #16
moveq r0, #0
cmp r2, #0
orrne r0, r0, #8
cmp r1, #0
orrne r0, r0, #4
cmp ip, #0
orrne r0, r0, #2
cmp lr, #0
orrne r0, r0, #1
ldr pc, [sp], #4
.L8:
.align 2
.L7:
.word -1431655766
.word -252645136
.word -858993460
25 instructions. 3 words of additional data. 5 registers. 0 register
based shifts.
I feel that this is far too expensive to sanely inline - at least three
words of additional data for a use in a function, and has a high register
usage comparable to that of an out of line function.
int mita_ffs(unsigned long word)
{
int b = 0, s;
s = 16; if (word << 16 != 0) s = 0; b += s; word >>= s;
s = 8; if (word << 24 != 0) s = 0; b += s; word >>= s;
s = 4; if (word << 28 != 0) s = 0; b += s; word >>= s;
s = 2; if (word << 30 != 0) s = 0; b += s; word >>= s;
s = 1; if (word << 31 != 0) s = 0; b += s;
return b;
}
mita_ffs:
movs r1, r0, asl #16
moveq r2, #16
movne r2, #0
mov r0, r0, lsr r2 @ register-based shift
mov r3, r2
movs r2, r0, asl #24
moveq r2, #8
movne r2, #0
mov r0, r0, lsr r2 @ register-based shift
movs r1, r0, asl #28
add r3, r3, r2
moveq r2, #4
movne r2, #0
mov r0, r0, lsr r2 @ register-based shift
movs r1, r0, asl #30
add r3, r3, r2
moveq r2, #2
movne r2, #0
mov r0, r0, lsr r2 @ register-based shift
tst r0, #1
add r3, r3, r2
moveq r2, #1
movne r2, #0
add r3, r3, r2
mov r0, r3
mov pc, lr
26 instructions. 4 registers used. 4 unconditional register-based
shifts (expensive).
Better, but uses inefficient register based shifts (which can take twice
as many cycles as non-register based shifts depending on the CPU). Still
has a high usage on CPU registers though. Could possibly be a candidate
for inlining.
int arm_ffs(unsigned long word)
{
int k = 31;
if (word & 0x0000ffff) { k -= 16; word <<= 16; }
if (word & 0x00ff0000) { k -= 8; word <<= 8; }
if (word & 0x0f000000) { k -= 4; word <<= 4; }
if (word & 0x30000000) { k -= 2; word <<= 2; }
if (word & 0x40000000) { k -= 1; }
return k;
}
arm_ffs:
mov r3, r0, asl #16
mov r3, r3, lsr #16
cmp r3, #0
movne r0, r0, asl #16
mov r3, #31
movne r3, #15
tst r0, #16711680
movne r0, r0, asl #8
subne r3, r3, #8
tst r0, #251658240
movne r0, r0, asl #4
subne r3, r3, #4
tst r0, #805306368
movne r0, r0, asl #2
subne r3, r3, #2
tst r0, #1073741824
subne r3, r3, #1
mov r0, r3
mov pc, lr
19 instructions. 2 registers. 0 register based shifts. More reasonable
for inlining.
Clearly the smallest of the lot with the smallest register pressure,
being the best candidate out of the lot, whether we inline it or not.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Grant Grundler @ 2006-01-26 16:18 UTC (permalink / raw)
To: Akinobu Mita, linux-kernel, Ivan Kokshaysky, Ian Molton,
dev-etrax, David Howells, Yoshinori Sato, Linus Torvalds,
linux-ia64, Hirokazu Takata, linux-m68k, Greg Ungerer, linux-mips,
parisc-linux, linuxppc-dev, linux390, linuxsh-dev,
linuxsh-shmedia-dev, sparclinux, ultralinux, Miles Bader,
Andi Kleen, Chris Zankel
In-Reply-To: <20060126085540.GA15377@flint.arm.linux.org.uk>
On Thu, Jan 26, 2006 at 08:55:41AM +0000, Russell King wrote:
> Unfortunately that's not correct. You do not appear to have checked
> the compiler output like I did - this code does _not_ generate
> constant shifts.
Russell,
By "written stupidly", I thought Richard meant they could have
used constants instead of "s". e.g.:
if (word << 16 == 0) { b += 16; word >>= 16); }
if (word << 24 == 0) { b += 8; word >>= 8); }
if (word << 28 == 0) { b += 4; word >>= 4); }
But I prefer what Edgar Toernig suggested.
grant
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Nicolas Pitre @ 2006-01-26 16:30 UTC (permalink / raw)
To: Grant Grundler
Cc: linux-mips, linux-m68k, linux-ia64, Ian Molton, Andi Kleen,
David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Linus Torvalds, Ivan Kokshaysky, Akinobu Mita, Chris Zankel,
dev-etrax, ultralinux, lkml, linuxsh-dev, linux390, parisc-linux
In-Reply-To: <20060126161849.GA13632@colo.lackof.org>
On Thu, 26 Jan 2006, Grant Grundler wrote:
> On Thu, Jan 26, 2006 at 08:55:41AM +0000, Russell King wrote:
> > Unfortunately that's not correct. You do not appear to have checked
> > the compiler output like I did - this code does _not_ generate
> > constant shifts.
>
> Russell,
> By "written stupidly", I thought Richard meant they could have
> used constants instead of "s". e.g.:
> if (word << 16 == 0) { b += 16; word >>= 16); }
> if (word << 24 == 0) { b += 8; word >>= 8); }
> if (word << 28 == 0) { b += 4; word >>= 4); }
>
> But I prefer what Edgar Toernig suggested.
It is just as bad on ARM since it requires large constants that cannot
be expressed with immediate litteral values. The constant shift
approach is really the best on ARM.
Nicolas
^ permalink raw reply
* Re: [PATCH 1/6] {set,clear,test}_bit() related cleanup
From: Pavel Machek @ 2006-01-26 16:14 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-dev, Linus Torvalds,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, linux-m68k, linux-kernel, linuxsh-shmedia-dev,
linux390, Russell King, parisc-linux
In-Reply-To: <20060125112857.GB18584@miraclelinux.com>
Hi!
> While working on these patch set, I found several possible cleanup
> on x86-64 and ia64.
It is probably not your fault, but...
> Index: 2.6-git/include/asm-x86_64/mmu_context.h
> ===================================================================
> --- 2.6-git.orig/include/asm-x86_64/mmu_context.h 2006-01-25 19:07:15.000000000 +0900
> +++ 2.6-git/include/asm-x86_64/mmu_context.h 2006-01-25 19:13:59.000000000 +0900
> @@ -34,12 +34,12 @@
> unsigned cpu = smp_processor_id();
> if (likely(prev != next)) {
> /* stop flush ipis for the previous mm */
> - clear_bit(cpu, &prev->cpu_vm_mask);
> + cpu_clear(cpu, prev->cpu_vm_mask);
> #ifdef CONFIG_SMP
> write_pda(mmu_state, TLBSTATE_OK);
> write_pda(active_mm, next);
> #endif
> - set_bit(cpu, &next->cpu_vm_mask);
> + cpu_set(cpu, next->cpu_vm_mask);
> load_cr3(next->pgd);
>
> if (unlikely(next->context.ldt != prev->context.ldt))
cpu_set sounds *very* ambiguous. We have thing called cpusets, for
example. I'd not guess that is set_bit in cpu endianity (is it?).
Pavel
--
Thanks, Sharp!
^ permalink raw reply
* Re: Error: Three ML403 boards
From: Paula Saameño @ 2006-01-26 14:07 UTC (permalink / raw)
To: Peter Ryser, linuxppc-embedded
In-Reply-To: <259581790601110038w5c4164bcy3a4b2ba916195fa@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]
Hi again,
Finally, I get those three boards working with 2.4. It was a hardware
problem. I had written in ddr size 0x40000000, when it should be 0x4000000
(one extra 0, oops!).
I don't really know why it worked in the first one, haha!
Thank you very much!!!
Paula
On 1/11/06, Paula Saameño <gnathita@gmail.com> wrote:
>
>
> Hi, Peter,
>
> I have already checked that record, and even fixing that bug and adding
> the C_APU_CONTROL parameter, it still does not work in any board but one.
>
> Anyone has suffered the same issue or have any idea of why it is
> happening??
>
> Thanks a lot!
> Paula
>
>
> On 1/10/06, Peter Ryser <peter.ryser@xilinx.com> wrote:
> >
> > Paula,
> >
> > please verify that you are not running into the problem described in
> > Xilinx Answer Record 22179
> > (http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=22179
> > ).
> >
> > - Peter
> >
> >
> > Paula Saameño wrote:
> >
> > > Hello,
> > >
> > > I have 3 Xilinx ML403 boards. I have implemented a 2.4 kernel with a
> > > basic configuration, with network support, systemACE, IIC... and it
> > > works perfectly in one of them.
> > >
> > > However, when I put the ACE card, without making any change, in other
> > > ML403 board, it does not work. The .ace file is loaded ok but then the
> > > network leds (6 leds) start blinking and nothing else happens.
> > >
> > > I have tried with two ML403 different boards, and I have no idea of
> > > where the problem is. They should work in the same way, don't they?
> > >
> > > Any help would be great.
> > >
> > > Also, I am trying to load a 2.6 kernel, but I am still on the way. I
> > > will let you know if I get it working.
> > >
> > > Thanks a lot!
> > > Paula
> > >
> >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >Linuxppc-embedded mailing list
> > >Linuxppc-embedded@ozlabs.org
> > >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> >
> >
> >
> >
>
[-- Attachment #2: Type: text/html, Size: 3324 bytes --]
^ permalink raw reply
* HELP! Memory mapping and address space doubts
From: Jose França (Ext_GTBC) @ 2006-01-26 14:04 UTC (permalink / raw)
To: linuxppc-embedded
Hello u all!
I need to clarify some aspects of the memory management in ppc linux =
and i hope that you could help me.
Lets imagine we have a mpc8272 based board with 3 devices A, B and C.In =
the bootloader (in my case, i use u-boot), i configured the BRx and Orx =
so that A has base address X, B has base address Y and C has base =
address Z. My first doubt arrises here: what address should i use? Being =
SDRAM base address 0x00000000 and kernel base address 0xC0000000, where =
will i put these devices mapped on? Above 0xC0000000 or in between the =
end of physical memory and 0xC0000000? Do i really need to configure the =
BAT registers in u boot?
In linux 2.4 kernel, we have ppc_md.setup_io_mappings to map address =
blocks into the BAT registers... As i observed in the kernel source tree =
examples, we must map CPM (why?). And what about the other devices A, B =
and C? How will i setup them in this case and what addresses i can use? =
Above 0xC0000000 or in between the end of physical memory and =
0xC0000000? Is the SDRAM included?
Thanks in advance to all contributions! All of them will be most =
welcomed!
Best regards,
Filipe
^ permalink raw reply
* RE: Linux kernel and u-boot debugging with Eclipse IDE
From: IGOR LURI @ 2006-01-26 10:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]
We have rev. B CPU (MPC5200LiteB evaluation board), and we have found that Eclipse don´t see difference between two files with the same name but different path, that's why we thought Eclipse had problems understanding u-boot symbols.
Now, we have removed all folders under "board" and "cpu" except "icecube" and "mpc5xxx". Also we have removed "lib_arm", "lib_i386", etc. except "lib_generic" and "lib_ppc" folders, and we have debugged u-boot until it relocates in RAM. At this point, the stack is moved from internal SRAM to the SDRAM. Eclipse has problems when it examines the stack and it shows the folowing error message:
< instantanea21.png >
In the other hand, if we see the backtrace with DDD, it shows the same error but it continues showing the stack.
< instantanea11.png >
Answering people who says Metrowerks IDE is better than DDD etc., we could say that Eclipse IDE is a very good choice, even better than Metrowerks and its open source.
Igor Luri
R&D Software Department
Fagor Automation S. Coop.
-----Mensaje original-----
De: wd@denx.de [mailto:wd@denx.de]
Enviado el: miércoles, 25 de enero de 2006 12:43
Para: IGOR LURI
CC: linuxppc-embedded@ozlabs.org
Asunto: Re: Linux kernel and u-boot debugging with Eclipse IDE
In message <918EB199DDDFFA42BEA2EB3A1C6021F399AFAD@correo.fagorautomation.net> you wrote:
>
> We have a MPC5200Lite board running Linux 2.4.25 and u-boot 1.1.4. We
> are able to debug Linux kernel and U-boot using DDD/GDB and BDI2000, and
> we are trying to use Eclipse IDE (with CDT plugin) / BDI2000 to develop
> and debug software.
Are you sure that U-Boot and Kernel debugging works fine with GDB? So
is this a rev. B CPU then? If not, please read the errata!
> Eclipse works well to remote debugging aplications over ethernet,
> however, we are not able to debug Linux kernel or u-boot using Eclipse.
> When it stops in the first breakpoint, I can´t view some variables and
> stepping into a function, it shows another. It seems that Eclipse has
> problems with Linux kernel and u-boot symbols.
My guess is that what you see is the effects of the chip errata -
please read the errata sheet.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
- Antoine de Saint-Exupery
[-- Attachment #2: instantánea1.png --]
[-- Type: image/png, Size: 12938 bytes --]
[-- Attachment #3: instantánea2.png --]
[-- Type: image/png, Size: 117172 bytes --]
^ permalink raw reply
* [PATCH] Remove arch/ppc/syslib/ppc4xx_pm.c
From: Alexey Dobriyan @ 2006-01-26 10:50 UTC (permalink / raw)
To: Andrew Morton, Paul Mackerras; +Cc: linuxppc-dev, Domen Puncer, linux-kernel
From: Domen Puncer <domen@coderock.org>
Remove nowhere referenced file ("grep ppc4xx_pm -r ." didn't find anything).
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
arch/ppc/syslib/ppc4xx_pm.c | 47 --------------------------------------------
1 file changed, 47 deletions(-)
--- a/arch/ppc/syslib/ppc4xx_pm.c
+++ b/arch/ppc/syslib/ppc4xx_pm.c
@@ -1,47 +0,0 @@
-/*
- * Author: Armin Kuster <akuster@mvista.com>
- *
- * 2002 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- *
- * This an attempt to get Power Management going for the IBM 4xx processor.
- * This was derived from the ppc4xx._setup.c file
- */
-
-#include <linux/config.h>
-#include <linux/init.h>
-
-#include <asm/ibm4xx.h>
-
-void __init
-ppc4xx_pm_init(void)
-{
-
- unsigned int value = 0;
-
- /* turn off unused hardware to save power */
-#ifdef CONFIG_405GP
- value |= CPM_DCP; /* CodePack */
-#endif
-
-#if !defined(CONFIG_IBM_OCP_GPIO)
- value |= CPM_GPIO0;
-#endif
-
-#if !defined(CONFIG_PPC405_I2C_ADAP)
- value |= CPM_IIC0;
-#ifdef CONFIG_STB03xxx
- value |= CPM_IIC1;
-#endif
-#endif
-
-
-#if !defined(CONFIG_405_DMA)
- value |= CPM_DMA;
-#endif
-
- mtdcr(DCRN_CPMFR, value);
-
-}
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: Stefan Roese @ 2006-01-26 10:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43D7D334.3070709@ovro.caltech.edu>
On Wednesday 25 January 2006 20:36, David Hawkins wrote:
> I haven't looked for it yet, but do you know if there is a driver
> for the Yosemite board I2C temperature sensor already written?
The Analog Devices AD7414 is used on Yosemite/Yellowstone and it doesn't seem
to be supported from the lm-sensors project right now. Shouldn't be that
difficult to write a driver for it though.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Russell King @ 2006-01-26 8:55 UTC (permalink / raw)
To: Akinobu Mita, linux-kernel, Ivan Kokshaysky, Ian Molton,
dev-etrax, David Howells, Yoshinori Sato, Linus Torvalds,
linux-ia64, Hirokazu Takata, linux-m68k, Greg Ungerer, linux-mips,
parisc-linux, linuxppc-dev, linux390, linuxsh-dev,
linuxsh-shmedia-dev, sparclinux, ultralinux, Miles Bader,
Andi Kleen, Chris Zankel
In-Reply-To: <20060126000618.GA5592@twiddle.net>
On Wed, Jan 25, 2006 at 04:06:18PM -0800, Richard Henderson wrote:
> On Wed, Jan 25, 2006 at 08:02:50PM +0000, Russell King wrote:
> > > + s = 16; if (word << 16 != 0) s = 0; b += s; word >>= s;
> > > + s = 8; if (word << 24 != 0) s = 0; b += s; word >>= s;
> > > + s = 4; if (word << 28 != 0) s = 0; b += s; word >>= s;
> ...
> > Basically, shifts which depend on a variable are more expensive than
> > constant-based shifts.
>
> Actually, they're all constant shifts. Just written stupidly.
Unfortunately that's not correct. You do not appear to have checked
the compiler output like I did - this code does _not_ generate
constant shifts.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Ian Molton @ 2006-01-25 23:25 UTC (permalink / raw)
To: Russell King
Cc: linux-mips, linux-m68k, linux-ia64, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Linus Torvalds, Ivan Kokshaysky, Richard Henderson, Akinobu Mita,
Chris Zankel, dev-etrax, ultralinux, linux-kernel, linuxsh-dev,
linux390, parisc-linux
In-Reply-To: <20060125200250.GA26443@flint.arm.linux.org.uk>
Russell King wrote:
> This code generates more expensive shifts than our (ARMs) existing C
> version. This is a backward step.
>
> Basically, shifts which depend on a variable are more expensive than
> constant-based shifts.
arm26 will have the same problem here.
^ permalink raw reply
* Re: [PATCH] Updated Patch to add support for Freescale 83xx Host Mode USB
From: Kumar Gala @ 2006-01-26 5:15 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20060125161959.GC4390@dmt.cnet>
On Jan 25, 2006, at 10:19 AM, Marcelo Tosatti wrote:
> On Mon, Jan 23, 2006 at 04:59:33PM -0700, Randy Vinson wrote:
>> Greetings,
>> I've attached an updated patch (based on 2.6.16-rc1) which adds
>> Host mode support for the Dual-Role(DR) and Multi-Port-Host (MPH) USB
>> controllers found in the Freescale 8349. The update was to
>> reconcile the
>> port numbering scheme such that it matches the 8349 documentation.
>> Since
>> my previous patch has not yet gone upstream, the maintainer
>> requested a
>> fresh patch.
>>
>> Note that this patch only provides the platform-specific code that
>> sets up the external hardware and pin configuration. The actual DR
>> and
>> MPH controller driver was posted on the linux-usb-devel mailing list.
>>
>> Using a Freescale 8349CDS reference board, the DR and MPH
>> controllers have been successfully tested using a USB 2.0 high speed
>> FLASH drive, a USB 1.1 full speed 4-port hub and a Siemens
>> SpeedStream
>> USB to Ethernet adapter (assuming the previous 8349 driver updates
>> posted to linux-usb-devel have been applied).
>>
>> Randy Vinson
>> MontaVista Software
>
>> Adding platform support for the 834x Host Mode USB controller.
>>
>> This patch provides the platform-specific hardware setup required
>> by the
>> 83xx Host Mode USB controller on the Freescale 8349CDS reference
>> system.
>>
>> Signed-off-by: Randy Vinson <rvinson@mvista.com>
>>
>> ---
>> commit 30caa62b0e433b466b0880efa32375359b6e4fea
>> tree e9bacf15ad1a58f6f15a343a2b5f233affec0ca1
>> parent a3d36ef38dcdcbbc7e1860f2f92569145524b1d5
>> author Randy Vinson <rvinson@linuxbox.(none)> Mon, 23 Jan 2006
>> 16:46:39 -0700
>> committer Randy Vinson <rvinson@linuxbox.(none)> Mon, 23 Jan 2006
>> 16:46:39 -0700
>>
>> arch/ppc/Kconfig | 2 +
>> arch/ppc/platforms/83xx/Kconfig | 28 +++++++++
>> arch/ppc/platforms/83xx/mpc834x_sys.c | 100 +++++++++++++++++++++
>> ++++++++++++
>> arch/ppc/platforms/83xx/mpc834x_sys.h | 3 +
>> arch/ppc/syslib/mpc83xx_devices.c | 16 +++++
>> include/asm-ppc/mpc83xx.h | 17 ++++++
>> 6 files changed, 166 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
>> index 11899f0..b33b0eb 100644
>> --- a/arch/ppc/Kconfig
>> +++ b/arch/ppc/Kconfig
>> @@ -681,6 +681,8 @@ config EV64360
>> platform.
>> endchoice
>>
>> +source arch/ppc/platforms/83xx/Kconfig
>> +
>> config PQ2ADS
>> bool
>> depends on ADS8272
>> diff --git a/arch/ppc/platforms/83xx/Kconfig b/arch/ppc/platforms/
>> 83xx/Kconfig
>> new file mode 100644
>> index 0000000..90bc67a
>> --- /dev/null
>> +++ b/arch/ppc/platforms/83xx/Kconfig
>> @@ -0,0 +1,28 @@
>> +config 834x_USB_SUPPORT
>> + bool "834x USB Support"
>> + depends on MPC834x_SYS
>> + default y
>> + ---help---
>> + Enables support for the USB controllers on the MPC834x chip.
>> The 834x
>> + reference board is wired for only one USB port. That port may be
>> + used by either the MPH or DR USB controller.
>> + Requires USB Host EHCI support.
>> + If unsure, say Y.
>> +choice
>> + prompt "834x USB Controller Selection"
>> + depends on 834x_USB_SUPPORT
>> + default 834x_DR_USB_SUPPORT
>> +
>> +config 834x_DR_USB_SUPPORT
>> + bool "DR Controller"
>> + select USB_EHCI_ROOT_HUB_TT
>> + ---help---
>> + Select if using the Dual-Role (DR) USB controller.
>> +
>> +config 834x_MPH_USB_SUPPORT
>> + bool "MPH Controller"
>> + ---help---
>> + Select if using the Multi-Port-Host (MPH) USB controller.
>> +
>> +endchoice
>> +
>> diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c b/arch/ppc/
>> platforms/83xx/mpc834x_sys.c
>> index 012e1e6..319661e 100644
>> --- a/arch/ppc/platforms/83xx/mpc834x_sys.c
>> +++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
>> @@ -11,6 +11,9 @@
>> * 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.
>> + *
>> + * USB setup added by Randy Vinson <rvinson@mvista.com> based on
>> code from
>> + * Hunter Wu.
>> */
>>
>> #include <linux/config.h>
>> @@ -93,6 +96,99 @@ mpc83xx_exclude_device(u_char bus, u_cha
>> }
>> #endif /* CONFIG_PCI */
>>
>> +/*
>> + * Configure the on-chip USB controller. The MPC834xCDS only
>> supports the
>> + * second USB interface (port 1). This code sets up the hardware
>> and then
>> + * lets the platform driver take over device setup.
>> + */
>> +
>> +#ifdef CONFIG_834x_USB_SUPPORT
>> +void mpc834x_board_init(void)
>> +{
>> + unsigned char __iomem *bcsr;
>> + volatile unsigned char *bcsr5_p;
>> +
>> + /*
>> + * if SYS board is plug into PIB board,
>> + * force to use the PHY on SYS board
>> + * */
>> + bcsr = ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
>> + bcsr5_p = bcsr + BCSR5_OFF;
>> + if ( (*bcsr5_p & BCSR5_INT_USB) == 0 )
>> + *bcsr5_p = (*bcsr5_p | BCSR5_INT_USB);
>
> Randy,
>
> Can you please use in/out io accessors instead of direct memory
> references
> to ?
Marcelo, good comment. Just, an FYI. This patch of Randy's isn't
going into the kernel. I ask him to post it just so it was on list.
I wonder if sparse would be capable of warning for doing direct
pointer load/store on __iomem pointers.
- kumar
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Edgar Toernig @ 2006-01-26 4:34 UTC (permalink / raw)
To: Richard Henderson
Cc: linux-mips, linux-m68k, linux-ia64, Ian Molton, Kleen,
David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, Andi,
linuxsh-shmedia-dev, Linus Torvalds, Kokshaysky, Ivan,
Akinobu Mita, Chris Zankel, dev-etrax, ultralinux, linux-kernel,
linuxsh-dev, linux390, parisc-linux
In-Reply-To: <20060126000618.GA5592@twiddle.net>
Richard Henderson wrote:
>
> On Wed, Jan 25, 2006 at 08:02:50PM +0000, Russell King wrote:
> > > + s = 16; if (word << 16 != 0) s = 0; b += s; word >>= s;
> > > + s = 8; if (word << 24 != 0) s = 0; b += s; word >>= s;
> > > + s = 4; if (word << 28 != 0) s = 0; b += s; word >>= s;
> ...
> > Basically, shifts which depend on a variable are more expensive than
> > constant-based shifts.
>
> Actually, they're all constant shifts. Just written stupidly.
Why shift at all?
int ffs(u32 word)
{
int bit = 0;
word &= -word; // only keep the lsb.
if (word & 0xffff0000) bit |= 16;
if (word & 0xff00ff00) bit |= 8;
if (word & 0xf0f0f0f0) bit |= 4;
if (word & 0xcccccccc) bit |= 2;
if (word & 0xaaaaaaaa) bit |= 1;
return bit;
}
Ciao, ET.
^ permalink raw reply
* Re: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Paul Mackerras @ 2006-01-26 4:12 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-m68k, linux-ia64, ultralinux, Andi Kleen,
Linux Kernel Development, Linux/PPC Development, Chen, Kenneth W,
'Geert Uytterhoeven', sparclinux, linux390, linuxsh-dev,
parisc-linux
In-Reply-To: <20060126035004.GA11543@miraclelinux.com>
Akinobu Mita writes:
> I can fix this without changing the flags size for those architectures.
>
> 1. Introduce *_le_bit() bit operations which takes void *addr
> (already I have these functions in the scope of
> HAVE_ARCH_EXT2_NON_ATOMIC_BITOPS in my patch)
>
> 2. Change flags to __u8 flags[4] or __u8 flags[8] for each architectures.
>
> 3. Use *_le_bit() in include/linux/thread_info.h
Please don't do this, you'll break the powerpc assembly code that
tests bits in thread_info()->flags.
Paul.
^ permalink raw reply
* Re: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Akinobu Mita @ 2006-01-26 3:50 UTC (permalink / raw)
To: Chen, Kenneth W
Cc: linux-m68k, linux-ia64, ultralinux, Linux Kernel Development,
Andi Kleen, Linux/PPC Development, 'Geert Uytterhoeven',
sparclinux, linux390, linuxsh-dev, parisc-linux
In-Reply-To: <200601252002.k0PK2Mg31276@unix-os.sc.intel.com>
On Wed, Jan 25, 2006 at 12:02:21PM -0800, Chen, Kenneth W wrote:
> Geert Uytterhoeven wrote on Wednesday, January 25, 2006 9:19 AM
> > > I don't think you need to change the flags size.
> >
> > Passing a pointer to a 32-bit entity to a function that takes a
> > pointer to a 64-bit entity is a classical endianness bug. So it's
> > better to change it, before people copy the code to a big endian
> > platform.
>
> Well, x86-64 and linux-ia64 both use little endian. I don't
> understand why you are barking at us with big endian issue.
>
I can fix this without changing the flags size for those architectures.
1. Introduce *_le_bit() bit operations which takes void *addr
(already I have these functions in the scope of
HAVE_ARCH_EXT2_NON_ATOMIC_BITOPS in my patch)
2. Change flags to __u8 flags[4] or __u8 flags[8] for each architectures.
3. Use *_le_bit() in include/linux/thread_info.h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox