Hi Tom,
On Tue, 5 Feb 2013 09:58:52 -0500, Tom Rini trini@ti.com wrote:
On Mon, Feb 04, 2013 at 03:19:56PM +0100, Albert ARIBAUD wrote:
Hi Nikita,
On Mon, 04 Feb 2013 14:37:06 +0200, Nikita Kiryanov nikita@compulab.co.il wrote:
Hi Albert,
On 02/04/2013 01:57 PM, Albert ARIBAUD wrote:
IIRC, you has submitted a fix so that BMP loads would result in correctly aligned fields and thus no need for accessors. Why this change of mind?
I did mention that I consider that fix as temporary. I believe this fix is better because it addresses the issue everywhere and does so in a more maintainable way (does not require the address fix to be duplicated everywhere there is a problem).
I actually like the new fix less, as it adds an API where there is no need of one -- it's not like the implementation of BMP is at risk of changing. What is the problem in fixing the load address at load time and then passing this fixed address around?
OK, so I'm wondering. Isn't this an example of where our idea that unaligned accesses are a software problem to fix, rather than an area to let the hardware fixup for us, when able, is wrong?
In other words, a real life example of why we should go with -munaligned-access being set for v7, set the HW bit and let things go?
I feel this is addressed to me. :)
And no, I don't think the BMP issue should be solved by relaxing HW constraints. BMP is not a HW-enforced or protocol format.
Anyway, as I said, even if we really could not avoid misaligned fields (and we know at least two ways we could), then the solution would not be to flip a general HW switch controlling all accesses, since only the BMP accesses are a problem! We could just make sure we access the poorly aligned fields through dedicated unaligned accessors, e.g. readl_u(&field) / writel_u(&field).
Amicalement,