- 10 Jul, 2012 40 commits
-
-
Prabhakar Kushwaha authored
BSC9131RDB is a Freescale reference design board for BSC9131 SoC. The BSC9131 is integrated SoC that targets Femto base station market. It combines Power Architecture e500v2 and DSP StarCore SC3850 core technologies with MAPLE-B2F baseband acceleration processing elements. The BSC9131 SoC includes the following function and features: . Power Architecture subsystem including a e500 processor with 256-Kbyte shared L2 cache . StarCore SC3850 DSP subsystem with a 512-Kbyte private L2 cache . The Multi Accelerator Platform Engine for Femto BaseStation Baseband Processing (MAPLE-B2F) . A multi-standard baseband algorithm accelerator for Channel Decoding/Encoding, Fourier Transforms, UMTS chip rate processing, LTE UP/DL Channel processing, and CRC algorithms . Consists of accelerators for Convolution, Filtering, Turbo Encoding, Turbo Decoding, Viterbi decoding, Chiprate processing, and Matrix Inversion operations . DDR3/3L memory interface with 32-bit data width without ECC and 16-bit with ECC, up to 400-MHz clock/800 MHz data rate . Dedicated security engine featuring trusted boot . DMA controller . OCNDMA with four bidirectional channels . Interfaces . Two triple-speed Gigabit Ethernet controllers featuring network acceleration including IEEE 1588. v2 hardware support and virtualization (eTSEC) . eTSEC 1 supports RGMII/RMII . eTSEC 2 supports RGMII . High-speed USB 2.0 host and device controller with ULPI interface . Enhanced secure digital (SD/MMC) host controller (eSDHC) . Antenna interface controller (AIC), supporting three industry standard JESD207/three custom ADI RF interfaces (two dual port and one single port) and three MAXIM's MaxPHY serial interfaces . ADI lanes support both full duplex FDD support and half duplex TDD support . Universal Subscriber Identity Module (USIM) interface that facilitates communication to SIM cards or Eurochip pre-paid phone cards . TDM with one TDM port . Two DUART, four eSPI, and two I2C controllers . Integrated Flash memory controller (IFC) . TDM with 256 channels . GPIO . Sixteen 32-bit timers The DSP portion of the SoC consists of DSP core (SC3850) and various accelerators pertaining to DSP operations. BSC9131RDB Overview ---------------------- BSC9131 SoC 1Gbyte DDR3 (on board DDR) 128Mbyte 2K page size NAND Flash 256 Kbit M24256 I2C EEPROM 128 Mbit SPI Flash memory USB-ULPI eTSEC1: Connected to RGMII PHY eTSEC2: Connected to RGMII PHY DUART interface: supports one UARTs up to 115200 bps for console display Linux runs on e500v2 core and access some DSP peripherals like AIC Signed-off-by:Ramneek Mehresh <ramneek.mehresh@freescale.com> Signed-off-by:
Priyanka Jain <Priyanka.Jain@freescale.com> Signed-off-by:
Akhil Goyal <Akhil.Goyal@freescale.com> Signed-off-by:
Poonam Aggrwal <poonam.aggrwal@freescale.com> Signed-off-by:
Rajan Srivastava <rajan.srivastava@freescale.com> Signed-off-by:
Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org>
-
Timur Tabi authored
This reverts commit 96cc017c. The P3060 was cancelled before it went into production, so there's no point in supporting it. Signed-off-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
-
Timur Tabi authored
In order to enable the DIU video controller on the P1022DS, the FPGA needs to be switched to "indirect mode", where the localbus is disabled and the FPGA is accessed via writes to localbus chip select signals CS0 and CS1. To obtain the address of CS0 and CS1, the platform driver uses an "indirect pixis mode" device tree node. This node assumes that the localbus 'ranges' property is sorted in chip-select order. That is, reg value 0 maps to CS0, reg value 1 maps to CS1, etc. This is how the 'ranges' property is supposed to be arranged. Unfortunately, the 'ranges' property is often mis-arranged, and not just on the P1022DS. Linux normally does not care, since it does not program the localbus. But the indirect-mode code on the P1022DS does care. The "proper" fix is to have U-Boot fix the 'ranges' property, but this would be too cumbersome. The names and 'reg' properties of all the localbus devices would also need to be updated, and determining which localbus device maps to which chip select is board-specific. Instead, we determine the CS0/CS1 base addresses the same way that U-boot does -- by reading the BRx registers directly and mapping them to physical addresses. This code is simpler and more reliable, and it does not require a U-boot or device tree change. Since the indirect pixis device tree node is no longer needed, the node is deleted from the DTS. Signed-off-by:
-
Shaohui Xie authored
NAND on p2041 uses CS1 as chip select. Signed-off-by:
Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by:
-
Paul Gortmaker authored
This reference board dates back to 2004, and is largely a legacy EOL product. The MPC8560 is a pre e500v2 CPU. The SBC8548 is a more modern, better e500v2 target for people to use as a reference board with today's kernels, should they require one. Removing support for it will also allow us to remove some sbc8560 specific quirk handling in 8250 UART code, and some MTD mapping support. Cc: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Tang Yuantian authored
Signed-off-by:
Jin Qing <b24347@freescale.com> Signed-off-by:
Li Yang <leoli@freescale.com> Signed-off-by:
Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by:
-
Tang Yuantian authored
The p1024rdb has the similar feature as the p1020rdb. Therefore, p1024rdb use the same platform file as the p1/p2 rdb board. Overview of P2020RDB platform - DDR3 1G - NOR flash 16M - 3 Ethernet interfaces - NAND Flash 32M - SPI EEPROM 16M - SD/MMC - 2 USB ports - 4 TDM ports Signed-off-by:
-
Gustavo Zacarias authored
Add EEPROM to the P1010RDB device tree. The 24c01 acts as a memory SPD so it shouldn't be overwritten without care. The 24c256 is a general purpose memory. Signed-off-by:
Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by:
-
Sebastian Andrzej Siewior authored
This reverts commit 0c00f656. The initial commit was my fault. There are two boards out there: P2020RDB and P2020RDB-PC. I wasn't aware of that and assumed that I have a RDB board in front of me while I the RDB-PC. This patch makes it work for the RDB-PC variant and breaks it for the RDB. Now there is a device tree file available for the RDB-PC which was not there earlier. So with this revert, everything gets back to normal :) Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Holger Brunck authored
Add spi support for mgcoge into the platform code and the dts file. Additionaly SPIDEV is switched on in the defconfig and the updates for the newer kernel version are committed. The SPI interface is used to drive the Maxim DS3106 clock chip. Signed-off-by:
Holger Brunck <holger.brunck@keymile.com> cc: Heiko Schocher <hs@denx.de> Signed-off-by:
-
Holger Brunck authored
Switch on UBIFS, HOTPLUG and TIPC and update the config to the latest kernel version. Signed-off-by:
-
Christian Herzig authored
Fix RGMII workaround code in km83xx.c for MPC8360E and MPC8358E that it correctly identifes all affected SoC chip models and applies the workarounds appropriate for 2.0 and 2.1 revisions as per Freescale MPC8360ECE Errata document Rev.5(9/2011) item QE_ENET10. Signed-off-by:
Christian Herzig <christian.herzig@keymile.com> Signed-off-by:
-
Holger Brunck authored
Signed-off-by:
-
Jerry Huang authored
Add the RTC support into the p1022ds device tree Signed-off-by:
Jerry Huang <Chang-Ming.Huang@freescale.com> Acked-by:
-
Shengzhou Liu authored
Enable MTD/NOR/NAND options by default in mpc85xx_defconfig and mpc85xx_smp_defconfig to support NOR, NAND flash. Signed-off-by:
Shengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by:
-
Kim Phillips authored
At least for crypto/IPSec, doing so provides users with a better performance experience out of the box. Signed-off-by:
Kim Phillips <kim.phillips@freescale.com> Signed-off-by:
-
Matias Garcia authored
Change quirk_fsl_pcie_header from __init to __devinit to ensure if we have a runtime access (like via an FPGA being loaded after boot on the PCIe link) that we dont access randomly freed memory. Signed-off-by:
Matias Garcia <mgarcia@rossvideo.com> Signed-off-by:
-
Michael Ellerman authored
Matt added BPF_JIT support in commit 0ca87f05, but currently none of our defconfigs build it. Turn that sucker on. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Anton Blanchard authored
Add the ability to inject IOMMU faults. We enable this per device via a fail_iommu sysfs property, similar to fault injection on other subsystems. An example: ... 0003:01:00.1 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (be3) (rev 02) To inject one error to this device: echo 1 > /sys/bus/pci/devices/0003:01:00.1/fail_iommu echo 1 > /sys/kernel/debug/fail_iommu/probability echo 1 > /sys/kernel/debug/fail_iommu/times As feared, the first failure injected on the be3 results in an unrecoverable error, taking down both functions of the card permanently: be2net 0003:01:00.1: Unrecoverable error in the card Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Anton Blanchard authored
The DMA API debug code has hooks to verify all DMA entries have been freed at time of hot unplug. We need to call dma_debug_add_bus for this to work. Signed-off-by:
-
Anton Blanchard authored
Similar to PCI, separate the bus probe from device probe. This allows us to attach bus notifiers for DMA debug and IOMMU fault injection before devices have been probed. Signed-off-by:
-
Anton Blanchard authored
During boot we see a number of these warnings: vio 30000000: Warning: IOMMU dma not supported: mask 0xffffffffffffffff, table unavailable The reason for this is that we set IOMMU properties for all VIO devices even if they are not DMA capable. Only set DMA ops, table and mask for devices with a DMA window. Signed-off-by:
-
Michael Neuling authored
Signed-off-by:
Michael Neuling <mikey@neuling.org> Acked-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
-
Anton Blanchard authored
We use SIAR or regs->nip for the instruction pointer depending on the PMU configuration, but we always use regs->nip in the callchain. Use perf_instruction_pointer so the backtrace is consistent. Signed-off-by:
-
Anton Blanchard authored
At the moment we always use the SIAR if the PMU supports continuous sampling. Unfortunately the SIAR and the PMU exception are not synchronised for non marked events so we can end up with callchains that dont make sense. The following patch checks the HV and PR bits for samples coming from userspace and always uses pt_regs for them. Userspace will never have interrupts off so there is no real advantage to using the SIAR for non marked events in userspace. I had experimented with a patch that did a similar thing for kernel samples but we lost a significant amount of information. I was unable to profile any of our early exception code for example. Signed-off-by:
-
Anton Blanchard authored
The logic to choose whether to use the SIAR or get the information out of pt_regs is going to get more complicated, so do it once in perf_read_regs. We overload regs->result which is gross but we are already doing it with regs->dsisr. Signed-off-by:
-
Anton Blanchard authored
We want to access the MMCRA_SIHV and MMCRA_SIPR bits elsewhere so create mmcra_sihv and mmcra_sipr which hide the differences between the old and new layout of the bits. Signed-off-by:
-
Michael Neuling authored
Some macros use RA where when RA=R0 the values is 0, so make this the enforced mnemonic in the macro. Idea suggested by Andreas Schwab. Signed-off-by:
-
Michael Neuling authored
R0 is special since it'll be 0. Signed-off-by:
-
Michael Neuling authored
Enforce the use of R0-R31 in macros where possible now we have all the fixes in. R0-R31 macros are removed here so that can't be used anymore. They should not be defined anywhere. Signed-off-by:
-
Michael Neuling authored
Signed-off-by:
-
Michael Neuling authored
Now have ___PPC_RA/B/S/T we can use it in some places. These are places where we can't use the existing defines which will soon enforce R0-R31 usage. The macros being changed here are being used in inline asm, which can't convert to enforce the R0-R31 usage. bpf_jit uses a mix of both generated and non-generated with the same code, so just convert all these to use the ___PPC_R versions which won't enforce R usage later. Signed-off-by:
-
Michael Neuling authored
These are currently the same as __PPC_RA/B/S/T but we'll wrap them soon. Signed-off-by:
-
Michael Neuling authored
We need to do this so we can enforce the name of a and b in called macros PPC_RA/B later. Signed-off-by:
-
Michael Neuling authored
These macros are using integers where they could be using logical names since they take registers. We are going to enforce this soon, so fix these up now. Signed-off-by:
-
Michael Neuling authored
LOAD_REG_ADDR define is just a wrapper around real instructions so we can just use real register names here (ie. lower case). Signed-off-by:
-
Michael Neuling authored
mtocrf define is just a wrapper around the real instructions so we can just use real register names here (ie. lower case). Also remove braces in macro so this is possible. Signed-off-by:
-
Benjamin Herrenschmidt authored
Move this duplicated definition to ppc_asm.h and remove the braces which prevent the use of %rN register names Signed-off-by: -
Michael Neuling authored
Merge the defines of VCPU_GPR from different places. Signed-off-by:
-
Michael Neuling authored
Merge the defines of STACKFRAMESIZE, STK_REG, STK_PARAM from different places. Signed-off-by:
-
