RE: [PATCH 8/8 RESEND] ARM: dma-mapping: add support for IOMMU mapper
Hello,
On Wednesday, January 25, 2012 1:59 PM Russell King - ARM Linux wrote:
On Mon, Jan 09, 2012 at 04:49:21PM +0100, Marek Szyprowski wrote:
This patch add a complete implementation of DMA-mapping API for
devices that have IOMMU support. All DMA-mapping calls are supported.
This patch contains some of the code kindly provided by Krishna Reddy
vdu...@nvidia.com and Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Hello,
This is the corrected version of the previous patch from the [PATCH 0/8
v4] ARM: DMA-mapping framework redesign thread which can be found here:
http://www.spinics.net/lists/linux-mm/msg27382.html
Previous version had very nasty bug which causes memory trashing if
DMA-mapping managed to allocate pages larger than 4KiB. The problem was
in __iommu_alloc_buffer() function which did not check how many pages
has been left to allocate.
This patch seems to be incomplete.
If the standard DMA API is used (the one which exists in current kernels)
and NEED_SG_DMA_LENGTH is enabled, then where do we set the DMA length
in the scatterlist?
Standard DMA API is also updated to work correctly with NEED_SG_DMA_LENGTH,
please notice the following chunk:
-
@@ -644,6 +659,9 @@ int arm_dma_map_sg(struct device *dev, struct scatterlist
*sg, int nents,
int i, j;
for_each_sg(sg, s, nents, i) {
+#ifdef CONFIG_NEED_SG_DMA_LENGTH
+ s-dma_length = s-length;
+#endif
s-dma_address = ops-map_page(dev, sg_page(s), s-offset,
s-length, dir, attrs);
if (dma_mapping_error(dev, s-dma_address))
-
(http://www.spinics.net/lists/arm-kernel/msg154889.html for the reference)
diff --git a/arch/arm/include/asm/dma-iommu.h
b/arch/arm/include/asm/dma-iommu.h
new file mode 100644
index 000..6668b41
--- /dev/null
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -0,0 +1,36 @@
+#ifndef ASMARM_DMA_IOMMU_H
+#define ASMARM_DMA_IOMMU_H
+
+#ifdef __KERNEL__
+
+#include linux/mm_types.h
+#include linux/scatterlist.h
+#include linux/dma-debug.h
+#include linux/kmemcheck.h
+
+#include asm/memory.h
I can't see anything in here which needs asm/memory.h - if files which
include this need it, please include it in there so we can see why it's
needed.
Ok, I will fix this issue.
+
+struct dma_iommu_mapping {
+ /* iommu specific data */
+ struct iommu_domain *domain;
+
+ void*bitmap;
+ size_t bits;
+ unsigned intorder;
+ dma_addr_t base;
+
+ spinlock_t lock;
+ struct kref kref;
+};
+
+struct dma_iommu_mapping *
+arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t
size,
+int order);
+
+void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);
+
+int arm_iommu_attach_device(struct device *dev,
+ struct dma_iommu_mapping *mapping);
+
+#endif /* __KERNEL__ */
+#endif
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4845c09..2287b01 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -27,6 +27,9 @@
#include asm/sizes.h
#include asm/mach/arch.h
+#include linux/iommu.h
linux/ includes should be grouped together.
Ok, I will fix this.
diff --git a/arch/arm/mm/vmregion.h b/arch/arm/mm/vmregion.h
index 15e9f04..6bbc402 100644
--- a/arch/arm/mm/vmregion.h
+++ b/arch/arm/mm/vmregion.h
@@ -17,7 +17,7 @@ struct arm_vmregion {
struct list_headvm_list;
unsigned long vm_start;
unsigned long vm_end;
- struct page *vm_pages;
+ void*priv;
I want to think about that - I may wish to export the vm_pages via
the new dma-mappings file to provide additional information.
For IOMMU case I need to store a page array for each allocated buffer.
I haven't analyzed it yet, but maybe it would be possible to use standard
vmalloc style entries and avoid creating separate arm_vmregion for coherent
allocations?
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
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 v2 2/2] regulator: add device tree support for max8997
On 25.01.2012 14:32, Mark Brown wrote: On Wed, Jan 25, 2012 at 01:02:29PM +0100, Karol Lewandowski wrote: On 25.01.2012 12:26, Mark Brown wrote: However, I still find it little problematic that dt and non-dt versions behave differently when given the same set of parameters (previously apply_uV wasn't the default and required explicit flag). Well, they're different things. Device tree isn't Linux specific at all. There is no official platform-agnostic regulator API, nor DT-bindings document I'm aware of. Thus, I don't see why, while transitioning to DT, should we lose ability to describe certain hardware configurations. On 25.01.2012 12:22, Mark Brown wrote: The big problem there seems like specifying voltages in the first place, if we know what device it is we should already know what's going on. Driver which handles said regulator might know what's going on, but that might not be case for its consumers. Should we limit ability to query given parameter just because its value is hardcoded in hardware? My understanding of this whole device tree effort was to provide ability to describe hardware properties which can't be queried from hardware itself. Consequently, if it's property of hardware that it provides fixed voltage somewhere shouldn't it be possible to describe this fact in DT? If device tree isn't good place for it then which one is? Regards, -- Karol Lewandowski | Samsung Poland RD Center | Linux/Platform -- 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 v2 2/2] regulator: add device tree support for max8997
On Thu, Jan 26, 2012 at 04:28:00PM +0100, Karol Lewandowski wrote: On 25.01.2012 14:32, Mark Brown wrote: Well, they're different things. Device tree isn't Linux specific at all. There is no official platform-agnostic regulator API, nor DT-bindings document I'm aware of. Thus, I don't see why, while transitioning to The binding for the regulator API is supposed to be the one true platform agnostic binding, none of the device tree stuff is supposed to be Linux specific. DT, should we lose ability to describe certain hardware configurations. We don't loose anything, a single voltage constraint that didn't set apply_uV was always meaningless. I keep meaning to make the core complain about things like that and people specifying voltage ranges without SET_VOLTAGE. On 25.01.2012 12:22, Mark Brown wrote: The big problem there seems like specifying voltages in the first place, if we know what device it is we should already know what's going on. Driver which handles said regulator might know what's going on, but that might not be case for its consumers. Should we limit ability to query given parameter just because its value is hardcoded in hardware? I'm sorry, this makes no sense. Setting a value in the constraints is not going to have any impact on the value reported by the driver, it never has. Consequently, if it's property of hardware that it provides fixed voltage somewhere shouldn't it be possible to describe this fact in DT? If the device has a fixed voltage output the driver should just know this without having to read the information from device tree, device tree is for configuration. If the device has some hardware fixed configurability it should define this in a sensible fashion in the bindings (which may for example be a case of specifying the values of the passive components for ease of use). signature.asc Description: Digital signature
[PATCH 0/2] S5P-TV support for Exynos Nuri and Universal boards
Hello, This patch series contains platform definitions for s5p-tv driver. It includes fixes to HDMI support on Exynos Universal. It adds S5P-TV support on Nuri board. Please refer to patchset 'Updates to S5P-TV drivers' on linux-media where definitions of platform data for SII0234 were introduced. Regards Tomasz Stanislawski Tomasz Stanislawski (2): ARM: Exynos4: enable TV support on Nuri board ARM: Exynos4: fix TV support on Universal_C210 board arch/arm/mach-exynos/Kconfig |2 + arch/arm/mach-exynos/mach-nuri.c | 99 arch/arm/mach-exynos/mach-universal_c210.c | 14 3 files changed, 115 insertions(+), 0 deletions(-) -- 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/2] ARM: Exynos4: fix TV support on Universal_C210 board
This patch adds support for HDMI platform data.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-universal_c210.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 37ac93e..bec57c0 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -45,6 +45,8 @@
#include media/v4l2-mediabus.h
#include media/s5p_fimc.h
+#include media/s5p_hdmi.h
+
#include media/m5mols.h
#include common.h
@@ -997,6 +999,15 @@ static void __init universal_map_io(void)
s3c24xx_init_uarts(universal_uartcfgs, ARRAY_SIZE(universal_uartcfgs));
}
+static struct i2c_board_info s5p_hdmiphy_info = {
+ I2C_BOARD_INFO(hdmiphy, 0x70 1),
+};
+
+static struct s5p_hdmi_platform_data s5p_hdmi_pdata = {
+ .hdmiphy_info = s5p_hdmiphy_info,
+ .hdmiphy_bus = 8,
+};
+
void s5p_tv_setup(void)
{
/* direct HPD to HDMI chip */
@@ -1004,6 +1015,9 @@ void s5p_tv_setup(void)
s3c_gpio_cfgpin(EXYNOS4_GPX3(7), S3C_GPIO_SFN(0x3));
s3c_gpio_setpull(EXYNOS4_GPX3(7), S3C_GPIO_PULL_NONE);
+ /* setting platform data */
+ s5p_device_hdmi.dev.platform_data = s5p_hdmi_pdata;
+
/* setup dependencies between TV devices */
s5p_device_hdmi.dev.parent = exynos4_device_pd[PD_TV].dev;
s5p_device_mixer.dev.parent = exynos4_device_pd[PD_TV].dev;
--
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 1/2] ARM: Exynos4: enable TV support on Nuri board
This patch adds platform devices and regulators for TV devices on
Samsung Nuri board.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/Kconfig |2 +
arch/arm/mach-exynos/mach-nuri.c | 99 ++
2 files changed, 101 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 5d602f6..4cb5225 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -268,12 +268,14 @@ config MACH_NURI
select S3C_DEV_I2C1
select S3C_DEV_I2C3
select S3C_DEV_I2C5
+ select S5P_DEV_I2C_HDMIPHY
select S5P_DEV_CSIS0
select S5P_DEV_FIMC0
select S5P_DEV_FIMC1
select S5P_DEV_FIMC2
select S5P_DEV_FIMC3
select S5P_DEV_MFC
+ select S5P_DEV_TV
select S5P_DEV_USB_EHCI
select S5P_SETUP_MIPIPHY
select EXYNOS4_DEV_DMA
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index b895ec0..7d04844 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include linux/delay.h
#include linux/platform_device.h
#include linux/serial_core.h
#include linux/input.h
@@ -29,6 +30,8 @@
#include video/platform_lcd.h
#include media/m5mols.h
#include media/s5p_fimc.h
+#include media/s5p_hdmi.h
+#include media/sii9234.h
#include media/v4l2-mediabus.h
#include asm/mach/arch.h
@@ -75,6 +78,7 @@ enum fixed_regulator_id {
FIXED_REG_ID_MAX8903,
FIXED_REG_ID_CAM_A28V,
FIXED_REG_ID_CAM_12V,
+ FIXED_REG_ID_HDMI_EN,
};
static struct s3c2410_uartcfg nuri_uartcfgs[] __initdata = {
@@ -389,9 +393,12 @@ static void __init nuri_tsp_init(void)
static struct regulator_consumer_supply __initdata max8997_ldo1_[] = {
REGULATOR_SUPPLY(vdd, s5p-adc), /* Used by CPU's ADC drv */
+ REGULATOR_SUPPLY(vdd_osc, exynos4-hdmi), /* HDMI */
};
static struct regulator_consumer_supply __initdata max8997_ldo3_[] = {
REGULATOR_SUPPLY(vdd11, s5p-mipi-csis.0), /* MIPI */
+ REGULATOR_SUPPLY(vdd, exynos4-hdmi), /* HDMI */
+ REGULATOR_SUPPLY(vdd_pll, exynos4-hdmi), /* HDMI */
};
static struct regulator_consumer_supply __initdata max8997_ldo4_[] = {
REGULATOR_SUPPLY(vdd18, s5p-mipi-csis.0), /* MIPI */
@@ -563,6 +570,51 @@ static struct regulator_init_data __initdata
max8997_ldo7_data = {
.consumer_supplies = max8997_ldo7_,
};
+static struct regulator_consumer_supply hdmi_fixed_consumer[] = {
+ REGULATOR_SUPPLY(hdmi-en, exynos4-hdmi),
+ REGULATOR_SUPPLY(hdmi-en, 15-0039), /* sii9234 */
+};
+
+static struct regulator_init_data hdmi_fixed_voltage_init_data = {
+ .constraints= {
+ .name = HDMI_5V,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(hdmi_fixed_consumer),
+ .consumer_supplies = hdmi_fixed_consumer,
+};
+
+static struct fixed_voltage_config hdmi_fixed_voltage_config = {
+ .supply_name= HDMI_EN1,
+ .microvolts = 500,
+ .gpio = EXYNOS4_GPX2(4),
+ .enable_high= true,
+ .init_data = hdmi_fixed_voltage_init_data,
+};
+
+static struct platform_device hdmi_fixed_voltage = {
+ .name = reg-fixed-voltage,
+ .id = FIXED_REG_ID_HDMI_EN,
+ .dev= {
+ .platform_data = hdmi_fixed_voltage_config,
+ },
+};
+
+/* I2C-GPIO15: MHL */
+static struct i2c_gpio_platform_data i2c15_gpio_data = {
+ .sda_pin= EXYNOS4_GPY3(0), /* XM0ADDR_0 */
+ .scl_pin= EXYNOS4_GPY3(2), /* XM0ADDR_2 */
+ .udelay = 2,
+};
+
+static struct platform_device i2c15_gpio = {
+ .name = i2c-gpio,
+ .id = 15,
+ .dev= {
+ .platform_data = i2c15_gpio_data,
+ },
+};
+
static struct regulator_init_data __initdata max8997_ldo8_data = {
.constraints= {
.name = VUSB/VDAC_3.3V_C210,
@@ -1267,6 +1319,11 @@ static struct platform_device *nuri_devices[] __initdata
= {
exynos4_device_pd[PD_LCD0],
exynos4_device_pd[PD_CAM],
s5p_device_fimc_md,
+ exynos4_device_pd[PD_TV],
+ hdmi_fixed_voltage,
+ s5p_device_i2c_hdmiphy,
+ s5p_device_hdmi,
+ s5p_device_mixer,
/* NURI Devices */
nuri_gpio_keys,
@@ -1276,6 +1333,7 @@ static struct platform_device *nuri_devices[] __initdata
= {
nuri_max8903_device,
cam_vdda_fixed_rdev,
cam_8m_12v_fixed_rdev,
+ i2c15_gpio,
};
static void __init
Re: [PATCH 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
On Wed, Jan 25, 2012 at 11:06:47AM +, Russell King - ARM Linux wrote:
Right, so with the stack of amba patches on top, it looks like this,
which to me looks sane. I haven't build-tested it though.
Will,
Did you see this? Any comment?
Thanks.
diff --git a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
index 5c3c625..708f841 100644
--- a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
+++ b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
@@ -40,6 +40,7 @@
#define IRQ_DC1176_L2CC (IRQ_DC1176_GIC_START + 13)
#define IRQ_DC1176_RTC (IRQ_DC1176_GIC_START + 14)
#define IRQ_DC1176_CLCD (IRQ_DC1176_GIC_START + 15) /* CLCD
controller */
+#define IRQ_DC1176_GPIO0 (IRQ_DC1176_GIC_START + 16)
#define IRQ_DC1176_SSP (IRQ_DC1176_GIC_START + 17) /* SSP
port */
#define IRQ_DC1176_UART0 (IRQ_DC1176_GIC_START + 18) /* UART 0 on
development chip */
#define IRQ_DC1176_UART1 (IRQ_DC1176_GIC_START + 19) /* UART 1 on
development chip */
@@ -73,7 +74,6 @@
#define IRQ_PB1176_DMAC (IRQ_PB1176_GIC_START + 24) /* DMA
controller */
#define IRQ_PB1176_RTC (IRQ_PB1176_GIC_START + 25) /* Real
Time Clock */
-#define IRQ_PB1176_GPIO0 -1
#define IRQ_PB1176_SCTL -1
#define NR_GIC_PB11762
diff --git a/arch/arm/mach-realview/realview_pb1176.c
b/arch/arm/mach-realview/realview_pb1176.c
index 1b6e60c..b1d7caf 100644
--- a/arch/arm/mach-realview/realview_pb1176.c
+++ b/arch/arm/mach-realview/realview_pb1176.c
@@ -143,7 +143,7 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define PB1176_CLCD_IRQ { IRQ_DC1176_CLCD }
#define SCTL_IRQ { }
#define PB1176_WATCHDOG_IRQ { IRQ_DC1176_WATCHDOG }
-#define PB1176_GPIO0_IRQ { IRQ_PB1176_GPIO0 }
+#define PB1176_GPIO0_IRQ { IRQ_DC1176_GPIO0 }
#define GPIO1_IRQ{ IRQ_PB1176_GPIO1 }
#define PB1176_RTC_IRQ { IRQ_DC1176_RTC }
#define SCI_IRQ { IRQ_PB1176_SCI }
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
On Thu, Jan 26, 2012 at 05:25:27PM +, Russell King - ARM Linux wrote:
On Wed, Jan 25, 2012 at 11:06:47AM +, Russell King - ARM Linux wrote:
Right, so with the stack of amba patches on top, it looks like this,
which to me looks sane. I haven't build-tested it though.
Will,
Hi Russell,
Did you see this? Any comment?
Sorry, this somehow got buried in other mail.
diff --git a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
index 5c3c625..708f841 100644
--- a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
+++ b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
@@ -40,6 +40,7 @@
#define IRQ_DC1176_L2CC(IRQ_DC1176_GIC_START + 13)
#define IRQ_DC1176_RTC (IRQ_DC1176_GIC_START + 14)
#define IRQ_DC1176_CLCD(IRQ_DC1176_GIC_START + 15) /* CLCD
controller */
+#define IRQ_DC1176_GPIO0 (IRQ_DC1176_GIC_START + 16)
#define IRQ_DC1176_SSP (IRQ_DC1176_GIC_START + 17) /* SSP
port */
#define IRQ_DC1176_UART0 (IRQ_DC1176_GIC_START + 18) /* UART 0 on
development chip */
#define IRQ_DC1176_UART1 (IRQ_DC1176_GIC_START + 19) /* UART 1 on
development chip */
@@ -73,7 +74,6 @@
#define IRQ_PB1176_DMAC(IRQ_PB1176_GIC_START + 24) /* DMA
controller */
#define IRQ_PB1176_RTC (IRQ_PB1176_GIC_START + 25) /* Real
Time Clock */
-#define IRQ_PB1176_GPIO0 -1
#define IRQ_PB1176_SCTL-1
#define NR_GIC_PB1176 2
diff --git a/arch/arm/mach-realview/realview_pb1176.c
b/arch/arm/mach-realview/realview_pb1176.c
index 1b6e60c..b1d7caf 100644
--- a/arch/arm/mach-realview/realview_pb1176.c
+++ b/arch/arm/mach-realview/realview_pb1176.c
@@ -143,7 +143,7 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define PB1176_CLCD_IRQ{ IRQ_DC1176_CLCD }
#define SCTL_IRQ { }
#define PB1176_WATCHDOG_IRQ{ IRQ_DC1176_WATCHDOG }
-#define PB1176_GPIO0_IRQ { IRQ_PB1176_GPIO0 }
+#define PB1176_GPIO0_IRQ { IRQ_DC1176_GPIO0 }
#define GPIO1_IRQ { IRQ_PB1176_GPIO1 }
#define PB1176_RTC_IRQ { IRQ_DC1176_RTC }
#define SCI_IRQ{ IRQ_PB1176_SCI }
This looks fine to me. It matches what I posted originally, which was the
intention.
Acked-by: Will Deacon will.dea...@arm.com
Will
--
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 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
On Thu, Jan 26, 2012 at 05:37:21PM +, Will Deacon wrote: Acked-by: Will Deacon will.dea...@arm.com Thanks, I'll add that to patch 21 with the fix. -- 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: ARM/ARM-SoC plans for v3.4 merge window
On Tue, Jan 24, 2012 at 09:50:09AM +, Russell King - ARM Linux wrote: On Mon, Jan 23, 2012 at 11:49:02AM +, Russell King - ARM Linux wrote: This is an outline of the plan for this cycle, up to the next merge window, agreed between Olof and myself. As Nicolas' idle changes weren't merged before the last merge window opened, we have decided that Nicolas will resubmit his changes after -rc1 (in other words, now) and they will be merged into both the arm-soc and my trees. I have at least one other patch which has a high 'will cause horrible conficts' rating (the debug option rearrangement patch), so I'll be including that for the arm-soc tree as well. However, what this does mean is that Arnd, Olof, and myself will be in for up to three months of merge hell unless people take account of these changes. Therefore, our plan is to publish this as a baseline, and we'd really appreciate any development submitted after that baseline has been established is based upon those changes and does not conflict with them. That may mean you have to pull these changes into your tree and merge them into your development work (and fix up any conflicts there yourself.) Once you've taken these changes into your tree, you must not rebase or modify them. Changing those commits will cause all hell to break loose, and we'll have to refuse merging your tree (otherwise we'll be in Linus' sights for a roasting at gas mark 2 million.) Right, although it's out there - but I'd like to get the AMBA changes into it which are already conflicting the Samsung development. So I'm going to hold off officially asking for people to include the baseline until this evening. At that point, I will shut down my 'amba' branch and transfer that over; that means I won't be accepting any further acks etc for that work. If you haven't acked changes in the amba branch (eg, to Versatile, Realview etc) then it'll soon be too late... And we're now there. So... Arnd, Olaf, Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at: git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05. This will update the following files: arch/arm/Kconfig.debug| 156 ++-- arch/arm/include/asm/system.h |1 + arch/arm/kernel/process.c | 27 ++-- arch/arm/mach-at91/at91cap9.c |8 + arch/arm/mach-at91/at91rm9200.c | 10 ++ arch/arm/mach-at91/at91sam9260.c |8 + arch/arm/mach-at91/at91sam9261.c |8 + arch/arm/mach-at91/at91sam9263.c |8 + arch/arm/mach-at91/at91sam9g45.c |7 + arch/arm/mach-at91/at91sam9rl.c |8 + arch/arm/mach-at91/at91x40.c | 12 ++ arch/arm/mach-at91/include/mach/system.h | 50 --- arch/arm/mach-bcmring/core.c | 23 +--- arch/arm/mach-bcmring/include/mach/system.h | 28 arch/arm/mach-clps711x/common.c | 16 ++ arch/arm/mach-clps711x/include/mach/system.h | 35 - arch/arm/mach-cns3xxx/include/mach/system.h | 25 arch/arm/mach-davinci/include/mach/system.h | 21 --- arch/arm/mach-dove/include/mach/system.h | 17 --- arch/arm/mach-ebsa110/core.c | 25 arch/arm/mach-ebsa110/include/mach/system.h | 37 - arch/arm/mach-ep93xx/core.c | 46 +-- arch/arm/mach-ep93xx/include/mach/system.h|7 - arch/arm/mach-exynos/common.c | 12 -- arch/arm/mach-exynos/dma.c| 38 +- arch/arm/mach-exynos/include/mach/system.h| 20 --- arch/arm/mach-footbridge/include/mach/system.h| 13 -- arch/arm/mach-gemini/Makefile |2 +- arch/arm/mach-gemini/idle.c | 29 arch/arm/mach-gemini/include/mach/system.h| 14 -- arch/arm/mach-gemini/irq.c|4 +- arch/arm/mach-h720x/common.c | 18 +++ arch/arm/mach-h720x/include/mach/system.h | 27 arch/arm/mach-highbank/include/mach/system.h | 24 --- arch/arm/mach-imx/mm-imx3.c | 52 arch/arm/mach-imx/pm-imx27.c |3 +- arch/arm/mach-integrator/core.c | 70 ++ arch/arm/mach-integrator/impd1.c |9 +- arch/arm/mach-integrator/include/mach/system.h| 33 - arch/arm/mach-integrator/integrator_cp.c | 49 ++-- arch/arm/mach-iop13xx/include/mach/system.h | 13 -- arch/arm/mach-iop32x/include/mach/system.h| 13 -- arch/arm/mach-iop33x/include/mach/system.h| 13
RE: [PATCH 0/4] Pending S3C64xx updates
Mark Brown wrote: Hi Mark, This patch series is a collection of s3c64xx updates I've had hanging round in my tree for varying lengths of time that it'd be good to get merged. There's no particularly relationship between them except that they're all for s3c64xx. OK, see my comments below. Mark Brown (4): ARM: S3C64XX: Make s3c64xx_init_uarts() static As I commented, I have pushed this into rmk's patch system but not applied yet. I discarded that just now in there so that I can apply this in my tree. ARM: S3C64XX: Define some additional always off clocks Hmm, I know there were discussions about this with Tomasz Figa and I was waiting for his submitting. But now this looks ok to me so will apply this. ARM: S3C6410: Use device names for both I2C clocks OK, will apply and let me sort out the #ifdef in Samsung stuff for single zImage later. ARM: S3C64XX: Add hookup for Tomatin module on Cragganmore Already in my next/board-samsung. arch/arm/mach-s3c64xx/clock.c| 106 ++ arch/arm/mach-s3c64xx/common.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410-module.c | 27 ++- arch/arm/mach-s3c64xx/mach-crag6410.c| 11 +++- 4 files changed, 143 insertions(+), 3 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] ARM: S3C64XX: Use IN4 DC measurement mode on Tobermory
Mark Brown wrote:
The WM8962 on Tobermory has one of the IN4 inputs connected for DC
measurement. Tell the driver it can optimise for this mode.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
This feature is going to be merged via ASoC in 3.4 - is it OK if I apply
this patch to the ASoC tree too? It's a one liner, I'd be astonished if
it were to generate any conflicts.
Yes, would be better. If required, please go ahead with my ack:
Acked-by: Kukjin Kim kgene@samsung.com
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
arch/arm/mach-s3c64xx/mach-crag6410-module.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410-module.c b/arch/arm/mach-
s3c64xx/mach-crag6410-module.c
index 509307d..317f866 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
@@ -128,6 +128,7 @@ static struct wm8962_pdata wm8962_pdata __initdata = {
0x8000 | WM8962_GPIO_FN_DMICDAT,
WM8962_GPIO_FN_IRQ,/* Open drain mode */
},
+ .in4_dc_measure = true,
};
static struct wm9081_pdata wm9081_pdata __initdata = {
--
1.7.9.rc1
--
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 5/6] ARM: SAMSUNG: Correct M-5MOLS sensor clock frequency on Nuri board
Sylwester Nawrocki wrote:
Hi Sylwester,
oops, it's for Universal C210 so the subject should be:
ARM: SAMSUNG: Correct M-5MOLS sensor clock frequency on Universal C210
board
OK, let me fix the subject when I apply.
Should I resend or would you fix it when applying.
No :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
Regards,
Sylwester
On 01/25/2012 03:23 PM, Sylwester Nawrocki wrote:
In order to keep the sensor's master clock frequency in valid range
when FIMC parent clock is xusbxti, the specified frequency must be
exactly 24MHZ, otherwise it's being set to too low value due to
rounding.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-universal_c210.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c b/arch/arm/mach-
exynos/mach-universal_c210.c
index 44fc43e..0e3aeb9 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -973,7 +973,7 @@ static struct s5p_fimc_isp_info
universal_camera_sensors[] = {
.bus_type = FIMC_MIPI_CSI2,
.board_info =m5mols_board_info,
.i2c_bus_num= 0,
- .clk_frequency = 2160UL,
+ .clk_frequency = 2400UL,
.csi_data_align = 32,
},
};
--
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 0/6] ARM: SAMSUNG: Board updates and minor fixes
Sylwester Nawrocki wrote: The following patch series adds S5K6AAFX sensor support on Nuri and UNIVERSAL_C210 boards. It also includes minor correction for the I2C controller setup and the M-5MOLS sensor. Sylwester Nawrocki (6): ARM: SAMSUNG: Increase virtual framebuffer size on Universal C210 board ARM: SAMSUNG: Add support for S5K6AAFX image sensor on Universal C210 board ARM: SAMSUNG: Add support for S5K6AAFX camera on Nuri board ARM: SAMSUNG: Correct framebuffer window size on Nuri board ARM: SAMSUNG: Correct M-5MOLS sensor clock frequency on Nuri board ARM: SAMSUNG: Fix platform data setup for I2C adapter 0 arch/arm/mach-exynos/Kconfig |2 + arch/arm/mach-exynos/mach-nuri.c | 73 -- arch/arm/mach-exynos/mach-universal_c210.c | 78 ++-- arch/arm/plat-samsung/devs.c |4 +- 4 files changed, 147 insertions(+), 10 deletions(-) -- 1.7.8.3 OK, looks good to me, will apply in my v3.3-samsung-fixes-2 for 6/6 and next/board-samsung for others. And I'm not sure some board updates are for fix now so if required, please let me know. Plus, I looked at some wrong alignment(tab and white space?) in your patches, so if you don't mind, let me fix it when I apply. 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
[PATCH 02/13] ARM: SAMSUNG: allow the configuration of KERNEL HZ in plat-samsung
Cc: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/Kconfig |4 ++-- arch/arm/plat-samsung/Kconfig |7 +++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 24626b0..f9d7c47 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1590,8 +1590,8 @@ source kernel/Kconfig.preempt config HZ int - default 200 if ARCH_EBSA110 || ARCH_S3C2410 || ARCH_S5P64X0 || \ - ARCH_S5PV210 || ARCH_EXYNOS4 + default 200 if ARCH_EBSA110 + default SAMSUNG_TIMER_HZ if PLAT_SAMSUNG default OMAP_32K_TIMER_HZ if ARCH_OMAP OMAP_32K_TIMER default AT91_TIMER_HZ if ARCH_AT91 default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 6a2abe6..0a23b52 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -50,6 +50,13 @@ config S3C_LOWLEVEL_UART_PORT this configuration should be between zero and two. The port must have been initialised by the boot-loader before use. +config SAMSUNG_TIMER_HZ + int Kernel HZ for Samsung Platform + range 32 1024 + default 200 + help + Allows the configuration of the timer frequency for Samsung SoCs. + # clock options config SAMSUNG_CLKSRC -- 1.7.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
[PATCH] serial: samsung: Add support serial for EXYNOS4212 and EXYNOS4412
This should be added for EXYNOS4212 and EXYNOS4412 SoCs.
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: sta...@kerne.org
Signed-off-by: Kukjin Kim kgene@samsung.com
---
drivers/tty/serial/samsung.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index f96f37b..ce632da 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1593,7 +1593,8 @@ static struct s3c24xx_serial_drv_data
s5pv210_serial_drv_data = {
#define S5PV210_SERIAL_DRV_DATA(kernel_ulong_t)NULL
#endif
-#ifdef CONFIG_CPU_EXYNOS4210
+#if defined(CONFIG_CPU_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212) || \
+ defined(CONFIG_CPU_EXYNOS4412)
static struct s3c24xx_serial_drv_data exynos4210_serial_drv_data = {
.info = (struct s3c24xx_uart_info) {
.name = Samsung Exynos4 UART,
--
1.7.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 v8 2/2] iommu/exynos: Add iommu driver for Exynos Platforms
KyongHo Cho wrote:
Hi,
On Mon, Jan 23, 2012 at 11:27 PM, Joerg Roedel j...@8bytes.org wrote:
Hi,
please also get and inclue Acks from the Exynos maintainer for the next
post.
Since I have a compiling config for exynos now I will merge the patches
when you have the Acks and addressed or explained the issues I pointed
out below.
Thanks for review!
I will include the Acks in the next patchset.
If his updated patch is ok to me, let me reply then.
As a note, I'm preparing for new EXYNOS SoC and so some exynos stuff such as
clock can be modified. So would be better if KyongHo could update regarding
arch/arm/ part based on that. Maybe in the beginning of Feb.?
Joerg, as I said, I need a topic branch for this to avoid conflict and I
think, now you can provide it for samsung tree.
If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
I will post the next patchset with corrections by the day after tomorrow.
And sorry for late reply.
I had holidays for the new year's day based on Lunar system.
On Thu, Dec 29, 2011 at 09:26:08PM +0900, KyongHo Cho wrote:
+static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
+{
+ struct exynos_iommu_domain *priv = domain-priv;
+ struct list_head *pos, *n;
+ unsigned long flags;
+ int i;
+
+ WARN_ON(!list_empty(priv-clients));
This isn't really a problem. We allow destroying a domain with devices
attached. So this WARN_ON is not necessary.
OK.
BTW, Isn't it a problem when a device driver does not know that its
iommu domain is destroyed?
Can we regards that it is the faulty use of iommu API?
+static int exynos_iommu_map(struct iommu_domain *domain, unsigned long
iova,
+ phys_addr_t paddr, size_t size, int prot)
+{
+ struct exynos_iommu_domain *priv = domain-priv;
+ unsigned long *entry;
+ unsigned long flags;
+ int ret = -ENOMEM;
+
+ BUG_ON(priv-pgtable == NULL);
+
+ spin_lock_irqsave(priv-pgtablelock, flags);
+
+ entry = section_entry(priv-pgtable, iova);
+
+ if (size = SECT_SIZE) {
+ ret = lv1set_section(entry, paddr, size SECT_ORDER,
+ priv-
lv2entcnt[lv1ent_offset(iova)]);
This looks like you are partially re-implementing behavior of generic
code because you are mapping multiple sections at once. The generic map
code already splits up the address range correctly, so no need to do
this in the driver (unless there is some benefit in the hardware, like
an IOTLB entry that can cover multiple sections or something similar).
Yes, I wanted to avoid repeated function call by iommu_map().
s5p_iommu_map() maps once for the same page size since it is efficient
and simple.
That's why this driver initializes domain-pgsize_bitmap with 0xF000
even though our IOMMU driver just supports 3 different page sizes
including 4KB, 64KB and 1MB.
Do you think it is better for s5p_iommu_map() to map just one page at
once?
+static size_t exynos_iommu_unmap(struct iommu_domain *domain,
+ unsigned long iova, size_t
size)
+{
+ struct exynos_iommu_domain *priv = domain-priv;
+ struct iommu_client *client;
+ unsigned long flags;
+
+ BUG_ON(priv-pgtable == NULL);
+
+ spin_lock_irqsave(priv-pgtablelock, flags);
+
+ while (size != 0) {
+ int i, nent, order;
+ unsigned long *pent, *sent;
Same with this while-loop. This looks like it re-implements behavior
from the generic code.
If a region to unmap consists of tens of pages
there is no way to avoid flushing IOTLB repeatedly.
Out iommu driver doesn't need to flush IOTLB more than once for a
region to unmap.
Do you think the driver is better to unmaps just one page at once
though flushing IOTLB repeatedly?
Thank you.
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 02/13] ARM: SAMSUNG: allow the configuration of KERNEL HZ in plat-samsung
Kukjin Kim wrote: Please kindly ignore the patch number[02/13] in subject. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Cc: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/Kconfig |4 ++-- arch/arm/plat-samsung/Kconfig |7 +++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 24626b0..f9d7c47 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1590,8 +1590,8 @@ source kernel/Kconfig.preempt config HZ int - default 200 if ARCH_EBSA110 || ARCH_S3C2410 || ARCH_S5P64X0 || \ - ARCH_S5PV210 || ARCH_EXYNOS4 + default 200 if ARCH_EBSA110 + default SAMSUNG_TIMER_HZ if PLAT_SAMSUNG default OMAP_32K_TIMER_HZ if ARCH_OMAP OMAP_32K_TIMER default AT91_TIMER_HZ if ARCH_AT91 default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 6a2abe6..0a23b52 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -50,6 +50,13 @@ config S3C_LOWLEVEL_UART_PORT this configuration should be between zero and two. The port must have been initialised by the boot-loader before use. +config SAMSUNG_TIMER_HZ + int Kernel HZ for Samsung Platform + range 32 1024 + default 200 + help + Allows the configuration of the timer frequency for Samsung SoCs. + # clock options config SAMSUNG_CLKSRC -- 1.7.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 V1] ARM: EXYNOS: Adds Samsung TRATS board support
HeungJun, Kim wrote: Hi Kukjin Kim, -Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- kernel- boun...@lists.infradead.org] On Behalf Of Kukjin Kim Sent: Thursday, December 29, 2011 12:30 PM To: 'HeungJun, Kim' Cc: kyungmin.p...@samsung.com; linux-samsung-soc@vger.kernel.org; linux- arm- ker...@lists.infradead.org Subject: RE: [PATCH V1] ARM: EXYNOS: Adds Samsung TRATS board support HeungJun, Kim wrote: This patch adds Samsung Mobile TRATS board support. The changes against V0: 1) Modify Makefile boardfile name: from board-trats.c to mach- trats.c 2) Fix name of mmc's fixed regulator: remove inverted 3) Fix directory name on GPL comments: from exynos4 to exynos Signed-off-by: HeungJun, Kim riverful@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/Kconfig | 11 ++ arch/arm/mach-exynos/Makefile |1 + arch/arm/mach-exynos/mach-trats.c | 340 + 3 files changed, 352 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-exynos/mach-trats.c Hi HeungJun, Thanks for your re-submit. Hmm, maybe this is v2 not v1? Anyway, as I said, this conflicts with other ARM consolidation works. So please wait until after the merge window for this patch. Happy New Year. This probably my mistake. v2 is right. And it's no problem to be merge next windows. I'll wait. Happy new year, too! Hi, could you please re-work this based on v3.3-rc1? 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
[PATCH] ARM: SAMSUNG: use spin_lock_irqsave() in clk_{enable,disable}
From: Minho Ban mh...@samsung.com
The clk_enable()and clk_disable() can be called in process and ISR
either. Actually that is used for real product and other platforms
now. So it's time to use spin_lock_irqsave() instead.
Signed-off-by: Minho Ban mh...@samsung.com
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Sunyoung Kang sy0816.k...@samsung.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Note: There were discussion about this before.
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-October/028788.html
As we discussed, actually that is used for real product and other platforms
now. Plus, we don't need to change the PLL during kernel so the latency
doesn't matter. I think it's time to use spin_lock_irqsave() instead.
arch/arm/plat-samsung/clock.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-samsung/clock.c
index 10f7117..65c5eca 100644
--- a/arch/arm/plat-samsung/clock.c
+++ b/arch/arm/plat-samsung/clock.c
@@ -84,31 +84,35 @@ static int clk_null_enable(struct clk *clk, int enable)
int clk_enable(struct clk *clk)
{
+ unsigned long flags;
+
if (IS_ERR(clk) || clk == NULL)
return -EINVAL;
clk_enable(clk-parent);
- spin_lock(clocks_lock);
+ spin_lock_irqsave(clocks_lock, flags);
if ((clk-usage++) == 0)
(clk-enable)(clk, 1);
- spin_unlock(clocks_lock);
+ spin_unlock_irqrestore(clocks_lock, flags);
return 0;
}
void clk_disable(struct clk *clk)
{
+ unsigned long flags;
+
if (IS_ERR(clk) || clk == NULL)
return;
- spin_lock(clocks_lock);
+ spin_lock_irqsave(clocks_lock, flags);
if ((--clk-usage) == 0)
(clk-enable)(clk, 0);
- spin_unlock(clocks_lock);
+ spin_unlock_irqrestore(clocks_lock, flags);
clk_disable(clk-parent);
}
--
1.7.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
[PATCH] ARM: S5PV210: Fix the name of exynos4_clk_hdmiphy_ctrl() for S5PV210
Should be s5pv210_clk_hdmiphy_ctrl() in mach-s5pv210/.
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-s5pv210/clock.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index c78dfdd..b9ec0c3 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -175,7 +175,7 @@ static int s5pv210_clk_mask1_ctrl(struct clk *clk, int
enable)
return s5p_gatectrl(S5P_CLK_SRC_MASK1, clk, enable);
}
-static int exynos4_clk_hdmiphy_ctrl(struct clk *clk, int enable)
+static int s5pv210_clk_hdmiphy_ctrl(struct clk *clk, int enable)
{
return s5p_gatectrl(S5P_HDMI_PHY_CONTROL, clk, enable);
}
@@ -372,7 +372,7 @@ static struct clk init_clocks_off[] = {
}, {
.name = hdmiphy,
.devname= s5pv210-hdmi,
- .enable = exynos4_clk_hdmiphy_ctrl,
+ .enable = s5pv210_clk_hdmiphy_ctrl,
.ctrlbit= (1 0),
}, {
.name = dacphy,
--
1.7.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
