[PATCH] bsc9131/dts: Correct typo in SDHC device node
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@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] bsc9131:l2sram: Add compatible string for BSC9131 platform
Signed-off-by: Harninder Rai harninder@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] bsc913x:defconfig: Add new defconfig file for BSC913x platforms
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@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 000..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
Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat srivatsa.b...@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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On 02/19/2013 03:10 PM, Michel Lespinasse wrote: On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat srivatsa.b...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
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_ENTRIES0x1FF Where is this number coming from? Diana ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
-Original Message- From: Craciun Diana Madalina-STFD002 Sent: Tuesday, February 19, 2013 3:34 PM To: Sethi Varun-B16395 Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421; j...@8bytes.org; Yoder Stuart-B08248 Subject: Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation. 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_ENTRIES0x1FF Where is this number coming from? This is currently hard coded. We will not require these many entries once we implement the LIODN allocation scheme. -Varun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 00/45] CPU hotplug: stop_machine()-free CPU hotplug
On 18 February 2013 20:53, Steven Rostedt rost...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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. Signed-off-by: Liu po po@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=linux/kernel/git/galak/powerpc.git;a=commit;h=db29cd3c4497e7edf9176284ba7cf3cec1814c7a - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] bsc913x:defconfig: Add new defconfig file for BSC913x platforms
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 Fastpath) are enabled in this config * IPC for inter-domain communication (DSP and PA) is present Signed-off-by: Harninder Rai harninder@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git next branch
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
Re: [PATCH] bsc9131/dts: Correct typo in SDHC device node
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 Signed-off-by: Harninder Rai harninder@freescale.com --- arch/powerpc/boot/dts/bsc9131rdb.dtsi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] bsc9131:l2sram: Add compatible string for BSC9131 platform
On Feb 19, 2013, at 3:14 AM, Harninder Rai wrote: Signed-off-by: Harninder Rai harninder@freescale.com --- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PS3: Strange issue with kexec and FreeBSD loader
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 torva...@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
Re: [PATCH v5 29/45] x86/xen: Use get/put_online_cpus_atomic() to prevent CPU offline
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.w...@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-kernelm=136119260122255w=2 Regards, Srivatsa S. Bhat Cc: Jeremy Fitzhardinge jer...@goop.org Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org Cc: xen-de...@lists.xensource.com Cc: virtualizat...@lists.linux-foundation.org Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PS3: Strange issue with kexec and FreeBSD loader
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 torva...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] of: use platform_device_add
On Sun, Feb 17, 2013 at 10:49:08AM +, 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@020e {
compatible = fsl,imx6q-iomuxc-gpr, syscon;
reg = 0x020e 0x38;
};
iomuxc: iomuxc@020e {
compatible = fsl,imx6q-iomuxc;
reg = 0x020e 0x4000;
};
With the patch in place, pinctrl-imx6q fails to register like below.
syscon 20e.iomuxc: syscon regmap start 0x20e end 0x20e3fff
registered
imx6q-pinctrl 20e.iomuxc: can't request region for resource [mem
0x020e-0x020e3fff]
imx6q-pinctrl: probe of 20e.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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][RFC] Replaced tlbilx with tlbwe in the initialization code
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.crac...@freescale.com On Freescale e6500 cores EPCR[DGTMI] controls whether guest supervisor state can execute TLB management instructions. If EPCR[DGTMI]=0 tlbwe and tlbilx are allowed to execute normally in the guest state. 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 state are sharing the same bit, it is not possible to have a scenario where tlbwe is allowed to be executed in guest state and tlbilx traps. When guest TLB management instructions are allowed to be executed in guest state the guest cannot use tlbilx to invalidate TLB1 guest entries. Sorry, I don't understand the explanation... can you be more detailed ? TLB1 supports huge page sizes. The guest may see the memory as contiguous but it sees the guest physical memory as presented by the hypervisor. In reality the real physical memory may be fragmented. In this case the hypervisor can add more than one TLB1 entry for one guest request and the hypervisor will keep track of all fragments. When the guest performs a tlbilx, the hypervisor will correctly invalidate all the corresponding fragments because both tlbwe and tlbilx trap and has full control of tlb management instructions targeting TLB1. For e6500 a single bit controls if tlbwe and tlbilx trap to the Hypervisor. tlbwe targeting TLB1 always traps. But if we want to use LRAT for TLB0, we have to configure tlbwe (targeting TLB 0) to go directly to the guest. But in this case tlbilx (which is targeting both TLBs) will never trap. If the tlbilx does not trap, the guest can invalidate only one of (possible more) fragments and furthermore the synchronization between what entries the hypervisor thinks there are in the TLB1 and what are the actual entries is lost. This patch addresses boot-time invalidations only. How will you handle hugetlb invalidations (or indirect entry invalidations, once that becomes supported)? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 29/45] x86/xen: Use get/put_online_cpus_atomic() to prevent CPU offline
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.w...@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 jer...@goop.org
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: xen-de...@lists.xensource.com
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@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 jer...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of 5xxx tree
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%)
RE: [PATCH] powerpc/85xx: dts - add ranges property for SEC
Thanks again for the fix. Just ignore this post. Best regards, Liu Po - 8038 -Original Message- From: Gala Kumar-B11780 Sent: Wednesday, February 20, 2013 12:01 AM To: Liu Po-B43644 Cc: linuxppc-...@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. Signed-off-by: Liu po po@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=linux/kernel/git/galak/powerpc.git;a=commit;h=db29cd3c4497e7edf9176284ba7cf3cec1814c7a - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Tuesday, February 19, 2013 3:43 AM
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
On Jan 30, 2013, at 9:10 PM, Wang Dongsheng wrote:
Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc-action-
flag.
So the wake up interrupt will not be disable in suspend_device_irqs.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/sysdev/mpic.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
Why are we doing this globally for all interrupts? Don't we only have
some specific interrupts that wake us up?
Also, I'm guessing the wake behavior for interrupts is FSL specific so
should not apply to ALL users of MPIC.
That is IRQ wakeup (PM) control. Actually not all interrupts will be set.
We just let mpic have this ability. It's control by driver.
If a device has the ability to wake up system, this device driver can set
irq wake up(through enable/disable_irq_wake()), and the driver do not need
add a flag(IRQF_NO_SUSPEND) to request_irq().
for example,
suspend()
{
...;
enable_irq_wake(irq);
...;
}
resume()
{
...;
disable_irq_wake(irq);
...;
}
- k
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9c6e535..2ed0220 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d, unsigned
int flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
+ struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
+
+ if (on)
+ desc-action-flags |= IRQF_NO_SUSPEND;
+ else
+ desc-action-flags = ~IRQF_NO_SUSPEND;
+
+ return 0;
+}
+
void mpic_set_vector(unsigned int virq, unsigned int vector) {
struct mpic *mpic = mpic_from_irq(virq); @@ -957,6 +969,7 @@ static
struct irq_chip mpic_irq_chip = {
.irq_unmask = mpic_unmask_irq,
.irq_eoi= mpic_end_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_SMP
@@ -971,6 +984,7 @@ static struct irq_chip mpic_tm_chip = {
.irq_mask = mpic_mask_tm,
.irq_unmask = mpic_unmask_tm,
.irq_eoi= mpic_end_irq,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_MPIC_U3_HT_IRQS
@@ -981,6 +995,7 @@ static struct irq_chip mpic_irq_ht_chip = {
.irq_unmask = mpic_unmask_ht_irq,
.irq_eoi= mpic_end_ht_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#endif /* CONFIG_MPIC_U3_HT_IRQS */
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
