While booting today's next tree on a powerpc box [ power 6 blade]
observed the following :
khelper used greatest stack depth: 10176 bytes left
=
[ BUG: lock held at task exit time! ]
-
khelper/21 is exiting with locks still
From: Milton Miller
This adds the PowerPC 2.06 tlbie mnemonics and keeps backwards
compatibilty for CPUs before 2.06.
Only useful for bare metal systems.
Signed-off-by: Milton Miller
Signed-off-by: Michael Neuling
---
As they say, better out than in
---
arch/powerpc/include/asm/cputab
These patches implement the new PowerPC 2.06 tlbie mnemonics
Signed-off-by: Michael Neuling
---
It's friday afternoon & I'm drinking beer, so odds are that these
patches are complete crap.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://o
From: Milton Miller
powerpc: Enable CPU feature sections for inline asm
This adds the ability to do CPU feature sections for inline asm.
Signed-off-by: Milton Miller
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/feature-fixups.h | 25 -
1 file changed
On Thursday 23 April 2009, Arnav Das wrote:
> i am a newbie
Lesson #1: make sure your Subject: lines match the message
topic (I did a partial repair) and don't post to the wrong
list (e.g. PPC lists for OMAP questions).
> and am doing a project on beagle board(running
> omap3530). i am interfa
Thank Scott and Timur!
Scott Wood wrote:
Timur Tabi (CCed) has written an audio
driver that does something very similar; he could probably tell you more
about how to do that (this is why such discussions should be kept on the
mailing list rather than taken to private e-mail).
The code
On Fri, Apr 24, 2009 at 01:04:53AM +0100, Freeman Wiser wrote:
> Hey I saw that Jim installed Fedora on the 275, can you tell me how? I just
> bought one of the 275s and am not really ibm savvy, and was going to sell it
> when I came across Jim's post here:
>
> http://lists.infradead.org/pipermai
On Thursday 23 April 2009, Valentine Barshak wrote:
> Some U-Boot versions incorrectly set the number of chipselects to two
> for Sequoia/Rainier boards while they only have one chipselect hardwired.
> This patch adds a workaround for this, hardcoding the number of chipselects
> to one for sequioa/
On Thu, 2009-04-23 at 11:49 -0500, Scott Wood wrote:
> On Thu, Apr 23, 2009 at 11:31:37AM +1000, Michael Ellerman wrote:
> > + handler = desc->handler;
>
> Should be desc->handle_irq. It's fixed in a later patch, but this breaks
> bisect.
Ah crud, thanks for spotting it. That's an artifact of
Hi
i am a newbie and am doing a project on beagle board(running
omap3530). i am interfacing an adc(ads7886) to the beagleboard via
spi. need to know how the spi works and how a module can access the
spi registers of the omap. if someones already made an adc driver can
they mail me?
thanks
arnav
Hey I saw that Jim installed Fedora on the 275, can you tell me how? I just
bought one of the 275s and am not really ibm savvy, and was going to sell it
when I came across Jim's post here:
http://lists.infradead.org/pipermail/fedora-ppc/2008-November/001114.html
Geoff Levand recommended postin
Hello,
I am working with a MPC8265 processor for which I am compiling a
Kernel using LTIB. I just came to a point in my project in which I need
an additional serial port to interface my CPU with a FPGA. Since my
UTOPIA interface is using several serial ports -pins, the only option
that I find
Kumar Gala wrote:
>
> On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
>
>> I have found the culprit - in arch/powerpc/kernel/pci_32.c
>>
>> static void
>> fixup_hide_host_resource_fsl(struct pci_dev *dev)
>> {
>> int i, class = dev->class >> 8;
>>
>> #if 0
>> if ((class == PCI_CLASS_PROCE
On Thu, Apr 23, 2009 at 04:56:56PM -0500, Mike Wolf wrote:
> On Thu, 2009-04-23 at 12:52 -0500, Olof Johansson wrote:
> > On Wed, Apr 22, 2009 at 06:40:12PM -0500, Mike Wolf wrote:
> > > Resending. the patch was munged last time.
> > >
> > >
> > > Oprofile is changing the naming it is using for
On Thu, 2009-04-23 at 12:52 -0500, Olof Johansson wrote:
> On Wed, Apr 22, 2009 at 06:40:12PM -0500, Mike Wolf wrote:
> > Resending. the patch was munged last time.
> >
> >
> > Oprofile is changing the naming it is using for the compatibility modes.
> > Instead of having compat-power, oprofile w
Some U-Boot versions incorrectly set the number of chipselects to two
for Sequoia/Rainier boards while they only have one chipselect hardwired.
This patch adds a workaround for this, hardcoding the number of chipselects
to one for sequioa/rainer board models and reading the actual value from
the me
Josh Boyer wrote:
> On Fri, Apr 24, 2009 at 12:04:39AM +0400, Valentine wrote:
>> Thanks Steven,
>> Yes, both patches have to be applied.
>> Sorry, I missed a trailing space in the comment.
>> I'll resubmit another one in a bit.
>> Thanks,
>> Val.
>
> Could you roll both patches into one, and incl
On Fri, Apr 24, 2009 at 12:04:39AM +0400, Valentine wrote:
> Thanks Steven,
> Yes, both patches have to be applied.
> Sorry, I missed a trailing space in the comment.
> I'll resubmit another one in a bit.
> Thanks,
> Val.
Could you roll both patches into one, and include Steven's signed-off-by? T
Thanks Steven,
Yes, both patches have to be applied.
Sorry, I missed a trailing space in the comment.
I'll resubmit another one in a bit.
Thanks,
Val.
Steven A. Falco wrote:
Thanks for doing this so quickly!
I applied your patch plus my patch - my custom board reports
the correct memory size.
On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
I have found the culprit - in arch/powerpc/kernel/pci_32.c
static void
fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
#if 0
if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
class == P
On Apr 23, 2009, at 7:54 AM, Martyn Welch wrote:
Kumar Gala wrote:
Removed the need for asm/mpc86xx.h as it was only used in
mpc86xx_smp.c
and just moved the defines it cared about into there. Also fixed up
the ioremap to only map the one 4k page we need access to and to
iounmap
when we
Anton Vorontsov wrote:
This is exactly what we should try to avoid. We should not accept
any changes that might break older firmwares. That is, keep the
device tree workable with X1 and X2, by any means.
I think that's a much bigger restriction than trying to keep the kernel
compatible with ol
On Wed, Apr 22, 2009 at 06:40:12PM -0500, Mike Wolf wrote:
> Resending. the patch was munged last time.
>
>
> Oprofile is changing the naming it is using for the compatibility modes.
> Instead of having compat-power, oprofile will go to family naming
> convention and use compat-v. Currently onl
Valentine Barshak wrote:
> Some U-Boot versions incorrectly set the number of chipselects to two
> for Sequoia/Rainier boards while they only have one chipselect hardwired.
> This patch adds a workaround for this, hardcoding the number of chipselects
> to one for sequioa/rainer board models and rea
On Thu, Apr 23, 2009 at 12:03:06PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
>>> Even if the given change may not break the firmware, it could force an
>>> update in which a prior change breaks the firmware.
>>
>> I'm not sure I
Am 23.04.09 02:05 schrieb(en) Grant Likely:
http://patchwork.ozlabs.org/patch/24487/
That patch is already included in 2.6.29...
No, that's not the problem in this case. 2.6.29 networking is broken
for a lot of platforms, not just mpc5200. Use 2.6.29.1 instead.
...and with 2.6.29.1, ever
Some U-Boot versions incorrectly set the number of chipselects to two
for Sequoia/Rainier boards while they only have one chipselect hardwired.
This patch adds a workaround for this, hardcoding the number of chipselects
to one for sequioa/rainer board models and reading the actual value from
the me
Anton Vorontsov wrote:
On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
Even if the given change may not break the firmware, it could force an
update in which a prior change breaks the firmware.
I'm not sure I'm following here. Could you give an example?
1. U-boot X1 is used with
On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
> On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
> > As for Freescale parts, all the reference board I've seen were
> > very friendly wrt upgrading their device-trees, i.e. none of
> > the boards were shipping with device
On Thu, Apr 23, 2009 at 11:31:37AM +1000, Michael Ellerman wrote:
> + handler = desc->handler;
Should be desc->handle_irq. It's fixed in a later patch, but this breaks
bisect.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozl
On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
> As for Freescale parts, all the reference board I've seen were
> very friendly wrt upgrading their device-trees, i.e. none of
> the boards were shipping with device-tree soldered into the
> firmware.
But many of them have broken wh
Valentine Barshak wrote:
>
> Josh Boyer wrote:
>> On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
>>> Stefan Roese wrote:
On Thursday 23 April 2009, Josh Boyer wrote:
> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>> There is an error in the way
On Wed, Apr 22, 2009 at 10:36:36PM -0500, Kumar Gala wrote:
> I think this all sounds great in theory but in reality the vast
> majority (I'd say over 80-90%) we are talking about embedded reference
> boards.
I've handled plenty of support e-mails from people using custom 82xx
boards with devi
Hello Kumar,
Kumar Gala wrote:
>> diff --git a/arch/powerpc/boot/dts/kmeter1.dts
>> b/arch/powerpc/boot/dts/kmeter1.dts
>> new file mode 100644
>> index 000..4f343ca
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/kmeter1.dts
>> @@ -0,0 +1,518 @@
>> +/*
>> + * Keymile KMETER1 Device Tree Sourc
Stefan Roese wrote:
On Thursday 23 April 2009, Josh Boyer wrote:
On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
There is an error in the way ibm4xx_denali_fixup_memsize calculates
memory size. When testing the DDR_REDUC bit, the polarity is
backwards. A "1" implies 32-bit wi
Josh Boyer wrote:
On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
Stefan Roese wrote:
On Thursday 23 April 2009, Josh Boyer wrote:
On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
There is an error in the way ibm4xx_denali_fixup_memsize calculates
memory siz
On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
> Stefan Roese wrote:
>> On Thursday 23 April 2009, Josh Boyer wrote:
>>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
There is an error in the way ibm4xx_denali_fixup_memsize calculates
memory size. W
diff --git a/arch/powerpc/boot/dts/kmeter1.dts b/arch/powerpc/boot/
dts/kmeter1.dts
new file mode 100644
index 000..4f343ca
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmeter1.dts
@@ -0,0 +1,518 @@
+/*
+ * Keymile KMETER1 Device Tree Source
+ *
+ * 2008 DENX Software Engineering GmbH
+ *
+ *
Kumar Gala wrote:
>
> On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote:
>
>> Kumar Gala wrote:
>>>
>>> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>>>
I found the difference - in 2.6.28 the inbound/outbound windows
don't seem to be set up at all. In 2.6.26, the function
'fs
On Wednesday 22 April 2009, Kumar Gala wrote:
First of all, thanks for bringing this up, I'd love to see get_immrbase() gone.
> arch/powerpc/sysdev/cpm1.c: mpc8xx_immr = ioremap(get_immrbase(),
> 0x4000);
> not sure? ideas?
Nobody has commented on this, so I've taken a brief look a
On Thu, Apr 23, 2009 at 09:02:49AM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> > And note that most developers are using up-to-date firmwares
> > (U-Boots), device trees, and kernels.
>
> Developers? Yes.
> End-users? No.
If end-users upgraded the kernel on some FSL board, then there
Kumar Gala wrote:
> when? I'm not aware of any significant # of cases that customer is
> willing to update kernel & not dts. Usually if they are willing to
> update kernel they tend to be willing to update everything.
Well, now that you ask, I can't give you specifics, because I don't
remem
On Apr 23, 2009, at 9:02 AM, Timur Tabi wrote:
We've run into plenty of situations where customers will update the
kernel, but insist that U-Boot and the device tree remain unchanged.
when? I'm not aware of any significant # of cases that customer is
willing to update kernel & not dts. Us
On Thursday 23 April 2009, Josh Boyer wrote:
> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
> >There is an error in the way ibm4xx_denali_fixup_memsize calculates
> >memory size. When testing the DDR_REDUC bit, the polarity is
> >backwards. A "1" implies 32-bit wide memory whi
On Thu, Apr 23, 2009 at 07:53:11AM -0600, Grant Likely wrote:
> On Wed, Apr 22, 2009 at 3:31 PM, Kumar Gala wrote:
> >
> > On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
> >
> >> Scott Wood wrote:
> >>>
> >>> Timur Tabi wrote:
> >
> > these two are related and seem like we could look
Anton Vorontsov wrote:
> And note that most developers are using up-to-date firmwares
> (U-Boots), device trees, and kernels.
Developers? Yes.
End-users? No.
Updating U-Boot itself is often unacceptable for end-users. There's
also a strong connection between U-Boot and the device tree. That
c
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/include/asm/mmu.h|6 --
arch/powerpc/include/asm/ppc-opcode.h | 11 +--
arch/powerpc/kernel/cputable.c|
On Apr 23, 2009, at 7:56 AM, Stephen Rothwell wrote:
Previous gcc versions didn't notice this because one of the preceding
#ifs always evaluated to true.
gcc 4.4.0 produced this error:
arch/powerpc/mm/tlb_nohash_low.S:206:6: error: #elif with no
expression
Signed-off-by: Stephen Rothwell
On Wed, Apr 22, 2009 at 3:39 PM, Kumar Gala wrote:
>
> On Apr 22, 2009, at 4:33 PM, Timur Tabi wrote:
>
>> Kumar Gala wrote:
>>
>>> I disagree. If you update your kernel you should update your device
>>> tree (thus we have .dts in the kernel tree and not somewhere else).
>>
>> Is this a new polic
On Wed, Apr 22, 2009 at 3:31 PM, Kumar Gala wrote:
>
> On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
>
>> Scott Wood wrote:
>>>
>>> Timur Tabi wrote:
>
> these two are related and seem like we could look for "fsl,cpm2"
That's okay, as long as you don't break compatibility w
This reverts commit e9965577406a2148ade97b5e0ce7c448b4ba4ef6. Our HW
guys were able to fix this so it never sees the light of day.
Signed-off-by: Kumar Gala
---
arch/powerpc/include/asm/mmu.h|6 --
arch/powerpc/include/asm/ppc-opcode.h | 11 +--
arch/powerpc/kernel/cpu
On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote:
> David Gibson wrote:
>
> > It's not so much point of view as situation. Putting the device tree
> > in the firmware and putting the device tree in the kernel are both
> > valid choices, with their own distinct advantages and drawbacks.
On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>There is an error in the way ibm4xx_denali_fixup_memsize calculates
>memory size. When testing the DDR_REDUC bit, the polarity is
>backwards. A "1" implies 32-bit wide memory while a "0" implies
>64-bit wide memory.
>
>For a 32-bit
There is an error in the way ibm4xx_denali_fixup_memsize calculates
memory size. When testing the DDR_REDUC bit, the polarity is
backwards. A "1" implies 32-bit wide memory while a "0" implies
64-bit wide memory.
For a 32-bit wide system, this bug causes twice the memory to be
reported, leading
Kumar Gala wrote:
> Until we meet the most basic level of properly describing 95% of the
> HW I don't see the value you guys prescribe to FW compatibility.
> Additionally I believe for embedded developers its perfectly
> reasonable to expect them (if they are using u-boot) to possibly have
David Gibson wrote:
> It's not so much point of view as situation. Putting the device tree
> in the firmware and putting the device tree in the kernel are both
> valid choices, with their own distinct advantages and drawbacks.
I was under the impression that the reason we put the device trees i
Previous gcc versions didn't notice this because one of the preceding
#ifs always evaluated to true.
gcc 4.4.0 produced this error:
arch/powerpc/mm/tlb_nohash_low.S:206:6: error: #elif with no expression
Signed-off-by: Stephen Rothwell
Acked-by: Josh Boyer
---
arch/powerpc/mm/tlb_nohash_low.S
Kumar Gala wrote:
Removed the need for asm/mpc86xx.h as it was only used in mpc86xx_smp.c
and just moved the defines it cared about into there. Also fixed up
the ioremap to only map the one 4k page we need access to and to iounmap
when we are done.
Signed-off-by: Kumar Gala
---
arch/powerpc/i
On Thursday 23 April 2009, Michael Ellerman wrote:
> Currently PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but does not
> select PCI. This can lead to a config with the former and the latter
> disabled, which does not build.
>
> To fix this PPC_CELL_NATIVE should select PCI. However, that would
>
On Thu, Apr 23, 2009 at 04:06:56PM +1000, Stephen Rothwell wrote:
>Hi all,
>
>[I am now using gcc version 4.4.0 ...]
>
>Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
>arch/powerpc/mm/tlb_nohash_low.S:206:6: error: #elif with no expression
>
>Previous gcc versions didn't no
Hi Paul,
On Wed, 22 Apr 2009 22:56:52 +1000, Paul Mackerras wrote:
> Jean Delvare writes:
> > We're past -rc3 because people discuss instead of testing my patches.
> > Otherwise everything would be merged already.
>
> Well, no. The first conversion patch that I saw was posted after the
> merge w
Currently PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but does not
select PCI. This can lead to a config with the former and the latter
disabled, which does not build.
To fix this PPC_CELL_NATIVE should select PCI. However, that would
force PCI on for QPACE, which also selects PPC_CELL_NATIVE. So
On Thu, 23 Apr 2009, Michael Ellerman wrote:
> On Wed, 2009-04-22 at 20:15 -0700, Randy Dunlap wrote:
> > Michael Ellerman wrote:
> > > On Wed, 2009-04-22 at 21:46 +0530, Subrata Modak wrote:
> > >> On Wed, 2009-04-22 at 00:20 +0530, Subrata Modak wrote:
> > >>> Reported this earlier on 14th April
The following series implements basic board support for
the kmeter1 board from keymile, based on a MPC8360.
This series provides the following functionality:
- The board can boot with a serial console on UART1
- Ethernet:
UCC1 in RGMII mode
UCC2 in RGMII mode
UCC4 in RMII mode
UCC
64 matches
Mail list logo
