- Nov 23, 2014
-
-
Jingchang Lu authored
The LS1021A TWR is a low cost, high-performance evaluation, development and test platform supporting the LS1021A processor. It is optimized to support the high-bandwidth DDR3L memory and a full complement of high-speed SerDes ports. For more detail information about the LS1021A TWR board, please refer to LS1021A QorIQ Tower System Reference Manual. Signed-off-by: Chao Fu <B44548@freescale.com> Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Jingchang Lu authored
The LS1021A QorIQ development system (QDS) is a high-performance computing evaluation, development and test platform supporting the LS1021A processor. The LS1021A QDS is optimized to support the high-bandwidth DDR3LP/DDR4 memory and a full complement of high-speed SerDes ports. For more detail information about the LS1021AQDS, please refer to the QorIQ LS1021A Development System Reference Manual. Signed-off-by: Alison Wang <alison.wang@freescale.com> Signed-off-by: Chao Fu <B44548@freescale.com> Signed-off-by: Jason Jin <Jason.Jin@freescale.com> Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> Signed-off-by: Jaiprakash Singh <b44839@freescale.com> Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Jingchang Lu authored
This add Freescale QorIQ LS1021A SoC device tree support. The QorIQ LS1021A processor incorporates dual ARM Cortex-A7 cores, providing virtualization support, advanced security features and the broadest array of high-speed interconnects and optimized peripheral features. The LS1021A SoC shares IPs with i.MX, Vybrid and PowerPC platform. For the detail information about Freescale QorIQ LS1021A SoC, please refer to the QorIQ LS1021A Reference Manual. Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com> Signed-off-by: Chenhui Zhao <chenhui.zhao@freescale.com> Signed-off-by: Suresh Gupta <suresh.gupta@freescale.com> Signed-off-by: Shaveta Leekha <shaveta@freescale.com> Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> Signed-off-by: Chao Fu <b44548@freescale.com> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Alison Wang <alison.wang@freescale.com> Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Vladimir Zapolskiy authored
On registration I2C bus drivers attemp to get ids from device tree aliases, add a missing alias for I2C4 found on iMX6 DualLite/Solo. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Soeren Moch authored
TBS2910 is a i.MX6Q based board. For additional details refer to http://www.tbsdtv.com/products/tbs2910-matrix-arm-mini-pc.html Signed-off-by: Soeren Moch <smoch@web.de> Reviewed-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Fugang Duan authored
Add enet2 support for imx6sx-sdb board, and add the "fsl,imx6q-fec" compatible for fec2 node to be compatible with the old version. Signed-off-by: Fugang Duan <B38611@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Lucas Stach authored
Add all required properties for the cpufreq-dt driver. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Sanchayan Maity authored
Enable ADC support for Colibri VF61 modules Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Bhuvanchandra DV authored
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Acked-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Bhuvanchandra DV authored
The Colibri standard defines four pins as PWM outputs, two of them (PWM A and C) are routed to FTM instance 0 and the other two (PWM B and D) are routed to FTM instance 1. Hence enable both FTM instances for the Colibri module and mux the four pins accordingly. Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Acked-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Bhuvanchandra DV authored
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Stefan Agner authored
Add Global Timer support which is part of the private peripherals of the Cortex-A5 processor. This Global Timer is compatible with the Cortex-A9 implementation. It's a 64-bit timer and is clocked by the peripheral clock, which is typically 133 or 166MHz on Vybrid. Signed-off-by: Stefan Agner <stefan@agner.ch> Acked-by: Bill Pringlemeir <bpringlemeir@nbsps.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Fabio Estevam authored
SSI block has 'ipg' clock for internal peripheral access and also 'baud' clock for generating bit clock when SSI operates in master mode. Add the extra 'baud' clock so that we can have SSI functional in master mode. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Fabio Estevam authored
SSI block has 'ipg' clock for internal peripheral access and also 'baud' clock for generating bit clock when SSI operates in master mode. Add the extra 'baud' clock so that we can have SSI functional in master mode. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Arnd Bergmann authored
The newly introduced LS1021A SoC selects CONFIG_SOC_FSL, which is originally symbol used for the PowerPC based platforms and guards lots of code that does not build on ARM. This breaks allmodconfig, so let's remove it for now, until either all those drivers are fixed or they use a dependency on IMX instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Stefan Agner authored
With the clock assignment device tree changes, the clocks get initialized properly but the search for those clocks fails with errors: [ 0.000000] i.MX clk 4: register failed with -17 [ 0.000000] i.MX clk 5: register failed with -17 This is because the module can't find those clocks anymore, and tries to initialize fixed clocks with the same name. Get the clock modules input clocks from the assigned clocks by default by using of_clk_get_by_name(). If this function returns not a valid clock, fall back to the old behaviour and search the input clock from the device tree's /clocks/$name node. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Jingchang Lu authored
Freescale LS1021A SoCs deploy two cortex-A7 processors, this adds bring-up support for the secondary core. Signed-off-by: Jingchang Lu <b35083@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Jingchang Lu authored
The LS1021A SoC is a dual-core Cortex-A7 based processor, this adds the initial support for it. Signed-off-by: Jingchang Lu <b35083@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Lucas Stach authored
Instanciate device for the generic cpufreq-dt driver. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Lucas Stach authored
The ARM clock is a virtual clock feeding the ARM partition of the SoC. It controls multiple other clocks to ensure the right sequencing when cpufreq changes the CPU clock rate. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Lucas Stach authored
This implements a virtual clock used to abstract away all the steps needed in order to change the ARM clock, so we don't have to push all this clock handling into the cpufreq driver. While it will be used for i.MX53 at first it is generic enough to be used on i.MX6 later on. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Lucas Stach authored
This is the bypass clock used to feed the ARM partition while we reprogram PLL1 to another rate. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Fugang Duan authored
Add enet init for i.mx6sx: - Add phy ar8031 fixup - Set enet clock source from internal PLL Signed-off-by: Fugang Duan <B38611@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Stefan Agner authored
Add the ARM Global Timer as clocksource/scheduler clock option and use it as default scheduler clock. This leaves the PIT timer for other users e.g. the secondary Cortex-M4 core. Also, the Global Timer has double the precission (running at pheripheral clock compared to IPG clock) and a 64-bit incrementing counter register. We still keep the PIT timer as an secondary option in case the ARM Global Timer is not available. Signed-off-by: Stefan Agner <stefan@agner.ch> Acked-by: Bill Pringlemeir <bpringlemeir@nbsps.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Anson Huang authored
For LPDDR2 platform, no need to enable weak2P5 in DSM mode, it can be pulled down to save power(~0.65mW). And per design team's recommendation, we should disconnect VDDHIGH and SNVS in DSM mode on i.MX6SL. Signed-off-by: Anson Huang <b20788@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
Anson Huang authored
As the DDR/IO and MMDC setting are different on LPDDR2 and DDR3, we used cpu type to decide how to do these settings in suspend before which is NOT flexible, take i.MX6SL for example, although it has LPDDR2 on EVK board, but users can also use DDR3 on other boards, so it is better to read the DDR type from MMDC then decide how to do related settings. Signed-off-by: Anson Huang <b20788@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
-
- Nov 04, 2014
-
-
Fabio Estevam authored
Since 64546e9f ("ARM: imx_v6_v7_defconfig updates") and commit 0650f855 ("ARM: imx_v4_v5_defconfig: Select CONFIG_IMX_WEIM") CONFIG_SPI selection was dropped by savedefconfig for imx_v4_v5_defconfig and imx_v6_v7_defconfig. In order to keep the same behaviour as previous kernel versions and avoid regressions, let's add CONFIG_SPI option back. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
Stefan Agner authored
So far, the required PLL's (PLL1/PLL2/PLL5) have been initialized by boot loader and the kernel code defined fixed rates according to those default configurations. Beginning with the USB PLL7 the code started to initialize the PLL's itself (using imx_clk_pllv3). However, since commit dc4805c2 (ARM: imx: remove ENABLE and BYPASS bits from clk-pllv3 driver) imx_clk_pllv3 no longer takes care of the ENABLE and BYPASS bits, hence the USB PLL were not configured correctly anymore. This patch not only fixes those USB PLL's, but also makes use of the imx_clk_pllv3 for all PLL's and alignes the code with the PLL support of the i.MX6 series. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
-
- Nov 02, 2014
-
-
Paolo Bonzini authored
Most call paths to vmx_vcpu_reset do not hold the SRCU lock. Defer loading the APIC access page to the next vmentry. This avoids the following lockdep splat: [ INFO: suspicious RCU usage. ] 3.18.0-rc2-test2+ #70 Not tainted ------------------------------- include/linux/kvm_host.h:474 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by qemu-system-x86/2371: #0: (&vcpu->mutex){+.+...}, at: [<ffffffffa037d800>] vcpu_load+0x20/0xd0 [kvm] stack backtrace: CPU: 4 PID: 2371 Comm: qemu-system-x86 Not tainted 3.18.0-rc2-test2+ #70 Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A12 01/10/2013 0000000000000001 ffff880209983ca8 ffffffff816f514f 0000000000000000 ffff8802099b8990 ffff880209983cd8 ffffffff810bd687 00000000000fee00 ffff880208a2c000 ffff880208a10000 ffff88020ef50040 ffff880209983d08 Call Trace: [<ffffffff816f514f>] dump_stack+0x4e/0x71 [<ffffffff810bd687>] lockdep_rcu_suspicious+0xe7/0x120 [<ffffffffa037d055>] gfn_to_memslot+0xd5/0xe0 [kvm] [<ffffffffa03807d3>] __gfn_to_pfn+0x33/0x60 [kvm] [<ffffffffa0380885>] gfn_to_page+0x25/0x90 [kvm] [<ffffffffa038aeec>] kvm_vcpu_reload_apic_access_page+0x3c/0x80 [kvm] [<ffffffffa08f0a9c>] vmx_vcpu_reset+0x20c/0x460 [kvm_intel] [<ffffffffa039ab8e>] kvm_vcpu_reset+0x15e/0x1b0 [kvm] [<ffffffffa039ac0c>] kvm_arch_vcpu_setup+0x2c/0x50 [kvm] [<ffffffffa037f7e0>] kvm_vm_ioctl+0x1d0/0x780 [kvm] [<ffffffff810bc664>] ? __lock_is_held+0x54/0x80 [<ffffffff812231f0>] do_vfs_ioctl+0x300/0x520 [<ffffffff8122ee45>] ? __fget+0x5/0x250 [<ffffffff8122f0fa>] ? __fget_light+0x2a/0xe0 [<ffffffff81223491>] SyS_ioctl+0x81/0xa0 [<ffffffff816fed6d>] system_call_fastpath+0x16/0x1b Reported-by: Takashi Iwai <tiwai@suse.de> Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Reviewed-by: Wanpeng Li <wanpeng.li@linux.intel.com> Tested-by: Wanpeng Li <wanpeng.li@linux.intel.com> Fixes: 38b99173 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-
Jan Kiszka authored
In order to access the shadow VMCS, we need to load it. At this point, vmx->loaded_vmcs->vmcs and the actually loaded one start to differ. If we now get preempted by Linux, vmx_vcpu_put and, on return, the vmx_vcpu_load will work against the wrong vmcs. That can cause copy_shadow_to_vmcs12 to corrupt the vmcs12 state. Fix the issue by disabling preemption during the copy operation. copy_vmcs12_to_shadow is safe from this issue as it is executed by vmx_vcpu_run when preemption is already disabled before vmentry. This bug is exposed by running Jailhouse within KVM on CPUs with shadow VMCS support. Jailhouse never expects an interrupt pending vmexit, but the bug can cause it if, after copy_shadow_to_vmcs12 is preempted, the active VMCS happens to have the virtual interrupt pending flag set in the CPU-based execution controls. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-
Nadav Amit authored
Commit d1442d85 ("KVM: x86: Handle errors when RIP is set during far jumps") introduced a bug that caused the fix to be incomplete. Due to incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may not trigger #GP. As we know, this imposes a security problem. In addition, the condition for two warnings was incorrect. Fixes: d1442d85 Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Nadav Amit <namit@cs.technion.ac.il> [Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-
- Nov 01, 2014
-
-
Andy Lutomirski authored
Rusty noticed a Really Bad Bug (tm) in my NT fix. The entry code reads out of bounds, causing the NT fix to be unreliable. But, and this is much, much worse, if your stack is somehow just below the top of the direct map (or a hole), you read out of bounds and crash. Excerpt from the crash: [ 1.129513] RSP: 0018:ffff88001da4bf88 EFLAGS: 00010296 2b:* f7 84 24 90 00 00 00 testl $0x4000,0x90(%rsp) That read is deterministically above the top of the stack. I thought I even single-stepped through this code when I wrote it to check the offset, but I clearly screwed it up. Fixes: 8c7aa698 ("x86_64, entry: Filter RFLAGS.NT on entry from userspace") Reported-by: Rusty Russell <rusty@ozlabs.org> Cc: stable@vger.kernel.org Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Tony Lindgren authored
With legacy booting, the platform init code was taking care of the configuring of GPIOs. With device tree based booting, things may or may not work depending what bootloader has configured or if the legacy platform code gets called. Let's add support for the pwrdn and reset GPIOs to the smc91x driver to fix the issues of smc91x not working properly when booted in device tree mode. And let's change n900 to use these settings as some versions of the bootloader do not configure things properly causing errors. Reported-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- Oct 30, 2014
-
-
Andriy Skulysh authored
Resources scif1_resources & scif2_resources overlap. Actual SCIF region size is 0x10. This is regression from commit d850acf9 ("sh: Declare SCIF register base and IRQ as resources") Signed-off-by: Andriy Skulysh <askulysh@gmail.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Thomas Petazzoni authored
Since CONFIG_HIGHMEM got enabled on ARMv5 Kirkwood, we have noticed a very significant drop in networking performance. The test were conducted on an OpenBlocks A7 board. Without this patch, the outgoing performance measured with iperf are: - highmem OFF, TSO OFF 544 Mbit/s - highmem OFF, TSO ON 942 Mbit/s - highmem ON, TSO OFF 306 Mbit/s - highmem ON, TSO ON 246 Mbit/s On this Kirkwood platform, the L2 cache is a Feroceon cache, and with this cache, all the range operations have to be done on virtual addresses and not physical addresses. Therefore, whenever CONFIG_HIGHMEM is enabled, the cache maintenance operations call kmap_atomic_pfn() and kunmap_atomic(). However, kmap_atomic_pfn() does not implement the same fast path for non-highmem pages as the one implemented in kmap_atomic(), and this is one of the reason for the performance drop. While this patch does not fully restore the performances, it clearly improves them a lot: without patch with patch - highmem ON, TSO OFF 306 Mbit/s 387 Mbit/s - highmem ON, TSO ON 246 Mbit/s 434 Mbit/s We're still far from the !CONFIG_HIGHMEM performances, but it does improve a bit the situation. Thanks a lot to Ezequiel Garcia and Gregory Clement for all the testing work around this topic. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Fabio Estevam authored
Russell King suggested [1]: "I'd ask for one change. Please make all these messages start with "L2C-310 OF" not "PL310 OF:". The device is described in ARM documentation as a L2C-310 not PL310. (Also note the : is dropped too - most of the other messages don't have the : either.) The: "PL310 OF: cache setting yield illegal associativity PL310 OF: -1073346556 calculated, only 8 and 16 legal" message could also be changed to something like: "L2C-310 OF cache associativity %d invalid, only 8 or 16 permittedn" [1] http://www.spinics.net/lists/arm-kernel/msg372776.html Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Laura Abbott authored
Commit 513510dd (common: dma-mapping: introduce common remapping functions) managed to end up with an extra return statement from the original patch. Drop it. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- Oct 29, 2014
-
-
Paolo Bonzini authored
Emulation of code that is 14 bytes to the segment limit or closer (e.g. RIP = 0xFFFFFFF2 after reset) is broken because we try to read as many as 15 bytes from the beginning of the instruction, and __linearize fails when the passed (address, size) pair reaches out of the segment. To fix this, let __linearize return the maximum accessible size (clamped to 2^32-1) for usage in __do_insn_fetch_bytes, and avoid the limit check by passing zero for the desired size. For expand-down segments, __linearize is performing a redundant check. (u32)(addr.ea + size - 1) <= lim can only happen if addr.ea is close to 4GB; in this case, addr.ea + size - 1 will also fail the check against the upper bound of the segment (which is provided by the D/B bit). After eliminating the redundant check, it is simple to compute the *max_size for expand-down segments too. Now that the limit check is done in __do_insn_fetch_bytes, we want to inject a general protection fault there if size < op_size (like __linearize would have done), instead of just aborting. This fixes booting Tiano Core from emulated flash with EPT disabled. Cc: stable@vger.kernel.org Fixes: 719d5a9b Reported-by: Borislav Petkov <bp@suse.de> Tested-by: Borislav Petkov <bp@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
The error code for #GP and #SS is zero when the segment is used to access an operand or an instruction. It is only non-zero when a segment register is being loaded; for limit checks this means cases such as: * for #GP, when RIP is beyond the limit on a far call (before the first instruction is executed). We do not implement this check, but it would be in em_jmp_far/em_call_far. * for #SS, if the new stack overflows during an inter-privilege-level call to a non-conforming code segment. We do not implement stack switching at all. So use an error code of zero. Reviewed-by: Nadav Amit <namit@cs.technion.ac.il> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-
Fabio Estevam authored
Since commit f3354ab6 ("ARM: 8169/1: l2c: parse cache properties from ePAPR definitions") the following error is seen on imx6q: [ 0.000000] PL310 OF: cache setting yield illegal associativity [ 0.000000] PL310 OF: -2147097556 calculated, only 8 and 16 legal As imx6q does not pass the "cache-size" and "cache-sets" properties in DT, the function l2x0_cache_size_of_parse() returns early and keep the 'associativity' pointer uninitialized. To fix this problem, return error codes inside l2x0_cache_size_of_parse() and only use the 'associativity' pointer result if l2x0_cache_size_of_parse() succeeds. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-