Hello All,
I created a very simple program which has higher priority than normal
tasks and runs a tight loop. Under same test environment I ran this
program on both non-rt and rt 2.6.33.5 kernel. To my suprise I see that
performance of non-RT kernel is better than RT. non-RT kernel took 3 sec
On Wed, Aug 11, 2010 at 10:00 PM, Zang Roy-R61911 wrote:
>
>
>> -Original Message-
>> From: Zang Roy-R61911
>> Sent: Wednesday, August 11, 2010 12:47 PM
>> To: Zang Roy-R61911; a...@linux-foundation.org;
>> linux-...@vger.kernel.org
>> Cc: linuxppc-...@ozlabs.org; mir...@gmail.com;
>> cbou
> -Original Message-
> From: Zang Roy-R61911
> Sent: Wednesday, August 11, 2010 12:47 PM
> To: Zang Roy-R61911; a...@linux-foundation.org;
> linux-...@vger.kernel.org
> Cc: linuxppc-...@ozlabs.org; mir...@gmail.com;
> cbouatmai...@gmail.com; grant.lik...@secretlab.ca
> Subject: RE: [P
When looking at some issues with the virtual ethernet driver I noticed
that TCE allocation was following a very strange pattern:
address 00e9000 length 2048
address 0409000 length 2048 <-
address 0429000 length 2048
address 0449000 length 2048
address 0469000 length 2048
address 0489000 lengt
2.6.35-stable review patch. If anyone has any objections, please let us know.
--
From: Ian Campbell
commit 685fd0b4ea3f0f1d5385610b0d5b57775a8d5842 upstream.
A small number of users of IRQF_TIMER are using it for the implied no
suspend behaviour on interrupts which are not tim
2.6.34-stable review patch. If anyone has any objections, please let us know.
--
From: Ian Campbell
commit 685fd0b4ea3f0f1d5385610b0d5b57775a8d5842 upstream.
A small number of users of IRQF_TIMER are using it for the implied no
suspend behaviour on interrupts which are not tim
2.6.32-stable review patch. If anyone has any objections, please let us know.
--
From: Ian Campbell
commit 685fd0b4ea3f0f1d5385610b0d5b57775a8d5842 upstream.
A small number of users of IRQF_TIMER are using it for the implied no
suspend behaviour on interrupts which are not tim
While testing CPU DLPAR, the following problem was discovered.
We were DLPAR removing the first CPU, which in this case was
logical CPUs 0-3. CPUs 0-2 were already marked offline and
we were in the process of offlining CPU 3. After marking
the CPU inactive and offline in cpu_disable, but before th
Marvell and GPIO bindings live in their own files, so the TOC should not
mention them.
Also fix chapters numbering.
Signed-off-by: Anton Vorontsov
---
Documentation/powerpc/booting-without-of.txt | 31 +
1 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/D
On Wed, Aug 11, 2010 at 07:49:40PM +0530, Ravi Gupta wrote:
> Also, when I try to export a gpio in sysfs
>
> echo 9 > /sys/class/gpio/export
>
> It gives me an error in dmesg
> gpio_request: gpio-9 (sysfs) status -22
> export_store: status -22
>
> Here is a look of sysfs on my machine
>
> # ls
Hi,
On Wed, Aug 11, 2010 at 06:57:16PM +0530, Ravi Gupta wrote:
> I am new to device driver development. I am trying to access the GPIO of
> MPC837xERDB eval board. I have upgraded its kernel to linux-2.6.28.9 and
> enable support for mpc8xxx_gpio.c. On boot up, it successfully detect two
> gpio c
Also, when I try to export a gpio in sysfs
echo 9 > /sys/class/gpio/export
It gives me an error in dmesg
gpio_request: gpio-9 (sysfs) status -22
export_store: status -22
Here is a look of sysfs on my machine
# ls /sys/class/gpio/ -la
drwxr-xr-x4 root root0 Jan 1 00:00 .
drw
u can directly access GPIO registers in kernel, by ioremap of GPIO
memory mapped registers.
you might need to check
- muxing of gpio
-mj
On Wed, Aug 11, 2010 at 6:57 PM, Ravi Gupta wrote:
> Hi,
>
> I am new to device driver development. I am trying to access the GPIO of
> MPC837xERDB eval board.
On Mon, 2010-08-09 at 12:53 -0500, Nathan Fontenot wrote:
> This set of patches de-couples the idea that there is a single
> directory in sysfs for each memory section. The intent of the
> patches is to reduce the number of sysfs directories created to
> resolve a boot-time performance issue. On
Hi,
I am new to device driver development. I am trying to access the GPIO of
MPC837xERDB eval board. I have upgraded its kernel to linux-2.6.28.9 and
enable support for mpc8xxx_gpio.c. On boot up, it successfully detect two
gpio controllers. Now my question is how I am going to use it to communica
On 11.08.2010 09:53, Sripathi Kodi wrote:
On Wed, 11 Aug 2010 12:51:35 +0530
divya wrote:
Hi,
Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with
following error on both system x and p
fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
fs/9p/vfs_inode.c:
Hi Paul,
> Nice... Just one nit, and that is that I think we now need a dummy
> stcx in the context switch code so there is no possibility of getting
> from one user context to another with a reservation still pending from
> the first context. I guess our chances of getting through schedule()
>
On Wed, 2010-08-11 at 16:41 +1000, Paul Mackerras wrote:
> On Wed, Aug 11, 2010 at 03:20:05PM +1000, Anton Blanchard wrote:
>
> > All recent POWER CPUs check the address before letting the stcx succeed
> > so we can create a CPU feature and nop it out. As Ben suggested, we can
> > only do this in
On Wed, 11 Aug 2010 12:51:35 +0530
divya wrote:
> Hi,
>
> Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with
> following error on both system x and p
>
>fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
>fs/9p/vfs_inode.c:1267: error: implicit declaration
Hi Divya,
On Wed, 11 Aug 2010 12:51:35 +0530 divya wrote:
>
> Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with
> following error on both system x and p
>
>fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
>fs/9p/vfs_inode.c:1267: error: implicit declarat
Hi,
Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with
following error on both system x and p
fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
fs/9p/vfs_inode.c:1267: error: implicit declaration of function
'inode_setattr'
make[2]: *** [fs/9p/vfs_inode.o]
On Tue, Aug 10, 2010 at 11:55 PM, Shawn Jin wrote:
> Hi,
>
> The kernel 2.6.33 failed to mount the rootfs on the ramdisk. I enabled
> the ramdisk block device support and ext2 filesystem as shown below.
>
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=16
> CONFIG_BLK_DEV_RAM_SIZE=4096
> CONFIG_
Hi,
I am new to linux device driver development and I'm trying to learn the
DMA transfer. Currently I have created a DMA buffer using
pci_alloc_consistent() function. Since I don't have a real DMA enabled pci
device, so I am thinking of transfer the data in the DMA buffer to some
other buffer wit
23 matches
Mail list logo
