
On Tue, Aug 7, 2018 at 4:31 PM Daniel Schwierzeck daniel.schwierzeck@gmail.com wrote:
2018-08-07 9:36 GMT+02:00 Mario Six mario.six@gdsys.cc:
Hi Anatolij, On Mon, Aug 6, 2018 at 9:12 PM Anatolij Gustschin agust@denx.de wrote:
Hi Mario,
On Fri, 3 Aug 2018 10:01:12 +0200 Mario Six mario.six@gdsys.cc wrote: ...
+int regmap_raw_read(struct regmap *map, uint offset, void *valp, size_t val_len) +{
void *ptr;
ptr = map_physmem(map->ranges[0].start + offset, val_len, MAP_NOCACHE);
switch (val_len) {
case REGMAP_SIZE_8:
*((u8 *)valp) = in_8((u8 *)ptr);
break;
case REGMAP_SIZE_16:
*((u16 *)valp) = in_le16((u16 *)ptr);
break;
case REGMAP_SIZE_32:
*((u32 *)valp) = in_le32((u32 *)ptr);
this breaks building for MIPS:
https://travis-ci.org/vdsao/u-boot-video/jobs/412722192#L869
I see. MIPS apparently doesn't implement any of the in/out functions at all. But since the necessary __raw_read/__raw_write functions exist, it's just a matter of a few lines to add them. I'll add a patch that will fix this.
why don't you directly use readb(), readw(), readl() etc.? What about 64 Bit registers (readq())?
readb/readw/etc. are not endianness-safe, so the regmap functions would return different values on a big-endian and a little-endian system for the same IC, and since the vast majority of IC registers are little-endian, having LE as the default seems reasonable. That does make it a bit more complicated to implement drivers for big-endian register spaces (wrapping values in le*_to_cpu), but for everything else the default will work as expected.
The 64-bit support is a good point. It could be added with a few lines, so if it's needed I could.
There also seems to be a warning about a format specifier on MIPS, I'll fix that as well.
To make things less confusing, I'll import your v5 of "misc: Sort Makefile entries" and send a full v6 series.
Anatolij
Best regards, Mario
- Daniel
Best regards, Mario