Re: [PATCH 5/6] ARM: EXYNOS: Minor fixes to enable EXYNOS5410 support
On 3 October 2013 02:37, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vyacheslav, Tarek,
On Tuesday 01 of October 2013 20:17:06 Vyacheslav Tyrtov wrote:
From: Tarek Dakhran t.dakh...@samsung.com
Configure ARM_NR_BANKS as 16 for EXYNOS SoC.
Enable cci_control_port_by_index for ACE_PORT.
Add additional irqs for Exynos MCT.
Set irq base as 256 for EXYNOS5410 SoC.
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
---
arch/arm/Kconfig | 2 +-
drivers/bus/arm-cci.c | 7 +++
drivers/clocksource/exynos_mct.c | 8 +++-
drivers/irqchip/exynos-combiner.c | 12 +++-
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3f7714d..7f88896 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1080,7 +1080,7 @@ source arch/arm/mm/Kconfig
config ARM_NR_BANKS
int
- default 16 if ARCH_EP93XX
+ default 16 if ARCH_EP93XX || ARCH_EXYNOS
Could you explain why this is needed, please?
default 8
config IWMMXT
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 2009266..f2f5df1 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -363,8 +363,15 @@ int notrace __cci_control_port_by_index(u32 port,
bool enable) * interface (ie cci_disable_port_by_cpu(); control by
general purpose * indexing is therefore disabled for ACE ports.
*/
+
+ /*
+ * Using this way to enable cci_port on EXYNOS5410 SoC
+ */
+
+#ifndef CONFIG_SOC_EXYNOS5410
if (ports[port].type == ACE_PORT)
return -EPERM;
+#endif
Huh? Could you explain a) why this is needed b) why this can't be detected
at runtime? Any new code being added must be ready for multiplatform
builds and this clearly isn't.
I'd recommend extending the CCI binding with a boolean property that makes
the driver bypass this check, but I'd like to see an answer to question a)
first.
cci_port_control(port, enable);
return 0;
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c index 5b34768..33884d7 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -71,6 +71,12 @@ enum {
MCT_L1_IRQ,
MCT_L2_IRQ,
MCT_L3_IRQ,
+#ifdef CONFIG_ARM_CCI
+ MCT_L4_IRQ,
+ MCT_L5_IRQ,
+ MCT_L6_IRQ,
+ MCT_L7_IRQ,
+#endif
The above change is not required as patches are already submitted to
boot all eight cores, which include this change also.
This #ifdef is useless.
Basically this whole enum is, as it is a remnant of legacy non-DT support,
but it is a material for separate patch.
MCT_NR_IRQS,
};
@@ -406,7 +412,7 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt) mevt = container_of(evt, struct
mct_clock_event_device, evt);
mevt-base = EXYNOS4_MCT_L_BASE(cpu);
- sprintf(mevt-name, mct_tick%d, cpu);
+ snprintf(mevt-name, 10, mct_tick%d, cpu);
Is this really necessary to enable EXYNOS5410 support?
evt-name = mevt-name;
evt-cpumask = cpumask_of(cpu);
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c index 868ed40..2e056fc 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -18,6 +18,7 @@
#include linux/of_address.h
#include linux/of_irq.h
#include asm/mach/irq.h
+#include plat/cpu.h
#include irqchip.h
@@ -66,6 +67,11 @@ static void combiner_handle_cascade_irq(unsigned int
irq, struct irq_desc *desc) struct irq_chip *chip = irq_get_chip(irq);
unsigned int cascade_irq, combiner_irq;
unsigned long status;
+ if (unlikely(!chip || !chip_data)) {
+ printk_once(KERN_ALERT %s: Chip not found for IRQ %d\n
+ , __func__, irq);
+ return;
+ }
What is the reason for this change?
chained_irq_enter(chip, desc);
@@ -226,7 +232,11 @@ static int __init combiner_of_init(struct
device_node *np, * get their IRQ from DT, remove this in order to get
dynamic * allocation.
*/
- irq_base = 160;
+
+ if (soc_is_exynos5410())
+ irq_base = 256;
+ else
+ irq_base = 160;
combiner_init(combiner_base, np, max_nr, irq_base);
There was a patch floating on the ML, possibly already merged, removing
static IRQ base assignment for combiner (which is a remnant of legacy non-
DT support) and moving the driver to normal linear IRQ domain. That patch
is what you need instead of this change.
That's right Tomasz. Patch is already merged.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
with warm regards,
Chander Kashyap
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the
Re: [PATCH v3 2/2] arm: dt: Exynos5420: populate cpu node enteries to 8 cpus
Hi Kukgin, On 6 September 2013 00:52, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 09/05/2013 01:29 PM, Chander Kashyap wrote: Exynos5420 is octacore SoC from samsung. s/octacore/octa-core ? s/samsung/Samsung Hence populate all the cpu node enteries. s/cpu/CPU ? s/enteries/entries Signed-off-by: Chander Kashyapchander.kash...@linaro.org Subjects of the dts patches normally start with ARM: dts:. I guess this all could be corrected while the patch is being applied to the platform maitainter's tree. Shall i send a version or you will take these. -- Thanks, Sylwester -- with warm regards, Chander Kashyap -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Enable all cpus in Exynos5420
On 5 September 2013 16:59, Chander Kashyap chander.kash...@linaro.org wrote: Exynos5420 is an octacore SoC. This patch series enables the remaining 4 cores. Changes in v2: - Changed the cpu node @unit-address value to reg property value. Changes in v3: - Removed leading 0x from @unit-address value. Chander Kashyap (2): clocksource: mct: extend mct to support 8 local interrupts for Exynos5420 arm: dt: Exynos5420: populate cpu node enteries to 8 cpus arch/arm/boot/dts/exynos5420.dtsi | 37 +++-- drivers/clocksource/exynos_mct.c |4 2 files changed, 39 insertions(+), 2 deletions(-) -- 1.7.9.5 Hi Kukjin, can you please take these patches. -- with warm regards, Chander Kashyap -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ahci: exynos: add ahci sata support on Exynos platform
Hi,
On Tuesday, October 01, 2013 12:03:01 PM Yuvaraj Kumar C D wrote:
Exynos5250 contains one Synopsys AHCI SATA controller.The avalaible
ahci_platform driver is not sufficient to handle the AHCI PHY and PHY
clock related initialization.
This patch adds exynos specific ahci sata driver,contained the exynos
specific initialized codes, re-use the generic ahci_platform driver, and
keep the generic ahci_platform driver clean as much as possible.
This patch depends on the below patch
[1].drivers: phy: add generic PHY framework
by Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/ata/Kconfig |9 ++
drivers/ata/Makefile |1 +
drivers/ata/ahci_exynos.c | 226
+
3 files changed, 236 insertions(+)
create mode 100644 drivers/ata/ahci_exynos.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 4e73772..99b2392 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -106,6 +106,15 @@ config AHCI_IMX
If unsure, say N.
+config AHCI_EXYNOS
+ tristate Samsung Exynos AHCI SATA support
+ depends on SATA_AHCI_PLATFORM
This should also depend on SOC_EXYNOS5250.
+ help
+ This option enables support for the Samsung's Exynos SoC's
+ onboard AHCI SATA.
+
+ If unsure, say N.
+
config SATA_FSL
tristate Freescale 3.0Gbps SATA support
depends on FSL_SOC
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 46518c6..0e1f420f 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SATA_SIL24)+= sata_sil24.o
obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
obj-$(CONFIG_SATA_HIGHBANK) += sata_highbank.o libahci.o
obj-$(CONFIG_AHCI_IMX) += ahci_imx.o
+obj-$(CONFIG_AHCI_EXYNOS)+= ahci_exynos.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/ahci_exynos.c b/drivers/ata/ahci_exynos.c
new file mode 100644
index 000..7f0af00
--- /dev/null
+++ b/drivers/ata/ahci_exynos.c
@@ -0,0 +1,226 @@
+/*
+ * Samsung AHCI SATA platform driver
+ * Copyright 2013 Samsung Electronics Co., Ltd.
+ *
+ * based on the AHCI SATA platform driver by Jeff Garzik and Anton Vorontsov
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/i2c.h
This include doesn't seem to be needed.
+#include linux/io.h
+#include linux/ahci_platform.h
+#include linux/of_device.h
+#include linux/phy/phy.h
+#include ahci.h
+
+#define MHZ (1000 * 1000)
+
+struct exynos_ahci_priv {
+ struct platform_device *ahci_pdev;
+ struct clk *sclk;
+ unsigned int freq;
+ struct phy *phy;
+};
+
+static int exynos_sata_init(struct device *dev, void __iomem *mmio)
+{
+ struct exynos_ahci_priv *priv = dev_get_drvdata(dev-parent);
+ int ret;
+
+ priv-phy = devm_phy_get(dev , sata-phy);
+ if (IS_ERR(priv-phy))
+ return PTR_ERR(priv-phy);
This should happen in -probe (exynos_sata_init() is also called in
exynos_sata_resume() so the above code will be executed on every
resume operation which is incorrect).
Also please take a look at the following patch:
https://lkml.org/lkml/2013/9/19/173
it adds PHY support to ahci_platform driver, maybe it can be used
for your needs as well.
+ ret = phy_init(priv-phy);
+ if (ret 0) {
+ dev_err(dev, failed to init SATA PHY\n);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(priv-sclk);
+ if (ret 0) {
+ dev_err(dev, failed to enable source clk\n);
+ return ret;
+ }
+
+ ret = clk_set_rate(priv-sclk, priv-freq * MHZ);
+ if (ret 0) {
+ dev_err(dev, failed to set clk frequency\n);
+ clk_disable_unprepare(priv-sclk);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void exynos_sata_exit(struct device *dev)
+{
+ struct exynos_ahci_priv *priv = dev_get_drvdata(dev-parent);
+ if (!IS_ERR(priv-sclk))
+ clk_disable_unprepare(priv-sclk);
+}
+
+static int exynos_sata_suspend(struct device *dev)
+{
+ struct exynos_ahci_priv *priv =
Re: [PATCH 3/3] thermal: samsung: Add TMU support for Exynos5420 SoCs
On 4 September 2013 09:53, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
This patch adds the neccessary register changes and arch information
to support Exynos5420 SoCs
Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
Also updated the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Note: The platform data structure will be handled properly once the driver
moves to complete device driver solution.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v1:
1. modified the platform data structure in order to pass SHARED flag
for channels that need sharing of address space.
2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
As the changes are minimum and can be added here.
.../devicetree/bindings/thermal/exynos-thermal.txt | 39 ++
drivers/thermal/samsung/exynos_tmu.c | 14 ++-
drivers/thermal/samsung/exynos_tmu.h |1 +
drivers/thermal/samsung/exynos_tmu_data.c | 130
drivers/thermal/samsung/exynos_tmu_data.h |7 ++
5 files changed, 189 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..d70f2a4 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -7,12 +7,23 @@
samsung,exynos4210-tmu
samsung,exynos5250-tmu
samsung,exynos5440-tmu
+ samsung,exynos5420-tmu
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
+ The misplaced register address is passed through devicetree as the
+ second base
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +54,34 @@ Example 2):
clock-names = tmu_apbif;
};
+Example 3): (In case of Exynos5420)
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x10068000 0x100, 0x1006c000 0x4;
+ interrupts = 0 184 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x1006c000 0x100, 0x100a 0x4;
+ interrupts = 0 185 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x100a 0x100, 0x10068000 0x4;
+ interrupts = 0 215 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in aliases node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 3a55caf..6d34652 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
}
} else {
- trim_info = readl(data-base + reg-triminfo_data);
+ /* On exynos5420 the triminfo register is in the shared space
*/
+ if (data-base_second (data-soc == SOC_ARCH_EXYNOS5420))
+ trim_info = readl(data-base_second +
+ reg-triminfo_data);
+ else
+ trim_info = readl(data-base + reg-triminfo_data);
}
data-temp_error1 = trim_info EXYNOS_TMU_TEMP_MASK;
data-temp_error2 = ((trim_info reg-triminfo_85_shift)
@@ -499,6 +504,10 @@ static const struct of_device_id exynos_tmu_match[] = {
.compatible = samsung,exynos5440-tmu,
.data = (void *)EXYNOS5440_TMU_DRV_DATA,
},
+ {
+ .compatible =
Re: [PATCH 3/3] thermal: samsung: Add TMU support for Exynos5420 SoCs
Hi,
I would like to see few minor cleanup changes, please see below:
On Thursday, October 03, 2013 05:31:42 PM Naveen Krishna Ch wrote:
On 4 September 2013 09:53, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
This patch adds the neccessary register changes and arch information
to support Exynos5420 SoCs
Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
Also updated the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Note: The platform data structure will be handled properly once the driver
moves to complete device driver solution.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v1:
1. modified the platform data structure in order to pass SHARED flag
for channels that need sharing of address space.
2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
As the changes are minimum and can be added here.
.../devicetree/bindings/thermal/exynos-thermal.txt | 39 ++
drivers/thermal/samsung/exynos_tmu.c | 14 ++-
drivers/thermal/samsung/exynos_tmu.h |1 +
drivers/thermal/samsung/exynos_tmu_data.c | 130
drivers/thermal/samsung/exynos_tmu_data.h |7 ++
5 files changed, 189 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..d70f2a4 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -7,12 +7,23 @@
samsung,exynos4210-tmu
samsung,exynos5250-tmu
samsung,exynos5440-tmu
+ samsung,exynos5420-tmu
it should come before samsung,exynos5440-tmu
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has
multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
+ The misplaced register address is passed through devicetree as the
+ second base
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +54,34 @@ Example 2):
clock-names = tmu_apbif;
};
+Example 3): (In case of Exynos5420)
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x10068000 0x100, 0x1006c000 0x4;
+ interrupts = 0 184 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x1006c000 0x100, 0x100a 0x4;
+ interrupts = 0 185 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x100a 0x100, 0x10068000 0x4;
+ interrupts = 0 215 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in aliases node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 3a55caf..6d34652 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
}
} else {
- trim_info = readl(data-base + reg-triminfo_data);
+ /* On exynos5420 the triminfo register is in the shared
space */
+ if (data-base_second (data-soc == SOC_ARCH_EXYNOS5420))
+ trim_info = readl(data-base_second +
+ reg-triminfo_data);
+ else
+ trim_info = readl(data-base + reg-triminfo_data);
}
data-temp_error1 = trim_info EXYNOS_TMU_TEMP_MASK;
Re: [PATCH 0/6] thermal: exynos: Fixes for v3.12
Dear All, This patch series is divided into two parts: 1. Device tree node definition and enabelement for TMU at Exynos4412 (Trats2) 2. Exynos thermal subsystem regressions for v3.12-rc1. Several commits were necessary to properly fix regression for TMU test MUX address setting after reset. Zhang or Eduardo - will you find time to review those changes? They have already been reviewed by Amit. Now we have -rc3 and there is no feedback for regression/critical patches (posted for -rc1). Test HW: - Exynos4412 - TRATS2 board (Linux v3.12-rc1) Lukasz Majewski (6): thermal: exynos: fix: Return from exynos_report_trigger() when therm_dev is NULL thermal: exynos: Provide separate TMU data for Exynos4412 thermal: exynos: Provide initial setting for TMU's test MUX address at Exynos4412 thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250 ARM: dts: exynos4x12: Device tree node definition for TMU on Exynos4x12 ARM: dts: exynos4412-trats2: Enable TMU support at Trats2 arch/arm/boot/dts/exynos4412-trats2.dts |5 + arch/arm/boot/dts/exynos4x12.dtsi | 10 + drivers/thermal/samsung/exynos_thermal_common.c |2 +- drivers/thermal/samsung/exynos_tmu.c| 12 +++ drivers/thermal/samsung/exynos_tmu.h|3 ++- drivers/thermal/samsung/exynos_tmu_data.c | 26 +-- drivers/thermal/samsung/exynos_tmu_data.h | 13 +++- 7 files changed, 58 insertions(+), 13 deletions(-) -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+
+#include drmP.h
+#include drm_edid.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+#include bridge/ptn3460.h
+
+#define PTN3460_EDID_ADDR 0x0
+#define PTN3460_EDID_EMULATION_ADDR0x84
+#define PTN3460_EDID_ENABLE_EMULATION 0
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge? Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
Thanks,
Inki Dae
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(ptn3460-bridge, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
___
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
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+
+#include drmP.h
+#include drm_edid.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+#include bridge/ptn3460.h
+
+#define PTN3460_EDID_ADDR 0x0
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae inki@samsung.com wrote:
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge?
The problem doing something like this is that we won't have a handle
to drm_device if it's just a standalone driver, and so we won't be
able to register the bridge or connector. We need this init call one
way or another.
Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
No, this isn't what I want to do. The bridge should not hang off fimd
since it's a crtc. The bridge should only be initialized by the DP
driver (it doesn't make sense to initialize ptn when you're using
MIPI/LVDS/whatever).
Since the actual crtc/encoder drivers are abstracted through
exynos_drm_core/crtc/encoder, we need to initialize the ptn driver in
the abstraction layers in order to hook it directly into drm.
Sean
Thanks,
Inki Dae
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(ptn3460-bridge, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
___
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
Re: [PATCH 2/5] ARM: dts: Add dp-controller node to exynos5250-snow
On Wed, Oct 2, 2013 at 5:10 PM, Olof Johansson o...@lixom.net wrote:
On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul seanp...@chromium.org wrote:
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index e5af3f2..780511a 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -190,6 +190,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ dp-controller {
+ samsung,color-space = 0;
+ samsung,dynamic-range = 0;
+ samsung,ycbcr-coeff = 0;
+ samsung,color-depth = 1;
+ samsung,link-rate = 0x0a;
+ samsung,lane-count = 2;
+
+ pinctrl-names = default;
+ pinctrl-0 = dp_hpd;
+ };
This won't actually do what I think you want. Since the dtsi has the
node name dp-controller@145B, you will end up duplicating a new
node and not build on top of that one.
Thanks, Olof. I based this off Inki's exynos-drm-next tree which does
not have the latest from arm-soc, I'll re-upload.
Sean
There's two ways to do it: Always include the unit address, or create
a label in the dtsi such that:
dp_controller: dp-controller@ {
}
Then in your dts you can, at the root level:
dp_controller {
... new stuff and overrides ...
};
-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae inki@samsung.com wrote:
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge?
The problem doing something like this is that we won't have a handle
to drm_device if it's just a standalone driver, and so we won't be
able to register the bridge or connector. We need this init call one
way or another.
At least, dt binding shoul be done in real device driver so this way
is not good. Let's find a better way.
Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
No, this isn't what I want to do. The bridge should not hang off fimd
since it's a crtc. The bridge should only be initialized by the DP
driver (it doesn't make sense to initialize ptn when you're using
MIPI/LVDS/whatever).
I don't mean that the bridge device should be initialized by fimd
directly but the fimd driver provides just interfaces abstracted to
control the bridge device. And basically, the exynos_drm_display_ops
shouldn't be in fimd driver but in real connector driver; i.e. lcd
panel or LVDS driver. The reason I placed the exynos_drm_display_ops
in fimd driver is that lcd panel driver is controlled by lcd class
depended on Linux framebuffer, and I thought the panel driver should
be shared with drm driver in case of ARM SoC. The
exynos_drm_display_ops should be moved into right place if something
better exists some time or other.
So how can the DP driver control the bridge device as of now? the DP
you mentioned would be eDP, and the eDP driver is placed in
drivers/video/exynos/, and also MIPI-DSI driver.
Since the actual crtc/encoder drivers are abstracted through
exynos_drm_core/crtc/encoder, we need to initialize the ptn driver in
the abstraction layers in order to hook it directly into drm.
Sean
Thanks,
Inki Dae
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(ptn3460-bridge, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client,
bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
On Thu, Oct 3, 2013 at 1:18 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae inki@samsung.com wrote:
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge?
The problem doing something like this is that we won't have a handle
to drm_device if it's just a standalone driver, and so we won't be
able to register the bridge or connector. We need this init call one
way or another.
At least, dt binding shoul be done in real device driver so this way
is not good. Let's find a better way.
Right, so this is kind of tricky. If you do it in a real device
driver, you end up parsing the dt stuff in the probe, and then racing
the init callback. I figured it would be best just to do everything in
one place without races.
Hopefully I'm just missing a good way to solve this problem, any concrete ideas?
Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
No, this isn't what I want to do. The bridge should not hang off fimd
since it's a crtc. The bridge should only be initialized by the DP
driver (it doesn't make sense to initialize ptn when you're using
MIPI/LVDS/whatever).
I don't mean that the bridge device should be initialized by fimd
directly but the fimd driver provides just interfaces abstracted to
control the bridge device. And basically, the exynos_drm_display_ops
shouldn't be in fimd driver but in real connector driver; i.e. lcd
panel or LVDS driver. The reason I placed the exynos_drm_display_ops
in fimd driver is that lcd panel driver is controlled by lcd class
depended on Linux framebuffer, and I thought the panel driver should
be shared with drm driver in case of ARM SoC. The
exynos_drm_display_ops should be moved into right place if something
better exists some time or other.
So how can the DP driver control the bridge device as of now? the DP
you mentioned would be eDP, and the eDP driver is placed in
drivers/video/exynos/, and also MIPI-DSI driver.
It can't. The DP driver just operates on its own and display either
comes up or it doesn't depending on whether fimd happens to be
initialized first. As I mentioned earlier, I have a patch set which
moves DP driver into drm/exynos and removes the display_ops from fimd.
That will fix this issue.
Sean
Since the actual crtc/encoder drivers are abstracted through
exynos_drm_core/crtc/encoder, we need to initialize the ptn driver in
the abstraction layers in order to hook it directly into drm.
Sean
Thanks,
Inki Dae
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
On Thu, Oct 3, 2013 at 10:39 AM, Inki Dae inki@samsung.com wrote: 2013/10/3 Sean Paul seanp...@chromium.org: On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote: Can a regulator be used instead of gpio in other board case? No, not to my knowledge. Hm.. plz check it out again. the gpio pin is specific to board, and the the gpio be used as power source trigger could be replaced with a regulator according to board design. So you should consider all possibilities even though there are no other cases yet: other board could use a regulator instead. Take a look at the data sheet, it is publicly available. PD_N is not a power supply input, so modelling it as a regulator makes no sense: If PD_N is LOW, then the device is in Deep power-down completely, even if supply rail is ON; for the device to be able to operate, the PD_N pin must be HIGH. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:18 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae inki@samsung.com wrote:
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge?
The problem doing something like this is that we won't have a handle
to drm_device if it's just a standalone driver, and so we won't be
able to register the bridge or connector. We need this init call one
way or another.
At least, dt binding shoul be done in real device driver so this way
is not good. Let's find a better way.
Right, so this is kind of tricky. If you do it in a real device
driver, you end up parsing the dt stuff in the probe, and then racing
the init callback. I figured it would be best just to do everything in
one place without races.
Hopefully I'm just missing a good way to solve this problem, any concrete
ideas?
Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
No, this isn't what I want to do. The bridge should not hang off fimd
since it's a crtc. The bridge should only be initialized by the DP
driver (it doesn't make sense to initialize ptn when you're using
MIPI/LVDS/whatever).
I don't mean that the bridge device should be initialized by fimd
directly but the fimd driver provides just interfaces abstracted to
control the bridge device. And basically, the exynos_drm_display_ops
shouldn't be in fimd driver but in real connector driver; i.e. lcd
panel or LVDS driver. The reason I placed the exynos_drm_display_ops
in fimd driver is that lcd panel driver is controlled by lcd class
depended on Linux framebuffer, and I thought the panel driver should
be shared with drm driver in case of ARM SoC. The
exynos_drm_display_ops should be moved into right place if something
better exists some time or other.
So how can the DP driver control the bridge device as of now? the DP
you mentioned would be eDP, and the eDP driver is placed in
drivers/video/exynos/, and also MIPI-DSI driver.
It can't. The DP driver just operates on its own and display either
comes up or it doesn't depending on whether fimd happens to be
initialized first.
Ok, I don't know the DP hardware well. But, MIPI-DSI driver is
depending on fimd on/off ordering. ie. to enable display hw pipe, the
ordering should be FIMDMIPI-DSI-LCD because initial commands
_cannot be set_ to lcd panel if fimd is off. And to disable that, the
ordering should be LCD---MIPI-DSI---FIMD in same reason: to
get lcd panel off, off commands should be set to lcd panel. In similar
reason, I had posted FB_EARLY_EVENT_BLANK feature to mainline and that
have been merged.
As I mentioned earlier, I have a patch set which
moves DP driver into
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig
b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig
b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
On Thu, Oct 3, 2013 at 2:23 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig
b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it
looking for loan
Do you have a firm or company that need loan to start up a business or need,personal loan, Debt consolidation? For more information,Contact us now for a guarantee loan with low interest rate. We will provide you with loan to meet your needs. For more information contact us with the following information's. Full name: country: Address: Phone Number: Amount needed: Duration of loan: sg.loan...@outlook.com Kind regards -- 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/6] thermal: exynos: fix: Return from exynos_report_trigger() when therm_dev is NULL
On 24-09-2013 04:08, Lukasz Majewski wrote:
The commit 4de0bdaa9677d11406c9becb70c60887c957e1f0
(thermal: exynos: Add support for instance based register/unregister)
broke check for presence of therm_dev at global thermal zone in
exynos_report_trigger().
The resulting wrong test prevents thermal_zone_device_update() call, which
calls handlers for situation when trip points are passed.
Such behavior prevents thermal driver from proper reaction (when TMU interrupt
is raised) in a situation when overheating is detected at TMU hardware.
This patch fixes it.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
drivers/thermal/samsung/exynos_thermal_common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
index f10a6ad..55a912a 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -310,7 +310,7 @@ void exynos_report_trigger(struct thermal_sensor_conf
*conf)
}
th_zone = conf-pzone_data;
- if (th_zone-therm_dev)
+ if (!th_zone-therm_dev)
Fine with this fix, as it really looks obvious. But after reading the
code a bit, I am considering if we can remove the above check at all.
Reading the driver code piece at drivers/thermal/samsung/exynos_tmu.c,
by checking how exynos_register_thermal gets called, and how error is
handled, I assume we do not need to check for th_zone-therm_dev.
To me looks like the driver only allows th_zone's exist only with valid
therm_dev, isn't it? Except for the probe sequence, maybe, at run time
there is a time window that we have valid th_zone with invalid
therm_dev. However, reading the probe, still, the irq gets initialized
only in very end, so the work queue don't get queue till then at least.
So, my question before acking is, shall we remove this check altogether?
return;
if (th_zone-bind == false) {
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/6] thermal: exynos: Provide separate TMU data for Exynos4412
Lukasz,
Just minor comments.
On 24-09-2013 04:08, Lukasz Majewski wrote:
Up till now Exynos5250 and Exynos4412 had the same definitions for TMU
data. Following commit changes that, by introducing separate
exynos4412_default_tmu_data structure.
Since Exynos4412 was chronologically first, the corresponding name for
TMU registers and default data was renamed.
Additionally, new SOC_ARCH_EXYNOS4412 type has been defined.
It is not clear the objective of the patch itself. Was it just to make
the code more readable or are you fixing something?
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c |7 ---
drivers/thermal/samsung/exynos_tmu.h |1 +
drivers/thermal/samsung/exynos_tmu_data.c | 26 --
drivers/thermal/samsung/exynos_tmu_data.h |9 -
4 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index b43afda..a858cc4 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -488,7 +488,7 @@ static const struct of_device_id exynos_tmu_match[] = {
},
{
.compatible = samsung,exynos4412-tmu,
- .data = (void *)EXYNOS5250_TMU_DRV_DATA,
+ .data = (void *)EXYNOS4412_TMU_DRV_DATA,
},
{
.compatible = samsung,exynos5250-tmu,
@@ -630,8 +630,9 @@ static int exynos_tmu_probe(struct platform_device *pdev)
return ret;
if (pdata-type == SOC_ARCH_EXYNOS ||
- pdata-type == SOC_ARCH_EXYNOS4210 ||
- pdata-type == SOC_ARCH_EXYNOS5440)
+ pdata-type == SOC_ARCH_EXYNOS4210 ||
+ pdata-type == SOC_ARCH_EXYNOS4412 ||
+ pdata-type == SOC_ARCH_EXYNOS5440)
data-soc = pdata-type;
else {
ret = -EINVAL;
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index b364c9e..db37df0 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -41,6 +41,7 @@ enum calibration_mode {
enum soc_type {
SOC_ARCH_EXYNOS4210 = 1,
+ SOC_ARCH_EXYNOS4412,
SOC_ARCH_EXYNOS,
SOC_ARCH_EXYNOS5440,
};
I believe the above enum needs some documentation. SOC_ARCH_EXYNOS seams
to be a bit confusing.
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 9002499..bd08093 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -90,8 +90,8 @@ struct exynos_tmu_init_data const
exynos4210_default_tmu_data = {
};
#endif
-#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
-static const struct exynos_tmu_registers exynos5250_tmu_registers = {
+#if defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
+static const struct exynos_tmu_registers exynos4412_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
.triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
.triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
@@ -128,7 +128,7 @@ static const struct exynos_tmu_registers
exynos5250_tmu_registers = {
.emul_time_mask = EXYNOS_EMUL_TIME_MASK,
};
-#define EXYNOS5250_TMU_DATA \
+#define EXYNOS4412_TMU_DATA \
.threshold_falling = 10, \
.trigger_levels[0] = 85, \
.trigger_levels[1] = 103, \
@@ -162,15 +162,29 @@ static const struct exynos_tmu_registers
exynos5250_tmu_registers = {
.temp_level = 103, \
}, \
.freq_tab_count = 2, \
- .type = SOC_ARCH_EXYNOS, \
- .registers = exynos5250_tmu_registers, \
+ .registers = exynos4412_tmu_registers, \
.features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
TMU_SUPPORT_EMUL_TIME)
+#endif
+#if defined(CONFIG_SOC_EXYNOS4412)
+struct exynos_tmu_init_data const exynos4412_default_tmu_data = {
+ .tmu_data = {
+ { EXYNOS4412_TMU_DATA,
+ .type = SOC_ARCH_EXYNOS4412,
+ },
+ },
+ .tmu_count = 1,
+};
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250)
struct exynos_tmu_init_data const exynos5250_default_tmu_data = {
.tmu_data = {
- { EXYNOS5250_TMU_DATA },
+ { EXYNOS4412_TMU_DATA,
+ .type = SOC_ARCH_EXYNOS,
+ },
Please add a comment on this initialization, specially because we start
to mix macros with inline initialization. Starts to be hard to follow.
Besides, I believe
+ {
+ EXYNOS4412_TMU_DATA,
+ .type = SOC_ARCH_EXYNOS,
+
Re: [PATCH 3/6] thermal: exynos: Provide initial setting for TMU's test MUX address at Exynos4412
On 24-09-2013 04:08, Lukasz Majewski wrote:
The commit d0a0ce3e77c795258d47f9163e92d5031d0c5221 (thermal: exynos: Add
missing definations and code cleanup) has removed setting of test MUX address
value at TMU configuration setting.
This field is not present on Exynos4210 and Exynos5 SoCs. However on
Exynos4412
SoC it is required to set this field after reset because without it TMU shows
maximal available temperature, which causes immediate platform shutdown.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c |3 +++
drivers/thermal/samsung/exynos_tmu_data.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index a858cc4..21b89e4 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -317,6 +317,9 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
con = readl(data-base + reg-tmu_ctrl);
+ if (pdata-type == SOC_ARCH_EXYNOS4412)
+ con |= (EXYNOS4412_MUX_ADDR_VALUE EXYNOS4412_MUX_ADDR_SHIFT);
Amit has introduced a way to describe features instead of checking
features per type. It would be interesting to have a reasoning why not
to use it. Think what if new Exynos TMU versions come, are you guys
going to steadily increase the above check for type?
+
if (pdata-reference_voltage) {
con = ~(reg-buf_vref_sel_mask reg-buf_vref_sel_shift);
con |= pdata-reference_voltage reg-buf_vref_sel_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/thermal/samsung/exynos_tmu_data.h
index b130b1e..a1ea19d 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -95,6 +95,10 @@
#define EXYNOS_MAX_TRIGGER_PER_REG 4
+/* Exynos4412 specific */
+#define EXYNOS4412_MUX_ADDR_VALUE 6
+#define EXYNOS4412_MUX_ADDR_SHIFT 20
+
/*exynos5440 specific registers*/
#define EXYNOS5440_TMU_S0_7_TRIM 0x000
#define EXYNOS5440_TMU_S0_7_CTRL 0x020
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 4/6] thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250
On 24-09-2013 04:08, Lukasz Majewski wrote:
The TMU data definition is now separated to Exynos4412 and Exynos5250.
Now SOC_ARCH_EXYNOS only refers to Exynos5250. Hence the name
SOC_ARCH_EXYNOS has been changed to SOC_ARCH_EXYNOS5250.
How about merging this one with patch 02?
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c |4 ++--
drivers/thermal/samsung/exynos_tmu.h |2 +-
drivers/thermal/samsung/exynos_tmu_data.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 21b89e4..037cd46 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -632,9 +632,9 @@ static int exynos_tmu_probe(struct platform_device *pdev)
if (ret)
return ret;
- if (pdata-type == SOC_ARCH_EXYNOS ||
- pdata-type == SOC_ARCH_EXYNOS4210 ||
+ if (pdata-type == SOC_ARCH_EXYNOS4210 ||
pdata-type == SOC_ARCH_EXYNOS4412 ||
+ pdata-type == SOC_ARCH_EXYNOS5250 ||
pdata-type == SOC_ARCH_EXYNOS5440)
data-soc = pdata-type;
else {
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index db37df0..b42ece4 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -42,7 +42,7 @@ enum calibration_mode {
enum soc_type {
SOC_ARCH_EXYNOS4210 = 1,
SOC_ARCH_EXYNOS4412,
- SOC_ARCH_EXYNOS,
+ SOC_ARCH_EXYNOS5250,
SOC_ARCH_EXYNOS5440,
};
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index bd08093..188223f 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -183,7 +183,7 @@ struct exynos_tmu_init_data const
exynos4412_default_tmu_data = {
struct exynos_tmu_init_data const exynos5250_default_tmu_data = {
.tmu_data = {
{ EXYNOS4412_TMU_DATA,
- .type = SOC_ARCH_EXYNOS,
+ .type = SOC_ARCH_EXYNOS5250,
},
},
.tmu_count = 1,
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
[PATCH v2 3/5] drm/bridge: Add PTN3460 bridge driver
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed header definition to static inline
- Changed dt node name to lvds-bridge
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349 +
include/drm/bridge/ptn3460.h | 37 +++
7 files changed, 423 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..52b93b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460 bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ lvds-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+
+#include drmP.h
+#include drm_edid.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+#include bridge/ptn3460.h
+
+#define PTN3460_EDID_ADDR 0x0
+#define PTN3460_EDID_EMULATION_ADDR0x84
+#define PTN3460_EDID_ENABLE_EMULATION 0
+#define PTN3460_EDID_EMULATION_SELECTION 1
+#define PTN3460_EDID_SRAM_LOAD_ADDR0x85
+
+struct ptn3460_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+
[PATCH v2 0/5] Add some missing bits for exynos5250-snow
This set adds some missing devicetree nodes to the exynos5250-snow file as well as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in the exynos5250-snow board. Sean Sean Paul (5): ARM: dts: Add fimd display-timings for exynos5250-snow ARM: dts: Add dp-controller node to exynos5250-snow drm/bridge: Add PTN3460 bridge driver drm/exynos: Initialize ptn3460 if present ARM: dts: Add ptn3460 to exynos5250-snow Documentation/devicetree/bindings/drm/bridge/ptn3460.txt | 27 +++ arch/arm/boot/dts/exynos5250-snow.dts| 48 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/bridge/Kconfig | 4 + drivers/gpu/drm/bridge/Makefile | 3 + drivers/gpu/drm/bridge/ptn3460.c | 349 drivers/gpu/drm/exynos/exynos_drm_core.c | 44 - include/drm/bridge/ptn3460.h | 37 9 files changed, 514 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] ARM: dts: Add dp-controller node to exynos5250-snow
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: Added dp-controller address to node (rebased on linux-next)
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 2a0f0de..f1cf68e 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -186,6 +186,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ dp-controller@145B {
+ samsung,color-space = 0;
+ samsung,dynamic-range = 0;
+ samsung,ycbcr-coeff = 0;
+ samsung,color-depth = 1;
+ samsung,link-rate = 0x0a;
+ samsung,lane-count = 2;
+
+ pinctrl-names = default;
+ pinctrl-0 = dp_hpd;
+ };
+
fimd: fimd@1440 {
display-timings {
native-mode = lcd_timing;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] ARM: dts: Add ptn3460 to exynos5250-snow
This patch adds a node for the ptn3460 DP-LVDS chip in the
exynos5250-snow board dts file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: Changed node name to lvds-bridge
arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index f1cf68e..2870205 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -33,6 +33,13 @@
sd3_bus4: sd3-bus-width4 {
samsung,pin-drv = 0;
};
+
+ ptn3460_gpios: ptn3460-gpios {
+ samsung,pins = gpy2-5, gpx1-5;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
gpio-keys {
@@ -186,6 +193,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ i2c@12CD {
+ lvds-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 0;
+ reset-gpio = gpx1 5 0;
+ edid-emulation = 5;
+ pinctrl-names = default;
+ pinctrl-0 = ptn3460_gpios;
+ };
+ };
+
dp-controller@145B {
samsung,color-space = 0;
samsung,dynamic-range = 0;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44 +++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device *dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device *dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] ARM: dts: Add fimd display-timings for exynos5250-snow
This patch adds the internal panel timings to the exynos5250-snow board
dts file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: No difference
arch/arm/boot/dts/exynos5250-snow.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index fd711e2..2a0f0de 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -186,6 +186,23 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ fimd: fimd@1440 {
+ display-timings {
+ native-mode = lcd_timing;
+ lcd_timing: 1366x768 {
+ clock-frequency = 70589280;
+ hactive = 1366;
+ vactive = 768;
+ hfront-porch = 40;
+ hback-porch = 40;
+ hsync-len = 32;
+ vback-porch = 10;
+ vfront-porch = 12;
+ vsync-len = 6;
+ };
+ };
+ };
+
fixed-rate-clocks {
xxti {
compatible = samsung,clock-xxti;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Add some missing bits for exynos5250-snow
On Thu, Oct 3, 2013 at 3:28 PM, Sean Paul seanp...@chromium.org wrote: This set adds some missing devicetree nodes to the exynos5250-snow file as well as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in the exynos5250-snow board. Sean Series: Acked-by: Olof Johansson o...@lixom.net -Olof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ahci: exynos: add ahci sata support on Exynos platform
On Thursday, October 03, 2013 8:32 PM, Bartlomiej Zolnierkiewicz wrote:
On Tuesday, October 01, 2013 12:03:01 PM Yuvaraj Kumar C D wrote:
Exynos5250 contains one Synopsys AHCI SATA controller.The avalaible
ahci_platform driver is not sufficient to handle the AHCI PHY and PHY
clock related initialization.
This patch adds exynos specific ahci sata driver,contained the exynos
specific initialized codes, re-use the generic ahci_platform driver, and
keep the generic ahci_platform driver clean as much as possible.
This patch depends on the below patch
[1].drivers: phy: add generic PHY framework
by Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/ata/Kconfig |9 ++
drivers/ata/Makefile |1 +
drivers/ata/ahci_exynos.c | 226
+
3 files changed, 236 insertions(+)
create mode 100644 drivers/ata/ahci_exynos.c
[.]
+ priv-phy = devm_phy_get(dev , sata-phy);
+ if (IS_ERR(priv-phy))
+ return PTR_ERR(priv-phy);
[.]
Also please take a look at the following patch:
https://lkml.org/lkml/2013/9/19/173
it adds PHY support to ahci_platform driver, maybe it can be used
for your needs as well.
I also agree with Bartlomiej Zolnierkiewicz's opinion.
'ahci_exynos.c' just calls PHY API, without any additional control
for Exynos AHCI IP.
Best regards,
Jingoo Han
+ ret = phy_init(priv-phy);
+ if (ret 0) {
+ dev_err(dev, failed to init SATA PHY\n);
+ return ret;
+ }
+
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 2:23 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig
b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/4 Olof Johansson o...@lixom.net: On Thu, Oct 3, 2013 at 10:39 AM, Inki Dae inki@samsung.com wrote: 2013/10/3 Sean Paul seanp...@chromium.org: On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote: Can a regulator be used instead of gpio in other board case? No, not to my knowledge. Hm.. plz check it out again. the gpio pin is specific to board, and the the gpio be used as power source trigger could be replaced with a regulator according to board design. So you should consider all possibilities even though there are no other cases yet: other board could use a regulator instead. Take a look at the data sheet, it is publicly available. PD_N is not a power supply input, so modelling it as a regulator makes no sense: If PD_N is LOW, then the device is in Deep power-down completely, even if supply rail is ON; for the device to be able to operate, the PD_N pin must be HIGH. I still think the pin could be replaced with a regulator. But lvds-bridge node has powerdown-gpio property - it say this board will use gpio pin - specific to board. So it seems no problem. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/5] ARM: dts: Add fimd display-timings for exynos5250-snow
On Friday, October 04, 2013 7:28 AM, Sean Paul wrote:
This patch adds the internal panel timings to the exynos5250-snow board
dts file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: No difference
arch/arm/boot/dts/exynos5250-snow.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index fd711e2..2a0f0de 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -186,6 +186,23 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ fimd: fimd@1440 {
+ display-timings {
How about adding 'status = okay' as below?
fimd: fimd@1440 {
status = okay;
display-timings {
status of fimd node was disabled by exynos5.dtsi
./arch/arm/boot/dts/exynos5.dtsi
fimd@1440 {
status = disabled;
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] ARM: dts: Add dp-controller node to exynos5250-snow
On Friday, October 04, 2013 7:28 AM, Sean Paul wrote:
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: Added dp-controller address to node (rebased on linux-next)
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 2a0f0de..f1cf68e 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -186,6 +186,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ dp-controller@145B {
+ samsung,color-space = 0;
+ samsung,dynamic-range = 0;
+ samsung,ycbcr-coeff = 0;
+ samsung,color-depth = 1;
+ samsung,link-rate = 0x0a;
+ samsung,lane-count = 2;
+
+ pinctrl-names = default;
+ pinctrl-0 = dp_hpd;
How about adding 'status = okay as below?
pinctrl-names = default;
pinctrl-0 = dp_hpd;
status = okay;
status of dp node was disabled by exynos5.dtsi.
./arch/arm/boot/dts/exynos5.dtsi
dp-controller@145B {
status = disabled;
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
This is what I was explaining earlier today. If the bridge driver is
just an i2c driver, it won't get a pointer to drm_device, and can't
register itself as a drm_bridge or drm_connector. To solve this, you
need the ptn3460_init callback.
If it's an i2c driver with the ptn3460_init callback, where it parses
the dt in probe, then you have a race between the ptn probe and the
ptn init/drm hooks. ie: it's possible drm will initialize and call
disable/post_disable/pre_enable/enable before things have been probed.
To solve this, you need to use some global state and/or locking.
So, to summarize. We can have this of_find_compatible with a init
callback, or we can have an i2c driver + global state/locking + init
callback. I chose the former, since it seemed easier.
If you have a better way to achieve this, I'm definitely interested,
but I saw this as the lesser of two evils.
Sean
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.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
--
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] [media] s5p-mfc: Adjust the default values of some encoder params
The patch sets the default values of MAX_QP and GOP size encoder
parameters to some firmware recommended default values. This enables
the applications to get a better encoded output using the default
settings itself.
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 41f5a3c..4ff3b6c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -113,7 +113,7 @@ static struct mfc_control controls[] = {
.minimum = 0,
.maximum = (1 16) - 1,
.step = 1,
- .default_value = 0,
+ .default_value = 12,
},
{
.id = V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE,
@@ -356,7 +356,7 @@ static struct mfc_control controls[] = {
.minimum = 0,
.maximum = 51,
.step = 1,
- .default_value = 1,
+ .default_value = 51,
},
{
.id = V4L2_CID_MPEG_VIDEO_H264_P_FRAME_QP,
@@ -399,7 +399,7 @@ static struct mfc_control controls[] = {
.minimum = 1,
.maximum = 31,
.step = 1,
- .default_value = 1,
+ .default_value = 31,
},
{
.id = V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP,
@@ -444,7 +444,7 @@ static struct mfc_control controls[] = {
.minimum = 0,
.maximum = 51,
.step = 1,
- .default_value = 1,
+ .default_value = 51,
},
{
.id = V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
This is what I was explaining earlier today. If the bridge driver is
just an i2c driver, it won't get a pointer to drm_device, and can't
register itself as a drm_bridge or drm_connector. To solve this, you
need the ptn3460_init callback.
No, I think you can use sub driver. how about registering to exynos
drm core that driver using exynos_drm_subdrv_register function after
probed? Is there something I am missing?
If it's an i2c driver with the ptn3460_init callback, where it parses
the dt in probe, then you have a race between the ptn probe and the
ptn init/drm hooks. ie: it's possible drm will initialize and call
disable/post_disable/pre_enable/enable before things have been probed.
And also, exynos drm core will call a probe callback of the sub driver
after _drm is initialized_. Is there something I am missing?
To solve this, you need to use some global state and/or locking.
So, to summarize. We can have this of_find_compatible with a init
callback, or we can have an i2c driver + global state/locking + init
callback. I chose the former, since it seemed easier.
If you have a better way to achieve this, I'm definitely interested,
but I saw this as the lesser of two evils.
Sean
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client,
bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.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
--
To unsubscribe from this list: send the
[PATCH] [media] s5p-mfc: call wake_up_dev if in suspend mode
From: Prathyush K prathyus...@samsung.com
If a frame is still decoding when system enters suspend mode, we wait
on the device queue for a interrupt condition. This sometimes leads to a
timeout because the device queue might not be woken up everytime.
Usually, the context queue gets woken up when that context's frame gets
decoded. This patch adds a condition to wake up the device queue along
with the context queue when the system is in suspend mode.
Since the device queue is now woken up, we don't have to check the
context's int_cond flag while waiting. Also, we can skip calling try_run
after waking up the device queue to ensure that we don't have to wait
for more than one frame to be processed.
Signed-off-by: Prathyush K prathyus...@samsung.com
Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 084263d..bec0f61 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -404,7 +404,11 @@ leave_handle_frame:
if (test_and_clear_bit(0, dev-hw_lock) == 0)
BUG();
s5p_mfc_clock_off();
- s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
+ /* if suspending, wake up device and do not try_run again*/
+ if (test_bit(0, dev-enter_suspend))
+ wake_up_dev(dev, reason, err);
+ else
+ s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
}
/* Error handling for interrupt */
@@ -1286,9 +1290,7 @@ static int s5p_mfc_suspend(struct device *dev)
/* Try and lock the HW */
/* Wait on the interrupt waitqueue */
ret = wait_event_interruptible_timeout(m_dev-queue,
- m_dev-int_cond ||
m_dev-ctx[m_dev-curr_ctx]-int_cond,
- msecs_to_jiffies(MFC_INT_TIMEOUT));
-
+ m_dev-int_cond, msecs_to_jiffies(MFC_INT_TIMEOUT));
if (ret == 0) {
mfc_err(Waiting for hardware to finish timed out\n);
return -EIO;
--
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
