* RE: [PATCH] powerpc/85xx: dts - add ranges property for SEC
From: Liu Po-B43644 @ 2013-02-20 1:37 UTC (permalink / raw)
To: Gala Kumar-B11780; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <CF1EE7AED478CD48A05574C8E2DA142D72B420@039-SN1MPN1-005.039d.mgd.msft.net>
Thanks again for the fix. Just ignore this post.
Best regards,
Liu Po
- 8038
-----Original Message-----
From: Gala Kumar-B11780=20
Sent: Wednesday, February 20, 2013 12:01 AM
To: Liu Po-B43644
Cc: <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] powerpc/85xx: dts - add ranges property for SEC
On Feb 18, 2013, at 6:29 PM, Po Liu wrote:
> This facilitates getting the physical address of the SEC node.
>=20
> Signed-off-by: Liu po <po.liu@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Why are you reposting this, I already applied it:
http://git.kernel.org/?p=3Dlinux/kernel/git/galak/powerpc.git;a=3Dcommit;h=
=3Ddb29cd3c4497e7edf9176284ba7cf3cec1814c7a
- k
^ permalink raw reply
* Please pull 'next' branch of 5xxx tree
From: Anatolij Gustschin @ 2013-02-19 23:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
Hi Ben !
Please pull mpc5xxx patches for v3.9. The bestcomm driver is
moved to drivers/dma (so it will be usable for ColdFire).
mpc5121 now provides common dtsi file and existing mpc5121 device
trees use it. There are some minor clock init and sparse fixes
and updates for various 5200 device tree files from Grant. Some
fixes for bugs in the mpc5121 DIU driver are also included here
(Andrew Morton suggested to push them via my mpc5xxx tree).
All these patches have already been in linux-next for a while.
Thanks!
Anatolij
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git next
Anatolij Gustschin (11):
powerpc/mpc5121: add common .dtsi and use it in mpc5121ads.dts
powerpc/mpc5121: pdm360ng.dts: use common mpc5121.dtsi
mpc5121: remove obsolete cell-index property from PSC clock code
mpc5121: don't check PSC ac97 using node name
powerpc/512x: initialize clocks before bus probing
drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp
drivers/video: fsl-diu-fb: fix bugs in interrupt handling
powerpc/512x: add function for chip select parameter configuration
powerpc/mpc512x: fix noderef sparse warnings
powerpc/mpc512x: fix sparce warnings for non static symbols
powerpc/mpc5xxx: fix sparse warning for non static symbol
Grant Likely (2):
powerpc/5200: Add Lite5200 on-board LEDs as devices
powerpc/5200: Use the gpt* labels to simplify mpc5200 dts files
Philippe De Muyter (1):
powerpc, dma: move bestcomm driver from arch/powerpc/sysdev to drivers/dma
arch/powerpc/boot/dts/a3m071.dts | 6 +-
arch/powerpc/boot/dts/a4m072.dts | 27 +-
arch/powerpc/boot/dts/cm5200.dts | 6 +-
arch/powerpc/boot/dts/digsy_mtc.dts | 14 +-
arch/powerpc/boot/dts/lite5200b.dts | 23 +-
arch/powerpc/boot/dts/media5200.dts | 6 +-
arch/powerpc/boot/dts/motionpro.dts | 26 +-
arch/powerpc/boot/dts/mpc5121.dtsi | 410 ++++++++++++++++++++
arch/powerpc/boot/dts/mpc5121ads.dts | 319 ++-------------
arch/powerpc/boot/dts/mpc5200b.dtsi | 25 +-
arch/powerpc/boot/dts/mucmc52.dts | 48 +--
arch/powerpc/boot/dts/o2d.dtsi | 27 +-
arch/powerpc/boot/dts/pcm030.dts | 48 +--
arch/powerpc/boot/dts/pcm032.dts | 45 +--
arch/powerpc/boot/dts/pdm360ng.dts | 273 ++------------
arch/powerpc/boot/dts/uc101.dts | 52 +--
arch/powerpc/include/asm/mpc5121.h | 17 +
arch/powerpc/platforms/512x/clock.c | 34 +-
arch/powerpc/platforms/512x/mpc512x_shared.c | 32 ++-
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 6 +-
arch/powerpc/platforms/Kconfig | 2 -
arch/powerpc/sysdev/Makefile | 1 -
arch/powerpc/sysdev/mpc5xxx_clocks.c | 4 +-
drivers/Makefile | 2 +-
drivers/ata/pata_mpc52xx.c | 6 +-
drivers/dma/Kconfig | 2 +
drivers/dma/Makefile | 1 +
.../sysdev => drivers/dma}/bestcomm/Kconfig | 0
.../sysdev => drivers/dma}/bestcomm/Makefile | 0
.../powerpc/sysdev => drivers/dma}/bestcomm/ata.c | 6 +-
.../dma}/bestcomm/bcom_ata_task.c | 0
.../dma}/bestcomm/bcom_fec_rx_task.c | 0
.../dma}/bestcomm/bcom_fec_tx_task.c | 0
.../dma}/bestcomm/bcom_gen_bd_rx_task.c | 0
.../dma}/bestcomm/bcom_gen_bd_tx_task.c | 0
.../sysdev => drivers/dma}/bestcomm/bestcomm.c | 6 +-
.../powerpc/sysdev => drivers/dma}/bestcomm/fec.c | 6 +-
.../sysdev => drivers/dma}/bestcomm/gen_bd.c | 6 +-
.../powerpc/sysdev => drivers/dma}/bestcomm/sram.c | 2 +-
drivers/net/ethernet/freescale/fec_mpc52xx.c | 4 +-
drivers/video/fsl-diu-fb.c | 64 ++--
.../sysdev => include/linux/fsl}/bestcomm/ata.h | 0
.../linux/fsl}/bestcomm/bestcomm.h | 0
.../linux/fsl}/bestcomm/bestcomm_priv.h | 0
.../sysdev => include/linux/fsl}/bestcomm/fec.h | 0
.../sysdev => include/linux/fsl}/bestcomm/gen_bd.h | 0
.../sysdev => include/linux/fsl}/bestcomm/sram.h | 0
sound/soc/fsl/mpc5200_dma.c | 4 +-
48 files changed, 716 insertions(+), 844 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc5121.dtsi
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/Kconfig (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/Makefile (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/ata.c (97%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_ata_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_fec_rx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_fec_tx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_gen_bd_rx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_gen_bd_tx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bestcomm.c (99%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/fec.c (98%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/gen_bd.c (98%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/sram.c (99%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/ata.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/bestcomm.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/bestcomm_priv.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/fec.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/gen_bd.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/sram.h (100%)
^ permalink raw reply
* Re: [PATCH][RFC] Replaced tlbilx with tlbwe in the initialization code
From: Scott Wood @ 2013-02-19 19:47 UTC (permalink / raw)
To: Diana Craciun; +Cc: linuxppc-dev
In-Reply-To: <511E513F.7090103@freescale.com>
On 02/15/2013 09:16:15 AM, Diana Craciun wrote:
> On 02/15/2013 02:11 AM, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-02-14 at 14:56 +0200, Diana Craciun wrote:
>>> From: Diana Craciun <Diana.Craciun@freescale.com>
>>>=20
>>> On Freescale e6500 cores EPCR[DGTMI] controls whether guest =20
>>> supervisor
>>> state can execute TLB management instructions. If EPCR[DGTMI]=3D0
>>> tlbwe and tlbilx are allowed to execute normally in the guest state.
>>>=20
>>> A hypervisor may choose to virtualize TLB1 and for this purpose it
>>> may use IPROT to protect the entries for being invalidated by the
>>> guest. However, because tlbwe and tlbilx execution in the guest =20
>>> state
>>> are sharing the same bit, it is not possible to have a scenario =20
>>> where
>>> tlbwe is allowed to be executed in guest state and tlbilx traps. =20
>>> When
>>> guest TLB management instructions are allowed to be executed in =20
>>> guest
>>> state the guest cannot use tlbilx to invalidate TLB1 guest entries.
>> Sorry, I don't understand the explanation... can you be more =20
>> detailed ?
>=20
> TLB1 supports huge page sizes. The guest may see the memory as =20
> contiguous but it sees the guest physical memory as presented by the =20
> hypervisor. In reality the real physical memory may be fragmented. In =20
> this case the hypervisor can add more than one TLB1 entry for one =20
> guest request and the hypervisor will keep track of all fragments. =20
> When the guest performs a tlbilx, the hypervisor will correctly =20
> invalidate all the corresponding fragments because both tlbwe and =20
> tlbilx trap and has full control of tlb management instructions =20
> targeting TLB1.
>=20
> For e6500 a single bit controls if tlbwe and tlbilx trap to the =20
> Hypervisor. tlbwe targeting TLB1 always traps. But if we want to use =20
> LRAT for TLB0, we have to configure tlbwe (targeting TLB 0) to go =20
> directly to the guest. But in this case tlbilx (which is targeting =20
> both TLBs) will never trap.
>=20
> If the tlbilx does not trap, the guest can invalidate only one of =20
> (possible more) fragments and furthermore the synchronization between =20
> what entries the hypervisor thinks there are in the TLB1 and what are =20
> the actual entries is lost.
This patch addresses boot-time invalidations only. How will you handle =20
hugetlb invalidations (or indirect entry invalidations, once that =20
becomes supported)?
-Scott=
^ permalink raw reply
* Re: [PATCH 2/2] of: use platform_device_add
From: Jason Gunthorpe @ 2013-02-19 19:03 UTC (permalink / raw)
To: Grant Likely
Cc: Russell King - ARM Linux, Linux Kernel Mailing List, Rob Herring,
Greg Kroah-Hartman, Shawn Guo, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACxGe6sJfRZ4AaDDtoQv6c-xOdB6-=cCJSn6fKawB0ULnzQFoA@mail.gmail.com>
On Sun, Feb 17, 2013 at 10:49:08AM +0000, Grant Likely wrote:
> > > The patch introduce a regression on imx6q boot. The IOMUXC block on
> > > imx6q is special. It acts not only a pin controller but also a system
> > > controller with a bunch of system level registers in there. That's why
> > > we currently have the following two nodes in imx6q device tree with the
> > > same start "reg" address, which work with drivers/mfd/syscon.c and
> > > drivers/pinctrl/pinctrl-imx6q.c respectively.
> > >
> > > gpr: iomuxc-gpr@020e0000 {
> > > compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> > > reg = <0x020e0000 0x38>;
> > > };
> > >
> > > iomuxc: iomuxc@020e0000 {
> > > compatible = "fsl,imx6q-iomuxc";
> > > reg = <0x020e0000 0x4000>;
> > > };
> > >
> > > With the patch in place, pinctrl-imx6q fails to register like below.
> > >
> > > syscon 20e0000.iomuxc: syscon regmap start 0x20e0000 end 0x20e3fff registered
> > > imx6q-pinctrl 20e0000.iomuxc: can't request region for resource [mem 0x020e0000-0x020e3fff]
> > > imx6q-pinctrl: probe of 20e0000.iomuxc failed with error -16
>
> Strictly you're not supposed to do that with the device tree. There
> shouldn't be two nodes using the same overlapping memory region unless
> they are parent/child. That rule has been around for a long time, but
> the core never checked for it. What /should/ happen is the two drivers
> should be cooperating for the register region and only one device
> driver probe sets up both behaviours.
This case was something we both discussed when this patch was first
brough up, and both our tests seemed like it was OK.. What is going on
here that these non-staggered regions are failing? It looks like the
platform devices registered but the devm_request_and_iormap failed?
> >> It also breaks all of_amba_device users.
> >>
> >> of_amba_device_create() --> amba_device_add() --> request_resource()
> >> and fails.
> >
> > Presumably that's because we no longer know what the parent resource
> > is supposed to be?
>
> Hmmm, it looks that way, yes. Currently the OF code is using
> iomem_resource as the parent for all amba_device_add() calls
> (driver/of/platform.c), but if the parent node gets registered as a
> platform device and it has the resources then the parenthood chain
> doesn't match up. It isn't immediately obvious to me how to fix this.
> I'm going to drop the patch from my tree. I could use some help
> figuring out what the correct behaviour really should be here.
I looked for a bit and it wasn't obvious to me where the colliding
request_resource was coming from. The DTs for amba busses seem to all
be placed under the root node, or within a simple bus, so there is not
parent platform device and the use of iomem_resource should still be OK?
Jason
^ permalink raw reply
* Re: PS3: Strange issue with kexec and FreeBSD loader
From: Phileas Fogg @ 2013-02-19 19:54 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
In-Reply-To: <5123C729.5040607@mail.ru>
Phileas Fogg wrote:
> I could finally find the commit which broke FreeBSD booting in linux-stable.git
> repository.
> The Linux 3.4-rc1 seems to have this problem already.
>
> --------------
> commit 5375871d432ae9fc581014ac117b96aaee3cd0c7
> Merge: b57cb72 dfbc2d7
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed Mar 21 18:55:10 2012 -0700
>
> Merge branch 'next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
>
> Pull powerpc merge from Benjamin Herrenschmidt:
> "Here's the powerpc batch for this merge window. It is going to be a
> bit more nasty than usual as in touching things outside of
> arch/powerpc mostly due to the big iSeriesectomy :-) We finally got
> rid of the bugger (legacy iSeries support) which was a PITA to
> maintain and that nobody really used anymore.
>
> Here are some of the highlights:
>
> - Legacy iSeries is gone. Thanks Stephen ! There's still some bits
> and pieces remaining if you do a grep -ir series arch/powerpc but
> they are harmless and will be removed in the next few weeks
> hopefully.
>
> - The 'fadump' functionality (Firmware Assisted Dump) replaces the
> previous (equivalent) "pHyp assisted dump"... it's a rewrite of a
> mechanism to get the hypervisor to do crash dumps on pSeries, the
> new implementation hopefully being much more reliable. Thanks
> Mahesh Salgaonkar.
>
> - The "EEH" code (pSeries PCI error handling & recovery) got a big
> spring cleaning, motivated by the need to be able to implement a
> new backend for it on top of some new different type of firwmare.
>
> The work isn't complete yet, but a good chunk of the cleanups is
> there. Note that this adds a field to struct device_node which is
> not very nice and which Grant objects to. I will have a patch soon
> that moves that to a powerpc private data structure (hopefully
> before rc1) and we'll improve things further later on (hopefully
> getting rid of the need for that pointer completely). Thanks Gavin
> Shan.
>
> - I dug into our exception & interrupt handling code to improve the
> way we do lazy interrupt handling (and make it work properly with
> "edge" triggered interrupt sources), and while at it found & fixed
> a wagon of issues in those areas, including adding support for page
> fault retry & fatal signals on page faults.
>
> - Your usual random batch of small fixes & updates, including a bunch
> of new embedded boards, both Freescale and APM based ones, etc..."
>
> I fixed up some conflicts with the generalized irq-domain changes from
> Grant Likely, hopefully correctly.
>
> * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
> (141 commits)
> powerpc/ps3: Do not adjust the wrapper load address
> powerpc: Remove the rest of the legacy iSeries include files
> powerpc: Remove the remaining CONFIG_PPC_ISERIES pieces
> init: Remove CONFIG_PPC_ISERIES
> powerpc: Remove FW_FEATURE ISERIES from arch code
> tty/hvc_vio: FW_FEATURE_ISERIES is no longer selectable
> powerpc/spufs: Fix double unlocks
> powerpc/5200: convert mpc5200 to use of_platform_populate()
> powerpc/mpc5200: add options to mpc5200_defconfig
> powerpc/mpc52xx: add a4m072 board support
> powerpc/mpc5200: update mpc5200_defconfig to fit for charon board
> Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup
> powerpc/44x: Add additional device support for APM821xx SoC and Bluestone
> board
> powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
> MAINTAINERS: Update PowerPC 4xx tree
> powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board
> powerpc: document the FSL MPIC message register binding
> powerpc: add support for MPIC message register API
> powerpc/fsl: Added aliased MSIIR register address to MSI node in dts
> powerpc/85xx: mpc8548cds - add 36-bit dts
> ...
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Reverting this commit fixes the problem with SHA256 checkusm in the purgatory
code too. I'm trying to find out which commit exactly caused the problem.
regards
^ permalink raw reply
* Re: [PATCH v5 29/45] x86/xen: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Srivatsa S. Bhat @ 2013-02-19 18:29 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-doc, peterz, fweisbec, linux-kernel, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev, oleg, sbw,
tj, akpm, linuxppc-dev
In-Reply-To: <20130219181038.GB18244@phenom.dumpdata.com>
On 02/19/2013 11:40 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 22, 2013 at 01:10:51PM +0530, Srivatsa S. Bhat wrote:
>> Once stop_machine() is gone from the CPU offline path, we won't be able to
>> depend on preempt_disable() or local_irq_disable() to prevent CPUs from
>> going offline from under us.
>>
>> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
>> while invoking from atomic context.
>>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> Weird. I see this in the patch but I don't see it in the header?
Meaning, you didn't get this email at all?
> Did you
> explicitly suppress the CC part?
>
No.. I sent the entire patchset to a set of email ids and in addition to
that I CC'ed individual patches to the respective maintainers/lists (the
CC: list in the changelog). I used the --auto knob from stgit to do that.
>
> Anyhow, the patch looks sane enough, thought I need to to run it through
> a test framework just to be on a sure side.
>
Sure, thank you. But you might want to test the v6 that I sent out
yesterday instead of v5. Oh, wait a min, you didn't get the v6 mail also?
Here it is, for your reference:
http://marc.info/?l=linux-kernel&m=136119260122255&w=2
Regards,
Srivatsa S. Bhat
>> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Cc: xen-devel@lists.xensource.com
>> Cc: virtualization@lists.linux-foundation.org
>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>> ---
^ permalink raw reply
* Re: [PATCH v5 29/45] x86/xen: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Konrad Rzeszutek Wilk @ 2013-02-19 18:10 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: linux-doc, peterz, fweisbec, linux-kernel, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev, oleg, sbw,
tj, akpm, linuxppc-dev
In-Reply-To: <20130122074046.13822.61950.stgit@srivatsabhat.in.ibm.com>
On Tue, Jan 22, 2013 at 01:10:51PM +0530, Srivatsa S. Bhat wrote:
> Once stop_machine() is gone from the CPU offline path, we won't be able to
> depend on preempt_disable() or local_irq_disable() to prevent CPUs from
> going offline from under us.
>
> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
> while invoking from atomic context.
>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Weird. I see this in the patch but I don't see it in the header? Did you
explicitly suppress the CC part?
Anyhow, the patch looks sane enough, thought I need to to run it through
a test framework just to be on a sure side.
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> ---
>
> arch/x86/xen/mmu.c | 11 +++++++++--
> arch/x86/xen/smp.c | 9 +++++++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 01de35c..6a95a15 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -39,6 +39,7 @@
> * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
> */
> #include <linux/sched.h>
> +#include <linux/cpu.h>
> #include <linux/highmem.h>
> #include <linux/debugfs.h>
> #include <linux/bug.h>
> @@ -1163,9 +1164,13 @@ static void xen_drop_mm_ref(struct mm_struct *mm)
> */
> static void xen_exit_mmap(struct mm_struct *mm)
> {
> - get_cpu(); /* make sure we don't move around */
> + /*
> + * Make sure we don't move around, and prevent CPUs from going
> + * offline.
> + */
> + get_online_cpus_atomic();
> xen_drop_mm_ref(mm);
> - put_cpu();
> + put_online_cpus_atomic();
>
> spin_lock(&mm->page_table_lock);
>
> @@ -1371,6 +1376,7 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
> args->op.arg2.vcpumask = to_cpumask(args->mask);
>
> /* Remove us, and any offline CPUS. */
> + get_online_cpus_atomic();
> cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
> cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));
>
> @@ -1383,6 +1389,7 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
> MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);
>
> xen_mc_issue(PARAVIRT_LAZY_MMU);
> + put_online_cpus_atomic();
> }
>
> static unsigned long xen_read_cr3(void)
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 4f7d259..7d753ae 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -16,6 +16,7 @@
> #include <linux/err.h>
> #include <linux/slab.h>
> #include <linux/smp.h>
> +#include <linux/cpu.h>
> #include <linux/irq_work.h>
>
> #include <asm/paravirt.h>
> @@ -487,8 +488,10 @@ static void __xen_send_IPI_mask(const struct cpumask *mask,
> {
> unsigned cpu;
>
> + get_online_cpus_atomic();
> for_each_cpu_and(cpu, mask, cpu_online_mask)
> xen_send_IPI_one(cpu, vector);
> + put_online_cpus_atomic();
> }
>
> static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
> @@ -551,8 +554,10 @@ void xen_send_IPI_all(int vector)
> {
> int xen_vector = xen_map_vector(vector);
>
> + get_online_cpus_atomic();
> if (xen_vector >= 0)
> __xen_send_IPI_mask(cpu_online_mask, xen_vector);
> + put_online_cpus_atomic();
> }
>
> void xen_send_IPI_self(int vector)
> @@ -572,20 +577,24 @@ void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> if (!(num_online_cpus() > 1))
> return;
>
> + get_online_cpus_atomic();
> for_each_cpu_and(cpu, mask, cpu_online_mask) {
> if (this_cpu == cpu)
> continue;
>
> xen_smp_send_call_function_single_ipi(cpu);
> }
> + put_online_cpus_atomic();
> }
>
> void xen_send_IPI_allbutself(int vector)
> {
> int xen_vector = xen_map_vector(vector);
>
> + get_online_cpus_atomic();
> if (xen_vector >= 0)
> xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vector);
> + put_online_cpus_atomic();
> }
>
> static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: PS3: Strange issue with kexec and FreeBSD loader
From: Phileas Fogg @ 2013-02-19 18:40 UTC (permalink / raw)
To: Phileas Fogg; +Cc: linuxppc-dev
In-Reply-To: <1360365046.495584377@f356.mail.ru>
I could finally find the commit which broke FreeBSD booting in linux-stable.git
repository.
The Linux 3.4-rc1 seems to have this problem already.
--------------
commit 5375871d432ae9fc581014ac117b96aaee3cd0c7
Merge: b57cb72 dfbc2d7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed Mar 21 18:55:10 2012 -0700
Merge branch 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull powerpc merge from Benjamin Herrenschmidt:
"Here's the powerpc batch for this merge window. It is going to be a
bit more nasty than usual as in touching things outside of
arch/powerpc mostly due to the big iSeriesectomy :-) We finally got
rid of the bugger (legacy iSeries support) which was a PITA to
maintain and that nobody really used anymore.
Here are some of the highlights:
- Legacy iSeries is gone. Thanks Stephen ! There's still some bits
and pieces remaining if you do a grep -ir series arch/powerpc but
they are harmless and will be removed in the next few weeks
hopefully.
- The 'fadump' functionality (Firmware Assisted Dump) replaces the
previous (equivalent) "pHyp assisted dump"... it's a rewrite of a
mechanism to get the hypervisor to do crash dumps on pSeries, the
new implementation hopefully being much more reliable. Thanks
Mahesh Salgaonkar.
- The "EEH" code (pSeries PCI error handling & recovery) got a big
spring cleaning, motivated by the need to be able to implement a
new backend for it on top of some new different type of firwmare.
The work isn't complete yet, but a good chunk of the cleanups is
there. Note that this adds a field to struct device_node which is
not very nice and which Grant objects to. I will have a patch soon
that moves that to a powerpc private data structure (hopefully
before rc1) and we'll improve things further later on (hopefully
getting rid of the need for that pointer completely). Thanks Gavin
Shan.
- I dug into our exception & interrupt handling code to improve the
way we do lazy interrupt handling (and make it work properly with
"edge" triggered interrupt sources), and while at it found & fixed
a wagon of issues in those areas, including adding support for page
fault retry & fatal signals on page faults.
- Your usual random batch of small fixes & updates, including a bunch
of new embedded boards, both Freescale and APM based ones, etc..."
I fixed up some conflicts with the generalized irq-domain changes from
Grant Likely, hopefully correctly.
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
(141 commits)
powerpc/ps3: Do not adjust the wrapper load address
powerpc: Remove the rest of the legacy iSeries include files
powerpc: Remove the remaining CONFIG_PPC_ISERIES pieces
init: Remove CONFIG_PPC_ISERIES
powerpc: Remove FW_FEATURE ISERIES from arch code
tty/hvc_vio: FW_FEATURE_ISERIES is no longer selectable
powerpc/spufs: Fix double unlocks
powerpc/5200: convert mpc5200 to use of_platform_populate()
powerpc/mpc5200: add options to mpc5200_defconfig
powerpc/mpc52xx: add a4m072 board support
powerpc/mpc5200: update mpc5200_defconfig to fit for charon board
Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup
powerpc/44x: Add additional device support for APM821xx SoC and Bluestone
board
powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
MAINTAINERS: Update PowerPC 4xx tree
powerpc/44x: The bug fixed support for APM821xx SoC and Bluestone board
powerpc: document the FSL MPIC message register binding
powerpc: add support for MPIC message register API
powerpc/fsl: Added aliased MSIIR register address to MSI node in dts
powerpc/85xx: mpc8548cds - add 36-bit dts
...
^ permalink raw reply
* Re: [PATCH] bsc9131:l2sram: Add compatible string for BSC9131 platform
From: Gala Kumar-B11780 @ 2013-02-19 17:18 UTC (permalink / raw)
To: Rai Harninder-B01044; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <1361265261-28169-1-git-send-email-harninder.rai@freescale.com>
On Feb 19, 2013, at 3:14 AM, Harninder Rai wrote:
> Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] bsc9131/dts: Correct typo in SDHC device node
From: Gala Kumar-B11780 @ 2013-02-19 17:18 UTC (permalink / raw)
To: Rai Harninder-B01044; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <1361265238-28100-1-git-send-email-harninder.rai@freescale.com>
On Feb 19, 2013, at 3:13 AM, Harninder Rai wrote:
> BSC9131RDB doesn't have SDHC enabled. As a result of this typo,
> the node was not getting disabled from the device tree which was
> leading to linux hang during bootup
>=20
> Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
> ---
> arch/powerpc/boot/dts/bsc9131rdb.dtsi | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Kumar Gala @ 2013-02-19 17:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Mostly misc code cleanups in various board ports and adding support for a
new MPC85xx board - ppa8548.
- k
The following changes since commit 2468dcf641e4f3e1b0153e3e11ca20740b2f4ce8:
Ian Munsie (1):
powerpc: Add support for context switching the TAR register
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next
Gerlando Falauto (2):
powerpc/83xx: refactor mpc8360e quirk for kmeter1
powerpc/83xx: apply mpc8360e quirk for kmeter1 only when par_io is present
Harninder Rai (2):
powerpc/85xx: bsc9131 - Correct typo in SDHC device node
powerpc/85xx: l2sram - Add compatible string for BSC9131 platform
Holger Brunck (3):
powerpc/82xx: fix checkpatch warnings for km82xx.c
powerpc/83xx: fix checkpatch warnings for km83xx.c
powerpc/83xx: update kmeter1_defconfig
Julia Lawall (1):
arch/powerpc/platforms/85xx/p1022_ds.c: adjust duplicate test
Kim Phillips (4):
powerpc/fsl: lbc: sparse fixes
powerpc/fsl: fsl_soc: sparse fixes
powerpc/fsl: ifc: sparse fixes
powerpc/fsl: msi: sparse fixes
Paul Gortmaker (4):
powerpc/85xx: split sbc8548 dts file into pre and post chunks
powerpc/85xx: update sbc8548 flash information to match recent u-boot
powerpc/85xx: add alternate dts file for sbc8548 boot via SODIMM
powerpc/85xx: enable MTD options in sbc8548 defconfig
Po Liu (1):
powerpc/85xx: dts - add ranges property for SEC
Scott Wood (2):
powerpc/mpic: allow coreint to be determined by MPIC version
powerpc/e500/qemu-e500: enable coreint
Stef van Os (1):
powerpc/85xx: Board support for ppa8548
Timur Tabi (3):
powerpc/85xx: describe the PAMU topology in the device tree
powerpc/85xx: fix various PCI node compatible strings
powerpc/fsl: remove extraneous DIU platform functions
Vakul Garg (1):
crypto: caam - Added property fsl, sec-era in SEC4.0 device tree binding.
Varun Sethi (1):
powerpc/fsl_pci: Store the pci ctlr device ptr in the pci ctlr struct
Wei Yongjun (1):
powerpc/85xx: use for_each_compatible_node() macro
.../devicetree/bindings/crypto/fsl-sec4.txt | 12 +-
.../devicetree/bindings/powerpc/fsl/guts.txt | 13 +-
.../devicetree/bindings/powerpc/fsl/pamu.txt | 140 ++++++++
arch/powerpc/boot/dts/bsc9131rdb.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 4 +-
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 6 +-
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 87 ++++-
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 87 ++++-
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 74 +++-
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 92 ++++-
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 92 ++++-
arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 1 +
arch/powerpc/boot/dts/ppa8548.dts | 166 +++++++++
arch/powerpc/boot/dts/sbc8548-altflash.dts | 115 +++++++
arch/powerpc/boot/dts/sbc8548-post.dtsi | 295 ++++++++++++++++
arch/powerpc/boot/dts/sbc8548-pre.dtsi | 52 +++
arch/powerpc/boot/dts/sbc8548.dts | 356 ++------------------
arch/powerpc/configs/83xx/kmeter1_defconfig | 6 +-
arch/powerpc/configs/85xx/ppa8548_defconfig | 65 ++++
arch/powerpc/configs/85xx/sbc8548_defconfig | 19 ++
arch/powerpc/platforms/512x/mpc512x_shared.c | 5 -
arch/powerpc/platforms/82xx/km82xx.c | 6 +-
arch/powerpc/platforms/83xx/km83xx.c | 161 ++++-----
arch/powerpc/platforms/85xx/Kconfig | 7 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
arch/powerpc/platforms/85xx/p1022_ds.c | 40 +--
arch/powerpc/platforms/85xx/p1022_rdk.c | 12 -
arch/powerpc/platforms/85xx/ppa8548.c | 98 ++++++
arch/powerpc/platforms/85xx/qemu_e500.c | 7 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
arch/powerpc/sysdev/fsl_ifc.c | 2 +-
arch/powerpc/sysdev/fsl_lbc.c | 6 +-
arch/powerpc/sysdev/fsl_msi.c | 4 +-
arch/powerpc/sysdev/fsl_pci.c | 24 +-
arch/powerpc/sysdev/fsl_pci.h | 2 +-
arch/powerpc/sysdev/fsl_soc.c | 4 +-
arch/powerpc/sysdev/mpic.c | 26 +-
38 files changed, 1530 insertions(+), 564 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
create mode 100644 arch/powerpc/boot/dts/ppa8548.dts
create mode 100644 arch/powerpc/boot/dts/sbc8548-altflash.dts
create mode 100644 arch/powerpc/boot/dts/sbc8548-post.dtsi
create mode 100644 arch/powerpc/boot/dts/sbc8548-pre.dtsi
create mode 100644 arch/powerpc/configs/85xx/ppa8548_defconfig
create mode 100644 arch/powerpc/platforms/85xx/ppa8548.c
^ permalink raw reply
* Re: [PATCH] bsc913x:defconfig: Add new defconfig file for BSC913x platforms
From: Gala Kumar-B11780 @ 2013-02-19 16:01 UTC (permalink / raw)
To: Rai Harninder-B01044; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <1361265290-28206-1-git-send-email-harninder.rai@freescale.com>
On Feb 19, 2013, at 3:14 AM, Harninder Rai wrote:
> BSC913x are heterogeneous platforms having DSP and PowerPC.
> * Lot of new IPs like AIC (Antenna Interface Controller), RF (radio) etc
> * Such IPs are not present in any other 85xx platform
> * Lot of optimizations related to ethernet/ASF (Application Specific Fast=
path)
> are enabled in this config
> * IPC for inter-domain communication (DSP and PA) is present
>=20
> Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
> ---
> arch/powerpc/configs/qoriq_sdk_asf_term_defconfig | 209 ++++++++++++++++=
+++++
> 1 files changed, 209 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/configs/qoriq_sdk_asf_term_defconfig
I'm ignoring this as this is clearly meant for FSL SDK and not upstream.
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: dts - add ranges property for SEC
From: Gala Kumar-B11780 @ 2013-02-19 16:01 UTC (permalink / raw)
To: Liu Po-B43644; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <1361233746-19106-1-git-send-email-po.liu@freescale.com>
On Feb 18, 2013, at 6:29 PM, Po Liu wrote:
> This facilitates getting the physical address of the SEC node.
>=20
> Signed-off-by: Liu po <po.liu@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Why are you reposting this, I already applied it:
http://git.kernel.org/?p=3Dlinux/kernel/git/galak/powerpc.git;a=3Dcommit;h=
=3Ddb29cd3c4497e7edf9176284ba7cf3cec1814c7a
- k=
^ permalink raw reply
* Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Diana Craciun @ 2013-02-19 15:59 UTC (permalink / raw)
To: Varun Sethi
Cc: joro, stuart.yoder, linux-kernel, iommu, scottwood, linuxppc-dev
In-Reply-To: <1361191939-21260-7-git-send-email-Varun.Sethi@freescale.com>
On 02/18/2013 02:52 PM, Varun Sethi wrote:
> +/**
> + * pamu_get_ppaace() - Return the primary PACCE
> + * @liodn: liodn PAACT index for desired PAACE
> + *
> + * Returns the ppace pointer upon success else return
> + * null.
> + */
> +static struct paace *pamu_get_ppaace(int liodn)
> +{
> + if (!ppaact || liodn > PAACE_NUMBER_ENTRIES) {
Shouldn't be "liodn >= PAACE_NUMBER_ENTRIES" ?
> + pr_err("PPAACT doesn't exist\n");
> + return NULL;
> + }
> +
> + return &ppaact[liodn];
> +}
> +
Diana
^ permalink raw reply
* Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: Srivatsa S. Bhat @ 2013-02-19 10:58 UTC (permalink / raw)
To: David Laight
Cc: linux-doc, peterz, fweisbec, linux-kernel, namhyung,
Michel Lespinasse, mingo, linux-arch, linux, xiaoguangrong,
wangyun, paulmck, nikunj, linux-pm, rusty, rostedt, rjw,
vincent.guittot, tglx, linux-arm-kernel, netdev, oleg, sbw, tj,
akpm, linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7154@saturn3.aculab.com>
On 02/19/2013 04:12 PM, David Laight wrote:
>> I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
>> IMHO, the warning/documentation should suffice for anybody wanting to
>> try out this locking scheme for other use-cases.
>
> I presume that by 'fairness' you mean 'write preference'?
>
Yep.
> I'd not sure how difficult it would be, but maybe have two functions
> for acquiring the lock for read, one blocks if there is a writer
> waiting, the other doesn't.
>
> That way you can change the individual call sites separately.
>
Right, we could probably use that method to change the call sites in
multiple stages, in the future.
> The other place I can imagine a per-cpu rwlock being used
> is to allow a driver to disable 'sleep' or software controlled
> hardware removal while it performs a sequence of operations.
>
BTW, per-cpu rwlocks use spinlocks underneath, so they can be used only
in atomic contexts (you can't sleep holding this lock). So that would
probably make it less attractive or useless to "heavy-weight" usecases
like the latter one you mentioned. They probably need to use per-cpu
rw-semaphore or some such, which allows sleeping. I'm not very certain
of the exact usecases you are talking about, but I just wanted to
point out that percpu-rwlocks might not be applicable to many scenarios.
..(which might be a good thing, considering its unfair property today).
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* RE: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: David Laight @ 2013-02-19 10:42 UTC (permalink / raw)
To: Srivatsa S. Bhat, Michel Lespinasse
Cc: linux-doc, peterz, fweisbec, linux-kernel, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev, oleg,
vincent.guittot, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <51234C23.2030909@linux.vnet.ibm.com>
> I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
> IMHO, the warning/documentation should suffice for anybody wanting to
> try out this locking scheme for other use-cases.
I presume that by 'fairness' you mean 'write preference'?
I'd not sure how difficult it would be, but maybe have two functions
for acquiring the lock for read, one blocks if there is a writer
waiting, the other doesn't.
That way you can change the individual call sites separately.
The other place I can imagine a per-cpu rwlock being used
is to allow a driver to disable 'sleep' or software controlled
hardware removal while it performs a sequence of operations.
David
^ permalink raw reply
* Re: [PATCH v5 00/45] CPU hotplug: stop_machine()-free CPU hotplug
From: Vincent Guittot @ 2013-02-19 10:33 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-doc, peterz, fweisbec, linux-kernel, walken, mingo,
linux-arch, Russell King - ARM Linux, xiaoguangrong, wangyun,
paulmck, nikunj, linux-pm, Rusty Russell, rjw, namhyung, tglx,
linux-arm-kernel, netdev, oleg, sbw, Srivatsa S. Bhat, tj, akpm,
linuxppc-dev
In-Reply-To: <1361217204.23152.171.camel@gandalf.local.home>
On 18 February 2013 20:53, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 2013-02-18 at 17:50 +0100, Vincent Guittot wrote:
>
>> yes for sure.
>> The problem is more linked to cpuidle and function tracer.
>>
>> cpu hotplug and function tracer work when cpuidle is disable.
>> cpu hotplug and cpuidle works if i don't enable function tracer.
>> my platform is dead as soon as I enable function tracer if cpuidle is
>> enabled. It looks like some notrace are missing in my platform driver
>> but we haven't completely fix the issue yet
>>
>
> You can bisect to find out exactly what function is the problem:
>
> cat /debug/tracing/available_filter_functions > t
>
> f(t) {
> num=`wc -l t`
> sed -ne "1,${num}p" t > t1
> let num=num+1
> sed -ne "${num},$p" t > t2
>
> cat t1 > /debug/tracing/set_ftrace_filter
> # note this may take a long time to finish
>
> echo function > /debug/tracing/current_tracer
>
> <failed? bisect f(t1), if not bisect f(t2)>
> }
>
Thanks, i'm going to have a look
Vincent
> -- Steve
>
>
>
^ permalink raw reply
* RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Sethi Varun-B16395 @ 2013-02-19 10:27 UTC (permalink / raw)
To: Craciun Diana Madalina-STFD002
Cc: Wood Scott-B07421, joro@8bytes.org, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <51234E27.9020604@freescale.com>
> -----Original Message-----
> From: Craciun Diana Madalina-STFD002
> Sent: Tuesday, February 19, 2013 3:34 PM
> To: Sethi Varun-B16395
> Cc: iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
> linux-kernel@vger.kernel.org; Wood Scott-B07421; joro@8bytes.org; Yoder
> Stuart-B08248
> Subject: Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU
> API implementation.
>=20
> On 02/18/2013 02:52 PM, Varun Sethi wrote:
> > +
> > +#define PAACE_TCEF_FORMAT0_8B 0x00
> > +#define PAACE_TCEF_FORMAT1_RSVD 0x01
> > +
> > +#define PAACE_NUMBER_ENTRIES 0x1FF
>=20
> Where is this number coming from?
>=20
This is currently hard coded. We will not require these many entries once w=
e implement the LIODN allocation scheme.
-Varun
^ permalink raw reply
* Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Diana Craciun @ 2013-02-19 10:04 UTC (permalink / raw)
To: Varun Sethi
Cc: joro, stuart.yoder, linux-kernel, iommu, scottwood, linuxppc-dev
In-Reply-To: <1361191939-21260-7-git-send-email-Varun.Sethi@freescale.com>
On 02/18/2013 02:52 PM, Varun Sethi wrote:
> +
> +#define PAACE_TCEF_FORMAT0_8B 0x00
> +#define PAACE_TCEF_FORMAT1_RSVD 0x01
> +
> +#define PAACE_NUMBER_ENTRIES 0x1FF
Where is this number coming from?
Diana
^ permalink raw reply
* Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: Srivatsa S. Bhat @ 2013-02-19 9:55 UTC (permalink / raw)
To: Michel Lespinasse
Cc: linux-doc, peterz, fweisbec, linux-kernel, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev, oleg,
vincent.guittot, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <CANN689E-98zK69pGeojbm30n3sswQYVBvhk3i3OzqvbeqSrSrg@mail.gmail.com>
On 02/19/2013 03:10 PM, Michel Lespinasse wrote:
> On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat
> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>> But, the whole intention behind removing the parts depending on the
>> recursive property of rwlocks would be to make it easier to make rwlocks
>> fair (going forward) right? Then, that won't work for CPU hotplug, because,
>> just like we have a legitimate reason to have recursive
>> get_online_cpus_atomic(), we also have a legitimate reason to have
>> unfairness in locking (i.e., for deadlock-safety). So we simply can't
>> afford to make the locking fair - we'll end up in too many deadlock
>> possibilities, as hinted in the changelog of patch 1.
>
> Grumpf - I hadn't realized that making the underlying rwlock fair
> would break your hotplug use case. But you are right, it would. Oh
> well :/
>
Yeah :-/
>> So the only long-term solution I can think of is to decouple
>> percpu-rwlocks and rwlock_t (like what Tejun suggested) by implementing
>> our own unfair locking scheme inside. What do you think?
>
> I have no idea how hard would it be to change get_online_cpus_atomic()
> call sites so that the hotplug rwlock read side has a defined order vs
> other locks (thus making sure the situation you describe in patch 1
> doesn't happen). I agree we shouldn't base our short term plans around
> that, but maybe that's doable in the long term ???
>
I think it should be possible in the longer term. I'm expecting it to be
*much much* harder to audit and convert (requiring a lot of subsystem
knowledge of each subsystem that we are touching), than the simpler
tree-wide conversion that I did in this patchset... but I don't think it
is impossible.
> Otherwise, I think we should add some big-fat-warning that percpu
> rwlocks don't have reader/writer fairness, that the hotplug use case
> actually depends on the unfairness / would break if the rwlock was
> made fair, and that any new uses of percpu rwlocks should be very
> carefully considered because of the reader/writer fairness issues.
In fact, when I started out, I actually contained all the new locking code
inside CPU hotplug itself, and didn't even expose it as a generic percpu
rwlock in some of the previous versions of this patchset... :-)
But now that we already have a generic locking scheme exposed, we could
add a warning against using it without due consideration.
> Maybe even give percpu rwlocks a less generic sounding name, given how
> constrained they are by the hotplug use case.
I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
IMHO, the warning/documentation should suffice for anybody wanting to
try out this locking scheme for other use-cases.
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: Michel Lespinasse @ 2013-02-19 9:40 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: linux-doc, peterz, fweisbec, linux-kernel, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev, oleg,
vincent.guittot, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <51227810.6090009@linux.vnet.ibm.com>
On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat
<srivatsa.bhat@linux.vnet.ibm.com> wrote:
> But, the whole intention behind removing the parts depending on the
> recursive property of rwlocks would be to make it easier to make rwlocks
> fair (going forward) right? Then, that won't work for CPU hotplug, because,
> just like we have a legitimate reason to have recursive
> get_online_cpus_atomic(), we also have a legitimate reason to have
> unfairness in locking (i.e., for deadlock-safety). So we simply can't
> afford to make the locking fair - we'll end up in too many deadlock
> possibilities, as hinted in the changelog of patch 1.
Grumpf - I hadn't realized that making the underlying rwlock fair
would break your hotplug use case. But you are right, it would. Oh
well :/
> So the only long-term solution I can think of is to decouple
> percpu-rwlocks and rwlock_t (like what Tejun suggested) by implementing
> our own unfair locking scheme inside. What do you think?
I have no idea how hard would it be to change get_online_cpus_atomic()
call sites so that the hotplug rwlock read side has a defined order vs
other locks (thus making sure the situation you describe in patch 1
doesn't happen). I agree we shouldn't base our short term plans around
that, but maybe that's doable in the long term ???
Otherwise, I think we should add some big-fat-warning that percpu
rwlocks don't have reader/writer fairness, that the hotplug use case
actually depends on the unfairness / would break if the rwlock was
made fair, and that any new uses of percpu rwlocks should be very
carefully considered because of the reader/writer fairness issues.
Maybe even give percpu rwlocks a less generic sounding name, given how
constrained they are by the hotplug use case.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply
* [PATCH] bsc913x:defconfig: Add new defconfig file for BSC913x platforms
From: Harninder Rai @ 2013-02-19 9:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Harninder Rai, kumar.gala
BSC913x are heterogeneous platforms having DSP and PowerPC.
* Lot of new IPs like AIC (Antenna Interface Controller), RF (radio) etc
* Such IPs are not present in any other 85xx platform
* Lot of optimizations related to ethernet/ASF (Application Specific Fastpath)
are enabled in this config
* IPC for inter-domain communication (DSP and PA) is present
Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
---
arch/powerpc/configs/qoriq_sdk_asf_term_defconfig | 209 +++++++++++++++++++++
1 files changed, 209 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/configs/qoriq_sdk_asf_term_defconfig
diff --git a/arch/powerpc/configs/qoriq_sdk_asf_term_defconfig b/arch/powerpc/configs/qoriq_sdk_asf_term_defconfig
new file mode 100644
index 0000000..6ded6af
--- /dev/null
+++ b/arch/powerpc/configs/qoriq_sdk_asf_term_defconfig
@@ -0,0 +1,209 @@
+CONFIG_PPC_85xx=y
+CONFIG_EXPERIMENTAL=y
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_AUDIT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+# CONFIG_PERF_EVENTS is not set
+CONFIG_SLAB=y
+CONFIG_PROFILING=y
+CONFIG_OPROFILE=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_MAC_PARTITION=y
+# CONFIG_EFI_PARTITION is not set
+CONFIG_BSC9131_RDB=y
+CONFIG_HIGHMEM=y
+CONFIG_PREEMPT=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_MATH_EMULATION=y
+CONFIG_SWIOTLB=y
+CONFIG_PCI=y
+CONFIG_PCIEPORTBUS=y
+# CONFIG_PCIEAER is not set
+# CONFIG_PCIEASPM is not set
+CONFIG_PCI_MSI=y
+CONFIG_ADVANCED_OPTIONS=y
+CONFIG_LOWMEM_CAM_NUM_BOOL=y
+CONFIG_LOWMEM_CAM_NUM=6
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=y
+CONFIG_NET_KEY=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPIP=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
+CONFIG_ARPD=y
+CONFIG_INET_AH=y
+CONFIG_INET_ESP=y
+CONFIG_INET_IPCOMP=y
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_INET6_AH=y
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=y
+CONFIG_NF_CONNTRACK_EVENTS=y
+CONFIG_NF_CONNTRACK_FTP=y
+CONFIG_NF_CONNTRACK_TFTP=y
+CONFIG_NETFILTER_XT_MATCH_HL=y
+CONFIG_NF_CONNTRACK_IPV4=y
+CONFIG_IP_NF_IPTABLES=y
+CONFIG_IP_NF_FILTER=y
+CONFIG_IP_NF_TARGET_REJECT=y
+CONFIG_IP_NF_MANGLE=y
+CONFIG_BRIDGE=y
+CONFIG_VLAN_8021Q=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+CONFIG_FTL=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_PLATFORM=y
+CONFIG_MTD_NAND_FSL_ELBC=y
+CONFIG_MTD_NAND_FSL_IFC=y
+CONFIG_MTD_NAND_FSL_UPM=y
+CONFIG_MTD_UBI=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_ST=y
+CONFIG_BLK_DEV_SR=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_MULTI_LUN=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_ATA=y
+CONFIG_SATA_AHCI=y
+CONFIG_SATA_FSL=y
+CONFIG_SATA_SIL24=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_MD=y
+# CONFIG_MD_AUTODETECT is not set
+CONFIG_MD_RAID456=y
+CONFIG_NETDEVICES=y
+CONFIG_DUMMY=y
+CONFIG_MII=y
+# CONFIG_NET_VENDOR_3COM is not set
+CONFIG_GIANFAR=y
+CONFIG_E1000E=y
+CONFIG_VITESSE_PHY=y
+CONFIG_FIXED_PHY=y
+CONFIG_PPP=y
+CONFIG_PPPOE=y
+CONFIG_PPP_ASYNC=y
+CONFIG_INPUT_FF_MEMLESS=m
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_SERIO_LIBPS2=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_DETECT_IRQ=y
+CONFIG_SERIAL_8250_RSA=y
+CONFIG_NVRAM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MPC=y
+CONFIG_SPI=y
+CONFIG_SPI_BITBANG=y
+CONFIG_SPI_FSL_SPI=y
+CONFIG_SPI_FSL_ESPI=y
+CONFIG_GPIOLIB=y
+# CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_NOWAYOUT=y
+CONFIG_BOOKE_WDT=y
+CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+# CONFIG_USB_EHCI_TT_NEWSCHED is not set
+CONFIG_USB_EHCI_FSL=y
+CONFIG_USB_STORAGE=y
+CONFIG_MMC=y
+CONFIG_MMC_UNSAFE_RESUME=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_OF_ESDHC=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS1307=y
+CONFIG_RTC_DRV_DS3232=y
+CONFIG_RTC_DRV_CMOS=y
+CONFIG_DMADEVICES=y
+CONFIG_FSL_DMA=y
+# CONFIG_NET_DMA is not set
+CONFIG_ASYNC_TX_DMA=y
+CONFIG_UIO=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_XFS_FS=y
+CONFIG_ISO9660_FS=m
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=m
+CONFIG_VFAT_FS=y
+CONFIG_NTFS_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_JFFS2_FS_DEBUG=1
+CONFIG_JFFS2_FS_WBUF_VERIFY=y
+CONFIG_JFFS2_SUMMARY=y
+CONFIG_JFFS2_FS_XATTR=y
+CONFIG_JFFS2_COMPRESSION_OPTIONS=y
+CONFIG_JFFS2_LZO=y
+CONFIG_JFFS2_RUBIN=y
+CONFIG_UBIFS_FS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NFSD=y
+CONFIG_CIFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_CRC_T10DIF=y
+# CONFIG_FTRACE is not set
+CONFIG_CRYPTO_NULL=y
+CONFIG_CRYPTO_CTR=y
+CONFIG_CRYPTO_PCBC=y
+CONFIG_CRYPTO_XCBC=y
+CONFIG_CRYPTO_SHA512=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRYPTO_DEV_FSL_CAAM=y
+CONFIG_CRYPTO_DEV_FSL_CAAM_INTC=y
--
1.7.6.GIT
^ permalink raw reply related
* [PATCH] bsc9131:l2sram: Add compatible string for BSC9131 platform
From: Harninder Rai @ 2013-02-19 9:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Harninder Rai, kumar.gala
Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
---
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
index 8cf93f0..afc2dbf 100644
--- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -203,6 +203,7 @@ static struct of_device_id mpc85xx_l2ctlr_of_match[] = {
{ .compatible = "fsl,p1024-l2-cache-controller",},
{ .compatible = "fsl,p1015-l2-cache-controller",},
{ .compatible = "fsl,p1010-l2-cache-controller",},
+ { .compatible = "fsl,bsc9131-l2-cache-controller",},
{},
};
--
1.7.6.GIT
^ permalink raw reply related
* [PATCH] bsc9131/dts: Correct typo in SDHC device node
From: Harninder Rai @ 2013-02-19 9:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Harninder Rai, kumar.gala
BSC9131RDB doesn't have SDHC enabled. As a result of this typo,
the node was not getting disabled from the device tree which was
leading to linux hang during bootup
Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
---
arch/powerpc/boot/dts/bsc9131rdb.dtsi | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
index 638adda..9e6c013 100644
--- a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
+++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
@@ -126,7 +126,7 @@
};
};
- sdhci@2e000 {
+ sdhc@2e000 {
status = "disabled";
};
--
1.7.6.GIT
^ permalink raw reply related
* [PATCH] powerpc/85xx: dts - add ranges property for SEC
From: Po Liu @ 2013-02-19 0:29 UTC (permalink / raw)
To: linuxppc-dev, Kumar Gala; +Cc: Po Liu
This facilitates getting the physical address of the SEC node.
Signed-off-by: Liu po <po.liu@freescale.com>
---
arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
index d4c9d5d..ffadcb5 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
@@ -36,6 +36,7 @@ crypto@30000 {
compatible = "fsl,sec-v4.4", "fsl,sec-v4.0";
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0x0 0x30000 0x10000>;
reg = <0x30000 0x10000>;
interrupts = <58 2 0 0>;
--
1.6.4
^ permalink raw reply related
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