Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 11일 18:11, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 05:15:35PM +0900, Inki Dae wrote: >> On 2014년 08월 11일 16:50, Thierry Reding wrote: >>> On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: On 2014년 08월 11일 16:24, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: >> On 2014년 08월 08일 18:55, Thierry Reding wrote: >>> [...] >>> The above is actually more like this: >>> >>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) >>> clear DSI_HS_CLK_CTRL; >>> else >>> set DSI_HS_CLK_CTRL; >>> >>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) >>> clear DSI_HIGH_SPEED_TRANS; >>> else >>> set DSI_HIGH_SPEED_TRANS; >>> >>> So for peripherals that don't support non-continuous clock mode, this >>> will result in the following for low-power transmissions: >>> >>> clear DSI_HS_CLK_CTRL; /* HS clock always on */ >>> clear DSI_HIGH_SPEED_TRANS; >> >> Right, then how host driver should check it if peripheral doesn't >> support non-continuous clock mode? Or how the peripheral should notify >> it to host driver? It would need a new flag instead of >> MIPI_DSI_MODE_NON_CONTINUOUS. > > MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to > set to signal that they support non-continuous mode. If devices don't > have that set, then the controller should always provide the HS clock. > > So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral > does *not* support non-continuous mode. > Again, assume that there is a peripheral that doesn't support non-continuous clock mode but host driver want to transmit data in low power. For this, you already mentioned like below, "So for peripherals that don't support non-continuous clock mode, this will result in the following for low-power transmissions: clear DSI_HS_CLK_CTRL; /* HS clock always on */ clear DSI_HIGH_SPEED_TRANS; " In this case, how should host driver check it to clear above two flags? As you know, this is required to clear two flags same as non-continuous clock mode. Don't you think that we need a new flag to identify them - non-continuous clock mode or just for low-power transmission? >>> >>> See what I wrote a little further up: >>> >>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) >>> clear DSI_HS_CLK_CTRL; >>> else >>> set DSI_HS_CLK_CTRL; >>> >>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) >>> clear DSI_HIGH_SPEED_TRANS; >>> else >>> set DSI_HIGH_SPEED_TRANS; >>> >>> >>> MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- >>> continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because >>> that tells the controller to turn off the HS clock between high-speed >>> transmissions. >>> >>> MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power >>> mode. >>> >>> With the above two flags we can cover four cases: >>> >>> 1) non-continuous mode with messages transmitted in low-power mode >>> 2) non-continuous mode with messages transmitted in high-speed mode >>> 3) continuous mode with messages transmitted in low-power mode >> >> In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear >> DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but >> dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right. >> You mean that continuous mode is set by default implicitly? > > Yes, if the MIPI_DSI_MODE_NON_CONTINUOUS flag is not specified, then it > means the peripheral supports only continuous mode. > On more thing, in case of non-continuous clock mode, host controller can transmit data in low power or high speed. With MIPI_DSI_MODE_NON_CONTINUOUS flag, host controller can clear DSI_HS_CLK_CTRL or set it by default. However, we have no any flag to select low power or high speed transmission. Of course, as your patch of other thread, we can set MIPI_DSI_MSG_USE_LPM by default but I'm not sure that the change incurs what problem to all other panel devices. So I think it's better to add a new flag which decides host controller should transmit data in high speed or low power. i.e., MIPI_DSI_MODE_LPM at mipi dsi framework, if ((flags & MIPI_DSI_MODE_LPM) == 0) msg->flags |= MIPI_DSI_MSG_USE_LPM; at each host driver, if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) clear high speed clock of each SoC else set high speed clock of each SoC <- by default if ((msg->flags = MIPI_DSI_MSG_USE_LPM) == 0) clear high speed transmission of each SoC else set high speed t
[PATCHv2 2/5] rtc: s3c: Remove warning message when checking coding style with checkpatch script
From: Chanwoo Choi
This patch remove warning message when checking codeing style with checkpatch
script and reduce un-necessary i2c read operation on s3c_rtc_enable.
WARNING: line over 80 characters
#406: FILE: drivers/rtc/rtc-s3c.c:406:
+ if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_RTCEN) == 0) {
WARNING: line over 80 characters
#414: FILE: drivers/rtc/rtc-s3c.c:414:
+ if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_CNTSEL)) {
WARNING: line over 80 characters
#422: FILE: drivers/rtc/rtc-s3c.c:422:
+ if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_CLKRST)) {
WARNING: Missing a blank line after declarations
#451: FILE: drivers/rtc/rtc-s3c.c:451:
+ struct s3c_rtc_drv_data *data;
+ if (pdev->dev.of_node) {
WARNING: Missing a blank line after declarations
#453: FILE: drivers/rtc/rtc-s3c.c:453:
+ const struct of_device_id *match;
+ match = of_match_node(s3c_rtc_dt_match,
pdev->dev.of_node);
WARNING: DT compatible string "samsung,s3c2416-rtc" appears
un-documented -- check ./Documentation/devicetree/bindings/
#650: FILE: drivers/rtc/rtc-s3c.c:650:
+ .compatible = "samsung,s3c2416-rtc",
WARNING: DT compatible string "samsung,s3c2443-rtc" appears
un-documented -- check ./Documentation/devicetree/bindings/
#653: FILE: drivers/rtc/rtc-s3c.c:653:
+ .compatible = "samsung,s3c2443-rtc",
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 2 ++
drivers/rtc/rtc-s3c.c | 26 ---
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 7ac7259..06db446 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -3,6 +3,8 @@
Required properties:
- compatible: should be one of the following.
* "samsung,s3c2410-rtc" - for controllers compatible with s3c2410 rtc.
+* "samsung,s3c2416-rtc" - for controllers compatible with s3c2416 rtc.
+* "samsung,s3c2443-rtc" - for controllers compatible with s3c2443 rtc.
* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
- reg: physical base address of the controller and length of memory mapped
region.
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 1d9e158..d8f25bd 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -400,28 +400,28 @@ static const struct rtc_class_ops s3c_rtcops = {
static void s3c_rtc_enable(struct s3c_rtc *info, int en)
{
- unsigned int tmp;
+ unsigned int con, tmp;
if (!info->base)
return;
clk_enable(info->rtc_clk);
+
+ con = readw(info->base + S3C2410_RTCCON);
if (!en) {
- tmp = readw(info->base + S3C2410_RTCCON);
if (info->cpu_type == TYPE_S3C64XX)
- tmp &= ~S3C64XX_RTCCON_TICEN;
- tmp &= ~S3C2410_RTCCON_RTCEN;
- writew(tmp, info->base + S3C2410_RTCCON);
+ con &= ~S3C64XX_RTCCON_TICEN;
+ con &= ~S3C2410_RTCCON_RTCEN;
+ writew(con, info->base + S3C2410_RTCCON);
if (info->cpu_type != TYPE_S3C64XX) {
- tmp = readb(info->base + S3C2410_TICNT);
- tmp &= ~S3C2410_TICNT_ENABLE;
- writeb(tmp, info->base + S3C2410_TICNT);
+ con = readb(info->base + S3C2410_TICNT);
+ con &= ~S3C2410_TICNT_ENABLE;
+ writeb(con, info->base + S3C2410_TICNT);
}
} else {
/* re-enable the device, and check it is ok */
-
- if ((readw(info->base + S3C2410_RTCCON) & S3C2410_RTCCON_RTCEN)
== 0) {
+ if ((con & S3C2410_RTCCON_RTCEN) == 0) {
dev_info(info->dev, "rtc disabled, re-enabling\n");
tmp = readw(info->base + S3C2410_RTCCON);
@@ -429,7 +429,7 @@ static void s3c_rtc_enable(struct s3c_rtc *info, int en)
info->base + S3C2410_RTCCON);
}
- if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_CNTSEL)) {
+ if (con & S3C2410_RTCCON_CNTSEL) {
dev_info(info->dev, "removing RTCCON_CNTSEL\n");
tmp = readw(info->base + S3C2410_RTCCON);
@@ -437,7 +437,7 @@ static void s3c_rtc_enable(struct s3c_rtc *info, int en)
info->base + S3C2410_RTCCON);
}
- if ((readw(info->base + S3C2410_R
[PATCHv2 1/5] rtc: s3c: Define s3c_rtc structure to remove global variables.
From: Chanwoo Choi
This patch define s3c_rtc structure including necessary variables for S3C RTC
device instead of global variables. This patch improves the readability by
removing global variables.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
drivers/rtc/rtc-s3c.c | 448 ++
1 file changed, 235 insertions(+), 213 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 4958a36..1d9e158 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -43,125 +43,135 @@ struct s3c_rtc_drv_data {
int cpu_type;
};
-/* I have yet to find an S3C implementation with more than one
- * of these rtc blocks in */
+struct s3c_rtc {
+ struct device *dev;
+ struct rtc_device *rtc;
+
+ void __iomem *base;
+ struct clk *rtc_clk;
+ bool enabled;
-static struct clk *rtc_clk;
-static void __iomem *s3c_rtc_base;
-static int s3c_rtc_alarmno;
-static int s3c_rtc_tickno;
-static enum s3c_cpu_type s3c_rtc_cpu_type;
+ enum s3c_cpu_type cpu_type;
-static DEFINE_SPINLOCK(s3c_rtc_pie_lock);
+ int irq_alarm;
+ int irq_tick;
-static void s3c_rtc_alarm_clk_enable(bool enable)
+ spinlock_t pie_lock;
+ spinlock_t alarm_clk_lock;
+
+ int ticnt_save, ticnt_en_save;
+ bool wake_en;
+};
+
+static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, bool enable)
{
- static DEFINE_SPINLOCK(s3c_rtc_alarm_clk_lock);
- static bool alarm_clk_enabled;
unsigned long irq_flags;
- spin_lock_irqsave(&s3c_rtc_alarm_clk_lock, irq_flags);
+ spin_lock_irqsave(&info->alarm_clk_lock, irq_flags);
if (enable) {
- if (!alarm_clk_enabled) {
- clk_enable(rtc_clk);
- alarm_clk_enabled = true;
+ if (!info->enabled) {
+ clk_enable(info->rtc_clk);
+ info->enabled = true;
}
} else {
- if (alarm_clk_enabled) {
- clk_disable(rtc_clk);
- alarm_clk_enabled = false;
+ if (info->enabled) {
+ clk_disable(info->rtc_clk);
+ info->enabled = false;
}
}
- spin_unlock_irqrestore(&s3c_rtc_alarm_clk_lock, irq_flags);
+ spin_unlock_irqrestore(&info->alarm_clk_lock, irq_flags);
}
/* IRQ Handlers */
-
static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
{
- struct rtc_device *rdev = id;
+ struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(rtc_clk);
- rtc_update_irq(rdev, 1, RTC_AF | RTC_IRQF);
+ clk_enable(info->rtc_clk);
+ rtc_update_irq(info->rtc, 1, RTC_AF | RTC_IRQF);
- if (s3c_rtc_cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_ALM, s3c_rtc_base + S3C2410_INTP);
+ if (info->cpu_type == TYPE_S3C64XX)
+ writeb(S3C2410_INTP_ALM, info->base + S3C2410_INTP);
- clk_disable(rtc_clk);
+ clk_disable(info->rtc_clk);
- s3c_rtc_alarm_clk_enable(false);
+ s3c_rtc_alarm_clk_enable(info, false);
return IRQ_HANDLED;
}
static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
{
- struct rtc_device *rdev = id;
+ struct s3c_rtc *info = (struct s3c_rtc *)id;
+
+ clk_enable(info->rtc_clk);
+ rtc_update_irq(info->rtc, 1, RTC_PF | RTC_IRQF);
- clk_enable(rtc_clk);
- rtc_update_irq(rdev, 1, RTC_PF | RTC_IRQF);
+ if (info->cpu_type == TYPE_S3C64XX)
+ writeb(S3C2410_INTP_TIC, info->base + S3C2410_INTP);
- if (s3c_rtc_cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_TIC, s3c_rtc_base + S3C2410_INTP);
+ clk_disable(info->rtc_clk);
- clk_disable(rtc_clk);
return IRQ_HANDLED;
}
/* Update control registers */
static int s3c_rtc_setaie(struct device *dev, unsigned int enabled)
{
+ struct s3c_rtc *info = dev_get_drvdata(dev);
unsigned int tmp;
- dev_dbg(dev, "%s: aie=%d\n", __func__, enabled);
+ if (!info->base)
+ return -EINVAL;
+
+ dev_dbg(info->dev, "%s: aie=%d\n", __func__, enabled);
- clk_enable(rtc_clk);
- tmp = readb(s3c_rtc_base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
+ clk_enable(info->rtc_clk);
+ tmp = readb(info->base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
if (enabled)
tmp |= S3C2410_RTCALM_ALMEN;
- writeb(tmp, s3c_rtc_base + S3C2410_RTCALM);
- clk_disable(rtc_clk);
+ writeb(tmp, info->base + S3C2410_RTCALM);
+ clk_disable(info->rtc_clk);
- s3c_rtc_alarm_clk_enable(enabled);
+ s3c_rtc_alarm_clk_enable(info, enabled);
return 0;
}
-static int s3c_rtc_setfreq(struct device *dev, int freq)
+static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
{
- struct platform_device *pdev = to_platform_device(dev)
[PATCHv2 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC
From: Chanwoo Choi
This patch add support for RTC of Exynos3250 SoC. The Exynos3250 needs source
clock(32.768KHz) for RTC block. If source clock of RTC is registerd on clock
list of common clk framework, Exynos RTC drvier have to control this clock.
Clock list for s3c-rtc device:
- rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
- rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
(XRTCXTI: Specifies a clock from 32.768 kHz crystal pad with XRTCXTI and
XRTCXTO pins. RTC uses this clock as the source of a real-time clock.)
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 1 +
drivers/rtc/rtc-s3c.c | 93 ++-
2 files changed, 93 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 06db446..ab757b84 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -6,6 +6,7 @@ Required properties:
* "samsung,s3c2416-rtc" - for controllers compatible with s3c2416 rtc.
* "samsung,s3c2443-rtc" - for controllers compatible with s3c2443 rtc.
* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
+* "samsung,exynos3250-rtc" - for controllers compatible with exynos3250
rtc.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: Two interrupt numbers to the cpu should be specified. First
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 26a88f9..90dcf51 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -38,6 +38,7 @@ struct s3c_rtc {
void __iomem *base;
struct clk *rtc_clk;
+ struct clk *rtc_src_clk;
bool enabled;
struct s3c_rtc_data *data;
@@ -54,6 +55,7 @@ struct s3c_rtc {
struct s3c_rtc_data {
int max_user_freq;
+ bool needs_src_clk;
void (*irq_handler) (struct s3c_rtc *info, int mask);
void (*set_freq) (struct s3c_rtc *info, int freq);
@@ -73,10 +75,14 @@ static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info,
bool enable)
if (enable) {
if (!info->enabled) {
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
info->enabled = true;
}
} else {
if (info->enabled) {
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
info->enabled = false;
}
@@ -117,12 +123,16 @@ static int s3c_rtc_setaie(struct device *dev, unsigned
int enabled)
dev_dbg(info->dev, "%s: aie=%d\n", __func__, enabled);
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
tmp = readb(info->base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
if (enabled)
tmp |= S3C2410_RTCALM_ALMEN;
writeb(tmp, info->base + S3C2410_RTCALM);
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
s3c_rtc_alarm_clk_enable(info, enabled);
@@ -137,12 +147,16 @@ static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
return -EINVAL;
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
spin_lock_irq(&info->pie_lock);
if (info->data->set_freq)
info->data->set_freq(info, freq);
spin_unlock_irq(&info->pie_lock);
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
return 0;
@@ -158,6 +172,9 @@ static int s3c_rtc_gettime(struct device *dev, struct
rtc_time *rtc_tm)
return -EINVAL;
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
+
retry_get_time:
rtc_tm->tm_min = readb(info->base + S3C2410_RTCMIN);
rtc_tm->tm_hour = readb(info->base + S3C2410_RTCHOUR);
@@ -191,6 +208,8 @@ static int s3c_rtc_gettime(struct device *dev, struct
rtc_time *rtc_tm)
rtc_tm->tm_mon -= 1;
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
return rtc_valid_tm(rtc_tm);
@@ -216,6 +235,8 @@ static int s3c_rtc_settime(struct device *dev, struct
rtc_time *tm)
}
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
writeb(bin2bcd(tm->tm_sec), info->base + S3C2410_RTCSEC);
writeb(bin2bcd(tm
[PATCHv2 5/5] ARM: dts: Fix wrong compatible string of Exynos3250 RTC dt node
From: Chanwoo Choi
This patch fix wrong compatible string of Exynos3250 RTC (Real-Time Clock) dt
node. The RTC of Exynos3250 must need additional source clock (XrtcXTI).
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index cd6a69a..1be5ef8 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -192,7 +192,7 @@
};
rtc: rtc@1007 {
- compatible = "samsung,s3c6410-rtc";
+ compatible = "samsung,exynos3250-rtc";
reg = <0x1007 0x100>;
interrupts = <0 73 0>, <0 74 0>;
status = "disabled";
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/5] rtc: s3c: Add s3c_rtc_data structure to use variant data instead of s3c_cpu_type
From: Chanwoo Choi
This patch add s3c_rtc_data structure to variant data according to SoC type.
The s3c_rtc_data structure includes some functions to control RTC operation
and specific data dependent on SoC type.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
drivers/rtc/rtc-s3c.c | 464 +++---
1 file changed, 289 insertions(+), 175 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index d8f25bd..26a88f9 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -32,17 +32,6 @@
#include
#include "rtc-s3c.h"
-enum s3c_cpu_type {
- TYPE_S3C2410,
- TYPE_S3C2416,
- TYPE_S3C2443,
- TYPE_S3C64XX,
-};
-
-struct s3c_rtc_drv_data {
- int cpu_type;
-};
-
struct s3c_rtc {
struct device *dev;
struct rtc_device *rtc;
@@ -51,7 +40,7 @@ struct s3c_rtc {
struct clk *rtc_clk;
bool enabled;
- enum s3c_cpu_type cpu_type;
+ struct s3c_rtc_data *data;
int irq_alarm;
int irq_tick;
@@ -63,6 +52,19 @@ struct s3c_rtc {
bool wake_en;
};
+struct s3c_rtc_data {
+ int max_user_freq;
+
+ void (*irq_handler) (struct s3c_rtc *info, int mask);
+ void (*set_freq) (struct s3c_rtc *info, int freq);
+ void (*enable_tick) (struct s3c_rtc *info, struct seq_file *seq);
+ void (*select_tick_clk) (struct s3c_rtc *info);
+ void (*save_tick_cnt) (struct s3c_rtc *info);
+ void (*restore_tick_cnt) (struct s3c_rtc *info);
+ void (*enable) (struct s3c_rtc *info);
+ void (*disable) (struct s3c_rtc *info);
+};
+
static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, bool enable)
{
unsigned long irq_flags;
@@ -83,34 +85,22 @@ static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info,
bool enable)
}
/* IRQ Handlers */
-static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
+static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
{
struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(info->rtc_clk);
- rtc_update_irq(info->rtc, 1, RTC_AF | RTC_IRQF);
-
- if (info->cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_ALM, info->base + S3C2410_INTP);
-
- clk_disable(info->rtc_clk);
-
- s3c_rtc_alarm_clk_enable(info, false);
+ if (info->data->irq_handler)
+ info->data->irq_handler(info, S3C2410_INTP_TIC);
return IRQ_HANDLED;
}
-static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
+static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
{
struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(info->rtc_clk);
- rtc_update_irq(info->rtc, 1, RTC_PF | RTC_IRQF);
-
- if (info->cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_TIC, info->base + S3C2410_INTP);
-
- clk_disable(info->rtc_clk);
+ if (info->data->irq_handler)
+ info->data->irq_handler(info, S3C2410_INTP_ALM);
return IRQ_HANDLED;
}
@@ -140,36 +130,18 @@ static int s3c_rtc_setaie(struct device *dev, unsigned
int enabled)
return 0;
}
+/* Set RTC frequency */
static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
{
- unsigned int tmp = 0;
- int val;
-
if (!is_power_of_2(freq))
return -EINVAL;
clk_enable(info->rtc_clk);
spin_lock_irq(&info->pie_lock);
- if (info->cpu_type != TYPE_S3C64XX) {
- tmp = readb(info->base + S3C2410_TICNT);
- tmp &= S3C2410_TICNT_ENABLE;
- }
-
- val = (info->rtc->max_user_freq / freq) - 1;
-
- if (info->cpu_type == TYPE_S3C2416 || info->cpu_type == TYPE_S3C2443) {
- tmp |= S3C2443_TICNT_PART(val);
- writel(S3C2443_TICNT1_PART(val), info->base + S3C2443_TICNT1);
+ if (info->data->set_freq)
+ info->data->set_freq(info, freq);
- if (info->cpu_type == TYPE_S3C2416)
- writel(S3C2416_TICNT2_PART(val),
- info->base + S3C2416_TICNT2);
- } else {
- tmp |= val;
- }
-
- writel(tmp, info->base + S3C2410_TICNT);
spin_unlock_irq(&info->pie_lock);
clk_disable(info->rtc_clk);
@@ -177,7 +149,6 @@ static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
}
/* Time read/write */
-
static int s3c_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
{
struct s3c_rtc *info = dev_get_drvdata(dev);
@@ -370,22 +341,17 @@ static int s3c_rtc_setalarm(struct device *dev, struct
rtc_wkalrm *alrm)
static int s3c_rtc_proc(struct device *dev, struct seq_file *seq)
{
struct s3c_rtc *info = dev_get_drvdata(dev);
- unsigned int ticnt;
if (!info->base)
return -EINVAL;
clk_enable(info->rtc_clk);
- if (info->cpu_type == TYPE_S3C64XX) {
- ticnt = readw(info->base + S3C2410_RTCCON);
- ticnt &= S3C64XX_RT
[PATCHv2 0/5] rtc: s3c: Refactoring s3c-rtc driver and support Exynos3250 RTC
From: Chanwoo Choi This patchset clean up codes to improve readability as following and support the RTC of Exynos3250 SoC. - Remove global variables and then use new s3c_rtc structure - Remove warn message with checking checkpatch script - Use variant structure according to SoC type instead of legacy enum variable(s3c_cpu_type) Changes from v1: - Fix NULL pointer panic of s3c_rtc_settime() - Check info->base value to protect NULL pointer panic Chanwoo Choi (5): rtc: s3c: Define s3c_rtc structure to remove global variables. rtc: s3c: Remove warning message when checking coding style with checkpatch script rtc: s3c: Add s3c_rtc_data structure to use variant data instead of s3c_cpu_type rtc: s3c: Add support for RTC of Exynos3250 SoC ARM: dts: Fix wrong compatible string of Exynos3250 RTC dt node Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 3 + arch/arm/boot/dts/exynos3250.dtsi | 2 +- drivers/rtc/rtc-s3c.c | 869 ++ 3 files changed, 553 insertions(+), 321 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv10 4/5] ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
On Thu, Aug 7, 2014 at 2:38 AM, Jaehoon Chung wrote:
> 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
> Reviewed-by: Tushar Behera
> Reviewed-by: Ulf Hansson
> Acked-by: Seungwon Jeon
> Acked-by: Dinh Nguyen
> ---
I've queued this patch in my tree for v3.18.
Thanks,
Dinh
> 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
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] ARM: exynos_defconfig: Enable SBS battery support
Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have a SBS-compliant gas gauge battery. Enable to built it so the needed support is available for these boards. Suggested-by: Doug Anderson Signed-off-by: Javier Martinez Canillas Acked-by: Kukjin Kim Reviewed-by: Doug Anderson --- Changes since v1: - Don't build it as a module since is the exception in exynos_defconfig. Suggested by Bartlomiej Zolnierkiewicz. arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index fc7d168..c390bb9 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y CONFIG_I2C_S3C2410=y CONFIG_DEBUG_GPIO=y CONFIG_POWER_SUPPLY=y +CONFIG_BATTERY_SBS=y CONFIG_CHARGER_TPS65090=y # CONFIG_HWMON is not set CONFIG_THERMAL=y -- 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: [RESEND PATCH 2/2] ARM: dts: Add tps65090 FET constraints on Peach Pit and Pi
Hello Doug,
On 08/11/2014 05:57 PM, Doug Anderson wrote:
> Javier,
>
> On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas
> wrote:
>> Both Exynos5420 Peach Pit and Exynos5800 Peach Pi boards
>> have a tps65090 PMU that has a number of switches (FETs)
>> that are just on/off devices but they do have a current
>> limit and the output voltage of the switch is ramped up
>> within a controlled slope.
>>
>> After the switch is turned on, a safety timer is started
>> and before this timer times out the output voltage must
>> have reached the input voltage. Otherwise the switch is
>> turned off expecting an overload condition.
>>
>> So using the maximum output voltage slew rate and the timer
>> minimum and maximum timeouts, a voltage constraints can be
>> expressed as bounded limits for the timeout. That is what
>> is used in the board schematics and should be in the DT too.
>
> I don't understand this, but if you and Mark are happy with it...
>
> ...I'm also not 100% certain what the above description has to do with
> this change, but I'll admit to having only skimmed some of the earlier
> conversations.
>
As I stated before, I wrongly assumed from where the constraints in the
schematics came from. From the latest doc I now know that there is a
"recommended operating conditions table". I'll fix it in v2, sorry for the
confusion...
>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>> arch/arm/boot/dts/exynos5420-peach-pit.dts | 14 ++
>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 14 ++
>> 2 files changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> index d8710c1..eefafe6 100644
>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> @@ -386,27 +386,41 @@
>> };
>> tps65090_fet1: fet1 {
>> regulator-name = "vcd_led";
>> + regulator-min-microvolt =
>> <500>;
>> + regulator-max-microvolt =
>> <170>;
>
> This is almost certainly wrong. Your max is smaller than your min.
> Perhaps you want an extra 0.
>
>> };
>> tps65090_fet2: fet2 {
>> regulator-name = "video_mid";
>> + regulator-min-microvolt =
>> <450>;
>> + regulator-max-microvolt =
>> <550>;
>> regulator-always-on;
>> };
>> tps65090_fet3: fet3 {
>> regulator-name = "wwan_r";
>> + regulator-min-microvolt =
>> <300>;
>> + regulator-max-microvolt =
>> <550>;
>> regulator-always-on;
>> };
>> tps65090_fet4: fet4 {
>> regulator-name = "sdcard";
>> + regulator-min-microvolt =
>> <300>;
>> + regulator-max-microvolt =
>> <550>;
>> regulator-always-on;
>> };
>> tps65090_fet5: fet5 {
>> regulator-name = "camout";
>> + regulator-min-microvolt =
>> <300>;
>> + regulator-max-microvolt =
>> <550>;
>> };
>> tps65090_fet6: fet6 {
>> regulator-name = "lcd_vdd";
>> + regulator-min-microvolt =
>> <300>;
>> + regulator-max-microvolt =
>> <550>;
>> };
>> tps65090_fet7: fet7 {
>> regulator-name =
>> "video_mid_1a";
>> + regulator-min-microvolt =
>> <300>;
>> + regulator-max-microvolt =
>> <550>;
>> regulator-always-on;
>> };
>> tps65090_ldo1: ldo1 {
>> diff
Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Hello Bartlomiej, On 08/11/2014 07:28 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, August 11, 2014 06:23:01 PM Javier Martinez Canillas wrote: >> Hello, >> >> On 08/11/2014 05:59 PM, Doug Anderson wrote: >> > Bartlomiej, >> > >> > On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz >> > wrote: >> >> >> >> Hi, >> >> >> >> On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote: >> >>> Hello Bartlomiej, >> >>> >> >>> On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote: >> >>> >> index fc7d168..c390bb9 100644 >> >>> >> --- a/arch/arm/configs/exynos_defconfig >> >>> >> +++ b/arch/arm/configs/exynos_defconfig >> >>> >> @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y >> >>> >> CONFIG_I2C_S3C2410=y >> >>> >> CONFIG_DEBUG_GPIO=y >> >>> >> CONFIG_POWER_SUPPLY=y >> >>> >> +CONFIG_BATTERY_SBS=m >> >>> > >> >>> > Why not make it "=y"? >> >>> > >> >>> > Rationale: >> >>> > - currently no hardware related option uses "=m" in exynos_defconfig >> >>> > - it would match the SBS option usage in multi_v7_defconfig >> >>> > >> >>> >> CONFIG_CHARGER_TPS65090=y >> >>> >> # CONFIG_HWMON is not set >> >>> >> CONFIG_THERMAL=y >> >>> > >> >>> >> >>> I know but personally I think this should be changed. The idea of having >> >>> a multi >> >>> platform kernel is to build a single kernel image that can be used to >> >>> boot >> >>> different platforms. Not all platforms have a SBS-compliant battery so >> >>> this >> >>> support shouldn't be built in the kernel image IMHO. >> >>> >> >>> This also matches to what real users will do since distributions most >> >>> likely >> >>> will have a minimal kernel and every possible hardware support will be >> >>> enabled >> >>> as a loadable kernel module. This is what distros do for other platforms >> >>> too. >> >>> >> >>> If someone has a different use case and wants a kernel image that is >> >>> optimized >> >>> for a particular platform then she has to create its own defconfig >> >>> anyways. >> >> >> >> Distributions usually use their own configs anyway and the current most >> >> popular use case for exynos_defconfig (not multi_v7_defconfig) seems to >> >> be to build kernel image alone and use it without any modules: >> >> >> >> $ grep "=m" arch/arm/configs/exynos_defconfig >> >> CONFIG_DM_CRYPT=m >> >> >> >> $ grep "=m" .config >> >> CONFIG_NET_IP_TUNNEL=m >> >> CONFIG_INET_TUNNEL=m >> >> CONFIG_IPV6=m >> >> CONFIG_INET6_XFRM_MODE_TRANSPORT=m >> >> CONFIG_INET6_XFRM_MODE_TUNNEL=m >> >> CONFIG_INET6_XFRM_MODE_BEET=m >> >> CONFIG_IPV6_SIT=m >> >> CONFIG_DM_CRYPT=m >> >> CONFIG_CRYPTO_RNG=m >> >> CONFIG_CRYPTO_ANSI_CPRNG=m >> >> >> >> What I'm trying to say is that there is a high probability that people >> >> will continue to use just the kernel image for exynos_defconfig and >> >> will therefore miss SBS battery support altogether (which is only 3.6 >> >> kB of code more in the kernel image so there is no much gain in making >> >> it modular currently). >> > >> > I'm not against making it =y for exynos_defconfig. I do pretty >> > strongly agree that the multi_v7 version should be =m eventually, >> > though. We'd need to do everything we can to make that kernel >> > smaller. >> > >> >> Same for me. I don't have such a strong opinion about this so if you think >> that >> I should re-spin to change to =m, I will. >> >> I do think that we should try to keep the delta between exynos_defconfig and >> multi_v7_defconfig as small as possible and eventually even get rid of >> exynos_defconfig. Since building everything as built-in and having a config > > I completely agree. I proposed exynos_defconfig removal as soon as > Exynos gained multiplatform support (and before exynos_defconfig > started getting out-of-sync with multi_v7_defconfig). There were > arguments that it is still useful in some cases. I think that if > it would be possible to go from a modular multi_v7_defconfig to > a modular/built-in single platform config (using a script?) all > such use cases will be covered. > >> targeted to a single platform is not aligned with the effort to have support >> for >> multi platforms kernels. > > Currently even for multi_v7_defconfig "=m" seems to be an exception > from the general rule: > > $ grep "=m" arch/arm/configs/multi_v7_defconfig > CONFIG_INET6_AH=m > CONFIG_INET6_ESP=m > CONFIG_INET6_IPCOMP=m > CONFIG_IPV6_MIP6=m > CONFIG_IPV6_TUNNEL=m > CONFIG_CFG80211=m > CONFIG_MAC80211=m > CONFIG_BRCMFMAC=m > CONFIG_RT2X00=m > CONFIG_RT2800USB=m > > $ wc -l arch/arm/configs/multi_v7_defconfig > 405 arch/arm/configs/multi_v7_defconfig > Again, I think this is more of a consequence of people adding the config they use (which as you said in most cases is just built everything in the kernel to avoid copying modules) than something that was made on purpose. > so I would vote for CONFIG_BATTERY_SBS=y for both configs. Especially > since it results in only 3.6 kB bigger kernel image (0.05% kernel size > increase for kernel image built
Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Hi, On Mon, Aug 11, 2014 at 10:28 AM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, August 11, 2014 06:23:01 PM Javier Martinez Canillas wrote: >> Hello, >> >> On 08/11/2014 05:59 PM, Doug Anderson wrote: >> > Bartlomiej, >> > >> > On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz >> > wrote: >> >> >> >> Hi, >> >> >> >> On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote: >> >>> Hello Bartlomiej, >> >>> >> >>> On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote: >> >>> >> index fc7d168..c390bb9 100644 >> >>> >> --- a/arch/arm/configs/exynos_defconfig >> >>> >> +++ b/arch/arm/configs/exynos_defconfig >> >>> >> @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y >> >>> >> CONFIG_I2C_S3C2410=y >> >>> >> CONFIG_DEBUG_GPIO=y >> >>> >> CONFIG_POWER_SUPPLY=y >> >>> >> +CONFIG_BATTERY_SBS=m >> >>> > >> >>> > Why not make it "=y"? >> >>> > >> >>> > Rationale: >> >>> > - currently no hardware related option uses "=m" in exynos_defconfig >> >>> > - it would match the SBS option usage in multi_v7_defconfig >> >>> > >> >>> >> CONFIG_CHARGER_TPS65090=y >> >>> >> # CONFIG_HWMON is not set >> >>> >> CONFIG_THERMAL=y >> >>> > >> >>> >> >>> I know but personally I think this should be changed. The idea of having >> >>> a multi >> >>> platform kernel is to build a single kernel image that can be used to >> >>> boot >> >>> different platforms. Not all platforms have a SBS-compliant battery so >> >>> this >> >>> support shouldn't be built in the kernel image IMHO. >> >>> >> >>> This also matches to what real users will do since distributions most >> >>> likely >> >>> will have a minimal kernel and every possible hardware support will be >> >>> enabled >> >>> as a loadable kernel module. This is what distros do for other platforms >> >>> too. >> >>> >> >>> If someone has a different use case and wants a kernel image that is >> >>> optimized >> >>> for a particular platform then she has to create its own defconfig >> >>> anyways. >> >> >> >> Distributions usually use their own configs anyway and the current most >> >> popular use case for exynos_defconfig (not multi_v7_defconfig) seems to >> >> be to build kernel image alone and use it without any modules: >> >> >> >> $ grep "=m" arch/arm/configs/exynos_defconfig >> >> CONFIG_DM_CRYPT=m >> >> >> >> $ grep "=m" .config >> >> CONFIG_NET_IP_TUNNEL=m >> >> CONFIG_INET_TUNNEL=m >> >> CONFIG_IPV6=m >> >> CONFIG_INET6_XFRM_MODE_TRANSPORT=m >> >> CONFIG_INET6_XFRM_MODE_TUNNEL=m >> >> CONFIG_INET6_XFRM_MODE_BEET=m >> >> CONFIG_IPV6_SIT=m >> >> CONFIG_DM_CRYPT=m >> >> CONFIG_CRYPTO_RNG=m >> >> CONFIG_CRYPTO_ANSI_CPRNG=m >> >> >> >> What I'm trying to say is that there is a high probability that people >> >> will continue to use just the kernel image for exynos_defconfig and >> >> will therefore miss SBS battery support altogether (which is only 3.6 >> >> kB of code more in the kernel image so there is no much gain in making >> >> it modular currently). >> > >> > I'm not against making it =y for exynos_defconfig. I do pretty >> > strongly agree that the multi_v7 version should be =m eventually, >> > though. We'd need to do everything we can to make that kernel >> > smaller. >> > >> >> Same for me. I don't have such a strong opinion about this so if you think >> that >> I should re-spin to change to =m, I will. >> >> I do think that we should try to keep the delta between exynos_defconfig and >> multi_v7_defconfig as small as possible and eventually even get rid of >> exynos_defconfig. Since building everything as built-in and having a config > > I completely agree. I proposed exynos_defconfig removal as soon as > Exynos gained multiplatform support (and before exynos_defconfig > started getting out-of-sync with multi_v7_defconfig). There were > arguments that it is still useful in some cases. I think that if > it would be possible to go from a modular multi_v7_defconfig to > a modular/built-in single platform config (using a script?) all > such use cases will be covered. There's one really nice thing about having an "exynos_defconfig". It makes it a little easier to tease apart what's actually needed if you just want to build a product kernel that support exynos. Most product kernels shipping in embedded devices only support one or maybe a small number of SoCs. If you need to try to figure out what parts of the "multi_v7" config is relevant then it's very hard. It's also nice to help measure multiplatform code bloat. You can keep measuring the output kernel size of the exynos kernel to see how much bloat all of the mutliplatform stuff has added. > so I would vote for CONFIG_BATTERY_SBS=y for both configs. Especially > since it results in only 3.6 kB bigger kernel image (0.05% kernel size > increase for kernel image built with exynos_defconfig, probably a lot > less for multi_v7_defconfig one). Death by 1000 cuts is a very painful death indeed, even if each cut is small. -Doug -- To unsubscribe from this list: send the line "unsu
Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Hi, On Monday, August 11, 2014 06:23:01 PM Javier Martinez Canillas wrote: > Hello, > > On 08/11/2014 05:59 PM, Doug Anderson wrote: > > Bartlomiej, > > > > On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz > > wrote: > >> > >> Hi, > >> > >> On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote: > >>> Hello Bartlomiej, > >>> > >>> On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote: > >>> >> index fc7d168..c390bb9 100644 > >>> >> --- a/arch/arm/configs/exynos_defconfig > >>> >> +++ b/arch/arm/configs/exynos_defconfig > >>> >> @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y > >>> >> CONFIG_I2C_S3C2410=y > >>> >> CONFIG_DEBUG_GPIO=y > >>> >> CONFIG_POWER_SUPPLY=y > >>> >> +CONFIG_BATTERY_SBS=m > >>> > > >>> > Why not make it "=y"? > >>> > > >>> > Rationale: > >>> > - currently no hardware related option uses "=m" in exynos_defconfig > >>> > - it would match the SBS option usage in multi_v7_defconfig > >>> > > >>> >> CONFIG_CHARGER_TPS65090=y > >>> >> # CONFIG_HWMON is not set > >>> >> CONFIG_THERMAL=y > >>> > > >>> > >>> I know but personally I think this should be changed. The idea of having > >>> a multi > >>> platform kernel is to build a single kernel image that can be used to boot > >>> different platforms. Not all platforms have a SBS-compliant battery so > >>> this > >>> support shouldn't be built in the kernel image IMHO. > >>> > >>> This also matches to what real users will do since distributions most > >>> likely > >>> will have a minimal kernel and every possible hardware support will be > >>> enabled > >>> as a loadable kernel module. This is what distros do for other platforms > >>> too. > >>> > >>> If someone has a different use case and wants a kernel image that is > >>> optimized > >>> for a particular platform then she has to create its own defconfig > >>> anyways. > >> > >> Distributions usually use their own configs anyway and the current most > >> popular use case for exynos_defconfig (not multi_v7_defconfig) seems to > >> be to build kernel image alone and use it without any modules: > >> > >> $ grep "=m" arch/arm/configs/exynos_defconfig > >> CONFIG_DM_CRYPT=m > >> > >> $ grep "=m" .config > >> CONFIG_NET_IP_TUNNEL=m > >> CONFIG_INET_TUNNEL=m > >> CONFIG_IPV6=m > >> CONFIG_INET6_XFRM_MODE_TRANSPORT=m > >> CONFIG_INET6_XFRM_MODE_TUNNEL=m > >> CONFIG_INET6_XFRM_MODE_BEET=m > >> CONFIG_IPV6_SIT=m > >> CONFIG_DM_CRYPT=m > >> CONFIG_CRYPTO_RNG=m > >> CONFIG_CRYPTO_ANSI_CPRNG=m > >> > >> What I'm trying to say is that there is a high probability that people > >> will continue to use just the kernel image for exynos_defconfig and > >> will therefore miss SBS battery support altogether (which is only 3.6 > >> kB of code more in the kernel image so there is no much gain in making > >> it modular currently). > > > > I'm not against making it =y for exynos_defconfig. I do pretty > > strongly agree that the multi_v7 version should be =m eventually, > > though. We'd need to do everything we can to make that kernel > > smaller. > > > > Same for me. I don't have such a strong opinion about this so if you think > that > I should re-spin to change to =m, I will. > > I do think that we should try to keep the delta between exynos_defconfig and > multi_v7_defconfig as small as possible and eventually even get rid of > exynos_defconfig. Since building everything as built-in and having a config I completely agree. I proposed exynos_defconfig removal as soon as Exynos gained multiplatform support (and before exynos_defconfig started getting out-of-sync with multi_v7_defconfig). There were arguments that it is still useful in some cases. I think that if it would be possible to go from a modular multi_v7_defconfig to a modular/built-in single platform config (using a script?) all such use cases will be covered. > targeted to a single platform is not aligned with the effort to have support > for > multi platforms kernels. Currently even for multi_v7_defconfig "=m" seems to be an exception from the general rule: $ grep "=m" arch/arm/configs/multi_v7_defconfig CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_IPV6_MIP6=m CONFIG_IPV6_TUNNEL=m CONFIG_CFG80211=m CONFIG_MAC80211=m CONFIG_BRCMFMAC=m CONFIG_RT2X00=m CONFIG_RT2800USB=m $ wc -l arch/arm/configs/multi_v7_defconfig 405 arch/arm/configs/multi_v7_defconfig so I would vote for CONFIG_BATTERY_SBS=y for both configs. Especially since it results in only 3.6 kB bigger kernel image (0.05% kernel size increase for kernel image built with exynos_defconfig, probably a lot less for multi_v7_defconfig one). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] reset: Add a defer reset object to send board specific reset
On Fri, Aug 08, 2014 at 04:23:09PM +0200, Philipp Zabel wrote: > Am Dienstag, den 08.07.2014, 11:38 +0200 schrieb Linus Walleij: > > On Tue, Jul 8, 2014 at 10:05 AM, Maxime Ripard > > wrote: > > > On Tue, Jul 08, 2014 at 09:52:03AM +0200, Linus Walleij wrote: > > >> On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin wrote: > > >> > > >> > The Problem > > >> > --- > > >> > The reset signal on a hardware board is send either: > > >> > - during machine initialization > > >> > - during bus master's initialization > > >> > > >> I just thought about this a bit, since there isn't already a generic GPIO > > >> reset driver, just call this drivers/reset/reset-gpio.c and make the > > >> ability to deferral just a configuration detail of the GPIO reset driver. > > > > > > Philipp has been working on one for quite some time. See > > > http://www.spinics.net/lists/arm-kernel/msg321927.html > > > > > > However, it seems to progress slowly, and we don't seem to be able to > > > reach a consensus here. > > Mostly because Maxime and I seem to have a completely different opinion > and nobody else argued one way or the other. Yep, mostly because I don't see how a generic approach can work. The existing reset-gpios property only provide the gpio to use, but some informations are encoded in the driver, such as the reset duration, or a reset sequence if any. How do you plan on giving that information to your generic driver? The only solution I can think of would be to add an extra property that your code would parse. But then, you break the existing DT bindings. And if we're going to break those bindings, at least do it in a way consistent with reset bindings. Plus, your approach doesn't cover the weird corner cases such as: - reset-gpio - wlf,reset-gpios - phy-reset-gpios - snps,reset-gpio - the drivers that need several gpio and expect the reset one as a positional argument. - etc. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [RESEND PATCH 2/2] ARM: dts: Add tps65090 FET constraints on Peach Pit and Pi
Hello Mark, On 08/11/2014 06:02 PM, Mark Brown wrote: > On Mon, Aug 11, 2014 at 08:57:24AM -0700, Doug Anderson wrote: >> On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas > >> > After the switch is turned on, a safety timer is started >> > and before this timer times out the output voltage must >> > have reached the input voltage. Otherwise the switch is >> > turned off expecting an overload condition. > >> > So using the maximum output voltage slew rate and the timer >> > minimum and maximum timeouts, a voltage constraints can be >> > expressed as bounded limits for the timeout. That is what >> > is used in the board schematics and should be in the DT too. > >> I don't understand this, but if you and Mark are happy with it... > > I have not looked at this change to my knowledge. > No worries, I have to re-spin anyways to fix the 17v typo that Doug pointed out. But basically is related to our previous discussion in patch: "[RFC 3/5] regulator: core: Only apply constraints if available on list voltage" where you explained [0] to me that child regulators should explicit set their constraints instead of getting from its parent supply. So this patch adds the needed constraints for the children FETs even when their output voltage depend on its parent supply. >> ...I'm also not 100% certain what the above description has to do with >> this change, but I'll admit to having only skimmed some of the earlier >> conversations. > > It's not at all clear to me either looking at the quoted section. > Yes, the commit message is not great to say the least. Also I didn't have the last version of the documentation so I misunderstood from where the constraints mentioned in the schematics came from. Will fix the commit message when posting v2. Thanks a lot and best regards, Javier [0]: https://lkml.org/lkml/2014/7/30/99 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Hello, On 08/11/2014 05:59 PM, Doug Anderson wrote: > Bartlomiej, > > On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz > wrote: >> >> Hi, >> >> On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote: >>> Hello Bartlomiej, >>> >>> On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote: >>> >> index fc7d168..c390bb9 100644 >>> >> --- a/arch/arm/configs/exynos_defconfig >>> >> +++ b/arch/arm/configs/exynos_defconfig >>> >> @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y >>> >> CONFIG_I2C_S3C2410=y >>> >> CONFIG_DEBUG_GPIO=y >>> >> CONFIG_POWER_SUPPLY=y >>> >> +CONFIG_BATTERY_SBS=m >>> > >>> > Why not make it "=y"? >>> > >>> > Rationale: >>> > - currently no hardware related option uses "=m" in exynos_defconfig >>> > - it would match the SBS option usage in multi_v7_defconfig >>> > >>> >> CONFIG_CHARGER_TPS65090=y >>> >> # CONFIG_HWMON is not set >>> >> CONFIG_THERMAL=y >>> > >>> >>> I know but personally I think this should be changed. The idea of having a >>> multi >>> platform kernel is to build a single kernel image that can be used to boot >>> different platforms. Not all platforms have a SBS-compliant battery so this >>> support shouldn't be built in the kernel image IMHO. >>> >>> This also matches to what real users will do since distributions most likely >>> will have a minimal kernel and every possible hardware support will be >>> enabled >>> as a loadable kernel module. This is what distros do for other platforms >>> too. >>> >>> If someone has a different use case and wants a kernel image that is >>> optimized >>> for a particular platform then she has to create its own defconfig anyways. >> >> Distributions usually use their own configs anyway and the current most >> popular use case for exynos_defconfig (not multi_v7_defconfig) seems to >> be to build kernel image alone and use it without any modules: >> >> $ grep "=m" arch/arm/configs/exynos_defconfig >> CONFIG_DM_CRYPT=m >> >> $ grep "=m" .config >> CONFIG_NET_IP_TUNNEL=m >> CONFIG_INET_TUNNEL=m >> CONFIG_IPV6=m >> CONFIG_INET6_XFRM_MODE_TRANSPORT=m >> CONFIG_INET6_XFRM_MODE_TUNNEL=m >> CONFIG_INET6_XFRM_MODE_BEET=m >> CONFIG_IPV6_SIT=m >> CONFIG_DM_CRYPT=m >> CONFIG_CRYPTO_RNG=m >> CONFIG_CRYPTO_ANSI_CPRNG=m >> >> What I'm trying to say is that there is a high probability that people >> will continue to use just the kernel image for exynos_defconfig and >> will therefore miss SBS battery support altogether (which is only 3.6 >> kB of code more in the kernel image so there is no much gain in making >> it modular currently). > > I'm not against making it =y for exynos_defconfig. I do pretty > strongly agree that the multi_v7 version should be =m eventually, > though. We'd need to do everything we can to make that kernel > smaller. > Same for me. I don't have such a strong opinion about this so if you think that I should re-spin to change to =m, I will. I do think that we should try to keep the delta between exynos_defconfig and multi_v7_defconfig as small as possible and eventually even get rid of exynos_defconfig. Since building everything as built-in and having a config targeted to a single platform is not aligned with the effort to have support for multi platforms kernels. > -Doug > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 2/2] ARM: dts: Add tps65090 FET constraints on Peach Pit and Pi
On Mon, Aug 11, 2014 at 08:57:24AM -0700, Doug Anderson wrote: > On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas > > After the switch is turned on, a safety timer is started > > and before this timer times out the output voltage must > > have reached the input voltage. Otherwise the switch is > > turned off expecting an overload condition. > > So using the maximum output voltage slew rate and the timer > > minimum and maximum timeouts, a voltage constraints can be > > expressed as bounded limits for the timeout. That is what > > is used in the board schematics and should be in the DT too. > I don't understand this, but if you and Mark are happy with it... I have not looked at this change to my knowledge. > ...I'm also not 100% certain what the above description has to do with > this change, but I'll admit to having only skimmed some of the earlier > conversations. It's not at all clear to me either looking at the quoted section. signature.asc Description: Digital signature
Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Bartlomiej, On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote: >> Hello Bartlomiej, >> >> On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote: >> >> index fc7d168..c390bb9 100644 >> >> --- a/arch/arm/configs/exynos_defconfig >> >> +++ b/arch/arm/configs/exynos_defconfig >> >> @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y >> >> CONFIG_I2C_S3C2410=y >> >> CONFIG_DEBUG_GPIO=y >> >> CONFIG_POWER_SUPPLY=y >> >> +CONFIG_BATTERY_SBS=m >> > >> > Why not make it "=y"? >> > >> > Rationale: >> > - currently no hardware related option uses "=m" in exynos_defconfig >> > - it would match the SBS option usage in multi_v7_defconfig >> > >> >> CONFIG_CHARGER_TPS65090=y >> >> # CONFIG_HWMON is not set >> >> CONFIG_THERMAL=y >> > >> >> I know but personally I think this should be changed. The idea of having a >> multi >> platform kernel is to build a single kernel image that can be used to boot >> different platforms. Not all platforms have a SBS-compliant battery so this >> support shouldn't be built in the kernel image IMHO. >> >> This also matches to what real users will do since distributions most likely >> will have a minimal kernel and every possible hardware support will be >> enabled >> as a loadable kernel module. This is what distros do for other platforms too. >> >> If someone has a different use case and wants a kernel image that is >> optimized >> for a particular platform then she has to create its own defconfig anyways. > > Distributions usually use their own configs anyway and the current most > popular use case for exynos_defconfig (not multi_v7_defconfig) seems to > be to build kernel image alone and use it without any modules: > > $ grep "=m" arch/arm/configs/exynos_defconfig > CONFIG_DM_CRYPT=m > > $ grep "=m" .config > CONFIG_NET_IP_TUNNEL=m > CONFIG_INET_TUNNEL=m > CONFIG_IPV6=m > CONFIG_INET6_XFRM_MODE_TRANSPORT=m > CONFIG_INET6_XFRM_MODE_TUNNEL=m > CONFIG_INET6_XFRM_MODE_BEET=m > CONFIG_IPV6_SIT=m > CONFIG_DM_CRYPT=m > CONFIG_CRYPTO_RNG=m > CONFIG_CRYPTO_ANSI_CPRNG=m > > What I'm trying to say is that there is a high probability that people > will continue to use just the kernel image for exynos_defconfig and > will therefore miss SBS battery support altogether (which is only 3.6 > kB of code more in the kernel image so there is no much gain in making > it modular currently). I'm not against making it =y for exynos_defconfig. I do pretty strongly agree that the multi_v7 version should be =m eventually, though. We'd need to do everything we can to make that kernel smaller. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 2/2] ARM: dts: Add tps65090 FET constraints on Peach Pit and Pi
Javier,
On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas
wrote:
> Both Exynos5420 Peach Pit and Exynos5800 Peach Pi boards
> have a tps65090 PMU that has a number of switches (FETs)
> that are just on/off devices but they do have a current
> limit and the output voltage of the switch is ramped up
> within a controlled slope.
>
> After the switch is turned on, a safety timer is started
> and before this timer times out the output voltage must
> have reached the input voltage. Otherwise the switch is
> turned off expecting an overload condition.
>
> So using the maximum output voltage slew rate and the timer
> minimum and maximum timeouts, a voltage constraints can be
> expressed as bounded limits for the timeout. That is what
> is used in the board schematics and should be in the DT too.
I don't understand this, but if you and Mark are happy with it...
...I'm also not 100% certain what the above description has to do with
this change, but I'll admit to having only skimmed some of the earlier
conversations.
> Signed-off-by: Javier Martinez Canillas
> ---
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 14 ++
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 14 ++
> 2 files changed, 28 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index d8710c1..eefafe6 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -386,27 +386,41 @@
> };
> tps65090_fet1: fet1 {
> regulator-name = "vcd_led";
> + regulator-min-microvolt =
> <500>;
> + regulator-max-microvolt =
> <170>;
This is almost certainly wrong. Your max is smaller than your min.
Perhaps you want an extra 0.
> };
> tps65090_fet2: fet2 {
> regulator-name = "video_mid";
> + regulator-min-microvolt =
> <450>;
> + regulator-max-microvolt =
> <550>;
> regulator-always-on;
> };
> tps65090_fet3: fet3 {
> regulator-name = "wwan_r";
> + regulator-min-microvolt =
> <300>;
> + regulator-max-microvolt =
> <550>;
> regulator-always-on;
> };
> tps65090_fet4: fet4 {
> regulator-name = "sdcard";
> + regulator-min-microvolt =
> <300>;
> + regulator-max-microvolt =
> <550>;
> regulator-always-on;
> };
> tps65090_fet5: fet5 {
> regulator-name = "camout";
> + regulator-min-microvolt =
> <300>;
> + regulator-max-microvolt =
> <550>;
> };
> tps65090_fet6: fet6 {
> regulator-name = "lcd_vdd";
> + regulator-min-microvolt =
> <300>;
> + regulator-max-microvolt =
> <550>;
> };
> tps65090_fet7: fet7 {
> regulator-name =
> "video_mid_1a";
> + regulator-min-microvolt =
> <300>;
> + regulator-max-microvolt =
> <550>;
> regulator-always-on;
> };
> tps65090_ldo1: ldo1 {
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 07b29b7..5c38bc0 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -384,27 +384,41 @@
> };
> tps65090_fet1: fet1 {
>
Re: [RESEND PATCH 1/2] ARM: dts: Improve Peach Pit and Pi power scheme
Javier, On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas wrote: > The DeviceTree files for the Peach Pit and Pi machines have > a simplistic model of the connections between the different > regulators since not all the tps65090 regulators get their > input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7 > parent supply is indded VDC but the fet1-6 get their input > supply from the DCDC1 and DCDC2 output voltage rails. > > Update the DeviceTree to better reflect the real connections > between tps65090 regulators. Having this information in the > DTS is useful since FETs are switches that don't provide an > output voltage so the regulator core needs to fetch the FET > parent output voltage if the child voltage is queried. > > Signed-off-by: Javier Martinez Canillas > Acked-by: Mark Brown > --- > arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++-- > arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 ++-- > 2 files changed, 12 insertions(+), 12 deletions(-) Matches my schematics. Kukjin: I think this could be applied to for-next whenever it's convenient. Acked-by: Doug Anderson -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Hi, On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote: > Hello Bartlomiej, > > On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote: > >> index fc7d168..c390bb9 100644 > >> --- a/arch/arm/configs/exynos_defconfig > >> +++ b/arch/arm/configs/exynos_defconfig > >> @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y > >> CONFIG_I2C_S3C2410=y > >> CONFIG_DEBUG_GPIO=y > >> CONFIG_POWER_SUPPLY=y > >> +CONFIG_BATTERY_SBS=m > > > > Why not make it "=y"? > > > > Rationale: > > - currently no hardware related option uses "=m" in exynos_defconfig > > - it would match the SBS option usage in multi_v7_defconfig > > > >> CONFIG_CHARGER_TPS65090=y > >> # CONFIG_HWMON is not set > >> CONFIG_THERMAL=y > > > > I know but personally I think this should be changed. The idea of having a > multi > platform kernel is to build a single kernel image that can be used to boot > different platforms. Not all platforms have a SBS-compliant battery so this > support shouldn't be built in the kernel image IMHO. > > This also matches to what real users will do since distributions most likely > will have a minimal kernel and every possible hardware support will be enabled > as a loadable kernel module. This is what distros do for other platforms too. > > If someone has a different use case and wants a kernel image that is optimized > for a particular platform then she has to create its own defconfig anyways. Distributions usually use their own configs anyway and the current most popular use case for exynos_defconfig (not multi_v7_defconfig) seems to be to build kernel image alone and use it without any modules: $ grep "=m" arch/arm/configs/exynos_defconfig CONFIG_DM_CRYPT=m $ grep "=m" .config CONFIG_NET_IP_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_IPV6=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_IPV6_SIT=m CONFIG_DM_CRYPT=m CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_ANSI_CPRNG=m What I'm trying to say is that there is a high probability that people will continue to use just the kernel image for exynos_defconfig and will therefore miss SBS battery support altogether (which is only 3.6 kB of code more in the kernel image so there is no much gain in making it modular currently). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Javier, On Mon, Aug 11, 2014 at 4:06 AM, Javier Martinez Canillas wrote: > Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have > a SBS-compliant gas gauge battery. Enable it as module > so the needed support is available for these boards. > > Suggested-by: Doug Anderson > Signed-off-by: Javier Martinez Canillas > Acked-by: Kukjin Kim > --- > arch/arm/configs/exynos_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index fc7d168..c390bb9 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y > CONFIG_I2C_S3C2410=y > CONFIG_DEBUG_GPIO=y > CONFIG_POWER_SUPPLY=y > +CONFIG_BATTERY_SBS=m > CONFIG_CHARGER_TPS65090=y > # CONFIG_HWMON is not set > CONFIG_THERMAL=y I'm good with this, so: Reviewed-by: Doug Anderson To address Bartlomiej: =m is what's in ChromeOS for exynos, though I notice that other platforms in the ChromeOS tree have =y. I'm not sure why there is a difference, but it's probably just carelessness. Normally in ChromeOS we use "=m" for drivers that can afford to wait until after the UI is up and running. That helps improve boot time since the user can use the device sooner (and it's OK if the battery driver takes a few extra seconds to load). The only things that really should be "=y" are drivers that are critical to load early or that are needed for the user to interact with the system. In this case you could argue that loading sbs earlier means that if the system is low on battery it will get back to "shutdown" sooner. I'm not sure getting the shutdown a few seconds earlier is really critical, though... -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv10 5/5] ARM: dts: rockchip: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
Am Donnerstag, 7. August 2014, 16:38:02 schrieb Jaehoon Chung:
> 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
> Reviewed-by: Tushar Behera
> Reviewed-by: Ulf Hansson
> Reviewed-by: Heiko Stuebner
> Acked-by: Seungwon Jeon
I've added this one to my queue for 3.18
Heiko
> ---
> 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 {
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Hello Bartlomiej, On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote: >> index fc7d168..c390bb9 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y >> CONFIG_I2C_S3C2410=y >> CONFIG_DEBUG_GPIO=y >> CONFIG_POWER_SUPPLY=y >> +CONFIG_BATTERY_SBS=m > > Why not make it "=y"? > > Rationale: > - currently no hardware related option uses "=m" in exynos_defconfig > - it would match the SBS option usage in multi_v7_defconfig > >> CONFIG_CHARGER_TPS65090=y >> # CONFIG_HWMON is not set >> CONFIG_THERMAL=y > I know but personally I think this should be changed. The idea of having a multi platform kernel is to build a single kernel image that can be used to boot different platforms. Not all platforms have a SBS-compliant battery so this support shouldn't be built in the kernel image IMHO. This also matches to what real users will do since distributions most likely will have a minimal kernel and every possible hardware support will be enabled as a loadable kernel module. This is what distros do for other platforms too. If someone has a different use case and wants a kernel image that is optimized for a particular platform then she has to create its own defconfig anyways. > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Hi, On Monday, August 11, 2014 01:06:38 PM Javier Martinez Canillas wrote: > Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have > a SBS-compliant gas gauge battery. Enable it as module > so the needed support is available for these boards. > > Suggested-by: Doug Anderson > Signed-off-by: Javier Martinez Canillas > Acked-by: Kukjin Kim > --- > arch/arm/configs/exynos_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index fc7d168..c390bb9 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y > CONFIG_I2C_S3C2410=y > CONFIG_DEBUG_GPIO=y > CONFIG_POWER_SUPPLY=y > +CONFIG_BATTERY_SBS=m Why not make it "=y"? Rationale: - currently no hardware related option uses "=m" in exynos_defconfig - it would match the SBS option usage in multi_v7_defconfig > CONFIG_CHARGER_TPS65090=y > # CONFIG_HWMON is not set > CONFIG_THERMAL=y Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- 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 0/2] Firmware-assisted suspend/resume of Exynos SoCs
For both patches, on the Odroid U2: Tested-by: Tomeu Vizoso Thanks, Tomeu On 17 July 2014 17:56, Tomasz Figa wrote: > On Exynos-based boards running secure firmware the sequence of low level > operations to enter and leave system-wide sleep mode is different than > on those without the firmware. Namely: > - CP15 power control and diagnostic registers cannot be written directly, > - the way of setting boot address and boot flag is different, > - different resume handler needs to be used, > - dedicated SMC call needs to be performed instead of letting the CPU enter >WFI. > > This series introduces .suspend() and .resume() firmware operations to > perform low level firmware-specific suspend and resume and then leverages > them to provide suspend-resume path meeting the above requirements. > > The series is based on Kgene's for-next branch and tested on: > - Exynos4412-based Trats2 board running in non-secure mode (under secure >firmware) with few board-specific fixes that will be sent separately soon, > - Exynos4210-based Trats board running in secure mode, > - Exynos4412-based ODROID-U3 board running in non-secure mode with one minor >board-specific fix which will be send shortly. > > Depends on: > - [PATCH v3] ARM: save/restore Cortex-A9 CP15 registers on suspend/resume >(http://www.spinics.net/lists/arm-kernel/msg346212.html) > - [PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences >(https://lkml.org/lkml/2014/7/15/319) > - [PATCH] ARM: make it easier to check the CPU part number correctly >(http://thread.gmane.org/gmane.linux.ports.arm.kernel/335126 > already in linux-next) > > Changes since v1: > - dropped outer_resume() - will be handled in assembly in further patches, >as support for L2C in non-secure mode gets added, > - moved CP15 resume to assembly as it needs to be done before MMU is enabled, > - surrounded CP15 save with a check for cpuid part, because it is valid only >on Cortex A9, > - rebased on next-20140717 tag of linux-next tree. > > Tomasz Figa (2): > ARM: firmware: Introduce suspend and resume operations > ARM: EXYNOS: Add support for firmware-assisted suspend/resume > > Documentation/arm/firmware.txt | 28 + > arch/arm/include/asm/firmware.h | 8 > arch/arm/mach-exynos/Makefile | 1 + > arch/arm/mach-exynos/common.h | 4 > arch/arm/mach-exynos/firmware.c | 45 > + > arch/arm/mach-exynos/pm.c | 16 ++- > arch/arm/mach-exynos/sleep.S| 28 + > arch/arm/mach-exynos/smc.h | 4 > 8 files changed, 106 insertions(+), 28 deletions(-) > > -- > 1.9.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 1/2] ARM: dts: Improve Peach Pit and Pi power scheme
The DeviceTree files for the Peach Pit and Pi machines have a simplistic model of the connections between the different regulators since not all the tps65090 regulators get their input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7 parent supply is indded VDC but the fet1-6 get their input supply from the DCDC1 and DCDC2 output voltage rails. Update the DeviceTree to better reflect the real connections between tps65090 regulators. Having this information in the DTS is useful since FETs are switches that don't provide an output voltage so the regulator core needs to fetch the FET parent output voltage if the child voltage is queried. Signed-off-by: Javier Martinez Canillas Acked-by: Mark Brown --- arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 ++-- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts index 228a6b1..d8710c1 100644 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts @@ -365,12 +365,12 @@ vsys2-supply = <&vbat>; vsys3-supply = <&vbat>; infet1-supply = <&vbat>; - infet2-supply = <&vbat>; - infet3-supply = <&vbat>; - infet4-supply = <&vbat>; - infet5-supply = <&vbat>; - infet6-supply = <&vbat>; - infet7-supply = <&vbat>; + infet2-supply = <&tps65090_dcdc1>; + infet3-supply = <&tps65090_dcdc2>; + infet4-supply = <&tps65090_dcdc2>; + infet5-supply = <&tps65090_dcdc2>; + infet6-supply = <&tps65090_dcdc2>; + infet7-supply = <&tps65090_dcdc1>; vsys-l1-supply = <&vbat>; vsys-l2-supply = <&vbat>; diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts index f3ee48b..07b29b7 100644 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -363,12 +363,12 @@ vsys2-supply = <&vbat>; vsys3-supply = <&vbat>; infet1-supply = <&vbat>; - infet2-supply = <&vbat>; - infet3-supply = <&vbat>; - infet4-supply = <&vbat>; - infet5-supply = <&vbat>; - infet6-supply = <&vbat>; - infet7-supply = <&vbat>; + infet2-supply = <&tps65090_dcdc1>; + infet3-supply = <&tps65090_dcdc2>; + infet4-supply = <&tps65090_dcdc2>; + infet5-supply = <&tps65090_dcdc2>; + infet6-supply = <&tps65090_dcdc2>; + infet7-supply = <&tps65090_dcdc1>; vsys-l1-supply = <&vbat>; vsys-l2-supply = <&vbat>; -- 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
[RESEND PATCH 2/2] ARM: dts: Add tps65090 FET constraints on Peach Pit and Pi
Both Exynos5420 Peach Pit and Exynos5800 Peach Pi boards
have a tps65090 PMU that has a number of switches (FETs)
that are just on/off devices but they do have a current
limit and the output voltage of the switch is ramped up
within a controlled slope.
After the switch is turned on, a safety timer is started
and before this timer times out the output voltage must
have reached the input voltage. Otherwise the switch is
turned off expecting an overload condition.
So using the maximum output voltage slew rate and the timer
minimum and maximum timeouts, a voltage constraints can be
expressed as bounded limits for the timeout. That is what
is used in the board schematics and should be in the DT too.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 14 ++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 14 ++
2 files changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index d8710c1..eefafe6 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -386,27 +386,41 @@
};
tps65090_fet1: fet1 {
regulator-name = "vcd_led";
+ regulator-min-microvolt =
<500>;
+ regulator-max-microvolt =
<170>;
};
tps65090_fet2: fet2 {
regulator-name = "video_mid";
+ regulator-min-microvolt =
<450>;
+ regulator-max-microvolt =
<550>;
regulator-always-on;
};
tps65090_fet3: fet3 {
regulator-name = "wwan_r";
+ regulator-min-microvolt =
<300>;
+ regulator-max-microvolt =
<550>;
regulator-always-on;
};
tps65090_fet4: fet4 {
regulator-name = "sdcard";
+ regulator-min-microvolt =
<300>;
+ regulator-max-microvolt =
<550>;
regulator-always-on;
};
tps65090_fet5: fet5 {
regulator-name = "camout";
+ regulator-min-microvolt =
<300>;
+ regulator-max-microvolt =
<550>;
};
tps65090_fet6: fet6 {
regulator-name = "lcd_vdd";
+ regulator-min-microvolt =
<300>;
+ regulator-max-microvolt =
<550>;
};
tps65090_fet7: fet7 {
regulator-name = "video_mid_1a";
+ regulator-min-microvolt =
<300>;
+ regulator-max-microvolt =
<550>;
regulator-always-on;
};
tps65090_ldo1: ldo1 {
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 07b29b7..5c38bc0 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -384,27 +384,41 @@
};
tps65090_fet1: fet1 {
regulator-name = "vcd_led";
+ regulator-min-microvolt =
<500>;
+ regulator-max-microvolt =
<170>;
};
tps65090_fet2: fet2 {
regulator-name = "video_mid";
+ regulator-min-microvolt =
<450>;
+ regulator-max-microvolt =
<550>;
[RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have a SBS-compliant gas gauge battery. Enable it as module so the needed support is available for these boards. Suggested-by: Doug Anderson Signed-off-by: Javier Martinez Canillas Acked-by: Kukjin Kim --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index fc7d168..c390bb9 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y CONFIG_I2C_S3C2410=y CONFIG_DEBUG_GPIO=y CONFIG_POWER_SUPPLY=y +CONFIG_BATTERY_SBS=m CONFIG_CHARGER_TPS65090=y # CONFIG_HWMON is not set CONFIG_THERMAL=y -- 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 v5 05/10] ARM: dts: Move dp_hpd from exynos5250 into smdk5250 and snow
On Sunday, August 10, 2014 6:15 PM, Andreas Farber wrote:
> Am 05.08.2014 13:16, schrieb Jingoo Han:
> > On Saturday, August 02, 2014 5:57 AM, Tomasz Figa wrote:
> >> On 01.08.2014 22:54, Andreas Färber wrote:
> >>> Am 01.08.2014 22:33, schrieb Doug Anderson:
> On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber wrote:
> > Spring uses a different GPIO, so this is not a generic SoC piece.
> >
> > Suggested-by: Tomasz Figa
> > Signed-off-by: Andreas Färber
> > ---
> > v5: New (Tomasz Figa)
> > Frees dp_hpd for Spring.
> >
> > arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 7 ---
> > arch/arm/boot/dts/exynos5250-smdk5250.dts | 9 +
> > arch/arm/boot/dts/exynos5250-snow.dts | 7 +++
> > 3 files changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> > b/arch/arm/boot/dts/exynos5250-
> pinctrl.dtsi
> > index 886cfca044ac..ed0e5230514b 100644
> > --- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> > +++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> > @@ -581,13 +581,6 @@
> > samsung,pin-pud = <0>;
> > samsung,pin-drv = <0>;
> > };
> > -
> > - dp_hpd: dp_hpd {
> > - samsung,pins = "gpx0-7";
> > - samsung,pin-function = <3>;
> > - samsung,pin-pud = <0>;
> > - samsung,pin-drv = <0>;
> > - };
> > };
> >
> > pinctrl@1340 {
> > diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> > b/arch/arm/boot/dts/exynos5250-
> smdk5250.dts
> > index aaa055ac0fe3..5d30fe1dcda4 100644
> > --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> > +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> > @@ -414,3 +414,12 @@
> > };
> > };
> > };
> > +
> > +&pinctrl_0 {
> > + dp_hpd: dp_hpd {
> > + samsung,pins = "gpx0-7";
> > + samsung,pin-function = <3>;
> > + samsung,pin-pud = <0>;
> > + samsung,pin-drv = <0>;
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> > b/arch/arm/boot/dts/exynos5250-snow.dts
> > index c4b0c73c736d..a9a2f2743794 100644
> > --- a/arch/arm/boot/dts/exynos5250-snow.dts
> > +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> > @@ -547,6 +547,13 @@
> > };
> >
> > &pinctrl_0 {
> > + dp_hpd: dp_hpd {
> > + samsung,pins = "gpx0-7";
> > + samsung,pin-function = <3>;
> > + samsung,pin-pud = <0>;
> > + samsung,pin-drv = <0>;
> > + };
> > +
>
> NAK. dp_hpd is a generic SoC piece. Pin function 0 and 1 are GPIOs.
> Pin function 3 is special function. This pin _is_ the hot plug detect
> pin for display port. When it's set as special function 3 it goes
> straight into the hot plug logic of the display port controller.
>
> Spring may have had its reasons to detect hot plug events on a GPIO
> instead of using this pin, but that doesn't make this pin any less the
> "hot plug pin".
> >>>
> >>> Please advise how to handle it then: Should there be two different
> >>> pinctrl entries (if so, how should it be named?),
> >>
> >> IMHO this is the right way. Just name the GPIO variant dp_hpd_gpio.
> >
> > Hi Andreas Färber,
> >
> > I agree with Tomasz Figa and Doug Anderson.
> > Please refer to the following.
> >
> > 1. case: Standard HPD pin is used. (smdk5420)
> > arch/arm/boot/dts/exynos5420-pinctrl.dts
> > pinctrl@1340 {
> > dp_hpd: dp_hpd {
> > samsung,pins = "gpx0-7";
> > samsung,pin-function = <3>;
> > samsung,pin-pud = <0>;
> > samsung,pin-drv = <0>;
> > };
> > arch/arm/boot/dts/exynos5420-smdk5420.dts
> > dp-controller@145B {
> > pinctrl-names = "default";
> > pinctrl-0 = <&dp_hpd>;
> > ...
> >
> > 2. case: non-standard HPD pin such as GPIO is used. (peach pit)
> > arch/arm/boot/dts/exynos5420-peach-pit.dts
> > pinctrl@1340 {
> > dp_hpd_gpio: dp_hpd_gpio {
> > samsung,pins = "gpx2-6";
> > samsung,pin-function = <0>;
> > samsung,pin-pud = <3>;
> > samsung,pin-drv = <0>;
> > };
> > dp-controller@145B {
> > pinctrl-names = "default";
> > pinctrl-0 = <&dp_hpd_gpio>;
> > ...
> > samsung,hpd-gpio = <&gpx2 6 0>;
> >
> > So, you need to follow the second case.
> > "dp_hpd_gpio" can be used for Spring board.
>
> I believe I already did so in v6 [0]? Please take a look
Re: [PATCHv10 1/5] mmc: dw_mmc: Slot quirk "disable-wp" is deprecated.
On 7 August 2014 09:37, Jaehoon Chung wrote:
> 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
> Tested-by: Sachin Kamat
> Acked-by: Seungwon Jeon
> Reviewed-by: Doug Anderson
> Tested-by: Doug Anderson
Thanks! Applied for next!
Kind regards
Uffe
> ---
> 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
Re: [PATCHv10 2/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed
On 7 August 2014 09:37, Jaehoon Chung wrote:
> 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
> Reviewed-by: Tushar Behera
> Reviewed-by: Ulf Hansson
> Tested-by: Sachin Kamat
> Acked-by: Seungwon Jeon
> Reviewed-by: Doug Anderson
Thanks! Applied for next!
Kind regards
Uffe
> ---
> .../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 = <2
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Mon, Aug 11, 2014 at 05:15:35PM +0900, Inki Dae wrote: > On 2014년 08월 11일 16:50, Thierry Reding wrote: > > On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: > >> On 2014년 08월 11일 16:24, Thierry Reding wrote: > >>> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: > On 2014년 08월 08일 18:55, Thierry Reding wrote: > > [...] > > The above is actually more like this: > > > > if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) > > clear DSI_HS_CLK_CTRL; > > else > > set DSI_HS_CLK_CTRL; > > > > if (msg->flags & MIPI_DSI_MSG_USE_LPM) > > clear DSI_HIGH_SPEED_TRANS; > > else > > set DSI_HIGH_SPEED_TRANS; > > > > So for peripherals that don't support non-continuous clock mode, this > > will result in the following for low-power transmissions: > > > > clear DSI_HS_CLK_CTRL; /* HS clock always on */ > > clear DSI_HIGH_SPEED_TRANS; > > Right, then how host driver should check it if peripheral doesn't > support non-continuous clock mode? Or how the peripheral should notify > it to host driver? It would need a new flag instead of > MIPI_DSI_MODE_NON_CONTINUOUS. > >>> > >>> MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to > >>> set to signal that they support non-continuous mode. If devices don't > >>> have that set, then the controller should always provide the HS clock. > >>> > >>> So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral > >>> does *not* support non-continuous mode. > >>> > >> > >> Again, assume that there is a peripheral that doesn't support > >> non-continuous clock mode but host driver want to transmit data in low > >> power. For this, you already mentioned like below, > >> > >> "So for peripherals that don't support non-continuous clock mode, this > >> will result in the following for low-power transmissions: > >> > >>clear DSI_HS_CLK_CTRL; /* HS clock always on */ > >>clear DSI_HIGH_SPEED_TRANS; > >> " > >> > >> In this case, how should host driver check it to clear above two flags? > >> As you know, this is required to clear two flags same as non-continuous > >> clock mode. Don't you think that we need a new flag to identify them - > >> non-continuous clock mode or just for low-power transmission? > > > > See what I wrote a little further up: > > > > if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) > > clear DSI_HS_CLK_CTRL; > > else > > set DSI_HS_CLK_CTRL; > > > > if (msg->flags & MIPI_DSI_MSG_USE_LPM) > > clear DSI_HIGH_SPEED_TRANS; > > else > > set DSI_HIGH_SPEED_TRANS; > > > > > > MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- > > continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because > > that tells the controller to turn off the HS clock between high-speed > > transmissions. > > > > MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power > > mode. > > > > With the above two flags we can cover four cases: > > > > 1) non-continuous mode with messages transmitted in low-power mode > > 2) non-continuous mode with messages transmitted in high-speed mode > > 3) continuous mode with messages transmitted in low-power mode > > In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear > DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but > dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right. > You mean that continuous mode is set by default implicitly? Yes, if the MIPI_DSI_MODE_NON_CONTINUOUS flag is not specified, then it means the peripheral supports only continuous mode. Thierry pgpDS3SM5RpCn.pgp Description: PGP signature
Re: [PATCH v2 1/1] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
Hello Linus, On 08/11/2014 10:32 AM, Linus Walleij wrote: > I guess this discussion is about drivers/pinctrl/samsung/pinctrl-exynos.c? > > Or else I'm not really following this... $SUBJECT is a bit confusing. > Yes, the thing is that at the beginning I (wrongly) thought that the IRQ trigger type flags defined in the DTS were discarded if someone called request_threaded_irq() with a flags != 0. And since the atmel touchpad driver was pass pdata->irqflags | IRQF_ONESHOT I posted this patch to get the trigger type parsed from DT and pass it to request_threaded_irq(). But after digging further I found that the issue was in the pinctrl-exynos driver and Tomasz explained to me that the real cause was that the pin was being configured from GPIO IRQ to GPIO input (which on other platforms is just the same mode but on Exynos are two different modes). At the end passing the trigger type to request_threaded_irq() just had the side effect to call the exynos .irq_set_type function handler that reconfigured the pin as GPIO-IRQ and that is why it made it to work. So I posted a patch from Tomasz that fixes the real cause [0]. I'm so sorry for the confusion. > Yours, > Linus Walleij > Best regards, Javier [0]: https://lkml.org/lkml/2014/8/8/962 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs
On Sat, Aug 9, 2014 at 1:48 AM, Javier Martinez Canillas
wrote:
> From: Tomasz Figa
>
> Currently after configuring a GPIO pin as an interrupt related pinmux
> registers are changed, but there is no protection from calling
> gpio_direction_*() in a badly written driver, which would cause the same
> pinmux register to be reconfigured for regular input/output and this
> disabling interrupt capability of the pin.
>
> This patch addresses this issue by moving pinmux reconfiguration to
> .irq_{request,release}_resources() callback of irq_chip and calling
> gpio_lock_as_irq() helper to prevent reconfiguration of pin direction.
>
> Setting up a GPIO interrupt on Samsung SoCs is a two-step operation -
> in addition to trigger configuration in a dedicated register, the pinmux
> must be also reconfigured to GPIO interrupt, which is a different function
> than normal GPIO input, although I/O-wise they both behave in the same way
> and gpio_get_value() can be used on a pin configured as IRQ as well.
>
> Such design implies subtleties such as gpio_direction_input() not having
> to fail if a pin is already configured as an interrupt nor change the
> configuration to normal input. But the FLAG_USED_AS_IRQ set in gpiolib by
> gpio_lock_as_irq() is only used to check that gpio_direction_output() is
> not called, it's not used to prevent gpio_direction_input() to be called.
> So this is not a complete solution for Samsung SoCs but it's definitely a
> move in the right direction.
>
> Signed-off-by: Tomasz Figa
> [javier: use request resources instead of startup and expand commit message]
> Signed-off-by: Javier Martinez Canillas
> ---
>
> This patch solves the issue explained in https://lkml.org/lkml/2014/8/8/461
Hm, this looks much better atleast, it is not possible to use the
irqchip helpers from gpiolib then, because that grabs the request/release
resource callbacks.
If I get some ACKs on this we can go for this solution.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
I guess this discussion is about drivers/pinctrl/samsung/pinctrl-exynos.c? Or else I'm not really following this... $SUBJECT is a bit confusing. On Sat, Aug 9, 2014 at 12:26 AM, Javier Martinez Canillas wrote: > Regardless of this though I think that both the patch to move the IRQ > pinmux setup from .irq_set_type to the .irq_request_resources and the patch to > to prevent any pinmux reconfiguration are good improvements to avoid future > issues like the one we found here. I think someone should look into switching the Samsung/Exynos pinctrl driver to the gpiolib irqchip helpers, I looked at it but was scared by the special wkup chip and stuff I can't test. The irqchip helpers will atleast help out in flagging GPIO lines as used for IRQs so the core can keep track of stuff and show that properly in debugfs. The orthogonality compliance between GPIO and irqchip must however be solved in the driver itself, the core only helps out in blocking some abuse of the API. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 11일 16:50, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: >> On 2014년 08월 11일 16:24, Thierry Reding wrote: >>> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: On 2014년 08월 08일 18:55, Thierry Reding wrote: > [...] > The above is actually more like this: > > if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) > clear DSI_HS_CLK_CTRL; > else > set DSI_HS_CLK_CTRL; > > if (msg->flags & MIPI_DSI_MSG_USE_LPM) > clear DSI_HIGH_SPEED_TRANS; > else > set DSI_HIGH_SPEED_TRANS; > > So for peripherals that don't support non-continuous clock mode, this > will result in the following for low-power transmissions: > > clear DSI_HS_CLK_CTRL; /* HS clock always on */ > clear DSI_HIGH_SPEED_TRANS; Right, then how host driver should check it if peripheral doesn't support non-continuous clock mode? Or how the peripheral should notify it to host driver? It would need a new flag instead of MIPI_DSI_MODE_NON_CONTINUOUS. >>> >>> MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to >>> set to signal that they support non-continuous mode. If devices don't >>> have that set, then the controller should always provide the HS clock. >>> >>> So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral >>> does *not* support non-continuous mode. >>> >> >> Again, assume that there is a peripheral that doesn't support >> non-continuous clock mode but host driver want to transmit data in low >> power. For this, you already mentioned like below, >> >> "So for peripherals that don't support non-continuous clock mode, this >> will result in the following for low-power transmissions: >> >> clear DSI_HS_CLK_CTRL; /* HS clock always on */ >> clear DSI_HIGH_SPEED_TRANS; >> " >> >> In this case, how should host driver check it to clear above two flags? >> As you know, this is required to clear two flags same as non-continuous >> clock mode. Don't you think that we need a new flag to identify them - >> non-continuous clock mode or just for low-power transmission? > > See what I wrote a little further up: > > if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) > clear DSI_HS_CLK_CTRL; > else > set DSI_HS_CLK_CTRL; > > if (msg->flags & MIPI_DSI_MSG_USE_LPM) > clear DSI_HIGH_SPEED_TRANS; > else > set DSI_HIGH_SPEED_TRANS; > > > MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- > continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because > that tells the controller to turn off the HS clock between high-speed > transmissions. > > MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power > mode. > > With the above two flags we can cover four cases: > > 1) non-continuous mode with messages transmitted in low-power mode > 2) non-continuous mode with messages transmitted in high-speed mode > 3) continuous mode with messages transmitted in low-power mode In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right. You mean that continuous mode is set by default implicitly? Thanks, Inki Dae > 4) continuous mode with messages transmitted in high-speed mode > > What other cases do you think we need to support? > > 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 08/11/2014 09:44 AM, Andrzej Hajda wrote: > On 08/11/2014 09:09 AM, Inki Dae wrote: >> On 2014년 08월 08일 18:40, Andrzej Hajda wrote: >>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote: On 08/08/2014 09:37 AM, Inki Dae wrote: > On 2014년 08월 08일 16:03, Thierry Reding wrote: >> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >>> 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 > : >> [...] >> 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 wil
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 11일 16:44, Andrzej Hajda wrote: > On 08/11/2014 09:09 AM, Inki Dae wrote: >> On 2014년 08월 08일 18:40, Andrzej Hajda wrote: >>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote: On 08/08/2014 09:37 AM, Inki Dae wrote: > On 2014년 08월 08일 16:03, Thierry Reding wrote: >> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >>> 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 > : >> [...] >> 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 wil
Re: [PATCH] mmc: dw_mmc: change to use recommended reset procedure
On 5 August 2014 03:19, 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
> Signed-off-by: Yuvaraj Kumar C D
> Acked-by: Seungwon Jeon
> Signed-off-by: Ulf Hansson
> [sonnyrao: fix compile for !CONFIG_MMC_DW_IDMAC case]
Thanks! Applied for next!
Kind regards
Uffe
> ---
> 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 */
> + if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET))
> +
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: > On 2014년 08월 11일 16:24, Thierry Reding wrote: > > On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: > >> On 2014년 08월 08일 18:55, Thierry Reding wrote: [...] > >>> The above is actually more like this: > >>> > >>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) > >>> clear DSI_HS_CLK_CTRL; > >>> else > >>> set DSI_HS_CLK_CTRL; > >>> > >>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) > >>> clear DSI_HIGH_SPEED_TRANS; > >>> else > >>> set DSI_HIGH_SPEED_TRANS; > >>> > >>> So for peripherals that don't support non-continuous clock mode, this > >>> will result in the following for low-power transmissions: > >>> > >>> clear DSI_HS_CLK_CTRL; /* HS clock always on */ > >>> clear DSI_HIGH_SPEED_TRANS; > >> > >> Right, then how host driver should check it if peripheral doesn't > >> support non-continuous clock mode? Or how the peripheral should notify > >> it to host driver? It would need a new flag instead of > >> MIPI_DSI_MODE_NON_CONTINUOUS. > > > > MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to > > set to signal that they support non-continuous mode. If devices don't > > have that set, then the controller should always provide the HS clock. > > > > So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral > > does *not* support non-continuous mode. > > > > Again, assume that there is a peripheral that doesn't support > non-continuous clock mode but host driver want to transmit data in low > power. For this, you already mentioned like below, > > "So for peripherals that don't support non-continuous clock mode, this > will result in the following for low-power transmissions: > > clear DSI_HS_CLK_CTRL; /* HS clock always on */ > clear DSI_HIGH_SPEED_TRANS; > " > > In this case, how should host driver check it to clear above two flags? > As you know, this is required to clear two flags same as non-continuous > clock mode. Don't you think that we need a new flag to identify them - > non-continuous clock mode or just for low-power transmission? See what I wrote a little further up: > >>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) > >>> clear DSI_HS_CLK_CTRL; > >>> else > >>> set DSI_HS_CLK_CTRL; > >>> > >>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) > >>> clear DSI_HIGH_SPEED_TRANS; > >>> else > >>> set DSI_HIGH_SPEED_TRANS; > >>> MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because that tells the controller to turn off the HS clock between high-speed transmissions. MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power mode. With the above two flags we can cover four cases: 1) non-continuous mode with messages transmitted in low-power mode 2) non-continuous mode with messages transmitted in high-speed mode 3) continuous mode with messages transmitted in low-power mode 4) continuous mode with messages transmitted in high-speed mode What other cases do you think we need to support? Thierry pgp7G1pImdMYn.pgp Description: PGP signature
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 08/11/2014 09:09 AM, Inki Dae wrote: > On 2014년 08월 08일 18:40, Andrzej Hajda wrote: >> On 08/08/2014 11:02 AM, Andrzej Hajda wrote: >>> On 08/08/2014 09:37 AM, Inki Dae wrote: On 2014년 08월 08일 16:03, Thierry Reding wrote: > On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >> 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 : > [...] > 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-continuo
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 11일 16:24, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: >> On 2014년 08월 08일 18:55, Thierry Reding wrote: >>> On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote: On 2014년 08월 08일 16:03, Thierry Reding wrote: > On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >> 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 : > [...] > 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. > >> An
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: > On 2014년 08월 08일 18:55, Thierry Reding wrote: > > On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote: > >> On 2014년 08월 08일 16:03, Thierry Reding wrote: > >>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: > 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 > >> : > >>> [...] > >>> 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 differ
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 08일 18:40, Andrzej Hajda wrote: > On 08/08/2014 11:02 AM, Andrzej Hajda wrote: >> On 08/08/2014 09:37 AM, Inki Dae wrote: >>> On 2014년 08월 08일 16:03, Thierry Reding wrote: On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: > 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 >>> : [...] 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
