Age | Commit message (Collapse) | Author |
|
This patch adds support to ASC (asynchronous serial controller)
driver, which is basically a standard serial driver. This IP is common
across all the ST parts for settop box platforms.
ASC is embedded in ST COMMS IP block. It supports Rx & Tx functionality.
It support all industry standard baud rates.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
CC: Stephen Gallimore <stephen.gallimore@st.com>
CC: Stuart Menefy <stuart.menefy@st.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The driver fails to build on x86 because writel_relaxed isn't available
there. That function exists on arm, arm64, avr32, hexagon, mips and sh,
but adding all these is overkill so stick to arm only.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add the missing iounmap() before return from msm_request_port()
in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Ivan T. Ivanov <iivanov@mm-sol.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
No idea why we have redundant testing for ifdef CONFIG_SERIAL_BFIN_MODULE,
check it once is enough.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use the DMI interface rather than manually matching DMI strings.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Michael Brunner <mibru@gmx.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Some serial ports will not use the standard base baud rate. Report
this after initialization so it might be discovered and used for early
console configuration.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If earlyprintk is enabled and current UART is console port the platform
code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
avoid resuming of already active device, but now, driver initialization
will be performed in the wrong way:
pm_runtime_enable(&pdev->dev);
<-- PM runtime alowed (device state RPM_ACTIVE)
if (omap_up_info->autosuspend_timeout == 0)
omap_up_info->autosuspend_timeout = -1;
device_init_wakeup(up->dev, true);
pm_runtime_use_autosuspend(&pdev->dev);
<-- update_autosuspend() will be called and it will disable device
(device state RPM_SUSPENDED)
pm_runtime_set_autosuspend_delay(&pdev->dev,
omap_up_info->autosuspend_timeout);
<-- update_autosuspend() will be called which will re-enable device
(device state RPM_ACTIVE), because autosuspend_timeout < 0
pm_runtime_irq_safe(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
<-- will do nothing
Such behavior isn't expected by OMAP serial drivers and causes
unpredictable calls of serial_omap_runtime_suspend() and
serial_omap_runtime_resume().
Hence, fix it by allowing PM runtime only after all its parameters are
configured.
CC: Tony Lindgren <tony@atomide.com>
CC: Rajendra Nayak <rnayak@ti.com>
CC: Felipe Balbi <balbi@ti.com>
CC: Kevin Hilman <khilman@linaro.org>
Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Function lpuart_setup_watermark() clears some bits in register UARTCR2
before writing FIFO configuration registers as required by hardware.
But it should restore UARTCR2 after that. Otherwise, we end up changing
UARTCR2 register when setting up watermark, and that is not really
desirable. At least, when low-level debug and earlyprint is enabled,
serial console is broken due to it.
Fix the problem by restoring UARTCR2 register at the end of function
lpuart_setup_watermark().
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Ensure the Interrupt handling routine return IRQ_HANDLED vs
IRQ_NONE.
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Alexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Otherwise serial driver would crash accessing platform_data that was
not initialized in functions like:
serial_omap_pm(...)
...
if (!state && pdata->enable_wakeup)
^^^^^^^
...
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Alexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The revision register is a 32 bit register. The serial_in() function reads
only the lower 16 bits of the register. This leads to an incorrect computation
of the Module revision.
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
[oleksandr.savchenko@ti.com: add some whitespaces]
Signed-off-by: Alexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Current logic results in interrupt storm since the fifo
is constantly below the threshold level. Change the logic
to fill all the available spaces in the fifo as long as
we have data to minimize the possibilty of underflow and
elimiate excessive interrupts.
Signed-off-by: Dmitry Fink <finik@ti.com>
Signed-off-by: Alexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
wer has TX wakeup bit available enable the same
by populating the necessary tx wakeup flag for the
applicable module ip blocks and use the same
while configuaring wer reg.
Also wer is not context restored, restore wer when
context is lost.
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kevin Hilman <kevin.hilman@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(for drivers/tty changes)
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The recent regression about NetMos 9835 Multi-I/O boards indicates
that comment pointing to the parport_serial driver could be helpful.
Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This patch adds support for MAX14830 (advanced quad universal asynchronous
receiver-transmitter) into max310x driver.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This patch adds support for MAX3109 (advanced dual universal asynchronous
receiver-transmitter) into max310x driver.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This patch rework max310x driver.
Major changes have been made:
- Prepare driver to support ICs with more than one UART.
- Prepare driver to support work with I2C-bus.
The patch changes almost every function and can not be divided into parts.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
We only enable the DMA support when the following are meet:
[1] The uart port supports the hardware flow control(CTS/RTS).
(Some uart port does not support the CTS/RTS.)
[2] The application enables the CTS/RTS.
[3] The Soc is imx6q.
For the sdma's firmware limit, we do not support the DMA except
the imx6q platform.
[4] The uart is not used as a console.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
It was not possible to set custom-baudrates like 62500.
Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
We will add the DMA support for the imx uart. For the firmware's limit,
only the imx6 serial chips (including the imx6q, imx6dl, imx6sl) can
support the DMA.
This patch adds the necessary macro and helper to distinguish the
imx6q uart from the other imx uart. Other chips can use the "fsl,imx6q-uart"
to enable the DMA support.
This patch also replaces the check "is_imx21_uart()" with "!is_imx1_uart()".
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The uart_console() check makes the clocks(clk_per and clk_ipg) opened
even when we close the console uart.
This patch enable/disable the clocks in imx_console_write(),
so we can keep the clocks closed when the console uart is closed.
Also remove the clock enable/disable oprations in the probe, we do not
need them any more.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Barry Song <baohua.song@csr.com>
Acked-by: Tony Prisk <linux@prisktech.co.nz>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Implement the dtr_rts() hvc console callback to improve control when to
disconnect the IUCV connection. Previously, the IUCV connection was
disconnected during the notifier_del() callback, i.e., when the last file
descriptor to the hvc terminal device was closed.
Recent changes in login programs caused undesired disconnects during the
login phase. To prevent these kind of disconnects, implement the dtr_rts
callback to implicitly handle the HUPCL termios control via the hvc_console
driver.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Introduce a new callback to explicitly handle the HUPCL termios control flag.
This prepares for a follow-up commit for the hvc_iucv device driver to
improve handling when to drop an established network connection.
The callback naming is based on the recently added tty_port interface to
facilitate a potential refactoring of the hvc_console to use tty_port
functions.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13)
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Specifically:
n_gsm.c:810: ERROR: space required before the open parenthesis '('
n_gsm.c:830: WARNING: line over 80 characters
n_gsm.c:971: ERROR: trailing whitespace
n_gsm.c:984: ERROR: code indent should use tabs where possible
n_gsm.c:984: WARNING: please, no space before tabs
n_gsm.c:984: WARNING: please, no spaces at the start of a line
n_gsm.c:1141: WARNING: space prohibited before semicolon
n_gsm.c:1743: ERROR: space required before the open brace '{'
n_gsm.c:1744: WARNING: line over 80 characters
n_gsm.c:1745: ERROR: code indent should use tabs where possible
n_gsm.c:1746: ERROR: code indent should use tabs where possible
n_gsm.c:2908: WARNING: line over 80 characters
n_gsm.c:2912: ERROR: trailing whitespace
Signed-off-by: Aldo Iljazi <neonsync1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commits 6a1c0680cf3ba94356ecd58833e1540c93472a57 and
9356b535fcb71db494fc434acceb79f56d15bda2, respectively
'tty: Convert termios_mutex to termios_rwsem' and
'n_tty: Access termios values safely'
introduced a circular lock dependency with console_lock and
termios_rwsem.
The lockdep report [1] shows that n_tty_write() will attempt
to claim console_lock while holding the termios_rwsem, whereas
tty_do_resize() may already hold the console_lock while
claiming the termios_rwsem.
Since n_tty_write() and tty_do_resize() do not contend
over the same data -- the tty->winsize structure -- correct
the lock dependency by introducing a new lock which
specifically serializes access to tty->winsize only.
[1] Lockdep report
======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
-------------------------------------------------------
modprobe/277 is trying to acquire lock:
(&tty->termios_rwsem){++++..}, at: [<ffffffff81452656>] tty_do_resize+0x36/0xe0
but task is already holding lock:
((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 ((fb_notifier_list).rwsem){.+.+.+}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b797>] down_read+0x47/0x5c
[<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #1 (console_lock){+.+.+.}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff810430a7>] console_lock+0x77/0x80
[<ffffffff8146b2a1>] con_flush_chars+0x31/0x50
[<ffffffff8145780c>] n_tty_write+0x1ec/0x4d0
[<ffffffff814541b9>] tty_write+0x159/0x2e0
[<ffffffff814543f5>] redirected_tty_write+0xb5/0xc0
[<ffffffff811ab9d5>] vfs_write+0xc5/0x1f0
[<ffffffff811abec5>] SyS_write+0x55/0xa0
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #0 (&tty->termios_rwsem){++++..}:
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Chain exists of:
&tty->termios_rwsem --> console_lock --> (fb_notifier_list).rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(&tty->termios_rwsem);
*** DEADLOCK ***
7 locks held by modprobe/277:
#0: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b5b>] __driver_attach+0x5b/0xb0
#1: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b69>] __driver_attach+0x69/0xb0
#2: (drm_global_mutex){+.+.+.}, at: [<ffffffffa008a6dd>] drm_get_pci_dev+0xbd/0x2a0 [drm]
#3: (registration_lock){+.+.+.}, at: [<ffffffff813d93f5>] register_framebuffer+0x25/0x320
#4: (&fb_info->lock){+.+.+.}, at: [<ffffffff813d8116>] lock_fb_info+0x26/0x60
#5: (console_lock){+.+.+.}, at: [<ffffffff813d95a4>] register_framebuffer+0x1d4/0x320
#6: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
stack backtrace:
CPU: 0 PID: 277 Comm: modprobe Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012
ffffffff8213e5e0 ffff8802aa2fb298 ffffffff81755f19 ffff8802aa2fb2e8
ffffffff8174f506 ffff8802aa2fa000 ffff8802aa2fb378 ffff8802aa2ea8e8
ffff8802aa2ea910 ffff8802aa2ea8e8 0000000000000006 0000000000000007
Call Trace:
[<ffffffff81755f19>] dump_stack+0x19/0x1b
[<ffffffff8174f506>] print_circular_bug+0x1fb/0x20c
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b775e>] ? mark_held_locks+0xae/0x120
[<ffffffff810b78d5>] ? trace_hardirqs_on_caller+0x105/0x1d0
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffff8173cbcb>] ? kmemleak_alloc+0x5b/0xc0
[<ffffffff81198874>] ? kmem_cache_alloc_trace+0x104/0x290
[<ffffffffa01035e1>] ? drm_fb_helper_single_add_all_connectors+0x81/0xf0 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff8175f162>] ? _raw_spin_unlock_irqrestore+0x42/0x80
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff81497b00>] ? driver_probe_device+0x3a0/0x3a0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff81399a50>] ? ddebug_proc_open+0xb0/0xb0
[<ffffffff813855ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Acquiring the write_wait queue spin lock now accounts for the largest
slice of cpu time on the tty write path. Two factors contribute to
this situation; a overly-pessimistic line discipline write loop which
_always_ sets up a wait loop even if i/o will immediately succeed, and
on ptys, a wakeup storm from reads and writes.
Writer wakeup does not need to be performed by the pty driver.
Firstly, since the actual i/o is performed within the write, the
line discipline write loop will continue while space remains in
the flip buffers. Secondly, when space becomes avail in the
line discipline receive buffer (and thus also in the flip buffers),
the pty unthrottle re-wakes the writer (non-flow-controlled line
disciplines unconditionally unthrottle the driver when data is
received). Thus, existing in-kernel i/o is guaranteed to advance.
Finally, writer wakeup occurs at the conclusion of the line discipline
write (in tty_write_unlock()). This guarantees that any user-space write
waiters are woken to continue additional i/o.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
LNEXT processing accounts for ~15% of total cpu time in end-to-end
tty i/o; factor the lnext test/clear from the per-char i/o path.
Instead, attempt to immediately handle the literal next char if not
at the end of this received buffer; otherwise, handle the first char
of the next received buffer as the literal next char, then continue
with normal i/o.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
gcc will likely inline these single-use functions anyway; remove
inline modifier.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Always pre-figure the space available in the read_buf and limit
the inbound receive request to that amount.
For compatibility reasons with the non-flow-controlled interface,
n_tty_receive_buf() will continue filling read_buf until all data
has been received or receive_room() returns 0.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Handle PARMRK processing on the slow per-char i/o path.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert to modal receive_buf processing; factor char receive
processing for unusual termios settings out of normal per-char
i/o path.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Factor 'special' per-char processing into standalone fn,
n_tty_receive_char_special(), which handles processing for chars
marked in the char_map.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Relocate the IXANY restart tty test to code paths where the
the received char is not START_CHAR, STOP_CHAR, INTR_CHAR,
QUIT_CHAR or SUSP_CHAR.
Fixes the condition when ISIG if off and one of INTR_CHAR,
QUIT_CHAR or SUSP_CHAR does not restart i/o.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Simplify __receive_buf() into a dispatch function; perform per-char
processing for all other modes not already handled.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77
'n_tty: Move buffers into n_tty_data'
broke the ppc64 build.
Include vmalloc.h for the required function declarations.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert to modal receive_buf() processing; factor receive char
processing when tty->closing into n_tty_receive_buf_closing().
Note that EXTPROC when ISTRIP or IUCLC is set continues to be
handled by n_tty_receive_char().
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When EXTPROC is set without ISTRIP or IUCLC, processing is
identical to raw mode; handle this receiving mode as a special-case
of raw mode.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert to modal receive_buf() processing; factor raw mode
per-char i/o into n_tty_receive_buf_raw().
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Prepare for modal receive_buf() handling; factor handling for
TTY_BREAK, TTY_PARITY, TTY_FRAME and TTY_OVERRUN into
n_tty_receive_char_flagged().
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Reduce the monolithic n_tty_receive_char() complexity; factor the
handling of INTR_CHAR, QUIT_CHAR and SUSP_CHAR into
n_tty_receive_signal_char().
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert to modal receive_buf() processing; factor real_raw
receive_buf() into n_tty_receive_buf_real_raw().
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Reduce pointer reloading and improve locality-of-reference;
allocate read_buf and echo_buf within struct n_tty_data.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The char and flag buffer local alias pointers, p and f, are
unnecessary; remove them.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In canonical mode, an EOF which is not the first character of the line
causes read() to complete and return the number of characters read so
far (commonly referred to as EOF push). However, if the previous read()
returned because the user buffer was full _and_ the next character
is an EOF not at the beginning of the line, read() must not return 0,
thus mistakenly indicating the end-of-file condition.
The TTY_PUSH flag is used to indicate an EOF was received which is not
at the beginning of the line. Because the EOF push condition is
evaluated by a thread other than the read(), multiple EOF pushes can
cause a premature end-of-file to be indicated.
Instead, discover the 'EOF push as first read character' condition
from the read() thread itself, and restart the i/o loop if detected.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|