- 06 Sep, 2012 21 commits
-
-
Felipe Balbi authored
enable RX FIFO for 16 characters and TX FIFO for 16 spaces. Tested-by:
Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Felipe Balbi authored
nobody needs to access the uart_omap_port structure other than omap-serial.c file. Let's move that structure definition to the C source file in order to prevent anyone from accessing our structure. Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Felipe Balbi authored
this driver doesn't use any from <plat/dmtimer.h>, so we can remove it without any problems. This will, however cause a problem because omap-serial.c was relying on indirect inclusion of <linux/platform_device.h>, let's fix the issue by including <linux/platform_device.h> on omap-serial.c as it should be. Tested-by:
-
Vikram Pandita authored
Software flow control register bits were not defined correctly. Also clarify the IXON and IXOFF logic to reflect what userspace wants. Cc: stable@vger.kernel.org Tested-by:
Vikram Pandita <vikram.pandita@ti.com> Signed-off-by:
-
Felipe Balbi authored
if we would reach serial_omap_get_char() while Data Ready bit isn't set, we would return from it without kicking our pm timer. This would mean we would, eventually, have an unbalanced pm_runtime_get on our device which would prevent it from ever sleeping again. Tested-by:
-
Felipe Balbi authored
This has been missing from OMAP UART driver for quite a while and it's simple enough to implement it. Tested-by:
-
Ruchika Kharwar authored
This patch unlocks the port lock before calling a serial_core API and re-acquires the port lock after calling it. This patch fixes a system freeze issue seen when the serial_core API uart_write_wakeup() eventually attempts to acquire the port lock already acquired by omap serial interrupt handler. Tested-by:
Ruchika Kharwar <ruchika@ti.com> Signed-off-by:
Pavan Savoy <pavan_savoy@ti.com> Signed-off-by:
Vijay Badawadagi <bvijay@ti.com> Signed-off-by:
-
Felipe Balbi authored
it makes no sense to mark our IRQ handler inline since it's passed as a function pointer when enabling the IRQ line. Tested-by:
-
Felipe Balbi authored
Two functions: omap_serial_fill_features_erratas() and of_get_uart_port_info() are only called from probe(). Marking them as __devinit gives us another oportunity to free some code after .init.text is done. Tested-by:
-
Ruchika Kharwar authored
pm_runtime_enable() needs to be invoked before pm_runtime_use_autosuspend(), and pm_runtime_set_autosuspend_delay() functions. Tested-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
Felipe Balbi authored
When we're running our hardirq handler, there's not need to disable IRQs with spin_lock_irqsave() because IRQs are already disabled. It also makes no difference if we save or not IRQ flags. Switch over to simple spin_lock/spin_unlock and drop the "flags" variable. Tested-by:
-
Felipe Balbi authored
before removing the driver, let's make sure to force device into a suspended state in order to conserve power. Tested-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by:
-
Felipe Balbi authored
if platform_get_drvdata() returns NULL, that's quite a nasty bug on the driver which we want to catch ASAP. Otherwise, that check is hugely unneeded. Tested-by:
-
Felipe Balbi authored
by the time we call our first pm_runtme_get_sync() after enable pm_runtime, our resume method might be called. To avoid problems, we must make sure that our dev->drvdata is set correctly before our resume method gets called. Tested-by:
-
Felipe Balbi authored
Everytime we're done using our TTY, we want the pm timer to be reinitilized. By sticking to pm_runtime_pm_autosuspend() we make sure that this will always be the case. The idea behind this patch is to make sure we will always reinitialize the pm timer so that we don't fall into a situation where pm_runtime_put() expires right away (if timer was already about to expire when we made the call to pm_runtime_put()). While suspending right away wouldn't cause any issues, reinitializing the pm timer can help us avoiding unnecessary context save & restore operations (which are somewhat expensive) if there's another read/write/set_termios request coming right after. IOW, we are trying to make sure UART is still powered up while it's still under heavy usage. Tested-by:
-
Felipe Balbi authored
since all other IRQ types now do all necessary checks inside their handlers, transmit_chars() was the only one left expecting serial_omap_irq() to check THRE for it. We can move THRE check to transmit_chars() in order to make serial_omap_irq() more uniform. Tested-by:
-
Felipe Balbi authored
receive_chars() was getting too big and too difficult to follow. By splitting it into separate RDI and RSLI handlers, we have smaller functions which are easy to understand and only touch the pieces which they need to touch. Tested-by:
-
Felipe Balbi authored
quite a few changes here, though they are pretty obvious. In summary we're making sure to detect which interrupt type we need to handle before calling the underlying interrupt handling procedure. Tested-by:
-
Felipe Balbi authored
OMAP has some extra Interrupt types which can be really useful for SW. Let's define them so we can later use those in OMAP's serial driver. Tested-by:
-
Felipe Balbi authored
The current support is known to be broken and a later patch will come re-adding it using dma engine API. Tested-by:
-
Felipe Balbi authored
The driver doesn't need to know about its platform_device. Everything the driver needs can be done through the struct device pointer. In case we need to use the OMAP-specific PM function pointers, those can make sure to find the device's platform_device pointer so they can find the struct omap_device through pdev->archdata field. Tested-by:
-
- 05 Sep, 2012 19 commits
-
-
Alan Cox authored
These were reported in bugzilla long ago with a hack patch. Now we have a proper patch for one we can do the rest. Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=25102Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Wei Yongjun authored
ops has been allocated in this function and should be freed before leaving from the error handling cases. spatch with a semantic match is used to found this problem. (http://coccinelle.lip6.fr/) Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Huang Shijie authored
In most of the time, the driver needs to check if the cts flow control is enabled. But now, the driver checks the ASYNC_CTS_FLOW flag manually, which is not a grace way. So add a new wraper function to make the code tidy and clean. Signed-off-by:
Huang Shijie <shijie8@gmail.com> Signed-off-by:
-
Felipe Balbi authored
this patch is in preparation to a few other changes which will align on the prototype for function pointers passed through pdata. It also helps cleaning up the driver a little by agregating checks for pdata in a single location. Tested-by:
-
Felipe Balbi authored
current code only works because struct uart_port is the first member on the uart_omap_port structure. If, for whatever reason, someone puts another member as the first of the structure, that cast won't work anymore. In order to be safe, let's use a container_of() which, for now, gets optimized into a cast anyway. Tested-by:
-
Alexander Shiyan authored
This patch adds note about migration to driver SCCNXP in the code of driver SC26XX and in MIPS SNI board initialization with example. Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
Alexander Shiyan authored
This driver is a replacement for a SC26XX driver with a lot of improvements and new features. The main differences from the SC26XX driver: - Removed dependency on MIPS. Driver can be used on any platform. - Added support for SCC2681, SCC2691, SCC2692, SC28L91, SC28L92, SC28L202, SCC68681 and SCC68692 ICs. - Using devm_-related functions. - Improved error handling of serial port, improved FIFO handling. - Ability to load multiple instances of drivers. To avoid the possibility of regression, driver SC26XX left in the system to confirm the stability of the driver on platforms where it is being used. Signed-off-by:
-
Guainluca Anzolin authored
To allow parport_serial to handle the card the same PCI ids are blacklisted in 8250_pci.c using the existing software blacklist mechanism. The blacklist array is also renamed because it now covers this new use case. Since the two serial ports are auto-detected as XScale instead of 16550A clones, we also add a quirk to 8250_pci.c to skip autodetection and set the correct port type. Signed-off-by:
Gianluca Anzolin <gianluca@sottospazio.it> [Fold in fixes for the uart_8250 change] Signed-off-by:
-
Sachin Kamat authored
Fixes the following errors and warnings: ERROR: trailing whitespace ERROR: return is not a function, parentheses are not required WARNING: suspect code indent for conditional statements (32, 36) Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Acked-by:
-
Sachin Kamat authored
Silences checkpatch warnings regarding use of printks. Signed-off-by:
-
Matthew Leach authored
If the order of UART nodes is changed in the device tree, then tty dev devices are attached to different serial ports causing the console to be directed to a different physical serial port. The "serial" aliases in the device tree should prevent this. This patch ensures that the UART driver creates tty devices that honour these aliases if a device tree is present. Acked-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Rob Herring <rob.herring@calxeda.com> Signed-off-by:
Matthew Leach <matthew.leach@arm.com> Signed-off-by:
-
Paul Gortmaker authored
This structure might have made sense many years ago, but at this point it is only used in one specific driver, and referenced in stale comments elsewhere. Rather than change the sunsu.c driver, simply move the struct to be within the exclusive domain of that driver, so it won't get inadvertently picked up and used by other serial drivers going forward. The comments referencing the now driver specific struct are updated accordingly. Note that 8250.c has a struct that is similar in usage, with the name serial8250_config; but is 100% independent and untouched here. Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Paul Gortmaker authored
The addition of 8250-like entities continues to grow, while this driver has a snapshot of a select few common 8250 UARTs. So it has no need to grow with the new additions, since it calls out its own (largely historic) static list which does not grow. Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Paul Gortmaker authored
The struct serial_uart_config is hardly used at all, and the use case like this one are somewhat needless. Remove the trivial usage so that we can remove serial_uart_config. Since the type field isn't really used at all, we also delete the initialization and references of it here as well. Cc: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by:
-
Uwe Kleine-König authored
These error paths are used more often now after deep changes to the clock code and pinctrl is still new for imx. So help debugging and give clues in the boot log. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Alan Cox authored
These are used with the tty_port flags which are tty generic so move the flags into a more sensible place. This then makes it possible to add helpers such as those suggested by Huang Shijie. Signed-off-by:
-
Alan Cox authored
We want them split so that we can call them from setserial functionality where we copy to/from user space and do the locking, but also from sysfs where in future we'll want to came them within a sysfs context. Signed-off-by:
-
Julia Lawall authored
devm free functions should not have to be explicitly used. A semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ @@ ( * devm_kfree(...); | * devm_free_irq(...); | * devm_iounmap(...); | * devm_release_region(...); | * devm_release_mem_region(...); ) // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Wolfram Sang authored
Tested on a custom MPC5200B-board using some fancy industrial protocol. Verified that MPC512x has identical bits, so should work there as well. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Acked-by:
Anatolij Gustschin <agust@denx.de> Signed-off-by:
-
