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,
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 s
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: []
.inotify_inode_queue_event+
On Sun, Apr 5, 2009 at 2:52 AM, Anton Vorontsov
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?
>
> pcm->dev->parent do
On Apr 5, 2009, at 9:39 AM, Grant Likely wrote:
On Sun, Apr 5, 2009 at 2:52 AM, Anton Vorontsov
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 wh
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 s
On Sun, Apr 5, 2009 at 9:59 AM, Kumar Gala 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 to figure out what the r
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 the
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,
and
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, p
Arnd Bergmann writes:
> On Thursday 02 April 2009, Geert Uytterhoeven wrote:
> > | arch/powerpc/platforms/built-in.o:(.toc1+0x4e8): undefined reference to
> > `pci_io_base'
> >
> > due to arch/powerpc/platforms/cell/io-workarounds.c. I guess this file
> > shouldn't be built when CONFIG_PCI=n?
>
> > >> @@ -263,7 +263,9 @@ long compat_arch_ptrace(struct task_stru
> > >> ret = ptrace_put_reg(child, numReg, freg);
> > >> } else {
> > >> flush_fp_to_thread(child);
> > >> -((unsigned int *)child->thread.r
14 matches
Mail list logo
