- 15 11月, 2012 1 次提交
-
-
由 Nathan Fontenot 提交于
When adding or removing a device tree node we should also update the device tree in /proc/device-tree. This action is already done in the generic OF code for adding/removing properties of a node. This patch adds this functionality for nodes. Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com> Acked-by: NRob Herring <rob.herring@calxeda.com> Acked-by: NGrant Likely <grant.likely@secretlab.ca> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 18 10月, 2012 3 次提交
-
-
由 Deepthi Dharwar 提交于
Earlier without cpuidle framework on pseries, the native arch idle routine comprised of both snooze and nap states. smt_snooze_delay variable was used to delay the idle process entry to deeper idle state like nap. With the coming of cpuidle, this arch specific idle was replaced by two different idle routines, one for supporting snooze and other for nap. This enabled addition of more low level idle states on pseries in the future. On adopting the generic cpuidle framework for POWER systems, the decision of which idle state to choose from, given a predicted idle time is taken by the menu governor based on target_residency and exit_latency of the idle states. target_residency is the minimum time to be resident in that idle state. Exit_latency is time taken to exit out of idle state. Deeper the idle state, both the target residency and exit latency would be higher. In the current design, smt_snooze_delay is used as target_residency for the snooze state which is incorrect, as it is not the minimum but the maximum duration to be in snooze state. This would result in the governor in taking bad decision, as presently target_residency of nap < target_residency of snooze inspite of nap being deeper idle state. This patch aims to fix this problem by replacing the smt_snooze_delay loop in snooze state, with the need_resched() as the governor is aware of entry and exit of various idle transitions based on which next idle time prediction. The governor is intelligent enough to determine the idle state the needs to be transitioned to and maintains a whole of heuristics including io load, previous idle states predictions etc for the same, based on which idle state entry decision is taken. With this fix, of setting target_residency of snooze to 0 nap to smt_snooze_delay if the predicted idle time is less than smt_snooze_delay (target_residency of nap) value governor would pick snooze state, else nap. This adhers to the previous native idle design. Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Deepthi Dharwar 提交于
smt_snooze_delay was designed to delay idle loop's nap entry in the native idle code before it got ported over to use as part of the cpuidle framework. A -ve value assigned to smt_snooze_delay should result in busy looping, in other words disabling the entry to nap state. - https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-May/082450.html This particular functionality can be achieved currently by echo 1 > /sys/devices/system/cpu/cpu*/state1/disable but it is broken when one assigns -ve value to the smt_snooze_delay variable either via sysfs entry or ppc64_cpu util. This patch aims to fix this, by disabling nap state when smt_snooze_delay variable is set to -ve value. Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Deepthi Dharwar 提交于
Remove the redundant target residency initialisation in pseries_cpuidle_driver_init(). This is currently over-writing the residency time updated as part of the static table, resulting in all the idle states having the same target residency of 100us which is incorrect. This may result in the menu governor making wrong state decisions. Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 12 10月, 2012 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 11 10月, 2012 2 次提交
-
-
由 Yasuaki Ishimatsu 提交于
Followups to d760afd4 ("memory-hotplug: suppress "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning"). - use unsigned long type, as overflows are conceivable - rename `i' to the less-misleading and more informative `section' Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andrew Morton 提交于
Fix arch/powerpc/platforms/pseries/hotplug-memory.c: In function 'pseries_remove_memblock': arch/powerpc/platforms/pseries/hotplug-memory.c:103:17: error: unused variable 'pfn' [-Werror=unused-variable] Caused by commit d760afd4 ("memory-hotplug: suppress "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning"). Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Tested-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Tested-by: NNathan Fontenot <nfont@linux.vnet.ibm.com> Tested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 09 10月, 2012 1 次提交
-
-
由 Yasuaki Ishimatsu 提交于
memory-hotplug: suppress "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning When our x86 box calls __remove_pages(), release_mem_region() shows many warnings. And x86 box cannot unregister iomem_resource. "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" release_mem_region() has been changed to be called in each PAGES_PER_SECTION by commit de7f0cba ("memory hotplug: release memory regions in PAGES_PER_SECTION chunks"). Because powerpc registers iomem_resource in each PAGES_PER_SECTION chunk. But when I hot add memory on x86 box, iomem_resource is register in each _CRS not PAGES_PER_SECTION chunk. So x86 box unregisters iomem_resource. The patch fixes the problem. Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: David Rientjes <rientjes@google.com> Cc: Jiang Liu <liuj97@gmail.com> Cc: Len Brown <len.brown@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Christoph Lameter <cl@linux.com> Cc: Minchan Kim <minchan.kim@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Wen Congyang <wency@cn.fujitsu.com> Cc: Dave Hansen <dave@linux.vnet.ibm.com> Cc: Nathan Fontenot <nfont@austin.ibm.com> Cc: Badari Pulavarty <pbadari@us.ibm.com> Cc: Yasunori Goto <y-goto@jp.fujitsu.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 06 10月, 2012 1 次提交
-
-
由 Andi Kleen 提交于
Signed-off-by: NAndi Kleen <ak@linux.intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 27 9月, 2012 3 次提交
-
-
由 Aneesh Kumar K.V 提交于
Acked-by: NGavin Shan <shangw@linux.vnet.ibm.com> ===================================== [ BUG: bad unlock balance detected! ] 3.6.0-rc5-00338-gcaa1d631-dirty #6 Not tainted ------------------------------------- swapper/0/1 is trying to release lock (eeh_mutex) at: [<c000000000058218>] .eeh_add_to_parent_pe+0x318/0x410 but there are no more locks to release! other info that might help us debug this: no locks held by swapper/0/1. stack backtrace: Call Trace: [c00000003e483870] [c000000000013310] .show_stack+0x70/0x1c0 (unreliable) [c00000003e483920] [c0000000000d8310] .print_unlock_inbalance_bug+0x110/0x120 [c00000003e4839b0] [c0000000000d9a50] .lock_release+0x1d0/0x240 [c00000003e483a60] [c000000000778064] .__mutex_unlock_slowpath+0xb4/0x250 [c00000003e483b10] [c000000000058218] .eeh_add_to_parent_pe+0x318/0x410 [c00000003e483bc0] [c00000000005a118] .pseries_eeh_of_probe+0x258/0x2f0 [c00000003e483cc0] [c000000000032528] .traverse_pci_devices+0xa8/0x150 [c00000003e483d70] [c000000000aa7288] .eeh_init+0xd4/0x140 [c00000003e483e00] [c00000000000abc4] .do_one_initcall+0x64/0x1e0 [c00000003e483ec0] [c000000000a90418] .kernel_init+0x1e8/0x2bc [c00000003e483f90] [c00000000002048c] .kernel_thread+0x54/0x70 EEH: PCI Enhanced I/O Error Handling Enabled Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 18 9月, 2012 5 次提交
-
-
由 Gavin Shan 提交于
The kernel crash was reported by Alexy. He was testing some feature with private kernel, in which Alexy added some code in pci_pm_reset() to read the CSR after writting it. The bug could be reproduced on Fiber Channel card (Fibre Channel: Emulex Corporation Saturn-X: LightPulse Fibre Channel Host Adapter (rev 03)) by the following commands. # echo 1 > /sys/devices/pci0004:01/0004:01:00.0/reset # rmmod lpfc # modprobe lpfc The history behind the test case is that those additional config space reading operations in pci_pm_reset() would cause EEH error, but we didn't detect EEH error until "modprobe lpfc". For the case, all the PCI devices on PCI bus (0004:01) were removed and added after PE reset. Then the EEH devices would be figured out again based on the OF nodes. Unfortunately, there were some child OF nodes under PCI device (0004:01:00.0), but they didn't have attached PCI_DN since they're invisible from PCI domain. However, we were still trying to convert OF node to EEH device without checking on the attached PCI_DN. Eventually, it caused the kernel crash as follows: Unable to handle kernel paging request for data at address 0x00000030 Faulting instruction address: 0xc00000000004d888 cpu 0x0: Vector: 300 (Data Access) at [c000000fc797b950] pc: c00000000004d888: .eeh_add_device_tree_early+0x78/0x140 lr: c00000000004d880: .eeh_add_device_tree_early+0x70/0x140 sp: c000000fc797bbd0 msr: 8000000000009032 dar: 30 dsisr: 40000000 current = 0xc000000fc78d9f70 paca = 0xc00000000edb0000 softe: 0 irq_happened: 0x00 pid = 2951, comm = eehd enter ? for help [c000000fc797bc50] c00000000004d848 .eeh_add_device_tree_early+0x38/0x140 [c000000fc797bcd0] c00000000004d848 .eeh_add_device_tree_early+0x38/0x140 [c000000fc797bd50] c000000000051b54 .pcibios_add_pci_devices+0x34/0x190 [c000000fc797bde0] c00000000004fb10 .eeh_reset_device+0x100/0x160 [c000000fc797be70] c0000000000502dc .eeh_handle_event+0x19c/0x300 [c000000fc797bf00] c000000000050570 .eeh_event_handler+0x130/0x1a0 [c000000fc797bf90] c000000000020138 .kernel_thread+0x54/0x70 The patch changes of_node_to_eeh_dev() and just returns NULL if the passed OF node doesn't have attached PCI_DN. Cc: stable@vger.kernel.org Reported-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
The EEH core is talking with the PCI device driver to determine the action (purely reset, or PCI device removal). During the period, the driver might be unloaded and in turn causes kernel crash as follows: EEH: Detected PCI bus error on PHB#4-PE#10000 EEH: This PCI device has failed 3 times in the last hour lpfc 0004:01:00.0: 0:2710 PCI channel disable preparing for reset Unable to handle kernel paging request for data at address 0x00000490 Faulting instruction address: 0xd00000000e682c90 cpu 0x1: Vector: 300 (Data Access) at [c000000fc75ffa20] pc: d00000000e682c90: .lpfc_io_error_detected+0x30/0x240 [lpfc] lr: d00000000e682c8c: .lpfc_io_error_detected+0x2c/0x240 [lpfc] sp: c000000fc75ffca0 msr: 8000000000009032 dar: 490 dsisr: 40000000 current = 0xc000000fc79b88b0 paca = 0xc00000000edb0380 softe: 0 irq_happened: 0x00 pid = 3386, comm = eehd enter ? for help [c000000fc75ffca0] c000000fc75ffd30 (unreliable) [c000000fc75ffd30] c00000000004fd3c .eeh_report_error+0x7c/0xf0 [c000000fc75ffdc0] c00000000004ee00 .eeh_pe_dev_traverse+0xa0/0x180 [c000000fc75ffe70] c00000000004ffd8 .eeh_handle_event+0x68/0x300 [c000000fc75fff00] c0000000000503a0 .eeh_event_handler+0x130/0x1a0 [c000000fc75fff90] c000000000020138 .kernel_thread+0x54/0x70 1:mon> The patch increases the reference of the corresponding driver modules while EEH core does the negotiation with PCI device driver so that the corresponding driver modules can't be unloaded during the period and we're safe to refer the callbacks. Cc: stable@vger.kernel.org Reported-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
We have missed lots of situations where the PE hierarchy tree need protection through the EEH global mutex. The patch fixes that for those public APIs implemented in eeh_pe.c. The only exception is eeh_pe_restore_bars() because it calls eeh_pe_dev_traverse(), which has been protected by the mutex. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
Function eeh_rmv_from_parent_pe() could be called by the path of either normal PCI hotplug, or EEH recovery. For the former case, we need purge the corresponding PE on removal of the associated PE bus. The patch tries to cover that by passing more information to function pcibios_remove_pci_devices() so that we know if the corresponding PE needs to be purged or be marked as "invalid". Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
When EEH error happens on the PE whose PCI devices don't have attached drivers. In function eeh_handle_event(), the default value PCI_ERS_RESULT_NONE will be returned after iterating all drivers of those PCI devices belonging to the PE. Actually, we don't have installed drivers for the PCI devices. Under the circumstance, we will remove the corresponding PCI bus of the PE, including the associated EEH devices and PE instance. However, we still need the information stored in the PE instance to do PE reset after that. So it's unsafe to free the PE instance. The patch introduces EEH_PE_INVALID type PE to address the issue. When the PCI bus and the corresponding attached EEH devices are removed, we will mark the PE as EEH_PE_INVALID. At later point, the PE will be changed to EEH_PE_DEVICE or EEH_PE_BUS when the corresponding EEH devices are attached again. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 17 9月, 2012 10 次提交
-
-
由 Gavin Shan 提交于
We don't need them anymore. The patch removes those functions. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Reviewed-by: NRichard Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
Currently, the PCI probe flags "PCI_PROBE_ONLY | PCI_REASSIGN_ALL_RSRC" used on powernv platform. That means the platform has to do the PCI resource assignment by itself. The patch changes the PCI probe flag to "PCI_REASSIGN_ALL_RSRC" so that the PCI core will do the resource assignment. Also, the I/O and MMIO minimal alignment for P2P bridges have been configured while doing fixup for the PHBs. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Reviewed-by: NRichard Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
There're 2 arrays introduced to trace which PE has occupied the corresponding resource (I/O or MMIO) segment. However, we didn't allocate enough memory for them and that possiblly leads to PE descriptor corruption. The patch fixes that by allocating enough memory for those 2 arrays. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Reviewed-by: NRichard Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
While the device driver or PCI core tries to enable PCI device, the platform dependent callback "ppc_md.pcibios_enable_device_hook" will be called to check if there has one associated PE for the PCI device. If we don't have the associated PE for the PCI device, it's not allowed to enable the PCI device. Unfortunately, there might have some cases we have to enable the PCI device (e.g. P2P bridge), but the PEs have not been created yet. The patch handles the unfortunate cases. Each PHB (struct pnv_phb) has one field "initialized" to trace if the PEs have been created and configured or not. When the PEs are not available, we won't check the associated PE for the PCI device to be enabled. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Reviewed-by: NRichard Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
The patch introduces additional wrapper function to call the original implementation so that the DMA can be configured for all existing PEs. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Reviewed-by: NRichard Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
There're 2 types of PCI bus sensitive PEs: (A) The PE includes single PCI bus. (B) The PE includes the PCI bus and all the subordinate PCI buses, and the patch tries to assign I/O and MMIO resources based on created PEs. Fortunately, we figured out unified scheme to do resource assignment for all types of PCI bus based PEs according to Ben's idea: - Resource assignment based on PE from top to bottom. - The soureces, either I/O or MMIO, of the PE are figured out from the assigned PCI bus. - The occupied resource by parent PE could possibilly be overrided by children PEs. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Reviewed-by: NRichard Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
The resource (I/O and MMIO) will be assigned on basis of PE from top to bottom so that we can implement the trick here: the resource that has been assigned to parent PE could be taken by child PE if necessary. The current implementation already has PE list per PHB basis, but the list doesn't meet our requirment: tracing PE based on their cration time from top to bottom. So the patch does rename for the DMA based PE list and introduces the list to trace the PEs sequentially based on their creation time. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Reviewed-by: NRichard Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
Basically, there're 2 types of PCI bus sensitive PEs: (A) The PE includes single PCI bus. (B) The PE includes the PCI bus and all the subordinate PCI buses. At present, we'd like to put PCI bus originated by PCI-e link to form PE that contains single PCI bus, and the PCIe-to-PCI bridge will form the 2nd type of PE. We don't figure out to detect PLX bridge yet. Once we can detect PLX bridge some day, we have to put PCI buses originated from the downstream port of PLX bridge to the 2nd type of PE. The patch changes the original implementation for a little bit to support 2 types of PCI bus sensitive PEs described as above. Also, the function used to retrieve the corresponding PE according to the given PCI device has been changed based on that because each PCI device should trace the directly associated PE. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Reviewed-by: NRichard Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Aneesh Kumar K.V 提交于
This patch convert different functions to take virtual page number instead of virtual address. Virtual page number is virtual address shifted right by VPN_SHIFT (12) bits. This enable us to have an address range of upto 76 bits. Reviewed-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Aneesh Kumar K.V 提交于
Don't open code the same Reviewed-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 14 9月, 2012 2 次提交
-
-
由 Anatolij Gustschin 提交于
Currently fifo transfer is started when submitting a transfer request. Add posibility to defer the fifo transfer and start it later by calling additional function. This change is backward compatible, the behaviour of mpc52xx_lpbfifo_submit() is the same for previous driver users, so there is no need to adapt them. Signed-off-by: NAnatolij Gustschin <agust@denx.de>
-
由 Anatolij Gustschin 提交于
Add common o2d dtsi file to reuse it for other configurations. Add machine compatible string to mpc5200 simple platform file. Add dts files for O2D, O2I, O2MNT, O2DNT2, O2D300 and O3DNT boards. Signed-off-by: NAnatolij Gustschin <agust@denx.de>
-
- 13 9月, 2012 7 次提交
-
-
由 Jia Hongtao 提交于
We unified the Freescale pci/pcie initialization by changing the fsl_pci to a platform driver. In previous PCI code architecture the initialization routine is called at board_setup_arch stage. Now the initialization is done in probe function which is architectural better. Also It's convenient for adding PM support for PCI controller in later patch. Now we registered pci controllers as platform devices. So we combine two initialization code as one platform driver. Signed-off-by: NJia Hongtao <B38951@freescale.com> Signed-off-by: NLi Yang <leoli@freescale.com> Signed-off-by: NChunhe Lan <Chunhe.Lan@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Jia Hongtao 提交于
Remove the dependency on PCI initialization for SWIOTLB initialization. So that PCI can be initialized at proper time. SWIOTLB is partly determined by PCI inbound/outbound map which is assigned in PCI initialization. But swiotlb_init() should be done at the stage of mem_init() which is much earlier than PCI initialization. So we reserve the memory for SWIOTLB first and free it if not necessary. All boards are converted to fit this change. Signed-off-by: NJia Hongtao <B38951@freescale.com> Signed-off-by: NLi Yang <leoli@freescale.com> Acked-by: NTony Breeds <tony@bakeyournoodle.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Zhao Chenhui 提交于
Add support to disable and re-enable individual cores at runtime on MPC85xx/QorIQ SMP machines. Currently support e500v1/e500v2 core. MPC85xx machines use ePAPR spin-table in boot page for CPU kick-off. This patch uses the boot page from bootloader to boot core at runtime. It supports 32-bit and 36-bit physical address. Signed-off-by: NLi Yang <leoli@freescale.com> Signed-off-by: NJin Qing <b24347@freescale.com> Signed-off-by: NZhao Chenhui <chenhui.zhao@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Zhao Chenhui 提交于
Do hardware timebase sync. Firstly, stop all timebases, and transfer the timebase value of the boot core to the other core. Finally, start all timebases. Only apply to dual-core chips, such as MPC8572, P2020, etc. Signed-off-by: NZhao Chenhui <chenhui.zhao@freescale.com> Signed-off-by: NLi Yang <leoli@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Zhao Chenhui 提交于
Signed-off-by: NZhao Chenhui <chenhui.zhao@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Timur Tabi 提交于
The Freescale / iVeia P1022RDK reference board is a small-factor board with a Freescale P1022 SOC. It includes: 1) 512 MB 64-bit DDR3-800 (max) memory 2) 8MB SPI serial flash memory for boot loader 3) Bootable 4-bit SD/MMC port 4) Two 10/100/1000 Ethernet connectors 5) One SATA port 6) Two USB ports 7) One PCIe x4 slot 8) DVI video connector 9) Audio input and output jacks, powered by a Wolfson WM8960 codec. Unlike the P1022DS, the P1022RDK does not have any localbus devices, presumably because of the localbus / DIU multiplexing restriction of the P1022 SOC. Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Timur Tabi 提交于
Add support for the Freescale P5040DS Reference Board ("Superhydra"), which is similar to the P5020DS. Features of the P5040 are listed below, but not all of these features (e.g. DPAA networking) are currently supported. Four P5040 single-threaded e5500 cores built Up to 2.4 GHz with 64-bit ISA support Three levels of instruction: user, supervisor, hypervisor CoreNet platform cache (CPC) 2.0 MB configures as dual 1 MB blocks hierarchical interconnect fabric Two 64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving support Up to 1600MT/s Memory pre-fetch engine DPAA incorporating acceleration for the following functions Packet parsing, classification, and distribution (FMAN) Queue management for scheduling, packet sequencing and congestion management (QMAN) Hardware buffer management for buffer allocation and de-allocation (BMAN) Cryptography acceleration (SEC 5.0) at up to 40 Gbps SerDes 20 lanes at up to 5 Gbps Supports SGMII, XAUI, PCIe rev1.1/2.0, SATA Ethernet interfaces Two 10 Gbps Ethernet MACs Ten 1 Gbps Ethernet MACs High-speed peripheral interfaces Two PCI Express 2.0/3.0 controllers Additional peripheral interfaces Two serial ATA (SATA 2.0) controllers Two high-speed USB 2.0 controllers with integrated PHY Enhanced secure digital host controller (SD/MMC/eMMC) Enhanced serial peripheral interface (eSPI) Two I2C controllers Four UARTs Integrated flash controller supporting NAND and NOR flash DMA Dual four channel Support for hardware virtualization and partitioning enforcement Extra privileged level for hypervisor support QorIQ Trust Architecture 1.1 Secure boot, secure debug, tamper detection, volatile key storage Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 12 9月, 2012 1 次提交
-
-
由 Gavin Shan 提交于
The patch implements ppc_md.pcibios_window_alignment for powernv platform so that the resource reassignment in PCI core will be done according to the I/O and memory alignment returned from powernv platform. The alignments returned from powernv platform is closely depending on the scheme for PE segmenting. Besides, the patch isn't useful for now, but the subsequent patches will be working based on it. [bhelgaas: use pci_pcie_type() since pci_dev.pcie_type was removed] Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 11 9月, 2012 2 次提交
-
-
由 Uwe Kleine-König 提交于
This prepares *of_device_id.data becoming const. Without this change the following warning would occur: arch/powerpc/platforms/cell/celleb_pci.c: In function 'celleb_setup_phb': arch/powerpc/platforms/cell/celleb_pci.c:485:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default] Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
-
由 Uwe Kleine-König 提交于
This prepares *of_device_id.data becoming const. Without this change the following warning would occur: arch/powerpc/platforms/83xx/suspend.c: In function 'pmc_probe': arch/powerpc/platforms/83xx/suspend.c:336:7: error: assignment discards 'const' qualifier from pointer target type [-Werror] Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
-
- 10 9月, 2012 1 次提交
-
-
由 Alexey Kardashevskiy 提交于
The upcoming VFIO support requires a way to know which entry in the TCE map is not empty in order to do cleanup at QEMU exit/crash. This patch adds such functionality to POWERNV platform code. Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-