[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHTX3dKn7iwbHyOnpJ4XiNbK766oqrJW06kH7XrAW2TJtOhehA@mail.gmail.com>
Date: Tue, 12 Feb 2013 13:14:15 +0100
From: Michal Simek <monstr@...str.eu>
To: Arnd Bergmann <arnd@...db.de>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
Grant Likely <grant.likely@...retlab.ca>,
Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Vineet Gupta <Vineet.Gupta1@...opsys.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
dahinds@...rs.sourceforge.net
Subject: Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16
with generic iowrite(read)8/16(be)
2013/2/12 Arnd Bergmann <arnd@...db.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 the CPU does at the time.
>>
>> 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 be setup at run-time.
>
> I did not mean you have to use a run-time detection here, although
> that is often the easiest solution. If you know the endianess of
> a device for a specific architecture or platform, it is totally
> fine to pick that endianess at compile-time and use e.g. the
> readl_relaxed() accessors on ARM to give you the lowest access
> latency.
ok but still there should be well defined how to do it. Let's say
generic Kconfig option.
Or maybe there is also third option to modified code to use proper writes.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists