[PATCH v2 0/5] thermal: exynos: Fixes for v3.12
This patch series is divided into two parts: 1. Device tree node definition and enabelement for TMU at Exynos4412 (Trats2) 2. Exynos thermal subsystem regressions for v3.12-rc4. Several commits were necessary to properly fix regression for TMU test MUX address setting after reset. Test HW: - Exynos4412 - TRATS2 board (Linux v3.12-rc4) SHA1: 8b5ede69d24db939f52b47e2f6fe1e83e08b Lukasz Majewski (5): thermal: exynos: Remove check for thermal device pointer at exynos_report_trigger() thermal: exynos: Provide separate TMU data for Exynos4412 thermal: exynos: Provide initial setting for TMU's test MUX address at Exynos4412 ARM: dts: exynos4x12: Device tree node definition for TMU on Exynos4x12 ARM: dts: exynos4412-trats2: Enable TMU support at Trats2 arch/arm/boot/dts/exynos4412-trats2.dts |5 arch/arm/boot/dts/exynos4x12.dtsi | 10 drivers/thermal/samsung/exynos_thermal_common.c |2 -- drivers/thermal/samsung/exynos_tmu.c| 12 ++--- drivers/thermal/samsung/exynos_tmu.h|7 +- drivers/thermal/samsung/exynos_tmu_data.c | 30 ++- drivers/thermal/samsung/exynos_tmu_data.h | 13 +- 7 files changed, 65 insertions(+), 14 deletions(-) -- 1.7.10.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 v2 5/5] ARM: dts: exynos4412-trats2: Enable TMU support at Trats2
This patch enables support for TMU at Exynos4412 based Trats2 board.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
Changes for v2:
- None
arch/arm/boot/dts/exynos4412-trats2.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index fb7b9ae..57136f8 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -467,6 +467,11 @@
status = okay;
};
+ tmu@100C {
+ vtmu-supply = ldo10_reg;
+ status = okay;
+ };
+
i2c_ak8975: i2c-gpio-0 {
compatible = i2c-gpio;
gpios = gpy2 4 0, gpy2 5 0;
--
1.7.10.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 v2 4/5] ARM: dts: exynos4x12: Device tree node definition for TMU on Exynos4x12
The TMU device tree node definition for Exynos4x12 family of SoCs.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
Changes for v2:
- None
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index ad531fe..64c0ece 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -176,4 +176,14 @@
};
};
};
+
+ tmu@100C {
+ compatible = samsung,exynos4412-tmu;
+ interrupt-parent = combiner;
+ interrupts = 2 4;
+ reg = 0x100C 0x100;
+ clocks = clock 383;
+ clock-names = tmu_apbif;
+ status = disabled;
+ };
};
--
1.7.10.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 v2 3/5] thermal: exynos: Provide initial setting for TMU's test MUX address at Exynos4412
The commit d0a0ce3e77c795258d47f9163e92d5031d0c5221 (thermal: exynos: Add
missing definations and code cleanup) has removed setting of test MUX address
value at TMU configuration setting.
This field is not present on Exynos4210 and Exynos5 SoCs. However on Exynos4412
SoC it is required to set this field after reset because without it TMU shows
maximal available temperature, which causes immediate platform shutdown.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
Changes for v2:
- Define test_mux and test_mux_addr_shift to not use direct register access
- Remove pdata-type == SOC_ARCH_EXYNOS4412 check at exynos_tmu_control() and
use only generic code
drivers/thermal/samsung/exynos_tmu.c |3 +++
drivers/thermal/samsung/exynos_tmu.h |4
drivers/thermal/samsung/exynos_tmu_data.c |2 ++
drivers/thermal/samsung/exynos_tmu_data.h |4
4 files changed, 13 insertions(+)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 1312b34..32f38b9 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -317,6 +317,9 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
con = readl(data-base + reg-tmu_ctrl);
+ if (pdata-test_mux)
+ con |= (pdata-test_mux reg-test_mux_addr_shift);
+
if (pdata-reference_voltage) {
con = ~(reg-buf_vref_sel_mask reg-buf_vref_sel_shift);
con |= pdata-reference_voltage reg-buf_vref_sel_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index b42ece4..3fb6554 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -85,6 +85,7 @@ enum soc_type {
* @triminfo_reload_shift: shift of triminfo reload enable bit in triminfo_ctrl
reg.
* @tmu_ctrl: TMU main controller register.
+ * @test_mux_addr_shift: shift bits of test mux address.
* @buf_vref_sel_shift: shift bits of reference voltage in tmu_ctrl register.
* @buf_vref_sel_mask: mask bits of reference voltage in tmu_ctrl register.
* @therm_trip_mode_shift: shift bits of tripping mode in tmu_ctrl register.
@@ -151,6 +152,7 @@ struct exynos_tmu_registers {
u32 triminfo_reload_shift;
u32 tmu_ctrl;
+ u32 test_mux_addr_shift;
u32 buf_vref_sel_shift;
u32 buf_vref_sel_mask;
u32 therm_trip_mode_shift;
@@ -258,6 +260,7 @@ struct exynos_tmu_registers {
* @first_point_trim: temp value of the first point trimming
* @second_point_trim: temp value of the second point trimming
* @default_temp_offset: default temperature offset in case of no trimming
+ * @test_mux; information if SoC supports test MUX
* @cal_type: calibration type for temperature
* @cal_mode: calibration mode for temperature
* @freq_clip_table: Table representing frequency reduction percentage.
@@ -287,6 +290,7 @@ struct exynos_tmu_platform_data {
u8 first_point_trim;
u8 second_point_trim;
u8 default_temp_offset;
+ u8 test_mux;
enum calibration_type cal_type;
enum calibration_mode cal_mode;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index d8de5c1..073c292 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -98,6 +98,7 @@ static const struct exynos_tmu_registers
exynos4412_tmu_registers = {
.triminfo_ctrl = EXYNOS_TMU_TRIMINFO_CON,
.triminfo_reload_shift = EXYNOS_TRIMINFO_RELOAD_SHIFT,
.tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
+ .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
.buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
.buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
.therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
@@ -174,6 +175,7 @@ struct exynos_tmu_init_data const
exynos4412_default_tmu_data = {
{
EXYNOS4412_TMU_DATA,
.type = SOC_ARCH_EXYNOS4412,
+ .test_mux = EXYNOS4412_MUX_ADDR_VALUE,
},
},
.tmu_count = 1,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/thermal/samsung/exynos_tmu_data.h
index b130b1e..a1ea19d 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -95,6 +95,10 @@
#define EXYNOS_MAX_TRIGGER_PER_REG 4
+/* Exynos4412 specific */
+#define EXYNOS4412_MUX_ADDR_VALUE 6
+#define EXYNOS4412_MUX_ADDR_SHIFT 20
+
/*exynos5440 specific registers*/
#define EXYNOS5440_TMU_S0_7_TRIM 0x000
#define EXYNOS5440_TMU_S0_7_CTRL 0x020
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
[PATCH v2 1/5] thermal: exynos: Remove check for thermal device pointer at exynos_report_trigger()
The commit 4de0bdaa9677d11406c9becb70c60887c957e1f0
(thermal: exynos: Add support for instance based register/unregister)
broke check for presence of therm_dev at global thermal zone in
exynos_report_trigger().
The resulting wrong test prevents thermal_zone_device_update() call, which
calls handlers for situation when trip points are passed.
Such behavior prevents thermal driver from proper reaction (when TMU interrupt
is raised) in a situation when overheating is detected at TMU hardware.
It turns out, that after exynos thermal subsystem redesign (at v3.12) this
check is not needed, since it is not possible to register thermal zone
without valid thermal device.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
Changes for v2:
- Remove check for th_zone-therm_dev at exynos_report_trigger()
drivers/thermal/samsung/exynos_thermal_common.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
index f10a6ad..c2301da 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -310,8 +310,6 @@ void exynos_report_trigger(struct thermal_sensor_conf *conf)
}
th_zone = conf-pzone_data;
- if (th_zone-therm_dev)
- return;
if (th_zone-bind == false) {
for (i = 0; i th_zone-cool_dev_size; i++) {
--
1.7.10.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 v2 2/5] thermal: exynos: Provide separate TMU data for Exynos4412
Up till now Exynos5250 and Exynos4412 had the same definitions for TMU
data. Following commit changes that, by introducing separate
exynos4412_default_tmu_data structure.
Since Exynos4412 was chronologically first, the corresponding name for
TMU registers and default data was renamed.
Additionally, new SOC_ARCH_EXYNOS4412 type has been defined.
Moreover, the SOC_ARCH_EXYNOS name has been changed to SOC_ARCH_EXYNOS5250.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
Changes for v2:
- Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250
- Fix coding style for tmu_data elements definition
drivers/thermal/samsung/exynos_tmu.c |9 +
drivers/thermal/samsung/exynos_tmu.h |3 ++-
drivers/thermal/samsung/exynos_tmu_data.c | 28 ++--
drivers/thermal/samsung/exynos_tmu_data.h |9 -
4 files changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index b43afda..1312b34 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -488,7 +488,7 @@ static const struct of_device_id exynos_tmu_match[] = {
},
{
.compatible = samsung,exynos4412-tmu,
- .data = (void *)EXYNOS5250_TMU_DRV_DATA,
+ .data = (void *)EXYNOS4412_TMU_DRV_DATA,
},
{
.compatible = samsung,exynos5250-tmu,
@@ -629,9 +629,10 @@ static int exynos_tmu_probe(struct platform_device *pdev)
if (ret)
return ret;
- if (pdata-type == SOC_ARCH_EXYNOS ||
- pdata-type == SOC_ARCH_EXYNOS4210 ||
- pdata-type == SOC_ARCH_EXYNOS5440)
+ if (pdata-type == SOC_ARCH_EXYNOS4210 ||
+ pdata-type == SOC_ARCH_EXYNOS4412 ||
+ pdata-type == SOC_ARCH_EXYNOS5250 ||
+ pdata-type == SOC_ARCH_EXYNOS5440)
data-soc = pdata-type;
else {
ret = -EINVAL;
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index b364c9e..b42ece4 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -41,7 +41,8 @@ enum calibration_mode {
enum soc_type {
SOC_ARCH_EXYNOS4210 = 1,
- SOC_ARCH_EXYNOS,
+ SOC_ARCH_EXYNOS4412,
+ SOC_ARCH_EXYNOS5250,
SOC_ARCH_EXYNOS5440,
};
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 9002499..d8de5c1 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -90,8 +90,8 @@ struct exynos_tmu_init_data const exynos4210_default_tmu_data
= {
};
#endif
-#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
-static const struct exynos_tmu_registers exynos5250_tmu_registers = {
+#if defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
+static const struct exynos_tmu_registers exynos4412_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
.triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
.triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
@@ -128,7 +128,7 @@ static const struct exynos_tmu_registers
exynos5250_tmu_registers = {
.emul_time_mask = EXYNOS_EMUL_TIME_MASK,
};
-#define EXYNOS5250_TMU_DATA \
+#define EXYNOS4412_TMU_DATA \
.threshold_falling = 10, \
.trigger_levels[0] = 85, \
.trigger_levels[1] = 103, \
@@ -162,15 +162,31 @@ static const struct exynos_tmu_registers
exynos5250_tmu_registers = {
.temp_level = 103, \
}, \
.freq_tab_count = 2, \
- .type = SOC_ARCH_EXYNOS, \
- .registers = exynos5250_tmu_registers, \
+ .registers = exynos4412_tmu_registers, \
.features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
TMU_SUPPORT_EMUL_TIME)
+#endif
+#if defined(CONFIG_SOC_EXYNOS4412)
+struct exynos_tmu_init_data const exynos4412_default_tmu_data = {
+ .tmu_data = {
+ {
+ EXYNOS4412_TMU_DATA,
+ .type = SOC_ARCH_EXYNOS4412,
+ },
+ },
+ .tmu_count = 1,
+};
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250)
struct exynos_tmu_init_data const exynos5250_default_tmu_data = {
.tmu_data = {
- { EXYNOS5250_TMU_DATA },
+ {
+ EXYNOS4412_TMU_DATA,
+ .type = SOC_ARCH_EXYNOS5250,
+ },
},
.tmu_count = 1,
};
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/thermal/samsung/exynos_tmu_data.h
index dc7feb5..b130b1e 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++
[PATCH] PCI: designware: Add irq_create_mapping()
Without irq_create_mapping(), the correct irq number cannot be
provided. In this case, it makes problem such as NULL deference.
Thus, irq_create_mapping() should be added for MSI.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Kishon Vijay Abraham I kis...@ti.com
---
Tested on Exynos5440.
drivers/pci/host/pcie-designware.c | 10 --
drivers/pci/host/pcie-designware.h |1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 8963017..e536bb6 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -237,6 +237,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc,
int *pos)
}
}
+ pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0);
+
irq = (pp-msi_irq_start + pos0);
if ((irq + no_irqs) (pp-msi_irq_start + MAX_MSI_IRQS-1))
@@ -372,8 +374,6 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
struct of_pci_range_parser parser;
u32 val;
- struct irq_domain *irq_domain;
-
if (of_pci_range_parser_init(parser, np)) {
dev_err(pp-dev, missing ranges property\n);
return -EINVAL;
@@ -441,15 +441,13 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
}
if (IS_ENABLED(CONFIG_PCI_MSI)) {
- irq_domain = irq_domain_add_linear(pp-dev-of_node,
+ pp-irq_domain = irq_domain_add_linear(pp-dev-of_node,
MAX_MSI_IRQS, msi_domain_ops,
dw_pcie_msi_chip);
- if (!irq_domain) {
+ if (!pp-irq_domain) {
dev_err(pp-dev, irq domain init failed\n);
return -ENXIO;
}
-
- pp-msi_irq_start = irq_find_mapping(irq_domain, 0);
}
if (pp-ops-host_init)
diff --git a/drivers/pci/host/pcie-designware.h
b/drivers/pci/host/pcie-designware.h
index faccbbf..240fc11 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -50,6 +50,7 @@ struct pcie_port {
int msi_irq_start;
unsigned long msi_data;
DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
+ struct irq_domain *irq_domain;
};
struct pcie_host_ops {
--
1.7.10.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] ARM: dts: Update arch timer node with clock frequency
On Tue, Oct 08, 2013 at 11:15:47PM +0100, Olof Johansson wrote: [Adding Tony, who reported a mainline booting issue, and Sean who helped me track this down] On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland mark.rutl...@arm.com wrote: On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: Hi Yuvaraj, On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: Without the clock-frequency property in arch timer node, could able to see the below crash dump. [snip] diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -96,6 +96,7 @@ 1 14 0xf08, 1 11 0xf08, 1 10 0xf08; + clock-frequency = 2400; Shouldn't it rather come from some clock provided by some clock controller instead? The frequency would be then retrieved using clk_get_rate() on a clock received by clk_get(), specified in device tree using generic clock bindings. If the bootloader has initialised the generic timer correctly, the CNTFRQ register should contain the clock frequency, independent of any external clock. So, we just sat here to bisect a problem on the Samsung Chromebook where we hit exactly this problem. The read-only firmware on the device does not set CNTFRQ at boot, so this fails. Ouch. That's a shame. A chained bootloader (like the KVM guys are using) should be able to set CNTFRQ, so as long as any chained loader actually does that this won't cause that to blow up... Apparantly the u-boot that comes with Arndale sets it, so I haven't seen this error on that platform. Having the bootloader set CNTFRQ is by far the preferable solution, it is architected for this purpose. Unfortunately there is now real hardware out there that needs this due to firmware bugs / missing features, so there's little other choice. :( Indeed :( I'll pick this patch up in the fixes branch for 3.12, unless someone complains loudly. Could you please add a note to the dts regarding why we actually need this? It would be nice to maintain the impression that this is not the preferred way of doing things... Cheers, Mark. -- 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 V5 4/5] video: exynos_mipi_dsim: Use the generic PHY driver
On 28/09/13 22:27, Sylwester Nawrocki wrote: Use the generic PHY API instead of the platform callback for the MIPI DSIM DPHY enable/reset control. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Felipe Balbi ba...@ti.com Acked-by: Donghwa Lee dh09@samsung.com --- Changes since v4: - PHY label removed from the platform data structure. --- drivers/video/exynos/Kconfig |1 + drivers/video/exynos/exynos_mipi_dsi.c | 19 ++- include/video/exynos_mipi_dsim.h |5 ++--- 3 files changed, 13 insertions(+), 12 deletions(-) Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] PCI: designware: Add irq_create_mapping()
Hi Jingoo, On Wednesday 09 October 2013 01:39 PM, Jingoo Han wrote: Without irq_create_mapping(), the correct irq number cannot be provided. In this case, it makes problem such as NULL deference. Thus, irq_create_mapping() should be added for MSI. Signed-off-by: Jingoo Han jg1@samsung.com Cc: Kishon Vijay Abraham I kis...@ti.com --- Tested on Exynos5440. drivers/pci/host/pcie-designware.c | 10 -- drivers/pci/host/pcie-designware.h |1 + 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c index 8963017..e536bb6 100644 --- a/drivers/pci/host/pcie-designware.c +++ b/drivers/pci/host/pcie-designware.c @@ -237,6 +237,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos) } } + pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0); + I think irq_create_mapping should be done for all the MSI irq lines instead of only the first line. So you might have to do for MAX_MSI_IRQS lines. Thanks Kishon -- 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] PCI: designware: Add irq_create_mapping()
On Wednesday, October 09, 2013 6:06 PM, Kishon Vijay Abraham I wrote: On Wednesday 09 October 2013 01:39 PM, Jingoo Han wrote: Without irq_create_mapping(), the correct irq number cannot be provided. In this case, it makes problem such as NULL deference. Thus, irq_create_mapping() should be added for MSI. Signed-off-by: Jingoo Han jg1@samsung.com Cc: Kishon Vijay Abraham I kis...@ti.com --- Tested on Exynos5440. drivers/pci/host/pcie-designware.c | 10 -- drivers/pci/host/pcie-designware.h |1 + 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c index 8963017..e536bb6 100644 --- a/drivers/pci/host/pcie-designware.c +++ b/drivers/pci/host/pcie-designware.c @@ -237,6 +237,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos) } } + pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0); + I think irq_create_mapping should be done for all the MSI irq lines instead of only the first line. So you might have to do for MAX_MSI_IRQS lines. I tested PCIe LAN card after I replaced 0 with MAX_MSI_IRQS. However, it makes an error message as below: But, PCIe LAN card works properly. WARNING: CPU: 1 PID: 1 at kernel/irq/irqdomain.c:276 irq_domain_associate+0x150/0x1a8() error: hwirq 0x20 is too large for (null) Best regards, Jingoo Han -- 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] PCI: designware: Add irq_create_mapping()
On Wednesday 09 October 2013 02:47 PM, Jingoo Han wrote: On Wednesday, October 09, 2013 6:06 PM, Kishon Vijay Abraham I wrote: On Wednesday 09 October 2013 01:39 PM, Jingoo Han wrote: Without irq_create_mapping(), the correct irq number cannot be provided. In this case, it makes problem such as NULL deference. Thus, irq_create_mapping() should be added for MSI. Signed-off-by: Jingoo Han jg1@samsung.com Cc: Kishon Vijay Abraham I kis...@ti.com --- Tested on Exynos5440. drivers/pci/host/pcie-designware.c | 10 -- drivers/pci/host/pcie-designware.h |1 + 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c index 8963017..e536bb6 100644 --- a/drivers/pci/host/pcie-designware.c +++ b/drivers/pci/host/pcie-designware.c @@ -237,6 +237,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos) } } + pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0); + I think irq_create_mapping should be done for all the MSI irq lines instead of only the first line. So you might have to do for MAX_MSI_IRQS lines. Maybe it should be only till MAX_MSI_IRQS-1? Thanks Kishon -- 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: [RESEND PATCH 1/3] ARM: EXYNOS: Move arm core power down clock to exynos5250 common clock
Hi, Mike: Could you please apply this patch? It is few months overdue.. Amit: This patch no longer applies to -next. Could you please refresh and resend it? You can add: Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com while at it. Thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics On Friday, August 16, 2013 10:22:44 AM amit daniel kachhap wrote: Hi Mike, Please merge this patch as it is pending since last merge window. Thanks, Amit On Thu, Jun 13, 2013 at 5:56 PM, Kukjin Kim kgene@samsung.com wrote: Amit Daniel Kachhap wrote: Now with common clock support added for exynos5250 it is necessary to move this code to exynos5250 common clock driver as clock registers should be handled there. This change is tested in exynos5250 based arndale platform. Cc: Abhilash Kesavan a.kesa...@samsung.com Cc: Thomas Abraham thomas.abra...@linaro.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Hmm...I'm not sure it's better to handle the ARM core power down clock in common clock but the clock registers should be handled in one part, clock. Acked-by: Kukjin Kim kgene@samsugn.com Mike, the mach-exynos/cpuidle.c is not touched in samsung tree at this moment, so this patch will not create any conflict between samsung and clk. Thanks, - Kukjin -- 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] PCI: designware: Add irq_create_mapping()
On Wednesday, October 09, 2013 6:48 PM, Kishon Vijay Abraham I wrote: On Wednesday 09 October 2013 02:47 PM, Jingoo Han wrote: On Wednesday, October 09, 2013 6:06 PM, Kishon Vijay Abraham I wrote: On Wednesday 09 October 2013 01:39 PM, Jingoo Han wrote: Without irq_create_mapping(), the correct irq number cannot be provided. In this case, it makes problem such as NULL deference. Thus, irq_create_mapping() should be added for MSI. Signed-off-by: Jingoo Han jg1@samsung.com Cc: Kishon Vijay Abraham I kis...@ti.com --- Tested on Exynos5440. drivers/pci/host/pcie-designware.c | 10 -- drivers/pci/host/pcie-designware.h |1 + 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c index 8963017..e536bb6 100644 --- a/drivers/pci/host/pcie-designware.c +++ b/drivers/pci/host/pcie-designware.c @@ -237,6 +237,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos) } } + pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0); + I think irq_create_mapping should be done for all the MSI irq lines instead of only the first line. So you might have to do for MAX_MSI_IRQS lines. Maybe it should be only till MAX_MSI_IRQS-1? I am not sure; however, it doesn't look correct. irq_create_mapping() is defined as below. According to the comment, irq_create_mapping() maps 'a' hardware interrupt, not max value of MSI IRQ lines. ./kernel/irq/irqdomain.c /** * irq_create_mapping() - Map a hardware interrupt into linux irq space * @domain: domain owning this hardware interrupt or NULL for default domain * @hwirq: hardware irq number in that domain space [.] unsigned int irq_create_mapping(struct irq_domain *domain, irq_hw_number_t hwirq) Also, another value of 'irq' can be selected, because 'pos0' is added. pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0); irq = (pp-msi_irq_start + pos0); Pratyush Anand, If I am wrong, please let me know. :-) Best regards, Jingoo Han -- 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] PCI: designware: Add irq_create_mapping()
On Wednesday 09 October 2013 03:35 PM, Jingoo Han wrote: On Wednesday, October 09, 2013 6:48 PM, Kishon Vijay Abraham I wrote: On Wednesday 09 October 2013 02:47 PM, Jingoo Han wrote: On Wednesday, October 09, 2013 6:06 PM, Kishon Vijay Abraham I wrote: On Wednesday 09 October 2013 01:39 PM, Jingoo Han wrote: Without irq_create_mapping(), the correct irq number cannot be provided. In this case, it makes problem such as NULL deference. Thus, irq_create_mapping() should be added for MSI. Signed-off-by: Jingoo Han jg1@samsung.com Cc: Kishon Vijay Abraham I kis...@ti.com --- Tested on Exynos5440. drivers/pci/host/pcie-designware.c | 10 -- drivers/pci/host/pcie-designware.h |1 + 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c index 8963017..e536bb6 100644 --- a/drivers/pci/host/pcie-designware.c +++ b/drivers/pci/host/pcie-designware.c @@ -237,6 +237,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos) } } + pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0); + I think irq_create_mapping should be done for all the MSI irq lines instead of only the first line. So you might have to do for MAX_MSI_IRQS lines. Maybe it should be only till MAX_MSI_IRQS-1? I meant something like this, for (i = 0; i MAX_MSI_IRQS; i++) irq_create_mapping(pp-irq_domain, i); That didn't give me any issues though. Thanks Kishon -- 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] PCI: designware: Add irq_create_mapping()
On Wednesday, October 09, 2013 7:27 PM, Kishon Vijay Abraham I wrote:
On Wednesday 09 October 2013 03:35 PM, Jingoo Han wrote:
On Wednesday, October 09, 2013 6:48 PM, Kishon Vijay Abraham I wrote:
On Wednesday 09 October 2013 02:47 PM, Jingoo Han wrote:
On Wednesday, October 09, 2013 6:06 PM, Kishon Vijay Abraham I wrote:
On Wednesday 09 October 2013 01:39 PM, Jingoo Han wrote:
Without irq_create_mapping(), the correct irq number cannot be
provided. In this case, it makes problem such as NULL deference.
Thus, irq_create_mapping() should be added for MSI.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Kishon Vijay Abraham I kis...@ti.com
---
Tested on Exynos5440.
drivers/pci/host/pcie-designware.c | 10 --
drivers/pci/host/pcie-designware.h |1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 8963017..e536bb6 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -237,6 +237,8 @@ static int assign_irq(int no_irqs, struct msi_desc
*desc, int *pos)
}
}
+ pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0);
+
I think irq_create_mapping should be done for all the MSI irq lines
instead of
only the first line. So you might have to do for MAX_MSI_IRQS lines.
Maybe it should be only till MAX_MSI_IRQS-1?
I meant something like this,
for (i = 0; i MAX_MSI_IRQS; i++)
irq_create_mapping(pp-irq_domain, i);
That didn't give me any issues though.
However, no driver calls irq_create_mapping() like this.
For example, Tegra PCI driver gives 'hwirq' as single offset value
to irq_create_mapping() without any loop.
static int tegra_msi_setup_irq(struct msi_chip *chip, struct pci_dev *pdev,
struct msi_desc *desc)
{
hwirq = tegra_msi_alloc(msi);
irq = irq_create_mapping(msi-domain, hwirq);
Maybe, the following can be used, it uses 'pos0' as the offset value.
pp-msi_irq_start = irq_create_mapping(pp-irq_domain, pos0);
irq = pp-msi_irq_start;
Best regards,
Jingoo Han
--
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] PCI: designware: Add irq_create_mapping()
On Wed, Oct 09, 2013 at 06:49:15PM +0800, Jingoo Han wrote:
On Wednesday, October 09, 2013 7:27 PM, Kishon Vijay Abraham I wrote:
On Wednesday 09 October 2013 03:35 PM, Jingoo Han wrote:
On Wednesday, October 09, 2013 6:48 PM, Kishon Vijay Abraham I wrote:
On Wednesday 09 October 2013 02:47 PM, Jingoo Han wrote:
On Wednesday, October 09, 2013 6:06 PM, Kishon Vijay Abraham I wrote:
On Wednesday 09 October 2013 01:39 PM, Jingoo Han wrote:
Without irq_create_mapping(), the correct irq number cannot be
provided. In this case, it makes problem such as NULL deference.
Thus, irq_create_mapping() should be added for MSI.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Kishon Vijay Abraham I kis...@ti.com
---
Tested on Exynos5440.
drivers/pci/host/pcie-designware.c | 10 --
drivers/pci/host/pcie-designware.h |1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 8963017..e536bb6 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -237,6 +237,8 @@ static int assign_irq(int no_irqs, struct
msi_desc *desc, int *pos)
}
}
+ pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0);
+
I think irq_create_mapping should be done for all the MSI irq lines
instead of
only the first line. So you might have to do for MAX_MSI_IRQS lines.
Maybe it should be only till MAX_MSI_IRQS-1?
I meant something like this,
for (i = 0; i MAX_MSI_IRQS; i++)
irq_create_mapping(pp-irq_domain, i);
That didn't give me any issues though.
However, no driver calls irq_create_mapping() like this.
For example, Tegra PCI driver gives 'hwirq' as single offset value
to irq_create_mapping() without any loop.
static int tegra_msi_setup_irq(struct msi_chip *chip, struct pci_dev *pdev,
struct msi_desc *desc)
{
hwirq = tegra_msi_alloc(msi);
irq = irq_create_mapping(msi-domain, hwirq);
Maybe, the following can be used, it uses 'pos0' as the offset value.
pp-msi_irq_start = irq_create_mapping(pp-irq_domain, pos0);
irq = pp-msi_irq_start;
Documentation/IRQ-domain.txt says that The irq_create_mapping()
function must be called *atleast once* before any call to
irq_find_mapping(), lest the descriptor will not be allocated.
So for sure current code need to be modified.
Now, you can create the mapping statically during initialization and
then use it dynamically whenever needed. In that case what Kishon
suggested is right, something like following should work.
for (i = 0; i MAX_MSI_IRQS; i++)
irq_create_mapping(pp-irq_domain, i);
pp-msi_irq_start = irq_find_mapping(pp-irq_domain, 0);
But, I am not sure that created mapping is continuous. I mean,
difference between irq returned by
irq_find_mapping(pp-irq_domain, 0)
irq_find_mapping(pp-irq_domain, 9)
is always 9. If that is not the case then, static assignment of
msi_irq_start will not work. May be you need something as follows:
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 8963017..e6749e8 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -157,7 +157,7 @@ static struct irq_chip dw_msi_irq_chip = {
void dw_handle_msi_irq(struct pcie_port *pp)
{
unsigned long val;
- int i, pos;
+ int i, pos, irq;
for (i = 0; i MAX_MSI_CTRLS; i++) {
dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4,
@@ -165,8 +165,9 @@ void dw_handle_msi_irq(struct pcie_port *pp)
if (val) {
pos = 0;
while ((pos = find_next_bit(val, 32, pos)) != 32) {
- generic_handle_irq(pp-msi_irq_start
- + (i * 32) + pos);
+ irq = irq_find_mapping(pp-irq_domain,
+ i * 32 + pos);
+ generic_handle_irq(irq);
pos++;
}
}
@@ -237,9 +238,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc,
int *pos)
}
}
- irq = (pp-msi_irq_start + pos0);
-
- if ((irq + no_irqs) (pp-msi_irq_start + MAX_MSI_IRQS-1))
+ irq = irq_find_mapping(pp-irq_domain, pos0);
+ if (!irq)
goto no_valid_irq;
i = 0;
@@ -270,6 +270,7 @@ static void clear_irq(unsigned int irq)
struct irq_desc *desc;
struct msi_desc *msi;
struct pcie_port *pp;
+ struct irq_data *data = irq_get_irq_data(irq);
/* get the port structure */
desc = irq_to_desc(irq);
@@ -280,7 +281,7 @@ static void clear_irq(unsigned int irq)
Re: [PATCH 3/3] thermal: samsung: Add TMU support for Exynos5420 SoCs
Hello Bartlomiej,
On 3 October 2013 18:12, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
Hi,
I would like to see few minor cleanup changes, please see below:
Sure.
On Thursday, October 03, 2013 05:31:42 PM Naveen Krishna Ch wrote:
On 4 September 2013 09:53, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
This patch adds the neccessary register changes and arch information
to support Exynos5420 SoCs
Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
Also updated the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Note: The platform data structure will be handled properly once the driver
moves to complete device driver solution.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v1:
1. modified the platform data structure in order to pass SHARED flag
for channels that need sharing of address space.
2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
As the changes are minimum and can be added here.
.../devicetree/bindings/thermal/exynos-thermal.txt | 39 ++
drivers/thermal/samsung/exynos_tmu.c | 14 ++-
drivers/thermal/samsung/exynos_tmu.h |1 +
drivers/thermal/samsung/exynos_tmu_data.c | 130
drivers/thermal/samsung/exynos_tmu_data.h |7 ++
5 files changed, 189 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..d70f2a4 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -7,12 +7,23 @@
samsung,exynos4210-tmu
samsung,exynos5250-tmu
samsung,exynos5440-tmu
+ samsung,exynos5420-tmu
it should come before samsung,exynos5440-tmu
Done
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has
multiple
instances of TMU and some registers are shared across all TMU's
like
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second
set
of common TMU registers.
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
+ The misplaced register address is passed through devicetree as the
+ second base
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +54,34 @@ Example 2):
clock-names = tmu_apbif;
};
+Example 3): (In case of Exynos5420)
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x10068000 0x100, 0x1006c000 0x4;
+ interrupts = 0 184 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x1006c000 0x100, 0x100a 0x4;
+ interrupts = 0 185 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x100a 0x100, 0x10068000 0x4;
+ interrupts = 0 215 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in aliases node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 3a55caf..6d34652 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
}
} else {
- trim_info = readl(data-base + reg-triminfo_data);
+ /* On exynos5420 the triminfo register is in the shared
space */
+ if (data-base_second (data-soc ==
SOC_ARCH_EXYNOS5420))
+ trim_info = readl(data-base_second +
+
reg-triminfo_data);
+ else
+
[PATCH 1/3 v4] thermal: samsung: correct the fall interrupt en, status bit fields
The FALL interrupt related en, status bits are available at an offset of
16 on INTEN, INTSTAT registers and at an offset of
12 on INTCLEAR register.
This patch corrects the same for exyns5250 and exynos5440
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v1:
Changes since v2:
Changes since v3:
None
drivers/thermal/samsung/exynos_tmu.c |2 +-
drivers/thermal/samsung/exynos_tmu.h |2 ++
drivers/thermal/samsung/exynos_tmu_data.c |2 ++
drivers/thermal/samsung/exynos_tmu_data.h |3 ++-
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index b43afda..af69209 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -265,7 +265,7 @@ skip_calib_data:
data-base + reg-threshold_th1);
writel((reg-inten_rise_mask reg-inten_rise_shift) |
- (reg-inten_fall_mask reg-inten_fall_shift),
+ (reg-inten_fall_mask reg-intclr_fall_shift),
data-base + reg-tmu_intclear);
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index b364c9e..7c6c34a 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -134,6 +134,7 @@ enum soc_type {
* @inten_fall3_shift: shift bits of falling 3 interrupt bits.
* @tmu_intstat: Register containing the interrupt status values.
* @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
@@ -204,6 +205,7 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
u32 tmu_intclear;
+ u32 intclr_fall_shift;
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 9002499..23fea23 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -122,6 +122,7 @@ static const struct exynos_tmu_registers
exynos5250_tmu_registers = {
.inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
.tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+ .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
.emul_con = EXYNOS_EMUL_CON,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
.emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
@@ -210,6 +211,7 @@ static const struct exynos_tmu_registers
exynos5440_tmu_registers = {
.inten_fall0_shift = EXYNOS5440_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS5440_TMU_S0_7_IRQ,
.tmu_intclear = EXYNOS5440_TMU_S0_7_IRQ,
+ .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
.tmu_irqstatus = EXYNOS5440_TMU_IRQ_STATUS,
.emul_con = EXYNOS5440_TMU_S0_7_DEBUG,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/thermal/samsung/exynos_tmu_data.h
index dc7feb5..8788a87 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -69,9 +69,10 @@
#define EXYNOS_TMU_RISE_INT_MASK 0x111
#define EXYNOS_TMU_RISE_INT_SHIFT 0
#define EXYNOS_TMU_FALL_INT_MASK 0x111
-#define EXYNOS_TMU_FALL_INT_SHIFT 12
+#define EXYNOS_TMU_FALL_INT_SHIFT 16
#define EXYNOS_TMU_CLEAR_RISE_INT 0x111
#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 12)
+#define EXYNOS_TMU_CLEAR_FALL_INT_SHIFT12
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
#define EXYNOS_TMU_TRIP_MODE_MASK 0x7
#define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12
--
1.7.10.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 3/3 v4] thermal: samsung: Add TMU support for Exynos5420 SoCs
This patch adds the neccessary register changes and arch information
to support Exynos5420 SoCs
Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
Also updated the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Note: The platform data structure will be handled properly once the driver
moves to complete device driver solution.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
-Changes since v1:
1. modified the platform data structure in order to pass SHARED flag
for channels that need sharing of address space.
2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
As the changes are minimum and can be added here.
Changes since v3:
a. Rearraged the code alphabetically, make exynso5420 come before exynso5440
b. Reduce code duplication in passing platform data by introducing a common
macro
Bartlomiej Zolnierkiewicz Thanks for review and suggestions
---
.../devicetree/bindings/thermal/exynos-thermal.txt | 39
drivers/thermal/samsung/exynos_tmu.c | 12 ++-
drivers/thermal/samsung/exynos_tmu.h |1 +
drivers/thermal/samsung/exynos_tmu_data.c | 99
drivers/thermal/samsung/exynos_tmu_data.h |7 ++
5 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..c5f9a74 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,7 @@
samsung,exynos4412-tmu
samsung,exynos4210-tmu
samsung,exynos5250-tmu
+ samsung,exynos5420-tmu
samsung,exynos5440-tmu
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has multiple
@@ -13,6 +14,16 @@
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
+ The misplaced register address is passed through devicetree as the
+ second base
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +54,34 @@ Example 2):
clock-names = tmu_apbif;
};
+Example 3): (In case of Exynos5420)
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x10068000 0x100, 0x1006c000 0x4;
+ interrupts = 0 184 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x1006c000 0x100, 0x100a 0x4;
+ interrupts = 0 185 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x100a 0x100, 0x10068000 0x4;
+ interrupts = 0 215 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in aliases node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 40c4243..852034f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
}
} else {
- trim_info = readl(data-base + reg-triminfo_data);
+ /* On exynos5420 the triminfo register is in the shared space */
+ if (data-base_second (data-soc == SOC_ARCH_EXYNOS5420))
+ trim_info = readl(data-base_second +
+ reg-triminfo_data);
+ else
+ trim_info = readl(data-base + reg-triminfo_data);
}
data-temp_error1 = trim_info EXYNOS_TMU_TEMP_MASK;
data-temp_error2 = ((trim_info reg-triminfo_85_shift)
@@ -495,6 +500,10 @@ static const struct of_device_id exynos_tmu_match[] = {
.data = (void *)EXYNOS5250_TMU_DRV_DATA,
},
{
+ .compatible =
[PATCH 2/3 v4] thermal: samsung: change base_common to more meaningful base_second
On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.
To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the reg property of the node.
As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v1:
None
Changes since v2:
Changed the flag name from SHARED_MEMORY to ADDRESS_MULTIPLE.
https://lkml.org/lkml/2013/8/1/38
Changes since v3:
None
.../devicetree/bindings/thermal/exynos-thermal.txt |4 ++--
drivers/thermal/samsung/exynos_tmu.c | 12 ++--
drivers/thermal/samsung/exynos_tmu.h |4 ++--
drivers/thermal/samsung/exynos_tmu_data.c |2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..116cca0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
- belongs to each instance of TMU and second set belongs to common TMU
- registers.
+ belongs to each instance of TMU and second set belongs to second set
+ of common TMU registers.
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index af69209..40c4243 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
* @id: identifier of the one instance of the TMU controller.
* @pdata: pointer to the tmu platform/configuration data
* @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
* @irq: irq number of the TMU controller.
* @soc: id of the SOC type.
* @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
- void __iomem *base_common;
+ void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg-tmu_pmin !data-id)
- writel(0, data-base_common + reg-tmu_pmin);
+ writel(0, data-base_second + reg-tmu_pmin);
out:
clk_disable(data-clk);
mutex_unlock(data-lock);
@@ -451,7 +451,7 @@ static void exynos_tmu_work(struct work_struct *work)
/* Find which sensor generated this interrupt */
if (reg-tmu_irqstatus) {
- val_type = readl(data-base_common + reg-tmu_irqstatus);
+ val_type = readl(data-base_second + reg-tmu_irqstatus);
if (!((val_type data-id) 0x1))
goto out;
}
@@ -576,7 +576,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
* Check if the TMU shares some registers and then try to map the
* memory of common registers.
*/
- if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+ if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
if (of_address_to_resource(pdev-dev.of_node, 1, res)) {
@@ -584,7 +584,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
- data-base_common = devm_ioremap(pdev-dev, res.start,
+ data-base_second = devm_ioremap(pdev-dev, res.start,
resource_size(res));
if (!data-base_common) {
dev_err(pdev-dev, Failed to ioremap memory\n);
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 7c6c34a..ebd2ec1 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -59,7 +59,7 @@ enum soc_type {
* state(active/idle) can be checked.
* TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
* sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
+ * TMU_SUPPORT_ADDRESS_MULTIPLE - This feature tells that the different TMU
* sensors shares some common registers.
* TMU_SUPPORT - macro
Re: [PATCH] PCI: designware: Add irq_create_mapping()
On Wednesday, October 09, 2013 8:14 PM, Pratyush Anand wrote:
On Wed, Oct 09, 2013 at 06:49:15PM +0800, Jingoo Han wrote:
On Wednesday, October 09, 2013 7:27 PM, Kishon Vijay Abraham I wrote:
On Wednesday 09 October 2013 03:35 PM, Jingoo Han wrote:
On Wednesday, October 09, 2013 6:48 PM, Kishon Vijay Abraham I wrote:
On Wednesday 09 October 2013 02:47 PM, Jingoo Han wrote:
On Wednesday, October 09, 2013 6:06 PM, Kishon Vijay Abraham I wrote:
On Wednesday 09 October 2013 01:39 PM, Jingoo Han wrote:
Without irq_create_mapping(), the correct irq number cannot be
provided. In this case, it makes problem such as NULL deference.
Thus, irq_create_mapping() should be added for MSI.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Kishon Vijay Abraham I kis...@ti.com
---
Tested on Exynos5440.
drivers/pci/host/pcie-designware.c | 10 --
drivers/pci/host/pcie-designware.h |1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 8963017..e536bb6 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -237,6 +237,8 @@ static int assign_irq(int no_irqs, struct
msi_desc *desc, int *pos)
}
}
+ pp-msi_irq_start = irq_create_mapping(pp-irq_domain, 0);
+
I think irq_create_mapping should be done for all the MSI irq lines
instead of
only the first line. So you might have to do for MAX_MSI_IRQS lines.
Maybe it should be only till MAX_MSI_IRQS-1?
I meant something like this,
for (i = 0; i MAX_MSI_IRQS; i++)
irq_create_mapping(pp-irq_domain, i);
That didn't give me any issues though.
However, no driver calls irq_create_mapping() like this.
For example, Tegra PCI driver gives 'hwirq' as single offset value
to irq_create_mapping() without any loop.
static int tegra_msi_setup_irq(struct msi_chip *chip, struct pci_dev *pdev,
struct msi_desc *desc)
{
hwirq = tegra_msi_alloc(msi);
irq = irq_create_mapping(msi-domain, hwirq);
Maybe, the following can be used, it uses 'pos0' as the offset value.
pp-msi_irq_start = irq_create_mapping(pp-irq_domain, pos0);
irq = pp-msi_irq_start;
Documentation/IRQ-domain.txt says that The irq_create_mapping()
function must be called *atleast once* before any call to
irq_find_mapping(), lest the descriptor will not be allocated.
So for sure current code need to be modified.
Now, you can create the mapping statically during initialization and
then use it dynamically whenever needed. In that case what Kishon
suggested is right, something like following should work.
for (i = 0; i MAX_MSI_IRQS; i++)
irq_create_mapping(pp-irq_domain, i);
pp-msi_irq_start = irq_find_mapping(pp-irq_domain, 0);
But, I am not sure that created mapping is continuous. I mean,
difference between irq returned by
irq_find_mapping(pp-irq_domain, 0)
irq_find_mapping(pp-irq_domain, 9)
is always 9. If that is not the case then, static assignment of
msi_irq_start will not work. May be you need something as follows:
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 8963017..e6749e8 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -157,7 +157,7 @@ static struct irq_chip dw_msi_irq_chip = {
void dw_handle_msi_irq(struct pcie_port *pp)
{
unsigned long val;
- int i, pos;
+ int i, pos, irq;
for (i = 0; i MAX_MSI_CTRLS; i++) {
dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4,
@@ -165,8 +165,9 @@ void dw_handle_msi_irq(struct pcie_port *pp)
if (val) {
pos = 0;
while ((pos = find_next_bit(val, 32, pos)) != 32) {
- generic_handle_irq(pp-msi_irq_start
- + (i * 32) + pos);
+ irq = irq_find_mapping(pp-irq_domain,
+ i * 32 + pos);
+ generic_handle_irq(irq);
pos++;
}
}
@@ -237,9 +238,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc,
int *pos)
}
}
- irq = (pp-msi_irq_start + pos0);
-
- if ((irq + no_irqs) (pp-msi_irq_start + MAX_MSI_IRQS-1))
+ irq = irq_find_mapping(pp-irq_domain, pos0);
+ if (!irq)
goto no_valid_irq;
i = 0;
@@ -270,6 +270,7 @@ static void clear_irq(unsigned int irq)
struct irq_desc *desc;
struct msi_desc *msi;
struct pcie_port *pp;
+ struct irq_data *data =
[PATCH V2] PCI: designware: Add irq_create_mapping()
From: Pratyush Anand pratyush.an...@st.com
Without irq_create_mapping(), the correct irq number cannot be
provided. In this case, it makes problems such as NULL deference.
Thus, irq_create_mapping() should be added for MSI.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
Suggested-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Jingoo Han jg1@samsung.com
---
Tested on Exynos5440.
drivers/pci/host/pcie-designware.c | 25 +
drivers/pci/host/pcie-designware.h |2 +-
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 8963017..92d58fd 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -157,7 +157,7 @@ static struct irq_chip dw_msi_irq_chip = {
void dw_handle_msi_irq(struct pcie_port *pp)
{
unsigned long val;
- int i, pos;
+ int i, pos, irq;
for (i = 0; i MAX_MSI_CTRLS; i++) {
dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4,
@@ -165,8 +165,9 @@ void dw_handle_msi_irq(struct pcie_port *pp)
if (val) {
pos = 0;
while ((pos = find_next_bit(val, 32, pos)) != 32) {
- generic_handle_irq(pp-msi_irq_start
- + (i * 32) + pos);
+ irq = irq_find_mapping(pp-irq_domain,
+ i * 32 + pos);
+ generic_handle_irq(irq);
pos++;
}
}
@@ -237,9 +238,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc,
int *pos)
}
}
- irq = (pp-msi_irq_start + pos0);
-
- if ((irq + no_irqs) (pp-msi_irq_start + MAX_MSI_IRQS-1))
+ irq = irq_find_mapping(pp-irq_domain, pos0);
+ if (!irq)
goto no_valid_irq;
i = 0;
@@ -270,6 +270,7 @@ static void clear_irq(unsigned int irq)
struct irq_desc *desc;
struct msi_desc *msi;
struct pcie_port *pp;
+ struct irq_data *data = irq_get_irq_data(irq);
/* get the port structure */
desc = irq_to_desc(irq);
@@ -280,7 +281,7 @@ static void clear_irq(unsigned int irq)
return;
}
- pos = irq - pp-msi_irq_start;
+ pos = data-hwirq;
irq_free_desc(irq);
@@ -371,8 +372,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
struct of_pci_range range;
struct of_pci_range_parser parser;
u32 val;
-
- struct irq_domain *irq_domain;
+ int i;
if (of_pci_range_parser_init(parser, np)) {
dev_err(pp-dev, missing ranges property\n);
@@ -441,15 +441,16 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
}
if (IS_ENABLED(CONFIG_PCI_MSI)) {
- irq_domain = irq_domain_add_linear(pp-dev-of_node,
+ pp-irq_domain = irq_domain_add_linear(pp-dev-of_node,
MAX_MSI_IRQS, msi_domain_ops,
dw_pcie_msi_chip);
- if (!irq_domain) {
+ if (!pp-irq_domain) {
dev_err(pp-dev, irq domain init failed\n);
return -ENXIO;
}
- pp-msi_irq_start = irq_find_mapping(irq_domain, 0);
+ for (i = 0; i MAX_MSI_IRQS; i++)
+ irq_create_mapping(pp-irq_domain, i);
}
if (pp-ops-host_init)
diff --git a/drivers/pci/host/pcie-designware.h
b/drivers/pci/host/pcie-designware.h
index faccbbf..1bf9fc5 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -47,7 +47,7 @@ struct pcie_port {
u32 lanes;
struct pcie_host_ops*ops;
int msi_irq;
- int msi_irq_start;
+ struct irq_domain *irq_domain;
unsigned long msi_data;
DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
};
--
1.7.10.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 1/3 v4] thermal: samsung: correct the fall interrupt en, status bit fields
Hi,
All patches (#1-#3) look good to me, FWIW you can add:
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Please note that (at least) patch #3 conflicts with Lukasz's EXYNOS4412
fixup patchset:
https://lkml.org/lkml/2013/10/9/35
It is up to Eduardo to resolve this but it probably would be better to
merge EXYNOS4412 fixes first and then add EXYNOS5420 support. This would
require you to port patch #3 over Lukasz's patchset though.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
On Wednesday, October 09, 2013 05:38:27 PM Naveen Krishna Chatradhi wrote:
The FALL interrupt related en, status bits are available at an offset of
16 on INTEN, INTSTAT registers and at an offset of
12 on INTCLEAR register.
This patch corrects the same for exyns5250 and exynos5440
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v1:
Changes since v2:
Changes since v3:
None
drivers/thermal/samsung/exynos_tmu.c |2 +-
drivers/thermal/samsung/exynos_tmu.h |2 ++
drivers/thermal/samsung/exynos_tmu_data.c |2 ++
drivers/thermal/samsung/exynos_tmu_data.h |3 ++-
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index b43afda..af69209 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -265,7 +265,7 @@ skip_calib_data:
data-base + reg-threshold_th1);
writel((reg-inten_rise_mask reg-inten_rise_shift) |
- (reg-inten_fall_mask reg-inten_fall_shift),
+ (reg-inten_fall_mask reg-intclr_fall_shift),
data-base + reg-tmu_intclear);
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index b364c9e..7c6c34a 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -134,6 +134,7 @@ enum soc_type {
* @inten_fall3_shift: shift bits of falling 3 interrupt bits.
* @tmu_intstat: Register containing the interrupt status values.
* @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
@@ -204,6 +205,7 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
u32 tmu_intclear;
+ u32 intclr_fall_shift;
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 9002499..23fea23 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -122,6 +122,7 @@ static const struct exynos_tmu_registers
exynos5250_tmu_registers = {
.inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
.tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+ .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
.emul_con = EXYNOS_EMUL_CON,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
.emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
@@ -210,6 +211,7 @@ static const struct exynos_tmu_registers
exynos5440_tmu_registers = {
.inten_fall0_shift = EXYNOS5440_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS5440_TMU_S0_7_IRQ,
.tmu_intclear = EXYNOS5440_TMU_S0_7_IRQ,
+ .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
.tmu_irqstatus = EXYNOS5440_TMU_IRQ_STATUS,
.emul_con = EXYNOS5440_TMU_S0_7_DEBUG,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/thermal/samsung/exynos_tmu_data.h
index dc7feb5..8788a87 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -69,9 +69,10 @@
#define EXYNOS_TMU_RISE_INT_MASK 0x111
#define EXYNOS_TMU_RISE_INT_SHIFT0
#define EXYNOS_TMU_FALL_INT_MASK 0x111
-#define EXYNOS_TMU_FALL_INT_SHIFT12
+#define EXYNOS_TMU_FALL_INT_SHIFT16
#define EXYNOS_TMU_CLEAR_RISE_INT0x111
#define EXYNOS_TMU_CLEAR_FALL_INT(0x111 12)
+#define EXYNOS_TMU_CLEAR_FALL_INT_SHIFT 12
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
#define EXYNOS_TMU_TRIP_MODE_MASK0x7
#define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12
--
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] cpufreq: fix false return check from regulator_set_voltage
Currently, code checks false return value from regulator_set_voltage
to show failure message. Modify the code to check proper return
value from regulator_set_voltage.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
---
Based on master branch of linux-mainline.
:100644 100644 0fac344... 1537f32... M drivers/cpufreq/exynos-cpufreq.c
drivers/cpufreq/exynos-cpufreq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 0fac344..1537f32 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -141,7 +141,7 @@ post_notify:
if ((freqs.new freqs.old) ||
((freqs.new freqs.old) safe_arm_volt)) {
/* down the voltage after frequency change */
- regulator_set_voltage(arm_regulator, arm_volt,
+ ret = regulator_set_voltage(arm_regulator, arm_volt,
arm_volt);
if (ret) {
pr_err(%s: failed to set cpu voltage to %d\n,
--
1.7.10.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 V2] PCI: designware: Add irq_create_mapping()
On Wed, Oct 9, 2013 at 6:32 AM, Jingoo Han jg1@samsung.com wrote:
From: Pratyush Anand pratyush.an...@st.com
Without irq_create_mapping(), the correct irq number cannot be
provided. In this case, it makes problems such as NULL deference.
Thus, irq_create_mapping() should be added for MSI.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
Suggested-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Jingoo Han jg1@samsung.com
Applied to my pci/host-exynos branch for v3.13, thanks!
Bjorn
---
Tested on Exynos5440.
drivers/pci/host/pcie-designware.c | 25 +
drivers/pci/host/pcie-designware.h |2 +-
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 8963017..92d58fd 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -157,7 +157,7 @@ static struct irq_chip dw_msi_irq_chip = {
void dw_handle_msi_irq(struct pcie_port *pp)
{
unsigned long val;
- int i, pos;
+ int i, pos, irq;
for (i = 0; i MAX_MSI_CTRLS; i++) {
dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4,
@@ -165,8 +165,9 @@ void dw_handle_msi_irq(struct pcie_port *pp)
if (val) {
pos = 0;
while ((pos = find_next_bit(val, 32, pos)) != 32) {
- generic_handle_irq(pp-msi_irq_start
- + (i * 32) + pos);
+ irq = irq_find_mapping(pp-irq_domain,
+ i * 32 + pos);
+ generic_handle_irq(irq);
pos++;
}
}
@@ -237,9 +238,8 @@ static int assign_irq(int no_irqs, struct msi_desc *desc,
int *pos)
}
}
- irq = (pp-msi_irq_start + pos0);
-
- if ((irq + no_irqs) (pp-msi_irq_start + MAX_MSI_IRQS-1))
+ irq = irq_find_mapping(pp-irq_domain, pos0);
+ if (!irq)
goto no_valid_irq;
i = 0;
@@ -270,6 +270,7 @@ static void clear_irq(unsigned int irq)
struct irq_desc *desc;
struct msi_desc *msi;
struct pcie_port *pp;
+ struct irq_data *data = irq_get_irq_data(irq);
/* get the port structure */
desc = irq_to_desc(irq);
@@ -280,7 +281,7 @@ static void clear_irq(unsigned int irq)
return;
}
- pos = irq - pp-msi_irq_start;
+ pos = data-hwirq;
irq_free_desc(irq);
@@ -371,8 +372,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
struct of_pci_range range;
struct of_pci_range_parser parser;
u32 val;
-
- struct irq_domain *irq_domain;
+ int i;
if (of_pci_range_parser_init(parser, np)) {
dev_err(pp-dev, missing ranges property\n);
@@ -441,15 +441,16 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
}
if (IS_ENABLED(CONFIG_PCI_MSI)) {
- irq_domain = irq_domain_add_linear(pp-dev-of_node,
+ pp-irq_domain = irq_domain_add_linear(pp-dev-of_node,
MAX_MSI_IRQS, msi_domain_ops,
dw_pcie_msi_chip);
- if (!irq_domain) {
+ if (!pp-irq_domain) {
dev_err(pp-dev, irq domain init failed\n);
return -ENXIO;
}
- pp-msi_irq_start = irq_find_mapping(irq_domain, 0);
+ for (i = 0; i MAX_MSI_IRQS; i++)
+ irq_create_mapping(pp-irq_domain, i);
}
if (pp-ops-host_init)
diff --git a/drivers/pci/host/pcie-designware.h
b/drivers/pci/host/pcie-designware.h
index faccbbf..1bf9fc5 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -47,7 +47,7 @@ struct pcie_port {
u32 lanes;
struct pcie_host_ops*ops;
int msi_irq;
- int msi_irq_start;
+ struct irq_domain *irq_domain;
unsigned long msi_data;
DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
};
--
1.7.10.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] spi/s3c64xx: Use prepare_message() and unprepare_message()
From: Mark Brown broo...@linaro.org
This is of very little value in itself but will be useful once the loop
iterating over the transfers is also factored out into the core.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/spi/spi-s3c64xx.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 8e732a1..c7b36c0 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -849,16 +849,12 @@ static void s3c64xx_spi_unmap_mssg(struct
s3c64xx_spi_driver_data *sdd,
}
}
-static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
- struct spi_message *msg)
+static int s3c64xx_spi_prepare_message(struct spi_master *master,
+ struct spi_message *msg)
{
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct spi_device *spi = msg-spi;
struct s3c64xx_spi_csinfo *cs = spi-controller_data;
- struct spi_transfer *xfer;
- int status = 0, cs_toggle = 0;
- u32 speed;
- u8 bpw;
/* If Master's(controller) state differs from that needed by Slave */
if (sdd-cur_speed != spi-max_speed_hz
@@ -874,13 +870,25 @@ static int s3c64xx_spi_transfer_one_message(struct
spi_master *master,
if (s3c64xx_spi_map_mssg(sdd, msg)) {
dev_err(spi-dev,
Xfer: Unable to map message buffers!\n);
- status = -ENOMEM;
- goto out;
+ return -ENOMEM;
}
/* Configure feedback delay */
writel(cs-fb_delay 0x3, sdd-regs + S3C64XX_SPI_FB_CLK);
+ return 0;
+}
+
+static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
+ struct spi_message *msg)
+{
+ struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
+ struct spi_device *spi = msg-spi;
+ struct spi_transfer *xfer;
+ int status = 0, cs_toggle = 0;
+ u32 speed;
+ u8 bpw;
+
list_for_each_entry(xfer, msg-transfers, transfer_list) {
unsigned long flags;
@@ -988,6 +996,16 @@ out:
return 0;
}
+static int s3c64xx_spi_unprepare_message(struct spi_master *master,
+ struct spi_message *msg)
+{
+ struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
+
+ s3c64xx_spi_unmap_mssg(sdd, msg);
+
+ return 0;
+}
+
static struct s3c64xx_spi_csinfo *s3c64xx_get_slave_ctrldata(
struct spi_device *spi)
{
@@ -1360,7 +1378,9 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
master-setup = s3c64xx_spi_setup;
master-cleanup = s3c64xx_spi_cleanup;
master-prepare_transfer_hardware = s3c64xx_spi_prepare_transfer;
+ master-prepare_message = s3c64xx_spi_prepare_message;
master-transfer_one_message = s3c64xx_spi_transfer_one_message;
+ master-unprepare_message = s3c64xx_spi_unprepare_message;
master-unprepare_transfer_hardware = s3c64xx_spi_unprepare_transfer;
master-num_chipselect = sci-num_cs;
master-dma_alignment = 8;
--
1.8.4.rc3
--
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] spi: Provide per-message prepare and unprepare operations
From: Mark Brown broo...@linaro.org
Many SPI drivers perform setup and tear down on every message, usually
doing things like DMA mapping the message. Provide hooks for them to use
to provide such operations.
This is of limited value for drivers that implement transfer_one_message()
but will be of much greater utility with future factoring out of standard
implementations of that function.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/spi/spi.c | 22 ++
include/linux/spi/spi.h | 11 +++
2 files changed, 33 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index b86ba60..253ea3b 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -606,6 +606,18 @@ static void spi_pump_messages(struct kthread_work *work)
trace_spi_message_start(master-cur_msg);
+ if (master-prepare_message) {
+ ret = master-prepare_message(master, master-cur_msg);
+ if (ret) {
+ dev_err(master-dev,
+ failed to prepare message: %d\n, ret);
+ master-cur_msg-status = ret;
+ spi_finalize_current_message(master);
+ return;
+ }
+ master-cur_msg_prepared = true;
+ }
+
ret = master-transfer_one_message(master, master-cur_msg);
if (ret) {
dev_err(master-dev,
@@ -687,6 +699,7 @@ void spi_finalize_current_message(struct spi_master *master)
{
struct spi_message *mesg;
unsigned long flags;
+ int ret;
spin_lock_irqsave(master-queue_lock, flags);
mesg = master-cur_msg;
@@ -695,6 +708,15 @@ void spi_finalize_current_message(struct spi_master
*master)
queue_kthread_work(master-kworker, master-pump_messages);
spin_unlock_irqrestore(master-queue_lock, flags);
+ if (master-cur_msg_prepared master-unprepare_message) {
+ ret = master-unprepare_message(master, mesg);
+ if (ret) {
+ dev_err(master-dev,
+ failed to unprepare message: %d\n, ret);
+ }
+ }
+ master-cur_msg_prepared = false;
+
mesg-state = NULL;
if (mesg-complete)
mesg-complete(mesg-context);
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index b329192..98620486 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -257,6 +257,8 @@ static inline void spi_unregister_driver(struct spi_driver
*sdrv)
* @queue_lock: spinlock to syncronise access to message queue
* @queue: message queue
* @cur_msg: the currently in-flight message
+ * @cur_msg_prepared: spi_prepare_message was called for the currently
+ *in-flight message
* @busy: message pump is busy
* @running: message pump is running
* @rt: whether this queue is set to run as a realtime task
@@ -274,6 +276,10 @@ static inline void spi_unregister_driver(struct spi_driver
*sdrv)
* @unprepare_transfer_hardware: there are currently no more messages on the
* queue so the subsystem notifies the driver that it may relax the
* hardware by issuing this call
+ * @prepare_message: set up the controller to transfer a single message,
+ * for example doing DMA mapping. Called from threaded
+ * context.
+ * @unprepare_message: undo any work done by prepare_message().
* @cs_gpios: Array of GPIOs to use as chip select lines; one per CS
* number. Any individual value may be -ENOENT for CS lines that
* are not GPIOs (driven by the SPI controller itself).
@@ -388,11 +394,16 @@ struct spi_master {
boolrunning;
boolrt;
boolauto_runtime_pm;
+ boolcur_msg_prepared;
int (*prepare_transfer_hardware)(struct spi_master *master);
int (*transfer_one_message)(struct spi_master *master,
struct spi_message *mesg);
int (*unprepare_transfer_hardware)(struct spi_master *master);
+ int (*prepare_message)(struct spi_master *master,
+ struct spi_message *message);
+ int (*unprepare_message)(struct spi_master *master,
+struct spi_message *message);
/* gpio chip select */
int *cs_gpios;
--
1.8.4.rc3
--
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] PM / devfreq: Remove duplicate include of opp.h
Currently, code include opp.h twice. Remove one inclusion of opp.h Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com --- :100644 100644 574b16b... 93c29f4... M drivers/devfreq/exynos/exynos5_bus.c drivers/devfreq/exynos/exynos5_bus.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/devfreq/exynos/exynos5_bus.c b/drivers/devfreq/exynos/exynos5_bus.c index 574b16b..93c29f4 100644 --- a/drivers/devfreq/exynos/exynos5_bus.c +++ b/drivers/devfreq/exynos/exynos5_bus.c @@ -18,7 +18,6 @@ #include linux/opp.h #include linux/slab.h #include linux/suspend.h -#include linux/opp.h #include linux/clk.h #include linux/delay.h #include linux/platform_device.h -- 1.7.10.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 3/5] drm/bridge: Add PTN3460 bridge driver
On Fri, Oct 04, 2013 at 11:05:48AM +0900, Inki Dae wrote: 2013/10/4 Olof Johansson o...@lixom.net: If PD_N is LOW, then the device is in Deep power-down completely, even if supply rail is ON; for the device to be able to operate, the PD_N pin must be HIGH. I still think the pin could be replaced with a regulator. But lvds-bridge node has powerdown-gpio property - it say this board will use gpio pin - specific to board. So it seems no problem. No, don't model things that aren't regulators as regulators - it's just confusing from a usability standpoint and causes breakage when the pins don't behave like regulators. signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: Update arch timer node with clock frequency
On Wed, Oct 9, 2013 at 1:25 AM, Mark Rutland mark.rutl...@arm.com wrote: On Tue, Oct 08, 2013 at 11:15:47PM +0100, Olof Johansson wrote: [Adding Tony, who reported a mainline booting issue, and Sean who helped me track this down] On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland mark.rutl...@arm.com wrote: On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: Hi Yuvaraj, On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: Without the clock-frequency property in arch timer node, could able to see the below crash dump. [snip] diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -96,6 +96,7 @@ 1 14 0xf08, 1 11 0xf08, 1 10 0xf08; + clock-frequency = 2400; Shouldn't it rather come from some clock provided by some clock controller instead? The frequency would be then retrieved using clk_get_rate() on a clock received by clk_get(), specified in device tree using generic clock bindings. If the bootloader has initialised the generic timer correctly, the CNTFRQ register should contain the clock frequency, independent of any external clock. So, we just sat here to bisect a problem on the Samsung Chromebook where we hit exactly this problem. The read-only firmware on the device does not set CNTFRQ at boot, so this fails. Ouch. That's a shame. A chained bootloader (like the KVM guys are using) should be able to set CNTFRQ, so as long as any chained loader actually does that this won't cause that to blow up... Yes, but we have cases where we want to be able to boot without a chained u-boot as well. Apparantly the u-boot that comes with Arndale sets it, so I haven't seen this error on that platform. Having the bootloader set CNTFRQ is by far the preferable solution, it is architected for this purpose. Unfortunately there is now real hardware out there that needs this due to firmware bugs / missing features, so there's little other choice. :( Indeed :( I'll pick this patch up in the fixes branch for 3.12, unless someone complains loudly. Could you please add a note to the dts regarding why we actually need this? It would be nice to maintain the impression that this is not the preferred way of doing things... s/dts/dtsi/, yes I can do that. Hopefully with that we won't get too much automated copy and paste to other platforms. It looks like current upstream u-boot got the timer enablement patches merged together with HYP support, which explains why I didn't see this on Arndale since it has a forked version of u-boot from Linaro somewhere. -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: [PATCH 1/3] dmaengine: pl330: Set residue in tx_status callback.
On Sun, Oct 6, 2013 at 8:48 PM, Vinod Koul vinod.k...@intel.com wrote: On Mon, Oct 07, 2013 at 10:39:34AM +0900, Chanho Park wrote: Why didn't you use a cookie value to track the request? The cookie is assigned when each transfer is submitted. If you save the value in the desc, we can find the request easily. If there are several cyclic desc in the work list, is there a better way to find the current one? The chan struct tracks the last completed and last submitted cookies, but these will be the first and last respectively as long as the cyclic transfer is active. Is there an active cookie stored somewhere that I missed? Assume there are three cookies. If you want to get the second cookie not latest cookie, your way can be also correct in such case? I think tx_status API is to get dma status of the given cookie. You are only considering a cyclic case. For cyclic case you would have possible same descriptor running till you terminate. The cyclic case that makes this interesting is when there are multiple cyclic descriptors in the list. The cookie and completed_cookie markers don't help to determine which of the descriptors in the list is currently active. dma_cookie_complete isn't called for a cyclic desc, the desc is just pushed to the end of the list. For non cyclic, if you have 3 descriptors submitted, the cookie value can be, say 7, 8 and 9. If you query the status of any descriptor and pass the last optional txstate arg then you will know the last cookie completed. so if txstate-last is 7, then 7th was completed and 8 should be running and 9 in queue! Got it, but the correct desc for cookie 8 will still have to be searched for, correct? Thanks for the advise. Dylan Looking for the first buffer with status == BUSY is an improvement I'll make. Any way to avoid looking through the list? Its already there :) -- ~Vinod -- 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: dts: Update arch timer node with clock frequency
On Tue, Oct 8, 2013 at 5:15 PM, Olof Johansson o...@lixom.net wrote: [Adding Tony, who reported a mainline booting issue, and Sean who helped me track this down] On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland mark.rutl...@arm.com wrote: On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: Hi Yuvaraj, On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: Without the clock-frequency property in arch timer node, could able to see the below crash dump. [snip] diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -96,6 +96,7 @@ 1 14 0xf08, 1 11 0xf08, 1 10 0xf08; + clock-frequency = 2400; Shouldn't it rather come from some clock provided by some clock controller instead? The frequency would be then retrieved using clk_get_rate() on a clock received by clk_get(), specified in device tree using generic clock bindings. If the bootloader has initialised the generic timer correctly, the CNTFRQ register should contain the clock frequency, independent of any external clock. So, we just sat here to bisect a problem on the Samsung Chromebook where we hit exactly this problem. The read-only firmware on the device does not set CNTFRQ at boot, so this fails. Apparantly the u-boot that comes with Arndale sets it, so I haven't seen this error on that platform. Having the bootloader set CNTFRQ is by far the preferable solution, it is architected for this purpose. Unfortunately there is now real hardware out there that needs this due to firmware bugs / missing features, so there's little other choice. :( I'll pick this patch up in the fixes branch for 3.12, unless someone complains loudly. Perhaps the subject should say something about this only applying to exynos. Rob -- 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: dts: Update arch timer node with clock frequency
On Wed, Oct 09, 2013 at 08:46:06PM +0100, Olof Johansson wrote: On Wed, Oct 9, 2013 at 1:25 AM, Mark Rutland mark.rutl...@arm.com wrote: On Tue, Oct 08, 2013 at 11:15:47PM +0100, Olof Johansson wrote: [Adding Tony, who reported a mainline booting issue, and Sean who helped me track this down] On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland mark.rutl...@arm.com wrote: On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: Hi Yuvaraj, On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: Without the clock-frequency property in arch timer node, could able to see the below crash dump. [snip] diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -96,6 +96,7 @@ 1 14 0xf08, 1 11 0xf08, 1 10 0xf08; + clock-frequency = 2400; Shouldn't it rather come from some clock provided by some clock controller instead? The frequency would be then retrieved using clk_get_rate() on a clock received by clk_get(), specified in device tree using generic clock bindings. If the bootloader has initialised the generic timer correctly, the CNTFRQ register should contain the clock frequency, independent of any external clock. So, we just sat here to bisect a problem on the Samsung Chromebook where we hit exactly this problem. The read-only firmware on the device does not set CNTFRQ at boot, so this fails. Ouch. That's a shame. A chained bootloader (like the KVM guys are using) should be able to set CNTFRQ, so as long as any chained loader actually does that this won't cause that to blow up... Yes, but we have cases where we want to be able to boot without a chained u-boot as well. Sorry, that was poorly worded on my behalf. I meant that in the main case I'm aware of where the having the clock-frequency property wasn't good enough (because it doesn't get propagated to guests), we have another workaround. Apparantly the u-boot that comes with Arndale sets it, so I haven't seen this error on that platform. Having the bootloader set CNTFRQ is by far the preferable solution, it is architected for this purpose. Unfortunately there is now real hardware out there that needs this due to firmware bugs / missing features, so there's little other choice. :( Indeed :( I'll pick this patch up in the fixes branch for 3.12, unless someone complains loudly. Could you please add a note to the dts regarding why we actually need this? It would be nice to maintain the impression that this is not the preferred way of doing things... s/dts/dtsi/, yes I can do that. Hopefully with that we won't get too much automated copy and paste to other platforms. Cheers! Thanks, Mark. -- 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
Уборка Квартиры и дома. Сухая и влажная. Качественно.
Мы умеем подсобить с уборкой апартаментов или Квартиры за небольшие деньги http://74.ru/go/?url=http://m00.me/qpzd -- 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/3] ARM: dts: exynos4212: Add PMU dt data for pmu-irq
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4212.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 6f34d7f..3081bae 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -56,4 +56,10 @@
0x5 0 gic 1 12 0;
};
};
+
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupt-parent = combiner;
+ interrupts = 2 2, 3 2;
+ };
};
--
1.8.0
--
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 0/3] ARM: dts: exynos: Add missing dt data to bring up kernel feature
This patchset add missing dt data to bring up kernel feature - MAUDIO/GPS_ALIVE power domain - PMU - Clock data for Multi core timer Chanwoo Choi (2): ARM: dts: exynos4212: Add PMU dt data for pmu-irq ARM: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12 Marek Szyprowski (1): ARM: dts: exynos4212: Add missing clock for multi core timer arch/arm/boot/dts/exynos4212.dtsi | 8 arch/arm/boot/dts/exynos4x12.dtsi | 10 ++ 2 files changed, 18 insertions(+) -- 1.8.0 -- 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/3] ARM: dts: exynos4212: Add missing clock for multi core timer
From: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4212.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 3081bae..d7a3fbc 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -43,6 +43,8 @@
interrupt-parent = mct_map;
interrupts = 0 0, 1 0, 2 0, 3 0,
4 0, 5 0;
+ clocks = clock 3, clock 344;
+ clock-names = fin_pll, mct;
mct_map: mct-map {
#interrupt-cells = 2;
--
1.8.0
--
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 3/3] ARM: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12
This patch maudio/gps_alive power domain to exynos4x12.dtsi.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index ad531fe..c04418e 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -35,6 +35,16 @@
reg = 0x10023CA0 0x20;
};
+ pd_maudio: maudio-power-domain@10023CC0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023CC0 0x20;
+ };
+
+ pd_gps_alive: gps-alive-power-domain@10023D04 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023D00 0x20;
+ };
+
clock: clock-controller@1003 {
compatible = samsung,exynos4412-clock;
reg = 0x1003 0x2;
--
1.8.0
--
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: Remove unused s5p_device_ehci
Since commit ca91435 ARM: EXYNOS: Remove unused board files,
s5p_device_ehci is not used anymore. Thus, s5p_device_ehci can
be removed. Also, unnecessary S5P_DEV_USB_EHCI option is removed.
Signed-off-by: Jingoo Han jg1@samsung.com
---
arch/arm/plat-samsung/Kconfig |5 -
arch/arm/plat-samsung/devs.c | 34 -
arch/arm/plat-samsung/include/plat/devs.h |1 -
3 files changed, 40 deletions(-)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 7dfba93..99bfbb3 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -382,11 +382,6 @@ config S5P_DEV_TV
help
Compile in platform device definition for TV interface
-config S5P_DEV_USB_EHCI
- bool
- help
- Compile in platform device definition for USB EHCI
-
config S3C24XX_PWM
bool PWM device support
select PWM
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 8ce0ac0..25f40c9 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -49,7 +49,6 @@
#include plat/devs.h
#include plat/adc.h
#include linux/platform_data/ata-samsung_cf.h
-#include linux/platform_data/usb-ehci-s5p.h
#include plat/fb.h
#include plat/fb-s3c2410.h
#include plat/hdmi.h
@@ -1359,39 +1358,6 @@ void __init s3c24xx_udc_set_platdata(struct
s3c2410_udc_mach_info *pd)
}
#endif /* CONFIG_PLAT_S3C24XX */
-/* USB EHCI Host Controller */
-
-#ifdef CONFIG_S5P_DEV_USB_EHCI
-static struct resource s5p_ehci_resource[] = {
- [0] = DEFINE_RES_MEM(S5P_PA_EHCI, SZ_256),
- [1] = DEFINE_RES_IRQ(IRQ_USB_HOST),
-};
-
-struct platform_device s5p_device_ehci = {
- .name = s5p-ehci,
- .id = -1,
- .num_resources = ARRAY_SIZE(s5p_ehci_resource),
- .resource = s5p_ehci_resource,
- .dev= {
- .dma_mask = samsung_device_dma_mask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- }
-};
-
-void __init s5p_ehci_set_platdata(struct s5p_ehci_platdata *pd)
-{
- struct s5p_ehci_platdata *npd;
-
- npd = s3c_set_platdata(pd, sizeof(struct s5p_ehci_platdata),
- s5p_device_ehci);
-
- if (!npd-phy_init)
- npd-phy_init = s5p_usb_phy_init;
- if (!npd-phy_exit)
- npd-phy_exit = s5p_usb_phy_exit;
-}
-#endif /* CONFIG_S5P_DEV_USB_EHCI */
-
/* USB HSOTG */
#ifdef CONFIG_S3C_DEV_USB_HSOTG
diff --git a/arch/arm/plat-samsung/include/plat/devs.h
b/arch/arm/plat-samsung/include/plat/devs.h
index 0dc4ac4..eece188 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -75,7 +75,6 @@ extern struct platform_device s3c_device_usb_hsotg;
extern struct platform_device s3c_device_usb_hsudc;
extern struct platform_device s3c_device_wdt;
-extern struct platform_device s5p_device_ehci;
extern struct platform_device s5p_device_fimc0;
extern struct platform_device s5p_device_fimc1;
extern struct platform_device s5p_device_fimc2;
--
1.7.10.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] ARM: SAMSUNG: Remove unused s5p_device_ehci
Hi, On 10/10/2013 11:02 AM, Jingoo Han wrote: Since commit ca91435 ARM: EXYNOS: Remove unused board files, s5p_device_ehci is not used anymore. Thus, s5p_device_ehci can be removed. Also, unnecessary S5P_DEV_USB_EHCI option is removed. Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c index 8ce0ac0..25f40c9 100644 --- a/arch/arm/plat-samsung/devs.c +++ b/arch/arm/plat-samsung/devs.c @@ -49,7 +49,6 @@ #include plat/devs.h #include plat/adc.h #include linux/platform_data/ata-samsung_cf.h -#include linux/platform_data/usb-ehci-s5p.h Are you planning to remove also this file altogether ? Probably the s5p-ehci driver could be cleaned up then and the platform_data handling dropped from it as a follow up. Thanks, Sylwester -- 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: SAMSUNG: Remove unused s5p_device_ehci
On Thursday, October 10, 2013 11:26 AM, Sylwester Nawrocki wrote: On 10/10/2013 11:02 AM, Jingoo Han wrote: Since commit ca91435 ARM: EXYNOS: Remove unused board files, s5p_device_ehci is not used anymore. Thus, s5p_device_ehci can be removed. Also, unnecessary S5P_DEV_USB_EHCI option is removed. Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c index 8ce0ac0..25f40c9 100644 --- a/arch/arm/plat-samsung/devs.c +++ b/arch/arm/plat-samsung/devs.c @@ -49,7 +49,6 @@ #include plat/devs.h #include plat/adc.h #include linux/platform_data/ata-samsung_cf.h -#include linux/platform_data/usb-ehci-s5p.h Are you planning to remove also this file altogether ? Probably the s5p-ehci driver could be cleaned up then and the platform_data handling dropped from it as a follow up. Hi Sylwester Nawrocki, I will rename s5p-ehci to s5p-exynos, then drop platform_data handling from it. These will be separate patches. Thank you your comment. :-) Best regards, Jingoo Han -- 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: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12
On 10 October 2013 06:00, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch maudio/gps_alive power domain to exynos4x12.dtsi.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index ad531fe..c04418e 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -35,6 +35,16 @@
reg = 0x10023CA0 0x20;
};
+ pd_maudio: maudio-power-domain@10023CC0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023CC0 0x20;
+ };
+
+ pd_gps_alive: gps-alive-power-domain@10023D04 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023D00 0x20;
There is mismatch between node name and register value.
--
With warm regards,
Sachin
--
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: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12
On 10/10/2013 12:29 PM, Sachin Kamat wrote:
On 10 October 2013 06:00, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch maudio/gps_alive power domain to exynos4x12.dtsi.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index ad531fe..c04418e 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -35,6 +35,16 @@
reg = 0x10023CA0 0x20;
};
+ pd_maudio: maudio-power-domain@10023CC0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023CC0 0x20;
+ };
+
+ pd_gps_alive: gps-alive-power-domain@10023D04 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023D00 0x20;
There is mismatch between node name and register value.
What is exactly mismatch?
I checked the register address of MAUDIO_CONFIGURATION/GPS_ALIVE_CONFIGURATION
regsiter.
- MAUDIO_CONFIGURATION 0x1002_3CC0
- GPS_ALIVE_CONFIGURATION 0x1002_3D00
--
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: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12
On 10/10/2013 01:05 PM, Chanwoo Choi wrote:
On 10/10/2013 12:29 PM, Sachin Kamat wrote:
On 10 October 2013 06:00, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch maudio/gps_alive power domain to exynos4x12.dtsi.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index ad531fe..c04418e 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -35,6 +35,16 @@
reg = 0x10023CA0 0x20;
};
+ pd_maudio: maudio-power-domain@10023CC0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023CC0 0x20;
+ };
+
+ pd_gps_alive: gps-alive-power-domain@10023D04 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023D00 0x20;
There is mismatch between node name and register value.
What is exactly mismatch?
I checked the register address of
MAUDIO_CONFIGURATION/GPS_ALIVE_CONFIGURATION regsiter.
- MAUDIO_CONFIGURATION 0x1002_3CC0
- GPS_ALIVE_CONFIGURATION 0x1002_3D00
My mistake. I write wrong address about gps-alive-power-domain.
I will fix it.
- gps-alive-power-domain@10023D04 - gps-alive-power-domain@10023D00
Thanks,
Chanwoo Choi
--
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/5] drm/bridge: Add PTN3460 bridge driver
-Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Thursday, October 10, 2013 3:29 AM To: Inki Dae Cc: Olof Johansson; Sean Paul; devicet...@vger.kernel.org; linux-samsung- s...@vger.kernel.org; linux-...@vger.kernel.org; linux- ker...@vger.kernel.org; DRI mailing list; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver On Fri, Oct 04, 2013 at 11:05:48AM +0900, Inki Dae wrote: 2013/10/4 Olof Johansson o...@lixom.net: If PD_N is LOW, then the device is in Deep power-down completely, even if supply rail is ON; for the device to be able to operate, the PD_N pin must be HIGH. I still think the pin could be replaced with a regulator. But lvds-bridge node has powerdown-gpio property - it say this board will use gpio pin - specific to board. So it seems no problem. No, don't model things that aren't regulators as regulators - it's just confusing from a usability standpoint and causes breakage when the pins don't behave like regulators. It seems that there was your missing point. That _is not_ what I mentioned. I mean that other boards can use a regulator instead of gpio pin. -- 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: SAMSUNG: Remove unused s5p_device_ehci
Hi Jingoo, On Thursday 10 of October 2013 11:40:22 Jingoo Han wrote: On Thursday, October 10, 2013 11:26 AM, Sylwester Nawrocki wrote: On 10/10/2013 11:02 AM, Jingoo Han wrote: Since commit ca91435 ARM: EXYNOS: Remove unused board files, s5p_device_ehci is not used anymore. Thus, s5p_device_ehci can be removed. Also, unnecessary S5P_DEV_USB_EHCI option is removed. Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c index 8ce0ac0..25f40c9 100644 --- a/arch/arm/plat-samsung/devs.c +++ b/arch/arm/plat-samsung/devs.c @@ -49,7 +49,6 @@ #include plat/devs.h #include plat/adc.h #include linux/platform_data/ata-samsung_cf.h -#include linux/platform_data/usb-ehci-s5p.h Are you planning to remove also this file altogether ? Probably the s5p-ehci driver could be cleaned up then and the platform_data handling dropped from it as a follow up. Hi Sylwester Nawrocki, I will rename s5p-ehci to s5p-exynos, then drop platform_data handling from it. These will be separate patches. Thank you your comment. :-) I'd recommend keeping driver name as is. S5PV210 is going to receive DT support soon and it will be also able to use this driver. Otherwise this looks fine. Best regards, Tomasz -- 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
[RESEND] [PATCH] ARM: dts: exynos5: add pwm DT nodes to Exynos5250 and Exynos5420
Add the device-tree binding for the PWM controller to Exynos5250 and Exynos5420
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Olof Johansson ol...@chromium.org
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |9 +
arch/arm/boot/dts/exynos5420.dtsi |9 +
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 864ae90..99abc72 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -521,6 +521,15 @@
};
};
+ pwm: pwm@12dd {
+ compatible = samsung,exynos4210-pwm;
+ reg = 0x12dd 0x100;
+ samsung,pwm-outputs = 0, 1, 2, 3;
+ #pwm-cells = 3;
+ clocks = clock 311;
+ clock-names = timers;
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index d537cd7..80afc8b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -206,6 +206,15 @@
clock-names = uart, clk_uart_baud0;
};
+ pwm: pwm@12dd {
+ compatible = samsung,exynos4210-pwm;
+ reg = 0x12dd 0x100;
+ samsung,pwm-outputs = 0, 1, 2, 3;
+ #pwm-cells = 3;
+ clocks = clock 279;
+ clock-names = timers;
+ };
+
dp_phy: video-phy@10040728 {
compatible = samsung,exynos5250-dp-video-phy;
reg = 0x10040728 4;
--
1.7.10.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] clk: samsung: Fix PLL35XX lock time
Hi Arun, On Wednesday 09 of October 2013 09:21:43 Arun Kumar K wrote: Hi Doug, On Tue, Oct 8, 2013 at 9:39 PM, Doug Anderson diand...@chromium.org wrote: Arun, On Mon, Oct 7, 2013 at 11:56 PM, Arun Kumar K arun...@samsung.com wrote: PLL35XX lock factor is 250 as per the manual whereas its wrongly set as 270 now. Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/clk/samsung/clk-pll.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) I don't think this is right. I believe that it needs to be passed in by the SoC. On exynos5250 I see 250 in both the manual and in our code. On exynos5420 manual I actually see 200 now. I'm not actually sure where the 270 came from, now that I search for it. The manual I referred gives 250 for both 5250 and 5420 and thats why I concluded on this fix. I will check other versions of the manual to see if the value is changing. 270 is the value taken from Exynos 4412 User's Manual rev. 1.1. I believe we don't have to extend this to support per SoC value, because it should be always safe to take the value of SoC that requires the longest locking period. The differences are small enough to be insignificant, so there should be no practical performance penalty. Best regards, Tomasz -- 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: SAMSUNG: Remove unused s5p_device_ehci
On Thursday, October 10, 2013 2:18 PM, Tomasz Figa wrote: On Thursday 10 of October 2013 11:40:22 Jingoo Han wrote: On Thursday, October 10, 2013 11:26 AM, Sylwester Nawrocki wrote: [] Are you planning to remove also this file altogether ? Probably the s5p-ehci driver could be cleaned up then and the platform_data handling dropped from it as a follow up. Hi Sylwester Nawrocki, I will rename s5p-ehci to s5p-exynos, then drop platform_data handling from it. These will be separate patches. Thank you your comment. :-) I'd recommend keeping driver name as is. S5PV210 is going to receive DT support soon and it will be also able to use this driver. Hi Tomasz Figa, Now, Exynos EHCI and OHCI driver's name is different as below: ehci-s5p.c ohci-exynos.c I want to use same name. There is no reason to keep the different names. Also I want to use '-exynos.c' even though S5PV210 can support EHCI and OHCI. ehci-exynos.c ohci-exynos.c Then, do you want to use the following names? ehci-s5p.c ohci-s5p.c Best regards, Jingoo Han -- 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
LOAN OFFER
We are European Loan service,Do you need a Loan,contact Via (europanl...@foxmail.com) This message was sent using IMP, the Internet Messaging Program. -- 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
[PATCHv2 0/3] ARM: dts: exynos: Add missing dt data to bring up kernel feature
This patchset add missing dt data to bring up kernel feature - MAUDIO/GPS_ALIVE power domain - PMU - Clock data for Multi core timer Changes since v1: - Fix wrong address of GPS_ALIVE power domain Chanwoo Choi (2): ARM: dts: exynos4212: Add PMU dt data for pmu-irq ARM: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12 Marek Szyprowski (1): ARM: dts: exynos4212: Add missing clock for multi core timer arch/arm/boot/dts/exynos4212.dtsi | 8 arch/arm/boot/dts/exynos4x12.dtsi | 10 ++ 2 files changed, 18 insertions(+) -- 1.8.0 -- 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
[PATCHv2 2/3] ARM: dts: exynos4212: Add missing clock for multi core timer
From: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v1:
- No change
arch/arm/boot/dts/exynos4212.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 3081bae..d7a3fbc 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -43,6 +43,8 @@
interrupt-parent = mct_map;
interrupts = 0 0, 1 0, 2 0, 3 0,
4 0, 5 0;
+ clocks = clock 3, clock 344;
+ clock-names = fin_pll, mct;
mct_map: mct-map {
#interrupt-cells = 2;
--
1.8.0
--
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
[PATCHv2 1/3] ARM: dts: exynos4212: Add PMU dt data for pmu-irq
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v1:
- No change
arch/arm/boot/dts/exynos4212.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 6f34d7f..3081bae 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -56,4 +56,10 @@
0x5 0 gic 1 12 0;
};
};
+
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupt-parent = combiner;
+ interrupts = 2 2, 3 2;
+ };
};
--
1.8.0
--
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
[PATCHv2 3/3] ARM: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12
This patch maudio/gps_alive power domain to exynos4x12.dtsi.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v1:
- Fix GPS_ALIVE power domain's register address
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index ad531fe..d265047 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -35,6 +35,16 @@
reg = 0x10023CA0 0x20;
};
+ pd_maudio: maudio-power-domain@10023CC0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023CC0 0x20;
+ };
+
+ pd_gps_alive: gps-alive-power-domain@10023D00 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023D00 0x20;
+ };
+
clock: clock-controller@1003 {
compatible = samsung,exynos4412-clock;
reg = 0x1003 0x2;
--
1.8.0
--
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: [RESEND] [PATCH] ARM: dts: exynos5: add pwm DT nodes to Exynos5250 and Exynos5420
Hi Leela,
On 10 October 2013 11:12, Leela Krishna Amudala l.kris...@samsung.com wrote:
Add the device-tree binding for the PWM controller to Exynos5250 and
Exynos5420
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Olof Johansson ol...@chromium.org
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |9 +
arch/arm/boot/dts/exynos5420.dtsi |9 +
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 864ae90..99abc72 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -521,6 +521,15 @@
};
};
+ pwm: pwm@12dd {
+ compatible = samsung,exynos4210-pwm;
+ reg = 0x12dd 0x100;
+ samsung,pwm-outputs = 0, 1, 2, 3;
+ #pwm-cells = 3;
+ clocks = clock 311;
+ clock-names = timers;
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index d537cd7..80afc8b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -206,6 +206,15 @@
clock-names = uart, clk_uart_baud0;
};
+ pwm: pwm@12dd {
+ compatible = samsung,exynos4210-pwm;
+ reg = 0x12dd 0x100;
+ samsung,pwm-outputs = 0, 1, 2, 3;
+ #pwm-cells = 3;
+ clocks = clock 279;
+ clock-names = timers;
+ };
+
Looking at the properties in the above 2 nodes, can't we have the
common ones defined in exynos5.dtsi?
--
With warm regards,
Sachin
--
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
