On Fri, 21 Sep 2007, Russell King wrote:
> > I see no problem with implementing the ->pm() call as something like:
> >
> > void zs_pm(struct uart_port uport, unsigned int state, unsigned int
> > oldstate)
> > {
> > struct zs_port *zport = to_zport(uport);
> >
> > if (state < 3)
> >
On Fri, 21 Sep 2007, Russell King wrote:
I see no problem with implementing the -pm() call as something like:
void zs_pm(struct uart_port uport, unsigned int state, unsigned int
oldstate)
{
struct zs_port *zport = to_zport(uport);
if (state 3)
On Fri, Sep 21, 2007 at 03:36:05PM +0100, Maciej W. Rozycki wrote:
> On Fri, 21 Sep 2007, Russell King wrote:
> > You can find the fix in the mbox archive:
> >
> > http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cut/arm:devel.mbox
>
> Hmm, nothing of relevance there.
Hmm, it does help to
On Fri, 21 Sep 2007, Russell King wrote:
> I suspect the correct fix for this is to take the fix in the ARM tree
> for serial_core's console initialisation, and ensure that zs.c handles
> the power management of the port (enabling/disabling transmitter)
> in the power management callback.
Hmm,
On Fri, Sep 21, 2007 at 02:36:50PM +0100, Maciej W. Rozycki wrote:
> On Fri, 21 Sep 2007, Andrew Morton wrote:
>
> > It would be useful to have some basic information like: Which kernel
> > version was this found in? Which kernel version last worked?
>
> The kernel used was a 2.6.23-rc5
On Fri, 21 Sep 2007, Andrew Morton wrote:
> It would be useful to have some basic information like: Which kernel
> version was this found in? Which kernel version last worked?
The kernel used was a 2.6.23-rc5 snapshot from Sep 4th, 2007 taken from
the linux-mips.org tree (as stated by the
On Fri, 21 Sep 2007, Gerd Hoffmann wrote:
> Well, I placed the printk there is for user interface reasons. I think
> especially in case the early console and the real console go to
> different physical devices it is useful to have the reason it stops
> printing messages displayed on the early
Russell King wrote:
> I had an issue with the console initialisation on serial ports, which I
> discovered during my PXA work. My reason for asking about the kernel
> versions (which Andrew forwarded to LKML) is to determine whether the
> report is as a result of those changes, or lack of those
On Fri, Sep 21, 2007 at 02:42:34PM +0200, Gerd Hoffmann wrote:
> Andrew Morton wrote:
> > On Thu, 20 Sep 2007 18:28:49 +0100 (BST) "Maciej W. Rozycki" <[EMAIL
> > PROTECTED]> wrote:
> >
> >> Move the hadover message to after the boot console has been released to
> >> avoid bad interactions
Andrew Morton wrote:
> On Thu, 20 Sep 2007 18:28:49 +0100 (BST) "Maciej W. Rozycki" <[EMAIL
> PROTECTED]> wrote:
>
>> Move the hadover message to after the boot console has been released to
>> avoid bad interactions between it and the real console.
[ longish problem discussion snipped ]
>>
Maciej W. Rozycki <[EMAIL PROTECTED]> wrote:
> Move the hadover message to after the boot console has been released to
> avoid bad interactions between it and the real console.
This message is usefull if the handover fails, therefore it should be printed
on the boot console, while successfull
On Thu, 20 Sep 2007 18:28:49 +0100 (BST) "Maciej W. Rozycki" <[EMAIL
PROTECTED]> wrote:
> Move the hadover message to after the boot console has been released to
> avoid bad interactions between it and the real console.
>
> Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
> ---
> The
On Thu, 20 Sep 2007 18:28:49 +0100 (BST) Maciej W. Rozycki [EMAIL
PROTECTED] wrote:
Move the hadover message to after the boot console has been released to
avoid bad interactions between it and the real console.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
The
Maciej W. Rozycki [EMAIL PROTECTED] wrote:
Move the hadover message to after the boot console has been released to
avoid bad interactions between it and the real console.
This message is usefull if the handover fails, therefore it should be printed
on the boot console, while successfull
Andrew Morton wrote:
On Thu, 20 Sep 2007 18:28:49 +0100 (BST) Maciej W. Rozycki [EMAIL
PROTECTED] wrote:
Move the hadover message to after the boot console has been released to
avoid bad interactions between it and the real console.
[ longish problem discussion snipped ]
considered
On Fri, Sep 21, 2007 at 02:42:34PM +0200, Gerd Hoffmann wrote:
Andrew Morton wrote:
On Thu, 20 Sep 2007 18:28:49 +0100 (BST) Maciej W. Rozycki [EMAIL
PROTECTED] wrote:
Move the hadover message to after the boot console has been released to
avoid bad interactions between it and the
On Fri, 21 Sep 2007, Gerd Hoffmann wrote:
Well, I placed the printk there is for user interface reasons. I think
especially in case the early console and the real console go to
different physical devices it is useful to have the reason it stops
printing messages displayed on the early
Russell King wrote:
I had an issue with the console initialisation on serial ports, which I
discovered during my PXA work. My reason for asking about the kernel
versions (which Andrew forwarded to LKML) is to determine whether the
report is as a result of those changes, or lack of those
On Fri, 21 Sep 2007, Andrew Morton wrote:
It would be useful to have some basic information like: Which kernel
version was this found in? Which kernel version last worked?
The kernel used was a 2.6.23-rc5 snapshot from Sep 4th, 2007 taken from
the linux-mips.org tree (as stated by the
On Fri, Sep 21, 2007 at 02:36:50PM +0100, Maciej W. Rozycki wrote:
On Fri, 21 Sep 2007, Andrew Morton wrote:
It would be useful to have some basic information like: Which kernel
version was this found in? Which kernel version last worked?
The kernel used was a 2.6.23-rc5 snapshot from
On Fri, 21 Sep 2007, Russell King wrote:
I suspect the correct fix for this is to take the fix in the ARM tree
for serial_core's console initialisation, and ensure that zs.c handles
the power management of the port (enabling/disabling transmitter)
in the power management callback.
Hmm, it
On Fri, Sep 21, 2007 at 03:36:05PM +0100, Maciej W. Rozycki wrote:
On Fri, 21 Sep 2007, Russell King wrote:
You can find the fix in the mbox archive:
http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cut/arm:devel.mbox
Hmm, nothing of relevance there.
Hmm, it does help to
Move the hadover message to after the boot console has been released to
avoid bad interactions between it and the real console.
Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---
The 69331af79cf29e26d1231152a172a1a10c2df511 commit of May 8th added a
"console handover: ..." message to
Move the hadover message to after the boot console has been released to
avoid bad interactions between it and the real console.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
The 69331af79cf29e26d1231152a172a1a10c2df511 commit of May 8th added a
console handover: ... message to
24 matches
Mail list logo
