Re: [PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY

2015-09-03 Thread Heiko Stuebner 
Am Donnerstag, 3. September 2015, 11:25:00 schrieb Yakir Yang:
> 在 09/02/2015 09:27 PM, Rob Herring 写道:
> > On Tue, Sep 1, 2015 at 1:04 AM, Yakir Yang  wrote:
> >> +- clocks: from common clock binding: handle to dp clock.
> >> +   of memory mapped region.
> >> +- clock-names: from common clock binding:
> >> +   Required elements: "sclk_dp" "sclk_dp_24m"
> >> +
> >> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> > 
> > I have no idea what GRF means.
> 
> GRF is an module of our IC chip, the full name is General Register Files.
> I would rather to pick some words from our TRM.
> 
> The general register file will be used to do static set by software, which
> is composed of many registers for system control.

The general register files are present on all Rockchip SoCs I've seen so far 
and really are just an aggregation of registers for settings and status 
indications, ranging from memory stuff, dma-controller settings, usb-phy and 
settings for a lot of other phys, etc.

The most prevalent description in dt-bindings is currently:

- rockchip,grf: phandle to the syscon managing the "general register files"


Heiko
--
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

[PATCHv7] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4

2015-09-03 Thread Anand Moon 
Earlier design of the LED for Odroid XU3 was using gpio-leds
Now It was change to using both pwm-leds and gpio-leds.

Signed-off-by: Anand Moon 
Reviewed-by: Javier Martinez Canillas 

---
Changes from last version
dropped following option.
  CONFIG_LEDS_CLASS_FLASH
  CONFIG_TRIGGER_ONESHOT
  CONFIG_LEDS_TRIGGER_TIMER
  CONFIG_TRIGGER_GPIO
fixed the From address
fixed the commit message.
---
 arch/arm/configs/exynos_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 9504e77..bd6b7f7 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -163,6 +163,12 @@ CONFIG_MMC_SDHCI_S3C_DMA=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_EXYNOS=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_PWM=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_MAX77686=y
 CONFIG_RTC_DRV_MAX77802=y
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/3] cpufreq-dt: add suspend frequency support

2015-09-03 Thread Bartlomiej Zolnierkiewicz 
Hi,

This patch series adds suspend frequency support (using opp-v2
bindings and suspend-opp functionality) to cpufreq-dt driver and
then adds suspend opp for Exynos4412 based boards.

This patch series fixes suspend/resume support on Exynos4412
based Trats2 board and reboot hang on Exynos4412 based Odroid
U3 board.

Changes since v2:
- rewrited to use suspend-opp functionality

Changes since v1:
- removed superfluous ";"

Depends on:
- next-20150902 branch of linux-next kernel tree

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


Bartlomiej Zolnierkiewicz (3):
  PM / OPP: add dev_pm_opp_get_suspend_opp() helper
  cpufreq-dt: add suspend frequency support
  ARM: dts: add suspend opp to exynos4412

 arch/arm/boot/dts/exynos4412.dtsi |  1 +
 drivers/base/power/opp.c  | 28 
 drivers/cpufreq/cpufreq-dt.c  | 32 
 include/linux/pm_opp.h|  6 ++
 4 files changed, 67 insertions(+)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/3] ARM: dts: add suspend opp to exynos4412

2015-09-03 Thread Bartlomiej Zolnierkiewicz 
Mark 800MHz OPP as a suspend opp for Exynos4412 based
boards so effectively cpufreq-dt driver behavior w.r.t.
suspend frequency matches what the old exynos-cpufreq
driver has been doing.

This patch fixes suspend/resume support on Exynos4412 based
Trats2 board and reboot hang on Exynos4412 based Odroid U3
board.

Cc: Viresh Kumar 
Cc: Thomas Abraham 
Cc: Javier Martinez Canillas 
Cc: Krzysztof Kozlowski 
Cc: Marek Szyprowski 
Cc: Tobias Jakobi 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 arch/arm/boot/dts/exynos4412.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index ca0e3c1..294cfe4 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -98,6 +98,7 @@
opp-hz = /bits/ 64 <8>;
opp-microvolt = <100>;
clock-latency-ns = <20>;
+   opp-suspend;
};
opp07 {
opp-hz = /bits/ 64 <9>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/3] PM / OPP: add dev_pm_opp_get_suspend_opp() helper

2015-09-03 Thread Bartlomiej Zolnierkiewicz 
Add dev_pm_opp_get_suspend_opp() helper to obtain suspend opp.

Cc: Viresh Kumar 
Cc: Thomas Abraham 
Cc: Javier Martinez Canillas 
Cc: Krzysztof Kozlowski 
Cc: Marek Szyprowski 
Cc: Tobias Jakobi 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/base/power/opp.c | 28 
 include/linux/pm_opp.h   |  6 ++
 2 files changed, 34 insertions(+)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index eb25449..eaafca7 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -341,6 +341,34 @@ unsigned long dev_pm_opp_get_max_clock_latency(struct 
device *dev)
 EXPORT_SYMBOL_GPL(dev_pm_opp_get_max_clock_latency);
 
 /**
+ * dev_pm_opp_get_suspend_opp() - Get suspend opp
+ * @dev:   device for which we do this operation
+ *
+ * Return: This function returns pointer to the suspend opp if it is
+ * defined, otherwise it returns NULL.
+ *
+ * Locking: This function takes rcu_read_lock().
+ */
+struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device *dev)
+{
+   struct device_opp *dev_opp;
+   struct dev_pm_opp *suspend_opp;
+
+   rcu_read_lock();
+
+   dev_opp = _find_device_opp(dev);
+   if (IS_ERR(dev_opp))
+   suspend_opp = NULL;
+   else
+   suspend_opp = dev_opp->suspend_opp;
+
+   rcu_read_unlock();
+
+   return suspend_opp;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_suspend_opp);
+
+/**
  * dev_pm_opp_get_opp_count() - Get number of opps available in the opp list
  * @dev:   device for which we do this operation
  *
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index cab7ba5..e817722 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -34,6 +34,7 @@ bool dev_pm_opp_is_turbo(struct dev_pm_opp *opp);
 
 int dev_pm_opp_get_opp_count(struct device *dev);
 unsigned long dev_pm_opp_get_max_clock_latency(struct device *dev);
+struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device *dev);
 
 struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device *dev,
  unsigned long freq,
@@ -80,6 +81,11 @@ static inline unsigned long 
dev_pm_opp_get_max_clock_latency(struct device *dev)
return 0;
 }
 
+static inline struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device *dev)
+{
+   return NULL;
+}
+
 static inline struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device *dev,
unsigned long freq, bool available)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/3] cpufreq-dt: add suspend frequency support

2015-09-03 Thread Bartlomiej Zolnierkiewicz 
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).  Also implement
custom suspend method (needed to not error out on platforms
which don't require suspend frequency).

Cc: Viresh Kumar 
Cc: Thomas Abraham 
Cc: Javier Martinez Canillas 
Cc: Krzysztof Kozlowski 
Cc: Marek Szyprowski 
Cc: Tobias Jakobi 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/cpufreq/cpufreq-dt.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index c3583cd..ba4ca85 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -196,6 +196,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
struct device *cpu_dev;
struct regulator *cpu_reg;
struct clk *cpu_clk;
+   struct dev_pm_opp *suspend_opp;
unsigned long min_uV = ~0, max_uV = 0;
unsigned int transition_latency;
bool need_update = false;
@@ -329,6 +330,11 @@ static int cpufreq_init(struct cpufreq_policy *policy)
policy->driver_data = priv;
 
policy->clk = cpu_clk;
+
+   suspend_opp = dev_pm_opp_get_suspend_opp(cpu_dev);
+   if (suspend_opp)
+   policy->suspend_freq = dev_pm_opp_get_freq(suspend_opp) / 1000;
+
ret = cpufreq_table_validate_and_show(policy, freq_table);
if (ret) {
dev_err(cpu_dev, "%s: invalid frequency table: %d\n", __func__,
@@ -409,6 +415,31 @@ static void cpufreq_ready(struct cpufreq_policy *policy)
of_node_put(np);
 }
 
+#ifdef CONFIG_PM
+static int cpufreq_dt_suspend(struct cpufreq_policy *policy)
+{
+   int ret;
+
+   if (!policy->suspend_freq) {
+   pr_debug("%s: suspend_freq not defined\n", __func__);
+   return 0;
+   }
+
+   pr_debug("%s: Setting suspend-freq: %u\n", __func__,
+   policy->suspend_freq);
+
+   ret = __cpufreq_driver_target(policy, policy->suspend_freq,
+   CPUFREQ_RELATION_H);
+   if (ret)
+   pr_err("%s: unable to set suspend-freq: %u. err: %d\n",
+   __func__, policy->suspend_freq, ret);
+
+   return ret;
+}
+#else
+#define cpufreq_dt_suspend NULL
+#endif
+
 static struct cpufreq_driver dt_cpufreq_driver = {
.flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK,
.verify = cpufreq_generic_frequency_table_verify,
@@ -419,6 +450,7 @@ static struct cpufreq_driver dt_cpufreq_driver = {
.ready = cpufreq_ready,
.name = "cpufreq-dt",
.attr = cpufreq_dt_attr,
+   .suspend = cpufreq_dt_suspend,
 };
 
 static int dt_cpufreq_probe(struct platform_device *pdev)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] drivers: i2c: exynos5: irq spinlock rt-safe

2015-09-03 Thread Anders Roxell 
The current spin_lock_irqsave() protects the enabling of the device
interrupt.  In order to prevent recursion in the case of sleeping
spinlocks (e.g. with RT patch, stacktrace below), convert the spin lock
to a raw spin lock. No change for !RT kernels.

[   10.992238] kernel BUG at ../kernel/locking/rtmutex.c:998!
[   10.992243] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[   10.992250] Modules linked in:
[   10.992258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.1.5-rt5
[   10.992263] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   10.992268] task: ed88 ti: ed888000 task.ti: ed888000
[   10.992281] PC is at rt_spin_lock_slowlock+0xa4/0x2ec
[   10.992288] LR is at rt_spin_lock_slowlock+0x54/0x2ec
[   10.992296] pc : []lr : []psr: 6193
[   10.992296] sp : ed889a28  ip : ed880001  fp : 0089
[   10.992300] r10: ed889a28  r9 : c0f55654  r8 : 0060
[   10.992305] r7 : ed88  r6 :   r5 : 0001  r4 : ed9f7288
[   10.992310] r3 : ed88  r2 :   r1 : ed88  r0 : 
[   10.992316] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
...
...
[   10.992662] [] (rt_spin_lock_slowlock) from []
(exynos5_i2c_irq+0x20/0x2b0)
[   10.992678] [] (exynos5_i2c_irq) from []
(handle_irq_event_percpu+0x68/0x158)
[   10.992690] [] (handle_irq_event_percpu) from []
(handle_irq_event+0x68/0xa8)
[   10.992702] [] (handle_irq_event) from []
(handle_fasteoi_irq+0x11c/0x1d4)
[   10.992713] [] (handle_fasteoi_irq) from []
(generic_handle_irq+0x20/0x30)
[   10.992724] [] (generic_handle_irq) from []
(__handle_domain_irq+0x6c/0xe4)
[   10.992734] [] (__handle_domain_irq) from []
(gic_handle_irq+0x2c/0x68)
[   10.992744] [] (gic_handle_irq) from []
(__irq_svc+0x40/0x88)
[   10.992749] Exception stack(0xed889b28 to 0xed889b70)
...
...

Signed-off-by: Anders Roxell 
---
 drivers/i2c/busses/i2c-exynos5.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index b29c750..b12e77e 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -170,7 +170,7 @@ struct exynos5_i2c {
struct device   *dev;
int state;
 
-   spinlock_t  lock;   /* IRQ synchronization */
+   raw_spinlock_t  lock;   /* IRQ synchronization */
 
/*
 * Since the TRANS_DONE bit is cleared on read, and we may read it
@@ -433,7 +433,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
 
i2c->state = -EINVAL;
 
-   spin_lock(>lock);
+   raw_spin_lock(>lock);
 
int_status = readl(i2c->regs + HSI2C_INT_STATUS);
writel(int_status, i2c->regs + HSI2C_INT_STATUS);
@@ -521,7 +521,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
complete(>msg_complete);
}
 
-   spin_unlock(>lock);
+   raw_spin_unlock(>lock);
 
return IRQ_HANDLED;
 }
@@ -610,7 +610,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c 
*i2c, int stop)
 * Enable interrupts before starting the transfer so that we don't
 * miss any INT_I2C interrupts.
 */
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
writel(int_en, i2c->regs + HSI2C_INT_ENABLE);
 
if (stop == 1)
@@ -618,7 +618,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c 
*i2c, int stop)
i2c_auto_conf |= i2c->msg->len;
i2c_auto_conf |= HSI2C_MASTER_RUN;
writel(i2c_auto_conf, i2c->regs + HSI2C_AUTO_CONF);
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
 }
 
 static int exynos5_i2c_xfer_msg(struct exynos5_i2c *i2c,
@@ -763,7 +763,7 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
/* Clear pending interrupts from u-boot or misc causes */
exynos5_i2c_clr_pend_irq(i2c);
 
-   spin_lock_init(>lock);
+   raw_spin_lock_init(>lock);
init_completion(>msg_complete);
 
i2c->irq = ret = platform_get_irq(pdev, 0);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] drivers: i2c: exynos5: irq spinlock rt-safe

2015-09-03 Thread Thomas Gleixner 
On Thu, 3 Sep 2015, Anders Roxell wrote:

> The current spin_lock_irqsave() protects the enabling of the device
> interrupt.  In order to prevent recursion in the case of sleeping
> spinlocks (e.g. with RT patch, stacktrace below), convert the spin lock
> to a raw spin lock. No change for !RT kernels.
> 
> [   10.992238] kernel BUG at ../kernel/locking/rtmutex.c:998!
> [   10.992243] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [   10.992250] Modules linked in:
> [   10.992258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.1.5-rt5
> [   10.992263] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   10.992268] task: ed88 ti: ed888000 task.ti: ed888000
> [   10.992281] PC is at rt_spin_lock_slowlock+0xa4/0x2ec
> [   10.992288] LR is at rt_spin_lock_slowlock+0x54/0x2ec
> [   10.992296] pc : []lr : []psr: 6193
> [   10.992296] sp : ed889a28  ip : ed880001  fp : 0089
> [   10.992300] r10: ed889a28  r9 : c0f55654  r8 : 0060
> [   10.992305] r7 : ed88  r6 :   r5 : 0001  r4 : ed9f7288
> [   10.992310] r3 : ed88  r2 :   r1 : ed88  r0 : 
> [   10.992316] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
> Segment kernel
> ...
> ...
> [   10.992662] [] (rt_spin_lock_slowlock) from []
> (exynos5_i2c_irq+0x20/0x2b0)
> [   10.992678] [] (exynos5_i2c_irq) from []
> (handle_irq_event_percpu+0x68/0x158)
> [   10.992690] [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x68/0xa8)
> [   10.992702] [] (handle_irq_event) from []
> (handle_fasteoi_irq+0x11c/0x1d4)
> [   10.992713] [] (handle_fasteoi_irq) from []
> (generic_handle_irq+0x20/0x30)
> [   10.992724] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x6c/0xe4)
> [   10.992734] [] (__handle_domain_irq) from []
> (gic_handle_irq+0x2c/0x68)
> [   10.992744] [] (gic_handle_irq) from []
> (__irq_svc+0x40/0x88)
> [   10.992749] Exception stack(0xed889b28 to 0xed889b70)

What you completely fail to explain how this can happen at all.

On RT the interrupt of that device is force threaded, but the handler
is called in hard interrupt context, which is wrong to begin with.

While the interrupt request in this driver is bogus:

ret = devm_request_irq(>dev, i2c->irq, exynos5_i2c_irq,
IRQF_NO_SUSPEND | IRQF_ONESHOT,
dev_name(>dev), i2c);

because it sets the ONESHOT flag for no reason, it does not set the
NOTRHEAD flag which would prevent force threading.

Hmm?

tglx





--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

2015-09-03 Thread Rob Herring 
On Thu, Sep 3, 2015 at 3:47 AM, Thierry Reding  wrote:
> On Wed, Sep 02, 2015 at 03:17:57PM -0500, Rob Herring wrote:
> [...]
>> Are there any eDP panels which don't have EDID and need panel details in DT?
>
> Most panels need information other than EDID. They typically have some
> requirements regarding the power up sequence that aren't to be found
> anywhere in EDID or detectable by some other mechanism. A decision was
> therefore made a long time ago to require panels to be listed in DT with
> a specific compatible string. That way all of these details can be
> stashed away in drivers that know how to deal with these kinds of
> details.

I guess I was being hopeful that eDP was improving that situation.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 05/16] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & colorimetry

2015-09-03 Thread Krzysztof Kozlowski 
On 01.09.2015 14:55, Yakir Yang wrote:
> Both hsync/vsync polarity and interlace mode can be parsed from
> drm display mode, and dynamic_range and ycbcr_coeff can be judge
> by the video code, same to color space and color depth can be
> parsed from EDID.
> 
> But presumably Exynos still relaies on the DT properties, so take

s/relaies/relies/

> good use of mode_fixup() in to achieve the compatibility hacks.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v4:
> - Take Krzysztof suggest, provide backword compatibility with samsung.
> - Take Thierry suggest, add "color-depth" and "color-space" dynamic parsed.
> 
> Changes in v3:
> - Take Thierry Reding suggest, dynamic parse video timing info from
>   struct drm_display_mode and struct drm_display_info.
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 141 
> +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
>  drivers/gpu/drm/exynos/exynos_dp.c |  58 -
>  4 files changed, 151 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 7196097..f0db92e 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -897,8 +897,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>   return;
>   }
>  
> - ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
> -  dp->video_info->link_rate);
> + ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> +  dp->video_info.link_rate);
>   if (ret) {
>   dev_err(dp->dev, "unable to do link train\n");
>   return;
> @@ -1081,6 +1081,82 @@ static void analogix_dp_bridge_disable(struct 
> drm_bridge *bridge)
>   dp->dpms_mode = DRM_MODE_DPMS_OFF;
>  }
>  
> +static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *orig_mode,
> + struct drm_display_mode *mode)
> +{
> + struct analogix_dp_device *dp = bridge->driver_private;
> + struct drm_display_info *display_info = >connector.display_info;
> + struct video_info *video_info = >video_info;
> + struct device_node *dp_node = dp->dev->of_node;
> + int vic;
> +
> + /* interlaces & hsync pol & vsync pol */
> + video_info->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> + video_info->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
> + video_info->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> +
> + /* dynamic_range & colorimetry */
> + vic = drm_match_cea_mode(mode);
> + if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
> + (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
> + video_info->dynamic_range = CEA;
> + video_info->ycbcr_coeff = COLOR_YCBCR601;
> + } else if (vic) {
> + video_info->dynamic_range = CEA;
> + video_info->ycbcr_coeff = COLOR_YCBCR709;
> + } else {
> + video_info->dynamic_range = VESA;
> + video_info->ycbcr_coeff = COLOR_YCBCR709;
> + }
> +
> + switch (display_info->bpc) {
> + case 12:
> + video_info->color_depth = COLOR_12;
> + break;
> + case 10:
> + video_info->color_depth = COLOR_10;
> + break;
> + case 8:
> + video_info->color_depth = COLOR_8;
> + break;
> + case 6:
> + video_info->color_depth = COLOR_6;
> + break;
> + default:
> + video_info->color_depth = COLOR_8;
> + break;
> + }
> +
> + if (display_info->color_formats | DRM_COLOR_FORMAT_YCRCB444)
> + video_info->color_space = COLOR_YCBCR444;
> + else if (display_info->color_formats | DRM_COLOR_FORMAT_YCRCB422)
> + video_info->color_space = COLOR_YCBCR422;
> + else if (display_info->color_formats | DRM_COLOR_FORMAT_RGB444)
> + video_info->color_space = COLOR_RGB;
> + else
> + video_info->color_space = COLOR_RGB;
> +
> + /*
> +  * NOTE: those property parseing code is used for

s/parseing/parsing/

BTW, you can easily integrate spell-check to vim... It is not that I
search for such misspellings - they are highlighted...

> +  * providing backward compatibility for samsung platform.
> +  */
> + of_property_read_u32(dp_node, "samsung,color-space",
> +  _info->color_space);
> + of_property_read_u32(dp_node, "samsung,dynamic-range",
> +  _info->dynamic_range);
> + of_property_read_u32(dp_node,

Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting

2015-09-03 Thread Thierry Reding 
On Wed, Sep 02, 2015 at 06:02:25PM +0800, Yakir Yang wrote:
> 在 2015/9/2 16:34, Thierry Reding 写道:
[...]
> >At the very least your code must compile when applied against a recent
> >upstream tree. I would also expect you to make sure the code works at
> >runtime, though, contrary to build testing, not everybody will be able
> >to verify that you've actually done so. It is ultimately your platform
> >maintainer's (i.e. Heiko's) responsibility to ensure that because they
> >will get to deal with user complaints if people can't run an upstream
> >kernel on the devices.
> 
> Oh, first time to know this rule. So I should work on Heiko's github
> kernel branch at the first time to start send upstream.

It's usually not necessary to rebase on a specific platform tree. Most
platform trees should feed into linux-next anyway, so linux-next would
be the appropriate base in almost all cases.

Note, though, that that's only true if you expect somebody else to merge
your code. The reason is that whoever will end up applying your patches
will likely apply to a tree that feeds into linux-next, and that way you
both end up having roughly the same base.

On the other hand if you are a maintainer yourself you should be keeping
a branch based on the latest -rc1. That's especially important if your
tree feeds into linux-next, because basing on linux-next will break very
horribly that way.

So for this particular case I would expect either Mark or Inki to apply
these patches when they're ready. Their trees should be based on the
latest -rc1. At least the Exynos DRM tree feeds into linux-next, so you
should be fine if you use linux-next as a base.

Mark, have you ever considered having your tree added to linux-next?

I'm beginning to think that we need to make that a requirement for all
DRM drivers so that we can resolve integration issues early on rather
than Dave having to deal with them when he pulls code in.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

2015-09-03 Thread Thierry Reding 
On Wed, Sep 02, 2015 at 03:17:57PM -0500, Rob Herring wrote:
[...]
> Are there any eDP panels which don't have EDID and need panel details in DT?

Most panels need information other than EDID. They typically have some
requirements regarding the power up sequence that aren't to be found
anywhere in EDID or detectable by some other mechanism. A decision was
therefore made a long time ago to require panels to be listed in DT with
a specific compatible string. That way all of these details can be
stashed away in drivers that know how to deal with these kinds of
details.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

2015-09-03 Thread Thierry Reding 
On Thu, Sep 03, 2015 at 12:27:47PM +0800, Yakir Yang wrote:
> Hi Rob,
> 
> 在 09/03/2015 04:17 AM, Rob Herring 写道:
> >On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang  wrote:
> >>Some edp screen do not have hpd signal, so we can't just return
> >>failed when hpd plug in detect failed.
> >This is a property of the panel (or connector perhaps), so this
> >property should be located there. At least, it is a common issue and
> >not specific to this chip. We could have an HDMI connector and failed
> >to hook up HPD for example. A connector node is also where hpd-gpios
> >should be located instead (and are already defined by
> >../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector
> >binding, too.
> 
> Yep, I agree with your front point, it is a property of panel, not specific
> to eDP controller, so this code should handle in connector logic.

From your description it sounds more like this is in fact a property of
the panel. Or maybe I should say "quirk". If the panel doesn't generate
the HPD signal, then that should be a property of the panel, not the
connector. The eDP specification mandates that connectors have a HPD
signal, though it allows the "HPD conductor in the connector cable" to
be omitted if not used by the source. I'd consider the cable to belong
to the panel rather than the connector, so absence of HPD, either
because the cable doesn't have the conductor or because the panel does
not generate the signal, should be a quirk of the panel.

That said you could have a panel that supports HPD connected via a cable
that doesn't transmit it, so this would be a per-board variant and hence
should be a device tree property rather than hard-coded in some panel
driver.

Conversely, if the panel isn't capable of generating an HPD signal, then
I don't think it would be appropriate to make it a DT property. It would
be better to hard-code it in the driver, lest someone forget to set the
property in DT and get stuck with a device that isn't operational.

Thierry


signature.asc
Description: PGP signature

Re: [PATCHv6] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4

2015-09-03 Thread Javier Martinez Canillas 
Hello Anand,

On 09/03/2015 07:38 AM, Anand Moon wrote:
> Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM,
> LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for
> Odroid-XU3/XU4 board.
> 
> Signed-off-by: Anand Moon 
> 
> ---

I think Krzysztof already mentioned but a commit message shouln't
describe what the change is (one can look to the patch for that)
but why the change is needed.

So I would had expect something along these lines:

Many Exynos boards (i.e: the Exynos5422 Odroid XU3/XU4) have GPIO
and PWM based LEDs, so enable the needed Kconfig options to have
support for these. Also, some boards use the heartbeat LED trigger
so enable support for this as well.

> Changes from last version
> dropped following option.
>   CONFIG_LEDS_CLASS_FLASH
>   CONFIG_TRIGGER_ONESHOT
>   CONFIG_TRIGGER_GPIO
> fixed the From address
> ---
>  arch/arm/configs/exynos_defconfig | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/configs/exynos_defconfig 
> b/arch/arm/configs/exynos_defconfig
> index 9504e77..aaf7aa4 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_IDMAC=y
>  CONFIG_MMC_DW_EXYNOS=y
> +CONFIG_NEW_LEDS=y
> +CONFIG_LEDS_CLASS=y
> +CONFIG_LEDS_GPIO=y
> +CONFIG_LEDS_PWM=y
> +CONFIG_LEDS_TRIGGERS=y
> +CONFIG_LEDS_TRIGGER_TIMER=y

I don't see an Exynos board using the timer trigger. Do you need it for
some user-space application that uses the sysfs interface? I'm OK with
enabling it but again this should be mentioned in the commit message.

> +CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>  CONFIG_RTC_CLASS=y
>  CONFIG_RTC_DRV_MAX77686=y
>  CONFIG_RTC_DRV_MAX77802=y
> 

The change looks good to me though so with a better commit message:

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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: [PATCHv6] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4

2015-09-03 Thread Anand Moon 
Hi Javier,

On 3 September 2015 at 14:50, Javier Martinez Canillas
 wrote:
> Hello Anand,
>
> On 09/03/2015 07:38 AM, Anand Moon wrote:
>> Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM,
>> LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for
>> Odroid-XU3/XU4 board.
>>
>> Signed-off-by: Anand Moon 
>>
>> ---
>
> I think Krzysztof already mentioned but a commit message shouln't
> describe what the change is (one can look to the patch for that)
> but why the change is needed.
>
> So I would had expect something along these lines:
>
> Many Exynos boards (i.e: the Exynos5422 Odroid XU3/XU4) have GPIO
> and PWM based LEDs, so enable the needed Kconfig options to have
> support for these. Also, some boards use the heartbeat LED trigger
> so enable support for this as well.
>
>> Changes from last version
>> dropped following option.
>>   CONFIG_LEDS_CLASS_FLASH
>>   CONFIG_TRIGGER_ONESHOT
>>   CONFIG_TRIGGER_GPIO
>> fixed the From address
>> ---
>>  arch/arm/configs/exynos_defconfig | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/configs/exynos_defconfig 
>> b/arch/arm/configs/exynos_defconfig
>> index 9504e77..aaf7aa4 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y
>>  CONFIG_MMC_DW=y
>>  CONFIG_MMC_DW_IDMAC=y
>>  CONFIG_MMC_DW_EXYNOS=y
>> +CONFIG_NEW_LEDS=y
>> +CONFIG_LEDS_CLASS=y
>> +CONFIG_LEDS_GPIO=y
>> +CONFIG_LEDS_PWM=y
>> +CONFIG_LEDS_TRIGGERS=y
>> +CONFIG_LEDS_TRIGGER_TIMER=y
>

> I don't see an Exynos board using the timer trigger. Do you need it for
> some user-space application that uses the sysfs interface? I'm OK with
> enabling it but again this should be mentioned in the commit message.
>
>> +CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>>  CONFIG_RTC_CLASS=y
>>  CONFIG_RTC_DRV_MAX77686=y
>>  CONFIG_RTC_DRV_MAX77802=y
>>
>

Earlier design of the LED for Odroid XU3 was using gpio-leds
Now It was change to using both pwm-leds and gpio-leds.

Earlier I kept them as loadable module and now build-in.

Should I resend this again. Or some body will update the commit message.

-Anand Moon

> The change looks good to me though so with a better commit message:
>
> Reviewed-by: Javier Martinez Canillas 
>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
--
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: [PATCHv6] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4

2015-09-03 Thread Javier Martinez Canillas 
Hello Anand,

On 09/03/2015 11:47 AM, Anand Moon wrote:
> Hi Javier,
> 
> On 3 September 2015 at 14:50, Javier Martinez Canillas
>  wrote:
>> Hello Anand,
>>
>> On 09/03/2015 07:38 AM, Anand Moon wrote:
>>> Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM,
>>> LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for
>>> Odroid-XU3/XU4 board.
>>>
>>> Signed-off-by: Anand Moon 
>>>
>>> ---
>>
>> I think Krzysztof already mentioned but a commit message shouln't
>> describe what the change is (one can look to the patch for that)
>> but why the change is needed.
>>
>> So I would had expect something along these lines:
>>
>> Many Exynos boards (i.e: the Exynos5422 Odroid XU3/XU4) have GPIO
>> and PWM based LEDs, so enable the needed Kconfig options to have
>> support for these. Also, some boards use the heartbeat LED trigger
>> so enable support for this as well.
>>
>>> Changes from last version
>>> dropped following option.
>>>   CONFIG_LEDS_CLASS_FLASH
>>>   CONFIG_TRIGGER_ONESHOT
>>>   CONFIG_TRIGGER_GPIO
>>> fixed the From address
>>> ---
>>>  arch/arm/configs/exynos_defconfig | 7 +++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/configs/exynos_defconfig 
>>> b/arch/arm/configs/exynos_defconfig
>>> index 9504e77..aaf7aa4 100644
>>> --- a/arch/arm/configs/exynos_defconfig
>>> +++ b/arch/arm/configs/exynos_defconfig
>>> @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y
>>>  CONFIG_MMC_DW=y
>>>  CONFIG_MMC_DW_IDMAC=y
>>>  CONFIG_MMC_DW_EXYNOS=y
>>> +CONFIG_NEW_LEDS=y
>>> +CONFIG_LEDS_CLASS=y
>>> +CONFIG_LEDS_GPIO=y
>>> +CONFIG_LEDS_PWM=y
>>> +CONFIG_LEDS_TRIGGERS=y
>>> +CONFIG_LEDS_TRIGGER_TIMER=y
>>
> 
>> I don't see an Exynos board using the timer trigger. Do you need it for
>> some user-space application that uses the sysfs interface? I'm OK with
>> enabling it but again this should be mentioned in the commit message.
>>

You haven't answered this question.

>>> +CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>>>  CONFIG_RTC_CLASS=y
>>>  CONFIG_RTC_DRV_MAX77686=y
>>>  CONFIG_RTC_DRV_MAX77802=y
>>>
>>
> 
> Earlier design of the LED for Odroid XU3 was using gpio-leds
> Now It was change to using both pwm-leds and gpio-leds.
>

I know that Odroid XU3 have both LEDs connected to GPIO and
PWM lines but that should be mentioned in the commit message.
 
> Earlier I kept them as loadable module and now build-in.
>

Yes, because exynos_defconfig as everything as built-in to
make it easier for developers to test by only copying the
kernel image and not the modules.
 
> Should I resend this again. Or some body will update the commit message.
>

If a patch has a typo, an extra blank line or something
very easy to fix then it may be possible that the maintainer
will do the fix when applying but changing the commit message
I think is too much so in this case is better to resend IMHO.
 
> -Anand Moon
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support

2015-09-03 Thread Krzysztof Kozlowski 
On 01.09.2015 15:07, Yakir Yang wrote:

Empty commit message. Please explain here why you want to add platform
device type support.

Actually the title is confusing. You are not adding support for platform
device types but rather adding a field containing type of device.


> Signed-off-by: Yakir Yang 
> ---
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Add GNU license v2 declared and samsung copyright
> 
>  drivers/gpu/drm/exynos/exynos_dp.c  |  1 +
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |  1 +
>  include/drm/bridge/analogix_dp.h| 16 
>  3 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index 6060d2c..40ef727 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -224,6 +224,7 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>   dp->dev = dev;
>   dp->drm_dev = drm_dev;
>  
> + dp->plat_data.dev_type = EXYNOS_DP;
>   dp->plat_data.power_on = exynos_dp_poweron;
>   dp->plat_data.power_off = exynos_dp_poweroff;
>   dp->plat_data.get_modes = exynos_dp_get_modes;
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index efea045..4934271 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -293,6 +293,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
> device *master,
>   return ret;
>   }
>  
> + dp->plat_data.dev_type = RK3288_DP;
>   dp->plat_data.attach = NULL;
>   dp->plat_data.get_modes = NULL;
>   dp->plat_data.power_on = rockchip_dp_poweron;
> diff --git a/include/drm/bridge/analogix_dp.h 
> b/include/drm/bridge/analogix_dp.h
> index 8b4ffad..7209a64 100644
> --- a/include/drm/bridge/analogix_dp.h
> +++ b/include/drm/bridge/analogix_dp.h
> @@ -1,9 +1,25 @@
> +/*
> + * Analogix Core DP (Display Port) interface driver.
> + *
> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */

Two questions:
1. Why this change is here? I would rather expect it at patch 3/16 when
you created this file... That is the usual time for adding copyrights.

2. Does this file contains previous Samsung work?

Best regards,
Krzysztof

>  #ifndef _ANALOGIX_DP_H_
>  #define _ANALOGIX_DP_H_
>  
>  #include 
>  
> +enum analogix_dp_devtype {
> + EXYNOS_DP,
> + RK3288_DP,
> +};
> +
>  struct analogix_dp_plat_data {
> + enum analogix_dp_devtype dev_type;
>   struct drm_panel *panel;
>  
>   int (*power_on)(struct analogix_dp_plat_data *);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

2015-09-03 Thread Krzysztof Kozlowski 
On 03.09.2015 14:30, Yakir Yang wrote:
> Hi Krzysztof,
> 
> 在 09/03/2015 08:58 AM, Krzysztof Kozlowski 写道:
>> On 01.09.2015 14:49, Yakir Yang wrote:
>>> Split the dp core driver from exynos directory to bridge
>>> directory, and rename the core driver to analogix_dp_*,
>>> leave the platform code to analogix_dp-exynos.
>>>
>>> Signed-off-by: Yakir Yang 
>>> ---
>>> Changes in v4:
>>> - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT
>>> propery.
>>> - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to
>>> "exynos_dp.c"
>>> - Take Archit suggest, create a separate folder for analogix code in
>>> bridge/
>>>
>>> Changes in v3:
>>> - Take Thierry Reding suggest, move exynos's video_timing code
>>>to analogix_dp-exynos platform driver, add get_modes method
>>>to struct analogix_dp_plat_data.
>>> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
>>>
>>> Changes in v2:
>>> - Take Jingoo Han suggest, remove new copyright
>>> - Fix compiled failed dut to analogix_dp_device misspell
>>>
>>>   drivers/gpu/drm/bridge/Kconfig |2 +
>>>   drivers/gpu/drm/bridge/Makefile|1 +
>>>   drivers/gpu/drm/bridge/analogix/Kconfig|4 +
>>>   drivers/gpu/drm/bridge/analogix/Makefile   |1 +
>>>   .../analogix/analogix_dp_core.c}   |  817
>>> ++---
>>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  283 +
>>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 1265
>>> 
>>>   .../analogix/analogix_dp_reg.h}|  258 ++--
>>>   drivers/gpu/drm/exynos/Kconfig |3 +-
>>>   drivers/gpu/drm/exynos/Makefile|2 +-
>>>   drivers/gpu/drm/exynos/exynos_dp.c |  306 +
>>>   drivers/gpu/drm/exynos/exynos_dp_core.h|  282 -
>>>   drivers/gpu/drm/exynos/exynos_dp_reg.c | 1259
>>> ---
>>>   include/drm/bridge/analogix_dp.h   |   24 +
>>>   14 files changed, 2357 insertions(+), 2150 deletions(-)
>>>   create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
>>>   create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
>>>   rename drivers/gpu/drm/{exynos/exynos_dp_core.c =>
>>> bridge/analogix/analogix_dp_core.c} (50%)
>>>   create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>>>   create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>>>   rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
>>> bridge/analogix/analogix_dp_reg.h} (64%)
>>>   create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
>>>   delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
>>>   delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
>>>   create mode 100644 include/drm/bridge/analogix_dp.h
>>>
>>> diff --git a/drivers/gpu/drm/bridge/Kconfig
>>> b/drivers/gpu/drm/bridge/Kconfig
>>> index 2de52a5..7b5b77a 100644
>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>> @@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
>>>   ---help---
>>> Parade eDP-LVDS bridge chip driver.
>>>   +source "drivers/gpu/drm/bridge/analogix/Kconfig"
>>> +
>>>   endmenu
>>> diff --git a/drivers/gpu/drm/bridge/Makefile
>>> b/drivers/gpu/drm/bridge/Makefile
>>> index e2eef1c..5366c6b 100644
>>> --- a/drivers/gpu/drm/bridge/Makefile
>>> +++ b/drivers/gpu/drm/bridge/Makefile
>>> @@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
>>>   obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
>>>   obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>>>   obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>>> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>>> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
>>> b/drivers/gpu/drm/bridge/analogix/Kconfig
>>> new file mode 100644
>>> index 000..5ff6551
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
>>> @@ -0,0 +1,4 @@
>>> +config DRM_ANALOGIX_DP
>>> +tristate
>>> +depends on DRM
>>> +select DRM_KMS_HELPER
>>> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
>>> b/drivers/gpu/drm/bridge/analogix/Makefile
>>> new file mode 100644
>>> index 000..9107b86
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
>>> @@ -0,0 +1 @@
>>> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp_core.o analogix_dp_reg.o
>>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> similarity index 50%
>>> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
>>> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> index bed0252..7d62f22 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> @@ -1,14 +1,14 @@
>>>   /*
>>> - * Samsung SoC DP (Display Port) interface driver.
>>> - *
>>> - * Copyright (C) 2012 Samsung Electronics Co., Ltd.
>>> - * Author: Jingoo Han 
>>> -

Re: [PATCHv7] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4

2015-09-03 Thread Krzysztof Kozlowski 
On 04.09.2015 03:11, Anand Moon wrote:
> Earlier design of the LED for Odroid XU3 was using gpio-leds
> Now It was change to using both pwm-leds and gpio-leds.

It is still not a reason for this change. gpio-leds were not enabled
before. This could be a valid reason of adding LEDS_PWM to existing
config LEDS_GPIO. But LEDS_GPIO were not enabled... so why the change on
the board from gpio->(gpio+pwm) means that we have to enable LEDS_GPIO?

Actually I gave up on this and I wanted to change the commit message on
myself when applying. But discussion was brought up again so... clearly
we have different understanding of the meaning of "WHY". :)

Best regards,
Krzysztof

> 
> Signed-off-by: Anand Moon 
> Reviewed-by: Javier Martinez Canillas 
> 
> ---
> Changes from last version
> dropped following option.
>   CONFIG_LEDS_CLASS_FLASH
>   CONFIG_TRIGGER_ONESHOT
>   CONFIG_LEDS_TRIGGER_TIMER
>   CONFIG_TRIGGER_GPIO
> fixed the From address
> fixed the commit message.
> ---
>  arch/arm/configs/exynos_defconfig | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/configs/exynos_defconfig 
> b/arch/arm/configs/exynos_defconfig
> index 9504e77..bd6b7f7 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -163,6 +163,12 @@ CONFIG_MMC_SDHCI_S3C_DMA=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_IDMAC=y
>  CONFIG_MMC_DW_EXYNOS=y
> +CONFIG_NEW_LEDS=y
> +CONFIG_LEDS_CLASS=y
> +CONFIG_LEDS_GPIO=y
> +CONFIG_LEDS_PWM=y
> +CONFIG_LEDS_TRIGGERS=y
> +CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>  CONFIG_RTC_CLASS=y
>  CONFIG_RTC_DRV_MAX77686=y
>  CONFIG_RTC_DRV_MAX77802=y
> 

--
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: [PATCHv7] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4

2015-09-03 Thread Javier Martinez Canillas 
Hello Krzysztof,

On 09/04/2015 01:55 AM, Krzysztof Kozlowski wrote:
> On 04.09.2015 03:11, Anand Moon wrote:
>> Earlier design of the LED for Odroid XU3 was using gpio-leds
>> Now It was change to using both pwm-leds and gpio-leds.
> 
> It is still not a reason for this change. gpio-leds were not enabled
> before. This could be a valid reason of adding LEDS_PWM to existing
> config LEDS_GPIO. But LEDS_GPIO were not enabled... so why the change on
> the board from gpio->(gpio+pwm) means that we have to enable LEDS_GPIO?
>

Agreed, also the commit message doesn't explain why the heartbeat
LED trigger is enabled as I mentioned in the previous version.

> Actually I gave up on this and I wanted to change the commit message on
> myself when applying. But discussion was brought up again so... clearly
> we have different understanding of the meaning of "WHY". :)
>
> Best regards,
> Krzysztof
> 
 
Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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

[RFC PATCH] clocksource: exynos_mct: use container_of() instead of this_cpu_ptr()

2015-09-03 Thread Alexey Klimov 
Since evt structure is embedded in per-CPU mevt structure it's
definitely faster to use container_of() to get access to mevt
if we have evt (for example as incoming function argument) instead
of more expensive approach with this_cpu_ptr(_mct_tick).
this_cpu_ptr() on per-CPU mevt structure leads to access to cp15
to get cpu id and arithmetic operations.
Container_of() is cheaper since it's just one asm instruction.
This should work if used evt pointer is correct and owned by
local mevt structure.

For example, before this patch set_state_shutdown() looks like:

 4a4:   e92d4010push{r4, lr}
 4a8:   e3004000movwr4, #0
 4ac:   ebfebl  0 
 4b0:   e3003000movwr3, #0
 4b4:   e3404000movtr4, #0
 4b8:   e3403000movtr3, #0
 4bc:   e7933100ldr r3, [r3, r0, lsl #2]
 4c0:   e0844003add r4, r4, r3
 4c4:   e59400c0ldr r0, [r4, #192]  ; 0xc0
 4c8:   ebd4bl  420 
 4cc:   e3a0mov r0, #0
 4d0:   e8bd8010pop {r4, pc}

With this patch:

 4a4:   e92d4010push{r4, lr}
 4a8:   e59000c0ldr r0, [r0, #192]  ; 0xc0
 4ac:   ebdbbl  420 
 4b0:   e3a0mov r0, #0
 4b4:   e8bd8010pop {r4, pc}

Also, for me size of exynos_mct.o decreased from 84588 bytes
to 83956.

Signed-off-by: Alexey Klimov 
---
 drivers/clocksource/exynos_mct.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 029f96a..ff44082 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -382,24 +382,28 @@ static void exynos4_mct_tick_start(unsigned long cycles,
 static int exynos4_tick_set_next_event(unsigned long cycles,
   struct clock_event_device *evt)
 {
-   struct mct_clock_event_device *mevt = this_cpu_ptr(_mct_tick);
+   struct mct_clock_event_device *mevt;
 
+   mevt = container_of(evt, struct mct_clock_event_device, evt);
exynos4_mct_tick_start(cycles, mevt);
-
return 0;
 }
 
 static int set_state_shutdown(struct clock_event_device *evt)
 {
-   exynos4_mct_tick_stop(this_cpu_ptr(_mct_tick));
+   struct mct_clock_event_device *mevt;
+
+   mevt = container_of(evt, struct mct_clock_event_device, evt);
+   exynos4_mct_tick_stop(mevt);
return 0;
 }
 
 static int set_state_periodic(struct clock_event_device *evt)
 {
-   struct mct_clock_event_device *mevt = this_cpu_ptr(_mct_tick);
+   struct mct_clock_event_device *mevt;
unsigned long cycles_per_jiffy;
 
+   mevt = container_of(evt, struct mct_clock_event_device, evt);
cycles_per_jiffy = (((unsigned long long)NSEC_PER_SEC / HZ * evt->mult)
>> evt->shift);
exynos4_mct_tick_stop(mevt);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drm/exynos: add cursor plane support

2015-09-03 Thread Inki Dae 
Hi Gustavo,

I had already a review but I didn't give any comment to you. Sorry about
that. This patch looks good to me but one thing isn't clear. Below is my
comment.


On 2015년 09월 04일 05:14, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Set one of the planes for each crtc driver as a cursor plane enabled
> window managers to fully work on exynos.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  9 ++---
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++---
>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  5 ++---
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
>  8 files changed, 31 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index b3c7307..79b2b22 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -33,7 +33,6 @@ struct decon_context {
>   struct exynos_drm_plane planes[WINDOWS_NR];
>   void __iomem*addr;
>   struct clk  *clks[6];
> - unsigned intdefault_win;
>   unsigned long   irq_flags;
>   int pipe;
>   boolsuspended;
> @@ -493,7 +492,6 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   struct drm_device *drm_dev = data;
>   struct exynos_drm_private *priv = drm_dev->dev_private;
>   struct exynos_drm_plane *exynos_plane;
> - enum drm_plane_type type;
>   unsigned int zpos;
>   int ret;
>  
> @@ -501,16 +499,14 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   ctx->pipe = priv->pipe++;
>  
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
> - 1 << ctx->pipe, type, decon_formats,
> + 1 << ctx->pipe, decon_formats,
>   ARRAY_SIZE(decon_formats), zpos);
>   if (ret)
>   return ret;
>   }
>  
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
>   ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>   ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>   _crtc_ops, ctx);
> @@ -607,7 +603,6 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>   if (!ctx)
>   return -ENOMEM;
>  
> - ctx->default_win = 0;
>   ctx->suspended = true;
>   ctx->dev = dev;
>   if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index cbdb78e..f3826dc 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -52,7 +52,6 @@ struct decon_context {
>   struct clk  *eclk;
>   struct clk  *vclk;
>   void __iomem*regs;
> - unsigned intdefault_win;
>   unsigned long   irq_flags;
>   booli80_if;
>   boolsuspended;
> @@ -691,7 +690,6 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   struct decon_context *ctx = dev_get_drvdata(dev);
>   struct drm_device *drm_dev = data;
>   struct exynos_drm_plane *exynos_plane;
> - enum drm_plane_type type;
>   unsigned int zpos;
>   int ret;
>  
> @@ -702,16 +700,14 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   }
>  
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
> - 1 << ctx->pipe, type, decon_formats,
> + 1 << ctx->pipe, decon_formats,
>   ARRAY_SIZE(decon_formats), zpos);
>   if (ret)
>   return ret;
>   }
>  
> - exynos_plane = >planes[ctx->default_win];
> +

[PATCH] drm/exynos: add cursor plane support

2015-09-03 Thread Gustavo Padovan 
From: Gustavo Padovan 

Set one of the planes for each crtc driver as a cursor plane enabled
window managers to fully work on exynos.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  9 ++---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++---
 drivers/gpu/drm/exynos/exynos_drm_plane.h |  5 ++---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++---
 drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
 8 files changed, 31 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index b3c7307..79b2b22 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -33,7 +33,6 @@ struct decon_context {
struct exynos_drm_plane planes[WINDOWS_NR];
void __iomem*addr;
struct clk  *clks[6];
-   unsigned intdefault_win;
unsigned long   irq_flags;
int pipe;
boolsuspended;
@@ -493,7 +492,6 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_private *priv = drm_dev->dev_private;
struct exynos_drm_plane *exynos_plane;
-   enum drm_plane_type type;
unsigned int zpos;
int ret;
 
@@ -501,16 +499,14 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
ctx->pipe = priv->pipe++;
 
for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
-   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
-   DRM_PLANE_TYPE_OVERLAY;
ret = exynos_plane_init(drm_dev, >planes[zpos],
-   1 << ctx->pipe, type, decon_formats,
+   1 << ctx->pipe, decon_formats,
ARRAY_SIZE(decon_formats), zpos);
if (ret)
return ret;
}
 
-   exynos_plane = >planes[ctx->default_win];
+   exynos_plane = >planes[DEFAULT_WIN];
ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
_crtc_ops, ctx);
@@ -607,7 +603,6 @@ static int exynos5433_decon_probe(struct platform_device 
*pdev)
if (!ctx)
return -ENOMEM;
 
-   ctx->default_win = 0;
ctx->suspended = true;
ctx->dev = dev;
if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index cbdb78e..f3826dc 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -52,7 +52,6 @@ struct decon_context {
struct clk  *eclk;
struct clk  *vclk;
void __iomem*regs;
-   unsigned intdefault_win;
unsigned long   irq_flags;
booli80_if;
boolsuspended;
@@ -691,7 +690,6 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
struct decon_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
-   enum drm_plane_type type;
unsigned int zpos;
int ret;
 
@@ -702,16 +700,14 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
}
 
for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
-   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
-   DRM_PLANE_TYPE_OVERLAY;
ret = exynos_plane_init(drm_dev, >planes[zpos],
-   1 << ctx->pipe, type, decon_formats,
+   1 << ctx->pipe, decon_formats,
ARRAY_SIZE(decon_formats), zpos);
if (ret)
return ret;
}
 
-   exynos_plane = >planes[ctx->default_win];
+   exynos_plane = >planes[DEFAULT_WIN];
ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
   ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
   _crtc_ops, ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h

Re: [PATCHv7] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4

2015-09-03 Thread Anand Moon 
Hi All,

On 4 September 2015 at 05:56, Javier Martinez Canillas
 wrote:
> Hello Krzysztof,
>
> On 09/04/2015 01:55 AM, Krzysztof Kozlowski wrote:
>> On 04.09.2015 03:11, Anand Moon wrote:
>>> Earlier design of the LED for Odroid XU3 was using gpio-leds
>>> Now It was change to using both pwm-leds and gpio-leds.
>>
>> It is still not a reason for this change. gpio-leds were not enabled
>> before. This could be a valid reason of adding LEDS_PWM to existing
>> config LEDS_GPIO. But LEDS_GPIO were not enabled... so why the change on
>> the board from gpio->(gpio+pwm) means that we have to enable LEDS_GPIO?
>>
>
> Agreed, also the commit message doesn't explain why the heartbeat
> LED trigger is enabled as I mentioned in the previous version.
>
>> Actually I gave up on this and I wanted to change the commit message on
>> myself when applying. But discussion was brought up again so... clearly
>> we have different understanding of the meaning of "WHY". :)
>>
>> Best regards,
>> Krzysztof
>>
>
I give up. I will not resend any patch.
I don't own this changes.

sorry for the noise.

-Anand Moon
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
--
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