[PATCH v2] ARM: tlb: ASID macro should give 32bit result for BE correct operation

[Santosh Shilimkar]

Ben, Victor,

On Tuesday 08 October 2013 02:59 AM, Ben Dooks wrote:
> On 08/10/13 00:49, Santosh Shilimkar wrote:
>> Victor,
>>
>> On Monday 07 October 2013 12:37 PM, Victor Kamensky wrote:
>>> On 7 October 2013 08:57, Ben Dooks<ben.dooks at codethink.co.uk>  wrote:
>>>> On 07/10/13 17:48, Victor Kamensky wrote:
>>>>>
>>>>> Hi Will, Ben, Russell, Thomas,
>>>>>
>>>>> Please review second version of patch that fixes TLB asid issue in big
>>>>> endian
>>>>> V7 image.
>>>>>
>>>>> Changes from v1:
>>>>>      Note previous patch subject line was 'ARM: tlb:
>>>>>      __flush_tlb_mm need to use int asid var for BE correct operation'
>>>>>
>>>>>      Added 'unsigned int' cast into ASID macro itself rather
>>>>>      then use intermediate 'int' variable in __flush_tlb_mm function.
>>>>>      This is done per v1 patch discussion at
>>>>>
>>>>>
>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/202583.html
>>>>>
>>>>> Tested with Linaro BE topic branch on Arndale board. Both LE and BE
>>>>> images were tested.
>>>>
>>>>
>>>> If you are booting on the Arndale board, is there a patch to mark
>>>> the relevant Exynos devices as BE capable?
>>>
>>> Arndale need massive fixes in their BSP layer to be endian agnostic
>>> ARM V7 platform. Unfortunate it is not as simple as with few others
>>> that already marked as BE capable.
>>>
>>> Please see
>>> https://git.linaro.org/gitweb?p=people/victor.kamensky/linux-linaro-tracking-be.git;a=shortlog;h=refs/heads/llct-be-topic
>>> Mostly it is __raw_xxx conversion to xxx_relaxed, but there are
>>> more subtle changes (some of them similar to changs that you've
>>> done for other platforms). Also there are known unfixed issues like
>>> disabling CONFIG_MMC_DW_IDMAC config because idmac
>>> DMA related code is not endian agnostic yet (btw interesting class
>>> of BE related problem that was not seen before).
>>>
>>> In Linaro we use Arndale and Pandaboard as reference platforms
>>> therefore we have BE BSP fixes in our tree. But I am not sure
>>> what is fate of those in long term. Also we consider these as
>>> example of BSP changes that other BSP need to do.
>>>
>>> If Exynos and OMAP owners will have any interest for BE images,
>>> and would like to see these changes in main line, we gladly
>>> will work on this. Otherwise changes like this can mess up with
>>> BSP ongoing drivers development.
>>>
>> BE support in mainline is definitely we are interested for OMAP
>> and rest of the TI SoCs.
> 
> It would be great to get some more SoCs supported.
> 
>>> I think above position is consistent with similar discussion on
>>> some of BE related threads - changing BSP to support BE mode
>>> is BSP owners call.
>>>
>> Am just wondering a better method than the patch [1] which touches
>> many drivers for readl/writel() replacement. Drivers are using
>> that as standard based on device driver guide and was thinking
>> we should not change that rule to support BE. We definitely need
>> to get the byte swap achieved but probably through some other
>> means.
> 
> read{b,w,l} and write{b,w,l} work fine.  It is the use of the
> __raw_ versions that is the problem. I will be publishing a
> paper on this for ARM TechCon.
> 
> I have not yet suggested we also change the __raw functions as
> we are not yet sure if there are places where we could end up
> with mixed-endian systems.
>
Ok. Replacing _raw functions shouldn't be problem if we plan do
that but as you said we might have hardwares IPs which can support
endian swapping at IP level.

Will keep an eye on your updates on this part.

Regards,
Santosh