[PATCH v10 0/3] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
These patches are successfully compiled in linux-samsung.git/for-next branch You can find the git repo. In http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=summary Changes since v9: - Split the first patch into 2 patches. One removes System MMU driver from arch/arm/plat- tree and the other modifies and adds platform device definitions in arch/arm/mach tree - Some bug fixes - Change gsc for Exynos4 to fimc Changes since v8: - exynos_iommu_map/unmap() just works for the page sizes that System MMU supports. (Joerg's comment) - 1 platform device for 1 H/W though a multimedia accelerator with several System MMUs attached. This make controlling System MMU simpler. - Information between System MMU and the accelerators: Shifted to accelerator's device structure from System MMU's Changes since v7: - Rebased with the recent commits of the following git branches * git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/next * git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git/for-next - Changed magic numbers into macros - Setting owner of a System MMU in 'iommu' field of dev_archdata - Verbose message in the default fault handler - Some bug fixes. Changes since v6: - Totally rewrite exynos_iommu_map() and exynos_iommu_unmap() according to the change in iommu_map() and iommu_unmap(). - Change special slab for Lv2 page table to kmalloc(). Changes since v5: - Relation between device and a domain become n:1 (Joerg's comment) - Implements iommu_commit(). -- Removed Changes since v4: - exynos_iommu_unmap()returns unmapped size in page order (Ohad Ben-Cohen's comment) - Fixed typo error of resource names - Fixed missing #includemach/sysmmu.h in arch/arm/mach-exynos4/mach-armlex4210.c Changes since v3: - Used DEFINE_RES_MEM and DEFINE_RES_IRQ macros to define resources of System MMU (Russell King's comment) - Fixed removal of CONFIG_S5P_SLEEP definition (Sylwester Nawrocki's comment) Changes since v2: - Add lock for System MMU private data. And fixes the following problems pointed by Joerg Rodel: - Fix wrong argument to kmalloc() and get_free_pages() - Merged patches into 2 due to bisectability Changes since v1: Fixes of the following problems pointed by Russell King.: - Missing unlocking a spinlock in exynos_iommu_attach_dev(). - atomic_t - int in sysmmu_drvdata.activations - sysmmu_platdata - sysmmu_drvdata - Change in error messages in irq handler - Removed casting in format of error message - omap_iommu_ops - exynos_iommu_ops in the last patch Patch Summary: [PATCH v10 1/3] S5P: SYSMMU: Remove System MMU device driver definitions [PATCH v10 2/3] ARM: EXYNOS: Change System MMU platform device definitions [PATCH v10 3/3] iommu/exynos: Add iommu driver for Exynos Platforms The first patch removes the existing System MMU device driver which does not conform to IOMMU API set prepared in the kernel. The second patch enhances System MMU platform device definition: - Removed System MMU for MDMA0 in TOP block because it is not used. Use MDMA2 in LCD block. - Removed System MMU ID. Instead, a System MMU is bound to a device that the System MMU is dedicated during machin initialization. If a device driver wants to handle System MMU, it must bind its device with System MMU with sysmmu_set_owner(). - clkdev - Added support for Exynos5 The last patch implements IOMMU API: - New System MMU device driver that fully implements IOMMU API. Thanks to Kyungmin Park and Marek Szyprowski for kind review. Diffstats: arch/arm/mach-exynos/Kconfig| 11 +- arch/arm/mach-exynos/Makefile |2 +- arch/arm/mach-exynos/clock-exynos4.c| 87 +- arch/arm/mach-exynos/clock-exynos4.h|2 + arch/arm/mach-exynos/clock-exynos4210.c | 11 + arch/arm/mach-exynos/clock-exynos4212.c | 28 +- arch/arm/mach-exynos/clock-exynos5.c| 90 ++ arch/arm/mach-exynos/dev-sysmmu.c | 457 ++- arch/arm/mach-exynos/include/mach/irqs.h| 179 ++-- arch/arm/mach-exynos/include/mach/map.h | 38 + arch/arm/mach-exynos/include/mach/regs-clock.h |5 + arch/arm/mach-exynos/include/mach/regs-sysmmu.h | 28 - arch/arm/mach-exynos/include/mach/sysmmu.h | 84 +- arch/arm/mach-exynos/mach-armlex4210.c |1 - arch/arm/mach-exynos/mach-smdkv310.c|1 - arch/arm/plat-s5p/Kconfig |8 - arch/arm/plat-s5p/Makefile |1 - arch/arm/plat-s5p/sysmmu.c | 313 --- arch/arm/plat-samsung/include/plat/devs.h |1 - arch/arm/plat-samsung/include/plat/sysmmu.h | 95 -- drivers/iommu/Kconfig | 21 + drivers/iommu/Makefile |1 + drivers/iommu/exynos-iommu.c| 1088 +++ 23 files changed, 1726 insertions(+), 826 deletions(-) -- To
[PATCH v10 2/3] ARM: EXYNOS: Change System MMU platform device definitions
Handling System MMUs with an identifier is not flexible to manage System MMU platform devices because of the following reasons: 1. A device driver which needs to handle System MMU must know the ID. 2. A System MMU may not present in some implementations of Exynos family. 3. Handling System MMU with IOMMU API does not require an ID. This patch is the result of removing ID of System MMUs. Instead, a device driver that needs to handle its System MMU must use IOMMU API while its descriptor of platform device is given. This patch also includes the following enhanclements: - A System MMU device becomes a child if its power domain device. - clkdev Signed-off-by: KyongHo Cho pullip@samsung.com --- arch/arm/mach-exynos/Kconfig| 11 +- arch/arm/mach-exynos/Makefile |2 +- arch/arm/mach-exynos/clock-exynos4.c| 79 ++-- arch/arm/mach-exynos/clock-exynos4.h|2 + arch/arm/mach-exynos/clock-exynos4210.c | 11 + arch/arm/mach-exynos/clock-exynos4212.c | 28 ++- arch/arm/mach-exynos/clock-exynos5.c| 90 + arch/arm/mach-exynos/dev-sysmmu.c | 457 -- arch/arm/mach-exynos/include/mach/irqs.h| 179 +- arch/arm/mach-exynos/include/mach/map.h | 38 ++ arch/arm/mach-exynos/include/mach/regs-clock.h |5 + arch/arm/mach-exynos/include/mach/regs-sysmmu.h | 28 -- arch/arm/mach-exynos/include/mach/sysmmu.h | 84 +++-- arch/arm/mach-exynos/mach-armlex4210.c |1 - arch/arm/mach-exynos/mach-smdkv310.c|1 - 15 files changed, 612 insertions(+), 404 deletions(-) delete mode 100644 arch/arm/mach-exynos/include/mach/regs-sysmmu.h diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index c49d450..d5a6a29 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -88,10 +88,10 @@ config EXYNOS4_SETUP_FIMD0 help Common setup code for FIMD0. -config EXYNOS4_DEV_SYSMMU +config EXYNOS_DEV_SYSMMU bool help - Common setup code for SYSTEM MMU in EXYNOS4 + Common setup code for SYSTEM MMU in EXYNOS platforms config EXYNOS4_DEV_DWMCI bool @@ -201,12 +201,12 @@ config MACH_SMDKV310 select S3C_DEV_HSMMC2 select S3C_DEV_HSMMC3 select SAMSUNG_DEV_BACKLIGHT + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_AHCI select SAMSUNG_DEV_KEYPAD select EXYNOS4_DEV_DMA select SAMSUNG_DEV_PWM select EXYNOS4_DEV_USB_OHCI - select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_KEYPAD @@ -225,7 +225,6 @@ config MACH_ARMLEX4210 select S3C_DEV_HSMMC3 select EXYNOS4_DEV_AHCI select EXYNOS4_DEV_DMA - select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_SDHCI help Machine support for Samsung ARMLEX4210 based on EXYNOS4210 @@ -251,6 +250,7 @@ config MACH_UNIVERSAL_C210 select S5P_DEV_MFC select S5P_DEV_ONENAND select S5P_DEV_TV + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_DMA select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 @@ -320,6 +320,7 @@ config MACH_ORIGEN select S5P_DEV_USB_EHCI select SAMSUNG_DEV_BACKLIGHT select SAMSUNG_DEV_PWM + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_DMA select EXYNOS4_DEV_USB_OHCI select EXYNOS4_SETUP_FIMD0 @@ -343,6 +344,7 @@ config MACH_SMDK4212 select SAMSUNG_DEV_BACKLIGHT select SAMSUNG_DEV_KEYPAD select SAMSUNG_DEV_PWM + select EXYNOS_DEV_SYSMMU select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_I2C3 select EXYNOS4_SETUP_I2C7 @@ -368,6 +370,7 @@ comment EXYNOS5250 Boards config MACH_SMDK5250 bool SMDK5250 select SOC_EXYNOS5250 + select EXYNOS_DEV_SYSMMU help Machine support for Samsung SMDK5250 endif diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index 6fd8dd9..8b655e9 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -52,7 +52,7 @@ obj-$(CONFIG_MACH_SMDK5250) += mach-smdk5250.o obj-y += dev-uart.o obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o -obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o +obj-$(CONFIG_EXYNOS_DEV_SYSMMU)+= dev-sysmmu.o obj-$(CONFIG_EXYNOS4_DEV_DWMCI)+= dev-dwmci.o obj-$(CONFIG_EXYNOS4_DEV_DMA) += dma.o obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI) += dev-ohci.o diff --git a/arch/arm/mach-exynos/clock-exynos4.c b/arch/arm/mach-exynos/clock-exynos4.c index d72a1fe..18c48f0 100644 --- a/arch/arm/mach-exynos/clock-exynos4.c +++ b/arch/arm/mach-exynos/clock-exynos4.c @@ -169,7 +169,7 @@ static int
[PATCH v10 3/3] iommu/exynos: Add iommu driver for Exynos Platforms
HAALgBjAGgAbwBAAHMAYQBtAHMAdQBuAGcALgBjAG8AbQA=;Tue,
06 Mar 2012 08:31:29
GMT;WwBQAEEAVABDAEgAIAB2ADEAMAAgADMALwAzAF0AIABpAG8AbQBtAHUALwBlAHgAeQBuAG8AcwA6ACAAQQBkAGQAIABpAG8AbQBtAHUAIABkAHIAaQB2AGUAcgAgAGYAbwByACAARQB4AHkAbgBvAHMAIABQAGwAYQB0AGYAbwByAG0AcwA=
x-cr-puzzleid: {CF0AAF04-8639-4D69-B4E1-BF71EA1B0A70}
This is the System MMU driver and IOMMU API implementation for
Exynos SOC platforms. Exynos platforms has more than 10 System
MMUs dedicated for each multimedia accellerators.
The System MMU driver is already in arc/arm/plat-s5p but it is
moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers
there
Any device driver in Exynos platforms that needs to control its
System MMU must call platform_set_sysmmu() to inform System MMU
driver who will control it.
platform_set_sysmmu() is defined in mach/sysmmu.h
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: KyongHo Cho pullip@samsung.com
---
drivers/iommu/Kconfig| 21 +
drivers/iommu/Makefile |1 +
drivers/iommu/exynos-iommu.c | 1088 ++
3 files changed, 1110 insertions(+), 0 deletions(-)
create mode 100644 drivers/iommu/exynos-iommu.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 6bea696..25d3eed 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -142,4 +142,25 @@ config OMAP_IOMMU_DEBUG
Say N unless you know you need this.
+config EXYNOS_IOMMU
+ bool Exynos IOMMU Support
+ depends on EXYNOS_DEV_SYSMMU
+ select IOMMU_API
+ help
+ Support for the IOMMU(System MMU) of Samsung Exynos application
+ processor family. This enables H/W multimedia accellerators to see
+ non-linear physical memory chunks as a linear memory in their
+ address spaces
+
+ If unsure, say N here.
+
+config EXYNOS_IOMMU_DEBUG
+ bool Debugging log for Exynos IOMMU
+ depends on EXYNOS_IOMMU
+ help
+ Select this to see the detailed log message that shows what
+ happens in the IOMMU driver
+
+ Say N unless you need kernel log message for IOMMU debugging
+
endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 0e36b49..5a8fd97 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_IRQ_REMAP) += intr_remapping.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
+obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
new file mode 100644
index 000..4c1c48a
--- /dev/null
+++ b/drivers/iommu/exynos-iommu.c
@@ -0,0 +1,1088 @@
+/* linux/drivers/iommu/exynos_iommu.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifdef CONFIG_EXYNOS_IOMMU_DEBUG
+#define DEBUG
+#endif
+
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/mm.h
+#include linux/iommu.h
+#include linux/errno.h
+#include linux/list.h
+#include linux/memblock.h
+#include linux/export.h
+
+#include asm/cacheflush.h
+#include asm/pgtable.h
+
+#include mach/sysmmu.h
+
+#define S5P_MMU_CTRL 0x000
+#define S5P_MMU_CFG0x004
+#define S5P_MMU_STATUS 0x008
+#define S5P_MMU_FLUSH 0x00C
+#define S5P_PT_BASE_ADDR 0x014
+#define S5P_INT_STATUS 0x018
+#define S5P_INT_CLEAR 0x01C
+#define S5P_PAGE_FAULT_ADDR0x024
+#define S5P_AW_FAULT_ADDR 0x028
+#define S5P_AR_FAULT_ADDR 0x02C
+#define S5P_DEFAULT_SLAVE_ADDR 0x030
+#define S5P_MMU_VERSION0x034
+#define S5P_PB0_SADDR 0x04C
+#define S5P_PB0_EADDR 0x050
+#define S5P_PB1_SADDR 0x054
+#define S5P_PB1_EADDR 0x058
+
+#define SECT_ORDER 20
+#define LPAGE_ORDER 16
+#define SPAGE_ORDER 12
+
+#define SECT_SIZE (1 SECT_ORDER)
+#define LPAGE_SIZE (1 LPAGE_ORDER)
+#define SPAGE_SIZE (1 SPAGE_ORDER)
+
+#define SECT_MASK (~(SECT_SIZE - 1))
+#define LPAGE_MASK (~(LPAGE_SIZE - 1))
+#define SPAGE_MASK (~(SPAGE_SIZE - 1))
+
+#define lv1ent_fault(sent) (((*(sent) 3) == 0) || ((*(sent) 3) == 3))
+#define lv1ent_page(sent) ((*(sent) 3) == 1)
+#define lv1ent_section(sent) ((*(sent) 3) == 2)
+
+#define lv2ent_fault(pent) ((*(pent) 3) == 0)
+#define lv2ent_small(pent) ((*(pent) 2) == 2)
+#define lv2ent_large(pent) ((*(pent) 3) == 1)
+
+#define section_phys(sent) (*(sent)
[PATCH 1/4] ARM: S3C24XX: Move common-smdk code to mach directory
This code is used by boards based on the S3C2410/S3C2440/S3C2416.
The patch includes also a rename of the option, as the smdk code
is not a mach itself, but only an extension with common code.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/Kconfig | 19 ++-
arch/arm/mach-s3c24xx/Makefile |1 +
.../{plat-s3c24xx = mach-s3c24xx}/common-smdk.c |0
arch/arm/plat-s3c24xx/Kconfig |5 -
arch/arm/plat-s3c24xx/Makefile |1 -
5 files changed, 15 insertions(+), 11 deletions(-)
rename arch/arm/{plat-s3c24xx = mach-s3c24xx}/common-smdk.c (100%)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 48af6fc..7dede07 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -81,6 +81,15 @@ config CPU_S3C2443
help
Support for the S3C2443 SoC from the S3C24XX line
+# common code
+
+config S3C24XX_SMDK
+ bool
+ help
+ Common machine code for SMDK2410 and SMDK2440
+
+# cpu-specific sections
+
if CPU_S3C2410
config S3C2410_DMA
@@ -192,7 +201,7 @@ config MACH_QT2410
config ARCH_SMDK2410
bool SMDK2410/A9M2410
- select MACH_SMDK
+ select S3C24XX_SMDK
help
Say Y here if you are using the SMDK2410 or the derived module A9M2410
http://www.fsforth.de
@@ -279,7 +288,7 @@ config MACH_SMDK2412
config MACH_SMDK2413
bool SMDK2413
select MACH_S3C2413
- select MACH_SMDK
+ select S3C24XX_SMDK
select S3C_DEV_USB_HOST
select S3C_DEV_NAND
help
@@ -317,7 +326,7 @@ comment S3C2416 Boards
config MACH_SMDK2416
bool SMDK2416
- select MACH_SMDK
+ select S3C24XX_SMDK
select S3C_DEV_FB
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
@@ -420,7 +429,7 @@ config MACH_RX3715
config ARCH_S3C2440
bool SMDK2440
select S3C2440_XTAL_16934400
- select MACH_SMDK
+ select S3C24XX_SMDK
select S3C_DEV_USB_HOST
select S3C_DEV_NAND
help
@@ -492,7 +501,7 @@ comment S3C2443 Boards
config MACH_SMDK2443
bool SMDK2443
- select MACH_SMDK
+ select S3C24XX_SMDK
select S3C_DEV_HSMMC1
help
Say Y here if you are using an SMDK2443
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 876e5e5..b1c3c6f 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_MACH_SMDK2443) += mach-smdk2443.o
# common bits of machine support
+obj-$(CONFIG_S3C24XX_SMDK) += common-smdk.o
obj-$(CONFIG_SIMTEC_NOR) += nor-simtec.o
# machine additions
diff --git a/arch/arm/plat-s3c24xx/common-smdk.c
b/arch/arm/mach-s3c24xx/common-smdk.c
similarity index 100%
rename from arch/arm/plat-s3c24xx/common-smdk.c
rename to arch/arm/mach-s3c24xx/common-smdk.c
diff --git a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig
index 74f76e0..73ebc40 100644
--- a/arch/arm/plat-s3c24xx/Kconfig
+++ b/arch/arm/plat-s3c24xx/Kconfig
@@ -119,11 +119,6 @@ config S3C2412_IOTIMING
Intel node to select io timing code that is common to the s3c2412
and the s3c2443.
-config MACH_SMDK
- bool
- help
- Common machine code for SMDK2410 and SMDK2440
-
config S3C24XX_SIMTEC_AUDIO
bool
depends on (ARCH_BAST || MACH_VR1000 || MACH_OSIRIS || MACH_ANUBIS)
diff --git a/arch/arm/plat-s3c24xx/Makefile b/arch/arm/plat-s3c24xx/Makefile
index a7e8843..8dca10a 100644
--- a/arch/arm/plat-s3c24xx/Makefile
+++ b/arch/arm/plat-s3c24xx/Makefile
@@ -39,5 +39,4 @@ obj-$(CONFIG_S3C2410_SETUP_TS)+= setup-ts.o
# machine common support
-obj-$(CONFIG_MACH_SMDK)+= common-smdk.o
obj-$(CONFIG_S3C24XX_SIMTEC_AUDIO) += simtec-audio.o
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: S3C24XX: move simtec-specific code to mach directory
This includes a rename of the pm-simtec.c to keep the simtec
extensions together a bit and also better naming of the Kconfig
options.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/Kconfig | 23 +++
arch/arm/mach-s3c24xx/Makefile |2 +
.../{plat-s3c24xx = mach-s3c24xx}/simtec-audio.c |0
.../pm-simtec.c = mach-s3c24xx/simtec-pm.c} |0
arch/arm/plat-s3c24xx/Kconfig | 13 ---
arch/arm/plat-s3c24xx/Makefile |5
6 files changed, 20 insertions(+), 23 deletions(-)
rename arch/arm/{plat-s3c24xx = mach-s3c24xx}/simtec-audio.c (100%)
rename arch/arm/{plat-s3c24xx/pm-simtec.c = mach-s3c24xx/simtec-pm.c} (100%)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 7dede07..115cc50 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -88,6 +88,19 @@ config S3C24XX_SMDK
help
Common machine code for SMDK2410 and SMDK2440
+config S3C24XX_SIMTEC_AUDIO
+ bool
+ depends on (ARCH_BAST || MACH_VR1000 || MACH_OSIRIS || MACH_ANUBIS)
+ default y
+ help
+ Add audio devices for common Simtec S3C24XX boards
+
+config S3C24XX_SIMTEC_PM
+ bool
+ help
+ Common power management code for systems that are
+ compatible with the Simtec style of power management
+
# cpu-specific sections
if CPU_S3C2410
@@ -125,7 +138,7 @@ comment S3C2410 Boards
config MACH_AML_M5900
bool AML M5900 Series
- select PM_SIMTEC if PM
+ select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_USB_HOST
help
Say Y here if you are using the American Microsystems M5900 Series
@@ -134,7 +147,7 @@ config MACH_AML_M5900
config ARCH_BAST
bool Simtec Electronics BAST (EB2410ITX)
select S3C2410_IOTIMING if S3C2410_CPUFREQ
- select PM_SIMTEC if PM
+ select S3C24XX_SIMTEC_PM if PM
select SIMTEC_NOR
select MACH_BAST_IDE
select S3C24XX_DCLK
@@ -215,7 +228,7 @@ config MACH_TCT_HAMMER
config MACH_VR1000
bool Thorcom VR1000
- select PM_SIMTEC if PM
+ select S3C24XX_SIMTEC_PM if PM
select S3C24XX_DCLK
select SIMTEC_NOR
select MACH_BAST_IDE
@@ -355,7 +368,7 @@ comment S3C2440 Boards
config MACH_ANUBIS
bool Simtec Electronics ANUBIS
select S3C24XX_DCLK
- select PM_SIMTEC if PM
+ select S3C24XX_SIMTEC_PM if PM
select HAVE_PATA_PLATFORM
select S3C24XX_GPIO_EXTRA64
select S3C2440_XTAL_1200
@@ -395,7 +408,7 @@ config MACH_NEXCODER_2440
config MACH_OSIRIS
bool Simtec IM2440D20 (OSIRIS) module
select S3C24XX_DCLK
- select PM_SIMTEC if PM
+ select S3C24XX_SIMTEC_PM if PM
select S3C24XX_GPIO_EXTRA128
select S3C2440_XTAL_1200
select S3C2410_IOTIMING if S3C2440_CPUFREQ
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index b1c3c6f..fedbdb8 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -79,6 +79,8 @@ obj-$(CONFIG_MACH_SMDK2443) += mach-smdk2443.o
obj-$(CONFIG_S3C24XX_SMDK) += common-smdk.o
obj-$(CONFIG_SIMTEC_NOR) += nor-simtec.o
+obj-$(CONFIG_S3C24XX_SIMTEC_AUDIO) += simtec-audio.o
+obj-$(CONFIG_S3C24XX_SIMTEC_PM)+= simtec-pm.o
# machine additions
diff --git a/arch/arm/plat-s3c24xx/simtec-audio.c
b/arch/arm/mach-s3c24xx/simtec-audio.c
similarity index 100%
rename from arch/arm/plat-s3c24xx/simtec-audio.c
rename to arch/arm/mach-s3c24xx/simtec-audio.c
diff --git a/arch/arm/plat-s3c24xx/pm-simtec.c
b/arch/arm/mach-s3c24xx/simtec-pm.c
similarity index 100%
rename from arch/arm/plat-s3c24xx/pm-simtec.c
rename to arch/arm/mach-s3c24xx/simtec-pm.c
diff --git a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig
index 73ebc40..0338d20 100644
--- a/arch/arm/plat-s3c24xx/Kconfig
+++ b/arch/arm/plat-s3c24xx/Kconfig
@@ -70,12 +70,6 @@ config S3C24XX_GPIO_EXTRA128
Add an extra 128 gpio numbers to the available GPIO pool. This is
available for boards that need extra gpios for external devices.
-config PM_SIMTEC
- bool
- help
- Common power management code for systems that are
- compatible with the Simtec style of power management
-
config S3C24XX_DMA
bool S3C2410 DMA support
depends on ARCH_S3C24XX
@@ -119,13 +113,6 @@ config S3C2412_IOTIMING
Intel node to select io timing code that is common to the s3c2412
and the s3c2443.
-config S3C24XX_SIMTEC_AUDIO
- bool
- depends on (ARCH_BAST || MACH_VR1000 || MACH_OSIRIS || MACH_ANUBIS)
- default y
- help
- Add audio devices for common Simtec S3C24XX boards
-
config S3C2410_SETUP_TS
bool
help
diff --git a/arch/arm/plat-s3c24xx/Makefile
[PATCH 3/4] ARM: S3C24XX: Consolidate Simtec extensions
The Simtec extension didn't follow a specific naming scheme for files
and config options until now. This distributed the files throughout
the whole mach-s3c24xx directory.
This patch fixes the naming of files and option names and also creates
a simtec.h header instead of using many one-liners.
As the plat/audio-simtec.h only contains the platform-data struct now,
it can also move to include/sound in a later patch.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/Kconfig | 13 ++---
arch/arm/mach-s3c24xx/Makefile |7 ---
arch/arm/mach-s3c24xx/mach-anubis.c|1 +
arch/arm/mach-s3c24xx/mach-bast.c |3 +--
arch/arm/mach-s3c24xx/mach-vr1000.c|3 +--
arch/arm/mach-s3c24xx/simtec-audio.c |2 ++
.../mach-s3c24xx/{nor-simtec.c = simtec-nor.c}|2 +-
.../mach-s3c24xx/{usb-simtec.c = simtec-usb.c}|2 +-
arch/arm/mach-s3c24xx/{nor-simtec.h = simtec.h} |9 -
arch/arm/mach-s3c24xx/usb-simtec.h | 16
arch/arm/plat-samsung/include/plat/audio-simtec.h |3 ---
11 files changed, 29 insertions(+), 32 deletions(-)
rename arch/arm/mach-s3c24xx/{nor-simtec.c = simtec-nor.c} (98%)
rename arch/arm/mach-s3c24xx/{usb-simtec.c = simtec-usb.c} (99%)
rename arch/arm/mach-s3c24xx/{nor-simtec.h = simtec.h} (63%)
delete mode 100644 arch/arm/mach-s3c24xx/usb-simtec.h
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 115cc50..df6f419 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -101,6 +101,11 @@ config S3C24XX_SIMTEC_PM
Common power management code for systems that are
compatible with the Simtec style of power management
+config S3C24XX_SIMTEC_USB
+ bool
+ help
+ USB management code for common Simtec S3C24XX boards
+
# cpu-specific sections
if CPU_S3C2410
@@ -117,7 +122,7 @@ config S3C2410_PM
help
Power Management code common to S3C2410 and better
-config SIMTEC_NOR
+config S3C24XX_SIMTEC_NOR
bool
help
Internal node to specify machine has simtec NOR mapping
@@ -148,7 +153,8 @@ config ARCH_BAST
bool Simtec Electronics BAST (EB2410ITX)
select S3C2410_IOTIMING if S3C2410_CPUFREQ
select S3C24XX_SIMTEC_PM if PM
- select SIMTEC_NOR
+ select S3C24XX_SIMTEC_NOR
+ select S3C24XX_SIMTEC_USB
select MACH_BAST_IDE
select S3C24XX_DCLK
select ISA
@@ -230,9 +236,10 @@ config MACH_VR1000
bool Thorcom VR1000
select S3C24XX_SIMTEC_PM if PM
select S3C24XX_DCLK
- select SIMTEC_NOR
+ select S3C24XX_SIMTEC_NOR
select MACH_BAST_IDE
select S3C_DEV_USB_HOST
+ select S3C24XX_SIMTEC_USB
help
Say Y here if you are using the Thorcom VR1000 board.
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index fedbdb8..2843c81 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -44,7 +44,7 @@ obj-$(CONFIG_S3C2443_COMMON) += common-s3c2443.o
#
obj-$(CONFIG_MACH_AML_M5900) += mach-amlm5900.o
-obj-$(CONFIG_ARCH_BAST)+= mach-bast.o usb-simtec.o
+obj-$(CONFIG_ARCH_BAST)+= mach-bast.o
obj-$(CONFIG_BAST_PC104_IRQ) += bast-irq.o
obj-$(CONFIG_ARCH_H1940) += mach-h1940.o
obj-$(CONFIG_H1940BT) += h1940-bluetooth.o
@@ -54,7 +54,7 @@ obj-$(CONFIG_MACH_OTOM) += mach-otom.o
obj-$(CONFIG_MACH_QT2410) += mach-qt2410.o
obj-$(CONFIG_ARCH_SMDK2410)+= mach-smdk2410.o
obj-$(CONFIG_MACH_TCT_HAMMER) += mach-tct_hammer.o
-obj-$(CONFIG_MACH_VR1000) += mach-vr1000.o usb-simtec.o
+obj-$(CONFIG_MACH_VR1000) += mach-vr1000.o
obj-$(CONFIG_MACH_JIVE)+= mach-jive.o
obj-$(CONFIG_MACH_SMDK2413)+= mach-smdk2413.o
@@ -78,9 +78,10 @@ obj-$(CONFIG_MACH_SMDK2443) += mach-smdk2443.o
# common bits of machine support
obj-$(CONFIG_S3C24XX_SMDK) += common-smdk.o
-obj-$(CONFIG_SIMTEC_NOR) += nor-simtec.o
obj-$(CONFIG_S3C24XX_SIMTEC_AUDIO) += simtec-audio.o
+obj-$(CONFIG_S3C24XX_SIMTEC_NOR) += simtec-nor.o
obj-$(CONFIG_S3C24XX_SIMTEC_PM)+= simtec-pm.o
+obj-$(CONFIG_S3C24XX_SIMTEC_USB) += simtec-usb.o
# machine additions
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 2456955..9e0f745 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -55,6 +55,7 @@
#include plat/cpu.h
#include plat/audio-simtec.h
+#include simtec.h
#include common.h
#define COPYRIGHT , Copyright 2005-2009 Simtec Electronics
diff --git
[PATCH 4/4] ARM: S3C24XX: Move device setup files to mach directory
Includes a small rename of the SETUP_TS option to a S3C24XX prefix.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/Kconfig |7 ++-
arch/arm/mach-s3c24xx/Makefile |2 ++
.../arm/{plat-s3c24xx = mach-s3c24xx}/setup-i2c.c |0
arch/arm/{plat-s3c24xx = mach-s3c24xx}/setup-ts.c |0
arch/arm/plat-s3c24xx/Kconfig |5 -
arch/arm/plat-s3c24xx/Makefile |4
6 files changed, 8 insertions(+), 10 deletions(-)
rename arch/arm/{plat-s3c24xx = mach-s3c24xx}/setup-i2c.c (100%)
rename arch/arm/{plat-s3c24xx = mach-s3c24xx}/setup-ts.c (100%)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index df6f419..b399021 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -106,6 +106,11 @@ config S3C24XX_SIMTEC_USB
help
USB management code for common Simtec S3C24XX boards
+config S3C24XX_SETUP_TS
+ bool
+ help
+ Compile in platform device definition for Samsung TouchScreen.
+
# cpu-specific sections
if CPU_S3C2410
@@ -178,7 +183,7 @@ config ARCH_H1940
select PM_H1940 if PM
select S3C_DEV_USB_HOST
select S3C_DEV_NAND
- select S3C2410_SETUP_TS
+ select S3C24XX_SETUP_TS
help
Say Y here if you are using the HP IPAQ H1940
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 2843c81..3f39e6f 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -91,3 +91,5 @@ obj-$(CONFIG_MACH_OSIRIS_DVS) += mach-osiris-dvs.o
# device setup
obj-$(CONFIG_S3C2416_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
+obj-$(CONFIG_ARCH_S3C24XX) += setup-i2c.o
+obj-$(CONFIG_S3C24XX_SETUP_TS) += setup-ts.o
diff --git a/arch/arm/plat-s3c24xx/setup-i2c.c
b/arch/arm/mach-s3c24xx/setup-i2c.c
similarity index 100%
rename from arch/arm/plat-s3c24xx/setup-i2c.c
rename to arch/arm/mach-s3c24xx/setup-i2c.c
diff --git a/arch/arm/plat-s3c24xx/setup-ts.c b/arch/arm/mach-s3c24xx/setup-ts.c
similarity index 100%
rename from arch/arm/plat-s3c24xx/setup-ts.c
rename to arch/arm/mach-s3c24xx/setup-ts.c
diff --git a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig
index 0338d20..21bf6ad 100644
--- a/arch/arm/plat-s3c24xx/Kconfig
+++ b/arch/arm/plat-s3c24xx/Kconfig
@@ -113,9 +113,4 @@ config S3C2412_IOTIMING
Intel node to select io timing code that is common to the s3c2412
and the s3c2443.
-config S3C2410_SETUP_TS
- bool
- help
- Compile in platform device definition for Samsung TouchScreen.
-
endif
diff --git a/arch/arm/plat-s3c24xx/Makefile b/arch/arm/plat-s3c24xx/Makefile
index 27dd9c5..2467b80 100644
--- a/arch/arm/plat-s3c24xx/Makefile
+++ b/arch/arm/plat-s3c24xx/Makefile
@@ -31,7 +31,3 @@ obj-$(CONFIG_S3C24XX_DMA) += dma.o
obj-$(CONFIG_S3C2410_IOTIMING) += s3c2410-iotiming.o
obj-$(CONFIG_S3C2412_IOTIMING) += s3c2412-iotiming.o
obj-$(CONFIG_S3C2410_CPUFREQ_UTILS) += s3c2410-cpufreq-utils.o
-
-# device specific setup and/or initialisation
-obj-$(CONFIG_ARCH_S3C24XX) += setup-i2c.o
-obj-$(CONFIG_S3C2410_SETUP_TS) += setup-ts.o
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/3] ARM: EXYNOS: Change System MMU platform device definitions
Hi, On 3/6/12, KyongHo Cho pullip@samsung.com wrote: Handling System MMUs with an identifier is not flexible to manage System MMU platform devices because of the following reasons: 1. A device driver which needs to handle System MMU must know the ID. 2. A System MMU may not present in some implementations of Exynos family. 3. Handling System MMU with IOMMU API does not require an ID. This patch is the result of removing ID of System MMUs. Instead, a device driver that needs to handle its System MMU must use IOMMU API while its descriptor of platform device is given. This patch also includes the following enhanclements: - A System MMU device becomes a child if its power domain device. - clkdev Signed-off-by: KyongHo Cho pullip@samsung.com --- arch/arm/mach-exynos/Kconfig| 11 +- arch/arm/mach-exynos/Makefile |2 +- arch/arm/mach-exynos/clock-exynos4.c| 79 ++-- arch/arm/mach-exynos/clock-exynos4.h|2 + arch/arm/mach-exynos/clock-exynos4210.c | 11 + arch/arm/mach-exynos/clock-exynos4212.c | 28 ++- arch/arm/mach-exynos/clock-exynos5.c| 90 + arch/arm/mach-exynos/dev-sysmmu.c | 457 -- arch/arm/mach-exynos/include/mach/irqs.h| 179 +- arch/arm/mach-exynos/include/mach/map.h | 38 ++ arch/arm/mach-exynos/include/mach/regs-clock.h |5 + arch/arm/mach-exynos/include/mach/regs-sysmmu.h | 28 -- arch/arm/mach-exynos/include/mach/sysmmu.h | 84 +++-- arch/arm/mach-exynos/mach-armlex4210.c |1 - arch/arm/mach-exynos/mach-smdkv310.c|1 - 15 files changed, 612 insertions(+), 404 deletions(-) delete mode 100644 arch/arm/mach-exynos/include/mach/regs-sysmmu.h diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index c49d450..d5a6a29 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -88,10 +88,10 @@ config EXYNOS4_SETUP_FIMD0 help Common setup code for FIMD0. -config EXYNOS4_DEV_SYSMMU +config EXYNOS_DEV_SYSMMU bool help - Common setup code for SYSTEM MMU in EXYNOS4 + Common setup code for SYSTEM MMU in EXYNOS platforms config EXYNOS4_DEV_DWMCI bool @@ -201,12 +201,12 @@ config MACH_SMDKV310 select S3C_DEV_HSMMC2 select S3C_DEV_HSMMC3 select SAMSUNG_DEV_BACKLIGHT + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_AHCI select SAMSUNG_DEV_KEYPAD select EXYNOS4_DEV_DMA select SAMSUNG_DEV_PWM select EXYNOS4_DEV_USB_OHCI - select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_KEYPAD @@ -225,7 +225,6 @@ config MACH_ARMLEX4210 select S3C_DEV_HSMMC3 select EXYNOS4_DEV_AHCI select EXYNOS4_DEV_DMA - select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_SDHCI help Machine support for Samsung ARMLEX4210 based on EXYNOS4210 @@ -251,6 +250,7 @@ config MACH_UNIVERSAL_C210 select S5P_DEV_MFC select S5P_DEV_ONENAND select S5P_DEV_TV + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_DMA select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 @@ -320,6 +320,7 @@ config MACH_ORIGEN select S5P_DEV_USB_EHCI select SAMSUNG_DEV_BACKLIGHT select SAMSUNG_DEV_PWM + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_DMA select EXYNOS4_DEV_USB_OHCI select EXYNOS4_SETUP_FIMD0 @@ -343,6 +344,7 @@ config MACH_SMDK4212 select SAMSUNG_DEV_BACKLIGHT select SAMSUNG_DEV_KEYPAD select SAMSUNG_DEV_PWM + select EXYNOS_DEV_SYSMMU select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_I2C3 select EXYNOS4_SETUP_I2C7 @@ -368,6 +370,7 @@ comment EXYNOS5250 Boards config MACH_SMDK5250 bool SMDK5250 select SOC_EXYNOS5250 + select EXYNOS_DEV_SYSMMU help Machine support for Samsung SMDK5250 endif diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index 6fd8dd9..8b655e9 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -52,7 +52,7 @@ obj-$(CONFIG_MACH_SMDK5250) += mach-smdk5250.o obj-y+= dev-uart.o obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o -obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o +obj-$(CONFIG_EXYNOS_DEV_SYSMMU) += dev-sysmmu.o obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o obj-$(CONFIG_EXYNOS4_DEV_DMA)+= dma.o obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI) += dev-ohci.o diff --git a/arch/arm/mach-exynos/clock-exynos4.c b/arch/arm/mach-exynos/clock-exynos4.c index d72a1fe..18c48f0 100644 --- a/arch/arm/mach-exynos/clock-exynos4.c +++
RE: [PATCH 2/3] video: s3c-fb: remove 'default_win' element from platform data
-Original Message-
From: Thomas Abraham [mailto:thomas.abra...@linaro.org]
Sent: Sunday, March 04, 2012 12:50 AM
To: linux-fb...@vger.kernel.org
Cc: florianschandi...@gmx.de; linux-samsung-soc@vger.kernel.org;
kgene@samsung.com;
jg1@samsung.com; ben-li...@fluff.org; patc...@linaro.org
Subject: [PATCH 2/3] video: s3c-fb: remove 'default_win' element from
platform data
The decision to enable or disable the data output to the lcd panel from
the controller need not be based on the value of 'default_win' element
in the platform data. Instead, the data output to the panel is enabled
if any of the windows are active, else data output is disabled.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Jingoo Han jg1@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/plat-samsung/include/plat/fb.h |2 --
drivers/video/s3c-fb.c | 24
2 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h
b/arch/arm/plat-samsung/include/plat/fb.h
index 39d6bd7..536002f 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -62,8 +62,6 @@ struct s3c_fb_platdata {
struct s3c_fb_pd_win*win[S3C_FB_MAX_WIN];
struct fb_videomode *vtiming;
- u32 default_win;
-
u32 vidcon0;
u32 vidcon1;
};
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 8e05d4d..8baba31 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -531,7 +531,7 @@ static int s3c_fb_set_par(struct fb_info *info)
/* disable the window whilst we update it */
writel(0, regs + WINCON(win_no));
- if (win_no == sfb-pdata-default_win)
+ if (!sfb-output_on)
s3c_fb_enable(sfb, 1);
/* write the buffer address */
@@ -792,7 +792,7 @@ static int s3c_fb_blank(int blank_mode, struct fb_info
*info)
struct s3c_fb_win *win = info-par;
struct s3c_fb *sfb = win-parent;
unsigned int index = win-index;
- u32 wincon;
+ u32 wincon, output_on = sfb-output_on;
Can you add new line as below? It's more readable.
+ u32 output_on = sfb-output_on;
Sorry for nitpicking.
dev_dbg(sfb-dev, blank mode %d\n, blank_mode);
@@ -838,27 +838,11 @@ static int s3c_fb_blank(int blank_mode, struct fb_info
*info)
* it is highly likely that we also do not need to output
* anything.
*/
-
- /* We could do something like the following code, but the current
- * system of using framebuffer events means that we cannot make
- * the distinction between just window 0 being inactive and all
- * the windows being down.
- *
- * s3c_fb_enable(sfb, sfb-enabled ? 1 : 0);
- */
-
- /* we're stuck with this until we can do something about overriding
- * the power control using the blanking event for a single fb.
- */
- if (index == sfb-pdata-default_win) {
- shadow_protect_win(win, 1);
- s3c_fb_enable(sfb, blank_mode != FB_BLANK_POWERDOWN ? 1 : 0);
- shadow_protect_win(win, 0);
- }
+ s3c_fb_enable(sfb, sfb-enabled ? 1 : 0);
However, shadow_protect_win() is necessary as belows.
Because shadow registers such as VIDCON0 should be protectd
whenever the registers are updated. The s3c_fb_enable() updates
VIDCON0.
+ shadow_protect_win(win, 1);
+ s3c_fb_enable(sfb, sfb-enabled ? 1 : 0);
+ shadow_protect_win(win, 0);
pm_runtime_put_sync(sfb-dev);
- return 0;
+ return output_on == sfb-output_on;
}
/**
--
1.6.6.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: Exynos: fix SDHCI device names in regulator definitions
On 03/01/12 00:40, Marek Szyprowski wrote:
Patch 189eb7407 ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci
controllers changed the names of the SDHCI devices, but the author forgot
to update the definitions for the regulator subsystem. This patch fixes
this issue.
Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c |4 ++--
arch/arm/mach-exynos/mach-universal_c210.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 8c0479f..dd26581 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -117,7 +117,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply emmc_supplies[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
REGULATOR_SUPPLY(vmmc, dw_mmc),
};
@@ -417,7 +417,7 @@ static struct regulator_consumer_supply __initdata
max8997_ldo12_[] = {
REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
};
static struct regulator_consumer_supply __initdata max8997_ldo13_[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.2), /* TFLASH */
};
static struct regulator_consumer_supply __initdata max8997_ldo14_[] = {
REGULATOR_SUPPLY(inmotor, max8997-haptic),
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 908624c..7cd738c 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -750,7 +750,7 @@ static struct s3c_sdhci_platdata universal_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply mmc0_supplies[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
};
static struct regulator_init_data mmc0_fixed_voltage_init_data = {
(Cc'ed Jaehoon Chung)
Oops, I looked at same patch from Jaehoon Chung just now and it could
be. However, including same Signed-off-by from Kyungmin Park, it seems
wrong. What's happened in your side?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: Exynos: fix touchscreen IRQ setup on Universal C210 board
On 03/01/12 00:40, Marek Szyprowski wrote:
From: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com
Fixes atmel_mxt_ts freeze on Universal C210.
Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
---
arch/arm/mach-exynos/mach-universal_c210.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 7cd738c..e0cd5bb 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -13,6 +13,7 @@
#includelinux/i2c.h
#includelinux/gpio_keys.h
#includelinux/gpio.h
+#includelinux/interrupt.h
#includelinux/fb.h
#includelinux/mfd/max8998.h
#includelinux/regulator/machine.h
@@ -604,6 +605,7 @@ static struct mxt_platform_data qt602240_platform_data = {
.threshold = 0x28,
.voltage= 280, /* 2.8V */
.orient = MXT_DIAGONAL,
+ .irqflags = IRQF_TRIGGER_FALLING,
};
static struct i2c_board_info i2c3_devs[] __initdata = {
Looks ok, will apply into fixes-4.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] video: s3c-fb: remove 'default_win' element from platform data
On 6 March 2012 15:35, Jingoo Han jg1@samsung.com wrote:
-Original Message-
From: Thomas Abraham [mailto:thomas.abra...@linaro.org]
Sent: Sunday, March 04, 2012 12:50 AM
To: linux-fb...@vger.kernel.org
Cc: florianschandi...@gmx.de; linux-samsung-soc@vger.kernel.org;
kgene@samsung.com;
jg1@samsung.com; ben-li...@fluff.org; patc...@linaro.org
Subject: [PATCH 2/3] video: s3c-fb: remove 'default_win' element from
platform data
The decision to enable or disable the data output to the lcd panel from
the controller need not be based on the value of 'default_win' element
in the platform data. Instead, the data output to the panel is enabled
if any of the windows are active, else data output is disabled.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Jingoo Han jg1@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/plat-samsung/include/plat/fb.h | 2 --
drivers/video/s3c-fb.c | 24
2 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h
b/arch/arm/plat-samsung/include/plat/fb.h
index 39d6bd7..536002f 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -62,8 +62,6 @@ struct s3c_fb_platdata {
struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
struct fb_videomode *vtiming;
- u32 default_win;
-
u32 vidcon0;
u32 vidcon1;
};
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 8e05d4d..8baba31 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -531,7 +531,7 @@ static int s3c_fb_set_par(struct fb_info *info)
/* disable the window whilst we update it */
writel(0, regs + WINCON(win_no));
- if (win_no == sfb-pdata-default_win)
+ if (!sfb-output_on)
s3c_fb_enable(sfb, 1);
/* write the buffer address */
@@ -792,7 +792,7 @@ static int s3c_fb_blank(int blank_mode, struct fb_info
*info)
struct s3c_fb_win *win = info-par;
struct s3c_fb *sfb = win-parent;
unsigned int index = win-index;
- u32 wincon;
+ u32 wincon, output_on = sfb-output_on;
Can you add new line as below? It's more readable.
+ u32 output_on = sfb-output_on;
Sorry for nitpicking.
Ok. I will add a new line as you have suggested.
dev_dbg(sfb-dev, blank mode %d\n, blank_mode);
@@ -838,27 +838,11 @@ static int s3c_fb_blank(int blank_mode, struct fb_info
*info)
* it is highly likely that we also do not need to output
* anything.
*/
-
- /* We could do something like the following code, but the current
- * system of using framebuffer events means that we cannot make
- * the distinction between just window 0 being inactive and all
- * the windows being down.
- *
- * s3c_fb_enable(sfb, sfb-enabled ? 1 : 0);
- */
-
- /* we're stuck with this until we can do something about overriding
- * the power control using the blanking event for a single fb.
- */
- if (index == sfb-pdata-default_win) {
- shadow_protect_win(win, 1);
- s3c_fb_enable(sfb, blank_mode != FB_BLANK_POWERDOWN ? 1 : 0);
- shadow_protect_win(win, 0);
- }
+ s3c_fb_enable(sfb, sfb-enabled ? 1 : 0);
However, shadow_protect_win() is necessary as belows.
Because shadow registers such as VIDCON0 should be protectd
whenever the registers are updated. The s3c_fb_enable() updates
VIDCON0.
+ shadow_protect_win(win, 1);
+ s3c_fb_enable(sfb, sfb-enabled ? 1 : 0);
+ shadow_protect_win(win, 0);
Right. Thanks for the correction. I will submit updated patch series soon.
Regards,
Thomas.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: Exynos: fix SDHCI device names in regulator definitions
On 3/6/12, Kukjin Kim kgene@samsung.com wrote:
On 03/01/12 00:40, Marek Szyprowski wrote:
Patch 189eb7407 ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci
controllers changed the names of the SDHCI devices, but the author forgot
to update the definitions for the regulator subsystem. This patch fixes
this issue.
Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c |4 ++--
arch/arm/mach-exynos/mach-universal_c210.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 8c0479f..dd26581 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -117,7 +117,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply emmc_supplies[] = {
-REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
REGULATOR_SUPPLY(vmmc, dw_mmc),
};
@@ -417,7 +417,7 @@ static struct regulator_consumer_supply __initdata
max8997_ldo12_[] = {
REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
};
static struct regulator_consumer_supply __initdata max8997_ldo13_[] = {
-REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
+REGULATOR_SUPPLY(vmmc, exynos4-sdhci.2), /* TFLASH */
};
static struct regulator_consumer_supply __initdata max8997_ldo14_[] = {
REGULATOR_SUPPLY(inmotor, max8997-haptic),
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 908624c..7cd738c 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -750,7 +750,7 @@ static struct s3c_sdhci_platdata universal_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply mmc0_supplies[] = {
-REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
};
static struct regulator_init_data mmc0_fixed_voltage_init_data = {
(Cc'ed Jaehoon Chung)
Oops, I looked at same patch from Jaehoon Chung just now and it could
be. However, including same Signed-off-by from Kyungmin Park, it seems
wrong. What's happened in your side?
As your delayed work, we did the same thing from both side.
Most of all, exynos4-sdhci patchset should contains these change also.
as wrong merge, it breaks all sdhci support at least exynos4 series.
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: Exynos: fix SDHCI caps for UniversalC210 and NURI boards
On 03/01/12 00:40, Marek Szyprowski wrote:
Add a new quirk (introduced in 6e8201f57c935 mmc: core: add the capability
for broken voltage to indicate that MMC core should ignore voltage change
errors reported by the regulators core. This is required to get SDHCI
working on these boards again after commit ceb6143b2df81c (mmc: sdhci:
fix vmmc handling).
Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c |2 ++
arch/arm/mach-exynos/mach-universal_c210.c |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index a6b9162..8c0479f 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -112,6 +112,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_DISABLE | MMC_CAP_ERASE),
+ .host_caps2 = MMC_CAP2_BROKEN_VOLTAGE,
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
@@ -151,6 +152,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc2_data
__initdata = {
.host_caps = MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_DISABLE,
+ .host_caps2 = MMC_CAP2_BROKEN_VOLTAGE,
.ext_cd_gpio= EXYNOS4_GPX3(3), /* XEINT_27 */
.ext_cd_gpio_invert = 1,
.cd_type= S3C_SDHCI_CD_GPIO,
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 6017a21..908624c 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -745,6 +745,7 @@ static struct s3c_sdhci_platdata universal_hsmmc0_data
__initdata = {
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_DISABLE),
+ .host_caps2 = MMC_CAP2_BROKEN_VOLTAGE,
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
Hi Marek,
If possible, please adding cover letter for patch set(series), I think
these are just independent patches though. Anyway, will apply this.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: Exynos: fix SDHCI device names in regulator definitions
On 03/06/12 02:13, Kyungmin Park wrote:
On 3/6/12, Kukjin Kimkgene@samsung.com wrote:
On 03/01/12 00:40, Marek Szyprowski wrote:
Patch 189eb7407 ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci
controllers changed the names of the SDHCI devices, but the author forgot
to update the definitions for the regulator subsystem. This patch fixes
this issue.
Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c |4 ++--
arch/arm/mach-exynos/mach-universal_c210.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 8c0479f..dd26581 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -117,7 +117,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply emmc_supplies[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
REGULATOR_SUPPLY(vmmc, dw_mmc),
};
@@ -417,7 +417,7 @@ static struct regulator_consumer_supply __initdata
max8997_ldo12_[] = {
REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
};
static struct regulator_consumer_supply __initdata max8997_ldo13_[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.2), /* TFLASH */
};
static struct regulator_consumer_supply __initdata max8997_ldo14_[] = {
REGULATOR_SUPPLY(inmotor, max8997-haptic),
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 908624c..7cd738c 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -750,7 +750,7 @@ static struct s3c_sdhci_platdata universal_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply mmc0_supplies[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
};
static struct regulator_init_data mmc0_fixed_voltage_init_data = {
(Cc'ed Jaehoon Chung)
Oops, I looked at same patch from Jaehoon Chung just now and it could
be. However, including same Signed-off-by from Kyungmin Park, it seems
wrong. What's happened in your side?
As your delayed work, we did the same thing from both side.
NO! As I remember, there was same case from your side before. My concern
is still how your sign can be added in duplication same patches but
other author?
Most of all, exynos4-sdhci patchset should contains these change also.
as wrong merge, it breaks all sdhci support at least exynos4 series.
Wrong merge? what's that?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Samsung fixes-4 for v3.3
Hi Arnd, Olof Please pull Samsung fixes for v3.3. If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 6b21d18ed50c7d145220b0724ea7f2613abf0f95: Linux 3.3-rc5 (2012-02-25 12:18:16 -0800) are available in the git repository at: ssh://gitol...@ra.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.3-samsung-fixes-4 Bartlomiej Zolnierkiewicz (1): ARM: EXYNOS: fix touchscreen IRQ setup on Universal C210 board Gusakov Andrey (1): ARM: S3C24XX: DMA resume regression fix Heiko Stuebner (1): ARM: S3C24XX: Fix restart on S3C2442 Joonyoung Shim (1): ARM: SAMSUNG: Fix memory size for hsotg arch/arm/mach-exynos/mach-universal_c210.c |2 ++ arch/arm/mach-s3c2440/common.h |2 +- arch/arm/mach-s3c2440/mach-anubis.c|2 +- arch/arm/mach-s3c2440/mach-at2440evb.c |2 +- arch/arm/mach-s3c2440/mach-gta02.c |2 +- arch/arm/mach-s3c2440/mach-mini2440.c |2 +- arch/arm/mach-s3c2440/mach-nexcoder.c |2 +- arch/arm/mach-s3c2440/mach-osiris.c|2 +- arch/arm/mach-s3c2440/mach-rx1950.c|2 +- arch/arm/mach-s3c2440/mach-rx3715.c|2 +- arch/arm/mach-s3c2440/mach-smdk2440.c |2 +- arch/arm/mach-s3c2440/s3c2440.c| 13 - arch/arm/mach-s3c2440/s3c244x.c| 11 +++ arch/arm/plat-s3c24xx/dma.c|2 +- arch/arm/plat-samsung/devs.c |2 +- 15 files changed, 25 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung fixes-4 for v3.3
On 03/06/12 02:28, Kukjin Kim wrote: Hi Arnd, Olof Please pull Samsung fixes for v3.3. If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 6b21d18ed50c7d145220b0724ea7f2613abf0f95: Linux 3.3-rc5 (2012-02-25 12:18:16 -0800) are available in the git repository at: ssh://gitol...@ra.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.3-samsung-fixes-4 Oops, should be... git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git Bartlomiej Zolnierkiewicz (1): ARM: EXYNOS: fix touchscreen IRQ setup on Universal C210 board Gusakov Andrey (1): ARM: S3C24XX: DMA resume regression fix Heiko Stuebner (1): ARM: S3C24XX: Fix restart on S3C2442 Joonyoung Shim (1): ARM: SAMSUNG: Fix memory size for hsotg arch/arm/mach-exynos/mach-universal_c210.c | 2 ++ arch/arm/mach-s3c2440/common.h | 2 +- arch/arm/mach-s3c2440/mach-anubis.c | 2 +- arch/arm/mach-s3c2440/mach-at2440evb.c | 2 +- arch/arm/mach-s3c2440/mach-gta02.c | 2 +- arch/arm/mach-s3c2440/mach-mini2440.c | 2 +- arch/arm/mach-s3c2440/mach-nexcoder.c | 2 +- arch/arm/mach-s3c2440/mach-osiris.c | 2 +- arch/arm/mach-s3c2440/mach-rx1950.c | 2 +- arch/arm/mach-s3c2440/mach-rx3715.c | 2 +- arch/arm/mach-s3c2440/mach-smdk2440.c | 2 +- arch/arm/mach-s3c2440/s3c2440.c | 13 - arch/arm/mach-s3c2440/s3c244x.c | 11 +++ arch/arm/plat-s3c24xx/dma.c | 2 +- arch/arm/plat-samsung/devs.c | 2 +- 15 files changed, 25 insertions(+), 25 deletions(-) -- Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: Exynos: fix SDHCI device names in regulator definitions
On 3/6/12, Kukjin Kim kgene@samsung.com wrote:
On 03/06/12 02:13, Kyungmin Park wrote:
On 3/6/12, Kukjin Kimkgene@samsung.com wrote:
On 03/01/12 00:40, Marek Szyprowski wrote:
Patch 189eb7407 ARM: EXYNOS: use 'exynos4-sdhci' as device name for
sdhci
controllers changed the names of the SDHCI devices, but the author
forgot
to update the definitions for the regulator subsystem. This patch fixes
this issue.
Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c |4 ++--
arch/arm/mach-exynos/mach-universal_c210.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 8c0479f..dd26581 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -117,7 +117,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply emmc_supplies[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
REGULATOR_SUPPLY(vmmc, dw_mmc),
};
@@ -417,7 +417,7 @@ static struct regulator_consumer_supply __initdata
max8997_ldo12_[] = {
REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
};
static struct regulator_consumer_supply __initdata max8997_ldo13_[] =
{
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.2), /* TFLASH */
};
static struct regulator_consumer_supply __initdata max8997_ldo14_[] =
{
REGULATOR_SUPPLY(inmotor, max8997-haptic),
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 908624c..7cd738c 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -750,7 +750,7 @@ static struct s3c_sdhci_platdata
universal_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply mmc0_supplies[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
};
static struct regulator_init_data mmc0_fixed_voltage_init_data = {
(Cc'ed Jaehoon Chung)
Oops, I looked at same patch from Jaehoon Chung just now and it could
be. However, including same Signed-off-by from Kyungmin Park, it seems
wrong. What's happened in your side?
As your delayed work, we did the same thing from both side.
NO! As I remember, there was same case from your side before. My concern
is still how your sign can be added in duplication same patches but
other author?
Most of all, exynos4-sdhci patchset should contains these change also.
as wrong merge, it breaks all sdhci support at least exynos4 series.
Wrong merge? what's that?
That's problem. you don't know what you did. Did you test the
exynos4-sdhci patchset from Thomas?
and think why this patch is required.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file
On Tue, Mar 06, 2012 at 03:17:20PM +0900, Jaehoon Chung wrote: This patchset is the purpose for using sdhci-pltfm.c and removing the arch dependency. The sdhci-s3c has too heavy arch dependency. For example, if work for sdhci-s3c.c at mmc-tree, sometime need to change sdhci.h for Samsung-Soc. This series will break S3C64xx, you've not touched it at all in the update but it uses the same SDHCI controller. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 3/3] iommu/exynos: Add iommu driver for Exynos Platforms
Hi,
some not critical comments.
Thank you,
Kyungmin Park
On Tue, Mar 6, 2012 at 5:31 PM, KyongHo Cho pullip@samsung.com wrote:
HAALgBjAGgAbwBAAHMAYQBtAHMAdQBuAGcALgBjAG8AbQA=;Tue,
06 Mar 2012 08:31:29
GMT;WwBQAEEAVABDAEgAIAB2ADEAMAAgADMALwAzAF0AIABpAG8AbQBtAHUALwBlAHgAeQBuAG8AcwA6ACAAQQBkAGQAIABpAG8AbQBtAHUAIABkAHIAaQB2AGUAcgAgAGYAbwByACAARQB4AHkAbgBvAHMAIABQAGwAYQB0AGYAbwByAG0AcwA=
x-cr-puzzleid: {CF0AAF04-8639-4D69-B4E1-BF71EA1B0A70}
What's this?
This is the System MMU driver and IOMMU API implementation for
Exynos SOC platforms. Exynos platforms has more than 10 System
MMUs dedicated for each multimedia accellerators.
The System MMU driver is already in arc/arm/plat-s5p but it is
moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers
there
Any device driver in Exynos platforms that needs to control its
System MMU must call platform_set_sysmmu() to inform System MMU
driver who will control it.
platform_set_sysmmu() is defined in mach/sysmmu.h
Does it really required? if we can remove it. it can be compiled
without arch dependency.
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: KyongHo Cho pullip@samsung.com
---
drivers/iommu/Kconfig | 21 +
drivers/iommu/Makefile | 1 +
drivers/iommu/exynos-iommu.c | 1088
++
3 files changed, 1110 insertions(+), 0 deletions(-)
create mode 100644 drivers/iommu/exynos-iommu.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 6bea696..25d3eed 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -142,4 +142,25 @@ config OMAP_IOMMU_DEBUG
Say N unless you know you need this.
+config EXYNOS_IOMMU
+ bool Exynos IOMMU Support
+ depends on EXYNOS_DEV_SYSMMU
+ select IOMMU_API
+ help
+ Support for the IOMMU(System MMU) of Samsung Exynos application
+ processor family. This enables H/W multimedia accellerators to see
+ non-linear physical memory chunks as a linear memory in their
+ address spaces
+
+ If unsure, say N here.
+
+config EXYNOS_IOMMU_DEBUG
+ bool Debugging log for Exynos IOMMU
+ depends on EXYNOS_IOMMU
+ help
+ Select this to see the detailed log message that shows what
+ happens in the IOMMU driver
+
+ Say N unless you need kernel log message for IOMMU debugging
+
endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 0e36b49..5a8fd97 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_IRQ_REMAP) += intr_remapping.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
+obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
new file mode 100644
index 000..4c1c48a
--- /dev/null
+++ b/drivers/iommu/exynos-iommu.c
@@ -0,0 +1,1088 @@
+/* linux/drivers/iommu/exynos_iommu.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifdef CONFIG_EXYNOS_IOMMU_DEBUG
+#define DEBUG
+#endif
If it's used only at here. you can add it at Makefile.
ifeq ($(CONFIG_EXYNOS_IOMMU_DEBUG),y)
CFLAGS-exynos-iommu+= -DDEBUG
endif
Of course you can select as your preference.
+
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/mm.h
+#include linux/iommu.h
+#include linux/errno.h
+#include linux/list.h
+#include linux/memblock.h
+#include linux/export.h
+
+#include asm/cacheflush.h
+#include asm/pgtable.h
+
+#include mach/sysmmu.h
+
+#define S5P_MMU_CTRL 0x000
+#define S5P_MMU_CFG 0x004
+#define S5P_MMU_STATUS 0x008
+#define S5P_MMU_FLUSH 0x00C
+#define S5P_PT_BASE_ADDR 0x014
+#define S5P_INT_STATUS 0x018
+#define S5P_INT_CLEAR 0x01C
+#define S5P_PAGE_FAULT_ADDR 0x024
+#define S5P_AW_FAULT_ADDR 0x028
+#define S5P_AR_FAULT_ADDR 0x02C
+#define S5P_DEFAULT_SLAVE_ADDR 0x030
+#define S5P_MMU_VERSION 0x034
+#define S5P_PB0_SADDR 0x04C
+#define S5P_PB0_EADDR 0x050
+#define S5P_PB1_SADDR 0x054
+#define S5P_PB1_EADDR 0x058
+
+#define SECT_ORDER 20
+#define LPAGE_ORDER 16
+#define SPAGE_ORDER 12
+
+#define SECT_SIZE (1 SECT_ORDER)
+#define
Re: [PATCH v3 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file
Am Dienstag, 6. März 2012, 14:00:54 schrieb Mark Brown: On Tue, Mar 06, 2012 at 03:17:20PM +0900, Jaehoon Chung wrote: This patchset is the purpose for using sdhci-pltfm.c and removing the arch dependency. The sdhci-s3c has too heavy arch dependency. For example, if work for sdhci-s3c.c at mmc-tree, sometime need to change sdhci.h for Samsung-Soc. This series will break S3C64xx, you've not touched it at all in the update but it uses the same SDHCI controller. This problem will probably also surface for the S3C2416 which also uses the same SDHCI controller. Heiko -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file
2012/3/6 Heiko Stübner he...@sntech.de: Am Dienstag, 6. März 2012, 14:00:54 schrieb Mark Brown: On Tue, Mar 06, 2012 at 03:17:20PM +0900, Jaehoon Chung wrote: This patchset is the purpose for using sdhci-pltfm.c and removing the arch dependency. The sdhci-s3c has too heavy arch dependency. For example, if work for sdhci-s3c.c at mmc-tree, sometime need to change sdhci.h for Samsung-Soc. This series will break S3C64xx, you've not touched it at all in the update but it uses the same SDHCI controller. This problem will probably also surface for the S3C2416 which also uses the same SDHCI controller. i didn't know why will break on them. Could you explain to me? Are there codes which affect S3C64XX and S3C24XX? If i miss out something, let me know. Best Regards, Jaehoon Chung Heiko -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: EXYNOS: Hook up power domains to generic power domain infrastructure (part 2)
On Thursday 01 March 2012 04:58:23 Kukjin Kim wrote: Bartlomiej Zolnierkiewicz wrote: * Add support of enabling/disabling modules in S5P_CLKGATE_BLOCK register. NO. I remember, we talked about this before and I'm still thinking it should be handled independently. OK, here is only the cleanup part. Unfortunately I couldn't find the previous discussion regarding S5P_CLKGATE_BLOCK register handling on the public mailing lists so could you please describe how it should be done properly? Best regards, -- Bartlomiej Zolnierkiewicz Samsung Poland RD Center From: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Subject: [PATCH] ARM: EXYNOS: Remove leftovers of the Samsung specific power domain control Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rafael J. Wysocki r...@sisk.pl Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/mach-nuri.c |1 arch/arm/mach-exynos/mach-origen.c |1 arch/arm/mach-exynos/mach-smdkv310.c |1 arch/arm/mach-exynos/mach-universal_c210.c |1 arch/arm/plat-samsung/Kconfig |8 -- arch/arm/plat-samsung/Makefile |4 - arch/arm/plat-samsung/include/plat/devs.h |1 arch/arm/plat-samsung/include/plat/pd.h| 30 - arch/arm/plat-samsung/pd.c | 95 - 9 files changed, 142 deletions(-) Index: linux-sprc/arch/arm/mach-exynos/mach-nuri.c === --- linux-sprc.orig/arch/arm/mach-exynos/mach-nuri.c2012-03-06 15:59:13.432481942 +0100 +++ linux-sprc/arch/arm/mach-exynos/mach-nuri.c 2012-03-06 15:59:22.528481940 +0100 @@ -48,7 +48,6 @@ #include plat/gpio-cfg.h #include plat/iic.h #include plat/mfc.h -#include plat/pd.h #include plat/fimc-core.h #include plat/camport.h #include plat/mipi_csis.h Index: linux-sprc/arch/arm/mach-exynos/mach-origen.c === --- linux-sprc.orig/arch/arm/mach-exynos/mach-origen.c 2012-03-06 15:59:13.432481942 +0100 +++ linux-sprc/arch/arm/mach-exynos/mach-origen.c 2012-03-06 15:59:22.528481940 +0100 @@ -38,7 +38,6 @@ #include plat/clock.h #include plat/gpio-cfg.h #include plat/backlight.h -#include plat/pd.h #include plat/fb.h #include plat/mfc.h Index: linux-sprc/arch/arm/mach-exynos/mach-smdkv310.c === --- linux-sprc.orig/arch/arm/mach-exynos/mach-smdkv310.c2012-03-06 15:59:13.432481942 +0100 +++ linux-sprc/arch/arm/mach-exynos/mach-smdkv310.c 2012-03-06 15:59:22.532481931 +0100 @@ -34,7 +34,6 @@ #include plat/keypad.h #include plat/sdhci.h #include plat/iic.h -#include plat/pd.h #include plat/gpio-cfg.h #include plat/backlight.h #include plat/mfc.h Index: linux-sprc/arch/arm/mach-exynos/mach-universal_c210.c === --- linux-sprc.orig/arch/arm/mach-exynos/mach-universal_c210.c 2012-03-06 15:59:13.432481942 +0100 +++ linux-sprc/arch/arm/mach-exynos/mach-universal_c210.c 2012-03-06 15:59:22.532481931 +0100 @@ -35,7 +35,6 @@ #include plat/fb.h #include plat/mfc.h #include plat/sdhci.h -#include plat/pd.h #include plat/regs-fb-v4.h #include plat/fimc-core.h #include plat/camport.h Index: linux-sprc/arch/arm/plat-samsung/Kconfig === --- linux-sprc.orig/arch/arm/plat-samsung/Kconfig 2012-03-06 15:57:57.092481952 +0100 +++ linux-sprc/arch/arm/plat-samsung/Kconfig2012-03-06 15:59:22.532481931 +0100 @@ -350,14 +350,6 @@ and above. This code allows a set of interrupt to wakeup-mask mappings. See plat/wakeup-mask.h -comment Power Domain - -config SAMSUNG_PD - bool Samsung Power Domain - depends on PM_RUNTIME - help - Say Y here if you want to control Power Domain by Runtime PM. - config DEBUG_S3C_UART depends on PLAT_SAMSUNG int Index: linux-sprc/arch/arm/plat-samsung/Makefile === --- linux-sprc.orig/arch/arm/plat-samsung/Makefile 2012-03-06 15:57:57.092481952 +0100 +++ linux-sprc/arch/arm/plat-samsung/Makefile 2012-03-06 15:59:22.532481931 +0100 @@ -47,10 +47,6 @@ obj-$(CONFIG_SAMSUNG_WAKEMASK) += wakeup-mask.o -# PD support - -obj-$(CONFIG_SAMSUNG_PD) += pd.o - # PWM support obj-$(CONFIG_HAVE_PWM) += pwm.o Index: linux-sprc/arch/arm/plat-samsung/include/plat/devs.h === --- linux-sprc.orig/arch/arm/plat-samsung/include/plat/devs.h 2012-03-06 15:59:13.81941 +0100 +++ linux-sprc/arch/arm/plat-samsung/include/plat/devs.h2012-03-06
Re: [PATCH v3 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file
On Tue, Mar 06, 2012 at 11:40:08PM +0900, Jae hoon Chung wrote: 2012/3/6 Heiko Stübner he...@sntech.de: Am Dienstag, 6. März 2012, 14:00:54 schrieb Mark Brown: This series will break S3C64xx, you've not touched it at all in the update but it uses the same SDHCI controller. This problem will probably also surface for the S3C2416 which also uses the same SDHCI controller. i didn't know why will break on them. Could you explain to me? Are there codes which affect S3C64XX and S3C24XX? If i miss out something, let me know. The same IP is present and used with the same driver on other Samsung SoCs. signature.asc Description: Digital signature
Re: [PATCH v2 04/11] ARM: EXYNOS: add interrupt definitions for EXYNOS5250
Hi, On Tue, Feb 21, 2012 at 2:35 AM, Kukjin Kim kgene@samsung.com wrote: Yes, as you said, it brakes single zImage for EXYNOS4 + EXYNOS5 (mach-exynos). So I'm working on regarding resource for EXYNOS SoCs and I think, it can resolve the problem you said before v3.4 merge window. If any updates, let you know. Just a friendly reminder; the time is close to running out for staging new code for 3.4. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
+struct dma_iommu_mapping *
+arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t
size,
+int order)
+{
+ unsigned int count = (size PAGE_SHIFT) - order;
+ unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
The count calculation doesn't seem correct. order is log2 number and
size PAGE_SHIFT is number of pages.
If size is passed as 64*4096(256KB) and order is 6(allocation granularity is
2^6 pages=256KB),
just 1 bit is enough to manage allocations. So it should be 4 bytes or one
long.
But the calculation gives count = 64 - 6 = 58 and
Bitmap_size gets set to (58/(4*8)) * 4 = 8 bytes, which is incorrect.
It should be as follows.
unsigned int count = 1 get_order(size) - order;
unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long) * BITS_PER_BYTE;
-KR
--nvpublic
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
On Wed, Feb 29, 2012 at 04:04:22PM +0100, Marek Szyprowski wrote:
+static int arm_iommu_mmap_attrs(struct device *dev, struct vm_area_struct
*vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ struct dma_attrs *attrs)
+{
+ struct arm_vmregion *c;
+
+ vma-vm_page_prot = __get_dma_pgprot(attrs, vma-vm_page_prot);
+ c = arm_vmregion_find(consistent_head, (unsigned long)cpu_addr);
What protects this against other insertions/removals from the list?
+
+ if (c) {
+ struct page **pages = c-priv;
+
+ unsigned long uaddr = vma-vm_start;
+ unsigned long usize = vma-vm_end - vma-vm_start;
+ int i = 0;
+
+ do {
+ int ret;
+
+ ret = vm_insert_page(vma, uaddr, pages[i++]);
+ if (ret) {
+ pr_err(Remapping memory, error: %d\n, ret);
+ return ret;
+ }
+
+ uaddr += PAGE_SIZE;
+ usize -= PAGE_SIZE;
+ } while (usize 0);
+ }
+ return 0;
+}
+
+/*
+ * free a page as defined by the above mapping.
+ * Must not be called with IRQs disabled.
+ */
+void arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
+ dma_addr_t handle, struct dma_attrs *attrs)
+{
+ struct arm_vmregion *c;
+ size = PAGE_ALIGN(size);
+
+ c = arm_vmregion_find(consistent_head, (unsigned long)cpu_addr);
What protects this against other insertions/removals from the list?
+ if (c) {
+ struct page **pages = c-priv;
+ __dma_free_remap(cpu_addr, size);
+ __iommu_remove_mapping(dev, handle, size);
+ __iommu_free_buffer(dev, pages, size);
+ }
+}
+
+/*
+ * Map a part of the scatter-gather list into contiguous io address space
+ */
+static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
+ size_t size, dma_addr_t *handle,
+ enum dma_data_direction dir)
+{
+ struct dma_iommu_mapping *mapping = dev-archdata.mapping;
+ dma_addr_t iova, iova_base;
+ int ret = 0;
+ unsigned int count;
+ struct scatterlist *s;
+
+ size = PAGE_ALIGN(size);
+ *handle = ARM_DMA_ERROR;
+
+ iova_base = iova = __alloc_iova(mapping, size);
+ if (iova == ARM_DMA_ERROR)
+ return -ENOMEM;
+
+ for (count = 0, s = sg; count (size PAGE_SHIFT); s = sg_next(s))
+ {
+ phys_addr_t phys = page_to_phys(sg_page(s));
+ unsigned int len = PAGE_ALIGN(s-offset + s-length);
+
+ if (!arch_is_coherent())
+ __dma_page_cpu_to_dev(sg_page(s), s-offset, s-length,
dir);
+
+ ret = iommu_map(mapping-domain, iova, phys, len, 0);
Dealing with phys addresses on one part and pages + offset + length
in a different part doesn't look like a good idea. Why can't there
be some consistency?
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
On Wed, Feb 29, 2012 at 04:04:22PM +0100, Marek Szyprowski wrote:
+static int arm_iommu_mmap_attrs(struct device *dev, struct
vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ struct dma_attrs *attrs)
+{
+ struct arm_vmregion *c;
+
+ vma-vm_page_prot = __get_dma_pgprot(attrs, vma-
vm_page_prot);
+ c = arm_vmregion_find(consistent_head, (unsigned
long)cpu_addr);
What protects this against other insertions/removals from the list?
arm_vmregion_find uses a spin_lock internally before accessing consistent_head.
So, it is protected.
-KR
--nvpublic
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/3] ARM: EXYNOS: Change System MMU platform device definitions
On Tue, Mar 6, 2012 at 7:03 PM, Kyungmin Park kyungmin.p...@samsung.com wrote: -#define S5P_SYSMMU_TOTAL_IPNUM EXYNOS4_SYSMMU_TOTAL_IPNUM +#define SYSMMU_DEVNAME_BASE exynos-sysmmu + +#define SYSMMU_CLOCK_NAME sysmmu +#define SYSMMU_CLOCK_NAME2 sysmmu_mc What's the meaning of mc? It stands for multi clock gating source. ISP block has a lot of System MMUs and I merged them in a single platform device to control them easier. However it is required to access 2 control registers to gating their clocks. sysmmu_mc is prepared for the case that requires 2 clock descriptors for clock gating. + +#ifdef CONFIG_EXYNOS_DEV_SYSMMU +#include linux/device.h +struct platform_device; + +#define SYSMMU_PLATDEV(ipname) exynos_device_sysmmu_##ipname + +extern struct platform_device SYSMMU_PLATDEV(mfc_l); +extern struct platform_device SYSMMU_PLATDEV(mfc_r); +extern struct platform_device SYSMMU_PLATDEV(tv); +extern struct platform_device SYSMMU_PLATDEV(jpeg); +extern struct platform_device SYSMMU_PLATDEV(rot); Where's the fimc platform_device? I think you only tested it with exynos5. True. I am sorry that I have missed to define it externally. Thank you. Cho KyongHo. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 3/3] iommu/exynos: Add iommu driver for Exynos Platforms
On Tue, Mar 6, 2012 at 10:13 PM, Kyungmin Park kmp...@infradead.org wrote:
On Tue, Mar 6, 2012 at 5:31 PM, KyongHo Cho pullip@samsung.com wrote:
HAALgBjAGgAbwBAAHMAYQBtAHMAdQBuAGcALgBjAG8AbQA=;Tue,
06 Mar 2012 08:31:29
GMT;WwBQAEEAVABDAEgAIAB2ADEAMAAgADMALwAzAF0AIABpAG8AbQBtAHUALwBlAHgAeQBuAG8AcwA6ACAAQQBkAGQAIABpAG8AbQBtAHUAIABkAHIAaQB2AGUAcgAgAGYAbwByACAARQB4AHkAbgBvAHMAIABQAGwAYQB0AGYAbwByAG0AcwA=
x-cr-puzzleid: {CF0AAF04-8639-4D69-B4E1-BF71EA1B0A70}
What's this?
I think it is inserted by Outlook and it was not found in the email editor
before sending this patch. I am unable to use sendmail due to security
reason in my company.
I will find a way not to insert the above message. Thank you.
This is the System MMU driver and IOMMU API implementation for
Exynos SOC platforms. Exynos platforms has more than 10 System
MMUs dedicated for each multimedia accellerators.
The System MMU driver is already in arc/arm/plat-s5p but it is
moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers
there
Any device driver in Exynos platforms that needs to control its
System MMU must call platform_set_sysmmu() to inform System MMU
driver who will control it.
platform_set_sysmmu() is defined in mach/sysmmu.h
Does it really required? if we can remove it. it can be compiled
without arch dependency.
The function must be called while board initialization and all source files for
the purpose is placed in 'mach' directory. Thus device driver is not dependent
on arch except the definition of data structure conveyed in
device.platform_data.
Since our System MMUs are attached to each peripheral devices, it is required
to define relationships between System MMUs and peripheral devices.
platform_set_sysmmu() defines the relationship.
+
+#ifdef CONFIG_EXYNOS_IOMMU_DEBUG
+#define DEBUG
+#endif
If it's used only at here. you can add it at Makefile.
ifeq ($(CONFIG_EXYNOS_IOMMU_DEBUG),y)
CFLAGS-exynos-iommu += -DDEBUG
endif
Of course you can select as your preference.
Thank you for advice.
+
+#define lv2ent_fault(pent) ((*(pent) 3) == 0)
+#define lv2ent_small(pent) ((*(pent) 2) == 2)
#define lv2ent_small(pent) ((*(pent) 3) == 2)?
The last bit is 'don't-care'.
It is intentionally ignored in the above comparison.
+
+#define REG_MMU_CTRL 0x000
+#define REG_MMU_CFG 0x004
+#define REG_MMU_STATUS 0x008
+#define REG_MMU_FLUSH 0x00C
+#define REG_MMU_FLUSH_ENTRY 0x010
+#define REG_PT_BASE_ADDR 0x014
+#define REG_INT_STATUS 0x018
+#define REG_INT_CLEAR 0x01C
+#define REG_MMU_VERSION 0x034
Please place it in order.
I found that a mistake while defining the offsets of control registers.
I will fix it.
+
+enum EXYNOS_SYSMMU_INTERRUPT_TYPE {
+ SYSMMU_PAGEFAULT,
+ SYSMMU_AR_MULTIHIT,
+ SYSMMU_AW_MULTIHIT,
+ SYSMMU_BUSERROR,
+ SYSMMU_AR_SECURITY,
+ SYSMMU_AR_ACCESS,
+ SYSMMU_AW_SECURITY,
+ SYSMMU_AW_PROTECTION, /* 7 */
+ SYSMMU_FAULT_UNKNOWN,
+ SYSMMU_FAULTS_NUM
missing comma, SYSMMU_FAULTS_NUM,
Yes it is. I don't think that it is needed to appending comma after
the last element
unless it is predictable that adding elements after the last element
in the future.
+};
+
+typedef int (*sysmmu_fault_handler_t)(enum EXYNOS_SYSMMU_INTERRUPT_TYPE
itype,
+ unsigned long pgtable_base, unsigned long
fault_addr);
+
+static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
+ REG_PAGE_FAULT_ADDR,
+ REG_AR_FAULT_ADDR,
+ REG_AW_FAULT_ADDR,
+ REG_DEFAULT_SLAVE_ADDR,
+ REG_AR_FAULT_ADDR,
+ REG_AR_FAULT_ADDR,
+ REG_AW_FAULT_ADDR,
+ REG_AW_FAULT_ADDR
ditto.
Answered above.
+};
+
+static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
+ PAGE FAULT,
+ AR MULTI-HIT FAULT,
+ AW MULTI-HIT FAULT,
+ BUS ERROR,
+ AR SECURITY PROTECTION FAULT,
+ AR ACCESS PROTECTION FAULT,
+ AW SECURITY PROTECTION FAULT,
+ AW ACCESS PROTECTION FAULT,
+ UNKNOWN FAULT
ditto.
Answered above.
+void exynos_sysmmu_set_prefbuf(struct device *dev,
+ unsigned long base0, unsigned long size0,
+ unsigned long base1, unsigned long size1)
+{
+ struct sysmmu_drvdata *data = dev_get_drvdata(dev-archdata.iommu);
+ unsigned long flags;
+ int i;
+
+ BUG_ON((base0 + size0) = base0);
+ BUG_ON((size1 0) ((base1 + size1) = base1));
It's bogus check. it's impossible. Do you think overflow case?
Yes I do.
It is prepared to detect invalid parameters from device drivers.
+
+ read_lock_irqsave(data-lock, flags);
+ if (!is_sysmmu_active(data))
+ goto finish;
+
+ for (i = 0; i data-nsfrs; i++) {
+ if ((readl(data-sfrbases[i] + S5P_MMU_VERSION) 28) == 3)
{
+
Re: [PATCH v3 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file
On 03/07/2012 01:30 AM, Mark Brown wrote: On Tue, Mar 06, 2012 at 11:40:08PM +0900, Jae hoon Chung wrote: 2012/3/6 Heiko Stübner he...@sntech.de: Am Dienstag, 6. März 2012, 14:00:54 schrieb Mark Brown: This series will break S3C64xx, you've not touched it at all in the update but it uses the same SDHCI controller. This problem will probably also surface for the S3C2416 which also uses the same SDHCI controller. i didn't know why will break on them. Could you explain to me? Are there codes which affect S3C64XX and S3C24XX? If i miss out something, let me know. The same IP is present and used with the same driver on other Samsung SoCs. Hi Mark. I know that used with the same driver on other Samsung-SoCs(S3C64XX/S3C24XX..etc) I just only used the interface in sdhci-pltfm.c. Nothing difference.. Why do you think that will break the other SoC? Header file(/plat/regs-sdhci.h) also is only used in sdhci-s3c.c. And the least portion is moved into /linux/mmc/. Then included linux/mmc/sdhci-s3c.h in plat/sdhci.h. What's difference? If you can explain the more detail, i can understand. But sorry, now i didn't accept your opinion. Best Regards, Jaehoon Chung -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: EXYNOS: Fix compilation error with mach-exynos4-dt board
Commit 84499abd19d4 (ARM: EXYNOS: add support uart for EXYNOS4 and EXYNOS5)
renames S5P_PA_UARTn to EXYNOS4_PA_UARTn. Hence we need to do
similar modification in mach-exynos4-dt.c to fix compilation error.
arch/arm/mach-exynos/mach-exynos4-dt.c:40:2: error: ‘S5P_PA_UART0’
undeclared here (not in a function)
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/mach-exynos/mach-exynos4-dt.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index e6b02fd..8245f1c 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -37,13 +37,13 @@
* data from the device tree.
*/
static const struct of_dev_auxdata exynos4210_auxdata_lookup[] __initconst = {
- OF_DEV_AUXDATA(samsung,exynos4210-uart, S5P_PA_UART0,
+ OF_DEV_AUXDATA(samsung,exynos4210-uart, EXYNOS4_PA_UART0,
exynos4210-uart.0, NULL),
- OF_DEV_AUXDATA(samsung,exynos4210-uart, S5P_PA_UART1,
+ OF_DEV_AUXDATA(samsung,exynos4210-uart, EXYNOS4_PA_UART1,
exynos4210-uart.1, NULL),
- OF_DEV_AUXDATA(samsung,exynos4210-uart, S5P_PA_UART2,
+ OF_DEV_AUXDATA(samsung,exynos4210-uart, EXYNOS4_PA_UART2,
exynos4210-uart.2, NULL),
- OF_DEV_AUXDATA(samsung,exynos4210-uart, S5P_PA_UART3,
+ OF_DEV_AUXDATA(samsung,exynos4210-uart, EXYNOS4_PA_UART3,
exynos4210-uart.3, NULL),
OF_DEV_AUXDATA(samsung,exynos4210-sdhci, EXYNOS4_PA_HSMMC(0),
exynos4-sdhci.0, NULL),
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 3/3] iommu/exynos: Add iommu driver for Exynos Platforms
+static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
+{
+ /* SYSMMU is in blocked when interrupt occurred. */
+ struct sysmmu_drvdata *data = dev_id;
+ struct resource *irqres;
+ struct platform_device *pdev;
+ enum EXYNOS_SYSMMU_INTERRUPT_TYPE itype;
how about to change EXYNOS_SYSMMU_INTERRUPT_TYPE to small letter? just
for code clean.
+ unsigned long addr = -1;
+
+ int i, ret = -ENOSYS;
+
+ read_lock(data-lock);
+
+ WARN_ON(!is_sysmmu_active(data));
+
+ pdev = to_platform_device(data-sysmmu);
+ for (i = 0; i pdev-num_resources; i++) {
+ irqres = platform_get_resource(pdev, IORESOURCE_IRQ, i);
+ if (irqres ((int)irqres-start == irq))
+ break;
+ }
is there any reason that it should get irq resources in interrupt
handler? if not so then how about to move it into probe()?
+
+ if (i == pdev-num_resources) {
+ itype = SYSMMU_FAULT_UNKNOWN;
+ } else {
+ i /= 2;
+
+ itype = (enum EXYNOS_SYSMMU_INTERRUPT_TYPE)
ditto.
+ __ffs(__raw_readl(data-sfrbases[i] +
REG_INT_STATUS));
+ if (WARN_ON(!((itype = 0) (itype
SYSMMU_FAULT_UNKNOWN
+ itype = SYSMMU_FAULT_UNKNOWN;
+ else
+ addr = __raw_readl(
+ data-sfrbases[i] + fault_reg_offset[itype]);
+ }
+
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
From: Krishna Reddy vdu...@nvidia.com
Subject: RE: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
Date: Tue, 6 Mar 2012 23:48:42 +0100
Message-ID: 401e54ce964cd94bae1eb4a729c7087e3797011...@hqmail04.nvidia.com
+struct dma_iommu_mapping *
+arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t
size,
+int order)
+{
+ unsigned int count = (size PAGE_SHIFT) - order;
+ unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
The count calculation doesn't seem correct. order is log2 number and
size PAGE_SHIFT is number of pages.
If size is passed as 64*4096(256KB) and order is 6(allocation granularity is
2^6 pages=256KB),
just 1 bit is enough to manage allocations. So it should be 4 bytes or one
long.
Good catch!
But the calculation gives count = 64 - 6 = 58 and
Bitmap_size gets set to (58/(4*8)) * 4 = 8 bytes, which is incorrect.
order isn't the order of size passed, which is minimal *page*
allocation order which client decides whatever, just in case.
It should be as follows.
unsigned int count = 1 get_order(size) - order;
unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long) *
BITS_PER_BYTE;
-KR
--nvpublic
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: EXYNOS: Fix compilation error.
Commit 734b5bb7375 (Merge branch 'next/soc-exynos5250-arch-wip' into for-next)
on for-next branch of Kukjin's tree gives the following build errors:
arch/arm/mach-exynos/clock-exynos4.c:1328:2: error: ‘clk_sclk_mmc0’
undeclared here (not in a function)
arch/arm/mach-exynos/clock-exynos4.c:1329:2: error: ‘clk_sclk_mmc1’
undeclared here (not in a function)
arch/arm/mach-exynos/clock-exynos4.c:1330:2: error: ‘clk_sclk_mmc2’
undeclared here (not in a function)
arch/arm/mach-exynos/clock-exynos4.c:1331:2: error: ‘clk_sclk_mmc3’
undeclared here (not in a function)
This commit fixes the same.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/clock-exynos4.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos4.c
b/arch/arm/mach-exynos/clock-exynos4.c
index d72a1fe..bcb59e7 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -1325,10 +1325,10 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT(exynos4210-uart.1, clk_uart_baud0,
exynos4_clk_sclk_uart1.clk),
CLKDEV_INIT(exynos4210-uart.2, clk_uart_baud0,
exynos4_clk_sclk_uart2.clk),
CLKDEV_INIT(exynos4210-uart.3, clk_uart_baud0,
exynos4_clk_sclk_uart3.clk),
- CLKDEV_INIT(exynos4-sdhci.0, mmc_busclk.2, clk_sclk_mmc0.clk),
- CLKDEV_INIT(exynos4-sdhci.1, mmc_busclk.2, clk_sclk_mmc1.clk),
- CLKDEV_INIT(exynos4-sdhci.2, mmc_busclk.2, clk_sclk_mmc2.clk),
- CLKDEV_INIT(exynos4-sdhci.3, mmc_busclk.2, clk_sclk_mmc3.clk),
+ CLKDEV_INIT(exynos4-sdhci.0, mmc_busclk.2,
exynos4_clk_sclk_mmc0.clk),
+ CLKDEV_INIT(exynos4-sdhci.1, mmc_busclk.2,
exynos4_clk_sclk_mmc1.clk),
+ CLKDEV_INIT(exynos4-sdhci.2, mmc_busclk.2,
exynos4_clk_sclk_mmc2.clk),
+ CLKDEV_INIT(exynos4-sdhci.3, mmc_busclk.2,
exynos4_clk_sclk_mmc3.clk),
CLKDEV_INIT(dma-pl330.0, apb_pclk, exynos4_clk_pdma0),
CLKDEV_INIT(dma-pl330.1, apb_pclk, exynos4_clk_pdma1),
CLKDEV_INIT(s3c64xx-spi.0, spi_busclk0, exynos4_clk_sclk_spi0.clk),
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 3/3] iommu/exynos: Add iommu driver for Exynos Platforms
On Wed, Mar 7, 2012 at 2:28 PM, InKi Dae daei...@gmail.com wrote:
+static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
+{
+ /* SYSMMU is in blocked when interrupt occurred. */
+ struct sysmmu_drvdata *data = dev_id;
+ struct resource *irqres;
+ struct platform_device *pdev;
+ enum EXYNOS_SYSMMU_INTERRUPT_TYPE itype;
how about to change EXYNOS_SYSMMU_INTERRUPT_TYPE to small letter? just
for code clean.
I will. please refer to the my reply to Kyungmin Park.
+ unsigned long addr = -1;
+
+ int i, ret = -ENOSYS;
+
+ read_lock(data-lock);
+
+ WARN_ON(!is_sysmmu_active(data));
+
+ pdev = to_platform_device(data-sysmmu);
+ for (i = 0; i pdev-num_resources; i++) {
+ irqres = platform_get_resource(pdev, IORESOURCE_IRQ, i);
+ if (irqres ((int)irqres-start == irq))
+ break;
+ }
is there any reason that it should get irq resources in interrupt
handler? if not so then how about to move it into probe()?
The platform device of ISP has a lot of IRQ sources.
The above for clause determines which IRQ source (System MMU)
generated the interrupt.
+
+ if (i == pdev-num_resources) {
+ itype = SYSMMU_FAULT_UNKNOWN;
+ } else {
+ i /= 2;
+
+ itype = (enum EXYNOS_SYSMMU_INTERRUPT_TYPE)
ditto.
Thank you.
Cho KyongHo.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
From: Hiroshi DOYU hd...@nvidia.com
Subject: Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
Date: Wed, 07 Mar 2012 08:09:52 +0200 (EET)
Message-ID: 20120307.080952.2152478004740487196.hd...@nvidia.com
From: Krishna Reddy vdu...@nvidia.com
Subject: RE: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
Date: Tue, 6 Mar 2012 23:48:42 +0100
Message-ID: 401e54ce964cd94bae1eb4a729c7087e3797011...@hqmail04.nvidia.com
+struct dma_iommu_mapping *
+arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t
size,
+int order)
+{
+ unsigned int count = (size PAGE_SHIFT) - order;
+ unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
The count calculation doesn't seem correct. order is log2 number and
size PAGE_SHIFT is number of pages.
If size is passed as 64*4096(256KB) and order is 6(allocation granularity
is 2^6 pages=256KB),
just 1 bit is enough to manage allocations. So it should be 4 bytes or
one long.
Good catch!
But the calculation gives count = 64 - 6 = 58 and
Bitmap_size gets set to (58/(4*8)) * 4 = 8 bytes, which is incorrect.
order isn't the order of size passed, which is minimal *page*
allocation order which client decides whatever, just in case.
It should be as follows.
unsigned int count = 1 get_order(size) - order;
To be precise, as below?
unsigned int count = 1 (get_order(size) - order);
unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long) *
BITS_PER_BYTE;
-KR
--nvpublic
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
It should be as follows. unsigned int count = 1 get_order(size) - order; To be precise, as below? unsigned int count = 1 (get_order(size) - order); Minus has more precedence than left shift. 1 get_order(size) - order; is equivalent to 1 (get_order(size) - order); -KR --nvpublic -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
From: Hiroshi DOYU hd...@nvidia.com
Subject: Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
Date: Wed, 07 Mar 2012 08:37:06 +0200 (EET)
Message-ID: 20120307.083706.2087121294965856946.hd...@nvidia.com
From: Hiroshi DOYU hd...@nvidia.com
Subject: Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
Date: Wed, 07 Mar 2012 08:09:52 +0200 (EET)
Message-ID: 20120307.080952.2152478004740487196.hd...@nvidia.com
From: Krishna Reddy vdu...@nvidia.com
Subject: RE: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
Date: Tue, 6 Mar 2012 23:48:42 +0100
Message-ID: 401e54ce964cd94bae1eb4a729c7087e3797011...@hqmail04.nvidia.com
+struct dma_iommu_mapping *
+arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base,
size_t size,
+int order)
+{
+ unsigned int count = (size PAGE_SHIFT) - order;
+ unsigned int bitmap_size = BITS_TO_LONGS(count) *
sizeof(long);
The count calculation doesn't seem correct. order is log2 number and
size PAGE_SHIFT is number of pages.
If size is passed as 64*4096(256KB) and order is 6(allocation granularity
is 2^6 pages=256KB),
just 1 bit is enough to manage allocations. So it should be 4 bytes or
one long.
Good catch!
But the calculation gives count = 64 - 6 = 58 and
Bitmap_size gets set to (58/(4*8)) * 4 = 8 bytes, which is incorrect.
order isn't the order of size passed, which is minimal *page*
allocation order which client decides whatever, just in case.
It should be as follows.
unsigned int count = 1 get_order(size) - order;
To be precise, as below?
unsigned int count = 1 (get_order(size) - order);
This could be:
From fd40740ef4bc4a3924fe1188ea6dd785be0fe859 Mon Sep 17 00:00:00 2001
From: Hiroshi DOYU hd...@nvidia.com
Date: Wed, 7 Mar 2012 08:14:38 +0200
Subject: [PATCH 1/1] dma-mapping: Fix count calculation of iova space
Fix count calculation of iova space.
Pointed by Krishna Reddy vdu...@nvidia.com
Signed-off-by: Hiroshi DOYU hd...@nvidia.com
---
arch/arm/mm/dma-mapping.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6c2f104..56f0af5 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1483,11 +1483,18 @@ struct dma_iommu_mapping *
arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
int order)
{
- unsigned int count = (size PAGE_SHIFT) - order;
- unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
+ unsigned int n, count;
+ unsigned int bitmap_size;
struct dma_iommu_mapping *mapping;
int err = -ENOMEM;
+ n = get_order(size);
+ if (n order)
+ return ERR_PTR(-EINVAL);
+
+ count = 1 (n - order);
+ bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
+
mapping = kzalloc(sizeof(struct dma_iommu_mapping), GFP_KERNEL);
if (!mapping)
goto err;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
