* Re: [PATCH v3] KVM: Move gfn_to_memslot() to kvm_host.h
From: Avi Kivity @ 2012-01-16 13:21 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, Paul Mackerras, kvm, kvm-ppc
In-Reply-To: <2F423C68-0AAD-4FC4-999B-DEEECC4C631F@suse.de>
On 01/16/2012 03:18 PM, Alexander Graf wrote:
> Avi?
ACK!
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH v3] KVM: Move gfn_to_memslot() to kvm_host.h
From: Alexander Graf @ 2012-01-16 13:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Avi Kivity, kvm-ppc, kvm
In-Reply-To: <20120113060951.GB15875@drongo>
On 13.01.2012, at 07:09, Paul Mackerras wrote:
> This moves __gfn_to_memslot() and search_memslots() from kvm_main.c to
> kvm_host.h to reduce the code duplication caused by the need for
> non-modular code in arch/powerpc/kvm/book3s_hv_rm_mmu.c to call
> gfn_to_memslot() in real mode.
>=20
> Rather than putting gfn_to_memslot() itself in a header, which would
> lead to increased code size, this puts __gfn_to_memslot() in a header.
> Then, the non-modular uses of gfn_to_memslot() are changed to call
> __gfn_to_memslot() instead. This way there is only one place in the
> source code that needs to be changed should the gfn_to_memslot()
> implementation need to be modified.
>=20
> On powerpc, the Book3S HV style of KVM has code that is called from
> real mode which needs to call gfn_to_memslot() and thus needs this.
> (Module code is allocated in the vmalloc region, which can't be
> accessed in real mode.)
>=20
> With this, we can remove builtin_gfn_to_memslot() from =
book3s_hv_rm_mmu.c.
Which tree is this against? I got this diff between your patch and the =
patch when applied on my tree:
-@@ -97,7 +78,7 @@ static void remove_revmap_chain(struct kvm *kvm, long =
pte_index,
- rev =3D real_vmalloc_addr(&kvm->arch.revmap[pte_index]);
- ptel =3D rev->guest_rpte;
+@@ -99,7 +80,7 @@ static void remove_revmap_chain(struct kvm *kvm, long =
pte_index,
+ rcbits =3D hpte_r & (HPTE_R_R | HPTE_R_C);
+ ptel =3D rev->guest_rpte |=3D rcbits;
Since this is completely unrelated to the actual change, I'll apply the =
patch either way. It'd just be interesting to know.
Alex
^ permalink raw reply
* Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
From: Timur Tabi @ 2012-01-16 16:12 UTC (permalink / raw)
To: Michael Neuling
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org,
Florian Tobias Schandinat
In-Reply-To: <21370.1326683320@neuling.org>
Michael Neuling wrote:
> drivers/video/fsl-diu-fb.c: In function 'fsl_diu_suspend':
> drivers/video/fsl-diu-fb.c:1435: error: incompatible type for argument 1 of 'disable_lcdc'
> drivers/video/fsl-diu-fb.c:592: note: expected 'struct fb_info *' but argument is of type 'struct fb_info'
> drivers/video/fsl-diu-fb.c: In function 'fsl_diu_resume':
> drivers/video/fsl-diu-fb.c:1445: error: incompatible type for argument 1 of 'enable_lcdc'
> drivers/video/fsl-diu-fb.c:583: note: expected 'struct fb_info *' but argument is of type 'struct fb_info'
I figured out what the problem is. I never compiled a configuration with
CONFIG_PM enabled. For some reason, CONFIG_PM is disabled when SMP is
enabled, and I only tested with mpc85xx_smp_defconfig.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
From: Timur Tabi @ 2012-01-16 16:12 UTC (permalink / raw)
To: Michael Neuling, Florian Tobias Schandinat
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org
In-Reply-To: <21370.1326683320@neuling.org>
Michael Neuling wrote:
> From: Michael Neuling <mikey@neuling.org>
>
> [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
>
> Fix a compiler errors introduced in:
> commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0
> Author: Timur Tabi <timur@freescale.com>
> drivers/video: fsl-diu-fb: merge all allocated data into one block
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Kumar Gala @ 2012-01-16 19:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <1326435694.23910.229.camel@pasglop>
On Jan 13, 2012, at 12:21 AM, Benjamin Herrenschmidt wrote:
> Hi Linus !
>=20
> Please pull this couple of important bug fixes (a commit
> that went in breaks booting on some machines, this fixes
> it properly).
>=20
> Thanks !
>=20
> Cheers,
> Ben.
>=20
> The following changes since commit =
7b3480f8b701170c046e1ed362946f5f0d005e13:
>=20
> Merge tag 'for-linus-3.3' of git://git.infradead.org/mtd-2.6 =
(2012-01-10 13:45:22 -0800)
>=20
> are available in the git repository at:
>=20
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>=20
> Anton Blanchard (1):
> powerpc: Fix RCU idle and hcall tracing
>=20
> Li Zhong (1):
> powerpc: Fix unpaired __trace_hcall_entry and __trace_hcall_exit
>=20
> arch/powerpc/kernel/idle.c | 12 ++----------
> arch/powerpc/platforms/pseries/hvCall.S | 3 ++-
> arch/powerpc/platforms/pseries/lpar.c | 14 ++++++++++----
> 3 files changed, 14 insertions(+), 15 deletions(-)
Ben,
This doesnt appear to have the compile fix for p1022_ds.c.
- k=
^ permalink raw reply
* Re: [PATCH 1/2 v2] powerpc/85xx: Add dts for P1021RDB-PC board
From: Scott Wood @ 2012-01-16 19:36 UTC (permalink / raw)
To: Xu Jiucheng; +Cc: Matthew McClintock, linuxppc-dev
In-Reply-To: <1326697208-1519-1-git-send-email-B37781@freescale.com>
On 01/16/2012 01:00 AM, Xu Jiucheng wrote:
> + mdio@24000 {
> + phy0: ethernet-phy@0 {
> + interrupt-parent = <&mpic>;
> + interrupts = <3 1>;
> + reg = <0x0>;
> + };
> +
> + phy1: ethernet-phy@1 {
> + interrupt-parent = <&mpic>;
> + interrupts = <2 1>;
> + reg = <0x1>;
> + };
pq3-mpic.dtsi (included by p1021si-post.dtsi) uses 4-cell interrupt
specifiers, so they need to be used everywhere.
-Scott
^ permalink raw reply
* Re: Cannot wake-up from standby with MPC8313
From: Scott Wood @ 2012-01-16 20:22 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4F103C17.3080003@aimvalley.nl>
On 01/13/2012 08:13 AM, Norbert van Bolhuis wrote:
> I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
> but they do not change just before entering standby (via
> mpc6xx_enter_standby
> which omits setting MSR_POW). uart IRQ is always enabled, unmasked and
> not pending.
>
> I tried to log to physical memory to see what's going on whenever the
> board fails to wake-up.
> (I can examine physical memory after CPU is stuck in sleep, by connecting
> a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is
> re-configured)
Are you sure this isn't going to disturb anything? Why does U-Boot need
to be involved, and the SDRAM reconfigured?
> It looks like an interupt does occur, but do_IRQ seems to be stuck
> in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.
Stuck as in the load never completes, or as in ipic_get_irq() gets
called repeatedly? If the latter, what value is it reading out? Is the
interrupt pending in SIPNR at this point?
-Scott
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-01-16 20:27 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <5742F9CB-77C0-40AF-9719-B55AB2C17D8C@kernel.crashing.org>
On Mon, 2012-01-16 at 13:21 -0600, Kumar Gala wrote:
> This doesnt appear to have the compile fix for p1022_ds.c.
I must have pulled it into the wrong branch or something... I'll do a
new one after LCA.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Michael Bohan @ 2012-01-17 2:43 UTC (permalink / raw)
To: Rob Herring
Cc: sfr, Russell King, linux-kernel, linux-arm-msm, Thomas Gleixner,
linuxppc-dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <4F0F7B60.5040701@gmail.com>
On 1/12/2012 4:31 PM, Rob Herring wrote:
> You have removed the irq_alloc_descs call from the GIC which is a step
> backwards. Several of the ARM DT enabled platforms are at the point they
> can fully support dynamic virq base for each irqchip. I changed the
> domain from legacy to linear and got things working. The issue with
> linear is for SPARSE_IRQ. The default behavior on ARM for SPARSE_IRQ is
> all nr_irqs are allocated at boot time before any controller is
> initialized. The only platform with a GIC and requiring SPARSE_IRQ is
> shmobile, but it is also the only one that calls irq_alloc_desc
> functions for it's interrupts. So I think we are okay there. The problem
> occurs when enabling SPARSE_IRQ for a non-DT platform with a GIC and
> with irqchips that don't call irq_alloc_desc for their irqs. IMHO, this
> should be an okay trade-off. There's no advantage to enabling SPARSE_IRQ
> on ARM for platforms that don't require it. All the platforms with a GIC
> have active work to convert to DT (except shmobile which I think is
> okay), so it's a temporary issue.
I thought I would chime in here since this is very relevant to what
we're doing on arm-msm. We are using Device Tree with the GIC. We also
have several other interrupt chips, including one for a device that
supports up to 32768 sparsely populated interrupts. Hence we are using
SPARSE_IRQ to only allocate irq_descs on demand for this device.
To support this, I had to modify irq_domain_add() to not 'register' the
domain. Eg. simply add the domain to the list, but do not initialize the
hwirq values in the irq_data structure. This is because our irq_descs
are allocated later based on Device Tree topology. This information is
not available during of_irq_init().
But then I was left with the problem of managing irq_bases for multiple
chip drivers. The problem with irq_alloc_desc() is that it doesn't allow
you to allocate a range without allocating its corresponding resources.
Meaning, I'd like to reserve a chunk of virqs, but not utilize any
resources for them until I know they're necessary. This is where
irq_domains comes in.
In order to support this properly, I decided it made sense to add a new
API called irq_domain_find_free_range(). This walks the irq domains
list, now sorted by domain->irq_base, to find the first available range
of the size specified. Thus every irq chip then only needs to know the
worst case number of interrupts it could ever support. The framework
takes care of finding the specific virq base. And all of this
information is available at of_irq_init() time. This all assumes that
every chip driver registers with irq_domains.
I was planning on sending these patches out, but it seems like with
Grant's patches, they may no longer be up to date. I was curious if any
thought was given to supporting configurations like this the one I
mentioned with the advent of these patches. I am happy to help test if
you can steer me in the right direction.
Thanks,
Mike
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Benjamin Herrenschmidt @ 2012-01-17 3:42 UTC (permalink / raw)
To: Michael Bohan
Cc: sfr, Russell King, linux-arm-msm, linux-kernel, Rob Herring,
Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4F14E05C.30207@codeaurora.org>
On Mon, 2012-01-16 at 18:43 -0800, Michael Bohan wrote:
>
> I was planning on sending these patches out, but it seems like with
> Grant's patches, they may no longer be up to date. I was curious if any
> thought was given to supporting configurations like this the one I
> mentioned with the advent of these patches. I am happy to help test if
> you can steer me in the right direction.
I haven't had a chance to look in detail at what Grant is doing in his
latest series, but the ppc domain scheme that he's basing it on has the
concept of sparse interrupt domains.
For these, we use a radix tree for the reverse map (we do not rely on a
linear range) and we "allocate" linux IRQ numbers on-demand as we create
mapping for individual HW interrupts.
Cheers,
Ben.
^ permalink raw reply
* AUTO: Michael Barry is out of the office (returning 18/01/2012)
From: Michael Barry @ 2012-01-17 4:01 UTC (permalink / raw)
To: linuxppc-dev
I am out of the office until 18/01/2012.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 89, Issue 49" sent on 17/1/2012 1:00:02.
This is the only notification you will receive while this person is away.
^ permalink raw reply
* Re: [PATCH v3] KVM: Move gfn_to_memslot() to kvm_host.h
From: Paul Mackerras @ 2012-01-17 5:02 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, Avi Kivity, kvm-ppc, kvm
In-Reply-To: <E1127F8D-E42E-44C7-B869-2B46C2812C8F@suse.de>
On Mon, Jan 16, 2012 at 02:30:41PM +0100, Alexander Graf wrote:
> Which tree is this against? I got this diff between your patch and the patch when applied on my tree:
It's against your tree (previously) plus my first 13-patch series, but
not the second series of 5 patches, which presumably why you got the
difference. Sounds like you got it applied OK; if not let me know and
I'll rebase against your current tree.
Paul.
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Paul Mackerras @ 2012-01-17 5:56 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <1A57B98F-A4C7-457D-A52A-4F67D5902E32@suse.de>
On Mon, Jan 16, 2012 at 02:04:29PM +0100, Alexander Graf wrote:
>
> On 20.12.2011, at 11:22, Paul Mackerras wrote:
> > @@ -152,6 +152,8 @@ static unsigned long do_h_register_vpa(struct kvm_vcpu *vcpu,
> > flags &= 7;
> > if (flags == 0 || flags == 4)
>
> This could probably use a new variable name. Also, what do 0 and 4 mean? Constant defines would be nice here.
Those constants are defined in PAPR as being a subfunction code
indicating what sort of area and whether it is to be registered or
unregistered. I'll make up some names for them.
> [pasted from real source]
> > va = kvmppc_pin_guest_page(kvm, vpa, &nb);
>
> Here you're pinning the page, setting va to that temporarily available address.
Well, it's not just temporarily available, it's available until we
unpin it, since we increment the page count, which inhibits migration.
> > len = *(unsigned int *)(va + 4);
>
> va + 4 isn't really descriptive. Is this a defined struct? Why not actually define one which you can just read data from? Or at least make this a define too. Reading random numbers in code is barely readable.
It's not really a struct, at least not one that is used for anything
else. PAPR defines that the length of the buffer has to be placed in
the second 32-bit word at registration time.
>
> > + free_va = va;
>
> Now free_va is the temporarily available address.
...
> > + free_va = tvcpu->arch.next_vpa;
> > + tvcpu->arch.next_vpa = va;
>
> Now you're setting next_vpa to this temporarily available address? But next_vpa will be used after va is getting free'd, no? Or is that why you have free_va?
Yes; here we are freeing any previously-set value of next_vpa. The
idea of free_va is that it is initially set to va so that we correctly
unpin va if any error occurs. But if there is no error, va gets put
into next_vpa and we free anything that was previously in next_vpa
instead.
>
> Wouldn't it be easier to just map it every time we actually use it and only shove the GPA around? We could basically save ourselves a lot of the logic here.
There are fields in the VPA that we really want to be able to access
from real mode, for instance the fields that indicate whether we need
to save the FPR and/or VR values. As far as the DTL is concerned, we
could in fact use copy_to_user to access it, so it doesn't strictly
need to be pinned. We don't currently use the slb_shadow buffer, but
if we did we would need to access it from real mode, since we would be
reading it in order to set up guest SLB entries.
The other thing is that the VPA registration/unregistration is only
done a few times in the life of the guest, whereas we use the VPAs
constantly while the guest is running. So it is more efficient to do
more of the work at registration time to make it quicker to access the
VPAs.
I'll send revised patches. There's a small change I want to make to
patch 2 to avoid putting a very large stolen time value in the first
entry that gets put in after the DTL is registered, which can happen
currently if the DTL gets registered some time after the guest started
running.
Paul.
^ permalink raw reply
* Re: [PATCH 1/2 v2] powerpc/85xx: Add dts for P1021RDB-PC board
From: Xu Jiucheng @ 2012-01-17 7:30 UTC (permalink / raw)
To: Scott Wood; +Cc: Matthew McClintock, linuxppc-dev
In-Reply-To: <4F147C49.40008@freescale.com>
On Mon, 2012-01-16 at 13:36 -0600, Scott Wood wrote:
> On 01/16/2012 01:00 AM, Xu Jiucheng wrote:
> > + mdio@24000 {
> > + phy0: ethernet-phy@0 {
> > + interrupt-parent = <&mpic>;
> > + interrupts = <3 1>;
> > + reg = <0x0>;
> > + };
> > +
> > + phy1: ethernet-phy@1 {
> > + interrupt-parent = <&mpic>;
> > + interrupts = <2 1>;
> > + reg = <0x1>;
> > + };
>
> pq3-mpic.dtsi (included by p1021si-post.dtsi) uses 4-cell interrupt
> specifiers, so they need to be used everywhere.
>
> -Scott
ok.
Thanks,
Jiucheng
^ permalink raw reply
* [PATCH 2/2 v3] powerpc/85xx: Added P1021RDB-PC Platform support
From: Xu Jiucheng @ 2012-01-17 8:01 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Xu Jiucheng
In-Reply-To: <1326787291-8922-1-git-send-email-B37781@freescale.com>
Signed-off-by: Xu Jiucheng <B37781@freescale.com>
---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index ccf520e..1273381 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -90,6 +90,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
machine_device_initcall(p2020_rdb, mpc85xx_common_publish_devices);
machine_device_initcall(p1020_rdb, mpc85xx_common_publish_devices);
+machine_device_initcall(p1021_rdb_pc, mpc85xx_common_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -112,6 +113,15 @@ static int __init p1020_rdb_probe(void)
return 0;
}
+static int __init p1021_rdb_pc_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,P1021RDB-PC"))
+ return 1;
+ return 0;
+}
+
define_machine(p2020_rdb) {
.name = "P2020 RDB",
.probe = p2020_rdb_probe,
@@ -139,3 +149,17 @@ define_machine(p1020_rdb) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(p1021_rdb_pc) {
+ .name = "P1021 RDB-PC",
+ .probe = p1021_rdb_pc_probe,
+ .setup_arch = mpc85xx_rdb_setup_arch,
+ .init_IRQ = mpc85xx_rdb_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.6.4
^ permalink raw reply related
* [PATCH 1/2 v3] powerpc/85xx: Added dts for P1021RDB-PC board
From: Xu Jiucheng @ 2012-01-17 8:01 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Matthew McClintock, Xu Jiucheng
P1021RDB-PC Overview
-----------------
1Gbyte DDR3 (on board DDR)
16Mbyte NOR flash
32Mbyte eSLC NAND Flash
256 Kbit M24256 I2C EEPROM
128 Mbit SPI Flash memory
Real-time clock on I2C bus
SD/MMC connector to interface with the SD memory card
PCIex
- x1 PCIe slot or x1 PCIe to dual SATA controller
- x1 mini-PCIe slot
USB 2.0
- ULPI PHY interface: SMSC USB3300 USB PHY and Genesys Logic=E2=80=99=
s GL850A
- Two USB2.0 Type A receptacles
- One USB2.0 signal to Mini PCIe slot
eTSEC1: Connected to RGMII PHY VSC7385
eTSEC2: Connected to SGMII PHY VSC8221
eTSEC3: Connected to SGMII PHY AR8021
DUART interface: supports two UARTs up to 115200 bps for console display
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Xu Jiucheng <B37781@freescale.com>
---
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 4 +
arch/powerpc/boot/dts/p1021rdb.dts | 96 +++++++++++
arch/powerpc/boot/dts/p1021rdb.dtsi | 236 +++++++++++++++++++++=
++++++
arch/powerpc/boot/dts/p1021rdb_36b.dts | 96 +++++++++++
4 files changed, 432 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1021rdb.dts
create mode 100644 arch/powerpc/boot/dts/p1021rdb.dtsi
create mode 100644 arch/powerpc/boot/dts/p1021rdb_36b.dts
diff --git a/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi b/arch/powerpc/b=
oot/dts/fsl/p1021si-post.dtsi
index 38ba54d..b7929c9 100644
--- a/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
@@ -144,6 +144,10 @@
/include/ "pq3-usb2-dr-0.dtsi"
=20
/include/ "pq3-esdhc-0.dtsi"
+ sdhc@2e000 {
+ sdhci,auto-cmd12;
+ };
+
/include/ "pq3-sec3.3-0.dtsi"
=20
/include/ "pq3-mpic.dtsi"
diff --git a/arch/powerpc/boot/dts/p1021rdb.dts b/arch/powerpc/boot/dts/p=
1021rdb.dts
new file mode 100644
index 0000000..90b6b4c
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1021rdb.dts
@@ -0,0 +1,96 @@
+/*
+ * P1021 RDB Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions ar=
e met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyrig=
ht
+ * notice, this list of conditions and the following disclaimer in=
the
+ * documentation and/or other materials provided with the distribu=
tion.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote pro=
ducts
+ * derived from this software without specific prior written permi=
ssion.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of th=
e
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR A=
NY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DA=
MAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SE=
RVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUS=
ED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR=
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE=
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1021si-pre.dtsi"
+/ {
+ model =3D "fsl,P1021RDB";
+ compatible =3D "fsl,P1021RDB-PC";
+
+ memory {
+ device_type =3D "memory";
+ };
+
+ lbc: localbus@ffe05000 {
+ reg =3D <0 0xffe05000 0 0x1000>;
+
+ /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
+ ranges =3D <0x0 0x0 0x0 0xef000000 0x01000000
+ 0x1 0x0 0x0 0xff800000 0x00040000
+ 0x2 0x0 0x0 0xffb00000 0x00020000>;
+ };
+
+ soc: soc@ffe00000 {
+ ranges =3D <0x0 0x0 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@ffe09000 {
+ ranges =3D <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
+ reg =3D <0 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges =3D <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ reg =3D <0 0xffe0a000 0 0x1000>;
+ ranges =3D <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges =3D <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ qe: qe@ffe80000 {
+ ranges =3D <0x0 0x0 0xffe80000 0x40000>;
+ reg =3D <0 0xffe80000 0 0x480>;
+ brg-frequency =3D <0>;
+ bus-frequency =3D <0>;
+ };
+};
+
+/include/ "p1021rdb.dtsi"
+/include/ "fsl/p1021si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1021rdb.dtsi b/arch/powerpc/boot/dts/=
p1021rdb.dtsi
new file mode 100644
index 0000000..afb6906
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1021rdb.dtsi
@@ -0,0 +1,236 @@
+/*
+ * P1021 RDB Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions ar=
e met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyrig=
ht
+ * notice, this list of conditions and the following disclaimer in=
the
+ * documentation and/or other materials provided with the distribu=
tion.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote pro=
ducts
+ * derived from this software without specific prior written permi=
ssion.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of th=
e
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND AN=
Y
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR A=
NY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DA=
MAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SE=
RVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUS=
ED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR=
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE=
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+ nor@0,0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "cfi-flash";
+ reg =3D <0x0 0x0 0x1000000>;
+ bank-width =3D <2>;
+ device-width =3D <1>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385 Switch firmware */
+ reg =3D <0x0 0x00040000>;
+ label =3D "NOR Vitesse-7385 Firmware";
+ read-only;
+ };
+
+ partition@40000 {
+ /* 256KB for DTB Image */
+ reg =3D <0x00040000 0x00040000>;
+ label =3D "NOR DTB Image";
+ };
+
+ partition@80000 {
+ /* 3.5 MB for Linux Kernel Image */
+ reg =3D <0x00080000 0x00380000>;
+ label =3D "NOR Linux Kernel Image";
+ };
+
+ partition@400000 {
+ /* 11MB for JFFS2 based Root file System */
+ reg =3D <0x00400000 0x00b00000>;
+ label =3D "NOR JFFS2 Root File System";
+ };
+
+ partition@f00000 {
+ /* This location must not be altered */
+ /* 512KB for u-boot Bootloader Image */
+ /* 512KB for u-boot Environment Variables */
+ reg =3D <0x00f00000 0x00100000>;
+ label =3D "NOR U-Boot Image";
+ };
+ };
+
+ nand@1,0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "fsl,p1021-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg =3D <0x1 0x0 0x40000>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg =3D <0x0 0x00100000>;
+ label =3D "NAND U-Boot Image";
+ read-only;
+ };
+
+ partition@100000 {
+ /* 1MB for DTB Image */
+ reg =3D <0x00100000 0x00100000>;
+ label =3D "NAND DTB Image";
+ };
+
+ partition@200000 {
+ /* 4MB for Linux Kernel Image */
+ reg =3D <0x00200000 0x00400000>;
+ label =3D "NAND Linux Kernel Image";
+ };
+
+ partition@600000 {
+ /* 4MB for Compressed Root file System Image */
+ reg =3D <0x00600000 0x00400000>;
+ label =3D "NAND Compressed RFS Image";
+ };
+
+ partition@a00000 {
+ /* 7MB for JFFS2 based Root file System */
+ reg =3D <0x00a00000 0x00700000>;
+ label =3D "NAND JFFS2 Root File System";
+ };
+
+ partition@1100000 {
+ /* 15MB for User Writable Area */
+ reg =3D <0x01100000 0x00f00000>;
+ label =3D "NAND Writable User area";
+ };
+ };
+
+ L2switch@2,0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "vitesse-7385";
+ reg =3D <0x2 0x0 0x20000>;
+ };
+};
+
+&soc {
+ i2c@3000 {
+ rtc@68 {
+ compatible =3D "pericom,pt7c4338";
+ reg =3D <0x68>;
+ };
+ };
+
+ spi@7000 {
+ flash@0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "spansion,s25sl12801";
+ reg =3D <0>;
+ spi-max-frequency =3D <40000000>; /* input clock */
+
+ partition@u-boot {
+ /* 512KB for u-boot Bootloader Image */
+ reg =3D <0x0 0x00080000>;
+ label =3D "SPI Flash U-Boot Image";
+ read-only;
+ };
+
+ partition@dtb {
+ /* 512KB for DTB Image */
+ reg =3D <0x00080000 0x00080000>;
+ label =3D "SPI Flash DTB Image";
+ };
+
+ partition@kernel {
+ /* 4MB for Linux Kernel Image */
+ reg =3D <0x00100000 0x00400000>;
+ label =3D "SPI Flash Linux Kernel Image";
+ };
+
+ partition@fs {
+ /* 4MB for Compressed RFS Image */
+ reg =3D <0x00500000 0x00400000>;
+ label =3D "SPI Flash Compressed RFSImage";
+ };
+
+ partition@jffs-fs {
+ /* 7MB for JFFS2 based RFS */
+ reg =3D <0x00900000 0x00700000>;
+ label =3D "SPI Flash JFFS2 RFS";
+ };
+ };
+ };
+
+ usb@22000 {
+ phy_type =3D "ulpi";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ interrupt-parent =3D <&mpic>;
+ interrupts =3D <3 1 0 0>;
+ reg =3D <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ interrupt-parent =3D <&mpic>;
+ interrupts =3D <2 1 0 0>;
+ reg =3D <0x1>;
+ };
+
+ tbi0: tbi-phy@11 {
+ reg =3D <0x11>;
+ device_type =3D "tbi-phy";
+ };
+ };
+
+ mdio@25000 {
+ tbi1: tbi-phy@11 {
+ reg =3D <0x11>;
+ device_type =3D "tbi-phy";
+ };
+ };
+
+ mdio@26000 {
+ tbi2: tbi-phy@11 {
+ reg =3D <0x11>;
+ device_type =3D "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@b0000 {
+ fixed-link =3D <1 1 1000 0 0>;
+ phy-connection-type =3D "rgmii-id";
+
+ };
+
+ enet1: ethernet@b1000 {
+ phy-handle =3D <&phy0>;
+ tbi-handle =3D <&tbi1>;
+ phy-connection-type =3D "sgmii";
+ };
+
+ enet2: ethernet@b2000 {
+ phy-handle =3D <&phy1>;
+ tbi-handle =3D <&tbi2>;
+ phy-connection-type =3D "rgmii-id";
+ };
+};
diff --git a/arch/powerpc/boot/dts/p1021rdb_36b.dts b/arch/powerpc/boot/d=
ts/p1021rdb_36b.dts
new file mode 100644
index 0000000..ea6d8b5
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1021rdb_36b.dts
@@ -0,0 +1,96 @@
+/*
+ * P1021 RDB Device Tree Source (36-bit address map)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions ar=
e met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyrig=
ht
+ * notice, this list of conditions and the following disclaimer in=
the
+ * documentation and/or other materials provided with the distribu=
tion.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote pro=
ducts
+ * derived from this software without specific prior written permi=
ssion.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of th=
e
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR A=
NY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DA=
MAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SE=
RVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUS=
ED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR=
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE=
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1021si-pre.dtsi"
+/ {
+ model =3D "fsl,P1021RDB";
+ compatible =3D "fsl,P1021RDB-PC";
+
+ memory {
+ device_type =3D "memory";
+ };
+
+ lbc: localbus@fffe05000 {
+ reg =3D <0xf 0xffe05000 0 0x1000>;
+
+ /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
+ ranges =3D <0x0 0x0 0xf 0xef000000 0x01000000
+ 0x1 0x0 0xf 0xff800000 0x00040000
+ 0x2 0x0 0xf 0xffb00000 0x00020000>;
+ };
+
+ soc: soc@fffe00000 {
+ ranges =3D <0x0 0xf 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@fffe09000 {
+ ranges =3D <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
+ reg =3D <0xf 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges =3D <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@fffe0a000 {
+ reg =3D <0xf 0xffe0a000 0 0x1000>;
+ ranges =3D <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges =3D <0x2000000 0x0 0xc0000000
+ 0x2000000 0x0 0xc0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ qe: qe@fffe80000 {
+ ranges =3D <0x0 0xf 0xffe80000 0x40000>;
+ reg =3D <0xf 0xffe80000 0 0x480>;
+ brg-frequency =3D <0>;
+ bus-frequency =3D <0>;
+ };
+};
+
+/include/ "p1021rdb.dtsi"
+/include/ "fsl/p1021si-post.dtsi"
--=20
1.6.4
^ permalink raw reply related
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Alexander Graf @ 2012-01-17 9:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <20120117055654.GB9170@drongo>
On 17.01.2012, at 06:56, Paul Mackerras <paulus@samba.org> wrote:
> On Mon, Jan 16, 2012 at 02:04:29PM +0100, Alexander Graf wrote:
>>=20
>> On 20.12.2011, at 11:22, Paul Mackerras wrote:
>=20
>>> @@ -152,6 +152,8 @@ static unsigned long do_h_register_vpa(struct kvm_vc=
pu *vcpu,
>>> flags &=3D 7;
>>> if (flags =3D=3D 0 || flags =3D=3D 4)
>>=20
>> This could probably use a new variable name. Also, what do 0 and 4 mean? C=
onstant defines would be nice here.
>=20
> Those constants are defined in PAPR as being a subfunction code
> indicating what sort of area and whether it is to be registered or
> unregistered. I'll make up some names for them.
>=20
>> [pasted from real source]
>>> va =3D kvmppc_pin_guest_page(kvm, vpa, &nb);
>>=20
>> Here you're pinning the page, setting va to that temporarily available ad=
dress.
>=20
> Well, it's not just temporarily available, it's available until we
> unpin it, since we increment the page count, which inhibits migration.
>=20
>>> len =3D *(unsigned int *)(va + 4);
>>=20
>> va + 4 isn't really descriptive. Is this a defined struct? Why not actual=
ly define one which you can just read data from? Or at least make this a def=
ine too. Reading random numbers in code is barely readable.
>=20
> It's not really a struct, at least not one that is used for anything
> else. PAPR defines that the length of the buffer has to be placed in
> the second 32-bit word at registration time.
>=20
>>=20
>>> + free_va =3D va;
>>=20
>> Now free_va is the temporarily available address.
> ...
>>> + free_va =3D tvcpu->arch.next_vpa;
>>> + tvcpu->arch.next_vpa =3D va;
>>=20
>> Now you're setting next_vpa to this temporarily available address? But ne=
xt_vpa will be used after va is getting free'd, no? Or is that why you have f=
ree_va?
>=20
> Yes; here we are freeing any previously-set value of next_vpa. The
> idea of free_va is that it is initially set to va so that we correctly
> unpin va if any error occurs. But if there is no error, va gets put
> into next_vpa and we free anything that was previously in next_vpa
> instead.
>=20
>>=20
>> Wouldn't it be easier to just map it every time we actually use it and on=
ly shove the GPA around? We could basically save ourselves a lot of the logi=
c here.
>=20
> There are fields in the VPA that we really want to be able to access
> from real mode, for instance the fields that indicate whether we need
> to save the FPR and/or VR values. As far as the DTL is concerned, we
> could in fact use copy_to_user to access it, so it doesn't strictly
> need to be pinned. We don't currently use the slb_shadow buffer, but
> if we did we would need to access it from real mode, since we would be
> reading it in order to set up guest SLB entries.
>=20
> The other thing is that the VPA registration/unregistration is only
> done a few times in the life of the guest, whereas we use the VPAs
> constantly while the guest is running. So it is more efficient to do
> more of the work at registration time to make it quicker to access the
> VPAs.
The thing I was getting at was not the map during the lifetime, but the map d=
uring registration. Currently we have:
1) Set VPA to x
2) Assign feature y to VPA
3) Use VPA
1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to be fast=
. 1 and 2 don't matter that much wrt performance.
You are currently mapping the VPA at /, which gets you into this map/unmap m=
ess trying to free the previous mapping. If you moved the map to step 2 and o=
nly stored the GPA at step 1, all map+unmap operations except for final unma=
ps would be in one spot, so you wouldn't need to construct this big complex s=
tate machine.
I hope that makes it more clear :)
Alex
>=20
> I'll send revised patches. There's a small change I want to make to
> patch 2 to avoid putting a very large stolen time value in the first
> entry that gets put in after the DTL is registered, which can happen
> currently if the DTL gets registered some time after the guest started
> running.
>=20
> Paul.
^ permalink raw reply
* [PATCH 1/2] powerpc/dts: Add some DTS nodes and attributes for mpc8536ds
From: Xie Xiaobo @ 2012-01-17 9:59 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Xie Xiaobo
1. Add partitions for NOR and NAND Flash.
2. Additional attributes for sdhc.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 5 ++
arch/powerpc/boot/dts/mpc8536ds.dts | 6 ++-
arch/powerpc/boot/dts/mpc8536ds.dtsi | 93 +++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8536ds_36b.dts | 8 ++-
4 files changed, 109 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
index 89af626..3ebfda3 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
@@ -236,6 +236,11 @@
};
/include/ "pq3-esdhc-0.dtsi"
+
+ sdhc@2e000 {
+ compatible = "fsl,mpc8536-esdhc", "fsl,esdhc";
+ };
+
/include/ "pq3-sec3.0-0.dtsi"
/include/ "pq3-mpic.dtsi"
/include/ "pq3-mpic-timer-B.dtsi"
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts b/arch/powerpc/boot/dts/mpc8536ds.dts
index c158815..1973622 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -1,7 +1,7 @@
/*
* MPC8536 DS Device Tree Source
*
- * Copyright 2008 Freescale Semiconductor, Inc.
+ * Copyright 2008, 2011 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -34,6 +34,10 @@
lbc: localbus@ffe05000 {
reg = <0 0xffe05000 0 0x1000>;
+
+ ranges = <0x0 0x0 0x0 0xe8000000 0x08000000
+ 0x2 0x0 0x0 0xffa00000 0x00040000
+ 0x3 0x0 0x0 0xffdf0000 0x00008000>;
};
board_soc: soc: soc@ffe00000 {
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dtsi b/arch/powerpc/boot/dts/mpc8536ds.dtsi
index 1462e4c..cc46dbd 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8536ds.dtsi
@@ -32,6 +32,99 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+&lbc {
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ reg = <0x0 0x03000000>;
+ label = "ramdisk-nor";
+ };
+
+ partition@3000000 {
+ reg = <0x03000000 0x00e00000>;
+ label = "diagnostic-nor";
+ read-only;
+ };
+
+ partition@3e00000 {
+ reg = <0x03e00000 0x00200000>;
+ label = "dink-nor";
+ read-only;
+ };
+
+ partition@4000000 {
+ reg = <0x04000000 0x00400000>;
+ label = "kernel-nor";
+ };
+
+ partition@4400000 {
+ reg = <0x04400000 0x03b00000>;
+ label = "fs-nor";
+ };
+
+ partition@7f00000 {
+ reg = <0x07f00000 0x00080000>;
+ label = "dtb-nor";
+ };
+
+ partition@7f80000 {
+ reg = <0x07f80000 0x00080000>;
+ label = "u-boot-nor";
+ read-only;
+ };
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8536-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <0x2 0x0 0x40000>;
+
+ partition@0 {
+ reg = <0x0 0x02000000>;
+ label = "u-boot-nand";
+ read-only;
+ };
+
+ partition@2000000 {
+ reg = <0x02000000 0x10000000>;
+ label = "fs-nand";
+ };
+
+ partition@12000000 {
+ reg = <0x12000000 0x08000000>;
+ label = "ramdisk-nand";
+ };
+
+ partition@1a000000 {
+ reg = <0x1a000000 0x04000000>;
+ label = "kernel-nand";
+ };
+
+ partition@1e000000 {
+ reg = <0x1e000000 0x01000000>;
+ label = "dtb-nand";
+ };
+
+ partition@1f000000 {
+ reg = <0x1f000000 0x21000000>;
+ label = "empty-nand";
+ };
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,mpc8536ds-fpga-pixis";
+ reg = <0x3 0x0 0x8000>;
+ };
+};
+
&board_soc {
i2c@3100 {
rtc@68 {
diff --git a/arch/powerpc/boot/dts/mpc8536ds_36b.dts b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
index 8f4b929..f8a3b34 100644
--- a/arch/powerpc/boot/dts/mpc8536ds_36b.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
@@ -1,7 +1,7 @@
/*
* MPC8536DS Device Tree Source (36-bit address map)
*
- * Copyright 2008-2009 Freescale Semiconductor, Inc.
+ * Copyright 2008-2009, 2011 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -33,7 +33,11 @@
};
lbc: localbus@ffe05000 {
- reg = <0 0xffe05000 0 0x1000>;
+ reg = <0xf 0xffe05000 0 0x1000>;
+
+ ranges = <0x0 0x0 0xf 0xe8000000 0x08000000
+ 0x2 0x0 0xf 0xffa00000 0x00040000
+ 0x3 0x0 0xf 0xffdf0000 0x00008000>;
};
board_soc: soc: soc@fffe00000 {
--
1.7.5.1
^ permalink raw reply related
* [PATCH 2/2] powerpc/dts: Add magic-packet properties for etsec
From: Xie Xiaobo @ 2012-01-17 9:59 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Xie Xiaobo
In-Reply-To: <1326794391-6105-1-git-send-email-X.Xie@freescale.com>
The properties indicates that the hardware supports waking up via magic packet.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi | 3 ++-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
index a1979ae..3b0650a 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x24000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@24000 {
compatible = "gianfar";
reg = <0x24000 0x1000>;
ranges = <0x0 0x24000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <29 2 0 0 30 2 0 0 34 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
index 4c4fdde..96693b4 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x25000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@25000 {
compatible = "gianfar";
reg = <0x25000 0x1000>;
ranges = <0x0 0x25000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <35 2 0 0 36 2 0 0 40 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
index 4b8ab43..6b3fab1 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x26000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@26000 {
compatible = "gianfar";
reg = <0x26000 0x1000>;
ranges = <0x0 0x26000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <31 2 0 0 32 2 0 0 33 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
index 40c9137..0da592d 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x27000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@27000 {
compatible = "gianfar";
reg = <0x27000 0x1000>;
ranges = <0x0 0x27000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <37 2 0 0 38 2 0 0 39 2 0 0>;
};
--
1.7.5.1
^ permalink raw reply related
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Paul Mackerras @ 2012-01-17 11:31 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <6D049B19-8A91-445A-9FBB-E4851D4F586E@suse.de>
On Tue, Jan 17, 2012 at 10:27:26AM +0100, Alexander Graf wrote:
> The thing I was getting at was not the map during the lifetime, but
> the map during registration. Currently we have:
>
> 1) Set VPA to x
> 2) Assign feature y to VPA
> 3) Use VPA
>
> 1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to
> be fast. 1 and 2 don't matter that much wrt performance.
>
> You are currently mapping the VPA at /, which gets you into this
> map/unmap mess trying to free the previous mapping. If you moved the
> map to step 2 and only stored the GPA at step 1, all map+unmap
> operations except for final unmaps would be in one spot, so you
> wouldn't need to construct this big complex state machine.
That might simplify things - I'll try it and see. The worry with
doing the map/pin at 2 is that if anything goes wrong we no longer
have the opportunity to return an error for the H_REGISTER_VPA call,
so I'll have to at least do some checking in 1, leading to possibly
more code overall.
Paul.
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Alexander Graf @ 2012-01-17 12:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <20120117113140.GA9093@bloggs.ozlabs.ibm.com>
On 17.01.2012, at 12:31, Paul Mackerras wrote:
> On Tue, Jan 17, 2012 at 10:27:26AM +0100, Alexander Graf wrote:
>=20
>> The thing I was getting at was not the map during the lifetime, but
>> the map during registration. Currently we have:
>>=20
>> 1) Set VPA to x
>> 2) Assign feature y to VPA
>> 3) Use VPA
>>=20
>> 1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to
>> be fast. 1 and 2 don't matter that much wrt performance.
>>=20
>> You are currently mapping the VPA at /, which gets you into this
>> map/unmap mess trying to free the previous mapping. If you moved the
>> map to step 2 and only stored the GPA at step 1, all map+unmap
>> operations except for final unmaps would be in one spot, so you
>> wouldn't need to construct this big complex state machine.
>=20
> That might simplify things - I'll try it and see. The worry with
> doing the map/pin at 2 is that if anything goes wrong we no longer
> have the opportunity to return an error for the H_REGISTER_VPA call,
> so I'll have to at least do some checking in 1, leading to possibly
> more code overall.
Well, then map and unmap it in step 1 and map it in step 2 again. We're =
in the slow path so performance isn't critical. Readability and =
maintainability however are :)
Alex
^ permalink raw reply
* Re: Problem with full speed devices on PowerPC MPC5121 host port
From: Matthias Fuchs @ 2012-01-17 14:12 UTC (permalink / raw)
To: Alan Stern; +Cc: Greg KH, linux-usb, linuxppc-dev
In-Reply-To: <Pine.LNX.4.44L0.1201061258040.1326-100000@iolanthe.rowland.org>
On 06.01.2012 19:03, Alan Stern wrote:
> On Fri, 6 Jan 2012, Matthias Fuchs wrote:
>
>> For my eyes it does not really look like a general USB issue.
>> It looks like a problem with the Freescale EHCI implementation that is
>> influenced by high interrupt or internal bus load caused by the flood ping.
>
> Indeed, it might be a problem with the built-in Transaction Translator.
> That would explain why it affect full-speed devices.
>
> However, I would expect the resetting the controller hardware (which
> happens when you reload the ehci-fsl driver) would fix any such issues.
> It's hard to imagine how a problem could survive a reset like that.
I did the tests again. When the error occured I reloaded the ehci-hcd driver and reconnected the device. It ends up with some kernel messages
that come up time after time:
usb 1-1: new full-speed USB device number 2 using fsl-ehci
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full-speed USB device number 3 using fsl-ehci
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full-speed USB device number 4 using fsl-ehci
usb 1-1: device not accepting address 4, error -110
usb 1-1: new full-speed USB device number 5 using fsl-ehci
usb 1-1: device not accepting address 5, error -110
hub 1-0:1.0: unable to enumerate USB device on port 1
A recommondation from freescale was to check the TXFILLTUNING register settings ("Initialization of this registers can produce problem if full-speed device is used").
So I tried various values in the TXFILLTUNING register (I added this
code to ehci_reset()). Finally I disabled USB streaming mode in the USBMODE register (set bit USBMODE_SDIS - btw., it should be defined as "1 << 4" in ehci_def.h at least for the MPC5121).
All this does not fix the problem or even have an impact.
This is my stripped down version of the test:
on the MPC5121 unit I do nothing but:
$~ stty -F /dev/ttyUSB0 -echo -crtscts -cstopb
$~ stty -F /dev/ttyUSB0 115200
$~ while true; do \
read LINE < /dev/ttyUSB0 \
echo $LINE > /dev/ttyUSB0 \
done
The other side looks like this:
$~ while true; do \
echo "_THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG 1234567890#" > /dev/ttyS0 \
done
and also I start a flood ping against the MPC5121 unit (.. to speed things up).
Can anybody with a MPC5121 board try to reproduce this?
Matthias
^ permalink raw reply
* Re: Cannot wake-up from standby with MPC8313
From: Norbert van Bolhuis @ 2012-01-17 16:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4F1486F1.7000406@freescale.com>
On 01/16/12 21:22, Scott Wood wrote:
> On 01/13/2012 08:13 AM, Norbert van Bolhuis wrote:
>> I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
>> but they do not change just before entering standby (via
>> mpc6xx_enter_standby
>> which omits setting MSR_POW). uart IRQ is always enabled, unmasked and
>> not pending.
>>
>> I tried to log to physical memory to see what's going on whenever the
>> board fails to wake-up.
>> (I can examine physical memory after CPU is stuck in sleep, by connecting
>> a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is
>> re-configured)
>
> Are you sure this isn't going to disturb anything? Why does U-Boot need
> to be involved, and the SDRAM reconfigured?
>
If CPU is stuck in sleep, JTAG will send HRESET or SRESET (i'm nor sure
which one it is) and u-boot is needed to reconfigure CPU and DDR2 SDRAM ctrl.
SDRAM contents (for physical memory "unknown" to u-boot and linux) seems to
survive such a soft-reset.
>> It looks like an interupt does occur, but do_IRQ seems to be stuck
>> in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.
>
> Stuck as in the load never completes, or as in ipic_get_irq() gets
> called repeatedly? If the latter, what value is it reading out? Is the
> interrupt pending in SIPNR at this point?
>
I think I was wrong. I enabled tracing do_IRQ just a little bit too soon
(in suspend_enter). The interrupt I saw was probably one that occured
just before CPU entered sleep (mpc6xx_enter_standby).
Right now I see no external interrupt happening, so that brings us back
where we were before: I'm not getting an interrupt regardless of low-power state.
So now my main question is: how can JTAG and/or any other external signal
cause this ?
Another weird thing I noticed is that whenever I dump CPU memmap
(which starts at 0xe0000000) under linux it always crashes with a "check stop"
when it is displaying somewhere at 0xe0000800-0xe0001000
If I connect our JTAG debugger it never crashes and dumping CPU memmap
always works.
---
NvBolhuis
^ permalink raw reply
* RE: [PATCH 2/2] Kbuild: Use dtc's -d (dependency) option
From: Stephen Warren @ 2012-01-17 17:20 UTC (permalink / raw)
To: Michal Marek, Mark Salter
Cc: Jonas Bonn, Jon Loeliger, Russell King,
linux-c6x-dev@linux-c6x.org, Arnd Bergmann, Aurelien Jacquiot,
linux@openrisc.net, linux-kbuild@vger.kernel.org, Michal Simek,
Rob Herring, linux-kernel@vger.kernel.org, Paul Mackerras,
microblaze-uclinux@itee.uq.edu.au, linuxppc-dev@lists.ozlabs.org,
Devicetree Discuss, linux-arm-kernel@lists.infradead.org,
David Gibson
In-Reply-To: <4F1206F1.5090405@suse.cz>
Michal Marek wrote at Saturday, January 14, 2012 3:51 PM:
> On 11.1.2012 20:36, Mark Salter wrote:
> > On Mon, 2012-01-09 at 11:38 -0700, Stephen Warren wrote:
> >> This hooks dtc into Kbuild's dependency system.
> >>
> >> Thus, for example, "make dtbs" will rebuild tegra-harmony.dtb if only
> >> tegra20.dtsi has changed yet tegra-harmony.dts has not. The previous
> >> lack of this feature recently caused me to have very confusing "git
> >> bisect" results.
> >>
> >> For ARM, it's obvious what to add to $(targets). I'm not familiar enou=
gh
> >> with other architectures to know what to add there. Powerpc appears to
> >> already add various .dtb files into $(targets), but the other archs ma=
y
> >> need something added to $(targets) to work.
> >>
> >> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> >>
> >
> > Acked-by: Mark Salter <msalter@redhat.com>
> >
> > For the arch/c6x bit.
>=20
> As the C6X port has been merged in this merge window, I can't easily
> apply this patch to my kbuild branch and at the same time please Linus
> by basing the pull request on a tagged release. So I'm going to drop the
> arch/c6x part to keep the kbuild branch "pretty" and let either Mark or
> Stephen send the patch to Linus directly, once he has merged the kbuild
> branch. Would that work?
I was assuming my patches were for 3.4 rather than 3.3, since it's pretty
late for new features in 3.3. In that case, there wouldn't be an issue,
right?
If you do want to go ahead and push my patches into 3.3, your proposal
looks fine to me. Mark, do you want me to push the patch to Linus, or
do you want to pick it up?
Thanks.
--=20
nvpublic
^ permalink raw reply
* RE: [PATCH 2/2] Kbuild: Use dtc's -d (dependency) option
From: Mark Salter @ 2012-01-17 18:26 UTC (permalink / raw)
To: Stephen Warren
Cc: Michal Marek, Jonas Bonn, Jon Loeliger, Russell King,
linux-c6x-dev@linux-c6x.org, Arnd Bergmann, Aurelien Jacquiot,
linux@openrisc.net, linux-kbuild@vger.kernel.org, Michal Simek,
Rob Herring, linux-kernel@vger.kernel.org, Paul Mackerras,
microblaze-uclinux@itee.uq.edu.au, linuxppc-dev@lists.ozlabs.org,
Devicetree Discuss, linux-arm-kernel@lists.infradead.org,
David Gibson
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF17801D2255@HQMAIL01.nvidia.com>
On Tue, 2012-01-17 at 09:20 -0800, Stephen Warren wrote:
> Michal Marek wrote at Saturday, January 14, 2012 3:51 PM:
> > On 11.1.2012 20:36, Mark Salter wrote:
> > > On Mon, 2012-01-09 at 11:38 -0700, Stephen Warren wrote:
> > >> This hooks dtc into Kbuild's dependency system.
> > >>
> > >> Thus, for example, "make dtbs" will rebuild tegra-harmony.dtb if only
> > >> tegra20.dtsi has changed yet tegra-harmony.dts has not. The previous
> > >> lack of this feature recently caused me to have very confusing "git
> > >> bisect" results.
> > >>
> > >> For ARM, it's obvious what to add to $(targets). I'm not familiar enough
> > >> with other architectures to know what to add there. Powerpc appears to
> > >> already add various .dtb files into $(targets), but the other archs may
> > >> need something added to $(targets) to work.
> > >>
> > >> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > >>
> > >
> > > Acked-by: Mark Salter <msalter@redhat.com>
> > >
> > > For the arch/c6x bit.
> >
> > As the C6X port has been merged in this merge window, I can't easily
> > apply this patch to my kbuild branch and at the same time please Linus
> > by basing the pull request on a tagged release. So I'm going to drop the
> > arch/c6x part to keep the kbuild branch "pretty" and let either Mark or
> > Stephen send the patch to Linus directly, once he has merged the kbuild
> > branch. Would that work?
>
> I was assuming my patches were for 3.4 rather than 3.3, since it's pretty
> late for new features in 3.3. In that case, there wouldn't be an issue,
> right?
>
> If you do want to go ahead and push my patches into 3.3, your proposal
> looks fine to me. Mark, do you want me to push the patch to Linus, or
> do you want to pick it up?
It would probably be best to keep it all together, but if there's a need
to break out c6x individually, I don't mind picking it up.
--Mark
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox