Re: [PATCH] drm/exynos: consider deferred probe case
Sorry for wrong patch version. Ignore this patch.
Thanks,
Inki Dae
On 2014년 05월 29일 18:27, Inki Dae wrote:
This patch makes sure that exynos drm framework handles deferred
probe case correctly.
Sub drivers could be probed before resources, clock, regulator,
phy or panel, are ready for them so we should make sure that exynos
drm core waits until all resources are ready and sub drivers are
probed correctly.
Chagelog v2:
- Make sure that exynos drm core tries to bind sub drivers only in case that
they have a pair: crtc and encoder/connector components should be a pair.
- Remove unnecessary patch:
drm/exynos: mipi-dsi: consider panel driver-deferred probe
- Return error type correctly.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 18 +++-
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 22 -
drivers/gpu/drm/exynos/exynos_drm_drv.c | 139
+-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 13 ++-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 41 ++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 51 ---
drivers/gpu/drm/exynos/exynos_hdmi.c | 78 -
drivers/gpu/drm/exynos/exynos_mixer.c| 17 +++-
8 files changed, 304 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index ff63901..a892586 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1328,12 +1328,26 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
- return exynos_drm_component_add(pdev-dev, exynos_dp_ops);
+ int ret;
+
+ ret = exynos_drm_component_add(pdev-dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
+ exynos_dp_display.type);
+ if (ret)
+ return ret;
+
+ ret = component_add(pdev-dev, exynos_dp_ops);
+ if (ret)
+ exynos_drm_component_del(pdev-dev,
+ EXYNOS_DEVICE_TYPE_CONNECTOR);
+
+ return ret;
}
static int exynos_dp_remove(struct platform_device *pdev)
{
- exynos_drm_component_del(pdev-dev, exynos_dp_ops);
+ component_del(pdev-dev, exynos_dp_ops);
+ exynos_drm_component_del(pdev-dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
+
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index a832364..f1b8587 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -295,9 +295,15 @@ struct exynos_drm_display *exynos_dpi_probe(struct
device *dev)
struct exynos_dpi *ctx;
int ret;
+ ret = exynos_drm_component_add(dev,
+ EXYNOS_DEVICE_TYPE_CONNECTOR,
+ exynos_dpi_display.type);
+ if (ret)
+ return ERR_PTR(ret);
+
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
- return NULL;
+ goto err_del_component;
ctx-dev = dev;
exynos_dpi_display.ctx = ctx;
@@ -306,16 +312,24 @@ struct exynos_drm_display *exynos_dpi_probe(struct
device *dev)
ret = exynos_dpi_parse_dt(ctx);
if (ret 0) {
devm_kfree(dev, ctx);
- return NULL;
+ goto err_del_component;
}
if (ctx-panel_node) {
ctx-panel = of_drm_find_panel(ctx-panel_node);
- if (!ctx-panel)
+ if (!ctx-panel) {
+ exynos_drm_component_del(dev,
+ EXYNOS_DEVICE_TYPE_CONNECTOR);
return ERR_PTR(-EPROBE_DEFER);
+ }
}
return exynos_dpi_display;
+
+err_del_component:
+ exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
+
+ return NULL;
}
int exynos_dpi_remove(struct device *dev)
@@ -327,5 +341,7 @@ int exynos_dpi_remove(struct device *dev)
encoder-funcs-destroy(encoder);
drm_connector_cleanup(ctx-connector);
+ exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
+
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index c5a401ae..72a5de1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -48,7 +48,10 @@ static LIST_HEAD(drm_component_list);
struct component_dev {
struct list_head list;
- struct device *dev;
+ struct device *crtc_dev;
+ struct device *conn_dev;
+ enum exynos_drm_output_type out_type;
+ unsigned int dev_type_flag;
};
static int exynos_drm_load(struct drm_device *dev, unsigned long flags)
@@ -382,22 +385,65 @@ static
[PATCH 0/2] drm/exynos: consider deferred probe case
This patch series includes the following two patches. One makes sure that exynos drm framework handles deferred probe case of sub drivers, and other makes sure that mipi dsi driver considers deferred probe incurred by panel driver. Inki Dae (2): drm/exynos: consider deferred probe feature drm/exynos: mipi-dsi: consider panel driver-deferred probe drivers/gpu/drm/exynos/exynos_dp_core.c | 16 ++- drivers/gpu/drm/exynos/exynos_drm_drv.c | 28 ++-- drivers/gpu/drm/exynos/exynos_drm_drv.h |7 +-- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 69 +++--- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 49 +++-- drivers/gpu/drm/exynos/exynos_hdmi.c | 62 +++ drivers/gpu/drm/exynos/exynos_mixer.c| 16 ++- 7 files changed, 170 insertions(+), 77 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drm/exynos: mipi-dsi: consider panel driver-deferred probe
This patch makes sure that mipi dsi driver makes it re-probe
in case that panel driver isn't probed yet.
For this, it checks if panel driver is probed or not before
component_add() is called.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 38 +++
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 1421d9b..22503f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1166,11 +1166,8 @@ exynos_dsi_detect(struct drm_connector *connector, bool
force)
{
struct exynos_dsi *dsi = connector_to_dsi(connector);
- if (!dsi-panel) {
- dsi-panel = of_drm_find_panel(dsi-panel_node);
- if (dsi-panel)
- drm_panel_attach(dsi-panel, dsi-connector);
- } else if (!dsi-panel_node) {
+/* Power off if panel driver is removed. */
+ if (!dsi-panel_node) {
struct exynos_drm_display *display;
display = platform_get_drvdata(to_platform_device(dsi-dev));
@@ -1383,19 +1380,8 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
void *data)
{
struct drm_device *drm_dev = data;
- struct exynos_dsi *dsi;
- int ret;
- ret = exynos_drm_create_enc_conn(drm_dev, exynos_dsi_display);
- if (ret) {
- DRM_ERROR(Encoder create [%d] failed with %d\n,
- exynos_dsi_display.type, ret);
- return ret;
- }
-
- dsi = exynos_dsi_display.ctx;
-
- return mipi_dsi_host_register(dsi-dsi_host);
+ return exynos_drm_create_enc_conn(drm_dev, exynos_dsi_display);
}
static void exynos_dsi_unbind(struct device *dev, struct device *master,
@@ -1406,8 +1392,6 @@ static void exynos_dsi_unbind(struct device *dev, struct
device *master,
exynos_dsi_dpms(exynos_dsi_display, DRM_MODE_DPMS_OFF);
- mipi_dsi_host_unregister(dsi-dsi_host);
-
encoder-funcs-destroy(encoder);
drm_connector_cleanup(dsi-connector);
}
@@ -1502,6 +1486,18 @@ static int exynos_dsi_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, exynos_dsi_display);
+ ret = mipi_dsi_host_register(dsi-dsi_host);
+ if (ret)
+ goto err_del_component;
+
+ dsi-panel = of_drm_find_panel(dsi-panel_node);
+ if (!dsi-panel) {
+ mipi_dsi_host_unregister(dsi-dsi_host);
+ return -EPROBE_DEFER;
+ }
+
+ drm_panel_attach(dsi-panel, dsi-connector);
+
ret = component_add(pdev-dev, exynos_dsi_component_ops);
if (ret)
goto err_del_component;
@@ -1515,6 +1511,10 @@ err_del_component:
static int exynos_dsi_remove(struct platform_device *pdev)
{
+ struct exynos_dsi *dsi = exynos_dsi_display.ctx;
+
+ mipi_dsi_host_unregister(dsi-dsi_host);
+
component_del(pdev-dev, exynos_dsi_component_ops);
exynos_drm_component_del(pdev-dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drm/exynos: consider deferred probe case
This patch makes sure that exynos drm framework handles deferred
probe case correctly.
Sub drivers could be probed before resources, clock, regulator,
phy or panel, are ready for them so we should make sure that exynos
drm core waits until all resources are ready and sub drivers are
probed correctly.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 16 +++-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 28 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h |7 +---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 31 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 49 +--
drivers/gpu/drm/exynos/exynos_hdmi.c | 62 ++
drivers/gpu/drm/exynos/exynos_mixer.c| 16 +++-
7 files changed, 151 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index ff63901..7526f36 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1328,12 +1328,24 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
- return exynos_drm_component_add(pdev-dev, exynos_dp_ops);
+ int ret;
+
+ ret = exynos_drm_component_add(pdev-dev);
+ if (ret)
+ return ret;
+
+ ret = component_add(pdev-dev, exynos_dp_ops);
+ if (ret)
+ exynos_drm_component_del(pdev-dev);
+
+ return ret;
}
static int exynos_dp_remove(struct platform_device *pdev)
{
- exynos_drm_component_del(pdev-dev, exynos_dp_ops);
+ component_del(pdev-dev, exynos_dp_ops);
+ exynos_drm_component_del(pdev-dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index c5a401ae..f611f5a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -381,22 +381,25 @@ static const struct dev_pm_ops exynos_drm_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_sys_suspend, exynos_drm_sys_resume)
};
-int exynos_drm_component_add(struct device *dev,
- const struct component_ops *ops)
+int exynos_drm_component_add(struct device *dev)
{
struct component_dev *cdev;
- int ret;
+
+ mutex_lock(drm_component_lock);
+
+ list_for_each_entry(cdev, drm_component_list, list) {
+ if (cdev-dev == dev) {
+ mutex_unlock(drm_component_lock);
+ return 0;
+ }
+ }
+
+ mutex_unlock(drm_component_lock);
cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
if (!cdev)
return -ENOMEM;
- ret = component_add(dev, ops);
- if (ret) {
- kfree(cdev);
- return ret;
- }
-
cdev-dev = dev;
mutex_lock(drm_component_lock);
@@ -406,8 +409,7 @@ int exynos_drm_component_add(struct device *dev,
return 0;
}
-void exynos_drm_component_del(struct device *dev,
- const struct component_ops *ops)
+void exynos_drm_component_del(struct device *dev)
{
struct component_dev *cdev, *next;
@@ -422,8 +424,6 @@ void exynos_drm_component_del(struct device *dev,
}
mutex_unlock(drm_component_lock);
-
- component_del(dev, ops);
}
static int compare_of(struct device *dev, void *data)
@@ -446,6 +446,8 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
ret = component_master_add_child(m, compare_of, cdev-dev);
if (!ret)
attached_cnt++;
+ else
+ return ret;
mutex_lock(drm_component_lock);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index e82e620..13480b2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -354,12 +354,9 @@ void exynos_drm_remove_vidi(void);
int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display);
-struct component_ops;
-int exynos_drm_component_add(struct device *dev,
- const struct component_ops *ops);
+int exynos_drm_component_add(struct device *dev);
-void exynos_drm_component_del(struct device *dev,
- const struct component_ops *ops);
+void exynos_drm_component_del(struct device *dev);
extern struct platform_driver fimd_driver;
extern struct platform_driver dp_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 84661fe..1421d9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
Re: [PATCH v5] drm/exynos: enable fimd clocks in probe before accessing fimd registers
On 2014년 05월 27일 18:55, Rahul Sharma wrote:
Gentle Reminder
On 26 May 2014 14:21, Rahul Sharma rahul.sha...@samsung.com wrote:
Hi Daniel,
On 26 May 2014 13:11, Daniel Kurtz djku...@chromium.org wrote:
On Mon, May 26, 2014 at 2:59 PM, Rahul Sharma rahul.sha...@samsung.com
wrote:
Hi Inki,
Please review this patch.
[snip]
+
+ ret = clk_prepare_enable(ctx-lcd_clk);
Hi Rahul,
Can you explain why exactly we are clearing windows here in probe(),
anyway?
I am not sure why it was added there but it is present since the first
version of this
file. Probably Inki can explain about this :). I can see the change
coming from his
first patch for adding drm fimd driver.
IIUC, bus_clk is the clock that enables FIMD register access, and
lcd_clk clocks the scan out engine.
Therefore, if we only need to read/write some registers, we only need
the bus_clk, not lcd_clk, right?
Correct, bus_clk should be sufficient to access the registers. But unless we
are confident about all implicit clock requirements in all SoCs, it is
safer to follow
the power_on/off sequence. This implementation is as good as DPMS on -
perform
reg operation - DPMS Off. It was same in the original version but
later clock enables
were moved out of the probe.
However, fimd_clear_win() actually clears per-window registers.
Writes to per-window registers typically do not take effect until the
next vblank.
Therefore we do would need to enable lcd_clk to ensure that these
changes take effect.
Furthermore, to ensure the window clear completes during probe(), we
would also need to synchronously wait for the next vblank here - but
only if FIMD scanout is actually enabled already, otherwise there will
never be a next scanout, so we must check for that first.
Lastly, waiting around for a vblank could take a while. Doing so in
probe() is not very friendly to boot up time, so the waiting should
probably be moved out of the main probe() thread into some sort of
asynchronous handler, which could then signal back when the clear is
complete.
Do you agree, or am I missing something?
I agree. There seems a room for improvement. But at present we have two
options,
either fix the current implementation and try to improve it as you mentioned
above. OR remove fimd_clear_win from probe if it is just a legacy code which
Just let's remove fimd_clear_win. it wouldn't need to disable all
hardware overlays at probe.
Thanks,
Inki Dae
is no more required.
@Inki, need your inputs here.
Regards,
Rahul Sharma.
Thanks,
-djk
+ if (ret) {
[snip]
+pm_put_err:
+ return ret;
}
static void fimd_unbind(struct device *dev, struct device *master,
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: Make exynos_drm_init() call late during the bootup
On 2014년 05월 26일 14:39, Naveen Krishna Ch wrote: Hello Everyone, On 21 May 2014 21:16, Thierry Reding thierry.red...@gmail.com wrote: On Wed, May 14, 2014 at 05:09:45PM +0530, Naveen Krishna Chatradhi wrote: exynos_drm_init() does probing of various drivers like dp_panel, hdmi, fimd, mixer, etc in an order and finally binds them together. Some of the drm devices (Eg: dp_panel) try to do regulator_get() and enable few supplies during their probe. Chances are that, these devices may get probed before the respective supply/PMIC is hooked. In such cases, dp_panel would continue with dummy regulator. Which is not what the system wants. Lets give the core connectivity and regulators modules some time to hookup the supplies before Exynos DRM devices comes into picture. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- This change is proposed after 1. Discussing with I2C/SPI DMA subsystem maintainers and Others @ https://lkml.org/lkml/2014/5/9/333 Trying to change the I2C, SPI and DMA drivers as subsys_initcall() Which was strictly opposed, as a flaw was found in DRM subsystem. 2. -EPROBE_DEFER won't work well with the current sequency of platform_driver_register()s in exynos_drm_init() Then this is the problem that you need to fix. If the driver doesn't handle -EPROBE_DEFER properly then that means the driver is broken. No amount of initcall ordering can fix this for you. We seem to have a problem with the probe sequencing and usage of _EPROBE_DEFER in DRM. Component way of registration doesnt seem to fix everything. Inki Dae, Is there any discussion or approach underway. Anyone working on this. Hi, I have just posted a patch series, [PATCH 0/2] drm/exynos: consider deferred probe case, to resolve that issue. With this, it wouldn't need your patch anymore. Thanks, Inki Dae Thierry -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/18] ARM: dts: s6e3fa0: add DT bindings
2014-05-27 16:53 GMT+09:00 Thierry Reding thierry.red...@gmail.com: On Tue, May 27, 2014 at 08:28:52AM +0200, Andrzej Hajda wrote: Hi Thierry, On 05/26/2014 03:41 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote: This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu mode timings. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt You're totally confusing me here. Half of this patch series is about adding i80 support to Exynos FIMD, and then you go and add what is apparently a DSI peripheral driver here that's supposed to be used by this new i80 support. Nothing I've been able to dig up indicates that i80 or DSI are in anyway related. FIMD can produce parallel RGB output or command mode in i80 style output via parallel lines. DSIM can accept parallel RGB stream in this case it produces MIPI DSI video mode signal or it can accept i80 and in this case it translates it to MIPI DSI command mode. Then the command mode timings aren't a property of the panel at all. Then the video mode timings aren't also a property of the panel. Which interface mipi and display controller should use would be decided by lcd panel type: display controller can use i80 interface based lcd panel, and also mipi controller can use i80 interface based lcd panel. In here, the only difference is that lcd panel receives packets, which includes video data or command data, packed with mipi protocol via lane lines or receives video data or command data via parallel lines. And the below is LCD types, RGB interface panel. i80 interface panel. MIPI based RGB interface panel. MIPI based i80 interface panel. RGB interface also is called video mode, and i80 interface also is called cpu mode. In case of omap SoC, it is also called Smart panel. i80 interface is just one of LCD types. So I think this interface timings should be handled by frameworks related to mode in same way as RGB interface. Thanks, Inki Dae They describe what DSIM expects, so that's where they should be defined. Thierry ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 13/18] ARM: dts: s6e3fa0: add DT bindings
On 2014년 05월 28일 05:21, Thierry Reding wrote: On Tue, May 27, 2014 at 11:24:49PM +0900, Inki Dae wrote: 2014-05-27 16:53 GMT+09:00 Thierry Reding thierry.red...@gmail.com: On Tue, May 27, 2014 at 08:28:52AM +0200, Andrzej Hajda wrote: Hi Thierry, On 05/26/2014 03:41 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote: This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu mode timings. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt You're totally confusing me here. Half of this patch series is about adding i80 support to Exynos FIMD, and then you go and add what is apparently a DSI peripheral driver here that's supposed to be used by this new i80 support. Nothing I've been able to dig up indicates that i80 or DSI are in anyway related. FIMD can produce parallel RGB output or command mode in i80 style output via parallel lines. DSIM can accept parallel RGB stream in this case it produces MIPI DSI video mode signal or it can accept i80 and in this case it translates it to MIPI DSI command mode. Then the command mode timings aren't a property of the panel at all. Then the video mode timings aren't also a property of the panel. Which interface mipi and display controller should use would be decided by lcd panel type: display controller can use i80 interface based lcd panel, and also mipi controller can use i80 interface based lcd panel. In here, the only difference is that lcd panel receives packets, which includes video data or command data, packed with mipi protocol via lane lines or receives video data or command data via parallel lines. And the below is LCD types, RGB interface panel. i80 interface panel. MIPI based RGB interface panel. MIPI based i80 interface panel. RGB interface also is called video mode, and i80 interface also is called cpu mode. In case of omap SoC, it is also called Smart panel. i80 interface is just one of LCD types. So I think this interface timings should be handled by frameworks related to mode in same way as RGB interface. LCD is a display technology, it has nothing to do with the interface. My point is that from Andrzej's description, and in fact from this patch series in general, the S6E3FA0 panel is a DSI panel. Associating timings that are i80 specific to it is therefore wrong. Consider for instance what would happen if somebody were to use the same panel on some other device (connected to a DSI controller). If you specify i80 timings for the panel then the new device won't know what to do with them because it expects DSI-related timings. Let me try to summarize the above to make sure we're all on the same page: - FIMD is a display controller that can be configured to either send RGB data or i80 data - DSIM takes either RGB as input and outputs DSI (video mode) or i80 as input and outputs DSI (command mode) In both cases the panel is connected to DSIM and it takes DSI as input, because it is a DSI panel (it doesn't understand RGB or i80). The panel needs to describe the properties of the DSI interface so that DSIM can be configured appropriately. DSIM in turn works as a bridge or encoder that converts RGB or i80 to DSI (video or command mode). So it makes no sense to describe the i80 timings for the panel because it has nothing to do with i80. Instead the DSIM is the hardware that needs to specify the i80 timings, so that FIMD can be configured to generate the timings that DSIM needs. CPU interface MIPI lane FIMD --- DSIM - LCD Panel Hmm... reasonable. So your point is that command mode timing should be placed in fimd device node, not panel device node? And panel device node should provide only a property that DSIM driver can set LCD mode properly to i80 or rgb interface mode, and also FIMD driver can set LCD mode to i80 or rgb interface mode. Is there my missing point? And in case of Exynos, now video timing property is also placed in panel device node so it needs to move to fimd device node. Andrzej, do you have other opinion? I have looked into dts files for other SoC and In most SoC, it seems that display controller node has video timing property, not panel node. Thierry's pointing seems reasonable to me. Thanks, Inki Dae Thierry -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: add fimd dependency to fimd related encoders
On 2014년 05월 23일 19:59, Andrzej Hajda wrote: DPI, DSI and DP drivers will not work without FIMD. The patch adds appropriate dependencies in Kconfig. Applied. Thanks, Inki Dae Signed-off-by: Andrzej Hajda a.ha...@samsung.com --- drivers/gpu/drm/exynos/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index e0d73fb..178d2a9 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -33,7 +33,7 @@ config DRM_EXYNOS_FIMD config DRM_EXYNOS_DPI bool EXYNOS DRM parallel output support - depends on DRM_EXYNOS + depends on DRM_EXYNOS_FIMD select DRM_PANEL default n help @@ -41,7 +41,7 @@ config DRM_EXYNOS_DPI config DRM_EXYNOS_DSI bool EXYNOS DRM MIPI-DSI driver support - depends on DRM_EXYNOS + depends on DRM_EXYNOS_FIMD select DRM_MIPI_DSI select DRM_PANEL default n @@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI config DRM_EXYNOS_DP bool EXYNOS DRM DP driver support - depends on DRM_EXYNOS ARCH_EXYNOS (DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS) + depends on DRM_EXYNOS_FIMD ARCH_EXYNOS (DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS) default DRM_EXYNOS help This enables support for DP device. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: remove redundant mutex_unlock
On 2014년 05월 23일 19:57, Andrzej Hajda wrote:
The patch fixes unlocking in exynos_drm_component_del.
Applied.
Thanks,
Inki Dae
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
Hi Inki,
This patch is based on exynos_drm_next branch.
Regards
Andrzej
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4cef88f..c5a401ae 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -417,7 +417,6 @@ void exynos_drm_component_del(struct device *dev,
if (dev == cdev-dev) {
list_del(cdev-list);
kfree(cdev);
- mutex_unlock(drm_component_lock);
break;
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: allocate non-contigous buffers when iommu is enabled
On 2014년 05월 22일 14:25, Rahul Sharma wrote:
Hi Inki,
The below fix doesn't affect the FB dev buffer allocation. IMO the scenario
where u-boot allocates the buffer is not disturbed.
Please review the implementation.
Applied.
Thanks,
Inki Dae
Regards,
Rahul Sharma.
On 7 May 2014 17:21, Rahul Sharma rahul.sha...@samsung.com wrote:
From: Rahul Sharma rahul.sha...@samsung.com
Allow to allocate non-contigous buffers when iommu is enabled.
Currently, it tries to allocates contigous buffer which consistently
fail for large buffers and then fall back to non contigous. Apart
from being slow, this implementation is also very noisy and fills
the screen with alloc fail logs.
Change-Id: I523e95aa308122ed2edc55e065ae6eb8be996541
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 5d88924..7136945 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -624,22 +624,20 @@ int exynos_drm_gem_dumb_create(struct drm_file
*file_priv,
args-pitch = args-width * ((args-bpp + 7) / 8);
args-size = args-pitch * args-height;
- exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
- EXYNOS_BO_WC, args-size);
- /*
-* If physically contiguous memory allocation fails and if IOMMU is
-* supported then try to get buffer from non physically contiguous
-* memory area.
-*/
- if (IS_ERR(exynos_gem_obj) is_drm_iommu_supported(dev)) {
- dev_warn(dev-dev, contiguous FB allocation failed, falling
back to non-contiguous\n);
+ if (is_drm_iommu_supported(dev)) {
+ exynos_gem_obj = exynos_drm_gem_create(dev,
+ EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
+ args-size);
+ } else {
exynos_gem_obj = exynos_drm_gem_create(dev,
- EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
- args-size);
+ EXYNOS_BO_CONTIG | EXYNOS_BO_WC,
+ args-size);
}
- if (IS_ERR(exynos_gem_obj))
+ if (IS_ERR(exynos_gem_obj)) {
+ dev_warn(dev-dev, FB allocation failed.\n);
return PTR_ERR(exynos_gem_obj);
+ }
ret = exynos_drm_gem_handle_create(exynos_gem_obj-base, file_priv,
args-handle);
--
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] drm/exynos: use 4WORD dma burst length for small fbs
On 2014년 05월 22일 13:36, Rahul Sharma wrote:
Hi Inki,
On 21 May 2014 16:43, Inki Dae inki@samsung.com wrote:
Hi Rahul,
On 2014년 05월 07일 20:25, Rahul Sharma wrote:
From: Rahul Sharma rahul.sha...@samsung.com
In case of exynos, setting dma-burst to 16Word causes permanent
tearing for very small buffers, e.g. cursor buffer. Burst Mode
switching, which is based on overlay size is not recommended as
overlay size varies a lot towards the end of the screen. This
causes unstable DMA which results into tearing again.
[snip]
+ /*
+ * In case of exynos, setting dma-burst to 16Word causes permanent
+ * tearing for very small buffers, e.g. cursor buffer. Burst Mode
+ * switching which is based on overlay size is not recommended as
+ * overlay size varies alot towards the end of the screen and rapid
+ * movement causes unstable DMA which results into iommu crash/tear.
FIMD has width limitation so width of hardware overlay may need to be
aligned to 16 pixels.
We had faced with similar issue and the issue had been resolved by
aligning it to 16 pixels.
So can you try to align it instead of changing burst len size?
This problem is only with the very small FBs which are
rendered towards corners. For large FBs like 1366x768,
we dont see this issue though 1366 is not 16 pixel
aligned.
Right, we had test it with 8x64 pixels. the limitation would be decided
by memory bus length(ML), DMA burst length(DL) and pixel size in bytes(PS).
And that can be calculated like below, which was guided by hardware team,
Align { (ML * DI / PS) + (4bytes / PS), 2}
It seems too big value. Actually, 16 pixels works well and I don't see
why it woks well although out of limitation.
Thanks,
Inki Dae
But I still carried out following experiments just to
verify the fimd behaviour for small overlay.
1) Round DOWN:
+ overlay-crtc_width = ((overlay-crtc_width)/16)*16;
Cursor corruption from A to B
A: [ 308.53] start addr = 0x20408000, end addr = 0x2040e000, size =
0x6000
[ 308.53] ovl_width = 64, ovl_height = 64
[ 308.54] offset_x = 1302, offset_y = 335
[ 308.54] fb_width = 96, fb_height = 64
B: [ 341.89] start addr = 0x20408000, end addr = 0x2040e000, size =
0x6000
[ 341.89] ovl_width = 48, ovl_height = 64
[ 341.90] offset_x = 1303, offset_y = 335
[ 341.90] fb_width = 96, fb_height = 64
2) Round UP:
+ overlay-crtc_width = ((overlay-crtc_width + 16)/16)*16;
+ if(overlay-crtc_width overlay-fb_width)
+ overlay-crtc_width = overlay-fb_width;
Cursor corruption from A to B
A: [ 63.20] start addr = 0x20408000, end addr = 0x2040e000, size =
0x6000
[ 63.21] ovl_width = 96, ovl_height = 64
[ 63.21] offset_x = 1271, offset_y = 346
[ 63.22] fb_width = 96, fb_height = 64
B: [ 68.60] start addr = 0x20408000, end addr = 0x2040e000, size =
0x6000
[ 68.61] ovl_width = 96, ovl_height = 64
[ 68.61] offset_x = 1272, offset_y = 346
[ 68.62] fb_width = 96, fb_height = 64
In both the scenarios ovl_width is always 16 Pixel aligned.
Please let me know if you have something else in mind. I
will check and share the observations.
The solution in the patch is proposed by hardware team
and work fine for exynos 5250, 5420 and 5800.
Regards,
Rahul Sharma
Thanks,
Inki Dae
+ */
+
+ if (win_data-fb_width MIN_FB_WIDTH_FOR_16WORD_BURST) {
+ val = ~WINCONx_BURSTLEN_MASK;
+ val |= WINCONx_BURSTLEN_4WORD;
+ }
+
writel(val, ctx-regs + WINCON(win));
}
--
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 0/8] drm/exynos/ipp: image post processing improvements
On 2014년 05월 19일 19:54, Andrzej Hajda wrote: This set of independent patches contains various improvement and fixes for exynos_drm ipp framework and drivers. The patchset is based on drm-exynos/exynos-drm-next branch. Thanks for contributions and merged. Thanks, Inki Dae Regards Andrzej Andrzej Hajda (8): drm/exynos/ipp: fix get_property IOCTL drm/exynos/ipp: correct ipp_id field initialization drm/exynos/ipp: simplify property list allocation drm/exynos/fimc: simplify pre-scaler ratio calculation drm/exynos/fimc: simplify irq masking function drm/exynos/fimc: replace hw access macros with functions drm/exynos/fimc: replace mutex by spinlock drm/exynos/fimc: simplify and rename fimc_dst_get_buf_seq drivers/gpu/drm/exynos/exynos_drm_fimc.c| 427 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 10 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 16 +- drivers/gpu/drm/exynos/exynos_drm_ipp.h | 3 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 8 +- 5 files changed, 196 insertions(+), 268 deletions(-) -- 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] drm/exynos: use regmap interface to set hdmiphy control bit in pmu
On 2014년 05월 21일 18:51, Rahul Sharma wrote:
Hi Inki, Tomasz,
Any comment on this patch?
Merged.
Thanks,
Inki Dae
Regards,
Rahul Sharma
On 20 May 2014 10:36, Rahul Sharma rahul.sha...@samsung.com wrote:
Exynos drm hdmi driver used to get dummy hdmiphy clock to
control the PMU bit for hdmiphy. This bit needs to be set
before setting any resolution to hdmi hardware. This was
handled using dummy hdmiphy clock which is removed here.
PMU is already defined as system controller for exynos
SoCs. Hdmi driver is modified to control the phy enable bit
inside PMU using regmap interfaces.
Devicetree binding document for hdmi is also updated.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
V2:
1) Squashed hdmiphy clock cleanup patch.
2) Addressed comments related to indentation, using
BIT macro while definnig bits and using IS_ERR check
while verifying regmap handle.
This patch is based on exynos-drm-next branch.
.../devicetree/bindings/video/exynos_hdmi.txt |2 ++
drivers/gpu/drm/exynos/exynos_hdmi.c | 27
++--
drivers/gpu/drm/exynos/regs-hdmi.h |4 +++
3 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 75ada04..1fd8cf9 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,7 @@ Required properties:
hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and mout_hdmi.
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
+- samsung,syscon-phandle: phandle for system controller node for PMU.
Example:
@@ -38,4 +39,5 @@ Example:
hpd-gpio = gpx3 7 1;
ddc = hdmi_ddc_node;
phy = hdmi_phy_node;
+ samsung,syscon-phandle = pmu_system_controller;
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index b03e721..f5e188f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -38,6 +38,8 @@
#include linux/of_gpio.h
#include linux/hdmi.h
#include linux/component.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
#include drm/exynos_drm.h
@@ -81,7 +83,6 @@ struct hdmi_resources {
struct clk *sclk_hdmi;
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
- struct clk *hdmiphy;
struct clk *mout_hdmi;
struct regulator_bulk_data *regul_bulk;
int regul_count;
@@ -208,6 +209,7 @@ struct hdmi_context {
const struct hdmiphy_config *phy_confs;
unsigned intphy_conf_count;
+ struct regmap *pmureg;
enum hdmi_type type;
};
@@ -2013,7 +2015,10 @@ static void hdmi_poweron(struct exynos_drm_display
*display)
if (regulator_bulk_enable(res-regul_count, res-regul_bulk))
DRM_DEBUG_KMS(failed to enable regulator bulk\n);
- clk_prepare_enable(res-hdmiphy);
+ /* set pmu hdmiphy control bit to enable hdmiphy */
+ regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
+ PMU_HDMI_PHY_ENABLE_BIT, 1);
+
clk_prepare_enable(res-hdmi);
clk_prepare_enable(res-sclk_hdmi);
@@ -2040,7 +2045,11 @@ static void hdmi_poweroff(struct exynos_drm_display
*display)
clk_disable_unprepare(res-sclk_hdmi);
clk_disable_unprepare(res-hdmi);
- clk_disable_unprepare(res-hdmiphy);
+
+ /* reset pmu hdmiphy control bit to disable hdmiphy */
+ regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
+ PMU_HDMI_PHY_ENABLE_BIT, 0);
+
regulator_bulk_disable(res-regul_count, res-regul_bulk);
pm_runtime_put_sync(hdata-dev);
@@ -2143,11 +2152,6 @@ static int hdmi_resources_init(struct hdmi_context
*hdata)
DRM_ERROR(failed to get clock 'sclk_hdmiphy'\n);
goto fail;
}
- res-hdmiphy = devm_clk_get(dev, hdmiphy);
- if (IS_ERR(res-hdmiphy)) {
- DRM_ERROR(failed to get clock 'hdmiphy'\n);
- goto fail;
- }
res-mout_hdmi = devm_clk_get(dev, mout_hdmi);
if (IS_ERR(res-mout_hdmi)) {
DRM_ERROR(failed to get clock 'mout_hdmi'\n);
@@ -2353,6 +2357,13 @@ static int hdmi_probe(struct platform_device *pdev)
goto err_hdmiphy;
}
+ hdata-pmureg = syscon_regmap_lookup_by_phandle(dev-of_node,
+ samsung,syscon-phandle);
+ if (IS_ERR(hdata-pmureg)) {
+ DRM_ERROR(syscon regmap lookup
Re: [PATCH] drm/exynos: use 4WORD dma burst length for small fbs
On 2014년 05월 22일 17:39, Rahul Sharma wrote:
On 22 May 2014 12:25, Inki Dae inki@samsung.com wrote:
On 2014년 05월 22일 13:36, Rahul Sharma wrote:
Hi Inki,
On 21 May 2014 16:43, Inki Dae inki@samsung.com wrote:
Hi Rahul,
On 2014년 05월 07일 20:25, Rahul Sharma wrote:
From: Rahul Sharma rahul.sha...@samsung.com
In case of exynos, setting dma-burst to 16Word causes permanent
tearing for very small buffers, e.g. cursor buffer. Burst Mode
switching, which is based on overlay size is not recommended as
overlay size varies a lot towards the end of the screen. This
causes unstable DMA which results into tearing again.
[snip]
+ /*
+ * In case of exynos, setting dma-burst to 16Word causes permanent
+ * tearing for very small buffers, e.g. cursor buffer. Burst Mode
+ * switching which is based on overlay size is not recommended as
+ * overlay size varies alot towards the end of the screen and rapid
+ * movement causes unstable DMA which results into iommu crash/tear.
FIMD has width limitation so width of hardware overlay may need to be
aligned to 16 pixels.
We had faced with similar issue and the issue had been resolved by
aligning it to 16 pixels.
So can you try to align it instead of changing burst len size?
This problem is only with the very small FBs which are
rendered towards corners. For large FBs like 1366x768,
we dont see this issue though 1366 is not 16 pixel
aligned.
Right, we had test it with 8x64 pixels. the limitation would be decided
by memory bus length(ML), DMA burst length(DL) and pixel size in bytes(PS).
And that can be calculated like below, which was guided by hardware team,
Align { (ML * DI / PS) + (4bytes / PS), 2}
What will be the value for ML in Exynos? 4, I guess ?
It seems too big value. Actually, 16 pixels works well and I don't see
why it works well although out of limitation.
Actually Peach Pit and Peach Pi, native LCD resolution is 1366x768
which has no issues.
In above experiments, I rendered FB of size 96*64 which corrupts when
overlay width reduces beyond 48 Pixels for 5420, 5800 and 64 for 5250.
Probably we have not tested rendering the Small buffers (96 Pixels) with
16 bit DMA burst and towards end of FB. As if now, this scenario only
applicable for Chrome which is having cursor.
Please let me know how to proceed further.
As we had a discussion about this, there is no right solution but one
issue. So merged it temporarily until we could find the right solution
that can consider memory bus length of all Exynos SoC: the limitation
would have dependency of memory bus length of SoC.
Thanks,
Inki Dae
Regards,
Rahul Sharma.
Thanks,
Inki Dae
But I still carried out following experiments just to
verify the fimd behaviour for small overlay.
1) Round DOWN:
+ overlay-crtc_width = ((overlay-crtc_width)/16)*16;
Cursor corruption from A to B
A: [ 308.53] start addr = 0x20408000, end addr = 0x2040e000, size =
0x6000
[ 308.53] ovl_width = 64, ovl_height = 64
[ 308.54] offset_x = 1302, offset_y = 335
[ 308.54] fb_width = 96, fb_height = 64
B: [ 341.89] start addr = 0x20408000, end addr = 0x2040e000, size =
0x6000
[ 341.89] ovl_width = 48, ovl_height = 64
[ 341.90] offset_x = 1303, offset_y = 335
[ 341.90] fb_width = 96, fb_height = 64
2) Round UP:
+ overlay-crtc_width = ((overlay-crtc_width + 16)/16)*16;
+ if(overlay-crtc_width overlay-fb_width)
+ overlay-crtc_width = overlay-fb_width;
Cursor corruption from A to B
A: [ 63.20] start addr = 0x20408000, end addr = 0x2040e000, size =
0x6000
[ 63.21] ovl_width = 96, ovl_height = 64
[ 63.21] offset_x = 1271, offset_y = 346
[ 63.22] fb_width = 96, fb_height = 64
B: [ 68.60] start addr = 0x20408000, end addr = 0x2040e000, size =
0x6000
[ 68.61] ovl_width = 96, ovl_height = 64
[ 68.61] offset_x = 1272, offset_y = 346
[ 68.62] fb_width = 96, fb_height = 64
In both the scenarios ovl_width is always 16 Pixel aligned.
Please let me know if you have something else in mind. I
will check and share the observations.
The solution in the patch is proposed by hardware team
and work fine for exynos 5250, 5420 and 5800.
Regards,
Rahul Sharma
Thanks,
Inki Dae
+ */
+
+ if (win_data-fb_width MIN_FB_WIDTH_FOR_16WORD_BURST) {
+ val = ~WINCONx_BURSTLEN_MASK;
+ val |= WINCONx_BURSTLEN_4WORD;
+ }
+
writel(val, ctx-regs + WINCON(win));
}
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 04/18] video: add command mode and command mode display timing
On 2014년 05월 21일 20:41, YoungJun Cho wrote: Hi Therry On 05/21/2014 08:02 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 01:42:56PM +0900, YoungJun Cho wrote: This patch is based on videomode and display_timing relevant codes. To support command mode panel, it does not need to guide its timing information to the display controller like video mode panel, but it requires signal timings to transfer video data. So this patch adds cmdmode struct, cmdmode_display_timing struct and the according helper functions to convert cmdmode_display_timing to a generic cmdmode. Can you point me to relevant documentation? I wasn't able to find it by a quick scan through the DSI specification. I'm sorry to say that there is no specific one document. I referred to several ones, CPU interface, I80 interface and DBI document(last time you said it). I think this is good to check it. [ http://cache.freescale.com/files/dsp/doc/app_note/AN4180.pdf ] Ping~. Is there other comment? If so then I'd like to pick them up. We would be happy for you leave reviewed-by or acked-by. Thanks, Inki Dae And I asked panel vendor custom service centre also. Thank you. Best regards YJ Thierry -- To unsubscribe from this list: send the line unsubscribe devicetree 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] drm/exynos: use 4WORD dma burst length for small fbs
Hi Rahul,
On 2014년 05월 07일 20:25, Rahul Sharma wrote:
From: Rahul Sharma rahul.sha...@samsung.com
In case of exynos, setting dma-burst to 16Word causes permanent
tearing for very small buffers, e.g. cursor buffer. Burst Mode
switching, which is based on overlay size is not recommended as
overlay size varies a lot towards the end of the screen. This
causes unstable DMA which results into tearing again.
Rendering small buffers with lower burst size doesn't
cause any noticable performance overhead. 128 pixel width is
selected based on mulitple experiments with exynos5 SoCs.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Prathyush K prathyus...@samsung.com
---
Based on Inki Dae's exynos-drm-next branch.
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 40fd6cc..ef56077 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -38,6 +38,7 @@
*/
#define FIMD_DEFAULT_FRAMERATE 60
+#define MIN_FB_WIDTH_FOR_16WORD_BURST 128
/* position control register for hardware window 0, 2 ~ 4.*/
#define VIDOSD_A(win)(VIDOSD_BASE + 0x00 + (win) * 16)
@@ -446,6 +447,19 @@ static void fimd_win_set_pixfmt(struct fimd_context
*ctx, unsigned int win)
DRM_DEBUG_KMS(bpp = %d\n, win_data-bpp);
+ /*
+ * In case of exynos, setting dma-burst to 16Word causes permanent
+ * tearing for very small buffers, e.g. cursor buffer. Burst Mode
+ * switching which is based on overlay size is not recommended as
+ * overlay size varies alot towards the end of the screen and rapid
+ * movement causes unstable DMA which results into iommu crash/tear.
FIMD has width limitation so width of hardware overlay may need to be
aligned to 16 pixels.
We had faced with similar issue and the issue had been resolved by
aligning it to 16 pixels.
So can you try to align it instead of changing burst len size?
Thanks,
Inki Dae
+ */
+
+ if (win_data-fb_width MIN_FB_WIDTH_FOR_16WORD_BURST) {
+ val = ~WINCONx_BURSTLEN_MASK;
+ val |= WINCONx_BURSTLEN_4WORD;
+ }
+
writel(val, ctx-regs + WINCON(win));
}
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V2 0/3] drm/bridge: panel and chaining
Hi Andrzej On 2014년 05월 08일 15:41, Andrzej Hajda wrote: On 05/05/2014 09:52 PM, Ajay Kumar wrote: This patchset is based on exynos-drm-next-todo branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git I have just put up Rob's and Sean's idea of chaining up the bridges in code, and have implemented basic panel controls as a chained bridge. This works well with ptn3460 bridge chip on exynos5250-snow board. Still need to make use of standard list calls and figure out proper way of deleting the bridge chain. So, this is just a rough version. As I understand this patchset tries to solve two things: 1. Implement panel as drm_bridge, to ease support for hardware chains: Crtc - Encoder - Bridge - Panel 2. Add support to drm_bridge chaining, to allow software chains: drm_crtc - drm_encoder - drm_bridge - drm_bridge,panel It is done using Russian doll schema, ops from the bridge calls the same ops from the next bridge and the next bridge ops can do the same. This schema means that all the bridges including the last one are seen from the drm core point of view as a one big drm_bridge. Additionally in this particular case, the first bridge (ptn3460) implements connector so it is hard to guess what is the location of the 2nd bridge in video stream chain, sometimes it is after the connector, sometimes before. All this is quite confusing. But if you look at the bridge from upstream video interface point of view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its video input side acts as a panel. On the output side it expects a panel, lvds panel in this case. So why not implement ptn3460 bridge as drm_panel which internally uses another drm_panel. With this approach everything fits much better. You do not need those (pre|post)_(enable|disable) calls, you do not need to implement connector in the bridge and you have a driver following linux driver model. And no single bit changed in drm core. I have implemented this way DSI/LVDS bridge, it was sent as RFC [1][2]. It was not accepted as Inki preferred drm_bridge but as I see the problems with drm_bridges I have decide to attract attention to much Yes, in above email threads, I disagreed to using drm_panel framework for bridge device, especially, to implement connector/encoder to crtc driver. However, I thought that it'd be more generic way that lvds drivers use driver-model, and the use of drm_panel infrastructure would be suitable to doing this. So my intention in turn, was that LVDS driver uses integrated drm_bridge based on drm_panel infrastructure[1], and RFC patch[2] for it. This way is same as your proposal in the point that LVDS and Panel drivers use driver-model. The only different point is that LVDS driver has some ops specific to LVDS device, not using existing ops of drm_panel commonly: we may need to consider the characteristic of LVDS device. [1]:http://www.spinics.net/lists/dri-devel/msg5.html [2]:http://www.spinics.net/lists/dri-devel/msg55658.html Thanks, Inki Dae more cleaner solution. [1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 [2]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/27044 Regards Andrzej Ajay Kumar (3): [RFC V2 1/3] drm: implement chaining of drm bridges [RFC V2 2/3] drm/bridge: add a dummy panel driver to support lvds bridges [RFC V2 3/3] drm/bridge: ptn3460: support bridge chaining .../bindings/drm/bridge/bridge_panel.txt | 45 drivers/gpu/drm/bridge/Kconfig | 6 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/bridge_panel.c | 240 + drivers/gpu/drm/bridge/ptn3460.c | 21 +- drivers/gpu/drm/drm_crtc.c | 13 +- include/drm/bridge/bridge_panel.h | 37 include/drm/drm_crtc.h | 2 + 8 files changed, 360 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt create mode 100644 drivers/gpu/drm/bridge/bridge_panel.c create mode 100644 include/drm/bridge/bridge_panel.h -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V2 0/3] drm/bridge: panel and chaining
Just re-sending with text mode. Sorry for this. On 2014년 05월 08일 15:41, Andrzej Hajda wrote: On 05/05/2014 09:52 PM, Ajay Kumar wrote: This patchset is based on exynos-drm-next-todo branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git I have just put up Rob's and Sean's idea of chaining up the bridges in code, and have implemented basic panel controls as a chained bridge. This works well with ptn3460 bridge chip on exynos5250-snow board. Still need to make use of standard list calls and figure out proper way of deleting the bridge chain. So, this is just a rough version. As I understand this patchset tries to solve two things: 1. Implement panel as drm_bridge, to ease support for hardware chains: Crtc - Encoder - Bridge - Panel 2. Add support to drm_bridge chaining, to allow software chains: drm_crtc - drm_encoder - drm_bridge - drm_bridge,panel It is done using Russian doll schema, ops from the bridge calls the same ops from the next bridge and the next bridge ops can do the same. This schema means that all the bridges including the last one are seen from the drm core point of view as a one big drm_bridge. Additionally in this particular case, the first bridge (ptn3460) implements connector so it is hard to guess what is the location of the 2nd bridge in video stream chain, sometimes it is after the connector, sometimes before. All this is quite confusing. But if you look at the bridge from upstream video interface point of view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its video input side acts as a panel. On the output side it expects a panel, lvds panel in this case. So why not implement ptn3460 bridge as drm_panel which internally uses another drm_panel. With this approach everything fits much better. You do not need those (pre|post)_(enable|disable) calls, you do not need to implement connector in the bridge and you have a driver following linux driver model. And no single bit changed in drm core. I have implemented this way DSI/LVDS bridge, it was sent as RFC [1][2]. It was not accepted as Inki preferred drm_bridge but as I see the Yes, in above email threads, I disagreed to using drm_panel framework for bridge device, especially, to implement connector/encoder to crtc driver. However, I thought that it'd be more generic way that lvds drivers use driver-model, and the use of drm_panel infrastructure would be suitable to doing this. So my intention in turn, was that LVDS driver uses integrated drm_bridge based on drm_panel infrastructure[1], and RFC patch[2] for it. This way is same as your proposal in the point that LVDS and Panel drivers use driver-model. The only different point is that LVDS driver has some ops specific to LVDS device, not using existing ops of drm_panel commonly: we may need to consider the characteristic of LVDS device. [1]:http://www.spinics.net/lists/dri-devel/msg5.html [2]:http://www.spinics.net/lists/dri-devel/msg55658.html Thanks, Inki Dae problems with drm_bridges I have decide to attract attention to much more cleaner solution. [1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 [2]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/27044 Regards Andrzej Ajay Kumar (3): [RFC V2 1/3] drm: implement chaining of drm bridges [RFC V2 2/3] drm/bridge: add a dummy panel driver to support lvds bridges [RFC V2 3/3] drm/bridge: ptn3460: support bridge chaining .../bindings/drm/bridge/bridge_panel.txt | 45 drivers/gpu/drm/bridge/Kconfig | 6 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/bridge_panel.c | 240 + drivers/gpu/drm/bridge/ptn3460.c | 21 +- drivers/gpu/drm/drm_crtc.c | 13 +- include/drm/bridge/bridge_panel.h | 37 include/drm/drm_crtc.h | 2 + 8 files changed, 360 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt create mode 100644 drivers/gpu/drm/bridge/bridge_panel.c create mode 100644 include/drm/bridge/bridge_panel.h -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] drm/exynos/mixer: use MXR_GRP_SXY_SY
Hi Daniel, On 2014년 05월 08일 18:21, Daniel Kurtz wrote: On Thu, May 8, 2014 at 12:33 PM, Seung-Woo Kim sw0312@samsung.com wrote: Hello Daniel, On 2014년 05월 07일 23:14, Daniel Kurtz wrote: On Wed, May 7, 2014 at 1:14 PM, Seung-Woo Kim sw0312@samsung.com wrote: Hi Daniel, On 2014년 05월 05일 00:26, Daniel Kurtz wrote: Mixer hardware supports offsetting dma from start of source buffer using the MXR_GRP_SXY register. Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 475eb49..40cf39b 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -529,13 +529,11 @@ static void mixer_graph_buffer(struct mixer_context *ctx, int win) dst_x_offset = win_data-crtc_x; dst_y_offset = win_data-crtc_y; + src_x_offset = win_data-fb_x; + src_y_offset = win_data-fb_y; /* converting dma address base and source offset */ - dma_addr = win_data-dma_addr - + (win_data-fb_x * win_data-bpp 3) - + (win_data-fb_y * win_data-fb_width * win_data-bpp 3); - src_x_offset = 0; - src_y_offset = 0; + dma_addr = win_data-dma_addr; Basically, you are right and source offset register can be used. But because of limitation of resolution for mixer up to 1920x1080, I considered modified soruce dma address to set one frame buffer, which is bigger than 1920x1080, on to both fimd and hdmi. Hi Seung-Woo, I do not see why the maximum MIXER resolution matters for choosing between offsetting BASE or using SXY. Let's say you have one big 1920x1908 framebuffer, with a span of 1920, starting at dma_addr (there is no extra padding at the end of the line). Let's say you wanted the mixer to scan out 1920x1080 pixels starting from (0, 800) in the framebuffer, and start drawing them at (0,0) on the screen. What we currently do is: BASE = dma_addr + (800 * 1080 * 4) SPAN = 1920 SXY = SX(0) | SY(0) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) I am proposing we do: BASE = dma_addr SPAN = 1920 SXY = SX(0) | SY(800) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) In both cases, the mixer resolution is 1920x1080. In my test to show each half of big one framebuffer (3840 x 1080) to FIMD from 0 to 1079 and MIXER from 1080 to 3839 with exynos4210 and exynos4412, it was failed to show proper hdmi display. Also it is same for framebuffer (1920 x 2160). AFAIK, it is mainly because mixer dma has limitation of dma memory size. That is unfortunate, but thank you for your explanation. Is this limitation exynos4 specific, or does it also apply for the exynos5 mixer? It seems that exynos5260/5420 mixers also have same limitation: SX/Y fields is 11 bits. Was the limitation perhaps the number of bits in the SXY register fields ( 11) on those devices? For 5250/5420 these fields are 11 bits, and I don't see any restrictions about dma memory size in the documentation that I have. So I guess that the reason Mixer controller was operated incorrectly is that SX/Y fields exceed maximum value (2047) by itself when he calculates DMA address to access the memory region: the value of SX/Y fields would be increased by Mixer controller internally until reaching width or height, and in turn the value would exceed 2047. So I think it'd better to use existing codes because this patch isn't tested so not safe. You can add more comments enough to existing codes if needed. In addition, it seems that Exynos5422/5430 has no such limitation but they are much different from old ones so we would need new drivers for them. Thanks, Inki Dae Thanks, -Dan In this case, I set register as like: BASE = dma_addr /* 3840 x 1080 x 4 */ SPAN = 3840 SXY = SX(1920) | SY(0) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) or: BASE = dma_addr /* 1920 x 2160 x 4 */ SPAN = 1920 SXY = SX(0) | SY(1080) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) but these two setting did not show hdmi display as I expected. So I used modified dma address. My motivation for wanting to program an un-modified dma_addr into BASE is so we can then just check BASE_S to determine from which buffer the mixer is actively being scanned out without worrying about the source offset, since the source offset can change for a given framebuffer (for example, when doing panning, or if an overlay is used for a HW cursor). Actually, this patch is exactly same with my first implementation, so I completely understand your motivation. Anyway, I was focus on extended displays with one buffer, so I wrote modified dma base address. Thanks and Regards, - Seung-Woo Kim Best Regards, -Daniel Regards, - Seung-Woo Kim if (win_data-scan_flags DRM_MODE_FLAG_INTERLACE) ctx
Re: [RFC V2 0/3] drm/bridge: panel and chaining
On 2014년 05월 08일 19:52, Ajay kumar wrote: +Dave +Thierry On Thu, May 8, 2014 at 1:14 PM, Inki Dae inki@samsung.com wrote: Just re-sending with text mode. Sorry for this. On 2014년 05월 08일 15:41, Andrzej Hajda wrote: On 05/05/2014 09:52 PM, Ajay Kumar wrote: This patchset is based on exynos-drm-next-todo branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git I have just put up Rob's and Sean's idea of chaining up the bridges in code, and have implemented basic panel controls as a chained bridge. This works well with ptn3460 bridge chip on exynos5250-snow board. Still need to make use of standard list calls and figure out proper way of deleting the bridge chain. So, this is just a rough version. As I understand this patchset tries to solve two things: 1. Implement panel as drm_bridge, to ease support for hardware chains: Crtc - Encoder - Bridge - Panel 2. Add support to drm_bridge chaining, to allow software chains: drm_crtc - drm_encoder - drm_bridge - drm_bridge,panel It is done using Russian doll schema, ops from the bridge calls the same ops from the next bridge and the next bridge ops can do the same. This schema means that all the bridges including the last one are seen from the drm core point of view as a one big drm_bridge. Additionally in this particular case, the first bridge (ptn3460) implements connector so it is hard to guess what is the location of the 2nd bridge in video stream chain, sometimes it is after the connector, sometimes before. All this is quite confusing. But if you look at the bridge from upstream video interface point of view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its video input side acts as a panel. On the output side it expects a panel, lvds panel in this case. So why not implement ptn3460 bridge as drm_panel which internally uses another drm_panel. With this approach everything fits much better. You do not need those (pre|post)_(enable|disable) calls, you do not need to implement connector in the bridge and you have a driver following linux driver model. And no single bit changed in drm core. I have implemented this way DSI/LVDS bridge, it was sent as RFC [1][2]. It was not accepted as Inki preferred drm_bridge but as I see the Yes, in above email threads, I disagreed to using drm_panel framework for bridge device, especially, to implement connector/encoder to crtc driver. However, I thought that it'd be more generic way that lvds drivers use driver-model, and the use of drm_panel infrastructure would be suitable to doing this. So my intention in turn, was that LVDS driver uses integrated drm_bridge based on drm_panel infrastructure[1], and RFC patch[2] for it. This way is same as your proposal in the point that LVDS and Panel drivers use driver-model. The only different point is that LVDS driver has some ops specific to LVDS device, not using existing ops of drm_panel commonly: we may need to consider the characteristic of LVDS device. [1]:http://www.spinics.net/lists/dri-devel/msg5.html [2]:http://www.spinics.net/lists/dri-devel/msg55658.html Thanks, Inki Dae I am just consolidating the discussion happening here. 1) This patchset started from a discussion wherein I tried to combine drm_panel with drm_bridge. https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg28943.html 2) Sean and Rob suggested to implement a chain of bridges and then consider adding basic panel controls as a bridge. 3) Andrej's idea is to drop the existing bridge infrastructure and implement ptn3460 using drm_panel, the same way he has implemented http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559. 4) Inki's suggestion is to combine drm_bridge, drm_panel and drm_enhance into a single drm_hw_block. And more thing, we would need to consider image enhancer device placed between crtc and connector/encoder devices. And it'd better to rename drm_hw_block to drm_bridge, and existing drm_bridge relevant codes should be removed. Thanks, Inki Dae I am currently trying to implement (2):chaining of bridges, and I think we have not yet reached to a consensus. So adding few other people from drm community to comment. Regards, Ajay problems with drm_bridges I have decide to attract attention to much more cleaner solution. [1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 [2]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/27044 Regards Andrzej Ajay Kumar (3): [RFC V2 1/3] drm: implement chaining of drm bridges [RFC V2 2/3] drm/bridge: add a dummy panel driver to support lvds bridges [RFC V2 3/3] drm/bridge: ptn3460: support bridge chaining .../bindings/drm/bridge/bridge_panel.txt | 45 drivers/gpu/drm/bridge/Kconfig | 6 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge
[PATCH 0/5] add super device node support
This patch series adds super device node approach and relevant dt bindings, and rebased on top of below patch series, http://www.spinics.net/lists/dri-devel/msg57673.html Thanks, Inki Dae Inki Dae (5): drm/exynos: add super device support ARM: dts: exynos4210-universal: add super device node for exynos drm ARM: dts: exynos4210-trats: add super device node for exynos drm ARM: dts: exynos4412-trats2: add super device node for exynos drm exynos/drm: add DT bindings for super device node .../bindings/drm/exynos/samsung-exynos-drm.txt | 32 ++ arch/arm/boot/dts/exynos4210-trats.dts |5 + arch/arm/boot/dts/exynos4210-universal_c210.dts|5 + arch/arm/boot/dts/exynos4412-trats2.dts|5 + drivers/gpu/drm/exynos/exynos_dp_core.c|4 +- drivers/gpu/drm/exynos/exynos_drm_drv.c| 119 ++-- drivers/gpu/drm/exynos/exynos_drm_drv.h|7 -- drivers/gpu/drm/exynos/exynos_drm_dsi.c|4 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 +- drivers/gpu/drm/exynos/exynos_hdmi.c |4 +- drivers/gpu/drm/exynos/exynos_mixer.c |4 +- 11 files changed, 116 insertions(+), 77 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: dts: exynos4210-universal: add super device node for exynos drm
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4210-universal_c210.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 0a80a72..5351ac4 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -409,6 +409,11 @@
};
};
+ display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd;
+ };
+
pwm@139D {
compatible = samsung,s5p6440-pwm;
status = okay;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] exynos/drm: add DT bindings for super device node
This patch adds bindings for Exynos drm display subsystem.
The bindings describes ports containing a list of phandles
pointing to display controller, image enhancer, and display
interfaces nodes.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/drm/exynos/samsung-exynos-drm.txt | 32
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
diff --git
a/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
new file mode 100644
index 000..6f7fae0
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
@@ -0,0 +1,32 @@
+Samsung Exynos DRM master device
+
+
+The Samsung Exynos DRM master device is a virtual device needed to list all
+display controller, image enhancer, and display interface nodes that comprise
+the graphics subsystem.
+
+Required properties:
+- compatible: Should be samsung,exynos-display-subsystem
+- ports: Should contain a list of phandles pointing to display controller,
+ image enhancer, and display interface ports.
+
+Examples:
+
+In case of using MIPI-DSI,
+display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd, dsi;
+};
+
+
+In case of using DisplayPort,
+display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd, dp;
+};
+
+In case of using parallel panel,
+display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: dts: exynos4210-trats: add super device node for exynos drm
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4210-trats.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 02c6768..a41c109 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -414,6 +414,11 @@
status = okay;
};
+ display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd, dsi_0;
+ };
+
camera {
pinctrl-names = default;
pinctrl-0 = ;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/5] drm/exynos: add super device support
This patch adds super device support to bind sub drivers
using device tree.
For this, you should add a super device node to each machine dt files
like belows,
In case of using MIPI-DSI,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd, dsi;
};
In case of using DisplayPort,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd, dp;
};
In case of using Parallel panel,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd;
};
And if you don't add connector device node to ports property,
default parallel panel driver, exynos_drm_dpi module, will be used.
ports property can have the following device nodes,
fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI
With this patch, we can resolve the probing order issue without
some global lists. So this patch also removes the unnecessary lists and
stuff related to these lists.
Previous RFC patch,
http://www.spinics.net/lists/dri-devel/msg54671.html
Changelog since RFC patch:
- Register sub drivers and probe them at load(). In case of non sub
drivers, sub driver probe is needed.
- Enable runtime pm at fimd_probe() instead of fimd_bind(). runtime pm
should be enabled before iommu device is attached to fimd device.
- Do not return an error with component_master_add fail.
- Remove super device support from mipi dsi driver which was in RFC.
- Add super device support to parallel driver.
Changelog v2:
- Add super device support to mipi dsi driver.
- Bind fimd driver only in case that a drm_panel for parallel panel driver
is added to panel_list of drm_panel module.
- Change super node name to 'display-subsystem'
. 'exynos-drm' is specific to Linux so change it to generic name.
- Change propery name of super node to 'ports'
. crtcs and connectors propery names are also specific to Linux so
change them to generic name.
Changlog v3:
- Do not probe/remove dpi module if fimd node has no port node.
Changelog v4:
- Move some codes for getting resources from each bind function to
each probe function.
. if -EPROBE_DEFER is returned at bind context, components will be
bound and unbound repeatedly by deferred probe feature.
Changelog v5:
- Return error only in case that there is no any compoment attached
to master.
- Add legacy dt binding support
- Probe vidi driver in exynos_drm_init(), and release vidi driver
correctly.
- Remove duplicated coherent_dma_mask setting.
Changelog v6:
- Add super device support, and remove existing specific codes.
- Re-based on top of below patch series,
http://www.spinics.net/lists/dri-devel/msg57673.html
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c |4 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 119 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h |7 --
drivers/gpu/drm/exynos/exynos_drm_dsi.c |4 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 +-
drivers/gpu/drm/exynos/exynos_hdmi.c |4 +-
drivers/gpu/drm/exynos/exynos_mixer.c|4 +-
7 files changed, 69 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a97840c..1cc3981 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1313,12 +1313,12 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
- return exynos_drm_component_add(pdev-dev, exynos_dp_ops);
+ return component_add(pdev-dev, exynos_dp_ops);
}
static int exynos_dp_remove(struct platform_device *pdev)
{
- exynos_drm_component_del(pdev-dev, exynos_dp_ops);
+ component_del(pdev-dev, exynos_dp_ops);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ab8ffbb..1d653f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -43,14 +43,6 @@
static struct platform_device *exynos_drm_pdev;
-static DEFINE_MUTEX(drm_component_lock);
-static LIST_HEAD(drm_component_list);
-
-struct component_dev {
- struct list_head list;
- struct device *dev;
-};
-
static int exynos_drm_load(struct drm_device *dev, unsigned long flags)
{
struct exynos_drm_private *private;
@@ -382,78 +374,72 @@ static const struct dev_pm_ops exynos_drm_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_sys_suspend, exynos_drm_sys_resume)
};
-int exynos_drm_component_add(struct device *dev,
- const struct component_ops *ops)
+static int compare_of(struct device *dev, void *data)
{
- struct component_dev *cdev;
- int ret
[PATCH 4/5] ARM: dts: exynos4412-trats2: add super device node for exynos drm
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4412-trats2.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 53c717b..115b9ed 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -581,6 +581,11 @@
status = okay;
};
+ display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd, dsi_0;
+ };
+
camera {
pinctrl-0 = cam_port_b_clk_active;
pinctrl-names = default;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] drm/exynos: dpi: fix hotplug fail issue
When connector is created, if connector-polled is DRM_CONNECTOR_POLL_CONNECT then drm_kms_helper_hotplug_event function isn't called at drm_helper_hpd_irq_event because the function will be called only in case of DRM_CONNECTOR_POLL_HPD. So this patch sets always DRM_CONNECTOR_POLL_HPD flag to connector-polled of parallel panel driver at connector creation. Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_dpi.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c index c1f4b35..ac206e7 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c @@ -123,10 +123,7 @@ static int exynos_dpi_create_connector(struct exynos_drm_display *display, ctx-encoder = encoder; - if (ctx-panel_node) - connector-polled = DRM_CONNECTOR_POLL_CONNECT; - else - connector-polled = DRM_CONNECTOR_POLL_HPD; + connector-polled = DRM_CONNECTOR_POLL_HPD; ret = drm_connector_init(encoder-dev, connector, exynos_dpi_connector_funcs, -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] drm/exynos: add component framework support
This patch adds component framework support to resolve
the probe order issue.
Until now, exynos drm had used codes specific to exynos drm
to resolve that issue so with this patch, the specific codes
are removed.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 45 +++--
drivers/gpu/drm/exynos/exynos_drm_core.c | 216 -
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 ++
drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 +
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 16 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 310 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 89 +
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 110 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 87 +++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 101 --
drivers/gpu/drm/exynos/exynos_hdmi.c | 59 +++---
drivers/gpu/drm/exynos/exynos_mixer.c| 54 --
12 files changed, 643 insertions(+), 465 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index aed533b..a97840c 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/of.h
+#include linux/component.h
#include linux/phy/phy.h
#include video/of_display_timing.h
#include video/of_videomode.h
@@ -969,16 +970,6 @@ static struct drm_connector_helper_funcs
exynos_dp_connector_helper_funcs = {
.best_encoder = exynos_dp_best_encoder,
};
-static int exynos_dp_initialize(struct exynos_drm_display *display,
- struct drm_device *drm_dev)
-{
- struct exynos_dp_device *dp = display-ctx;
-
- dp-drm_dev = drm_dev;
-
- return 0;
-}
-
static bool find_bridge(const char *compat, struct bridge_init *bridge)
{
bridge-client = NULL;
@@ -1106,7 +1097,6 @@ static void exynos_dp_dpms(struct exynos_drm_display
*display, int mode)
}
static struct exynos_drm_display_ops exynos_dp_display_ops = {
- .initialize = exynos_dp_initialize,
.create_connector = exynos_dp_create_connector,
.dpms = exynos_dp_dpms,
};
@@ -1230,8 +1220,10 @@ static int exynos_dp_dt_parse_panel(struct
exynos_dp_device *dp)
return 0;
}
-static int exynos_dp_probe(struct platform_device *pdev)
+static int exynos_dp_bind(struct device *dev, struct device *master, void
*data)
{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct drm_device *drm_dev = data;
struct resource *res;
struct exynos_dp_device *dp;
@@ -1293,21 +1285,40 @@ static int exynos_dp_probe(struct platform_device *pdev)
}
disable_irq(dp-irq);
+ dp-drm_dev = drm_dev;
exynos_dp_display.ctx = dp;
platform_set_drvdata(pdev, exynos_dp_display);
- exynos_drm_display_register(exynos_dp_display);
- return 0;
+ return exynos_drm_create_enc_conn(drm_dev, exynos_dp_display);
}
-static int exynos_dp_remove(struct platform_device *pdev)
+static void exynos_dp_unbind(struct device *dev, struct device *master,
+ void *data)
{
- struct exynos_drm_display *display = platform_get_drvdata(pdev);
+ struct exynos_drm_display *display = dev_get_drvdata(dev);
+ struct exynos_dp_device *dp = display-ctx;
+ struct drm_encoder *encoder = dp-encoder;
exynos_dp_dpms(display, DRM_MODE_DPMS_OFF);
- exynos_drm_display_unregister(exynos_dp_display);
+ encoder-funcs-destroy(encoder);
+ drm_connector_cleanup(dp-connector);
+}
+
+static const struct component_ops exynos_dp_ops = {
+ .bind = exynos_dp_bind,
+ .unbind = exynos_dp_unbind,
+};
+
+static int exynos_dp_probe(struct platform_device *pdev)
+{
+ return exynos_drm_component_add(pdev-dev, exynos_dp_ops);
+}
+
+static int exynos_dp_remove(struct platform_device *pdev)
+{
+ exynos_drm_component_del(pdev-dev, exynos_dp_ops);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 0e9e06c..4c9f972 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -19,21 +19,19 @@
#include exynos_drm_fbdev.h
static LIST_HEAD(exynos_drm_subdrv_list);
-static LIST_HEAD(exynos_drm_manager_list);
-static LIST_HEAD(exynos_drm_display_list);
-static int exynos_drm_create_enc_conn(struct drm_device *dev,
+int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display)
{
struct drm_encoder *encoder;
- struct exynos_drm_manager *manager;
int ret;
unsigned long possible_crtcs = 0;
- /* Find possible crtcs for this display */
- list_for_each_entry(manager, exynos_drm_manager_list, list
[PATCH 0/5] drm/exynos: more cleanup with component framework
This patch series cleans up exynos drm framework and kms sub drivers using the component framework[1]. And also this separates super device support from previous cleanup patch series[2] for more discussion. So the patch series for super node support will be posted later. [1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html [2]http://www.spinics.net/lists/dri-devel/msg57401.html Thanks, Ink Dae Andrzej Hajda (1): drm/exynos: separate dpi from fimd Inki Dae (4): drm/exynos: modify goto labels to meaningful names drm/exynos: add component framework support drm/exynos: dpi: fix hotplug fail issue drm/exynos: fix comment to exynos_drm_device_subdrv_prove call drivers/gpu/drm/exynos/exynos_dp_core.c | 45 ++-- drivers/gpu/drm/exynos/exynos_drm_core.c | 216 --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 ++ drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 + drivers/gpu/drm/exynos/exynos_drm_dpi.c | 51 +++-- drivers/gpu/drm/exynos/exynos_drm_drv.c | 339 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.h | 80 --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 110 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 74 +-- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 101 +++-- drivers/gpu/drm/exynos/exynos_hdmi.c | 59 -- drivers/gpu/drm/exynos/exynos_mixer.c| 54 - 12 files changed, 649 insertions(+), 501 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] drm/exynos: fix comment to exynos_drm_device_subdrv_prove call
subdrv_probe callback of virtual display driver will be called by exynos_drm_device_subdrv_probe() to create crtc and encoder/connector for virtual display driver. So it fixes comments to exynos_drm_device_subdrv probe call. Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index dc45881..6fa6f07 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -109,7 +109,7 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) if (ret) goto err_cleanup_vblank; - /* Probe non kms sub drivers. */ + /* Probe non kms sub drivers and virtual display driver. */ ret = exynos_drm_device_subdrv_probe(dev); if (ret) goto err_unbind_all; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] drm/exynos: modify goto labels to meaningful names
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 55 +++
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2d27ba2..b3ba043 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -447,139 +447,138 @@ static int __init exynos_drm_init(void)
#ifdef CONFIG_DRM_EXYNOS_DP
ret = platform_driver_register(dp_driver);
if (ret 0)
- goto out_dp;
+ return ret;
#endif
#ifdef CONFIG_DRM_EXYNOS_DSI
ret = platform_driver_register(dsi_driver);
if (ret 0)
- goto out_dsi;
+ goto err_unregister_dp_drv;
#endif
#ifdef CONFIG_DRM_EXYNOS_FIMD
ret = platform_driver_register(fimd_driver);
if (ret 0)
- goto out_fimd;
+ goto err_unregister_dsi_drv;
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
ret = platform_driver_register(hdmi_driver);
if (ret 0)
- goto out_hdmi;
+ goto err_unregister_fimd_drv;
ret = platform_driver_register(mixer_driver);
if (ret 0)
- goto out_mixer;
+ goto err_unregister_hdmi_drv;
#endif
#ifdef CONFIG_DRM_EXYNOS_VIDI
ret = platform_driver_register(vidi_driver);
if (ret 0)
- goto out_vidi;
+ goto err_unregister_mixer_drv;
#endif
#ifdef CONFIG_DRM_EXYNOS_G2D
ret = platform_driver_register(g2d_driver);
if (ret 0)
- goto out_g2d;
+ goto err_unregister_vidi_drv;
#endif
#ifdef CONFIG_DRM_EXYNOS_FIMC
ret = platform_driver_register(fimc_driver);
if (ret 0)
- goto out_fimc;
+ goto err_unregister_g2d_drv;
#endif
#ifdef CONFIG_DRM_EXYNOS_ROTATOR
ret = platform_driver_register(rotator_driver);
if (ret 0)
- goto out_rotator;
+ goto err_unregister_fimc_drv;
#endif
#ifdef CONFIG_DRM_EXYNOS_GSC
ret = platform_driver_register(gsc_driver);
if (ret 0)
- goto out_gsc;
+ goto err_unregister_rotator_drv;
#endif
#ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(ipp_driver);
if (ret 0)
- goto out_ipp;
+ goto err_unregister_gsc_drv;
ret = exynos_platform_device_ipp_register();
if (ret 0)
- goto out_ipp_dev;
+ goto err_unregister_ipp_drv;
#endif
ret = platform_driver_register(exynos_drm_platform_driver);
if (ret 0)
- goto out_drm;
+ goto err_unregister_ipp_dev;
exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1,
NULL, 0);
if (IS_ERR(exynos_drm_pdev)) {
ret = PTR_ERR(exynos_drm_pdev);
- goto out;
+ goto err_unregister_drm_drv;
}
return 0;
-out:
+err_unregister_drm_drv:
platform_driver_unregister(exynos_drm_platform_driver);
-out_drm:
+err_unregister_ipp_dev:
#ifdef CONFIG_DRM_EXYNOS_IPP
exynos_platform_device_ipp_unregister();
-out_ipp_dev:
+err_unregister_ipp_drv:
platform_driver_unregister(ipp_driver);
-out_ipp:
+err_unregister_gsc_drv:
#endif
#ifdef CONFIG_DRM_EXYNOS_GSC
platform_driver_unregister(gsc_driver);
-out_gsc:
+err_unregister_rotator_drv:
#endif
#ifdef CONFIG_DRM_EXYNOS_ROTATOR
platform_driver_unregister(rotator_driver);
-out_rotator:
+err_unregister_fimc_drv:
#endif
#ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(fimc_driver);
-out_fimc:
+err_unregister_g2d_drv:
#endif
#ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(g2d_driver);
-out_g2d:
+err_unregister_vidi_drv:
#endif
#ifdef CONFIG_DRM_EXYNOS_VIDI
platform_driver_unregister(vidi_driver);
-out_vidi:
+err_unregister_mixer_drv:
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(mixer_driver);
-out_mixer:
+err_unregister_hdmi_drv:
platform_driver_unregister(hdmi_driver);
-out_hdmi:
+err_unregister_fimd_drv:
#endif
#ifdef CONFIG_DRM_EXYNOS_FIMD
platform_driver_unregister(fimd_driver);
-out_fimd:
+err_unregister_dsi_drv:
#endif
#ifdef CONFIG_DRM_EXYNOS_DSI
platform_driver_unregister(dsi_driver);
-out_dsi:
+err_unregister_dp_drv:
#endif
#ifdef CONFIG_DRM_EXYNOS_DP
platform_driver_unregister(dp_driver);
-out_dp:
#endif
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] drm/exynos: separate dpi from fimd
From: Andrzej Hajda a.ha...@samsung.com
The patch separates dpi related routines from fimd.
Changelog v2:
- Rename ctx-dpi to ctx-display
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 40 +--
drivers/gpu/drm/exynos/exynos_drm_drv.h | 15 ++--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 109 --
3 files changed, 69 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index ac206e7..03cb126 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -40,20 +40,10 @@ exynos_dpi_detect(struct drm_connector *connector, bool
force)
{
struct exynos_dpi *ctx = connector_to_dpi(connector);
- /* panels supported only by boot-loader are always connected */
- if (!ctx-panel_node)
- return connector_status_connected;
-
- if (!ctx-panel) {
- ctx-panel = of_drm_find_panel(ctx-panel_node);
- if (ctx-panel)
- drm_panel_attach(ctx-panel, ctx-connector);
- }
+ if (!ctx-panel-connector)
+ drm_panel_attach(ctx-panel, ctx-connector);
- if (ctx-panel)
- return connector_status_connected;
-
- return connector_status_disconnected;
+ return connector_status_connected;
}
static void exynos_dpi_connector_destroy(struct drm_connector *connector)
@@ -291,8 +281,10 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
return -ENOMEM;
ret = of_get_videomode(dn, vm, 0);
- if (ret 0)
+ if (ret 0) {
+ devm_kfree(dev, vm);
return ret;
+ }
ctx-vm = vm;
@@ -305,27 +297,35 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
return 0;
}
-int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev)
+struct exynos_drm_display *exynos_dpi_probe(struct device *dev)
{
struct exynos_dpi *ctx;
int ret;
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
- return -ENOMEM;
+ return NULL;
ctx-dev = dev;
exynos_dpi_display.ctx = ctx;
ctx-dpms_mode = DRM_MODE_DPMS_OFF;
ret = exynos_dpi_parse_dt(ctx);
- if (ret 0)
- return ret;
+ if (ret 0) {
+ devm_kfree(dev, ctx);
+ return NULL;
+ }
+
+ if (ctx-panel_node) {
+ ctx-panel = of_drm_find_panel(ctx-panel_node);
+ if (!ctx-panel)
+ return ERR_PTR(-EPROBE_DEFER);
+ }
- return exynos_drm_create_enc_conn(drm_dev, exynos_dpi_display);
+ return exynos_dpi_display;
}
-int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev)
+int exynos_dpi_remove(struct device *dev)
{
struct drm_encoder *encoder = exynos_dpi_display.encoder;
struct exynos_dpi *ctx = exynos_dpi_display.ctx;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 3aee01b..d955f60 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -334,17 +334,12 @@ int exynos_platform_device_ipp_register(void);
void exynos_platform_device_ipp_unregister(void);
#ifdef CONFIG_DRM_EXYNOS_DPI
-int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev);
-int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev);
-struct device_node *exynos_dpi_of_find_panel_node(struct device *dev);
+struct exynos_drm_display * exynos_dpi_probe(struct device *dev);
+int exynos_dpi_remove(struct device *dev);
#else
-static inline int exynos_dpi_probe(struct drm_device *drm_dev,
- struct device *dev) { return 0; }
-static inline int exynos_dpi_remove(struct drm_device *drm_dev,
- struct device *dev) { return 0; }
-static inline struct device_node
- *exynos_dpi_of_find_panel_node(struct device *dev)
-{ return NULL; }
+static inline struct exynos_drm_display *
+exynos_dpi_probe(struct device *dev) { return 0; }
+static inline int exynos_dpi_remove(struct device *dev) { return 0; }
#endif
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bab870c..a6d6386 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -24,7 +24,6 @@
#include video/of_display_timing.h
#include video/of_videomode.h
#include video/samsung_fimd.h
-#include drm/drm_panel.h
#include drm/exynos_drm.h
#include exynos_drm_drv.h
@@ -124,6 +123,7 @@ struct fimd_context {
struct exynos_drm_panel_info panel;
struct
[PATCH] drm/exynos: dsi: remove unnecessary pm interfaces
Exynos drm driver is a single driver so pm operation
for kms drivers should be done by connector-dpms
at top level driver.
If kms driver has its own pm interfaces, single driver model
would be broken so this patch removes unnecessary pm interfaces
from dsi driver.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 31 ---
1 file changed, 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 09cc4bae..ae81124 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1412,36 +1412,6 @@ static void exynos_dsi_unbind(struct device *dev, struct
device *master,
drm_connector_cleanup(dsi-connector);
}
-#if CONFIG_PM_SLEEP
-static int exynos_dsi_resume(struct device *dev)
-{
- struct exynos_dsi *dsi = exynos_dsi_display.ctx;
-
- if (dsi-state DSIM_STATE_ENABLED) {
- dsi-state = ~DSIM_STATE_ENABLED;
- exynos_dsi_enable(dsi);
- }
-
- return 0;
-}
-
-static int exynos_dsi_suspend(struct device *dev)
-{
- struct exynos_dsi *dsi = exynos_dsi_display.ctx;
-
- if (dsi-state DSIM_STATE_ENABLED) {
- exynos_dsi_disable(dsi);
- dsi-state |= DSIM_STATE_ENABLED;
- }
-
- return 0;
-}
-#endif
-
-static const struct dev_pm_ops exynos_dsi_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(exynos_dsi_suspend, exynos_dsi_resume)
-};
-
static const struct component_ops exynos_dsi_component_ops = {
.bind = exynos_dsi_bind,
.unbind = exynos_dsi_unbind,
@@ -1545,7 +1515,6 @@ struct platform_driver dsi_driver = {
.driver = {
.name = exynos-dsi,
.owner = THIS_MODULE,
- .pm = exynos_dsi_pm_ops,
.of_match_table = exynos_dsi_of_match,
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: remove unnecessary runtime pm interfaces
Exyno drm driver has no real hardware device, and
runtime pm operation should be done by sub drivers.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 6fa6f07..ab8ffbb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -378,34 +378,8 @@ static int exynos_drm_sys_resume(struct device *dev)
}
#endif
-#ifdef CONFIG_PM_RUNTIME
-static int exynos_drm_runtime_suspend(struct device *dev)
-{
- struct drm_device *drm_dev = dev_get_drvdata(dev);
- pm_message_t message;
-
- if (pm_runtime_suspended(dev))
- return 0;
-
- message.event = PM_EVENT_SUSPEND;
- return exynos_drm_suspend(drm_dev, message);
-}
-
-static int exynos_drm_runtime_resume(struct device *dev)
-{
- struct drm_device *drm_dev = dev_get_drvdata(dev);
-
- if (!pm_runtime_suspended(dev))
- return 0;
-
- return exynos_drm_resume(drm_dev);
-}
-#endif
-
static const struct dev_pm_ops exynos_drm_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_sys_suspend, exynos_drm_sys_resume)
- SET_RUNTIME_PM_OPS(exynos_drm_runtime_suspend,
- exynos_drm_runtime_resume, NULL)
};
int exynos_drm_component_add(struct device *dev,
@@ -488,9 +462,6 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
static int exynos_drm_bind(struct device *dev)
{
- pm_runtime_enable(dev);
- pm_runtime_get_sync(dev);
-
return drm_platform_init(exynos_drm_driver, to_platform_device(dev));
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] exynos/drm: add DT bindings
This patch adds bindings for Exynos drm display subsystem.
The bindings describes ports containing a list of phandles
pointing to display controller, image enhancer, and display
interfaces nodes.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/drm/exynos/samsung-exynos-drm.txt | 32
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
diff --git
a/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
new file mode 100644
index 000..6f7fae0
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
@@ -0,0 +1,32 @@
+Samsung Exynos DRM master device
+
+
+The Samsung Exynos DRM master device is a virtual device needed to list all
+display controller, image enhancer, and display interface nodes that comprise
+the graphics subsystem.
+
+Required properties:
+- compatible: Should be samsung,exynos-display-subsystem
+- ports: Should contain a list of phandles pointing to display controller,
+ image enhancer, and display interface ports.
+
+Examples:
+
+In case of using MIPI-DSI,
+display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd, dsi;
+};
+
+
+In case of using DisplayPort,
+display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd, dp;
+};
+
+In case of using parallel panel,
+display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] drm/exynos: dpi: fix hotplug fail issue
When connector is created, if connector-polled is DRM_CONNECTOR_POLL_CONNECT then drm_kms_helper_hotplug_event function isn't called at drm_helper_hpd_irq_event because the function will be called only in case of DRM_CONNECTOR_POLL_HPD. So this patch sets always DRM_CONNECTOR_POLL_HPD flag to connector-polled of parallel panel driver at connector creation. Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_dpi.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c index c1f4b35..ac206e7 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c @@ -123,10 +123,7 @@ static int exynos_dpi_create_connector(struct exynos_drm_display *display, ctx-encoder = encoder; - if (ctx-panel_node) - connector-polled = DRM_CONNECTOR_POLL_CONNECT; - else - connector-polled = DRM_CONNECTOR_POLL_HPD; + connector-polled = DRM_CONNECTOR_POLL_HPD; ret = drm_connector_init(encoder-dev, connector, exynos_dpi_connector_funcs, -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/9] drm/exynos: more cleanup with super device support
This patch series cleans up exynos drm framework and kms sub drivers using the component framework[1] [1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html Previous patches, RFC: http://comments.gmane.org/gmane.comp.video.dri.devel/101200 v1: http://lists.freedesktop.org/archives/dri-devel/2014-March/056387.html v2: http://www.spinics.net/lists/dri-devel/msg56372.html Changelog v3: - Add a patch for separating dpi from fimd - Add legacy dt binding support - Add more cleanup patches Thanks, Inki Dae Andrzej Hajda (1): drm/exynos: separate dpi from fimd Inki Dae (8): drm/exynos: add super device support drm/exynos: dpi: fix hotplug fail issue ARM: dts: exynos4210-universal: add super device node for exynos drm ARM: dts: exynos4210-trats: add super device node for exynos drm ARM: dts: exynos4412-trats2: add super device node for exynos drm exynos/drm: add DT bindings drm/exynos: fix comment to exynos_drm_device_subdrv_prove call drm/exynos: modify goto labels to meaningful names .../bindings/drm/exynos/samsung-exynos-drm.txt | 32 ++ arch/arm/boot/dts/exynos4210-trats.dts |5 + arch/arm/boot/dts/exynos4210-universal_c210.dts|5 + arch/arm/boot/dts/exynos4412-trats2.dts|5 + drivers/gpu/drm/exynos/exynos_dp_core.c| 45 +-- drivers/gpu/drm/exynos/exynos_drm_core.c | 216 +++--- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 ++ drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 + drivers/gpu/drm/exynos/exynos_drm_dpi.c| 51 ++-- drivers/gpu/drm/exynos/exynos_drm_drv.c| 313 +--- drivers/gpu/drm/exynos/exynos_drm_drv.h| 69 ++--- drivers/gpu/drm/exynos/exynos_drm_dsi.c| 110 --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 74 +++-- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 101 +-- drivers/gpu/drm/exynos/exynos_hdmi.c | 59 ++-- drivers/gpu/drm/exynos/exynos_mixer.c | 54 +++- 16 files changed, 675 insertions(+), 485 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/9] drm/exynos: add super device support
This patch adds super device support to bind sub drivers
using device tree.
For this, you should add a super device node to each machine dt files
like belows,
In case of using MIPI-DSI,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd, dsi;
};
In case of using DisplayPort,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd, dp;
};
In case of using Parallel panel,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd;
};
And if you don't add connector device node to ports property,
default parallel panel driver, exynos_drm_dpi module, will be used.
ports property can have the following device nodes,
fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI
With this patch, we can resolve the probing order issue without
some global lists. So this patch also removes the unnecessary lists and
stuff related to these lists.
Previous RFC patch,
http://www.spinics.net/lists/dri-devel/msg54671.html
Changelog since RFC patch:
- Register sub drivers and probe them at load(). In case of non sub
drivers, sub driver probe is needed.
- Enable runtime pm at fimd_probe() instead of fimd_bind(). runtime pm
should be enabled before iommu device is attached to fimd device.
- Do not return an error with component_master_add fail.
- Remove super device support from mipi dsi driver which was in RFC.
- Add super device support to parallel driver.
Changelog v2:
- Add super device support to mipi dsi driver.
- Bind fimd driver only in case that a drm_panel for parallel panel driver
is added to panel_list of drm_panel module.
- Change super node name to 'display-subsystem'
. 'exynos-drm' is specific to Linux so change it to generic name.
- Change propery name of super node to 'ports'
. crtcs and connectors propery names are also specific to Linux so
change them to generic name.
Changlog v3:
- Do not probe/remove dpi module if fimd node has no port node.
Changelog v4:
- Move some codes for getting resources from each bind function to
each probe function.
. if -EPROBE_DEFER is returned at bind context, components will be
bound and unbound repeatedly by deferred probe feature.
Changelog v5:
- Return error only in case that there is no any compoment attached
to master.
- Add legacy dt binding support
- Probe vidi driver in exynos_drm_init(), and release vidi driver
correctly.
- Remove duplicated coherent_dma_mask setting.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 45 +++--
drivers/gpu/drm/exynos/exynos_drm_core.c | 216 ---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 ++
drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 +
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 16 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 273 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 78 -
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 110 +++-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 87 --
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 101 +--
drivers/gpu/drm/exynos/exynos_hdmi.c | 59 ---
drivers/gpu/drm/exynos/exynos_mixer.c| 54 --
12 files changed, 616 insertions(+), 444 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index aed533b..1cc3981 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/of.h
+#include linux/component.h
#include linux/phy/phy.h
#include video/of_display_timing.h
#include video/of_videomode.h
@@ -969,16 +970,6 @@ static struct drm_connector_helper_funcs
exynos_dp_connector_helper_funcs = {
.best_encoder = exynos_dp_best_encoder,
};
-static int exynos_dp_initialize(struct exynos_drm_display *display,
- struct drm_device *drm_dev)
-{
- struct exynos_dp_device *dp = display-ctx;
-
- dp-drm_dev = drm_dev;
-
- return 0;
-}
-
static bool find_bridge(const char *compat, struct bridge_init *bridge)
{
bridge-client = NULL;
@@ -1106,7 +1097,6 @@ static void exynos_dp_dpms(struct exynos_drm_display
*display, int mode)
}
static struct exynos_drm_display_ops exynos_dp_display_ops = {
- .initialize = exynos_dp_initialize,
.create_connector = exynos_dp_create_connector,
.dpms = exynos_dp_dpms,
};
@@ -1230,8 +1220,10 @@ static int exynos_dp_dt_parse_panel(struct
exynos_dp_device *dp)
return 0;
}
-static int exynos_dp_probe(struct platform_device *pdev)
+static int exynos_dp_bind(struct device *dev, struct device *master, void
*data
[PATCH 3/9] ARM: dts: exynos4210-universal: add super device node for exynos drm
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4210-universal_c210.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 0a80a72..5351ac4 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -409,6 +409,11 @@
};
};
+ display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd;
+ };
+
pwm@139D {
compatible = samsung,s5p6440-pwm;
status = okay;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] ARM: dts: exynos4412-trats2: add super device node for exynos drm
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4412-trats2.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 53c717b..115b9ed 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -581,6 +581,11 @@
status = okay;
};
+ display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd, dsi_0;
+ };
+
camera {
pinctrl-0 = cam_port_b_clk_active;
pinctrl-names = default;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/9] drm/exynos: separate dpi from fimd
From: Andrzej Hajda a.ha...@samsung.com
The patch separates dpi related routines from fimd.
Changelog v2:
- Rename ctx-dpi to ctx-display
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 40 +--
drivers/gpu/drm/exynos/exynos_drm_drv.h | 15 ++--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 109 --
3 files changed, 69 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index ac206e7..03cb126 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -40,20 +40,10 @@ exynos_dpi_detect(struct drm_connector *connector, bool
force)
{
struct exynos_dpi *ctx = connector_to_dpi(connector);
- /* panels supported only by boot-loader are always connected */
- if (!ctx-panel_node)
- return connector_status_connected;
-
- if (!ctx-panel) {
- ctx-panel = of_drm_find_panel(ctx-panel_node);
- if (ctx-panel)
- drm_panel_attach(ctx-panel, ctx-connector);
- }
+ if (!ctx-panel-connector)
+ drm_panel_attach(ctx-panel, ctx-connector);
- if (ctx-panel)
- return connector_status_connected;
-
- return connector_status_disconnected;
+ return connector_status_connected;
}
static void exynos_dpi_connector_destroy(struct drm_connector *connector)
@@ -291,8 +281,10 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
return -ENOMEM;
ret = of_get_videomode(dn, vm, 0);
- if (ret 0)
+ if (ret 0) {
+ devm_kfree(dev, vm);
return ret;
+ }
ctx-vm = vm;
@@ -305,27 +297,35 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
return 0;
}
-int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev)
+struct exynos_drm_display *exynos_dpi_probe(struct device *dev)
{
struct exynos_dpi *ctx;
int ret;
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
- return -ENOMEM;
+ return NULL;
ctx-dev = dev;
exynos_dpi_display.ctx = ctx;
ctx-dpms_mode = DRM_MODE_DPMS_OFF;
ret = exynos_dpi_parse_dt(ctx);
- if (ret 0)
- return ret;
+ if (ret 0) {
+ devm_kfree(dev, ctx);
+ return NULL;
+ }
+
+ if (ctx-panel_node) {
+ ctx-panel = of_drm_find_panel(ctx-panel_node);
+ if (!ctx-panel)
+ return ERR_PTR(-EPROBE_DEFER);
+ }
- return exynos_drm_create_enc_conn(drm_dev, exynos_dpi_display);
+ return exynos_dpi_display;
}
-int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev)
+int exynos_dpi_remove(struct device *dev)
{
struct drm_encoder *encoder = exynos_dpi_display.encoder;
struct exynos_dpi *ctx = exynos_dpi_display.ctx;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a589dfb..257ce09 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -334,17 +334,12 @@ int exynos_platform_device_ipp_register(void);
void exynos_platform_device_ipp_unregister(void);
#ifdef CONFIG_DRM_EXYNOS_DPI
-int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev);
-int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev);
-struct device_node *exynos_dpi_of_find_panel_node(struct device *dev);
+struct exynos_drm_display * exynos_dpi_probe(struct device *dev);
+int exynos_dpi_remove(struct device *dev);
#else
-static inline int exynos_dpi_probe(struct drm_device *drm_dev,
- struct device *dev) { return 0; }
-static inline int exynos_dpi_remove(struct drm_device *drm_dev,
- struct device *dev) { return 0; }
-static inline struct device_node
- *exynos_dpi_of_find_panel_node(struct device *dev)
-{ return NULL; }
+static inline struct exynos_drm_display *
+exynos_dpi_probe(struct device *dev) { return 0; }
+static inline int exynos_dpi_remove(struct device *dev) { return 0; }
#endif
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b26b27e..dd8637b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -24,7 +24,6 @@
#include video/of_display_timing.h
#include video/of_videomode.h
#include video/samsung_fimd.h
-#include drm/drm_panel.h
#include drm/exynos_drm.h
#include exynos_drm_drv.h
@@ -124,6 +123,7 @@ struct fimd_context {
struct exynos_drm_panel_info panel;
struct
[PATCH 9/9] drm/exynos: modify goto labels to meaningful names
Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 40 +++ 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index cdd74e2..1d1c604 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -508,56 +508,56 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) #ifdef CONFIG_DRM_EXYNOS_DSI ret = platform_driver_register(dsi_driver); if (ret 0) - goto out_dsi; + goto err_unregister_dp; #endif #ifdef CONFIG_DRM_EXYNOS_FIMD ret = platform_driver_register(fimd_driver); if (ret 0) - goto out_fimd; + goto err_unregister_dsi; #endif #ifdef CONFIG_DRM_EXYNOS_HDMI ret = platform_driver_register(hdmi_driver); if (ret 0) - goto out_hdmi; + goto err_unregister_fimd; ret = platform_driver_register(mixer_driver); if (ret 0) - goto out_mixer; + goto err_unregister_hdmi; #endif #ifdef CONFIG_DRM_EXYNOS_G2D ret = platform_driver_register(g2d_driver); if (ret 0) - goto out_g2d; + goto err_unregister_mixer; #endif #ifdef CONFIG_DRM_EXYNOS_FIMC ret = platform_driver_register(fimc_driver); if (ret 0) - goto out_fimc; + goto err_unregister_g2d; #endif #ifdef CONFIG_DRM_EXYNOS_ROTATOR ret = platform_driver_register(rotator_driver); if (ret 0) - goto out_rotator; + goto err_unregister_fimc; #endif #ifdef CONFIG_DRM_EXYNOS_GSC ret = platform_driver_register(gsc_driver); if (ret 0) - goto out_gsc; + goto err_unregister_rotator; #endif #ifdef CONFIG_DRM_EXYNOS_IPP ret = platform_driver_register(ipp_driver); if (ret 0) - goto out_ipp; + goto err_unregister_gsc; ret = exynos_platform_device_ipp_register(); if (ret 0) - goto out_ipp_dev; + goto err_unregister_ipp; #endif ret = component_master_add(pdev-dev, exynos_drm_ops); @@ -568,46 +568,46 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) #ifdef CONFIG_DRM_EXYNOS_IPP exynos_platform_device_ipp_unregister(); -out_ipp_dev: +err_unregister_ipp: platform_driver_unregister(ipp_driver); -out_ipp: +err_unregister_gsc: #endif #ifdef CONFIG_DRM_EXYNOS_GSC platform_driver_unregister(gsc_driver); -out_gsc: +err_unregister_rotator: #endif #ifdef CONFIG_DRM_EXYNOS_ROTATOR platform_driver_unregister(rotator_driver); -out_rotator: +err_unregister_fimc: #endif #ifdef CONFIG_DRM_EXYNOS_FIMC platform_driver_unregister(fimc_driver); -out_fimc: +err_unregister_g2d: #endif #ifdef CONFIG_DRM_EXYNOS_G2D platform_driver_unregister(g2d_driver); -out_g2d: +err_unregister_mixer: #endif #ifdef CONFIG_DRM_EXYNOS_HDMI platform_driver_unregister(mixer_driver); -out_mixer: +err_unregister_hdmi: platform_driver_unregister(hdmi_driver); -out_hdmi: +err_unregister_fimd: #endif #ifdef CONFIG_DRM_EXYNOS_FIMD platform_driver_unregister(fimd_driver); -out_fimd: +err_unregister_dsi: #endif #ifdef CONFIG_DRM_EXYNOS_DSI platform_driver_unregister(dsi_driver); -out_dsi: +err_unregister_dp: #endif #ifdef CONFIG_DRM_EXYNOS_DP -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] drm/exynos: fix comment to exynos_drm_device_subdrv_prove call
subdrv_probe callback of virtual display driver will be called by exynos_drm_device_subdrv_probe() to create crtc and encoder/connector for virtual display driver. So it fixes comments to exynos_drm_device_subdrv probe call. Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 63dabba..cdd74e2 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -101,7 +101,7 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) if (ret) goto err_cleanup_vblank; - /* Probe non kms sub drivers. */ + /* Probe non kms sub drivers and virtual display driver. */ ret = exynos_drm_device_subdrv_probe(dev); if (ret) goto err_unbind_all; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] ARM: dts: exynos4210-trats: add super device node for exynos drm
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4210-trats.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 02c6768..a41c109 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -414,6 +414,11 @@
status = okay;
};
+ display-subsystem {
+ compatible = samsung,exynos-display-subsystem;
+ ports = fimd, dsi_0;
+ };
+
camera {
pinctrl-names = default;
pinctrl-0 = ;
--
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 RFC 0/2] drm/exynos: refactoring drm device init/deinit
-Original Message- From: Andrzej Hajda [mailto:a.ha...@samsung.com] Sent: Monday, April 14, 2014 5:55 PM To: Inki Dae Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...; Kyungmin Park; Marek Szyprowski Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit On 04/12/2014 04:18 PM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-04-11 23:11 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi Inki, This patchset refactors drm device initialization. Details are described in respective patches. It is an alternative to DT supernode concept. The first patch uses linker sections to get rid of ifdef macros, it is not That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this way. essential for 2nd patch but it makes code more readable. Similar approach is used by irqchip, clks and clk_sources. But 2nd patch doesn't seem reasnoable to me. Your approach is same as existing one conceptually. I think we need to handle drm driver in a different way from irqchip, clks and clk_sources. DRM driver means one integrated graphics card but in most embedded systems, graphics and display relevant devices have separated hardware resources. So we would need abstractional integrated hardware, display-subsystem, super device. That is why I are trying to use super device approach, and conceptually it would be right solution. It wouldn't be not good to combine those separated hardware somehow using specific codes. Conceptually both approaches are the same: we have number of devices which should be ready before we can start super-device and if any device is to be removed super-device should be removed before. The difference is in 'details': - super-node approach have list of components provided explicitly in DT special node, - in this approach list of components is constructed from devices present in the system. Creating special DT node with information which is available anyway seems to be redundant and against DT rules. CCing Russell King, What is the special DT node? You mean device node from ports property? It is supposed to use super device and its properties in mainline so I don't see what it is against DT rules. If they are really against DT rules, why component framework is in mainline? As you said above, conceptually both approaches may be the same but your approach has no any abstract hardware meaning one integrated hardware. And if conceptually both approaches are the same, it would be good to use existing infrastructure, component framework so there is no any reason to add and use specific codes. And component framework says, Subsystems such as ALSA, DRM and others require a single card-level device structure to represent a subsystem. However, firmware tends to describe the individual devices and the connections between them. Therefore, we need a way to gather up the individual component devices together, and indicate when we have all the component devices. Thanks, Inki Dae Regarding the old approach, I would not compare it with the current ones as it has two main flaws: - it is not aware of deferred probing, or more precisely it assumes that driver registration instantly triggers device probing (it happens to be true) and no probe of drm component will happen later (and this is false assumption, eg. deferred probe), - it do not remove super-device in case of removal of any of components. Regards Andrzej I have updated and tested super device approach with existing dt support so there wouldn't be any dt broken issue. I will post next version of this patch series soon, maybe tomorrow or the day after tomorrow. Thanks, Inki Dae The patchset is based on exynos-drm-next branch. Regards Andrzej Andrzej Hajda (2): drm/exynos: refactor drm drivers registration code drm/exynos: initialize drm master only when all exynos drm devices are ready drivers/gpu/drm/exynos/Makefile | 2 + drivers/gpu/drm/exynos/exynos_dp_core.c | 37 ++-- drivers/gpu/drm/exynos/exynos_drm.lds.S | 9 + drivers/gpu/drm/exynos/exynos_drm_drv.c | 279 + --- drivers/gpu/drm/exynos/exynos_drm_drv.h | 20 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 42 +++-- drivers/gpu/drm/exynos/exynos_drm_fimc.c| 35 ++-- drivers/gpu/drm/exynos/exynos_drm_fimd.c| 38 ++-- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 17 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 30 +-- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 18 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 27 ++- drivers/gpu/drm/exynos/exynos_drm_vidi.c| 18 +- drivers/gpu/drm/exynos/exynos_hdmi.c| 53 -- drivers/gpu/drm/exynos/exynos_mixer.c | 14 +- 15 files changed, 360 insertions(+), 279 deletions(-) create mode 100644 drivers/gpu/drm/exynos
RE: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit
Hi Tomasz, Always thanks for your opinions. -Original Message- From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc- ow...@vger.kernel.org] On Behalf Of Tomasz Figa Sent: Monday, April 14, 2014 8:32 PM To: Inki Dae; 'Andrzej Hajda' Cc: 'Kyungmin Park'; 'moderated list:ARM/S5P EXYNOS AR...'; 'Russell King'; dri-de...@lists.freedesktop.org; 'Marek Szyprowski' Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit Hi Inki, On 14.04.2014 13:04, Inki Dae wrote: -Original Message- From: Andrzej Hajda [mailto:a.ha...@samsung.com] Sent: Monday, April 14, 2014 5:55 PM To: Inki Dae Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...; Kyungmin Park; Marek Szyprowski Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit On 04/12/2014 04:18 PM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-04-11 23:11 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi Inki, This patchset refactors drm device initialization. Details are described in respective patches. It is an alternative to DT supernode concept. The first patch uses linker sections to get rid of ifdef macros, it is not That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this way. essential for 2nd patch but it makes code more readable. Similar approach is used by irqchip, clks and clk_sources. But 2nd patch doesn't seem reasnoable to me. Your approach is same as existing one conceptually. I think we need to handle drm driver in a different way from irqchip, clks and clk_sources. DRM driver means one integrated graphics card but in most embedded systems, graphics and display relevant devices have separated hardware resources. So we would need abstractional integrated hardware, display-subsystem, super device. That is why I are trying to use super device approach, and conceptually it would be right solution. It wouldn't be not good to combine those separated hardware somehow using specific codes. Conceptually both approaches are the same: we have number of devices which should be ready before we can start super-device and if any device is to be removed super-device should be removed before. The difference is in 'details': - super-node approach have list of components provided explicitly in DT special node, - in this approach list of components is constructed from devices present in the system. Creating special DT node with information which is available anyway seems to be redundant and against DT rules. CCing Russell King, What is the special DT node? You mean device node from ports property? It is supposed to use super device and its properties in mainline so I don't see what it is against DT rules. If they are really against DT rules, why component framework is in mainline? Component framework in mainline doesn't have anything in common with DT. All it does is providing tools for handling cases where a subsystem can be initialized only after all components are available. It doesn't define any means of getting the list of components, it's a task for the user of this framework to provide it. As you said above, conceptually both approaches may be the same but your approach has no any abstract hardware meaning one integrated hardware. And if conceptually both approaches are the same, it would be good to use existing infrastructure, component framework so there is no any reason to add and use specific codes. What do you mean by abstract hardware? Physically, in the SoC, there is no single integrated hardware block, but multiple IPs and they need to be described this way in DT. There is nothing that prevents using them separately if a user doesn't want to use Exynos DRM. Exynos DRM is a I don't think that super device approach prevents using existing device nodes separately. If a user doesn't want to use Exynos DRM, he cannot declare the super node and each IP would work well in existing way. There would be nothing to change existing device nodes. Linux-specific thing and its details should not be leaked into DT, which is a _hardware_ description method. And component framework says, Subsystems such as ALSA, DRM and others require a single card-level device structure to represent a subsystem. However, firmware tends to describe the individual devices and the connections between them. Therefore, we need a way to gather up the individual component devices together, and indicate when we have all the component devices. Note following things: - Nothing in the quote above says that an additional DT node must be added. The framework works on generic driver model level, above the description level (such as DT). And also the component framework says, We do this in DT by providing a superdevice node which specifies the components, eg: imx-drm
Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit
Hi Andrzej, Thanks for your contributions. 2014-04-11 23:11 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi Inki, This patchset refactors drm device initialization. Details are described in respective patches. It is an alternative to DT supernode concept. The first patch uses linker sections to get rid of ifdef macros, it is not That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this way. essential for 2nd patch but it makes code more readable. Similar approach is used by irqchip, clks and clk_sources. But 2nd patch doesn't seem reasnoable to me. Your approach is same as existing one conceptually. I think we need to handle drm driver in a different way from irqchip, clks and clk_sources. DRM driver means one integrated graphics card but in most embedded systems, graphics and display relevant devices have separated hardware resources. So we would need abstractional integrated hardware, display-subsystem, super device. That is why I are trying to use super device approach, and conceptually it would be right solution. It wouldn't be not good to combine those separated hardware somehow using specific codes. I have updated and tested super device approach with existing dt support so there wouldn't be any dt broken issue. I will post next version of this patch series soon, maybe tomorrow or the day after tomorrow. Thanks, Inki Dae The patchset is based on exynos-drm-next branch. Regards Andrzej Andrzej Hajda (2): drm/exynos: refactor drm drivers registration code drm/exynos: initialize drm master only when all exynos drm devices are ready drivers/gpu/drm/exynos/Makefile | 2 + drivers/gpu/drm/exynos/exynos_dp_core.c | 37 ++-- drivers/gpu/drm/exynos/exynos_drm.lds.S | 9 + drivers/gpu/drm/exynos/exynos_drm_drv.c | 279 +--- drivers/gpu/drm/exynos/exynos_drm_drv.h | 20 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 42 +++-- drivers/gpu/drm/exynos/exynos_drm_fimc.c| 35 ++-- drivers/gpu/drm/exynos/exynos_drm_fimd.c| 38 ++-- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 17 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 30 +-- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 18 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 27 ++- drivers/gpu/drm/exynos/exynos_drm_vidi.c| 18 +- drivers/gpu/drm/exynos/exynos_hdmi.c| 53 -- drivers/gpu/drm/exynos/exynos_mixer.c | 14 +- 15 files changed, 360 insertions(+), 279 deletions(-) create mode 100644 drivers/gpu/drm/exynos/exynos_drm.lds.S -- 1.8.3.2 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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/7] drm/exynos: add super device support
2014-04-08 0:40 GMT+09:00, Tomasz Figa tomasz.f...@gmail.com:
On 07.04.2014 17:16, Inki Dae wrote:
Hi Andrzej,
2014-04-07 23:18 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:
Hi Inki and Tomasz,
On 04/06/2014 05:15 AM, Inki Dae wrote:
(...)
The code creating the list of components to wait for
(exynos_drm_add_components()) doesn't seem to consider which sub-drivers
are
actually enabled in kernel config.
Are you sure?
exynos_drm_add_components() will try to attach components *added to
component_lists. And these components will be added by only
corresponding sub drivers to the component_lists and
master-components.
So in this case, if users disabled HDMI support then a commponent
object for HDMI sub driver doesn't exists in the component_lists and
master-components. This means that a component object for HDMI sub
driver *cannot be attached to master object*.
As a result, component_bind_add() will ignor component_bind call for
HDMI sub driver so HDMI driver will not be bounded. The only
components added by sub drivers will be bound, component-ops-bind().
For more understanding, it seems like you need to look into below
codes,
static int exynos_drm_add_components(...)
{
...
for (i == 0;; i++) {
...
node = of_parse_phandle(np, ports, i);
...
ret = component_master_add_child(m, compare_of, node);
...
}
}
Hmm, In case HDMI driver is not present, HDMI device is not probed and
HDMI component is not added, so component_master_add_child returns
an error when it tries to add hdmi component and master is never brought
up, am I correct?
Ok, after that,
ret = component_master_add(,..)
if (ret 0)
DRM_DEBUG_KMS(re-tried by last sub driver probed later.\n);
As you can see above, if component_master_add() is failed, return 0,
*not error*. And then component_add() called by other kms drivers,
late probing of hdmi or fimd probing - if there is any kms driver
enabled - will try to bring up master again by calling
try_to_bring_up_master() from beginning.
And if component_list is empty then it means that there is no any kms
driver enabled.
Do you still think in that case, exynos drm initialization will be
failed?
There will be no HDMI driver to call component_add(), because HDMI sub
driver will be disabled in kernel config and any previous
component_master_add_child() for the phandle pointing to HDMI node will
wail, because such component will never be registered.
The complete failure path is as follows:
exynos_drm_platform_probe()
component_master_add()
try_to_bring_up_master()
exynos_drm_add_components()
// phandle to HDMI node
component_master_add_child()
= -ENXIO
= -ENXIO
= 0 // but no call to master-ops-bind(master-dev);
= 0
= 0 // but Exynos DRM platform is not registered yet
Now if any other late-probed sub-driver comes, the sequence will be as
follows (let's take FIMD as an example):
fimd_probe()
component_add()
try_to_bring_up_masters()
try_to_bring_up_master()
exynos_drm_add_components()
// phandle to HDMI node
component_master_add_child()
= -ENXIO
= -ENXIO
= 0 // but no call to
// master-ops-bind(master-dev);
= 0
= 0
= 0 // but Exynos DRM platform still not registered
And the same for any late-probed driver, unless HDMI drivers loads, but
there is no HDMI driver, because it is disabled in kernel config and not
compiled in.
Ah, right. I missed that it gets phandle to hdmi, and compares the
phandle to one in component_list.
Yes, in this case, exynos drm driver will be failed because
component_list never has a component object for hdmi.
So this shouldn't return as long as there is any component - in
component_list - that can be attached to master.
Hm.. the foot of the candle is dark.
For this, I fixed and tested it like below,
for (i = 0;; i++) {
node = of_parse_phandle(np, ports, i);
...
ret = component_master_add_child(...);
...
if (!ret)
attached_cnt++;
}
if (!attached_cnt)
return -ENXIO;
...
And one more thing, it seems that we could resolve dt broken issue
easily by getting phandle to existing device node directly.
Thanks,
Inki Dae
Best regards,
Tomasz
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line
Re: [PATCH v2 1/7] drm/exynos: add super device support
Hi Andrzej,
2014-04-07 23:18 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:
Hi Inki and Tomasz,
On 04/06/2014 05:15 AM, Inki Dae wrote:
(...)
The code creating the list of components to wait for
(exynos_drm_add_components()) doesn't seem to consider which sub-drivers are
actually enabled in kernel config.
Are you sure?
exynos_drm_add_components() will try to attach components *added to
component_lists. And these components will be added by only
corresponding sub drivers to the component_lists and
master-components.
So in this case, if users disabled HDMI support then a commponent
object for HDMI sub driver doesn't exists in the component_lists and
master-components. This means that a component object for HDMI sub
driver *cannot be attached to master object*.
As a result, component_bind_add() will ignor component_bind call for
HDMI sub driver so HDMI driver will not be bounded. The only
components added by sub drivers will be bound, component-ops-bind().
For more understanding, it seems like you need to look into below codes,
static int exynos_drm_add_components(...)
{
...
for (i == 0;; i++) {
...
node = of_parse_phandle(np, ports, i);
...
ret = component_master_add_child(m, compare_of, node);
...
}
}
Hmm, In case HDMI driver is not present, HDMI device is not probed and
HDMI component is not added, so component_master_add_child returns
an error when it tries to add hdmi component and master is never brought
up, am I correct?
Ok, after that,
ret = component_master_add(,..)
if (ret 0)
DRM_DEBUG_KMS(re-tried by last sub driver probed later.\n);
As you can see above, if component_master_add() is failed, return 0,
*not error*. And then component_add() called by other kms drivers,
late probing of hdmi or fimd probing - if there is any kms driver
enabled - will try to bring up master again by calling
try_to_bring_up_master() from beginning.
And if component_list is empty then it means that there is no any kms
driver enabled.
Do you still think in that case, exynos drm initialization will be failed?
Thanks,
Inki Dae
And below codes,
int component_master_add_child(...)
{
list_for_each_entry(c, component_list, node) {
if (c-master)
continue;
if (compare(...)) {
component_attach_master(master, c);
...
}
}
}
And below codes,
static void component_attach_master(master, c)
{
c-master = master;
list_add_tail(c-master_node, master-comonents);
}
As you can see above, the only components added to component_list can
be attached to master. And the important thing is that components can
be added by sub drivers to the component_list.
And below codes that actually tries to bind each sub drivers,
int component_bind_add(...)
{
list_for_each_entry(c, master-components, master_node) {
ret = component_bind(c, master, data);
...
}
...
}
The hdmi driver users disabled doesn't exist to master-components list.
How Exynos DRM cannot be initialized?
Of course, there may be my missing point, but I think I see them
correctly. Anyway I will test them tomorrow.
Thanks,
Inki Dae
register, which is completely wrong. Users should be able to select which
drivers should be compiled into their kernels.
So users are be able to select drivers they want to use, and will be
compiled correctly. So no, the only thing users can disable is each
sub driver, not core module.
3) Such approach leads to complete integration of all Exynos DRM drivers,
without possibility of loading some sub-drivers as modules. I know that
current driver design doesn't support it either, but if this series is
No, current drm driver *must also be built* as one integrated single
drm driver without super device approach.
As I wrote, I know that current design before this patch isn't modular
either, but this is not my concern here. See below.
So the super device approach
*has no any effect on existing design*, and what the super device
approch tries to do is to resolve the probe order issue to sub drivers
*without some codes specific to Exynos drm*.
My concern is that the supernode design is actually carving such broken
non-modular design in stone. Remember that we are currently heading towards
a fully multi-platform kernel where it is critical for such subsystems to be
modular, because the same zImage is going to be running on completely
different machines.
claimed to improve things, it should really do so.
4) Exactly the same can be achieved without changing the DT bindings at
all.
In fact even without adding any new single property or node to DT. We
discussed this with Andrzej and Marek today and came
Re: [PATCH v2 1/7] drm/exynos: add super device support
Hi Russell, 2014-04-06 17:47 GMT+09:00 Russell King - ARM Linux li...@arm.linux.org.uk: On Sun, Apr 06, 2014 at 01:21:24PM +0900, Inki Dae wrote: As you may know, there is exynos chip that has two display controllers. So it is possible to compose display pipe lines at same time like below, fimd0-bridges..--Panel fimd1-maybe bridges..-CPU Panel How we can care such pipelines without component? Of course, it would be possible somehow but I'm not sure there could be better and more generic way than super device. And super device will make existing dtb broken but this time it might be good opportunity to more generic way before more users use existing dt. There has been a discussion ongoing about how to best represent display (and capture) stuff in DT using graphs, which you may wish to consider Right, there was my wrong comments. Actually, I had made a discussion about it. For this, you can refer to below link, http://www.spinics.net/lists/dri-devel/msg5.html My intension there was that let's use super device approach to resolve the probe order issue of drm drivers for embedded system, and the graphs to compose their display pipelines. And for this, we need generic common structure to handle various bridge devices that could be controlled by crtc and encoder/connector drivers. I'd be happy to get your opinions about it. looking at. That discussion never reached any kind of conclusion before the merge window, but it does need to reach a conclusion for the next window. Yes. I still think the super device approach is a best solution, and I think the only problem here is backward compatibility. I have a feel that we might resolve that issue easier then we think. I think all we have to do for it is to implement some codes for backward compatibility on top of super device approach. This way, we could have a better design for the future drm drivers without being tied to the backward compatibility. Thanks, Inki Dae -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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/7] drm/exynos: add super device support
I'd be really happy if you gave me such opinions before pull request.
Anyway, below is my comments.
2014-04-06 2:32 GMT+09:00 Tomasz Figa tomasz.f...@gmail.com:
[adding more people and MLs on Cc for further discussion]
On 04.04.2014 17:44, Inki Dae wrote:
2014-04-04 22:55 GMT+09:00 Tomasz Figa t.f...@samsung.com:
Hi Inki,
On 01.04.2014 14:37, Inki Dae wrote:
This patch adds super device support to bind sub drivers
using device tree.
For this, you should add a super device node to each machine dt files
like belows,
In case of using MIPI-DSI,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd, dsi;
};
In case of using DisplayPort,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd, dp;
};
In case of using Parallel panel,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd;
};
And if you don't add connector device node to ports property,
default parallel panel driver, exynos_drm_dpi module, will be used.
ports property can have the following device nodes,
fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or
HDMI
With this patch, we can resolve the probing order issue without
some global lists. So this patch also removes the unnecessary lists and
stuff related to these lists.
I can see several problems with this approach:
1) It breaks compatibility with existing DT. After this patch it is no
longer possible to use old device trees and get a working DRM. However,
in
my opinion, this requirement can be relaxed if we make sure that any
users
are properly converted.
2) What happens if in Kconfig you disable a driver for a component that
is
I'm not sure what you meant but there wouldn't be no way that users
*cannot disable* the driver for a component. The driver would be
exynos_drm_drv, not separated module, and would always be built as
long as users want to use *exynos drm driver*.
I think you don't understand what I mean. Let me show you an example:
You have a board with a DSI panel and also a HDMI output. So you have a
supernode pointing to FIMD, DSI and HDMI.
Now, an user finds that he doesn't need HDMI in his system, so he turns off
CONFIG_DRM_EXYNOS_HDMI. The supernode still points at hdmi node and Exynos
DRM core will register it as a component, but HDMI driver is not available
and will never probe, leading the whole Exynos DRM to never initialize. Is
this a desired behavior?
Ok, now I understood. Your comment was not enough to me.
First of all, if I see component codes correctly then it seems your
misunderstanding. See the below comments,
listed in supernode? If I'm reading the code correctly, Exynos DRM will
not
And the only case a component isn't added to the list is when users
disabled sub driver.
See above.
The code creating the list of components to wait for
(exynos_drm_add_components()) doesn't seem to consider which sub-drivers are
actually enabled in kernel config.
Are you sure?
exynos_drm_add_components() will try to attach components *added to
component_lists. And these components will be added by only
corresponding sub drivers to the component_lists and
master-components.
So in this case, if users disabled HDMI support then a commponent
object for HDMI sub driver doesn't exists in the component_lists and
master-components. This means that a component object for HDMI sub
driver *cannot be attached to master object*.
As a result, component_bind_add() will ignor component_bind call for
HDMI sub driver so HDMI driver will not be bounded. The only
components added by sub drivers will be bound, component-ops-bind().
For more understanding, it seems like you need to look into below codes,
static int exynos_drm_add_components(...)
{
...
for (i == 0;; i++) {
...
node = of_parse_phandle(np, ports, i);
...
ret = component_master_add_child(m, compare_of, node);
...
}
}
And below codes,
int component_master_add_child(...)
{
list_for_each_entry(c, component_list, node) {
if (c-master)
continue;
if (compare(...)) {
component_attach_master(master, c);
...
}
}
}
And below codes,
static void component_attach_master(master, c)
{
c-master = master;
list_add_tail(c-master_node, master-comonents);
}
As you can see above, the only components added to component_list can
be attached to master. And the important thing is that components can
be added by sub drivers to the component_list.
And below codes that actually tries to bind each sub drivers,
int component_bind_add
Re: [PATCH v2 1/7] drm/exynos: add super device support
2014-04-06 3:31 GMT+09:00, Tomasz Figa tomasz.f...@gmail.com:
On 05.04.2014 20:24, Russell King - ARM Linux wrote:
On Sat, Apr 05, 2014 at 07:32:50PM +0200, Tomasz Figa wrote:
Not exactly. The approach we found does mostly the same as componentized
subsystem framework but without _any_ extra data in Device Tree. Just
based on the list of subsystem sub-drivers that is already available to
the master driver.
The existing approach is fundamentally broken. Yes, your solution may
work for the probing case, but have you tried unbinding any of your
sub-drivers?
From what I can see, that causes a kernel oops for one very simple reason
-
you destroy stuff while it's still in use. Let's look at an example:
struct platform_driver ipp_driver = {
.probe = ipp_probe,
.remove = ipp_remove,
.driver = {
.name = exynos-drm-ipp,
.owner = THIS_MODULE,
.pm = ipp_pm_ops,
},
};
static int ipp_remove(struct platform_device *pdev)
{
struct ipp_context *ctx = platform_get_drvdata(pdev);
/* unregister sub driver */
exynos_drm_subdrv_unregister(ctx-subdrv);
/* remove,destroy ipp idr */
idr_destroy(ctx-ipp_idr);
idr_destroy(ctx-prop_idr);
mutex_destroy(ctx-ipp_lock);
mutex_destroy(ctx-prop_lock);
/* destroy command, event work queue */
destroy_workqueue(ctx-cmd_workq);
destroy_workqueue(ctx-event_workq);
return 0;
}
int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
{
if (!subdrv)
return -EINVAL;
list_del(subdrv-list);
return 0;
}
Oh dear, that destroys a whole pile of resources which could already
be in use without telling anything that it's about to do that.
I'm sure if I continue looking at the exynos stuff, it'll show similar
crap all over the place.
What you have now in mainline is not a solution. It's a crappy bodge.
Undoubtedly. Nobody here is trying to state the opposite.
Maybe my words have been misinterpreted, but all I'm suggesting here is
that there is no need to add any new data to DT to solve the same issue
to the same extent as componentized subsystem framework, at least in
Exynos case.
As you may know, there is exynos chip that has two display
controllers. So it is possible to compose display pipe lines at same
time like below,
fimd0-bridges..--Panel
fimd1-maybe bridges..-CPU Panel
How we can care such pipelines without component? Of course, it would
be possible somehow but I'm not sure there could be better and more
generic way than super device.
And super device will make existing dtb broken but this time it might
be good opportunity to more generic way before more users use existing
dt.
Thanks,
Inki Dae
Best regards,
Tomasz
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 00/12] Add DSI display support for Exynos based boards
Hi Andrzej, 2014-03-28 20:52 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2. The patchset is based on exynos_drm_next branch. It is the 3rd iteration of the patches, main changes: - based on exynos_drm_next branch, - added video interface bindings between DSI host and slave, it seems to me to be redundand, and I hope when video interface bindings will be stabilized it can become optional, - GPIOs implemented using gpiod framework, - removed controversial stuff (toshiba bridge implementation and arndale support), it will be send in another set of patches Other changes are described in individual patches. Regards Andrzej Andrzej Hajda (12): drm/mipi_dsi: add flags to DSI messages drm/mipi_dsi: create dsi devices only for nodes with reg property drm/exynos: disallow fbdev initialization if no device is connected exynos/dsim: add DT bindings drm/exynos: add DSIM driver panel/s6e8aa0: add DT bindings drm/panel: add S6E8AA0 driver ARM: dts: exynos4: add MIPI DSI Master node ARM: dts: exynos4210-trats: add panel node ARM: dts: exynos4412-trats2: add panel node ARM: dts: exynos4210-trats: enable exynos/fimd node ARM: dts: exynos4412-trats2: enable exynos/fimd node Picked up this patch series. Thanks for your contribution, Inki Dae .../devicetree/bindings/panel/samsung,s6e8aa0.txt | 56 + .../devicetree/bindings/video/exynos_dsim.txt | 80 + arch/arm/boot/dts/exynos4.dtsi | 14 + arch/arm/boot/dts/exynos4210-trats.dts | 61 + arch/arm/boot/dts/exynos4412-trats2.dts| 70 + drivers/gpu/drm/drm_mipi_dsi.c |6 +- drivers/gpu/drm/exynos/Kconfig |9 + drivers/gpu/drm/exynos/Makefile|1 + drivers/gpu/drm/exynos/exynos_drm_drv.c| 15 + drivers/gpu/drm/exynos/exynos_drm_drv.h|1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1525 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 21 + drivers/gpu/drm/panel/Kconfig |7 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-s6e8aa0.c | 1069 ++ include/drm/drm_mipi_dsi.h |6 + 16 files changed, 2941 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c -- 1.8.3.2 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 8/9] drm/exynos/fimd: use polarization flags provided by drm_display_mode
Thanks for your contributions,
2014-03-17 19:27 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:
The patch replaces fimd private bindings for signal polarization by
polarization flags provided by drm_display_mode.
This patch needs below patch not merged yet,
drm: drm_display_mode: add signal polarity flags
So let me pick up all of your path series except for patch 7 and 8.
And for these two patches, later.
Your opinion?
Thanks,
Inki Dae
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 15d6b37..dbfad4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -115,7 +115,6 @@ struct fimd_context {
unsigned intdefault_win;
unsigned long irq_flags;
u32 vidcon0;
- u32 vidcon1;
boolsuspended;
int pipe;
wait_queue_head_t wait_vsync_queue;
@@ -232,7 +231,11 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
return;
/* setup polarity values */
- vidcon1 = ctx-vidcon1;
+ vidcon1 = 0;
+ if (mode-pol_flags DRM_MODE_FLAG_POL_DE_NEGEDGE)
+ vidcon1 |= VIDCON1_INV_VDEN;
+ if (mode-pol_flags DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE)
+ vidcon1 |= VIDCON1_INV_VCLK;
if (mode-flags DRM_MODE_FLAG_NVSYNC)
vidcon1 |= VIDCON1_INV_VSYNC;
if (mode-flags DRM_MODE_FLAG_NHSYNC)
@@ -875,11 +878,6 @@ static int fimd_probe(struct platform_device *pdev)
ctx-dev = dev;
ctx-suspended = true;
- if (of_property_read_bool(dev-of_node, samsung,invert-vden))
- ctx-vidcon1 |= VIDCON1_INV_VDEN;
- if (of_property_read_bool(dev-of_node, samsung,invert-vclk))
- ctx-vidcon1 |= VIDCON1_INV_VCLK;
-
ctx-bus_clk = devm_clk_get(dev, fimd);
if (IS_ERR(ctx-bus_clk)) {
dev_err(dev, failed to get bus clock\n);
--
1.8.3.2
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos4210-universal: add fimd polarization settings
Hi Andrzej,
2014-03-20 22:26 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:
The patch adds polarization flags to fimd node.
It fixes parallel display support.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
Hi Inki,
Since polarization patches were not merged, polarization
settings should be provided to fimd via properties.
This patch fixes it.
Just let me integrate it to old one, 'ARM: dts: exynos4210-universal:
add exynos/fimd node'.
Thanks,
Inki Dae
Regards
Andrzej
---
arch/arm/boot/dts/exynos4210-universal_c210.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 21ca0b978..477208d 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -351,6 +351,8 @@
pinctrl-0 = lcd_clk, lcd_data24;
pinctrl-names = default;
status = okay;
+ samsung,invert-vden;
+ samsung,invert-vclk;
display-timings {
timing {
clock-frequency = 23492370;
--
1.8.3.2
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c
2014-03-18 14:45 GMT+09:00 Kukjin Kim kgene@samsung.com: Inki Dae wrote: Applied. Thanks, Inki Dae 2014-03-17 12:28 GMT+09:00 Daniel Kurtz djku...@chromium.org: The following commit [0] fixed a use-after-free, but left the subdrv open in the error path. [0] commit 6ca605f7c70895a35737435f17ae9cc5e36f1466 drm/exynos: Fix freeing issues in exynos_drm_drv.c Change-Id: I452e944bf090fb11434d9e34213c890c41c15d73 This should be removed when Inki apply this. No, Daniel's patch just complements above previous one that is what I missed. Thanks, Inki Dae Thanks, Kukjin Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) ___ 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] drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c
Applied.
Thanks,
Inki Dae
2014-03-17 12:28 GMT+09:00 Daniel Kurtz djku...@chromium.org:
The following commit [0] fixed a use-after-free, but left the subdrv open
in the error path.
[0] commit 6ca605f7c70895a35737435f17ae9cc5e36f1466
drm/exynos: Fix freeing issues in exynos_drm_drv.c
Change-Id: I452e944bf090fb11434d9e34213c890c41c15d73
Signed-off-by: Daniel Kurtz djku...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 215131a..c204b4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -172,20 +172,24 @@ static int exynos_drm_open(struct drm_device *dev,
struct drm_file *file)
ret = exynos_drm_subdrv_open(dev, file);
if (ret)
- goto out;
+ goto err_file_priv_free;
anon_filp = anon_inode_getfile(exynos_gem, exynos_drm_gem_fops,
NULL, 0);
if (IS_ERR(anon_filp)) {
ret = PTR_ERR(anon_filp);
- goto out;
+ goto err_subdrv_close;
}
anon_filp-f_mode = FMODE_READ | FMODE_WRITE;
file_priv-anon_filp = anon_filp;
return ret;
-out:
+
+err_subdrv_close:
+ exynos_drm_subdrv_close(dev, file);
+
+err_file_priv_free:
kfree(file_priv);
file-driver_priv = NULL;
return ret;
--
1.9.0.279.gdc9e3eb
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
2014-03-12 20:16 GMT+09:00 Tomasz Figa t.f...@samsung.com: On 12.03.2014 11:08, Inki Dae wrote: 2014-03-07 19:00 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/05/2014 03:56 AM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. In this particular case DSI master expects on the other end any device having DSI slave interface, it could be panel or bridge. So it seems natural that both types of slave devices should expose the same interface also on programming level. Another problem with drm_bridge is that it is not scalable - if some manufacturer will decide to add another block between the bridge and the panel there is no drm component which can be used for it. Using drm_panel the way I have used in toshiba bridge makes scalability possible, it will be only a matter of adding a driver for new block and making proper links in device tree, I see no easy way of doing it with drm_bridge approach. Now drm_bridge may not cover all hardware. However drm_bridge has already been merged to mainline so I think we need to use drm_bridge somehow instead of using other one, and also we could extend drm_bridge if needed. It would be definitely impossible for a new framework to cover all hardware because there may be other hardware not appeared yet. That is what we are doing for mainline until now. Well, maybe drm_bridge has been merged, but so has been drm_panel. Moreover, merged code is not carved in stone, if there is a better option that could replace it, users of it can be converted to the new approach and the old one can be removed. As I believe Andrzej has demonstrated, drm_panel framework is clearly superior over drm_bridge and I can't think of any good reason why it couldn't become more generic and replace drm_bridge. Of course it can be renamed then to something more generic appropriately. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Could you explain what you mean by dt binding of LVDS bridge can be done at top level of Exynos drm ? How it will look like if there will be more bridges, one for DSI, one for HDMI, etc... What if there will be two bridges in one chain. How it will cope with video pipeline bindings? it was just my idea so I have no implementation about it yet. My idea is that crtc and encoder are binded at top level of Exynos drm as is. And for bridge support, the only difference is, in case that encoder driver has bridge, the dt binding of the encoder driver is done once last one between encoder and bridge driver is binded. It would mean that bridge driver can use driver model and it doesn't need to concern about probe order issue. For this, encoder driver with bridge, MIPI-DSI or eDP, would need to use component interfaces specific to Exynos drm. As a result, once the dt bindings of crtc and encoder are completed at top level, encoder driver has its own drm_bridge for bridge, and dt binding you proposed could be used without any change, and drm_panel could also be used only for real lcd panel driver. And below is a block diagram I think, DRM KMS / | \ / | \ crtc encoder connector
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
2014-03-13 22:41 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/13/2014 08:08 AM, Inki Dae wrote: 2014-03-12 20:16 GMT+09:00 Tomasz Figa t.f...@samsung.com: On 12.03.2014 11:08, Inki Dae wrote: 2014-03-07 19:00 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/05/2014 03:56 AM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. In this particular case DSI master expects on the other end any device having DSI slave interface, it could be panel or bridge. So it seems natural that both types of slave devices should expose the same interface also on programming level. Another problem with drm_bridge is that it is not scalable - if some manufacturer will decide to add another block between the bridge and the panel there is no drm component which can be used for it. Using drm_panel the way I have used in toshiba bridge makes scalability possible, it will be only a matter of adding a driver for new block and making proper links in device tree, I see no easy way of doing it with drm_bridge approach. Now drm_bridge may not cover all hardware. However drm_bridge has already been merged to mainline so I think we need to use drm_bridge somehow instead of using other one, and also we could extend drm_bridge if needed. It would be definitely impossible for a new framework to cover all hardware because there may be other hardware not appeared yet. That is what we are doing for mainline until now. Well, maybe drm_bridge has been merged, but so has been drm_panel. Moreover, merged code is not carved in stone, if there is a better option that could replace it, users of it can be converted to the new approach and the old one can be removed. As I believe Andrzej has demonstrated, drm_panel framework is clearly superior over drm_bridge and I can't think of any good reason why it couldn't become more generic and replace drm_bridge. Of course it can be renamed then to something more generic appropriately. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Could you explain what you mean by dt binding of LVDS bridge can be done at top level of Exynos drm ? How it will look like if there will be more bridges, one for DSI, one for HDMI, etc... What if there will be two bridges in one chain. How it will cope with video pipeline bindings? it was just my idea so I have no implementation about it yet. My idea is that crtc and encoder are binded at top level of Exynos drm as is. And for bridge support, the only difference is, in case that encoder driver has bridge, the dt binding of the encoder driver is done once last one between encoder and bridge driver is binded. It would mean that bridge driver can use driver model and it doesn't need to concern about probe order issue. For this, encoder driver with bridge, MIPI-DSI or eDP, would need to use component interfaces specific to Exynos drm. As a result, once the dt bindings of crtc and encoder are completed at top level, encoder driver has its own drm_bridge for bridge, and dt binding you proposed could be used without any change, and drm_panel could also be used only for real lcd panel driver. And below is a block diagram I think, DRM KMS / | \ / | \ crtc encoder
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
2014-03-07 19:00 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: On 03/05/2014 03:56 AM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. In this particular case DSI master expects on the other end any device having DSI slave interface, it could be panel or bridge. So it seems natural that both types of slave devices should expose the same interface also on programming level. Another problem with drm_bridge is that it is not scalable - if some manufacturer will decide to add another block between the bridge and the panel there is no drm component which can be used for it. Using drm_panel the way I have used in toshiba bridge makes scalability possible, it will be only a matter of adding a driver for new block and making proper links in device tree, I see no easy way of doing it with drm_bridge approach. Now drm_bridge may not cover all hardware. However drm_bridge has already been merged to mainline so I think we need to use drm_bridge somehow instead of using other one, and also we could extend drm_bridge if needed. It would be definitely impossible for a new framework to cover all hardware because there may be other hardware not appeared yet. That is what we are doing for mainline until now. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Could you explain what you mean by dt binding of LVDS bridge can be done at top level of Exynos drm ? How it will look like if there will be more bridges, one for DSI, one for HDMI, etc... What if there will be two bridges in one chain. How it will cope with video pipeline bindings? it was just my idea so I have no implementation about it yet. My idea is that crtc and encoder are binded at top level of Exynos drm as is. And for bridge support, the only difference is, in case that encoder driver has bridge, the dt binding of the encoder driver is done once last one between encoder and bridge driver is binded. It would mean that bridge driver can use driver model and it doesn't need to concern about probe order issue. For this, encoder driver with bridge, MIPI-DSI or eDP, would need to use component interfaces specific to Exynos drm. As a result, once the dt bindings of crtc and encoder are completed at top level, encoder driver has its own drm_bridge for bridge, and dt binding you proposed could be used without any change, and drm_panel could also be used only for real lcd panel driver. And below is a block diagram I think, DRM KMS / | \ / | \ crtc encoder connector | / \ | | / \ | | | drm_bridge drm_panel | | | | | | | | FIMD MIPI-DSILVDS bridgePanel Thanks, Inki Dae Will review your patch series soon. Thanks in advance. Regards Andrzej ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe
Re: [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
Hi Andrzej, Thanks for your contributions. 2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com: Hi, This patchset adds drivers and bindings to the following devices: - Exynos DSI master, - S6E8AA0 DSI panel, - TC358764 DSI/LVDS bridge, - HV070WSA-100 LVDS panel. It adds also display support in DTS files for the following boards: - Exynos4210/Trats, - Exynos4412/Trats2, - Exynos5250/Arndale. Things worth mentioning: 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. the driver exposes drm_panel interface on DSI side, and interact with panels on LVDS side using drm_panel framework. This approach seems to me simpler and more natural than using drm_bridge. Can you give me more details about why you think better to use panel framework than using drm_bridge? Simpler and more natural are ambiguous to me. Using same drm_panel framework for LDVS bridge and real panel drivers isn't reasonable to me as now because drm_panel framework would be for real panel device even if the use of drm_panel framework looks like suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver using drm_bride stuff, is good enough, and that would be why drm_bridge exists and why drm_encoder has drm_bridge. And I'm finding more generic way, how to handle LVDS bridge using super node so that LVDS bridge driver isn't embedded to connector drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be done at top level of Exynos drm. Once the binding is done, encoder of display bus driver will have drm_bridge object of LVDS bridge driver so that display bus driver can handle LVDS bridge driver. Will review your patch series soon. Thanks, Inki Dae 2. I have used video interface bindings to make link between bridge and LVDS panel. Other places where such links can be created are: a) link between DSI master and slave, I wonder if it is always neccessary, DSI bus is also video bus, b) link between FIMD(display controller) and DSI Master, currently Exynos DRM framework uses driver's hardcoded links, converting it to video interface bindings should be done (if required) by separate patches. The patchset is based on Sean's Paul Exynos refactor patches v4 [1]. To work properly porch calculation should be fixed according to my comment [2]. It is the 2nd iteration of the patches, main changes: - based on v4 refactor patches, - added arndale related stuff. Other changes are described in individual patches. [1] http://permalink.gmane.org/gmane.comp.video.dri.devel/99264 [2] http://permalink.gmane.org/gmane.comp.video.dri.devel/99826 Regards Andrzej Andrzej Hajda (21): drm_mipi_dsi: add flags to DSI messages drm/exynos: delay fbdev initialization until an output is connected exynos/dsim: add DT bindings drm/exynos: add DSIM driver panel/s6e8aa0: add DT bindings drm/panel: add S6E8AA0 driver panel/tc358764: add DT bindings drm/panel: add TC358764 driver panel/simple: add video interface DT bindings panel/hv070wsa-100: add DT bindings drm/panel: add support for BOE HV070WSA-100 panel to simple-panel ARM: dts: exynos4: add MIPI DSI Master node ARM: dts: exynos4210-trats: add panel node ARM: dts: exynos4412-trats2: add panel node ARM: dts: exynos5250: add mipi-phy node ARM: dts: exynos5250: add display power domain node ARM: dts: exynos5250: add DSI node ARM: dts: exynos5250-arndale: add display regulators ARM: dts: exynos5250-arndale: add dsi and panel nodes ARM: dts: exynos4210-trats: enable exynos/fimd node ARM: dts: exynos4412-trats2: enable exynos/fimd node .../devicetree/bindings/panel/boe,hv070wsa-100.txt |7 + .../devicetree/bindings/panel/samsung,s6e8aa0.txt | 51 + .../devicetree/bindings/panel/simple-panel.txt |6 + .../devicetree/bindings/panel/toshiba,tc358764.txt | 41 + .../devicetree/bindings/video/exynos_dsim.txt | 53 + arch/arm/boot/dts/exynos4.dtsi | 14 + arch/arm/boot/dts/exynos4210-trats.dts | 42 + arch/arm/boot/dts/exynos4412-trats2.dts| 51 + arch/arm/boot/dts/exynos5250-arndale.dts | 63 + arch/arm/boot/dts/exynos5250.dtsi | 25 + drivers/gpu/drm/exynos/Kconfig |9 + drivers/gpu/drm/exynos/Makefile|1 + drivers/gpu/drm/exynos/exynos_drm_drv.c| 26 +- drivers/gpu/drm/exynos/exynos_drm_drv.h|1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1402 drivers/gpu/drm/exynos/exynos_drm_fb.c |3 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +- drivers/gpu/drm/panel/Kconfig | 14 + drivers/gpu/drm/panel/Makefile |2 + drivers/gpu/drm/panel/panel-s6e8aa0.c | 1064 +++ drivers/gpu/drm/panel/panel-simple.c | 25 + drivers
Re: [RFC PATCH v2 03/21] exynos/dsim: add DT bindings
2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:
The patch adds DT bindings for Exynos DSI Master. DSIM follows rules
for DSI bus host bindings [1].
Properties describes its resources: memory, interrupt, clocks,
phy, regulators and frequencies of clocks.
[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
v2
- added burst and esc clock frequency properties
- add samsung prefix to all frequency props
---
.../devicetree/bindings/video/exynos_dsim.txt | 53
++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
new file mode 100644
index 000..2a49704
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -0,0 +1,53 @@
+Exynos MIPI DSI Master
+
+Required properties:
+ - compatible: samsung,exynos4210-mipi-dsi
+ - reg: physical base address and length of the registers set for the device
+ - interrupts: should contain DSI interrupt
+ - clocks: list of clock specifiers, must contain an entry for each required
+entry in clock-names
+ - clock-names: should include bus_clkand pll_clk entries
+ - phys: list of phy specifiers, must contain an entry for each required
+entry in phy-names
+ - phy-names: should include dsim entry
+ - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
+ - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
+ - samsung,pll-clock-frequency: specifies frequency of the pll_clk clock
+ - samsung,burst-clock-frequency: specifies DSI frequency in high-speed
burst
+mode
+ - samsung,esc-clock-frequency: specifies DSI frequency in escape mode
+ - #address-cells, #size-cells: should be set respectively to 1 and 0
+according to DSI host bindings (see MIPI DSI bindings [1])
+
+Optional properties:
+ - samsung,power-domain: a phandle to DSIM power domain node
+
+Child nodes:
+ Should contain DSI peripheral nodes (see DSI bindings [1])
+
+[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+Example:
+
+ dsi@11C8 {
+ compatible = samsung,exynos4210-mipi-dsi;
+ reg = 0x11C8 0x1;
+ interrupts = 0 79 0;
+ clocks = clock 286, clock 143;
+ clock-names = bus_clk, pll_clk;
+ phys = mipi_phy 1;
+ phy-names = dsim;
+ vddcore-supply = vusb_reg;
+ vddio-supply = vmipi_reg;
+ samsung,power-domain = pd_lcd0;
+ #address-cells = 1;
+ #size-cells = 0;
+ samsung,pll-clock-frequency = 2400;
+ samsung,burst-clock-frequency = 5;
+ samsung,esc-clock-frequency = 2000;
Isn't a property indicating cpu or video mode needed for the future
even though now DSI driver doesn't support CPU interface yet? Which
mode is used would depend on machine.
+
+ panel@0 {
+ reg = 0;
+ ...
+ };
+ };
--
1.8.3.2
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 08/21] drm/panel: add TC358764 driver
2014-02-12 20:31 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:
The patch adds driver for Toshiba DSI/LVDS TC358764 bridge.
Driver registers itself as mipi_dsi_driver. It is exposed to the
system via drm_panel interface, it uses also drm_panel framework
to interact with LVDS panel connected to it.
Driver supports only DT bindings.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/panel/Kconfig | 7 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-tc358764.c | 505
+
3 files changed, 513 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tc358764.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 7527557..b98a485 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -23,4 +23,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_TC358764
+ tristate TC358764 DSI/LVDS bridge
+ depends on DRM DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 181265b..7cbb0cf 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_TC358764) += panel-tc358764.o
diff --git a/drivers/gpu/drm/panel/panel-tc358764.c
b/drivers/gpu/drm/panel/panel-tc358764.c
new file mode 100644
index 000..f9c1289
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tc358764.c
@@ -0,0 +1,505 @@
+/*
+ * TC358764 MIPI-DSI to LVDS bridge panel driver.
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd
+ *
+ * Andrzej Hajda a.ha...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include drm/drmP.h
+#include drm/drm_mipi_dsi.h
+#include drm/drm_panel.h
...
+/* of_* functions will be removed after acceptance of of_graph patches */
+static struct device_node *
+of_get_child_by_name_reg(struct device_node *parent, const char *name, u32
reg)
+{
+ struct device_node *np;
+
+ for_each_child_of_node(parent, np) {
+ u32 r;
+
+ if (!np-name || of_node_cmp(np-name, name))
+ continue;
+
+ if (of_property_read_u32(np, reg, r) 0)
+ r = 0;
+
+ if (reg == r)
+ break;
+ }
+
+ return np;
+}
+
+static struct device_node *of_graph_get_port_by_reg(struct device_node
*parent,
+ u32 reg)
+{
+ struct device_node *ports, *port;
+
+ ports = of_get_child_by_name(parent, ports);
+ if (ports) {
+ port = of_get_child_by_name_reg(ports, port, reg);
+ of_node_put(ports);
+ } else {
+ port = of_get_child_by_name_reg(parent, port, reg);
+ }
+ return port;
+}
+
+static struct device_node *
+of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
+{
+ return of_get_child_by_name_reg(port, endpoint, reg);
+}
+
+static struct device_node *
+of_graph_get_remote_port_parent(const struct device_node *node)
+{
+ struct device_node *np;
+ unsigned int depth;
+
+ /* Get remote endpoint node. */
+ np = of_parse_phandle(node, remote-endpoint, 0);
+
+ /* Walk 3 levels up only if there is 'ports' node. */
+ for (depth = 3; depth np; depth--) {
+ np = of_get_next_parent(np);
+ if (depth == 2 of_node_cmp(np-name, ports))
+ break;
+ }
+ return np;
+}
+
+static struct device_node *tc358764_of_find_panel_node(struct device *dev)
+{
+ struct device_node *np, *ep;
+
+ np = of_graph_get_port_by_reg(dev-of_node, 1);
+ if (!np)
+ return NULL;
+
+ ep = of_graph_get_endpoint_by_reg(np, 0);
+ of_node_put(np);
+ if (!ep)
+ return NULL;
+
+ np = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+
+ return np;
+}
+
+static int tc358764_parse_dt(struct tc358764 *ctx)
+{
+ struct device *dev = ctx-dev;
+ struct device_node *np = dev-of_node;
+ struct device_node *lvds;
+
+ ctx-reset_gpio = of_get_named_gpio(np, reset-gpio, 0);
+ if (ctx-reset_gpio 0) {
+ dev_err(dev, no reset GPIO pin provided\n);
+ //return ctx-reset_gpio;
Seem like your mistake.
+ }
+
+ lvds = tc358764_of_find_panel_node(ctx-dev);
Isn't lvds device_node object of
Re: [PATCH] iommu/exynos: Remove driver
2014-02-07 Olof Johansson o...@lixom.net: The driver has been unbuildable due to unfulfilled dependencies since 3.11, and even if enabled it won't build due to build breakage. Emails about status on this have gone unanswered, and fixes seem to have been abandoned. It's obvious that nobody cares about it, so let's remove it. Wait, we are going to fix up this module. It seems that KyoungHo, original author, is busy with some works related to product. we can care about it if KyoungHo cannot afford to care for the time being. Thanks, Inki Dae Signed-off-by: Olof Johansson o...@lixom.net --- drivers/iommu/Kconfig| 21 - drivers/iommu/Makefile |1 - drivers/iommu/exynos-iommu.c | 1035 -- 3 files changed, 1057 deletions(-) delete mode 100644 drivers/iommu/exynos-iommu.c diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 79bbc21..b893367 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -176,27 +176,6 @@ config TEGRA_IOMMU_SMMU space through the SMMU (System Memory Management Unit) hardware included on Tegra SoCs. -config EXYNOS_IOMMU - bool Exynos IOMMU Support - depends on ARCH_EXYNOS EXYNOS_DEV_SYSMMU - select IOMMU_API - help - Support for the IOMMU(System MMU) of Samsung Exynos application - processor family. This enables H/W multimedia accellerators to see - non-linear physical memory chunks as a linear memory in their - address spaces - - If unsure, say N here. - -config EXYNOS_IOMMU_DEBUG - bool Debugging log for Exynos IOMMU - depends on EXYNOS_IOMMU - help - Select this to see the detailed log message that shows what - happens in the IOMMU driver - - Say N unless you need kernel log message for IOMMU debugging - config SHMOBILE_IPMMU bool diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 5d58bf1..de6c909 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -14,7 +14,6 @@ obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o -obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o obj-$(CONFIG_SHMOBILE_IOMMU) += shmobile-iommu.o obj-$(CONFIG_SHMOBILE_IPMMU) += shmobile-ipmmu.o obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c deleted file mode 100644 index 0740189..000 --- a/drivers/iommu/exynos-iommu.c +++ /dev/null @@ -1,1035 +0,0 @@ -/* linux/drivers/iommu/exynos_iommu.c - * - * Copyright (c) 2011 Samsung Electronics Co., Ltd. - * http://www.samsung.com - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#ifdef CONFIG_EXYNOS_IOMMU_DEBUG -#define DEBUG -#endif - -#include linux/io.h -#include linux/interrupt.h -#include linux/platform_device.h -#include linux/slab.h -#include linux/pm_runtime.h -#include linux/clk.h -#include linux/err.h -#include linux/mm.h -#include linux/iommu.h -#include linux/errno.h -#include linux/list.h -#include linux/memblock.h -#include linux/export.h - -#include asm/cacheflush.h -#include asm/pgtable.h - -#include mach/sysmmu.h - -/* We does not consider super section mapping (16MB) */ -#define SECT_ORDER 20 -#define LPAGE_ORDER 16 -#define SPAGE_ORDER 12 - -#define SECT_SIZE (1 SECT_ORDER) -#define LPAGE_SIZE (1 LPAGE_ORDER) -#define SPAGE_SIZE (1 SPAGE_ORDER) - -#define SECT_MASK (~(SECT_SIZE - 1)) -#define LPAGE_MASK (~(LPAGE_SIZE - 1)) -#define SPAGE_MASK (~(SPAGE_SIZE - 1)) - -#define lv1ent_fault(sent) (((*(sent) 3) == 0) || ((*(sent) 3) == 3)) -#define lv1ent_page(sent) ((*(sent) 3) == 1) -#define lv1ent_section(sent) ((*(sent) 3) == 2) - -#define lv2ent_fault(pent) ((*(pent) 3) == 0) -#define lv2ent_small(pent) ((*(pent) 2) == 2) -#define lv2ent_large(pent) ((*(pent) 3) == 1) - -#define section_phys(sent) (*(sent) SECT_MASK) -#define section_offs(iova) ((iova) 0xF) -#define lpage_phys(pent) (*(pent) LPAGE_MASK) -#define lpage_offs(iova) ((iova) 0x) -#define spage_phys(pent) (*(pent) SPAGE_MASK) -#define spage_offs(iova) ((iova) 0xFFF) - -#define lv1ent_offset(iova) ((iova) SECT_ORDER) -#define lv2ent_offset(iova) (((iova) 0xFF000) SPAGE_ORDER) - -#define NUM_LV1ENTRIES 4096 -#define NUM_LV2ENTRIES 256 - -#define LV2TABLE_SIZE (NUM_LV2ENTRIES * sizeof(long)) - -#define SPAGES_PER_LPAGE (LPAGE_SIZE / SPAGE_SIZE) - -#define lv2table_base(sent) (*(sent) 0xFC00) - -#define mk_lv1ent_sect(pa) ((pa) | 2) -#define mk_lv1ent_page(pa) ((pa) | 1) -#define mk_lv2ent_lpage(pa) ((pa
Re: [PATCH V2] drm/exynos: Fix multiplatform breakage for ipp/gsc
Applied. Thanks, Inki Dae 2014/1/16 Tushar Behera tushar.beh...@linaro.org: There is no need to include plat/map-base.h in ipp driver. Remove this and enable this driver for multi-platform. However gsc driver is not multiplatform compliant yet, so make the compilation conditional upon !ARCH_MULTIPLATFORM. Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- Changes for V2: * Made compilation of exynos_drm_gsc.c conditional on !ARCH_MULTIPLATFORM. drivers/gpu/drm/exynos/Kconfig |4 ++-- drivers/gpu/drm/exynos/exynos_drm_ipp.c |1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index f227f54..6e1a1a2 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -51,7 +51,7 @@ config DRM_EXYNOS_G2D config DRM_EXYNOS_IPP bool Exynos DRM IPP - depends on DRM_EXYNOS !ARCH_MULTIPLATFORM + depends on DRM_EXYNOS help Choose this option if you want to use IPP feature for DRM. @@ -69,6 +69,6 @@ config DRM_EXYNOS_ROTATOR config DRM_EXYNOS_GSC bool Exynos DRM GSC - depends on DRM_EXYNOS_IPP ARCH_EXYNOS5 + depends on DRM_EXYNOS_IPP ARCH_EXYNOS5 !ARCH_MULTIPLATFORM help Choose this option if you want to use Exynos GSC for DRM. diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index d519a4e..eefb429 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -16,7 +16,6 @@ #include linux/types.h #include linux/clk.h #include linux/pm_runtime.h -#include plat/map-base.h #include drm/drmP.h #include drm/exynos_drm.h -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drm/exynos: Fix build after removal of DRM_WAKUP
Hi,
2014/1/8 Daniel Vetter dan...@ffwll.ch:
On Tue, Jan 07, 2014 at 01:59:12PM +, Mark Brown wrote:
From: Mark Brown broo...@linaro.org
Commit 57ed0f7b4375 (drm: Kill DRM_WAKUP and DRM_INIT_WAITQUEUE) removed
the definition of DRM_WAKUP but did not remove the use of it in the Exynos
DRM driver causing it to fail to build. Fix that.
Signed-off-by: Mark Brown broo...@linaro.org
Oops, looks like something slipped past between me making the patches and
them getting merged. Thanks for taking care of this. Both patches are
These patches already were posted by Seung-Woo link below, and I
merged already them to exynos-drm-next.
http://www.spinics.net/lists/dri-devel/msg50921.html
Thanks,
Inki Dae
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bdfe31fb731b..05b72b07a134 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -706,7 +706,7 @@ static irqreturn_t fimd_irq_handler(int irq, void
*dev_id)
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(ctx-wait_vsync_event)) {
atomic_set(ctx-wait_vsync_event, 0);
- DRM_WAKEUP(ctx-wait_vsync_queue);
+ wake_up(ctx-wait_vsync_queue);
}
out:
return IRQ_HANDLED;
--
1.8.5.2
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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] video: exynos_mipi_dsim: Remove unused variable
Hi Olof,
-Original Message-
From: Olof Johansson [mailto:o...@lixom.net]
Sent: Friday, November 15, 2013 10:49 AM
To: Greg Kroah-Hartman
Cc: Kishon Vijay Abraham I; linux-fb...@vger.kernel.org; linux-samsung-
s...@vger.kernel.org; linux-ker...@vger.kernel.org; Sylwester Nawrocki;
InKi Dae
Subject: Re: [PATCH] video: exynos_mipi_dsim: Remove unused variable
On Thu, Nov 14, 2013 at 5:32 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Thu, Nov 14, 2013 at 01:09:24PM -0800, Olof Johansson wrote:
commit 7e0be9f9f7cba3356f75b86737dbe3a005da067e ('video:
exynos_mipi_dsim:
Use the generic PHY driver') resulted in a warning about an unused
variable:
drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable
'pdev' [-Wunused-variable]
It is indeed unused; remove it.
Signed-off-by: Olof Johansson o...@lixom.net
Cc: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/video/exynos/exynos_mipi_dsi.c |1 -
1 file changed, 1 deletion(-)
I had to take the offending patch through my tree due to the phy
changes, but I'm not the maintainer of it, nor the video mantainer, so I
can't really take this patch through my trees, sorry.
I was wondering why you had signed off, since it didn't follow the
regular path. Makes sense.
So, looks like most historical patches to this file have gone through
Andrew. Can I get an ack from someone and just take it through arm-soc
in this case, please? Inki?
Acked-by: Inki Dae inki@samsung.com
Thanks,
Inki Dae
-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 v2 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
Hi Rahul, I have merged the re-factoring patch set from Sean Paul to exynos-drm-next except eDP related patch set that these need more reviews. Can you re-base at top of exynos-drm-next? Thanks, Inki Dae 2013/10/22 Rahul Sharma rahul.sha...@samsung.com: Currently, exynos hdmiphy operations and configs are kept inside the hdmi driver. Hdmiphy related code is very tightly coupled with hdmi IP driver. With these patches, hdmiphy related stuff is moved to hdmiphy i2c driver for exynos4 and exynos5250 socs. hdmi driver, being the phy controller, calls exynos hdmiphy interfaces. This series also removes hdmiphy dummy clock for hdmiphy and replace it with Phy PMU Control from the hdmiphy driver. At the end, support for exynos5420 hdmiphy is added to the hdmiphy platform driver. Drm related paches are based on exynos-drm-next branch at git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Arch related paches are based on for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git Rahul Sharma (7): drm/exynos: move hdmiphy code to hdmiphy i2c driver drm/exynos: remove dummy hdmiphy clock drm/exynos: add hdmiphy platform driver for exynos5420 drm/exynos: add hdmiphy pmu bit control in hdmiphy drivers exynos/drm: fix ddc i2c device probe failure ARM: dts: update hdmiphy dt node for exynos5250 ARM: dts: update hdmiphy dt node for exynos5420 .../devicetree/bindings/video/exynos_hdmi.txt |2 + .../devicetree/bindings/video/exynos_hdmiphy.txt |8 +- arch/arm/boot/dts/exynos5250-smdk5250.dts |9 +- arch/arm/boot/dts/exynos5420.dtsi | 14 +- drivers/gpu/drm/exynos/Makefile|3 +- drivers/gpu/drm/exynos/exynos_ddc.c|5 + drivers/gpu/drm/exynos/exynos_hdmi.c | 407 +--- drivers/gpu/drm/exynos/exynos_hdmiphy.c| 65 --- drivers/gpu/drm/exynos/exynos_hdmiphy.h| 46 ++ drivers/gpu/drm/exynos/exynos_hdmiphy_i2c.c| 484 drivers/gpu/drm/exynos/exynos_hdmiphy_platform.c | 418 + drivers/gpu/drm/exynos/exynos_hdmiphy_priv.h | 36 ++ drivers/gpu/drm/exynos/regs-hdmiphy.h | 37 ++ 13 files changed, 1174 insertions(+), 360 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.c create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.h create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy_i2c.c create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy_platform.c create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy_priv.h create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/12] Add DRM Exynos HDMI on SoCs from Exynos4 family
Hi Tomasz, I have merged the re-factoring patch set from Sean Paul. Can you re-base your patch set at top of exynos-drm-next? Thanks, Inki Dae 2013/10/21 Tomasz Stanislawski t.stanisl...@samsung.com: This patchset adds support for HDMI at SoCs from Exynos4 family. The patches are rebased on kishon/next. Additionally, The patchset contains small fixes to PHY and CLK frameworks. I preferred to keep all the patches together for the first version of the RFC. The interesting part might be 'propagation of clk_set_parent()'. This feature allows to remove the usage of artificial clocks in drivers. Such a situation happens for Exynos HDMI and 'mout_hdmi' where the clock is not even mentioned in some versions of SoC's documentation. Since enabling and setting rate can be propagated I think that clk_set_parent() should also be propagated. This would simplify driver's code and make it less dependant on SoC's version. Another interesting feature refers to simple PHY driver. This driver register a PHY interface that operates by setting a special bit in platform register. This situation is very common in Exynos SoCs. The current version supports only one phy per node. The code might be modified to support multiple phys from single simple-phy provider to avoid creation of multiple nodes in DT. All comments are welcome. Regards, Tomasz Stanislawski Tomasz Stanislawski (12): clk: propagate parent change up one level clk: exynos4: export sclk_hdmiphy clock clk: exynos4: enable clk_set_parent() propagation for sclk_hdmi and sclk_mixer clocks phy: Add simple-phy driver phy: use of_phy_simple_xlate for NULL xlate function Revert drm/exynos: add mout_hdmi clock in hdmi driver to change parent drm: exynos: hdmi: use hdmiphy as PHY drm: exynos: hdmi: simplify extracting hpd-gpio from DT drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC arm: dts: exynos4: add i2c controller for HDMIPHY arm: dts: exynos4: add HDMI devices arm: dts: universal_c210: add HDMI devices .../devicetree/bindings/clock/exynos4-clock.txt|1 + arch/arm/boot/dts/exynos4.dtsi | 43 +++ arch/arm/boot/dts/exynos4210-universal_c210.dts| 53 arch/arm/boot/dts/exynos4210.dtsi |4 + drivers/clk/clk.c |6 + drivers/clk/samsung/clk-exynos4.c | 10 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 41 +++ drivers/gpu/drm/exynos/exynos_mixer.c |3 + drivers/phy/Kconfig|5 + drivers/phy/Makefile |1 + drivers/phy/phy-core.c |2 +- drivers/phy/phy-simple.c | 128 include/linux/clk-provider.h |1 + 13 files changed, 269 insertions(+), 29 deletions(-) create mode 100644 drivers/phy/phy-simple.c -- 1.7.9.5 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/12] Add DRM Exynos HDMI on SoCs from Exynos4 family
2013/10/29 Kukjin Kim kgene@samsung.com: On 10/28/13 06:42, Inki Dae wrote: Hi Tomasz, I have merged the re-factoring patch set from Sean Paul. Can you re-base your patch set at top of exynos-drm-next? Basically, RFC is not patch for merge. So Tomasz needs to re-submit after addressing comments from RFC. There must definitely be your misunderstanding. I have never merged this RFC patch set. For review, shouldn't this RFC patch set be rebased at top of latest exynos-drm-next? :) Thanks, Inki Dae Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
-Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Thursday, October 10, 2013 6:37 PM To: Inki Dae Cc: 'Olof Johansson'; 'Sean Paul'; devicet...@vger.kernel.org; linux- samsung-...@vger.kernel.org; linux-...@vger.kernel.org; linux- ker...@vger.kernel.org; 'DRI mailing list'; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver On Thu, Oct 10, 2013 at 01:18:05PM +0900, Inki Dae wrote: 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. No, don't model things that aren't regulators as regulators - it's just confusing from a usability standpoint and causes breakage when the pins don't behave like regulators. It seems that there was your missing point. That _is not_ what I mentioned. I mean that other boards can use a regulator instead of gpio pin. What I'm saying is no boards should use a regulator to control that GPIO pin, obviously if they're controlling the actual regulators that's fine That is what I mentioned. Some boards _could control_ the actual regulator for lvds-bridge, and that would be depended on how HW engineer designs the board. but the reset signal should not be controlled via the regulator API (there are some unfortunate cases where people have done that already but let's not have any more). -- 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
-Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Thursday, October 10, 2013 3:29 AM To: Inki Dae Cc: Olof Johansson; Sean Paul; devicet...@vger.kernel.org; linux-samsung- s...@vger.kernel.org; linux-...@vger.kernel.org; linux- ker...@vger.kernel.org; DRI mailing list; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver On Fri, Oct 04, 2013 at 11:05:48AM +0900, Inki Dae wrote: 2013/10/4 Olof Johansson o...@lixom.net: 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. No, don't model things that aren't regulators as regulators - it's just confusing from a usability standpoint and causes breakage when the pins don't behave like regulators. It seems that there was your missing point. That _is not_ what I mentioned. I mean that other boards can use a regulator instead of gpio pin. -- 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
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Friday, October 04, 2013 11:17 PM
To: Inki Dae
Cc: Kukjin Kim; DRI mailing list; linux-samsung-soc@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux-
d...@vger.kernel.org; devicet...@vger.kernel.org; Dave Airlie
Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
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?
The ptn driver isn't exynos-specific, so I don't think making it an
exynos_drm_subdrv is appropriate.
I _really know_ that the ptn driver isn't exynos-specific. I mean that you
can use exynos_drm_subdrv somehow. ie. you can add a new bridge module
specific to exynos, and this module can register its own sub driver at end
of probe. Why do you try to use such tricky codes?
Thanks,
Inki Dae
Sean
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
RE: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Saturday, October 05, 2013 12:05 AM
To: Inki Dae
Cc: Kukjin Kim; DRI mailing list; linux-samsung-soc; Linux ARM Kernel;
Linux Kernel Mailing List; linux-...@vger.kernel.org;
devicet...@vger.kernel.org; Dave Airlie
Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
On Fri, Oct 4, 2013 at 11:01 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Friday, October 04, 2013 11:17 PM
To: Inki Dae
Cc: Kukjin Kim; DRI mailing list; linux-samsung-soc@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
linux-
d...@vger.kernel.org; devicet...@vger.kernel.org; Dave Airlie
Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
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?
The ptn driver isn't exynos-specific, so I don't think making it an
exynos_drm_subdrv is appropriate.
I _really know_ that the ptn driver isn't exynos-specific. I mean that
you
can use exynos_drm_subdrv somehow. ie. you can add a new bridge module
specific to exynos, and this module can register its own sub driver at
end
of probe. Why do you try to use such tricky codes?
So I create a new exynos_lvds_driver which is an i2c driver. When that
probes, all it does is register that driver as an exynos_drm_subdrv.
Then in the subdrv probe I call into ptn3460_init?
That seems a lot more tricky than just calling ptn3460_init directly...
Why more tricky? At least the dt binding will be done in device driver.
Anyway, this also is reasonable to me. It seems that we need a bit different
design for such bridge driver.
Basically, exysnos drm fimd driver has one encoder and one connector, and
these are connected each other, and this connector means lcd panel without
any display bus. So if we want to use display bus, it might need to create a
new encoder and connector for the display bus device. It seems that this way
is more reasonable to me.
ie. if we want for image data goes from fimd to lcd panel, we can connect a
existing connector and crtc of fimd, and if fimd to display bus, we can
connect the new connector and the crtc of fimd through setcrtc or setplane.
Of course, for this we would need more works and efforts. Such tricky codes
definitely are not good.
Thanks,
Inki Dae
Sean
Thanks,
Inki Dae
Sean
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
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 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 encoder\n
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 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
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
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
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 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
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
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: Sylwester Nawrocki [mailto:sylvester.nawro...@gmail.com]
Sent: Monday, September 30, 2013 7:09 AM
To: Inki Dae
Cc: Rahul Sharma; devicet...@vger.kernel.org; linux-samsung-soc;
sw0312.kim; sunil joshi; dri-devel; kgene.kim; Shirish S; Sylwester
Nawrocki; Rahul Sharma; Stephen Warren; Mark Rutland; Kumar Gala; Pawel
Moll; Rob Herring; Sean Paul
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 09/28/2013 06:10 PM, Inki Dae wrote:
Any opinion from Device-Tree folks?
IMO, we should have same consensus on Shirish patches before
proceeding.
Rahul, it seems that DT people have no interest in this issue. So let's
have a consensus about this issue internally.
To Mr. Kyungmin, Sylwester, Kukjin Kim, and Tomasz,
How about keeping hdmiphy config data in each board dts file?
Please don't use HTML and quote only relevant part of e-mails. Otherwise
there are good chances your messages end up in people's spam box.
Ah, I missed checking text mode. Sorry about this. :)
It often helps to Cc a DT binding maintainer directly.
Good idea.
Then, you consider moving the HDMI phy configuration to the device tree.
As Sean suggested in this thread:
Right.
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
+ },
+ },
[trimmed couple more entries]
+};
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them universally.
Shirish has uploaded a patch to the chromium review site to push these
into dt (https://chromium-review.googlesource.com/#/c/65581). Maybe
you can work that into your patch set?
The configuration data is 64 bytes of the register values IIUC. Would it
be
possible to figure out exact meaning of each byte ? Do all of these bytes
Right, but the user manual doesn't describe that enough so we might need to
inquire for what it means to design team.
need to be changed per board ? Perhaps we can have per SoC static tables
in
the PHY driver and be overwriting only some of the bytes with values read
from device tree ?
AFAIR firmware-like binary blobs (register address/value pairs) are not
supposed to be stored in DT.
If there is no detailed documentation for theese PHY configuration tables
I guess there is no choice but to put these raw 64 bytes in DT. Presumably
this should be a an required property defined only by board dts, since
those
values are PCB design dependent.
However, if not all boards need tweaking this configuration data, then it
could make sense to define recommended per-SoC tables in the driver and
overwrite from DT only if it is specified there for a specific board.
If we can come up with universal configuration for a SoC and selected
pixel
clock frequency then it could likely be better to store that in the driver
rather than in DT.
Thanks you your opinion. However, we need to make sure how we take care of
the PHY configuration values. So I will have two steps to merge this pages
set.
To Rahul,
Could you post only your patch set regardless of Shirish's patch? I will
merge your patch set first because as is, Exynos drm hdmi driver is broken.
And, we need more discussions about Shirish patch. So I will not merge this
patch until we have a consensus about it.
To Shirish,
For your patch, it seems that you need to make sure to figure out exact
meaning of each byte of the PHY configuration values first. Maybe you need
to inquire for that to hardware or design team. And please separate the
values into common and specific parts if needed.
Thanks,
Inki Dae
--
Thanks,
Sylwester
--
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/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Tomasz Figa
Sent: Monday, September 30, 2013 8:13 AM
To: Sylwester Nawrocki
Cc: Inki Dae; Rahul Sharma; devicet...@vger.kernel.org; linux-samsung-soc;
sw0312.kim; sunil joshi; dri-devel; kgene.kim; Shirish S; Sylwester
Nawrocki; Rahul Sharma; Stephen Warren; Mark Rutland; Kumar Gala; Pawel
Moll; Rob Herring; Sean Paul
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Monday 30 of September 2013 00:08:46 Sylwester Nawrocki wrote:
On 09/28/2013 06:10 PM, Inki Dae wrote:
Any opinion from Device-Tree folks?
IMO, we should have same consensus on Shirish patches before
proceeding.
Rahul, it seems that DT people have no interest in this issue. So
let's
have a consensus about this issue internally.
To Mr. Kyungmin, Sylwester, Kukjin Kim, and Tomasz,
How about keeping hdmiphy config data in each board dts file?
Please don't use HTML and quote only relevant part of e-mails. Otherwise
there are good chances your messages end up in people's spam box.
It often helps to Cc a DT binding maintainer directly.
Then, you consider moving the HDMI phy configuration to the device tree.
As Sean suggested in this thread:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
I'd like to only add that patches introducing or modifying a device tree
binding need to be acked by at least one DT binding maintainer to be
merged.
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
0x00,
+ },
+ },
[trimmed couple more entries]
+};
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them universally.
Shirish has uploaded a patch to the chromium review site to push these
into dt (https://chromium-review.googlesource.com/#/c/65581). Maybe
you can work that into your patch set?
The configuration data is 64 bytes of the register values IIUC. Would it
be possible to figure out exact meaning of each byte ?
This is definitely something that I would go for. Then for board specific
data appropriate device tree properties could be defined, not just a
binary blob.
Agree. Thanks for your opinion.
Thanks,
Inki Dae
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
--
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/7] drm/exynos: move hdmiphy related code to hdmiphy driver
CCing devicetree,
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Tuesday, September 10, 2013 5:28 PM
To: Sean Paul
Cc: Inki Dae; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 6 September 2013 19:21, Sean Paul seanp...@chromium.org wrote:
On Thu, Sep 5, 2013 at 11:37 PM, Rahul Sharma r.sh.o...@gmail.com
wrote:
On 5 September 2013 19:20, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Thursday, September 05, 2013 10:20 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel;
kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil
joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
On Thu, Sep 5, 2013 at 2:19 AM, Inki Dae inki@samsung.com
wrote:
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-
samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Thursday, September 05, 2013 3:04 PM
To: Inki Dae
Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel;
kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil
joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] =
{
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10,
0x1C,
0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF,
0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00,
0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00,
0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10,
0x9C,
0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF,
0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00,
0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00,
0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10,
0x9C,
0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef,
0xF3,
0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00,
0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01,
0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10,
0x9c,
0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff,
0xf1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00,
0x08,
0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01,
0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10,
0x9C,
0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff,
0xF1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00,
0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02,
0x00,
0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since
these
are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review
site to
push
these
into dt
(https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy
setting
is same as the current board. But if changed, you need to
confirm
with
measurement of signals, because it may vary slightly by
resistance
of
board pattern
Right. it seems that the phy configuration should be adjusted
according
to
PCB
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Thursday, September 05, 2013 3:04 PM
To: Inki Dae
Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these
are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to
push
these
into dt (https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy setting
is same as the current board. But if changed, you need to confirm
with
measurement of signals, because it may vary slightly by resistance
of
board pattern
Right. it seems that the phy configuration should be adjusted
according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by
PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-
board
basis.
In the 5420 datasheet, there are a few register descriptions
available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
post
your patch set after discussing how to rebase these patch set.
Thanks,
Inki Dae
In that case, we need to test the phy confs for all the exynos boards,
supported in
mainline. Probably needs a analyser as well to precisely compare the
deviation.
Shirish patch adds phy config data only to arndale and smdk5250 boards,
and
these config data should have each board specific values. Therefore, for
other boards, shouldn't correct phy config data suitable to their boards
be
added to their board dts files? Is the above analyzer really needed?
Sorry, I had only seen his patches for chromium tree. In mainline
version, he added for 5250 as well. But both sets (for arndale and
smdk) are exactly
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Thursday, September 05, 2013 10:20 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Thu, Sep 5, 2013 at 2:19 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Thursday, September 05, 2013 3:04 PM
To: Inki Dae
Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these
are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to
push
these
into dt
(https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy
setting
is same as the current board. But if changed, you need to confirm
with
measurement of signals, because it may vary slightly by
resistance
of
board pattern
Right. it seems that the phy configuration should be adjusted
according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided
by
PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-
board
basis.
In the 5420 datasheet, there are a few register descriptions
available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch
set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please
re-
post
your patch set after discussing how to rebase these patch set.
Thanks,
Inki Dae
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Wednesday, September 04, 2013 2:48 PM
To: Sean Paul
Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
shir...@chromium.org
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul seanp...@chromium.org wrote:
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma rahul.sha...@samsung.com
wrote:
Exynos hdmiphy operations and configs are kept inside
the hdmi driver. Hdmiphy related code is tightly coupled
with hdmi IP driver.
This patche moves hdmiphy related code to hdmiphy driver.
s/patche/patch
ok.
It will help in cleanly supporting the hdmiphy variations
in further SoCs.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |2 +
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 343
+++
drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
+++-
drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
5 files changed, 533 insertions(+), 296 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 50decf8..240eca5 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -25,6 +25,7 @@ Required properties:
sclk_pixel.
- clock-names: aliases as per driver requirements for above clock IDs:
hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and
mout_hdmi.
+- phy: it points to hdmiphy dt node.
Example:
hdmi {
@@ -32,4 +33,5 @@ Example:
reg = 0x1453 0x10;
interrupts = 0 95 0;
hpd-gpio = gpx3 7 1;
+ phy = hdmiphy;
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 724cab1..1c839f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
exynos_drm_hdmi_context *ctx);
void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
+
+int exynos_hdmiphy_driver_register(void);
+void exynos_hdmiphy_driver_unregister(void);
+
+void exynos_hdmiphy_enable(struct device *dev);
+void exynos_hdmiphy_disable(struct device *dev);
+int exynos_hdmiphy_check_mode(struct device *dev,
+ struct drm_display_mode *mode);
+int exynos_hdmiphy_set_mode(struct device *dev,
+ struct drm_display_mode *mode);
+int exynos_hdmiphy_conf_apply(struct device *dev);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f67ffca..3af4e4c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,6 +34,8 @@
#include linux/io.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
+#include linux/of_platform.h
#include drm/exynos_drm.h
@@ -172,7 +174,6 @@ struct hdmi_v14_conf {
};
struct hdmi_conf_regs {
- int pixel_clock;
int cea_video_id;
union {
struct hdmi_v13_conf v13_conf;
@@ -193,9 +194,9 @@ struct hdmi_context {
int irq;
struct i2c_client *ddc_port;
- struct i2c_client *hdmiphy_port;
+ struct device *hdmiphy_dev;
- /* current hdmiphy conf regs */
+ /* current hdmi ip configuration registers. */
struct hdmi_conf_regs mode_conf;
struct hdmi_resources res;
@@ -205,180 +206,6 @@ struct hdmi_context {
enum hdmi_type type;
};
-struct hdmiphy_config {
- int pixel_clock;
- u8 conf[32];
-};
-
-/* list of phy config settings */
-static const struct hdmiphy_config hdmiphy_v13_configs[] = {
- {
- .pixel_clock = 2700,
- .conf = {
- 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
- 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
- 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
- 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Sean Paul
Sent: Wednesday, September 04, 2013 11:52 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Wed, Sep 4, 2013 at 3:37 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Wednesday, September 04, 2013 2:48 PM
To: Sean Paul
Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
shir...@chromium.org
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul seanp...@chromium.org wrote:
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
rahul.sha...@samsung.com
wrote:
Exynos hdmiphy operations and configs are kept inside
the hdmi driver. Hdmiphy related code is tightly coupled
with hdmi IP driver.
This patche moves hdmiphy related code to hdmiphy driver.
s/patche/patch
ok.
It will help in cleanly supporting the hdmiphy variations
in further SoCs.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |2 +
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 343
+++
drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
+++-
drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
5 files changed, 533 insertions(+), 296 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 50decf8..240eca5 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -25,6 +25,7 @@ Required properties:
sclk_pixel.
- clock-names: aliases as per driver requirements for above clock
IDs:
hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and
mout_hdmi.
+- phy: it points to hdmiphy dt node.
Example:
hdmi {
@@ -32,4 +33,5 @@ Example:
reg = 0x1453 0x10;
interrupts = 0 95 0;
hpd-gpio = gpx3 7 1;
+ phy = hdmiphy;
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 724cab1..1c839f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
exynos_drm_hdmi_context *ctx);
void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
+
+int exynos_hdmiphy_driver_register(void);
+void exynos_hdmiphy_driver_unregister(void);
+
+void exynos_hdmiphy_enable(struct device *dev);
+void exynos_hdmiphy_disable(struct device *dev);
+int exynos_hdmiphy_check_mode(struct device *dev,
+ struct drm_display_mode *mode);
+int exynos_hdmiphy_set_mode(struct device *dev,
+ struct drm_display_mode *mode);
+int exynos_hdmiphy_conf_apply(struct device *dev);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f67ffca..3af4e4c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,6 +34,8 @@
#include linux/io.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
+#include linux/of_platform.h
#include drm/exynos_drm.h
@@ -172,7 +174,6 @@ struct hdmi_v14_conf {
};
struct hdmi_conf_regs {
- int pixel_clock;
int cea_video_id;
union {
struct hdmi_v13_conf v13_conf;
@@ -193,9 +194,9 @@ struct hdmi_context {
int irq;
struct i2c_client *ddc_port;
- struct i2c_client *hdmiphy_port;
+ struct device *hdmiphy_dev;
- /* current hdmiphy conf regs */
+ /* current hdmi ip configuration registers. */
struct hdmi_conf_regs mode_conf;
struct hdmi_resources res;
@@ -205,180 +206,6 @@ struct hdmi_context {
enum hdmi_type
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to push
these
into dt (https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy setting
is same as the current board. But if changed, you need to confirm with
measurement of signals, because it may vary slightly by resistance of
board pattern
Right. it seems that the phy configuration should be adjusted according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-board
basis.
In the 5420 datasheet, there are a few register descriptions available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
post
your patch set after discussing how to rebase these patch set.
Thanks,
Inki Dae
In that case, we need to test the phy confs for all the exynos boards,
supported in
mainline. Probably needs a analyser as well to precisely compare the
deviation.
Shirish patch adds phy config data only to arndale and smdk5250 boards, and
these config data should have each board specific values. Therefore, for
other boards, shouldn't correct phy config data suitable to their boards be
added to their board dts files? Is the above analyzer really needed?
Shirish patch is only for 5420 Peach board. Else, to start with we can
mark
phyconf as optional property which overrides the default Phy Confs for
given SoC.
Hm you mean that hdmiphy driver use the default phy config data in
driver; most boards use the same data, and only in special case; a board
uses different OSC clock rate, the hdmiphy driver use phy config data from
dts file checking hdmiphy-confs property?
regards,
Rahul Sharma.
Sean
--
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 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Monday, September 02, 2013 3:28 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-de...@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 2 September 2013 10:38, Inki Dae inki@samsung.com wrote:
Hi Rahul,
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Friday, August 30, 2013 7:06 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-de...@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Mr. Dae,
I have some points for discussion.
On 30 August 2013 14:03, Inki Dae inki@samsung.com wrote:
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could
fully
hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from
hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*apply)(struct device *dev);
};
Above looks fine to me. I will hide the ops as you suggested.
at exynos_hdmi.c
/*
* Add a new structure for hdmi driver data.
* type could be HDMI_TYPE13 or HDMI_TYPE14.
* i2c_hdmiphy could be true or false: true means that current hdmi
device
uses i2c
* based hdmiphy device, otherwise platform device based one.
*/
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};
...
/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};
/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};
static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data = (void *)exynos4212_hdmi_drv_data,
}, {
...
.compatible = samsung,exynos5420-hdmi,
.data = (void *)exynos5420_hdmi_drv_data,
}, {
}
};
/* the below example function shows how hdmiphy interfaces can be
hided
from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
This looks fine.
}
static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;
...
/* Register hdmiphy driver according to i2c_hdmiphy value. */
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value. */
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}
at exynos_hdmiphy.c
/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};
struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};
Actually, Ops for Hdmiphy I2c and platform devices are exactly
same. We don't need 2 sets. Only difference is in static function to
write configuration values to phy. Based on i2c_verify_client(hdata-
dev),
we use i2c_master_send or writeb.
struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
i2c_hdmiphy)
{
/* Return hdmiphy ops appropriately according to i2c_hdmiphy.
*/
if (i2c_hdmiphy)
return hdmiphy_i2c_ops;
return hdmiphy_platdev_ops;
}
We don't need i2c_hdmiphy flag from the hdmi driver. After probe,
this information is available in hdmiphy driver itself.
int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy
RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Monday, September 02, 2013 6:06 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-de...@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 2 September 2013 12:52, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Monday, September 02, 2013 3:28 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-de...@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
On 2 September 2013 10:38, Inki Dae inki@samsung.com wrote:
Hi Rahul,
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Friday, August 30, 2013 7:06 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc;
dri-de...@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa;
Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Mr. Dae,
I have some points for discussion.
On 30 August 2013 14:03, Inki Dae inki@samsung.com wrote:
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could
fully
hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from
hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct
drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct
drm_display_mode
*mode);
int (*apply)(struct device *dev);
};
Above looks fine to me. I will hide the ops as you suggested.
at exynos_hdmi.c
/*
* Add a new structure for hdmi driver data.
* type could be HDMI_TYPE13 or HDMI_TYPE14.
* i2c_hdmiphy could be true or false: true means that current
hdmi
device
uses i2c
* based hdmiphy device, otherwise platform device based one.
*/
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};
...
/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};
/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};
static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data = (void
*)exynos4212_hdmi_drv_data,
}, {
...
.compatible = samsung,exynos5420-hdmi,
.data = (void
*)exynos5420_hdmi_drv_data,
}, {
}
};
/* the below example function shows how hdmiphy interfaces can be
hided
from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
This looks fine.
}
static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;
...
/* Register hdmiphy driver according to i2c_hdmiphy value.
*/
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value.
*/
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}
at exynos_hdmiphy.c
/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};
struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};
Actually, Ops for Hdmiphy I2c and platform devices are exactly
same. We don't need 2 sets. Only difference is in static function
RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
Hi Rahul,
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Friday, August 30, 2013 7:06 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-de...@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
Thanks Mr. Dae,
I have some points for discussion.
On 30 August 2013 14:03, Inki Dae inki@samsung.com wrote:
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could fully
hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*apply)(struct device *dev);
};
Above looks fine to me. I will hide the ops as you suggested.
at exynos_hdmi.c
/*
* Add a new structure for hdmi driver data.
* type could be HDMI_TYPE13 or HDMI_TYPE14.
* i2c_hdmiphy could be true or false: true means that current hdmi
device
uses i2c
* based hdmiphy device, otherwise platform device based one.
*/
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};
...
/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};
/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};
static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data = (void *)exynos4212_hdmi_drv_data,
}, {
...
.compatible = samsung,exynos5420-hdmi,
.data = (void *)exynos5420_hdmi_drv_data,
}, {
}
};
/* the below example function shows how hdmiphy interfaces can be hided
from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
This looks fine.
}
static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;
...
/* Register hdmiphy driver according to i2c_hdmiphy value. */
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value. */
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}
at exynos_hdmiphy.c
/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};
struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};
Actually, Ops for Hdmiphy I2c and platform devices are exactly
same. We don't need 2 sets. Only difference is in static function to
write configuration values to phy. Based on i2c_verify_client(hdata-dev),
we use i2c_master_send or writeb.
struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
i2c_hdmiphy)
{
/* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
if (i2c_hdmiphy)
return hdmiphy_i2c_ops;
return hdmiphy_platdev_ops;
}
We don't need i2c_hdmiphy flag from the hdmi driver. After probe,
this information is available in hdmiphy driver itself.
int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
{
...
/* Register hdmiphy driver appropriately according to
i2c_hdmiphy.
*/
if (i2c_hdmiphy) {
ret = i2c_add_driver(hdmiphy_i2c_driver);
...
} else {
ret =
platform_driver_register(hdmiphy_platform_driver);
...
}
Here i2c_hdmiphy flag helps in avoiding registering both i2c
and platform drivers for phy. But is it a concern that we should
not register 2 drivers on different buses for single hw device. I am
still not clear on this.
Otherwise we do not need to maintain i2c_hdmiphy flag
RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could fully hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct drm_display_mode *mode);
int (*apply)(struct device *dev);
};
at exynos_hdmi.c
/*
* Add a new structure for hdmi driver data.
* type could be HDMI_TYPE13 or HDMI_TYPE14.
* i2c_hdmiphy could be true or false: true means that current hdmi device
uses i2c
* based hdmiphy device, otherwise platform device based one.
*/
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};
...
/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};
/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};
static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data = (void *)exynos4212_hdmi_drv_data,
}, {
...
.compatible = samsung,exynos5420-hdmi,
.data = (void *)exynos5420_hdmi_drv_data,
}, {
}
};
/* the below example function shows how hdmiphy interfaces can be hided from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
}
static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;
...
/* Register hdmiphy driver according to i2c_hdmiphy value. */
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value. */
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}
at exynos_hdmiphy.c
/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};
struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};
struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int i2c_hdmiphy)
{
/* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
if (i2c_hdmiphy)
return hdmiphy_i2c_ops;
return hdmiphy_platdev_ops;
}
int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
{
...
/* Register hdmiphy driver appropriately according to i2c_hdmiphy.
*/
if (i2c_hdmiphy) {
ret = i2c_add_driver(hdmiphy_i2c_driver);
...
} else {
ret = platform_driver_register(hdmiphy_platform_driver);
...
}
return ret;
}
Thanks,
Inki Dae
-Original Message-
From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
Sent: Friday, August 30, 2013 3:59 PM
To: linux-samsung-soc@vger.kernel.org; dri-de...@lists.freedesktop.org
Cc: kgene@samsung.com; sw0312@samsung.com; inki@samsung.com;
seanp...@chromium.org; l.st...@pengutronix.de; tomasz.f...@gmail.com;
s.nawro...@samsung.com; jo...@samsung.com; r.sh.o...@gmail.com; Rahul
Sharma
Subject: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
Currently, exynos hdmiphy operations and configs are kept
inside the hdmi driver. Hdmiphy related code is tightly
coupled with hdmi IP driver.
This series also removes hdmiphy dummy clock for hdmiphy
and replace it with Phy PMU Control from the hdmiphy driver.
At the end, support for exynos5420 hdmiphy is added to the
hdmiphy driver which is a platform device.
Drm related paches are based on exynos-drm-next branch at
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
Arch patches are dependent on
http://www.mail-archive.com/linux-samsung-
s...@vger.kernel.org/msg22195.html
Rahul Sharma (7):
drm/exynos: move hdmiphy related code to hdmiphy driver
drm/exynos: remove dummy hdmiphy clock
drm/exynos: add hdmiphy pmu bit control in hdmiphy driver
drm/exynos: add support for exynos5420 hdmiphy
exynos/drm: fix ddc i2c device probe failure
ARM: dts: update hdmiphy dt node for exynos5250
ARM: dts: update hdmiphy dt node for exynos5420
.../devicetree/bindings
RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
One more thing, you would need to check if other driver can be probed in
probe context. With your patch, exynos_hdmiphy_driver_register() is called
in hdmi_probe() via hdmi_get_phy_device(), and then
platform_driver_reigster() is called via the
exynos_hdmiphy_driver_register(). I remember that was failed.
Thanks,
Inki Dae
-Original Message-
From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
[mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
Behalf Of Inki Dae
Sent: Friday, August 30, 2013 5:33 PM
To: 'Rahul Sharma'; linux-samsung-soc@vger.kernel.org; dri-
de...@lists.freedesktop.org
Cc: kgene@samsung.com; sw0312@samsung.com; jo...@samsung.com;
s.nawro...@samsung.com
Subject: RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could fully
hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct drm_display_mode *mode);
int (*apply)(struct device *dev);
};
at exynos_hdmi.c
/*
* Add a new structure for hdmi driver data.
* type could be HDMI_TYPE13 or HDMI_TYPE14.
* i2c_hdmiphy could be true or false: true means that current hdmi
device
uses i2c
* based hdmiphy device, otherwise platform device based one.
*/
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};
...
/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};
/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};
static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data = (void *)exynos4212_hdmi_drv_data,
}, {
...
.compatible = samsung,exynos5420-hdmi,
.data = (void *)exynos5420_hdmi_drv_data,
}, {
}
};
/* the below example function shows how hdmiphy interfaces can be hided
from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
}
static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;
...
/* Register hdmiphy driver according to i2c_hdmiphy value. */
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value. */
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}
at exynos_hdmiphy.c
/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};
struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};
struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
i2c_hdmiphy)
{
/* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
if (i2c_hdmiphy)
return hdmiphy_i2c_ops;
return hdmiphy_platdev_ops;
}
int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
{
...
/* Register hdmiphy driver appropriately according to i2c_hdmiphy.
*/
if (i2c_hdmiphy) {
ret = i2c_add_driver(hdmiphy_i2c_driver);
...
} else {
ret = platform_driver_register(hdmiphy_platform_driver);
...
}
return ret;
}
Thanks,
Inki Dae
-Original Message-
From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
Sent: Friday, August 30, 2013 3:59 PM
To: linux-samsung-soc@vger.kernel.org; dri-de...@lists.freedesktop.org
Cc: kgene@samsung.com; sw0312@samsung.com; inki@samsung.com;
seanp...@chromium.org; l.st...@pengutronix.de; tomasz.f...@gmail.com;
s.nawro...@samsung.com; jo...@samsung.com; r.sh.o...@gmail.com; Rahul
Sharma
Subject: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
Currently, exynos hdmiphy operations and configs are kept
inside the hdmi driver. Hdmiphy related code is tightly
coupled with hdmi IP driver.
This series also
RE: [PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree
-Original Message- From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc- ow...@vger.kernel.org] On Behalf Of Andrzej Hajda Sent: Wednesday, August 21, 2013 11:22 PM To: open list:DRM DRIVERS FOR E... Cc: Andrzej Hajda; Inki Dae; Joonyoung Shim; Seung-Woo Kim; Kyungmin Park; David Airlie; moderated list:ARM/S5P EXYNOS AR...; t.f...@samsung.com; s.nawro...@samsung.com Subject: [PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree Hi, This patch series adds signal polarities parsing from display-timings devicetree node. To do it efficiently struct fb_videomode is replaced with struct videomode and some additional code cleaning is performed. Good patch set. Applied. Thanks, Inki Dae The patches are for drm-exynos/exynos-drm-next branch. Regards Andrzej Hajda Andrzej Hajda (3): drm/exynos: fimd: replace struct fb_videomode with videomode drm/exynos: fimd: get signal polarities from device tree drm/exynos: fimd: move platform data parsing to separate function drivers/gpu/drm/exynos/exynos_drm_connector.c | 33 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 189 +- include/drm/exynos_drm.h | 3 +- 3 files changed, 103 insertions(+), 122 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-samsung- soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create
One more thing, changed the subject to Consider fallback option to
allocation fail. The subject is too long :)
Thanks,
Inki Dae
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Vikas Sajjan
Sent: Tuesday, August 27, 2013 12:05 PM
To: Inki Dae
Cc: DRI mailing list; kgene.kim; Sylwester Nawrocki; Rob Clark; Tomasz
Figa; Laurent Pinchart; Patch Tracking; linaro-...@lists.linaro.org; sunil
joshi; linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH] drm/exynos: Add fallback option to get non physically
contiguous memory for gem_dumb_create
Thanks.
On 27 August 2013 08:14, Inki Dae inki@samsung.com wrote:
Applied.
Thanks,
Inki Dae
-Original Message-
From: Vikas Sajjan [mailto:vikas.saj...@linaro.org]
Sent: Friday, August 23, 2013 3:35 PM
To: dri-de...@lists.freedesktop.org; inki@samsung.com
Cc: kgene@samsung.com; s.nawro...@samsung.com; robdcl...@gmail.com;
tomasz.f...@gmail.com; laurent.pinch...@ideasonboard.com;
patc...@linaro.org; linaro-...@lists.linaro.org
Subject: [PATCH] drm/exynos: Add fallback option to get non physically
contiguous memory for gem_dumb_create
To address the case where physically contiguous memory MAY NOT be a
mandatory
requirement for framebuffer for the application calling
exynos_drm_gem_dumb_create,
the patch adds a feature to get non physically contiguous memory for
framebuffer,
if physically contiguous memory allocation fails and if IOMMU is
supported.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Signed-off-by: Arun Kumar arun...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2eabe1a..66d1b40 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -17,6 +17,7 @@
#include exynos_drm_drv.h
#include exynos_drm_gem.h
#include exynos_drm_buf.h
+#include exynos_drm_iommu.h
static unsigned int convert_to_vm_err_msg(int msg)
{
@@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file
*file_priv,
exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
EXYNOS_BO_WC,
args-size);
+ /*
+ * If physically contiguous memory allocation fails and if IOMMU
is
+ * supported then try to get buffer from non physically
contiguous
+ * memory area.
+ */
+ if (IS_ERR(exynos_gem_obj) is_drm_iommu_supported(dev)) {
+ dev_warn(dev-dev, contiguous FB allocation failed,
falling
back to non-contiguous\n);
+ exynos_gem_obj = exynos_drm_gem_create(dev,
+ EXYNOS_BO_NONCONTIG |
EXYNOS_BO_WC,
+ args-size);
+ }
+
if (IS_ERR(exynos_gem_obj))
return PTR_ERR(exynos_gem_obj);
--
1.7.9.5
--
Thanks and Regards
Vikas Sajjan
--
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
