[U-Boot] [PATCH v1 0/9] MIPS: sync asm header files with linux-4.4

[Daniel Schwierzeck <daniel.schwierzeck@gmail.com>]

Am Montag, den 11.01.2016, 22:29 +0800 schrieb Wills Wang:
> 
> On 01/11/2016 06:55 PM, Purna Chandra Mandal wrote:
> > On 01/09/2016 10:02 PM, Daniel Schwierzeck wrote:
> > 
> > > This patch series updates all MIPS asm header files containing
> > > I/O code as well as processor, register and assembly definitions.
> > > The source of the update are the MIPS asm header files of linux
> > > -4.4.
> > > 
> > > The main goal is to get a complete set of I/O accessors on MIPS
> > > and
> > > to support platform-specific address spaces and mappings. Also a
> > > working ioremap() implementation will be added, which supports
> > > platform-specific callbacks. Furthermore support for bit
> > > manipulating
> > > I/O accessors (clrbits_X, setbits_X, clrsetbits_X) will be added.
> > > 
> > > The patch series is also available on git://git.denx.de/u-boot
> > > -mips.git
> > > in branch mips_io_v1 and based on next branch.
> > > 
> > > @Wills
> > > I changed map_physmem() and used the new and working ioremap()
> > > function.
> > > Thus you can discard your patch.
> > > 
> > > @Wills, Purna
> > > You can use now ioremap() directly in your drivers. You can also
> > > use the
> > > new bit manipulating I/O accessors as requested by Marek. Please
> > > rebase
> > > and test your patch series against this series, thanks.
> > Thanks Daniel.
> > Rebased my PIC32 patches on 'mips_io_v1' branch and tested
> > functionality to work fine.
> > Also updated drivers to use ioremap() (instead of pic32_ioremap())
> > and clrsetbits_le()
> > wherever applicable.
> > 
> Should we use these macros with the explicitly endianess in driver?
> if 
> chip can
> select big-endian and little-endian by hardware pin, i think driver
> may 
> not work
> properly, what's your idea?

that depends on the SoC and the peripheral. 

Peripherals usually have a fixed endianess and the bus between CPU and
peripheral converts the CPU endianess to peripheral one in hardware. In
that case a driver should never swap. You could use the
__raw_readX/__raw_writeX variants. Or you could implement this
explicitely with readX/writeX resp. readX_be/writeX_be and make this
configurable at compile time or runtime. 

For an example you could look at kernel commit
 37786c7fee40771d13901de129af7e084ed48b55.

If the bus does not convert the endianess, a driver must explicitely
use I/O accessors according to the peripheral endianess.

-- 
- Daniel