* [PATCH] serial8250-em: clk_get() IS_ERR() error handling fix
From: Magnus Damm @ 2012-05-09 6:49 UTC (permalink / raw)
To: linux-serial
Cc: horms, arnd, linux-sh, gregkh, swarren, linux-kernel, rjw,
paul.gortmaker, lethal, olof, Magnus Damm, dan.j.williams, alan
From: Magnus Damm <damm@opensource.se>
Update the 8250_em driver to correctly handle the case
where no clock is associated with the device.
The return value of clk_get() needs to be checked with
IS_ERR() to avoid NULL pointer referencing.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
Applies of top of "[PATCH] serial8250-em: Emma Mobile UART driver V2"
included in linux-next 20120508.
drivers/tty/serial/8250/8250_em.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- 0001/drivers/tty/serial/8250/8250_em.c
+++ work/drivers/tty/serial/8250/8250_em.c 2012-05-09 15:35:10.000000000 +0900
@@ -110,8 +110,9 @@ static int __devinit serial8250_em_probe
}
priv->sclk = clk_get(&pdev->dev, "sclk");
- if (!priv->sclk) {
+ if (IS_ERR(priv->sclk)) {
dev_err(&pdev->dev, "unable to get clock\n");
+ ret = PTR_ERR(priv->sclk);
goto err1;
}
^ permalink raw reply
* [PATCH] serial8250-em: Add DT support
From: Magnus Damm @ 2012-05-09 6:55 UTC (permalink / raw)
To: linux-serial
Cc: horms, arnd, linux-sh, gregkh, swarren, linux-kernel, rjw,
paul.gortmaker, lethal, olof, Magnus Damm, dan.j.williams, alan
From: Magnus Damm <damm@opensource.se>
Update the 8250_em driver to support DT.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
Applies of top of "[PATCH] serial8250-em: Emma Mobile UART driver V2"
(included in linux-next 20120508) and the recently posted
"[PATCH] serial8250-em: clk_get() IS_ERR() error handling fix".
drivers/tty/serial/8250/8250_em.c | 7 +++++++
1 file changed, 7 insertions(+)
--- 0002/drivers/tty/serial/8250/8250_em.c
+++ work/drivers/tty/serial/8250/8250_em.c 2012-05-09 15:39:22.000000000 +0900
@@ -163,9 +163,16 @@ static int __devexit serial8250_em_remov
return 0;
}
+static const struct of_device_id serial8250_em_dt_ids[] __devinitconst = {
+ { .compatible = "renesas,em-uart", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, serial8250_em_dt_ids);
+
static struct platform_driver serial8250_em_platform_driver = {
.driver = {
.name = "serial8250-em",
+ .of_match_table = serial8250_em_dt_ids,
.owner = THIS_MODULE,
},
.probe = serial8250_em_probe,
^ permalink raw reply
* Re: [PATCH] serial8250-em: Add DT support
From: Arnd Bergmann @ 2012-05-09 11:21 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-serial, horms, linux-sh, gregkh, swarren, linux-kernel, rjw,
paul.gortmaker, lethal, olof, dan.j.williams, alan
In-Reply-To: <20120509065514.18528.83245.sendpatchset@w520>
On Wednesday 09 May 2012, Magnus Damm wrote:
>
> From: Magnus Damm <damm@opensource.se>
>
> Update the 8250_em driver to support DT.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 3/3] RFC: Solved unnecessary schedule latency in the TTY layer (3/3)
From: Alan Cox @ 2012-05-10 15:28 UTC (permalink / raw)
To: Ivo Sieben; +Cc: Greg KH, linux-serial, RT
In-Reply-To: <1336048663-21882-3-git-send-email-meltedpianoman@gmail.com>
On Thu, 3 May 2012 14:37:43 +0200
Ivo Sieben <meltedpianoman@gmail.com> wrote:
> Solved unnecessary schedule latency in the TTY layer when used in
> realtime context:
> The global wait_queue that is used for line discipline idle handling
> is moved to a separate wait_queue for each line instance. This
> prevents unnecessary blocking on one line, because of idle handling
> on another line.
>
> Note: In a PREEMPT_RT system "normal" spin locks behave like mutexes
> and no interrupts (and therefor no scheduling) is disabled.
>
> Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
And this one as a standalone I think we should merge. I'm surprised it
makes a difference but its small, clean and localises a lock which is a
good thing.
Alan
^ permalink raw reply
* Re: [PATCH 1/3] RFC: Solved unnecessary schedule latency in the TTY layer (1/3)
From: Alan Cox @ 2012-05-10 15:26 UTC (permalink / raw)
To: Ivo Sieben; +Cc: Greg KH, linux-serial, RT
In-Reply-To: <1336048663-21882-1-git-send-email-meltedpianoman@gmail.com>
> Note: In a PREEMPT_RT system "normal" spin locks behave like mutexes
> and no interrupts (and therefor no scheduling) is disabled.
>
> Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
(Coming back round to these patches now the urgent stuff is buried for
a bit)
> void tty_schedule_flip(struct tty_struct *tty)
> {
> - unsigned long flags;
> - spin_lock_irqsave(&tty->buf.lock, flags);
> - if (tty->buf.tail != NULL)
> - tty->buf.tail->commit = tty->buf.tail->used;
> - spin_unlock_irqrestore(&tty->buf.lock, flags);
> - schedule_work(&tty->buf.work);
> + tty_flip_buffer_push(tty);
> }
You'd need to ifdef both of these for non RT cases. I think it may be
right for RT although I'm not 100% sure on the locking.
At this point I think we'd be better off sorting out our tty locking in
general before tackling RT optimisations. However as an RT patch it
looks good and its interesting to see RT simplifying code not making it
more complex.
^ permalink raw reply
* Re: [PATCH 3/3] tty_lock: Localise the lock
From: Sasha Levin @ 2012-05-11 10:40 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Alan Cox, linux-kernel, linux-serial, Jiri Slaby
In-Reply-To: <CA+1xoqdi1Jdkrjtj9bmnDfs4Ok=o=AsmpP=MY0V8cDXjcSNm1w@mail.gmail.com>
On Tue, May 8, 2012 at 8:12 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> On Mon, May 7, 2012 at 11:04 PM, Jiri Slaby <jslaby@suse.cz> wrote:
>> On 05/07/2012 07:00 PM, Sasha Levin wrote:
>>>> So whatever your trace is showing, that's not the bug. Something more
>>>> complicated would appear to be afoot.
>>>
>>> Oddly enough, tty != tty->link, but the lockdep warning triggers.
>>>
>>> Any idea why it might happen?
>>
>> I think so, both locks are the same lockdep class. So lockdep thinks it
>> is the same lock. However this is a false positive. I guess we need
>> mutex_lock_nested...
>
> It looks like it causes an actual deadlock, and hung_tasks screams if
> left alone for a bit, so it doesn't look like a lockdep issue.
I've applied the patch that unlocks before hangup, and started seeing
this new warning instead (sorry if output below looks a bit broken,
linux-next has a printk rework in progress):
[ 47.919734] =============================================
[ 47.920013] [ INFO: possible recursive locking detected ]
[ 47.920013] 3.4.0-rc6-next-20120511-sasha-00001-g1975c5f #183
Tainted: G W
[ 47.920013] ---------------------------------------------
[ 47.920013] trinity/6825 is trying to acquire lock:
[ 47.920013] (&tty->legacy_mutex){+.+.+.}, at: [<ffffffff82e9cd02>]
tty_lock+0x72/0x80
[ 47.920013]
but task is already holding lock:
[ 47.920013] (&tty->legacy_mutex){+.+.+.}, at: [<ffffffff82e9cd02>]
tty_lock+0x72/0x80
[ 47.920013]
other info that might help us debug this:
[ 47.920013] Possible unsafe locking scenario:
[ 47.920013] CPU0
[ 47.920013] ----
[ 47.920013] lock(&tty->legacy_mutex);
[ 47.920013] lock(&tty->legacy_mutex);
[ 47.920013]
*** DEADLOCK ***
[ 47.920013] May be due to missing lock nesting notation
[ 47.920013] 2 locks held by trinity/6825:
[ 47.920013] #0: (tty_mutex){+.+.+.}, at: [<ffffffff81b00837>]
tty_release+0x177/0x4d0
[ 47.920013] #1: (&tty->legacy_mutex){+.+.+.}, at:
[<ffffffff82e9cd02>] tty_lock+0x72/0x80
[ 47.920013]
stack backtrace:
[ 47.920013] Pid: 6825, comm: trinity Tainted: G W
3.4.0-rc6-next-20120511-sasha-00001-g1975c5f #183
[ 47.920013] Call Trace:
[ 47.920013] [<ffffffff811440b9>] print_deadlock_bug+0x119/0x140
[ 47.920013] [<ffffffff8114622e>] validate_chain+0x5ee/0x790
[ 47.920013] [<ffffffff81119eb8>] ? sched_clock_cpu+0x108/0x120
[ 47.920013] [<ffffffff811467f3>] __lock_acquire+0x423/0x4c0
[ 47.920013] [<ffffffff81146a1a>] lock_acquire+0x18a/0x1e0
[ 47.920013] [<ffffffff82e9cd02>] ? tty_lock+0x72/0x80
[ 47.920013] [<ffffffff82e99558>] ? __mutex_lock_common+0x518/0x590
[ 47.920013] [<ffffffff82e990a0>] __mutex_lock_common+0x60/0x590
[ 47.920013] [<ffffffff82e9cd02>] ? tty_lock+0x72/0x80
[ 47.920013] [<ffffffff82e9cd02>] ? tty_lock+0x72/0x80
[ 47.920013] [<ffffffff82e99700>] mutex_lock_nested+0x40/0x50
[ 47.920013] [<ffffffff82e9cd02>] tty_lock+0x72/0x80
[ 47.920013] [<ffffffff82e9cd36>] tty_lock_pair+0x26/0x54
[ 47.920013] [<ffffffff81b00842>] tty_release+0x182/0x4d0
[ 47.920013] [<ffffffff8122cf1a>] __fput+0x11a/0x2c0
[ 47.920013] [<ffffffff8122d0d5>] fput+0x15/0x20
[ 47.920013] [<ffffffff812293e2>] filp_close+0x82/0xa0
[ 47.920013] [<ffffffff810d6214>] close_files+0x1b4/0x200
[ 47.920013] [<ffffffff810d6060>] ? wait_task_stopped+0x3c0/0x3c0
[ 47.920013] [<ffffffff810d6425>] ? exit_files+0x45/0x60
[ 47.920013] [<ffffffff810d6281>] put_files_struct+0x21/0x180
[ 47.920013] [<ffffffff82e9c6a0>] ? _raw_spin_unlock+0x30/0x60
[ 47.920013] [<ffffffff810d642d>] exit_files+0x4d/0x60
[ 47.920013] [<ffffffff810d86e2>] do_exit+0x322/0x500
[ 47.920013] [<ffffffff810d8961>] do_group_exit+0xa1/0xe0
[ 47.920013] [<ffffffff810d89b2>] sys_exit_group+0x12/0x20
[ 47.920013] [<ffffffff82e9d7f9>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* auto-RTS and TL16C754C
From: grego rigolo @ 2012-05-11 12:18 UTC (permalink / raw)
To: linux-serial@vger.kernel.org
Hi all,
I am using a TL16C754C in my design and i was wondering why the Auto-RTS was not enabled.
Indeed in the 8250.c source code we can read
FIXME:
* - TI16C752 requires control thresholds to be set.
* - UART_MCR_RTS is ineffective if auto-RTS mode is enabled
In the serial-omap.c, i saw that auto-rts had been enabled:
/* Hardware Flow Control Configuration */
if (termios->c_cflag & CRTSCTS)
{
efr |= (UART_EFR_CTS | UART_EFR_RTS);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
up->mcr = serial_in(up, UART_MCR);
serial_out(up, UART_MCR, up->mcr | UART_MCR_TCRTLR);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
up->efr = serial_in(up, UART_EFR);
serial_out(up, UART_EFR, up->efr | UART_EFR_ECB);
serial_out(up, UART_TI752_TCR, OMAP_UART_TCR_TRIG);
serial_out(up, UART_EFR, efr); /* Enable AUTORTS and AUTOCTS */
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up,
UART_MCR, up->mcr | UART_MCR_RTS);
serial_out(up, UART_LCR, cval);
Thanks in advance for your comments
greg
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] tty_lock: Localise the lock
From: Greg KH @ 2012-05-11 14:52 UTC (permalink / raw)
To: Sasha Levin; +Cc: Jiri Slaby, Alan Cox, linux-kernel, linux-serial, Jiri Slaby
In-Reply-To: <CA+1xoqcZnxGoo=_X1idCPTk9gR=drnAKhULGzgkH33zYGnAgOA@mail.gmail.com>
On Fri, May 11, 2012 at 12:40:41PM +0200, Sasha Levin wrote:
> On Tue, May 8, 2012 at 8:12 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> > On Mon, May 7, 2012 at 11:04 PM, Jiri Slaby <jslaby@suse.cz> wrote:
> >> On 05/07/2012 07:00 PM, Sasha Levin wrote:
> >>>> So whatever your trace is showing, that's not the bug. Something more
> >>>> complicated would appear to be afoot.
> >>>
> >>> Oddly enough, tty != tty->link, but the lockdep warning triggers.
> >>>
> >>> Any idea why it might happen?
> >>
> >> I think so, both locks are the same lockdep class. So lockdep thinks it
> >> is the same lock. However this is a false positive. I guess we need
> >> mutex_lock_nested...
> >
> > It looks like it causes an actual deadlock, and hung_tasks screams if
> > left alone for a bit, so it doesn't look like a lockdep issue.
>
> I've applied the patch that unlocks before hangup, and started seeing
> this new warning instead (sorry if output below looks a bit broken,
> linux-next has a printk rework in progress):
The printk rework should now be working again in linux-next. Is it
still causing problems for you?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/3] tty_lock: Localise the lock
From: Sasha Levin @ 2012-05-11 15:09 UTC (permalink / raw)
To: Greg KH; +Cc: Jiri Slaby, Alan Cox, linux-kernel, linux-serial, Jiri Slaby
In-Reply-To: <20120511145243.GE5958@kroah.com>
On Fri, May 11, 2012 at 4:52 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> The printk rework should now be working again in linux-next. Is it
> still causing problems for you?
Mostly does, there's still a minor issue regarding showing timestamps
on each line in the log, I've commented about it in the original
thread (
http://permalink.gmane.org/gmane.linux.kernel/1295580).
It's fairly visible in the lockdep spew, since lockdep does lots of
this "printk("\nsomething\n");"
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* haalloo,
From: abi @ 2012-05-12 16:54 UTC (permalink / raw)
haalloo,
how are you doing,i hope you are fine,my name is miss abi okom i got your
contact and want us to be a good friend,
please try and write back to me so that i will give you my pictures and tell
you more about me,
^ permalink raw reply
* Dedicated server rental
From: eric @ 2012-05-14 4:14 UTC (permalink / raw)
Dear Sir/Madam,
Please see below our Server Rental Package,
HKD1980/month + one-time setup fee HKD2000
Dell? PowerEdge? Enterprise Rack Mount Server
- Intel(R) Xeon(R) E3-1220 Processor (3.10GHz, 8M Cache, Turbo, 4C/4T, 80W)
- 4GB RAM, 1x4GB, 1333MHz, DDR-3, Single Ranked UDIMMs
- 500GB, 3.5", SATA II x 1 Enterprise Hard Disk
- Remote KVM (iDRAC6 Enterprise)
- 8x SATA slim DVD-ROM Drive
- Dell OpenManage
- Broadcom 5716 dual-port Gigabit Ethernet without TOE enabled
- Dell BMC Info Mod
Software Specification
- CentOS 5/6 Linux Operating System
Data Center Facilities
- 1Gbps Share Internet Connectivity with 10/BASE-T
- One IP Addresses Allocation
- Un-interruptible Power Supply (UPS) backed up by private diesel generator
- FM200 gas¡Vbased fire suppression system
- 24x7 CRAC Air Conditioning and Humidity Control
- 24x7 Security Control
Should you have any query, please feel free to contact me. Thanks.
Best,
Eric Chan
Senior Sales Executive
If you do not wish to further receive this event message, meail subscriber@dedicatedserver.com.hk to unsubscribe this message.
^ permalink raw reply
* RE: [PATCH v2] serial: 8250: Add cpufreq support
From: Shankarmurthy, Akshay @ 2012-05-14 12:20 UTC (permalink / raw)
To: alan@linux.intel.com, linux-serial@vger.kernel.org
Cc: gregkh@linuxfoundation.org, paul.gortmaker@windriver.com,
jamie@jamieiles.com, swarren@nvidia.com, dianders@chromium.org,
davinci-linux-open-source@linux.davincidsp.com
In-Reply-To: <1335353194-2621-1-git-send-email-akshay.s@ti.com>
Hi Alan,
On Wed, Apr 25, 2012 at 16:56:33, Shankarmurthy, Akshay wrote:
> This patch adds cpufreq support for 8250 serial driver. A clk structure member has been added to the platform and port data structures. This member is used by the cpufreq notifier callback to get the updated clock rate. Also adds a member 'cpufreq_flag' to the plat_serial8250_port and uart_port structures which decides the requirement of cpufreq registration for each individual ports. If the port requires registration then 'cpufreq_flag'
> should be passed as TRUE from the board file.
>
> Tested on TI DA850/OMAP-L138 EVM.
>
> Signed-off-by: Chaithrika U S <chaithrika@ti.com>
> Signed-off-by: Shankarmurthy, Akshay <akshay.s@ti.com>
> ---
> v2 includes following changes :
>
> 1. Used "tty_port_tty_get" API to get the tty struct instead of accesing it directly from the uart_port structure.
> 2. Added a boolean member "enable_cpufreq" to the uart_port and serial8250_port structures. This indicates the requirement of cpu freq registration for each individual ports.
> 3. Renamed the function from "serial8250_cpufreq_deregister" to "serial8250_cpufreq_unregister".
>
> Changes are as per these discussions
> http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg22841.html
>
Please let me know if there are any comments on this patch?
Regards,
Akshay
^ permalink raw reply
* Re: [PATCH 1/3] RFC: Solved unnecessary schedule latency in the TTY layer (1/3)
From: Ivo Sieben @ 2012-05-14 12:25 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg KH, linux-serial, RT
In-Reply-To: <20120510162621.4b5d7907@bob.linux.org.uk>
Hi,
2012/5/10 Alan Cox <alan@linux.intel.com>:
>
> You'd need to ifdef both of these for non RT cases. I think it may be
> right for RT although I'm not 100% sure on the locking.
Alan, I don't completely understand what you mean with "ifdef both".
Regarding the following two functions defined in drivers/tty/tty_buffer.c
- tty_schedule_flip
- tty_flip_buffer_push
They both implement almost the same functionality:
void tty_schedule_flip(struct tty_struct *tty)
{
unsigned long flags;
spin_lock_irqsave(&tty->buf.lock, flags);
if (tty->buf.tail != NULL)
tty->buf.tail->commit = tty->buf.tail->used;
spin_unlock_irqrestore(&tty->buf.lock, flags);
schedule_work(&tty->buf.work);
}
void tty_flip_buffer_push(struct tty_struct *tty)
{
unsigned long flags;
spin_lock_irqsave(&tty->buf.lock, flags);
if (tty->buf.tail != NULL)
tty->buf.tail->commit = tty->buf.tail->used;
spin_unlock_irqrestore(&tty->buf.lock, flags);
#ifndef CONFIG_PREEMPT_RT_FULL
if (tty->low_latency)
flush_to_ldisc(&tty->buf.work);
else
schedule_work(&tty->buf.work);
#else
flush_to_ldisc(&tty->buf.work);
#endif
}
Only difference is that tty_schedule_flip() always uses the work
queue, while the tty_flip_buffer_push only uses the work queue in case
of a non prempt_rt system and low_latency flag unset.
I see that most serial drivers use the tty_flip_buffer_push()
function. But still a number of drivers use the tty_schedule_flip()
function. I even found one driver that uses both
(drivers/staging/serqt_usb2/serqt_usb2.c). Is is there a reason for
these two functions implementing slightly different behavior?
If not, I think it would be better to remove the tty_schedule_flip()
function completely in a separate patch...
Regards,
Ivo Sieben
^ permalink raw reply
* [PATCH] tty: Allow uart_register/unregister/register
From: Alan Cox @ 2012-05-14 13:51 UTC (permalink / raw)
To: greg, linux-serial
From: Alan Cox <alan@linux.intel.com>
This is legitimate but because we don't clear the drv->state pointer in the
unregister code causes a bogus BUG().
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/tty/serial/serial_core.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9c4c05b..246b823 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2282,6 +2282,7 @@ void uart_unregister_driver(struct uart_driver *drv)
tty_unregister_driver(p);
put_tty_driver(p);
kfree(drv->state);
+ drv->state = NULL;
drv->tty_driver = NULL;
}
^ permalink raw reply related
* [RESEND PATCH V2 10/17] SERIAL: MIPS: lantiq: implement OF support
From: John Crispin @ 2012-05-14 17:42 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips, John Crispin, Alan Cox, linux-serial
In-Reply-To: <1337017363-14424-1-git-send-email-blogic@openwrt.org>
Add devicetree and handling for our new clkdev clocks. The patch is rather
straightforward. .of_match_table is set and the 3 irqs are now loaded from the
devicetree.
This series converts the lantiq target to clkdev amongst other things. The
driver needs to handle two clocks now. The fpi bus clock used to derive the
divider and the clock gate needed on some socs to make the secondary port work.
Signed-off-by: John Crispin <blogic@openwrt.org>
Cc: Alan Cox <alan@linux.intel.com>
Cc: linux-serial@vger.kernel.org
---
This patch is part of a series moving the mips/lantiq target to OF and clkdev
support. The patch, once Acked, should go upstream via Ralf's MIPS tree.
Changes in V2
* use LTQ_EARLY_ASC to detect the console
drivers/tty/serial/lantiq.c | 83 ++++++++++++++++++++++++++----------------
1 files changed, 51 insertions(+), 32 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 96c1cac..02da071 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -31,16 +31,19 @@
#include <linux/tty_flip.h>
#include <linux/serial_core.h>
#include <linux/serial.h>
-#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <linux/io.h>
#include <linux/clk.h>
+#include <linux/gpio.h>
#include <lantiq_soc.h>
#define PORT_LTQ_ASC 111
#define MAXPORTS 2
#define UART_DUMMY_UER_RX 1
-#define DRVNAME "ltq_asc"
+#define DRVNAME "lantiq,asc"
#ifdef __BIG_ENDIAN
#define LTQ_ASC_TBUF (0x0020 + 3)
#define LTQ_ASC_RBUF (0x0024 + 3)
@@ -114,6 +117,9 @@ static DEFINE_SPINLOCK(ltq_asc_lock);
struct ltq_uart_port {
struct uart_port port;
+ /* clock used to derive divider */
+ struct clk *fpiclk;
+ /* clock gating of the ASC core */
struct clk *clk;
unsigned int tx_irq;
unsigned int rx_irq;
@@ -316,7 +322,9 @@ lqasc_startup(struct uart_port *port)
struct ltq_uart_port *ltq_port = to_ltq_uart_port(port);
int retval;
- port->uartclk = clk_get_rate(ltq_port->clk);
+ if (ltq_port->clk)
+ clk_enable(ltq_port->clk);
+ port->uartclk = clk_get_rate(ltq_port->fpiclk);
ltq_w32_mask(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
@@ -382,6 +390,8 @@ lqasc_shutdown(struct uart_port *port)
port->membase + LTQ_ASC_RXFCON);
ltq_w32_mask(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU,
port->membase + LTQ_ASC_TXFCON);
+ if (ltq_port->clk)
+ clk_disable(ltq_port->clk);
}
static void
@@ -630,7 +640,7 @@ lqasc_console_setup(struct console *co, char *options)
port = <q_port->port;
- port->uartclk = clk_get_rate(ltq_port->clk);
+ port->uartclk = clk_get_rate(ltq_port->fpiclk);
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
@@ -668,37 +678,32 @@ static struct uart_driver lqasc_reg = {
static int __init
lqasc_probe(struct platform_device *pdev)
{
+ struct device_node *node = pdev->dev.of_node;
struct ltq_uart_port *ltq_port;
struct uart_port *port;
- struct resource *mmres, *irqres;
- int tx_irq, rx_irq, err_irq;
- struct clk *clk;
+ struct resource *mmres, irqres[3];
+ int line = 0;
int ret;
mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- irqres = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!mmres || !irqres)
+ ret = of_irq_to_resource_table(node, irqres, 3);
+ if (!mmres || (ret != 3)) {
+ dev_err(&pdev->dev,
+ "failed to get memory/irq for serial port\n");
return -ENODEV;
+ }
- if (pdev->id >= MAXPORTS)
- return -EBUSY;
+ /* check if this is the console port */
+ if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
+ line = 1;
- if (lqasc_port[pdev->id] != NULL)
+ if (lqasc_port[line]) {
+ dev_err(&pdev->dev, "port %d already allocated\n", line);
return -EBUSY;
-
- clk = clk_get(&pdev->dev, "fpi");
- if (IS_ERR(clk)) {
- pr_err("failed to get fpi clk\n");
- return -ENOENT;
}
- tx_irq = platform_get_irq_byname(pdev, "tx");
- rx_irq = platform_get_irq_byname(pdev, "rx");
- err_irq = platform_get_irq_byname(pdev, "err");
- if ((tx_irq < 0) | (rx_irq < 0) | (err_irq < 0))
- return -ENODEV;
-
- ltq_port = kzalloc(sizeof(struct ltq_uart_port), GFP_KERNEL);
+ ltq_port = devm_kzalloc(&pdev->dev, sizeof(struct ltq_uart_port),
+ GFP_KERNEL);
if (!ltq_port)
return -ENOMEM;
@@ -709,19 +714,26 @@ lqasc_probe(struct platform_device *pdev)
port->ops = &lqasc_pops;
port->fifosize = 16;
port->type = PORT_LTQ_ASC,
- port->line = pdev->id;
+ port->line = line;
port->dev = &pdev->dev;
-
- port->irq = tx_irq; /* unused, just to be backward-compatibe */
+ /* unused, just to be backward-compatible */
+ port->irq = irqres[0].start;
port->mapbase = mmres->start;
- ltq_port->clk = clk;
+ ltq_port->fpiclk = clk_get_fpi();
+ if (IS_ERR(ltq_port->fpiclk)) {
+ pr_err("failed to get fpi clk\n");
+ return -ENOENT;
+ }
- ltq_port->tx_irq = tx_irq;
- ltq_port->rx_irq = rx_irq;
- ltq_port->err_irq = err_irq;
+ /* not all asc ports have clock gates, lets ignore the return code */
+ ltq_port->clk = clk_get(&pdev->dev, NULL);
- lqasc_port[pdev->id] = ltq_port;
+ ltq_port->tx_irq = irqres[0].start;
+ ltq_port->rx_irq = irqres[1].start;
+ ltq_port->err_irq = irqres[2].start;
+
+ lqasc_port[line] = ltq_port;
platform_set_drvdata(pdev, ltq_port);
ret = uart_add_one_port(&lqasc_reg, port);
@@ -729,10 +741,17 @@ lqasc_probe(struct platform_device *pdev)
return ret;
}
+static const struct of_device_id ltq_asc_match[] = {
+ { .compatible = DRVNAME },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ltq_asc_match);
+
static struct platform_driver lqasc_driver = {
.driver = {
.name = DRVNAME,
.owner = THIS_MODULE,
+ .of_match_table = ltq_asc_match,
},
};
--
1.7.9.1
^ permalink raw reply related
* Re: [RESEND PATCH V2 10/17] SERIAL: MIPS: lantiq: implement OF support
From: Alan Cox @ 2012-05-14 17:51 UTC (permalink / raw)
To: John Crispin; +Cc: Ralf Baechle, linux-mips, Alan Cox, linux-serial
In-Reply-To: <1337017363-14424-10-git-send-email-blogic@openwrt.org>
On Mon, 14 May 2012 19:42:36 +0200
John Crispin <blogic@openwrt.org> wrote:
> Add devicetree and handling for our new clkdev clocks. The patch is rather
> straightforward. .of_match_table is set and the 3 irqs are now loaded from the
> devicetree.
>
> This series converts the lantiq target to clkdev amongst other things. The
> driver needs to handle two clocks now. The fpi bus clock used to derive the
> divider and the clock gate needed on some socs to make the secondary port work.
>
> Signed-off-by: John Crispin <blogic@openwrt.org>
> Cc: Alan Cox <alan@linux.intel.com>
> Cc: linux-serial@vger.kernel.org
Doesn't really touch the tty parts of the logic so fine by me
^ permalink raw reply
* Re: [RESEND PATCH V2 10/17] SERIAL: MIPS: lantiq: implement OF support
From: Greg KH @ 2012-05-14 19:32 UTC (permalink / raw)
To: John Crispin; +Cc: Ralf Baechle, linux-mips, Alan Cox, linux-serial
In-Reply-To: <1337017363-14424-10-git-send-email-blogic@openwrt.org>
On Mon, May 14, 2012 at 07:42:36PM +0200, John Crispin wrote:
> Add devicetree and handling for our new clkdev clocks. The patch is rather
> straightforward. .of_match_table is set and the 3 irqs are now loaded from the
> devicetree.
>
> This series converts the lantiq target to clkdev amongst other things. The
> driver needs to handle two clocks now. The fpi bus clock used to derive the
> divider and the clock gate needed on some socs to make the secondary port work.
>
> Signed-off-by: John Crispin <blogic@openwrt.org>
> Cc: Alan Cox <alan@linux.intel.com>
> Cc: linux-serial@vger.kernel.org
> ---
> This patch is part of a series moving the mips/lantiq target to OF and clkdev
> support. The patch, once Acked, should go upstream via Ralf's MIPS tree.
Fine with me as well, if you need it:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [RESEND PATCH V2 10/17] SERIAL: MIPS: lantiq: implement OF support
From: John Crispin @ 2012-05-14 19:49 UTC (permalink / raw)
To: Greg KH; +Cc: Ralf Baechle, linux-mips, Alan Cox, linux-serial
In-Reply-To: <20120514193232.GA5741@kroah.com>
On 14/05/12 21:32, Greg KH wrote:
> On Mon, May 14, 2012 at 07:42:36PM +0200, John Crispin wrote:
>> Add devicetree and handling for our new clkdev clocks. The patch is rather
>> straightforward. .of_match_table is set and the 3 irqs are now loaded from the
>> devicetree.
>>
>> This series converts the lantiq target to clkdev amongst other things. The
>> driver needs to handle two clocks now. The fpi bus clock used to derive the
>> divider and the clock gate needed on some socs to make the secondary port work.
>>
>> Signed-off-by: John Crispin <blogic@openwrt.org>
>> Cc: Alan Cox <alan@linux.intel.com>
>> Cc: linux-serial@vger.kernel.org
>> ---
>> This patch is part of a series moving the mips/lantiq target to OF and clkdev
>> support. The patch, once Acked, should go upstream via Ralf's MIPS tree.
> Fine with me as well, if you need it:
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thank you very much !
^ permalink raw reply
* [PATCH] serial: samsung: Fixed wrong comparison for baudclk_rate
From: Kyoungil Kim @ 2012-05-15 10:13 UTC (permalink / raw)
To: linux-arm-kernel, linux-serial, linux-samsung-soc
Cc: 'Kukjin Kim', 'Alan Cox', 'Kyoungil Kim',
'Yoon'
port->baudclk_rate should be compared to the rate of port->baudclk,
because port->baudclk_rate was assigned as the rate of port->baudclk previously.
So to check that the current baudclk rate is same as previous rate,
the target of comparison sholud be the rate of port->baudclk.
Signed-off-by: Jun-Ho, Yoon <junho78.yoon@samsung.com>
Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
---
drivers/tty/serial/samsung.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d8b0aee..c4867ea 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1014,10 +1014,10 @@ static int s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
* a disturbance in the clock-rate over the change.
*/
- if (IS_ERR(port->clk))
+ if (IS_ERR_OR_NULL(port->baudclk))
goto exit;
- if (port->baudclk_rate == clk_get_rate(port->clk))
+ if (port->baudclk_rate == clk_get_rate(port->baudclk))
goto exit;
if (val == CPUFREQ_PRECHANGE) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] serial: samsung: Fixed wrong comparison for baudclk_rate
From: Russell King - ARM Linux @ 2012-05-15 10:15 UTC (permalink / raw)
To: Kyoungil Kim
Cc: linux-arm-kernel, linux-serial, linux-samsung-soc,
'Kukjin Kim', 'Yoon', 'Alan Cox'
In-Reply-To: <000101cd3283$5f58eba0$1e0ac2e0$%kim@samsung.com>
On Tue, May 15, 2012 at 07:13:28PM +0900, Kyoungil Kim wrote:
> port->baudclk_rate should be compared to the rate of port->baudclk,
> because port->baudclk_rate was assigned as the rate of port->baudclk previously.
> So to check that the current baudclk rate is same as previous rate,
> the target of comparison sholud be the rate of port->baudclk.
>
> Signed-off-by: Jun-Ho, Yoon <junho78.yoon@samsung.com>
> Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
> ---
> drivers/tty/serial/samsung.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index d8b0aee..c4867ea 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -1014,10 +1014,10 @@ static int s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
> * a disturbance in the clock-rate over the change.
> */
>
> - if (IS_ERR(port->clk))
> + if (IS_ERR_OR_NULL(port->baudclk))
NAK. See my previous emails on the validity of clk_get() return values.
^ permalink raw reply
* RE: [PATCH] serial: samsung: Fixed wrong comparison for baudclk_rate
From: Kyoungil Kim @ 2012-05-15 11:52 UTC (permalink / raw)
To: 'Russell King - ARM Linux'
Cc: linux-arm-kernel, linux-serial, linux-samsung-soc,
'Kukjin Kim', 'Yoon', 'Alan Cox'
In-Reply-To: <20120515101541.GH10453@n2100.arm.linux.org.uk>
Russell King wrote:
> On Tue, May 15, 2012 at 07:13:28PM +0900, Kyoungil Kim wrote:
> > port->baudclk_rate should be compared to the rate of port->baudclk,
> > because port->baudclk_rate was assigned as the rate of port->baudclk previously.
> > So to check that the current baudclk rate is same as previous rate,
> > the target of comparison sholud be the rate of port->baudclk.
> >
> > Signed-off-by: Jun-Ho, Yoon <junho78.yoon@samsung.com>
> > Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
> > ---
> > drivers/tty/serial/samsung.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> > index d8b0aee..c4867ea 100644
> > --- a/drivers/tty/serial/samsung.c
> > +++ b/drivers/tty/serial/samsung.c
> > @@ -1014,10 +1014,10 @@ static int s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
> > * a disturbance in the clock-rate over the change.
> > */
> >
> > - if (IS_ERR(port->clk))
> > + if (IS_ERR_OR_NULL(port->baudclk))
>
> NAK. See my previous emails on the validity of clk_get() return values.
I read your previous emails, but I don't understand.
Could you explain more details, please?
^ permalink raw reply
* Re: [PATCH] serial: samsung: Fixed wrong comparison for baudclk_rate
From: Russell King - ARM Linux @ 2012-05-15 11:57 UTC (permalink / raw)
To: Kyoungil Kim
Cc: linux-arm-kernel, linux-serial, linux-samsung-soc,
'Kukjin Kim', 'Yoon', 'Alan Cox'
In-Reply-To: <000301cd3291$3a7a6940$af6f3bc0$%kim@samsung.com>
On Tue, May 15, 2012 at 08:52:39PM +0900, Kyoungil Kim wrote:
> Russell King wrote:
> > On Tue, May 15, 2012 at 07:13:28PM +0900, Kyoungil Kim wrote:
> > > port->baudclk_rate should be compared to the rate of port->baudclk,
> > > because port->baudclk_rate was assigned as the rate of port->baudclk previously.
> > > So to check that the current baudclk rate is same as previous rate,
> > > the target of comparison sholud be the rate of port->baudclk.
> > >
> > > Signed-off-by: Jun-Ho, Yoon <junho78.yoon@samsung.com>
> > > Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
> > > ---
> > > drivers/tty/serial/samsung.c | 4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> > > index d8b0aee..c4867ea 100644
> > > --- a/drivers/tty/serial/samsung.c
> > > +++ b/drivers/tty/serial/samsung.c
> > > @@ -1014,10 +1014,10 @@ static int s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
> > > * a disturbance in the clock-rate over the change.
> > > */
> > >
> > > - if (IS_ERR(port->clk))
> > > + if (IS_ERR_OR_NULL(port->baudclk))
> >
> > NAK. See my previous emails on the validity of clk_get() return values.
>
> I read your previous emails, but I don't understand.
> Could you explain more details, please?
Drivers are only allowed to assume that IS_ERR() values for clocks are
invalid. Everything else they should not concern themselves with.
^ permalink raw reply
* [PATCH v2] serial: samsung: Fixed wrong comparison for baudclk_rate
From: Kyoungil Kim @ 2012-05-15 12:37 UTC (permalink / raw)
To: linux-arm-kernel, linux-serial, linux-samsung-soc
Cc: 'Kukjin Kim', 'Alan Cox', 'Kyoungil Kim',
'Jun-Ho Yoon'
port->baudclk_rate should be compared to the rate of port->baudclk,
because port->baudclk_rate was assigned as the rate of port->baudclk previously.
So to check that the current baudclk rate is same as previous rate,
the target of comparison sholud be the rate of port->baudclk.
Signed-off-by: Jun-Ho, Yoon <junho78.yoon@samsung.com>
Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
---
drivers/tty/serial/samsung.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d8b0aee..6a6a86a 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1014,10 +1014,10 @@ static int s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
* a disturbance in the clock-rate over the change.
*/
- if (IS_ERR(port->clk))
+ if (IS_ERR(port->baudclk) || port->baudclk == NULL)
goto exit;
- if (port->baudclk_rate == clk_get_rate(port->clk))
+ if (port->baudclk_rate == clk_get_rate(port->baudclk))
goto exit;
if (val == CPUFREQ_PRECHANGE) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2] serial: samsung: Fixed wrong comparison for baudclk_rate
From: Russell King - ARM Linux @ 2012-05-15 12:45 UTC (permalink / raw)
To: Kyoungil Kim
Cc: linux-arm-kernel, linux-serial, linux-samsung-soc,
'Kukjin Kim', 'Jun-Ho Yoon', 'Alan Cox'
In-Reply-To: <000501cd3297$75fba910$61f2fb30$%kim@samsung.com>
On Tue, May 15, 2012 at 09:37:16PM +0900, Kyoungil Kim wrote:
> port->baudclk_rate should be compared to the rate of port->baudclk,
> because port->baudclk_rate was assigned as the rate of port->baudclk previously.
> So to check that the current baudclk rate is same as previous rate,
> the target of comparison sholud be the rate of port->baudclk.
>
> Signed-off-by: Jun-Ho, Yoon <junho78.yoon@samsung.com>
> Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
> ---
> drivers/tty/serial/samsung.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index d8b0aee..6a6a86a 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -1014,10 +1014,10 @@ static int s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
> * a disturbance in the clock-rate over the change.
> */
>
> - if (IS_ERR(port->clk))
> + if (IS_ERR(port->baudclk) || port->baudclk == NULL)
Still no. Why are you wanting to detect a NULL baud clock?
As I said, drivers have no business interpreting anything but IS_ERR(clk)
as being an error. They should not make any other assumptions.
Now that I look at this driver, it makes this mistake all over the place.
This needs to be fixed. Something like the below should do it. Please
check.
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d8b0aee..6a952b1 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -529,7 +529,7 @@ static void s3c24xx_serial_pm(struct uart_port *port, unsigned int level,
switch (level) {
case 3:
- if (!IS_ERR(ourport->baudclk) && ourport->baudclk != NULL)
+ if (!IS_ERR(ourport->baudclk))
clk_disable(ourport->baudclk);
clk_disable(ourport->clk);
@@ -538,7 +538,7 @@ static void s3c24xx_serial_pm(struct uart_port *port, unsigned int level,
case 0:
clk_enable(ourport->clk);
- if (!IS_ERR(ourport->baudclk) && ourport->baudclk != NULL)
+ if (!IS_ERR(ourport->baudclk))
clk_enable(ourport->baudclk);
break;
@@ -713,9 +713,9 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
if (ourport->baudclk != clk) {
s3c24xx_serial_setsource(port, clk_sel);
- if (ourport->baudclk != NULL && !IS_ERR(ourport->baudclk)) {
+ if (!IS_ERR(ourport->baudclk)) {
clk_disable(ourport->baudclk);
- ourport->baudclk = NULL;
+ ourport->baudclk = ERR_PTR(-EINVAL);
}
clk_enable(clk);
@@ -1160,6 +1160,9 @@ static ssize_t s3c24xx_serial_show_clksrc(struct device *dev,
struct uart_port *port = s3c24xx_dev_to_port(dev);
struct s3c24xx_uart_port *ourport = to_ourport(port);
+ if (IS_ERR(ourport->baudclk))
+ return -EINVAL;
+
return snprintf(buf, PAGE_SIZE, "* %s\n", ourport->baudclk->name);
}
@@ -1200,6 +1203,7 @@ static int s3c24xx_serial_probe(struct platform_device *pdev)
return -ENODEV;
}
+ ourport->baudclk = ERR_PTR(-EINVAL);
ourport->info = ourport->drv_data->info;
ourport->cfg = (pdev->dev.platform_data) ?
(struct s3c2410_uartcfg *)pdev->dev.platform_data :
^ permalink raw reply related
* Re: [PATCH v2] serial: 8250: Add cpufreq support
From: Alan Cox @ 2012-05-15 13:44 UTC (permalink / raw)
To: Shankarmurthy, Akshay
Cc: linux-serial@vger.kernel.org, gregkh@linuxfoundation.org,
paul.gortmaker@windriver.com, jamie@jamieiles.com,
swarren@nvidia.com, dianders@chromium.org,
davinci-linux-open-source@linux.davincidsp.com
In-Reply-To: <6F6B80BD2E18844D97BB4B51FE3705C83E935014@DBDE01.ent.ti.com>
> > Changes are as per these discussions
> > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg22841.html
> >
>
> Please let me know if there are any comments on this patch?
It never got here for some reason. Last I have in my mailbox is the
discussion of the 17th April ?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox