[U-Boot] [PATCH] arm: enable unaligned access on ARMv7

[V, Aneesh]

Hi Albert,

On Sat, Jun 23, 2012 at 2:01 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hi Aneesh,
>
> On Fri, 22 Jun 2012 15:13:39 -0700, Aneesh V <aneesh at ti.com> wrote:
>> On 06/22/2012 03:11 PM, Aneesh V wrote:
>> > +Tom
>> >
>> > Hi Lucas,
>> >
>> > On 06/22/2012 04:47 AM, Lucas Stach wrote:
>> >> Hi Albert,
>> >>
>> >> Am Freitag, den 22.06.2012, 13:16 +0200 schrieb Albert ARIBAUD:
>
>> >>> I am not too happy with enabling a lax behavior only to avoid an
>> >>> issue which apparently is diagnosed and could / should be fixed at
>> >>> its root. Can you point me to the relevant LKML thread
>> >>> so that I get the details and understand what prevents fixing
>> >>> this by 'simply' aligning the USB structures?
>> >>
>> >> I'm with you that the issue for this particular fault that I ran
>> >> into should be fixed at it's root and I will do so as soon as I
>> >> have enough time to do so, i.e. within the next three weeks.
>> >> You can find a thread about this here:
>> >> https://lkml.org/lkml/2011/4/27/278
>
> From what I understand, the issue was not to allow unaligned access at
> the hardware level, but to modify the attributes of the structure,
> first by removing the packed attribute, then by reinstating the packed
> attribute along with align(4).
>
>> >> But apart from this, we certainly have situations where we have
>> >> unaligned accesses that are justified and could not be removed.
>> >> [...]
>> >> I cannot see how enabling a hardware feature can be seen as
>> >> allowing of lax behaviour. As some of the USB structs are used to
>> >> access hardware registers, we can not align every struct there.
>
> If the access is in true RAM, then we can always realign the data; and
> I don't know of memory-mapped registers which would be unaligned wrt
> their width. If some USB controller is designed so, then the fix should
> only and explicitly affect that controller, because we don't know it it
> will always be used with an ARM implementation that can do unaligned
> accesses.
>
>> > I think this issue was discussed before here(I haven't gone through
>> > all the details of your problem, but it looks similar). And I think
>> > Tom fixed this by wrapping the problematic accesses with
>> > get/set_unaligned().
>
> Could be a solution if the structures themselves cannot be fixed.
>
>> > Please look at this thread, especially starting from my post
>> > reporting the OMAP4 regression:
>> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/113347/
>
> Thanks for the reference. There seems to have been no confirmation that
> the structures involved needed packing in the first place, and my
> general opinion on packing structures is "DO NOT" -- if packing a
> structure has an effect, it can alway be to de-align some field, which
> barely makes sense as far as HW prgramming is concerned (I can only see
> some point in packing a struct when you deal with network layer 7 data
> in very special cases).
>
>> BTW, I agree that enabling un-aligned access is not a bad idea.
>
> Just being "not a bad idea" is not enough for me to accept this. It will
> have to be the sole sound solution to a problem, and at this point, I
> do not think it is as far as USB structure mis-alignement issues are
> concerned.

My point is that enabling un-aligned accesses in itsown merit
is not a bad idea, not as a solution to this problem. I have seen
it being enabled in HLOS environment. TI's Symbian port for
instance had it enabled for OMAP3. I don't know why Linux too
shoudln't take advantage of such hw features.
Perhaps you don't want to take it at this point of time to force
the real solution to the USB problem, which is reasonable.