[RFC PATCH 15/15] iommu/exynos: update to use iommu big-endian

[RFC PATCH 15/15] iommu/exynos: update to use iommu big-endian

[Matthew Leach]

From: Ben Dooks <ben.dooks@codethink.co.uk>

Add initial support for big endian by always writing the pte
in le32. Note, revisit if hardware capable of doing big endian
fetches.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: iommu@lists.linux-foundation.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org (open list)
---
 drivers/iommu/exynos-iommu.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 5ecc86c..dd8b3b3 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -54,6 +54,10 @@ typedef u32 sysmmu_pte_t;
 #define lv2ent_small(pent) ((*(pent) & 2) == 2)
 #define lv2ent_large(pent) ((*(pent) & 3) == 1)
 
+#ifdef CONFIG_BIG_ENDIAN
+#warning "revisit driver if we can enable big-endian ptes"
+#endif
+
 /*
  * v1.x - v3.x SYSMMU supports 32bit physical and 32bit virtual address spaces
  * v5.0 introduced support for 36bit physical address space by shifting
@@ -716,7 +720,7 @@ static inline void update_pte(sysmmu_pte_t *ent, sysmmu_pte_t val)
 {
 	dma_sync_single_for_cpu(dma_dev, virt_to_phys(ent), sizeof(*ent),
 				DMA_TO_DEVICE);
-	*ent = val;
+	*ent = cpu_to_le32(val);
 	dma_sync_single_for_device(dma_dev, virt_to_phys(ent), sizeof(*ent),
 				   DMA_TO_DEVICE);
 }
-- 
2.8.3

Re: [RFC PATCH 15/15] iommu/exynos: update to use iommu big-endian

[Marek Szyprowski]

Hi


On 2016-06-08 20:31, Matthew Leach wrote:
> From: Ben Dooks <ben.dooks@codethink.co.uk>
>
> Add initial support for big endian by always writing the pte
> in le32. Note, revisit if hardware capable of doing big endian
> fetches.
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>

Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>

Just to keep my curiosity satisfied - what's the reason to use
big-endian on ARM?

Good luck with fixing the kernel and userspace codes, which usually
assume little-endian is the only possible order!

> ---
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org (open list)
> ---
>   drivers/iommu/exynos-iommu.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 5ecc86c..dd8b3b3 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -54,6 +54,10 @@ typedef u32 sysmmu_pte_t;
>   #define lv2ent_small(pent) ((*(pent) & 2) == 2)
>   #define lv2ent_large(pent) ((*(pent) & 3) == 1)
>   
> +#ifdef CONFIG_BIG_ENDIAN
> +#warning "revisit driver if we can enable big-endian ptes"
> +#endif
> +

This warning can be removed. There is no way to force SYSMMU to operate with
big-endian PTEs according to the datasheet.

>   /*
>    * v1.x - v3.x SYSMMU supports 32bit physical and 32bit virtual address spaces
>    * v5.0 introduced support for 36bit physical address space by shifting
> @@ -716,7 +720,7 @@ static inline void update_pte(sysmmu_pte_t *ent, sysmmu_pte_t val)
>   {
>   	dma_sync_single_for_cpu(dma_dev, virt_to_phys(ent), sizeof(*ent),
>   				DMA_TO_DEVICE);
> -	*ent = val;
> +	*ent = cpu_to_le32(val);
>   	dma_sync_single_for_device(dma_dev, virt_to_phys(ent), sizeof(*ent),
>   				   DMA_TO_DEVICE);
>   }

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [RFC PATCH 15/15] iommu/exynos: update to use iommu big-endian

[Ben Dooks]

On 09/06/16 07:51, Marek Szyprowski wrote:
> Hi
> 
> 
> On 2016-06-08 20:31, Matthew Leach wrote:
>> From: Ben Dooks <ben.dooks@codethink.co.uk>
>>
>> Add initial support for big endian by always writing the pte
>> in le32. Note, revisit if hardware capable of doing big endian
>> fetches.
>>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> 
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> 
> Just to keep my curiosity satisfied - what's the reason to use
> big-endian on ARM?

Because we can. It was interesting to try.

> Good luck with fixing the kernel and userspace codes, which usually
> assume little-endian is the only possible order!

We did a BE8 build of the baserock userspace a year or two ago
and found mostly it just worked. I think Matt is using that image
for testing the work he's been doing.

I've no idea if we would ever bother trying to build Debian for BE8
or similar, as not sure it would be worth trying.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

Re: [RFC PATCH 15/15] iommu/exynos: update to use iommu big-endian

[Joerg Roedel]

On Wed, Jun 08, 2016 at 07:31:10PM +0100, Matthew Leach wrote:
> From: Ben Dooks <ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
> 
> Add initial support for big endian by always writing the pte
> in le32. Note, revisit if hardware capable of doing big endian
> fetches.
> 
> Signed-off-by: Ben Dooks <ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
> ---
> Cc: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Cc: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
> Cc: Kukjin Kim <kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Krzysztof Kozlowski <k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list)
> ---
>  drivers/iommu/exynos-iommu.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Applied, thanks.