diff mbox

[v3,03/23] serial: omap: don't access the platform_device

Message ID 1345717983-18179-4-git-send-email-balbi@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Felipe Balbi Aug. 23, 2012, 10:32 a.m. UTC
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: Shubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/serial.c                  |  15 ++--
 arch/arm/plat-omap/include/plat/omap-serial.h |  10 +--
 drivers/tty/serial/omap-serial.c              | 124 +++++++++++++-------------
 3 files changed, 76 insertions(+), 73 deletions(-)

Comments

Tony Lindgren Aug. 24, 2012, 7:07 p.m. UTC | #1
* Felipe Balbi <balbi@ti.com> [120823 03:37]:
> 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: Shubhrajyoti D <shubhrajyoti@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>

Acked-by: Tony Lindgren <tony@atomide.com>
Greg KH Sept. 5, 2012, 8:27 p.m. UTC | #2
On Thu, Aug 23, 2012 at 01:32:43PM +0300, Felipe Balbi wrote:
> 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: Shubhrajyoti D <shubhrajyoti@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> Acked-by: Tony Lindgren <tony@atomide.com>

This series fails when applying to my tty-next branch at this patch :(

Care to refresh it, and resend it, with Tony's acks added, so I can
apply it?  Note, I've already applied the first two.

thanks,

greg k-h
Felipe Balbi Sept. 6, 2012, 12:29 p.m. UTC | #3
On Wed, Sep 05, 2012 at 01:27:21PM -0700, Greg KH wrote:
> On Thu, Aug 23, 2012 at 01:32:43PM +0300, Felipe Balbi wrote:
> > 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: Shubhrajyoti D <shubhrajyoti@ti.com>
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> This series fails when applying to my tty-next branch at this patch :(
> 
> Care to refresh it, and resend it, with Tony's acks added, so I can
> apply it?  Note, I've already applied the first two.

Sure, will do and reply to this mail with the new series. Thanks
Felipe Balbi Sept. 6, 2012, 12:45 p.m. UTC | #4
Hi guys,

here's v4 of the omap uart patchset. No changes other than a rebase on top of
Greg's tty-next branch and Tony's Acked-by being added to a couple patches

Note: I'm resending the series with Vikram's Software Flow Control fix anyway
as it can just be ignored if it's decided it needs to go into this merge
window.

Changes since v3:
	. Rebased on top of Greg's tty-next branch
	. Added Tony's Acked-by

Changes since v2:
        . Added a bunch of new patches
        . Fixed a problem where we would always return IRQ_NONE even though we
                handled IRQ

Changes since v1:
        . improved commit log on patch 9/13 (formerly 10/13)
        . removed patch 2/13
        . added a new patch switching from spin_lock_irqsave() to spin_lock and
                spin_unlock_irqrestore to spin_unlock

Felipe Balbi (18):
  serial: omap: don't access the platform_device
  serial: omap: drop DMA support
  serial: add OMAP-specific defines
  serial: omap: simplify IRQ handling
  serial: omap: refactor receive_chars() into rdi/rlsi handlers
  serial: omap: move THRE check to transmit_chars()
  serial: omap: stick to put_autosuspend
  serial: omap: set dev->drvdata before enabling pm_runtime
  serial: omap: drop unnecessary check from remove
  serial: omap: make sure to suspend device before remove
  serial: omap: don't save IRQ flags on hardirq
  serial: omap: optimization with section annotations
  serial: omap: drop "inline" from IRQ handler prototype
  serial: omap: implement set_wake
  serial: omap: make sure to put() on poll_get_char
  serial: omap: remove unnecessary header and add a missing one
  serial: omap: move uart_omap_port definition to C file
  serial: omap: enable RX and TX FIFO usage

Ruchika Kharwar (2):
  serial: omap: fix sequence of pm_runtime_* calls.
  serial: omap: unlock the port lock

Vikram Pandita (1):
  serial: omap: fix software flow control

 arch/arm/mach-omap2/serial.c                  |  15 +-
 arch/arm/plat-omap/include/plat/omap-serial.h |  49 +-
 drivers/tty/serial/omap-serial.c              | 740 +++++++++-----------------
 include/linux/serial_reg.h                    |   4 +
 4 files changed, 282 insertions(+), 526 deletions(-)
Greg Kroah-Hartman Sept. 6, 2012, 4:18 p.m. UTC | #5
On Thu, Sep 06, 2012 at 03:45:19PM +0300, Felipe Balbi wrote:
> Hi guys,
> 
> here's v4 of the omap uart patchset. No changes other than a rebase on top of
> Greg's tty-next branch and Tony's Acked-by being added to a couple patches
> 
> Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> as it can just be ignored if it's decided it needs to go into this merge
> window.
> 
> Changes since v3:
> 	. Rebased on top of Greg's tty-next branch
> 	. Added Tony's Acked-by

Thanks for rebasing, all now applied.

greg k-h
Felipe Balbi Sept. 6, 2012, 5:25 p.m. UTC | #6
On Thu, Sep 06, 2012 at 09:18:35AM -0700, Greg KH wrote:
> On Thu, Sep 06, 2012 at 03:45:19PM +0300, Felipe Balbi wrote:
> > Hi guys,
> > 
> > here's v4 of the omap uart patchset. No changes other than a rebase on top of
> > Greg's tty-next branch and Tony's Acked-by being added to a couple patches
> > 
> > Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> > as it can just be ignored if it's decided it needs to go into this merge
> > window.
> > 
> > Changes since v3:
> > 	. Rebased on top of Greg's tty-next branch
> > 	. Added Tony's Acked-by
> 
> Thanks for rebasing, all now applied.

thank you, actually ;-)
Paul Walmsley Sept. 6, 2012, 9:37 p.m. UTC | #7
Hi

On Thu, 6 Sep 2012, Felipe Balbi wrote:

> Hi guys,
> 
> here's v4 of the omap uart patchset. No changes other than a rebase on top of
> Greg's tty-next branch and Tony's Acked-by being added to a couple patches
> 
> Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> as it can just be ignored if it's decided it needs to go into this merge
> window.

Was curious to know if these have been PM-tested, and if so, under what 
configurations?


- Paul
Kevin Hilman Sept. 6, 2012, 10:44 p.m. UTC | #8
Felipe Balbi <balbi@ti.com> writes:

> Hi guys,
>
> here's v4 of the omap uart patchset. No changes other than a rebase on top of
> Greg's tty-next branch and Tony's Acked-by being added to a couple patches
>
> Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> as it can just be ignored if it's decided it needs to go into this merge
> window.

Sorry to be late to the party... just getting back from some time off.

I'm assuming that this was not tested with PM, so decided I better do it
myself seeing that Greg is has already merge it.  To test, I merged
Greg's tty-next branch with v3.6-rc4 and did some PM testing.

The bad news is that it doesn't even compile (see reply to [PATCH v4
20/21]).  

Also, there is a big WARNING on boot[1], which seems to be triggered by
a new check added for v3.6-rc3[2].  This appears to be introduced by
$SUBJECT series, because I don't see it on vanilla v3.6-rc4.

The good news is that after hacking to fix up the compile problems,
basic PM testing seems to be fine: idle to retention and off as well as
suspend to retention and off work fine on 3430/n900, 3530/Overo,
3730/OveroSTORM, 3730/Beagle-xM.

Kevin


[1]
[    8.745666] WARNING: at /work/kernel/omap/pm/drivers/tty/tty_io.c:1420 tty_init_dev+0x14c/0x17c()
[    8.755218] tty_init_dev: ttyO driver does not set tty->port. This will crash the kernel later. Fix the driver!
[    8.765991] Modules linked in:
[    8.769287] [<c0013d90>] (unwind_backtrace+0x0/0xf0) from [<c0036eec>] (warn_slowpath_common+0x4c/0x64)
[    8.779327] [<c0036eec>] (warn_slowpath_common+0x4c/0x64) from [<c0036f98>] (warn_slowpath_fmt+0x30/0x40)
[    8.789550] [<c0036f98>] (warn_slowpath_fmt+0x30/0x40) from [<c02c626c>] (tty_init_dev+0x14c/0x17c)
[    8.799224] [<c02c626c>] (tty_init_dev+0x14c/0x17c) from [<c02c68a4>] (tty_open+0x11c/0x52c)
[    8.808258] [<c02c68a4>] (tty_open+0x11c/0x52c) from [<c00f86ac>] (chrdev_open+0x90/0x15c)
[    8.817108] [<c00f86ac>] (chrdev_open+0x90/0x15c) from [<c00f2b74>] (do_dentry_open+0x1e8/0x270)
[    8.826507] [<c00f2b74>] (do_dentry_open+0x1e8/0x270) from [<c00f2c30>] (finish_open+0x34/0x4c)
[    8.835784] [<c00f2c30>] (finish_open+0x34/0x4c) from [<c0102028>] (do_last.isra.21+0x5b0/0xbbc)
[    8.845184] [<c0102028>] (do_last.isra.21+0x5b0/0xbbc) from [<c01026dc>] (path_openat+0xa8/0x44c)
[    8.854675] [<c01026dc>] (path_openat+0xa8/0x44c) from [<c0102d34>] (do_filp_open+0x2c/0x80)
[    8.863708] [<c0102d34>] (do_filp_open+0x2c/0x80) from [<c00f3b6c>] (do_sys_open+0xe8/0x184)
[    8.872711] [<c00f3b6c>] (do_sys_open+0xe8/0x184) from [<c000db20>] (ret_fast_syscall+0x0/0x3c)
[    8.882019] ---[ end trace e9bf408c37051346 ]---

[2]
commit 5d4121c04b3577e37e389b3553d442f44bb346d7
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Aug 17 14:27:52 2012 +0200

    TTY: check if tty->port is assigned
    
    And if not, complain loudly. None in-kernel module should trigger
    that, but let us find out for sure. On the other hand, all the
    out-of-tree modules will hit that. Give them some time (maybe one
    release) to catch up.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe Balbi Sept. 7, 2012, 5:49 a.m. UTC | #9
Hi,

On Thu, Sep 06, 2012 at 03:44:13PM -0700, Kevin Hilman wrote:
> Felipe Balbi <balbi@ti.com> writes:
> 
> > Hi guys,
> >
> > here's v4 of the omap uart patchset. No changes other than a rebase on top of
> > Greg's tty-next branch and Tony's Acked-by being added to a couple patches
> >
> > Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> > as it can just be ignored if it's decided it needs to go into this merge
> > window.
> 
> Sorry to be late to the party... just getting back from some time off.
> 
> I'm assuming that this was not tested with PM, so decided I better do it

you assumed wrong. See the previous versions of the series and you'll
see I mention all the basic pm testing I did.

> myself seeing that Greg is has already merge it.  To test, I merged
> Greg's tty-next branch with v3.6-rc4 and did some PM testing.
> 
> The bad news is that it doesn't even compile (see reply to [PATCH v4
> 20/21]).  

yeah, that was an automerge issue when rebasing on greg's tty-next
branch, plus me assuming omap serial was already enabled on my .config
and not checking the compile output. Sent a patch now.

> Also, there is a big WARNING on boot[1], which seems to be triggered by
> a new check added for v3.6-rc3[2].  This appears to be introduced by
> $SUBJECT series, because I don't see it on vanilla v3.6-rc4.
> 
> The good news is that after hacking to fix up the compile problems,
> basic PM testing seems to be fine: idle to retention and off as well as
> suspend to retention and off work fine on 3430/n900, 3530/Overo,
> 3730/OveroSTORM, 3730/Beagle-xM.
> 
> Kevin
> 
> 
> [1]
> [    8.745666] WARNING: at /work/kernel/omap/pm/drivers/tty/tty_io.c:1420 tty_init_dev+0x14c/0x17c()
> [    8.755218] tty_init_dev: ttyO driver does not set tty->port. This will crash the kernel later. Fix the driver!
> [    8.765991] Modules linked in:
> [    8.769287] [<c0013d90>] (unwind_backtrace+0x0/0xf0) from [<c0036eec>] (warn_slowpath_common+0x4c/0x64)
> [    8.779327] [<c0036eec>] (warn_slowpath_common+0x4c/0x64) from [<c0036f98>] (warn_slowpath_fmt+0x30/0x40)
> [    8.789550] [<c0036f98>] (warn_slowpath_fmt+0x30/0x40) from [<c02c626c>] (tty_init_dev+0x14c/0x17c)
> [    8.799224] [<c02c626c>] (tty_init_dev+0x14c/0x17c) from [<c02c68a4>] (tty_open+0x11c/0x52c)
> [    8.808258] [<c02c68a4>] (tty_open+0x11c/0x52c) from [<c00f86ac>] (chrdev_open+0x90/0x15c)
> [    8.817108] [<c00f86ac>] (chrdev_open+0x90/0x15c) from [<c00f2b74>] (do_dentry_open+0x1e8/0x270)
> [    8.826507] [<c00f2b74>] (do_dentry_open+0x1e8/0x270) from [<c00f2c30>] (finish_open+0x34/0x4c)
> [    8.835784] [<c00f2c30>] (finish_open+0x34/0x4c) from [<c0102028>] (do_last.isra.21+0x5b0/0xbbc)
> [    8.845184] [<c0102028>] (do_last.isra.21+0x5b0/0xbbc) from [<c01026dc>] (path_openat+0xa8/0x44c)
> [    8.854675] [<c01026dc>] (path_openat+0xa8/0x44c) from [<c0102d34>] (do_filp_open+0x2c/0x80)
> [    8.863708] [<c0102d34>] (do_filp_open+0x2c/0x80) from [<c00f3b6c>] (do_sys_open+0xe8/0x184)
> [    8.872711] [<c00f3b6c>] (do_sys_open+0xe8/0x184) from [<c000db20>] (ret_fast_syscall+0x0/0x3c)
> [    8.882019] ---[ end trace e9bf408c37051346 ]---

This doesn't seem to be caused by $SUBJECT at all. See that we are
calling uart_add_one_port() which will call tty_port_register_device()
which, in turn, will call tty_port_link_device() and that will set
driver->ports[index] correctly.

Have you checked if this doesn't happen without my series before waving
your blame hammer ? FWIW, that part of the code wasn't change by
$SUBJECT at all.
Kevin Hilman Sept. 7, 2012, 8:53 p.m. UTC | #10
Felipe Balbi <balbi@ti.com> writes:

> Hi,
>
> On Thu, Sep 06, 2012 at 03:44:13PM -0700, Kevin Hilman wrote:
>> Felipe Balbi <balbi@ti.com> writes:
>> 
>> > Hi guys,
>> >
>> > here's v4 of the omap uart patchset. No changes other than a rebase on top of
>> > Greg's tty-next branch and Tony's Acked-by being added to a couple patches
>> >
>> > Note: I'm resending the series with Vikram's Software Flow Control fix anyway
>> > as it can just be ignored if it's decided it needs to go into this merge
>> > window.
>> 
>> Sorry to be late to the party... just getting back from some time off.
>> 
>> I'm assuming that this was not tested with PM, so decided I better do it
>
> you assumed wrong. See the previous versions of the series and you'll
> see I mention all the basic pm testing I did.

My apologies for not reading the previous versions.  I don't think it's
unusual that a reviewer should expect everything he to know about a
series (including how it was tested) is in the cover letter or in the
changelogs of the latest series.  I don't expect to have to look through
all the previous versions for this kind of info.  Since I wasn't around
to review/test the earlier versions, I just looked at the latest (v4)
and didn't see any mention of testing of any sort in the cover letter.

Looking back at the previous cover letters, I don't see any description
of the PM testing either.  I only see it was tested on pandaboard.
Since mainline doesn't have full PM support for OMAP4, testing on panda
doesn't really test UART PM at all.

Could you please point me to the descriptions in earlier mails of how
you did PM testing, and on what platforms?

In addition, IMO, if this was only tested on Panda (as suggested by
earlier cover letters), it really should not have been merged until it
got some broader testing.

>> myself seeing that Greg is has already merge it.  To test, I merged
>> Greg's tty-next branch with v3.6-rc4 and did some PM testing.
>> 
>> The bad news is that it doesn't even compile (see reply to [PATCH v4
>> 20/21]).  
>
> yeah, that was an automerge issue when rebasing on greg's tty-next
> branch, plus me assuming omap serial was already enabled on my .config
> and not checking the compile output. Sent a patch now.

As I reported in my reply to [PATCH v4 20/21], that patch also had
another problem where it introduced a new (but unused) field.  Maybe
another rebase problem?  I see the same problem in v3 and v4.

>> Also, there is a big WARNING on boot[1], which seems to be triggered by
>> a new check added for v3.6-rc3[2].  This appears to be introduced by
>> $SUBJECT series, because I don't see it on vanilla v3.6-rc4.

[...]

> This doesn't seem to be caused by $SUBJECT at all. See that we are
> calling uart_add_one_port() which will call tty_port_register_device()
> which, in turn, will call tty_port_link_device() and that will set
> driver->ports[index] correctly.
>
> Have you checked if this doesn't happen without my series before waving
> your blame hammer ? FWIW, that part of the code wasn't change by
> $SUBJECT at all.

Whoa.  This was only test report.  No need to get personal.  All I said
is that it "seemed" to introduced by $SUBJECT series.  Hardly waiving
"blame hammer."

And yes, I did check without your series.  As I reported above, the
warning didn't exist with v3.6-rc4, and it did with yesterday's tty-next
branch.  The WARNING pointed a finger at ttyO (omap-serial) so I assumed
it was in $SUBJECT series.

Testing with todays tty-next, the problem is gone.  The patch
'tty_register_device_attr updated for tty-next'[1] seems to have made
the problem go away.  So it's now clear that it wasn't introduced by
$SUBJECT series.   My bad.

Yesterday, it wasn't that obvious, so I made an assumption in order to
report a problem uncovered in my testing in the hopes that it would be
helpful to you in fixing a potential problem. My assumption was wrong, I
was wrong.  I'm wrong a lot, and I'm OK with that. The bug was
elsewhere, and is already fixed.

My apologies if it seemed like I was blaming you.

Kevin

[1] 
Author: Tomas Hlavacek <tmshlvck@gmail.com>  2012-09-06 14:17:47
Committer: Greg Kroah-Hartman <gregkh@linuxfoundation.org>  2012-09-06 14:40:18
Parent: 6915c0e487c822e2436683e14302c0b8a6155cc7 (tty: uartclk value from serial_core exposed to sysfs)
Child:  e36851d0fa94b0f7802b3cc80406dbd3ef4f2f16 (serial: omap: fix compile breakage)
Branch: tmp/uart-test-2
Follows: v3.6-rc3
Precedes: 

    tty_register_device_attr updated for tty-next
    
    Added tty_device_create_release() and bound to dev->release in
    tty_register_device_attr().
    Added tty_port_register_device_attr() and used in uart_add_one_port()
    instead of tty_register_device_attr().
    
    Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe Balbi Sept. 8, 2012, 7:04 p.m. UTC | #11
Hi,

On Fri, Sep 07, 2012 at 01:53:11PM -0700, Kevin Hilman wrote:
> Felipe Balbi <balbi@ti.com> writes:
> 
> > Hi,
> >
> > On Thu, Sep 06, 2012 at 03:44:13PM -0700, Kevin Hilman wrote:
> >> Felipe Balbi <balbi@ti.com> writes:
> >> 
> >> > Hi guys,
> >> >
> >> > here's v4 of the omap uart patchset. No changes other than a rebase on top of
> >> > Greg's tty-next branch and Tony's Acked-by being added to a couple patches
> >> >
> >> > Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> >> > as it can just be ignored if it's decided it needs to go into this merge
> >> > window.
> >> 
> >> Sorry to be late to the party... just getting back from some time off.
> >> 
> >> I'm assuming that this was not tested with PM, so decided I better do it
> >
> > you assumed wrong. See the previous versions of the series and you'll
> > see I mention all the basic pm testing I did.
> 
> My apologies for not reading the previous versions.  I don't think it's
> unusual that a reviewer should expect everything he to know about a
> series (including how it was tested) is in the cover letter or in the
> changelogs of the latest series.  I don't expect to have to look through

you've got a point there. My bad, should've kept series history on all
revisions.

> all the previous versions for this kind of info.  Since I wasn't around
> to review/test the earlier versions, I just looked at the latest (v4)
> and didn't see any mention of testing of any sort in the cover letter.

Well, fair enough. Maybe I wasn't too verbose, but here's what I did on
panda:

. check that console still works
. check that IRQs increase as I type on console
. check that pm_runtime suspend callback is called after 1 second of
	inactivity (with printk)
. check that device resumes properly when I type on console again
. enable UART wakeup (through sysfs) and 'echo mem > /sys/power/state'
	then check that I can wakeup from suspend and check that all
	powerdomains actually reached low power state

> Looking back at the previous cover letters, I don't see any description
> of the PM testing either.  I only see it was tested on pandaboard.

Yeah, initially I wasn't testing PM because UART wakeup was known to be
broken, but then I decided to test and sent it as a reply to cover
letter v2, then I forgot to keep the history on v3 and v4. My bad.

> Since mainline doesn't have full PM support for OMAP4, testing on panda
> doesn't really test UART PM at all.

Fair enough. What's missing for omap4 panda ? I could reach suspend2ram
with echo mem > /sys/power/state and wakeup from it.

> Could you please point me to the descriptions in earlier mails of how
> you did PM testing, and on what platforms?

Though not on a cover letter, this is how I was testing from v2 and
onwards:

http://marc.info/?l=linux-omap&m=134555434407362&w=2

> In addition, IMO, if this was only tested on Panda (as suggested by
> earlier cover letters), it really should not have been merged until it
> got some broader testing.

Shubhro's got his Tested-by tag. I believe he tested on beagleboard and
omap4sdp. Shubhro, can you confirm which platforms you tested the UART
patches ? cheers

> >> myself seeing that Greg is has already merge it.  To test, I merged
> >> Greg's tty-next branch with v3.6-rc4 and did some PM testing.
> >> 
> >> The bad news is that it doesn't even compile (see reply to [PATCH v4
> >> 20/21]).  
> >
> > yeah, that was an automerge issue when rebasing on greg's tty-next
> > branch, plus me assuming omap serial was already enabled on my .config
> > and not checking the compile output. Sent a patch now.
> 
> As I reported in my reply to [PATCH v4 20/21], that patch also had
> another problem where it introduced a new (but unused) field.  Maybe
> another rebase problem?  I see the same problem in v3 and v4.

I'll check it out and make sure to delete any such unused fields. Thanks

> >> Also, there is a big WARNING on boot[1], which seems to be triggered by
> >> a new check added for v3.6-rc3[2].  This appears to be introduced by
> >> $SUBJECT series, because I don't see it on vanilla v3.6-rc4.
> 
> [...]
> 
> > This doesn't seem to be caused by $SUBJECT at all. See that we are
> > calling uart_add_one_port() which will call tty_port_register_device()
> > which, in turn, will call tty_port_link_device() and that will set
> > driver->ports[index] correctly.
> >
> > Have you checked if this doesn't happen without my series before waving
> > your blame hammer ? FWIW, that part of the code wasn't change by
> > $SUBJECT at all.
> 
> Whoa.  This was only test report.  No need to get personal.  All I said
> is that it "seemed" to introduced by $SUBJECT series.  Hardly waiving
> "blame hammer."

fair enough.

> And yes, I did check without your series.  As I reported above, the

What about v3.6-rc4 + the patch which added the warning ? :-)

> warning didn't exist with v3.6-rc4, and it did with yesterday's tty-next
> branch.  The WARNING pointed a finger at ttyO (omap-serial) so I assumed
> it was in $SUBJECT series.
> 
> Testing with todays tty-next, the problem is gone.  The patch
> 'tty_register_device_attr updated for tty-next'[1] seems to have made
> the problem go away.  So it's now clear that it wasn't introduced by
> $SUBJECT series.   My bad.

Thankfully...

> Yesterday, it wasn't that obvious, so I made an assumption in order to
> report a problem uncovered in my testing in the hopes that it would be
> helpful to you in fixing a potential problem. My assumption was wrong, I
> was wrong.  I'm wrong a lot, and I'm OK with that. The bug was
> elsewhere, and is already fixed.
>
> My apologies if it seemed like I was blaming you.

I'm the one who owes you an apology for misunderstanding your bug
report. I'm sorry.
Shubhrajyoti Datta Sept. 11, 2012, 11:31 a.m. UTC | #12
On Sunday 09 September 2012 12:34 AM, Felipe Balbi wrote:
>> In addition, IMO, if this was only tested on Panda (as suggested by
>> > earlier cover letters), it really should not have been merged until it
>> > got some broader testing.
> Shubhro's got his Tested-by tag. I believe he tested on beagleboard and
> omap4sdp. Shubhro, can you confirm which platforms you tested the UART
> patches ? cheers
Felipe I had boot tested on omap3sdp and onap4 sdp and did pm testing
on both with omap3 hitting off.
Felipe Balbi Sept. 11, 2012, 11:54 a.m. UTC | #13
On Tue, Sep 11, 2012 at 05:01:06PM +0530, Shubhrajyoti wrote:
> On Sunday 09 September 2012 12:34 AM, Felipe Balbi wrote:
> >> In addition, IMO, if this was only tested on Panda (as suggested by
> >> > earlier cover letters), it really should not have been merged until it
> >> > got some broader testing.
> > Shubhro's got his Tested-by tag. I believe he tested on beagleboard and
> > omap4sdp. Shubhro, can you confirm which platforms you tested the UART
> > patches ? cheers
> Felipe I had boot tested on omap3sdp and onap4 sdp and did pm testing
> on both with omap3 hitting off.

Thanks ;-)
Paul Walmsley Sept. 11, 2012, 10:02 p.m. UTC | #14
Hi Felipe

Just tested these OMAP serial changes at commit 
e36851d0fa94b0f7802b3cc80406dbd3ef4f2f16 ("serial: omap: fix compile 
breakage").  There's good news and bad news...

The good news is that after applying this series, the 'OMAP4 UART garbage 
on long transmit buffers when PM is enabled' bug:

http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/pm/4430es2panda/4430es2panda_log.txt

... goes away.  (Unclear if it's because the underlying bug was fixed, or 
if unrelated changes are masking it.)  Not sure what caused the problem to 
go away exactly, but it's one of the changes between d37c6ceb and bf63a08.  
So that's good!

The bad news is that N800 no longer boots -- or the UART dies during 
serial init:

http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt

The problem doesn't seem to affect the 2430SDP.

Could you put together a patch to fix N800?


regards

- Paul
Felipe Balbi Sept. 12, 2012, 6:23 a.m. UTC | #15
Hi,

On Tue, Sep 11, 2012 at 10:02:48PM +0000, Paul Walmsley wrote:
> 
> Hi Felipe
> 
> Just tested these OMAP serial changes at commit 
> e36851d0fa94b0f7802b3cc80406dbd3ef4f2f16 ("serial: omap: fix compile 
> breakage").  There's good news and bad news...
> 
> The good news is that after applying this series, the 'OMAP4 UART garbage 
> on long transmit buffers when PM is enabled' bug:
> 
> http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/pm/4430es2panda/4430es2panda_log.txt
> 
> ... goes away.  (Unclear if it's because the underlying bug was fixed, or 
> if unrelated changes are masking it.)  Not sure what caused the problem to 
> go away exactly, but it's one of the changes between d37c6ceb and bf63a08.  
> So that's good!

I'd point the finger at sticking to put_autosuspend() as that would give
HW enough time to actually unload all bytes from its FIFO through the
UART lines. can you check if forcing the autosuspend_delay to -1
triggers the issue again ? If it does, it's some help from autosuspend,
which would mean we still have the problem and needs to be properly
fixed.

> The bad news is that N800 no longer boots -- or the UART dies during 
> serial init:
> 
> http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
> 
> The problem doesn't seem to affect the 2430SDP.
> 
> Could you put together a patch to fix N800?

I'll see what I can do. BTW, is that log with DEBUG_LL enabled ?

cheers
Paul Walmsley Sept. 12, 2012, 8:25 p.m. UTC | #16
Hi

On Wed, 12 Sep 2012, Felipe Balbi wrote:

> On Tue, Sep 11, 2012 at 10:02:48PM +0000, Paul Walmsley wrote:
> 
> > The bad news is that N800 no longer boots -- or the UART dies during 
> > serial init:
> > 
> > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
> > 
> > The problem doesn't seem to affect the 2430SDP.
> > 
> > Could you put together a patch to fix N800?
> 
> I'll see what I can do. BTW, is that log with DEBUG_LL enabled ?

Yes.  Here's the .config that was used on N800:

http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/build/n800_b_testconfig/Kconfig


- Paul
Felipe Balbi Sept. 13, 2012, 5:01 a.m. UTC | #17
On Wed, Sep 12, 2012 at 08:25:30PM +0000, Paul Walmsley wrote:
> Hi
> 
> On Wed, 12 Sep 2012, Felipe Balbi wrote:
> 
> > On Tue, Sep 11, 2012 at 10:02:48PM +0000, Paul Walmsley wrote:
> > 
> > > The bad news is that N800 no longer boots -- or the UART dies during 
> > > serial init:
> > > 
> > > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
> > > 
> > > The problem doesn't seem to affect the 2430SDP.
> > > 
> > > Could you put together a patch to fix N800?
> > 
> > I'll see what I can do. BTW, is that log with DEBUG_LL enabled ?
> 
> Yes.  Here's the .config that was used on N800:
> 
> http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/build/n800_b_testconfig/Kconfig

Thanks :-)
Paul Walmsley Sept. 16, 2012, 1:22 a.m. UTC | #18
On Wed, 12 Sep 2012, Felipe Balbi wrote:

> On Tue, Sep 11, 2012 at 10:02:48PM +0000, Paul Walmsley wrote:
> 
> > The bad news is that N800 no longer boots -- or the UART dies during 
> > serial init:
> > 
> > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
> > 
> > The problem doesn't seem to affect the 2430SDP.
> > 
> > Could you put together a patch to fix N800?

Bisected this down.  It's this one that causes the problem on N800:

commit 93220dcc3052182e7156c09655ad1316055564b9
Author: Felipe Balbi <balbi@ti.com>
Date:   Thu Sep 6 15:45:27 2012 +0300

    serial: omap: set dev->drvdata before enabling pm_runtime
    
    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: Shubhrajyoti D <shubhrajyoti@ti.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

- Paul
Felipe Balbi Sept. 16, 2012, 6:36 p.m. UTC | #19
Hi,

On Sun, Sep 16, 2012 at 01:22:01AM +0000, Paul Walmsley wrote:
> On Wed, 12 Sep 2012, Felipe Balbi wrote:
> 
> > On Tue, Sep 11, 2012 at 10:02:48PM +0000, Paul Walmsley wrote:
> > 
> > > The bad news is that N800 no longer boots -- or the UART dies during 
> > > serial init:
> > > 
> > > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
> > > 
> > > The problem doesn't seem to affect the 2430SDP.
> > > 
> > > Could you put together a patch to fix N800?
> 
> Bisected this down.  It's this one that causes the problem on N800:
> 
> commit 93220dcc3052182e7156c09655ad1316055564b9
> Author: Felipe Balbi <balbi@ti.com>
> Date:   Thu Sep 6 15:45:27 2012 +0300
> 
>     serial: omap: set dev->drvdata before enabling pm_runtime
>     
>     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: Shubhrajyoti D <shubhrajyoti@ti.com>
>     Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>     Signed-off-by: Felipe Balbi <balbi@ti.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Interesting. That simply moves platform_set_drvdata() to a saner
location... The only way for this to cause problems is if we're trying
to restore a context which was never saved.

Is there a way to prevent runtime_resume() to be called during probe()
if I know the HW is already enabled ? Maybe with
pm_runtime_set_active() ?
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c1b93c7..8f07841 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -81,8 +81,9 @@  static struct omap_uart_port_info omap_serial_default_info[] __initdata = {
 };
 
 #ifdef CONFIG_PM
-static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
+static void omap_uart_enable_wakeup(struct device *dev, bool enable)
 {
+	struct platform_device *pdev = to_platform_device(dev);
 	struct omap_device *od = to_omap_device(pdev);
 
 	if (!od)
@@ -99,15 +100,17 @@  static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
  * in Smartidle Mode When Configured for DMA Operations.
  * WA: configure uart in force idle mode.
  */
-static void omap_uart_set_noidle(struct platform_device *pdev)
+static void omap_uart_set_noidle(struct device *dev)
 {
+	struct platform_device *pdev = to_platform_device(dev);
 	struct omap_device *od = to_omap_device(pdev);
 
 	omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_NO);
 }
 
-static void omap_uart_set_smartidle(struct platform_device *pdev)
+static void omap_uart_set_smartidle(struct device *dev)
 {
+	struct platform_device *pdev = to_platform_device(dev);
 	struct omap_device *od = to_omap_device(pdev);
 	u8 idlemode;
 
@@ -120,10 +123,10 @@  static void omap_uart_set_smartidle(struct platform_device *pdev)
 }
 
 #else
-static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
+static void omap_uart_enable_wakeup(struct device *dev, bool enable)
 {}
-static void omap_uart_set_noidle(struct platform_device *pdev) {}
-static void omap_uart_set_smartidle(struct platform_device *pdev) {}
+static void omap_uart_set_noidle(struct device *dev) {}
+static void omap_uart_set_smartidle(struct device *dev) {}
 #endif /* CONFIG_PM */
 
 #ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index f3b35d9..743ac80 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -18,7 +18,7 @@ 
 #define __OMAP_SERIAL_H__
 
 #include <linux/serial_core.h>
-#include <linux/platform_device.h>
+#include <linux/device.h>
 #include <linux/pm_qos.h>
 
 #include <plat/mux.h>
@@ -71,9 +71,9 @@  struct omap_uart_port_info {
 	unsigned int		dma_rx_poll_rate;
 
 	int (*get_context_loss_count)(struct device *);
-	void (*set_forceidle)(struct platform_device *);
-	void (*set_noidle)(struct platform_device *);
-	void (*enable_wakeup)(struct platform_device *, bool);
+	void (*set_forceidle)(struct device *);
+	void (*set_noidle)(struct device *);
+	void (*enable_wakeup)(struct device *, bool);
 };
 
 struct uart_omap_dma {
@@ -105,7 +105,7 @@  struct uart_omap_dma {
 struct uart_omap_port {
 	struct uart_port	port;
 	struct uart_omap_dma	uart_dma;
-	struct platform_device	*pdev;
+	struct device		*dev;
 
 	unsigned char		ier;
 	unsigned char		lcr;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6814a26..6ab3582 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -103,36 +103,36 @@  static inline void serial_omap_clear_fifos(struct uart_omap_port *up)
 
 static int serial_omap_get_context_loss_count(struct uart_omap_port *up)
 {
-	struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+	struct omap_uart_port_info *pdata = up->dev->platform_data;
 
 	if (!pdata->get_context_loss_count)
 		return 0;
 
-	return pdata->get_context_loss_count(&up->pdev->dev);
+	return pdata->get_context_loss_count(up->dev);
 }
 
 static void serial_omap_set_forceidle(struct uart_omap_port *up)
 {
-	struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+	struct omap_uart_port_info *pdata = up->dev->platform_data;
 
 	if (pdata->set_forceidle)
-		pdata->set_forceidle(up->pdev);
+		pdata->set_forceidle(up->dev);
 }
 
 static void serial_omap_set_noidle(struct uart_omap_port *up)
 {
-	struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+	struct omap_uart_port_info *pdata = up->dev->platform_data;
 
 	if (pdata->set_noidle)
-		pdata->set_noidle(up->pdev);
+		pdata->set_noidle(up->dev);
 }
 
 static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
 {
-	struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+	struct omap_uart_port_info *pdata = up->dev->platform_data;
 
 	if (pdata->enable_wakeup)
-		pdata->enable_wakeup(up->pdev, enable);
+		pdata->enable_wakeup(up->dev, enable);
 }
 
 /*
@@ -168,8 +168,8 @@  static void serial_omap_stop_rxdma(struct uart_omap_port *up)
 		omap_free_dma(up->uart_dma.rx_dma_channel);
 		up->uart_dma.rx_dma_channel = OMAP_UART_DMA_CH_FREE;
 		up->uart_dma.rx_dma_used = false;
-		pm_runtime_mark_last_busy(&up->pdev->dev);
-		pm_runtime_put_autosuspend(&up->pdev->dev);
+		pm_runtime_mark_last_busy(up->dev);
+		pm_runtime_put_autosuspend(up->dev);
 	}
 }
 
@@ -179,16 +179,16 @@  static void serial_omap_enable_ms(struct uart_port *port)
 
 	dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->port.line);
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	up->ier |= UART_IER_MSI;
 	serial_out(up, UART_IER, up->ier);
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 }
 
 static void serial_omap_stop_tx(struct uart_port *port)
 {
 	struct uart_omap_port *up = to_uart_omap_port(port);
-	struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+	struct omap_uart_port_info *pdata = up->dev->platform_data;
 
 	if (up->use_dma &&
 		up->uart_dma.tx_dma_channel != OMAP_UART_DMA_CH_FREE) {
@@ -201,11 +201,11 @@  static void serial_omap_stop_tx(struct uart_port *port)
 		omap_stop_dma(up->uart_dma.tx_dma_channel);
 		omap_free_dma(up->uart_dma.tx_dma_channel);
 		up->uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
-		pm_runtime_mark_last_busy(&up->pdev->dev);
-		pm_runtime_put_autosuspend(&up->pdev->dev);
+		pm_runtime_mark_last_busy(up->dev);
+		pm_runtime_put_autosuspend(up->dev);
 	}
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	if (up->ier & UART_IER_THRI) {
 		up->ier &= ~UART_IER_THRI;
 		serial_out(up, UART_IER, up->ier);
@@ -214,22 +214,22 @@  static void serial_omap_stop_tx(struct uart_port *port)
 	if (!up->use_dma && pdata)
 		serial_omap_set_forceidle(up);
 
-	pm_runtime_mark_last_busy(&up->pdev->dev);
-	pm_runtime_put_autosuspend(&up->pdev->dev);
+	pm_runtime_mark_last_busy(up->dev);
+	pm_runtime_put_autosuspend(up->dev);
 }
 
 static void serial_omap_stop_rx(struct uart_port *port)
 {
 	struct uart_omap_port *up = to_uart_omap_port(port);
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	if (up->use_dma)
 		serial_omap_stop_rxdma(up);
 	up->ier &= ~UART_IER_RLSI;
 	up->port.read_status_mask &= ~UART_LSR_DR;
 	serial_out(up, UART_IER, up->ier);
-	pm_runtime_mark_last_busy(&up->pdev->dev);
-	pm_runtime_put_autosuspend(&up->pdev->dev);
+	pm_runtime_mark_last_busy(up->dev);
+	pm_runtime_put_autosuspend(up->dev);
 }
 
 static inline void receive_chars(struct uart_omap_port *up,
@@ -347,11 +347,11 @@  static void serial_omap_start_tx(struct uart_port *port)
 	int ret = 0;
 
 	if (!up->use_dma) {
-		pm_runtime_get_sync(&up->pdev->dev);
+		pm_runtime_get_sync(up->dev);
 		serial_omap_enable_ier_thri(up);
 		serial_omap_set_noidle(up);
-		pm_runtime_mark_last_busy(&up->pdev->dev);
-		pm_runtime_put_autosuspend(&up->pdev->dev);
+		pm_runtime_mark_last_busy(up->dev);
+		pm_runtime_put_autosuspend(up->dev);
 		return;
 	}
 
@@ -361,7 +361,7 @@  static void serial_omap_start_tx(struct uart_port *port)
 	xmit = &up->port.state->xmit;
 
 	if (up->uart_dma.tx_dma_channel == OMAP_UART_DMA_CH_FREE) {
-		pm_runtime_get_sync(&up->pdev->dev);
+		pm_runtime_get_sync(up->dev);
 		ret = omap_request_dma(up->uart_dma.uart_dma_tx,
 				"UART Tx DMA",
 				(void *)uart_tx_dma_callback, up,
@@ -444,11 +444,11 @@  static inline irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	unsigned int iir, lsr;
 	unsigned long flags;
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	iir = serial_in(up, UART_IIR);
 	if (iir & UART_IIR_NO_INT) {
-		pm_runtime_mark_last_busy(&up->pdev->dev);
-		pm_runtime_put_autosuspend(&up->pdev->dev);
+		pm_runtime_mark_last_busy(up->dev);
+		pm_runtime_put_autosuspend(up->dev);
 		return IRQ_NONE;
 	}
 
@@ -472,8 +472,8 @@  static inline irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		transmit_chars(up);
 
 	spin_unlock_irqrestore(&up->port.lock, flags);
-	pm_runtime_mark_last_busy(&up->pdev->dev);
-	pm_runtime_put_autosuspend(&up->pdev->dev);
+	pm_runtime_mark_last_busy(up->dev);
+	pm_runtime_put_autosuspend(up->dev);
 
 	up->port_activity = jiffies;
 	return IRQ_HANDLED;
@@ -485,12 +485,12 @@  static unsigned int serial_omap_tx_empty(struct uart_port *port)
 	unsigned long flags = 0;
 	unsigned int ret = 0;
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	dev_dbg(up->port.dev, "serial_omap_tx_empty+%d\n", up->port.line);
 	spin_lock_irqsave(&up->port.lock, flags);
 	ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0;
 	spin_unlock_irqrestore(&up->port.lock, flags);
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 	return ret;
 }
 
@@ -500,9 +500,9 @@  static unsigned int serial_omap_get_mctrl(struct uart_port *port)
 	unsigned int status;
 	unsigned int ret = 0;
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	status = check_modem_status(up);
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 
 	dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->port.line);
 
@@ -534,11 +534,11 @@  static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl)
 	if (mctrl & TIOCM_LOOP)
 		mcr |= UART_MCR_LOOP;
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	up->mcr = serial_in(up, UART_MCR);
 	up->mcr |= mcr;
 	serial_out(up, UART_MCR, up->mcr);
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 }
 
 static void serial_omap_break_ctl(struct uart_port *port, int break_state)
@@ -547,7 +547,7 @@  static void serial_omap_break_ctl(struct uart_port *port, int break_state)
 	unsigned long flags = 0;
 
 	dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->port.line);
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	spin_lock_irqsave(&up->port.lock, flags);
 	if (break_state == -1)
 		up->lcr |= UART_LCR_SBC;
@@ -555,7 +555,7 @@  static void serial_omap_break_ctl(struct uart_port *port, int break_state)
 		up->lcr &= ~UART_LCR_SBC;
 	serial_out(up, UART_LCR, up->lcr);
 	spin_unlock_irqrestore(&up->port.lock, flags);
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 }
 
 static int serial_omap_startup(struct uart_port *port)
@@ -574,7 +574,7 @@  static int serial_omap_startup(struct uart_port *port)
 
 	dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->port.line);
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	/*
 	 * Clear the FIFO buffers and disable them.
 	 * (they will be reenabled in set_termios())
@@ -630,8 +630,8 @@  static int serial_omap_startup(struct uart_port *port)
 	/* Enable module level wake up */
 	serial_out(up, UART_OMAP_WER, OMAP_UART_WER_MOD_WKUP);
 
-	pm_runtime_mark_last_busy(&up->pdev->dev);
-	pm_runtime_put_autosuspend(&up->pdev->dev);
+	pm_runtime_mark_last_busy(up->dev);
+	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 	return 0;
 }
@@ -643,7 +643,7 @@  static void serial_omap_shutdown(struct uart_port *port)
 
 	dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->port.line);
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	/*
 	 * Disable interrupts from this port
 	 */
@@ -678,7 +678,7 @@  static void serial_omap_shutdown(struct uart_port *port)
 		up->uart_dma.rx_buf = NULL;
 	}
 
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 	free_irq(up->port.irq, up);
 }
 
@@ -807,7 +807,7 @@  serial_omap_set_termios(struct uart_port *port, struct ktermios *termios,
 	 * Ok, we're now changing the port state. Do it with
 	 * interrupts disabled.
 	 */
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	spin_lock_irqsave(&up->port.lock, flags);
 
 	/*
@@ -956,7 +956,7 @@  serial_omap_set_termios(struct uart_port *port, struct ktermios *termios,
 	serial_omap_configure_xonxoff(up, termios);
 
 	spin_unlock_irqrestore(&up->port.lock, flags);
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 	dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->port.line);
 }
 
@@ -969,7 +969,7 @@  serial_omap_pm(struct uart_port *port, unsigned int state,
 
 	dev_dbg(up->port.dev, "serial_omap_pm+%d\n", up->port.line);
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
 	efr = serial_in(up, UART_EFR);
 	serial_out(up, UART_EFR, efr | UART_EFR_ECB);
@@ -980,14 +980,14 @@  serial_omap_pm(struct uart_port *port, unsigned int state,
 	serial_out(up, UART_EFR, efr);
 	serial_out(up, UART_LCR, 0);
 
-	if (!device_may_wakeup(&up->pdev->dev)) {
+	if (!device_may_wakeup(up->dev)) {
 		if (!state)
-			pm_runtime_forbid(&up->pdev->dev);
+			pm_runtime_forbid(up->dev);
 		else
-			pm_runtime_allow(&up->pdev->dev);
+			pm_runtime_allow(up->dev);
 	}
 
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 }
 
 static void serial_omap_release_port(struct uart_port *port)
@@ -1066,10 +1066,10 @@  static void serial_omap_poll_put_char(struct uart_port *port, unsigned char ch)
 {
 	struct uart_omap_port *up = to_uart_omap_port(port);
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	wait_for_xmitr(up);
 	serial_out(up, UART_TX, ch);
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 }
 
 static int serial_omap_poll_get_char(struct uart_port *port)
@@ -1077,13 +1077,13 @@  static int serial_omap_poll_get_char(struct uart_port *port)
 	struct uart_omap_port *up = to_uart_omap_port(port);
 	unsigned int status;
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 	status = serial_in(up, UART_LSR);
 	if (!(status & UART_LSR_DR))
 		return NO_POLL_CHAR;
 
 	status = serial_in(up, UART_RX);
-	pm_runtime_put(&up->pdev->dev);
+	pm_runtime_put(up->dev);
 	return status;
 }
 
@@ -1112,7 +1112,7 @@  serial_omap_console_write(struct console *co, const char *s,
 	unsigned int ier;
 	int locked = 1;
 
-	pm_runtime_get_sync(&up->pdev->dev);
+	pm_runtime_get_sync(up->dev);
 
 	local_irq_save(flags);
 	if (up->port.sysrq)
@@ -1146,8 +1146,8 @@  serial_omap_console_write(struct console *co, const char *s,
 	if (up->msr_saved_flags)
 		check_modem_status(up);
 
-	pm_runtime_mark_last_busy(&up->pdev->dev);
-	pm_runtime_put_autosuspend(&up->pdev->dev);
+	pm_runtime_mark_last_busy(up->dev);
+	pm_runtime_put_autosuspend(up->dev);
 	if (locked)
 		spin_unlock(&up->port.lock);
 	local_irq_restore(flags);
@@ -1309,7 +1309,7 @@  static int serial_omap_start_rxdma(struct uart_omap_port *up)
 	int ret = 0;
 
 	if (up->uart_dma.rx_dma_channel == -1) {
-		pm_runtime_get_sync(&up->pdev->dev);
+		pm_runtime_get_sync(up->dev);
 		ret = omap_request_dma(up->uart_dma.uart_dma_rx,
 				"UART Rx DMA",
 				(void *)uart_rx_dma_callback, up,
@@ -1421,7 +1421,7 @@  static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
 		minor = (mvr & OMAP_UART_MVR_MIN_MASK);
 		break;
 	default:
-		dev_warn(&up->pdev->dev,
+		dev_warn(up->dev,
 			"Unknown %s revision, defaulting to highest\n",
 			up->name);
 		/* highest possible revision */
@@ -1502,7 +1502,7 @@  static int serial_omap_probe(struct platform_device *pdev)
 	if (!up)
 		return -ENOMEM;
 
-	up->pdev = pdev;
+	up->dev = &pdev->dev;
 	up->port.dev = &pdev->dev;
 	up->port.type = PORT_OMAP;
 	up->port.iotype = UPIO_MEM;
@@ -1599,7 +1599,7 @@  static int serial_omap_remove(struct platform_device *dev)
 	struct uart_omap_port *up = platform_get_drvdata(dev);
 
 	if (up) {
-		pm_runtime_disable(&up->pdev->dev);
+		pm_runtime_disable(up->dev);
 		uart_remove_one_port(&serial_omap_reg, &up->port);
 		pm_qos_remove_request(&up->pm_qos_request);
 	}
@@ -1634,7 +1634,7 @@  static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
 		timeout--;
 		if (!timeout) {
 			/* Should *never* happen. we warn and carry on */
-			dev_crit(&up->pdev->dev, "Errata i202: timedout %x\n",
+			dev_crit(up->dev, "Errata i202: timedout %x\n",
 						serial_in(up, UART_LSR));
 			break;
 		}