Re: Suspend broken on 3.3?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----Original Message-----
From: "Raja, Govindraj" <govindraj.raja@xxxxxx>
To: Joe Woodward <jw@xxxxxxxxxxxxxx>
Cc: Paul Walmsley <paul@xxxxxxxxx>, Kevin Hilman <khilman@xxxxxx>, linux-omap@xxxxxxxxxxxxxxx, Felipe Balbi <balbi@xxxxxx>, neilb@xxxxxxx
Date: Thu, 29 Mar 2012 19:59:54 +0530
Subject: Re: Suspend broken on 3.3?

> On Thu, Mar 29, 2012 at 5:10 PM, Joe Woodward <jw@xxxxxxxxxxxxxx>
> wrote:
> >
> >
> > -----Original Message-----
> > From: "Joe Woodward" <jw@xxxxxxxxxxxxxx>
> > To: "Paul Walmsley" <paul@xxxxxxxxx>
> > Cc: "Kevin Hilman" <khilman@xxxxxx>, "Raja\\, Govindraj"
> <govindraj.raja@xxxxxx>, linux-omap@xxxxxxxxxxxxxxx, "Felipe Balbi"
> <balbi@xxxxxx>, neilb@xxxxxxx
> > Date: Thu, 29 Mar 2012 12:27:55 +0100
> > Subject: Re: Suspend broken on 3.3?
> >
> >> > Hello Joe,
> >> >
> >> > thanks for reporting this.  Some thoughts -- really just pure
> >> > speculation
> >> > -- but I hope some of it might be useful for you...
> >> >
> >> > On Thu, 29 Mar 2012, Joe Woodward wrote:
> >> >
> >> > > After digging a bit further I found that the problem isn't lost
> >> > characters or character corruption at all...
> >> > >
> >> > > The UART is actually at 430KBaud (not 900KBaud as I mentioned
> >> > earlier).
> >> >
> >> > 430Kbps?  Could you confirm this?  OMAP UARTs don't support that
> rate
> >> > as
> >> > far as I know - the closest is 460Kbps (OMAP34xx TRM vZR Table
> 17-1
> >> > "UART
> >> > Mode Baud Rates, Divisor Values, and Error Rates).  If one was
> >> > desperate,
> >> > it might be possible to get 430Kbps by tweaking other parts of the
> >> > clock
> >> > tree though...
> >>
> >> Sorry for the confusion... It's 460KBaud - the 430 was just a typo
> in
> >> my previous mail...
> >>
> >> >
> >> > > The data received is very bursty (i.e. sets of messages every
> >> second
> >> > or
> >> > > so), containing a sync sequence to indicate a start of packet.
> >> > >
> >> > > The received bytes should be: 0x01, 0x52, 0x41 ....rest of
> packet.
> >> > >
> >> > > This works 100% of the time on 3.2, but on 3.3 I sometimes (but
> not
> >> > always) get: 0x01, 0x00, 0x52, 0x41.
> >> > >
> >> > > i.e. there is a NULL/0x00 inserted after the first character.
> >> >
> >> > Is this on the serial console, or on a non-console serial port?
> >> >
> >> > Looking at drivers/tty/serial/omap-serial.c:receive_chars(), I
> wonder
> >> > if
> >> > the driver is somehow reading bytes from the RX FIFO when it's
> empty.
> >>
> >> > It's unclear to me how this could happen.  But you might want to
> try
> >> > doing
> >> > an LSR read right before entering the loop in
> >> > drivers/tty/serial/omap-serial.c:receive_chars().  In stock v3.3,
> >> this
> >> > would mean adding
> >> >
> >> >             lsr = serial_in(up, UART_LSR);
> >> >
> >> > at line 190 of drivers/tty/serial/omap-serial.c.
> >> >
> >>
> >> Adding this is made no obvious difference.
> >>
> >> >
> >> > You might also try the DMA path as an experiment.  This will
> totally
> >> > wedge
> >> > power management due to an insanely low timer expiration in that
> >> path,
> >> > but
> >> > at least might help narrow the problem down.  To do so with a
> quick
> >> > hack,
> >> > you could set omap_serial_default_info.dma_enabled to true instead
> of
> >> > false at arch/arm/mach-omap2/serial.c:76.
> >> >
> >>
> >> This did the trick (I've added it in addition to the LSR read above,
> >> i'll back out the LSR read and see if it still works).
> >> When DMA is enabled the behaviour (as seen from my application in
> >> userspace) is the same as on the stock 3.2 kernel (i.e. for me it
> works
> >> :) ).
> >>
> >
> > I've just realised that if anyone has joined this thread late, then
> I'm running in a state with Govindraj's patch in a previous mail in
> this thread applied to serial.c to
> > fix the suspend issues due to the UART wakeup's not being correctly
> changed from userspace via sysfs.
> >
> > It may actually by this patch that is causing the interrupt-enabled
> serial driver to have broken? The tty that is causing me a problem does
> have wake-from-suspend
> > disabled for it from userspace...
> 
> Is the patch shared earlier causing this issue of getting 0x00 from rx
> randomly ?
> 

In short, yes.

I've gone back to a stock 3.3 kernel and the serial ports give the correct data, but suspend fails (due to not being able to disable wake-from-serial).

I then applied your patch and could disable wakeup on the serial ports and suspend correctly, but the (non-console) serial port starts to misbehave.

Forcing the driver to be DMA-enabled caused everything to work again. So something in the patch is causing the (default) interrupt-enabled serial driver to 
occassionally fail.

Sorry for the goose chase yesterday. I didn't even think to check if the patch caused the issue as it seemed a bit unrelated.

Cheers,
Joe


> --
> Thanks,
> Govindraj.R
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap"
> in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux