Becky Kumar,
Considering these fixups, would it be advisable for the dma functions
to climb up the dev-parent linkage when dma_ops are NULL?
g.
On Sat, Apr 4, 2009 at 12:33 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
The driver should pass a device that specifies internal DMA ops, but
On Sat, Apr 04, 2009 at 11:59:39PM -0600, Grant Likely wrote:
Becky Kumar,
Considering these fixups, would it be advisable for the dma functions
to climb up the dev-parent linkage when dma_ops are NULL?
pcm-dev-parent doesn't point to the proper device, so
this won't work.
On Sat, Apr 4,
Hi All,
I'm trying to upgrade my powerpc system from 2.6.14.7 to 2.6.24.2 .
I'm confused regarding the need to use a Flattened Device Tree, and not sure
whether and how I should use it .Does u-boot 1.1.2 support it ?
(I migrated from ARCH=ppc to ARCH=powerpc) .
Best Regards,
Yigal Goldberger.
Dear Yigal Goldberger,
In message 673522.16603...@web38902.mail.mud.yahoo.com you wrote:
I'm trying to upgrade my powerpc system from 2.6.14.7 to 2.6.24.2 .
I'm confused regarding the need to use a Flattened Device Tree, and not sure
whether and how I should use it .Does u-boot 1.1.2
With 2.6.29-git12 on a powerpc box i observed the following
warning
=
2.6.29-git12 #1
inconsistent {IN-RECLAIM_FS-W} - {RECLAIM_FS-ON-W} usage.
yum-updatesd-he/6947 [HC0[0]:SC0[0]:HE1:SE1] takes:
(inode-inotify_mutex){+.+.?.}, at: [c0154a04]
On Sun, Apr 5, 2009 at 2:52 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Sat, Apr 04, 2009 at 11:59:39PM -0600, Grant Likely wrote:
Becky Kumar,
Considering these fixups, would it be advisable for the dma functions
to climb up the dev-parent linkage when dma_ops are NULL?
On Apr 5, 2009, at 9:39 AM, Grant Likely wrote:
On Sun, Apr 5, 2009 at 2:52 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Sat, Apr 04, 2009 at 11:59:39PM -0600, Grant Likely wrote:
Becky Kumar,
Considering these fixups, would it be advisable for the dma
functions
to climb up
On Thu, 2 Apr 2009, Chris Friesen wrote:
Hugh Dickins wrote:
This is a cosmetic matter, not worth more than a couple of lines of
code: I suggested masking off the high bits in the display, but when
KAMEZAWA-san suggested just showing 0, it was hard to argue against
his brutal
On Sun, Apr 5, 2009 at 9:59 AM, Kumar Gala ga...@kernel.crashing.org wrote:
No, I think we should just fix drivers. There aren't that many SoC drivers
and once they are fixed this will resolve itself.
I agree. The only reason I passed NULL when I wrote the drivers was
because I was too lazy
On Fri, Mar 20, 2009 at 07:44:29PM +0300, Anton Vorontsov wrote:
This patch introduces ARCH_HAS_NORMAL_FRAME_POINTERS Kconfig symbol.
When defined, the top level Makefile won't add -fno-omit-frame-pointer
cflag (the flag is useless in PowerPC kernels, and also makes gcc
generate wrong code).
On Sat, Apr 04, 2009 at 05:46:38PM +0530, Vijay Nikam wrote:
Hello Vijay.
Because while searching some information regarding this I learned
about High-Res Timers. In linux-2.6.20 x86 has this feature enabled
rather you can enable it but not for powerpc arch, Right ? ? ? If yes
then is there
The irq remapping layer seems to cause some confusion when people
see a different irq number in /proc/interrupts vs the one they
request in their driver or DTS.
So have the irq remapping layer print out a message when we map an
irq. The message is only printed the first time the irq is mapped,
Add an option, on by default, to build all code under arch/powerpc with
-Werror, which causes gcc to treat warnings as errors.
The intention is to make it harder for people to inadvertantly introduce
errors in the arch/powerpc code. It needs to be configurable so that
if a warning is introduced,
13 matches
Mail list logo