diff mbox

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

Message ID 20160608183110.13851-16-matthew@mattleach.net (mailing list archive)
State Not Applicable
Headers show

Commit Message

Matthew Leach June 8, 2016, 6:31 p.m. UTC
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(-)

Comments

Marek Szyprowski June 9, 2016, 6:51 a.m. UTC | #1
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
Ben Dooks June 9, 2016, 8:14 a.m. UTC | #2
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.
Joerg Roedel June 21, 2016, 9:59 a.m. UTC | #3
On Wed, Jun 08, 2016 at 07:31:10PM +0100, 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>
> ---
> 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(-)

Applied, thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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);
 }