* Bogdan Purcareata | 2015-04-24 15:53:11 [+]:
>0001: converts the openpic spinlock to a raw spinlock, in order to circumvent
>0002: disables in-kernel MPIC emulation for guest running on RT, in order to
Scott, I'm asking here for your explicit Acked-by on those two patches.
That you want it
* Bogdan Purcareata | 2015-04-24 15:53:13 [+]:
>While converting the openpic emulation code to use a raw_spinlock_t enables
>guests to run on RT, there's still a performance issue. For interrupts sent in
>Signed-off-by: Bogdan Purcareata
Applied with Scott's Acked-by
Sebastian
On 10/31/2014 09:12 AM, Johannes Thumshirn wrote:
> On Thu, Oct 30, 2014 at 02:51:57PM +1100, Michael Ellerman wrote:
>> Why would you not use MSI-X ?
If I'm not mistaken, a PCI-E requirement is to support MSI but MSI-X is
optional. And with MSI you can have multiple interrupts per single
device (
On 11/03/2014 11:18 PM, Scott Wood wrote:
> Is it really necessary for the virqs to be contiguous? How is the
> availability of multiple MSIs communicated to the driver? Is there an
> example of a driver that currently uses multiple MSIs?
I used this in PCI and after enabling 2^x, I allocated an
On Mon, May 27, 2013 at 01:00:17PM +0530, Priyanka Jain wrote:
> While returning from exception handling in case of PREEMPT enabled,
> _TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of current
> task. Only if this bit is set, it should continue with the process of
> calling preempt
On 06/12/2013 02:47 PM, Oded Gabbay wrote:
> This patch fixes a bug in the fsl_pq_mdio.c module and in relevant device-tree
> files regarding the correct offset of the tbipa register in the eTSEC
> controller in some of Freescale's PQ3 and QorIQ SoC.
> The bug happens when the mdio in the device tr
On 06/21/2013 02:52 AM, Santosh Shilimkar wrote:
> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
> index 0a2c68f..62e2e8f 100644
> --- a/arch/microblaze/kernel/prom.c
> +++ b/arch/microblaze/kernel/prom.c
> @@ -136,8 +136,7 @@ void __init early_init_devtree(void *params
On 06/27/2013 10:54 PM, Rob Herring wrote:
>> Rob,
>> Are you ok with phys_addr_t since your concern was about rest
>> of the memory specific bits of the device-tree code use u64 ?
>
> No. I still think it should be u64 for same reasons I said originally.
The physical address space is represente
On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>
> Sebastian,
>
> Apart from waste of 32bit, what is the other concern you
> have ?
You pass a u64 as a physical address which is represented in other
parts of the kernel (for a good reason) by phys_addr_t.
> I really want to converge on this pa
On 07/01/2013 09:59 AM, Geert Uytterhoeven wrote:
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
And I think the DT code should check if the u64 fits in phys_addr_t and
if does not it should write an error messa
l2irq to l1irq since this is
the number that is evaluated.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
b/arch/powerpc/platforms/52xx/mpc5
From: Thomas Gleixner
These low level handlers cannot be threaded. Mark them NO_THREAD
Reported-by: leroy christophe
Tested-by: leroy christophe
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
This patch has been posted on Feb 13, 2013 and nobody responded back
irq since it was
not in the case statement? l2 holds the number, l1 the level.
> Signed-off-by: Wolfram Sang
> Cc: Sebastian Andrzej Siewior
> Cc: Anatolij Gustschin
> ---
>
> Have I been on CC when the original patch was sent?
You were but your email bounced. I wasn't aw
On 10/01/2013 11:11 AM, Wolfram Sang wrote:
> Hi,
Hi Wolfram,
> Well, if you insist, I'd prefer the following patch.
>
> From: Wolfram Sang Subject: [PATCH] ppc:
> mpc52xx: silence false positive from old GCC
>
> So people can compile with -Werror (RT patchset).
Why do you mention the RT patc
On 10/01/2013 09:03 PM, Wolfram Sang wrote:
>
> Yup. But I just remembered a better solution:
>
> From: Wolfram Sang Subject: [PATCH] ppc:
> mpc52xx: silence false positive from old GCC
>
> So people can compile with -Werror.
>
> Signed-off-by: Wolfram Sang ---
> arch/powerpc/platforms/52xx/
printout) needs revert, too. We want to know WHICH critical irq failed,
> not which level it had.
>
> Signed-off-by: Wolfram Sang
> Cc: Sebastian Andrzej Siewior
> Cc: Anatolij Gustschin
Acked-by: Sebastian Andrzej Siewior
Sebastian
___
On 01/04/2013 05:42 AM, Benjamin Herrenschmidt wrote:
On Tue, 2012-12-11 at 11:18 +0530, Suzuki K. Poulose wrote:
On 12/03/2012 08:37 PM, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose
External/Decrement exceptions have lower priority than the Debug Exception.
So, we don't have to disable th
lockdep thinks that it might deadlock because it grabs a lock of the
same class while calling the generic_irq_handler(). This annotation will
inform lockdep that it will not.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/sysdev/fsl_msi.c |4 +++-
1 files changed, 3 insertions
* Hong H. Pham | 2013-12-07 09:06:33 [-0500]:
>On PPC32, only SMP kernels are affected.
>
>On PPC64, only SMP kernels with 4K page size are affected.
$ uname -a
Linux mpc8536-1 3.12.1-rt3-00281-g9de268d #76 SMP PREEMPT RT Fri Nov 22
16:53:05 CET 2013 ppc GNU/Linux
$ uptime
22:01:10 up 22 days,
If CONFIG_UCC_GETH or CONFIG_SERIAL_QE is not defined then we get a
warning about an used variable which leads to a build error.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch
powerpc uses early_init_dt_scan_chosen() from common fdt code. By
enabling this option, the common code can take the built in
command line over the one that is comming from bootloader / DT.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/Kconfig | 9 +
1 file changed, 9
sed on irq_create_mapping() but due to the
number argument there is very little in common now.
Cc: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/irqdomain.h | 2 ++
kernel/irq/irqdomain.c| 61 +++
2 files chang
This series adds support for multiple MSI interrupts on FSL's MPIC. The
code has been tested on v3.2 with custom FPGA device on PCIe and then
forward ported. Patch #1 has been created from scratch during porting,
patch #2 almost applied as-it.
Sebastian
___
od
Cc: Minghuan Lian
Cc: Kumar Gala
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/kernel/msi.c | 4
arch/powerpc/platforms/cell/axon_msi.c | 3 +++
arch/powerpc/platforms/powernv/pci.c | 2 ++
arch/powerpc/platforms/pseries/msi.c | 3 +++
arch/powerpc/pla
On 02/20/2014 10:06 PM, Scott Wood wrote:
> On Thu, 2014-02-20 at 21:53 +0100, Sebastian Andrzej Siewior wrote:
>> A MSI device may have multiple interrupts. That means that the
>> interrupts numbers should be continuos so that pdev->irq refers to the
>> first interru
sed on irq_create_mapping() but due to the
number argument there is very little in common now.
Cc: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
Scott, this is what you suggested. I must admit, it does not look that
bad. It is just compile tested.
v1.v2:
- use irq_create_mapping
On 02/18/2015 10:32 AM, Bogdan Purcareata wrote:
> Due to the introduction of the raw_spinlock for the KVM openpic, guests with a
> high number of VCPUs may induce great latencies on the underlying RT Linux
> system (e.g. cyclictest reports latencies of ~15ms for guests with 24 VCPUs).
> This can b
On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
>> Thomas, what is the usual approach for patches like this? Do you take
>> them into your rt tree or should they get integrated to upstream?
>
> Patch 1 is definitely suitable for upstream, that's the reason why we
> have raw_spin_lock vs. raw_spin_unl
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
>
>
> On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote:
>> Usually you see "scheduling while atomic" on -RT and convert them to
>> raw locks if it is appropriate.
>>
>> Bogdan wrote in 2/2 that he needs
On 02/20/2015 04:10 PM, Paolo Bonzini wrote:
> On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote:
>> On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
>
>>> Yes, but large latencies just mean the code has to be rewritten (x86
>>> doesn't anymore do event injecti
* Scott Wood | 2015-02-23 17:27:31 [-0600]:
>This isn't a host PIC driver. It's guest PIC emulation, some of which
>is indeed not suitable for a rawlock (in particular, openpic_update_irq
>which loops on the number of vcpus, with a loop body that calls
>IRQ_check() which loops over all pending IR
On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
>
>
> On 24/02/2015 00:27, Scott Wood wrote:
>> This isn't a host PIC driver. It's guest PIC emulation, some of which
>> is indeed not suitable for a rawlock (in particular, openpic_update_irq
>> which loops on the number of vcpus, with a loop body th
(). So now we have a put_cpu_var() which does
a preempt_enable() and nothing that does preempt_disable() so we
underflow the preempt counter.
Cc: Benjamin Herrenschmidt
Cc: Christoph Lameter
Cc: Michael Ellerman
Cc: Tiejun Chen
Cc:
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/
On 03/08/2016 12:41 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2016-03-07 at 21:04 +0530, Aneesh Kumar K.V wrote:
>> Sebastian Andrzej Siewior writes:
>>
>> While you are there, can you also fix the wrong indentation on line
>> 423
>> ?
>
> .../...
&g
(). So now we have a put_cpu_var() which does
a preempt_enable() and nothing that does preempt_disable() so we
underflow the preempt counter.
Cc: Benjamin Herrenschmidt
Cc: Christoph Lameter
Cc: Michael Ellerman
Cc:
Signed-off-by: Sebastian Andrzej Siewior
---
v1…v2: - use get_cpu_var() in
On 2016-03-10 01:04:24 [+0530], Aneesh Kumar K.V wrote:
> Sebastian Andrzej Siewior writes:
*ping*
http://patchwork.ozlabs.org/patch/593943/
> > [ text/plain ]
> > hugepd_free() used __get_cpu_var() once. Nothing ensured that the code
> > accessing the variable did not mi
On 03/30/2016 02:41 AM, Michael Ellerman wrote:
> The merge window just closed, I'm still recovering.
>
> I've got it in my fixes branch locally, I'll probably push that today to
> linux-next.
Thank you.
>
> cheers
>
Sebastian
___
Linuxppc-dev mailin
With qemu-system-ppc64le -machine pseries -smp 4 I get:
|# chrt 1 hackbench
|Running in process mode with 10 groups using 40 file descriptors each (== 400
tasks)
|Each sender will pass 100 messages of 100 bytes
| Oops: Exception in kernel mode, sig: 4 [#1]
| LE PAGE_SIZE=64K MMU=Hash PREEMPT SMP
On 2019-03-29 16:20:51 [+1100], Suraj Jitindar Singh wrote:
>
> Yeah the kernel must have used msgsndp which isn't implemented for TCG
> yet. We use doorbells in linux but only for threads which are on the
> same core.
It is msgsndp as per instruction decode.
> And when I try to construct a situ
On 2019-04-05 02:25:44 [+1000], Nicholas Piggin wrote:
> Sebastian, are you able to test if this patch solves your problem?
yes, it does.
Tested-by: Sebastian Andrzej Siewior
> Thanks,
> Nick
Sebastian
On 2020-03-18 21:43:09 [+0100], Thomas Gleixner wrote:
> --- a/arch/powerpc/platforms/ps3/device-init.c
> +++ b/arch/powerpc/platforms/ps3/device-init.c
> @@ -725,12 +728,12 @@ static int ps3_notification_read_write(s
> unsigned long flags;
> int res;
>
> - init_completion(&dev->d
On 2020-03-19 03:04:59 [-0700], Christoph Hellwig wrote:
> But I wonder how alive the whole PS3 support is to start with..
OtherOS can only be used on "old" PS3 which do not have have their
firmware upgraded past version 3.21, released April 1, 2010 [0].
It was not possible to install OtherOS on P
On 2020-03-19 22:36:57 [-0700], Davidlohr Bueso wrote:
> On Wed, 18 Mar 2020, Thomas Gleixner wrote:
>
> Right now I'm not sure what the proper fix should be.
I though that v2 has it fixed with the previous commit (acpi: Remove
header dependency). The kbot just reported that everything is fine.
L
On 2020-03-20 01:55:25 [-0700], Davidlohr Bueso wrote:
> Let the caller know if wake_up_process() was actually called or not;
> some users can use this information for ad-hoc. Of course returning
> true does not guarantee that wake_up_process() actually woke anything
> up.
Wouldn't it make sense t
On 2020-03-20 01:55:27 [-0700], Davidlohr Bueso wrote:
> diff --git a/include/linux/swait.h b/include/linux/swait.h
> index 73e06e9986d4..6e5b5d0e64fd 100644
> --- a/include/linux/swait.h
> +++ b/include/linux/swait.h
> @@ -39,7 +26,7 @@
> *sleeper state.
> *
> * - the !exclusive mode; b
chal Simek
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
---
arch/microblaze/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/microblaze/include/asm/uaccess.h
b/arch/microblaze/include/asm/uaccess.h
index a1f206b90753a..4916d5fbea5e3 100644
The following mini-series removes linux/mm.h from the asm/uaccess.h of
the individual architecture. The series has been compile tested with the
defconfig and additionally for ia64 with the "special" allmodconfig
supplied by the bot. The regular allmod for the architectures does not
compile (even wi
Cc: linux-hexa...@vger.kernel.org
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
---
arch/hexagon/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/hexagon/include/asm/uaccess.h
b/arch/hexagon/include/asm/uaccess.h
index 00cb38faad0c4..c10
c: linux-c...@vger.kernel.org
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
---
arch/csky/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/csky/include/asm/uaccess.h b/arch/csky/include/asm/uaccess.h
index eaa1c3403a424..abefa125b93cf 100644
--- a
eentime Hu
Cc: Vincent Chen
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
---
arch/nds32/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/nds32/include/asm/uaccess.h b/arch/nds32/include/asm/uaccess.h
index 8916ad9f9f139..3a9219f53ee0d 10
Fenghua Yu
Cc: linux-i...@vger.kernel.org
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
---
arch/ia64/include/asm/uaccess.h | 1 -
arch/ia64/kernel/process.c | 1 +
arch/ia64/mm/ioremap.c | 1 +
3 files changed, 2 insertions(+), 1 deletion(-)
diff --git a
Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Thomas Gleixner
[bigeasy: +Kconfig]
Signed-off-by: Sebastian Andrzej Siewior
---
v1…v2: Remove the changes to die.c
arch/powerpc/Kconfig | 2 +-
arch/powerpc/kernel/entry_32.S | 4
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Thomas Gleixner
[bigeasy: +Kconfig]
Signed-off-by: Sebastian Andrzej Siewior
---
v2…v3: Don't mention die.c changes in the description.
v1…v2: Remove the changes to die.c.
arch/powerpc/Kconfig | 2 +-
arch/po
I've been looking at phandle_cache and noticed the following: The raw
phandle value as generated by dtc starts at zero and is incremented by
one for each phandle entry. The qemu pSeries model is using Slof (which
is probably the same thing as used on real hardware) and this looks like
a poiner valu
On 2019-11-29 20:14:47 [-0600], Frank Rowand wrote:
> The hash used is based on the assumptions you noted, and as stated in the
> code, that phandle property values are in a contiguous range of 1..n
> (not starting from zero), which is what dtc generates.
>
> We knew that for systems that do not m
On 2019-12-03 10:56:35 [-0600], Rob Herring wrote:
> > Another possibility would be to make the cache be dependent
> > upon not CONFIG_PPC. It might be possible to disable the
> > cache with a minimal code change.
>
> I'd rather not do that.
>
> And yes, as mentioned earlier I don't like the com
On 2019-12-05 20:01:41 [-0600], Frank Rowand wrote:
> Is there a memory usage issue for the systems that led to this thread?
No, no memory issue led to this thread. I was just testing my patch and
I assumed that I did something wrong in the counting/lock drop/lock
acquire/allocate path because the
On 2019-12-19 11:41:21 [+0100], Jason A. Donenfeld wrote:
> Hi folks,
Hi,
so this should duct tape it:
diff --git a/arch/powerpc/kernel/dbell.c b/arch/powerpc/kernel/dbell.c
index f17ff1200eaae..ec044bdf362a1 100644
--- a/arch/powerpc/kernel/dbell.c
+++ b/arch/powerpc/kernel/dbell.c
@@ -60,16 +60
With CONFIG_QUICC_ENGINE enabled and CONFIG_UCC_GETH + CONFIG_SERIAL_QE
disabled we have an unused variable (np). The code won't compile with
-Werror.
Move the np variable to the block where it is actually used.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/platforms
I've been looking at usage of per-CPU variable cpu_hw_events in
arch/powerpc/perf/core-book3s.c.
power_pmu_enable() and power_pmu_disable() (pmu::pmu_enable() and
pmu::pmu_disable()) are accessing the variable and the callbacks are
invoked always with disabled interrupts.
power_pmu_event_init() (
On 2020-02-05 07:10:59 [+0530], maddy wrote:
> Yes, currently we dont have anything that prevents the timer
> callback to interrupt pmu::event_init. Nice catch. Thanks for
> pointing this out.
You are welcome.
> Looking at the code, per-cpu variable access are made to
> check for constraints and
* Pratyush Anand | 2011-08-30 17:27:50 [+0530]:
>diff --git a/drivers/usb/dwc/apmppc.c b/drivers/usb/dwc/apmppc.c
>new file mode 100644
>index 000..80ea274
>--- /dev/null
>+++ b/drivers/usb/dwc/apmppc.c
>@@ -0,0 +1,436 @@
>+/*
>+ * DesignWare HS OTG controller driver
>+ * Copyright (C) 2006 Sy
* Pratyush Anand | 2011-08-30 17:28:01 [+0530]:
>diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
>index 815efa2..32282b4 100644
>--- a/arch/arm/include/asm/io.h
>+++ b/arch/arm/include/asm/io.h
>@@ -297,6 +297,14 @@ extern int valid_mmap_phys_addr_range(unsigned long pfn,
>size
* Pratyush Anand | 2011-08-30 17:27:55 [+0530]:
>diff --git a/drivers/usb/dwc/pcd.c b/drivers/usb/dwc/pcd.c
>new file mode 100644
>index 000..2ef6405
>--- /dev/null
>+++ b/drivers/usb/dwc/pcd.c
>+static const struct usb_gadget_ops dwc_otg_pcd_ops = {
>+ .get_frame = dwc_otg_pcd_get_frame,
On 09/02/2011 01:17 PM, Pratyush Anand wrote:
oh boy, oh boy. This is a huge number of module parameters. Do you
actually expect someone setting all of them on modprobe? And if udev is
faster you rmmod and modpobe again, right? The clever ones would enter
it somewhere in modprobe.conf or so. Anyw
* Benjamin Herrenschmidt | 2011-09-02 21:01:43 [+1000]:
>or better, switch to the newer iomap variants which should be
>provided in both endianness.
I know some ppc-mmu provide the capability to perform the endian swap
during page access. I wasn't aware that there is a kernel wide interface
for t
* Grant Likely | 2012-01-27 14:36:16 [-0700]:
>This patch removes the x86-specific definition of irq_domain and replaces
>it with the common implementation.
I pulled your devicetree/next tree. After this patch I get:
|Hierarchical RCU implementation.
|NR_IRQS:2304 nr_irqs:256 16
|[ c
* Grant Likely | 2012-01-30 12:58:42 [-0700]:
>Ugh. This isn't easy. The legacy mapping really needs all the
Feel free to merge this patch. I don't have the time to look at this now
so I take a look at the ioapic later.
>g.
Sebastian
___
Linuxppc-de
On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
Why not phys_addr_t?
The rest of the memory specific bits of the device-tree code use u64 for
On 09/13/2012 12:08 AM, Rob Herring wrote:
Geert is right here. If it is a physical address, it should be
phys_addr_t.
While generally true, for the DT specific code I think it should be a
fixed u64. The size of the address is defined by the FDT, not the
kernel. It is very likely we could have
> index 9bfde82..968f751 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -222,7 +222,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
>
> if (pdata->controller_ver < 0) {
> dev_warn(hcd->self.controller, "Could not get controller
> v
On 02/23/2012 08:56 PM, Grant Likely wrote:
On Wed, Feb 1, 2012 at 11:06 AM, Grant Likely wrote:
On Wed, Feb 1, 2012 at 7:17 AM, Sebastian Andrzej Siewior
wrote:
* Grant Likely | 2012-01-30 12:58:42 [-0700]:
Ugh. This isn't easy. The legacy mapping really needs all the
Feel fr
It is not at 0xffa0. According to current u-boot source the NAND
controller is always at 0xff80 and it is either at CS0 or CS1
depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
0xfff80 but it has always an eight there and never an A.
Signed-off-by: Sebastian Andrzej
by 4 and this is what the fsl-spi driver in tree is doing.
Since then the flash is not wokring I guess. After chaning the freq from
50Mhz to 40Mhz like others do then I can access the flash.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/boot/dts/p1010rdb.dtsi |2 +-
arch/powerpc
as always an eight there and never an A.
>
> Signed-off-by: Sebastian Andrzej Siewior
> Signed-off-by: Kumar Gala
I am having a hard time verifying this change. I don't think you are
wrong, I'm just having a hard time following.
I do not see where this has always been 0xff800
On 03/29/2012 03:10 PM, Kumar Gala wrote:
- include/configs/P1_P2_RDB.h
#ifndef CONFIG_NAND_SPL
#define CONFIG_SYS_NAND_BASE0xffa0
#ifdef CONFIG_PHYS_64BIT
#define CONFIG_SYS_NAND_BASE_PHYS 0xfffa0ull
#else
#define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
#
* Kumar Gala | 2012-03-31 09:48:18 [-0500]:
Sorry for the delay Kumar, I though I allready done it.
>Yes, please do.
Here it comes.
>From 5b3e09992615e5670fa8e432e50424466fa9ca1a Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Wed, 9 May 2012 21:48:42 +0200
Subject:
for them. of_bus_isa_get_flags(), of_bus_pci_get_flags() and
of_bus_isa_map() were accessing the data directly and were doing it wrong.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/include/asm/prom.h |2 +-
drivers/of/address.c| 54
* Kyle Moffett | 2011-03-09 00:22:11 [-0500]:
>On Tue, Mar 8, 2011 at 23:39, Segher Boessenkool
> wrote:
>>> The problem is not with the kernel compile itself, but with the 2.12
>>> "dssall" binutils test. ??Basically, recent binutils treats e500 as
>>> effectively a separate architecture that hap
wilbur.chan wrote:
Hi Sebastian,
Hi Wilbur,
Recently I've implemented non-SMP kexec on MPC8572 and P2020ds(2G ram).
I modified your
misc_32.S that , I setuped two '1G' entries after the "rfi"
instruction, so that I did
not need to setup mapping for instruction address.
If you send s
Hi John,
on my mpc512x custom board I have non-working USB after the kexec
syscall. I've traced it down to the ehci_turn_off_all_ports() which is
called from within ehci_shutdown(). If I omit ehci_turn_off_all_ports()
it works fine. The content of the portstatus register is the same after
the setu
nt I'm not sure if the PowerON Reset takes the PHY a few
nsecs too early out of reset or if this reset is required and everyone
relies on U-boot performing this reset.
Signed-off-by: Sebastian Andrzej Siewior
---
This is done on a custom mpc512x board. Unfortunately I don't have other
Grant Likely wrote:
> What version of the kernel are you using? The line numbers don't
match up with kernel mainline, so I wonder if this is before or after
the OF MDIO rework changes.
It is the kernel which was shipped in ads5121's bsp which is 2.6.24.
Regardless, this doesn't look right.
* Alemao | 2009-09-04 16:29:15 [-0300]:
>On Fri, Sep 4, 2009 at 4:28 PM, Alemao wrote:
>> I've read some posts in the list, and about:
>>
>> irq_of_parse_and_map()
>> irq_create_map()
>>
>> But Im still trying to understand MPC85xx TSEC1 dts.
>>
>> Gianfar driver is using request_irq(), and reques
* Scott Wood | 2009-09-09 13:28:57 [-0500]:
>> That's why you always have an offset of 16 between every internal
>> interupt source number in the MPC855ERM document and those weired
>> numbers in the device tree :)
>
>This seems to be a common point of confusion -- we should probably put
>somethin
* Sebastian Andrzej Siewior | 2009-09-10 15:15:44 [+0200]:
>* Scott Wood | 2009-09-09 13:28:57 [-0500]:
>
>>> That's why you always have an offset of 16 between every internal
>>> interupt source number in the MPC855ERM document and those weired
>>> numbers i
Signed-off-by: Sebastian Andrzej Siewior
---
Documentation/powerpc/dts-bindings/fsl/mpic.txt | 42 +++
1 files changed, 42 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt
diff --git a/Documentation/powerpc/dts-bindings/fsl
* Arnd Bergmann | 2009-12-11 16:49:25 [+0100]:
>On Friday 11 December 2009, Simon Richter wrote:
>> Hi,
>>
>> since there has been a thread on allowing the use of a coprocessor in
>> the kernel already: I am wondering if it'd make sense to use AltiVec for
>> AES in dm-crypt, and how difficult it
From: Sebastian Andrzej Siewior
This adds support kexec on FSL-BookE where the MMU can not be simply
switched off. The code borrows the initial MMU-setup code to create the
identical mapping mapping. The only difference to the original boot code
is the size of the mapping(s) and the executeable
From: Sebastian Andrzej Siewior
This patch moves only the initial entry code which setups the mapping
from what ever to KERNELBASE into a seperate file. No code change has
been made here.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/kernel/fsl_booke_entry_mapping.S | 189
From: Sebastian Andrzej Siewior
24 is offset between the opcode past bl and past rfi. This makes it more
obvious.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/kernel/head_fsl_booke.S |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel
From: Sebastian Andrzej Siewior
During boot we change the mapping a few times until we have a "defined"
mapping. During this procedure a small 4KiB mapping is created and after
that one a 64MiB. Currently the offset of the 4KiB page in that we run
is zero because the complete startup
This is take two :)
SMP support did not work in the first one and due to the lack of a working
SMP machine it is still absent. I took the e500v1 problem into account and
the result is that I now use multiple 256MiB mappings.
The final mapping covers the first 2GiB so the part of the highmem should
From: Sebastian Andrzej Siewior
Right now the setup code takes ESEL of the current mapping and puts the
temporary into ESEL (old_ESEL & 1 ) + 1 which is either one or two.
This is actually not required since all slots in TLB0 are invalid by now
and can be used.
This patch moved the temp map
* Kumar Gala | 2010-01-15 11:53:13 [-0600]:
>On Jan 15, 2010, at 10:41 AM, Sebastian Andrzej Siewior wrote:
>
>> This is take two :)
>> SMP support did not work in the first one and due to the lack of a working
>> SMP machine it is still absent. I took the e500v1 problem
* wilbur.chan | 2010-01-16 20:35:50 [+0800]:
>Is it possible to avoid setting up the 1:1 mapping but to convert
>physical address into virt before relocate , like mips do?
No.
>2010/1/16 Kumar Gala :
>
>>
>> What do you think we need for SMP support? I'm happy to test out on SMP HW
>> (8572)
* Kumar Gala | 2010-01-15 11:53:13 [-0600]:
>On Jan 15, 2010, at 10:41 AM, Sebastian Andrzej Siewior wrote:
>
>> This is take two :)
>What do you think we need for SMP support? I'm happy to test out on SMP HW
>(8572)
I've updated a comment in the last patch whic
* Kumar Gala | 2010-02-17 21:07:49 [-0600]:
>
>On Jan 15, 2010, at 10:41 AM, Sebastian Andrzej Siewior wrote:
>
>> From: Sebastian Andrzej Siewior
>>
>> During boot we change the mapping a few times until we have a "defined"
>> mapping. During this pr
* Kumar Gala | 2010-02-17 21:09:08 [-0600]:
>
>On Jan 15, 2010, at 10:41 AM, Sebastian Andrzej Siewior wrote:
>
>> From: Sebastian Andrzej Siewior
>>
>> Right now the setup code takes ESEL of the current mapping and puts the
>> temporary into ESEL (old_ESEL &am
From: Sebastian Andrzej Siewior
This adds support kexec on FSL-BookE where the MMU can not be simply
switched off. The code borrows the initial MMU-setup code to create the
identical mapping mapping. The only difference to the original boot code
is the size of the mapping(s) and the executeable
1 - 100 of 207 matches
Mail list logo
