On 02/12/2013 09:25 PM, Arnd Bergmann wrote:
On Tuesday 12 February 2013, Michal Simek wrote:
But on Microblaze LE is necessary to use different datain/out_le16
functions as below
which are also not compatible with Microblaze and PPC BE.
diff --git a/drivers/block/xsysace.c
On 02/12/2013 09:25 PM, Arnd Bergmann wrote:
On Tuesday 12 February 2013, Michal Simek wrote:
But on Microblaze LE is necessary to use different datain/out_le16
functions as below
which are also not compatible with Microblaze and PPC BE.
diff --git a/drivers/block/xsysace.c
On Tuesday 12 February 2013, Michal Simek wrote:
> But on Microblaze LE is necessary to use different datain/out_le16
> functions as below
> which are also not compatible with Microblaze and PPC BE.
>
> diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
> index bbad046..8dd192c 100644
2013/2/7 Grant Likely :
> On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin
> wrote:
>> On 02/07/2013 06:51 PM, Grant Likely wrote:
>>>
>>> On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely
>>> wrote:
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
wrote:
>>
>> In fact,
On Tuesday 12 February 2013, Michal Simek wrote:
> ok but still there should be well defined how to do it. Let's say
> generic Kconfig option.
You cannot solve it in a generic way, since every device has different
needs. In a single SoC, you may have one device that only ever exists
with
On Tue, 2013-02-12 at 11:11 +0100, Michal Simek wrote:
> For high performance IPs using accessors functions is still
> problematic
> because there will be performance regression it means that
> from my point of view there still should be any option to "setup"
> proper endians for the driver and it
2013/2/12 Arnd Bergmann :
> On Tuesday 12 February 2013, Michal Simek wrote:
>> > In particular, ARM can run both big- and little-endian even though
>> > big-endian is rarely used, so you need to know the endianess for
>> > the device you are talking to rather than assume that it knows
>> > what
On Tuesday 12 February 2013, Benjamin Herrenschmidt wrote:
> It depends how the ARM core operates vs. IO when switched between BE and
> LE, does it keep the same lines doing byte 0 or does it keep the MSB/LSB
> in the same place (and thus changes which lanes contain byte 0) ?
IIRC it changed
On Tuesday 12 February 2013, Michal Simek wrote:
> > In particular, ARM can run both big- and little-endian even though
> > big-endian is rarely used, so you need to know the endianess for
> > the device you are talking to rather than assume that it knows
> > what the CPU does at the time.
>
>
2013/2/11 Arnd Bergmann :
> On Monday 11 February 2013, Michal Simek wrote:
>> Unfortunately no. Another is spi/i2c (sysace as we discuss in this
>> thread), probably icap
>> network drivers are ok because they are not shared.
>> Timer when it is moved to clocksource(not important right now)
>>
2013/2/12 Benjamin Herrenschmidt :
> On Mon, 2013-02-11 at 16:57 +0100, Michal Simek wrote:
>> But it reminds me that maybe the easiest solution is not to use endian
>> accessors just use two simple macros which should work on all systems.
>>
>> #define _readreg(offset)
2013/2/12 Benjamin Herrenschmidt b...@kernel.crashing.org:
On Mon, 2013-02-11 at 16:57 +0100, Michal Simek wrote:
But it reminds me that maybe the easiest solution is not to use endian
accessors just use two simple macros which should work on all systems.
#define name_readreg(offset)
2013/2/11 Arnd Bergmann a...@arndb.de:
On Monday 11 February 2013, Michal Simek wrote:
Unfortunately no. Another is spi/i2c (sysace as we discuss in this
thread), probably icap
network drivers are ok because they are not shared.
Timer when it is moved to clocksource(not important right now)
On Tuesday 12 February 2013, Michal Simek wrote:
In particular, ARM can run both big- and little-endian even though
big-endian is rarely used, so you need to know the endianess for
the device you are talking to rather than assume that it knows
what the CPU does at the time.
For high
On Tuesday 12 February 2013, Benjamin Herrenschmidt wrote:
It depends how the ARM core operates vs. IO when switched between BE and
LE, does it keep the same lines doing byte 0 or does it keep the MSB/LSB
in the same place (and thus changes which lanes contain byte 0) ?
IIRC it changed between
2013/2/12 Arnd Bergmann a...@arndb.de:
On Tuesday 12 February 2013, Michal Simek wrote:
In particular, ARM can run both big- and little-endian even though
big-endian is rarely used, so you need to know the endianess for
the device you are talking to rather than assume that it knows
what
On Tue, 2013-02-12 at 11:11 +0100, Michal Simek wrote:
For high performance IPs using accessors functions is still
problematic
because there will be performance regression it means that
from my point of view there still should be any option to setup
proper endians for the driver and it can't
On Tuesday 12 February 2013, Michal Simek wrote:
ok but still there should be well defined how to do it. Let's say
generic Kconfig option.
You cannot solve it in a generic way, since every device has different
needs. In a single SoC, you may have one device that only ever exists
with
2013/2/7 Grant Likely grant.lik...@secretlab.ca:
On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
On 02/07/2013 06:51 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Wed, Feb 6, 2013 at 9:35 PM,
On Tuesday 12 February 2013, Michal Simek wrote:
But on Microblaze LE is necessary to use different datain/out_le16
functions as below
which are also not compatible with Microblaze and PPC BE.
diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index bbad046..8dd192c 100644
---
On Mon, 2013-02-11 at 16:08 +, Arnd Bergmann wrote:
> I tend to disagree. You should never assume that a device is the same
> endianess as the the CPU, and you should try not to use the __raw_*
> accessors in device drivers either.
>
> In particular, ARM can run both big- and little-endian
On Mon, 2013-02-11 at 16:57 +0100, Michal Simek wrote:
> But it reminds me that maybe the easiest solution is not to use endian
> accessors just use two simple macros which should work on all systems.
>
> #define _readreg(offset) ({__raw_readl(offset); rmb(); })
> #define
On Monday 11 February 2013, Michal Simek wrote:
> Unfortunately no. Another is spi/i2c (sysace as we discuss in this
> thread), probably icap
> network drivers are ok because they are not shared.
> Timer when it is moved to clocksource(not important right now)
> xilinx gpio is using __raw IO
2013/2/11 Arnd Bergmann :
> On Monday 11 February 2013, Michal Simek wrote:
>> I have just found that it won't be so easy as I thought because I have found
>> that microblaze wrong implementation was done because of others device
>> drivers.
>> It means that I have to fix all device drivers to
On Monday 11 February 2013, Michal Simek wrote:
> I have just found that it won't be so easy as I thought because I have found
> that microblaze wrong implementation was done because of others device
> drivers.
> It means that I have to fix all device drivers to support big and
> little endian
2013/2/11 Arnd Bergmann :
> On Monday 11 February 2013, Michal Simek wrote:
>>
>> 2013/2/8 Arnd Bergmann :
>> > On Thursday 07 February 2013, Michal Simek wrote:
>> >> Subject: "asm-generic: io: Fix ioread16/32be and iowrite16/32be"
>> >
>> > Ok, thanks. If you don't mind, I think this can just go
On Monday 11 February 2013, Michal Simek wrote:
>
> 2013/2/8 Arnd Bergmann :
> > On Thursday 07 February 2013, Michal Simek wrote:
> >> Subject: "asm-generic: io: Fix ioread16/32be and iowrite16/32be"
> >
> > Ok, thanks. If you don't mind, I think this can just go with the other
> > patches
> >
2013/2/8 Arnd Bergmann :
> On Thursday 07 February 2013, Michal Simek wrote:
>> Subject: "asm-generic: io: Fix ioread16/32be and iowrite16/32be"
>
> Ok, thanks. If you don't mind, I think this can just go with the other patches
> for xsysace that come out of this discussion.
I want to move
2013/2/8 Arnd Bergmann a...@arndb.de:
On Thursday 07 February 2013, Michal Simek wrote:
Subject: asm-generic: io: Fix ioread16/32be and iowrite16/32be
Ok, thanks. If you don't mind, I think this can just go with the other patches
for xsysace that come out of this discussion.
I want to move
On Monday 11 February 2013, Michal Simek wrote:
2013/2/8 Arnd Bergmann a...@arndb.de:
On Thursday 07 February 2013, Michal Simek wrote:
Subject: asm-generic: io: Fix ioread16/32be and iowrite16/32be
Ok, thanks. If you don't mind, I think this can just go with the other
patches
for
2013/2/11 Arnd Bergmann a...@arndb.de:
On Monday 11 February 2013, Michal Simek wrote:
2013/2/8 Arnd Bergmann a...@arndb.de:
On Thursday 07 February 2013, Michal Simek wrote:
Subject: asm-generic: io: Fix ioread16/32be and iowrite16/32be
Ok, thanks. If you don't mind, I think this can
On Monday 11 February 2013, Michal Simek wrote:
I have just found that it won't be so easy as I thought because I have found
that microblaze wrong implementation was done because of others device
drivers.
It means that I have to fix all device drivers to support big and
little endian
2013/2/11 Arnd Bergmann a...@arndb.de:
On Monday 11 February 2013, Michal Simek wrote:
I have just found that it won't be so easy as I thought because I have found
that microblaze wrong implementation was done because of others device
drivers.
It means that I have to fix all device drivers
On Monday 11 February 2013, Michal Simek wrote:
Unfortunately no. Another is spi/i2c (sysace as we discuss in this
thread), probably icap
network drivers are ok because they are not shared.
Timer when it is moved to clocksource(not important right now)
xilinx gpio is using __raw IO functions
On Mon, 2013-02-11 at 16:57 +0100, Michal Simek wrote:
But it reminds me that maybe the easiest solution is not to use endian
accessors just use two simple macros which should work on all systems.
#define name_readreg(offset) ({__raw_readl(offset); rmb(); })
#define
On Mon, 2013-02-11 at 16:08 +, Arnd Bergmann wrote:
I tend to disagree. You should never assume that a device is the same
endianess as the the CPU, and you should try not to use the __raw_*
accessors in device drivers either.
In particular, ARM can run both big- and little-endian even
On Thu, Feb 7, 2013 at 5:22 PM, Alexey Brodkin
wrote:
> On 02/07/2013 09:16 PM, Grant Likely wrote:
>>
>> On Thu, Feb 7, 2013 at 4:56 PM, Alexey Brodkin
>> wrote:
>>>
>>> On 02/07/2013 08:44 PM, Grant Likely wrote:
So, if I'm correct that means that for the data port (specifically
On Thu, Feb 7, 2013 at 11:05 PM, Arnd Bergmann wrote:
> On Thursday 07 February 2013, Grant Likely wrote:
>> On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin
> Of course, as long as the driver is only ever used to access
> the same non-removable block device and you don't change
> the driver, it
On Fri, Feb 8, 2013 at 12:05 AM, Arnd Bergmann wrote:
>> The same is true for the data port. A BE read does the right thing on
>> a BE platform, and LE read on a LE platform. (again, this is all about
>> bus attachment). However, the difference is what is then done with the
>> data.
>
> Well,
On Thursday 07 February 2013, Michal Simek wrote:
> Subject: "asm-generic: io: Fix ioread16/32be and iowrite16/32be"
Ok, thanks. If you don't mind, I think this can just go with the other patches
for xsysace that come out of this discussion.
Arnd
--
To unsubscribe from this list: send
On Thursday 07 February 2013, Grant Likely wrote:
> On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin
> Starting with register (non-data) access. The bus bindings are such
> that on both BE and LE systems a native 16 bit read results in the
> bits being in the correct order. On powerpc, you want to
On Thu, 2013-02-07 at 20:56 +0400, Alexey Brodkin wrote:
> > So, if I'm correct that means that for the data port (specifically
> > copying between RAM and the data port) using ioread16/iowrite16 on the
> > data port results in the correct behaviour. It also means that LE
> > support in the
On Thu, 2013-02-07 at 16:44 +, Grant Likely wrote:
>
> I've just spent some quality time with a piece of paper, and I think
> I've figured it out...
http://linuxplumbers.ubicast.tv/videos/big-and-little-endian-inside-out/
Watch the last part on IO busses
This all has to do which which
On Thu, 2013-02-07 at 15:23 +, Grant Likely wrote:
>
> Maybe. In a separate patch. Hmmm... I guess there isn't an
> ioread16be_rep variant.
Because it would not make sense. The ioread16_rep isn't "LE" ... it
should be usable for any kind if data port since such a fifo should
never require
On Thu, 2013-02-07 at 19:12 +0400, Alexey Brodkin wrote:
> not sure about items for "ace_datain/out_be16" - what about _rep
> options here?
Well, you have a backward wiring of an LE device so you can't use the
_rep variants, unless you ping pong, so you either use a loop of
ioread/write16 (le)
On 02/07/2013 09:16 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 4:56 PM, Alexey Brodkin
wrote:
On 02/07/2013 08:44 PM, Grant Likely wrote:
So, if I'm correct that means that for the data port (specifically
copying between RAM and the data port) using ioread16/iowrite16 on the
data port
On Thu, Feb 7, 2013 at 4:56 PM, Alexey Brodkin
wrote:
> On 02/07/2013 08:44 PM, Grant Likely wrote:
>> So, if I'm correct that means that for the data port (specifically
>> copying between RAM and the data port) using ioread16/iowrite16 on the
>> data port results in the correct behaviour. It
On 02/07/2013 08:44 PM, Grant Likely wrote:
Then that data needs to be stored into memory. This is where things
are different with native 16 bit stores:
On a BE memory system. MSB in byte address 0 and LSB in byte address 1.
On a LE memory system. MSB in byte address 1 and LSB in byte
On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin
wrote:
> On 02/07/2013 07:23 PM, Grant Likely wrote:
>>
>> On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin
>> wrote:
>>>
>>> On 02/07/2013 06:51 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely
wrote:
>
On 02/07/2013 07:23 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin
wrote:
On 02/07/2013 06:51 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely
wrote:
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
wrote:
In fact, the driver already
On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin
wrote:
> On 02/07/2013 06:51 PM, Grant Likely wrote:
>>
>> On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely
>> wrote:
>>>
>>> On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
>>> wrote:
>
> In fact, the driver already knows about this
On 02/07/2013 06:51 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely wrote:
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
wrote:
In fact, the driver already knows about this and figures
out at runtime how the device is wired up to the bus. This is not the
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely wrote:
> On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
> wrote:
>>> In fact, the driver already knows about this and figures
>>> out at runtime how the device is wired up to the bus. This is not the
>>> problem.
>>
>> Except that this is
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2013-02-06 at 10:14 +, Grant Likely wrote:
>>
>> Huh? That makes no sense. This device out in the wild with both big
>> and little endian bus attachments. You can argue all day that one of
>> them is wrong, but it doesn't
On 02/07/2013 06:31 PM, Michal Simek wrote:
The origin patch (after some microblaze ioread/iowrite fixes) works ok,
These additional changes is breaking sysace on microblaze big endian
ml505 16bit mode.
8bit mode just works
Also I have looked at our tree and I see that the mainline kernel
2013/2/7 Alexey Brodkin :
> On 02/07/2013 01:35 AM, Benjamin Herrenschmidt wrote:
>>
>> On Wed, 2013-02-06 at 10:14 +, Grant Likely wrote:
>>>
>>>
>>> Huh? That makes no sense. This device out in the wild with both big
>>> and little endian bus attachments. You can argue all day that one of
2013/2/7 Arnd Bergmann :
> On Thursday 07 February 2013, Geert Uytterhoeven wrote:
>>
>> On Thu, Feb 7, 2013 at 9:01 AM, Michal Simek wrote:
>> > ok. Can you please confirm with me that the same problem is also for
>> > iowrite32be
>> > ioread16be and ioread32be?
>> >
>> > This description seems
On Thu, 2013-02-07 at 23:20 +1100, Benjamin Herrenschmidt wrote:
> For the "swapped" case, I would suggest using ioread16be for the registers
> for the data port, use ioread16_rep followed by a pass of byteswap. I assume
> that this incorrect wiring case only happens on BE platforms right ?
Of
On Thu, 2013-02-07 at 16:09 +0400, Alexey Brodkin wrote:
>
> BTW I've just realized that in case if there's no bridge between CPU and
> CF-controller or if this bridge is "transparent" (does no swapping
> neither bytes nor bits) our data accessors here should be changed.
>
> Isn't it strange in
On 02/07/2013 01:35 AM, Benjamin Herrenschmidt wrote:
On Wed, 2013-02-06 at 10:14 +, Grant Likely wrote:
Huh? That makes no sense. This device out in the wild with both big
and little endian bus attachments. You can argue all day that one of
them is wrong, but it doesn't matter. It exists,
On Thursday 07 February 2013, Geert Uytterhoeven wrote:
>
> On Thu, Feb 7, 2013 at 9:01 AM, Michal Simek wrote:
> > ok. Can you please confirm with me that the same problem is also for
> > iowrite32be
> > ioread16be and ioread32be?
> >
> > This description seems to me correct for BE and LE.
> >
On Thu, Feb 7, 2013 at 9:01 AM, Michal Simek wrote:
> ok. Can you please confirm with me that the same problem is also for
> iowrite32be
> ioread16be and ioread32be?
>
> This description seems to me correct for BE and LE.
> #define ioread16be(addr) __be16_to_cpu(__raw_readw(addr))
> #define
On 02/07/2013 08:38 AM, Geert Uytterhoeven wrote:
On Thu, Feb 7, 2013 at 8:23 AM, Michal Simek wrote:
#define iowrite16be(v, addr) iowrite16(be16_to_cpu(v), (addr))
#define iowrite16(v, addr) writew((v), (addr))
#define writew(b,addr) __raw_writew(__cpu_to_le16(b),addr)
static inline
On Thu, 2013-02-07 at 19:12 +0400, Alexey Brodkin wrote:
not sure about items for ace_datain/out_be16 - what about _rep
options here?
Well, you have a backward wiring of an LE device so you can't use the
_rep variants, unless you ping pong, so you either use a loop of
ioread/write16 (le) and
On Thu, 2013-02-07 at 15:23 +, Grant Likely wrote:
Maybe. In a separate patch. Hmmm... I guess there isn't an
ioread16be_rep variant.
Because it would not make sense. The ioread16_rep isn't LE ... it
should be usable for any kind if data port since such a fifo should
never require
On Thu, 2013-02-07 at 16:44 +, Grant Likely wrote:
I've just spent some quality time with a piece of paper, and I think
I've figured it out...
http://linuxplumbers.ubicast.tv/videos/big-and-little-endian-inside-out/
Watch the last part on IO busses
This all has to do which which
On Thu, 2013-02-07 at 20:56 +0400, Alexey Brodkin wrote:
So, if I'm correct that means that for the data port (specifically
copying between RAM and the data port) using ioread16/iowrite16 on the
data port results in the correct behaviour. It also means that LE
support in the current driver
On Thursday 07 February 2013, Grant Likely wrote:
On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin
Starting with register (non-data) access. The bus bindings are such
that on both BE and LE systems a native 16 bit read results in the
bits being in the correct order. On powerpc, you want to do a
On Thursday 07 February 2013, Michal Simek wrote:
Subject: asm-generic: io: Fix ioread16/32be and iowrite16/32be
Ok, thanks. If you don't mind, I think this can just go with the other patches
for xsysace that come out of this discussion.
Arnd
--
To unsubscribe from this list: send the
On Fri, Feb 8, 2013 at 12:05 AM, Arnd Bergmann a...@arndb.de wrote:
The same is true for the data port. A BE read does the right thing on
a BE platform, and LE read on a LE platform. (again, this is all about
bus attachment). However, the difference is what is then done with the
data.
Well,
On Thu, Feb 7, 2013 at 11:05 PM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 07 February 2013, Grant Likely wrote:
On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin
Of course, as long as the driver is only ever used to access
the same non-removable block device and you don't change
the
On Thu, Feb 7, 2013 at 5:22 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
On 02/07/2013 09:16 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 4:56 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
On 02/07/2013 08:44 PM, Grant Likely wrote:
So, if I'm correct that means that for
On 02/07/2013 08:38 AM, Geert Uytterhoeven wrote:
On Thu, Feb 7, 2013 at 8:23 AM, Michal Simek mon...@monstr.eu wrote:
#define iowrite16be(v, addr) iowrite16(be16_to_cpu(v), (addr))
#define iowrite16(v, addr) writew((v), (addr))
#define writew(b,addr) __raw_writew(__cpu_to_le16(b),addr)
On Thu, Feb 7, 2013 at 9:01 AM, Michal Simek mon...@monstr.eu wrote:
ok. Can you please confirm with me that the same problem is also for
iowrite32be
ioread16be and ioread32be?
This description seems to me correct for BE and LE.
#define ioread16be(addr) __be16_to_cpu(__raw_readw(addr))
On Thursday 07 February 2013, Geert Uytterhoeven wrote:
On Thu, Feb 7, 2013 at 9:01 AM, Michal Simek mon...@monstr.eu wrote:
ok. Can you please confirm with me that the same problem is also for
iowrite32be
ioread16be and ioread32be?
This description seems to me correct for BE and LE.
On 02/07/2013 01:35 AM, Benjamin Herrenschmidt wrote:
On Wed, 2013-02-06 at 10:14 +, Grant Likely wrote:
Huh? That makes no sense. This device out in the wild with both big
and little endian bus attachments. You can argue all day that one of
them is wrong, but it doesn't matter. It exists,
On Thu, 2013-02-07 at 16:09 +0400, Alexey Brodkin wrote:
BTW I've just realized that in case if there's no bridge between CPU and
CF-controller or if this bridge is transparent (does no swapping
neither bytes nor bits) our data accessors here should be changed.
Isn't it strange in
On Thu, 2013-02-07 at 23:20 +1100, Benjamin Herrenschmidt wrote:
For the swapped case, I would suggest using ioread16be for the registers
for the data port, use ioread16_rep followed by a pass of byteswap. I assume
that this incorrect wiring case only happens on BE platforms right ?
Of course
2013/2/7 Arnd Bergmann a...@arndb.de:
On Thursday 07 February 2013, Geert Uytterhoeven wrote:
On Thu, Feb 7, 2013 at 9:01 AM, Michal Simek mon...@monstr.eu wrote:
ok. Can you please confirm with me that the same problem is also for
iowrite32be
ioread16be and ioread32be?
This
2013/2/7 Alexey Brodkin alexey.brod...@synopsys.com:
On 02/07/2013 01:35 AM, Benjamin Herrenschmidt wrote:
On Wed, 2013-02-06 at 10:14 +, Grant Likely wrote:
Huh? That makes no sense. This device out in the wild with both big
and little endian bus attachments. You can argue all day that
On 02/07/2013 06:31 PM, Michal Simek wrote:
The origin patch (after some microblaze ioread/iowrite fixes) works ok,
These additional changes is breaking sysace on microblaze big endian
ml505 16bit mode.
8bit mode just works
Also I have looked at our tree and I see that the mainline kernel
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2013-02-06 at 10:14 +, Grant Likely wrote:
Huh? That makes no sense. This device out in the wild with both big
and little endian bus attachments. You can argue all day that one of
them is wrong,
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
In fact, the driver already knows about this and figures
out at runtime how the device is wired up to the bus. This is not the
On 02/07/2013 06:51 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
In fact, the driver already knows about this and figures
out at runtime how the
On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
On 02/07/2013 06:51 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On 02/07/2013 07:23 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
On 02/07/2013 06:51 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin
On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
On 02/07/2013 07:23 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
On 02/07/2013 06:51 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 2:39 PM, Grant
On 02/07/2013 08:44 PM, Grant Likely wrote:
Then that data needs to be stored into memory. This is where things
are different with native 16 bit stores:
On a BE memory system. MSB in byte address 0 and LSB in byte address 1.
On a LE memory system. MSB in byte address 1 and LSB in byte
On Thu, Feb 7, 2013 at 4:56 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
On 02/07/2013 08:44 PM, Grant Likely wrote:
So, if I'm correct that means that for the data port (specifically
copying between RAM and the data port) using ioread16/iowrite16 on the
data port results in the
On 02/07/2013 09:16 PM, Grant Likely wrote:
On Thu, Feb 7, 2013 at 4:56 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
On 02/07/2013 08:44 PM, Grant Likely wrote:
So, if I'm correct that means that for the data port (specifically
copying between RAM and the data port) using
On Thu, Feb 7, 2013 at 8:23 AM, Michal Simek wrote:
>>> #define iowrite16be(v, addr) iowrite16(be16_to_cpu(v), (addr))
>>> #define iowrite16(v, addr) writew((v), (addr))
>>> #define writew(b,addr) __raw_writew(__cpu_to_le16(b),addr)
>>>
>>> static inline void __raw_writew(u16 b, volatile
2013/2/6 Geert Uytterhoeven :
> On Wed, Feb 6, 2013 at 6:40 PM, Michal Simek wrote:
>> One question regarding to asm-generic/io.h about iowrite16be implementation
>>
>> #define iowrite16be(v, addr) iowrite16(be16_to_cpu(v), (addr))
>> #define iowrite16(v, addr) writew((v), (addr))
>>
On Wed, 2013-02-06 at 10:14 +, Grant Likely wrote:
>
> Huh? That makes no sense. This device out in the wild with both big
> and little endian bus attachments. You can argue all day that one of
> them is wrong, but it doesn't matter. It exists, is used, and must be
> supported.
No. That's
On Wed, Feb 6, 2013 at 6:40 PM, Michal Simek wrote:
> One question regarding to asm-generic/io.h about iowrite16be implementation
>
> #define iowrite16be(v, addr) iowrite16(be16_to_cpu(v), (addr))
> #define iowrite16(v, addr) writew((v), (addr))
> #define writew(b,addr)
On 02/07/2013 01:34 AM, Arnd Bergmann wrote:
On Wednesday 06 February 2013 17:21:37 Michal Simek wrote:
I have looked at the patches from more practical side and I have tested it on
microblaze big endian in 16bit mode and I have found that sysace driver
stop to work.
After that I have looked
On Wednesday 06 February 2013 17:21:37 Michal Simek wrote:
> I have looked at the patches from more practical side and I have tested it on
> microblaze big endian in 16bit mode and I have found that sysace driver
> stop to work.
> After that I have looked at ioread/iowrite microblaze
On Wednesday 06 February 2013, Grant Likely wrote:
> The only problem that I see is that the ARM and Microblaze
> ioread16be/iowrite16be helpers are missing barriers which smells like
> a bug and should be fixed.
It looks correct to me on ARM, we use the same barriers in ioread and
iowrite that
2013/2/6 Grant Likely :
> On Tue, Feb 5, 2013 at 3:12 PM, Arnd Bergmann wrote:
>> On Tuesday 05 February 2013 18:03:31 Alexey Brodkin wrote:
>>> The Xilinx System ACE Compact Flash chip is a true little-endian device
>>> and the PLB is a big-endian bus. Therefore the XPS System ACE Interface
>>>
On Wednesday 06 February 2013, Grant Likely wrote:
> The driver already handles this. It has three sets of accessors;
> 8-bit, 16-bit LE and 16-bit BE and when doing 16-bit it figures out
> on its own which set to use at runtime. There is nothing controversial
> here. The only problem is that the
On Wednesday 06 February 2013, Geert Uytterhoeven wrote:
> On Wed, Feb 6, 2013 at 12:03 AM, Arnd Bergmann wrote:
> > On Tuesday 05 February 2013, Michal Simek wrote:
> >> I want to be sure about this. I have parsed this again with closer look and
> >> seems to me that ioread32 is equal to readl
1 - 100 of 162 matches
Mail list logo
