HI All,
Please find version XI of the PPC64 implementation of the
hardware breakpoint interfaces.
Changelog - ver XI
--
(Version X: linuxppc-dev ref: 20091211160144.ga23...@in.ibm.com)
- Conditionally unset MSR_SE in the single-step handler
- Added comments to explain the d
Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
These interfaces help arbitrate requests from various users and schedules
them as appropriate.
Signed-off-by: K.Prasad
---
arch/powerpc/Kconfig |1
arch/powerpc/include/asm/hw_breakpoint.h | 55
Hi ALL,
I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
rootfs resides in memory so modify files is non-effective after a
reboot. Some directories in rootfs, like /etc, /usr, ... are contain
many application configuration files and I want to mount it to jffs2
flash filesysye
On Fri, Dec 18, 2009 at 12:33:20AM +0530, K.Prasad wrote:
> On Mon, Dec 14, 2009 at 11:26:26AM -0800, Roland McGrath wrote:
> > What remains less than clear is how preemption relates. For any per-thread
> > hw_breakpoint, there is no high-level reason to care one way or the other.
> > The thread,
From: Anton Vorontsov
Date: Mon, 18 Jan 2010 18:47:50 +0300
> From: Jiajun Wu
>
> commit 7583605b6d29f1f7f6fc505b883328089f3485ad ("ucc_geth: Fix empty
> TX queue processing") fixed empty TX queue mishandling, but didn't
> account another corner case: when TX queue becomes full.
>
> Without th
> It is also not clear to me if disabling pre-emption for the user-space
> (albeit for a very tiny time-window) is incorrect and if their side-effects
> are known. If otherwise, I think we should choose to operate in pre-empt
> safe mode and avoid all costs associated when done without it.
I never
2010/1/19 Matthias Kaehlcke :
> El Tue, Jan 19, 2010 at 05:20:53PM +0800 Johnny Hung ha dit:
>
>> I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
>> rootfs resides in memory so modify files is non-effective after a
>> reboot. Some directories in rootfs, like /etc, /usr, ... a
El Tue, Jan 19, 2010 at 06:13:07PM +0800 Johnny Hung ha dit:
> 2010/1/19 Matthias Kaehlcke :
> > El Tue, Jan 19, 2010 at 05:20:53PM +0800 Johnny Hung ha dit:
> >
> >> I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
> >> rootfs resides in memory so modify files is non-effecti
2010/1/19 Matthias Kaehlcke :
> El Tue, Jan 19, 2010 at 06:13:07PM +0800 Johnny Hung ha dit:
>
>> 2010/1/19 Matthias Kaehlcke :
>> > El Tue, Jan 19, 2010 at 05:20:53PM +0800 Johnny Hung ha dit:
>> >
>> >> I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
>> >> rootfs resides in
El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
> On Tue, 19 Jan 2010, Johnny Hung wrote:
>
>> Okay, I think the steps is below if my rootfs is ramdisk and configure
>> files in jffs2,
>>
>> 1. cp /etc/* /mnt/mtd/etc/(/mnt/mtd is my jffs2 fs)
>> 2. rm -rf /etc/*
>> 3. make sy
El Tue, Jan 19, 2010 at 05:20:53PM +0800 Johnny Hung ha dit:
> I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
> rootfs resides in memory so modify files is non-effective after a
> reboot. Some directories in rootfs, like /etc, /usr, ... are contain
> many application config
We had merged the 2.6.24 with the FSL based NAND driver, we observed that
gpio library is mandatory to be included. We have not included the gpios
configured in the dts file as the we don’t have the separate GPIO
chip(arch/powepc/boot/dts/board.dts).
After executing the image in the board,
On Tue, 19 Jan 2010, Johnny Hung wrote:
Okay, I think the steps is below if my rootfs is ramdisk and configure
files in jffs2,
1. cp /etc/* /mnt/mtd/etc/(/mnt/mtd is my jffs2 fs)
2. rm -rf /etc/*
3. make symbolic links from all /etc/xx to /mnt/mtd/etc/xxx
4. remake ramdisk rootfs
It seems
nanda wrote:
We had merged the 2.6.24
That's pretty old...
with the FSL based NAND driver,
Which one? Which chip are you using, and how is NAND attached to it?
we observed that gpio library is mandatory to be included. We have not included the
gpios configured in the dts file as the we
On Jan 19, 2010, at 12:54 AM, Alex Dubov wrote:
> I'm working on an mpc8548 based board and recently I've encountered a
> problem, whereupon kernel crashed each time module loading is attempted. I
> traced the problem to the fact, that vmalloc_exec was setting incorrect
> page attributes on alloc
On Jan 18, 2010, at 9:53 AM, Anton Vorontsov wrote:
> On Wed, Dec 16, 2009 at 01:58:09AM +0300, Anton Vorontsov wrote:
>> MPC85xx chips report the wrong value in feature reporting register,
>> and that causes the following oops:
>>
>> Unable to handle kernel paging request for data at address 0x
The following patch series brings support for the Freescale MPC512x
processsors up to date:
[PATCH 01/11] fs_enet: Add support for MPC512x to fs_enet driver
[PATCH 02/11] fs_enet: Add FEC TX Alignment workaround for MPC5121
[PATCH 03/11] powerpc/mpc5121: Add machine restart support
[PATCH 04/11] i
drivers/net/fs_enet/*
Enable fs_enet driver to work 5121 FEC
Enable it with CONFIG_FS_ENET_MPC5121_FEC
Signed-off-by: John Rigby
Signed-off-by: Piotr Ziecik
Signed-off-by: Wolfgang Denk
Signed-off-by: Anatolij Gustschin
Cc:
Cc: Grant Likely
Cc: John Rigby
---
drivers/ne
From: John Rigby
The FEC on 5121 has problems with misaligned tx buffers.
The RM says any alignment is ok but empirical results
show that packet buffers ending in 0x1E will sometimes
hang the FEC. Other bad alignment does not hang but will
cause silent TX failures resulting in about a 1% packet
Add reset module registers representation and
machine restart callback for mpc5121 platform.
Signed-off-by: Piotr Ziecik
Signed-off-by: Wolfgang Denk
Signed-off-by: Anatolij Gustschin
Cc: Grant Likely
Cc: John Rigby
---
arch/powerpc/include/asm/mpc5xxx.h| 14 +-
arch/po
From: Piotr Ziecik
- Update Kconfig for i2c-mpc driver.
- Enable I2C interrupts on MPC5121.
Signed-off-by: Piotr Ziecik
Signed-off-by: Wolfgang Denk
Signed-off-by: Anatolij Gustschin
Cc:
Cc: Grant Likely
Cc: John Rigby
---
drivers/i2c/busses/Kconfig |9 +
drivers/i2c
From: John Rigby
Based on Domen Puncer's rtc driver for 5200 posted to
the ppclinux mailing list:
http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11675
but never commited anywhere.
Changes to Domen's original:
Changed filenames/routine names from mpc5200* to mpc5121*
Chan
From: Piotr Ziecik
Adds NAND Flash Controller driver for MPC5121 Revision 2.
All device features, except hardware ECC and power management,
are supported.
Signed-off-by: Piotr Ziecik
Signed-off-by: Wolfgang Denk
Signed-off-by: Anatolij Gustschin
Cc:
Cc: Grant Likely
Cc: John Rigby
---
arc
From: Piotr Ziecik
Adds initial version of MPC512x DMA driver.
Only memory to memory transfers are currenly supported.
Signed-off-by: Piotr Ziecik
Signed-off-by: Wolfgang Denk
Signed-off-by: Anatolij Gustschin
Cc: Dan Williams
Cc: Grant Likely
Cc: John Rigby
---
drivers/dma/Kconfig
Platform specific code for MPC5121 USB Host support.
MPC5121 Rev 2.0 silicon EHCI registers are big endian.
Add appropriate support by specifying "big-endian-regs"
property in device tree node for USB controller. Also
allow specifying DRVVBUS and PWR_FAULT signal polarity
of MPC5121 internal PHY us
MPC5121 DIU configuration/setup as initialized by the boot
loader currently will get lost while booting Linux. As a
result displaying the boot splash is not possible through
the boot process.
To prevent this we reserve configured DIU frame buffer
address range while booting and preserve AOI descri
Collects several changes needed after applying
previous mpc5121 platform and driver patches:
- Add mpc5121 reset module node
- Clean up and fix NAND description, remove unused properties
here and correct NAND flash chip size.
- Add I2C RTC node for m41t80 RTC
- Fix compatible property in DMA nod
From: Wolfgang Denk
As more MPC512x based boards will be coming soon, a new directory
arch/powerpc/configs/512x/ for board specific config files is created,
following the example of other processor families.
In a first step, we just copy (and update) the existing defconfig
file for the mpc5121ad
Well... where are the other 9 patches?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Anatolij Gustschin wrote:
+struct reg_tbl {
+ void __iomem *fec_ievent;
+ void __iomem *fec_imask;
+ void __iomem *fec_r_des_active;
+ void __iomem *fec_x_des_active;
+ void __iomem *fec_r_des_start;
+ void __iomem *fec_x_des_start;
+ void __iomem *fec_r_
Hi All,
please comment on following patch.
Kind regards,
Wim.
commit 88d0b1a9c071d26e7b4831320067c84b04ea04a8
Author: Wim Van Sebroeck
Date: Sat Dec 26 18:55:22 2009 +
[WATCHDOG] watchdog_info separation and constify
make sure that the watchdog_info struct is seperated from
On Tue, Jan 19, 2010 at 16:42, Joe Perches wrote:
> On Tue, 2010-01-19 at 22:17 +0100, Wim Van Sebroeck wrote:
>> -static struct watchdog_info at32_wdt_info = {
>> +static const struct watchdog_info at32_wdt_info = {
>
> It'd be good to use a consistent structure name:
>
> static const struct watch
On Tue, 2010-01-19 at 22:17 +0100, Wim Van Sebroeck wrote:
> -static struct watchdog_info at32_wdt_info = {
> +static const struct watchdog_info at32_wdt_info = {
It'd be good to use a consistent structure name:
static const struct watchdog_info ident = {
etc...
}
$ grep -Poh "struct\s*w
On Tue, 19 Jan 2010 22:17:59 +0100
Wim Van Sebroeck wrote:
> Hi All,
>
> please comment on following patch.
Why move them out - why not just make them const ?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinf
Hi Alan,
> > please comment on following patch.
>
> Why move them out - why not just make them const ?
There's 2 options:
1) we only make them const now. And we move them out later when we do the
conversion to the generic watchdog api (which means that we will rip out the
code for the open, re
On Tue, 2010-01-19 at 22:16 +, Mark Brown wrote:
> On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote:
> > Maybe a standard #define WATCHDOG_NAME
> > .identity = WATCHGOD_NAME
>
> I don't really see that the indrection via the #define would buy us
> anything?
Maybe not, just a sugge
On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote:
> Maybe a standard #define WATCHDOG_NAME
> .identity = WATCHGOD_NAME
I don't really see that the indrection via the #define would buy us
anything?
___
Linuxppc-dev mailing list
Linuxppc-dev@
Benjamin Herrenschmidt wrote:
On Wed, 2010-01-13 at 10:18 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2010-01-12 at 15:09 +0100, Stef van Os wrote:
This patch adds type 1 PCI transactions to 4xx PCI code, enabling the
discovery of
devices behind a PCI bridge.
Your patch appears
On Wed, 2010-01-20 at 00:52 +0200, Felix Radensky wrote:
>
> 405XX - no
> 440EP - no
> 440GR - no
> 440EPx/440GRx - no
>
> 440GP - yes
> 440GX - yes
> 440SP - yes
> 440SPe - yes
> 460XX - yes
>
> The distinction between these groups is pretty clear in the device trees.
> The members of the first
Hi Dave,
On Tue, 19 Jan 2010 12:37:06 -0800 (PST) David Miller
wrote:
>
> Well... where are the other 9 patches?
I think the other 9 are not network related, just PowerPC related.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgp3rmiI
>
> > So, the obvious question is, what is the current
> status of large physical
> > address support on e500? Is it a problem in current
> git version or is it
> > not ready yet?
> >
> > Thanks.
>
> Its possible that we've broken module/vmalloc support with
> "Large physical addressing". Its n
2010/1/19 Matthias Kaehlcke :
> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
>
>> On Tue, 19 Jan 2010, Johnny Hung wrote:
>>
>>> Okay, I think the steps is below if my rootfs is ramdisk and configure
>>> files in jffs2,
>>>
>>> 1. cp /etc/* /mnt/mtd/etc/ (/mnt/mtd is my jffs
From: Stephen Rothwell
Date: Wed, 20 Jan 2010 10:42:25 +1100
> On Tue, 19 Jan 2010 12:37:06 -0800 (PST) David Miller
> wrote:
>>
>> Well... where are the other 9 patches?
>
> I think the other 9 are not network related, just PowerPC related.
Ok, but that's very confusing.
If it's meant to go
[Not sure what happened to the previous versions To/CC lists, sorry]
Hi all,
Today's linux-next build (powerpc allyesconfig) produced this warning:
arch/powerpc/kvm/book3s.c: In function '__kvmppc_vcpu_run':
arch/powerpc/kvm/book3s.c:1102: warning: 'ext_bkp.vrsave' may be used
uninitialized in
On Wed, 20 Jan 2010, Johnny Hung wrote:
i'd also recommend you to consider if you really need the
ramdisk. when using a ram disk its entire content is loaded to the RAM
occupying space, even if you don't use certain files (or part of
them). other filesystems are more efficient in this aspect.
i
El Wed, Jan 20, 2010 at 10:32:15AM +0800 Johnny Hung ha dit:
> 2010/1/19 Matthias Kaehlcke :
> > El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
> >
> >> On Tue, 19 Jan 2010, Johnny Hung wrote:
> >>
> >>> Okay, I think the steps is below if my rootfs is ramdisk and configure
> >>
El Wed, Jan 20, 2010 at 08:15:01AM +0100 Ricard Wanderlof ha dit:
> On Wed, 20 Jan 2010, Johnny Hung wrote:
>
>>> i'd also recommend you to consider if you really need the
>>> ramdisk. when using a ram disk its entire content is loaded to the RAM
>>> occupying space, even if you don't use certain
47 matches
Mail list logo
