From: H. Peter Anvin on
On 07/10/2010 02:07 PM, Cyrill Gorcunov wrote:
> On Sat, Jul 10, 2010 at 10:40:20PM +0300, Pekka Enberg wrote:
>> This patch adds serial I/O support to very early boot printf(). It's useful for
>> debugging boot code when running Linux under KVM, for example. The actual code
>>
>> +#define cpu_relax() asm volatile("rep; nop" ::: "memory")
>> +

We don't need "memory" here since the early boot environment is
single-threaded.

-hpa


--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on
On Sun, Jul 11, 2010 at 12:27 AM, H. Peter Anvin <hpa(a)zytor.com> wrote:
> On 07/10/2010 02:17 PM, Pekka Enberg wrote:
>> On Sat, Jul 10, 2010 at 11:49 PM, Yinghai Lu <yinghai(a)kernel.org> wrote:
>>> can you analyze "console=uart8250,io,0x3f8,115200n8" instead?
>>>
>>> that is equal to "earlyprintk=ttyS0,115200 console=ttyS0,115200"
>>>
>>> so we only use one for all.
>>>
>>> also like to kill earlyprintk=ttyS0,115200 to favor earlycon
>>
>> hpa, what's your take on this?
>>
>> The 'console' variant seems overly complicated to me. We can add it
>> but we also need to check for 'earlyprintk' as long as it's supported
>> by the kernel.
>>
>
> earlyprintk= seems to be preferred over console= these days. �Quite
> frankly it's idiotic to have the user enter as many low-level details as
> one has to do for the console= one.
>
> Now, as for the I/O base, the I/O base for legacy serial ports are
> available from a 4-element u16 array starting at absolute address 0x400.
> �I don't think Linux currently examines that array -- instead relying on
> the hard-coded values 0x3f8, 0x2f8, 0x3e8, 0x2e8 -- but it might
> something to consider for the future. �However, we should match the
> serial port subsystem there, of course.

OK. The current patch should match 'earlyprintk' handling which uses
hard-coded values only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Cyrill Gorcunov on
On Sat, Jul 10, 2010 at 02:37:01PM -0700, H. Peter Anvin wrote:
> On 07/10/2010 02:07 PM, Cyrill Gorcunov wrote:
> > On Sat, Jul 10, 2010 at 10:40:20PM +0300, Pekka Enberg wrote:
> >> This patch adds serial I/O support to very early boot printf(). It's useful for
> >> debugging boot code when running Linux under KVM, for example. The actual code
> >>
> >> +#define cpu_relax() asm volatile("rep; nop" ::: "memory")
> >> +
>
> We don't need "memory" here since the early boot environment is
> single-threaded.
>
> -hpa
>

I rather wonder -- can't we use cpu_relax() from processor.h? Or there
is some type conflicts?

-- Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 07/10/2010 02:55 PM, Cyrill Gorcunov wrote:
>
> I rather wonder -- can't we use cpu_relax() from processor.h? Or there
> is some type conflicts?
>

Probably. The boot environment is pretty different, and not sharing
header files where we don't need to because of shared data structures is
probably a good idea.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on
On 07/10/2010 02:55 PM, Cyrill Gorcunov wrote:
>> I rather wonder -- can't we use cpu_relax() from processor.h? Or there
>> is some type conflicts?

H. Peter Anvin wrote:
> Probably. The boot environment is pretty different, and not sharing
> header files where we don't need to because of shared data structures is
> probably a good idea.

I did try it but got bunch of compile errors and figured I was not
supposed to use it.

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/