On 7/5/21 9:33 PM, Mark Cave-Ayland wrote:
> On 05/07/2021 08:52, Mark Cave-Ayland wrote:
>
>> I think the problem is because of the interaction of
>> .impl.max_access_size = 2 and the it_shift property specifying a
>> stride of 4 bytes: when the 4 byte access is split into 2 x 2 byte
>> accesses
On 7/5/21 3:44 AM, Finn Thain wrote:
> On Sun, 4 Jul 2021, Mark Cave-Ayland wrote:
>
>> Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" assumed that all
>> accesses
>> to the registers were 32-bit
>
> As I said, that assumption was not made there.
>
> If commit 3fe9a838ec is deficient
On 05/07/2021 08:52, Mark Cave-Ayland wrote:
I think the problem is because of the interaction of .impl.max_access_size = 2 and
the it_shift property specifying a stride of 4 bytes: when the 4 byte access is split
into 2 x 2 byte accesses then for a read reg = addr >> s->it_shift causes the sec
On 05/07/2021 02:44, Finn Thain wrote:
On Sun, 4 Jul 2021, Mark Cave-Ayland wrote:
Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" assumed that all
accesses
to the registers were 32-bit
As I said, that assumption was not made there.
If commit 3fe9a838ec is deficient it is probably
On Sun, 4 Jul 2021, Mark Cave-Ayland wrote:
> Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" assumed that all
> accesses
> to the registers were 32-bit
As I said, that assumption was not made there.
If commit 3fe9a838ec is deficient it is probably because I am unaware of
the ability
Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" assumed that all
accesses
to the registers were 32-bit but this is actually not the case. The access size
is
determined by the CPU instruction used and not the number of physical address
lines.
The big_endian workaround applied to the regi
