* Setting GPIO to trigger interrupt on mpc85xx
From: Kenny Ho @ 2011-01-21 20:47 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3207 bytes --]
Hi,
I am working on the fsl P1020rdb kit with the 2.6.32 linux kernel that
came with the kit and I am trying to get an GPIO to trigger an
interrupt. I am fairly new and have been stumbling for quite a bit with
no success so I am hoping some of you experts out there can give me some
pointers.
**What I have tried so far**:
I am implementing the interrupt setup on my custom GPIO module during
its init. I started following the information available in Linux Device
Drivers, Third Edition but it turns out to be out of date or
incompatible with the ppc platform. (The device tree, the hwirq to virq
mapping... even though the number turns out to be the same for GPIO,
etc.)
Initially I was only calling request_irq but I got ENOSYS. That was
solved by calling irq_create_mapping but then the module init was stuck
at the request_irq (with the isr continuously being called.) That was
resolved when I ended up using the device tree by calling
irq_of_parse_and_map and using set_irq_handler before calling
request_irq. Now the module successfully init and I can see the isr
entry in /proc/interrupt but when I physically toggle my GPIO pin, the
handler set by set_irq_handler was being called continuously (and then
crash) while the isr set by request_irq was never called.
Another thing I don't understand is that the /proc/interrupt entry say
the gpio interrupt is OpenPIC Level when the GPIO interrupt is suppose
to be edge only (either falling only or both.) My dts interrupt entry
for the GPIO is <47 2>, which should indicates edge trigger right?
**My questions**:
What are the relationship between set_irq_handler, set_irq_type and
request_irq? Are the first two supposed to be a replacement of the 3rd
or are they suppose to be used concurrently?
What are the differences between the handler set by set_irq_handler and
the isr set by request_irq? Which one is called first? Or should only
one of them get set at all time?
(I was reading
http://www.kernel.org/pub/linux/kernel/people/tglx/armirq/DocBook/index.
html but I am still very confused.)
Which signals are those IRQ type referring to? Are they referring to
the triggering signal (GPIO in my case) or the PIC signal to the cpu
core?
What are the things I need to do in the IRQ handler/isr to terminate an
interrupt? I know I need to clear the event register (which is GPIER in
my case) which I have done but that didn't stop the handler from getting
call again. Must I also disable the interrupt? For the isr set by
request_irq, I also return IRQ_HANDLED... is that sufficient?
For the handler set by set_irq_handler, do I need to call other handler?
I noticed there are generic_handle_irq and handle_(level/edge,
etc)_irq... am I suppose to call those to terminate an interrupt? I
also noticed there are eoi() and end() in desc->chip. (I assume those
are for the PIC)... am I suppose to call those as well?
As you can see... I am very much confused and have lots of questions.
Any help from you folks is much appreciated.
Regards,
Kenny Ho
[-- Attachment #2: Type: text/html, Size: 9192 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Fix some 6xx/7xxx CPU setup functions
From: Benjamin Herrenschmidt @ 2011-01-21 21:16 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikd14Kw02nzde19FsR9JUGA=c-xzVVXpkGLoUjf@mail.gmail.com>
On Fri, 2011-01-21 at 12:15 -0600, kevin diggs wrote:
> I have a GigE (PowerMac 3,4?) with an upgrade card that has a pair of
> 7455s on it and an 8600 with a 750GX cpu card. I can probably test
> this on the GigE. It is running 2.6.36. Is that recent enough? The
> 8600 is not cooperating.
>
> The GigE is running 2.6.36 compiled with 4.3.5 built from sources. It
> seems to run fine.
The bug would have caused the kernel to allow enabling of "nap" mode
when idle on machines where this is buggy and can cause loss of cache
coherency among others. I really don't remember off hand which specific
machines may or may not have been affected. But I'd like at least people
to verify that my patches to "fix" that aren't causing a regression for
people like you who don't seem to have problems :-)
The bug was introduced a while back in 2005.
Cheers,
Ben.
^ permalink raw reply
* Re: BootX
From: Benjamin Herrenschmidt @ 2011-01-21 21:21 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikAVgH9-UQfrjoAJSemet5p_PxhxCdot8cChQu3@mail.gmail.com>
On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
> Hi,
>
> Anyone familiar with BootX? Could my problems with the 8600 be related
> to some interaction with BootX?
It's possible. Have you tried using OF booting instead ? The 8600 should
be cable to boot off SCSI or netboot COFF images.
Cheers,
Ben.
^ permalink raw reply
* elf section .text.unlikely
From: kevin diggs @ 2011-01-22 1:40 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am trying to get a PowerMac 8600 to boot past 2.6.28.
I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get
2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section
'.text.unlikely' that the 3.4.6 version does not. Anyone know what
this might be?
kevin
^ permalink raw reply
* Re: BootX
From: kevin diggs @ 2011-01-22 1:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1295644908.2148.309.camel@pasglop>
Hi,
This would require quik, right? I went to penguinppc.org and tried to
get the latest BootX and quik but the links are dead. Do you know
where the latest versions are?
kevin
On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
>> Hi,
>>
>> Anyone familiar with BootX? Could my problems with the 8600 be related
>> to some interaction with BootX?
>
> It's possible. Have you tried using OF booting instead ? The 8600 should
> be cable to boot off SCSI or netboot COFF images.
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: BootX
From: Benjamin Herrenschmidt @ 2011-01-22 1:49 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=CVNC-UjdCyByyey_VnPHGtujuH01tquSQyqRm@mail.gmail.com>
On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote:
> Hi,
>
> This would require quik, right? I went to penguinppc.org and tried to
> get the latest BootX and quik but the links are dead. Do you know
> where the latest versions are?
That link still works:
> kevin
>
> On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
> >> Hi,
> >>
> >> Anyone familiar with BootX? Could my problems with the 8600 be related
> >> to some interaction with BootX?
> >
> > It's possible. Have you tried using OF booting instead ? The 8600 should
> > be cable to boot off SCSI or netboot COFF images.
> >
> > Cheers,
> > Ben.
> >
> >
^ permalink raw reply
* Re: BootX
From: Benjamin Herrenschmidt @ 2011-01-22 1:50 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=CVNC-UjdCyByyey_VnPHGtujuH01tquSQyqRm@mail.gmail.com>
On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote:
> Hi,
>
> This would require quik, right? I went to penguinppc.org and tried to
> get the latest BootX and quik but the links are dead. Do you know
> where the latest versions are?
That link still works:
Oops... typing FAIL :-)
I meant:
http://penguinppc.org/bootloaders/quik/
However, it's possible that distros like debian have done more changes to it.
Another option is to netboot a zImage directly, which works if it's not
too big.
Cheers,
Ben.
> kevin
>
> On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
> >> Hi,
> >>
> >> Anyone familiar with BootX? Could my problems with the 8600 be related
> >> to some interaction with BootX?
> >
> > It's possible. Have you tried using OF booting instead ? The 8600 should
> > be cable to boot off SCSI or netboot COFF images.
> >
> > Cheers,
> > Ben.
> >
> >
^ permalink raw reply
* Re: BootX
From: kevin diggs @ 2011-01-22 2:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1295661056.2148.334.camel@pasglop>
Hi,
The link:
http://www.shiner.info/?files/Yellow%20Dog%20Linux%204/quik
to download the latest source does not seem to have anything useful???
kevin
On Fri, Jan 21, 2011 at 7:50 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote:
>> Hi,
>>
>> This would require quik, right? I went to penguinppc.org and tried to
>> get the latest BootX and quik but the links are dead. Do you know
>> where the latest versions are?
>
> That link still works:
>
> Oops... typing FAIL :-)
>
> I meant:
>
> http://penguinppc.org/bootloaders/quik/
>
> However, it's possible that distros like debian have done more changes to it.
>
> Another option is to netboot a zImage directly, which works if it's not
> too big.
>
> Cheers,
> Ben.
>
>> kevin
>>
>> On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>> > On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
>> >> Hi,
>> >>
>> >> Anyone familiar with BootX? Could my problems with the 8600 be related
>> >> to some interaction with BootX?
>> >
>> > It's possible. Have you tried using OF booting instead ? The 8600 should
>> > be cable to boot off SCSI or netboot COFF images.
>> >
>> > Cheers,
>> > Ben.
>> >
>> >
>
>
>
>
^ permalink raw reply
* Re: elf section .text.unlikely
From: kevin diggs @ 2011-01-22 2:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTimbZh5KCD2tT3rE5prhOBV9D_-QVdLyu0usmvMw@mail.gmail.com>
For what it is worth, this section contains dump_stack, panic, and printk
Thanks!
kevin
On Fri, Jan 21, 2011 at 7:40 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> I am trying to get a PowerMac 8600 to boot past 2.6.28.
>
> I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get
> 2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section
> '.text.unlikely' that the 3.4.6 version does not. Anyone know what
> this might be?
>
> kevin
>
^ permalink raw reply
* Re: BootX
From: Benjamin Herrenschmidt @ 2011-01-22 2:31 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikitgJYiALMRmtKQTs_eYgzGbZpeMkpg2M478cj@mail.gmail.com>
On Fri, 2011-01-21 at 20:03 -0600, kevin diggs wrote:
> Hi,
>
> The link:
>
> http://www.shiner.info/?files/Yellow%20Dog%20Linux%204/quik
>
> to download the latest source does not seem to have anything useful???
Ah right. 2.0e is still there tho. Try to have a look at what's in
distros like debian or genpoo..
Cheers,
Ben.
> kevin
>
> On Fri, Jan 21, 2011 at 7:50 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote:
> >> Hi,
> >>
> >> This would require quik, right? I went to penguinppc.org and tried to
> >> get the latest BootX and quik but the links are dead. Do you know
> >> where the latest versions are?
> >
> > That link still works:
> >
> > Oops... typing FAIL :-)
> >
> > I meant:
> >
> > http://penguinppc.org/bootloaders/quik/
> >
> > However, it's possible that distros like debian have done more changes to it.
> >
> > Another option is to netboot a zImage directly, which works if it's not
> > too big.
> >
> > Cheers,
> > Ben.
> >
> >> kevin
> >>
> >> On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
> >> <benh@kernel.crashing.org> wrote:
> >> > On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
> >> >> Hi,
> >> >>
> >> >> Anyone familiar with BootX? Could my problems with the 8600 be related
> >> >> to some interaction with BootX?
> >> >
> >> > It's possible. Have you tried using OF booting instead ? The 8600 should
> >> > be cable to boot off SCSI or netboot COFF images.
> >> >
> >> > Cheers,
> >> > Ben.
> >> >
> >> >
> >
> >
> >
> >
^ permalink raw reply
* Re: elf section .text.unlikely
From: kevin diggs @ 2011-01-22 3:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTime0kT7rpVKvqZZ1uyib8GqBkgpQ6osDnfCrN0p@mail.gmail.com>
Hi,
One more thing:
The last message printed is:
Driver 'sd' needs updating - please us bus_type methods
The mesh SCSI controller seems to successfully scan the bus. The next
message that a 3.4.6 compiled kernel prints are details about disk sda
(from SCSI disk driver?).
4.3.5 keyboard is dead.
Jog any thoughts?
Thanks!
kevin
On Fri, Jan 21, 2011 at 8:31 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> For what it is worth, this section contains dump_stack, panic, and printk
>
> Thanks!
>
> kevin
>
> On Fri, Jan 21, 2011 at 7:40 PM, kevin diggs <diggskevin38@gmail.com> wrote:
>> Hi,
>>
>> I am trying to get a PowerMac 8600 to boot past 2.6.28.
>>
>> I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get
>> 2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section
>> '.text.unlikely' that the 3.4.6 version does not. Anyone know what
>> this might be?
>>
>> kevin
>>
>
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Joakim Tjernlund @ 2011-01-22 9:50 UTC (permalink / raw)
To: hs; +Cc: Wolfgang Denk, Rafael Beims, scottwood, linuxppc-dev, michael,
RFeany
In-Reply-To: <4D392D4E.2000004@denx.de>
Heiko Schocher <hs@denx.de> wrote on 2011/01/21 07:53:02:
> Hello Joakim,
>
> Joakim Tjernlund wrote:
> >> Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
> >>
> >> Rafael Beims <rbeims@gmail.com> wrote on 2011/01/10 17:35:38:
> >>>> Once you have tested it and it works, please send a patch to remove the 8xx workaround.
> >>>> Make sure Scott is cc:ed
> >>>>
> >>>>
> >>> I tested linux-2.6.33 on my ppc880 board today, and even without the
> >>> slowdown.patch applied, the board runs processes with good
> >>> performance.
> >>> It really seems that the problem is solved from linux-2.6.33 on.
> >>>
> >>> I'm not sure what you mean by sending a patch to remove the
> >>> workaround. The only thing that I did in the 2.6.32 version was to
> >>> apply the slowdown.patch attached in the message from Michael.
> >>>
> >>> Could you clarify please?
> >> Yes, this part in arch/powerpc/mm/pgtable.c:
> >> #ifdef CONFIG_8xx
> >> /* On 8xx, cache control instructions (particularly
> >> * "dcbst" from flush_dcache_icache) fault as write
> >> * operation if there is an unpopulated TLB entry
> >> * for the address in question. To workaround that,
> >> * we invalidate the TLB here, thus avoiding dcbst
> >> * misbehaviour.
> >> */
> >> /* 8xx doesn't care about PID, size or ind args */
> >> _tlbil_va(addr, 0, 0, 0);
> >> #endif /* CONFIG_8xx */
> >>
> >> Should be removed in >= 2.6.33 kernels.
> >> My 8xx TLB work fixes this problem more efficiently.
> >
> > Can you test these 2 patches on recent 2.6 linux:
> >>From 9024200169bf86b4f34cb3b1ebf68e0056237bc0 Mon Sep 17 00:00:00 2001
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Tue, 11 Jan 2011 13:43:42 +0100
> > Subject: [PATCH 1/2] powerpc: Move 8xx invalidation of non present TLBs
> [...]
> > and
> >
> >>From 0ef93601290a75b087495dddeee6062a870f1dc6 Mon Sep 17 00:00:00 2001
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Tue, 11 Jan 2011 13:55:22 +0100
> > Subject: [PATCH 2/2] powerpc: Remove 8xx redundant dcbst workaround.
>
> Tested this on a board similliar to the mainline tqm8xx board with
> lmbench:
>
> -bash-3.2# cat /proc/cpuinfo
> processor : 0
> cpu : 8xx
> clock : 80.000000MHz
> revision : 0.0 (pvr 0050 0000)
> bogomips : 10.00
> timebase : 5000000
> platform : KUP4K
> model : KUP4K
> Memory : 96 MB
> -bash-3.2#
>
> -bash-3.2# cat /proc/version
> Linux version 2.6.34-00064-g3e81b6b (hs@pollux.denx.de) (gcc version 4.2.2) #89 Thu Jan 20 08:39:52 CET 2011
> -bash-3.2#
>
> (First run of lmbench without your 2 patches, the two other runs with it)
Thanks,
>From a quick look, the only thing that really stands out is Prot Fault below:
> File & VM system latencies in microseconds - smaller is better
> -------------------------------------------------------------------------------
> Host OS 0K File 10K File Mmap Prot Page 100fd
> Create Delete Create Delete Latency Fault Fault selct
> --------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
> kup4k Linux 2.6.34- 16.7K 10.3K 90.9K 13.7K 22.6K 27.1 43.4 117.9
> kup4k Linux 2.6.34- 16.9K 15.6K 100.0K 16.1K 22.7K 9.590 39.8 119.2
> kup4k Linux 2.6.34- 16.7K 13.5K 100.0K 15.9K 22.8K 9.306 39.8 119.6
Anyhow, nothing broke so I am happy with the results.
On top of those 2 patches I came up with this cleanup patch too:
>From 920c236b290ee00d84506369e3898126c78215e8 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 18 Jan 2011 09:50:09 +0100
Subject: [PATCH 3/3] powerpc: Use symbolic constants in 8xx TLB asm
Use the PTE #defines where possible instead of
hardcoded constants.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/kernel/head_8xx.S | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 6cd99e2..31ed813 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -451,11 +451,11 @@ DataStoreTLBMiss:
* this into the Linux pgd/pmd and load it in the operation
* above.
*/
- rlwimi r11, r10, 0, 27, 27
+ rlwimi r11, r10, 0, _PAGE_GUARDED
/* Insert the WriteThru flag into the TWC from the Linux PTE.
* It is bit 25 in the Linux PTE and bit 30 in the TWC
*/
- rlwimi r11, r10, 32-5, 30, 30
+ rlwimi r11, r10, 32-5, _PAGE_WRITETHRU>>5
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
@@ -474,10 +474,10 @@ DataStoreTLBMiss:
rlwimi r10, r11, 0, _PAGE_PRESENT
#endif
/* Honour kernel RO, User NA */
- /* 0x200 == Extended encoding, bit 22 */
- rlwimi r10, r10, 32-2, 0x200 /* Copy USER to bit 22, 0x200 */
+ /* 0x200 == Encoding, bit 22 */
+ rlwimi r10, r10, 32-2, _PAGE_USER>>2 /* Copy USER to Encoding */
/* r11 = (r10 & _PAGE_RW) >> 1 */
- rlwinm r11, r10, 32-1, 0x200
+ rlwinm r11, r10, 32-1, _PAGE_RW>>1
or r10, r11, r10
/* invert RW and 0x200 bits */
xori r10, r10, _PAGE_RW | 0x200
--
1.7.3.4
^ permalink raw reply related
* Re: [patch 0/2] Sparse irq cleanup - Resend
From: Benjamin Herrenschmidt @ 2011-01-22 10:18 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-dev
In-Reply-To: <20110121142848.050196552@linutronix.de>
On Fri, 2011-01-21 at 16:12 +0000, Thomas Gleixner wrote:
> The following series cleans up the left overs of the old sparse irq
> code.
For some odd reason I forgot to put that in the last time around. I'll
try to remember to do so on monday before I go to LCA.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v5 06/27] powerpc: introduce little-endian bitops
From: Akinobu Mita @ 2011-01-22 13:13 UTC (permalink / raw)
To: linux-kernel, linux-arch, akpm; +Cc: linuxppc-dev, Paul Mackerras, Akinobu Mita
In-Reply-To: <1295702039-23186-1-git-send-email-akinobu.mita@gmail.com>
Introduce little-endian bit operations by renaming existing powerpc
native little-endian bit operations and changing them to take any
pointer types.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
Change from v4:
- change the prototypes and add casts in the macro to take any pointer types
The whole series is available in the git branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/mita/linux-2.6.git le-bitops-v5
arch/powerpc/include/asm/bitops.h | 46 ++++++++++++++++++------------------
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
index db567ed..a77f6be 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -281,27 +281,27 @@ unsigned long __arch_hweight64(__u64 w);
/* Little-endian versions */
-static __inline__ int test_le_bit(unsigned long nr,
- __const__ unsigned long *addr)
+static __inline__ int test_bit_le(unsigned long nr,
+ __const__ void *addr)
{
__const__ unsigned char *tmp = (__const__ unsigned char *) addr;
return (tmp[nr >> 3] >> (nr & 7)) & 1;
}
-#define __set_le_bit(nr, addr) \
- __set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define __clear_le_bit(nr, addr) \
- __clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
+#define __set_bit_le(nr, addr) \
+ __set_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
+#define __clear_bit_le(nr, addr) \
+ __clear_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
-#define test_and_set_le_bit(nr, addr) \
- test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define test_and_clear_le_bit(nr, addr) \
- test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
+#define test_and_set_bit_le(nr, addr) \
+ test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
+#define test_and_clear_bit_le(nr, addr) \
+ test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
-#define __test_and_set_le_bit(nr, addr) \
- __test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define __test_and_clear_le_bit(nr, addr) \
- __test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
+#define __test_and_set_bit_le(nr, addr) \
+ __test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
+#define __test_and_clear_bit_le(nr, addr) \
+ __test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
#define find_first_zero_bit_le(addr, size) \
find_next_zero_bit_le((addr), (size), 0)
@@ -313,16 +313,16 @@ unsigned long find_next_bit_le(const void *addr,
/* Bitmap functions for the ext2 filesystem */
#define ext2_set_bit(nr,addr) \
- __test_and_set_le_bit((nr), (unsigned long*)addr)
+ __test_and_set_bit_le((nr), (unsigned long*)addr)
#define ext2_clear_bit(nr, addr) \
- __test_and_clear_le_bit((nr), (unsigned long*)addr)
+ __test_and_clear_bit_le((nr), (unsigned long*)addr)
#define ext2_set_bit_atomic(lock, nr, addr) \
- test_and_set_le_bit((nr), (unsigned long*)addr)
+ test_and_set_bit_le((nr), (unsigned long*)addr)
#define ext2_clear_bit_atomic(lock, nr, addr) \
- test_and_clear_le_bit((nr), (unsigned long*)addr)
+ test_and_clear_bit_le((nr), (unsigned long*)addr)
-#define ext2_test_bit(nr, addr) test_le_bit((nr),(unsigned long*)addr)
+#define ext2_test_bit(nr, addr) test_bit_le((nr),(unsigned long*)addr)
#define ext2_find_first_zero_bit(addr, size) \
find_first_zero_bit_le((unsigned long*)addr, size)
@@ -334,13 +334,13 @@ unsigned long find_next_bit_le(const void *addr,
/* Bitmap functions for the minix filesystem. */
#define minix_test_and_set_bit(nr,addr) \
- __test_and_set_le_bit(nr, (unsigned long *)addr)
+ __test_and_set_bit_le(nr, (unsigned long *)addr)
#define minix_set_bit(nr,addr) \
- __set_le_bit(nr, (unsigned long *)addr)
+ __set_bit_le(nr, (unsigned long *)addr)
#define minix_test_and_clear_bit(nr,addr) \
- __test_and_clear_le_bit(nr, (unsigned long *)addr)
+ __test_and_clear_bit_le(nr, (unsigned long *)addr)
#define minix_test_bit(nr,addr) \
- test_le_bit(nr, (unsigned long *)addr)
+ test_bit_le(nr, (unsigned long *)addr)
#define minix_find_first_zero_bit(addr,size) \
find_first_zero_bit_le((unsigned long *)addr, size)
--
1.7.3.4
^ permalink raw reply related
* Re: BootX
From: kevin diggs @ 2011-01-22 18:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTikAVgH9-UQfrjoAJSemet5p_PxhxCdot8cChQu3@mail.gmail.com>
Hi,
If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that
WILL boot on the PowerMac8600 (single 750GX). The previously mentioned
G4 that runs is a dual cpu beast and thus also runs SMP.
I at least know this (ok, I THINK I know):
For non-SMP: The spinlock 'acct_lock' in kernel/acct.c that IS
present in 3.4.6 (i.e. kernel 2.6.28 compiled with gcc 3.4.6). Not so
much for 4.3.5. I have not yet done a general 4.3.5 compiled 2.6.28
spinlock safari.
Don't some funky, optimizery things happen to spinlocks for the NON-smp case?
I'll see what the 4.2.x gcc does.
Thanks!
kevin
P.S.: There is one other difference for the SMP 4.3.5 compiled
2.6.28: my 750gx cpufreq driver gets disabled. It is fairly isolated
code though. Should not be able to nuke the spinlock in kernel/acct.c
On Fri, Jan 21, 2011 at 1:26 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> Anyone familiar with BootX? Could my problems with the 8600 be related
> to some interaction with BootX?
>
> kevin
>
^ permalink raw reply
* Re: [PATCH V8 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Greg KH @ 2011-01-23 3:01 UTC (permalink / raw)
To: tmarri; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1295477836-14589-1-git-send-email-tmarri@apm.com>
On Wed, Jan 19, 2011 at 02:57:16PM -0800, tmarri@apm.com wrote:
> From: Tirumala Marri <tmarri@apm.com>
>
> v8:
> 1. Add set_wedge to usb_ep_ops.
>
> v7:
> 1. Fix sparse tool warnings.
> 2. Fix checkpatch errors and warnings.
> 3. Rename USB_OTG config variable to USB_DWC_CONFIG
>
> Tirumala Marri (10):
> USB/ppc4xx: Add Synopsys DWC OTG Register definitions
> USB/ppc4xx: Add Synopsys DWC OTG driver framework
> USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer
> USB/ppc4xx: Add Synopsys DWC OTG HCD function
> USB/ppc4xx: Add Synopsys DWC OTG HCD interrupt function
> USB/ppc4xx: Add Synopsys DWC OTG HCD queue function
> USB/ppc4xx: Add Synopsys DWC OTG PCD function
> USB ppc4xx: Add Synopsys DWC OTG PCD interrupt function
> USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
> USB ppc4xx: Add Synopsys DWC OTG driver kernel configuration and
> Makefile
>
> drivers/Makefile | 2 +
> drivers/usb/Kconfig | 3 +-
> drivers/usb/dwc_otg/Kconfig | 96 ++
Why are you creating a new subdirectory here? Shouldn't it be in
drivers/usb/otg/dwc/ instead?
> drivers/usb/dwc_otg/Makefile | 19 +
> drivers/usb/dwc_otg/dwc_otg_apmppc.c | 414 ++++++
> drivers/usb/dwc_otg/dwc_otg_cil.c | 972 ++++++++++++
> drivers/usb/dwc_otg/dwc_otg_cil.h | 1220 +++++++++++++++
> drivers/usb/dwc_otg/dwc_otg_cil_intr.c | 616 ++++++++
> drivers/usb/dwc_otg/dwc_otg_driver.h | 76 +
> drivers/usb/dwc_otg/dwc_otg_hcd.c | 2466 +++++++++++++++++++++++++++++++
> drivers/usb/dwc_otg/dwc_otg_hcd.h | 416 ++++++
> drivers/usb/dwc_otg/dwc_otg_hcd_intr.c | 1477 ++++++++++++++++++
> drivers/usb/dwc_otg/dwc_otg_hcd_queue.c | 696 +++++++++
> drivers/usb/dwc_otg/dwc_otg_param.c | 180 +++
> drivers/usb/dwc_otg/dwc_otg_pcd.c | 1766 ++++++++++++++++++++++
> drivers/usb/dwc_otg/dwc_otg_pcd.h | 139 ++
> drivers/usb/dwc_otg/dwc_otg_pcd_intr.c | 2311 +++++++++++++++++++++++++++++
> drivers/usb/dwc_otg/dwc_otg_regs.h | 1325 +++++++++++++++++
As you are in your own subdir, no need to put "dwc_otg_" at the start of
every file name, right?
Care to make these changes and resend?
thanks,
greg k-h
^ permalink raw reply
* About mpc85xx flash memory allocation
From: Mitsutaka Amano @ 2011-01-24 1:15 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm testing the ppc platform is based on mpc85xx. 256MB Flash memory
has been installed. Then I found this entries.
/proc/vmallocinfo
~~~
0xc9100000-0xd9101000 268439552 of_flash_probe+0x290/0x814 ioremap
physmap_of allocated 268MB over to the vmalloc. vmalloc space is tight.
Why does we need mpc platforms to flash memory allocation? I know
other architectures don't allocate to the vmalloc.
The design of the hardware? or Is there the way to use the flash
memory without vmalloc?
Thanks,
Mitsutaka
^ permalink raw reply
* Re: fsl-esdhc on P2020 weird endianess behavior
From: tiejun.chen @ 2011-01-24 3:26 UTC (permalink / raw)
To: Elie De Brauwer; +Cc: linuxppc-dev
In-Reply-To: <4D39B2B0.9050207@gmail.com>
Elie De Brauwer wrote:
> Hello list,
>
> I have a P2020 processor on a custom board which uses the embedded
> fsl-esdhc controller. Hardware-wise this is functional and in u-boot
> everything seems to behave (mmc part 0 gives the correct partition table
> and ext2ls/fatls are capable of reading the contents of the sd card).
>
> However as soon as I start Linux (2.6.36), I get all sorts of unwanted
> behavior. Linux is unable to detect the partition layout (but if I do a
Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then
I'm a bit curious what it'll be happened.
> hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa
> 55 00 00). Also when I try to obtain the card registers they show the
> same behavior:
> # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
> 0000b50200000000
>
> While for comparison the same value on my (x86) laptop gives:
> edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
> cat scr
> 02b5000000000000
>
> In my config I have the following set:
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_IO_ACCESSORS=y
> CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
> # CONFIG_MMC_SDHCI_PCI is not set
> CONFIG_MMC_SDHCI_OF=y
> CONFIG_MMC_SDHCI_OF_ESDHC=y
At least looks the config is fine.
Tiejun
>
>
> any pointers are welcome.
>
> gr
> E.
>
^ permalink raw reply
* Re: elf section .text.unlikely
From: tiejun.chen @ 2011-01-24 3:29 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinhu1fS5ESwivxSepnp-CXirm9dfV74_GEUi9qB@mail.gmail.com>
kevin diggs wrote:
> Hi,
>
> One more thing:
>
> The last message printed is:
>
> Driver 'sd' needs updating - please us bus_type methods
>
> The mesh SCSI controller seems to successfully scan the bus. The next
> message that a 3.4.6 compiled kernel prints are details about disk sda
> (from SCSI disk driver?).
>
> 4.3.5 keyboard is dead.
>
> Jog any thoughts?
Maybe the kernel already panic then serial cannot print the last messages
immediately. So after reset the target you can dump __log_buf from the u-boot
prompt to track this in detail.
Tiejun
>
> Thanks!
>
> kevin
>
> On Fri, Jan 21, 2011 at 8:31 PM, kevin diggs <diggskevin38@gmail.com> wrote:
>> For what it is worth, this section contains dump_stack, panic, and printk
>>
>> Thanks!
>>
>> kevin
>>
>> On Fri, Jan 21, 2011 at 7:40 PM, kevin diggs <diggskevin38@gmail.com> wrote:
>>> Hi,
>>>
>>> I am trying to get a PowerMac 8600 to boot past 2.6.28.
>>>
>>> I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get
>>> 2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section
>>> '.text.unlikely' that the 3.4.6 version does not. Anyone know what
>>> this might be?
>>>
>>> kevin
^ permalink raw reply
* Re: About mpc85xx flash memory allocation
From: tiejun.chen @ 2011-01-24 6:48 UTC (permalink / raw)
To: Mitsutaka Amano; +Cc: linuxppc-dev
In-Reply-To: <AANLkTin0RHAF8ieFqv12dFfOr_N3g3w6VVUTGOvH47uq@mail.gmail.com>
Mitsutaka Amano wrote:
> Hi all,
>
> I'm testing the ppc platform is based on mpc85xx. 256MB Flash memory
> has been installed. Then I found this entries.
>
> /proc/vmallocinfo
> ~~~
> 0xc9100000-0xd9101000 268439552 of_flash_probe+0x290/0x814 ioremap
>
> physmap_of allocated 268MB over to the vmalloc. vmalloc space is tight.
>
> Why does we need mpc platforms to flash memory allocation? I know
This should not be dedicated to so-called mpc platform. And we always use
ioremap() to map the device space. And on PPC ioremap also use the same space as
vmalloc(). While bootstrap you also can see this associated message like the
follows,
------
......
* 0xd1000000..0xffbe9000 : vmalloc & ioremap
> other architectures don't allocate to the vmalloc.
> The design of the hardware? or Is there the way to use the flash
You can open /dev/mem then mmap() with a appropriate offset to access the device
space including flash.
Tiejun
> memory without vmalloc?
>
> Thanks,
> Mitsutaka
^ permalink raw reply
* Re: fsl-esdhc on P2020 weird endianess behavior
From: Elie De Brauwer @ 2011-01-24 7:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tiejun.chen
In-Reply-To: <4D3CF158.20704@windriver.com>
On 01/24/11 04:26, tiejun.chen wrote:
> Elie De Brauwer wrote:
>> Hello list,
>>
>> I have a P2020 processor on a custom board which uses the embedded
>> fsl-esdhc controller. Hardware-wise this is functional and in u-boot
>> everything seems to behave (mmc part 0 gives the correct partition table
>> and ext2ls/fatls are capable of reading the contents of the sd card).
>>
>> However as soon as I start Linux (2.6.36), I get all sorts of unwanted
>> behavior. Linux is unable to detect the partition layout (but if I do a
>
> Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then
> I'm a bit curious what it'll be happened.
This was already partitioned under (x86) Linux, and when I plug it into
my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0
command shows the correct partition table). And this does not explain
why the card registers (such as the scr pasted below) also seem to have
their endianess swapped, which will result in other side-effects, such
as improper reading of card capabilities.
>
>> hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa
>> 55 00 00). Also when I try to obtain the card registers they show the
>> same behavior:
>> # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
>> 0000b50200000000
>>
>> While for comparison the same value on my (x86) laptop gives:
>> edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
>> cat scr
>> 02b5000000000000
>>
>> In my config I have the following set:
>> CONFIG_MMC_SDHCI=y
>> CONFIG_MMC_SDHCI_IO_ACCESSORS=y
>> CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
>> # CONFIG_MMC_SDHCI_PCI is not set
>> CONFIG_MMC_SDHCI_OF=y
>> CONFIG_MMC_SDHCI_OF_ESDHC=y
>
> At least looks the config is fine.
>
> Tiejun
>
^ permalink raw reply
* Re: fsl-esdhc on P2020 weird endianess behavior
From: tiejun.chen @ 2011-01-24 8:15 UTC (permalink / raw)
To: Elie De Brauwer; +Cc: linuxppc-dev
In-Reply-To: <4D3D2FBB.6010504@gmail.com>
Elie De Brauwer wrote:
> On 01/24/11 04:26, tiejun.chen wrote:
>> Elie De Brauwer wrote:
>>> Hello list,
>>>
>>> I have a P2020 processor on a custom board which uses the embedded
>>> fsl-esdhc controller. Hardware-wise this is functional and in u-boot
>>> everything seems to behave (mmc part 0 gives the correct partition table
>>> and ext2ls/fatls are capable of reading the contents of the sd card).
>>>
>>> However as soon as I start Linux (2.6.36), I get all sorts of unwanted
>>> behavior. Linux is unable to detect the partition layout (but if I do a
>>
>> Can you re-partition that under Linux? i.e, you can use fdisk to do
>> this. Then
>> I'm a bit curious what it'll be happened.
>
> This was already partitioned under (x86) Linux, and when I plug it into
I means you should partition the disk on the PPC Linux, not x86. As you know x86
work with LE for Linux, but PPC with BE. So I think you should partition that on
the same type machine. Can you try it?
> my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0
> command shows the correct partition table). And this does not explain
I didn't check this implemented codes within u-boot. Maybe u-boot can do
something to swap MMC ending problem. You can try to get the conclusion. Firstly
you can re-partition that on PPC Linux then check if u-boot can identify it
properly. I guess u-boot still can read that successfully.
Tiejun
> why the card registers (such as the scr pasted below) also seem to have
> their endianess swapped, which will result in other side-effects, such
> as improper reading of card capabilities.
>
>>
>>> hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa
>>> 55 00 00). Also when I try to obtain the card registers they show the
>>> same behavior:
>>> # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
>>> 0000b50200000000
>>>
>>> While for comparison the same value on my (x86) laptop gives:
>>> edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
>>>
>>> cat scr
>>> 02b5000000000000
>>>
>>> In my config I have the following set:
>>> CONFIG_MMC_SDHCI=y
>>> CONFIG_MMC_SDHCI_IO_ACCESSORS=y
>>> CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
>>> # CONFIG_MMC_SDHCI_PCI is not set
>>> CONFIG_MMC_SDHCI_OF=y
>>> CONFIG_MMC_SDHCI_OF_ESDHC=y
>>
>> At least looks the config is fine.
>>
>> Tiejun
>>
>
>
^ permalink raw reply
* Re: fsl-esdhc on P2020 weird endianess behavior
From: Elie De Brauwer @ 2011-01-24 9:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tiejun.chen
In-Reply-To: <4D3D3512.4020105@windriver.com>
On 01/24/11 09:15, tiejun.chen wrote:
> Elie De Brauwer wrote:
>> On 01/24/11 04:26, tiejun.chen wrote:
>>> Elie De Brauwer wrote:
>>>> Hello list,
>>>>
>>>> I have a P2020 processor on a custom board which uses the embedded
>>>> fsl-esdhc controller. Hardware-wise this is functional and in u-boot
>>>> everything seems to behave (mmc part 0 gives the correct partition table
>>>> and ext2ls/fatls are capable of reading the contents of the sd card).
>>>>
>>>> However as soon as I start Linux (2.6.36), I get all sorts of unwanted
>>>> behavior. Linux is unable to detect the partition layout (but if I do a
>>>
>>> Can you re-partition that under Linux? i.e, you can use fdisk to do
>>> this. Then
>>> I'm a bit curious what it'll be happened.
>>
>> This was already partitioned under (x86) Linux, and when I plug it into
>
> I means you should partition the disk on the PPC Linux, not x86. As you know x86
> work with LE for Linux, but PPC with BE. So I think you should partition that on
> the same type machine. Can you try it?
>
>> my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0
>> command shows the correct partition table). And this does not explain
>
> I didn't check this implemented codes within u-boot. Maybe u-boot can do
> something to swap MMC ending problem. You can try to get the conclusion. Firstly
> you can re-partition that on PPC Linux then check if u-boot can identify it
> properly. I guess u-boot still can read that successfully.
>
Unfortunately two wrongs don't make a right here. When I fdisk it on
target, then on target the partition gets detected, in u-boot it fails
(Unknown partition table). To be honest this was already the behavior
which I expected because the endianness swap was also seen for the card
registers. So I think something more fundamental is wrong (which in turn
smells like the "BIG_ENDIAN_32BIT_BYTE_SWAPPER" but this is used in a
very convincing way by the fsl-esdh driver...
>
>> why the card registers (such as the scr pasted below) also seem to have
>> their endianess swapped, which will result in other side-effects, such
>> as improper reading of card capabilities.
>>
>>>
>>>> hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa
>>>> 55 00 00). Also when I try to obtain the card registers they show the
>>>> same behavior:
>>>> # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
>>>> 0000b50200000000
>>>>
>>>> While for comparison the same value on my (x86) laptop gives:
>>>> edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
>>>>
>>>> cat scr
>>>> 02b5000000000000
>>>>
>>>> In my config I have the following set:
>>>> CONFIG_MMC_SDHCI=y
>>>> CONFIG_MMC_SDHCI_IO_ACCESSORS=y
>>>> CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
>>>> # CONFIG_MMC_SDHCI_PCI is not set
>>>> CONFIG_MMC_SDHCI_OF=y
>>>> CONFIG_MMC_SDHCI_OF_ESDHC=y
>>>
>>> At least looks the config is fine.
>>>
>>> Tiejun
>>>
>>
>>
>
--
Elie De Brauwer
^ permalink raw reply
* Re: fsl-esdhc on P2020 weird endianess behavior
From: tiejun.chen @ 2011-01-24 9:28 UTC (permalink / raw)
To: Elie De Brauwer; +Cc: linuxppc-dev
In-Reply-To: <4D3D407D.4080800@gmail.com>
Elie De Brauwer wrote:
> On 01/24/11 09:15, tiejun.chen wrote:
>> Elie De Brauwer wrote:
>>> On 01/24/11 04:26, tiejun.chen wrote:
>>>> Elie De Brauwer wrote:
>>>>> Hello list,
>>>>>
>>>>> I have a P2020 processor on a custom board which uses the embedded
>>>>> fsl-esdhc controller. Hardware-wise this is functional and in u-boot
>>>>> everything seems to behave (mmc part 0 gives the correct partition
>>>>> table
>>>>> and ext2ls/fatls are capable of reading the contents of the sd card).
>>>>>
>>>>> However as soon as I start Linux (2.6.36), I get all sorts of unwanted
>>>>> behavior. Linux is unable to detect the partition layout (but if I
>>>>> do a
>>>>
>>>> Can you re-partition that under Linux? i.e, you can use fdisk to do
>>>> this. Then
>>>> I'm a bit curious what it'll be happened.
>>>
>>> This was already partitioned under (x86) Linux, and when I plug it into
>>
>> I means you should partition the disk on the PPC Linux, not x86. As
>> you know x86
>> work with LE for Linux, but PPC with BE. So I think you should
>> partition that on
>> the same type machine. Can you try it?
>>
>>> my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0
>>> command shows the correct partition table). And this does not explain
>>
>> I didn't check this implemented codes within u-boot. Maybe u-boot can do
>> something to swap MMC ending problem. You can try to get the
>> conclusion. Firstly
>> you can re-partition that on PPC Linux then check if u-boot can
>> identify it
>> properly. I guess u-boot still can read that successfully.
>>
>
> Unfortunately two wrongs don't make a right here. When I fdisk it on
> target, then on target the partition gets detected, in u-boot it fails
> (Unknown partition table). To be honest this was already the behavior
> which I expected because the endianness swap was also seen for the card
> registers. So I think something more fundamental is wrong (which in turn
> smells like the "BIG_ENDIAN_32BIT_BYTE_SWAPPER" but this is used in a
> very convincing way by the fsl-esdh driver...
As you said looks you can disable 'MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER' from
the Kconfig to rebuild Linux since its unnecessary for your target.
Tiejun
>
>>
>>> why the card registers (such as the scr pasted below) also seem to have
>>> their endianess swapped, which will result in other side-effects, such
>>> as improper reading of card capabilities.
>>>
>>>>
>>>>> hexdump of the MBR, I see the endianness is swapped (last 4 bytes
>>>>> are aa
>>>>> 55 00 00). Also when I try to obtain the card registers they show the
>>>>> same behavior:
>>>>> # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
>>>>> 0000b50200000000
>>>>>
>>>>> While for comparison the same value on my (x86) laptop gives:
>>>>> edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
>>>>>
>>>>>
>>>>> cat scr
>>>>> 02b5000000000000
>>>>>
>>>>> In my config I have the following set:
>>>>> CONFIG_MMC_SDHCI=y
>>>>> CONFIG_MMC_SDHCI_IO_ACCESSORS=y
>>>>> CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
>>>>> # CONFIG_MMC_SDHCI_PCI is not set
>>>>> CONFIG_MMC_SDHCI_OF=y
>>>>> CONFIG_MMC_SDHCI_OF_ESDHC=y
>>>>
>>>> At least looks the config is fine.
>>>>
>>>> Tiejun
>>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* Re: fsl-esdhc on P2020 weird endianess behavior
From: Elie De Brauwer @ 2011-01-24 9:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tiejun.chen
In-Reply-To: <4D3D4652.6030403@windriver.com>
On 01/24/11 10:28, tiejun.chen wrote:
> Elie De Brauwer wrote:
>> On 01/24/11 09:15, tiejun.chen wrote:
>>> Elie De Brauwer wrote:
>>>> On 01/24/11 04:26, tiejun.chen wrote:
>>>>> Elie De Brauwer wrote:
>>>>>> Hello list,
>>>>>>
>>>>>> I have a P2020 processor on a custom board which uses the embedded
>>>>>> fsl-esdhc controller. Hardware-wise this is functional and in u-boot
>>>>>> everything seems to behave (mmc part 0 gives the correct partition
>>>>>> table
>>>>>> and ext2ls/fatls are capable of reading the contents of the sd card).
>>>>>>
>>>>>> However as soon as I start Linux (2.6.36), I get all sorts of unwanted
>>>>>> behavior. Linux is unable to detect the partition layout (but if I
>>>>>> do a
>>>>>
>>>>> Can you re-partition that under Linux? i.e, you can use fdisk to do
>>>>> this. Then
>>>>> I'm a bit curious what it'll be happened.
>>>>
>>>> This was already partitioned under (x86) Linux, and when I plug it into
>>>
>>> I means you should partition the disk on the PPC Linux, not x86. As
>>> you know x86
>>> work with LE for Linux, but PPC with BE. So I think you should
>>> partition that on
>>> the same type machine. Can you try it?
>>>
>>>> my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0
>>>> command shows the correct partition table). And this does not explain
>>>
>>> I didn't check this implemented codes within u-boot. Maybe u-boot can do
>>> something to swap MMC ending problem. You can try to get the
>>> conclusion. Firstly
>>> you can re-partition that on PPC Linux then check if u-boot can
>>> identify it
>>> properly. I guess u-boot still can read that successfully.
>>>
>>
>> Unfortunately two wrongs don't make a right here. When I fdisk it on
>> target, then on target the partition gets detected, in u-boot it fails
>> (Unknown partition table). To be honest this was already the behavior
>> which I expected because the endianness swap was also seen for the card
>> registers. So I think something more fundamental is wrong (which in turn
>> smells like the "BIG_ENDIAN_32BIT_BYTE_SWAPPER" but this is used in a
>> very convincing way by the fsl-esdh driver...
>
> As you said looks you can disable 'MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER' from
> the Kconfig to rebuild Linux since its unnecessary for your target.
>
Well no, since this gets selected by the fsl-esdhc driver
config MMC_SDHCI_OF_ESDHC
bool "SDHCI OF support for the Freescale eSDHC controller"
depends on MMC_SDHCI_OF
select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
help
This selects the Freescale eSDHC controller support.
If unsure, say N.
And if you look in the sdhc-of.esdhc.c
(http://lxr.linux.no/#linux+v2.6.37/drivers/mmc/host/sdhci-of-esdhc.c#L75 )
you can see that this driver is very stubborn in using the sdhci_be32bs*
variants, so it just won't compile without the BYTE_SWAPPER set. But the
entire sdhci_esdhc struct looks odd (for example they do byteswapping
for the read_b but nog for the write_b, and it gets only done for the
{read|write}_l. I'll try using the 'regular' callbacks here instead of
the byteswapped versions.
> Tiejun
>
>>
>>>
>>>> why the card registers (such as the scr pasted below) also seem to have
>>>> their endianess swapped, which will result in other side-effects, such
>>>> as improper reading of card capabilities.
>>>>
>>>>>
>>>>>> hexdump of the MBR, I see the endianness is swapped (last 4 bytes
>>>>>> are aa
>>>>>> 55 00 00). Also when I try to obtain the card registers they show the
>>>>>> same behavior:
>>>>>> # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
>>>>>> 0000b50200000000
>>>>>>
>>>>>> While for comparison the same value on my (x86) laptop gives:
>>>>>> edb@lapedb:/sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.2/mmc_host/mmc0/mmc0:0001$
>>>>>>
>>>>>>
>>>>>> cat scr
>>>>>> 02b5000000000000
>>>>>>
>>>>>> In my config I have the following set:
>>>>>> CONFIG_MMC_SDHCI=y
>>>>>> CONFIG_MMC_SDHCI_IO_ACCESSORS=y
>>>>>> CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
>>>>>> # CONFIG_MMC_SDHCI_PCI is not set
>>>>>> CONFIG_MMC_SDHCI_OF=y
>>>>>> CONFIG_MMC_SDHCI_OF_ESDHC=y
>>>>>
>>>>> At least looks the config is fine.
>>>>>
>>>>> Tiejun
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Elie De Brauwer
^ 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