| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Huang Shijie <b32955@freescale.com>
|
|
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Huang Shijie <b32955@freescale.com>
|
|
Use devm_ioremap_resource() in order to make the code simpler and
it gives proper codes on errors.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Huang Shijie <b32955@freescale.com>
|
|
LDISCs shouldn't call tty->ops->write() from within
->write_wakeup().
->write_wakeup() is called with port lock taken and
IRQs disabled, tty->ops->write() will try to acquire
the same port lock and we will deadlock.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Reported-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Tested-by: Andreas Bießmann <andreas@biessmann.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Huang Shijie <b32955@freescale.com>
|
|
In the uart_handle_cts_change(), uart_write_wakeup() is called after
we call @uart_port->ops->start_tx().
The Documentation/serial/driver tells us:
-----------------------------------------------
start_tx(port)
Start transmitting characters.
Locking: port->lock taken.
Interrupts: locally disabled.
-----------------------------------------------
So when the uart_write_wakeup() is called, the port->lock is taken by
the upper. See the following callstack:
|_ uart_write_wakeup
|_ tty_wakeup
|_ ld->ops->write_wakeup
With the port->lock held, we call the @write_wakeup. Some implemetation of
the @write_wakeup does not notice that the port->lock is held, and it still
tries to send data with uart_write() which will try to grab the prot->lock.
A dead lock occurs, see the following log caught in the Bluetooth by uart:
--------------------------------------------------------------------
BUG: spinlock lockup suspected on CPU#0, swapper/0/0
lock: 0xdc3f4410, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.10.17-16839-ge4a1bef #1320
[<80014cbc>] (unwind_backtrace+0x0/0x138) from [<8001251c>] (show_stack+0x10/0x14)
[<8001251c>] (show_stack+0x10/0x14) from [<802816ac>] (do_raw_spin_lock+0x108/0x184)
[<802816ac>] (do_raw_spin_lock+0x108/0x184) from [<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60)
[<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60) from [<802f5754>] (uart_write+0x38/0xe0)
[<802f5754>] (uart_write+0x38/0xe0) from [<80455270>] (hci_uart_tx_wakeup+0xa4/0x168)
[<80455270>] (hci_uart_tx_wakeup+0xa4/0x168) from [<802dab18>] (tty_wakeup+0x50/0x5c)
[<802dab18>] (tty_wakeup+0x50/0x5c) from [<802f81a4>] (imx_rtsint+0x50/0x80)
[<802f81a4>] (imx_rtsint+0x50/0x80) from [<802f88f4>] (imx_int+0x158/0x17c)
[<802f88f4>] (imx_int+0x158/0x17c) from [<8007abe0>] (handle_irq_event_percpu+0x50/0x194)
[<8007abe0>] (handle_irq_event_percpu+0x50/0x194) from [<8007ad60>] (handle_irq_event+0x3c/0x5c)
--------------------------------------------------------------------
This patch adds more limits to the @write_wakeup, the one who wants to
implemet the @write_wakeup should follow the limits which avoid the deadlock.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
this patch fix gpu database query failure with gmem_info
Date: Apr 28, 2014
Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
(cherry picked from commit e04a8681a977153c7adf34c36d7ee33218cfcab3)
|
|
This patch fix the failure when OTG port switch from host to device mode
after removes ID cable with usb device(e.g usb hub) connected.
How to reproduce:
- Enable console wakeup:
echo enabled > /sys/class/tty/ttymxc0/power/wakeup
- Connect a usb hub with ID cable to OTG port.
- Suspend the system:
ehco mem > /sys/power/state
- Wakeup the system by console.
- Remove ID cable together with usb hub.
- OTG port cannot switch to device role.
Root cause:
In this case, ID change interrupt generates before port change interrupt,
so with irq disabled, ci_handle_id_switch() will find there is usb device
still connected and wait it to disconnect by sleep, but disconnect will not
happen since usb irq still disabled so port change irq has no chance to be
handled.
How this patch is fixing this issue:
This patch enables irq before sleep and disables irq after, thus port change
irq can be handled and usb device disconnection can timely happen, then
ci_handle_id_switch() can stop host and switch to device role correctly.
meanwhile change the delay time to 10~15 ms to avoid too frequent connection
check and irq enable/disable.
Signed-off-by: Li Jun <b47624@freescale.com>
|
|
On i.MX6SX, when CA9 and CM4 are working together, CA9 can
NOT disable those shared modules' clock, so keep those
clocks CM4 needs always enabled.
Signed-off-by: Anson Huang <b20788@freescale.com>
|
|
In VDOA PP mode, the input resolution would be changed to be VDOA's output
for PP to use as its input resolution to go on to do resizing or color space
conversion. The input resolution will be different from the original one
when VDOA input cropping is enabled. And, this finally causes a wrong input
resolution being used if the users do rotation by calling the S_CTRL ioctrl
in runtime. In order to fix this issue, this patch sets the original input
resolution back after PP task check and process. The issue can be reproduced
by the following command line(enable VDOA mode in the gst plugin configuration
file first):
gplay AVC_MP30_854x356_23.976_679_AACLC_44.1_96_2_TRON_LEGACY.flv
(Enter 't 90' to change to rotate 90 degrees in runtime.)
In this case, VDOA input cropping(854x356 -> 848x352) is enabled because VDOA
input resolution should align to macro block size.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
(cherry picked from commit 4c732ad69265d8e441e6c15a2e87f5aeef234624)
|
|
Since we've fixed the clock's shared-gate issue, we no longer
need this gate clock. Thus drop it.
Acked-by: Wang Shengjiu <b02247@freescale.com>
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit c368f9011aebb877aaffc6e4c5d12c7893b552b0)
|
|
Since we no longer use clk_set_rate() in spdif driver, the rate we provide
to it on imx6q/sl platforms is no more contented for its supporting sample
rates.
By setting the clock to 22736841Hz, we can get the sample rates:
48008Hz for 48000Hz
32005Hz for 32000Hz
43859Hz for 44100Hz
The results for 48KHz and 32KHz has changed comparing to the previous
release, but the one for 44100Hz has a bit lose even though it should
be the best we can get based on the current clock rate. If user want
to playback a perfect 44100Hz, they need to change the parent clock
rate.
Acked-by: Wang Shengjiu <b02247@freescale.com>
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit f12e2ea9c6c5557adb3bbe26c51021978f2c8d99)
|
|
Shawn's patch -- ARM: imx: shared gate support for i.MX clk_gate2 clocko
has fixed the problem of clock conflicts due to sharing a same gate.
So from now on, we can no longer need to take care the shared gate clock
for each audio clock route. Thus this patch separates them by using the
new clock registering helper function. And meanwhile, we set a proper
rate for each route so as to support each module.
For S/PDIF, we use 98304000Hz so that the current driver would perfectly
get 32000Hz and 48000Hz sample rate playback support, even though we
can only get 43885Hz for 44100Hz sample rate in this way -- If user
want to playback 44100Hz group sample rates, they need to change the
parent rate.
Acked-by: Wang Shengjiu <b02247@freescale.com>
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit b50eb55b1eb35e8e568ab777dc794370f20464eb)
|
|
It's quite common on i.MX that one gate bit controls the gating of
multiple clocks, i.e. this is a shared gate. The patch adds the
function imx_clk_gate2_shared() for such case. The clocks controlled
by the same gate bits should call this function with a pointer to a
single share count variable, so that the gate bits will only be
operated on the first enabling and the last disabling of these shared
gate clocks.
Thanks to Gerhard Sittig <gsi@denx.de> for this idea.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit 9c830d95d0e6d7522a31cd14f9641c37700d4e85)
|
|
The imx specific clk_gate2 always has a valid lock with the clock. So
the validation on gate->lock is not really needed. Remove it.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit 430468ff84e8d8a8d53e3ca974721edd85042d47)
|
|
The imx clk-gate2 driver implements an i.MX specific gate clock, which
has two bits controlling the gate states. While this is a completely
separate gate driver from the common clk-gate one, it reuses the common
clk_gate structure. Such reusing makes the extending of clk_gate2
clumsy. Let's define struct clk_gate2 on our own to make the driver
independent of the common clk-gate one, and ease the clk_gate2 extending
at a later time.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit b0293bafbb378183279eb74442506194db7b2c89)
|
|
this patch can fix NULL pointer issue in GPU kernel driver with the following log
[<7f240438>] (gckEVENT_AddList+0x0/0x810 [galcore]) from [<7f239ebc>] (gckCOMMAND_Commit+0xf28/0x118c [galcore])
[<7f238f94>] (gckCOMMAND_Commit+0x0/0x118c [galcore]) from [<7f2362dc>] (gckKERNEL_Dispatch+0x120c/0x24e4 [galcore])
[<7f2350d0>] (gckKERNEL_Dispatch+0x0/0x24e4 [galcore]) from [<7f222280>] (drv_ioctl+0x390/0x540 [galcore])
[<7f221ef0>] (drv_ioctl+0x0/0x540 [galcore]) from [<800facd0>] (vfs_ioctl+0x30/0x44)
The false code is at 0x217bc where the 0-pointer happens (r3 = 0)
gcuVIDMEM_NODE_PTR node = (gcuVIDMEM_NODE_PTR)(gcmUINT64_TO_PTR(Record->info.u.FreeVideoMemory.node));
217b8: e5953028 ldr r3, [r5, #40] ; 0x28
if (node->VidMem.memory->object.type == gcvOBJ_VIDMEM)
217bc: e5932000 ldr r2, [r3]
217c0: e5922000 ldr r2, [r2]
217c4: e152000a cmp r2, sl
{
gcmkVERIFY_OK(gckKERNEL_RemoveProcessDB(Event->kernel,
Date: Apr 23, 2014
Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
(cherry picked from commit 13859c2276997dbfd1b45aff1ff598e2ee1d4f74)
|
|
The current return value is not right beacause there may have irq
interrupt that is processed. So correct the return value.
Signed-off-by: Fugang Duan <B38611@freescale.com>
|
|
Enable g_ncm as module for use g_ncm gadget driver.
Signed-off-by: Li Jun <b47624@freescale.com>
|
|
Add imx6sx-17x17-arm2-mlb.dtb in devicetree makefile list
Signed-off-by: Luwei Zhou <b45643@freescale.com>
(cherry picked from commit 0ac36559f00dace422fbc766de3e06cf2a343fdf)
|
|
Enable usb charger for imx6sx-sdb board
Signed-off-by: Peter Chen <peter.chen@freescale.com>
|
|
Create standalone dts for a9 when m4 is running, since there
are some conflictions in the following modules
* i2c3
* flexcan1&2
* uart2
Signed-off-by: Richard Zhu <r65037@freescale.com>
|
|
The issue can be reproduced after overninght test, reproduced
step: nfs mount rootfs, don't do any other ethernet test cases.
If the issue generates, there has log:
fec 2188000.ethernet eth0: MDIO read timeout
The origin interrupt handler may ignore to process mdio interrupt
in current irq handler until the next irq action. If the next irq
comes in time that is less than the mdio wait time, the next irq
handler wake up a single thread waiting on this completion, MDIO
read function can get the single before time expired. Otherwise,
MDIO read generate timeout issue. The patch just to fix the issue.
Signed-off-by: Fugang Duan <B38611@freescale.com>
|
|
It'd better to tell people what's the current rate from the clock
selecting function against the required sample rate.
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit 468755326e5ab405e1567480d4c09c3387ce028a)
|
|
The sysclk, which could be connected to IPG clock, is one of the eight
clocks on the inner clock mux of SPDIF. Previously we forbade the usage
of this clock due to imperfect clock selecting function.
This patch adds the sysclk_df divisor so as to complete sysclk function.
[ In order to potect those clocks from other modules and the situation
when SPDIF root clock is shared with other module (ASRC on imx6sx for
example) that demands us to fix the clock and not to change its rate,
starting from now on, we no longer use clk_round() and clk_set_rate(). ]
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit 3092f062768d7c4312c54c7ec2c5f9acfbbf7e69)
|
|
Even if we assign regmap to manage the coreclk control, we still need
to open the clock if we are going to run the driver because DMA access
would not be detected by regmap.
So this patch adds clock control for coreclk.
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit 7e9a6bb3eb4df21f96a6f3efd1f3a334a910b2ac)
|
|
This patch exports symbol of otg_statemachine for kernel module
to use it.
Signed-off-by: Li Jun <b47624@freescale.com>
|
|
fixed 3D context switch issue, the original comments from Vivante
Set command->using2D correctly when gcdCMD_NO_2D_CONTEXT = 1
this patch is to fix Android mess UI issue on GC400T
Date: Apr 21, 2014
Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
(cherry picked from commit 31ced071862c9e28d10c8680919637b716296786)
|
|
gcvVERSION_STRING is not consistent with gcvVERSION_BUILD. Vivante
will provide a more flexible way in future release.
Date: Apr 18, 2014
Signed-off-by: Zhenyong Chen <b07273@freescale.com>
Acked-by: Jason Liu
(cherry picked from commit e3a5ec334a239599f7ea2ab98ec5fc8c576b614f)
|
|
The src_maxburst and dst_maxburst means the watermark level for
p2p, no need to be scaled.
Signed-off-by: Shengjiu Wang <b02247@freescale.com>
|
|
-When allocation failed, the node will be null.
node->Virtual.type access will cause kernel panic
when forceContiguous is enabled.
Date: Apr 21,2014
Signed-off-by: Loren Huang <b02279@freescale.com>
Acked-by: Shawn Guo
(cherry picked from commit 9b5b98b69201135fef0500907ecb3320b128ef0f)
|
|
Virtual command buffer is forcibly enabled and causes gpu hang on i.MX6SLX
- Android GPU hang
- X11 GPU hang when run es2gears
- Dfb 2D test case df_dok may cause gpu hang.
The safe fix is to disable virtual command buffer temporarily
Date: Apr 17, 2014
Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
(cherry picked from commit f0aaa7521e0e58b4a7c9f104271343ab277fed56)
(cherry picked from commit a5730ef091adfc28b8fd3866bf9a771bff09d8ea)
|
|
It should use STC_SYSCLK_DIV_OFFSET. Thus fix it.
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
(cherry picked from commit 6ae6698276ca36f37afc2ad38054092021519ad4)
|
|
We have a 2s timer once the wakeup occurs, if we unload module within
2s before wakeup occurs, the timer is still active, so we need
to delete the timer before the destroy of struct ci_hdrc, otherwise,
the below oops will occur.
ci_hdrc ci_hdrc.1: remove, state 1
usb usb1: USB disconnect, device number 1
usb 1-1: USB disconnect, device number 2
ci_hdrc ci_hdrc.1: USB bus 1 deregistered
ci_hdrc ci_hdrc.1: ci_otg_thread quits
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = a9474000
[00000000] *pgd=a84b1831, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
Modules linked in: ci_hdrc_imx(-) usbmisc_imx ci_hdrc ehci_hcd udc_core phy_mxs_usb evbug [last unloaded: configfs]
CPU: 0 PID: 11542 Comm: modprobe Not tainted 3.10.17-01265-ga8a6771-dirty #561
task: a81243c0 ti: a94b4000 task.ti: a94b4000
PC is at 0x0
LR is at call_timer_fn.isra.29+0x24/0x84
pc : [<00000000>] lr : [<8003189c>] psr: 200b0113
sp : a94b5d68 ip : 00000000 fp : 00000000
r10: a94b5d88 r9 : 00000000 r8 : 00200200
r7 : 00000000 r6 : 80c320c0 r5 : 00000100 r4 : a94b4000
r3 : a94b5d68 r2 : a94b5d80 r1 : 00000000 r0 : 00000000
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c53c7d Table: a947404a DAC: 00000015
Process modprobe (pid: 11542, stack limit = 0xa94b4238)
Stack: (0xa94b5d68 to 0xa94b6000)
5d60: 000797ae 00015220 80c2c620 80cc1ac0 00000000 80c320c0
5d80: 80cc22d4 80031ab4 a94b5d88 a94b5d88 00000000 00000101 80c32084 a94b4000
5da0: 00000100 80cc1880 00000000 80c32080 00000001 8002c4b4 000000c3 a8009240
5dc0: 00000004 0000000a 000797af 00404100 018c8300 600b0193 00000057 00000000
5de0: c0802100 8000e2c4 a94b4000 00000000 018c8300 8002c624 a94b4000 8002c898
5e00: 80c2cef0 8000ea04 c080210c 80c38904 a94b5e30 80008538 80115b7c 80115b8c
5e20: a00b0013 ffffffff a94b5e64 8000dd40 80c45808 00000000 00000001 00000000
5e40: a83f8900 00000000 a94b5e98 00000081 8000e2c4 a94b4000 00000000 018c8300
5e60: 00000001 a94b5e78 80115b7c 80115b8c a00b0013 ffffffff 00000000 00000000
5e80: a83f83c0 a83f83c0 a83f83c0 80b349b4 00000000 801140fc a83f83c0 a83f8900
5ea0: 80c56ae8 a83f83c0 a80c4610 80117454 00000000 80c56aa0 a88bc018 8030b9ac
5ec0: ffffffff a88bc010 a80c4610 8030437c a88bc000 a80c4600 a80c4610 80308510
5ee0: 7f7d21c0 a88bc000 a80c4600 803088b4 00000000 7f7c0500 a83c4c10 7f7d21e0
5f00: a80c4610 7f7d3250 a80c4644 8030827c 80308264 80306b70 7f7d3250 a80c4610
5f20: 7f7d3250 80307360 7f7d3290 7f7d3250 80c56710 803069a0 7f7d3290 00000000
5f40: a94b4000 800679d0 00000020 685f6963 5f637264 00786d69 a81243c0 800495b4
5f60: 80c2ceac 00000000 018c8300 80049578 018c8300 8003f614 8000e2c4 000f000f
5f80: a89b7840 004b4000 7f7d3290 00000800 a94b5f94 00000000 018c8300 018c8334
5fa0: 018c8334 8000e140 018c8300 018c8334 018c8334 00000800 7ee8aa50 0002e6b0
5fc0: 018c8300 018c8334 018c8334 00000081 00000001 7ee8be0c 7ee8be04 018c8300
5fe0: 76ebcf40 7ee8aa2c 00019268 76ebcf4c 60070010 018c8334 abf58811 abf58c11
[<8003189c>] (call_timer_fn.isra.29+0x24/0x84) from [<80031ab4>] (run_timer_softirq+0x1b8/0x1cc)
[<80031ab4>] (run_timer_softirq+0x1b8/0x1cc) from [<8002c4b4>] (__do_softirq+0xd8/0x1b8)
[<8002c4b4>] (__do_softirq+0xd8/0x1b8) from [<8002c624>] (do_softirq+0x4c/0x58)
[<8002c624>] (do_softirq+0x4c/0x58) from [<8002c898>] (irq_exit+0x90/0xc8)
[<8002c898>] (irq_exit+0x90/0xc8) from [<8000ea04>] (handle_IRQ+0x3c/0x90)
[<8000ea04>] (handle_IRQ+0x3c/0x90) from [<80008538>] (gic_handle_irq+0x28/0x5c)
[<80008538>] (gic_handle_irq+0x28/0x5c) from [<8000dd40>] (__irq_svc+0x40/0x70)
Exception stack(0xa94b5e30 to 0xa94b5e78)
5e20: 80c45808 00000000 00000001 00000000
5e40: a83f8900 00000000 a94b5e98 00000081 8000e2c4 a94b4000 00000000 018c8300
5e60: 00000001 a94b5e78 80115b7c 80115b8c a00b0013 ffffffff
[<8000dd40>] (__irq_svc+0x40/0x70) from [<80115b8c>] (sysfs_addrm_finish+0x24/0xd4)
[<80115b8c>] (sysfs_addrm_finish+0x24/0xd4) from [<801140fc>] (sysfs_hash_and_remove+0x4c/0x88)
[<801140fc>] (sysfs_hash_and_remove+0x4c/0x88) from [<80117454>] (sysfs_unmerge_group+0x40/0x7c)
[<80117454>] (sysfs_unmerge_group+0x40/0x7c) from [<8030b9ac>] (dpm_sysfs_remove+0x20/0x3c)
[<8030b9ac>] (dpm_sysfs_remove+0x20/0x3c) from [<8030437c>] (device_del+0x34/0x178)
[<8030437c>] (device_del+0x34/0x178) from [<80308510>] (platform_device_del+0x14/0xa8)
[<80308510>] (platform_device_del+0x14/0xa8) from [<803088b4>] (platform_device_unregister+0xc/0x18)
[<803088b4>] (platform_device_unregister+0xc/0x18) from [<7f7c0500>] (ci_hdrc_remove_device+0xc/0x20 [ci_hdrc])
[<7f7c0500>] (ci_hdrc_remove_device+0xc/0x20 [ci_hdrc]) from [<7f7d21e0>] (ci_hdrc_imx_remove+0x20/0xc8 [ci_hdrc_imx])
[<7f7d21e0>] (ci_hdrc_imx_remove+0x20/0xc8 [ci_hdrc_imx]) from [<8030827c>] (platform_drv_remove+0x18/0x1c)
[<8030827c>] (platform_drv_remove+0x18/0x1c) from [<80306b70>] (__device_release_driver+0x70/0xcc)
[<80306b70>] (__device_release_driver+0x70/0xcc) from [<80307360>] (driver_detach+0xac/0xb0)
[<80307360>] (driver_detach+0xac/0xb0) from [<803069a0>] (bus_remove_driver+0x7c/0xc0)
[<803069a0>] (bus_remove_driver+0x7c/0xc0) from [<800679d0>] (SyS_delete_module+0x144/0x1f8)
[<800679d0>] (SyS_delete_module+0x144/0x1f8) from [<8000e140>] (ret_fast_syscall+0x0/0x30)
Code: bad PC value
Signed-off-by: Peter Chen <peter.chen@freescale.com>
|
|
Compared to i.MX6 Quad/Dual the CCM_CCGR1 register in the i.MX6 Solo/DualLite
replaces the ecspi5 clock with the i2c4 clock.
Handle this difference using cpu_is_imx6dl().
Signed-off-by: Iain Paton <ipaton0@gmail.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
|
commit 224aa3ed45c8735ae02bb2ecca002409fa6aa772 upstream.
Vybrids PIT register is monitonic decreasing. However, sched_clock
reading needs to be monitonic increasing. Use bitwise not to get
the complement of the clock register. This fixes the clock going
backward. Also, the clock now starts at 0 since we load the
register with the maximum value at start.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: daniel.lezcano@linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux@arm.linux.org.uk
Link: http://lkml.kernel.org/r/d25af915993aec1b486be653eb86f748ddef54fe.1394057313.git.stefan@agner.ch
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
|
"FSL_stressPTP" tool is supposed to test the capability characteristics of
a ptp stack porting. The stresstest shall measure the overall load of the
stack under test by sending delay request and signalling messages.The higher
the overall load on the stack is, the higher your packet loss will be.
The patch fix the timestamp error in high overall load stress test like:
./FSL_stressPTP -u -b 10.192.242.10 -d 10.192.242.6 -e eth0 -m 00:01:02:04:04:19
-i 100 -t 10 -f -6 -s -6 -c 10
And enet interrupt coalescing feature introduce ptp packet latency, which may
cause that the timestamp don't store the related timestamp buffer when stack
use ioctl interface to access the message. So add some 4ms delay after getting
timestamp fail to let the next looking up success. Suggest to disable interrupt
coalescing feature by ethtool when run 1588 cases.
Signed-off-by: Fugang Duan <B38611@freescale.com>
(cherry picked from commit 11107938cc5a4a7cb4e5fc5e00d248183ed43d93)
|
|
1588 convergence process (setup time about 15s) is not ideal:
Applied a time jump on the reference master which causes both slaves
to apply a time jump as well and then synchronize back to the nanoseconds.
Optimize the 1588 adjust algorithm to get better convergent action.
Signed-off-by: Fugang Duan <B38611@freescale.com>
(cherry picked from commit 46a727f7ef469ae7c77c3458efd8a0de2396c360)
|
|
Since we changed asrc_p2p's DT bindings to support record case, we should
update it in imx6sx platform as well.
Acked-by: Wang Shengjiu <b02247@freescale.com>
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit 94b2a00e1a6f17669975dcaa9fdd02fa695b7600)
|
|
There's a possiblity that ASRC P2P would error out during its probe() due to
missing some DT bindings for example. If that happens, this asrc_p2p would
be a NULL pointer and accessing it would cause Kernel Panic.
Thus this patch adds an error out here to keep it safe.
Acked-by: Wang Shengjiu <b02247@freescale.com>
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
(cherry picked from commit cc678a578ef873127b8237680282f1cd55fe1873)
|
|
The following two commits for backlight core driver introduce
an usecount for each backlight device and on/off usage info of
each framebuffer associated with it so that we may enable/disable
a backlight device when necessary.
commit dcb7e61054b959dc4d601a96cce5cc85ad1568ef
commit b48b097319587422195adc3f8b2b3b0c067943cc
The problem is that some framebuffer drivers would enable their
display controllers in probe() and some backlight device drivers
would enable their backlights in probe() so that the backlight
device usecounts and the on/off usage info of framebuffers are
out of counting at the probing stage. This causes a backlight
cannot be disabled by blanking the relevant framebuffer(s) before
any fb unblanking operation, though it's quite reasonable for the
userland to unblank the framebuffer(s) before using it. In order
to avoid the potential unnecessary lighten backlight left behind
for the mxsfb driver, this patch unblanks framebuffer explicitly
in probe() since the LCDIF display controller is actually enabled
there.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
(cherry picked from commit 61667ae1430849af17e2431bbe9290295e0ec492)
|
|
Commits 11d4616bd07f ("futex: revert back to the explicit waiter
counting code") and 69cd9eba3886 ("futex: avoid race between requeue and
wake") changed some of the finer details of how we think about futexes.
One was a late fix and the other a consequence of overlooking the whole
requeuing logic.
The first change caused our documentation to be incorrect, and the
second made us aware that we need to explicitly add more details to it.
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Jan Stancek reported:
"pthread_cond_broadcast/4-1.c testcase from openposix testsuite (LTP)
occasionally fails, because some threads fail to wake up.
Testcase creates 5 threads, which are all waiting on same condition.
Main thread then calls pthread_cond_broadcast() without holding mutex,
which calls:
futex(uaddr1, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, uaddr2, ..)
This immediately wakes up single thread A, which unlocks mutex and
tries to wake up another thread:
futex(uaddr2, FUTEX_WAKE_PRIVATE, 1)
If thread A manages to call futex_wake() before any waiters are
requeued for uaddr2, no other thread is woken up"
The ordering constraints for the hash bucket waiter counting are that
the waiter counts have to be incremented _before_ getting the spinlock
(because the spinlock acts as part of the memory barrier), but the
"requeue" operation didn't honor those rules, and nobody had even
thought about that case.
This fairly simple patch just increments the waiter count for the target
hash bucket (hb2) when requeing a futex before taking the locks. It
then decrements them again after releasing the lock - the code that
actually moves the futex(es) between hash buckets will do the additional
required waiter count housekeeping.
Reported-and-tested-by: Jan Stancek <jstancek@redhat.com>
Acked-by: Davidlohr Bueso <davidlohr@hp.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org # 3.14
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Srikar Dronamraju reports that commit b0c29f79ecea ("futexes: Avoid
taking the hb->lock if there's nothing to wake up") causes java threads
getting stuck on futexes when runing specjbb on a power7 numa box.
The cause appears to be that the powerpc spinlocks aren't using the same
ticket lock model that we use on x86 (and other) architectures, which in
turn result in the "spin_is_locked()" test in hb_waiters_pending()
occasionally reporting an unlocked spinlock even when there are pending
waiters.
So this reinstates Davidlohr Bueso's original explicit waiter counting
code, which I had convinced Davidlohr to drop in favor of figuring out
the pending waiters by just using the existing state of the spinlock and
the wait queue.
Reported-and-tested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Original-code-by: Davidlohr Bueso <davidlohr@hp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
If an architecture has futex_atomic_cmpxchg_inatomic() implemented and there
is no runtime check necessary, allow to skip the test within futex_init().
This allows to get rid of some code which would always give the same result,
and also allows the compiler to optimize a couple of if statements away.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Finn Thain <fthain@telegraphics.com.au>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Link: http://lkml.kernel.org/r/20140302120947.GA3641@osiris
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
"futexes: Increase hash table size for better performance"
introduces a new alloc_large_system_hash() call.
alloc_large_system_hash() however may allocate less memory than
requested, e.g. limited by MAX_ORDER.
Hence pass a pointer to alloc_large_system_hash() which will
contain the hash shift when the function returns. Afterwards
correctly set futex_hashsize.
Fixes a crash on s390 where the requested allocation size was
4MB but only 1MB was allocated.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Waiman Long <Waiman.Long@hp.com>
Cc: Jason Low <jason.low2@hp.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Link: http://lkml.kernel.org/r/20140116135450.GA4345@osiris
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
In futex_wake() there is clearly no point in taking the hb->lock
if we know beforehand that there are no tasks to be woken. While
the hash bucket's plist head is a cheap way of knowing this, we
cannot rely 100% on it as there is a racy window between the
futex_wait call and when the task is actually added to the
plist. To this end, we couple it with the spinlock check as
tasks trying to enter the critical region are most likely
potential waiters that will be added to the plist, thus
preventing tasks sleeping forever if wakers don't acknowledge
all possible waiters.
Furthermore, the futex ordering guarantees are preserved,
ensuring that waiters either observe the changed user space
value before blocking or is woken by a concurrent waker. For
wakers, this is done by relying on the barriers in
get_futex_key_refs() -- for archs that do not have implicit mb
in atomic_inc(), we explicitly add them through a new
futex_get_mm function. For waiters we rely on the fact that
spin_lock calls already update the head counter, so spinners
are visible even if the lock hasn't been acquired yet.
For more details please refer to the updated comments in the
code and related discussion:
https://lkml.org/lkml/2013/11/26/556
Special thanks to tglx for careful review and feedback.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Scott Norton <scott.norton@hp.com>
Cc: Tom Vaden <tom.vaden@hp.com>
Cc: Aswin Chandramouleeswaran <aswin@hp.com>
Cc: Waiman Long <Waiman.Long@hp.com>
Cc: Jason Low <jason.low2@hp.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1389569486-25487-5-git-send-email-davidlohr@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
That's essential, if you want to hack on futexes.
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Reviewed-by: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Scott Norton <scott.norton@hp.com>
Cc: Tom Vaden <tom.vaden@hp.com>
Cc: Aswin Chandramouleeswaran <aswin@hp.com>
Cc: Waiman Long <Waiman.Long@hp.com>
Cc: Jason Low <jason.low2@hp.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1389569486-25487-4-git-send-email-davidlohr@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Currently, the futex global hash table suffers from its fixed,
smallish (for today's standards) size of 256 entries, as well as
its lack of NUMA awareness. Large systems, using many futexes,
can be prone to high amounts of collisions; where these futexes
hash to the same bucket and lead to extra contention on the same
hb->lock. Furthermore, cacheline bouncing is a reality when we
have multiple hb->locks residing on the same cacheline and
different futexes hash to adjacent buckets.
This patch keeps the current static size of 16 entries for small
systems, or otherwise, 256 * ncpus (or larger as we need to
round the number to a power of 2). Note that this number of CPUs
accounts for all CPUs that can ever be available in the system,
taking into consideration things like hotpluging. While we do
impose extra overhead at bootup by making the hash table larger,
this is a one time thing, and does not shadow the benefits of
this patch.
Furthermore, as suggested by tglx, by cache aligning the hash
buckets we can avoid access across cacheline boundaries and also
avoid massive cache line bouncing if multiple cpus are hammering
away at different hash buckets which happen to reside in the
same cache line.
Also, similar to other core kernel components (pid, dcache,
tcp), by using alloc_large_system_hash() we benefit from its
NUMA awareness and thus the table is distributed among the nodes
instead of in a single one.
For a custom microbenchmark that pounds on the uaddr hashing --
making the wait path fail at futex_wait_setup() returning
-EWOULDBLOCK for large amounts of futexes, we can see the
following benefits on a 80-core, 8-socket 1Tb server:
+---------+--------------------+------------------------+-----------------------+-------------------------------+
| threads | baseline (ops/sec) | aligned-only (ops/sec) | large table (ops/sec) | large table+aligned (ops/sec) |
+---------+--------------------+------------------------+-----------------------+-------------------------------+
| 512 | 32426 | 50531 (+55.8%) | 255274 (+687.2%) | 292553 (+802.2%) |
| 256 | 65360 | 99588 (+52.3%) | 443563 (+578.6%) | 508088 (+677.3%) |
| 128 | 125635 | 200075 (+59.2%) | 742613 (+491.1%) | 835452 (+564.9%) |
| 80 | 193559 | 323425 (+67.1%) | 1028147 (+431.1%) | 1130304 (+483.9%) |
| 64 | 247667 | 443740 (+79.1%) | 997300 (+302.6%) | 1145494 (+362.5%) |
| 32 | 628412 | 721401 (+14.7%) | 965996 (+53.7%) | 1122115 (+78.5%) |
+---------+--------------------+------------------------+-----------------------+-------------------------------+
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Reviewed-by: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-and-tested-by: Jason Low <jason.low2@hp.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Scott Norton <scott.norton@hp.com>
Cc: Tom Vaden <tom.vaden@hp.com>
Cc: Aswin Chandramouleeswaran <aswin@hp.com>
Link: http://lkml.kernel.org/r/1389569486-25487-3-git-send-email-davidlohr@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Avoid waking up every thread sleeping in a futex_wait call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Signed-off-by: Colin Cross <ccross@android.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: arve@android.com
Cc: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Link: http://lkml.kernel.org/r/1367458508-9133-8-git-send-email-ccross@android.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
- Remove unnecessary head variables.
- Delete unused parameter in queue_unlock().
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Reviewed-by: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jason Low <jason.low2@hp.com>
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Scott Norton <scott.norton@hp.com>
Cc: Tom Vaden <tom.vaden@hp.com>
Cc: Aswin Chandramouleeswaran <aswin@hp.com>
Cc: Waiman Long <Waiman.Long@hp.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1389569486-25487-2-git-send-email-davidlohr@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
