From: Lada Trimasova <Lada.Trimasova@synopsys.com>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"noamc@ezchip.com" <noamc@ezchip.com>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH] arc: use little endian accesses
Date: Thu, 10 Mar 2016 18:57:48 +0000 [thread overview]
Message-ID: <1457636268.457.34.camel@synopsys.com> (raw)
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075F4E8F1A0@us01wembx1.internal.synopsys.com>
Hi Vineet, Alexey, Arnd,
On Thu, 2016-03-10 at 09:55 +0000, Vineet Gupta wrote:
Can you or Lada provide more details as to exactly what is not working - what
driver to be precise 8250 or dw-8250.
And where exactly the failure shows up. I want to understand this more
Noam told me off list that he has no issues with both big endian ARC + 8250 in
systemc model or silicon.
-Vineet
Driver is 8250, kernel is built for BE arc, nsim option in model "nsim_isa_big_endian = 1".
With current "readl" and "writel" implementation for ARC we read word from memory without any endianess manipulation. So in case of little endian architecture we get what we want: the first memory byte is the low byte in the word. But in case of big endian architecture the word endianess is swapped: the first memory byte is the high word byte.
And for example, let's see what happens when we use "readl" in function "serial8250_early_in" in driver/tty/serial/8250.
Take a look to one line from memory dump:
0xf0000010: 0x0b 0x00 0x00 0x00 0x60 0x00 0x00 0x00
When kernel is built for little endian architecture, we read this data in status register in function "serial_putc" using "readl" function in driver/tty/serial/8250 as:
r0: 0x0000006
The low byte is 0x0b, so the condition "if ((status & BOTH_EMPTY) == BOTH_EMPTY)" is true, as BOTH_EMPTY is some mask with low bytes set.
When kernel is built with "CPU_BIG_ENDIAN" and model nsim option is "nsim_isa_big_endian=1", we read this data as:
r0: 0x6000000
So as you can see the low byte is 0x00 and above mentioned condition never becomes true, we can't continue initialization.
Regards,
Lada
WARNING: multiple messages have this Message-ID (diff)
From: Lada.Trimasova@synopsys.com (Lada Trimasova)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] arc: use little endian accesses
Date: Thu, 10 Mar 2016 18:57:48 +0000 [thread overview]
Message-ID: <1457636268.457.34.camel@synopsys.com> (raw)
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075F4E8F1A0@us01wembx1.internal.synopsys.com>
Hi Vineet, Alexey, Arnd,
On Thu, 2016-03-10@09:55 +0000, Vineet Gupta wrote:
Can you or Lada provide more details as to exactly what is not working - what
driver to be precise 8250 or dw-8250.
And where exactly the failure shows up. I want to understand this more
Noam told me off list that he has no issues with both big endian ARC + 8250 in
systemc model or silicon.
-Vineet
Driver is 8250, kernel is built for BE arc, nsim option in model "nsim_isa_big_endian = 1".
With current "readl" and "writel" implementation for ARC we read word from memory without any endianess manipulation. So in case of little endian architecture we get what we want: the first memory byte is the low byte in the word. But in case of big endian architecture the word endianess is swapped: the first memory byte is the high word byte.
And for example, let's see what happens when we use "readl" in function "serial8250_early_in" in driver/tty/serial/8250.
Take a look to one line from memory dump:
0xf0000010: 0x0b 0x00 0x00 0x00 0x60 0x00 0x00 0x00
When kernel is built for little endian architecture, we read this data in status register in function "serial_putc" using "readl" function in driver/tty/serial/8250 as:
r0: 0x0000006
The low byte is 0x0b, so the condition "if ((status & BOTH_EMPTY) == BOTH_EMPTY)" is true, as BOTH_EMPTY is some mask with low bytes set.
When kernel is built with "CPU_BIG_ENDIAN" and model nsim option is "nsim_isa_big_endian=1", we read this data as:
r0: 0x6000000
So as you can see the low byte is 0x00 and above mentioned condition never becomes true, we can't continue initialization.
Regards,
Lada
next prev parent reply other threads:[~2016-03-10 18:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 17:21 [PATCH] arc: use little endian accesses Lada Trimasova
2016-03-09 17:21 ` Lada Trimasova
2016-03-10 5:05 ` Vineet Gupta
2016-03-10 5:05 ` Vineet Gupta
2016-03-10 5:19 ` Vineet Gupta
2016-03-10 5:19 ` Vineet Gupta
2016-03-10 7:44 ` Alexey Brodkin
2016-03-10 7:44 ` Alexey Brodkin
2016-03-10 9:55 ` Vineet Gupta
2016-03-10 9:55 ` Vineet Gupta
2016-03-10 18:57 ` Lada Trimasova [this message]
2016-03-10 18:57 ` Lada Trimasova
2016-03-10 19:23 ` Arnd Bergmann
2016-03-10 19:23 ` Arnd Bergmann
2016-03-11 12:44 ` Vineet Gupta
2016-03-11 12:44 ` Vineet Gupta
2016-03-12 4:20 ` Vineet Gupta
2016-03-12 4:20 ` Vineet Gupta
2016-03-12 4:20 ` Vineet Gupta
2016-03-12 4:20 ` Vineet Gupta
2016-03-11 5:07 ` Noam Camus
2016-03-11 5:07 ` Noam Camus
2016-03-11 5:07 ` Noam Camus
2016-03-10 7:45 ` Arnd Bergmann
2016-03-10 7:45 ` Arnd Bergmann
2016-03-10 7:45 ` Arnd Bergmann
2016-03-11 5:18 ` Vineet Gupta
2016-03-11 5:18 ` Vineet Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1457636268.457.34.camel@synopsys.com \
--to=lada.trimasova@synopsys.com \
--cc=Alexey.Brodkin@synopsys.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=noamc@ezchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.