[PATCH] ARM: OMAP4: sleep: byteswap data for big-endian

[Taras Kondratiuk]

On 14 January 2014 23:13, Nishanth Menon <nm at ti.com> wrote:
> On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar
> <santosh.shilimkar at ti.com> wrote:
>>
>>> ok.. some sort of Linaro thing about which I have no background about
>>> - but dont really care in this context.
>>>
>> Nothing related Linaro. Its just that platforms are supporting ARM BE
>> mode and Linaro folks had working patches for Panda. So I suggested
>> to get them on the lists.
>
> I tend to think -> is this with OFF mode and CPUidle completely
> working? All context save and restore works with this? on HS and GP
> devices with BE mode builds? works on SDP4430,60 variations,
> considered reuse with AM43xx which could use parts of that logic?
>
> I mean to indicate that terms like "works on panda" tends always to be relative.

Nishanth, let's be objective here.
CPUidle on 4460 does *not* work in mainline for at least two kernel releases
even for LE [1]. That fix exists because that "one group of folks"
faced the issue
during BE testing. Looks like not much people care about CPUIdle on OMAP4.

> It is nice to see it as a proof of concept, but I'd hate to see some
> dead code lying around in kernel and folks blindly following suit and
> introducing macros for new assembly for a feature that in practice
> just one group of folks care about and creates additional burden for
> rest of folks trying to keep that functionality going as we jump from
> one "device tree" style churn to another "framework"? Not to mean that
> good features should be kept away.. but personally, I could not find
> convincing arguments in this case..

In general I understand your concerns from previous e-mails, but I don't
see a point to spend time for a generic solution for a single user.
If there will be other platforms which need similar changes, then we can
think of some generic solution. Let's drop this patch for now.
We can just disable CPUidle for BE tasks or keep this patch forked.

[1] https://lkml.org/lkml/2013/10/22/401

-- 
Regards,
Taras Kondratiuk