13:06 <milkylainen> Hmm. Can one regulate the transaction sizes on AMBA->system busses to match whatever page sizes are out in memory mapped devices? Or is the access always cache line sized, regardless?

13:11 <robmur01> it's up to the thing generating the transaction

13:14 <milkylainen> hmm. ok. So like the actual instructions and whatever load sizes they do? I was thinking since this is memory mapped it'll do a cacheline sized pull regardless.

13:15 <milkylainen> Maybe that's just within the realm of the cpu cache coherency bus.

13:16 <robmur01> For a CPU, if it's mapped as Device memory, then loads/store instructions should generate transactions of the exact corresponding size. For Normal memory, you're largely at the mercy of whatever the CPU feels like doing

13:16 <robmur01> (e.g. normal non-cacheable stores could still be merged in a write buffer)

13:17 <robmur01> A DMA engine, on the other hand, may allow you to program specific burst sizes for a transfer

13:20 <milkylainen> mm.

13:24 <milkylainen> So how would a parallel nor flash be treated like? there is no dma for the generic physmap mtd?

13:25 <rfs613> page size of 4kB is much larger than typical burst size on AMBA/AXI, which IIRC is max of 256 bytes

16:10 <HdkR> Has there been any work towards having *at variants of the various xattr syscalls? {l,}{get,set,list,remove}xattr?

16:22 <milkylainen> rfs613: I was refering to the page burst mode of nor flash:es and their sizes. Typically between 16-64 bytes. Sorry for the confusion.

16:28 <rfs613> milkylainen: ah that would probably be a better fit then ;-) but often you don't have that kind of control over the interconnect, so I wouldn't try to reply on burst sizes happening to line up.

17:19 <milkylainen> So.. Page mode on a parallel attached NOR is a semi useless feature on a modern machine? :)