Skip to content

MIPS: sync asm header files with linux-4.4

Daniel Schwierzeck u-boot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 9 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 9 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

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

Am Montag, den 11.01.2016, 22:29 +0800 schrieb Wills Wang:

Quoted 39 lines · Purna Chandra Mandal
Quoted 30 lines · Daniel Schwierzeck
Quoted 23 lines

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.

Quoted 6 lines

@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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Signature · 1 line
- Daniel

Read the cover letter in its thread