Hi Kim,
u-boot assigns the IMMR to 0xff40 in TQM834x.h, whereas the device
tree you picked has it at 0xe000 (it's defined in the soc node).
Don't forget to match up the PCI addresses too. patches welcome, of
course (we don't have tqm boards).
Thanks for this important information! I'
Anton Vorontsov <[EMAIL PROTECTED]> writes:
> On Tue, Sep 09, 2008 at 07:45:19AM -0700, Junio C Hamano wrote:
> ...
>> ... It's an interesting idea from git person's point of
>> view (i.e. "would be fun to implement"), but I doubt it would be useful in
>> practice, because:
>>
>> (1) You often
On Tue, 2008-09-09 at 19:11 -0500, James Bottomley wrote:
> On Wed, 2008-09-10 at 10:09 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2008-09-09 at 19:04 -0500, James Bottomley wrote:
> > > commit deac93df26b20cf8438339b5935b5f5643bc30c9
> > > Author: James Bottomley <[EMAIL PROTECTED]>
> > > Da
On Wed, 2008-09-10 at 10:09 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2008-09-09 at 19:04 -0500, James Bottomley wrote:
> > commit deac93df26b20cf8438339b5935b5f5643bc30c9
> > Author: James Bottomley <[EMAIL PROTECTED]>
> > Date: Wed Sep 3 20:43:36 2008 -0500
> >
> > lib: Correct printk
On Tue, 2008-09-09 at 19:04 -0500, James Bottomley wrote:
> commit deac93df26b20cf8438339b5935b5f5643bc30c9
> Author: James Bottomley <[EMAIL PROTECTED]>
> Date: Wed Sep 3 20:43:36 2008 -0500
>
> lib: Correct printk %pF to work on all architectures
>
> Broke the non modular builds by moving
commit deac93df26b20cf8438339b5935b5f5643bc30c9
Author: James Bottomley <[EMAIL PROTECTED]>
Date: Wed Sep 3 20:43:36 2008 -0500
lib: Correct printk %pF to work on all architectures
Broke the non modular builds by moving an essential function into
modules.c. Fix this by moving it out again
On Fri, Sep 05, 2008 at 03:06:18AM +0200, Christoph Hellwig wrote:
> Current linus tree fail to build for me for a 64bit powerpc config with:
This is cause by
commit 7563dc64585324f443f5ac107eb6d89ee813a2d2
Author: Tony Breeds <[EMAIL PROTECTED]>
Date: Tue Sep 2 16:50:38 2008 +1000
powerpc
On Sep 9, 2008, at 5:13 PM, Christoph Hellwig wrote:
On Wed, Sep 10, 2008 at 08:10:31AM +1000, Benjamin Herrenschmidt
wrote:
Yeah, the statement this time should be why do you keep _single :)
It don't really mind which one we keep, but having both and both
optional seems rather odd.
It wo
On Wed, Sep 10, 2008 at 08:10:31AM +1000, Benjamin Herrenschmidt wrote:
>
> > Yeah, the statement this time should be why do you keep _single :)
> > It don't really mind which one we keep, but having both and both
> > optional seems rather odd.
>
> It would be more logic to implement _single on t
> Yeah, the statement this time should be why do you keep _single :)
> It don't really mind which one we keep, but having both and both
> optional seems rather odd.
It would be more logic to implement _single on top of _page.. as long as
we can still do sub-page mappings (needed on ppc64) which I
On Tue, 2008-09-09 at 14:08 -0400, Kyle McMartin wrote:
> On Tue, Sep 09, 2008 at 09:12:41AM -0500, James Bottomley wrote:
> > OK, so could we get this in to -rc5 please? It's a bug fix for parisc
> > since we're currently printing rubbish.
> >
>
> While I suppose it's a "parisc" patch, I'm not
Timur Tabi wrote:
On Mon, Sep 8, 2008 at 2:56 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
This patch doesn't change that for cpm2, since port.dev is never
initialized. :-P
I don't initialize port->dev in the UCC UART driver,
Yes you do -- check line 1403.
-Scott
___
On Tue, Sep 09, 2008 at 09:39:20AM -0500, Becky Bruce wrote:
> because you asked me to have just map/unmap_page in your review
> of an earlier rev of this patch series in May? :) I don't actually
> expect you to remember this, because it was a long time ago, but
> here's the relevant ch
On Mon, 8 Sep 2008 21:47:29 -0300
Rogério Brito <[EMAIL PROTECTED]> wrote:
> Hi there.
>
> I just compiled a new 2.6.27-rc5 kernel for my standard Kurobox (an
> embedded NAS that has an MPC8241 CPU, if I'm not mistaken) and upon
> booting, I get these scary messages and Call Traces:
[snip]
This
Anton Vorontsov <[EMAIL PROTECTED]> writes:
> Now consider the following patch (modified by hand: it should say
> +foo, but I changed it to +bar).
> ...
> The "index ..." stuff says that there are no changes and it is
> pure rename, but obviously there is a change.
Ah, I see what you mean. But i
Anton Vorontsov <[EMAIL PROTECTED]> writes:
> ..rename and changes ideally go in separate patches.
>
> IIRC this also helps git to track renames (it can easily compare
> hashes instead of guessing).
It does not help much, and it is frowned upon (at least by well educated
users in git circle) beca
Anton Vorontsov <[EMAIL PROTECTED]> writes:
>>> 3 files changed, 201 insertions(+), 201 deletions(-)
>>> create mode 100644 arch/powerpc/kernel/dma.c
>>> delete mode 100644 arch/powerpc/kernel/dma_64.c
>>
>> Passing -M to git format-patch makes it much easier
>
> I always thought that posting "
Hi Josh,
Thanks for your reply.
> That was a bit old and I've updated it now to match the overallpowerpc.git
> tree master branch
Thanks. I can see the changes now.
> Generally, if you track my 'next' branch that is what will be most current
> for 4xxjosh
Should I base my patch from your master
Hi Josh,
I am planning to submit a patch to support 4K/16K and 64K page size for 4xx
processors.
I see that your git tree still has the include/asm-powerpc/* header files,
while in Linus's git tree, the powerpc specific header file has been moved to
arch/powerpc/include/asm.
Should I base my pa
For Freescale 8xxx devices that use an MPIC, the interrupt numbers in the
device tree must be 16 greater than the values documented in the reference
manual. In these chips, the MPIC is wired to use the first 16 numbers for
external interrupts, but the documentation numbers internal interrupts from
Hello,
Anyone has the BDI2000 board configuration file for Freescale's
MPC8323e-RDB board?
Thanks for your help,
Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
The interrupt values in a device tree must be 16 greater than the actual
interrupt number for a given device. The interrupt property for the DMA
channels for DMA2 in the MPC8610 HPCD device tree was using the raw values,
not the adjusted ones.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
Ku
Dear Oliver,
In message <[EMAIL PROTECTED]> you wrote:
>
> currently I'm evaluating a TQM8349 (MPC8349E-based) module on a STK85xx.
> I wonder if anybody has already managed to get this module running under
> ARCH=powerpc.
No such attempts were made by us. So far, TQ did not voice any inte-
r
On Mon, Sep 8, 2008 at 2:56 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
> This patch doesn't change that for cpm2, since port.dev is never
> initialized. :-P
I don't initialize port->dev in the UCC UART driver, but it's still
non-zero, so why isn't it initialized in the CPM UART driver?
(P.S. Beck
On Tue, Sep 09, 2008 at 09:12:41AM -0500, James Bottomley wrote:
> OK, so could we get this in to -rc5 please? It's a bug fix for parisc
> since we're currently printing rubbish.
>
While I suppose it's a "parisc" patch, I'm not going to try to push it
unless either Linus just applies it, or we g
On Tue, 09 Sep 2008 16:25:39 +0200
Oliver Rutsch <[EMAIL PROTECTED]> wrote:
> U-Boot (1.3.4):
> Appended the file include/configs/TQM834x.h to support fdt:
>
> #define CONFIG_OF_LIBFDT 1
> #define CONFIG_OF_BOARD_SETUP 1
> #define CONFIG_OF_STDOUT_VIA_ALIAS1
>
> Appended the file board/
On Tue, Sep 09, 2008 at 07:45:19AM -0700, Junio C Hamano wrote:
> Anton Vorontsov <[EMAIL PROTECTED]> writes:
>
> > Now consider the following patch (modified by hand: it should say
> > +foo, but I changed it to +bar).
> > ...
> > The "index ..." stuff says that there are no changes and it is
> >
On Sep 8, 2008, at 5:03 PM, Christoph Hellwig wrote:
- if (unlikely(dev == NULL || dev->archdata.dma_ops == NULL))
+
+ if (unlikely(dev == NULL) || dev->archdata.dma_ops == NULL) {
+#ifdef CONFIG_PPC64
return NULL;
+#else
+ /* Use default on 32-bit if d
Hi,
currently I'm evaluating a TQM8349 (MPC8349E-based) module on a STK85xx.
I wonder if anybody has already managed to get this module running under
ARCH=powerpc.
As I did not found anything on the net I tried the following:
U-Boot (1.3.4):
Appended the file include/configs/TQM834x.h to supp
On Sep 8, 2008, at 2:56 PM, Scott Wood wrote:
Becky Bruce wrote:
We're currently passing NULL, and really shouldn't be.
This patch doesn't change that for cpm2, since port.dev is never
initialized. :-P
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
drivers/serial/cpm_uart/cpm_uart_c
OK, so could we get this in to -rc5 please? It's a bug fix for parisc
since we're currently printing rubbish.
James
---
From: James Bottomley <[EMAIL PROTECTED]>
Date: Wed, 3 Sep 2008 20:43:36 -0500
Subject: lib: Correct printk %pF to work on all architectures
It was introduced by
commit 0fe1e
On Tue, Sep 09, 2008 at 10:00:28AM -0400, Josh Boyer wrote:
>One of the changes in the bootwrapper makefile introduced the dtbImage targets
>for boards that need a simple zImage with a DTB embedded in them. When this
>was done, it broke booting on the Holly board as the zImage.holly wrapper did
>n
One of the changes in the bootwrapper makefile introduced the dtbImage targets
for boards that need a simple zImage with a DTB embedded in them. When this
was done, it broke booting on the Holly board as the zImage.holly wrapper did
not get the DTB embedded properly.
This patch changes the target
On Tue, Sep 09, 2008 at 01:52:29PM +0200, Matthias Fuchs wrote:
>On Monday 08 September 2008 18:03, Scott Wood wrote:
>> On Sat, Sep 06, 2008 at 05:07:15PM +0200, Wolfgang Grandegger wrote:
>> > How about "dtt"? That's what we use in U-Boot for digital temperature
>> > sensors as well.
>>
>> I vot
On Tue, Sep 09, 2008 at 03:04:47PM +1000, David Gibson wrote:
> The typesafe version of the powerpc pagetable handling (with
> USE_STRICT_MM_TYPECHECKS defined) has bitrotted again. This patch
> makes a bunch of small fixes to get it building again.
It might be a better idea to mark these types _
On Monday 08 September 2008 18:03, Scott Wood wrote:
> On Sat, Sep 06, 2008 at 05:07:15PM +0200, Wolfgang Grandegger wrote:
> > How about "dtt"? That's what we use in U-Boot for digital temperature
> > sensors as well.
>
> I vote against any acronyms that are not very well known. Even knowing
> t
On Tue, 2008-09-09 at 00:03 +0200, Christoph Hellwig wrote:
> > - if (unlikely(dev == NULL || dev->archdata.dma_ops == NULL))
> > +
> > + if (unlikely(dev == NULL) || dev->archdata.dma_ops == NULL) {
> > +#ifdef CONFIG_PPC64
> > return NULL;
> > +#else
> > + /* Use default
On Tue, 09 Sep 2008 17:11:23 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-09-08 at 08:44 -0400, Josh Boyer wrote:
> > The following patch series adds things needed to support the PowerPC 405EZ
> > SoC. I've incorporated the suggestions and fixes from the previous round
>
On Mon, Sep 08, 2008 at 05:53:41PM -0700, Junio C Hamano wrote:
> Anton Vorontsov <[EMAIL PROTECTED]> writes:
>
> >>> 3 files changed, 201 insertions(+), 201 deletions(-)
> >>> create mode 100644 arch/powerpc/kernel/dma.c
> >>> delete mode 100644 arch/powerpc/kernel/dma_64.c
> >>
> >> Passing -
On Tue, 9 Sep 2008, Anton Vorontsov wrote:
> On Mon, Sep 08, 2008 at 04:38:57PM -0500, Scott Wood wrote:
> > Anton Vorontsov wrote:
> >> I always thought that posting "-M" patches to the public lists is
> >> discouraged since it is quite difficult to apply them via patch(1).
> >> Also think of non-
Hello,
please consider the ehea-fix-dlpar-memory-handling.patch as critical bug fix,
as it fixes a potential firmware error causing the driver to get inoperable
when system memory is sparse. Therefore please include this fix into 2.6.27.
Regards
Hannes
On Tuesday 09 September 2008 00:25:56 you
On Mon, 2008-09-08 at 08:44 -0400, Josh Boyer wrote:
> The following patch series adds things needed to support the PowerPC 405EZ
> SoC. I've incorporated the suggestions and fixes from the previous round
> of patches and barring any further comments these should be ready to go.
For some reason,
On Sun, 2008-09-07 at 22:57 -0700, Victor Gallardo wrote:
> Hello Benjamin,
>
> On the 460EX/GT in SGMII mode, GPCS access is needed for communication with
> the internal SGMII SerDes. It is possible that there is still a PHY. So we
> need a way to access both addresses.
>
> For Example on th
43 matches
Mail list logo
