From patchwork Mon Jul 21 09:35:28 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tony Lindgren X-Patchwork-Id: 372014 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id C1014140192 for ; Mon, 21 Jul 2014 19:39:36 +1000 (EST) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1X9A25-0006I8-IY; Mon, 21 Jul 2014 09:37:21 +0000 Received: from mho-03-ewr.mailhop.org ([204.13.248.66] helo=mho-01-ewr.mailhop.org) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1X9A20-00066h-T1 for linux-arm-kernel@lists.infradead.org; Mon, 21 Jul 2014 09:37:17 +0000 Received: from 99-127-230-128.lightspeed.sntcca.sbcglobal.net ([99.127.230.128] helo=atomide.com) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X9A1d-000KKk-UB; Mon, 21 Jul 2014 09:36:54 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 99.127.230.128 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/1O4B3aisPFHbv0RadE7wg Date: Mon, 21 Jul 2014 02:35:28 -0700 From: Tony Lindgren To: Sebastian Andrzej Siewior Subject: Re: [PATCH 5/5] tty: serial: Add 8250-core based omap driver Message-ID: <20140721093528.GS18374@atomide.com> References: <1405521903-5877-1-git-send-email-bigeasy@linutronix.de> <1405521903-5877-6-git-send-email-bigeasy@linutronix.de> <20140717070859.GD18374@atomide.com> <20140717074219.GA29193@linutronix.de> <20140717081232.GH18374@atomide.com> <53C7A01C.50107@linutronix.de> <20140718062456.GJ18374@atomide.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140718062456.GJ18374@atomide.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140721_023717_038164_50FED48C X-CRM114-Status: GOOD ( 22.39 ) X-Spam-Score: -0.0 (/) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [204.13.248.66 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [204.13.248.66 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Felipe Balbi , linux-serial@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org * Tony Lindgren [140717 23:28]: > * Sebastian Andrzej Siewior [140717 03:09]: > > On 07/17/2014 10:12 AM, Tony Lindgren wrote: > > > Hmm it could be that it works for a while because the clocks are on > > > from the bootloader and pm_runtime calls won't do anything. This > > > could happen if the interconnect data based on the ti,hwmods entry > > > is not getting matched to the new driver. This gets initialized when > > > the device entry gets created in omap_device_build_from_dt(). > > > > > > Or maybe something now affects the clock aliases? It seems that we > > > are still missing the clocks entries in the .dtsi files, see the > > > mappings with $ git grep uart drivers/clk/ti/ > > > > I've been looking for something completely different while I noticed > > this: > > > > in drivers/tty/serial/omap-serial.c > > | static struct platform_driver serial_omap_driver = { > > | .driver = { > > | .name = DRIVER_NAME, > > | }, > > | }; > > | > > > > and DRIVER_NAME should come from include/linux/platform_data/serial-omap.h > > Looking further, I've found arch/arm/mach-omap2/serial.c: > > | void __init omap_serial_init_port(struct omap_board_data *bdata, > > | struct omap_uart_port_info *info) > > | { > > | char *name > > … > > | name = DRIVER_NAME; > > … > > | pdev = omap_device_build(name, uart->num, oh, pdata, pdata_size); > > … > > | > > > > Would this explain it? > > That would explain it for legacy booting, but not for device tree > based booting. I can try to debug it further on Monday. Looks like the following is needed to avoid the error, no idea why.. But this is what we also do in omap-serial.c. It may be needed in other places too? Also, no luck yet on runtime PM. If the console is enabled omap won't idle, and if no serial console is enabled, it just hangs. Will try to debug this part further, it may be also related to the above. Regards, Tony --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -2066,8 +2066,8 @@ int serial8250_do_startup(struct uart_port *port) /* * Clear the interrupt registers. */ - serial_port_in(port, UART_LSR); - serial_port_in(port, UART_RX); + if (serial_port_in(port, UART_LSR) & UART_LSR_DR) + serial_port_in(port, UART_RX); serial_port_in(port, UART_IIR); serial_port_in(port, UART_MSR); @@ -2228,8 +2228,8 @@ dont_test_tx_en: * saved flags to avoid getting false values from polling * routines or the previous session. */ - serial_port_in(port, UART_LSR); - serial_port_in(port, UART_RX); + if (serial_port_in(port, UART_LSR) & UART_LSR_DR) + serial_port_in(port, UART_RX); serial_port_in(port, UART_IIR); serial_port_in(port, UART_MSR); up->lsr_saved_flags = 0;