* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
From: Alessandro Zummo @ 2009-02-23 15:05 UTC (permalink / raw)
To: rtc-linux
Cc: Richard Zidlicky, linux-parisc, Linux Kernel Development, David,
Kyle McMartin, Linux/PPC Development, Linux/m68k,
Geert.Uytterhoeven, Woodhouse
In-Reply-To: <alpine.LRH.2.00.0902231319170.22762@vixen.sonytel.be>
On Mon, 23 Feb 2009 13:34:49 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > Hello,
> >
> > my opinion on this kind of stuff is that I want to avoid the layering
> > of implementations under the rtc subsystem. I'd rather prefer that each
> > rtc device had its own driver.
> >
> > I've made error in the past, by accepting such kind of drivers, and
> > would like to avoid that it happens again.
>
> So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
not all at once :)
I'd start writing a working driver and then see how we should eventually
adapt the rtc subsystem to cope with your needs.
> What about ppc_md.get_boot_time() [ppc]?
> Please note that the functions above may also be used for very early clock
> setting (e.g. time_init()) and in read_persistent_clock().
> How should we handle these?
read_persistent_clock is something that should be reconsidered
as well along with all the ntp stuff.
> Even on x86 there seems to be way too much RTC logic in arch/x86/kernel/rtc.c
> (e.g. mach_get_cmos_time()), which is duplicated in drivers/rtc/rtc-cmos.c
> through the inline function __get_rtc_time() in include/asm-generic/rtc.h
> (clever, hardware-specific stuff in asm-generic ;-)
yep, I know :( that hardcoded rtc stuff seems to be everywhere!
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: Problem with decrementer interrupt
From: Matt Gessner @ 2009-02-23 14:48 UTC (permalink / raw)
To: sumedh tirodkar; +Cc: linuxppc-dev
In-Reply-To: <d2b9ccd90902230503i4c2535d5lbd05b7ddeddf3192@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar
<sumedhtirodkar@gmail.com>wrote:
> I am using PowerPC 7447A...I am trying to port SA-RTL on PowerPC...
What I said earlier was: You need to tell people what cpu you're using, what
linux kernel, etc etc etc.
Fine, we know the CPU. What kernel are you using? Is it ancient?
I doubt the information below is going to be useful...
>
> I am using
>
> bla <function_name>
>
> from the assembly code to call the function in C file...This i am
> doing from interrupt handler of the decrementer...
> If any more details are required, please let me know...
>
[-- Attachment #2: Type: text/html, Size: 1096 bytes --]
^ permalink raw reply
* Re: Custom kernel driver for MPC8548
From: Kumar Gala @ 2009-02-23 14:47 UTC (permalink / raw)
To: Pieter; +Cc: linuxppc-dev
In-Reply-To: <49A26B03.4080300@vastech.co.za>
On Feb 23, 2009, at 3:23 AM, Pieter wrote:
> Hi all
>
> I recently ported my board to use the new U-boot 2009 and boot Linux
> 2.6.27. ( the previous Linux version was 2.6.19 which supported the
> ppc
> architecture)
>
> I am now at the stage where I need to port a custom platform driver.
> The
> driver used files that resided in /include/asm-ppc/. which are no
> longer
> available using the powerpc architecture. Can someone please guide
> me as
> to where to look for the appropriate contents?
>
> In particular:
> asm-ppc/io.h
> asm-ppc/mpc85xx.h
> asm-ppc/immap_85xx.h
look in arch/powerpc/include/asm/
- k
^ permalink raw reply
* Re: [PATCH 2/2] Make sure we copy all cpu_spec features except PMC related ones
From: Dave Kleikamp @ 2009-02-23 13:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <30c3ca265326d7aaa86cc75367d23739398a7b23.1235355941.git.michael@ellerman.id.au>
On Mon, 2009-02-23 at 13:25 +1100, Michael Ellerman wrote:
> When identify_cpu() is called a second time with a logical PVR, it
> only copies a subset of the cpu_spec fields so as to avoid overwriting
> the performance monitor fields that were initialized based on the
> real PVR.
>
> However some of the other, non performance monitor related fields are
> also not copied:
> * pvr_mask
> * pvr_value
> * mmu_features
> * machine_check
>
> The fact that pvr_mask is not copied can result in show_cpuinfo()
> showing the cpu as "unknown", if we override an unknown PVR with a
> logical one - as reported by Shaggy.
>
> So change the logic to copy all fields, and then put back the PMC
> related ones in the case that we're overwriting a real PVR with a
> logical one.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 1/2] Deindentify identify_cpu()
From: Dave Kleikamp @ 2009-02-23 13:27 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <689159d7e17a2227e6000b51911750503eed1778.1235355941.git.michael@ellerman.id.au>
On Mon, 2009-02-23 at 13:25 +1100, Michael Ellerman wrote:
> The for-loop body of identify_cpu() has gotten a little big, so move the
> loop body logic into a separate function. No other changes.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Looks good to me.
Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: Problem with decrementer interrupt
From: sumedh tirodkar @ 2009-02-23 13:03 UTC (permalink / raw)
To: Matt Gessner, linuxppc-dev
In-Reply-To: <85a5c2010902230439n1096196dr519462513bc3910d@mail.gmail.com>
I am using PowerPC 7447A...I am trying to port SA-RTL on PowerPC...
I am using
bla <function_name>
from the assembly code to call the function in C file...This i am
doing from interrupt handler of the decrementer...
If any more details are required, please let me know...
Regards,
Sumedh
On Mon, Feb 23, 2009 at 6:09 PM, Matt Gessner <mgessner@gmail.com> wrote:
> You need to tell people what cpu you're using, what linux kernel, etc etc
> etc.
>
> Your email is otherwise completely useless.
>
> On Mon, Feb 23, 2009 at 2:54 AM, sumedh tirodkar <sumedhtirodkar@gmail.com>
> wrote:
>>
>> In the handler for decrementer interrupt...there is a call to a C
>> function...
>> Now if the call is removed...the decrementer interrupt works perfectly
>> fine...
>> But if the C function is present, then the decrementer interrupt stops
>> coming after say 5-6 times...
>> Not able to find any reasoning for the same...
>> Has anyone come across this kind of problem?If yes, am i missing
>> something?
>>
>> Regards,
>> Sumedh
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
From: Geert Uytterhoeven @ 2009-02-23 12:34 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Richard Zidlicky, rtc-linux, linux-parisc, David,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Linux/m68k, Woodhouse
In-Reply-To: <20090220170454.04382e9e@i1501.lan.towertech.it>
On Fri, 20 Feb 2009, Alessandro Zummo wrote:
> On Fri, 20 Feb 2009 16:46:44 +0100
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > Fortunately there already exists a generic RTC class driver: "rtc-parisc".
> > Despite it's name, it's platform-independent, as it's build on top of the RTC
> > abstraction used by "genrtc".
> >
> > This patch series
> > - adds a missing module alias to rtc-parisc,
> > - renames rtc-parisc to rtc-generic,
> > - converts the architectures that currently have CONFIG_GEN_RTC enabled in
> > their defconfig (m68k, parisc, powerpc) to rtc-generic,
> > - removes the obsolete rtc-ppc driver,
> > - removes the old genrtc driver.
> >
> > Note that genrtc may be used on other archictectures as well: at least alpha
> > has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow
> > genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, xtensa).
> >
> > Furthermore genrtc and rtc-generic are not 100% userspace compatible:
> > - /dev/rtc provided by genrtc uses a misc character device (10:135),
> > - /dev/rtc provided by rtc-generic uses a dynamic character device.
>
> Hello,
>
> my opinion on this kind of stuff is that I want to avoid the layering
> of implementations under the rtc subsystem. I'd rather prefer that each
> rtc device had its own driver.
>
> I've made error in the past, by accepting such kind of drivers, and
> would like to avoid that it happens again.
So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
What about ppc_md.get_boot_time() [ppc]?
Please note that the functions above may also be used for very early clock
setting (e.g. time_init()) and in read_persistent_clock().
How should we handle these?
Even on x86 there seems to be way too much RTC logic in arch/x86/kernel/rtc.c
(e.g. mach_get_cmos_time()), which is duplicated in drivers/rtc/rtc-cmos.c
through the inline function __get_rtc_time() in include/asm-generic/rtc.h
(clever, hardware-specific stuff in asm-generic ;-)
> Regarding the user space, the assumption that a device has
> a fixed major:minor number should be dropped as well.
I know. But it's a userland-visible change, so I wanted to explicit point to
it.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Regarding Level/Edge of Interrupt sense values
From: Vijay Nikam @ 2009-02-23 11:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
Hello,
I created a device node for gpio-controller for evaluation board
mpc83313erdb. I created the dtb and loaded on target and the interrupt
is generated successfully.
But in dts at interrupts = <74 0x2> I set sense as Edge (sense== 2:
Edge, high-to-low change), when I load the driver module and checked
the entry in /proc/interrupts it shows the sense as Level i.e. 8
(sense == 8: Level, low assertion) as follows;
74: 1 IPIC Level gpio
Following is gpio-controller device tree node;
gpio-controller@c00 {
#gpio-cells = <2>;
compatible = "fsl,mpc8313-gpio", "fsl,mpc8349-gpio";
reg = <0xc00 0x100>;
interrupts = <74 0x2>;
interrupt-parent = <&ipic>;
gpio-controller;
};
Could anyone please tell what could be the reason ? ? ? Am I missing
something ? ? ?
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
##################### Start ############################
cat /proc/interrupts
CPU0
16: 162 IPIC Level serial
19: 43 IPIC Level i2c-mpc
20: 1 IPIC Level i2c-mpc
22: 2 IPIC Edge phy_interrupt
32: 0 IPIC Level enet_error
33: 765 IPIC Level enet_rx
34: 3 IPIC Level enet_tx
35: 0 IPIC Level enet_error
36: 0 IPIC Level enet_rx
37: 15 IPIC Level enet_tx
38: 0 IPIC Edge ehci_hcd:usb1
72: 0 IPIC Level gtm timer
74: 1 IPIC Level gpio
77: 51451 IPIC Level fsl-elbc
80: 0 IPIC Level pmc
BAD: 0
###################### END ############################
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Sachin P. Sant @ 2009-02-23 10:57 UTC (permalink / raw)
To: Paul Mackerras
Cc: Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev, Andrew Morton,
linux-ext4
In-Reply-To: <18850.31567.212454.514549@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> It appears to have faulted on a load, implicating the source. The
> address being referenced (0xc00000003f380000) doesn't look
> outlandish. I wonder if this kernel has CONFIG_DEBUG_PAGEALLOC turned
> on, and what page size is selected?
Yes CONFIG_DEBUG_PAGEALLOC is enabled and the page size is 64K.
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_PPC_64K_PAGES=y
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Sachin P. Sant @ 2009-02-23 10:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, linuxppc-dev, linux-ext4, Jan Kara, linux-kernel
In-Reply-To: <20090223021320.11019d64.akpm@linux-foundation.org>
Andrew Morton wrote:
> hm, I wonder what could have caused that - we haven't altered
> fs/ext3/xattr.c in ages.
>
> What is the most recent kernel version you know of which didn't do
> this? Bear in mind that this crash might be triggered by the
> current contents of the filesystem, so if possible, please test
> some other kernel versions on that disk.
>
I am trying to boot a vanilla kernel on this machine for the first
time. Haven't tried any other kernels. Will give it a try.
> It looks like we died in ext3_xattr_block_get():
>
> memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> size);
>
> Perhaps entry->e_value_offs is no good. I wonder if the filesystem is
> corrupted and this snuck through the defenses.
>
> I also wonder if there is enough info in that trace for a ppc person to
> be able to determine whether the faulting address is in the source or
> destination of the memcpy() (please)?
>
Some more information if this could be of any help.
0:mon> di 0xc000000000039574
c000000000039574 e9240008 ld r9,8(r4)
c000000000039578 409d0010 ble cr7,c000000000039588 # .memcpy+0x88/0x244
c00000000003957c 79290002 rotldi r9,r9,32
c000000000039580 91230000 stw r9,0(r3)
c000000000039584 38630004 addi r3,r3,4
c000000000039588 409e0010 bne cr7,c000000000039598 # .memcpy+0x98/0x244
c00000000003958c 79298000 rotldi r9,r9,16
c000000000039590 b1230000 sth r9,0(r3)
c000000000039594 38630002 addi r3,r3,2
c000000000039598 409f000c bns cr7,c0000000000395a4 # .memcpy+0xa4/0x244
c00000000003959c 79294000 rotldi r9,r9,8
c0000000000395a0 99230000 stb r9,0(r3)
c0000000000395a4 e8610030 ld r3,48(r1)
c0000000000395a8 4e800020 blr
c0000000000395ac 78a6e8c2 rldicl r6,r5,61,3
c0000000000395b0 38a5fff0 addi r5,r5,-16
0:mon> r
R00 = 000000000000e40f R16 = 00000000100edbc8
R01 = c00000003e59b3e0 R17 = 00000000100b0000
R02 = c0000000009c2110 R18 = 0000000000000005
R03 = c000000044bc90e0 R19 = 00000000fff0d7a8
R04 = c000000039cffff4 R20 = 00000000fff0d708
R05 = 0000000000000003 R21 = 00000000000000ff
R06 = 0000000000000000 R22 = 0000000000000006
R07 = 0000000000000001 R23 = c00000000079ab49
R08 = 723a7573725f743a R24 = c0000000372fe2a8
R09 = 3a6f626a6563745f R25 = c000000044bc90c8
R10 = c00000003b250968 R26 = c0000000372fe240
R11 = c000000000039500 R27 = c0000000372fe3b0
R12 = d00000000244c590 R28 = c0000000372c5280
R13 = c000000000a53480 R29 = 000000000000001b
R14 = 00000000100d0000 R30 = d0000000024654d0
R15 = 0000000000000000 R31 = ffffffffffffffde
pc = c000000000039574 .memcpy+0x74/0x244
lr = d00000000244916c .ext3_xattr_get+0x288/0x2f4 [ext3]
msr = 8000000000009032 cr = 4400844b
ctr = 0000000000000000 xer = 0000000000000001 trap = 300
dar = c000000039d00000 dsisr = 40000000
0:mon>
So the other thing i noticed was that this machine was running
a kernel with selinux enabled. I turned off selinux and there
were no issues during bootup. It was a clean boot.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: PCI reading without endian conversion
From: Geert Uytterhoeven @ 2009-02-23 10:37 UTC (permalink / raw)
To: Ira Snyder; +Cc: PowerPC dev list
In-Reply-To: <20090220235054.GA27349@ovro.caltech.edu>
On Fri, 20 Feb 2009, Ira Snyder wrote:
> On Fri, Feb 20, 2009 at 03:56:39PM -0600, Matt Sealey wrote:
> > Am I correct in saying that cpu_to_le32 and le32_to_cpu are the
> > functions/macros I need to use to do byte swapping to make everything
> > go little endian (and back again when I read them back in the kernel)?
> >
> > Or is there some cleverer way already implemented in the kernel?
>
> I would say that the __raw_readl() reads in cpu order. If you wanted to
> convert that to le32, you'd use cpu_to_le32().
Well...
__raw_readl() does read in cpu order. But since you're reading from the PCI
bus, which is little endian, you actually read a little endian value. So you
should use le32_to_cpu() to convert it to a native value.
(yes, at the lowest level, cpu_to_le32() and le32_to_cpu() do the same thing
on PPC: byte swapping 32-bit data).
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Paul Mackerras @ 2009-02-23 10:32 UTC (permalink / raw)
To: Andrew Morton
Cc: Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev, linux-ext4
In-Reply-To: <20090223021320.11019d64.akpm@linux-foundation.org>
Andrew Morton writes:
> It looks like we died in ext3_xattr_block_get():
>
> memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> size);
>
> Perhaps entry->e_value_offs is no good. I wonder if the filesystem is
> corrupted and this snuck through the defenses.
>
> I also wonder if there is enough info in that trace for a ppc person to
> be able to determine whether the faulting address is in the source or
> destination of the memcpy() (please)?
It appears to have faulted on a load, implicating the source. The
address being referenced (0xc00000003f380000) doesn't look
outlandish. I wonder if this kernel has CONFIG_DEBUG_PAGEALLOC turned
on, and what page size is selected?
Paul.
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Andrew Morton @ 2009-02-23 10:13 UTC (permalink / raw)
To: Sachin P. Sant
Cc: Mel Gorman, linuxppc-dev, linux-ext4, Jan Kara, linux-kernel
In-Reply-To: <49A2705D.9030008@in.ibm.com>
On Mon, 23 Feb 2009 15:16:05 +0530 "Sachin P. Sant" <sachinp@in.ibm.com> wrote:
> 2.6.29-rc6 bootup on a powerpc box failed with
>
> Unable to handle kernel paging request for data at address 0xc00000003f380000
> Faulting instruction address: 0xc000000000039574
> cpu 0x1: Vector: 300 (Data Access) at [c00000003baf3020]
> pc: c000000000039574: .memcpy+0x74/0x244
> lr: d00000000244916c: .ext3_xattr_get+0x288/0x2f4 [ext3]
> sp: c00000003baf32a0
> msr: 8000000000009032
> dar: c00000003f380000
> dsisr: 40000000
> current = 0xc00000003e54b010
> paca = 0xc000000000a53680
> pid = 1840, comm = readahead
> enter ? for help
> [link register ] d00000000244916c .ext3_xattr_get+0x288/0x2f4 [ext3]
> [c00000003baf32a0] d000000002449104 .ext3_xattr_get+0x220/0x2f4 [ext3]
> (unreliab
> le)
> [c00000003baf3390] d00000000244a6e8 .ext3_xattr_security_get+0x40/0x5c [ext3]
> [c00000003baf3400] c000000000148154 .generic_getxattr+0x74/0x9c
> [c00000003baf34a0] c000000000333400 .inode_doinit_with_dentry+0x1c4/0x678
> [c00000003baf3560] c00000000032c6b0 .security_d_instantiate+0x50/0x68
> [c00000003baf35e0] c00000000013c818 .d_instantiate+0x78/0x9c
> [c00000003baf3680] c00000000013ced0 .d_splice_alias+0xf0/0x120
> [c00000003baf3720] d00000000243e05c .ext3_lookup+0xec/0x134 [ext3]
> [c00000003baf37c0] c000000000131e74 .do_lookup+0x110/0x260
> [c00000003baf3880] c000000000134ed0 .__link_path_walk+0xa98/0x1010
> [c00000003baf3970] c0000000001354a0 .path_walk+0x58/0xc4
> [c00000003baf3a20] c000000000135720 .do_path_lookup+0x138/0x1e4
> [c00000003baf3ad0] c00000000013645c .path_lookup_open+0x6c/0xc8
> [c00000003baf3b70] c000000000136780 .do_filp_open+0xcc/0x874
> [c00000003baf3d10] c0000000001251e0 .do_sys_open+0x80/0x140
> [c00000003baf3dc0] c00000000016aaec .compat_sys_open+0x24/0x38
> [c00000003baf3e30] c00000000000855c syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 000000000ff0ef18
> SP (ffc6f4b0) is in userspace
> 1:mon>
>
> Following EXT3 related options were enabled in the config.
>
> CONFIG_EXT3_FS=m
> CONFIG_EXT3_FS_XATTR=y
> CONFIG_EXT3_FS_POSIX_ACL=y
> CONFIG_EXT3_FS_SECURITY=y
>
hm, I wonder what could have caused that - we haven't altered
fs/ext3/xattr.c in ages.
What is the most recent kernel version you know of which didn't do
this? Bear in mind that this crash might be triggered by the
current contents of the filesystem, so if possible, please test
some other kernel versions on that disk.
It looks like we died in ext3_xattr_block_get():
memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
size);
Perhaps entry->e_value_offs is no good. I wonder if the filesystem is
corrupted and this snuck through the defenses.
I also wonder if there is enough info in that trace for a ppc person to
be able to determine whether the faulting address is in the source or
destination of the memcpy() (please)?
^ permalink raw reply
* Custom kernel driver for MPC8548
From: Pieter @ 2009-02-23 9:23 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
Hi all
I recently ported my board to use the new U-boot 2009 and boot Linux
2.6.27. ( the previous Linux version was 2.6.19 which supported the ppc
architecture)
I am now at the stage where I need to port a custom platform driver. The
driver used files that resided in /include/asm-ppc/. which are no longer
available using the powerpc architecture. Can someone please guide me as
to where to look for the appropriate contents?
In particular:
asm-ppc/io.h
asm-ppc/mpc85xx.h
asm-ppc/immap_85xx.h
thanks Pieter
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2722 bytes --]
^ permalink raw reply
* [Powerpc / eHEA] Circular dependency with 2.6.29-rc6
From: Sachin P. Sant @ 2009-02-23 8:47 UTC (permalink / raw)
To: linuxppc-dev, netdev
Cc: TKLEIN, Mel Gorman, Kamalesh Babulal, Jan-Bernd Themann
While booting 2.6.29-rc6 on a powerpc box came across this
circular dependency with eHEA driver.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-rc6 #2
-------------------------------------------------------
ip/2174 is trying to acquire lock:
(&ehea_fw_handles.lock){--..}, at: [<d000000002a13e30>] .ehea_up+0x64/0x6e0
[ehea]
but task is already holding lock:
(&port->port_lock){--..}, at: [<d000000002a1533c>] .ehea_open+0x3c/0xc4 [ehea]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&port->port_lock){--..}:
[<c0000000000a8590>] .__lock_acquire+0x7e0/0x8a8
[<c0000000000a86ac>] .lock_acquire+0x54/0x80
[<c0000000005d7564>] .mutex_lock_nested+0x190/0x46c
[<d000000002a1533c>] .ehea_open+0x3c/0xc4 [ehea]
[<c000000000537834>] .dev_open+0xf4/0x168
[<c000000000535780>] .dev_change_flags+0xe4/0x1e8
[<c000000000597bfc>] .devinet_ioctl+0x2c4/0x750
[<c0000000005997a8>] .inet_ioctl+0xcc/0x11c
[<c000000000523400>] .sock_ioctl+0x2f0/0x34c
[<c0000000001380ec>] .vfs_ioctl+0x5c/0xf0
[<c000000000138810>] .do_vfs_ioctl+0x690/0x70c
[<c000000000138900>] .SyS_ioctl+0x74/0xb8
[<c00000000016fb08>] .dev_ifsioc+0x210/0x4b8
[<c00000000016ef18>] .compat_sys_ioctl+0x3f4/0x488
[<c00000000000855c>] syscall_exit+0x0/0x40
-> #1 (rtnl_mutex){--..}:
[<c0000000000a8590>] .__lock_acquire+0x7e0/0x8a8
[<c0000000000a86ac>] .lock_acquire+0x54/0x80
[<c0000000005d7564>] .mutex_lock_nested+0x190/0x46c
[<c0000000005430a8>] .rtnl_lock+0x20/0x38
[<c00000000053677c>] .register_netdev+0x1c/0x80
[<d000000002a12714>] .ehea_setup_single_port+0x2c8/0x3d0 [ehea]
[<d000000002a19da8>] .ehea_probe_adapter+0x288/0x394 [ehea]
[<c00000000051f034>] .of_platform_device_probe+0x78/0x86c
[<c00000000047faec>] .driver_probe_device+0x13c/0x200
[<c00000000047fc44>] .__driver_attach+0x94/0xd8
[<c00000000047eab4>] .bus_for_each_dev+0x80/0xd8
[<c00000000047f850>] .driver_attach+0x28/0x40
[<c00000000047f23c>] .bus_add_driver+0xd4/0x284
[<c00000000047ff7c>] .driver_register+0xc4/0x198
[<c00000000051eeec>] .of_register_driver+0x4c/0x60
[<c000000000024da4>] .ibmebus_register_driver+0x30/0x4c
[<d000000002a1a090>] .ehea_module_init+0x1dc/0x234c [ehea]
[<c000000000009368>] .do_one_initcall+0x90/0x1b0
[<c0000000000b2f24>] .SyS_init_module+0xc8/0x220
[<c00000000000855c>] syscall_exit+0x0/0x40
-> #0 (&ehea_fw_handles.lock){--..}:
[<c0000000000a8590>] .__lock_acquire+0x7e0/0x8a8
[<c0000000000a86ac>] .lock_acquire+0x54/0x80
[<c0000000005d7564>] .mutex_lock_nested+0x190/0x46c
[<d000000002a13e30>] .ehea_up+0x64/0x6e0 [ehea]
[<d000000002a15364>] .ehea_open+0x64/0xc4 [ehea]
[<c000000000537834>] .dev_open+0xf4/0x168
[<c000000000535780>] .dev_change_flags+0xe4/0x1e8
[<c000000000597bfc>] .devinet_ioctl+0x2c4/0x750
[<c0000000005997a8>] .inet_ioctl+0xcc/0x11c
[<c000000000523400>] .sock_ioctl+0x2f0/0x34c
[<c0000000001380ec>] .vfs_ioctl+0x5c/0xf0
[<c000000000138810>] .do_vfs_ioctl+0x690/0x70c
[<c000000000138900>] .SyS_ioctl+0x74/0xb8
[<c00000000016fb08>] .dev_ifsioc+0x210/0x4b8
[<c00000000016ef18>] .compat_sys_ioctl+0x3f4/0x488
[<c00000000000855c>] syscall_exit+0x0/0x40
other info that might help us debug this:
2 locks held by ip/2174:
#0: (rtnl_mutex){--..}, at: [<c0000000005430a8>] .rtnl_lock+0x20/0x38
#1: (&port->port_lock){--..}, at: [<d000000002a1533c>] .ehea_open+0x3c/0xc4
[ehea]
stack backtrace:
Call Trace:
[c00000004246b070] [c00000000001154c] .show_stack+0x70/0x184 (unreliable)
[c00000004246b120] [c0000000000a6ee4] .print_circular_bug_tail+0xd8/0xfc
[c00000004246b1f0] [c0000000000a76ec] .validate_chain+0x7e4/0xea8
[c00000004246b2b0] [c0000000000a8590] .__lock_acquire+0x7e0/0x8a8
[c00000004246b3a0] [c0000000000a86ac] .lock_acquire+0x54/0x80
[c00000004246b430] [c0000000005d7564] .mutex_lock_nested+0x190/0x46c
[c00000004246b510] [d000000002a13e30] .ehea_up+0x64/0x6e0 [ehea]
[c00000004246b610] [d000000002a15364] .ehea_open+0x64/0xc4 [ehea]
[c00000004246b6b0] [c000000000537834] .dev_open+0xf4/0x168
[c00000004246b740] [c000000000535780] .dev_change_flags+0xe4/0x1e8
[c00000004246b7f0] [c000000000597bfc] .devinet_ioctl+0x2c4/0x750
[c00000004246b8f0] [c0000000005997a8] .inet_ioctl+0xcc/0x11c
[c00000004246b960] [c000000000523400] .sock_ioctl+0x2f0/0x34c
[c00000004246ba00] [c0000000001380ec] .vfs_ioctl+0x5c/0xf0
[c00000004246baa0] [c000000000138810] .do_vfs_ioctl+0x690/0x70c
[c00000004246bb80] [c000000000138900] .SyS_ioctl+0x74/0xb8
[c00000004246bc30] [c00000000016fb08] .dev_ifsioc+0x210/0x4b8
[c00000004246bd40] [c00000000016ef18] .compat_sys_ioctl+0x3f4/0x488
[c00000004246be30] [c00000000000855c] syscall_exit+0x0/0x40
ehea: eth2: Physical port up
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: hash-table creation...
From: sumedh tirodkar @ 2009-02-23 7:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1234041420.31963.66.camel@pasglop>
Thanks a lot...paging mechanism working successfully...
Regards,
Sumedh
On Sun, Feb 8, 2009 at 2:47 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sat, 2009-02-07 at 11:43 +0530, sumedh tirodkar wrote:
>> Hello,
>>
>> I wanted algorithm for creating hash tables used in paging mechanism..
>> In the manual that i read i got algorithm to convert Effective Address
>> to Real Address using these hash tables that are created..but i could
>> not find how these hash tables are created in first place using the
>> Real addresses.
>> Is there any document available for the same?
>
> There's one MMU hash table. It's allocated & cleared by the kernel
> during early boot or by the hypervisor and pointed to by the SDR1
> register.
>
> It's populated by code in arch/powerpc/mm/hash_low_64.S or
> hash_low_32.S, typically as the result of a hash miss exception.
>
> Ben.
>
>
^ permalink raw reply
* Re: PowerPC 7447A Paging table Search
From: sumedh tirodkar @ 2009-02-23 7:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <00F33F10-8CD0-465F-9545-46009AA85E8E@kernel.crashing.org>
Thanks a lot...Its working now...
Regards,
Sumedh
On Thu, Feb 12, 2009 at 7:28 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Feb 12, 2009, at 3:59 AM, sumedh tirodkar wrote:
>
>> How will i confirm if PowerPC 7447A processor has or does not have a
>> dedicated hardware for page table search algorithm?
>> If it does not have, then which interrupt handler is written for page
>> address translation mechanism?
>
> It has one and linux uses it.
>
> - k
>
^ permalink raw reply
* Problem with decrementer interrupt
From: sumedh tirodkar @ 2009-02-23 7:54 UTC (permalink / raw)
To: linuxppc-dev
In the handler for decrementer interrupt...there is a call to a C function...
Now if the call is removed...the decrementer interrupt works perfectly fine...
But if the C function is present, then the decrementer interrupt stops
coming after say 5-6 times...
Not able to find any reasoning for the same...
Has anyone come across this kind of problem?If yes, am i missing something?
Regards,
Sumedh
^ permalink raw reply
* RE: Newby trying to get Ethernet going on MPC83xx series device.
From: Dushara Jayasinghe @ 2009-02-23 5:28 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Cc: Aggrwal Poonam-B10812, Timur Tabi, 'Michael Bergandi'
In-Reply-To: <DE0CCFFBFF707949BEABD4537A14ACBA0C04B40550@mailsvr>
> -----Original Message-----
> From: linuxppc-dev-bounces+dusharaj=3Doptiscan.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+dusharaj=3Doptiscan.com@ozlabs.org] On
> Behalf Of Dushara Jayasinghe
> Sent: Friday, 20 February 2009 6:18 PM
> To: 'Michael Bergandi'
> Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812; Timur Tabi
> Subject: RE: Newby trying to get Ethernet going on MPC83xx series
> device.
Hi all, I've solved this issue. I was passing the wrong .dtb file to the ke=
rnel. Sorry for adding noise the list.
Thanks again for all you help.
D
^ permalink raw reply
* Re: [patch] powerpc: estimate G5 cpufreq transition latency
From: Benjamin Herrenschmidt @ 2009-02-23 3:54 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, paulus
In-Reply-To: <20090219170741.GI1747@wotan.suse.de>
On Thu, 2009-02-19 at 18:07 +0100, Nick Piggin wrote:
> Setting G5's cpu frequency transition latency to CPUFREQ_ETERNAL stops
> ondemand governor from working. I measured the latency using sched_clock
> and haven't seen much higher than 11000ns, so I set this to 12000ns for
> my configuration. Possibly other configurations will be different?
> Ideally the generic code would be able to measure it in case the platform
> does not provide it.
>
> But this simple patch at least makes it throttle again.
>
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> ---
Oh well, I've never used ondemand but some userspace stuff instead :-)
No objection appart from the change to drivers/cpufreq/cpufreq.c which
should be in a separate patch to whoever maintains that code :-)
Cheers,
Ben.
> Index: linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/powermac/cpufreq_64.c 2009-02-20 01:42:41.000000000 +1100
> +++ linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c 2009-02-20 01:50:15.000000000 +1100
> @@ -86,6 +86,7 @@
>
> static DEFINE_MUTEX(g5_switch_mutex);
>
> +static unsigned long transition_latency;
>
> #ifdef CONFIG_PMAC_SMU
>
> @@ -357,7 +358,7 @@
>
> static int g5_cpufreq_cpu_init(struct cpufreq_policy *policy)
> {
> - policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
> + policy->cpuinfo.transition_latency = transition_latency;
> policy->cur = g5_cpu_freqs[g5_query_freq()].frequency;
> /* secondary CPUs are tied to the primary one by the
> * cpufreq core if in the secondary policy we tell it that
> @@ -500,6 +501,7 @@
> g5_cpu_freqs[1].frequency = max_freq/2;
>
> /* Set callbacks */
> + transition_latency = 12000;
> g5_switch_freq = g5_scom_switch_freq;
> g5_query_freq = g5_scom_query_freq;
> freq_method = "SCOM";
> @@ -675,6 +677,7 @@
> g5_cpu_freqs[1].frequency = min_freq;
>
> /* Set callbacks */
> + transition_latency = CPUFREQ_ETERNAL;
> g5_switch_volt = g5_pfunc_switch_volt;
> g5_switch_freq = g5_pfunc_switch_freq;
> g5_query_freq = g5_pfunc_query_freq;
> Index: linux-2.6/drivers/cpufreq/cpufreq.c
> ===================================================================
> --- linux-2.6.orig/drivers/cpufreq/cpufreq.c 2009-02-20 01:42:43.000000000 +1100
> +++ linux-2.6/drivers/cpufreq/cpufreq.c 2009-02-20 01:50:15.000000000 +1100
> @@ -1559,9 +1559,11 @@
> else {
> printk(KERN_WARNING "%s governor failed, too long"
> " transition latency of HW, fallback"
> - " to %s governor\n",
> + " to %s governor (latency=%lld max=%lld)\n",
> policy->governor->name,
> - gov->name);
> + gov->name,
> + policy->cpuinfo.transition_latency,
> + policy->governor->max_transition_latency);
> policy->governor = gov;
> }
> }
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: provide APIs for validating and updating DABR
From: Benjamin Herrenschmidt @ 2009-02-23 3:51 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20090217125122.5bbf713b@thinkcentre.lan>
> +/* for reprogramming DABR/DAC during restart of a checkpointed task */
> +extern bool debugreg_valid(unsigned long val);
> +extern void debugreg_update(struct task_struct *task, unsigned long val);
> +
Please keep the "index" here. We may want to add support for IABR, and
there is some WIP to add support for multiple DACs and IACs on BookE
processors.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Add support for using doorbells for SMP IPI
From: Benjamin Herrenschmidt @ 2009-02-23 2:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1234482893-17712-1-git-send-email-galak@kernel.crashing.org>
On Thu, 2009-02-12 at 17:54 -0600, Kumar Gala wrote:
> The e500mc supports the new msgsnd/doorbell mechanisms that were added in
> the Power ISA 2.05 architecture. We use the normal level doorbell for
> doing SMP IPIs at this point.
Any reason why you don't use the tag ? I'm not too familiar with the
doorbell stuff just yet but can't you use that instead of doing those
atomics ?
On thing we also need to look at is change our low level msg send to
take a CPU mask.
This will be better generically and we need a good cpu mask based IPI
for the TLB stuff anyway. Volunteer ? :-)
Cheers,
Ben.
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/cputable.h | 4 ++-
> arch/powerpc/include/asm/dbell.h | 43 +++++++++++++++++++++++++++++++++
> arch/powerpc/kernel/Makefile | 2 +-
> arch/powerpc/kernel/dbell.c | 44 ++++++++++++++++++++++++++++++++++
> arch/powerpc/kernel/head_fsl_booke.S | 6 ++++-
> arch/powerpc/kernel/traps.c | 21 ++++++++++++++++
> 6 files changed, 117 insertions(+), 3 deletions(-)
> create mode 100644 arch/powerpc/include/asm/dbell.h
> create mode 100644 arch/powerpc/kernel/dbell.c
>
> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
> index 4911104..fca1611 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -145,6 +145,7 @@ extern const char *powerpc_base_platform;
> #define CPU_FTR_USE_TB ASM_CONST(0x0000000000000040)
> #define CPU_FTR_L2CSR ASM_CONST(0x0000000000000080)
> #define CPU_FTR_601 ASM_CONST(0x0000000000000100)
> +#define CPU_FTR_DBELL ASM_CONST(0x0000000000000200)
> #define CPU_FTR_CAN_NAP ASM_CONST(0x0000000000000400)
> #define CPU_FTR_L3CR ASM_CONST(0x0000000000000800)
> #define CPU_FTR_L3_DISABLE_NAP ASM_CONST(0x0000000000001000)
> @@ -373,7 +374,8 @@ extern const char *powerpc_base_platform;
> CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
> #define CPU_FTRS_E500MC (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
> CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
> - CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE)
> + CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
> + CPU_FTR_DBELL)
> #define CPU_FTRS_GENERIC_32 (CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
>
> /* 64-bit CPUs */
> diff --git a/arch/powerpc/include/asm/dbell.h b/arch/powerpc/include/asm/dbell.h
> new file mode 100644
> index 0000000..501189a
> --- /dev/null
> +++ b/arch/powerpc/include/asm/dbell.h
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright 2009 Freescale Semicondutor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + *
> + * provides masks and opcode images for use by code generation, emulation
> + * and for instructions that older assemblers might not know about
> + */
> +#ifndef _ASM_POWERPC_DBELL_H
> +#define _ASM_POWERPC_DBELL_H
> +
> +#include <linux/smp.h>
> +#include <linux/threads.h>
> +
> +#include <asm/ppc-opcode.h>
> +
> +#define PPC_DBELL_MSG_BRDCAST (0x04000000)
> +#define PPC_DBELL_TYPE(x) (((x) & 0xf) << 28)
> +enum ppc_dbell {
> + PPC_DBELL = 0, /* doorbell */
> + PPC_DBELL_CRIT = 1, /* critical doorbell */
> + PPC_G_DBELL = 2, /* guest doorbell */
> + PPC_G_DBELL_CRIT = 3, /* guest critical doorbell */
> + PPC_G_DBELL_MC = 4, /* guest mcheck doorbell */
> +};
> +
> +#ifdef CONFIG_SMP
> +extern unsigned long dbell_smp_message[NR_CPUS];
> +extern void smp_dbell_message_pass(int target, int msg);
> +#endif
> +
> +static inline void ppc_msgsnd(enum ppc_dbell type, u32 flags, u32 tag)
> +{
> + u32 msg = PPC_DBELL_TYPE(type) | (flags & PPC_DBELL_MSG_BRDCAST) |
> + (tag & 0x07ffffff);
> +
> + __asm__ __volatile__ (PPC_MSGSND(%0) : : "r" (msg));
> +}
> +
> +#endif /* _ASM_POWERPC_DBELL_H */
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index d159921..f420844 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -61,7 +61,7 @@ obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
> obj64-$(CONFIG_HIBERNATION) += swsusp_asm64.o
> obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o
> obj-$(CONFIG_44x) += cpu_setup_44x.o
> -obj-$(CONFIG_FSL_BOOKE) += cpu_setup_fsl_booke.o
> +obj-$(CONFIG_FSL_BOOKE) += cpu_setup_fsl_booke.o dbell.o
>
> extra-$(CONFIG_PPC_STD_MMU) := head_32.o
> extra-$(CONFIG_PPC64) := head_64.o
> diff --git a/arch/powerpc/kernel/dbell.c b/arch/powerpc/kernel/dbell.c
> new file mode 100644
> index 0000000..1493734
> --- /dev/null
> +++ b/arch/powerpc/kernel/dbell.c
> @@ -0,0 +1,44 @@
> +/*
> + * Author: Kumar Gala <galak@kernel.crashing.org>
> + *
> + * Copyright 2009 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/smp.h>
> +#include <linux/threads.h>
> +
> +#include <asm/dbell.h>
> +
> +#ifdef CONFIG_SMP
> +unsigned long dbell_smp_message[NR_CPUS];
> +
> +void smp_dbell_message_pass(int target, int msg)
> +{
> + int i;
> +
> + if(target < NR_CPUS) {
> + set_bit(msg, &dbell_smp_message[target]);
> + ppc_msgsnd(PPC_DBELL, 0, target);
> + }
> + else if(target == MSG_ALL_BUT_SELF) {
> + for_each_online_cpu(i) {
> + if (i == smp_processor_id())
> + continue;
> + set_bit(msg, &dbell_smp_message[i]);
> + ppc_msgsnd(PPC_DBELL, 0, i);
> + }
> + }
> + else { /* target == MSG_ALL */
> + for_each_online_cpu(i)
> + set_bit(msg, &dbell_smp_message[i]);
> + ppc_msgsnd(PPC_DBELL, PPC_DBELL_MSG_BRDCAST, 0);
> + }
> +}
> +#endif
> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> index 4ea6e1a..4c22620 100644
> --- a/arch/powerpc/kernel/head_fsl_booke.S
> +++ b/arch/powerpc/kernel/head_fsl_booke.S
> @@ -698,7 +698,9 @@ interrupt_base:
> /* Performance Monitor */
> EXCEPTION(0x2060, PerformanceMonitor, performance_monitor_exception, EXC_XFER_STD)
>
> - EXCEPTION(0x2070, Doorbell, unknown_exception, EXC_XFER_STD)
> + EXCEPTION(0x2070, Doorbell, doorbell_exception, EXC_XFER_STD)
> +
> + CRITICAL_EXCEPTION(0x2080, CriticalDoorbell, unknown_exception)
>
> /* Debug Interrupt */
> DEBUG_DEBUG_EXCEPTION
> @@ -921,6 +923,8 @@ _GLOBAL(__setup_e500mc_ivors)
> mtspr SPRN_IVOR35,r3
> li r3,Doorbell@l
> mtspr SPRN_IVOR36,r3
> + li r3,CriticalDoorbell@l
> + mtspr SPRN_IVOR37,r3
> sync
> blr
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 970d66e..678fbff 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -53,6 +53,9 @@
> #endif
> #include <asm/kexec.h>
> #include <asm/ppc-opcode.h>
> +#ifdef CONFIG_FSL_BOOKE
> +#include <asm/dbell.h>
> +#endif
>
> #if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
> int (*__debugger)(struct pt_regs *regs);
> @@ -1122,6 +1125,24 @@ void vsx_assist_exception(struct pt_regs *regs)
> #endif /* CONFIG_VSX */
>
> #ifdef CONFIG_FSL_BOOKE
> +
> +void doorbell_exception(struct pt_regs *regs)
> +{
> +#ifdef CONFIG_SMP
> + int cpu = smp_processor_id();
> + int msg;
> +
> + if (num_online_cpus() < 2)
> + return;
> +
> + for (msg = 0; msg < 4; msg++)
> + if (test_and_clear_bit(msg, &dbell_smp_message[cpu]))
> + smp_message_recv(msg);
> +#else
> + printk(KERN_WARNING "Received doorbell on non-smp system\n");
> +#endif
> +}
> +
> void CacheLockingException(struct pt_regs *regs, unsigned long address,
> unsigned long error_code)
> {
^ permalink raw reply
* Re: [PATCH 01/13] sdhci: Add quirk for controllers with no end-of-busy IRQ
From: Ben Dooks @ 2009-02-23 1:56 UTC (permalink / raw)
To: Pierre Ossman
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090221170504.657ff791@mjolnir.ossman.eu>
On Sat, Feb 21, 2009 at 05:05:04PM +0100, Pierre Ossman wrote:
> On Fri, 20 Feb 2009 20:33:08 +0300
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > From: Ben Dooks <ben-linux@fluff.org>
> >
> > The Samsung SDHCI (and FSL eSDHC) controller block seems to fail
> > to generate an INT_DATA_END after the transfer has completed and
> > the bus busy state finished.
> >
> > Changes in e809517f6fa5803a5a1cd56026f0e2190fc13d5c to use the
> > new busy method are the cause of the behaviour change.
> >
> > Signed-off-by: Ben Dooks <ben-linux@fluff.org>
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
>
> Any objections to me merging this right away? It is needed for another
> controller.
none from me.
sorry about the delay, moving servers.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
^ permalink raw reply
* powerpc 4xx power-management feature
From: Soohyung Cho @ 2009-02-23 2:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]
I have a AMCC Kilauea board and I want to use linux power-management
feature on it.
But it seems that there's no power-management codes for the powerpc 4xx
series.
I think the device-tree source for the Kilauea should be modified first.
Is there anyone who has tried it before?
Please help me.
[-- Attachment #2: Type: text/html, Size: 538 bytes --]
^ permalink raw reply
* [PATCH 2/2] Make sure we copy all cpu_spec features except PMC related ones
From: Michael Ellerman @ 2009-02-23 2:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, shaggy
In-Reply-To: <689159d7e17a2227e6000b51911750503eed1778.1235355941.git.michael@ellerman.id.au>
When identify_cpu() is called a second time with a logical PVR, it
only copies a subset of the cpu_spec fields so as to avoid overwriting
the performance monitor fields that were initialized based on the
real PVR.
However some of the other, non performance monitor related fields are
also not copied:
* pvr_mask
* pvr_value
* mmu_features
* machine_check
The fact that pvr_mask is not copied can result in show_cpuinfo()
showing the cpu as "unknown", if we override an unknown PVR with a
logical one - as reported by Shaggy.
So change the logic to copy all fields, and then put back the PMC
related ones in the case that we're overwriting a real PVR with a
logical one.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/cputable.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 944bd01..77febd3 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1765,22 +1765,27 @@ static struct cpu_spec the_cpu_spec;
static void __init setup_cpu_spec(unsigned long offset, struct cpu_spec *s)
{
struct cpu_spec *t = &the_cpu_spec;
+ struct cpu_spec old;
+
t = PTRRELOC(t);
+ old = *t;
+
+ /* Copy everything, then do fixups */
+ *t = *s;
/*
* If we are overriding a previous value derived from the real
* PVR with a new value obtained using a logical PVR value,
* don't modify the performance monitor fields.
*/
- if (t->num_pmcs && !s->num_pmcs) {
- t->cpu_name = s->cpu_name;
- t->cpu_features = s->cpu_features;
- t->cpu_user_features = s->cpu_user_features;
- t->icache_bsize = s->icache_bsize;
- t->dcache_bsize = s->dcache_bsize;
- t->cpu_setup = s->cpu_setup;
- t->cpu_restore = s->cpu_restore;
- t->platform = s->platform;
+ if (old.num_pmcs && !s->num_pmcs) {
+ t->num_pmcs = old.num_pmcs;
+ t->pmc_type = old.pmc_type;
+ t->oprofile_type = old.oprofile_type;
+ t->oprofile_mmcra_sihv = old.oprofile_mmcra_sihv;
+ t->oprofile_mmcra_sipr = old.oprofile_mmcra_sipr;
+ t->oprofile_mmcra_clear = old.oprofile_mmcra_clear;
+
/*
* If we have passed through this logic once before and
* have pulled the default case because the real PVR was
@@ -1794,10 +1799,9 @@ static void __init setup_cpu_spec(unsigned long offset, struct cpu_spec *s)
* and, in that case, keep the current value for
* oprofile_cpu_type.
*/
- if (t->oprofile_cpu_type == NULL)
+ if (old.oprofile_cpu_type == NULL)
t->oprofile_cpu_type = s->oprofile_cpu_type;
- } else
- *t = *s;
+ }
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
--
1.5.5
^ permalink raw reply related
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;
as well as URLs for NNTP newsgroup(s).