[PATCH v11 4/4] ARM: dts: Exynos5420: Add device nodes for TMU blocks
Exynos5420 SoC has per core thermal management unit.
5 TMU channels 4 for CPUs and 5th for GPU.
This patch adds the device tree nodes to the DT device list.
Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Andrew Bresticker
---
Changes since previous version:
1. used lables instead of comment lines
2. pass the same clock as trimfo_apbif clock for TMU channel 2
arch/arm/boot/dts/exynos5420.dtsi | 40 +
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index b1fa334..c62cde6 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -402,4 +402,44 @@
clock-names = "gscl";
samsung,power-domain = <&gsc_pd>;
};
+
+ tmu_cpu0:tmu@1006 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x1006 0x100>;
+ interrupts = <0 65 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ tmu_cpu1:tmu@10064000 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x10064000 0x100>;
+ interrupts = <0 183 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ tmu_cpu2:tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = <&clock 318>, <&clock 318>;
+ clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+ };
+
+ tmu_cpu3:tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = <&clock 318>, <&clock 319>;
+ clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+ };
+
+ tmu_gpu:tmu@100a {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = <&clock 319>, <&clock 318>;
+ clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+ };
};
--
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 1/1] ARM: exynos_defconfig: Enable S2MPS11 voltage regulator
S2MPS11 voltage regulator is commonly used on the latest Exynos boards like SMDK5420, Arndale-Octa, etc. Hence it makes sense to enable it like S5M8767A voltage regulator. Signed-off-by: Sachin Kamat --- arch/arm/configs/exynos_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index aec8a3ea1436..dbe1f1c47bb0 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -79,6 +79,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_MAX8997=y CONFIG_REGULATOR_MAX77686=y +CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS65090=y CONFIG_FB=y -- 1.7.9.5 -- 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 v11 3/4] thermal: samsung: Add TMU support for Exynos5420 SoCs
Exynos5420 has 5 TMU channels, 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
This patch
1 Adds the neccessary register changes and arch information
to support Exynos5420 SoCs.
2. Handles the gate clock for misplaced TRIMINFO register
3. Updates the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Andrew Bresticker
Acked-by: Amit Daniel Kachhap
Reviewed-by: Bartlomiej Zolnierkiewicz
---
Changes since v10:
1. using renamed compatible "samsung,exynos5420-tmu-ext-triminfo"
and passing same clock as triminfo_apbif clock for channel 2
2. removed the "exynos5420-tmu-triminfo-clk" compatible
.../devicetree/bindings/thermal/exynos-thermal.txt | 38
drivers/thermal/samsung/exynos_tmu.c | 52 +-
drivers/thermal/samsung/exynos_tmu.h |1 +
drivers/thermal/samsung/exynos_tmu_data.c | 99
drivers/thermal/samsung/exynos_tmu_data.h |8 ++
5 files changed, 194 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index a1aa602..a3e78c0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,9 @@
"samsung,exynos4412-tmu"
"samsung,exynos4210-tmu"
"samsung,exynos5250-tmu"
+ "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
+ "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
+ Exynos5420 (Must pass triminfo base and triminfo clock)
"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 +16,16 @@
interrupt related then 2 set of register has to supplied. First set
belongs to register set of TMU instance and second set belongs to
registers shared with the TMU instance.
+
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+ Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a misplaced
+ register, also provide clock to access that base.
+
+ 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
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +56,31 @@ Example 2):
clock-names = "tmu_apbif";
};
+Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
+ tmu_cpu2: tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = <&clock 318>, <&clock 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
+ tmu_cpu3: tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = <&clock 318>, <&clock 319>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
+ tmu_gpu: tmu@100a {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = <&clock 319>, <&clock 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_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 bbd0fc3..6f40c91 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -47,6 +47,7 @@
* @irq_work: pointer to the irq work structure.
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
+ * @clk_sec: pointer to the clock structure for accessing the base_second.
* @temp_error1: fused value of the first point trim.
* @temp_error2: fused value of the second point trim.
* @regulator: pointer to the TMU regulator structure.
@@ -61,7 +62,7 @@ struct exynos_tmu_data {
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
- struct clk *clk;
+ struct clk *clk, *clk_sec;
u8 temp_error1, tem
[PATCH v11 2/4] 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
Acked-by: Amit Daniel Kachhap
Reviewed-by: Bartlomiej Zolnierkiewicz
---
Changes since v10:
Documentation rephrased as per comments from Tomasz Figa
.../devicetree/bindings/thermal/exynos-thermal.txt |4 ++--
drivers/thermal/samsung/exynos_tmu.c | 14 +++---
drivers/thermal/samsung/exynos_tmu.h |4 ++--
drivers/thermal/samsung/exynos_tmu_data.c|2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..a1aa602 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 register set of TMU instance and second set belongs to
+ registers shared with the TMU instance.
- 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 c493245..bbd0fc3 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);
@@ -454,7 +454,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;
}
@@ -579,7 +579,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)) {
@@ -587,9 +587,9 @@ 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) {
+ if (!data->base_second) {
dev_err(&pdev->dev, "Failed to ioremap memory\n");
return -ENOMEM;
}
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 980859a..0d6b32f 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -60,7 +60,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
*
[PATCH v11 1/4] thermal: samsung: replace inten_ bit fields with intclr_
This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
to configure intclr related registers.
Description of H/W:
The offset for the bits in the CLEAR register are not consistent across TMU
modules in Exynso5250, 5420 and 5440.
On Exynos5250, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT registers and at an offset of
12 in INTCLEAR register.
On Exynos5420, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT and INTCLEAR registers.
On Exynos5440,
the FALL_IRQEN bits are at an offset of 4
and the RISE_IRQEN bits are at an offset of 0
Signed-off-by: Naveen Krishna Chatradhi
Acked-by: Amit Daniel Kachhap
Reviewed-by: Bartlomiej Zolnierkiewicz
---
Changes since v10:
None
drivers/thermal/samsung/exynos_tmu.c |6 +++---
drivers/thermal/samsung/exynos_tmu.h | 16
drivers/thermal/samsung/exynos_tmu_data.c | 18 +-
drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 32f38b9..c493245 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -237,7 +237,7 @@ skip_calib_data:
writeb(pdata->trigger_levels[i], data->base +
reg->threshold_th0 + i * sizeof(reg->threshold_th0));
- writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
+ writel(reg->intclr_rise_mask, data->base + reg->tmu_intclear);
} else {
/* Write temperature code for rising and falling threshold */
for (i = 0;
@@ -264,8 +264,8 @@ skip_calib_data:
writel(falling_threshold,
data->base + reg->threshold_th1);
- writel((reg->inten_rise_mask << reg->inten_rise_shift) |
- (reg->inten_fall_mask << reg->inten_fall_shift),
+ writel((reg->intclr_rise_mask << reg->intclr_rise_shift) |
+ (reg->intclr_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 3fb6554..980859a 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -122,10 +122,6 @@ enum soc_type {
* @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
* @tmu_inten: register containing the different threshold interrupt
enable bits.
- * @inten_rise_shift: shift bits of all rising interrupt bits.
- * @inten_rise_mask: mask bits of all rising interrupt bits.
- * @inten_fall_shift: shift bits of all rising interrupt bits.
- * @inten_fall_mask: mask bits of all rising interrupt bits.
* @inten_rise0_shift: shift bits of rising 0 interrupt bits.
* @inten_rise1_shift: shift bits of rising 1 interrupt bits.
* @inten_rise2_shift: shift bits of rising 2 interrupt bits.
@@ -136,6 +132,10 @@ 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
+ * @intclr_rise_shift: shift bits of all rising interrupt bits.
+ * @intclr_rise_mask: mask bits of all rising interrupt bits.
+ * @intclr_fall_mask: mask bits of all rising interrupt bits.
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
@@ -191,10 +191,6 @@ struct exynos_tmu_registers {
u32 threshold_th3_l0_shift;
u32 tmu_inten;
- u32 inten_rise_shift;
- u32 inten_rise_mask;
- u32 inten_fall_shift;
- u32 inten_fall_mask;
u32 inten_rise0_shift;
u32 inten_rise1_shift;
u32 inten_rise2_shift;
@@ -207,6 +203,10 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
u32 tmu_intclear;
+ u32 intclr_fall_shift;
+ u32 intclr_rise_shift;
+ u32 intclr_fall_mask;
+ u32 intclr_rise_mask;
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 073c292..7cdb04e 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -40,13 +40,13 @@ static const struct exynos_tmu_registers
exynos4210_tmu_registers = {
[PATCH v11 0/4] thermal: samsung: Clean up and add support for Exynos5420
This patchset does a little clean up of the existing code (linux-soc-thermal) 1. [v11] thermal: samsung: replace inten_ bit fields with intclr_ 2. [v11] thermal: samsung: change base_common to more meaningful base_second adds support for Exynos5420 in the driver and (linux-soc-thermal) 3. [v11] thermal: samsung: Add TMU support for Exynos5420 SoCs also adds the device tree nodes for the same to exynos5420.dtsi (linux-samsung.git) 4. [v11] ARM: dts: Exynos5420: Add device nodes for TMU blocks (linux-soc-thermal) Naveen Krishna Chatradhi (3): thermal: samsung: replace inten_ bit fields with intclr_ thermal: samsung: change base_common to more meaningful base_second thermal: samsung: Add TMU support for Exynos5420 SoCs .../devicetree/bindings/thermal/exynos-thermal.txt | 42 ++- drivers/thermal/samsung/exynos_tmu.c | 72 +--- drivers/thermal/samsung/exynos_tmu.h | 21 ++-- drivers/thermal/samsung/exynos_tmu_data.c | 119 ++-- drivers/thermal/samsung/exynos_tmu_data.h | 12 +- 5 files changed, 228 insertions(+), 38 deletions(-) (linux-samsung.git) Naveen Krishna Chatradhi (1): ARM: dts: Exynos5420: Add device nodes for TMU blocks arch/arm/boot/dts/exynos5420.dtsi | 40 + 1 file changed, 40 insertions(+) -- 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 1/1] ARM: dts: Add PMIC support to arndale-octa
Added PMIC node to Arndale-Octa board.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 220 +
1 file changed, 220 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 7340745ff979..7d94d8d3b118 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5420.dtsi"
+#include
/ {
model = "Insignal Arndale Octa evaluation board based on EXYNOS5420";
@@ -63,4 +64,223 @@
bus-width = <4>;
};
};
+
+ hsi2c_4: i2c@12CA {
+ status = "okay";
+
+ s2mps11_pmic@66 {
+ compatible = "samsung,s2mps11-pmic";
+ reg = <0x66>;
+ s2mps11,buck2-ramp-delay = <12>;
+ s2mps11,buck34-ramp-delay = <12>;
+ s2mps11,buck16-ramp-delay = <12>;
+ s2mps11,buck6-ramp-enable = <1>;
+ s2mps11,buck2-ramp-enable = <1>;
+ s2mps11,buck3-ramp-enable = <1>;
+ s2mps11,buck4-ramp-enable = <1>;
+
+ interrupt-parent = <&gpx3>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+
+ s2mps11_osc: clocks {
+ #clock-cells = <1>;
+ clock-output-names = "s2mps11_ap",
+ "s2mps11_cp", "s2mps11_bt";
+ };
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "vdd_ldo1";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = "vdd_ldo3";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = "vdd_ldo5";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = "vdd_ldo6";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ regulator-always-on;
+ };
+
+ ldo7_reg: LDO7 {
+ regulator-name = "vdd_ldo7";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo8_reg: LDO8 {
+ regulator-name = "vdd_ldo8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo9_reg: LDO9 {
+ regulator-name = "vdd_ldo9";
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-always-on;
+ };
+
+ ldo10_reg: LDO10 {
+ regulator-name = "vdd_ldo10";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo11_reg: LDO11 {
+ regulator-name = "vdd_ldo11";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ regula
Re: [PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
Hi Alan, On Mon, Dec 9, 2013 at 8:54 PM, Alan Stern wrote: > On Mon, 9 Dec 2013, Vikas Sajjan wrote: > >> Does warm reset while activating SuperSpeed HUBs if the hub activate type >> is HUB_RESET_RESUME. >> >> When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend >> USB 3.0 device connected on 3.0 port, during resume I noticed that the >> XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE. >> This behaviour is inconsistent and the connection with connected USB 3.0 >> device >> on 3.0 port was LOST. >> >> Doing warm reset while activating SuperSpeed HUBs if the hub >> activate type is HUB_RESET_RESUME, gets the connected device to the stable >> state. >> >> Reviewed at https://chromium-review.googlesource.com/#/c/177132/ >> >> Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device >> (8564:1000) >> >> rebased on Greg Kroah-Hartman's usb-next >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git >> >> Signed-off-by: Vikas Sajjan >> --- >> drivers/usb/core/hub.c | 41 + >> 1 file changed, 25 insertions(+), 16 deletions(-) >> >> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c >> index a7c04e2..d8432b0 100644 >> --- a/drivers/usb/core/hub.c >> +++ b/drivers/usb/core/hub.c > >> @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum >> hub_activation_type type) >> u16 portstatus, portchange; >> >> portstatus = portchange = 0; >> + >> + /* Some connected devices might be still in unknown state even >> + * after reset-resume, a WARM_RESET gets the connected device >> + * to the normal state. >> + */ >> + if (udev && hub_is_superspeed(hub->hdev) && >> + type == HUB_RESET_RESUME) >> + hub_port_reset(hub, port1, NULL, >> + HUB_BH_RESET_TIME, true); > > Please don't do this all the time to every attached port. Do it only > when it is really needed. > > Shouldn't you pass udev as the third argument? If not, please explain > why not. yea, I have NOT tried passing udev as the third argument. > > Finally, I don't see why you put this in hub_activate(). Isn't it more > closely connected with the reset-resume procedure for the child device? I was trying to add a FIX in usb_port_resume(), but in our case we have CONFIG_USB_DEFAULT_PERSIST disabled. Interestingly, if I disable the CONFIG_USB_DEFAULT_PERSIST, then the function usb_port_resume() will never be called and transcend Jetflash device Suspend-to-RAM fails. In normal scenario (ie., CONFIG_USB_DEFAULT_PERSIST=y) the sequence is: === Step 1: For Root HUB : usb_resume_both() ---> usb_resume_device() -> generic_resume() --> hcd_bus_resume() --> xhci_bus_resume(). | |-->usb_resume_interface() ---> hub_reset_resume() --> xhci_update_hub_device() Step 2: For the Device connected usb_resume_both() ---> usb_resume_device() -> generic_resume()-->usb_port_resume()-->hub_port_logical_disconnect() --> hub_port_disable() --> hub_usb3_port_disable(). In our scenario (ie., CONFIG_USB_DEFAULT_PERSIST=N) the sequence is: === Step 1: For Root HUB usb_resume_both() ---> usb_resume_device() -> generic_resume() --> hcd_bus_resume() --> xhci_bus_resume(). | |-->usb_resume_interface() ---> hub_reset_resume() --> xhci_update_hub_device() Step 2 : Never occurs So Suspend-to-RAM fails. Hence i added a FIX in hub_reset_resume(). Let me know if I am wrong. > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
Hi Sarah,
On Mon, Dec 9, 2013 at 11:54 PM, Sarah Sharp
wrote:
> On Mon, Dec 09, 2013 at 10:24:52AM -0500, Alan Stern wrote:
>> On Mon, 9 Dec 2013, Vikas Sajjan wrote:
>>
>> > Does warm reset while activating SuperSpeed HUBs if the hub activate type
>> > is HUB_RESET_RESUME.
>> >
>> > When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash)
>> > transcend
>> > USB 3.0 device connected on 3.0 port, during resume I noticed that the
>> > XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE.
>> > This behaviour is inconsistent and the connection with connected USB 3.0
>> > device
>> > on 3.0 port was LOST.
>
> Does the device eventually re-connect on the USB port? Or is warm reset
> necessary to make the device connect?
Yes, warm reset was necesssary, without which the device was NOT reconnecting.
>
> Does the xHCI register restore complete after resume from S3, or is
> power lost? I'm trying to figure out whether xhci_reset is called
> before your issue is triggered.
The reason why I came up with this solution is during xhci_resume(),
it enters below condition and marks the reset_resume flag for the
ROOT_HUB as 1
/* If restore operation fails, re-initialize the HC during resume */
if ((temp & STS_SRE) || hibernated) {
/* Let the USB core know _both_ roothubs lost power. */
usb_root_hub_lost_power(xhci->main_hcd->self.root_hub);
usb_root_hub_lost_power(xhci->shared_hcd->self.root_hub);
>
>> > Doing warm reset while activating SuperSpeed HUBs if the hub
>> > activate type is HUB_RESET_RESUME, gets the connected device to the stable
>> > state.
>> >
>> > Reviewed at https://chromium-review.googlesource.com/#/c/177132/
>> >
>> > Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device
>> > (8564:1000)
>
> Is this issue specific to the particular USB device manufacturer
> (Transcend)? Does the same device lose connection on resume from S3
> with other host controller vendors? Have you seen this issue when the
> USB 3.0 device is behind a USB 3.0 hub?
This issue was specific to this paritcular make of Transcend.
we saw this on our chromebook. I did try Suspend-to-RAM with the same
device on Intel machine running Ubuntu.
It had worked fine without any issue.
Interestingly, if I connect with analyser, Suspend-to-RAM works fine
and USB re-enumerates successfully.
so connecting Suspend-to-RAM for debugging was not helping, as it works fine.
I did put prints in multiple places to get port status, and i see that
port is in sometimes RECOVERY, POLLING or In active STATE.
The behaviour was inconsistent.
>
> I ask because this sounds like a low-level link training issue that's
> specific to the exynos host or USB device. I would rather track down
> which hardware is to blame than generically add a warm reset for all USB
> 3.0 devices.
>
>> > rebased on Greg Kroah-Hartman's usb-next
>> > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
>> >
>> > Signed-off-by: Vikas Sajjan
>> > ---
>> > drivers/usb/core/hub.c | 41 +
>> > 1 file changed, 25 insertions(+), 16 deletions(-)
>> >
>> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
>> > index a7c04e2..d8432b0 100644
>> > --- a/drivers/usb/core/hub.c
>> > +++ b/drivers/usb/core/hub.c
>>
>> > @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum
>> > hub_activation_type type)
>> > u16 portstatus, portchange;
>> >
>> > portstatus = portchange = 0;
>> > +
>> > + /* Some connected devices might be still in unknown state even
>> > +* after reset-resume, a WARM_RESET gets the connected device
>> > +* to the normal state.
>> > +*/
>> > + if (udev && hub_is_superspeed(hub->hdev) &&
>> > + type == HUB_RESET_RESUME)
>> > + hub_port_reset(hub, port1, NULL,
>> > + HUB_BH_RESET_TIME, true);
>>
>> Please don't do this all the time to every attached port. Do it only
>> when it is really needed.
>
> Agreed. Can we at least limit the warm reset to devices directly
> attached to roothubs? You can also change this code to get the port
> status and only do the warm reset if the port link state is
> USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
> USB_SS_PORT_LS_SS_INACTIVE.
>
>> Shouldn't you pass udev as the third argument? If not, please explain
>> why not.
>>
>> Finally, I don't see why you put this in hub_activate(). Isn't it more
>> closely connected with the reset-resume procedure for the child device?
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] CHROMIUM: s5p-mfc: add controls to set vp8 enc profile
Hi Sachin, On Tue, Dec 10, 2013 at 10:38 AM, Sachin Kamat wrote: > Hi Arun, > > On 10 December 2013 10:15, Arun Kumar K wrote: >> Hi Pawel, >> >> On Tue, Dec 10, 2013 at 6:21 AM, Pawel Osciak wrote: >>> Hi Arun, >>> > >> >> Ok will make the change in next version. >> > > While at it also update the patch subject appropriately. > Oh I totally missed that. Thanks for pointing out. Regards Arun -- 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] CHROMIUM: s5p-mfc: add controls to set vp8 enc profile
Hi Arun, On 10 December 2013 10:15, Arun Kumar K wrote: > Hi Pawel, > > On Tue, Dec 10, 2013 at 6:21 AM, Pawel Osciak wrote: >> Hi Arun, >> > > Ok will make the change in next version. > While at it also update the patch subject appropriately. -- 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 2/2] i2c: exynos5: configure fifo_depth based on HSI2C module version
Hello Tomasz,
On 9 December 2013 22:01, Tomasz Figa wrote:
>
> Hi Naveen,
>
> On Friday 22 of November 2013 11:44:11 Naveen Krishna Chatradhi wrote:
> > fifo_depth of the HSI2C is not constant
> > Exynos5420 and Exynos5250 supports fifo_depth of 64bytes
> > Exynos5260 supports fifo_depth of 16bytes
> >
> > This patch configures the fifo_depth based on HSI2C modules version.
> > Signed-off-by: Naveen Krishna Chatradhi
> > ---
> > drivers/i2c/busses/i2c-exynos5.c | 29 ++---
> > 1 file changed, 18 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-exynos5.c
> > b/drivers/i2c/busses/i2c-exynos5.c
> > index cbb49e2..19277d8 100644
> > --- a/drivers/i2c/busses/i2c-exynos5.c
> > +++ b/drivers/i2c/busses/i2c-exynos5.c
> > @@ -77,12 +77,6 @@
> > #define HSI2C_RXFIFO_TRIGGER_LEVEL(x)((x) << 4)
> > #define HSI2C_TXFIFO_TRIGGER_LEVEL(x)((x) << 16)
> >
> > -/* As per user manual FIFO max depth is 64bytes */
> > -#define HSI2C_FIFO_MAX 0x40
> > -/* default trigger levels for Tx and Rx FIFOs */
> > -#define HSI2C_DEF_TXFIFO_LVL (HSI2C_FIFO_MAX - 0x30)
> > -#define HSI2C_DEF_RXFIFO_LVL (HSI2C_FIFO_MAX - 0x10)
> > -
> > /* I2C_TRAILING_CTL Register bits */
> > #define HSI2C_TRAILING_COUNT (0xf)
> >
> > @@ -187,6 +181,9 @@ struct exynos5_i2c {
> >
> > /* Version of HS-I2C Hardware */
> > unsigned intversion;
> > +
> > + /* FIFO depth */
> > + unsigned intfifo_depth;
> > };
> >
> > enum hsi2c_version {
> > @@ -437,7 +434,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void
> > *dev_id)
> > fifo_status = readl(i2c->regs + HSI2C_FIFO_STATUS);
> > fifo_level = HSI2C_TX_FIFO_LVL(fifo_status);
> >
> > - len = HSI2C_FIFO_MAX - fifo_level;
> > + len = i2c->fifo_depth - fifo_level;
> > if (len > (i2c->msg->len - i2c->msg_ptr))
> > len = i2c->msg->len - i2c->msg_ptr;
> >
> > @@ -505,6 +502,7 @@ static void exynos5_i2c_message_start(struct
> > exynos5_i2c *i2c, int stop)
> > u32 i2c_auto_conf = 0;
> > u32 fifo_ctl;
> > unsigned long flags;
> > + unsigned short trig_lvl;
> >
> > i2c_ctl = readl(i2c->regs + HSI2C_CTL);
> > i2c_ctl &= ~(HSI2C_TXCHON | HSI2C_RXCHON);
> > @@ -515,13 +513,19 @@ static void exynos5_i2c_message_start(struct
> > exynos5_i2c *i2c, int stop)
> >
> > i2c_auto_conf = HSI2C_READ_WRITE;
> >
> > - fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(HSI2C_DEF_TXFIFO_LVL);
> > + trig_lvl = (i2c->msg->len > i2c->fifo_depth) ?
> > + (i2c->fifo_depth * 3/4) : i2c->msg->len;
>
> This patch changes the fifo trigger level calculation (it's dependent now
> on message length), not just maximum fifo size, as the description says.
Actually, message->length need not be involved in this calculation.
Involving msg->len
will raise another interrupt for every small transactions. It better be avoided.
> It should be split into two separate patches, explaining why both changes
> are necessary.
I will split the fifo_depth configuration code along with comments addressed on
https://lkml.org/lkml/2013/11/22/31
I can think of 3 ways to address the h/w version changes
1. Compatible string as i implemented
2. Varient struct
3. Passing the information via device tree
How about passing fifo_depth from device tree information.
Currently, HSI2C Module on Exynso5260 is not another H/W version.
It only defer in fifo_depth and init sequence needs a reset.
>
>
> Best regards,
> Tomasz
>
--
Shine bright,
(: Nav :)
--
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] CHROMIUM: s5p-mfc: add controls to set vp8 enc profile
Hi Pawel, On Tue, Dec 10, 2013 at 6:21 AM, Pawel Osciak wrote: > Hi Arun, > > On Mon, Dec 9, 2013 at 10:16 PM, Arun Kumar K wrote: >> Add v4l2 controls to set desired profile for VP8 encoder. >> Acceptable levels for VP8 encoder are >> 0: Version 0 >> 1: Version 1 >> 2: Version 2 >> 3: Version 3 >> >> Signed-off-by: Pawel Osciak > > Sorry, but I'm not the author of this patch, Kiran is. I think the > confusion comes from the fact that I committed it to Chromium tree. I > think Kiran's sign-off should go first and the patch should contain: > "From: Kiran AVND " > Ok will make the change in next version. Thanks & Regards Arun -- 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] CHROMIUM: s5p-mfc: add controls to set vp8 enc profile
Hi Hans, Thanks for the review. On Mon, Dec 9, 2013 at 6:52 PM, Hans Verkuil wrote: > Hi Arun, > > Some comments below... > > On 12/09/2013 02:16 PM, Arun Kumar K wrote: >> Add v4l2 controls to set desired profile for VP8 encoder. >> Acceptable levels for VP8 encoder are >> 0: Version 0 >> 1: Version 1 >> 2: Version 2 >> 3: Version 3 >> >> Signed-off-by: Pawel Osciak >> Signed-off-by: Kiran AVND >> Signed-off-by: Arun Kumar K >> --- >> This patch is rebased over another VP8 control patch from me: >> https://linuxtv.org/patch/20733/ >> --- >> Documentation/DocBook/media/v4l/controls.xml|9 + >> drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 + >> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 11 +++ >> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |6 ++ >> drivers/media/v4l2-core/v4l2-ctrls.c|8 >> include/uapi/linux/v4l2-controls.h |1 + >> 6 files changed, 32 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/controls.xml >> b/Documentation/DocBook/media/v4l/controls.xml >> index e4db4ac..c1f7544 100644 >> --- a/Documentation/DocBook/media/v4l/controls.xml >> +++ b/Documentation/DocBook/media/v4l/controls.xml >> @@ -3193,6 +3193,15 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a >> golden frame. >> Quantization parameter for a P >> frame for VP8. >> >> >> + >> + >> + > spanname="id">V4L2_CID_MPEG_VIDEO_VPX_PROFILE >> + integer > > This says 'integer' whereas the control is actually an integer menu. > > Why did you choose 'integer menu' for this? Would a regular integer or > perhaps a standard > menu be better? > I chose integer menu as it is standard set of values with only 4 options (integers). Same thing is done in the controls - V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS and V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES. I felt this new controls is also in-line with the requirement of a integer-menu type. What do you think? >> + >> + Select the desired profile for VP8 >> encoder. >> +Acceptable values are 0, 1, 2 and 3 corresponding to encoder versions 0, 1, >> 2 and 3. > > Is it a 'profile' or a 'version'? It looks a bit confusing. I don't have the > VP8 standard, > so I can't really tell what the correct terminology is. > Ok will make it more clear. > Also, does this control apply just to VP8 or also to other VP versions? The > control name > says 'VPX' while the description says 'VP8' explicitly. > As of now its applicable to VP8, but I am not sure if the same thing will apply to VP9 also. Regards Arun -- 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] cpufreq: exynos: Add exynos5420 cpufreq driver
Hi Lukasz,
Thank you for the review.
On Mon, Dec 9, 2013 at 1:53 PM, Lukasz Majewski wrote:
> Hi Arun,
>
>> From: "Arjun.K.V"
>>
>> The patch adds cpufreq driver for exynos5420.
>>
>> Signed-off-by: Arjun.K.V
>> Signed-off-by: Andrew Bresticker
>> Signed-off-by: Arun Kumar K
>> ---
>> drivers/cpufreq/Kconfig.arm | 11 ++
>> drivers/cpufreq/Makefile |1 +
>> drivers/cpufreq/exynos-cpufreq.c |2 +
>> drivers/cpufreq/exynos-cpufreq.h |8 +
>> drivers/cpufreq/exynos5420-cpufreq.c | 346
>> ++ 5 files changed, 368 insertions(+)
>> create mode 100644 drivers/cpufreq/exynos5420-cpufreq.c
>
> I think that we shall cleanup "a bit" the cpufreq code for exynos.
> Now we have [*]:
> - exynos4x12-cpufreq.c
> - exynos4210-cpufreq.c
> - exynos5250-cpufreq.c
>
> and you want to add exynos5420-cpufreq.c
>
> Those files are pretty similar, so are a very good candidates for
> cleanup.
>
Yes thats right. There is a lot of common code now in these files.
> All supported processors (up to exynos5250) allows for frequency
> setting on all cores in the SoC.
>
> Those files [*] can be easily replaced by cpu0-cpufreq.c generic code.
> Also we can provide frequency, voltage table and ASV if needed via
> device tree.
>
> I did some preliminary work on this for Exynos4412. My plan is to
> continue when things with BOOST "calm down" :-).
>
Ok I will wait for your patches then :)
[snip]
>> +static unsigned int exynos5420_volt_table[CPUFREQ_NUM_LEVELS];
>> +static struct cpufreq_frequency_table exynos5420_freq_table[] = {
>> + {L0, 2000 * 1000},
>> + {L1, 1900 * 1000},
>> + {L2, 1800 * 1000},
>> + {L3, 1700 * 1000},
>> + {L4, 1600 * 1000},
>> + {L5, 1500 * 1000},
>> + {L6, 1400 * 1000},
>> + {L7, 1300 * 1000},
>> + {L8, 1200 * 1000},
>> + {L9, 1100 * 1000},
>> + {L10, 1000 * 1000},
>> + {L11, 900 * 1000},
>> + {L12, 800 * 1000},
>> + {L13, 700 * 1000},
>> + {L14, 600 * 1000},
>> + {L15, 500 * 1000},
>> + {L16, 400 * 1000},
>> + {L17, 300 * 1000},
>> + {L18, 200 * 1000},
>> + {0, CPUFREQ_TABLE_END},
>> +};
>
> This shall be provided via device tree.
>
Ok.
>> +
>> +static struct cpufreq_clkdiv
>> exynos5420_clkdiv_table[CPUFREQ_NUM_LEVELS]; +
>> +static unsigned int clkdiv_cpu0_5420[CPUFREQ_NUM_LEVELS][7] = {
>> + /*
>> + * Clock divider values for {CPUD, ATB, PCLK_DBG, APLL,
>> ARM2}
>> + */
>> + { 2, 7, 7, 3, 0 }, /* ARM L0: 2.0GHz */
>> + { 2, 7, 7, 3, 0 }, /* ARM L1: 1.9GHz */
>> + { 2, 7, 7, 3, 0 }, /* ARM L2: 1.8GHz */
>> + { 2, 7, 7, 3, 0 }, /* ARM L3: 1.7GHz */
>> + { 2, 7, 7, 3, 0 }, /* ARM L4: 1.6GHz */
>> + { 2, 7, 7, 3, 0 }, /* ARM L5: 1.5GHz */
>> + { 2, 7, 7, 3, 0 }, /* ARM L6: 1.4GHz */
>> + { 2, 7, 7, 3, 0 }, /* ARM L7: 1.3GHz */
>> + { 2, 7, 7, 3, 0 }, /* ARM L8: 1.2GHz */
>> + { 2, 7, 7, 3, 0 }, /* ARM L9: 1.1GHz */
>> + { 2, 6, 6, 3, 0 }, /* ARM L10: 1GHz */
>> + { 2, 6, 6, 3, 0 }, /* ARM L11: 900MHz */
>> + { 2, 5, 5, 3, 0 }, /* ARM L12: 800MHz */
>> + { 2, 5, 5, 3, 0 }, /* ARM L13: 700MHz */
>> + { 2, 4, 4, 3, 0 }, /* ARM L14: 600MHz */
>> + { 2, 3, 3, 3, 0 }, /* ARM L15: 500MHz */
>> + { 2, 3, 3, 3, 0 }, /* ARM L16: 400MHz */
>> + { 2, 3, 3, 3, 0 }, /* ARM L17: 300MHz */
>> + { 2, 3, 3, 3, 0 }, /* ARM L18: 200MHz */
>> +};
>
> This table is not needed (as similar ones in this patch), since the
> Common Clock Framework (and more specific the PLL code for Exynos)
> shall handle this.
>
Actually these values are not for PLL, but for the dividers.
If you see below, the PLL rate setting is done through clk_set_rate() going
via CCF. But I found an issue if the divider values are set via
clk_set_rate API.
What I found is, the system goes into freeze if all the divider values are not
set in one shot. So we cannot call multiple clk_set_rate()'s on each divider.
Thats why I continued with non-CCF way of setting the divider.
Are you taking care of this requirement in your restructuring?
>> +
>> +unsigned int clkdiv_cpu1_5420[CPUFREQ_NUM_LEVELS][2] = {
>> + /* Clock divider values for { copy, HPM } */
>> + { 7, 7 }, /* ARM L0: 2.0GHz */
>> + { 7, 7 }, /* ARM L1: 1.9GHz */
>> + { 7, 7 }, /* ARM L2: 1.8GHz */
>> + { 7, 7 }, /* ARM L3: 1.7GHz */
>> + { 7, 7 }, /* ARM L4: 1.6GHz */
>> + { 7, 7 }, /* ARM L5: 1.5GHz */
>> + { 7, 7 }, /* ARM L6: 1.4GHz */
>> + { 7, 7 }, /* ARM L7: 1.3GHz */
>> + { 7, 7 }, /* ARM L8: 1.2GHz */
>> + { 7, 7 }, /* ARM L9: 1.1GHz */
>> + { 7, 7 }, /* ARM L10: 1GHz */
>> + { 7, 7 }, /* ARM L11: 900MHz */
>> + { 7, 7 }, /* ARM L12: 800MHz */
>> + { 7, 7 }, /* ARM L13: 700MHz */
>> + { 7, 7 }, /* ARM L14: 600MHz */
>> + { 7, 7 }, /* ARM L15: 500MHz */
>> + { 7, 7 }, /* ARM L16: 400MHz */
>> + { 7, 7 }, /* ARM L17: 300MHz */
>> + { 7, 7 }, /* ARM L18: 200M
RE: [PATCH v4 3/9] phy: Add new Exynos USB PHY driver
Hi Kamil,
Same USB2.0 PHY may be used by several HCDs, for example EHCI and OHCI.
Consider the situation, when EHCI stops using the PHY and calls power_off,
then OHCI becomes non-operational. In other words, PHY power_on and
power_off calls must be balanced.
Shall we handle it in your driver? (usage count?)
> Add a new driver for the Exynos USB PHY. The new driver uses the
> generic
> PHY framework. The driver includes support for the Exynos 4x10 and 4x12
> SoC families.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> ---
> .../devicetree/bindings/phy/samsung-usbphy.txt | 54
> drivers/phy/Kconfig| 20 ++
> drivers/phy/Makefile |3 +
> drivers/phy/phy-exynos4210-usb2.c | 264
> +
> drivers/phy/phy-exynos4212-usb2.c | 312
>
> drivers/phy/phy-samsung-usb2.c | 228
> ++
> drivers/phy/phy-samsung-usb2.h | 72 +
> 7 files changed, 953 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/samsung-
> usbphy.txt
> create mode 100644 drivers/phy/phy-exynos4210-usb2.c
> create mode 100644 drivers/phy/phy-exynos4212-usb2.c
> create mode 100644 drivers/phy/phy-samsung-usb2.c
> create mode 100644 drivers/phy/phy-samsung-usb2.h
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
> b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
> new file mode 100644
> index 000..cadbf70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
> @@ -0,0 +1,54 @@
> +Samsung S5P/EXYNOS SoC series USB PHY
> +-
> +
> +Required properties:
> +- compatible : should be one of the listed compatibles:
> + - "samsung,exynos4210-usb2-phy"
> + - "samsung,exynos4212-usb2-phy"
> +- reg : a list of registers used by phy driver
> + - first and obligatory is the location of phy modules registers
> +- samsung,sysreg-phandle - handle to syscon used to control the system
> registers
> +- samsung,pmureg-phandle - handle to syscon used to control PMU
> registers
> +- #phy-cells : from the generic phy bindings, must be 1;
> +- clocks and clock-names:
> + - the "phy" clocks is required by the phy module
> + - next for each of the phys a clock has to be assidned, this
> clock
> + will be used to determine clocking frequency for the phys
> + (the labels are specified in the paragraph below)
> +
> +The first phandle argument in the PHY specifier identifies the PHY,
> its
> +meaning is compatible dependent. For the currently supported SoCs
> (Exynos 4210
> +and Exynos 4212) it is as follows:
> + 0 - USB device ("device"),
> + 1 - USB host ("host"),
> + 2 - HSIC0 ("hsic0"),
> + 3 - HSIC1 ("hsic1"),
> +
> +Exynos 4210 and Exynos 4212 use mode switching and require that mode
> switch
> +register is supplied.
> +
> +Example:
> +
> +For Exynos 4412 (compatible with Exynos 4212):
> +
> +usbphy: phy@125B {
> + compatible = "samsung,exynos4212-usb2-phy";
> + reg = <0x125B 0x100 0x10020704 0x0c 0x1001021c 0x4>;
> + clocks = <&clock 305>, <&clock 2>, <&clock 2>, <&clock 2>,
> + <&clock 2>;
> + clock-names = "phy", "device", "host", "hsic0", "hsic1";
> + status = "okay";
> + #phy-cells = <1>;
> + samsung,sysreg-phandle = <&sys_reg>;
> + samsung,pmureg-phandle = <&pmu_reg>;
> +};
> +
> +Then the PHY can be used in other nodes such as:
> +
> +phy-consumer@1234 {
> + phys = <&usbphy 2>;
> + phy-names = "phy";
> +};
> +
> +Refer to DT bindings documentation of particular PHY consumer devices
> for more
> +information about required PHYs and the way of specification.
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index a344f3d..b29018f 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -51,4 +51,24 @@ config PHY_EXYNOS_DP_VIDEO
> help
> Support for Display Port PHY found on Samsung EXYNOS SoCs.
>
> +config PHY_SAMSUNG_USB2
> + tristate "Samsung USB 2.0 PHY driver"
> + help
> + Enable this to support Samsung USB phy helper driver for
> Samsung SoCs.
> + This driver provides common interface to interact, for Samsung
> + USB 2.0 PHY driver.
> +
> +config PHY_EXYNOS4210_USB2
> + bool "Support for Exynos 4210"
> + depends on PHY_SAMSUNG_USB2
> + depends on CPU_EXYNOS4210
> + help
> + Enable USB PHY support for Exynos 4210
> +
> +config PHY_EXYNOS4212_USB2
> + bool "Support for Exynos 4212"
> + depends on PHY_SAMSUNG_USB2
> + depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412)
> + help
> + Enable USB PHY support for Exynos 4212
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index d0caae9..9f4befd 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Ma
Re: [PATCH 1/3] ARM: dts: Leave Exynos5250 SPI controller disabled by default
Hi,
On Mon, Nov 25, 2013 at 4:15 AM, Mark Brown wrote:
> From: Mark Brown
>
> Rather than requiring each board to explicitly disable the SPI controllers
> it is not using instead require boards to enable those that they are using.
> This is less work overall since normally at most one of the controllers is
> in use and avoids issues caused by inappropriate pinmuxing.
>
> Signed-off-by: Mark Brown
> Acked-by: Tomasz Figa
> ---
> arch/arm/boot/dts/cros5250-common.dtsi| 9 +
> arch/arm/boot/dts/exynos5250-arndale.dts | 12
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 6 ++
> arch/arm/boot/dts/exynos5250.dtsi | 3 +++
> 4 files changed, 6 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> b/arch/arm/boot/dts/cros5250-common.dtsi
> index dc259e8b8a73..0fcca2930c61 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -286,19 +286,12 @@
> };
> };
>
> - spi_0: spi@12d2 {
> - status = "disabled";
> - };
> -
> spi_1: spi@12d3 {
> + status = "okay";
> samsung,spi-src-clk = <0>;
> num-cs = <1>;
> };
>
> - spi_2: spi@12d4 {
> - status = "disabled";
> - };
> -
> hdmi {
> hpd-gpio = <&gpx3 7 0>;
> };
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index 684527087aa4..0385b58116ec 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -434,18 +434,6 @@
> status = "okay";
> };
>
> - spi_0: spi@12d2 {
> - status = "disabled";
> - };
> -
> - spi_1: spi@12d3 {
> - status = "disabled";
> - };
> -
> - spi_2: spi@12d4 {
> - status = "disabled";
> - };
> -
> gpio_keys {
> compatible = "gpio-keys";
>
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index f86d56760a45..5d0395e07eee 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -189,6 +189,8 @@
> };
>
> spi_1: spi@12d3 {
> + status = "okay";
> +
> w25q80bw@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -214,10 +216,6 @@
> };
> };
>
> - spi_2: spi@12d4 {
> - status = "disabled";
> - };
> -
> hdmi {
> hpd-gpio = <&gpx3 7 0>;
> };
I'm a little surprised that I don't see removal of spi_0 on SMDK5250.
When I apply your patch to ToT Linux I still see this in
"exynos5250-smdk5250.dts":
spi_0: spi@12d2 {
status = "disabled";
};
Other than that things look good to me and you can add my Reviewed-by:
Reviewed-by: Doug Anderson
-Doug
--
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] CHROMIUM: s5p-mfc: add controls to set vp8 enc profile
Hi Arun,
On Mon, Dec 9, 2013 at 10:16 PM, Arun Kumar K wrote:
> Add v4l2 controls to set desired profile for VP8 encoder.
> Acceptable levels for VP8 encoder are
> 0: Version 0
> 1: Version 1
> 2: Version 2
> 3: Version 3
>
> Signed-off-by: Pawel Osciak
Sorry, but I'm not the author of this patch, Kiran is. I think the
confusion comes from the fact that I committed it to Chromium tree. I
think Kiran's sign-off should go first and the patch should contain:
"From: Kiran AVND "
Thanks,
Pawel
> Signed-off-by: Kiran AVND
> Signed-off-by: Arun Kumar K
> ---
> This patch is rebased over another VP8 control patch from me:
> https://linuxtv.org/patch/20733/
> ---
> Documentation/DocBook/media/v4l/controls.xml|9 +
> drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 11 +++
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |6 ++
> drivers/media/v4l2-core/v4l2-ctrls.c|8
> include/uapi/linux/v4l2-controls.h |1 +
> 6 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml
> b/Documentation/DocBook/media/v4l/controls.xml
> index e4db4ac..c1f7544 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -3193,6 +3193,15 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a
> golden frame.
> Quantization parameter for a P
> frame for VP8.
>
>
> +
> +
> +spanname="id">V4L2_CID_MPEG_VIDEO_VPX_PROFILE
> + integer
> +
> + Select the desired profile for VP8
> encoder.
> +Acceptable values are 0, 1, 2 and 3 corresponding to encoder versions 0, 1,
> 2 and 3.
> +
> +
>
>
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index d91f757..797e61d 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -426,6 +426,7 @@ struct s5p_mfc_vp8_enc_params {
> u8 rc_max_qp;
> u8 rc_frame_qp;
> u8 rc_p_frame_qp;
> + u8 profile;
> };
>
> /**
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 33e8ae3..ec0581c 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -650,6 +650,14 @@ static struct mfc_control controls[] = {
> .step = 1,
> .default_value = 10,
> },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
> + .type = V4L2_CTRL_TYPE_INTEGER_MENU,
> + .minimum = 0,
> + .maximum = 3,
> + .step = 1,
> + .default_value = 0,
> + },
> };
>
> #define NUM_CTRLS ARRAY_SIZE(controls)
> @@ -1601,6 +1609,9 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:
> p->codec.vp8.rc_p_frame_qp = ctrl->val;
> break;
> + case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + p->codec.vp8.profile = ctrl->val;
> + break;
> default:
> v4l2_err(&dev->v4l2_dev, "Invalid control, id=%d, val=%d\n",
> ctrl->id, ctrl->val);
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index b4886d6..f6ff2db 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -1197,10 +1197,8 @@ static int s5p_mfc_set_enc_params_vp8(struct
> s5p_mfc_ctx *ctx)
> reg |= ((p->num_b_frame & 0x3) << 16);
> WRITEL(reg, S5P_FIMV_E_GOP_CONFIG_V6);
>
> - /* profile & level */
> - reg = 0;
> - /** profile */
> - reg |= (0x1 << 4);
> + /* profile - 0 ~ 3 */
> + reg = p_vp8->profile & 0x3;
> WRITEL(reg, S5P_FIMV_E_PICTURE_PROFILE_V6);
>
> /* rate control config. */
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 20840df..5069dd2 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -575,11 +575,17 @@ const s64 *v4l2_ctrl_get_int_menu(u32 id, u32 *len)
> 1, 2, 3,
> };
>
> + static const s64 qmenu_int_vpx_profile[] = {
> + 0, 1, 2, 3,
> + };
> +
> switch (id) {
> case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:
> return __v4l2_qmenu_int_len(qmenu_int_vpx_num_partitions,
> len);
> case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
> return __v4l2_qmenu_int_len(qmenu_int_vpx_num_ref_frame
Re: [PATCH 1/3] ARM: dts: Leave Exynos5250 SPI controller disabled by default
Hi, On Mon, Dec 9, 2013 at 1:07 PM, Kukjin Kim wrote: > On 12/10/13 00:23, Tomasz Figa wrote: >> >> Hi Kukjin, >> > Hi, > > >> On Monday 25 of November 2013 12:15:08 Mark Brown wrote: >>> >>> From: Mark Brown >>> >>> Rather than requiring each board to explicitly disable the SPI >>> controllers >>> it is not using instead require boards to enable those that they are >>> using. >>> This is less work overall since normally at most one of the controllers >>> is >>> in use and avoids issues caused by inappropriate pinmuxing. >>> >>> Signed-off-by: Mark Brown >>> Acked-by: Tomasz Figa >>> --- >>> arch/arm/boot/dts/cros5250-common.dtsi| 9 + >>> arch/arm/boot/dts/exynos5250-arndale.dts | 12 >>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 6 ++ >>> arch/arm/boot/dts/exynos5250.dtsi | 3 +++ >>> 4 files changed, 6 insertions(+), 24 deletions(-) >> >> >> Seems like you have missed this series. Could you apply it? >> > Yeah, thanks for your gentle reminder. > > + Doug and Olof > > BTW, Doug and Olof, are you OK with changing the name of cros5250-common DT > file? Basically, I agree with Mark's patch. I don't see anything that's changing a name, so perhaps I'm confused or missing something. Mark's patch looks good to me so I'll add a reviewed by... -Doug -- 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/1] ARM: dts: Add missing op_mode property to PMIC on Arndale
On 11/27/13 18:14, Sachin Kamat wrote:
Though the default value is 1, add it explicitly to avoid
unnecessary boot warnings and for consistency.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5250-arndale.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index e1d79efadf02..6c92c4a827dc 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -302,11 +302,13 @@
buck7_reg: BUCK7 {
regulator-name = "PVDD_BUCK7";
regulator-always-on;
+ op_mode =<1>;
};
buck8_reg: BUCK8 {
regulator-name = "PVDD_BUCK8";
regulator-always-on;
+ op_mode =<1>;
};
buck9_reg: BUCK9 {
OK, applied.
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 1/1] ARM: dts: Fix min voltage for vdd_arm on Arndale
On 11/27/13 18:15, Sachin Kamat wrote:
The minimum recommended ARM voltage for Exynos5250 at 200MHz
on Arndale board is 0.9125V. Update accordingly.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5250-arndale.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index bbfb23f942e1..6c92c4a827dc 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -266,7 +266,7 @@
buck2_reg: BUCK2 {
regulator-name = "vdd_arm";
- regulator-min-microvolt =<925000>;
+ regulator-min-microvolt =<912500>;
regulator-max-microvolt =<130>;
regulator-always-on;
regulator-boot-on;
OK, applied.
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 4/4 v4] ARM: dts: Exynos5420: Add device nodes for TMU blocks
Hi Kukjin,
On Tuesday 10 of December 2013 06:15:08 Kukjin Kim wrote:
> On 11/19/13 22:05, Naveen Krishna Chatradhi wrote:
> > Exynos5420 SoC has per core thermal management unit.
> > 5 TMU channels 4 for CPUs and 5th for GPU.
> >
> > This patch adds the device tree nodes to the DT device list.
> >
> > Nodes carry the misplaced second base address and the second
> > clock to access the misplaced base address.
> >
> > Signed-off-by: Leela Krishna Amudala
> > Signed-off-by: Naveen Krishna Chatradhi
> > Signed-off-by: Andrew Bresticker
> > ---
> > Changes since v3:
> > None, Just respinning
> >
> > Changes since v2:
> > 3. uses the new compatible strings introduced along with adding
> > support for Exynso5420.
> >
> > Changes since v1:
> > 1. Nodes carry the misplaced second base address and the second
> > clock to access the misplaced base address.
> > 2. Correct the clock number for the TMU4
> >
> > arch/arm/boot/dts/exynos5420.dtsi | 48
> > +
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> > b/arch/arm/boot/dts/exynos5420.dtsi
> > index 6ffefd1..d736b40 100644
> > --- a/arch/arm/boot/dts/exynos5420.dtsi
> > +++ b/arch/arm/boot/dts/exynos5420.dtsi
> > @@ -369,4 +369,52 @@
> > clock-names = "gscl";
> > samsung,power-domain =<&gsc_pd>;
> > };
> > +
> > + /* tmu for CPU0 */
> > + tmu@1006 {
> > + compatible = "samsung,exynos5420-tmu";
> > + reg =<0x1006 0x100>;
> > + interrupts =<0 65 0>;
> > + clocks =<&clock 318>;
> > + clock-names = "tmu_apbif";
> > + };
> > +
> > + /* tmu for CPU1 */
> > + tmu@10064000 {
> > + compatible = "samsung,exynos5420-tmu";
> > + reg =<0x10064000 0x100>;
> > + interrupts =<0 183 0>;
> > + clocks =<&clock 318>;
> > + clock-names = "tmu_apbif";
> > + };
> > +
> > + /* tmu for CPU2 */
> > + tmu@10068000 {
> > + compatible = "samsung,exynos5420-tmu-triminfo";
> > + /* 2nd reg is for the misplaced TRIMINFO register */
> > + 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-triminfo-clk";
> > + /* 2nd reg is for the misplaced TRIMINFO register */
> > + reg =<0x1006c000 0x100>,<0x100a 0x4>;
> > + interrupts =<0 185 0>;
> > + clocks =<&clock 318>,<&clock 319>;
> > + clock-names = "tmu_apbif", "tmu_apbif_triminfo";
> > + };
> > +
> > + /* tmu for GPU */
> > + tmu@100a {
> > + compatible = "samsung,exynos5420-tmu-triminfo-clk";
> > + /* 2nd reg is for the misplaced TRIMINFO register */
> > + reg =<0x100a 0x100>,<0x10068000 0x4>;
> > + interrupts =<0 215 0>;
> > + clocks =<&clock 319>,<&clock 318>;
> > + clock-names = "tmu_apbif", "tmu_apbif_triminfo";
> > + };
> > };
>
> BTW, there is just only this patch to support TMU on exynos5420?
This patch is a part of a 4-patch series, but unfortunately it was not
sent with correct threading, so it's hard to find remaing patches,
which are:
[PATCH 1/4 v9] thermal: samsung: replace inten_ bit fields with intclr_
[PATCH 2/4 v10] thermal: samsung: change base_common to more meaningful
base_second
[PATCH 3/4 v10] thermal: samsung: Add TMU support for Exynos5420 SoCs
There are comments to be addressed to those patches, so I guest at least
one more iteration is needed.
Naveen, it would be nice if you could send next version with proper
threading and consistent versioning. Thanks in advance.
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 1/1] ARM: dts: Add missing frequency property to exynos5250
On 11/30/13 02:29, Tomasz Figa wrote: On Friday 29 of November 2013 17:04:52 Sachin Kamat wrote: Added missing clock frequency property to CPU node to avoid boot time warnings. Signed-off-by: Sachin Kamat --- arch/arm/boot/dts/exynos5250.dtsi |2 ++ 1 file changed, 2 insertions(+) Reviewed-by: Tomasz Figa Thanks, applied. 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 1/1] ARM: dts: Fix a typo in exynos5420-pinctrl.dtsi
On 12/02/13 19:27, Sachin Kamat wrote: On 10 November 2013 23:50, Tomasz Figa wrote: On Thursday 07 of November 2013 09:39:46 Sachin Kamat wrote: Fixed samaung -> samsung in property name. Signed-off-by: Sachin Kamat --- arch/arm/boot/dts/exynos5420-pinctrl.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi index e695aba5f73c..e62c8eb57438 100644 --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi @@ -64,7 +64,7 @@ samsung,pins = "gpx0-7"; samsung,pin-function =<3>; samsung,pin-pud =<0>; - samaung,pin-drv =<0>; + samsung,pin-drv =<0>; }; }; Good catch. Reviewed-by: Tomasz Figa Best regards, Tomasz Ping Kukjin. Oh, OK, applied ;-) 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 v2] ARM: dts: Add regulator entries to Exynos5420 SMDK board
On 12/05/13 18:44, Sachin Kamat wrote:
Added regulator entries to Exynos5420 SMDK board.
Signed-off-by: Sachin Kamat
---
Changes since v1:
Changed node name
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 216 +
1 file changed, 216 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index fb5a1e25c632..62e1ebe4e989 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -120,4 +120,220 @@
reg =<0x50>;
};
};
+
+ hsi2c_4: i2c@12CA {
+ status = "okay";
+
+ s2mps11_pmic@66 {
+ compatible = "samsung,s2mps11-pmic";
+ reg =<0x66>;
+ s2mps11,buck2-ramp-delay =<12>;
+ s2mps11,buck34-ramp-delay =<12>;
+ s2mps11,buck16-ramp-delay =<12>;
+ s2mps11,buck6-ramp-enable =<1>;
+ s2mps11,buck2-ramp-enable =<1>;
+ s2mps11,buck3-ramp-enable =<1>;
+ s2mps11,buck4-ramp-enable =<1>;
+
+ s2mps11_osc: clocks {
+ #clock-cells =<1>;
+ clock-output-names = "s2mps11_ap",
+ "s2mps11_cp", "s2mps11_bt";
+ };
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "vdd_ldo1";
+ regulator-min-microvolt =<100>;
+ regulator-max-microvolt =<100>;
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = "vdd_ldo3";
+ regulator-min-microvolt =<180>;
+ regulator-max-microvolt =<180>;
+ regulator-always-on;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = "vdd_ldo5";
+ regulator-min-microvolt =<180>;
+ regulator-max-microvolt =<180>;
+ regulator-always-on;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = "vdd_ldo6";
+ regulator-min-microvolt =<100>;
+ regulator-max-microvolt =<100>;
+ regulator-always-on;
+ };
+
+ ldo7_reg: LDO7 {
+ regulator-name = "vdd_ldo7";
+ regulator-min-microvolt =<180>;
+ regulator-max-microvolt =<180>;
+ regulator-always-on;
+ };
+
+ ldo8_reg: LDO8 {
+ regulator-name = "vdd_ldo8";
+ regulator-min-microvolt =<180>;
+ regulator-max-microvolt =<180>;
+ regulator-always-on;
+ };
+
+ ldo9_reg: LDO9 {
+ regulator-name = "vdd_ldo9";
+ regulator-min-microvolt =<300>;
+ regulator-max-microvolt =<300>;
+ regulator-always-on;
+ };
+
+ ldo10_reg: LDO10 {
+ regulator-name = "vdd_ldo10";
+ regulator-min-microvolt =<180>;
+ regulator-max-microvolt =<180>;
+ regulator-always-on;
+ };
+
+ ldo11_reg: LDO11 {
+ regulator-name = "vdd_ldo11";
+ regulator-min-microvolt =<100>;
+ regulator-max-microvolt =<100>;
+ regulator-always-on;
+ };
+
+ ldo12_reg: LDO12 {
+ regulator-name = "vdd_ldo12";
+ regulator-
Re: [PATCH v2] ARM: dts: Add hs-i2c nodes to exynos5420
On 12/05/13 20:36, Tomasz Figa wrote: Hi Sachin, On Monday 02 of December 2013 16:41:42 Sachin Kamat wrote: Added high speed I2C nodes to Exynos5420 DT file. Signed-off-by: Sachin Kamat --- Changes since v1: Changed the node name to i2c as suggested by Tomasz Figa. --- arch/arm/boot/dts/exynos5420.dtsi | 98 + 1 file changed, 98 insertions(+) Reviewed-by: Tomasz Figa Looks good to me, applied. 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] ARM: s3c24xx: get rid of custom
On 12/06/13 20:58, Linus Walleij wrote: On Fri, Dec 6, 2013 at 10:31 AM, Linus Walleij wrote: Hi Linus, This isolates the custom S3C24xx GPIO definition table to Maybe I'm too trigger happy. I'll send a combined series with S3C24xx, S3C64xx and maybe also S5P variants all fixed so you can see the overall idea here. Hold on. Basically, looks good to me and let me hold on look at this patch? as you requested ;-) Anyway, thanks for your care of samsung gpio stuff. - 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] ARM: SAMSUNG: remove unused SAMSUNG_GPIOLIB_4BIT Kconfig parameter
On 12/09/13 13:38, Michael Opdenacker wrote: This removes the SAMSUNG_GPIOLIB_4BIT Kconfig parameter, which was no longer used anywhere in the source code and Makefiles. Signed-off-by: Michael Opdenacker Reviewed-by: Jingoo Han --- arch/arm/Kconfig | 1 - arch/arm/plat-samsung/Kconfig | 8 2 files changed, 9 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c1f1a7eee953..5e227a371401 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -740,7 +740,6 @@ config ARCH_S3C64XX select S3C_DEV_NAND select S3C_GPIO_TRACK select SAMSUNG_ATAGS - select SAMSUNG_GPIOLIB_4BIT select SAMSUNG_WAKEMASK select SAMSUNG_WDT_RESET select USB_ARCH_HAS_OHCI diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 6d95d60276d6..58645a58d0d8 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -24,7 +24,6 @@ config PLAT_S5P select S3C_GPIO_TRACK select S5P_GPIO_DRVSTR select SAMSUNG_CLKSRC if !COMMON_CLK - select SAMSUNG_GPIOLIB_4BIT help Base platform code for Samsung's S5P series SoC. @@ -115,13 +114,6 @@ config S5P_GPIO_INT # options for gpio configuration support -config SAMSUNG_GPIOLIB_4BIT - bool - help - GPIOlib file contains the 4 bit modification functions for gpio - configuration. GPIOlib shall be compiled only for S3C64XX and S5P - series of processors. - config S5P_GPIO_DRVSTR bool help OK, applied. 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][RESEND] ARM: SAMSUNG: remove IRQF_DISABLED
On 12/09/13 18:02, Michael Opdenacker wrote:
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
Reviewed-by: Jingoo Han
---
arch/arm/mach-s3c24xx/dma.c | 2 +-
arch/arm/mach-s3c24xx/simtec-usb.c | 3 +--
arch/arm/mach-s3c64xx/mach-smartq.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/dma.c b/arch/arm/mach-s3c24xx/dma.c
index 4a65cba3295d..a8dafc174fe3 100644
--- a/arch/arm/mach-s3c24xx/dma.c
+++ b/arch/arm/mach-s3c24xx/dma.c
@@ -742,7 +742,7 @@ int s3c2410_dma_request(enum dma_ch channel,
chan->irq_claimed = 1;
local_irq_restore(flags);
- err = request_irq(chan->irq, s3c2410_dma_irq, IRQF_DISABLED,
+ err = request_irq(chan->irq, s3c2410_dma_irq, 0,
client->name, (void *)chan);
local_irq_save(flags);
diff --git a/arch/arm/mach-s3c24xx/simtec-usb.c
b/arch/arm/mach-s3c24xx/simtec-usb.c
index 2ed2e32430dc..bb3eac6a7697 100644
--- a/arch/arm/mach-s3c24xx/simtec-usb.c
+++ b/arch/arm/mach-s3c24xx/simtec-usb.c
@@ -78,8 +78,7 @@ static void usb_simtec_enableoc(struct s3c2410_hcd_info
*info, int on)
if (on) {
ret = request_irq(BAST_IRQ_USBOC, usb_simtec_ocirq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING |
- IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
"USB Over-current", info);
if (ret != 0) {
printk(KERN_ERR "failed to request usb oc irq\n");
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index a6b338fd0470..08a889c141da 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -106,7 +106,7 @@ static void smartq_usb_host_enableoc(struct
s3c2410_hcd_info *info, int on)
if (on) {
ret = request_irq(gpio_to_irq(S3C64XX_GPL(10)),
- smartq_usb_host_ocirq, IRQF_DISABLED |
+ smartq_usb_host_ocirq,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
"USB host overcurrent", info);
if (ret != 0)
Looks OK to me, applied.
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 4/4 v4] ARM: dts: Exynos5420: Add device nodes for TMU blocks
On 11/19/13 22:05, Naveen Krishna Chatradhi wrote:
Exynos5420 SoC has per core thermal management unit.
5 TMU channels 4 for CPUs and 5th for GPU.
This patch adds the device tree nodes to the DT device list.
Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Andrew Bresticker
---
Changes since v3:
None, Just respinning
Changes since v2:
3. uses the new compatible strings introduced along with adding
support for Exynso5420.
Changes since v1:
1. Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
2. Correct the clock number for the TMU4
arch/arm/boot/dts/exynos5420.dtsi | 48 +
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 6ffefd1..d736b40 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -369,4 +369,52 @@
clock-names = "gscl";
samsung,power-domain =<&gsc_pd>;
};
+
+ /* tmu for CPU0 */
+ tmu@1006 {
+ compatible = "samsung,exynos5420-tmu";
+ reg =<0x1006 0x100>;
+ interrupts =<0 65 0>;
+ clocks =<&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU1 */
+ tmu@10064000 {
+ compatible = "samsung,exynos5420-tmu";
+ reg =<0x10064000 0x100>;
+ interrupts =<0 183 0>;
+ clocks =<&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu-triminfo";
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ 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-triminfo-clk";
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg =<0x1006c000 0x100>,<0x100a 0x4>;
+ interrupts =<0 185 0>;
+ clocks =<&clock 318>,<&clock 319>;
+ clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = "samsung,exynos5420-tmu-triminfo-clk";
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg =<0x100a 0x100>,<0x10068000 0x4>;
+ interrupts =<0 215 0>;
+ clocks =<&clock 319>,<&clock 318>;
+ clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+ };
};
BTW, there is just only this patch to support TMU on exynos5420?
- 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 1/3] ARM: dts: Leave Exynos5250 SPI controller disabled by default
On 12/10/13 00:23, Tomasz Figa wrote: Hi Kukjin, Hi, On Monday 25 of November 2013 12:15:08 Mark Brown wrote: From: Mark Brown Rather than requiring each board to explicitly disable the SPI controllers it is not using instead require boards to enable those that they are using. This is less work overall since normally at most one of the controllers is in use and avoids issues caused by inappropriate pinmuxing. Signed-off-by: Mark Brown Acked-by: Tomasz Figa --- arch/arm/boot/dts/cros5250-common.dtsi| 9 + arch/arm/boot/dts/exynos5250-arndale.dts | 12 arch/arm/boot/dts/exynos5250-smdk5250.dts | 6 ++ arch/arm/boot/dts/exynos5250.dtsi | 3 +++ 4 files changed, 6 insertions(+), 24 deletions(-) Seems like you have missed this series. Could you apply it? Yeah, thanks for your gentle reminder. + Doug and Olof BTW, Doug and Olof, are you OK with changing the name of cros5250-common DT file? Basically, I agree with Mark's patch. - 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 1/3] ARM: EXYNOS: pmu: Constify data tables
On 12/10/13 01:15, Tomasz Figa wrote: On Tuesday 10 of December 2013 00:11:40 Daniel Kurtz wrote: Hi Tomasz, Thank you for the reviews. On Dec 9, 2013 5:15 AM, "Tomasz Figa" wrote: Hi Daniel, On Thursday 21 of November 2013 02:21:24 Daniel Kurtz wrote: These tables are all immutable, make them const to save 4416 bytes of RAM. size arch/arm/mach-exynos/pmu.o text data bss 848 4420 4 // before 5264 4 4 // after I'm not sure where the mentioned saving of RAM is. Moving data between sections is not supposed to make it use less memory, I believe. You are correct. This was my misunderstanding from doing too much work with microcontrollers, where .text sections are accessed in place from FLASH for code and const data, but .data memory is copied from a FLASH section to a second RAM section at init for access at runtime. Most modern Linux systems copy/decompress their code and data sections from external storage to RAM anyway, so there is no actual memory savings (except potentially the compiler may be able to optimize a bit more with the const hint). Anyway, it's a good practice to mark constant data as const, to disallow changing them at runtime by mistake, so the patch is fine. Except some issues I commented on inline. Were there supposed to be inline comments? I don't see any. Oops, sorry for this, forgot to remove the last sentence. I initially had one question about the constant pointers below, but I read through the full code again and answered it myself. The patch is fine. Reviewed-by: Tomasz Figa OK, applied 1 to 3 patches into cleanup. 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 1/2] ARM: dts: Fix status property of mmc nodes for snow board
On 12/10/13 01:16, Doug Anderson wrote:
Yuvaraj,
On Sun, Dec 8, 2013 at 10:38 PM, Yuvaraj Kumar C D wrote:
Commit 0c3de788 ("ARM: dts: change status property of dwmmc nodes
for exynos5250") missed out handling the exynos5250 snow dts file.
Signed-off-by : Abhilash Kesavan
Signed-off-by: Yuvaraj Kumar C D
---
arch/arm/boot/dts/cros5250-common.dtsi |4
arch/arm/boot/dts/exynos5250-snow.dts |9 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 6470536..1ceb62e 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -247,10 +247,6 @@
};
};
- mmc@1221 {
- status = "disabled";
- };
-
mmc@1222 {
num-slots =<1>;
supports-highspeed;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index a9395c4..67484d1 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -171,11 +171,20 @@
};
};
+ mmc@1220 {
+ status = "okay";
+ };
+
+ mmc@1222 {
+ status = "okay";
+ };
+
I probably would have put the 1220 and 1222 ones in
cros5250-common since that's where all of the other stuff relating to
those ports is. Some of it may need to be moved around once we get
the HP Chromebook 11 (exynos5250-spring) in place, but until then it
seems best to keep it all together.
-Doug
OK, sounds better, I don't know well about the HP Chromebook though ;-)
- 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 2/2] ARM: dts:Move fifo-depth property from cros5250-common.dtsi
On 12/10/13 01:19, Doug Anderson wrote:
Yuvaraj,
On Sun, Dec 8, 2013 at 10:38 PM, Yuvaraj Kumar C D wrote:
Commit 64c138a ("ARM: dts: Move fifo-depth property from exynos5250
board dts") missed out handling the exynos5250 snow dts file.
Deletes the fifo-depth property, as this property has been moved to
SOC specific exynos5250.dtsi file.
Signed-off-by : Abhilash Kesavan
No need space between "by" and ":".
Signed-off-by: Yuvaraj Kumar C D
Reviewed-by: Doug Anderson
Looks good, applied.
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 v4 2/4] clk: exynos5410: register clocks using common clock framework
On 12/10/13 01:34, Tomasz Figa wrote: Hi Vyacheslav, Tarek, On Tuesday 26 of November 2013 12:58:06 Vyacheslav Tyrtov wrote: From: Tarek Dakhran The EXYNOS5410 clocks are statically listed and registered using the Samsung specific common clock helper functions. Signed-off-by: Tarek Dakhran Signed-off-by: Vyacheslav Tyrtov --- .../devicetree/bindings/clock/exynos5410-clock.txt | 54 + drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos5410.c | 239 + include/dt-bindings/clock/exynos5410.h | 32 +++ 4 files changed, 326 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt create mode 100644 drivers/clk/samsung/clk-exynos5410.c create mode 100644 include/dt-bindings/clock/exynos5410.h Acked-by: Tomasz Figa Tomasz, thanks for your ack on clk stuff. This should go through Samsung tree, I guess, since it's a dependency of other patches in this series and doesn't depend on any things from clock tree. Mike, Kukjin, are you okay with this? Yeah, I'm fine on this series but 4th patch for supporting dual cluster. Let me take 1 to 3 patches firstly. 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 1/1] ARM: dts: Add initial support for Arndale Octa board
On 12/10/13 01:37, Tomasz Figa wrote: Hi Sachin, On Thursday 28 of November 2013 16:08:01 Sachin Kamat wrote: Arndale Octa board is based on Exynos5420 SoC. This patch adds the basic support required for booting it through DT. Signed-off-by: Sachin Kamat --- arch/arm/boot/dts/Makefile|1 + arch/arm/boot/dts/exynos5420-arndale-octa.dts | 66 + 2 files changed, 67 insertions(+) create mode 100644 arch/arm/boot/dts/exynos5420-arndale-octa.dts Reviewed-by: Tomasz Figa Tomasz, thanks for your review and looks good to me :-) Applied, 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: [RFC v2 1/4] power: asv: Add common ASV support for Samsung SoCs
Hi Yadwinder, Sachin,
On Friday 15 of November 2013 17:11:28 Sachin Kamat wrote:
> From: Yadwinder Singh Brar
>
> This patch introduces a common ASV (Adaptive Supply Voltage) basic framework
> for samsung SoCs. It provides common APIs (to be called by users to get ASV
> values or init opp_table) and an interface for SoC specific drivers to
> register ASV members (instances).
[snip]
> diff --git a/drivers/power/asv/asv.c b/drivers/power/asv/asv.c
> new file mode 100644
> index ..3f2c31a0d3a9
> --- /dev/null
> +++ b/drivers/power/asv/asv.c
> @@ -0,0 +1,176 @@
> +/*
> + * ASV(Adaptive Supply Voltage) common core
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static LIST_HEAD(asv_list);
> +static DEFINE_MUTEX(asv_mutex);
> +
> +struct asv_member {
> + struct list_headnode;
> + struct asv_info *asv_info;
nit: Inconsistent indentation of member names. In general I would
recommend dropping the tabs between types and names and using a single
space instead, since this is more future proof - you will never have to
change other lines to add new ones.
> +};
> +
> +static void add_asv_member(struct asv_member *asv_mem)
> +{
> + mutex_lock(&asv_mutex);
> + list_add_tail(&asv_mem->node, &asv_list);
> + mutex_unlock(&asv_mutex);
> +}
> +
> +static struct asv_member *asv_get_mem(enum asv_type_id asv_type)
I don't really like this enum based look-up. It's hard to define an enum
that covers any possible existing and future platforms that would not be
bloated with single platform specific entries. IMHO something string based
could be more scalable.
> +{
> + struct asv_member *asv_mem;
> + struct asv_info *asv_info;
> +
> + list_for_each_entry(asv_mem, &asv_list, node) {
> + asv_info = asv_mem->asv_info;
> + if (asv_type == asv_info->type)
> + return asv_mem;
> + }
Don't you need any kind of locking here? A mutex in add_asv_member()
suggests that read access to the list should be protected as well.
> +
> + return NULL;
> +}
> +
> +unsigned int asv_get_volt(enum asv_type_id target_type,
> + unsigned int target_freq)
Do you need this function at all? I believe this is all about populating
device's OPP array with frequencies and voltages according to its ASV
level. Users will be able to query for required voltage using standard OPP
calls then, without a need for ASV specific functions like this one.
> +{
> + struct asv_member *asv_mem = asv_get_mem(target_type);
> + struct asv_freq_table *dvfs_table;
> + struct asv_info *asv_info;
> + unsigned int i;
> +
> + if (!asv_mem)
> + return 0;
> +
> + asv_info = asv_mem->asv_info;
> + dvfs_table = asv_info->dvfs_table;
> +
> + for (i = 0; i < asv_info->nr_dvfs_level; i++) {
> + if (dvfs_table[i].freq == target_freq)
> + return dvfs_table[i].volt;
> + }
> +
> + return 0;
> +}
> +
> +int asv_init_opp_table(struct device *dev, enum asv_type_id target_type)
> +{
> + struct asv_member *asv_mem = asv_get_mem(target_type);
> + struct asv_info *asv_info;
> + struct asv_freq_table *dvfs_table;
> + unsigned int i;
> +
> + if (!asv_mem)
> + return -EINVAL;
> +
> + asv_info = asv_mem->asv_info;
> + dvfs_table = asv_info->dvfs_table;
> +
> + for (i = 0; i < asv_info->nr_dvfs_level; i++) {
> + if (dev_pm_opp_add(dev, dvfs_table[i].freq * 1000,
> + dvfs_table[i].volt)) {
> + dev_warn(dev, "Failed to add OPP %d\n",
> + dvfs_table[i].freq);
Hmm, shouldn't it be considered a failure instead?
> + continue;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static struct asv_member *asv_init_member(struct asv_info *asv_info)
> +{
> + struct asv_member *asv_mem;
> + int ret = 0;
> +
> + if (!asv_info) {
> + pr_err("No ASV info provided\n");
> + return NULL;
I'd suggest adopting the ERR_PTR() convention, which allows returning more
information about the error.
> + }
> +
> + asv_mem = kzalloc(sizeof(*asv_mem), GFP_KERNEL);
> + if (!asv_mem) {
> + pr_err("Allocation failed for member: %s\n", asv_info->name);
> + return NULL;
> + }
> +
> + asv_mem->asv_info = kmemdup(asv_info, sizeof(*asv_info), GFP_KERNEL);
> + if (!asv_mem->asv_info) {
> + pr_err("Copying asv_info failed for member: %s\n",
> + asv_info->name);
> + kfree(asv_mem);
> + retu
Re: [PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
On Mon, Dec 09, 2013 at 10:24:52AM -0500, Alan Stern wrote: > On Mon, 9 Dec 2013, Vikas Sajjan wrote: > > > Does warm reset while activating SuperSpeed HUBs if the hub activate type > > is HUB_RESET_RESUME. > > > > When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) > > transcend > > USB 3.0 device connected on 3.0 port, during resume I noticed that the > > XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE. > > This behaviour is inconsistent and the connection with connected USB 3.0 > > device > > on 3.0 port was LOST. Does the device eventually re-connect on the USB port? Or is warm reset necessary to make the device connect? Does the xHCI register restore complete after resume from S3, or is power lost? I'm trying to figure out whether xhci_reset is called before your issue is triggered. > > Doing warm reset while activating SuperSpeed HUBs if the hub > > activate type is HUB_RESET_RESUME, gets the connected device to the stable > > state. > > > > Reviewed at https://chromium-review.googlesource.com/#/c/177132/ > > > > Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device > > (8564:1000) Is this issue specific to the particular USB device manufacturer (Transcend)? Does the same device lose connection on resume from S3 with other host controller vendors? Have you seen this issue when the USB 3.0 device is behind a USB 3.0 hub? I ask because this sounds like a low-level link training issue that's specific to the exynos host or USB device. I would rather track down which hardware is to blame than generically add a warm reset for all USB 3.0 devices. > > rebased on Greg Kroah-Hartman's usb-next > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git > > > > Signed-off-by: Vikas Sajjan > > --- > > drivers/usb/core/hub.c | 41 + > > 1 file changed, 25 insertions(+), 16 deletions(-) > > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > index a7c04e2..d8432b0 100644 > > --- a/drivers/usb/core/hub.c > > +++ b/drivers/usb/core/hub.c > > > @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum > > hub_activation_type type) > > u16 portstatus, portchange; > > > > portstatus = portchange = 0; > > + > > + /* Some connected devices might be still in unknown state even > > +* after reset-resume, a WARM_RESET gets the connected device > > +* to the normal state. > > +*/ > > + if (udev && hub_is_superspeed(hub->hdev) && > > + type == HUB_RESET_RESUME) > > + hub_port_reset(hub, port1, NULL, > > + HUB_BH_RESET_TIME, true); > > Please don't do this all the time to every attached port. Do it only > when it is really needed. Agreed. Can we at least limit the warm reset to devices directly attached to roothubs? You can also change this code to get the port status and only do the warm reset if the port link state is USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or USB_SS_PORT_LS_SS_INACTIVE. > Shouldn't you pass udev as the third argument? If not, please explain > why not. > > Finally, I don't see why you put this in hub_activate(). Isn't it more > closely connected with the reset-resume procedure for the child device? Sarah Sharp -- 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: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible
On Mon, Dec 09, 2013 at 11:22:39PM +0530, Padma Venkat wrote: > I think this is what you are concern about why it is not working as-is. OK, makes sense - thanks! signature.asc Description: Digital signature
Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible
Hi Mark, On Thu, Dec 5, 2013 at 5:15 PM, Mark Brown wrote: > On Thu, Dec 05, 2013 at 04:20:03PM +0530, Padma Venkat wrote: >> On Thu, Nov 28, 2013 at 5:23 PM, Mark Brown wrote: > >> > OK, so we can probably just reinitialise the dmaengine data after we >> > reset it? Like below > >> Yes. That works well. > > Great. > >> As I forgot to add SND_DMAENGINE_PCM_FLAG_NO_RESIDUE flag, I was >> getting underrun error. After adding this flag audio playback is >> working fine for smaller files on smdk5420 with pl330 dma driver. > > OK, there were some patches on the thread adding residue support to the > PL330 driver yesterday - hopefully those can get merged at some point > >> Except for the crash due to NULL pointer dereference in secondary >> dai(I posted a patch for the same (ASoC: samsung: Initialize the >> dma_data for secondary dai)) you can add my > >> Tested By: Padmavathi Venna > > Excellent, thanks - I'd squashed in your change already. Like I say I'm > still concerned that we might need a fix for v3.13 since I can't > entirely see why the code works as-is. Here two things 1)crash due to null pointer reference during boot which got fixed by initializing the secondary dai. This crash was not there in mainline because the channel request happening at runtime and with dmaengine the channel request happening at boot time. But if some one try to play audio with secondary device then at run time this crash might happen. 2) overwritting of dma_size during hw_params This is not required in mainline because pointer to the whole s3c_dma_params were being passed as dma_data which has dma_size init. But with dmaengine we are just passing the pointer to snd_dmaengine_dai_dma_data which is embedded in s3c_dma_params and dma_size is outside. I think this is what you are concern about why it is not working as-is. Thanks Padma -- 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: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible
On Fri, Dec 06, 2013 at 10:44:19AM +0530, Padma Venkat wrote: > I couldn't test this patch set due to some crash in recent kernel in > dmaengine_unmap_put. I think this unmap support is not yet implemented > for pl330 driver. It is mentioned in the commit "dmaengine: prepare > for generic 'unmap' data", [bzolnier: prepare pl330 driver for adding > missing unmap while at it]. This is unfortunate... I'd suggest trying mainline but I see it's broken in Linus' tree too and no fixes in -next. :( I'm tempted to push up with your Tested-by a note saying you did your testing on an earlier version but weren't able to test due to other bugs. signature.asc Description: Digital signature
Re: [PATCH v3 0/5] ARM: S3C24XX: Convert s3c2416 and s3c2443 to common clock framework
Hi Heiko, On Tuesday 03 of December 2013 16:19:57 Heiko Stübner wrote: > Resurrecting this series again after to much time. > > Changed is the pll registration to follow the new system and getting the > external clocks from dt fixed-rate clocks. > > Hopefully I did address all comments received for v2 in july. > > Tested on both non-dt and dt s3c2416. As s3c2443 is working the same way it > should work, but is only compile tested. > > Heiko Stuebner (5): > clk: samsung: add pll_6552 variant for s3c2416 > clk: samsung: add plls used by the s3c2443 > dt-bindings: add binding for clock-controller of s3c2443 and following > clk: samsung: add clock-driver for s3c2416, s3c2443 and s3c2450 > ARM: S3C24XX: Convert s3c2416 and s3c2443 to common clock framework > > .../bindings/clock/samsung,s3c2443-clock.txt | 46 ++ > arch/arm/boot/dts/s3c2416-smdk2416.dts |9 + > arch/arm/boot/dts/s3c2416.dtsi | 48 ++ > arch/arm/mach-s3c24xx/Kconfig | 14 +- > arch/arm/mach-s3c24xx/Makefile |5 +- > arch/arm/mach-s3c24xx/clock-s3c2416.c | 171 - > arch/arm/mach-s3c24xx/clock-s3c2443.c | 212 -- > arch/arm/mach-s3c24xx/common-s3c2443.c | 675 > > arch/arm/mach-s3c24xx/common.c | 16 +- > arch/arm/mach-s3c24xx/common.h |6 + > arch/arm/mach-s3c24xx/mach-s3c2416-dt.c| 39 +- > arch/arm/mach-s3c24xx/mach-smdk2416.c |9 +- > arch/arm/mach-s3c24xx/mach-smdk2443.c |9 +- > drivers/clk/samsung/Makefile |1 + > drivers/clk/samsung/clk-pll.c | 84 ++- > drivers/clk/samsung/clk-pll.h |3 + > drivers/clk/samsung/clk-s3c2443.c | 417 > include/dt-bindings/clock/samsung,s3c2443-clock.h | 92 +++ > 18 files changed, 742 insertions(+), 1114 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt > delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2416.c > delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2443.c > delete mode 100644 arch/arm/mach-s3c24xx/common-s3c2443.c > create mode 100644 drivers/clk/samsung/clk-s3c2443.c > create mode 100644 include/dt-bindings/clock/samsung,s3c2443-clock.h Thanks for you great work on S3C24xx. Except for my (minor) comments on patches 3 and 5: Acked-by: Tomasz Figa 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 v3 5/5] ARM: S3C24XX: Convert s3c2416 and s3c2443 to common clock framework
Hi Heiko,
On Tuesday 03 of December 2013 16:24:11 Heiko Stübner wrote:
> This converts the mentioned platforms to use the newly introduced driver
> for the common clock framework for them.
>
> With this the whole legacy clock structure can go away too.
>
> Signed-off-by: Heiko Stuebner
> ---
> arch/arm/boot/dts/s3c2416-smdk2416.dts |9 +
> arch/arm/boot/dts/s3c2416.dtsi | 48 +++
> arch/arm/mach-s3c24xx/Kconfig | 14 +-
> arch/arm/mach-s3c24xx/Makefile |5 +-
> arch/arm/mach-s3c24xx/clock-s3c2416.c | 171
> arch/arm/mach-s3c24xx/clock-s3c2443.c | 212 --
> arch/arm/mach-s3c24xx/common-s3c2443.c | 675
> ---
> arch/arm/mach-s3c24xx/common.c | 16 +-
> arch/arm/mach-s3c24xx/common.h |6 +
> arch/arm/mach-s3c24xx/mach-s3c2416-dt.c | 39 +-
> arch/arm/mach-s3c24xx/mach-smdk2416.c |9 +-
> arch/arm/mach-s3c24xx/mach-smdk2443.c |9 +-
> 12 files changed, 98 insertions(+), 1115 deletions(-)
> delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2416.c
> delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2443.c
> delete mode 100644 arch/arm/mach-s3c24xx/common-s3c2443.c
I would split this patch into one adding necessary definitions to DTS
files, then one migrating the platform to CCF. Until the driver gets
selected by respective Kconfig options, the entries in device tree should
not have any impact on the system, but you get rid of one patch doing
changes across two different trees.
Ideally this should be also done in one more step, allowing both clock
frameworks to coexist first and then removing the legacy code as the last
step to allow the new code to get more testing. However for this platform,
which isn't really very active nowadays, it might be fine to skip this.
> diff --git a/arch/arm/boot/dts/s3c2416-smdk2416.dts
> b/arch/arm/boot/dts/s3c2416-smdk2416.dts
> index 59594cf..fefb699 100644
> --- a/arch/arm/boot/dts/s3c2416-smdk2416.dts
> +++ b/arch/arm/boot/dts/s3c2416-smdk2416.dts
> @@ -19,6 +19,15 @@
> reg = <0x3000 0x400>;
> };
>
> + clocks {
> + xti: xti {
> + compatible = "fixed-clock";
> + clock-frequency = <1200>;
> + clock-output-names = "xti";
> + #clock-cells = <0>;
> + };
> + };
> +
> serial@5000 {
> status = "okay";
> pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
> index e6555bd..4bde5a2 100644
> --- a/arch/arm/boot/dts/s3c2416.dtsi
> +++ b/arch/arm/boot/dts/s3c2416.dtsi
> @@ -8,6 +8,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include "s3c24xx.dtsi"
> #include "s3c2416-pinctrl.dtsi"
>
> @@ -28,26 +29,59 @@
> compatible = "samsung,s3c2416-irq";
> };
>
> + clocks {
Don't you need compatible = "simple-bus" here for the subnodes to be
instantiated?
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + clocks: clock-controller@0x4c00 {
Why is this in a subnode? Clock controller is a part of the SoC, so IMHO
it should be on the same level as other peripherals.
> + compatible = "samsung,s3c2416-clock";
> + reg = <0x4c00 0x40>;
> + #clock-cells = <1>;
> + };
> + };
> +
[snip]
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index 2eeeb55..f2fe2ad 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -50,9 +50,9 @@ config CPU_S3C2416
> select CPU_ARM926T
> select CPU_LLSERIAL_S3C2440
> select S3C2416_PM if PM
> - select S3C2443_COMMON
> select S3C2443_DMA if S3C24XX_DMA
> - select SAMSUNG_CLKSRC
> + select COMMON_CLK
> + select S3C2443_COMMON_CLK
Please keep selected symbols sorted alphabetically.
> help
> Support for the S3C2416 SoC from the S3C24XX line
>
> @@ -85,9 +85,9 @@ config CPU_S3C2443
> bool "SAMSUNG S3C2443"
> select CPU_ARM920T
> select CPU_LLSERIAL_S3C2440
> - select S3C2443_COMMON
> select S3C2443_DMA if S3C24XX_DMA
> - select SAMSUNG_CLKSRC
> + select COMMON_CLK
> + select S3C2443_COMMON_CLK
Ditto.
> help
> Support for the S3C2443 SoC from the S3C24XX line
>
> @@ -664,12 +664,6 @@ endif# CPU_S3C2442
>
> if CPU_S3C2443 || CPU_S3C2416
>
> -config S3C2443_COMMON
> - bool
> - help
> - Common code for the S3C2443 and similar processors, which includes
> - the S3C2416 and S3C2450.
> -
> config S3C2443_COMMON_CLK
> bool
> help
[snip]
> diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
> index 4adaa4b..d87e432 100644
> --- a/arch/arm/mach-s3c24xx/common.c
> +++
Re: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init
On Mon, Dec 09, 2013 at 05:30:47PM +0530, Padma Venkat wrote: > This is required only after your changes because in dmaengine we are > requesting the dma channel statically but in mainline(with samsung > proprietary ops) we are requesting the dma channel at run time during > playback or capture. OK, so it does get set somewhere but not here? signature.asc Description: Digital signature
Re: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init
Hi Mark, On Mon, Dec 9, 2013 at 5:30 PM, Padma Venkat wrote: > Hi Mark, > > On Fri, Dec 6, 2013 at 4:57 PM, Mark Brown wrote: >> On Fri, Dec 06, 2013 at 10:44:33AM +0530, Padma Venkat wrote: >> >>> This is done in your earlier patch " ASoC: samsung: Ensure DMA data is >>> initialised for secondary DAI ". Was it done on purpose or by mistake >>> in this patch? >> >> It's intentional - notice that the function has changed, this is why I >> kept asking you about mainline. Mainline doesn't have the wrapper >> function that abstracts the difference between s3c-dma and dmaengine, >> this is why I'm saying these two will need to be rebased on top of the >> mainline fix. > > Ok. I didn't notice the function name. Then this commit is not > required in the mainline. > This is required only after your changes because in dmaengine we are > requesting the dma channel statically but in mainline(with samsung > proprietary ops) we are requesting the dma channel at run time during > playback or capture. sorry for the mix-up. I think we need to set the dma data for the secondary dai even in mainline. > >> >>> I think you also told to include a patch for reinitialization of the >>> dma_data in i2s_hw_params. If you are in the process of debugging some >>> bug as you mentioned earlier you can ignore this comment. Otherwise it >>> is just a reminder. >> >> Hrm, forgot to commit that bit. > > Thanks > Padma -- 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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Mon, Dec 09, 2013 at 11:22:44AM +0100, Linus Walleij wrote: > On Thu, Dec 5, 2013 at 4:07 PM, Mark Brown wrote: > > Or should we be going and applying the default state to all devices on > > init without worrying about a driver appearing? > That doesn't really work: if you have an unused device not in the > DT you usually mark it "disabled", and then the DT core doesn't > even create a platform_device for this node. > So doing this would involve parsing the tree and ... yuck. Hrm, yeah, good point. That's got a low awesomeness factor even though it should work. Boo. signature.asc Description: Digital signature
Re: [PATCH v3 3/5] dt-bindings: add binding for clock-controller of s3c2443 and following
Hi Heiko, On Tuesday 03 of December 2013 16:23:09 Heiko Stübner wrote: > Starting with the s3c2443 the s3c24xx series got a new clock tree > compared to the previous s3c24xx socs. This binding describes the > clock controller found in the s3c2443, s3c2416 and s3c2450 socs. > > Signed-off-by: Heiko Stuebner > --- > .../bindings/clock/samsung,s3c2443-clock.txt | 46 > > 1 file changed, 46 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt > > diff --git > a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt > b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt > new file mode 100644 > index 000..a3eb4ed > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt > @@ -0,0 +1,46 @@ > +* Samsung S3C2443 Clock Controller > + > +The S3C2443 clock controller generates and supplies clock to various > controllers > +within the SoC. The clock binding described here is applicable to all SoCs in > +the s3c24x family starting with the s3c2443. > + > +Required Properties: > + > +- compatible: should be one of the following. > + - "samsung,s3c2416-clock" - controller compatible with S3C2416 SoC. > + - "samsung,s3c2443-clock" - controller compatible with S3C2443 SoC. > + - "samsung,s3c2450-clock" - controller compatible with S3C2450 SoC. > +- reg: physical base address of the controller and length of memory mapped > + region. > +- #clock-cells: should be 1. > + > +Each clock is assigned an identifier and client nodes can use this identifier > +to specify the clock which they consume. Some of the clocks are available > only > +on a particular SoC. > + > +All available clocks are defined as preprocessor macros in > +dt-bindings/clock/samsung,s3c2443-clock.h header and can be used in device > +tree sources. I believe this driver needs some external clocks to be defined as fixed rate clocks using generic bindings. It should be noted what clocks are needed here in the documentation. Otherwise the patch 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
Re: [PATCH 1/1] ARM: dts: Add initial support for Arndale Octa board
Hi Sachin, On Thursday 28 of November 2013 16:08:01 Sachin Kamat wrote: > Arndale Octa board is based on Exynos5420 SoC. This patch > adds the basic support required for booting it through DT. > > Signed-off-by: Sachin Kamat > --- > arch/arm/boot/dts/Makefile|1 + > arch/arm/boot/dts/exynos5420-arndale-octa.dts | 66 > + > 2 files changed, 67 insertions(+) > create mode 100644 arch/arm/boot/dts/exynos5420-arndale-octa.dts Reviewed-by: Tomasz Figa 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 v4 2/4] clk: exynos5410: register clocks using common clock framework
Hi Vyacheslav, Tarek, On Tuesday 26 of November 2013 12:58:06 Vyacheslav Tyrtov wrote: > From: Tarek Dakhran > > The EXYNOS5410 clocks are statically listed and registered > using the Samsung specific common clock helper functions. > > Signed-off-by: Tarek Dakhran > Signed-off-by: Vyacheslav Tyrtov > --- > .../devicetree/bindings/clock/exynos5410-clock.txt | 54 + > drivers/clk/samsung/Makefile | 1 + > drivers/clk/samsung/clk-exynos5410.c | 239 > + > include/dt-bindings/clock/exynos5410.h | 32 +++ > 4 files changed, 326 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/exynos5410-clock.txt > create mode 100644 drivers/clk/samsung/clk-exynos5410.c > create mode 100644 include/dt-bindings/clock/exynos5410.h Acked-by: Tomasz Figa This should go through Samsung tree, I guess, since it's a dependency of other patches in this series and doesn't depend on any things from clock tree. Mike, Kukjin, are you okay with this? 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 2/2] i2c: exynos5: configure fifo_depth based on HSI2C module version
Hi Naveen,
On Friday 22 of November 2013 11:44:11 Naveen Krishna Chatradhi wrote:
> fifo_depth of the HSI2C is not constant
> Exynos5420 and Exynos5250 supports fifo_depth of 64bytes
> Exynos5260 supports fifo_depth of 16bytes
>
> This patch configures the fifo_depth based on HSI2C modules version.
> Signed-off-by: Naveen Krishna Chatradhi
> ---
> drivers/i2c/busses/i2c-exynos5.c | 29 ++---
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-exynos5.c
> b/drivers/i2c/busses/i2c-exynos5.c
> index cbb49e2..19277d8 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -77,12 +77,6 @@
> #define HSI2C_RXFIFO_TRIGGER_LEVEL(x)((x) << 4)
> #define HSI2C_TXFIFO_TRIGGER_LEVEL(x)((x) << 16)
>
> -/* As per user manual FIFO max depth is 64bytes */
> -#define HSI2C_FIFO_MAX 0x40
> -/* default trigger levels for Tx and Rx FIFOs */
> -#define HSI2C_DEF_TXFIFO_LVL (HSI2C_FIFO_MAX - 0x30)
> -#define HSI2C_DEF_RXFIFO_LVL (HSI2C_FIFO_MAX - 0x10)
> -
> /* I2C_TRAILING_CTL Register bits */
> #define HSI2C_TRAILING_COUNT (0xf)
>
> @@ -187,6 +181,9 @@ struct exynos5_i2c {
>
> /* Version of HS-I2C Hardware */
> unsigned intversion;
> +
> + /* FIFO depth */
> + unsigned intfifo_depth;
> };
>
> enum hsi2c_version {
> @@ -437,7 +434,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void
> *dev_id)
> fifo_status = readl(i2c->regs + HSI2C_FIFO_STATUS);
> fifo_level = HSI2C_TX_FIFO_LVL(fifo_status);
>
> - len = HSI2C_FIFO_MAX - fifo_level;
> + len = i2c->fifo_depth - fifo_level;
> if (len > (i2c->msg->len - i2c->msg_ptr))
> len = i2c->msg->len - i2c->msg_ptr;
>
> @@ -505,6 +502,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
> *i2c, int stop)
> u32 i2c_auto_conf = 0;
> u32 fifo_ctl;
> unsigned long flags;
> + unsigned short trig_lvl;
>
> i2c_ctl = readl(i2c->regs + HSI2C_CTL);
> i2c_ctl &= ~(HSI2C_TXCHON | HSI2C_RXCHON);
> @@ -515,13 +513,19 @@ static void exynos5_i2c_message_start(struct
> exynos5_i2c *i2c, int stop)
>
> i2c_auto_conf = HSI2C_READ_WRITE;
>
> - fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(HSI2C_DEF_TXFIFO_LVL);
> + trig_lvl = (i2c->msg->len > i2c->fifo_depth) ?
> + (i2c->fifo_depth * 3/4) : i2c->msg->len;
This patch changes the fifo trigger level calculation (it's dependent now
on message length), not just maximum fifo size, as the description says.
It should be split into two separate patches, explaining why both changes
are necessary.
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 1/2 v2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC
Hi Naveen,
On Tuesday 26 of November 2013 09:56:17 Naveen Krishna Chatradhi wrote:
> This patch adds new compatible to support HSI2C module on Exynos5260
> HSI2C module on Exynos5260 needs to be reset during during initialization.
>
> Signed-off-by: Naveen Krishna Chatradhi
> ---
> Changes since v1:
> Rebasing on linux-i2c for-next
>
> .../devicetree/bindings/i2c/i2c-exynos5.txt|6 +++-
> drivers/i2c/busses/i2c-exynos5.c | 31
> ++--
> 2 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> index 056732c..704ab92 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> @@ -5,7 +5,11 @@ at various speeds ranging from 100khz to 3.4Mhz.
>
> Required properties:
>- compatible: value should be.
> - -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
> + -> "samsung,exynos5-hsi2c", for i2c compatible with HSI2C available on
> + Exynos5250/5420 SoCs.
> + -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available
> + on Exynos5260 SoCs.
> +
>- reg: physical base address of the controller and length of memory mapped
> region.
>- interrupts: interrupt number to the cpu.
> diff --git a/drivers/i2c/busses/i2c-exynos5.c
> b/drivers/i2c/busses/i2c-exynos5.c
> index da39ff0..497ff91 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -184,14 +184,35 @@ struct exynos5_i2c {
>* 2. Fast speed upto 1Mbps
>*/
> int speed_mode;
> +
> + /* Version of HS-I2C Hardware */
> + unsigned intversion;
> +};
> +
> +enum hsi2c_version {
> + EXYNOS_5,
> + EXYNOS_5260
> };
I don't like this kind of hardware versioningm as there might show up
revisions that are previous revisions mixed together (e.g. some quirks
from one and some quirks from another).
IMHO better way to represent differences between hardware versions are
variant structs that define characteristics of particular variants.
For now, it doesn't really matter, though, as the only things that change
are fifo depth and whether the reset is needed (although see my comment
below on this). However if you could spot any other differences between
these two versions that might affect the driver in future, it would be
better to use a variant struct.
>
> static const struct of_device_id exynos5_i2c_match[] = {
> - { .compatible = "samsung,exynos5-hsi2c" },
> + {
> + .compatible = "samsung,exynos5-hsi2c",
> + .data = (void *)EXYNOS_5 },
> + {
> + .compatible = "samsung,exynos5260-hsi2c",
> + .data = (void *)EXYNOS_5260 },
> {},
> };
> MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
>
> +static inline unsigned int exynos5_i2c_get_version(struct platform_device
> *pdev)
> +{
> + const struct of_device_id *match;
> +
> + match = of_match_node(exynos5_i2c_match, pdev->dev.of_node);
> + return (unsigned int)match->data;
> +}
> +
> static void exynos5_i2c_clr_pend_irq(struct exynos5_i2c *i2c)
> {
> writel(readl(i2c->regs + HSI2C_INT_STATUS),
> @@ -692,7 +713,13 @@ static int exynos5_i2c_probe(struct platform_device
> *pdev)
> if (ret)
> goto err_clk;
>
> - exynos5_i2c_init(i2c);
> + i2c->version = exynos5_i2c_get_version(pdev);
> +
> + /* The HS-I2C core on Exynos5260 needs a reset to start with */
> + if (i2c->version == EXYNOS_5260)
> + exynos5_i2c_reset(i2c);
> + else
> + exynos5_i2c_init(i2c);
What about simply calling exynos5_i2c_reset() here regardless of the
version? I don't think it should cause any problems and could be even
more reliable as the hardware would be always reset to its default state
regardless of what the firmware does with it.
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 1/1] clk: exynos5250: Add CLK_SET_RATE_PARENT flag to mout_apll
Hi Tomasz, On 9 December 2013 19:01, Tomasz Figa wrote: > Hi Sachin, > > On Thursday 21 of November 2013 09:47:34 Sachin Kamat wrote: >> Add CLK_SET_RATE_PARENT flag to be able to change the frequency >> to desired value. >> >> Signed-off-by: Sachin Kamat >> --- >> drivers/clk/samsung/clk-exynos5250.c |3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > Your patch description is a bit off. It doesn't say frequency of what > clock will be able to be changed to "desired value" and what is the reason > for this change. Yes, I realize that now. Will update and resend. Thanks for review. -- 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 2/2] ARM: dts:Move fifo-depth property from cros5250-common.dtsi
Yuvaraj,
On Sun, Dec 8, 2013 at 10:38 PM, Yuvaraj Kumar C D wrote:
> Commit 64c138a ("ARM: dts: Move fifo-depth property from exynos5250
> board dts") missed out handling the exynos5250 snow dts file.
> Deletes the fifo-depth property, as this property has been moved to
> SOC specific exynos5250.dtsi file.
>
> Signed-off-by : Abhilash Kesavan
>
> Signed-off-by: Yuvaraj Kumar C D
Reviewed-by: Doug Anderson
--
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/2] ARM: dts: Fix status property of mmc nodes for snow board
Yuvaraj,
On Sun, Dec 8, 2013 at 10:38 PM, Yuvaraj Kumar C D wrote:
> Commit 0c3de788 ("ARM: dts: change status property of dwmmc nodes
> for exynos5250") missed out handling the exynos5250 snow dts file.
>
> Signed-off-by : Abhilash Kesavan
>
> Signed-off-by: Yuvaraj Kumar C D
> ---
> arch/arm/boot/dts/cros5250-common.dtsi |4
> arch/arm/boot/dts/exynos5250-snow.dts |9 +
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> b/arch/arm/boot/dts/cros5250-common.dtsi
> index 6470536..1ceb62e 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -247,10 +247,6 @@
> };
> };
>
> - mmc@1221 {
> - status = "disabled";
> - };
> -
> mmc@1222 {
> num-slots = <1>;
> supports-highspeed;
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index a9395c4..67484d1 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -171,11 +171,20 @@
> };
> };
>
> + mmc@1220 {
> + status = "okay";
> + };
> +
> + mmc@1222 {
> + status = "okay";
> + };
> +
I probably would have put the 1220 and 1222 ones in
cros5250-common since that's where all of the other stuff relating to
those ports is. Some of it may need to be moved around once we get
the HP Chromebook 11 (exynos5250-spring) in place, but until then it
seems best to keep it all together.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: EXYNOS: pmu: Constify data tables
On Tuesday 10 of December 2013 00:11:40 Daniel Kurtz wrote: > Hi Tomasz, > > Thank you for the reviews. > > On Dec 9, 2013 5:15 AM, "Tomasz Figa" wrote: > > > > Hi Daniel, > > > > On Thursday 21 of November 2013 02:21:24 Daniel Kurtz wrote: > > > These tables are all immutable, make them const to save 4416 bytes of RAM. > > > > > > size arch/arm/mach-exynos/pmu.o > > >text data bss > > > 848 4420 4 // before > > >5264 4 4 // after > > > > I'm not sure where the mentioned saving of RAM is. Moving data between > > sections is not supposed to make it use less memory, I believe. > > You are correct. This was my misunderstanding from doing too much > work with microcontrollers, where .text sections are accessed in place > from FLASH for code and const data, but .data memory is copied from a > FLASH section to a second RAM section at init for access at runtime. > Most modern Linux systems copy/decompress their code and data sections > from external storage to RAM anyway, so there is no actual memory > savings (except potentially the compiler may be able to optimize a bit > more with the const hint). > > > > > Anyway, it's a good practice to mark constant data as const, to disallow > > changing them at runtime by mistake, so the patch is fine. Except some > > issues I commented on inline. > > Were there supposed to be inline comments? I don't see any. Oops, sorry for this, forgot to remove the last sentence. I initially had one question about the constant pointers below, but I read through the full code again and answered it myself. The patch is fine. Reviewed-by: Tomasz Figa 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 1/3] ARM: EXYNOS: pmu: Constify data tables
Hi Tomasz, Thank you for the reviews. On Dec 9, 2013 5:15 AM, "Tomasz Figa" wrote: > > Hi Daniel, > > On Thursday 21 of November 2013 02:21:24 Daniel Kurtz wrote: > > These tables are all immutable, make them const to save 4416 bytes of RAM. > > > > size arch/arm/mach-exynos/pmu.o > >text data bss > > 848 4420 4 // before > >5264 4 4 // after > > I'm not sure where the mentioned saving of RAM is. Moving data between > sections is not supposed to make it use less memory, I believe. You are correct. This was my misunderstanding from doing too much work with microcontrollers, where .text sections are accessed in place from FLASH for code and const data, but .data memory is copied from a FLASH section to a second RAM section at init for access at runtime. Most modern Linux systems copy/decompress their code and data sections from external storage to RAM anyway, so there is no actual memory savings (except potentially the compiler may be able to optimize a bit more with the const hint). > > Anyway, it's a good practice to mark constant data as const, to disallow > changing them at runtime by mistake, so the patch is fine. Except some > issues I commented on inline. Were there supposed to be inline comments? I don't see any. Best Regards, -djk > > Reviewed-by: Tomasz Figa > > 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 v4] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
Hi Naveen, On Tuesday 26 of November 2013 09:52:46 Naveen Krishna Chatradhi wrote: > For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based > on a fixed 66 MHz peripheral clock, and therefore is completely > independent of the cpu frequency. > Thus, registering for a CPU freq notifier is very wasteful. > > This patch modifes the code such that, i2c bus registers to > cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled. > > This change should save a bunch of cpufreq transitions calls > which does not apply to exynos SoCs. > > Signed-off-by: Naveen Krishna Chatradhi > Acked-by: Kyungmin Park > Reviewed-by: Doug Anderson > --- > Changes since v3: > As per discussion at https://patchwork.kernel.org/patch/3235091/ > Post f023f8dd59 commit we should be using > ARM_S3C24XX_CPUFREQ instead of CPU_FREQ_S3C24XX > > upstrea linux kernel and linuxsamsung already has the commit > f023f8dd59. Hence, rebasing the patch. > > drivers/i2c/busses/i2c-s3c2410.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Tomasz Figa Wolfram, are you okay with this patch? 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] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
On Mon, 9 Dec 2013, Vikas Sajjan wrote: > Does warm reset while activating SuperSpeed HUBs if the hub activate type > is HUB_RESET_RESUME. > > When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend > USB 3.0 device connected on 3.0 port, during resume I noticed that the > XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE. > This behaviour is inconsistent and the connection with connected USB 3.0 > device > on 3.0 port was LOST. > > Doing warm reset while activating SuperSpeed HUBs if the hub > activate type is HUB_RESET_RESUME, gets the connected device to the stable > state. > > Reviewed at https://chromium-review.googlesource.com/#/c/177132/ > > Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device > (8564:1000) > > rebased on Greg Kroah-Hartman's usb-next > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git > > Signed-off-by: Vikas Sajjan > --- > drivers/usb/core/hub.c | 41 + > 1 file changed, 25 insertions(+), 16 deletions(-) > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index a7c04e2..d8432b0 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum > hub_activation_type type) > u16 portstatus, portchange; > > portstatus = portchange = 0; > + > + /* Some connected devices might be still in unknown state even > + * after reset-resume, a WARM_RESET gets the connected device > + * to the normal state. > + */ > + if (udev && hub_is_superspeed(hub->hdev) && > + type == HUB_RESET_RESUME) > + hub_port_reset(hub, port1, NULL, > + HUB_BH_RESET_TIME, true); Please don't do this all the time to every attached port. Do it only when it is really needed. Shouldn't you pass udev as the third argument? If not, please explain why not. Finally, I don't see why you put this in hub_activate(). Isn't it more closely connected with the reset-resume procedure for the child device? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: Leave Exynos5250 SPI controller disabled by default
Hi Kukjin, On Monday 25 of November 2013 12:15:08 Mark Brown wrote: > From: Mark Brown > > Rather than requiring each board to explicitly disable the SPI controllers > it is not using instead require boards to enable those that they are using. > This is less work overall since normally at most one of the controllers is > in use and avoids issues caused by inappropriate pinmuxing. > > Signed-off-by: Mark Brown > Acked-by: Tomasz Figa > --- > arch/arm/boot/dts/cros5250-common.dtsi| 9 + > arch/arm/boot/dts/exynos5250-arndale.dts | 12 > arch/arm/boot/dts/exynos5250-smdk5250.dts | 6 ++ > arch/arm/boot/dts/exynos5250.dtsi | 3 +++ > 4 files changed, 6 insertions(+), 24 deletions(-) Seems like you have missed this series. Could you apply it? 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
[PATCH 2/5] phy: add support for indexed lookup
Removes the need for the consumer drivers requesting the
phys to provide name for the phy. This should ease the use
of the framework considerable when using only one phy, which
is usually the case when except with USB, but it can also
be useful with multiple phys.
This will also reduce noise from the framework when there is
no phy by changing warnings to debug messages.
Signed-off-by: Heikki Krogerus
---
drivers/phy/phy-core.c | 106 ++--
include/linux/phy/phy.h | 14 +++
2 files changed, 89 insertions(+), 31 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 1102aef..99dc046 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -53,7 +53,8 @@ static int devm_phy_match(struct device *dev, void *res, void
*match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *con_id)
+static struct phy *phy_lookup(struct device *device, const char *con_id,
+ unsigned int idx)
{
unsigned int count;
struct phy *phy;
@@ -67,6 +68,10 @@ static struct phy *phy_lookup(struct device *device, const
char *con_id)
count = phy->init_data->num_consumers;
consumers = phy->init_data->consumers;
while (count--) {
+ /* index must always match exactly */
+ if (!con_id)
+ if (idx != count)
+ continue;
if (!strcmp(consumers->dev_name, dev_name(device)) &&
!strcmp(consumers->port, con_id)) {
class_dev_iter_exit(&iter);
@@ -242,7 +247,8 @@ EXPORT_SYMBOL_GPL(phy_power_off);
/**
* of_phy_get() - lookup and obtain a reference to a phy by phandle
* @dev: device that requests this phy
- * @index: the index of the phy
+ * @con_id: name of the phy from device's point of view
+ * @idx: the index of the phy if name is not used
*
* Returns the phy associated with the given phandle value,
* after getting a refcount to it or -ENODEV if there is no such phy or
@@ -250,12 +256,20 @@ EXPORT_SYMBOL_GPL(phy_power_off);
* not yet loaded. This function uses of_xlate call back function provided
* while registering the phy_provider to find the phy instance.
*/
-static struct phy *of_phy_get(struct device *dev, int index)
+static struct phy *of_phy_get(struct device *dev, const char *con_id,
+ unsigned int idx)
{
int ret;
struct phy_provider *phy_provider;
struct phy *phy = NULL;
struct of_phandle_args args;
+ int index;
+
+ if (!con_id)
+ index = idx;
+ else
+ index = of_property_match_string(dev->of_node, "phy-names",
+con_id);
ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
index, &args);
@@ -348,38 +362,36 @@ struct phy *of_phy_simple_xlate(struct device *dev,
struct of_phandle_args
EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
/**
- * phy_get() - lookup and obtain a reference to a phy.
+ * phy_get_index() - obtain a phy based on index
* @dev: device that requests this phy
* @con_id: name of the phy from device's point of view
+ * @idx: index of the phy to obtain in the consumer
*
- * Returns the phy driver, after getting a refcount to it; or
- * -ENODEV if there is no such phy. The caller is responsible for
- * calling phy_put() to release that count.
+ * This variant of phy_get() allows to access PHYs other than the first
+ * defined one for functions that define several PHYs.
*/
-struct phy *phy_get(struct device *dev, const char *con_id)
+struct phy *phy_get_index(struct device *dev, const char *con_id,
+ unsigned int idx)
{
- int index = 0;
struct phy *phy = NULL;
- if (con_id == NULL) {
- dev_WARN(dev, "missing string\n");
- return ERR_PTR(-EINVAL);
+ if (dev->of_node) {
+ dev_dbg(dev, "using device tree for PHY lookup\n");
+ phy = of_phy_get(dev, con_id, idx);
}
- if (dev->of_node) {
- index = of_property_match_string(dev->of_node, "phy-names",
-con_id);
- phy = of_phy_get(dev, index);
- if (IS_ERR(phy)) {
- dev_err(dev, "unable to find phy\n");
- return phy;
- }
- } else {
- phy = phy_lookup(dev, con_id);
- if (IS_ERR(phy)) {
- dev_err(dev, "unable to find phy\n");
- return phy;
- }
+ /**
+* Either we are not using DT, or their lookup did not return
+* a result. In that case, use platform lookup a
[PATCH 1/5] phy: unify the phy name parameters
Replace "string" and "port" that are used as phy name
parameter for various functions with "con_id" which is
commonly used in other frameworks.
Signed-off-by: Heikki Krogerus
---
drivers/phy/phy-core.c | 22 ++
include/linux/phy/phy.h | 8
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 03cf8fb..1102aef 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -53,7 +53,7 @@ static int devm_phy_match(struct device *dev, void *res, void
*match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
+static struct phy *phy_lookup(struct device *device, const char *con_id)
{
unsigned int count;
struct phy *phy;
@@ -68,7 +68,7 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
consumers = phy->init_data->consumers;
while (count--) {
if (!strcmp(consumers->dev_name, dev_name(device)) &&
- !strcmp(consumers->port, port)) {
+ !strcmp(consumers->port, con_id)) {
class_dev_iter_exit(&iter);
return phy;
}
@@ -350,33 +350,32 @@ EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
/**
* phy_get() - lookup and obtain a reference to a phy.
* @dev: device that requests this phy
- * @string: the phy name as given in the dt data or the name of the controller
- * port for non-dt case
+ * @con_id: name of the phy from device's point of view
*
* Returns the phy driver, after getting a refcount to it; or
* -ENODEV if there is no such phy. The caller is responsible for
* calling phy_put() to release that count.
*/
-struct phy *phy_get(struct device *dev, const char *string)
+struct phy *phy_get(struct device *dev, const char *con_id)
{
int index = 0;
struct phy *phy = NULL;
- if (string == NULL) {
+ if (con_id == NULL) {
dev_WARN(dev, "missing string\n");
return ERR_PTR(-EINVAL);
}
if (dev->of_node) {
index = of_property_match_string(dev->of_node, "phy-names",
- string);
+con_id);
phy = of_phy_get(dev, index);
if (IS_ERR(phy)) {
dev_err(dev, "unable to find phy\n");
return phy;
}
} else {
- phy = phy_lookup(dev, string);
+ phy = phy_lookup(dev, con_id);
if (IS_ERR(phy)) {
dev_err(dev, "unable to find phy\n");
return phy;
@@ -395,14 +394,13 @@ EXPORT_SYMBOL_GPL(phy_get);
/**
* devm_phy_get() - lookup and obtain a reference to a phy.
* @dev: device that requests this phy
- * @string: the phy name as given in the dt data or phy device name
- * for non-dt case
+ * @con_id: name of the phy from device's point of view
*
* Gets the phy using phy_get(), and associates a device with it using
* devres. On driver detach, release function is invoked on the devres data,
* then, devres data is freed.
*/
-struct phy *devm_phy_get(struct device *dev, const char *string)
+struct phy *devm_phy_get(struct device *dev, const char *con_id)
{
struct phy **ptr, *phy;
@@ -410,7 +408,7 @@ struct phy *devm_phy_get(struct device *dev, const char
*string)
if (!ptr)
return ERR_PTR(-ENOMEM);
- phy = phy_get(dev, string);
+ phy = phy_get(dev, con_id);
if (!IS_ERR(phy)) {
*ptr = phy;
devres_add(dev, ptr);
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 6d72269..d67dcbf 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -127,8 +127,8 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
-struct phy *phy_get(struct device *dev, const char *string);
-struct phy *devm_phy_get(struct device *dev, const char *string);
+struct phy *phy_get(struct device *dev, const char *con_id);
+struct phy *devm_phy_get(struct device *dev, const char *con_id);
void phy_put(struct phy *phy);
void devm_phy_put(struct device *dev, struct phy *phy);
struct phy *of_phy_simple_xlate(struct device *dev,
@@ -199,12 +199,12 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
-static inline struct phy *phy_get(struct device *dev, const char *string)
+static inline struct phy *phy_get(struct device *dev, const char *con_id)
{
return ERR_PTR(-ENOSYS);
}
-static inline struct phy *devm_phy_get(struct device *dev, const char *string)
+static inline struct phy *devm_phy_get(struct device *dev, const char *con_id)
{
return ERR_PTR
[PATCH 3/5] phy: improved lookup method
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from gpiolib.c.
Signed-off-by: Heikki Krogerus
---
drivers/phy/phy-core.c | 91 -
include/linux/phy/phy.h | 48 ++
2 files changed, 138 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 99dc046..05792d0 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -25,6 +25,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phy_lookup_list);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -85,6 +86,94 @@ static struct phy *phy_lookup(struct device *device, const
char *con_id,
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_add_table() - register PHY/device association to the lookup list
+ * @table: association to register
+ */
+void phy_add_lookup_table(struct phy_lookup_table *table)
+{
+ mutex_lock(&phy_provider_mutex);
+ list_add_tail(&table->list, &phy_lookup_list);
+ mutex_unlock(&phy_provider_mutex);
+}
+
+/**
+ * phy_add_table() - remove PHY/device association from the lookup list
+ * @table: association to be removed
+ */
+void phy_del_lookup_table(struct phy_lookup_table *table)
+{
+ mutex_lock(&phy_provider_mutex);
+ list_del(&table->list);
+ mutex_unlock(&phy_provider_mutex);
+}
+
+static struct phy *find_phy_by_name(const char *name)
+{
+ struct class_dev_iter iter;
+ struct phy *phy = NULL;
+ struct device *dev;
+
+ class_dev_iter_init(&iter, phy_class, NULL, NULL);
+ while ((dev = class_dev_iter_next(&iter))) {
+ if (!strcmp(dev_name(dev), name)) {
+ phy = to_phy(dev);
+ break;
+ }
+ }
+ class_dev_iter_exit(&iter);
+
+ return phy;
+}
+
+static struct phy_lookup_table *phy_get_lookup_table(struct device *dev)
+{
+ const char *dev_id = dev ? dev_name(dev) : NULL;
+ struct phy_lookup_table *table;
+
+ mutex_lock(&phy_provider_mutex);
+ list_for_each_entry(table, &phy_lookup_list, list)
+ if (!strcmp(table->dev_id, dev_id))
+ goto out;
+ table = NULL;
+out:
+ mutex_unlock(&phy_provider_mutex);
+ return table;
+}
+
+static struct phy *phy_find(struct device *dev, const char *con_id,
+ unsigned int idx)
+{
+ struct phy_lookup_table *table;
+ struct phy_lookup *p;
+ struct phy *phy;
+
+ table = phy_get_lookup_table(dev);
+ if (!table)
+ /* fall-back to the old lookup method for now */
+ return phy_lookup(dev, con_id, idx);
+
+ for (p = &table->table[0]; p->phy_name; p++) {
+ /* index must always match exactly */
+ if (idx != p->idx)
+ continue;
+
+ /* If the lookup entry has a con_id, require exact match */
+ if (p->con_id && (!con_id || strcmp(p->con_id, con_id)))
+ continue;
+
+ phy = find_phy_by_name(p->phy_name);
+ if (!phy) {
+ dev_warn(dev, "no PHY by the name %s\n", p->phy_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
{
struct phy_provider *phy_provider;
@@ -386,7 +475,7 @@ struct phy *phy_get_index(struct device *dev, const char
*con_id,
*/
if (!phy || IS_ERR(phy)) {
dev_dbg(dev, "using lookup tables for PHY lookup");
- phy = phy_lookup(dev, con_id, idx);
+ phy = phy_find(dev, con_id, idx);
}
if (IS_ERR(phy)) {
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 43d1a23..cca363a 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -98,6 +98,54 @@ struct phy_init_data {
.port = _port,\
}
+/**
+ * struct phy_lookup - Lookup entry for associating PHYs
+ * @phy_name: device name of the PHY
+ * @con_id: name of the PHY from device's point of view
+ * @idx: index of the PHY when name is not used
+ */
+struct phy_lookup {
+ const char *phy_name;
+ const char *con_id;
+ unsigned int idx;
+};
+
+/**
+ * struct phy_lookup_table - association of PHYs to specific device
+ * @list: entry in the lookup list
+ * @dev_id: the name of the device
+ * @table: table of PHYs attached to this device
+ */
+struct phy_lookup_table {
+ struct list_head list;
+ const char *dev_id;
+ struct phy_lookup table[];
+};
+
+/**
+ * Simple definition of a single PHY under a consumer
+ */
+#define PHY_LOOKUP(_ph
[PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
Provide a complete association for the phy and it's user
(musb) with the new phy_lookup_table.
Signed-off-by: Heikki Krogerus
---
arch/arm/mach-omap2/twl-common.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..972430b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER("musb-hdrc.0", "usb"),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup_table twl4030_usb_lookup = {
+ .dev_id = "musb-hdrc.0",
+ .table = PHY_LOOKUP("phy-twl4030_usb.0", NULL),
};
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
- .init_data = &init_data,
};
static int omap3_batt_table[] = {
@@ -225,8 +220,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
+ if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb) {
+ phy_add_lookup_table(&twl4030_usb_lookup);
pmic_data->usb = &omap3_usb_pdata;
+ }
if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci)
pmic_data->bci = &omap3_bci_pdata;
--
1.8.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus
---
Documentation/phy.txt | 100 ++--
drivers/phy/phy-core.c | 46 ++---
drivers/phy/phy-exynos-dp-video.c | 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-twl4030-usb.c | 4 +-
include/linux/phy/phy.h | 36 ++---
7 files changed, 73 insertions(+), 119 deletions(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index 0103e4b..cfff1a2 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -53,17 +53,13 @@ unregister the PHY.
The PHY driver should create the PHY in order for other peripheral controllers
to make use of it. The PHY framework provides 2 APIs to create the PHY.
-struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
-struct phy_init_data *init_data);
-struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
- struct phy_init_data *init_data);
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops);
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops);
The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, phy ops and init_data.
+the device pointer, phy ops.
phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *init_data* is mandatory to get a reference
-to the PHY in the case of non-dt boot. See section *Board File Initialization*
-on how init_data should be used.
+init, exit, power_on and power_off.
Inorder to dereference the private data (in phy_ops), the phy provider driver
can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
@@ -74,16 +70,21 @@ phy_ops to get back the private data.
Before the controller can make use of the PHY, it has to get a reference to
it. This framework provides the following APIs to get a reference to the PHY.
-struct phy *phy_get(struct device *dev, const char *string);
-struct phy *devm_phy_get(struct device *dev, const char *string);
+struct phy *phy_get(struct device *dev, const char *con_id);
+struct phy *devm_phy_get(struct device *dev, const char *con_id);
phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
-the string arguments should contain the phy name as given in the dt data and
+the con_id arguments should contain the phy name as given in the dt data and
in the case of non-dt boot, it should contain the label of the PHY.
The only difference between the two APIs is that devm_phy_get associates the
device with the PHY using devres on successful PHY get. On driver detach,
release function is invoked on the the devres data and devres data is freed.
+Indexed lookup is also possible when device has multiple PHYs attached to it.
+The framework provides variants for phy_get() functions called phy_get_index()
+and devm_phy_get_index(). They take the same parameters as do the normal
+phy_get() plus the index number of the PHY as the last parameter.
+
5. Releasing a reference to the PHY
When the controller no longer needs the PHY, it has to release the reference
@@ -123,42 +124,63 @@ There are exported APIs like phy_pm_runtime_get,
phy_pm_runtime_get_sync,
phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
phy_pm_runtime_forbid for performing PM operations.
-8. Board File Initialization
+8. Platform Data binding
-Certain board file initialization is necessary in order to get a reference
-to the PHY in the case of non-dt boot.
-Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
-then in the board file the following initialization should be done.
+PHY's are mapped by the means of tables of lookups, containing instances of the
+phy_lookup structure. Two macros are defined to help declaring such mappings:
-struct phy_consumer consumers[] = {
- PHY_CONSUMER("dwc3.0", "usb"),
- PHY_CONSUMER("pcie.0", "pcie"),
- PHY_CONSUMER("sata.0", "sata"),
-};
-PHY_CONSUMER takes 2 parameters, first is the device name of the controller
-(PHY consumer) and second is the port name.
+ PHY_LOOKUP(phy_name, con_id)
+ PHY_LOOKUP_IDX(phy_name, con_id, idx)
+
+where
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+ - phy_name identifiers of the phy device
+ - con_id is the name of the PHY from the device point of view. It can be
NULL.
+ - idx is the index of the PHY within the function.
+
+A lookup table can then be defined as follows, with an empty entry defining its
+end:
+
+struct phy_lookup_table phys_table = {
+ .dev_id = "usb_controller.0",
+ .table = {
+ PHY_LOOKUP_IDX("phy-usb2phy.0", "usb2-phy", 0),
+ PHY_LOOKUP_IDX("phy-usb3phy.0", "usb3-ph
[PATCH 0/5] phy: remove the need for the phys to know about their users
Hi, This replaces the consumer & init_data structures with a lookup table that contains complete associations with the phys and their users, removing the need for the phy drivers themselves to care about their users even when not using DT. The lookup method is copied from the way the gpio descriptor lookup is now handled in gpiolib.c. Heikki Krogerus (5): phy: unify the phy name parameters phy: add support for indexed lookup phy: improved lookup method arm: omap3: twl: use the new lookup method with usb phy phy: remove the old lookup method arch/arm/mach-omap2/twl-common.c| 15 ++- drivers/phy/phy-core.c | 209 ++-- drivers/phy/phy-exynos-dp-video.c | 2 +- drivers/phy/phy-exynos-mipi-video.c | 2 +- drivers/phy/phy-omap-usb2.c | 2 +- drivers/phy/phy-twl4030-usb.c | 4 +- include/linux/phy/phy.h | 86 ++- 7 files changed, 221 insertions(+), 99 deletions(-) -- 1.8.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/9] phy: Add new Exynos USB PHY driver
Hi,
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Monday, December 09, 2013 8:56 AM
>
> Hi,
>
> On Friday 06 December 2013 09:58 PM, Kamil Debski wrote:
> > Hi Kishon,
> >
> > Thank you for the review.
> >
> >> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> >> Sent: Friday, December 06, 2013 11:59 AM
> >>
> >> Hi,
> >>
> >> On Thursday 05 December 2013 05:59 PM, Kamil Debski wrote:
> >>> Add a new driver for the Exynos USB PHY. The new driver uses the
> >>> generic PHY framework. The driver includes support for the Exynos
> >> 4x10
> >>> and 4x12 SoC families.
> >>>
> >>> Signed-off-by: Kamil Debski
> >>> Signed-off-by: Kyungmin Park
> >>> ---
>
>
>
> .
> .
> >>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
> >>> d0caae9..9f4befd 100644
> >>> --- a/drivers/phy/Makefile
> >>> +++ b/drivers/phy/Makefile
> >>> @@ -7,3 +7,6 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-
> exynos-dp-
> >> video.o
> >>> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-
> video.o
> >>> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> >>> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
> >>> +obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-samsung-usb2.o
> >>> +obj-$(CONFIG_PHY_EXYNOS4210_USB2)+= phy-exynos4210-usb2.o
> >>> +obj-$(CONFIG_PHY_EXYNOS4212_USB2)+= phy-exynos4212-usb2.o
> >>> diff --git a/drivers/phy/phy-exynos4210-usb2.c
> >>> b/drivers/phy/phy-exynos4210-usb2.c
> >>> new file mode 100644
> >>> index 000..a02e5c2
> >>> --- /dev/null
> >>> +++ b/drivers/phy/phy-exynos4210-usb2.c
> >>> @@ -0,0 +1,264 @@
> >>> +/*
> >>> + * Samsung SoC USB 1.1/2.0 PHY driver - Exynos 4210 support
> >>> + *
> >>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> >>> + * Author: Kamil Debski
> >>> + *
> >>> + * This program is free software; you can redistribute it and/or
> >>> +modify
> >>> + * it under the terms of the GNU General Public License version 2
> >>> +as
> >>> + * published by the Free Software Foundation.
> >>> + */
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>
> >> You've included most of the above header files in phy-samsung-usb2.h
> >> which you are including below.
> >
> > I agree that includes in phy-samsung-usb2.h could use a cleanup. On
> > the other hand my opinion is that a .c file should include all .h
> > files that are used in this .c file. Relaying on .h file to include
> > another .h doesn't seem good to me.
>
> then remove it in .h file.
> >
> >>> +#include "phy-samsung-usb2.h"
> >>> +
> >>> +/* Exynos USB PHY registers */
> >>> +
> >>> +/* PHY power control */
> >>> +#define EXYNOS_4210_UPHYPWR 0x0
> >>> +
> >>> +#define EXYNOS_4210_UPHYPWR_PHY0_SUSPEND (1 << 0)
> >>
> >> use BIT() here and everywhere below.
> >
>
>
> .
> .
>
> >>> +#ifdef CONFIG_PHY_EXYNOS4212_USB2
> >>> + {
> >>> + .compatible = "samsung,exynos4212-usb2-phy",
> >>> + .data = &exynos4212_usb2_phy_config,
> >>> + },
> >>> +#endif
> >>> + { },
> >>> +};
> >>
> >> I think we've had enough discussion about this approach. Let's get
> >> the opinion of others too. Felipe? Greg?
> >
> > Good idea.
> >
> >> Summary:
> >> We have two drivers PHY_EXYNOS4210_USB2 and PHY_EXYNOS4212_USB2 with
> >> almost similar register map [1] and a samsung helper driver for
> these
> >> two drivers.
> >
> > I would not call them separate drivers. It's a single USB 2.0 driver
> > with the option to include support for various SoCs. This patchset
> adds:
> > Exynos 4210, Exynos 4212, Exynos 5250 and S5PCV210. I know that
> > another person is working on supporting S3C6410.
> >
> >> These two PHY drivers populate the function pointers in the helper
> >> driver. So any phy_ops will first invoke the helper driver which
> will
> >> then invoke the corresponding phy driver.
> >>
> >> [1] -> http://www.diffchecker.com/7yno1uvk
> >
> > Come on, this diff only includes the registers part of the file.
> > The following functions are also different:
> > - exynos421*_rate_to_clk
> > - exynos421*_isol
> > - exynos421*_phy_pwr
> > - exynos421*_power_on
> > - exynos421*_power_on
>
> But most of the differences is because your 4212 has additional
> features in HSIC and supports more clock rates.
> >
> > It seems that the file is too large for the tool. But still this
> makes
> > a false impression that only registers are different.
> >
> >> Advantages:
> >> * (more) clean and readable
> >> * helper driver can be used with other PHY drivers which will be
> >> added soon
> >>
> >> Disadvantages:
> >> * code duplication
> >
> > I would say that actually in this case less code is duplicated.
> Having
> > Separate drivers would mean that most of the phy-samsung-usb2.c file
> > has
>
> I actually meant a single driver for 4210 and 4212.
>
> your current code has separate drivers for
Re: [PATCH] clk: samsung: exynos4: Correct SRC_MFC register
Hi Seung-Woo, On Friday 22 of November 2013 14:21:08 Seung-Woo Kim wrote: > The SRC_MFC register was incorrect. This patch corrects it. > > Signed-off-by: Seung-Woo Kim > --- > drivers/clk/samsung/clk-exynos4.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Good catch. Acked-by: Tomasz Figa I guess this could go as a fix for current rc, through clk-fixes. Mike, what do you think? 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 1/1] clk: exynos5250: Add CLK_SET_RATE_PARENT flag to mout_apll
Hi Sachin, On Thursday 21 of November 2013 09:47:34 Sachin Kamat wrote: > Add CLK_SET_RATE_PARENT flag to be able to change the frequency > to desired value. > > Signed-off-by: Sachin Kamat > --- > drivers/clk/samsung/clk-exynos5250.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Your patch description is a bit off. It doesn't say frequency of what clock will be able to be changed to "desired value" and what is the reason for this change. 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 2/3] ARM: SAMSUNG: Let s3c_pm_do_restore_*() take const sleep_save
Hi Daniel, On Thursday 21 of November 2013 02:21:25 Daniel Kurtz wrote: > The restore functions do not modify the passed in struct sleep_save, > so that parameter can be const. > > This allows us to pass in const struct. This allows us to use const > structs sleep_save to define system registers that will always be > restored to a constant value. > > Signed-off-by: Daniel Kurtz > --- > arch/arm/plat-samsung/include/plat/pm.h | 4 ++-- > arch/arm/plat-samsung/pm.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Tomasz Figa 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] CHROMIUM: s5p-mfc: add controls to set vp8 enc profile
Hi Arun,
Some comments below...
On 12/09/2013 02:16 PM, Arun Kumar K wrote:
> Add v4l2 controls to set desired profile for VP8 encoder.
> Acceptable levels for VP8 encoder are
> 0: Version 0
> 1: Version 1
> 2: Version 2
> 3: Version 3
>
> Signed-off-by: Pawel Osciak
> Signed-off-by: Kiran AVND
> Signed-off-by: Arun Kumar K
> ---
> This patch is rebased over another VP8 control patch from me:
> https://linuxtv.org/patch/20733/
> ---
> Documentation/DocBook/media/v4l/controls.xml|9 +
> drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 11 +++
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |6 ++
> drivers/media/v4l2-core/v4l2-ctrls.c|8
> include/uapi/linux/v4l2-controls.h |1 +
> 6 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml
> b/Documentation/DocBook/media/v4l/controls.xml
> index e4db4ac..c1f7544 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -3193,6 +3193,15 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a
> golden frame.
> Quantization parameter for a P frame
> for VP8.
>
>
> +
> +
> + spanname="id">V4L2_CID_MPEG_VIDEO_VPX_PROFILE
> + integer
This says 'integer' whereas the control is actually an integer menu.
Why did you choose 'integer menu' for this? Would a regular integer or perhaps
a standard
menu be better?
> +
> + Select the desired profile for VP8
> encoder.
> +Acceptable values are 0, 1, 2 and 3 corresponding to encoder versions 0, 1,
> 2 and 3.
Is it a 'profile' or a 'version'? It looks a bit confusing. I don't have the
VP8 standard,
so I can't really tell what the correct terminology is.
Also, does this control apply just to VP8 or also to other VP versions? The
control name
says 'VPX' while the description says 'VP8' explicitly.
> +
> +
>
>
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index d91f757..797e61d 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -426,6 +426,7 @@ struct s5p_mfc_vp8_enc_params {
> u8 rc_max_qp;
> u8 rc_frame_qp;
> u8 rc_p_frame_qp;
> + u8 profile;
> };
>
> /**
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 33e8ae3..ec0581c 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -650,6 +650,14 @@ static struct mfc_control controls[] = {
> .step = 1,
> .default_value = 10,
> },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
> + .type = V4L2_CTRL_TYPE_INTEGER_MENU,
> + .minimum = 0,
> + .maximum = 3,
> + .step = 1,
> + .default_value = 0,
> + },
> };
>
> #define NUM_CTRLS ARRAY_SIZE(controls)
> @@ -1601,6 +1609,9 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:
> p->codec.vp8.rc_p_frame_qp = ctrl->val;
> break;
> + case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + p->codec.vp8.profile = ctrl->val;
> + break;
> default:
> v4l2_err(&dev->v4l2_dev, "Invalid control, id=%d, val=%d\n",
> ctrl->id, ctrl->val);
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index b4886d6..f6ff2db 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -1197,10 +1197,8 @@ static int s5p_mfc_set_enc_params_vp8(struct
> s5p_mfc_ctx *ctx)
> reg |= ((p->num_b_frame & 0x3) << 16);
> WRITEL(reg, S5P_FIMV_E_GOP_CONFIG_V6);
>
> - /* profile & level */
> - reg = 0;
> - /** profile */
> - reg |= (0x1 << 4);
> + /* profile - 0 ~ 3 */
> + reg = p_vp8->profile & 0x3;
> WRITEL(reg, S5P_FIMV_E_PICTURE_PROFILE_V6);
>
> /* rate control config. */
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 20840df..5069dd2 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -575,11 +575,17 @@ const s64 *v4l2_ctrl_get_int_menu(u32 id, u32 *len)
> 1, 2, 3,
> };
>
> + static const s64 qmenu_int_vpx_profile[] = {
> + 0, 1, 2, 3,
> + };
> +
> switch (id) {
> case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:
> return __v4l2_qmenu_int_len(qmenu_in
[PATCH] CHROMIUM: s5p-mfc: add controls to set vp8 enc profile
Add v4l2 controls to set desired profile for VP8 encoder.
Acceptable levels for VP8 encoder are
0: Version 0
1: Version 1
2: Version 2
3: Version 3
Signed-off-by: Pawel Osciak
Signed-off-by: Kiran AVND
Signed-off-by: Arun Kumar K
---
This patch is rebased over another VP8 control patch from me:
https://linuxtv.org/patch/20733/
---
Documentation/DocBook/media/v4l/controls.xml|9 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 11 +++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |6 ++
drivers/media/v4l2-core/v4l2-ctrls.c|8
include/uapi/linux/v4l2-controls.h |1 +
6 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index e4db4ac..c1f7544 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3193,6 +3193,15 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a
golden frame.
Quantization parameter for a P frame
for VP8.
+
+
+ V4L2_CID_MPEG_VIDEO_VPX_PROFILE
+ integer
+
+ Select the desired profile for VP8
encoder.
+Acceptable values are 0, 1, 2 and 3 corresponding to encoder versions 0, 1, 2
and 3.
+
+
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index d91f757..797e61d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -426,6 +426,7 @@ struct s5p_mfc_vp8_enc_params {
u8 rc_max_qp;
u8 rc_frame_qp;
u8 rc_p_frame_qp;
+ u8 profile;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 33e8ae3..ec0581c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -650,6 +650,14 @@ static struct mfc_control controls[] = {
.step = 1,
.default_value = 10,
},
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
+ .type = V4L2_CTRL_TYPE_INTEGER_MENU,
+ .minimum = 0,
+ .maximum = 3,
+ .step = 1,
+ .default_value = 0,
+ },
};
#define NUM_CTRLS ARRAY_SIZE(controls)
@@ -1601,6 +1609,9 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:
p->codec.vp8.rc_p_frame_qp = ctrl->val;
break;
+ case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ p->codec.vp8.profile = ctrl->val;
+ break;
default:
v4l2_err(&dev->v4l2_dev, "Invalid control, id=%d, val=%d\n",
ctrl->id, ctrl->val);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index b4886d6..f6ff2db 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1197,10 +1197,8 @@ static int s5p_mfc_set_enc_params_vp8(struct s5p_mfc_ctx
*ctx)
reg |= ((p->num_b_frame & 0x3) << 16);
WRITEL(reg, S5P_FIMV_E_GOP_CONFIG_V6);
- /* profile & level */
- reg = 0;
- /** profile */
- reg |= (0x1 << 4);
+ /* profile - 0 ~ 3 */
+ reg = p_vp8->profile & 0x3;
WRITEL(reg, S5P_FIMV_E_PICTURE_PROFILE_V6);
/* rate control config. */
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 20840df..5069dd2 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -575,11 +575,17 @@ const s64 *v4l2_ctrl_get_int_menu(u32 id, u32 *len)
1, 2, 3,
};
+ static const s64 qmenu_int_vpx_profile[] = {
+ 0, 1, 2, 3,
+ };
+
switch (id) {
case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:
return __v4l2_qmenu_int_len(qmenu_int_vpx_num_partitions, len);
case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
return __v4l2_qmenu_int_len(qmenu_int_vpx_num_ref_frames, len);
+ case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ return __v4l2_qmenu_int_len(qmenu_int_vpx_profile, len);
default:
*len = 0;
return NULL;
@@ -749,6 +755,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_MAX_QP:return "VPX
Maximum QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP:return "VPX
I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX
P-Frame QP Value";
+ case V4L2_
Re: [PATCH 1/3] ARM: EXYNOS: pmu: Constify data tables
Hi Daniel, On Thursday 21 of November 2013 02:21:24 Daniel Kurtz wrote: > These tables are all immutable, make them const to save 4416 bytes of RAM. > > size arch/arm/mach-exynos/pmu.o >text data bss > 848 4420 4 // before >5264 4 4 // after I'm not sure where the mentioned saving of RAM is. Moving data between sections is not supposed to make it use less memory, I believe. Anyway, it's a good practice to mark constant data as const, to disallow changing them at runtime by mistake, so the patch is fine. Except some issues I commented on inline. Reviewed-by: Tomasz Figa 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 4/4 v3] ARM: dts: Exynos5420: Add device nodes for TMU blocks
Hi Naveen,
On Tuesday 12 of November 2013 12:07:48 Naveen Krishna Chatradhi wrote:
> Exynos5420 SoC has per core thermal management unit.
> 5 TMU channels 4 for CPUs and 5th for GPU.
>
> This patch adds the device tree nodes to the DT device list.
>
> Nodes carry the misplaced second base address and the second
> clock to access the misplaced base address.
>
> Signed-off-by: Leela Krishna Amudala
> Signed-off-by: Naveen Krishna Chatradhi
> Signed-off-by: Andrew Bresticker
> ---
> Changes since v2:
> 3. uses the new compatible strings introduced along with adding
>support for Exynso5420.
>
> Changes since v1:
> 1. Nodes carry the misplaced second base address and the second
>clock to access the misplaced base address.
> 2. Correct the clock number for the TMU4
>
> arch/arm/boot/dts/exynos5420.dtsi | 48
> +
> 1 file changed, 48 insertions(+)
In addition to updating to reflect my comments to patch 3/4, please also
see my comments inline.
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 6ffefd1..d736b40 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -369,4 +369,52 @@
> clock-names = "gscl";
> samsung,power-domain = <&gsc_pd>;
> };
> +
> + /* tmu for CPU0 */
> + tmu@1006 {
Instead of the comment, it might be better to add a label to the node,
such as
tmu_cpu0: tmu@1006 {
for TMU of CPU0 and so on.
> + compatible = "samsung,exynos5420-tmu";
> + reg = <0x1006 0x100>;
> + interrupts = <0 65 0>;
> + clocks = <&clock 318>;
> + clock-names = "tmu_apbif";
> + };
> +
> + /* tmu for CPU1 */
> + tmu@10064000 {
> + compatible = "samsung,exynos5420-tmu";
> + reg = <0x10064000 0x100>;
> + interrupts = <0 183 0>;
> + clocks = <&clock 318>;
> + clock-names = "tmu_apbif";
> + };
> +
> + /* tmu for CPU2 */
> + tmu@10068000 {
> + compatible = "samsung,exynos5420-tmu-triminfo";
> + /* 2nd reg is for the misplaced TRIMINFO register */
Hmm, I'm not convinced about usefulness of this comment. Used compatible
value directly implies the meaning of all reg entries.
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Fri, Dec 6, 2013 at 12:54 AM, Stephen Warren wrote: > On 12/03/2013 02:29 AM, Linus Walleij wrote: (skipped the conversation on weak hogs, we are on the same page here, just waiting for someone to start working on it ...) > Related, I prefer to put /all/ static pinctrl configuration into the > pinctrl device's "default" state (i.e. use a hog) rather than > configuring the static pinctrl setup per device, for another reason too: > > If a particular IO controller's signals can be routed to n different > (sets of) pins, then we need to do *both* of the following when setting > up the pinmux: > > a) Configure the pins we want to host those signals to route to/from > that particular IO controller. > > b) Configure any other pins that could route to/from that particular IO > controller as some other function; either disabled, or routed to/from > some different IO controller. > > That is so that the IO controller's RX/input signals are not connected > from two different sets of pins at once, which would cause two things to > driver them. Depending on HW, this could cause on of: > > 1) Multiple drivers -> high power usage, or even Silicon damage. > > 2) Inconsistent configuration, with the "wrong" set of pins driving the > IO controller's inputs, and hence the signals on the "correct" pins > being ignored -> hard to find bug. I'm following, I think what we need here is to think about additional behaviours and electronic constraints we can encode into the drivers and/or the pin tables to safeguard pin states from electronically unsound states. That is to say, I prefer the subsystem to be conscious about the electronic constraints and navigate around them or put up a road block, rather than trying ti avoid driving into the roadblocks by means of carefully crafted tables if you get the picture ... Yours, Linus Walleij -- 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] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
Hi Vikas,
On Mon, Dec 9, 2013 at 5:59 PM, Vikas Sajjan wrote:
few minor nits here. ;-)
> Does warm reset while activating SuperSpeed HUBs if the hub activate type
> is HUB_RESET_RESUME.
>
> When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend
> USB 3.0 device connected on 3.0 port, during resume I noticed that the
> XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE.
> This behaviour is inconsistent and the connection with connected USB 3.0
> device
> on 3.0 port was LOST.
>
> Doing warm reset while activating SuperSpeed HUBs if the hub
> activate type is HUB_RESET_RESUME, gets the connected device to the stable
> state.
>
> Reviewed at https://chromium-review.googlesource.com/#/c/177132/
>
> Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device
> (8564:1000)
>
> rebased on Greg Kroah-Hartman's usb-next
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
Above two lines may not be required in the commit message.
>
> Signed-off-by: Vikas Sajjan
> ---
> drivers/usb/core/hub.c | 41 +
> 1 file changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index a7c04e2..d8432b0 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -993,6 +993,21 @@ int usb_remove_device(struct usb_device *udev)
> return 0;
> }
>
> +#define PORT_RESET_TRIES 5
> +#define SET_ADDRESS_TRIES 2
> +#define GET_DESCRIPTOR_TRIES 2
> +#define SET_CONFIG_TRIES (2 * (use_both_schemes + 1))
> +#define USE_NEW_SCHEME(i) ((i) / 2 == (int)old_scheme_first)
> +
> +#define HUB_ROOT_RESET_TIME50 /* times are in msec */
> +#define HUB_SHORT_RESET_TIME 10
> +#define HUB_BH_RESET_TIME 50
> +#define HUB_LONG_RESET_TIME200
> +#define HUB_RESET_TIMEOUT 800
> +
> +static int hub_port_reset(struct usb_hub *hub, int port1,
> + struct usb_device *udev, unsigned int delay, bool
> warm);
> +
> enum hub_activation_type {
> HUB_INIT, HUB_INIT2, HUB_INIT3, /* INITs must come first */
> HUB_POST_RESET, HUB_RESUME, HUB_RESET_RESUME,
> @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum
> hub_activation_type type)
> u16 portstatus, portchange;
>
> portstatus = portchange = 0;
> +
> + /* Some connected devices might be still in unknown state even
Please take care of multiple line commenting style.
> +* after reset-resume, a WARM_RESET gets the connected device
> +* to the normal state.
> +*/
> + if (udev && hub_is_superspeed(hub->hdev) &&
> + type == HUB_RESET_RESUME)
> + hub_port_reset(hub, port1, NULL,
> + HUB_BH_RESET_TIME, true);
> +
> status = hub_port_status(hub, port1, &portstatus,
> &portchange);
> if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
> dev_dbg(hub->intfdev,
> @@ -2510,22 +2535,6 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
> return hcd->wireless;
> }
>
> -
> -#define PORT_RESET_TRIES 5
> -#define SET_ADDRESS_TRIES 2
> -#define GET_DESCRIPTOR_TRIES 2
> -#define SET_CONFIG_TRIES (2 * (use_both_schemes + 1))
> -#define USE_NEW_SCHEME(i) ((i) / 2 == (int)old_scheme_first)
> -
> -#define HUB_ROOT_RESET_TIME50 /* times are in msec */
> -#define HUB_SHORT_RESET_TIME 10
> -#define HUB_BH_RESET_TIME 50
> -#define HUB_LONG_RESET_TIME200
> -#define HUB_RESET_TIMEOUT 800
> -
> -static int hub_port_reset(struct usb_hub *hub, int port1,
> - struct usb_device *udev, unsigned int delay, bool
> warm);
> -
> /* Is a USB 3.0 port in the Inactive or Complinance Mode state?
> * Port worm reset is required to recover
> */
> --
> 1.7.9.5
>
> --
> 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
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4 v10] thermal: samsung: replace inten_ bit fields with intclr_
Hi Naveen, On Tuesday 19 of November 2013 18:34:19 Naveen Krishna Chatradhi wrote: > This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask > with intclr_rise_shift/mask and intclr_fall_shift/mask respectively. > Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used > to configure intclr related registers. > > Description of H/W: > The offset for the bits in the CLEAR register are not consistent across TMU > modules in Exynso5250, 5420 and 5440. > > On Exynos5250, the FALL interrupt related en, status and clear bits are > available at an offset of > 16 in INTEN, INTSTAT registers and at an offset of > 12 in INTCLEAR register. > > On Exynos5420, the FALL interrupt related en, status and clear bits are > available at an offset of > 16 in INTEN, INTSTAT and INTCLEAR registers. > > On Exynos5440, > the FALL_IRQEN bits are at an offset of 4 > and the RISE_IRQEN bits are at an offset of 0 > > Signed-off-by: Naveen Krishna Chatradhi > Acked-by: Amit Daniel Kachhap > Reviewed-by: Bartlomiej Zolnierkiewicz > --- > Changes since v9: > Just respinning > > Changes since v8: > 1. Modified the patch description, > 2. replaces the inten_rise/fall_shift/mask with intclr_rise/fall_shift/mask > > drivers/thermal/samsung/exynos_tmu.c |6 +++--- > drivers/thermal/samsung/exynos_tmu.h | 16 > drivers/thermal/samsung/exynos_tmu_data.c | 18 +- > drivers/thermal/samsung/exynos_tmu_data.h |4 ++-- > 4 files changed, 22 insertions(+), 22 deletions(-) Reviewed-by: Tomasz Figa 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 2/4 v10] thermal: samsung: change base_common to more meaningful base_second
Hi Naveen, On Tuesday 19 of November 2013 18:34:51 Naveen Krishna Chatradhi wrote: > 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 > Acked-by: Amit Daniel Kachhap > Reviewed-by: Bartlomiej Zolnierkiewicz > --- > Changes since v9: > Just respinning > > Changes since v8: > None > .../devicetree/bindings/thermal/exynos-thermal.txt |4 ++-- > drivers/thermal/samsung/exynos_tmu.c | 14 > +++--- > drivers/thermal/samsung/exynos_tmu.h |4 ++-- > drivers/thermal/samsung/exynos_tmu_data.c|2 +- > 4 files changed, 12 insertions(+), 12 deletions(-) Please see my comments inline. > 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. Just a wording issue, I think: If this is "second set of common TMU registers", then where is the first set of common TMU registers? Otherwise the patch 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
Re: [PATCH 3/4 v10] thermal: samsung: Add TMU support for Exynos5420 SoCs
Hi Naveen, On Tuesday 19 of November 2013 18:35:25 Naveen Krishna Chatradhi wrote: > Exynos5420 has 5 TMU channels, 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 > > This patch > 1 Adds the neccessary register changes and arch information >to support Exynos5420 SoCs. > 2. Handles the gate clock for misplaced TRIMINFO register > 3. Updates the Documentation at >Documentation/devicetree/bindings/thermal/exynos-thermal.txt > > Signed-off-by: Naveen Krishna Chatradhi > Signed-off-by: Andrew Bresticker > Acked-by: Amit Daniel Kachhap > Reviewed-by: Bartlomiej Zolnierkiewicz > --- > Changes since v9: > Just respinning > > Changes since v8: > 1. rewrote the Documentation for device tree bindings > 2. Merged the https://lkml.org/lkml/2013/11/7/262 (as this is a fix) > 3. introduces "samsung,exynos5420-tmu-triminfo" and >"samsung,exynos5420-tmu-triminfo-clk" to handle the TMU channels on >Exynos5420 more appropriately > > .../devicetree/bindings/thermal/exynos-thermal.txt | 45 + > drivers/thermal/samsung/exynos_tmu.c | 58 ++- > drivers/thermal/samsung/exynos_tmu.h |2 + > drivers/thermal/samsung/exynos_tmu_data.c | 106 > > drivers/thermal/samsung/exynos_tmu_data.h |8 ++ > 5 files changed, 215 insertions(+), 4 deletions(-) I have replied to previous version by mistake, but since this is just a respin, same comments apply. 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 3/4 v9] thermal: samsung: Add TMU support for Exynos5420 SoCs
Hi Naveen, Andrew, Please see my comments inline. On Tuesday 12 of November 2013 12:07:05 Naveen Krishna Chatradhi wrote: > Exynos5420 has 5 TMU channels, 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 > > This patch > 1 Adds the neccessary register changes and arch information >to support Exynos5420 SoCs. > 2. Handles the gate clock for misplaced TRIMINFO register > 3. Updates the Documentation at >Documentation/devicetree/bindings/thermal/exynos-thermal.txt > > Signed-off-by: Naveen Krishna Chatradhi > Signed-off-by: Andrew Bresticker > --- > Changes since v8: > 1. rewrote the Documentation for device tree bindings > 2. Merged the https://lkml.org/lkml/2013/11/7/262 (as this is a fix) > 3. introduces "samsung,exynos5420-tmu-triminfo" and >"samsung,exynos5420-tmu-triminfo-clk" to handle the TMU channels on >Exynos5420 more appropriately > > .../devicetree/bindings/thermal/exynos-thermal.txt | 45 + > drivers/thermal/samsung/exynos_tmu.c | 58 ++- > drivers/thermal/samsung/exynos_tmu.h |2 + > drivers/thermal/samsung/exynos_tmu_data.c | 106 > > drivers/thermal/samsung/exynos_tmu_data.h |8 ++ > 5 files changed, 215 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > index 116cca0..5055b31 100644 > --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > @@ -6,6 +6,11 @@ > "samsung,exynos4412-tmu" > "samsung,exynos4210-tmu" > "samsung,exynos5250-tmu" > +"samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420 > +"samsung,exynos5420-tmu-triminfo" for TMU channel 2 Exynos5420 > + (Must pass triminfo base) > +"samsung,exynos5420-tmu-triminfo-clk" for TMU channel 3 and 4 > + Exynos5420 (Must pass triminfo base and triminfo clock) I don't think you need those two separate compatible values. Instead you can keep only the one that requires clock and specify the same base clock as triminfo clock. Also IMHO "samsung,exynos5420-tmu-ext-triminfo" would be a better name, as it describes the hardware better (TMU with external triminfo block, as opposed to normal TMU that has it internally). Otherwise the patch 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
[PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
Does warm reset while activating SuperSpeed HUBs if the hub activate type
is HUB_RESET_RESUME.
When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend
USB 3.0 device connected on 3.0 port, during resume I noticed that the
XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE.
This behaviour is inconsistent and the connection with connected USB 3.0 device
on 3.0 port was LOST.
Doing warm reset while activating SuperSpeed HUBs if the hub
activate type is HUB_RESET_RESUME, gets the connected device to the stable
state.
Reviewed at https://chromium-review.googlesource.com/#/c/177132/
Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device
(8564:1000)
rebased on Greg Kroah-Hartman's usb-next
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
Signed-off-by: Vikas Sajjan
---
drivers/usb/core/hub.c | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a7c04e2..d8432b0 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -993,6 +993,21 @@ int usb_remove_device(struct usb_device *udev)
return 0;
}
+#define PORT_RESET_TRIES 5
+#define SET_ADDRESS_TRIES 2
+#define GET_DESCRIPTOR_TRIES 2
+#define SET_CONFIG_TRIES (2 * (use_both_schemes + 1))
+#define USE_NEW_SCHEME(i) ((i) / 2 == (int)old_scheme_first)
+
+#define HUB_ROOT_RESET_TIME50 /* times are in msec */
+#define HUB_SHORT_RESET_TIME 10
+#define HUB_BH_RESET_TIME 50
+#define HUB_LONG_RESET_TIME200
+#define HUB_RESET_TIMEOUT 800
+
+static int hub_port_reset(struct usb_hub *hub, int port1,
+ struct usb_device *udev, unsigned int delay, bool warm);
+
enum hub_activation_type {
HUB_INIT, HUB_INIT2, HUB_INIT3, /* INITs must come first */
HUB_POST_RESET, HUB_RESUME, HUB_RESET_RESUME,
@@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum
hub_activation_type type)
u16 portstatus, portchange;
portstatus = portchange = 0;
+
+ /* Some connected devices might be still in unknown state even
+* after reset-resume, a WARM_RESET gets the connected device
+* to the normal state.
+*/
+ if (udev && hub_is_superspeed(hub->hdev) &&
+ type == HUB_RESET_RESUME)
+ hub_port_reset(hub, port1, NULL,
+ HUB_BH_RESET_TIME, true);
+
status = hub_port_status(hub, port1, &portstatus, &portchange);
if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
dev_dbg(hub->intfdev,
@@ -2510,22 +2535,6 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
return hcd->wireless;
}
-
-#define PORT_RESET_TRIES 5
-#define SET_ADDRESS_TRIES 2
-#define GET_DESCRIPTOR_TRIES 2
-#define SET_CONFIG_TRIES (2 * (use_both_schemes + 1))
-#define USE_NEW_SCHEME(i) ((i) / 2 == (int)old_scheme_first)
-
-#define HUB_ROOT_RESET_TIME50 /* times are in msec */
-#define HUB_SHORT_RESET_TIME 10
-#define HUB_BH_RESET_TIME 50
-#define HUB_LONG_RESET_TIME200
-#define HUB_RESET_TIMEOUT 800
-
-static int hub_port_reset(struct usb_hub *hub, int port1,
- struct usb_device *udev, unsigned int delay, bool warm);
-
/* Is a USB 3.0 port in the Inactive or Complinance Mode state?
* Port worm reset is required to recover
*/
--
1.7.9.5
--
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: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init
Hi Mark, On Fri, Dec 6, 2013 at 4:57 PM, Mark Brown wrote: > On Fri, Dec 06, 2013 at 10:44:33AM +0530, Padma Venkat wrote: > >> This is done in your earlier patch " ASoC: samsung: Ensure DMA data is >> initialised for secondary DAI ". Was it done on purpose or by mistake >> in this patch? > > It's intentional - notice that the function has changed, this is why I > kept asking you about mainline. Mainline doesn't have the wrapper > function that abstracts the difference between s3c-dma and dmaengine, > this is why I'm saying these two will need to be rebased on top of the > mainline fix. Ok. I didn't notice the function name. Then this commit is not required in the mainline. This is required only after your changes because in dmaengine we are requesting the dma channel statically but in mainline(with samsung proprietary ops) we are requesting the dma channel at run time during playback or capture. > >> I think you also told to include a patch for reinitialization of the >> dma_data in i2s_hw_params. If you are in the process of debugging some >> bug as you mentioned earlier you can ignore this comment. Otherwise it >> is just a reminder. > > Hrm, forgot to commit that bit. Thanks Padma -- 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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Thu, Dec 5, 2013 at 4:07 PM, Mark Brown wrote: > On Tue, Dec 03, 2013 at 10:29:42AM +0100, Linus Walleij wrote: > >> So a suggested patch to support weak hogs would be interesting >> to look at. Can you provide details on how you think this would >> work? > > Or should we be going and applying the default state to all devices on > init without worrying about a driver appearing? That doesn't really work: if you have an unused device not in the DT you usually mark it "disabled", and then the DT core doesn't even create a platform_device for this node. So doing this would involve parsing the tree and ... yuck. Yours, Linus Walleij -- 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 RESEND v10 0/7] cpufreq:boost: CPU Boost mode support
Hi Rafael, > On 04-12-2013 02:59, Lukasz Majewski wrote: > > Hi Rafael, > > > >> This patch series introduces support for CPU overclocking technique > >> called Boost. > >> > >> It is a follow up of a LAB governor proposal. Boost is a LAB > >> component: > >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > >> > >> Boost unifies hardware based solution (e.g. Intel Nehalem) with > >> software oriented one (like the one done at Exynos). > >> For this reason cpufreq/freq_table code has been reorganized to > >> include common code. > >> > >> Important design decisions: > >> - Boost related code is compiled-in unconditionally to cpufreq core > >> and disabled by default. The cpufreq_driver is responsibile for > >> setting boost_supported flag and providing set_boost callback(if HW > >> support is needed). For software managed boost, special Kconfig > >> flag - CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be > >> selected only when a target platform has thermal framework > >> properly configured. > >> > >> - struct cpufreq_driver has been extended with boost related > >> fields: -- boost_supported - when driver supports boosting > >> -- boost_enabled - boost state > >> -- set_boost - callback to function, which is necessary to > >>enable/disable boost > >> > >> - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is > >> visible _only_ when cpufreq driver supports Boost. > >> > >> - No special spin_lock for Boost was created. The one from cpufreq > >> core was reused. > >> > >> - The Boost code doesn't rely on any policy. When boost state is > >> changed, then the policy list is iterated and proper adjustements > >> are done. > >> > >> - To improve safety level, the thermal framework is also extended > >> to disable software boosting, when thermal trip point is reached. > >> After cooling down the boost can be enabled again. This emulates > >> behaviour similar to HW managed boost (like x86) > >> > >> Tested at HW: > >>Exynos 4412 3.13-rc2 Linux > >>Intel Core i7-3770 3.13-rc2 Linux > >> > >> Above patches were posted on top of kernel_pm/bleeding-edge > >> (SHA1: 9483a9f69d5c8f83f1723361bf8340ddfb6475b4) > >> > > > > Rafael, could you pull patches from 1 to 6 of this series? Those are > > related to cpufreq core and has already been accepted by Viresh at a > > late August this year. > > This would facilitate my further cpufreq work. > > > > And about the last patch - related to thermal. It seems that more > > discussion NOT related to cpufreq will be ongoing. > > > > I would prefer to add it as a separate patch to thermal subtree. > > I agree with Lukasz here. The part that touches the thermal driver is > minimal and the discussion is a simple matter of concept and > optimization of data structures. Rafael, what is your opinion here? Shall I prepare another resend (without thermal patch) or would you accept the cpufreq part of this patch set (1 to 6) as is? > > > > > > > > >> > >> Lukasz Majewski (7): > >> cpufreq: Add boost frequency support in core > >> cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with > >> common boost solution > >> cpufreq:boost:Kconfig: Provide support for software managed BOOST > >> cpufreq:exynos:Extend Exynos cpufreq driver to support boost > >> framework > >> Documentation:cpufreq:boost: Update BOOST documentation > >> cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ > >> thermal:exynos:boost: Automatic enable/disable of BOOST feature > >> (at Exynos4412) > >> > >> Documentation/cpu-freq/boost.txt | 26 +++ > >> drivers/cpufreq/Kconfig |4 + > >> drivers/cpufreq/Kconfig.arm | 15 > >> drivers/cpufreq/acpi-cpufreq.c| 86 > >> +++-- drivers/cpufreq/cpufreq.c | > >> 118 - > >> drivers/cpufreq/exynos-cpufreq.c |3 + > >> drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > >> drivers/cpufreq/freq_table.c | 56 -- > >> drivers/thermal/samsung/exynos_tmu_data.c | 47 > >> include/linux/cpufreq.h | 24 ++ 10 files > >> changed, 302 insertions(+), 79 deletions(-) > >> > > > > > > > > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- 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] usb: ohci-exynos: Change to use phy provided by the generic phy framework
On Monday, December 09, 2013 10:56 AM, Greg KH wrote: > On Wed, Nov 06, 2013 at 10:27:49AM +0900, Jingoo Han wrote: > > Change the phy provider used from the old usb phy specific to a new one > > using the generic phy framework. > > > > Signed-off-by: Jingoo Han > > Cc: Kamil Debski > > --- > > Exynos OHCI driver also uses Exynos USB2.0 PHY. Thus, I make this > > patch based-on Kamil Debski's patchset for adding Exynos USB 2.0 PHY > > driver. > > (http://www.spinics.net/lists/linux-samsung-soc/msg24104.html) > > > > drivers/usb/host/ohci-exynos.c | 28 > > 1 file changed, 8 insertions(+), 20 deletions(-) > > This has some fuzz when applied to my tree, care to redo it against my > usb-next branch of the usb.git tree on git.kernel.org? Hi Greg, This patch should be updated, based on Kamil Debski's V4 patchset for adding Exynos USB 2.0 PHY driver [1]. I will send v2 patch based on Kamil Debski's V4 patchset [1]. [1] [PATCH v4 0/9] phy: Add new Exynos USB 2.0 PHY driver (http://www.spinics.net/lists/linux-usb/msg98911.html) Thank you. 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
[PATCH][RESEND] ARM: SAMSUNG: remove IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
Reviewed-by: Jingoo Han
---
arch/arm/mach-s3c24xx/dma.c | 2 +-
arch/arm/mach-s3c24xx/simtec-usb.c | 3 +--
arch/arm/mach-s3c64xx/mach-smartq.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/dma.c b/arch/arm/mach-s3c24xx/dma.c
index 4a65cba3295d..a8dafc174fe3 100644
--- a/arch/arm/mach-s3c24xx/dma.c
+++ b/arch/arm/mach-s3c24xx/dma.c
@@ -742,7 +742,7 @@ int s3c2410_dma_request(enum dma_ch channel,
chan->irq_claimed = 1;
local_irq_restore(flags);
- err = request_irq(chan->irq, s3c2410_dma_irq, IRQF_DISABLED,
+ err = request_irq(chan->irq, s3c2410_dma_irq, 0,
client->name, (void *)chan);
local_irq_save(flags);
diff --git a/arch/arm/mach-s3c24xx/simtec-usb.c
b/arch/arm/mach-s3c24xx/simtec-usb.c
index 2ed2e32430dc..bb3eac6a7697 100644
--- a/arch/arm/mach-s3c24xx/simtec-usb.c
+++ b/arch/arm/mach-s3c24xx/simtec-usb.c
@@ -78,8 +78,7 @@ static void usb_simtec_enableoc(struct s3c2410_hcd_info
*info, int on)
if (on) {
ret = request_irq(BAST_IRQ_USBOC, usb_simtec_ocirq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING |
- IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
"USB Over-current", info);
if (ret != 0) {
printk(KERN_ERR "failed to request usb oc irq\n");
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index a6b338fd0470..08a889c141da 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -106,7 +106,7 @@ static void smartq_usb_host_enableoc(struct
s3c2410_hcd_info *info, int on)
if (on) {
ret = request_irq(gpio_to_irq(S3C64XX_GPL(10)),
- smartq_usb_host_ocirq, IRQF_DISABLED |
+ smartq_usb_host_ocirq,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
"USB host overcurrent", info);
if (ret != 0)
--
1.8.3.2
--
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 4/5] ARM: dts: exynos4x12: Device tree node definition for TMU on Exynos4x12
Hi Kukjin,
> Lukasz Majewski wrote:
> >
> > Hi Kukjin,
> >
> Hi,
>
> > > Hi Kukjin,
> > >
> > > > The TMU device tree node definition for Exynos4x12 family of
> > > > SoCs.
> > > >
> > > > Signed-off-by: Lukasz Majewski
> > > > Reviewed-by: Bartlomiej Zolnierkiewicz
> > > > Reviewed-by: Tomasz Figa
> > > >
> > > >
> > > > ---
> > > > 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";
> > > > + };
> > > > };
> > >
> > > Can you pull this DT node definition for TMU (as a fix to v3.12)?
> > >
> > > It is crucial for Exynos4412.
> > >
> >
> > Kukjin, could you pull this patch?
> >
> Yes, but I'm not sure this is _really_ critical bug fix so maybe this
> will be queued for 3.14.
Will you apply this patch to your Samsung tree?
Thanks in advance.
>
> If any problem, please kindly let me know.
>
> Thanks,
> Kukjin
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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] usb: ohci-exynos: Change to use phy provided by the generic phy framework
On Wed, Nov 06, 2013 at 10:27:49AM +0900, Jingoo Han wrote: > Change the phy provider used from the old usb phy specific to a new one > using the generic phy framework. > > Signed-off-by: Jingoo Han > Cc: Kamil Debski > --- > Exynos OHCI driver also uses Exynos USB2.0 PHY. Thus, I make this > patch based-on Kamil Debski's patchset for adding Exynos USB 2.0 PHY > driver. > (http://www.spinics.net/lists/linux-samsung-soc/msg24104.html) > > drivers/usb/host/ohci-exynos.c | 28 > 1 file changed, 8 insertions(+), 20 deletions(-) This has some fuzz when applied to my tree, care to redo it against my usb-next branch of the usb.git tree on git.kernel.org? thanks, greg k-h -- 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] cpufreq: exynos: Add exynos5420 cpufreq driver
Hi Arun,
> From: "Arjun.K.V"
>
> The patch adds cpufreq driver for exynos5420.
>
> Signed-off-by: Arjun.K.V
> Signed-off-by: Andrew Bresticker
> Signed-off-by: Arun Kumar K
> ---
> drivers/cpufreq/Kconfig.arm | 11 ++
> drivers/cpufreq/Makefile |1 +
> drivers/cpufreq/exynos-cpufreq.c |2 +
> drivers/cpufreq/exynos-cpufreq.h |8 +
> drivers/cpufreq/exynos5420-cpufreq.c | 346
> ++ 5 files changed, 368 insertions(+)
> create mode 100644 drivers/cpufreq/exynos5420-cpufreq.c
I think that we shall cleanup "a bit" the cpufreq code for exynos.
Now we have [*]:
- exynos4x12-cpufreq.c
- exynos4210-cpufreq.c
- exynos5250-cpufreq.c
and you want to add exynos5420-cpufreq.c
Those files are pretty similar, so are a very good candidates for
cleanup.
All supported processors (up to exynos5250) allows for frequency
setting on all cores in the SoC.
Those files [*] can be easily replaced by cpu0-cpufreq.c generic code.
Also we can provide frequency, voltage table and ASV if needed via
device tree.
I did some preliminary work on this for Exynos4412. My plan is to
continue when things with BOOST "calm down" :-).
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index ce52ed9..96769fe 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -51,6 +51,17 @@ config ARM_EXYNOS5250_CPUFREQ
>
> If in doubt, say N.
>
> +config ARM_EXYNOS5420_CPUFREQ
> + bool "SAMSUNG EXYNOS5420"
> + depends on SOC_EXYNOS5420
> + default y
> + select ARM_EXYNOS_CPUFREQ
> + help
> + This adds the CPUFreq driver for Samsung EXYNOS5420
> + SoC.
> +
> + If in doubt, say N.
> +
> config ARM_EXYNOS5440_CPUFREQ
> bool "SAMSUNG EXYNOS5440"
> depends on SOC_EXYNOS5440
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 7494565..802c251 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)+=
> exynos-cpufreq.o obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) +=
> exynos4210-cpufreq.o obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) +=
> exynos4x12-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) +=
> exynos5250-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS5420_CPUFREQ)+=
> exynos5420-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) +=
> exynos5440-cpufreq.o obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) +=
> highbank-cpufreq.o obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+=
> imx6q-cpufreq.o diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c index f3c2287..ac556eb 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -246,6 +246,8 @@ static int __init exynos_cpufreq_init(void)
> ret = exynos4x12_cpufreq_init(exynos_info);
> else if (soc_is_exynos5250())
> ret = exynos5250_cpufreq_init(exynos_info);
> + else if (soc_is_exynos5420())
> + ret = exynos5420_cpufreq_init(exynos_info);
> else
> return 0;
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.h
> b/drivers/cpufreq/exynos-cpufreq.h index 7f25cee..d2f3d1e 100644
> --- a/drivers/cpufreq/exynos-cpufreq.h
> +++ b/drivers/cpufreq/exynos-cpufreq.h
> @@ -67,3 +67,11 @@ static inline int exynos5250_cpufreq_init(struct
> exynos_dvfs_info *info) return -EOPNOTSUPP;
> }
> #endif
> +#ifdef CONFIG_ARM_EXYNOS5420_CPUFREQ
> +extern int exynos5420_cpufreq_init(struct exynos_dvfs_info *);
> +#else
> +static inline int exynos5420_cpufreq_init(struct exynos_dvfs_info
> *info) +{
> + return -EOPNOTSUPP;
> +}
> +#endif
> diff --git a/drivers/cpufreq/exynos5420-cpufreq.c
> b/drivers/cpufreq/exynos5420-cpufreq.c new file mode 100644
> index 000..728ce71
> --- /dev/null
> +++ b/drivers/cpufreq/exynos5420-cpufreq.c
> @@ -0,0 +1,346 @@
> +/*
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * EXYNOS5420 - CPU frequency scaling support
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "exynos-cpufreq.h"
> +
> +#define CPUFREQ_NUM_LEVELS (L18 + 1)
> +#define EXYNOS5_CLKDIV_STATCPU0_MASK 0x
> +#define EXYNOS5_CLKDIV_STATCPU1_MASK 0x111
> +
> +static struct clk *mout_cpu;
> +static struct clk *mout_mspll_cpu;
> +static struct clk *mout_apll;
> +static struct clk *fout_apll;
> +static struct clk *fout_spll;
> +
> +struct cpufreq_clkdiv {
> + unsigned intindex;
> + unsigned intclkdiv;
> + unsigned intclkdiv1;
> +};
> +
> +static unsigned int exynos5420_volt_table[CPUFREQ_NUM_LEVELS];
> +static struct cpufreq_frequency_table exynos5420_freq_table[] = {
Re: [PATCH 5/7] clk/samsung: add support for pll2550xx
Hi Rahul, On 6 December 2013 21:26, Rahul Sharma wrote: > From: Pankaj Dubey > > exynos5260 use pll2520xx and it has different bitfields > for P,M,S values as compared to pll2550xx. Support for > pll2520xx is added here. This is a bit confusing to me. The commit message says "Support for pll2520xx is added". However, the patch subject and the entire code looks to be adding support for 2550xx. -- 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 6/7] clk/samsung: add support for pll2650xx
Hi Rahul,
On 6 December 2013 21:26, Rahul Sharma wrote:
> Add support for pll2650xx in samsung pll file. This pll variant
> is close to pll36xx but uses CON2 registers instead of CON1.
>
> Aud_pll in Exynos5260 is pll2650xx and uses this code.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/clk/samsung/clk-pll.c | 101
> +
> drivers/clk/samsung/clk-pll.h |2 +-
> 2 files changed, 102 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index 237a889..60c5679 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -811,6 +811,101 @@ static const struct clk_ops
> samsung_pll2550xx_clk_min_ops = {
> .recalc_rate = samsung_pll2550xx_recalc_rate,
> };
>
> +/*
> + * PLL2650XX Clock Type
> + */
> +
> +/* Maximum lock time can be 3000 * PDIV cycles */
> +#define PLL2650XX_LOCK_FACTOR (3000)
> +
> +#define PLL2650XX_MDIV_SHIFT (9)
> +#define PLL2650XX_PDIV_SHIFT (3)
> +#define PLL2650XX_SDIV_SHIFT (0)
> +#define PLL2650XX_KDIV_SHIFT (0)
> +#define PLL2650XX_MDIV_MASK(0x1ff)
> +#define PLL2650XX_PDIV_MASK(0x3f)
> +#define PLL2650XX_SDIV_MASK(0x7)
> +#define PLL2650XX_KDIV_MASK(0x)
> +#define PLL2650XX_PLL_ENABLE_SHIFT (23)
> +#define PLL2650XX_PLL_LOCKTIME_SHIFT (21)
> +#define PLL2650XX_PLL_FOUTMASK_SHIFT (31)
nit: Braces are unnecessary.
--
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
