- Oct 16, 2015
-
-
Tony Lindgren authored
Looks like thevarious omap5-uevm models and igepv5 are very similar. So let's create omap5-board-common.dtsi to allow fixing up things properly for mainline kernel to support all these. Even if we eventually end up having only PMIC + MMC + eMMC + SDIO WLAN + SATA + USB + HDMI configuration in the omap5-board-common.dtsi, this is the easiest way to add support for other boards rather than diffing various versions of out of tree dts files. My guess is that also omap5-sbc-t54.dts can use this, but I don't have that board so that will need to be dealt with later on. Signed-off-by:Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Commit 99f84cae ("ARM: dts: add wl12xx/wl18xx bindings") added device tree bindings for the TI WLAN SDIO on many omap variants. I recall wondering how come omap5-uevm did not have the WLAN added and this issue has been bugging me for a while now, and I finally tracked it down to a bad pinmux regression, and a missing deferred probe handling for the 32k clock from palmas that's requested by twl6040. Basically 392adaf7 ("ARM: dts: omap5-evm: Add mcspi data") added pin muxing for mcspi4 that conflicts with the onboard WLAN. While some omap5-uevm don't have WLAN populated, the pins are not reused for other devices. And as the SDIO bus should be probed, let's try to enable WLAN by default. Let's fix the regression and add the WLAN configuration as done for the other boards in 99f84cae ("ARM: dts: add wl12xx/wl18xx bindings"). And let's use the new MMC pwrseq for the 32k clock as suggested by Javier Martinez Canillas <javier@dowhile0.org>. Note that without a related deferred probe fix for twl6040, the 32k clock is not initialized if palmas-clk is a module and twl6040 is built-in. Let's also use the generic "non-removable" instead of the legacy "ti,non-removable" property while at it. And finally, note that omap5 seems to require WAKEUP_EN for the WLAN GPIO interrupt. Fixes: 392adaf7 ("ARM: dts: omap5-evm: Add mcspi data") Cc: Sourav Poddar <sourav.poddar@ti.com> Signed-off-by:
-
- Oct 14, 2015
-
-
Laurent Pinchart authored
Use the macro instead of absolute register offsets to make the code more readable as the values now match register addresses from the datasheet. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
-
- Oct 12, 2015
-
-
Mugunthan V N authored
As per mmc device tree binding documentation card detect gpio has to be active low signal. When a hardware is designed with active high card detect, gpio polarity has to be changed with cd-inverted dt property. In DRA74x, DRA72x and AM57xx EVMs the card detect gpio is designed as active low gpio. So correcting the dt card detect gpio definition. Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
-
Mugunthan V N authored
As per mmc device tree binding documentation card detect gpio has to be active low signal. When a hardware is designed with active high card detect, gpio polarity has to be changed with cd-inverted dt property. In AM43xx the card detect gpio is designed as active low gpio. So correcting the dt card detect gpio definition. Signed-off-by:
-
Mugunthan V N authored
As per mmc device tree binding documentation card detect gpio has to be active low signal. When a hardware is designed with active high card detect, gpio polarity has to be changed with cd-inverted dt property. In AM335x the card detect gpio is designed as active low gpio. So correcting the dt card detect gpio definition. Signed-off-by:
-
Laurent Pinchart authored
uart2 pinmux is already defined in omap3-igep0020-common.dtsi, remove the duplicate node. Signed-off-by:
-
Laurent Pinchart authored
Use tabs instead of spaces for indentation. Signed-off-by:
-
Javier Martinez Canillas authored
The card detect GPIO is using IRQ_TYPE_LEVEL_LOW in the GPIO flag cells but this defined constant is meant to be used for a IRQ and not a GPIO. So instead use GPIO_ACTIVE_LOW that seems to be the original intention. Signed-off-by:
-
Suman Anna authored
The DRA74x family of SoCs have a second DSP, that also has two MMUs just like the DSP1 subsystem. Add the IOMMU nodes for this DSP2 subsystem in disabled state to the DRA74x specific DTS file, the nodes would need to be enabled appropriately in the respective board DTS files. Signed-off-by:
Suman Anna <s-anna@ti.com> Signed-off-by:
-
Suman Anna authored
The DRA7xx family of SOCs have two IPUs and one DSP processor subsystems in common. The IOMMU DT nodes have been added for these processor subsystems, and have been disabled by default. These MMUs are very similar to those on OMAP4 and OMAP5, with the only difference being the presence of a second MMU within the DSP subsystem for the EDMA port. The DSP IOMMUs also need an additional 'ti,syscon-mmuconfig' property compared to the IPU IOMMUs. NOTE: The enabling of these nodes is left to the respective board dts files. Signed-off-by:
-
Suman Anna authored
The DSP_SYSTEM sub-module is a dedicated system control logic module present within a DRA7 DSP processor sub-system. This module is responsible for power management, clock generation and connection to the device PRCM module. Add a syscon node for this module for the DSP2 processor sub-system. This is added as a syscon node as it is a common configuration module that can be used by the different IOMMU instances and the corresponding remoteproc device. The node is added to the dra74x.dtsi file, as the DSP2 processor subsystem is usually present only on the DRA74x variants of the DRA7 SoC family. Signed-off-by:
-
Suman Anna authored
The DSP_SYSTEM sub-module is a dedicated system control logic module present within a DRA7 DSP processor sub-system. This module is responsible for power management, clock generation and connection to the device PRCM module. Add a syscon node for this module for the DSP1 processor sub-system. This is added as a syscon node as it is a common configuration module that can be used by the different IOMMU instances and the corresponding remoteproc device. The node is added to the common dra7.dtsi file, as the DSP1 processor sub-system is mostly common across all the variants of the DRA7 SoC family. Signed-off-by:
-
Javier Martinez Canillas authored
Many OMAP2+ DTS are not using the defined constants to express the GPIO polarity. Replace these so the DTS are easier to read. Signed-off-by:
-
Robert Nelson authored
SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) minus the HDMI port and addition of two Grove connectors (i2c2 and usart2). This board can be identified by the 1A value after A335BNLT (BBB) in the at24 eeprom: 1A: [aa 55 33 ee 41 33 33 35 42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT....|] http://beagleboard.org/green http://www.seeedstudio.com/wiki/Beaglebone_green Signed-off-by:
Robert Nelson <robertcnelson@gmail.com> CC: Tony Lindgren <tony@atomide.com> CC: Jason Kridner <jkridner@gmail.com> Signed-off-by:
-
Suman Anna authored
Enable the System Mailboxes 5 and 6 and the corresponding child sub-mailbox (IPC 3.x) nodes for the Beagle X15 EVM boards. This is needed to enable communication with the respective remote processors IPU1, IPU2, DSP1 and DSP2 from the MPU. Signed-off-by:
-
Suman Anna authored
Enable the System Mailboxes 5 and 6 and the corresponding child sub-mailbox (IPC 3.x) nodes for the DRA72 EVM board. This is needed to enable communication with the respective remote processors IPU1, IPU2, and DSP1 from the MPU. Signed-off-by:
-
Suman Anna authored
Enable the System Mailboxes 5 and 6 and the corresponding child sub-mailbox (IPC 3.x) nodes for the DRA7 EVM board. This is needed to enable communication with the respective remote processors IPU1, IPU2, DSP1 and DSP2 from the MPU. Signed-off-by:
-
Suman Anna authored
Add the sub-mailbox nodes that are used to communicate between MPU and the remote processors IPU1, IPU2 and DSP1. These match the respective node definitions on DRA74x to maintain compatibility for the equivalent remote processors. There is no DSP2 on DRA72x, and so the corresponding sub-mailbox node is not added. These sub-mailbox nodes are added to match the hard-coded mailbox configuration used within the TI IPC 3.x software package. The Dual-Cortex M4 IPU1 and IPU2 processor sub-systems are assumed to be running in SMP-mode, and hence only a single sub-mailbox node is added for each. All these sub-mailbox nodes are left in disabled state, and should be enabled (and modified if needed) as per the individual product configuration in the corresponding board dts files. Signed-off-by:
-
Suman Anna authored
Add the sub-mailbox nodes that are used to communicate between MPU and the remote processors IPU1, IPU2, DSP1 and DSP2. The sub-mailbox nodes utilize the System Mailbox instances 5 and 6. These sub-mailbox nodes are added to match the hard-coded mailbox configuration used within the TI IPC 3.x software package. The Dual-Cortex M4 IPU1 and IPU2 processor sub-systems are assumed to be running in SMP-mode, and hence only a single sub-mailbox node is added for each. All these sub-mailbox nodes are left in disabled state, and should be enabled (and modified if needed) as per the individual product configuration in the corresponding board dts files. Signed-off-by:
-
Teresa Remmet authored
Cleaned up the regulators on the wega board. Created a simple bus, renamed the regulators according to the schematics and added missing regulator on wega. Signed-off-by:
Teresa Remmet <t.remmet@phytec.de> Signed-off-by:
-
Grygorii Strashko authored
dra7-evm has 2 gpio keys wired through TS_LCD_GPIO3, TS_LCD_GPIO4 which in turn connected to PCF8575 GPIO pcf_lcd: gpio@20 expander pins 2 and 3. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Grygorii Strashko authored
dra7-evm has 4 user gpio leds connected to PCF8575 GPIO pcf_lcd: gpio@20 expander pins [4,5,6,7], so add corresponding DT nodes. Do not enable any triggers by default as not all of them are proved to work on -RT. Signed-off-by:
-
Grygorii Strashko authored
This patch adds DT definition for CF8575 GPIO pcf_lcd: gpio@20 expander which is connected to i2c bus 1 and has slave address 0x20. It allows to control: - tc_lcd gpios, pins p0-p3 - user leds, pins p4-p7 - control LCD panel power, p15 PCF8575 GPIO pcf_lcd: gpio@20 expander supports interrupt controller functionality and its INT line is connected to dra7 GPIO6.11 pin. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Peter Ujfalusi authored
The analog audio setup consists of: McASP3 <-> tlv320aic3104 codec Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Peter Ujfalusi authored
The DVDD is supplied via TPS77018DBVT fixed regulator from vdd_3v3 Signed-off-by:
-
Peter Ujfalusi authored
The board uses tlv320aic3106 codec connected to McASP3. The master clock for the codec and McASP3 is coming from ATL2. McASP3 is the master on the I2S bus. Signed-off-by:
-
Peter Ujfalusi authored
The GPIO expander's p1 on i2c5 bus 0x26 address is used for selecting between audio and VIN6 functionality. For VIN6 use an add on card is needed while audio is present on the board itself. Select the audio functionality over the VIN6 in the dts file. Signed-off-by:
-
Peter Ujfalusi authored
The DVDD is supplied via TPS77018DBVT fixed regulator from evm_3v3 Signed-off-by:
Darren Etheridge <detheridge@ti.com> Signed-off-by:
-
Peter Ujfalusi authored
The board uses tlv320aic3106 codec connected to McASP3. The master clock for the codec and McASP3 is coming from ATL2. McASP3 is the master on the I2S bus. Signed-off-by:
-
Peter Ujfalusi authored
This GPIO expander is used for controlling various muxes on the board. By default select audio functionality over VIN6 by setting the P1 (vin6_sel_s0) pin to low. Signed-off-by:
-
Peter Ujfalusi authored
TPS77018DBVT is used to create 1.8V from avm_3v3_sw's 3.3V connected to aic3106's DVDD. Signed-off-by:
-
Peter Ujfalusi authored
Use the name for the supply as it is in the schematics since the same supply is used for other peripherals than MMC2, like audio. Signed-off-by:
-
Peter Ujfalusi authored
Signed-off-by:
-
Roger Quadros authored
Add DCAN sleep pins to save some power during suspend. Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
- Oct 04, 2015
-
-
Markos Chandras authored
The MIPS syscall handler code used to return -ENOSYS on invalid syscalls. Whilst this is expected, it caused problems for seccomp filters because the said filters never had the change to run since the code returned -ENOSYS before triggering them. This caused problems on the chromium testsuite for filters looking for invalid syscalls. This has now changed and the seccomp filters are always run even if the syscall is invalid. We return -ENOSYS once we return from the seccomp filters. Moreover, similar codepaths have been merged in the process which simplifies somewhat the overall syscall code. Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11236/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
- Oct 02, 2015
-
-
Matt Bennett authored
During development it was found that a number of builds would panic during the kernel init process, more specifically in 'delayed_fput()'. The panic showed the kernel trying to access a memory address of '0xb7fdc00' while traversing the 'delayed_fput_list' structure. Comparing this memory address to the value of the pointer used on builds that did not panic confirmed that the pointer on crashing builds must have been corrupted at some stage earlier in the init process. By traversing the list earlier and earlier in the code it was found that 'plat_mem_setup()' was responsible for corrupting the list. Specifically the line: memory = cvmx_bootmem_phy_alloc(mem_alloc_size, __pa_symbol(&__init_end), -1, 0x100000, CVMX_BOOTMEM_FLAG_NO_LOCKING); Which would eventually call: cvmx_bootmem_phy_set_size(new_ent_addr, cvmx_bootmem_phy_get_size (ent_addr) - (desired_min_addr - ent_addr)); Where 'new_ent_addr'=0x4800000 (the address of 'delayed_fput_list') and the second argument (size)=0xb7fdc00 (the address causing the kernel panic). The job of this part of 'plat_mem_setup()' is to allocate chunks of memory for the kernel to use. At the start of each chunk of memory the size of the chunk is written, hence the value 0xb7fdc00 is written onto memory at 0x4800000, therefore the kernel panics when it goes back to access 'delayed_fput_list' later on in the initialisation process. On builds that were not crashing it was found that the compiler had placed 'delayed_fput_list' at 0x4800008, meaning it wasn't corrupted (but something else in memory was overwritten). As can be seen in the first function call above the code begins to allocate chunks of memory beginning from the symbol '__init_end'. The MIPS linker script (vmlinux.lds.S) however defines the .bss section to begin after '__init_end'. Therefore memory within the .bss section is allocated to the kernel to use (System.map shows 'delayed_fput_list' and other kernel structures to be in .bss). To stop the kernel panic (and the .bss section being corrupted) memory should begin being allocated from the symbol '_end'. Signed-off-by:Matt Bennett <matt.bennett@alliedtelesis.co.nz> Acked-by:
David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: aleksey.makarov@auriga.com Patchwork: https://patchwork.linux-mips.org/patch/11251/ Signed-off-by:
-
Paul Burton authored
Commit 1a3d5957 ("MIPS: Tidy up FPU context switching") removed FP context saving from the asm-written resume function in favour of reusing existing code to perform the same task. However it only removed the FP context saving code from the r4k_switch.S implementation of resume. Remove it from the r2300_switch.S implementation too in order to prevent attempting to save the FP context twice, which would likely lead to an exception from the second save because the FPU had already been disabled by the first save. This patch has only been build tested, using rbtx49xx_defconfig. Fixes: 1a3d5957 ("MIPS: Tidy up FPU context switching") Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-kernel@vger.kernel.org Cc: Manuel Lauss <manuel.lauss@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/11167/ Signed-off-by:
-
Paul Burton authored
Commit 1a3d5957 ("MIPS: Tidy up FPU context switching") removed FP context saving from the asm-written resume function in favour of reusing existing code to perform the same task. However it only removed the FP context saving code from the r4k_switch.S implementation of resume. Octeon uses its own implementation in octeon_switch.S, so remove FP context saving there too in order to prevent attempting to save context twice. That formerly led to an exception from the second save as follows because the FPU had already been disabled by the first save: do_cpu invoked from kernel context![#1]: CPU: 0 PID: 2 Comm: kthreadd Not tainted 4.3.0-rc2-dirty #2 task: 800000041f84a008 ti: 800000041f864000 task.ti: 800000041f864000 $ 0 : 0000000000000000 0000000010008ce1 0000000000100000 ffffffffbfffffff $ 4 : 800000041f84a008 800000041f84ac08 800000041f84c000 0000000000000004 $ 8 : 0000000000000001 0000000000000000 0000000000000000 0000000000000001 $12 : 0000000010008ce3 0000000000119c60 0000000000000036 800000041f864000 $16 : 800000041f84ac08 800000000792ce80 800000041f84a008 ffffffff81758b00 $20 : 0000000000000000 ffffffff8175ae50 0000000000000000 ffffffff8176c740 $24 : 0000000000000006 ffffffff81170300 $28 : 800000041f864000 800000041f867d90 0000000000000000 ffffffff815f3fa0 Hi : 0000000000fa8257 Lo : ffffffffe15cfc00 epc : ffffffff8112821c resume+0x9c/0x200 ra : ffffffff815f3fa0 __schedule+0x3f0/0x7d8 Status: 10008ce2 KX SX UX KERNEL EXL Cause : 1080002c (ExcCode 0b) PrId : 000d0601 (Cavium Octeon+) Modules linked in: Process kthreadd (pid: 2, threadinfo=800000041f864000, task=800000041f84a008, tls=0000000000000000) Stack : ffffffff81604218 ffffffff815f7e08 800000041f84a008 ffffffff811681b0 800000041f84a008 ffffffff817e9878 0000000000000000 ffffffff81770000 ffffffff81768340 ffffffff81161398 0000000000000001 0000000000000000 0000000000000000 ffffffff815f4424 0000000000000000 ffffffff81161d68 ffffffff81161be8 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ffffffff8111e16c 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ... Call Trace: [<ffffffff8112821c>] resume+0x9c/0x200 [<ffffffff815f3fa0>] __schedule+0x3f0/0x7d8 [<ffffffff815f4424>] schedule+0x34/0x98 [<ffffffff81161d68>] kthreadd+0x180/0x198 [<ffffffff8111e16c>] ret_from_kernel_thread+0x14/0x1c Tested using cavium_octeon_defconfig on an EdgeRouter Lite. Fixes: 1a3d5957 ("MIPS: Tidy up FPU context switching") Reported-by:
Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by:
-
Li Bin authored
When function graph tracer is enabled, the following operation will trigger panic: mount -t debugfs nodev /sys/kernel echo next_tgid > /sys/kernel/tracing/set_ftrace_filter echo function_graph > /sys/kernel/tracing/current_tracer ls /proc/ ------------[ cut here ]------------ [ 198.501417] Unable to handle kernel paging request at virtual address cb88537fdc8ba316 [ 198.506126] pgd = ffffffc008f79000 [ 198.509363] [cb88537fdc8ba316] *pgd=00000000488c6003, *pud=00000000488c6003, *pmd=0000000000000000 [ 198.517726] Internal error: Oops: 94000005 [#1] SMP [ 198.518798] Modules linked in: [ 198.520582] CPU: 1 PID: 1388 Comm: ls Tainted: G [ 198.521800] Hardware name: linux,dummy-virt (DT) [ 198.522852] task: ffffffc0fa9e8000 ti: ffffffc0f9ab0000 task.ti: ffffffc0f9ab0000 [ 198.524306] PC is at next_tgid+0x30/0x100 [ 198.525205] LR is at return_to_handler+0x0/0x20 [ 198.526090] pc : [<ffffffc0002a1070>] lr : [<ffffffc0000907c0>] pstate: 60000145 [ 198.527392] sp : ffffffc0f9ab3d40 [ 198.528084] x29: ffffffc0f9ab3d40 x28: ffffffc0f9ab0000 [ 198.529406] x27: ffffffc000d6a000 x26: ffffffc000b786e8 [ 198.530659] x25: ffffffc0002a1900 x24: ffffffc0faf16c00 [ 198.531942] x23: ffffffc0f9ab3ea0 x22: 0000000000000002 [ 198.533202] x21: ffffffc000d85050 x20: 0000000000000002 [ 198.534446] x19: 0000000000000002 x18: 0000000000000000 [ 198.535719] x17: 000000000049fa08 x16: ffffffc000242efc [ 198.537030] x15: 0000007fa472b54c x14: ffffffffff000000 [ 198.538347] x13: ffffffc0fada84a0 x12: 0000000000000001 [ 198.539634] x11: ffffffc0f9ab3d70 x10: ffffffc0f9ab3d70 [ 198.540915] x9 : ffffffc0000907c0 x8 : ffffffc0f9ab3d40 [ 198.542215] x7 : 0000002e330f08f0 x6 : 0000000000000015 [ 198.543508] x5 : 0000000000000f08 x4 : ffffffc0f9835ec0 [ 198.544792] x3 : cb88537fdc8ba316 x2 : cb88537fdc8ba306 [ 198.546108] x1 : 0000000000000002 x0 : ffffffc000d85050 [ 198.547432] [ 198.547920] Process ls (pid: 1388, stack limit = 0xffffffc0f9ab0020) [ 198.549170] Stack: (0xffffffc0f9ab3d40 to 0xffffffc0f9ab4000) [ 198.582568] Call trace: [ 198.583313] [<ffffffc0002a1070>] next_tgid+0x30/0x100 [ 198.584359] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70 [ 198.585503] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70 [ 198.586574] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70 [ 198.587660] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70 [ 198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60) [ 198.591092] ---[ end trace 6a346f8f20949ac8 ]--- This is because when using function graph tracer, if the traced function return value is in multi regs ([x0-x7]), return_to_handler may corrupt them. So in return_to_handler, the parameter regs should be protected properly. Cc: <stable@vger.kernel.org> # 3.18+ Signed-off-by:
Li Bin <huawei.libin@huawei.com> Acked-by:
AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
