* Sebastian Andrzej Siewior [140813 09:23]:
> On 07/21/2014 11:35 AM, Tony Lindgren wrote:
>
> > 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?
>
> Yes, there was a third one on shut
On 07/21/2014 11:35 AM, Tony Lindgren wrote:
> 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?
Yes, there was a third one on shutdown.
> Also, no luck yet on runtime PM. If the console is
* 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
* 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 e
On Thu, Jul 17, 2014 at 05:11:58PM +0200, Sebastian Andrzej Siewior wrote:
> On 07/17/2014 04:54 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Jul 16, 2014 at 04:45:03PM +0200, Sebastian Andrzej Siewior wrote:
> >> +static int omap_8250_startup(struct uart_port *port)
> >> +{
> >> + struct uart
On 07/17/2014 04:54 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 16, 2014 at 04:45:03PM +0200, Sebastian Andrzej Siewior wrote:
>> +static int omap_8250_startup(struct uart_port *port)
>> +{
>> +struct uart_8250_port *up =
>> +container_of(port, struct uart_8250_port, port);
>> +
Hi,
On Wed, Jul 16, 2014 at 04:45:03PM +0200, Sebastian Andrzej Siewior wrote:
> +static int omap_8250_startup(struct uart_port *port)
> +{
> + struct uart_8250_port *up =
> + container_of(port, struct uart_8250_port, port);
> + struct omap8250_priv *priv = port->private_data;
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
* Sebastian Andrzej Siewior [140717 00:44]:
> * Tony Lindgren | 2014-07-17 00:09:00 [-0700]:
>
> >Seems to boot a bit further now with output from serial console
> >initially, then I'm getting the following error again that's probably
> >related to clocks not enabled when the registers are access
* Tony Lindgren | 2014-07-17 00:09:00 [-0700]:
>Seems to boot a bit further now with output from serial console
>initially, then I'm getting the following error again that's probably
>related to clocks not enabled when the registers are accessed:
It is (mostly) the same thing as before. We have a
* Sebastian Andrzej Siewior [140716 07:47]:
> This patch provides a 8250-core based UART driver for the internal OMAP
> UART. The longterm goal is to provide the same functionality as the
> current OMAP uart driver and hopefully DMA support which could borrowed
> from the 8250-core.
>
> It has be
11 matches
Mail list logo
