Creates P1020si.dtsi, containing information for the P1020 SoC. Modifies dts
files for P1020 based systems to use dtsi file.
Signed-off-by: Prabhakar Kushwaha
Acked-by: Kumar Gala
---
Based upon
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch
master)
Please see m
Some of the 64bit PPC CPU features are MMU-related, so this patch moves
them to MMU_FTR_ bits. All cpu_has_feature()-style tests are moved to
mmu_has_feature(), and seven feature bits are freed as a result.
Signed-off-by: Matt Evans
---
Boot-tested on pseries and G5.
arch/powerpc/include/asm/c
Hi Leon,
Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
In order to work in legacy mode, IDSEL entries are required.
--Prabhakar
> -Original Message-
> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
> Reading the MPC8536E Chip Errata I saw the SDHC_WP signal polarity is
> reversed to the silicon revision 1.0.
>
> Unfortunately my prototype board is using revision 1.0. So, I asked to
> my hardware team workaround putting an extra inverter for the SDHC_WP
> signal.
>
> Now its working fine!
> > Doesn't that mean that power_pmu_read() can only ever increase the value of
> > the perf_event and so will essentially -stop- once the counter rolls over ?
> >
> > Similar comments every where you do this type of comparison.
> >
> > Cheers,
> > Ben.
>
> Sorry for the nag, but am I missing s
This removes MMU_FTR_TLBIE_206 as we can now use CPU_FTR_HVMODE_206. It
also changes the logic to select which tlbie to use to be based on this
new CPU feature bit.
This also duplicates the ASM_FTR_IF/SET/CLR defines for CPU features
(copied from MMU features).
Signed-off-by: Michael Neuling
--
On Wed, 2011-04-06 at 15:50 -0700, Richard A Lary wrote:
> From: Richard A. Lary
>
> Added support for ibm,configure-pe RTAS call introduced with
> PAPR 2.2.
Care to tell us a bit about the difference ? :-) There's nothing obvious
in the code Also you added calls to rtas_configure_bridge() a
From: Richard A. Lary
Added support for ibm,configure-pe RTAS call introduced with
PAPR 2.2.
Signed-off-by: Richard A. Lary
---
arch/powerpc/platforms/pseries/eeh.c | 1312 +1 - 0 !
1 file changed, 12 insertions(+), 1 deletion(-)
Index: b/arch/powerpc/platforms/pseries/eeh.c
==
Wolfram,
Reading the MPC8536E Chip Errata I saw the SDHC_WP signal polarity is
reversed to the silicon revision 1.0.
Unfortunately my prototype board is using revision 1.0. So, I asked to
my hardware team workaround putting an extra inverter for the SDHC_WP
signal.
Now its working fine!
Thank
On Wed, Apr 06, 2011 at 01:29:05PM -0700, Chuck Ketcham wrote:
> Ira,
>
> Thanks for the reference to the CARMA drivers. I will have to take a look at
> that.
>
> In my case, CONFIG_NET_DMA is not enabled. However, I did notice the
> following entry in my p2020rdb.dts file that may have somet
On Thu, 31 Mar 2011, Benjamin Herrenschmidt wrote:
> On Wed, 2011-03-30 at 14:36 -0400, Eric B Munson wrote:
> > On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote:
> >
> > > On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote:
> > > > Here I made the assumption that the hardware would never re
Hi Leon,
On 04/06/2011 11:58 PM, Leon Woestenberg wrote:
Hello Felix,
On Wed, Apr 6, 2011 at 10:49 PM, Felix Radensky wrote:
I think there's a hardware problem with mini PCI-E slot
on P2020RDB related to legacy IRQ routing. See this
thread for details
http://www.mail-archive.com/linuxppc-dev@
Hello Felix,
On Wed, Apr 6, 2011 at 10:49 PM, Felix Radensky wrote:
> I think there's a hardware problem with mini PCI-E slot
> on P2020RDB related to legacy IRQ routing. See this
> thread for details
> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40037.html
>
Thanks for the heads
Hi Leon,
I think there's a hardware problem with mini PCI-E slot
on P2020RDB related to legacy IRQ routing. See this
thread for details
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40037.html
You may have better luck with PCI-E slot and mini PCI-E to
PCI-E adapter.
Felix.
__
On Wed, Apr 06, 2011 at 06:46:55PM +1000, Dave Airlie wrote:
> 2011/4/6 Uwe Kleine-König :
> > Hi Gabriel,
> >
> > On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
> >> I've had the following funny crashes on PPC machines, with
> >> cataleptic X server as a consequence:
> >>
> >> ke
Ira,
Thanks for the reference to the CARMA drivers. I will have to take a look at
that.
In my case, CONFIG_NET_DMA is not enabled. However, I did notice the following
entry in my p2020rdb.dts file that may have something to do with dma channels
being allocated -- can anyone interpret this?:
On Wed, Apr 06, 2011 at 12:40:58PM -0700, Chuck Ketcham wrote:
> All,
>
> I have a Freescale P2020 Reference Design Board. I am investigating the
> possibility of using the dmaengine capability in the 2.6.32.13 kernel to
> transfer data from memory out onto the PCIe bus. As a first step, I tho
All,
I have a Freescale P2020 Reference Design Board. I am investigating the
possibility of using the dmaengine capability in the 2.6.32.13 kernel to
transfer data from memory out onto the PCIe bus. As a first step, I thought I
would try the DMA test client (dmatest.ko) to make sure the dmaen
Hello Jeff, all,
On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik wrote:
> On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
>> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
>>> after investigating problems with sata_sil24.c on a freescale p2020
>>> soc, I wonder if this driver works on powerpc at a
On Tue, 5 Apr 2011 16:35:10 -0700
Barry G wrote:
> I want to run UBIFS on the combined 2 gigs of flash. Whats the best
> way to do this?
>
> I tried using the mtdconcat stuff and wrote a small driver
> but I am not sure how to populate the mtd_info structure since do_probe_map
> doesn't work wi
On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
> after investigating problems with sata_sil24.c on a freescale p2020
> soc, I wonder if this driver works on powerpc at all?
>
> Does anyone know of a working setup of sata_sil24 on a big endian
> powerpc system?
Our P2020 boards work fine with
On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
after investigating problems with sata_sil24.c on a freescale p2020
soc, I wonder if this driver works on powerpc at all?
Does anyone know of a working setup of sata_sil24 on a big endian
powerpc s
On Wed, 6 Apr 2011 07:29:03 -0500
Kumar Gala wrote:
> diff --git a/arch/powerpc/include/asm/cputable.h
> b/arch/powerpc/include/asm/cputable.h
> index be3cdf9..9028a9e 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -386,6 +386,10 @@ extern con
I will try address the issue in details.
When I insert the SDCard, the same is detect like read-only:
mmcblk0: mmc0:b368 NCard 966 MiB (ro)
mmcblk0:
mmc0: starting CMD18 arg flags 00b5
mmc0: blksz 512 blocks 8 flags 0200 tsac 100 ms nsac 0
mmc0: CMD12 arg flags 0
Fix possible problem with mport registration left non cleared after
fsl_rio_setup() exits on link error. Abort mport initialization
if registration failed.
This patch is applicable to 2.6.39-rc1 only. The problem does not exists
for earlier versions.
Signed-off-by: Alexandre Bounine
Cc: Kumar Ga
Hello,
after investigating problems with sata_sil24.c on a freescale p2020
soc, I wonder if this driver works on powerpc at all?
Does anyone know of a working setup of sata_sil24 on a big endian
powerpc system?
Regards,
--
Leon
___
Linuxppc-dev mailin
On Wed, Apr 6, 2011 at 9:03 AM, Scott Wood wrote:
> On Wed, 6 Apr 2011 08:07:58 -0700
> Justin Mattock wrote:
>
>> ahh.. so the: fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use
>> even though FSL_85XX_CACHE_SRAM is not really used, but really is used!!
>>
>> but might be wrong with this.
On Wed, 6 Apr 2011 08:07:58 -0700
Justin Mattock wrote:
> ahh.. so the: fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use
> even though FSL_85XX_CACHE_SRAM is not really used, but really is used!!
>
> but might be wrong with this.
More like there are plans to use it, or possibly out-of-t
On Tue, Apr 5, 2011 at 11:15 AM, Scott Wood wrote:
> On Tue, 5 Apr 2011 09:58:19 -0700
> "Justin P. Mattock" wrote:
>
>> The patch below removes an unused config variable found by using a kernel
>> cleanup script.
>> Note: I did try to cross compile these but hit erros while doing so..
>> (gcc is
Signed-off-by: Alexandre Bounine
Cc: Matt Porter
Cc: Kumar Gala
---
drivers/rapidio/switches/idt_gen2.c |1 +
include/linux/rio_ids.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/rapidio/switches/idt_gen2.c
b/drivers/rapidio/switches/idt_gen
Hi Andreas -
that's great; thanks. I'm on 2.4.4, which doesn't have BUG_ON. The right
way for 2.4.4 turns out to be
#define MY_ASSERT(expr) if(!(expr)) BUG()
-Evan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/
Signed-off-by: Kumar Gala
---
arch/powerpc/include/asm/cputable.h |4 ++-
arch/powerpc/kernel/exceptions-64e.S | 65 --
arch/powerpc/kernel/setup_64.c |8
3 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm
The CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS defines did not encompass
e5500 CPU features when built for 64-bit. This causes issues with
cpu_has_feature() as it utilizes the POSSIBLE & ALWAYS defines as part
of its check.
Create a unique CPU_FTRS_E5500 (as its different from CPU_FTRS_E500MC),
create
On Apr 6, 2011, at 12:41 AM, Stephen Rothwell wrote:
> Hi Kumar,
>
> On Wed, 6 Apr 2011 00:29:32 -0500 Kumar Gala
> wrote:
>>
>> * I'm concerned if its ok to assume 'enum' can handle a 64-bit mask or not.
>> I'm assuming this is the reason that we use a #define on __powerpc64__
>
> enums a
On Wed, 2011-04-06 at 11:07 +0200, Michal Marek wrote:
> > So additionally, I'd suggest:
> > 1. Instrument checkpatch.pl and make it err or warn on timestamps.
>
> This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198
Yeah, great, did not notice, thanks!
> > 2. Probably instrume
On 5.4.2011 17:49, Greg KH wrote:
> Very nice stuff. Do you want to take the individual patches through one
> of your trees, or do you mind if the subsystem maintainers take them
> through theirs?
I'd leave it up to the subsystem maintainers. I'll check once the merge
window opens and send the re
On 5.4.2011 21:24, Artem Bityutskiy wrote:
> On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
>> On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
>>>
>>> Hi,
>>>
>>> this series makes it possible to build bit-identical kernel image and
>>> modules from identical sources. Of course the
* Michal Marek wrote:
>
> Hi,
>
> this series makes it possible to build bit-identical kernel image and
> modules from identical sources. Of course the build is already
> deterministic in terms of behavior of the code, but the various
> timestamps embedded in the object files make it hard to c
* Artem Bityutskiy wrote:
> On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
> > On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
> > >
> > > Hi,
> > >
> > > this series makes it possible to build bit-identical kernel image and
> > > modules from identical sources. Of course the
2011/4/6 Uwe Kleine-König :
> Hi Gabriel,
>
> On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
>> I've had the following funny crashes on PPC machines, with
>> cataleptic X server as a consequence:
>>
>> kernel: [drm] Setting GART location based on new memory map
>> kernel: Oops: Ex
Hi Gabriel,
On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
> I've had the following funny crashes on PPC machines, with
> cataleptic X server as a consequence:
>
> kernel: [drm] Setting GART location based on new memory map
> kernel: Oops: Exception in kernel mode, sig: 4 [#1]
>
serial port nodes with the property status="disabled" are not usable and so
avoid adding "disabled" port with the system.
Signed-off-by: Prabhakar Kushwaha
---
Based upon
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch
master)
This patch is made to support "Re-or
42 matches
Mail list logo
