Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com: On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: On 2014년 08월 05일 20:12, Thierry Reding wrote: [...] I think that low power mode is more often used for command transmission (in host-driven mode). I'm not sure how much sense it really makes to transmit video data in low power mode. It also seems like low power mode is what all peripherals need to support (if they can do command mode). Hence I'd like to propose the attached patch that makes all command messages use low power mode. To use low power mode, I think SoC drivers should add more codes: checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does exactly that, http://www.spinics.net/lists/linux-samsung-soc/msg34866.html I agree in general that DSI host drivers need to check the flags to make a decision about which mode to enable. But your patch also introduces additional flags that I don't think are necessary (at least for any of the use-cases discussed so far). As I understand it the MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM flags that you introduce would advertise that the device only supports low power mode for command or video modes respectively. However, I doubt Not so. My intention is to add LPM support for video and command data transfers because mipi-dsi framework enforces implicitly using HS mode for by default. No, it doesn't enforce anything at this point. Everyone is free to use whatever they see fit. Drivers that require low power mode for command transmission can set the MIPI_DSI_MSG_USE_LPM flag in messages. For video there's no way to specify what a given peripheral uses, so DSI host controller drivers are free to do whatever they want. So for command data we already have a means, and for video data I don't think it makes sense to use low power mode. Therefore I don't think these new flags are necessary. that there really are devices that only support low power video mode. It wouldn't make much sense because you'd get a maximum of 10 MHz for the clock, which is about 1.6 frames per second at 1920x1080 resolution (not counting blanking). And even with lower resolutions such as 1024x768 it would be somewhere around 4 frames per second. And I think it's reasonable to assume that we'll see that kind of resolution become very rare in the future. So my point is that devices which support video mode will always support high speed mode for video transmission too. Similarly, if a device supports command mode, then it will likely support it in low-power mode, and optionally in high speed mode too. And what I and Andrzej don't make sure is non-continuous clock mode. Do you know how non-continuous clock mode is related to HS clock? As far as I can tell non-continuous mode simply means that the host can turn off the HS clock after a high-speed transmission. I think Andrzej mentioned this already in another subthread, but this is an optional mode that peripherals can support if they have extra circuitry that provides an internal clock. Peripherals that don't have such circuitry may rely on the HS clock to perform in between transmissions and therefore require the HS clock to be always on (continuous mode). That's what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the peripheral supports non-continuous mode and therefore the host can turn the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. No. High speed clock and low power mode are orthogonal. Non-continuous mode simply means that the clock lane enters LP-11 between HS transmissions (see 5.6 Clock Management of the DSI specification). For low power mode the clock is embedded in the signal on the data lane and therefore independent of the high speed clock. A peripheral device will set the MIPI_DSI_CLOCK_NON_CONTINUOUS flag if it supports non-continuous mode of operation. That is, it has own circuitry to generate a clock that can be used for clocked
[PATCHv10 0/5] ARM: remove the sub-node and deprecate supports-highspeed property for dwmmc.
Since used the mmc_of_parse(), didn't parse the sub-node. So we can remove the sub-node, because almost SoC used the only one card per a host. And supports-highspeed can be replaced with cap-mmc/sd-highspeed property. Changelog V10: - Rebased for next. - Remove conflict Changelog V9: - Fix typos. - Relocated the warning message. - Change patch's sequence. Changelog V8: - Add the warning message to notice that slot-node was removed. (As Doug's suggestion) Changelog V7: - Fixed typo and modified the commit message. Changelog V6: - Fixed Wrong bit control for host's quirks and rename. - Add Acked-by for each SoC maintainers. Changelog V5: - Rebased on v3.16-rc4. - Add Acked-by. Changelog V4: - Fix the checkpatch error. Changelog V3: - Fix the wrong bus-width value. - Use the slot-host-quirks instead of brq-quirks. - Add tested-by and reviewd-by. Changelog V2: - Add the mmc: dw_mmc: replace disable-wp from slot's quirks to host's quirk Jaehoon Chung (5): mmc: dw_mmc: Slot quirk disable-wp is deprecated. mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed ARM: dts: exynos: unuse the slot-node and deprecate the supports-highspeed for dw-mmc ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc ARM: dts: rockchip: unuse the slot-node and deprecate the supports-highspeed for dw-mmc .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 17 - .../devicetree/bindings/mmc/k3-dw-mshc.txt | 12 -- .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 12 -- arch/arm/boot/dts/exynos4412-odroid-common.dtsi|8 ++- arch/arm/boot/dts/exynos4412-origen.dts|8 ++- arch/arm/boot/dts/exynos4412-trats2.dts|8 ++- arch/arm/boot/dts/exynos5250-arndale.dts | 18 -- arch/arm/boot/dts/exynos5250-cros-common.dtsi | 25 ++-- arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 -- arch/arm/boot/dts/exynos5250-snow.dts |6 ++--- arch/arm/boot/dts/exynos5260-xyref5260.dts | 18 -- arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 -- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 - arch/arm/boot/dts/exynos5420-peach-pit.dts | 16 - arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 - arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 - arch/arm/boot/dts/rk3066a-bqcurie2.dts | 15 arch/arm/boot/dts/rk3188-radxarock.dts |7 ++ arch/arm/boot/dts/socfpga_arria5.dtsi |9 +++ arch/arm/boot/dts/socfpga_cyclone5.dtsi|9 +++ arch/arm/boot/dts/socfpga_vt.dts |9 +++ drivers/mmc/host/dw_mmc.c | 11 +++-- include/linux/mmc/dw_mmc.h |2 ++ 23 files changed, 92 insertions(+), 202 deletions(-) -- 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
[PATCHv10 1/5] mmc: dw_mmc: Slot quirk disable-wp is deprecated.
Slot quirks disable-wp is deprecated.
Instead, use the host quirk disable-wp.
(Because the slot-node is removed in dt-file.)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
---
drivers/mmc/host/dw_mmc.c | 11 +--
include/linux/mmc/dw_mmc.h |2 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..47b52cc 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -997,7 +997,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
int gpio_ro = mmc_gpio_get_ro(mmc);
/* Use platform get_ro function, else try on board write protect */
- if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
+ if ((slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) ||
+ (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT))
read_only = 0;
else if (!IS_ERR_VALUE(gpio_ro))
read_only = gpio_ro;
@@ -2021,8 +2022,11 @@ static int dw_mci_of_get_slot_quirks(struct device *dev,
u8 slot)
/* get quirks */
for (idx = 0; idx ARRAY_SIZE(of_slot_quirks); idx++)
- if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
+ if (of_get_property(np, of_slot_quirks[idx].quirk, NULL)) {
+ dev_warn(dev, Slot quirk %s is deprecated\n,
+ of_slot_quirks[idx].quirk);
quirks |= of_slot_quirks[idx].id;
+ }
return quirks;
}
@@ -2238,6 +2242,9 @@ static struct dw_mci_of_quirks {
{
.quirk = broken-cd,
.id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
+ }, {
+ .quirk = disable-wp,
+ .id = DW_MCI_QUIRK_NO_WRITE_PROTECT,
},
};
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index babaea9..29ce014 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -213,6 +213,8 @@ struct dw_mci_dma_ops {
#define DW_MCI_QUIRK_HIGHSPEED BIT(2)
/* Unreliable card detection */
#define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
+/* No write protect */
+#define DW_MCI_QUIRK_NO_WRITE_PROTECT BIT(4)
/* Slot level quirks */
/* This slot has no write protect */
--
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
[PATCHv10 2/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed
Almost all SoCs use one slot per host controller.
(Even if controller can support the multiple slot, Recommend to use one slot
per host controller.)
Don't use the slot-node and deprecate the supports-highspeed property.
Instead, use the cap-mmc/sd-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
.../devicetree/bindings/mmc/exynos-dw-mshc.txt | 17 +
.../devicetree/bindings/mmc/k3-dw-mshc.txt | 12 +---
.../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 12 +---
3 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index 532b1d4..6cd3525 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -46,13 +46,14 @@ Required Properties:
- if CIU clock divider value is 0 (that is divide by 1), both tx and rx
phase shift clocks should be 0.
-Required properties for a slot:
+Required properties for a slot (Deprecated - Recommend to use one slot per
host):
* gpios: specifies a list of gpios used for command, clock and data bus. The
first gpio is the command line and the second gpio is the clock line. The
rest of the gpios (depending on the bus-width property) are the data lines in
no particular order. The format of the gpio specifier depends on the gpio
controller.
+(Deprecated - Refer to
Documentation/devicetree/binding/pinctrl/samsung-pinctrl.txt)
Example:
@@ -69,21 +70,13 @@ Example:
dwmmc0@1220 {
num-slots = 1;
- supports-highspeed;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
broken-cd;
fifo-depth = 0x80;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- gpios = gpc0 0 2 0 3, gpc0 1 2 0 3,
- gpc1 0 2 3 3, gpc1 1 2 3 3,
- gpc1 2 2 3 3, gpc1 3 2 3 3,
- gpc0 3 2 3 3, gpc0 4 2 3 3,
- gpc0 5 2 3 3, gpc0 6 2 3 3;
- };
+ bus-width = 8;
};
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
index e5bc49f..3b35449 100644
--- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
@@ -34,13 +34,11 @@ Example:
num-slots = 1;
vmmc-supply = ldo12;
fifo-depth = 0x100;
- supports-highspeed;
pinctrl-names = default;
pinctrl-0 = sd_pmx_pins sd_cfg_func1 sd_cfg_func2;
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- cd-gpios = gpio10 3 0;
- };
+ bus-width = 4;
+ disable-wp;
+ cd-gpios = gpio10 3 0;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 2d4a725..346c609 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -67,7 +67,8 @@ Optional properties:
* card-detect-delay: Delay in milli-seconds before detecting card after card
insert event. The default value is 0.
-* supports-highspeed: Enables support for high speed cards (up to 50MHz)
+* supports-highspeed (DEPRECATED): Enables support for high speed cards (up to
50MHz)
+ (use cap-mmc-highspeed or cap-sd-highspeed
instead)
* broken-cd: as documented in mmc core bindings.
@@ -98,14 +99,11 @@ board specific portions as listed below.
clock-frequency = 4;
clock-freq-min-max = 40 2;
num-slots = 1;
- supports-highspeed;
broken-cd;
fifo-depth = 0x80;
card-detect-delay = 200;
vmmc-supply = buck8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
[PATCHv10 4/5] ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced with cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Seungwon Jeon tgih@samsung.com
Acked-by: Dinh Nguyen dingu...@altera.com
---
arch/arm/boot/dts/socfpga_arria5.dtsi |9 +++--
arch/arm/boot/dts/socfpga_cyclone5.dtsi |9 +++--
arch/arm/boot/dts/socfpga_vt.dts|9 +++--
3 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_arria5.dtsi
b/arch/arm/boot/dts/socfpga_arria5.dtsi
index 12d1c2c..468fc4c 100644
--- a/arch/arm/boot/dts/socfpga_arria5.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria5.dtsi
@@ -29,13 +29,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
sysmgr@ffd08000 {
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
index bf51182..1ee03c4 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
@@ -30,13 +30,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
ethernet@ff702000 {
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index 09792b4..f9345e0 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -43,13 +43,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
ethernet@ff70 {
--
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
[PATCHv10 5/5] ARM: dts: rockchip: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced with cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Reviewed-by: Heiko Stuebner he...@sntech.de
Acked-by: Seungwon Jeon tgih@samsung.com
---
arch/arm/boot/dts/rk3066a-bqcurie2.dts | 15 ---
arch/arm/boot/dts/rk3188-radxarock.dts |7 ++-
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
index 042f821d..665dd56 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -150,12 +150,8 @@
num-slots = 1;
status = okay;
vmmc-supply = vcc_sd0;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
mmc1 { /* wifi */
@@ -166,11 +162,8 @@
pinctrl-names = default;
pinctrl-0 = sd1_clk sd1_cmd sd1_bus4;
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
uart0 {
diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts
b/arch/arm/boot/dts/rk3188-radxarock.dts
index 171b610..ef72faf 100644
--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts
@@ -181,11 +181,8 @@
status = okay;
vmmc-supply = vcc_sd0;
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
pinctrl {
--
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
[PATCHv10 3/5] ARM: dts: exynos: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced with cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Tested-by: Sachin Kamat sachin.ka...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi |8 ++--
arch/arm/boot/dts/exynos4412-origen.dts |8 ++--
arch/arm/boot/dts/exynos4412-trats2.dts |8 ++--
arch/arm/boot/dts/exynos5250-arndale.dts| 18 +---
arch/arm/boot/dts/exynos5250-cros-common.dtsi | 25 +++
arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 +---
arch/arm/boot/dts/exynos5250-snow.dts |6 ++
arch/arm/boot/dts/exynos5260-xyref5260.dts | 18 +---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 +---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 ---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 16 ---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 ---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 ---
13 files changed, 51 insertions(+), 140 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 6d6d23c..f5c0f81 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -54,17 +54,13 @@
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
watchdog@1006 {
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e925c9f..de15114 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -137,17 +137,13 @@
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
codec@1340 {
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 11967f4..5e066cd 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -520,7 +520,6 @@
mmc@1255 {
num-slots = 1;
- supports-highspeed;
broken-cd;
non-removable;
card-detect-delay = 200;
@@ -532,11 +531,8 @@
pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
pinctrl-names = default;
status = okay;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
serial@1380 {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..42a3590 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -401,7 +401,6 @@
mmc_0: mmc@1220 {
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
@@ -410,17 +409,13 @@
vmmc-supply = mmc_reg;
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_bus4 sd0_bus8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
mmc_2: mmc@1222 {
status = okay;
num-slots = 1;
- supports-highspeed;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -428,12 +423,9 @@
vmmc-supply
[PATCH v2 1/1] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
The Atmel maXTouch driver assumed that the IRQ type flags will
always be passed using platform data but this is not true when
booting using Device Trees. In these setups the interrupt type
was ignored by the driver when requesting an IRQ.
This means that it will fail if a machine specified other type
than IRQ_TYPE_NONE. The right approach is to get the IRQ flags
that was parsed by OF from the interrupt Device Tree propery.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
This patch was first sent as a part of a two part series along
with [PATCH 2/2] Input: atmel_mxt_ts - Add keycodes array example.
But there are no dependencies between these two patches so there
is no need to resend that one with no changes for v2.
Changes since v1:
- Assign flags to pdata-irqflags in mxt_parse_dt() instead of probe().
Suggested by Tomasz Figa.
drivers/input/touchscreen/atmel_mxt_ts.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 03b8571..5c8cbd3 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -22,6 +22,7 @@
#include linux/i2c.h
#include linux/i2c/atmel_mxt_ts.h
#include linux/input/mt.h
+#include linux/irq.h
#include linux/interrupt.h
#include linux/of.h
#include linux/slab.h
@@ -2093,6 +2094,8 @@ static struct mxt_platform_data *mxt_parse_dt(struct
i2c_client *client)
if (!pdata)
return ERR_PTR(-ENOMEM);
+ pdata-irqflags = irq_get_trigger_type(client-irq);
+
if (of_find_property(client-dev.of_node, linux,gpio-keymap,
proplen)) {
pdata-t19_num_keys = proplen / sizeof(u32);
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
Hello Dmitry, On 08/07/2014 08:09 AM, Dmitry Torokhov wrote: irq_of_parse_and_map() already sets up IRQ trigger type based on DT data, by calling irq_create_of_mapping() which in turn calls irq_set_irq_type(). Right but somehow when the IRQ is actually requested the type is overwritten by the value passed to request_threaded_irq() and interrupts are not being generated by the device without this patch. Do you think that this is a bug in the interrupt-parent irqchip driver or the IRQ core? I'm not that familiar with the IRQ subsystem. No, this is clearly driver fault - it smashed previously done setup with new flags. Thanks a lot for the clarification. That was my understanding as well but wanted to be sure. It might be a bit cleaner to just assign the flags to pdata-irqflags in mxt_parse_dt() instead. That would also account for the fact that pdata, if provided, should have priority over DT. You are totally right, also this will break if CONFIG_OF is not enabled since dev.of_node will not be defined. While this already is taken into account for mxt_parse_dt() by defining an empty function. I'll change it in v2 if getting the flags from the driver is the right approach Yes, please. Just posted a v2 [0] with Tomasz suggestion and the patch is indeed a lot cleaner. Best regards, Javier [0]: https://lkml.org/lkml/2014/8/7/82 -- 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 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 07일 15:58, Thierry Reding wrote: On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com: On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: On 2014년 08월 05일 20:12, Thierry Reding wrote: [...] I think that low power mode is more often used for command transmission (in host-driven mode). I'm not sure how much sense it really makes to transmit video data in low power mode. It also seems like low power mode is what all peripherals need to support (if they can do command mode). Hence I'd like to propose the attached patch that makes all command messages use low power mode. To use low power mode, I think SoC drivers should add more codes: checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does exactly that, http://www.spinics.net/lists/linux-samsung-soc/msg34866.html I agree in general that DSI host drivers need to check the flags to make a decision about which mode to enable. But your patch also introduces additional flags that I don't think are necessary (at least for any of the use-cases discussed so far). As I understand it the MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM flags that you introduce would advertise that the device only supports low power mode for command or video modes respectively. However, I doubt Not so. My intention is to add LPM support for video and command data transfers because mipi-dsi framework enforces implicitly using HS mode for by default. No, it doesn't enforce anything at this point. Everyone is free to use whatever they see fit. Drivers that require low power mode for command transmission can set the MIPI_DSI_MSG_USE_LPM flag in messages. For video there's no way to specify what a given peripheral uses, so DSI host controller drivers are free to do whatever they want. So for command data we already have a means, and for video data I don't think it makes sense to use low power mode. Therefore I don't think these new flags are necessary. that there really are devices that only support low power video mode. It wouldn't make much sense because you'd get a maximum of 10 MHz for the clock, which is about 1.6 frames per second at 1920x1080 resolution (not counting blanking). And even with lower resolutions such as 1024x768 it would be somewhere around 4 frames per second. And I think it's reasonable to assume that we'll see that kind of resolution become very rare in the future. So my point is that devices which support video mode will always support high speed mode for video transmission too. Similarly, if a device supports command mode, then it will likely support it in low-power mode, and optionally in high speed mode too. And what I and Andrzej don't make sure is non-continuous clock mode. Do you know how non-continuous clock mode is related to HS clock? As far as I can tell non-continuous mode simply means that the host can turn off the HS clock after a high-speed transmission. I think Andrzej mentioned this already in another subthread, but this is an optional mode that peripherals can support if they have extra circuitry that provides an internal clock. Peripherals that don't have such circuitry may rely on the HS clock to perform in between transmissions and therefore require the HS clock to be always on (continuous mode). That's what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the peripheral supports non-continuous mode and therefore the host can turn the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. No. High speed clock and low power mode are orthogonal. Non-continuous mode simply means that the clock lane enters LP-11 between HS transmissions (see 5.6 Clock Management of the DSI specification). It seems that clock lane enters LP-11 regardless of HS clock enabled if non-continous mode is used. Right? And also it seems that non-continous mode is different from LPM at all because with non-continuous mode, command data is transmitted to panel in HS mode, but with LPM, command data is transmitted to panel in LP
Re: [PATCH v6 00/10] ARM: dts: exynos: Prepare Spring
Hello, On 08/04/2014 05:42 PM, Doug Anderson wrote: For the touchpad it seems DT support has landed in the input tree as atmel,maxtouch. Backporting just that patch does not make it work though. (Tried the rejected pinctrl approach to be on the safe side.) https://code.google.com/p/chromium/issues/detail?id=371114 https://patchwork.kernel.org/patch/3976801/ This is the same work as needed for pit and pi, I believe. Perhaps Javier or Dmitry has this on their todo list? I posted a couple of patches that allowed me to have the atmel touchpad working on Peach Pit. I found two issues while testing the driver: a) The device keycode event capabilities are hardcoded in the downstream Chrome OS driver while the mainline driver expect these to be defined in the DT. The property is called linux,gpio-keymap since it seems that the actual implementation is using a set of GPIOs. But this is handled by the firmware since the kernel just read a status register from the atmel T9 object. I found the property confusing at first since it didn't have anything to do with Linux GPIO so posted a patch to add an example to the DT binding doc in order to make it easier to understand [0]. b) The driver overwrites the edge/level flags parsed by OF core and expects that the IRQ type will be passed using platform data. The downstream Chrome OS driver defaults the type to IRQF_TRIGGER_FALLING if this is not provided while the mainline does not have a default so it's just 0 (IRQ_TYPE_NONE). This is fixed by reading back the IRQ type from the struct irq_data when parsing the DT data [1]. The DTS changes to make the atmel touchpad work on Peach Pit were posted in [2]. Changes for Pi were included as well since it should be the same but it was not tested since I don't have access to that machine, testing will be highly appreciated. -Doug Thanks a lot and best regards, Javier [0]: https://lkml.org/lkml/2014/8/6/584 [1]: https://lkml.org/lkml/2014/8/7/82 [2]: https://lkml.org/lkml/2014/8/6/589 -- 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] mmc: dw_mmc: change to use recommended reset procedure
Hi,
I remembered that this patch was pushed at Ulf's tree.
Since dw_mci_idmac_reset() is located into #if CONFIG_MMC_DW_IDMAC,
it occurred the compiler error.
And it seems that didn't need to use IS_ENABLED() at there.
Acked-by: Jaehoon Chung jh80.ch...@samsung.com
Best Regards,
Jaehoon Chung
On 08/05/2014 10:19 AM, Sonny Rao wrote:
This patch changes the fifo reset code to follow the reset procedure
outlined in the documentation of Synopsys Mobile storage host databook.
Signed-off-by: Sonny Rao sonny...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
[sonnyrao: fix compile for !CONFIG_MMC_DW_IDMAC case]
---
drivers/mmc/host/dw_mmc.c | 87
++-
drivers/mmc/host/dw_mmc.h | 5 +++
2 files changed, 69 insertions(+), 23 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..39cf54f 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -111,8 +111,7 @@ static const u8 tuning_blk_pattern_8bit[] = {
0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
};
-static inline bool dw_mci_fifo_reset(struct dw_mci *host);
-static inline bool dw_mci_ctrl_all_reset(struct dw_mci *host);
+static bool dw_mci_reset(struct dw_mci *host);
#if defined(CONFIG_DEBUG_FS)
static int dw_mci_req_show(struct seq_file *s, void *v)
@@ -1235,7 +1234,7 @@ static int dw_mci_data_complete(struct dw_mci *host,
struct mmc_data *data)
* After an error, there may be data lingering
* in the FIFO
*/
- dw_mci_fifo_reset(host);
+ dw_mci_reset(host);
} else {
data-bytes_xfered = data-blocks * data-blksz;
data-error = 0;
@@ -1352,7 +1351,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
/* CMD error in data command */
if (mrq-cmd-error mrq-data)
- dw_mci_fifo_reset(host);
+ dw_mci_reset(host);
host-cmd = NULL;
host-data = NULL;
@@ -1963,14 +1962,8 @@ static void dw_mci_work_routine_card(struct
work_struct *work)
}
/* Power down slot */
- if (present == 0) {
- /* Clear down the FIFO */
- dw_mci_fifo_reset(host);
-#ifdef CONFIG_MMC_DW_IDMAC
- dw_mci_idmac_reset(host);
-#endif
-
- }
+ if (present == 0)
+ dw_mci_reset(host);
spin_unlock_bh(host-lock);
@@ -2208,8 +2201,11 @@ static bool dw_mci_ctrl_reset(struct dw_mci *host, u32
reset)
return false;
}
-static inline bool dw_mci_fifo_reset(struct dw_mci *host)
+static bool dw_mci_reset(struct dw_mci *host)
{
+ u32 flags = SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET;
+ bool ret = false;
+
/*
* Reseting generates a block interrupt, hence setting
* the scatter-gather pointer to NULL.
@@ -2219,15 +2215,60 @@ static inline bool dw_mci_fifo_reset(struct dw_mci
*host)
host-sg = NULL;
}
- return dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET);
-}
+ if (host-use_dma)
+ flags |= SDMMC_CTRL_DMA_RESET;
-static inline bool dw_mci_ctrl_all_reset(struct dw_mci *host)
-{
- return dw_mci_ctrl_reset(host,
- SDMMC_CTRL_FIFO_RESET |
- SDMMC_CTRL_RESET |
- SDMMC_CTRL_DMA_RESET);
+ if (dw_mci_ctrl_reset(host, flags)) {
+ /*
+ * In all cases we clear the RAWINTS register to clear any
+ * interrupts.
+ */
+ mci_writel(host, RINTSTS, 0x);
+
+ /* if using dma we wait for dma_req to clear */
+ if (host-use_dma) {
+ unsigned long timeout = jiffies + msecs_to_jiffies(500);
+ u32 status;
+ do {
+ status = mci_readl(host, STATUS);
+ if (!(status SDMMC_STATUS_DMA_REQ))
+ break;
+ cpu_relax();
+ } while (time_before(jiffies, timeout));
+
+ if (status SDMMC_STATUS_DMA_REQ) {
+ dev_err(host-dev,
+ %s: Timeout waiting for dma_req to
+ clear during reset\n, __func__);
+ goto ciu_out;
+ }
+
+ /* when using DMA next we reset the fifo again */
+
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: On 2014년 08월 07일 15:58, Thierry Reding wrote: On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com: [...] As far as I can tell non-continuous mode simply means that the host can turn off the HS clock after a high-speed transmission. I think Andrzej mentioned this already in another subthread, but this is an optional mode that peripherals can support if they have extra circuitry that provides an internal clock. Peripherals that don't have such circuitry may rely on the HS clock to perform in between transmissions and therefore require the HS clock to be always on (continuous mode). That's what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the peripheral supports non-continuous mode and therefore the host can turn the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. No. High speed clock and low power mode are orthogonal. Non-continuous mode simply means that the clock lane enters LP-11 between HS transmissions (see 5.6 Clock Management of the DSI specification). It seems that clock lane enters LP-11 regardless of HS clock enabled if non-continous mode is used. Right? No, I think as long as HS clock is enabled the clock lane won't enter LP-11. Non-continuous mode means that the controller can disable the HS clock between HS transmissions. So in non-continuous mode the clock lane can enter LP-11 because the controller disables the HS clock. In continuous mode, then the clock will never be disabled, hence the clock lane will never enter LP-11. And also it seems that non-continous mode is different from LPM at all because with non-continuous mode, command data is transmitted to panel in HS mode, but with LPM, command data is transmitted to panel in LP mode. Also right? No. I think you can send command data to the peripheral in low power mode in both continuous and non-continuous clock modes. If so, shouldn't the host driver disable HS clock, in case of LP mode, before the host driver transmits command data? No. If the peripheral doesn't support non-continuous mode, then the HS clock must never be turned off. On the other hand, if the peripheral supports non-continuous mode, then the DSI host should automatically disable the HS clock between high-speed transmissions. That means if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefore disable the HS clock. Obviously if the controller can't do that automatically then it might be necessary to explicitly do that in the driver. But I doubt that any DSI controller wouldn't be able to do that automatically. On Tegra we have a control bit that enables non-continuous mode: DSI_HS_CLK_CTRL: control for the HS clock lane - 0 = CONTINUOUS: HS clock is on all the time - 1 = TX_ONLY: HS clock is only active during HS transmissions And it seems that only one of these two flags, MSG_LPM and NON-CONTINUOUS, should be set by panel driver because with NON-CONTINUOUS clock mode, host controller generate clock and data lane signals regardless of controlling HS clock. No. Non-continuous mode is something that's specific to the peripheral and is always valid, whereas the MSG_LPM flag is only used to mark a packet to be transmitted in low power mode (as opposed to high speed mode). For peripherals that don't support non-continuous mode the NON_CONTINUOUS flag needs to be set. But the driver for the peripheral can still initiate low power mode packet transmissions by setting the MSG_LPM flag. Thierry pgpOCE3c6B34y.pgp Description: PGP signature
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 07일 18:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: On 2014년 08월 07일 15:58, Thierry Reding wrote: On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com: [...] As far as I can tell non-continuous mode simply means that the host can turn off the HS clock after a high-speed transmission. I think Andrzej mentioned this already in another subthread, but this is an optional mode that peripherals can support if they have extra circuitry that provides an internal clock. Peripherals that don't have such circuitry may rely on the HS clock to perform in between transmissions and therefore require the HS clock to be always on (continuous mode). That's what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the peripheral supports non-continuous mode and therefore the host can turn the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. No. High speed clock and low power mode are orthogonal. Non-continuous mode simply means that the clock lane enters LP-11 between HS transmissions (see 5.6 Clock Management of the DSI specification). It seems that clock lane enters LP-11 regardless of HS clock enabled if non-continous mode is used. Right? No, I think as long as HS clock is enabled the clock lane won't enter LP-11. Non-continuous mode means that the controller can disable the HS clock between HS transmissions. So in non-continuous mode the clock lane can enter LP-11 because the controller disables the HS clock. It makes me a little bit confusing. You said if HS clock is enabled, the the clock lane won't enter LP-11 But you said again the clock lane can enter LP-11 because the controller disables the HS clock What is the meaning? In continuous mode, then the clock will never be disabled, hence the clock lane will never enter LP-11. And also it seems that non-continous mode is different from LPM at all because with non-continuous mode, command data is transmitted to panel in HS mode, but with LPM, command data is transmitted to panel in LP mode. Also right? No. I think you can send command data to the peripheral in low power mode in both continuous and non-continuous clock modes. If so, shouldn't the host driver disable HS clock, in case of LP mode, before the host driver transmits command data? No. If the peripheral doesn't support non-continuous mode, then the HS clock must never be turned off. On the other hand, if the peripheral supports non-continuous mode, then the DSI host should automatically disable the HS clock between high-speed transmissions. That means if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefore disable the HS clock. What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So for LPM transfer, lanes should be LP-11 state and also HS clock of the host controller should be disabled. Your comment, if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefor disable the HS clock would mean same as my question. Obviously if the controller can't do that automatically then it might be necessary to explicitly do that in the driver. But I doubt that any DSI controller wouldn't be able to do that automatically. On Tegra we have a control bit that enables non-continuous mode: DSI_HS_CLK_CTRL: control for the HS clock lane - 0 = CONTINUOUS: HS clock is on all the time - 1 = TX_ONLY: HS clock is only active during HS transmissions MIPI-DSI of Exynos SoC also has similar bit but the spec doesn't describe it enough. Thanks for information. I will try to get more information about above comments from HW guys if I can contact them. Thanks, Inki Dae And it seems that only one of these two flags, MSG_LPM and NON-CONTINUOUS, should be set by panel driver because with NON-CONTINUOUS clock mode, host controller generate clock and data lane signals regardless of controlling HS clock. No.
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: On 2014년 08월 07일 18:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: On 2014년 08월 07일 15:58, Thierry Reding wrote: On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com: [...] As far as I can tell non-continuous mode simply means that the host can turn off the HS clock after a high-speed transmission. I think Andrzej mentioned this already in another subthread, but this is an optional mode that peripherals can support if they have extra circuitry that provides an internal clock. Peripherals that don't have such circuitry may rely on the HS clock to perform in between transmissions and therefore require the HS clock to be always on (continuous mode). That's what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the peripheral supports non-continuous mode and therefore the host can turn the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. No. High speed clock and low power mode are orthogonal. Non-continuous mode simply means that the clock lane enters LP-11 between HS transmissions (see 5.6 Clock Management of the DSI specification). It seems that clock lane enters LP-11 regardless of HS clock enabled if non-continous mode is used. Right? No, I think as long as HS clock is enabled the clock lane won't enter LP-11. Non-continuous mode means that the controller can disable the HS clock between HS transmissions. So in non-continuous mode the clock lane can enter LP-11 because the controller disables the HS clock. It makes me a little bit confusing. You said if HS clock is enabled, the the clock lane won't enter LP-11 But you said again the clock lane can enter LP-11 because the controller disables the HS clock What is the meaning? It means that if the HS clock is enabled, then the clock lane is not in LP-11. When the HS clock stops, then the clock lane enters LP-11. In continuous mode, then the clock will never be disabled, hence the clock lane will never enter LP-11. And also it seems that non-continous mode is different from LPM at all because with non-continuous mode, command data is transmitted to panel in HS mode, but with LPM, command data is transmitted to panel in LP mode. Also right? No. I think you can send command data to the peripheral in low power mode in both continuous and non-continuous clock modes. If so, shouldn't the host driver disable HS clock, in case of LP mode, before the host driver transmits command data? No. If the peripheral doesn't support non-continuous mode, then the HS clock must never be turned off. On the other hand, if the peripheral supports non-continuous mode, then the DSI host should automatically disable the HS clock between high-speed transmissions. That means if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefore disable the HS clock. What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So for LPM transfer, lanes should be LP-11 state and also HS clock of the host controller should be disabled. No. I don't think any transmissions can happen when all lanes are in LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet should be transmitted in low power mode (see LP Transmission in 2.1 Definitions of the MIPI DSI specification). For low power transmissions, only data lane 0 is used (with a clock embedded in the signal), therefore the clock lane (driven by the HS clock) can be in LP-11. Thierry pgpH58pafye95.pgp Description: PGP signature
[PATCH v3 2/2] ARM: EXYNOS: Refactor the pm code to use DT based lookup
Refactoring the pm.c to avoid using soc_is_exynos checks,
instead use the DT based lookup.
While at it, consolidate the common code across SoCs
and create a static helper functions.
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/pm.c | 168 +--
arch/arm/mach-exynos/regs-pmu.h |1 +
2 files changed, 126 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index fdd68c2..b6690c4 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -36,6 +36,8 @@
#include regs-pmu.h
#include regs-sys.h
+#define REG_TABLE_END (-1U)
+
/**
* struct exynos_wkup_irq - Exynos GIC to PMU IRQ mapping
* @hwirq: Hardware IRQ signal of the GIC
@@ -59,6 +61,21 @@ static struct sleep_save exynos_core_save[] = {
SAVE_ITEM(S5P_SROM_BC3),
};
+struct exynos_pm_data {
+ const struct exynos_wkup_irq *wkup_irq;
+ struct sleep_save *extra_save;
+ int num_extra_save;
+ unsigned int wake_disable_mask;
+ unsigned int *release_ret_regs;
+
+ void (*pm_prepare)(void);
+ void (*pm_resume)(void);
+ int (*pm_suspend)(void);
+ int (*cpu_suspend)(unsigned long);
+};
+
+struct exynos_pm_data *pm_data;
+
/*
* GIC wake-up support
*/
@@ -77,14 +94,24 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[] =
{
{ /* sentinel */ },
};
+unsigned int exynos_release_ret_regs[] = {
+ S5P_PAD_RET_MAUDIO_OPTION,
+ S5P_PAD_RET_GPIO_OPTION,
+ S5P_PAD_RET_UART_OPTION,
+ S5P_PAD_RET_MMCA_OPTION,
+ S5P_PAD_RET_MMCB_OPTION,
+ S5P_PAD_RET_EBIA_OPTION,
+ S5P_PAD_RET_EBIB_OPTION,
+ REG_TABLE_END,
+};
+
static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
{
const struct exynos_wkup_irq *wkup_irq;
- if (soc_is_exynos5250())
- wkup_irq = exynos5250_wkup_irq;
- else
- wkup_irq = exynos4_wkup_irq;
+ if (!pm_data-wkup_irq)
+ return -ENOENT;
+ wkup_irq = pm_data-wkup_irq;
while (wkup_irq-mask) {
if (wkup_irq-hwirq == data-hwirq) {
@@ -239,15 +266,8 @@ static void exynos_cpu_restore_register(void)
: cc);
}
-static int exynos_cpu_suspend(unsigned long arg)
+static int exynos_cpu_do_idle(void)
{
-#ifdef CONFIG_CACHE_L2X0
- outer_flush_all();
-#endif
-
- if (soc_is_exynos5250())
- flush_cache_all();
-
/* issue the standby signal into the pm unit. */
cpu_do_idle();
@@ -255,29 +275,43 @@ static int exynos_cpu_suspend(unsigned long arg)
return 1; /* Aborting suspend */
}
-static void exynos_pm_prepare(void)
+static int exynos_cpu_suspend(unsigned long arg)
+{
+ flush_cache_all();
+ outer_flush_all();
+ return exynos_cpu_do_idle();
+}
+static void exynos_pm_set_wakeup_mask(void)
{
- unsigned int tmp;
-
/* Set wake-up mask registers */
pmu_raw_writel(exynos_get_eint_wake_mask(), S5P_EINT_WAKEUP_MASK);
pmu_raw_writel(exynos_irqwake_intmask ~(1 31), S5P_WAKEUP_MASK);
+}
- s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
-
- if (soc_is_exynos5250())
- s3c_pm_do_save(exynos5_sys_save, ARRAY_SIZE(exynos5_sys_save));
-
+static void exynos_pm_enter_sleep_mode(void)
+{
/* Set value of power down register for sleep mode */
-
exynos_sys_powerdown_conf(SYS_SLEEP);
pmu_raw_writel(S5P_CHECK_SLEEP, S5P_INFORM1);
/* ensure at least INFORM0 has the resume address */
-
pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
}
+static void exynos_pm_prepare(void)
+{
+ /* Set wake-up mask registers */
+ exynos_pm_set_wakeup_mask();
+
+ s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
+
+if (pm_data-extra_save)
+ s3c_pm_do_save(pm_data-extra_save,
+ pm_data-num_extra_save);
+
+ exynos_pm_enter_sleep_mode();
+}
+
static void exynos_pm_central_suspend(void)
{
unsigned long tmp;
@@ -328,6 +362,15 @@ static int exynos_pm_central_resume(void)
return 0;
}
+static void exynos_pm_release_retention(void)
+{
+ unsigned int i;
+
+ for (i = 0; (pm_data-release_ret_regs[i] != REG_TABLE_END); i++)
+ pmu_raw_writel(EXYNOS_WAKEUP_FROM_LOWPWR,
+ pm_data-release_ret_regs[i]);
+}
+
static void exynos_pm_resume(void)
{
if (exynos_pm_central_resume())
@@ -337,18 +380,11 @@ static void exynos_pm_resume(void)
exynos_cpu_restore_register();
/* For release retention */
+ exynos_pm_release_retention();
- pmu_raw_writel((1 28), S5P_PAD_RET_MAUDIO_OPTION);
- pmu_raw_writel((1 28), S5P_PAD_RET_GPIO_OPTION);
- pmu_raw_writel((1 28), S5P_PAD_RET_UART_OPTION);
- pmu_raw_writel((1
[PATCH v3 1/2] ARM: EXYNOS: Move Disabling of JPEG USE_RETENTION for exynos5250 to pmu.c
Move the Disabling of JPEG USE_RETENTION for exynos5250 to pmu.c to make way for
refactoring of pm.c and to create common functions across exynos4 and
exynos5250.
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/pm.c |7 +--
arch/arm/mach-exynos/pmu.c |6 ++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index c4c6d98..fdd68c2 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -265,13 +265,8 @@ static void exynos_pm_prepare(void)
s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
- if (soc_is_exynos5250()) {
+ if (soc_is_exynos5250())
s3c_pm_do_save(exynos5_sys_save, ARRAY_SIZE(exynos5_sys_save));
- /* Disable USE_RETENTION of JPEG_MEM_OPTION */
- tmp = pmu_raw_readl(EXYNOS5_JPEG_MEM_OPTION);
- tmp = ~EXYNOS5_OPTION_USE_RETENTION;
- pmu_raw_writel(tmp, EXYNOS5_JPEG_MEM_OPTION);
- }
/* Set value of power down register for sleep mode */
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index ff9d23f..6021adb 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -389,6 +389,7 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
static int __init exynos_pmu_init(void)
{
unsigned int value;
+ unsigned int tmp;
exynos_pmu_config = exynos4210_pmu_config;
@@ -411,6 +412,11 @@ static int __init exynos_pmu_init(void)
value = ~EXYNOS5_SYS_WDTRESET;
pmu_raw_writel(value, EXYNOS5_MASK_WDTRESET_REQUEST);
+ /* Disable USE_RETENTION of JPEG_MEM_OPTION */
+ tmp = pmu_raw_readl(EXYNOS5_JPEG_MEM_OPTION);
+ tmp = ~EXYNOS5_OPTION_USE_RETENTION;
+ pmu_raw_writel(tmp, EXYNOS5_JPEG_MEM_OPTION);
+
exynos_pmu_config = exynos5250_pmu_config;
pr_info(EXYNOS5250 PMU Initialize\n);
} else {
--
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: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 07일 20:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: On 2014년 08월 07일 18:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: On 2014년 08월 07일 15:58, Thierry Reding wrote: On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com: [...] As far as I can tell non-continuous mode simply means that the host can turn off the HS clock after a high-speed transmission. I think Andrzej mentioned this already in another subthread, but this is an optional mode that peripherals can support if they have extra circuitry that provides an internal clock. Peripherals that don't have such circuitry may rely on the HS clock to perform in between transmissions and therefore require the HS clock to be always on (continuous mode). That's what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the peripheral supports non-continuous mode and therefore the host can turn the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. No. High speed clock and low power mode are orthogonal. Non-continuous mode simply means that the clock lane enters LP-11 between HS transmissions (see 5.6 Clock Management of the DSI specification). It seems that clock lane enters LP-11 regardless of HS clock enabled if non-continous mode is used. Right? No, I think as long as HS clock is enabled the clock lane won't enter LP-11. Non-continuous mode means that the controller can disable the HS clock between HS transmissions. So in non-continuous mode the clock lane can enter LP-11 because the controller disables the HS clock. It makes me a little bit confusing. You said if HS clock is enabled, the the clock lane won't enter LP-11 But you said again the clock lane can enter LP-11 because the controller disables the HS clock What is the meaning? It means that if the HS clock is enabled, then the clock lane is not in LP-11. When the HS clock stops, then the clock lane enters LP-11. In continuous mode, then the clock will never be disabled, hence the clock lane will never enter LP-11. And also it seems that non-continous mode is different from LPM at all because with non-continuous mode, command data is transmitted to panel in HS mode, but with LPM, command data is transmitted to panel in LP mode. Also right? No. I think you can send command data to the peripheral in low power mode in both continuous and non-continuous clock modes. If so, shouldn't the host driver disable HS clock, in case of LP mode, before the host driver transmits command data? No. If the peripheral doesn't support non-continuous mode, then the HS clock must never be turned off. On the other hand, if the peripheral supports non-continuous mode, then the DSI host should automatically disable the HS clock between high-speed transmissions. That means if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefore disable the HS clock. What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So for LPM transfer, lanes should be LP-11 state and also HS clock of the host controller should be disabled. No. I don't think any transmissions can happen when all lanes are in LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet should be transmitted in low power mode (see LP Transmission in 2.1 Definitions of the MIPI DSI specification). Hm.. I see. I meant, if (flags MIPI_DSI_MSG_USE_LPM) disable HS clock - required. transmit command data - in LPM. Thanks, Inki Dae For low power transmissions, only data lane 0 is used (with a clock embedded in the signal), therefore the clock lane (driven by the HS clock) can be in LP-11. Thierry -- 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 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: On 2014년 08월 07일 20:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: On 2014년 08월 07일 18:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: On 2014년 08월 07일 15:58, Thierry Reding wrote: On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com: [...] As far as I can tell non-continuous mode simply means that the host can turn off the HS clock after a high-speed transmission. I think Andrzej mentioned this already in another subthread, but this is an optional mode that peripherals can support if they have extra circuitry that provides an internal clock. Peripherals that don't have such circuitry may rely on the HS clock to perform in between transmissions and therefore require the HS clock to be always on (continuous mode). That's what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the peripheral supports non-continuous mode and therefore the host can turn the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. No. High speed clock and low power mode are orthogonal. Non-continuous mode simply means that the clock lane enters LP-11 between HS transmissions (see 5.6 Clock Management of the DSI specification). It seems that clock lane enters LP-11 regardless of HS clock enabled if non-continous mode is used. Right? No, I think as long as HS clock is enabled the clock lane won't enter LP-11. Non-continuous mode means that the controller can disable the HS clock between HS transmissions. So in non-continuous mode the clock lane can enter LP-11 because the controller disables the HS clock. It makes me a little bit confusing. You said if HS clock is enabled, the the clock lane won't enter LP-11 But you said again the clock lane can enter LP-11 because the controller disables the HS clock What is the meaning? It means that if the HS clock is enabled, then the clock lane is not in LP-11. When the HS clock stops, then the clock lane enters LP-11. In continuous mode, then the clock will never be disabled, hence the clock lane will never enter LP-11. And also it seems that non-continous mode is different from LPM at all because with non-continuous mode, command data is transmitted to panel in HS mode, but with LPM, command data is transmitted to panel in LP mode. Also right? No. I think you can send command data to the peripheral in low power mode in both continuous and non-continuous clock modes. If so, shouldn't the host driver disable HS clock, in case of LP mode, before the host driver transmits command data? No. If the peripheral doesn't support non-continuous mode, then the HS clock must never be turned off. On the other hand, if the peripheral supports non-continuous mode, then the DSI host should automatically disable the HS clock between high-speed transmissions. That means if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefore disable the HS clock. What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So for LPM transfer, lanes should be LP-11 state and also HS clock of the host controller should be disabled. No. I don't think any transmissions can happen when all lanes are in LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet should be transmitted in low power mode (see LP Transmission in 2.1 Definitions of the MIPI DSI specification). Hm.. I see. I meant, if (flags MIPI_DSI_MSG_USE_LPM) disable HS clock - required. transmit command data - in LPM. No. Disabling the HS clock is not required for LPM mode. In fact if the peripheral specifies that it doesn't support non-continuous mode then the HS clock must *never* be disabled as long as the peripheral is in use. MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and need to be considered
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: On 2014년 08월 07일 22:17, Thierry Reding wrote: On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: On 2014년 08월 07일 20:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: On 2014년 08월 07일 18:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: On 2014년 08월 07일 15:58, Thierry Reding wrote: On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com: [...] As far as I can tell non-continuous mode simply means that the host can turn off the HS clock after a high-speed transmission. I think Andrzej mentioned this already in another subthread, but this is an optional mode that peripherals can support if they have extra circuitry that provides an internal clock. Peripherals that don't have such circuitry may rely on the HS clock to perform in between transmissions and therefore require the HS clock to be always on (continuous mode). That's what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the peripheral supports non-continuous mode and therefore the host can turn the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. No. High speed clock and low power mode are orthogonal. Non-continuous mode simply means that the clock lane enters LP-11 between HS transmissions (see 5.6 Clock Management of the DSI specification). It seems that clock lane enters LP-11 regardless of HS clock enabled if non-continous mode is used. Right? No, I think as long as HS clock is enabled the clock lane won't enter LP-11. Non-continuous mode means that the controller can disable the HS clock between HS transmissions. So in non-continuous mode the clock lane can enter LP-11 because the controller disables the HS clock. It makes me a little bit confusing. You said if HS clock is enabled, the the clock lane won't enter LP-11 But you said again the clock lane can enter LP-11 because the controller disables the HS clock What is the meaning? It means that if the HS clock is enabled, then the clock lane is not in LP-11. When the HS clock stops, then the clock lane enters LP-11. In continuous mode, then the clock will never be disabled, hence the clock lane will never enter LP-11. And also it seems that non-continous mode is different from LPM at all because with non-continuous mode, command data is transmitted to panel in HS mode, but with LPM, command data is transmitted to panel in LP mode. Also right? No. I think you can send command data to the peripheral in low power mode in both continuous and non-continuous clock modes. If so, shouldn't the host driver disable HS clock, in case of LP mode, before the host driver transmits command data? No. If the peripheral doesn't support non-continuous mode, then the HS clock must never be turned off. On the other hand, if the peripheral supports non-continuous mode, then the DSI host should automatically disable the HS clock between high-speed transmissions. That means if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefore disable the HS clock. What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So for LPM transfer, lanes should be LP-11 state and also HS clock of the host controller should be disabled. No. I don't think any transmissions can happen when all lanes are in LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet should be transmitted in low power mode (see LP Transmission in 2.1 Definitions of the MIPI DSI specification). Hm.. I see. I meant, if (flags MIPI_DSI_MSG_USE_LPM) disable HS clock - required. transmit command data - in LPM. No. Disabling the HS clock is not required for LPM mode. In fact if the peripheral specifies that it doesn't support non-continuous mode then the HS clock must *never* be disabled as
[PATCH] mmc: sdhci-s3c: fix runtime PM handling on sdhci_add_host() failure
Runtime Power Management handling for the sdhci_add_host() failure
case in sdhci_s3c_probe() should match the code in sdhci_s3c_remove()
(which uses pm_runtime_disable() call which matches the earlier
pm_runtime_enable() one). Fix it.
This patch fixes BUG: spinlock bad magic on CPU#0, swapper/0/1 and
Unbalanced pm_runtime_enable! warnings.
From the kernel log:
...
[1.659631] s3c-sdhci 1253.sdhci: sdhci_add_host() failed
[1.665096] BUG: spinlock bad magic on CPU#0, swapper/0/1
[1.670433] lock: 0xea01e484, .magic: , .owner: none/-1,
.owner_cpu: 0
[1.677895] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.16.0-next-20140804-8-ga59480f-dirty #707
[1.687037] [c0013ae4] (unwind_backtrace) from [c0010d70]
(show_stack+0x10/0x14)
[1.694740] [c0010d70] (show_stack) from [c04050c8]
(dump_stack+0x68/0xb8)
[1.701948] [c04050c8] (dump_stack) from [c0052558]
(do_raw_spin_lock+0x15c/0x1a4)
[1.709848] [c0052558] (do_raw_spin_lock) from [c040a630]
(_raw_spin_lock_irqsave+0x20/0x28)
[1.718619] [c040a630] (_raw_spin_lock_irqsave) from [c030d7d0]
(sdhci_do_set_ios+0x1c/0x5cc)
[1.727464] [c030d7d0] (sdhci_do_set_ios) from [c030ddfc]
(sdhci_runtime_resume_host+0x50/0x104)
[1.736574] [c030ddfc] (sdhci_runtime_resume_host) from [c02462dc]
(pm_generic_runtime_resume+0x2c/0x40)
[1.746383] [c02462dc] (pm_generic_runtime_resume) from [c0247898]
(__rpm_callback+0x34/0x70)
[1.755233] [c0247898] (__rpm_callback) from [c02478fc]
(rpm_callback+0x28/0x88)
[1.762958] [c02478fc] (rpm_callback) from [c02486f0]
(rpm_resume+0x384/0x4ec)
[1.770511] [c02486f0] (rpm_resume) from [c02488b0]
(pm_runtime_forbid+0x58/0x64)
[1.778325] [c02488b0] (pm_runtime_forbid) from [c030ea70]
(sdhci_s3c_probe+0x4a4/0x540)
[1.786749] [c030ea70] (sdhci_s3c_probe) from [c02429cc]
(platform_drv_probe+0x2c/0x5c)
[1.795076] [c02429cc] (platform_drv_probe) from [c02415f0]
(driver_probe_device+0x114/0x234)
[1.803929] [c02415f0] (driver_probe_device) from [c024179c]
(__driver_attach+0x8c/0x90)
[1.812347] [c024179c] (__driver_attach) from [c023ffb4]
(bus_for_each_dev+0x54/0x88)
[1.820506] [c023ffb4] (bus_for_each_dev) from [c0240df8]
(bus_add_driver+0xd8/0x1cc)
[1.828665] [c0240df8] (bus_add_driver) from [c0241db8]
(driver_register+0x78/0xf4)
[1.836652] [c0241db8] (driver_register) from [c00088a4]
(do_one_initcall+0x80/0x1d0)
[1.844816] [c00088a4] (do_one_initcall) from [c059ac94]
(kernel_init_freeable+0x108/0x1d4)
[1.853503] [c059ac94] (kernel_init_freeable) from [c0401300]
(kernel_init+0x8/0xe4)
[1.861568] [c0401300] (kernel_init) from [c000e538]
(ret_from_fork+0x14/0x3c)
[1.869582] platform 1253.sdhci: Driver s3c-sdhci requests probe deferral
...
[1.997047] s3c-sdhci 1253.sdhci: Unbalanced pm_runtime_enable!
...
[2.027235] s3c-sdhci 1253.sdhci: sdhci_add_host() failed
[2.032884] platform 1253.sdhci: Driver s3c-sdhci requests probe deferral
...
Tested on Hardkernel's Exynos4412 based ODROID-U3 board.
Fixes: 9f4e8151dbbc (mmc: sdhci-s3c: Enable runtime power management)
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Jaehoon Chung jh80.ch...@samsung.com
Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
patch is against next-20140804 branch of linux-next kernel
drivers/mmc/host/sdhci-s3c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index fa5954a..1e47903 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -606,8 +606,6 @@ static int sdhci_s3c_probe(struct platform_device *pdev)
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, sdhci_add_host() failed\n);
- pm_runtime_forbid(pdev-dev);
- pm_runtime_get_noresume(pdev-dev);
goto err_req_regs;
}
@@ -618,6 +616,8 @@ static int sdhci_s3c_probe(struct platform_device *pdev)
return 0;
err_req_regs:
+ pm_runtime_disable(pdev-dev);
+
err_no_busclks:
clk_disable_unprepare(sc-clk_io);
--
1.8.2.3
--
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] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
On Thu, Aug 07, 2014 at 09:49:49AM +0200, Javier Martinez Canillas wrote: Hello Dmitry, On 08/07/2014 08:09 AM, Dmitry Torokhov wrote: irq_of_parse_and_map() already sets up IRQ trigger type based on DT data, by calling irq_create_of_mapping() which in turn calls irq_set_irq_type(). Right but somehow when the IRQ is actually requested the type is overwritten by the value passed to request_threaded_irq() and interrupts are not being generated by the device without this patch. Do you think that this is a bug in the interrupt-parent irqchip driver or the IRQ core? I'm not that familiar with the IRQ subsystem. No, this is clearly driver fault - it smashed previously done setup with new flags. Thanks a lot for the clarification. That was my understanding as well but wanted to be sure. Actually, I take this back. In mainline everything as it should: if pdata does not specify particular trigger the flags requested end up being IRQF_ONESHOT, which should preserve trigger bits previously set up by the board or OF code. In Chrome kernel we have: /* Default to falling edge if no platform data provided */ irqflags = data-pdata ? data-pdata-irqflags : IRQF_TRIGGER_FALLING; error = request_threaded_irq(client-irq, NULL, mxt_interrupt, irqflags | IRQF_ONESHOT, client-name, data); which I believe should go away. If it is needed on ACPI systems we need to figure out how to do things we can do with OF there. Thanks. -- Dmitry -- 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] mfd: sec-irq: fix support for devices without irq specified
[ added missing linux-samsung-soc ML, sorry for the noise ]
On Thursday, August 07, 2014 06:42:28 PM Bartlomiej Zolnierkiewicz wrote:
Add missing check for the case of device without irq specified
in sec_irq_exit() (please note that sec_irq_init() already
correctly handles such devices).
This is needed for Insignal's Exynos4412 based Origen board.
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Sangbeom Kim sbki...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
patch is against next-20140804 branch of linux-next kernel
drivers/mfd/sec-irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index f9a5786..b65a7f0 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -478,5 +478,6 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
void sec_irq_exit(struct sec_pmic_dev *sec_pmic)
{
- regmap_del_irq_chip(sec_pmic-irq, sec_pmic-irq_data);
+ if (sec_pmic-irq)
+ regmap_del_irq_chip(sec_pmic-irq, sec_pmic-irq_data);
}
--
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] mfd: sec-core: add missing sec_irq_init() return value checking
[ added missing linux-samsung-soc ML, sorry for the noise ] On Thursday, August 07, 2014 06:44:18 PM Bartlomiej Zolnierkiewicz wrote: sec_irq_init() can fail if it encounters unknown device type or on regmap_add_irq_chip() error. Add missing sec_irq_init() return value checking to sec_pmic_probe(). Tested on Insignal's Exynos4412 based Origen board. Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- patch is against next-20140804 branch of linux-next kernel drivers/mfd/sec-core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c index dba7e2b..f498867 100644 --- a/drivers/mfd/sec-core.c +++ b/drivers/mfd/sec-core.c @@ -353,7 +353,9 @@ static int sec_pmic_probe(struct i2c_client *i2c, if (pdata pdata-cfg_pmic_irq) pdata-cfg_pmic_irq(); - sec_irq_init(sec_pmic); + ret = sec_irq_init(sec_pmic); + if (ret) + return ret; pm_runtime_set_active(sec_pmic-dev); -- 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: [PATCHv2 1/3] iio: adc: exynos_adc: add support for s3c64xx adc
On 28/07/14 13:44, Chanwoo Choi wrote:
From: Arnd Bergmann a...@arndb.de
The ADC in s3c64xx is almost the same as exynosv1, but
has a different 'select' method. Adding this here will be
helpful to move over the existing s3c64xx platform from the
legacy plat-samsung/adc driver to the new exynos-adc.
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Applied to the togreg branch of iio.git. Initially pushed out as testing
for the autobuilders to play.
Thanks,
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 2 ++
drivers/iio/adc/exynos_adc.c | 28
+-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index adc61b0..d3dad46 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -16,6 +16,8 @@ Required properties:
future controllers.
Must be samsung,exynos3250-adc for
controllers compatible with ADC of Exynos3250.
+ Must be samsung,s3c6410-adc for
+ the ADC in s3c6410 and compatibles
- reg: Contains ADC register address range (base
address and
length) and the address of the phy enable register.
- interrupts:Contains the interrupt information for the
timer. The
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 87e0895..ed9e4c8 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,7 +40,7 @@
#include linux/iio/machine.h
#include linux/iio/driver.h
-/* EXYNOS4412/5250 ADC_V1 registers definitions */
+/* S3C/EXYNOS4412/5250 ADC_V1 registers definitions */
#define ADC_V1_CON(x)((x) + 0x00)
#define ADC_V1_DLY(x)((x) + 0x08)
#define ADC_V1_DATX(x) ((x) + 0x0C)
@@ -61,6 +61,9 @@
#define ADC_V1_CON_PRSCLV(x) (((x) 0xFF) 6)
#define ADC_V1_CON_STANDBY (1u 2)
+/* Bit definitions for S3C2410 ADC */
+#define ADC_S3C2410_CON_SELMUX(x) (((x) 7) 3)
+
/* Bit definitions for ADC_V2 */
#define ADC_V2_CON1_SOFT_RESET (1u 2)
@@ -217,6 +220,26 @@ static const struct exynos_adc_data const
exynos_adc_v1_data = {
.start_conv = exynos_adc_v1_start_conv,
};
+static void exynos_adc_s3c64xx_start_conv(struct exynos_adc *info,
+ unsigned long addr)
+{
+ u32 con1;
+
+ con1 = readl(ADC_V1_CON(info-regs));
+ con1 = ~ADC_S3C2410_CON_SELMUX(0x7);
+ con1 |= ADC_S3C2410_CON_SELMUX(addr);
+ writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info-regs));
+}
+
+static struct exynos_adc_data const exynos_adc_s3c64xx_data = {
+ .num_channels = MAX_ADC_V1_CHANNELS,
+
+ .init_hw= exynos_adc_v1_init_hw,
+ .exit_hw= exynos_adc_v1_exit_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_s3c64xx_start_conv,
+};
+
static void exynos_adc_v2_init_hw(struct exynos_adc *info)
{
u32 con1, con2;
@@ -285,6 +308,9 @@ static const struct exynos_adc_data const
exynos3250_adc_data = {
static const struct of_device_id exynos_adc_match[] = {
{
+ .compatible = samsung,s3c6410-adc,
+ .data = exynos_adc_s3c64xx_data,
+ }, {
.compatible = samsung,exynos-adc-v1,
.data = exynos_adc_v1_data,
}, {
--
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: [PATCHv2 2/3] iio: adc: exynos_adc: Add support for s3c24xx ADC
On 28/07/14 13:44, Chanwoo Choi wrote:
This patch add support for s3c2410/s3c2416/s3c2440/s3c2443 ADC. The s3c24xx
is alomost same as ADCv1. But, There are a little difference as following:
- ADCMUX register address
- ADCDAT mask (10 bit or 12 bit ADC resolution according to SoC version)
- s3c24xx/s3c64xx has not included ADC_PHY enable register
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
Applied - with a little bit of fuzz and pushed out as testing for the
autobuilders
to play with it.
Thanks
Jonathan
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 16 ++-
drivers/iio/adc/Kconfig| 2 +-
drivers/iio/adc/exynos_adc.c | 109
+++--
3 files changed, 114 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index d3dad46..709efaa 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -11,15 +11,25 @@ New driver handles the following
Required properties:
- compatible:Must be samsung,exynos-adc-v1
- for exynos4412/5250 controllers.
+ for exynos4412/5250 and s5pv210 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
Must be samsung,exynos3250-adc for
controllers compatible with ADC of Exynos3250.
+ Must be samsung,s3c2410-adc for
+ the ADC in s3c2410 and compatibles
+ Must be samsung,s3c2416-adc for
+ the ADC in s3c2416 and compatibles
+ Must be samsung,s3c2440-adc for
+ the ADC in s3c2440 and compatibles
+ Must be samsung,s3c2443-adc for
+ the ADC in s3c2443 and compatibles
Must be samsung,s3c6410-adc for
the ADC in s3c6410 and compatibles
-- reg: Contains ADC register address range (base
address and
- length) and the address of the phy enable register.
+- reg: List of ADC register address range
+ - The base address and range of ADC register
+ - The base address and range of ADC_PHY register (every
+ SoC except for s3c24xx/s3c64xx ADC)
- interrupts:Contains the interrupt information for the
timer. The
format is being dependent on which interrupt controller
the Samsung device uses.
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a80d236..a247655 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -119,7 +119,7 @@ config AT91_ADC
config EXYNOS_ADC
tristate Exynos ADC driver support
- depends on ARCH_EXYNOS || (OF COMPILE_TEST)
+ depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF
COMPILE_TEST)
help
Core support for the ADC block found in the Samsung EXYNOS series
of SoCs for drivers such as the touchscreen and hwmon to use to share
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index ed9e4c8..3b17faa 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -47,6 +47,9 @@
#define ADC_V1_INTCLR(x) ((x) + 0x18)
#define ADC_V1_MUX(x)((x) + 0x1c)
+/* S3C2410 ADC registers definitions */
+#define ADC_S3C2410_MUX(x) ((x) + 0x18)
+
/* Future ADC_V2 registers definitions */
#define ADC_V2_CON1(x) ((x) + 0x00)
#define ADC_V2_CON2(x) ((x) + 0x04)
@@ -63,6 +66,8 @@
/* Bit definitions for S3C2410 ADC */
#define ADC_S3C2410_CON_SELMUX(x) (((x) 7) 3)
+#define ADC_S3C2410_DATX_MASK0x3FF
+#define ADC_S3C2416_CON_RES_SEL (1u 3)
/* Bit definitions for ADC_V2 */
#define ADC_V2_CON1_SOFT_RESET (1u 2)
@@ -80,6 +85,7 @@
/* Bit definitions common for ADC_V1 and ADC_V2 */
#define ADC_CON_EN_START (1u 0)
+#define ADC_CON_EN_START_MASK(0x3 0)
#define ADC_DATX_MASK0xFFF
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
@@ -103,6 +109,8 @@ struct exynos_adc {
struct exynos_adc_data {
int num_channels;
bool needs_sclk;
+ bool needs_adc_phy;
+ u32 mask;
void (*init_hw)(struct exynos_adc *info);
void (*exit_hw)(struct exynos_adc *info);
@@ -174,7 +182,8 @@ static void exynos_adc_v1_init_hw(struct exynos_adc *info)
{
u32 con1;
- writel(1, info-enable_reg);
+ if
Re: [PATCHv2 3/3] dt-bindings: samsung: exynos_adc: Remove un-necessary white-sapce
On 28/07/14 13:44, Chanwoo Choi wrote: This patch remove un-necessary white-sapce to code clean. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Applied to the togreg branch of iio.git. Obviously this didn't need to go through my tree, but as it is so trivial it might as well do so. J --- Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt index 709efaa..5ee0266 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt @@ -30,7 +30,7 @@ Required properties: - The base address and range of ADC register - The base address and range of ADC_PHY register (every SoC except for s3c24xx/s3c64xx ADC) -- interrupts:Contains the interrupt information for the timer. The +- interrupts:Contains the interrupt information for the timer. The format is being dependent on which interrupt controller the Samsung device uses. - #io-channel-cells = 1; As ADC has multiple outputs -- 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 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 07일 22:55, Thierry Reding wrote: On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: On 2014년 08월 07일 22:17, Thierry Reding wrote: On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: On 2014년 08월 07일 20:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: On 2014년 08월 07일 18:09, Thierry Reding wrote: On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: On 2014년 08월 07일 15:58, Thierry Reding wrote: On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com: [...] As far as I can tell non-continuous mode simply means that the host can turn off the HS clock after a high-speed transmission. I think Andrzej mentioned this already in another subthread, but this is an optional mode that peripherals can support if they have extra circuitry that provides an internal clock. Peripherals that don't have such circuitry may rely on the HS clock to perform in between transmissions and therefore require the HS clock to be always on (continuous mode). That's what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the peripheral supports non-continuous mode and therefore the host can turn the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. No. High speed clock and low power mode are orthogonal. Non-continuous mode simply means that the clock lane enters LP-11 between HS transmissions (see 5.6 Clock Management of the DSI specification). It seems that clock lane enters LP-11 regardless of HS clock enabled if non-continous mode is used. Right? No, I think as long as HS clock is enabled the clock lane won't enter LP-11. Non-continuous mode means that the controller can disable the HS clock between HS transmissions. So in non-continuous mode the clock lane can enter LP-11 because the controller disables the HS clock. It makes me a little bit confusing. You said if HS clock is enabled, the the clock lane won't enter LP-11 But you said again the clock lane can enter LP-11 because the controller disables the HS clock What is the meaning? It means that if the HS clock is enabled, then the clock lane is not in LP-11. When the HS clock stops, then the clock lane enters LP-11. In continuous mode, then the clock will never be disabled, hence the clock lane will never enter LP-11. And also it seems that non-continous mode is different from LPM at all because with non-continuous mode, command data is transmitted to panel in HS mode, but with LPM, command data is transmitted to panel in LP mode. Also right? No. I think you can send command data to the peripheral in low power mode in both continuous and non-continuous clock modes. If so, shouldn't the host driver disable HS clock, in case of LP mode, before the host driver transmits command data? No. If the peripheral doesn't support non-continuous mode, then the HS clock must never be turned off. On the other hand, if the peripheral supports non-continuous mode, then the DSI host should automatically disable the HS clock between high-speed transmissions. That means if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefore disable the HS clock. What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So for LPM transfer, lanes should be LP-11 state and also HS clock of the host controller should be disabled. No. I don't think any transmissions can happen when all lanes are in LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet should be transmitted in low power mode (see LP Transmission in 2.1 Definitions of the MIPI DSI specification). Hm.. I see. I meant, if (flags MIPI_DSI_MSG_USE_LPM) disable HS clock - required. transmit command data - in LPM. No. Disabling the HS clock is not required for LPM mode. In fact if the peripheral specifies that it doesn't support non-continuous mode then the HS clock must *never* be disabled as long as the peripheral is in use. MIPI_DSI_MSG_USE_LPM and
