* [PATCH V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
@ 2014-07-25 19:22 ` Ajay Kumar
2014-07-30 10:00 ` Thierry Reding
2014-07-25 19:22 ` [PATCH V6 2/8] drm/panel: Add support for prepare and unprepare routines Ajay Kumar
` (8 subsequent siblings)
9 siblings, 1 reply; 70+ messages in thread
From: Ajay Kumar @ 2014-07-25 19:22 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g, Ajay Kumar
Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BACKLIGHT_EN
And, a de-init sequence as mentioned below:
-- poweroff LED unit/BACKLIGHT_EN
-- stop video data
-- poweroff LCD unit/LCD_EN
With existing callbacks for drm panel, we cannot accomodate such panels,
since only two callbacks, i.e "panel_enable" and panel_disable are supported.
This patch adds:
-- "prepare" callback which can be called before
the actual video data is on, and then call the "enable"
callback after the video data is available.
-- "unprepare" callback which can be called after
the video data is off, and use "disable" callback
to do something before switching off the video data.
Now, we can easily map the above scenario as shown below:
poweron LCD unit/LCD_EN = "prepare" callback
poweron LED unit/BACKLIGHT_EN = "enable" callback
poweroff LED unit/BACKLIGHT_EN = "disable" callback
poweroff LCD unit/LCD_EN = "unprepare" callback
Also, a helper function for get_modes is added.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
include/drm/drm_panel.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index c2ab77a..efc63cc 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -31,7 +31,9 @@ struct drm_device;
struct drm_panel;
struct drm_panel_funcs {
+ int (*unprepare)(struct drm_panel *panel);
int (*disable)(struct drm_panel *panel);
+ int (*prepare)(struct drm_panel *panel);
int (*enable)(struct drm_panel *panel);
int (*get_modes)(struct drm_panel *panel);
};
@@ -46,6 +48,14 @@ struct drm_panel {
struct list_head list;
};
+static inline int drm_panel_unprepare(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->unprepare)
+ return panel->funcs->unprepare(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
static inline int drm_panel_disable(struct drm_panel *panel)
{
if (panel && panel->funcs && panel->funcs->disable)
@@ -54,6 +64,14 @@ static inline int drm_panel_disable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
}
+static inline int drm_panel_prepare(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->prepare)
+ return panel->funcs->prepare(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
static inline int drm_panel_enable(struct drm_panel *panel)
{
if (panel && panel->funcs && panel->funcs->enable)
@@ -62,6 +80,14 @@ static inline int drm_panel_enable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
}
+static inline int drm_panel_get_modes(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->get_modes)
+ return panel->funcs->get_modes(panel);
+
+ return 0;
+}
+
void drm_panel_init(struct drm_panel *panel);
int drm_panel_add(struct drm_panel *panel);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines
2014-07-25 19:22 ` [PATCH V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines Ajay Kumar
@ 2014-07-30 10:00 ` Thierry Reding
2014-07-30 10:29 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 10:00 UTC (permalink / raw)
To: Ajay Kumar
Cc: devicetree, linux-samsung-soc, seanpaul, daniel.vetter, joshi,
dri-devel, ajaynumb, prashanth.g
[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]
On Sat, Jul 26, 2014 at 12:52:03AM +0530, Ajay Kumar wrote:
> Most of the panels need an init sequence as mentioned below:
> -- poweron LCD unit/LCD_EN
> -- start video data
> -- poweron LED unit/BACKLIGHT_EN
> And, a de-init sequence as mentioned below:
> -- poweroff LED unit/BACKLIGHT_EN
> -- stop video data
> -- poweroff LCD unit/LCD_EN
> With existing callbacks for drm panel, we cannot accomodate such panels,
> since only two callbacks, i.e "panel_enable" and panel_disable are supported.
>
> This patch adds:
> -- "prepare" callback which can be called before
> the actual video data is on, and then call the "enable"
> callback after the video data is available.
>
> -- "unprepare" callback which can be called after
> the video data is off, and use "disable" callback
> to do something before switching off the video data.
>
> Now, we can easily map the above scenario as shown below:
> poweron LCD unit/LCD_EN = "prepare" callback
> poweron LED unit/BACKLIGHT_EN = "enable" callback
> poweroff LED unit/BACKLIGHT_EN = "disable" callback
> poweroff LCD unit/LCD_EN = "unprepare" callback
>
> Also, a helper function for get_modes is added.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> ---
> include/drm/drm_panel.h | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
I had already decided to apply an earlier version that you posted (I
think the only difference was that it didn't have the inline
implementation for drm_panel_get_modes() yet), reworded the commit
message a little (to be less specific about LED, LCD and backlight
units) and added some kerneldoc for struct drm_panel_funcs.
What I propose is to merge that patch (I'll hopefully push it today so
that it shows up in tomorrow's linux-next) and then apply a separate
patch to add drm_panel_get_modes().
Do you have any objections to that?
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines
2014-07-30 10:00 ` Thierry Reding
@ 2014-07-30 10:29 ` Ajay kumar
0 siblings, 0 replies; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 10:29 UTC (permalink / raw)
To: Thierry Reding
Cc: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree, InKi Dae,
Rob Clark, Daniel Vetter, Sean Paul, Jingoo Han, sunil joshi,
Prashanth G
On Wed, Jul 30, 2014 at 3:30 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sat, Jul 26, 2014 at 12:52:03AM +0530, Ajay Kumar wrote:
>> Most of the panels need an init sequence as mentioned below:
>> -- poweron LCD unit/LCD_EN
>> -- start video data
>> -- poweron LED unit/BACKLIGHT_EN
>> And, a de-init sequence as mentioned below:
>> -- poweroff LED unit/BACKLIGHT_EN
>> -- stop video data
>> -- poweroff LCD unit/LCD_EN
>> With existing callbacks for drm panel, we cannot accomodate such panels,
>> since only two callbacks, i.e "panel_enable" and panel_disable are supported.
>>
>> This patch adds:
>> -- "prepare" callback which can be called before
>> the actual video data is on, and then call the "enable"
>> callback after the video data is available.
>>
>> -- "unprepare" callback which can be called after
>> the video data is off, and use "disable" callback
>> to do something before switching off the video data.
>>
>> Now, we can easily map the above scenario as shown below:
>> poweron LCD unit/LCD_EN = "prepare" callback
>> poweron LED unit/BACKLIGHT_EN = "enable" callback
>> poweroff LED unit/BACKLIGHT_EN = "disable" callback
>> poweroff LCD unit/LCD_EN = "unprepare" callback
>>
>> Also, a helper function for get_modes is added.
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> ---
>> include/drm/drm_panel.h | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>
> I had already decided to apply an earlier version that you posted (I
> think the only difference was that it didn't have the inline
> implementation for drm_panel_get_modes() yet), reworded the commit
> message a little (to be less specific about LED, LCD and backlight
> units) and added some kerneldoc for struct drm_panel_funcs.
>
> What I propose is to merge that patch (I'll hopefully push it today so
> that it shows up in tomorrow's linux-next) and then apply a separate
> patch to add drm_panel_get_modes().
>
> Do you have any objections to that?
I am okay with that. drm_panel_get_modes() will come as a separate patch.
Ajay
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH V6 2/8] drm/panel: Add support for prepare and unprepare routines
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
2014-07-25 19:22 ` [PATCH V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines Ajay Kumar
@ 2014-07-25 19:22 ` Ajay Kumar
2014-07-30 10:32 ` Thierry Reding
2014-07-25 19:22 ` [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel Ajay Kumar
` (7 subsequent siblings)
9 siblings, 1 reply; 70+ messages in thread
From: Ajay Kumar @ 2014-07-25 19:22 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g, Ajay Kumar
Now that we have 2 new callbacks(prepare and unprepare) for drm_panel,
make changes in all the drm drivers which use the drm_panel framework
to support the new callbacks.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 +++--
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +++++
drivers/gpu/drm/panel/panel-ld9040.c | 18 +++++++++--
drivers/gpu/drm/panel/panel-s6e8aa0.c | 18 +++++++++--
drivers/gpu/drm/panel/panel-simple.c | 51 ++++++++++++++++++++++++-------
drivers/gpu/drm/tegra/output.c | 2 ++
6 files changed, 85 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 3aa1c7e..fa08f05 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -125,14 +125,18 @@ static int exynos_dpi_create_connector(struct exynos_drm_display *display,
static void exynos_dpi_poweron(struct exynos_dpi *ctx)
{
- if (ctx->panel)
+ if (ctx->panel) {
+ drm_panel_prepare(ctx->panel);
drm_panel_enable(ctx->panel);
+ }
}
static void exynos_dpi_poweroff(struct exynos_dpi *ctx)
{
- if (ctx->panel)
+ if (ctx->panel) {
drm_panel_disable(ctx->panel);
+ drm_panel_unprepare(ctx->panel);
+ }
}
static void exynos_dpi_dpms(struct exynos_drm_display *display, int mode)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..2f58e45 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1333,6 +1333,12 @@ static int exynos_dsi_enable(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
+ ret = drm_panel_prepare(dsi->panel);
+ if (ret < 0) {
+ exynos_dsi_poweroff(dsi);
+ return ret;
+ }
+
ret = drm_panel_enable(dsi->panel);
if (ret < 0) {
exynos_dsi_poweroff(dsi);
@@ -1354,6 +1360,7 @@ static void exynos_dsi_disable(struct exynos_dsi *dsi)
exynos_dsi_set_display_enable(dsi, false);
drm_panel_disable(dsi->panel);
+ drm_panel_unprepare(dsi->panel);
exynos_dsi_poweroff(dsi);
dsi->state &= ~DSIM_STATE_ENABLED;
diff --git a/drivers/gpu/drm/panel/panel-ld9040.c b/drivers/gpu/drm/panel/panel-ld9040.c
index db1601f..046d9fe 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -214,7 +214,7 @@ static int ld9040_power_off(struct ld9040 *ctx)
return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
}
-static int ld9040_disable(struct drm_panel *panel)
+static int ld9040_unprepare(struct drm_panel *panel)
{
struct ld9040 *ctx = panel_to_ld9040(panel);
@@ -228,7 +228,12 @@ static int ld9040_disable(struct drm_panel *panel)
return ld9040_power_off(ctx);
}
-static int ld9040_enable(struct drm_panel *panel)
+static int ld9040_disable(struct drm_panel *panel)
+{
+ return 0;
+}
+
+static int ld9040_prepare(struct drm_panel *panel)
{
struct ld9040 *ctx = panel_to_ld9040(panel);
int ret;
@@ -242,11 +247,16 @@ static int ld9040_enable(struct drm_panel *panel)
ret = ld9040_clear_error(ctx);
if (ret < 0)
- ld9040_disable(panel);
+ ld9040_unprepare(panel);
return ret;
}
+static int ld9040_enable(struct drm_panel *panel)
+{
+ return 0;
+}
+
static int ld9040_get_modes(struct drm_panel *panel)
{
struct drm_connector *connector = panel->connector;
@@ -272,7 +282,9 @@ static int ld9040_get_modes(struct drm_panel *panel)
}
static const struct drm_panel_funcs ld9040_drm_funcs = {
+ .unprepare = ld9040_unprepare,
.disable = ld9040_disable,
+ .prepare = ld9040_prepare,
.enable = ld9040_enable,
.get_modes = ld9040_get_modes,
};
diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c b/drivers/gpu/drm/panel/panel-s6e8aa0.c
index 06e57a2..51c657a 100644
--- a/drivers/gpu/drm/panel/panel-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
@@ -887,7 +887,7 @@ static int s6e8aa0_power_off(struct s6e8aa0 *ctx)
return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
}
-static int s6e8aa0_disable(struct drm_panel *panel)
+static int s6e8aa0_unprepare(struct drm_panel *panel)
{
struct s6e8aa0 *ctx = panel_to_s6e8aa0(panel);
@@ -900,7 +900,12 @@ static int s6e8aa0_disable(struct drm_panel *panel)
return s6e8aa0_power_off(ctx);
}
-static int s6e8aa0_enable(struct drm_panel *panel)
+static int s6e8aa0_disable(struct drm_panel *panel)
+{
+ return 0;
+}
+
+static int s6e8aa0_prepare(struct drm_panel *panel)
{
struct s6e8aa0 *ctx = panel_to_s6e8aa0(panel);
int ret;
@@ -913,11 +918,16 @@ static int s6e8aa0_enable(struct drm_panel *panel)
ret = ctx->error;
if (ret < 0)
- s6e8aa0_disable(panel);
+ s6e8aa0_unprepare(panel);
return ret;
}
+static int s6e8aa0_enable(struct drm_panel *panel)
+{
+ return 0;
+}
+
static int s6e8aa0_get_modes(struct drm_panel *panel)
{
struct drm_connector *connector = panel->connector;
@@ -943,7 +953,9 @@ static int s6e8aa0_get_modes(struct drm_panel *panel)
}
static const struct drm_panel_funcs s6e8aa0_drm_funcs = {
+ .unprepare = s6e8aa0_unprepare,
.disable = s6e8aa0_disable,
+ .prepare = s6e8aa0_prepare,
.enable = s6e8aa0_enable,
.get_modes = s6e8aa0_get_modes,
};
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index a251361..fb0cfe2 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -45,7 +45,8 @@ struct panel_desc {
struct panel_simple {
struct drm_panel base;
- bool enabled;
+ bool panel_enabled;
+ bool backlight_enabled;
const struct panel_desc *desc;
@@ -93,11 +94,28 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
return num;
}
+static int panel_simple_unprepare(struct drm_panel *panel)
+{
+ struct panel_simple *p = to_panel_simple(panel);
+
+ if (!p->panel_enabled)
+ return 0;
+
+ if (p->enable_gpio)
+ gpiod_set_value_cansleep(p->enable_gpio, 0);
+
+ regulator_disable(p->supply);
+
+ p->panel_enabled = false;
+
+ return 0;
+}
+
static int panel_simple_disable(struct drm_panel *panel)
{
struct panel_simple *p = to_panel_simple(panel);
- if (!p->enabled)
+ if (!p->backlight_enabled)
return 0;
if (p->backlight) {
@@ -105,21 +123,17 @@ static int panel_simple_disable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}
- if (p->enable_gpio)
- gpiod_set_value_cansleep(p->enable_gpio, 0);
-
- regulator_disable(p->supply);
- p->enabled = false;
+ p->backlight_enabled = false;
return 0;
}
-static int panel_simple_enable(struct drm_panel *panel)
+static int panel_simple_prepare(struct drm_panel *panel)
{
struct panel_simple *p = to_panel_simple(panel);
int err;
- if (p->enabled)
+ if (p->panel_enabled)
return 0;
err = regulator_enable(p->supply);
@@ -131,12 +145,24 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->enable_gpio)
gpiod_set_value_cansleep(p->enable_gpio, 1);
+ p->panel_enabled = true;
+
+ return 0;
+}
+
+static int panel_simple_enable(struct drm_panel *panel)
+{
+ struct panel_simple *p = to_panel_simple(panel);
+
+ if (p->backlight_enabled)
+ return 0;
+
if (p->backlight) {
p->backlight->props.power = FB_BLANK_UNBLANK;
backlight_update_status(p->backlight);
}
- p->enabled = true;
+ p->backlight_enabled = true;
return 0;
}
@@ -164,6 +190,8 @@ static int panel_simple_get_modes(struct drm_panel *panel)
static const struct drm_panel_funcs panel_simple_funcs = {
.disable = panel_simple_disable,
+ .unprepare = panel_simple_unprepare,
+ .prepare = panel_simple_prepare,
.enable = panel_simple_enable,
.get_modes = panel_simple_get_modes,
};
@@ -178,7 +206,8 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
if (!panel)
return -ENOMEM;
- panel->enabled = false;
+ panel->panel_enabled = false;
+ panel->backlight_enabled = false;
panel->desc = desc;
panel->supply = devm_regulator_get(dev, "power");
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 446837e..b574ee6 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -139,9 +139,11 @@ static void tegra_encoder_dpms(struct drm_encoder *encoder, int mode)
if (mode != DRM_MODE_DPMS_ON) {
drm_panel_disable(panel);
+ drm_panel_unprepare(panel);
tegra_output_disable(output);
} else {
tegra_output_enable(output);
+ drm_panel_prepare(panel);
drm_panel_enable(panel);
}
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V6 2/8] drm/panel: Add support for prepare and unprepare routines
2014-07-25 19:22 ` [PATCH V6 2/8] drm/panel: Add support for prepare and unprepare routines Ajay Kumar
@ 2014-07-30 10:32 ` Thierry Reding
2014-07-30 11:09 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 10:32 UTC (permalink / raw)
To: Ajay Kumar
Cc: devicetree, linux-samsung-soc, seanpaul, daniel.vetter, joshi,
dri-devel, ajaynumb, prashanth.g
[-- Attachment #1.1: Type: text/plain, Size: 7883 bytes --]
On Sat, Jul 26, 2014 at 12:52:04AM +0530, Ajay Kumar wrote:
> Now that we have 2 new callbacks(prepare and unprepare) for drm_panel,
> make changes in all the drm drivers which use the drm_panel framework
> to support the new callbacks.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> ---
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 +++--
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +++++
> drivers/gpu/drm/panel/panel-ld9040.c | 18 +++++++++--
> drivers/gpu/drm/panel/panel-s6e8aa0.c | 18 +++++++++--
> drivers/gpu/drm/panel/panel-simple.c | 51 ++++++++++++++++++++++++-------
> drivers/gpu/drm/tegra/output.c | 2 ++
> 6 files changed, 85 insertions(+), 19 deletions(-)
I'd prefer for this to be split up into patches per panel and per
display driver. The reason is that if this patch is merged as-is, then
if it's ever determined to cause a regression it'll be difficult to find
out which change exactly caused this.
But to not break bisectability you'll need to be careful in how you
break up the patches. I think the following should work:
- for each panel driver, implement dummy .prepare() and
.unprepare() that return 0
- for each display driver, make use of drm_panel_prepare() and
drm_panel_unprepare()
- for each panel driver, properly implement .prepare() and
.unprepare() (presumably by moving code out of .enable() and
.disable(), respectively)
I have a couple more comments below about the ordering of the .prepare()
vs. .enable() and .disable() vs. .unprepare() calls.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 5e78d45..2f58e45 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1333,6 +1333,12 @@ static int exynos_dsi_enable(struct exynos_dsi *dsi)
> if (ret < 0)
> return ret;
>
> + ret = drm_panel_prepare(dsi->panel);
> + if (ret < 0) {
> + exynos_dsi_poweroff(dsi);
> + return ret;
> + }
> +
> ret = drm_panel_enable(dsi->panel);
> if (ret < 0) {
> exynos_dsi_poweroff(dsi);
> @@ -1354,6 +1360,7 @@ static void exynos_dsi_disable(struct exynos_dsi *dsi)
>
> exynos_dsi_set_display_enable(dsi, false);
> drm_panel_disable(dsi->panel);
> + drm_panel_unprepare(dsi->panel);
> exynos_dsi_poweroff(dsi);
I don't know Exynos very well, so this may be completely wrong, but
should disable_panel_prepare() be called much earlier than
drm_panel_enable() and drm_panel_unprepare() much later than
drm_panel_disable()? With the above the result is still the same, so
you'll get the same glitches as without their separation.
Without knowing exactly what Exynos does in the above, I'd expect the
correct sequence to be something like this:
ret = exynos_dsi_power_on(dsi);
if (ret < 0)
return ret;
ret = drm_panel_prepare(dsi->panel);
if (ret < 0) {
exynos_dsi_poweroff(dsi);
return ret;
}
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
ret = drm_panel_enable(dsi->panel);
if (ret < 0) {
/* perhaps undo exynos_dsi_set_display_enable() here? */
exynos_dsi_poweroff(dsi);
return ret;
}
And for disable:
drm_panel_disable(dsi->panel);
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi->panel);
exynos_dsi_poweroff(dsi);
Perhaps I should quote the kerneldoc that I added for drm_panel_funcs to
underline why I think this is important:
/**
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
* @unprepare: turn off panel
* @prepare: turn on panel and perform set up
* @enable: enable panel (turn on back light, etc.)
* @get_modes: add modes to the connector that the panel is attached to and
* return the number of modes added
*
* The .prepare() function is typically called before the display controller
* starts to transmit video data. Panel drivers can use this to turn the panel
* on and wait for it to become ready. If additional configuration is required
* (via a control bus such as I2C, SPI or DSI for example) this is a good time
* to do that.
*
* After the display controller has started transmitting video data, it's safe
* to call the .enable() function. This will typically enable the backlight to
* make the image on screen visible. Some panels require a certain amount of
* time or frames before the image is displayed. This function is responsible
* for taking this into account before enabling the backlight to avoid visual
* glitches.
*
* Before stopping video transmission from the display controller it can be
* necessary to turn off the panel to avoid visual glitches. This is done in
* the .disable() function. Analogously to .enable() this typically involves
* turning off the backlight and waiting for some time to make sure no image
* is visible on the panel. It is then safe for the display controller to
* cease transmission of video data.
*
* To save power when no video data is transmitted, a driver can power down
* the panel. This is the job of the .unprepare() function.
*/
As you see, .prepare() should do whatever is necessary to make the panel
accept a stream of video data, then the display driver can start sending
video data and call .enable() to make the transmitted data visible.
Analogously .disable() should turn off the display, so that the user can
no longer see what's going on, then the display controller can cease
transmission of video data (and since the panel is disabled this should
no longer cause visual glitches) and then call .unprepare() to turn the
panel off.
I know that this isn't immediately relevant just yet because currently
the backlight will already turn on by default, but like we discussed
earlier I have ideas on how to properly fix it. As a matter of fact I'll
go and send out another mail about that when I'm through this series.
> static const struct drm_panel_funcs ld9040_drm_funcs = {
> + .unprepare = ld9040_unprepare,
> .disable = ld9040_disable,
> + .prepare = ld9040_prepare,
> .enable = ld9040_enable,
> .get_modes = ld9040_get_modes,
> };
The patch I applied for .prepare() and .unprepare() I've reordered the
functions slightly to give a more natural sequence. .disable() is now
first, while .unprepare() is next, since that's the sequence that they
should be called in.
Patches for the panel drivers should follow this same ordering.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index a251361..fb0cfe2 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -45,7 +45,8 @@ struct panel_desc {
>
> struct panel_simple {
> struct drm_panel base;
> - bool enabled;
> + bool panel_enabled;
> + bool backlight_enabled;
Perhaps this should rather be:
bool prepared;
bool enabled;
?
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index 446837e..b574ee6 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -139,9 +139,11 @@ static void tegra_encoder_dpms(struct drm_encoder *encoder, int mode)
>
> if (mode != DRM_MODE_DPMS_ON) {
> drm_panel_disable(panel);
> + drm_panel_unprepare(panel);
> tegra_output_disable(output);
Similarly to my comments for the Exynos drivers, this should be:
drm_panel_disable(panel);
tegra_output_disable(output);
drm_panel_unprepare(panel);
> } else {
> tegra_output_enable(output);
> + drm_panel_prepare(panel);
> drm_panel_enable(panel);
> }
and
drm_panel_prepare(panel);
tegra_output_enable(output);
drm_panel_enable(panel);
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 2/8] drm/panel: Add support for prepare and unprepare routines
2014-07-30 10:32 ` Thierry Reding
@ 2014-07-30 11:09 ` Ajay kumar
0 siblings, 0 replies; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 11:09 UTC (permalink / raw)
To: Thierry Reding, InKi Dae, Andrzej Hajda
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
On Wed, Jul 30, 2014 at 4:02 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sat, Jul 26, 2014 at 12:52:04AM +0530, Ajay Kumar wrote:
>> Now that we have 2 new callbacks(prepare and unprepare) for drm_panel,
>> make changes in all the drm drivers which use the drm_panel framework
>> to support the new callbacks.
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 +++--
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +++++
>> drivers/gpu/drm/panel/panel-ld9040.c | 18 +++++++++--
>> drivers/gpu/drm/panel/panel-s6e8aa0.c | 18 +++++++++--
>> drivers/gpu/drm/panel/panel-simple.c | 51 ++++++++++++++++++++++++-------
>> drivers/gpu/drm/tegra/output.c | 2 ++
>> 6 files changed, 85 insertions(+), 19 deletions(-)
>
> I'd prefer for this to be split up into patches per panel and per
> display driver. The reason is that if this patch is merged as-is, then
> if it's ever determined to cause a regression it'll be difficult to find
> out which change exactly caused this.
>
> But to not break bisectability you'll need to be careful in how you
> break up the patches. I think the following should work:
>
> - for each panel driver, implement dummy .prepare() and
> .unprepare() that return 0
> - for each display driver, make use of drm_panel_prepare() and
> drm_panel_unprepare()
> - for each panel driver, properly implement .prepare() and
> .unprepare() (presumably by moving code out of .enable() and
> .disable(), respectively)
>
I will try this. With this approach, compilation should not fail.
> I have a couple more comments below about the ordering of the .prepare()
> vs. .enable() and .disable() vs. .unprepare() calls.
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 5e78d45..2f58e45 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1333,6 +1333,12 @@ static int exynos_dsi_enable(struct exynos_dsi *dsi)
>> if (ret < 0)
>> return ret;
>>
>> + ret = drm_panel_prepare(dsi->panel);
>> + if (ret < 0) {
>> + exynos_dsi_poweroff(dsi);
>> + return ret;
>> + }
>> +
>> ret = drm_panel_enable(dsi->panel);
>> if (ret < 0) {
>> exynos_dsi_poweroff(dsi);
>> @@ -1354,6 +1360,7 @@ static void exynos_dsi_disable(struct exynos_dsi *dsi)
>>
>> exynos_dsi_set_display_enable(dsi, false);
>> drm_panel_disable(dsi->panel);
>> + drm_panel_unprepare(dsi->panel);
>> exynos_dsi_poweroff(dsi);
>
> I don't know Exynos very well, so this may be completely wrong, but
> should disable_panel_prepare() be called much earlier than
> drm_panel_enable() and drm_panel_unprepare() much later than
> drm_panel_disable()? With the above the result is still the same, so
> you'll get the same glitches as without their separation.
Actually, I have not worked on DSI panels.
And till now, these DSI panels have been working with just the
enable/disable callback. So, I thought it might not really cause a
glitch/garbage on the screen.
I just placed the new panel calls so that basic working will not be broken.
It would be great if someone can test this on exynos boards with DSI panels :(
Inki/Andrej?
Anyways, now there is a kerneldoc which explains all these calls,
I will rearrange the panel calls.
> Without knowing exactly what Exynos does in the above, I'd expect the
> correct sequence to be something like this:
>
> ret = exynos_dsi_power_on(dsi);
> if (ret < 0)
> return ret;
>
> ret = drm_panel_prepare(dsi->panel);
> if (ret < 0) {
> exynos_dsi_poweroff(dsi);
> return ret;
> }
>
> exynos_dsi_set_display_mode(dsi);
> exynos_dsi_set_display_enable(dsi, true);
>
> ret = drm_panel_enable(dsi->panel);
> if (ret < 0) {
> /* perhaps undo exynos_dsi_set_display_enable() here? */
> exynos_dsi_poweroff(dsi);
> return ret;
> }
>
> And for disable:
>
> drm_panel_disable(dsi->panel);
> exynos_dsi_set_display_enable(dsi, false);
> drm_panel_unprepare(dsi->panel);
> exynos_dsi_poweroff(dsi);
>
> Perhaps I should quote the kerneldoc that I added for drm_panel_funcs to
> underline why I think this is important:
>
> /**
> * struct drm_panel_funcs - perform operations on a given panel
> * @disable: disable panel (turn off back light, etc.)
> * @unprepare: turn off panel
> * @prepare: turn on panel and perform set up
> * @enable: enable panel (turn on back light, etc.)
> * @get_modes: add modes to the connector that the panel is attached to and
> * return the number of modes added
> *
> * The .prepare() function is typically called before the display controller
> * starts to transmit video data. Panel drivers can use this to turn the panel
> * on and wait for it to become ready. If additional configuration is required
> * (via a control bus such as I2C, SPI or DSI for example) this is a good time
> * to do that.
> *
> * After the display controller has started transmitting video data, it's safe
> * to call the .enable() function. This will typically enable the backlight to
> * make the image on screen visible. Some panels require a certain amount of
> * time or frames before the image is displayed. This function is responsible
> * for taking this into account before enabling the backlight to avoid visual
> * glitches.
> *
> * Before stopping video transmission from the display controller it can be
> * necessary to turn off the panel to avoid visual glitches. This is done in
> * the .disable() function. Analogously to .enable() this typically involves
> * turning off the backlight and waiting for some time to make sure no image
> * is visible on the panel. It is then safe for the display controller to
> * cease transmission of video data.
> *
> * To save power when no video data is transmitted, a driver can power down
> * the panel. This is the job of the .unprepare() function.
> */
>
> As you see, .prepare() should do whatever is necessary to make the panel
> accept a stream of video data, then the display driver can start sending
> video data and call .enable() to make the transmitted data visible.
>
> Analogously .disable() should turn off the display, so that the user can
> no longer see what's going on, then the display controller can cease
> transmission of video data (and since the panel is disabled this should
> no longer cause visual glitches) and then call .unprepare() to turn the
> panel off.
>
> I know that this isn't immediately relevant just yet because currently
> the backlight will already turn on by default, but like we discussed
> earlier I have ideas on how to properly fix it. As a matter of fact I'll
> go and send out another mail about that when I'm through this series.
>
>> static const struct drm_panel_funcs ld9040_drm_funcs = {
>> + .unprepare = ld9040_unprepare,
>> .disable = ld9040_disable,
>> + .prepare = ld9040_prepare,
>> .enable = ld9040_enable,
>> .get_modes = ld9040_get_modes,
>> };
>
> The patch I applied for .prepare() and .unprepare() I've reordered the
> functions slightly to give a more natural sequence. .disable() is now
> first, while .unprepare() is next, since that's the sequence that they
> should be called in.
>
> Patches for the panel drivers should follow this same ordering.
Ok. I will follow the same order for all panel drivers.
>> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
>> index a251361..fb0cfe2 100644
>> --- a/drivers/gpu/drm/panel/panel-simple.c
>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>> @@ -45,7 +45,8 @@ struct panel_desc {
>>
>> struct panel_simple {
>> struct drm_panel base;
>> - bool enabled;
>> + bool panel_enabled;
>> + bool backlight_enabled;
>
> Perhaps this should rather be:
>
> bool prepared;
> bool enabled;
>
More generic. Will change it!
Ajay
>
>> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
>> index 446837e..b574ee6 100644
>> --- a/drivers/gpu/drm/tegra/output.c
>> +++ b/drivers/gpu/drm/tegra/output.c
>> @@ -139,9 +139,11 @@ static void tegra_encoder_dpms(struct drm_encoder *encoder, int mode)
>>
>> if (mode != DRM_MODE_DPMS_ON) {
>> drm_panel_disable(panel);
>> + drm_panel_unprepare(panel);
>> tegra_output_disable(output);
>
> Similarly to my comments for the Exynos drivers, this should be:
>
> drm_panel_disable(panel);
> tegra_output_disable(output);
> drm_panel_unprepare(panel);
>
>> } else {
>> tegra_output_enable(output);
>> + drm_panel_prepare(panel);
>> drm_panel_enable(panel);
>> }
>
> and
>
> drm_panel_prepare(panel);
> tegra_output_enable(output);
> drm_panel_enable(panel);
>
> Thierry
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
2014-07-25 19:22 ` [PATCH V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines Ajay Kumar
2014-07-25 19:22 ` [PATCH V6 2/8] drm/panel: Add support for prepare and unprepare routines Ajay Kumar
@ 2014-07-25 19:22 ` Ajay Kumar
2014-07-30 10:51 ` Thierry Reding
2014-07-25 19:22 ` [PATCH V6 4/8] drm/exynos: Move DP setup into commit() Ajay Kumar
` (6 subsequent siblings)
9 siblings, 1 reply; 70+ messages in thread
From: Ajay Kumar @ 2014-07-25 19:22 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g, Ajay Kumar
Add panel_desc structure for auo_b133htn01 eDP panel.
Also, modify the panel_simple routines to support timing_parameter
delays if mentioned in the panel_desc structure.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
.../devicetree/bindings/panel/auo,b133htn01.txt | 7 +++
drivers/gpu/drm/panel/panel-simple.c | 47 ++++++++++++++++++++
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt
diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
new file mode 100644
index 0000000..302226b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
+
+Required properties:
+- compatible: should be "auo,b133htn01"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index fb0cfe2..cbbb1b8 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -41,6 +41,13 @@ struct panel_desc {
unsigned int width;
unsigned int height;
} size;
+
+ struct {
+ unsigned int prepare_stage_delay;
+ unsigned int enable_stage_delay;
+ unsigned int disable_stage_delay;
+ unsigned int unprepare_stage_delay;
+ } timing_parameter;
};
struct panel_simple {
@@ -105,6 +112,8 @@ static int panel_simple_unprepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p->enable_gpio, 0);
regulator_disable(p->supply);
+ if (p->desc)
+ msleep(p->desc->timing_parameter.unprepare_stage_delay);
p->panel_enabled = false;
@@ -123,6 +132,9 @@ static int panel_simple_disable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}
+ if (p->desc)
+ msleep(p->desc->timing_parameter.disable_stage_delay);
+
p->backlight_enabled = false;
return 0;
@@ -142,6 +154,9 @@ static int panel_simple_prepare(struct drm_panel *panel)
return err;
}
+ if (p->desc)
+ msleep(p->desc->timing_parameter.prepare_stage_delay);
+
if (p->enable_gpio)
gpiod_set_value_cansleep(p->enable_gpio, 1);
@@ -157,6 +172,8 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->backlight_enabled)
return 0;
+ if (p->desc)
+ msleep(p->desc->timing_parameter.enable_stage_delay);
if (p->backlight) {
p->backlight->props.power = FB_BLANK_UNBLANK;
backlight_update_status(p->backlight);
@@ -342,6 +359,33 @@ static const struct panel_desc auo_b133xtn01 = {
},
};
+static const struct drm_display_mode auo_b133htn01_mode = {
+ .clock = 150660,
+ .hdisplay = 1920,
+ .hsync_start = 1920 + 172,
+ .hsync_end = 1920 + 172 + 80,
+ .htotal = 1920 + 172 + 80 + 60,
+ .vdisplay = 1080,
+ .vsync_start = 1080 + 25,
+ .vsync_end = 1080 + 25 + 10,
+ .vtotal = 1080 + 25 + 10 + 10,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b133htn01 = {
+ .modes = &auo_b133htn01_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 293,
+ .height = 165,
+ },
+ .timing_parameter = {
+ .prepare_stage_delay = 105,
+ .enable_stage_delay = 20,
+ .prepare_stage_delay = 50,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -481,6 +525,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = &auo_b101aw03,
}, {
+ .compatible = "auo,b133htn01",
+ .data = &auo_b133htn01,
+ }, {
.compatible = "auo,b133xtn01",
.data = &auo_b133xtn01,
}, {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
2014-07-25 19:22 ` [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel Ajay Kumar
@ 2014-07-30 10:51 ` Thierry Reding
2014-07-30 11:32 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 10:51 UTC (permalink / raw)
To: Ajay Kumar
Cc: devicetree, linux-samsung-soc, seanpaul, daniel.vetter, joshi,
dri-devel, ajaynumb, prashanth.g
[-- Attachment #1.1: Type: text/plain, Size: 5490 bytes --]
On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
> Add panel_desc structure for auo_b133htn01 eDP panel.
>
> Also, modify the panel_simple routines to support timing_parameter
> delays if mentioned in the panel_desc structure.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> ---
> .../devicetree/bindings/panel/auo,b133htn01.txt | 7 +++
> drivers/gpu/drm/panel/panel-simple.c | 47 ++++++++++++++++++++
> 2 files changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt
I think this should be two patches, one which adds the delay parameters
and another which adds support for the new panel.
> diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
> new file mode 100644
> index 0000000..302226b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
> @@ -0,0 +1,7 @@
> +AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
> +
> +Required properties:
> +- compatible: should be "auo,b133htn01"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index fb0cfe2..cbbb1b8 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -41,6 +41,13 @@ struct panel_desc {
> unsigned int width;
> unsigned int height;
> } size;
> +
> + struct {
> + unsigned int prepare_stage_delay;
> + unsigned int enable_stage_delay;
> + unsigned int disable_stage_delay;
> + unsigned int unprepare_stage_delay;
> + } timing_parameter;
These are overly long in my opinion, how about:
struct {
unsigned int prepare;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;
? Oh, and this should probably mention that it's in milliseconds. On
that note, do you think we'll ever need microsecond resolution? I don't
think I've ever seen a panel datasheet mentioning that kind of
granularity.
> struct panel_simple {
> @@ -105,6 +112,8 @@ static int panel_simple_unprepare(struct drm_panel *panel)
> gpiod_set_value_cansleep(p->enable_gpio, 0);
>
> regulator_disable(p->supply);
> + if (p->desc)
Should have a blank line between "regulator_disable(...)" and "if ...".
Also it's not useful to check for p->desc, really, since it's a bug if
that is NULL.
However I think it would be good to check for the delay being set, like
so:
if (p->desc->delay.unprepare)
msleep(p->desc->delay.unprepare);
I'm not sure about the placement of the delay here, see below for more.
> @@ -142,6 +154,9 @@ static int panel_simple_prepare(struct drm_panel *panel)
> return err;
> }
>
> + if (p->desc)
> + msleep(p->desc->timing_parameter.prepare_stage_delay);
> +
> if (p->enable_gpio)
> gpiod_set_value_cansleep(p->enable_gpio, 1);
Should the delay not be *after* all steps in prepare have been
performed? That way drivers can use it to specify the time that a panel
needs to "internally" become ready after they've been power up (for
example).
>
> @@ -157,6 +172,8 @@ static int panel_simple_enable(struct drm_panel *panel)
> if (p->backlight_enabled)
> return 0;
>
> + if (p->desc)
> + msleep(p->desc->timing_parameter.enable_stage_delay);
> if (p->backlight) {
> p->backlight->props.power = FB_BLANK_UNBLANK;
> backlight_update_status(p->backlight);
I think here the delay makes sense where it is because it allows the
panel driver to wait for a given amount of time (after video data has
been sent by the display controller) until the first "good" frame is
visible.
In general I think it would be good to have a description of these in
the struct panel_desc structure, something like this perhaps:
/**
* @prepare: the time (in milliseconds) that it takes for the panel
* to become ready and start receiving video data
* @enable: the time (in milliseconds) that it takes for the panel
* to display the first valid frame after starting to
* receive video data
* @disable: the time (in milliseconds) that it takes for the panel
* to turn the display off (no content is visible)
* @unprepare: ???
*/
struct {
unsigned int prepare;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;
For prepare and enable delays this would mean that they should take
effect at the very end of the .prepare() and .enable() functions,
respectively. For disable in means that it should be at the end (for
example to take into account the time it takes for backlight to
completely turn off). For unprepare I have no idea what we would need it
for. And the new panel that you're adding in this patch doesn't use it
either, so perhaps it can just be left out (for now)?
> +static const struct panel_desc auo_b133htn01 = {
> + .modes = &auo_b133htn01_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 293,
> + .height = 165,
> + },
> + .timing_parameter = {
> + .prepare_stage_delay = 105,
> + .enable_stage_delay = 20,
> + .prepare_stage_delay = 50,
I take it that this last one was supposed to be .enable_stage_delay
since you've already set up .prepare_stage_delay.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
2014-07-30 10:51 ` Thierry Reding
@ 2014-07-30 11:32 ` Ajay kumar
2014-07-30 13:30 ` Thierry Reding
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 11:32 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
On Wed, Jul 30, 2014 at 4:21 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
>> Add panel_desc structure for auo_b133htn01 eDP panel.
>>
>> Also, modify the panel_simple routines to support timing_parameter
>> delays if mentioned in the panel_desc structure.
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> ---
>> .../devicetree/bindings/panel/auo,b133htn01.txt | 7 +++
>> drivers/gpu/drm/panel/panel-simple.c | 47 ++++++++++++++++++++
>> 2 files changed, 54 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt
>
> I think this should be two patches, one which adds the delay parameters
> and another which adds support for the new panel.
Ok. Will split it.
>> diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
>> new file mode 100644
>> index 0000000..302226b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
>> @@ -0,0 +1,7 @@
>> +AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
>> +
>> +Required properties:
>> +- compatible: should be "auo,b133htn01"
>> +
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.
>> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
>> index fb0cfe2..cbbb1b8 100644
>> --- a/drivers/gpu/drm/panel/panel-simple.c
>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>> @@ -41,6 +41,13 @@ struct panel_desc {
>> unsigned int width;
>> unsigned int height;
>> } size;
>> +
>> + struct {
>> + unsigned int prepare_stage_delay;
>> + unsigned int enable_stage_delay;
>> + unsigned int disable_stage_delay;
>> + unsigned int unprepare_stage_delay;
>> + } timing_parameter;
>
> These are overly long in my opinion, how about:
>
> struct {
> unsigned int prepare;
> unsigned int enable;
> unsigned int disable;
> unsigned int unprepare;
> } delay;
Ok, will use this.
> ? Oh, and this should probably mention that it's in milliseconds. On
> that note, do you think we'll ever need microsecond resolution? I don't
> think I've ever seen a panel datasheet mentioning that kind of
> granularity.
Nope. All in milliseconds.
>> struct panel_simple {
>> @@ -105,6 +112,8 @@ static int panel_simple_unprepare(struct drm_panel *panel)
>> gpiod_set_value_cansleep(p->enable_gpio, 0);
>>
>> regulator_disable(p->supply);
>> + if (p->desc)
>
> Should have a blank line between "regulator_disable(...)" and "if ...".
> Also it's not useful to check for p->desc, really, since it's a bug if
> that is NULL.
Well, I added this check because I used just the "simple-panel" compatible
for panel node on snow. This check won't be needed anymore.
> However I think it would be good to check for the delay being set, like
> so:
>
> if (p->desc->delay.unprepare)
> msleep(p->desc->delay.unprepare);
Ok, will change it.
> I'm not sure about the placement of the delay here, see below for more.
>
>> @@ -142,6 +154,9 @@ static int panel_simple_prepare(struct drm_panel *panel)
>> return err;
>> }
>>
>> + if (p->desc)
>> + msleep(p->desc->timing_parameter.prepare_stage_delay);
>> +
>> if (p->enable_gpio)
>> gpiod_set_value_cansleep(p->enable_gpio, 1);
>
> Should the delay not be *after* all steps in prepare have been
> performed? That way drivers can use it to specify the time that a panel
> needs to "internally" become ready after they've been power up (for
> example).
Right. I will move that delay down.
>>
>> @@ -157,6 +172,8 @@ static int panel_simple_enable(struct drm_panel *panel)
>> if (p->backlight_enabled)
>> return 0;
>>
>> + if (p->desc)
>> + msleep(p->desc->timing_parameter.enable_stage_delay);
>> if (p->backlight) {
>> p->backlight->props.power = FB_BLANK_UNBLANK;
>> backlight_update_status(p->backlight);
>
> I think here the delay makes sense where it is because it allows the
> panel driver to wait for a given amount of time (after video data has
> been sent by the display controller) until the first "good" frame is
> visible.
Exactly!
> In general I think it would be good to have a description of these in
> the struct panel_desc structure, something like this perhaps:
>
> /**
> * @prepare: the time (in milliseconds) that it takes for the panel
> * to become ready and start receiving video data
> * @enable: the time (in milliseconds) that it takes for the panel
> * to display the first valid frame after starting to
> * receive video data
> * @disable: the time (in milliseconds) that it takes for the panel
> * to turn the display off (no content is visible)
> * @unprepare: the time (in milliseconds) that it takes for the panel
to power down itself completely.
> */
> struct {
> unsigned int prepare;
> unsigned int enable;
> unsigned int disable;
> unsigned int unprepare;
> } delay;
>
> For prepare and enable delays this would mean that they should take
> effect at the very end of the .prepare() and .enable() functions,
> respectively. For disable in means that it should be at the end (for
> example to take into account the time it takes for backlight to
> completely turn off). For unprepare I have no idea what we would need it
> for. And the new panel that you're adding in this patch doesn't use it
> either, so perhaps it can just be left out (for now)?
Actually, there was a typo.
That should have been .unprepare_stage_delay = 50.
This is needed because panels need some delay before powering
them on again.
As in, assume you are doing a test to turn on/off display continuously,
Then, the delay between
(N - 1)th cycle poweroff to Nth cycle poweron should be at least 500ms.
That's what the datasheet says! And, somehow 50ms works fine for me.
Ajay
>> +static const struct panel_desc auo_b133htn01 = {
>> + .modes = &auo_b133htn01_mode,
>> + .num_modes = 1,
>> + .size = {
>> + .width = 293,
>> + .height = 165,
>> + },
>> + .timing_parameter = {
>> + .prepare_stage_delay = 105,
>> + .enable_stage_delay = 20,
>> + .prepare_stage_delay = 50,
>
> I take it that this last one was supposed to be .enable_stage_delay
> since you've already set up .prepare_stage_delay.
>
> Thierry
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
2014-07-30 11:32 ` Ajay kumar
@ 2014-07-30 13:30 ` Thierry Reding
2014-07-30 13:42 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 13:30 UTC (permalink / raw)
To: Ajay kumar
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
[-- Attachment #1.1: Type: text/plain, Size: 3083 bytes --]
On Wed, Jul 30, 2014 at 05:02:11PM +0530, Ajay kumar wrote:
> On Wed, Jul 30, 2014 at 4:21 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
> >> Add panel_desc structure for auo_b133htn01 eDP panel.
> >>
> >> Also, modify the panel_simple routines to support timing_parameter
> >> delays if mentioned in the panel_desc structure.
> >>
> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> >> ---
> >> .../devicetree/bindings/panel/auo,b133htn01.txt | 7 +++
> >> drivers/gpu/drm/panel/panel-simple.c | 47 ++++++++++++++++++++
> >> 2 files changed, 54 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt
> >
> > I think this should be two patches, one which adds the delay parameters
> > and another which adds support for the new panel.
> Ok. Will split it.
I was going to propose that I split this up myself so you no longer have
to worry about it. I can easily apply the changes we discussed. But if
you prefer to keep it in one series that works for me too.
> > In general I think it would be good to have a description of these in
> > the struct panel_desc structure, something like this perhaps:
> >
> > /**
> > * @prepare: the time (in milliseconds) that it takes for the panel
> > * to become ready and start receiving video data
> > * @enable: the time (in milliseconds) that it takes for the panel
> > * to display the first valid frame after starting to
> > * receive video data
> > * @disable: the time (in milliseconds) that it takes for the panel
> > * to turn the display off (no content is visible)
> > * @unprepare: the time (in milliseconds) that it takes for the panel
> to power down itself completely.
> > */
> > struct {
> > unsigned int prepare;
> > unsigned int enable;
> > unsigned int disable;
> > unsigned int unprepare;
> > } delay;
> >
> > For prepare and enable delays this would mean that they should take
> > effect at the very end of the .prepare() and .enable() functions,
> > respectively. For disable in means that it should be at the end (for
> > example to take into account the time it takes for backlight to
> > completely turn off). For unprepare I have no idea what we would need it
> > for. And the new panel that you're adding in this patch doesn't use it
> > either, so perhaps it can just be left out (for now)?
> Actually, there was a typo.
> That should have been .unprepare_stage_delay = 50.
> This is needed because panels need some delay before powering
> them on again.
> As in, assume you are doing a test to turn on/off display continuously,
> Then, the delay between
> (N - 1)th cycle poweroff to Nth cycle poweron should be at least 500ms.
> That's what the datasheet says! And, somehow 50ms works fine for me.
Okay, that makes sense then.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
2014-07-30 13:30 ` Thierry Reding
@ 2014-07-30 13:42 ` Ajay kumar
0 siblings, 0 replies; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 13:42 UTC (permalink / raw)
To: Thierry Reding
Cc: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree, InKi Dae,
Rob Clark, Daniel Vetter, Sean Paul, Jingoo Han, sunil joshi,
Prashanth G
On Wed, Jul 30, 2014 at 7:00 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Wed, Jul 30, 2014 at 05:02:11PM +0530, Ajay kumar wrote:
>> On Wed, Jul 30, 2014 at 4:21 PM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
>> >> Add panel_desc structure for auo_b133htn01 eDP panel.
>> >>
>> >> Also, modify the panel_simple routines to support timing_parameter
>> >> delays if mentioned in the panel_desc structure.
>> >>
>> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> >> ---
>> >> .../devicetree/bindings/panel/auo,b133htn01.txt | 7 +++
>> >> drivers/gpu/drm/panel/panel-simple.c | 47 ++++++++++++++++++++
>> >> 2 files changed, 54 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt
>> >
>> > I think this should be two patches, one which adds the delay parameters
>> > and another which adds support for the new panel.
>> Ok. Will split it.
>
> I was going to propose that I split this up myself so you no longer have
> to worry about it. I can easily apply the changes we discussed. But if
> you prefer to keep it in one series that works for me too.
Well, you can only take in the "delay" structure as of now.
Ajay
>> > In general I think it would be good to have a description of these in
>> > the struct panel_desc structure, something like this perhaps:
>> >
>> > /**
>> > * @prepare: the time (in milliseconds) that it takes for the panel
>> > * to become ready and start receiving video data
>> > * @enable: the time (in milliseconds) that it takes for the panel
>> > * to display the first valid frame after starting to
>> > * receive video data
>> > * @disable: the time (in milliseconds) that it takes for the panel
>> > * to turn the display off (no content is visible)
>> > * @unprepare: the time (in milliseconds) that it takes for the panel
>> to power down itself completely.
>> > */
>> > struct {
>> > unsigned int prepare;
>> > unsigned int enable;
>> > unsigned int disable;
>> > unsigned int unprepare;
>> > } delay;
>> >
>> > For prepare and enable delays this would mean that they should take
>> > effect at the very end of the .prepare() and .enable() functions,
>> > respectively. For disable in means that it should be at the end (for
>> > example to take into account the time it takes for backlight to
>> > completely turn off). For unprepare I have no idea what we would need it
>> > for. And the new panel that you're adding in this patch doesn't use it
>> > either, so perhaps it can just be left out (for now)?
>> Actually, there was a typo.
>> That should have been .unprepare_stage_delay = 50.
>> This is needed because panels need some delay before powering
>> them on again.
>> As in, assume you are doing a test to turn on/off display continuously,
>> Then, the delay between
>> (N - 1)th cycle poweroff to Nth cycle poweron should be at least 500ms.
>> That's what the datasheet says! And, somehow 50ms works fine for me.
>
> Okay, that makes sense then.
>
> Thierry
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH V6 4/8] drm/exynos: Move DP setup into commit()
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
` (2 preceding siblings ...)
2014-07-25 19:22 ` [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel Ajay Kumar
@ 2014-07-25 19:22 ` Ajay Kumar
2014-07-30 10:52 ` Thierry Reding
2014-07-25 19:22 ` [PATCH V6 5/8] drm/exynos: dp: Modify driver to support drm_panel Ajay Kumar
` (5 subsequent siblings)
9 siblings, 1 reply; 70+ messages in thread
From: Ajay Kumar @ 2014-07-25 19:22 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g, Ajay Kumar, Sean Paul
This patch moves the DP training and video enable from the hotplug
handler into commit().
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 845d766..4b6ad95 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -875,10 +875,18 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void *arg)
static void exynos_dp_hotplug(struct work_struct *work)
{
struct exynos_dp_device *dp;
- int ret;
dp = container_of(work, struct exynos_dp_device, hotplug_work);
+ if (dp->drm_dev)
+ drm_helper_hpd_irq_event(dp->drm_dev);
+}
+
+static void exynos_dp_commit(struct exynos_drm_display *display)
+{
+ struct exynos_dp_device *dp = display->ctx;
+ int ret;
+
ret = exynos_dp_detect_hpd(dp);
if (ret) {
/* Cable has been disconnected, we're done */
@@ -1050,8 +1058,10 @@ static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
}
}
-static void exynos_dp_poweron(struct exynos_dp_device *dp)
+static void exynos_dp_poweron(struct exynos_drm_display *display)
{
+ struct exynos_dp_device *dp = display->ctx;
+
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
return;
@@ -1059,10 +1069,13 @@ static void exynos_dp_poweron(struct exynos_dp_device *dp)
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
+ exynos_dp_commit(display);
}
-static void exynos_dp_poweroff(struct exynos_dp_device *dp)
+static void exynos_dp_poweroff(struct exynos_drm_display *display)
{
+ struct exynos_dp_device *dp = display->ctx;
+
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;
@@ -1078,12 +1091,12 @@ static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
switch (mode) {
case DRM_MODE_DPMS_ON:
- exynos_dp_poweron(dp);
+ exynos_dp_poweron(display);
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
- exynos_dp_poweroff(dp);
+ exynos_dp_poweroff(display);
break;
default:
break;
@@ -1094,6 +1107,7 @@ static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
static struct exynos_drm_display_ops exynos_dp_display_ops = {
.create_connector = exynos_dp_create_connector,
.dpms = exynos_dp_dpms,
+ .commit = exynos_dp_commit,
};
static struct exynos_drm_display exynos_dp_display = {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V6 4/8] drm/exynos: Move DP setup into commit()
2014-07-25 19:22 ` [PATCH V6 4/8] drm/exynos: Move DP setup into commit() Ajay Kumar
@ 2014-07-30 10:52 ` Thierry Reding
2014-07-30 12:05 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 10:52 UTC (permalink / raw)
To: Ajay Kumar
Cc: devicetree, linux-samsung-soc, seanpaul, daniel.vetter, joshi,
dri-devel, ajaynumb, prashanth.g
[-- Attachment #1.1: Type: text/plain, Size: 319 bytes --]
On Sat, Jul 26, 2014 at 12:52:06AM +0530, Ajay Kumar wrote:
> This patch moves the DP training and video enable from the hotplug
> handler into commit().
I don't think I can comment on this one, but perhaps the commit message
should describe why it's doing this rather than just parroting what the
code does.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 4/8] drm/exynos: Move DP setup into commit()
2014-07-30 10:52 ` Thierry Reding
@ 2014-07-30 12:05 ` Ajay kumar
0 siblings, 0 replies; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 12:05 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
On Wed, Jul 30, 2014 at 4:22 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sat, Jul 26, 2014 at 12:52:06AM +0530, Ajay Kumar wrote:
>> This patch moves the DP training and video enable from the hotplug
>> handler into commit().
>
> I don't think I can comment on this one, but perhaps the commit message
> should describe why it's doing this rather than just parroting what the
> code does.
Actually, this patch adds the missing commit callback for dp encoder.
I will add proper commit message.
Ajay
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH V6 5/8] drm/exynos: dp: Modify driver to support drm_panel
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
` (3 preceding siblings ...)
2014-07-25 19:22 ` [PATCH V6 4/8] drm/exynos: Move DP setup into commit() Ajay Kumar
@ 2014-07-25 19:22 ` Ajay Kumar
2014-07-30 10:58 ` Thierry Reding
2014-07-25 19:22 ` [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model Ajay Kumar
` (4 subsequent siblings)
9 siblings, 1 reply; 70+ messages in thread
From: Ajay Kumar @ 2014-07-25 19:22 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g, Ajay Kumar
Add drm_panel controls to support powerup/down of the
eDP panel, if one is present at the sink side.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_dp_core.c | 88 ++++++++++++++++++++++++-------
drivers/gpu/drm/exynos/exynos_dp_core.h | 3 +-
3 files changed, 71 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 9ba1aae..7f9f6f9 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -53,6 +53,7 @@ config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
default DRM_EXYNOS
+ select DRM_PANEL
help
This enables support for DP device.
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 4b6ad95..49356cc 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -16,7 +16,6 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/interrupt.h>
-#include <linux/delay.h>
#include <linux/of.h>
#include <linux/of_gpio.h>
#include <linux/gpio.h>
@@ -28,6 +27,7 @@
#include <drm/drmP.h>
#include <drm/drm_crtc.h>
#include <drm/drm_crtc_helper.h>
+#include <drm/drm_panel.h>
#include <drm/bridge/ptn3460.h>
#include "exynos_drm_drv.h"
@@ -41,7 +41,7 @@ struct bridge_init {
struct device_node *node;
};
-static int exynos_dp_init_dp(struct exynos_dp_device *dp)
+static void exynos_dp_init_dp(struct exynos_dp_device *dp)
{
exynos_dp_reset(dp);
@@ -58,8 +58,6 @@ static int exynos_dp_init_dp(struct exynos_dp_device *dp)
exynos_dp_init_hpd(dp);
exynos_dp_init_aux(dp);
-
- return 0;
}
static int exynos_dp_detect_hpd(struct exynos_dp_device *dp)
@@ -887,6 +885,12 @@ static void exynos_dp_commit(struct exynos_drm_display *display)
struct exynos_dp_device *dp = display->ctx;
int ret;
+ /* Keep backlight disabled while we configure video */
+ if (dp->panel) {
+ if (drm_panel_disable(dp->panel))
+ DRM_ERROR("failed to disable panel backlight\n");
+ }
+
ret = exynos_dp_detect_hpd(dp);
if (ret) {
/* Cable has been disconnected, we're done */
@@ -917,6 +921,12 @@ static void exynos_dp_commit(struct exynos_drm_display *display)
ret = exynos_dp_config_video(dp);
if (ret)
dev_err(dp->dev, "unable to config video\n");
+
+ /* Safe to turn on backlight now */
+ if (dp->panel) {
+ if (drm_panel_enable(dp->panel))
+ DRM_ERROR("failed to enable panel backlight\n");
+ }
}
static enum drm_connector_status exynos_dp_detect(
@@ -941,15 +951,18 @@ static int exynos_dp_get_modes(struct drm_connector *connector)
struct exynos_dp_device *dp = ctx_from_connector(connector);
struct drm_display_mode *mode;
+ if (dp->panel)
+ return drm_panel_get_modes(dp->panel);
+
mode = drm_mode_create(connector->dev);
if (!mode) {
DRM_ERROR("failed to create a new display mode.\n");
return 0;
}
- drm_display_mode_from_videomode(&dp->panel.vm, mode);
- mode->width_mm = dp->panel.width_mm;
- mode->height_mm = dp->panel.height_mm;
+ drm_display_mode_from_videomode(&dp->priv.vm, mode);
+ mode->width_mm = dp->priv.width_mm;
+ mode->height_mm = dp->priv.height_mm;
connector->display_info.width_mm = mode->width_mm;
connector->display_info.height_mm = mode->height_mm;
@@ -1029,7 +1042,10 @@ static int exynos_dp_create_connector(struct exynos_drm_display *display,
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
- return 0;
+ if (dp->panel)
+ ret = drm_panel_attach(dp->panel, &dp->connector);
+
+ return ret;
}
static void exynos_dp_phy_init(struct exynos_dp_device *dp)
@@ -1065,6 +1081,13 @@ static void exynos_dp_poweron(struct exynos_drm_display *display)
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
return;
+ if (dp->panel) {
+ if (drm_panel_prepare(dp->panel)) {
+ DRM_ERROR("failed to powerup the panel\n");
+ return;
+ }
+ }
+
clk_prepare_enable(dp->clock);
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
@@ -1079,10 +1102,22 @@ static void exynos_dp_poweroff(struct exynos_drm_display *display)
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;
+ if (dp->panel) {
+ if (drm_panel_disable(dp->panel)) {
+ DRM_ERROR("failed to disable panel backlight\n");
+ return;
+ }
+ }
+
disable_irq(dp->irq);
flush_work(&dp->hotplug_work);
exynos_dp_phy_exit(dp);
clk_disable_unprepare(dp->clock);
+
+ if (dp->panel) {
+ if (drm_panel_unprepare(dp->panel))
+ DRM_ERROR("failed to powerdown the panel\n");
+ }
}
static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
@@ -1215,7 +1250,7 @@ static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
{
int ret;
- ret = of_get_videomode(dp->dev->of_node, &dp->panel.vm,
+ ret = of_get_videomode(dp->dev->of_node, &dp->priv.vm,
OF_USE_NATIVE_MODE);
if (ret) {
DRM_ERROR("failed: of_get_videomode() : %d\n", ret);
@@ -1229,16 +1264,10 @@ 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;
+ struct exynos_dp_device *dp = exynos_dp_display.ctx;
unsigned int irq_flags;
-
int ret = 0;
- dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
- GFP_KERNEL);
- if (!dp)
- return -ENOMEM;
-
dp->dev = &pdev->dev;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1250,9 +1279,11 @@ static int exynos_dp_bind(struct device *dev, struct device *master, void *data)
if (ret)
return ret;
- ret = exynos_dp_dt_parse_panel(dp);
- if (ret)
- return ret;
+ if (!dp->panel) {
+ ret = exynos_dp_dt_parse_panel(dp);
+ if (ret)
+ return ret;
+ }
dp->clock = devm_clk_get(&pdev->dev, "dp");
if (IS_ERR(dp->clock)) {
@@ -1312,7 +1343,6 @@ static int exynos_dp_bind(struct device *dev, struct device *master, void *data)
disable_irq(dp->irq);
dp->drm_dev = drm_dev;
- exynos_dp_display.ctx = dp;
platform_set_drvdata(pdev, &exynos_dp_display);
@@ -1339,6 +1369,9 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+ struct device_node *panel_node;
+ struct exynos_dp_device *dp;
int ret;
ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
@@ -1346,6 +1379,21 @@ static int exynos_dp_probe(struct platform_device *pdev)
if (ret)
return ret;
+ dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
+ GFP_KERNEL);
+ if (!dp)
+ return -ENOMEM;
+
+ panel_node = of_parse_phandle(dev->of_node, "panel", 0);
+ if (panel_node) {
+ dp->panel = of_drm_find_panel(panel_node);
+ of_node_put(panel_node);
+ if (!dp->panel)
+ return -EPROBE_DEFER;
+ }
+
+ exynos_dp_display.ctx = dp;
+
ret = component_add(&pdev->dev, &exynos_dp_ops);
if (ret)
exynos_drm_component_del(&pdev->dev,
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h b/drivers/gpu/drm/exynos/exynos_dp_core.h
index 02cc4f9..a1aee69 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -149,6 +149,7 @@ struct exynos_dp_device {
struct drm_device *drm_dev;
struct drm_connector connector;
struct drm_encoder *encoder;
+ struct drm_panel *panel;
struct clk *clock;
unsigned int irq;
void __iomem *reg_base;
@@ -162,7 +163,7 @@ struct exynos_dp_device {
int dpms_mode;
int hpd_gpio;
- struct exynos_drm_panel_info panel;
+ struct exynos_drm_panel_info priv;
};
/* exynos_dp_reg.c */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V6 5/8] drm/exynos: dp: Modify driver to support drm_panel
2014-07-25 19:22 ` [PATCH V6 5/8] drm/exynos: dp: Modify driver to support drm_panel Ajay Kumar
@ 2014-07-30 10:58 ` Thierry Reding
0 siblings, 0 replies; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 10:58 UTC (permalink / raw)
To: Ajay Kumar
Cc: dri-devel, linux-samsung-soc, devicetree, inki.dae, robdclark,
daniel.vetter, seanpaul, ajaynumb, jg1.han, joshi, prashanth.g
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
On Sat, Jul 26, 2014 at 12:52:07AM +0530, Ajay Kumar wrote:
[...]
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
[...]
> @@ -887,6 +885,12 @@ static void exynos_dp_commit(struct exynos_drm_display *display)
> struct exynos_dp_device *dp = display->ctx;
> int ret;
>
> + /* Keep backlight disabled while we configure video */
> + if (dp->panel) {
> + if (drm_panel_disable(dp->panel))
> + DRM_ERROR("failed to disable panel backlight\n");
> + }
drm_panel_disable() already gracefully handles the dp->panel == NULL
case, so no need to check for it explicitly. But perhaps you do that
only because panel support is optional and you want to avoid the
error message if it isn't set up. In that case it's probably fine to
leave this as-is.
But you should change the comment and error message, since you don't
know what exactly drm_panel_disable() does.
And it might be useful to print the error code while at it, it might
help save some debugging time in the future.
The same comments apply to most of the remainder of the file, but it
looks good to me otherwise.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
` (4 preceding siblings ...)
2014-07-25 19:22 ` [PATCH V6 5/8] drm/exynos: dp: Modify driver to support drm_panel Ajay Kumar
@ 2014-07-25 19:22 ` Ajay Kumar
2014-07-30 11:19 ` Thierry Reding
2014-09-15 17:37 ` Laurent Pinchart
2014-07-25 19:22 ` [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge Ajay Kumar
` (3 subsequent siblings)
9 siblings, 2 replies; 70+ messages in thread
From: Ajay Kumar @ 2014-07-25 19:22 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g, Ajay Kumar
This patch tries to seperate drm_bridge implementation
into 2 parts, a drm part and a non_drm part.
A set of helper functions are defined in this patch to make
bridge driver probe independent of the drm flow.
The bridge devices register themselves on a lookup table
when they get probed by calling "drm_bridge_add_for_lookup".
The parent encoder driver waits till the bridge is available in the
lookup table(by calling "of_drm_find_bridge") and then continues with
its initialization.
The encoder driver should call "drm_bridge_attach_encoder" to pass on
the drm_device and the encoder pointers to the bridge object.
Now that the drm_device pointer is available, the encoder then calls
"bridge->funcs->post_encoder_init" to allow the bridge to continue
registering itself with the drm core.
Also, non driver model based ptn3460 driver is removed in this patch.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 --
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 12 +-
drivers/gpu/drm/bridge/Makefile | 2 -
drivers/gpu/drm/bridge/ptn3460.c | 343 --------------------
drivers/gpu/drm/drm_bridge.c | 89 +++++
drivers/gpu/drm/drm_crtc.c | 9 +-
drivers/gpu/drm/exynos/Kconfig | 3 +-
drivers/gpu/drm/exynos/exynos_dp_core.c | 57 ++--
drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 3 +-
include/drm/bridge/ptn3460.h | 37 ---
include/drm/drm_crtc.h | 16 +-
13 files changed, 147 insertions(+), 453 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
delete mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 drivers/gpu/drm/drm_bridge.c
delete 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
deleted file mode 100644
index 52b93b2..0000000
--- a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-ptn3460 bridge bindings
-
-Required properties:
- - compatible: "nxp,ptn3460"
- - reg: i2c address of the bridge
- - powerdown-gpio: OF device-tree gpio specification
- - reset-gpio: OF device-tree gpio specification
- - edid-emulation: The EDID emulation entry to use
- +-------+------------+------------------+
- | Value | Resolution | Description |
- | 0 | 1024x768 | NXP Generic |
- | 1 | 1920x1080 | NXP Generic |
- | 2 | 1920x1080 | NXP Generic |
- | 3 | 1600x900 | Samsung LTM200KT |
- | 4 | 1920x1080 | Samsung LTM230HT |
- | 5 | 1366x768 | NXP Generic |
- | 6 | 1600x900 | ChiMei M215HGE |
- +-------+------------+------------------+
-
-Example:
- lvds-bridge@20 {
- compatible = "nxp,ptn3460";
- reg = <0x20>;
- powerdown-gpio = <&gpy2 5 1 0 0>;
- reset-gpio = <&gpx1 5 1 0 0>;
- edid-emulation = <5>;
- };
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index af9a609..14a8b45 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -20,6 +20,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
drm-$(CONFIG_PCI) += ati_pcigart.o
drm-$(CONFIG_DRM_PANEL) += drm_panel.o
+drm-$(CONFIG_DRM_BRIDGE) += drm_bridge.o
drm-usb-y := drm_usb.o
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..1e2f96c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -1,5 +1,9 @@
-config DRM_PTN3460
- tristate "PTN3460 DP/LVDS bridge"
+config DRM_BRIDGE
+ tristate
depends on DRM
- select DRM_KMS_HELPER
- ---help---
+ help
+ Bridge registration and lookup framework.
+
+menu "bridge chips"
+ depends on DRM_BRIDGE
+endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..be16eca 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1 @@
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
deleted file mode 100644
index d466696..0000000
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ /dev/null
@@ -1,343 +0,0 @@
-/*
- * 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_ADDR 0x84
-#define PTN3460_EDID_ENABLE_EMULATION 0
-#define PTN3460_EDID_EMULATION_SELECTION 1
-#define PTN3460_EDID_SRAM_LOAD_ADDR 0x85
-
-struct ptn3460_bridge {
- struct drm_connector connector;
- struct i2c_client *client;
- struct drm_encoder *encoder;
- struct drm_bridge *bridge;
- struct edid *edid;
- int gpio_pd_n;
- int gpio_rst_n;
- u32 edid_emulation;
- bool enabled;
-};
-
-static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
- u8 *buf, int len)
-{
- int ret;
-
- ret = i2c_master_send(ptn_bridge->client, &addr, 1);
- if (ret <= 0) {
- DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
- return ret;
- }
-
- ret = i2c_master_recv(ptn_bridge->client, buf, len);
- if (ret <= 0) {
- DRM_ERROR("Failed to recv i2c data, ret=%d\n", ret);
- return ret;
- }
-
- return 0;
-}
-
-static int ptn3460_write_byte(struct ptn3460_bridge *ptn_bridge, char addr,
- char val)
-{
- int ret;
- char buf[2];
-
- buf[0] = addr;
- buf[1] = val;
-
- ret = i2c_master_send(ptn_bridge->client, buf, ARRAY_SIZE(buf));
- if (ret <= 0) {
- DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
- return ret;
- }
-
- return 0;
-}
-
-static int ptn3460_select_edid(struct ptn3460_bridge *ptn_bridge)
-{
- int ret;
- char val;
-
- /* Load the selected edid into SRAM (accessed at PTN3460_EDID_ADDR) */
- ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_SRAM_LOAD_ADDR,
- ptn_bridge->edid_emulation);
- if (ret) {
- DRM_ERROR("Failed to transfer edid to sram, ret=%d\n", ret);
- return ret;
- }
-
- /* Enable EDID emulation and select the desired EDID */
- val = 1 << PTN3460_EDID_ENABLE_EMULATION |
- ptn_bridge->edid_emulation << PTN3460_EDID_EMULATION_SELECTION;
-
- ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_EMULATION_ADDR, val);
- if (ret) {
- DRM_ERROR("Failed to write edid value, ret=%d\n", ret);
- return ret;
- }
-
- return 0;
-}
-
-static void ptn3460_pre_enable(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
- int ret;
-
- if (ptn_bridge->enabled)
- return;
-
- if (gpio_is_valid(ptn_bridge->gpio_pd_n))
- gpio_set_value(ptn_bridge->gpio_pd_n, 1);
-
- if (gpio_is_valid(ptn_bridge->gpio_rst_n)) {
- gpio_set_value(ptn_bridge->gpio_rst_n, 0);
- udelay(10);
- gpio_set_value(ptn_bridge->gpio_rst_n, 1);
- }
-
- /*
- * There's a bug in the PTN chip where it falsely asserts hotplug before
- * it is fully functional. We're forced to wait for the maximum start up
- * time specified in the chip's datasheet to make sure we're really up.
- */
- msleep(90);
-
- ret = ptn3460_select_edid(ptn_bridge);
- if (ret)
- DRM_ERROR("Select edid failed ret=%d\n", ret);
-
- ptn_bridge->enabled = true;
-}
-
-static void ptn3460_enable(struct drm_bridge *bridge)
-{
-}
-
-static void ptn3460_disable(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
-
- if (!ptn_bridge->enabled)
- return;
-
- ptn_bridge->enabled = false;
-
- if (gpio_is_valid(ptn_bridge->gpio_rst_n))
- gpio_set_value(ptn_bridge->gpio_rst_n, 1);
-
- if (gpio_is_valid(ptn_bridge->gpio_pd_n))
- gpio_set_value(ptn_bridge->gpio_pd_n, 0);
-}
-
-static void ptn3460_post_disable(struct drm_bridge *bridge)
-{
-}
-
-void ptn3460_bridge_destroy(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
-
- drm_bridge_cleanup(bridge);
- if (gpio_is_valid(ptn_bridge->gpio_pd_n))
- gpio_free(ptn_bridge->gpio_pd_n);
- if (gpio_is_valid(ptn_bridge->gpio_rst_n))
- gpio_free(ptn_bridge->gpio_rst_n);
- /* Nothing else to free, we've got devm allocated memory */
-}
-
-struct drm_bridge_funcs ptn3460_bridge_funcs = {
- .pre_enable = ptn3460_pre_enable,
- .enable = ptn3460_enable,
- .disable = ptn3460_disable,
- .post_disable = ptn3460_post_disable,
- .destroy = ptn3460_bridge_destroy,
-};
-
-int ptn3460_get_modes(struct drm_connector *connector)
-{
- struct ptn3460_bridge *ptn_bridge;
- u8 *edid;
- int ret, num_modes;
- bool power_off;
-
- ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
-
- if (ptn_bridge->edid)
- return drm_add_edid_modes(connector, ptn_bridge->edid);
-
- power_off = !ptn_bridge->enabled;
- ptn3460_pre_enable(ptn_bridge->bridge);
-
- edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
- if (!edid) {
- DRM_ERROR("Failed to allocate edid\n");
- return 0;
- }
-
- ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
- EDID_LENGTH);
- if (ret) {
- kfree(edid);
- num_modes = 0;
- goto out;
- }
-
- ptn_bridge->edid = (struct edid *)edid;
- drm_mode_connector_update_edid_property(connector, ptn_bridge->edid);
-
- num_modes = drm_add_edid_modes(connector, ptn_bridge->edid);
-
-out:
- if (power_off)
- ptn3460_disable(ptn_bridge->bridge);
-
- return num_modes;
-}
-
-struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
-{
- struct ptn3460_bridge *ptn_bridge;
-
- ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
-
- return ptn_bridge->encoder;
-}
-
-struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
- .get_modes = ptn3460_get_modes,
- .best_encoder = ptn3460_best_encoder,
-};
-
-enum drm_connector_status ptn3460_detect(struct drm_connector *connector,
- bool force)
-{
- return connector_status_connected;
-}
-
-void ptn3460_connector_destroy(struct drm_connector *connector)
-{
- drm_connector_cleanup(connector);
-}
-
-struct drm_connector_funcs ptn3460_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
- .fill_modes = drm_helper_probe_single_connector_modes,
- .detect = ptn3460_detect,
- .destroy = ptn3460_connector_destroy,
-};
-
-int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
- struct i2c_client *client, struct device_node *node)
-{
- int ret;
- struct drm_bridge *bridge;
- struct ptn3460_bridge *ptn_bridge;
-
- bridge = devm_kzalloc(dev->dev, sizeof(*bridge), GFP_KERNEL);
- if (!bridge) {
- DRM_ERROR("Failed to allocate drm bridge\n");
- return -ENOMEM;
- }
-
- ptn_bridge = devm_kzalloc(dev->dev, sizeof(*ptn_bridge), GFP_KERNEL);
- if (!ptn_bridge) {
- DRM_ERROR("Failed to allocate ptn bridge\n");
- return -ENOMEM;
- }
-
- ptn_bridge->client = client;
- ptn_bridge->encoder = encoder;
- ptn_bridge->bridge = bridge;
- ptn_bridge->gpio_pd_n = of_get_named_gpio(node, "powerdown-gpio", 0);
- if (gpio_is_valid(ptn_bridge->gpio_pd_n)) {
- ret = gpio_request_one(ptn_bridge->gpio_pd_n,
- GPIOF_OUT_INIT_HIGH, "PTN3460_PD_N");
- if (ret) {
- DRM_ERROR("Request powerdown-gpio failed (%d)\n", ret);
- return ret;
- }
- }
-
- ptn_bridge->gpio_rst_n = of_get_named_gpio(node, "reset-gpio", 0);
- if (gpio_is_valid(ptn_bridge->gpio_rst_n)) {
- /*
- * Request the reset pin low to avoid the bridge being
- * initialized prematurely
- */
- ret = gpio_request_one(ptn_bridge->gpio_rst_n,
- GPIOF_OUT_INIT_LOW, "PTN3460_RST_N");
- if (ret) {
- DRM_ERROR("Request reset-gpio failed (%d)\n", ret);
- gpio_free(ptn_bridge->gpio_pd_n);
- return ret;
- }
- }
-
- ret = of_property_read_u32(node, "edid-emulation",
- &ptn_bridge->edid_emulation);
- if (ret) {
- DRM_ERROR("Can't read edid emulation value\n");
- goto err;
- }
-
- ret = drm_bridge_init(dev, bridge, &ptn3460_bridge_funcs);
- if (ret) {
- DRM_ERROR("Failed to initialize bridge with drm\n");
- goto err;
- }
-
- bridge->driver_private = ptn_bridge;
- encoder->bridge = bridge;
-
- ret = drm_connector_init(dev, &ptn_bridge->connector,
- &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
- if (ret) {
- DRM_ERROR("Failed to initialize connector with drm\n");
- goto err;
- }
- drm_connector_helper_add(&ptn_bridge->connector,
- &ptn3460_connector_helper_funcs);
- drm_connector_register(&ptn_bridge->connector);
- drm_mode_connector_attach_encoder(&ptn_bridge->connector, encoder);
-
- return 0;
-
-err:
- if (gpio_is_valid(ptn_bridge->gpio_pd_n))
- gpio_free(ptn_bridge->gpio_pd_n);
- if (gpio_is_valid(ptn_bridge->gpio_rst_n))
- gpio_free(ptn_bridge->gpio_rst_n);
- return ret;
-}
-EXPORT_SYMBOL(ptn3460_init);
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
new file mode 100644
index 0000000..84645e6
--- /dev/null
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+
+#include <drm/drm_crtc.h>
+
+static DEFINE_MUTEX(bridge_lock);
+static LIST_HEAD(bridge_lookup);
+
+int drm_bridge_add_for_lookup(struct drm_bridge *bridge)
+{
+ mutex_lock(&bridge_lock);
+ list_add_tail(&bridge->head, &bridge_lookup);
+ mutex_unlock(&bridge_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_bridge_add_for_lookup);
+
+void drm_bridge_remove_from_lookup(struct drm_bridge *bridge)
+{
+ mutex_lock(&bridge_lock);
+ list_del_init(&bridge->head);
+ mutex_unlock(&bridge_lock);
+}
+EXPORT_SYMBOL(drm_bridge_remove_from_lookup);
+
+int drm_bridge_attach_encoder(struct drm_bridge *bridge,
+ struct drm_encoder *encoder)
+{
+ if (!bridge || !encoder)
+ return -EINVAL;
+
+ if (bridge->encoder)
+ return -EBUSY;
+
+ encoder->bridge = bridge;
+ bridge->encoder = encoder;
+ bridge->drm_dev = encoder->dev;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_bridge_attach_encoder);
+
+#ifdef CONFIG_OF
+struct drm_bridge *of_drm_find_bridge(struct device_node *np)
+{
+ struct drm_bridge *bridge;
+
+ mutex_lock(&bridge_lock);
+
+ list_for_each_entry(bridge, &bridge_lookup, head) {
+ if (bridge->dev->of_node == np) {
+ mutex_unlock(&bridge_lock);
+ return bridge;
+ }
+ }
+
+ mutex_unlock(&bridge_lock);
+ return NULL;
+}
+EXPORT_SYMBOL(of_drm_find_bridge);
+#endif
+
+MODULE_AUTHOR("Ajay Kumar <ajaykumar.rs@samsung.com>");
+MODULE_DESCRIPTION("DRM bridge infrastructure");
+MODULE_LICENSE("GPL and additional rights");
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1ccf5cb..436e75d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -993,7 +993,6 @@ EXPORT_SYMBOL(drm_connector_unplug_all);
* drm_bridge_init - initialize a drm transcoder/bridge
* @dev: drm device
* @bridge: transcoder/bridge to set up
- * @funcs: bridge function table
*
* Initialises a preallocated bridge. Bridges should be
* subclassed as part of driver connector objects.
@@ -1001,8 +1000,7 @@ EXPORT_SYMBOL(drm_connector_unplug_all);
* Returns:
* Zero on success, error code on failure.
*/
-int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
- const struct drm_bridge_funcs *funcs)
+int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge)
{
int ret;
@@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
if (ret)
goto out;
- bridge->dev = dev;
- bridge->funcs = funcs;
+ bridge->drm_dev = dev;
list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
dev->mode_config.num_bridge++;
@@ -1032,7 +1029,7 @@ EXPORT_SYMBOL(drm_bridge_init);
*/
void drm_bridge_cleanup(struct drm_bridge *bridge)
{
- struct drm_device *dev = bridge->dev;
+ struct drm_device *dev = bridge->drm_dev;
drm_modeset_lock_all(dev);
drm_mode_object_put(dev, &bridge->base);
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9..bdef294 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -51,9 +51,10 @@ config DRM_EXYNOS_DSI
config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
- depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
+ depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS
default DRM_EXYNOS
select DRM_PANEL
+ select DRM_BRIDGE
help
This enables support for DP device.
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 49356cc..055a9e1 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,7 +28,6 @@
#include <drm/drm_crtc.h>
#include <drm/drm_crtc_helper.h>
#include <drm/drm_panel.h>
-#include <drm/bridge/ptn3460.h>
#include "exynos_drm_drv.h"
#include "exynos_dp_core.h"
@@ -986,33 +985,23 @@ static struct drm_connector_helper_funcs exynos_dp_connector_helper_funcs = {
.best_encoder = exynos_dp_best_encoder,
};
-static bool find_bridge(const char *compat, struct bridge_init *bridge)
+static int exynos_drm_attach_lcd_bridge(struct exynos_dp_device *dp,
+ struct drm_encoder *encoder)
{
- bridge->client = NULL;
- bridge->node = of_find_compatible_node(NULL, NULL, compat);
- if (!bridge->node)
- return false;
-
- bridge->client = of_find_i2c_device_by_node(bridge->node);
- if (!bridge->client)
- return false;
-
- return true;
-}
-
-/* returns the number of bridges attached */
-static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
- struct drm_encoder *encoder)
-{
- struct bridge_init bridge;
int ret;
- if (find_bridge("nxp,ptn3460", &bridge)) {
- ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
- if (!ret)
- return 1;
+ dp->bridge->connector_polled = DRM_CONNECTOR_POLL_HPD;
+ ret = drm_bridge_attach_encoder(dp->bridge, encoder);
+ if (ret) {
+ DRM_ERROR("Failed to attach bridge to encoder\n");
+ return ret;
}
- return 0;
+
+ /* Allow the bridge to continue with rest of initialization */
+ if (dp->bridge->funcs && dp->bridge->funcs->post_encoder_init)
+ return dp->bridge->funcs->post_encoder_init(dp->bridge);
+
+ return -ENODEV;
}
static int exynos_dp_create_connector(struct exynos_drm_display *display,
@@ -1025,9 +1014,11 @@ static int exynos_dp_create_connector(struct exynos_drm_display *display,
dp->encoder = encoder;
/* Pre-empt DP connector creation if there's a bridge */
- ret = exynos_drm_attach_lcd_bridge(dp->drm_dev, encoder);
- if (ret)
- return 0;
+ if (dp->bridge) {
+ ret = exynos_drm_attach_lcd_bridge(dp, encoder);
+ if (!ret)
+ return 0;
+ }
connector->polled = DRM_CONNECTOR_POLL_HPD;
@@ -1279,7 +1270,7 @@ static int exynos_dp_bind(struct device *dev, struct device *master, void *data)
if (ret)
return ret;
- if (!dp->panel) {
+ if (!dp->panel && !dp->bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
return ret;
@@ -1370,7 +1361,7 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct device_node *panel_node;
+ struct device_node *panel_node, *bridge_node;
struct exynos_dp_device *dp;
int ret;
@@ -1392,6 +1383,14 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
+ bridge_node = of_parse_phandle(dev->of_node, "bridge", 0);
+ if (bridge_node) {
+ dp->bridge = of_drm_find_bridge(bridge_node);
+ of_node_put(bridge_node);
+ if (!dp->bridge)
+ return -EPROBE_DEFER;
+ }
+
exynos_dp_display.ctx = dp;
ret = component_add(&pdev->dev, &exynos_dp_ops);
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h b/drivers/gpu/drm/exynos/exynos_dp_core.h
index a1aee69..3b0ba93 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -150,6 +150,7 @@ struct exynos_dp_device {
struct drm_connector connector;
struct drm_encoder *encoder;
struct drm_panel *panel;
+ struct drm_bridge *bridge;
struct clk *clock;
unsigned int irq;
void __iomem *reg_base;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index f6cf745..0309539 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -221,8 +221,9 @@ struct drm_bridge *hdmi_bridge_init(struct hdmi *hdmi)
hdmi_bridge->hdmi = hdmi_reference(hdmi);
bridge = &hdmi_bridge->base;
+ bridge->funcs = &hdmi_bridge_funcs;
- drm_bridge_init(hdmi->dev, bridge, &hdmi_bridge_funcs);
+ drm_bridge_init(hdmi->dev, bridge);
return bridge;
diff --git a/include/drm/bridge/ptn3460.h b/include/drm/bridge/ptn3460.h
deleted file mode 100644
index ff62344..0000000
--- a/include/drm/bridge/ptn3460.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * 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.
- */
-
-#ifndef _DRM_BRIDGE_PTN3460_H_
-#define _DRM_BRIDGE_PTN3460_H_
-
-struct drm_device;
-struct drm_encoder;
-struct i2c_client;
-struct device_node;
-
-#if defined(CONFIG_DRM_PTN3460) || defined(CONFIG_DRM_PTN3460_MODULE)
-
-int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
- struct i2c_client *client, struct device_node *node);
-#else
-
-static inline int ptn3460_init(struct drm_device *dev,
- struct drm_encoder *encoder, struct i2c_client *client,
- struct device_node *node)
-{
- return 0;
-}
-
-#endif
-
-#endif
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e529b68..e5a41ad 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -619,6 +619,7 @@ struct drm_plane {
/**
* drm_bridge_funcs - drm_bridge control functions
+ * @post_encoder_init: called by the parent encoder
* @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
* @disable: Called right before encoder prepare, disables the bridge
* @post_disable: Called right after encoder prepare, for lockstepped disable
@@ -628,6 +629,7 @@ struct drm_plane {
* @destroy: make object go away
*/
struct drm_bridge_funcs {
+ int (*post_encoder_init)(struct drm_bridge *bridge);
bool (*mode_fixup)(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
@@ -648,15 +650,19 @@ struct drm_bridge_funcs {
* @base: base mode object
* @funcs: control functions
* @driver_private: pointer to the bridge driver's internal context
+ * @connector_polled: polled flag needed for registering connector
*/
struct drm_bridge {
- struct drm_device *dev;
+ struct device *dev;
+ struct drm_device *drm_dev;
+ struct drm_encoder *encoder;
struct list_head head;
struct drm_mode_object base;
const struct drm_bridge_funcs *funcs;
void *driver_private;
+ int connector_polled;
};
/**
@@ -895,8 +901,12 @@ extern void drm_connector_cleanup(struct drm_connector *connector);
/* helper to unplug all connectors from sysfs for device */
extern void drm_connector_unplug_all(struct drm_device *dev);
-extern int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
- const struct drm_bridge_funcs *funcs);
+extern int drm_bridge_add_for_lookup(struct drm_bridge *bridge);
+extern void drm_bridge_remove_from_lookup(struct drm_bridge *bridge);
+extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
+extern int drm_bridge_attach_encoder(struct drm_bridge *bridge,
+ struct drm_encoder *encoder);
+extern int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge);
extern void drm_bridge_cleanup(struct drm_bridge *bridge);
extern int drm_encoder_init(struct drm_device *dev,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-07-25 19:22 ` [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model Ajay Kumar
@ 2014-07-30 11:19 ` Thierry Reding
2014-07-30 14:31 ` Ajay kumar
2014-09-15 17:37 ` Laurent Pinchart
1 sibling, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 11:19 UTC (permalink / raw)
To: Ajay Kumar
Cc: devicetree, linux-samsung-soc, seanpaul, daniel.vetter, joshi,
dri-devel, ajaynumb, prashanth.g
[-- Attachment #1.1: Type: text/plain, Size: 5122 bytes --]
On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
> This patch tries to seperate drm_bridge implementation
> into 2 parts, a drm part and a non_drm part.
>
> A set of helper functions are defined in this patch to make
> bridge driver probe independent of the drm flow.
>
> The bridge devices register themselves on a lookup table
> when they get probed by calling "drm_bridge_add_for_lookup".
>
> The parent encoder driver waits till the bridge is available in the
> lookup table(by calling "of_drm_find_bridge") and then continues with
> its initialization.
>
> The encoder driver should call "drm_bridge_attach_encoder" to pass on
> the drm_device and the encoder pointers to the bridge object.
>
> Now that the drm_device pointer is available, the encoder then calls
> "bridge->funcs->post_encoder_init" to allow the bridge to continue
> registering itself with the drm core.
>
> Also, non driver model based ptn3460 driver is removed in this patch.
Why is it removed in this patch? Can't you do this incrementally rather
than remove the driver in this patch and add it again later? If you do
it this way then we'll always have this one commit where devices that
have a ptn3460 don't work, so it becomes impossible to bisect across
this commit.
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
[...]
> +int drm_bridge_add_for_lookup(struct drm_bridge *bridge)
> +{
> + mutex_lock(&bridge_lock);
> + list_add_tail(&bridge->head, &bridge_lookup);
> + mutex_unlock(&bridge_lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_bridge_add_for_lookup);
> +
> +void drm_bridge_remove_from_lookup(struct drm_bridge *bridge)
> +{
> + mutex_lock(&bridge_lock);
> + list_del_init(&bridge->head);
> + mutex_unlock(&bridge_lock);
> +}
> +EXPORT_SYMBOL(drm_bridge_remove_from_lookup);
The "_for_lookup" and "_from_lookup" suffixes aren't useful in my
opinion.
> +int drm_bridge_attach_encoder(struct drm_bridge *bridge,
> + struct drm_encoder *encoder)
And this could simply be "drm_bridge_attach()" since we'll only ever
want to attach it to encoders.
> +{
> + if (!bridge || !encoder)
> + return -EINVAL;
> +
> + if (bridge->encoder)
> + return -EBUSY;
> +
> + encoder->bridge = bridge;
> + bridge->encoder = encoder;
> + bridge->drm_dev = encoder->dev;
Should this function perhaps call the bridge's ->post_encoder_init()?
And it should probably call drm_bridge_init() too, since the DRM device
is now available.
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
Maybe since you're introducing a new drm_bridge.c file above already it
would make sense to move out existing drm_bridge related code in a
preparatory patch?
Maybe Sean or Rob can comment on whether there was a specific reason to
include it in drm_crtc.c in the first place.
> @@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
> if (ret)
> goto out;
>
> - bridge->dev = dev;
> - bridge->funcs = funcs;
> + bridge->drm_dev = dev;
This sets ->drm_dev, but it was already set in drm_bridge_attach(), so I
think that's one more argument to call this function when attaching.
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
[...]
> @@ -1370,7 +1361,7 @@ static const struct component_ops exynos_dp_ops = {
> static int exynos_dp_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *panel_node;
> + struct device_node *panel_node, *bridge_node;
Nit: I don't think you'll need two variables here, since once you've
obtained the real panel or bridge objects you no longer need the OF
nodes.
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index e529b68..e5a41ad 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -619,6 +619,7 @@ struct drm_plane {
>
> /**
> * drm_bridge_funcs - drm_bridge control functions
> + * @post_encoder_init: called by the parent encoder
Maybe rename this to "attach" to make it more obvious when exactly it's
called?
> * @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
> * @disable: Called right before encoder prepare, disables the bridge
> * @post_disable: Called right after encoder prepare, for lockstepped disable
> @@ -628,6 +629,7 @@ struct drm_plane {
> * @destroy: make object go away
> */
> struct drm_bridge_funcs {
> + int (*post_encoder_init)(struct drm_bridge *bridge);
> bool (*mode_fixup)(struct drm_bridge *bridge,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode);
> @@ -648,15 +650,19 @@ struct drm_bridge_funcs {
> * @base: base mode object
> * @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> + * @connector_polled: polled flag needed for registering connector
Can you explain why this new field is needed? It seems like a completely
unrelated change.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-07-30 11:19 ` Thierry Reding
@ 2014-07-30 14:31 ` Ajay kumar
2014-07-30 15:08 ` Thierry Reding
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 14:31 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
On Wed, Jul 30, 2014 at 4:49 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
>> This patch tries to seperate drm_bridge implementation
>> into 2 parts, a drm part and a non_drm part.
>>
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when they get probed by calling "drm_bridge_add_for_lookup".
>>
>> The parent encoder driver waits till the bridge is available in the
>> lookup table(by calling "of_drm_find_bridge") and then continues with
>> its initialization.
>>
>> The encoder driver should call "drm_bridge_attach_encoder" to pass on
>> the drm_device and the encoder pointers to the bridge object.
>>
>> Now that the drm_device pointer is available, the encoder then calls
>> "bridge->funcs->post_encoder_init" to allow the bridge to continue
>> registering itself with the drm core.
>>
>> Also, non driver model based ptn3460 driver is removed in this patch.
>
> Why is it removed in this patch? Can't you do this incrementally rather
> than remove the driver in this patch and add it again later? If you do
> it this way then we'll always have this one commit where devices that
> have a ptn3460 don't work, so it becomes impossible to bisect across
> this commit.
Ok. I will try to modify ptn3460 to support driver model in this patch itself.
And then, adding panel support, converting it to gpiod interface and other
cleanups should follow.
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> [...]
>> +int drm_bridge_add_for_lookup(struct drm_bridge *bridge)
>> +{
>> + mutex_lock(&bridge_lock);
>> + list_add_tail(&bridge->head, &bridge_lookup);
>> + mutex_unlock(&bridge_lock);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(drm_bridge_add_for_lookup);
>> +
>> +void drm_bridge_remove_from_lookup(struct drm_bridge *bridge)
>> +{
>> + mutex_lock(&bridge_lock);
>> + list_del_init(&bridge->head);
>> + mutex_unlock(&bridge_lock);
>> +}
>> +EXPORT_SYMBOL(drm_bridge_remove_from_lookup);
>
> The "_for_lookup" and "_from_lookup" suffixes aren't useful in my
> opinion.
Ok. I will just remove the suffix.
>> +int drm_bridge_attach_encoder(struct drm_bridge *bridge,
>> + struct drm_encoder *encoder)
>
> And this could simply be "drm_bridge_attach()" since we'll only ever
> want to attach it to encoders.
Right.
>> +{
>> + if (!bridge || !encoder)
>> + return -EINVAL;
>> +
>> + if (bridge->encoder)
>> + return -EBUSY;
>> +
>> + encoder->bridge = bridge;
>> + bridge->encoder = encoder;
>> + bridge->drm_dev = encoder->dev;
>
> Should this function perhaps call the bridge's ->post_encoder_init()?
> And it should probably call drm_bridge_init() too, since the DRM device
> is now available.
This will cleanup some code in both the drivers. I will change it.
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> [...]
>
> Maybe since you're introducing a new drm_bridge.c file above already it
> would make sense to move out existing drm_bridge related code in a
> preparatory patch?
>
> Maybe Sean or Rob can comment on whether there was a specific reason to
> include it in drm_crtc.c in the first place.
>
>> @@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
>> if (ret)
>> goto out;
>>
>> - bridge->dev = dev;
>> - bridge->funcs = funcs;
>> + bridge->drm_dev = dev;
>
> This sets ->drm_dev, but it was already set in drm_bridge_attach(), so I
> think that's one more argument to call this function when attaching.
Point accepted.
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
> [...]
>> @@ -1370,7 +1361,7 @@ static const struct component_ops exynos_dp_ops = {
>> static int exynos_dp_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> - struct device_node *panel_node;
>> + struct device_node *panel_node, *bridge_node;
>
> Nit: I don't think you'll need two variables here, since once you've
> obtained the real panel or bridge objects you no longer need the OF
> nodes.
Right.
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index e529b68..e5a41ad 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -619,6 +619,7 @@ struct drm_plane {
>>
>> /**
>> * drm_bridge_funcs - drm_bridge control functions
>> + * @post_encoder_init: called by the parent encoder
>
> Maybe rename this to "attach" to make it more obvious when exactly it's
> called?
"post_encoder_attach"?
>> * @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
>> * @disable: Called right before encoder prepare, disables the bridge
>> * @post_disable: Called right after encoder prepare, for lockstepped disable
>> @@ -628,6 +629,7 @@ struct drm_plane {
>> * @destroy: make object go away
>> */
>> struct drm_bridge_funcs {
>> + int (*post_encoder_init)(struct drm_bridge *bridge);
>> bool (*mode_fixup)(struct drm_bridge *bridge,
>> const struct drm_display_mode *mode,
>> struct drm_display_mode *adjusted_mode);
>> @@ -648,15 +650,19 @@ struct drm_bridge_funcs {
>> * @base: base mode object
>> * @funcs: control functions
>> * @driver_private: pointer to the bridge driver's internal context
>> + * @connector_polled: polled flag needed for registering connector
>
> Can you explain why this new field is needed? It seems like a completely
> unrelated change.
How do I select this flag for the bridge chip?
Assume if I did select DRM_CONNECTOR_POLL_HPD, where to call
drm_helper_hpd_irq_event in the driver? Is post_encoder_init a right place?
Without the polled flag, I get display very late.
Please throw some light on this!
Ajay
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-07-30 14:31 ` Ajay kumar
@ 2014-07-30 15:08 ` Thierry Reding
2014-07-30 16:03 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 15:08 UTC (permalink / raw)
To: Ajay kumar
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
[-- Attachment #1.1: Type: text/plain, Size: 7135 bytes --]
On Wed, Jul 30, 2014 at 08:01:44PM +0530, Ajay kumar wrote:
> On Wed, Jul 30, 2014 at 4:49 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
> >> This patch tries to seperate drm_bridge implementation
> >> into 2 parts, a drm part and a non_drm part.
> >>
> >> A set of helper functions are defined in this patch to make
> >> bridge driver probe independent of the drm flow.
> >>
> >> The bridge devices register themselves on a lookup table
> >> when they get probed by calling "drm_bridge_add_for_lookup".
> >>
> >> The parent encoder driver waits till the bridge is available in the
> >> lookup table(by calling "of_drm_find_bridge") and then continues with
> >> its initialization.
> >>
> >> The encoder driver should call "drm_bridge_attach_encoder" to pass on
> >> the drm_device and the encoder pointers to the bridge object.
> >>
> >> Now that the drm_device pointer is available, the encoder then calls
> >> "bridge->funcs->post_encoder_init" to allow the bridge to continue
> >> registering itself with the drm core.
> >>
> >> Also, non driver model based ptn3460 driver is removed in this patch.
> >
> > Why is it removed in this patch? Can't you do this incrementally rather
> > than remove the driver in this patch and add it again later? If you do
> > it this way then we'll always have this one commit where devices that
> > have a ptn3460 don't work, so it becomes impossible to bisect across
> > this commit.
> Ok. I will try to modify ptn3460 to support driver model in this patch itself.
> And then, adding panel support, converting it to gpiod interface and other
> cleanups should follow.
I think it should even be possible to do this in more separate steps.
For example you could add the new bridge infrastructure without touching
any of the existing drivers (so that they are completely unaffected by
the changes) and then start converting one by one.
For some of the changes this may be difficult (such as the dev ->
drm_dev rename to make room for the new struct device *dev). But that
could for example be done in a preparatory patch that first renames the
field, so that the "infrastructure" patch can add the new field without
renaming any fields and therefore needing changes to drivers directly.
The goal of that whole exercise is to allow display drivers to keep
working with the existing API (ptn3460_init()) while we convert the
bridge drivers to register with the new framework. Then we can more
safely convert each display driver individually to make use of the new
framework and once all drivers have been converted the old API can
simply be removed.
That way there should be no impact on existing functionality at any
point.
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > [...]
> >
> > Maybe since you're introducing a new drm_bridge.c file above already it
> > would make sense to move out existing drm_bridge related code in a
> > preparatory patch?
> >
> > Maybe Sean or Rob can comment on whether there was a specific reason to
> > include it in drm_crtc.c in the first place.
> >
> >> @@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
> >> if (ret)
> >> goto out;
> >>
> >> - bridge->dev = dev;
> >> - bridge->funcs = funcs;
> >> + bridge->drm_dev = dev;
> >
> > This sets ->drm_dev, but it was already set in drm_bridge_attach(), so I
> > think that's one more argument to call this function when attaching.
> Point accepted.
I forgot to mention earlier. drm_dev seems redundant to me. I'd go with
just "drm".
> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >> index e529b68..e5a41ad 100644
> >> --- a/include/drm/drm_crtc.h
> >> +++ b/include/drm/drm_crtc.h
> >> @@ -619,6 +619,7 @@ struct drm_plane {
> >>
> >> /**
> >> * drm_bridge_funcs - drm_bridge control functions
> >> + * @post_encoder_init: called by the parent encoder
> >
> > Maybe rename this to "attach" to make it more obvious when exactly it's
> > called?
> "post_encoder_attach"?
"post_encoder_" doesn't contain much information, or even ambiguous
information. What does "post" "encoder" mean? A bridge is always
attached to an encoder, so "encoder" can be dropped. Now "post" has
implications as to the time when it is called, but does it mean after
the encoder has been initialized, or after the encoder has been removed?
Simply "attach" means it's called by the parent encoder to initialize
the bridge once it's been attached to an encoder. So obviously it's
after the encoder has been initialized. "attach" has all he information
required. Any prefix is redundant in my opinion and removing prefixes
gives shorter names and reduces the number of keypresses.
> >> * @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
> >> * @disable: Called right before encoder prepare, disables the bridge
> >> * @post_disable: Called right after encoder prepare, for lockstepped disable
> >> @@ -628,6 +629,7 @@ struct drm_plane {
> >> * @destroy: make object go away
> >> */
> >> struct drm_bridge_funcs {
> >> + int (*post_encoder_init)(struct drm_bridge *bridge);
> >> bool (*mode_fixup)(struct drm_bridge *bridge,
> >> const struct drm_display_mode *mode,
> >> struct drm_display_mode *adjusted_mode);
> >> @@ -648,15 +650,19 @@ struct drm_bridge_funcs {
> >> * @base: base mode object
> >> * @funcs: control functions
> >> * @driver_private: pointer to the bridge driver's internal context
> >> + * @connector_polled: polled flag needed for registering connector
> >
> > Can you explain why this new field is needed? It seems like a completely
> > unrelated change.
> How do I select this flag for the bridge chip?
> Assume if I did select DRM_CONNECTOR_POLL_HPD, where to call
> drm_helper_hpd_irq_event in the driver? Is post_encoder_init a right place?
>
> Without the polled flag, I get display very late.
> Please throw some light on this!
I just don't understand why it's necessary to implement this field in
the drm_bridge. Every bridge driver will already implement a connector,
in which case it can simply set the connector's .polled field, can't it?
It seems like the only reason you have it in drm_bridge is so that the
encoder driver can set it. But I don't see why it should be doing that.
The polled state is a property of the connector, and the encoder driver
doesn't know anything about it. So if the bridge has a way to detect HPD
then it should be setting up the connector to properly report it. For
example if the bridge has an input pin to detect it, then it could use a
GPIO to receive interrupts and call drm_helper_hpd_irq_event() in the
interrupt handler.
Perhaps you can explain the exact setup where you need this (or point me
at the code since I can't seem to find the relevant location) so that I
can gain a better understanding.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-07-30 15:08 ` Thierry Reding
@ 2014-07-30 16:03 ` Ajay kumar
2014-07-31 10:58 ` Thierry Reding
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 16:03 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
On Wed, Jul 30, 2014 at 8:38 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Wed, Jul 30, 2014 at 08:01:44PM +0530, Ajay kumar wrote:
>> On Wed, Jul 30, 2014 at 4:49 PM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
>> >> This patch tries to seperate drm_bridge implementation
>> >> into 2 parts, a drm part and a non_drm part.
>> >>
>> >> A set of helper functions are defined in this patch to make
>> >> bridge driver probe independent of the drm flow.
>> >>
>> >> The bridge devices register themselves on a lookup table
>> >> when they get probed by calling "drm_bridge_add_for_lookup".
>> >>
>> >> The parent encoder driver waits till the bridge is available in the
>> >> lookup table(by calling "of_drm_find_bridge") and then continues with
>> >> its initialization.
>> >>
>> >> The encoder driver should call "drm_bridge_attach_encoder" to pass on
>> >> the drm_device and the encoder pointers to the bridge object.
>> >>
>> >> Now that the drm_device pointer is available, the encoder then calls
>> >> "bridge->funcs->post_encoder_init" to allow the bridge to continue
>> >> registering itself with the drm core.
>> >>
>> >> Also, non driver model based ptn3460 driver is removed in this patch.
>> >
>> > Why is it removed in this patch? Can't you do this incrementally rather
>> > than remove the driver in this patch and add it again later? If you do
>> > it this way then we'll always have this one commit where devices that
>> > have a ptn3460 don't work, so it becomes impossible to bisect across
>> > this commit.
>> Ok. I will try to modify ptn3460 to support driver model in this patch itself.
>> And then, adding panel support, converting it to gpiod interface and other
>> cleanups should follow.
>
> I think it should even be possible to do this in more separate steps.
> For example you could add the new bridge infrastructure without touching
> any of the existing drivers (so that they are completely unaffected by
> the changes) and then start converting one by one.
>
> For some of the changes this may be difficult (such as the dev ->
> drm_dev rename to make room for the new struct device *dev). But that
> could for example be done in a preparatory patch that first renames the
> field, so that the "infrastructure" patch can add the new field without
> renaming any fields and therefore needing changes to drivers directly.
>
> The goal of that whole exercise is to allow display drivers to keep
> working with the existing API (ptn3460_init()) while we convert the
> bridge drivers to register with the new framework. Then we can more
> safely convert each display driver individually to make use of the new
> framework and once all drivers have been converted the old API can
> simply be removed.
>
> That way there should be no impact on existing functionality at any
> point.
As of now only exynos_dp uses ptn3460_init.
And, also only 2 drivers use drm_bridge_init.
It should be really easy to bisect if something goes wrong.
Still, I will try to divide it so that each patch contains minimal change.
>> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> > [...]
>> >
>> > Maybe since you're introducing a new drm_bridge.c file above already it
>> > would make sense to move out existing drm_bridge related code in a
>> > preparatory patch?
>> >
>> > Maybe Sean or Rob can comment on whether there was a specific reason to
>> > include it in drm_crtc.c in the first place.
>> >
>> >> @@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
>> >> if (ret)
>> >> goto out;
>> >>
>> >> - bridge->dev = dev;
>> >> - bridge->funcs = funcs;
>> >> + bridge->drm_dev = dev;
>> >
>> > This sets ->drm_dev, but it was already set in drm_bridge_attach(), so I
>> > think that's one more argument to call this function when attaching.
>> Point accepted.
>
> I forgot to mention earlier. drm_dev seems redundant to me. I'd go with
> just "drm".
Ok.
>> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> >> index e529b68..e5a41ad 100644
>> >> --- a/include/drm/drm_crtc.h
>> >> +++ b/include/drm/drm_crtc.h
>> >> @@ -619,6 +619,7 @@ struct drm_plane {
>> >>
>> >> /**
>> >> * drm_bridge_funcs - drm_bridge control functions
>> >> + * @post_encoder_init: called by the parent encoder
>> >
>> > Maybe rename this to "attach" to make it more obvious when exactly it's
>> > called?
>> "post_encoder_attach"?
>
> "post_encoder_" doesn't contain much information, or even ambiguous
> information. What does "post" "encoder" mean? A bridge is always
> attached to an encoder, so "encoder" can be dropped. Now "post" has
> implications as to the time when it is called, but does it mean after
> the encoder has been initialized, or after the encoder has been removed?
> Simply "attach" means it's called by the parent encoder to initialize
> the bridge once it's been attached to an encoder. So obviously it's
> after the encoder has been initialized. "attach" has all he information
> required. Any prefix is redundant in my opinion and removing prefixes
> gives shorter names and reduces the number of keypresses.
Finally, what name it should have?
>> >> * @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
>> >> * @disable: Called right before encoder prepare, disables the bridge
>> >> * @post_disable: Called right after encoder prepare, for lockstepped disable
>> >> @@ -628,6 +629,7 @@ struct drm_plane {
>> >> * @destroy: make object go away
>> >> */
>> >> struct drm_bridge_funcs {
>> >> + int (*post_encoder_init)(struct drm_bridge *bridge);
>> >> bool (*mode_fixup)(struct drm_bridge *bridge,
>> >> const struct drm_display_mode *mode,
>> >> struct drm_display_mode *adjusted_mode);
>> >> @@ -648,15 +650,19 @@ struct drm_bridge_funcs {
>> >> * @base: base mode object
>> >> * @funcs: control functions
>> >> * @driver_private: pointer to the bridge driver's internal context
>> >> + * @connector_polled: polled flag needed for registering connector
>> >
>> > Can you explain why this new field is needed? It seems like a completely
>> > unrelated change.
>> How do I select this flag for the bridge chip?
>> Assume if I did select DRM_CONNECTOR_POLL_HPD, where to call
>> drm_helper_hpd_irq_event in the driver? Is post_encoder_init a right place?
>>
>> Without the polled flag, I get display very late.
>> Please throw some light on this!
>
> I just don't understand why it's necessary to implement this field in
> the drm_bridge. Every bridge driver will already implement a connector,
> in which case it can simply set the connector's .polled field, can't it?
>
> It seems like the only reason you have it in drm_bridge is so that the
> encoder driver can set it. But I don't see why it should be doing that.
> The polled state is a property of the connector, and the encoder driver
> doesn't know anything about it. So if the bridge has a way to detect HPD
> then it should be setting up the connector to properly report it. For
> example if the bridge has an input pin to detect it, then it could use a
> GPIO to receive interrupts and call drm_helper_hpd_irq_event() in the
> interrupt handler.
Hmm. Are we allowed to call drm_helper_hpd_irq_event() the way
DSI panels use it? Like the last step in panel probe?
For bridges, it will be in post_encoder_init!
> Perhaps you can explain the exact setup where you need this (or point me
> at the code since I can't seem to find the relevant location) so that I
> can gain a better understanding.
I can see bridge getting detected only when I set polled member of
bridge connector to DRM_CONNECTOR_POLL_HPD, because exynos_drm
also calls drm_helper_hpd_irq_event() to force detect all connectors at the
end of drm_load.
If I don't set the polled member, I see bridge getting detected after
quite sometime.
Ajay
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-07-30 16:03 ` Ajay kumar
@ 2014-07-31 10:58 ` Thierry Reding
2014-08-22 23:33 ` Javier Martinez Canillas
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-31 10:58 UTC (permalink / raw)
To: Ajay kumar
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
[-- Attachment #1.1: Type: text/plain, Size: 6329 bytes --]
On Wed, Jul 30, 2014 at 09:33:28PM +0530, Ajay kumar wrote:
> On Wed, Jul 30, 2014 at 8:38 PM, Thierry Reding <thierry.reding@gmail.com> wrote:
[...]
> > I think it should even be possible to do this in more separate steps.
> > For example you could add the new bridge infrastructure without touching
> > any of the existing drivers (so that they are completely unaffected by
> > the changes) and then start converting one by one.
> >
> > For some of the changes this may be difficult (such as the dev ->
> > drm_dev rename to make room for the new struct device *dev). But that
> > could for example be done in a preparatory patch that first renames the
> > field, so that the "infrastructure" patch can add the new field without
> > renaming any fields and therefore needing changes to drivers directly.
> >
> > The goal of that whole exercise is to allow display drivers to keep
> > working with the existing API (ptn3460_init()) while we convert the
> > bridge drivers to register with the new framework. Then we can more
> > safely convert each display driver individually to make use of the new
> > framework and once all drivers have been converted the old API can
> > simply be removed.
> >
> > That way there should be no impact on existing functionality at any
> > point.
> As of now only exynos_dp uses ptn3460_init.
> And, also only 2 drivers use drm_bridge_init.
> It should be really easy to bisect if something goes wrong.
> Still, I will try to divide it so that each patch contains minimal change.
Thanks.
> >> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >> >> index e529b68..e5a41ad 100644
> >> >> --- a/include/drm/drm_crtc.h
> >> >> +++ b/include/drm/drm_crtc.h
> >> >> @@ -619,6 +619,7 @@ struct drm_plane {
> >> >>
> >> >> /**
> >> >> * drm_bridge_funcs - drm_bridge control functions
> >> >> + * @post_encoder_init: called by the parent encoder
> >> >
> >> > Maybe rename this to "attach" to make it more obvious when exactly it's
> >> > called?
> >> "post_encoder_attach"?
> >
> > "post_encoder_" doesn't contain much information, or even ambiguous
> > information. What does "post" "encoder" mean? A bridge is always
> > attached to an encoder, so "encoder" can be dropped. Now "post" has
> > implications as to the time when it is called, but does it mean after
> > the encoder has been initialized, or after the encoder has been removed?
> > Simply "attach" means it's called by the parent encoder to initialize
> > the bridge once it's been attached to an encoder. So obviously it's
> > after the encoder has been initialized. "attach" has all he information
> > required. Any prefix is redundant in my opinion and removing prefixes
> > gives shorter names and reduces the number of keypresses.
> Finally, what name it should have?
I originally proposed "attach" as a more concise name and I still think
that's the best alternative.
> >> >> * @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
> >> >> * @disable: Called right before encoder prepare, disables the bridge
> >> >> * @post_disable: Called right after encoder prepare, for lockstepped disable
> >> >> @@ -628,6 +629,7 @@ struct drm_plane {
> >> >> * @destroy: make object go away
> >> >> */
> >> >> struct drm_bridge_funcs {
> >> >> + int (*post_encoder_init)(struct drm_bridge *bridge);
> >> >> bool (*mode_fixup)(struct drm_bridge *bridge,
> >> >> const struct drm_display_mode *mode,
> >> >> struct drm_display_mode *adjusted_mode);
> >> >> @@ -648,15 +650,19 @@ struct drm_bridge_funcs {
> >> >> * @base: base mode object
> >> >> * @funcs: control functions
> >> >> * @driver_private: pointer to the bridge driver's internal context
> >> >> + * @connector_polled: polled flag needed for registering connector
> >> >
> >> > Can you explain why this new field is needed? It seems like a completely
> >> > unrelated change.
> >> How do I select this flag for the bridge chip?
> >> Assume if I did select DRM_CONNECTOR_POLL_HPD, where to call
> >> drm_helper_hpd_irq_event in the driver? Is post_encoder_init a right place?
> >>
> >> Without the polled flag, I get display very late.
> >> Please throw some light on this!
> >
> > I just don't understand why it's necessary to implement this field in
> > the drm_bridge. Every bridge driver will already implement a connector,
> > in which case it can simply set the connector's .polled field, can't it?
> >
> > It seems like the only reason you have it in drm_bridge is so that the
> > encoder driver can set it. But I don't see why it should be doing that.
> > The polled state is a property of the connector, and the encoder driver
> > doesn't know anything about it. So if the bridge has a way to detect HPD
> > then it should be setting up the connector to properly report it. For
> > example if the bridge has an input pin to detect it, then it could use a
> > GPIO to receive interrupts and call drm_helper_hpd_irq_event() in the
> > interrupt handler.
> Hmm. Are we allowed to call drm_helper_hpd_irq_event() the way
> DSI panels use it? Like the last step in panel probe?
> For bridges, it will be in post_encoder_init!
drm_helper_hpd_irq_event() should only be called when a hotplug event is
detected. For all other cases detection should already happen when DRM
initializes.
I see that on Tegra we call drm_helper_hpd_irq_event() in the DSI host's
->attach(), but I don't remember why that's there and I don't see why it
would be necessary either. I'll try to remove it and see if things still
work without.
> > Perhaps you can explain the exact setup where you need this (or point me
> > at the code since I can't seem to find the relevant location) so that I
> > can gain a better understanding.
>
> I can see bridge getting detected only when I set polled member of
> bridge connector to DRM_CONNECTOR_POLL_HPD, because exynos_drm
> also calls drm_helper_hpd_irq_event() to force detect all connectors at the
> end of drm_load.
That shouldn't be necessary. DRM automatically force detects all outputs
(at least if you use drm_helper_probe_single_connector_modes(), which
seems to be the case for Exynos).
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-07-31 10:58 ` Thierry Reding
@ 2014-08-22 23:33 ` Javier Martinez Canillas
2014-08-25 6:11 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Javier Martinez Canillas @ 2014-08-22 23:33 UTC (permalink / raw)
To: Ajay kumar, Ajay Kumar
Cc: Thierry Reding, dri-devel, linux-samsung-soc, devicetree,
InKi Dae, Rob Clark, Daniel Vetter, Sean Paul, Jingoo Han,
sunil joshi, Prashanth G
Hello Ajay,
On Thu, Jul 31, 2014 at 12:58 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Wed, Jul 30, 2014 at 09:33:28PM +0530, Ajay kumar wrote:
>> On Wed, Jul 30, 2014 at 8:38 PM, Thierry Reding <thierry.reding@gmail.com> wrote:
> [...]
>> > I think it should even be possible to do this in more separate steps.
>> > For example you could add the new bridge infrastructure without touching
>> > any of the existing drivers (so that they are completely unaffected by
>> > the changes) and then start converting one by one.
>> >
>> > For some of the changes this may be difficult (such as the dev ->
>> > drm_dev rename to make room for the new struct device *dev). But that
>> > could for example be done in a preparatory patch that first renames the
>> > field, so that the "infrastructure" patch can add the new field without
>> > renaming any fields and therefore needing changes to drivers directly.
>> >
>> > The goal of that whole exercise is to allow display drivers to keep
>> > working with the existing API (ptn3460_init()) while we convert the
>> > bridge drivers to register with the new framework. Then we can more
>> > safely convert each display driver individually to make use of the new
>> > framework and once all drivers have been converted the old API can
>> > simply be removed.
>> >
>> > That way there should be no impact on existing functionality at any
>> > point.
>> As of now only exynos_dp uses ptn3460_init.
>> And, also only 2 drivers use drm_bridge_init.
>> It should be really easy to bisect if something goes wrong.
>> Still, I will try to divide it so that each patch contains minimal change.
>
> Thanks.
>
Do you plan to address Thierry's concerns and re-spin this patch?
Same question for patches:
"drm/bridge: Add i2c based driver for ptn3460 bridge"
"drm/bridge: Add i2c based driver for ps8622/ps8625 bridge"
Thanks a lot and best regards,
Javier
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-08-22 23:33 ` Javier Martinez Canillas
@ 2014-08-25 6:11 ` Ajay kumar
2014-08-25 10:10 ` Javier Martinez Canillas
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-08-25 6:11 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
Hi Javier,
On Sat, Aug 23, 2014 at 5:03 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Ajay,
>
> On Thu, Jul 31, 2014 at 12:58 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
>> On Wed, Jul 30, 2014 at 09:33:28PM +0530, Ajay kumar wrote:
>>> On Wed, Jul 30, 2014 at 8:38 PM, Thierry Reding <thierry.reding@gmail.com> wrote:
>> [...]
>>> > I think it should even be possible to do this in more separate steps.
>>> > For example you could add the new bridge infrastructure without touching
>>> > any of the existing drivers (so that they are completely unaffected by
>>> > the changes) and then start converting one by one.
>>> >
>>> > For some of the changes this may be difficult (such as the dev ->
>>> > drm_dev rename to make room for the new struct device *dev). But that
>>> > could for example be done in a preparatory patch that first renames the
>>> > field, so that the "infrastructure" patch can add the new field without
>>> > renaming any fields and therefore needing changes to drivers directly.
>>> >
>>> > The goal of that whole exercise is to allow display drivers to keep
>>> > working with the existing API (ptn3460_init()) while we convert the
>>> > bridge drivers to register with the new framework. Then we can more
>>> > safely convert each display driver individually to make use of the new
>>> > framework and once all drivers have been converted the old API can
>>> > simply be removed.
>>> >
>>> > That way there should be no impact on existing functionality at any
>>> > point.
>>> As of now only exynos_dp uses ptn3460_init.
>>> And, also only 2 drivers use drm_bridge_init.
>>> It should be really easy to bisect if something goes wrong.
>>> Still, I will try to divide it so that each patch contains minimal change.
>>
>> Thanks.
>>
>
> Do you plan to address Thierry's concerns and re-spin this patch?
>
> Same question for patches:
>
> "drm/bridge: Add i2c based driver for ptn3460 bridge"
> "drm/bridge: Add i2c based driver for ps8622/ps8625 bridge"
Yes, I will. I was caught up with some other work.
I will be sending a version ASAP.
Ajay
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-08-25 6:11 ` Ajay kumar
@ 2014-08-25 10:10 ` Javier Martinez Canillas
0 siblings, 0 replies; 70+ messages in thread
From: Javier Martinez Canillas @ 2014-08-25 10:10 UTC (permalink / raw)
To: Ajay kumar
Cc: Ajay Kumar, Thierry Reding, dri-devel, linux-samsung-soc,
devicetree, InKi Dae, Rob Clark, Daniel Vetter, Sean Paul,
Jingoo Han, sunil joshi, Prashanth G
Hello Ajay,
On Mon, Aug 25, 2014 at 8:11 AM, Ajay kumar <ajaynumb@gmail.com> wrote:
>>
>> Do you plan to address Thierry's concerns and re-spin this patch?
>>
>> Same question for patches:
>>
>> "drm/bridge: Add i2c based driver for ptn3460 bridge"
>> "drm/bridge: Add i2c based driver for ps8622/ps8625 bridge"
> Yes, I will. I was caught up with some other work.
> I will be sending a version ASAP.
>
Great, glad to know that you will be doing a re-spin!
> Ajay
Thanks a lot and best regards,
Javier
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-07-25 19:22 ` [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model Ajay Kumar
2014-07-30 11:19 ` Thierry Reding
@ 2014-09-15 17:37 ` Laurent Pinchart
2014-09-17 9:07 ` Ajay kumar
1 sibling, 1 reply; 70+ messages in thread
From: Laurent Pinchart @ 2014-09-15 17:37 UTC (permalink / raw)
To: dri-devel
Cc: Ajay Kumar, linux-samsung-soc, devicetree, seanpaul,
daniel.vetter, joshi, ajaynumb, prashanth.g, Sean Cross,
Thierry Reding
Hi Ajay,
Thank you for the patch.
I think we're moving in the right direction, but we're not there yet.
On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> This patch tries to seperate drm_bridge implementation
> into 2 parts, a drm part and a non_drm part.
>
> A set of helper functions are defined in this patch to make
> bridge driver probe independent of the drm flow.
>
> The bridge devices register themselves on a lookup table
> when they get probed by calling "drm_bridge_add_for_lookup".
>
> The parent encoder driver waits till the bridge is available in the
> lookup table(by calling "of_drm_find_bridge") and then continues with
> its initialization.
Before the introduction of the component framework I would have said this is
the way to go. Now, I think bridges should register themselves as components,
and the DRM master driver should use the component framework to get a
reference to the bridges it needs.
> The encoder driver should call "drm_bridge_attach_encoder" to pass on
> the drm_device and the encoder pointers to the bridge object.
>
> Now that the drm_device pointer is available, the encoder then calls
> "bridge->funcs->post_encoder_init" to allow the bridge to continue
> registering itself with the drm core.
This is what really bothers me with DRM bridge.
The framework assumes that a bridge will always bridge an encoder and a
connector. Beside lacking support for chained bridges, this creates an
artificial split between bridges and encoders by modeling the same components
using drm_encoder or drm_bridge depending on their position in the video
output pipeline.
I would like to see drm_bridge becoming more self-centric, removing the
awareness of the upstream encoder and downstream connector. I'll give this a
try, but it will conflict with this patch, so I'd like to share opinions and
coordinate efforts sooner than later if possible.
> Also, non driver model based ptn3460 driver is removed in this patch.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> ---
> .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 --
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/bridge/Kconfig | 12 +-
> drivers/gpu/drm/bridge/Makefile | 2 -
> drivers/gpu/drm/bridge/ptn3460.c | 343 -----------------
> drivers/gpu/drm/drm_bridge.c | 89 +++++
> drivers/gpu/drm/drm_crtc.c | 9 +-
> drivers/gpu/drm/exynos/Kconfig | 3 +-
> drivers/gpu/drm/exynos/exynos_dp_core.c | 57 ++--
> drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 3 +-
> include/drm/bridge/ptn3460.h | 37 ---
> include/drm/drm_crtc.h | 16 +-
> 13 files changed, 147 insertions(+), 453 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
> delete mode 100644 drivers/gpu/drm/bridge/ptn3460.c
> create mode 100644 drivers/gpu/drm/drm_bridge.c
> delete mode 100644 include/drm/bridge/ptn3460.h
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-09-15 17:37 ` Laurent Pinchart
@ 2014-09-17 9:07 ` Ajay kumar
2014-09-17 9:22 ` Dave Airlie
2014-09-17 9:27 ` Laurent Pinchart
0 siblings, 2 replies; 70+ messages in thread
From: Ajay kumar @ 2014-09-17 9:07 UTC (permalink / raw)
To: Laurent Pinchart, Thierry Reding, Daniel Vetter, Rob Clark
Cc: dri-devel, Ajay Kumar, linux-samsung-soc, devicetree, Sean Paul,
sunil joshi, Prashanth G, Sean Cross
Hi Laurent,
On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Ajay,
>
> Thank you for the patch.
>
> I think we're moving in the right direction, but we're not there yet.
>
> On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
>> This patch tries to seperate drm_bridge implementation
>> into 2 parts, a drm part and a non_drm part.
>>
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when they get probed by calling "drm_bridge_add_for_lookup".
>>
>> The parent encoder driver waits till the bridge is available in the
>> lookup table(by calling "of_drm_find_bridge") and then continues with
>> its initialization.
>
> Before the introduction of the component framework I would have said this is
> the way to go. Now, I think bridges should register themselves as components,
> and the DRM master driver should use the component framework to get a
> reference to the bridges it needs.
Well, I have modified the bridge framework exactly the way Thierry wanted it
to be, I mean the same way the current panel framework is.
And, I don't think there is a problem with that.
What problem are you facing with current bridge implementation?
What is the advantage of using the component framework to register bridges?
>> The encoder driver should call "drm_bridge_attach_encoder" to pass on
>> the drm_device and the encoder pointers to the bridge object.
>>
>> Now that the drm_device pointer is available, the encoder then calls
>> "bridge->funcs->post_encoder_init" to allow the bridge to continue
>> registering itself with the drm core.
>
> This is what really bothers me with DRM bridge.
>
> The framework assumes that a bridge will always bridge an encoder and a
> connector. Beside lacking support for chained bridges, this creates an
> artificial split between bridges and encoders by modeling the same components
> using drm_encoder or drm_bridge depending on their position in the video
> output pipeline.
>
> I would like to see drm_bridge becoming more self-centric, removing the
> awareness of the upstream encoder and downstream connector. I'll give this a
> try, but it will conflict with this patch, so I'd like to share opinions and
> coordinate efforts sooner than later if possible.
I am not really able to understand how you want "drm_bridge" to be.
As of now, there are many platforms using drm_bridge and they don't
have a problem with current implementation.
Regarding chained bridges: Can't you add this once my patchset is merged?
As an additional feature?
To be honest, I have spent quite sometime for working on this patchset.
All I started with was to add drm_panel support to drm_bridge.
When I sent the first patchset for that, Daniel, Rob and Thierry raised a
concern that current bridge framework itself is not proper and hence
they asked me to fix that first. And we have reached till here based on
their comments only.
Without this patchset, you cannot bring an X server
based display on snow and peach_pit. Also, day by day the number of
platforms using drm_bridge is increasing. And, I don't really see a problem
with the current approach(which is exactly the same way panel framework is).
And, I am no decision maker here. I would expect the top guys to comment!
Ajay
>> Also, non driver model based ptn3460 driver is removed in this patch.
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> ---
>> .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 --
>> drivers/gpu/drm/Makefile | 1 +
>> drivers/gpu/drm/bridge/Kconfig | 12 +-
>> drivers/gpu/drm/bridge/Makefile | 2 -
>> drivers/gpu/drm/bridge/ptn3460.c | 343 -----------------
>> drivers/gpu/drm/drm_bridge.c | 89 +++++
>> drivers/gpu/drm/drm_crtc.c | 9 +-
>> drivers/gpu/drm/exynos/Kconfig | 3 +-
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 57 ++--
>> drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
>> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 3 +-
>> include/drm/bridge/ptn3460.h | 37 ---
>> include/drm/drm_crtc.h | 16 +-
>> 13 files changed, 147 insertions(+), 453 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
>> delete mode 100644 drivers/gpu/drm/bridge/ptn3460.c
>> create mode 100644 drivers/gpu/drm/drm_bridge.c
>> delete mode 100644 include/drm/bridge/ptn3460.h
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-09-17 9:07 ` Ajay kumar
@ 2014-09-17 9:22 ` Dave Airlie
2014-09-17 9:27 ` Laurent Pinchart
1 sibling, 0 replies; 70+ messages in thread
From: Dave Airlie @ 2014-09-17 9:22 UTC (permalink / raw)
To: Ajay kumar
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Laurent Pinchart, Prashanth G,
Ajay Kumar
>>
>> Before the introduction of the component framework I would have said this is
>> the way to go. Now, I think bridges should register themselves as components,
>> and the DRM master driver should use the component framework to get a
>> reference to the bridges it needs.
> Well, I have modified the bridge framework exactly the way Thierry wanted it
> to be, I mean the same way the current panel framework is.
> And, I don't think there is a problem with that.
> What problem are you facing with current bridge implementation?
> What is the advantage of using the component framework to register bridges?
At this point I'd rather merge something that keep iterating out of
tree, if this enables current hw to work and is better than what we
have we should merge it, and if we can get interest in using the
component framework then we should look at that as a separate problem.
Dave.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-09-17 9:07 ` Ajay kumar
2014-09-17 9:22 ` Dave Airlie
@ 2014-09-17 9:27 ` Laurent Pinchart
2014-09-17 13:15 ` Ajay kumar
2014-09-22 7:40 ` Thierry Reding
1 sibling, 2 replies; 70+ messages in thread
From: Laurent Pinchart @ 2014-09-17 9:27 UTC (permalink / raw)
To: Ajay kumar
Cc: Thierry Reding, Daniel Vetter, Rob Clark, dri-devel, Ajay Kumar,
linux-samsung-soc, devicetree, Sean Paul, sunil joshi,
Prashanth G, Sean Cross
Hi Ajay,
On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
> On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
> > Hi Ajay,
> >
> > Thank you for the patch.
> >
> > I think we're moving in the right direction, but we're not there yet.
> >
> > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> >> This patch tries to seperate drm_bridge implementation
> >> into 2 parts, a drm part and a non_drm part.
> >>
> >> A set of helper functions are defined in this patch to make
> >> bridge driver probe independent of the drm flow.
> >>
> >> The bridge devices register themselves on a lookup table
> >> when they get probed by calling "drm_bridge_add_for_lookup".
> >>
> >> The parent encoder driver waits till the bridge is available in the
> >> lookup table(by calling "of_drm_find_bridge") and then continues with
> >> its initialization.
> >
> > Before the introduction of the component framework I would have said this
> > is the way to go. Now, I think bridges should register themselves as
> > components, and the DRM master driver should use the component framework
> > to get a reference to the bridges it needs.
>
> Well, I have modified the bridge framework exactly the way Thierry wanted it
> to be, I mean the same way the current panel framework is.
> And, I don't think there is a problem with that.
> What problem are you facing with current bridge implementation?
> What is the advantage of using the component framework to register bridges?
There are several advantages.
- The component framework has been designed with this exact problem in mind,
piecing multiple components into a display device. This patch set introduces
yet another framework, without any compelling reason as far as I can see.
Today DRM drivers already need to use three different frameworks (component,
I2C slave encoder and panel), and we're adding a fourth one to make the mess
even messier. This is really a headlong rush, we need to stop and fix the
design mistakes.
- The component framework solves the probe ordering problem. Bridges can use
deferred probing, but when a bridge requires a resources (such as a clock for
instance) provided by the display controller, this will break.
> >> The encoder driver should call "drm_bridge_attach_encoder" to pass on
> >> the drm_device and the encoder pointers to the bridge object.
> >>
> >> Now that the drm_device pointer is available, the encoder then calls
> >> "bridge->funcs->post_encoder_init" to allow the bridge to continue
> >> registering itself with the drm core.
> >
> > This is what really bothers me with DRM bridge.
> >
> > The framework assumes that a bridge will always bridge an encoder and a
> > connector. Beside lacking support for chained bridges, this creates an
> > artificial split between bridges and encoders by modeling the same
> > components using drm_encoder or drm_bridge depending on their position in
> > the video output pipeline.
> >
> > I would like to see drm_bridge becoming more self-centric, removing the
> > awareness of the upstream encoder and downstream connector. I'll give this
> > a try, but it will conflict with this patch, so I'd like to share
> > opinions and coordinate efforts sooner than later if possible.
>
> I am not really able to understand how you want "drm_bridge" to be.
> As of now, there are many platforms using drm_bridge and they don't
> have a problem with current implementation.
> Regarding chained bridges: Can't you add this once my patchset is merged?
> As an additional feature?
Yes, as I mentioned in another e-mail this can be fixed later. I want to start
discussing it though.
> To be honest, I have spent quite sometime for working on this patchset.
> All I started with was to add drm_panel support to drm_bridge.
> When I sent the first patchset for that, Daniel, Rob and Thierry raised a
> concern that current bridge framework itself is not proper and hence
> they asked me to fix that first. And we have reached till here based on
> their comments only.
>
> Without this patchset, you cannot bring an X server
> based display on snow and peach_pit. Also, day by day the number of
> platforms using drm_bridge is increasing.
That's exactly why I'd like to use the component framework now, as the
conversion will become more complex as time goes by.
> And, I don't really see a problem with the current approach(which is exactly
> the same way panel framework is). And, I am no decision maker here. I would
> expect the top guys to comment!
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-09-17 9:27 ` Laurent Pinchart
@ 2014-09-17 13:15 ` Ajay kumar
2014-09-22 7:40 ` Thierry Reding
1 sibling, 0 replies; 70+ messages in thread
From: Ajay kumar @ 2014-09-17 13:15 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Thierry Reding, Daniel Vetter, Rob Clark,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Ajay Kumar,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, InKi Dae, Sean Paul,
sunil joshi, Prashanth G, Sean Cross
On Wed, Sep 17, 2014 at 2:57 PM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> Hi Ajay,
>
> On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
>> On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
>> > Hi Ajay,
>> >
>> > Thank you for the patch.
>> >
>> > I think we're moving in the right direction, but we're not there yet.
>> >
>> > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
>> >> This patch tries to seperate drm_bridge implementation
>> >> into 2 parts, a drm part and a non_drm part.
>> >>
>> >> A set of helper functions are defined in this patch to make
>> >> bridge driver probe independent of the drm flow.
>> >>
>> >> The bridge devices register themselves on a lookup table
>> >> when they get probed by calling "drm_bridge_add_for_lookup".
>> >>
>> >> The parent encoder driver waits till the bridge is available in the
>> >> lookup table(by calling "of_drm_find_bridge") and then continues with
>> >> its initialization.
>> >
>> > Before the introduction of the component framework I would have said this
>> > is the way to go. Now, I think bridges should register themselves as
>> > components, and the DRM master driver should use the component framework
>> > to get a reference to the bridges it needs.
>>
>> Well, I have modified the bridge framework exactly the way Thierry wanted it
>> to be, I mean the same way the current panel framework is.
>> And, I don't think there is a problem with that.
>> What problem are you facing with current bridge implementation?
>> What is the advantage of using the component framework to register bridges?
>
> There are several advantages.
>
> - The component framework has been designed with this exact problem in mind,
> piecing multiple components into a display device. This patch set introduces
> yet another framework, without any compelling reason as far as I can see.
Without this bridge registration framework, there is no way you can pass on a
drm_device pointer to the bridge driver. That is why we added a lookup
framework.
> Today DRM drivers already need to use three different frameworks (component,
> I2C slave encoder and panel), and we're adding a fourth one to make the mess
> even messier. This is really a headlong rush, we need to stop and fix the
> design mistakes.
>
> - The component framework solves the probe ordering problem. Bridges can use
> deferred probing, but when a bridge requires a resources (such as a clock for
> instance) provided by the display controller, this will break.
This is exactly the way sti drm uses bridge I think. It uses component framework
to wait till the master device initializes and then passes on a
drm_device pointer
to the component devices. But please know that it is feasible in case of sti,
because the bridge they use must be a embedded chip on the SOC, but not a
third party device.
And, the case which you mentioned(clock instance need to be passed to
bridge driver)
happens only in the case of bridges embedded on the SOC, but not a
third party device.
So, you are always allowed to use component framework for that.
But, assume the bridge chip is a third party device(ex: ptn3460 or ps8622) which
sits on an i2c bus. In that case, your approach poses the foll problems:
The way master and components are binded varies from platform to platform.
i.e the way exynos consolidates and adds the components is very much
different the way msm/sti/armada does the same!
So, when one needs to use a third party device as a bridge, they will end up
hacking up their drm layer to support this third party device.
With my approach, only the corresponding encoder driver needs to
know about the bridge, that too just the phandle to bridge node.
The platform specific drm layer can still be unaware of the bridge and stuff.
With your approach, the way we would specify the bridge node will change
from platform to platform resulting in non-uniformity. Also, the platform
specific drm layer needs to be aware of the bridge.
And, I assume these are the reasons why drm_panel doesn't use component
framework. Because all the panels are often third party and hence can be reused
across platforms, and so are ptn3460/ps8622.
>> >> The encoder driver should call "drm_bridge_attach_encoder" to pass on
>> >> the drm_device and the encoder pointers to the bridge object.
>> >>
>> >> Now that the drm_device pointer is available, the encoder then calls
>> >> "bridge->funcs->post_encoder_init" to allow the bridge to continue
>> >> registering itself with the drm core.
>> >
>> > This is what really bothers me with DRM bridge.
>> >
>> > The framework assumes that a bridge will always bridge an encoder and a
>> > connector. Beside lacking support for chained bridges, this creates an
>> > artificial split between bridges and encoders by modeling the same
>> > components using drm_encoder or drm_bridge depending on their position in
>> > the video output pipeline.
>> >
>> > I would like to see drm_bridge becoming more self-centric, removing the
>> > awareness of the upstream encoder and downstream connector. I'll give this
>> > a try, but it will conflict with this patch, so I'd like to share
>> > opinions and coordinate efforts sooner than later if possible.
>>
>> I am not really able to understand how you want "drm_bridge" to be.
>> As of now, there are many platforms using drm_bridge and they don't
>> have a problem with current implementation.
>> Regarding chained bridges: Can't you add this once my patchset is merged?
>> As an additional feature?
>
> Yes, as I mentioned in another e-mail this can be fixed later. I want to start
> discussing it though.
>> To be honest, I have spent quite sometime for working on this patchset.
>> All I started with was to add drm_panel support to drm_bridge.
>> When I sent the first patchset for that, Daniel, Rob and Thierry raised a
>> concern that current bridge framework itself is not proper and hence
>> they asked me to fix that first. And we have reached till here based on
>> their comments only.
>>
>> Without this patchset, you cannot bring an X server
>> based display on snow and peach_pit. Also, day by day the number of
>> platforms using drm_bridge is increasing.
>
> That's exactly why I'd like to use the component framework now, as the
> conversion will become more complex as time goes by.
As I have explained above, using component framework for third
party bridges is a bad idea. And all other private bridges, already use the
component framework(ex: sti). So, ideally this point should not be a blocker
for this patchset to get in. :)
Ajay
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-09-17 9:27 ` Laurent Pinchart
2014-09-17 13:15 ` Ajay kumar
@ 2014-09-22 7:40 ` Thierry Reding
2014-09-23 0:29 ` Laurent Pinchart
1 sibling, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-09-22 7:40 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ajay kumar, Daniel Vetter, Rob Clark, dri-devel, Ajay Kumar,
linux-samsung-soc, devicetree, Sean Paul, sunil joshi,
Prashanth G, Sean Cross
[-- Attachment #1: Type: text/plain, Size: 4239 bytes --]
On Wed, Sep 17, 2014 at 12:27:13PM +0300, Laurent Pinchart wrote:
> Hi Ajay,
>
> On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
> > On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
> > > Hi Ajay,
> > >
> > > Thank you for the patch.
> > >
> > > I think we're moving in the right direction, but we're not there yet.
> > >
> > > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> > >> This patch tries to seperate drm_bridge implementation
> > >> into 2 parts, a drm part and a non_drm part.
> > >>
> > >> A set of helper functions are defined in this patch to make
> > >> bridge driver probe independent of the drm flow.
> > >>
> > >> The bridge devices register themselves on a lookup table
> > >> when they get probed by calling "drm_bridge_add_for_lookup".
> > >>
> > >> The parent encoder driver waits till the bridge is available in the
> > >> lookup table(by calling "of_drm_find_bridge") and then continues with
> > >> its initialization.
> > >
> > > Before the introduction of the component framework I would have said this
> > > is the way to go. Now, I think bridges should register themselves as
> > > components, and the DRM master driver should use the component framework
> > > to get a reference to the bridges it needs.
> >
> > Well, I have modified the bridge framework exactly the way Thierry wanted it
> > to be, I mean the same way the current panel framework is.
> > And, I don't think there is a problem with that.
> > What problem are you facing with current bridge implementation?
> > What is the advantage of using the component framework to register bridges?
>
> There are several advantages.
>
> - The component framework has been designed with this exact problem in mind,
> piecing multiple components into a display device.
No. Component framework was designed with multi-device drivers in mind.
That is, drivers that need to combine two or more platform devices into
a single logical device. Typically that includes display controllers and
encoders (in various looks) for DRM.
Panels and bridges are in my opinion different because they are outside
of the DRM driver. They aren't part of the device complex that an SoC
provides. They represent hardware that is external to the SoC and the
DRM driver and can be shared across SoCs.
Forcing panels and bridges to register as components will require all
drivers to implement master/component support solely for accessing this
external hardware.
What you're suggesting is like saying that clocks or regulators should
register as components so that their users can get them that way. In
fact by that argument everything that's referenced by phandle would need
to register as component (PHYs, LEDs, GPIOs, I2C controllers, ...).
> This patch set introduces
> yet another framework, without any compelling reason as far as I can see.
> Today DRM drivers already need to use three different frameworks (component,
> I2C slave encoder and panel), and we're adding a fourth one to make the mess
> even messier.
Panel and bridge aren't really frameworks. Rather they are a simple
registry to allow drivers to register panels and bridges and display
drivers to look them up.
> This is really a headlong rush, we need to stop and fix the design mistakes.
Can you point out specific design mistakes? I don't see any, but I'm
obviously biased.
> - The component framework solves the probe ordering problem. Bridges can use
> deferred probing, but when a bridge requires a resources (such as a clock for
> instance) provided by the display controller, this will break.
Panel and bridges can support deferred probing without the component
framework just fine.
> > Without this patchset, you cannot bring an X server
> > based display on snow and peach_pit. Also, day by day the number of
> > platforms using drm_bridge is increasing.
>
> That's exactly why I'd like to use the component framework now, as the
> conversion will become more complex as time goes by.
No it won't. If we ever do decide that component framework is a better
fit then the conversion may be more work but it would still be largely
mechanical.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-09-22 7:40 ` Thierry Reding
@ 2014-09-23 0:29 ` Laurent Pinchart
2014-09-23 5:36 ` Thierry Reding
0 siblings, 1 reply; 70+ messages in thread
From: Laurent Pinchart @ 2014-09-23 0:29 UTC (permalink / raw)
To: Thierry Reding
Cc: Ajay kumar, Daniel Vetter, Rob Clark, dri-devel, Ajay Kumar,
linux-samsung-soc, devicetree, Sean Paul, sunil joshi,
Prashanth G, Sean Cross
[-- Attachment #1: Type: text/plain, Size: 5642 bytes --]
Hi Thierry,
On Monday 22 September 2014 09:40:38 Thierry Reding wrote:
> On Wed, Sep 17, 2014 at 12:27:13PM +0300, Laurent Pinchart wrote:
> > On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
> > > On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
> > > > Hi Ajay,
> > > >
> > > > Thank you for the patch.
> > > >
> > > > I think we're moving in the right direction, but we're not there yet.
> > > >
> > > > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> > > >> This patch tries to seperate drm_bridge implementation
> > > >> into 2 parts, a drm part and a non_drm part.
> > > >>
> > > >> A set of helper functions are defined in this patch to make
> > > >> bridge driver probe independent of the drm flow.
> > > >>
> > > >> The bridge devices register themselves on a lookup table
> > > >> when they get probed by calling "drm_bridge_add_for_lookup".
> > > >>
> > > >> The parent encoder driver waits till the bridge is available in the
> > > >> lookup table(by calling "of_drm_find_bridge") and then continues with
> > > >> its initialization.
> > > >
> > > > Before the introduction of the component framework I would have said
> > > > this is the way to go. Now, I think bridges should register themselves
> > > > as components, and the DRM master driver should use the component
> > > > framework to get a reference to the bridges it needs.
> > >
> > > Well, I have modified the bridge framework exactly the way Thierry
> > > wanted it to be, I mean the same way the current panel framework is.
> > > And, I don't think there is a problem with that.
> > > What problem are you facing with current bridge implementation?
> > > What is the advantage of using the component framework to register
> > > bridges?
> >
> > There are several advantages.
> >
> > - The component framework has been designed with this exact problem in
> > mind, piecing multiple components into a display device.
>
> No. Component framework was designed with multi-device drivers in mind.
> That is, drivers that need to combine two or more platform devices into
> a single logical device. Typically that includes display controllers and
> encoders (in various looks) for DRM.
I disagree. AFAIK the component framework was designed to easily combine
multiple devices into a single logical device, regardless of which bus each
device is connected to. That's what makes the component framework useful : it
allows master drivers to build logical devices from heterogeneous components
without having to use one API per bus and/or component type. If the only goal
had been to combine platform devices on an SoC, simpler device-specific
solutions would likely have been used instead.
> Panels and bridges are in my opinion different because they are outside
> of the DRM driver. They aren't part of the device complex that an SoC
> provides. They represent hardware that is external to the SoC and the
> DRM driver and can be shared across SoCs.
They represent hardware external to the SoC, but internal to the logical DRM
device.
> Forcing panels and bridges to register as components will require all
> drivers to implement master/component support solely for accessing this
> external hardware.
>
> What you're suggesting is like saying that clocks or regulators should
> register as components so that their users can get them that way. In
> fact by that argument everything that's referenced by phandle would need
> to register as component (PHYs, LEDs, GPIOs, I2C controllers, ...).
No, that's very different. The device you list are clearly external resources,
while the bridges and panels are components part of a logical display device.
> > This patch set introduces yet another framework, without any compelling
> > reason as far as I can see. Today DRM drivers already need to use three
> > different frameworks (component, I2C slave encoder and panel), and we're
> > adding a fourth oneto make the mess even messier.
>
> Panel and bridge aren't really frameworks. Rather they are a simple
> registry to allow drivers to register panels and bridges and display
> drivers to look them up.
Regardless of how you call them, we have three interfaces.
> > This is really a headlong rush, we need to stop and fix the design
> > mistakes.
>
> Can you point out specific design mistakes? I don't see any, but I'm
> obviously biased.
The slave encoder / bridge split is what I consider a design mistake. Those
two interfaces serve the same purpose, they should really be merged.
> > - The component framework solves the probe ordering problem. Bridges can
> > use deferred probing, but when a bridge requires a resources (such as a
> > clock for instance) provided by the display controller, this will break.
>
> Panel and bridges can support deferred probing without the component
> framework just fine.
Not if the bridge requires a clock provided by the display controller, in
which case there's a dependency loop.
> > > Without this patchset, you cannot bring an X server based display on
> > > snow and peach_pit. Also, day by day the number of platforms using
> > > drm_bridge is increasing.
> >
> > That's exactly why I'd like to use the component framework now, as the
> > conversion will become more complex as time goes by.
>
> No it won't. If we ever do decide that component framework is a better
> fit then the conversion may be more work but it would still be largely
> mechanical.
Are you volunteering to perform the conversion ? :-)
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
2014-09-23 0:29 ` Laurent Pinchart
@ 2014-09-23 5:36 ` Thierry Reding
0 siblings, 0 replies; 70+ messages in thread
From: Thierry Reding @ 2014-09-23 5:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Ajay kumar, Prashanth G, Ajay Kumar
[-- Attachment #1.1: Type: text/plain, Size: 9128 bytes --]
On Tue, Sep 23, 2014 at 03:29:13AM +0300, Laurent Pinchart wrote:
> Hi Thierry,
>
> On Monday 22 September 2014 09:40:38 Thierry Reding wrote:
> > On Wed, Sep 17, 2014 at 12:27:13PM +0300, Laurent Pinchart wrote:
> > > On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
> > > > On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
> > > > > Hi Ajay,
> > > > >
> > > > > Thank you for the patch.
> > > > >
> > > > > I think we're moving in the right direction, but we're not there yet.
> > > > >
> > > > > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> > > > >> This patch tries to seperate drm_bridge implementation
> > > > >> into 2 parts, a drm part and a non_drm part.
> > > > >>
> > > > >> A set of helper functions are defined in this patch to make
> > > > >> bridge driver probe independent of the drm flow.
> > > > >>
> > > > >> The bridge devices register themselves on a lookup table
> > > > >> when they get probed by calling "drm_bridge_add_for_lookup".
> > > > >>
> > > > >> The parent encoder driver waits till the bridge is available in the
> > > > >> lookup table(by calling "of_drm_find_bridge") and then continues with
> > > > >> its initialization.
> > > > >
> > > > > Before the introduction of the component framework I would have said
> > > > > this is the way to go. Now, I think bridges should register themselves
> > > > > as components, and the DRM master driver should use the component
> > > > > framework to get a reference to the bridges it needs.
> > > >
> > > > Well, I have modified the bridge framework exactly the way Thierry
> > > > wanted it to be, I mean the same way the current panel framework is.
> > > > And, I don't think there is a problem with that.
> > > > What problem are you facing with current bridge implementation?
> > > > What is the advantage of using the component framework to register
> > > > bridges?
> > >
> > > There are several advantages.
> > >
> > > - The component framework has been designed with this exact problem in
> > > mind, piecing multiple components into a display device.
> >
> > No. Component framework was designed with multi-device drivers in mind.
> > That is, drivers that need to combine two or more platform devices into
> > a single logical device. Typically that includes display controllers and
> > encoders (in various looks) for DRM.
>
> I disagree. AFAIK the component framework was designed to easily combine
> multiple devices into a single logical device, regardless of which bus each
> device is connected to. That's what makes the component framework useful : it
> allows master drivers to build logical devices from heterogeneous components
> without having to use one API per bus and/or component type.
But this doesn't work really well once you leave the SoC. For component/
master to work you need to usually (i.e. using DT) have access to a
device tree node for each of the devices so that you can create a list
of needed devices. Once you leave the SoC, the number of combinations
that you can have becomes non-deterministic. A driver that wants to pull
this off would need to more or less manually look up phandles and
traverse from SoC via bridges to panels to find all the devices that
make up the logical device.
> If the only goal
> had been to combine platform devices on an SoC, simpler device-specific
> solutions would likely have been used instead.
I think one of the goals was to replace any of the simpler device-
specific solutions with a generic one.
But one of the issues with component/master is that it's viral. That is
it requires users to register as master themselves in order to pull in
the components. While that makes sense for on-SoC devices I think it's a
mistake to use it for external hardware like bridges and panels that can
be shared across SoCs. If we make component/master mandatory for bridges
and panels, then we also force every driver that wants to use them to
implement component/master support.
Furthermore I did try a while back to convert the Tegra DRM driver to
use component/master and couldn't make it work. When I proposed patches
to enhance the API so that it would work for Tegra I got silence on one
side and "just keep using what you currently have" on the other side. So
in other words since I can't use component/master on Tegra it means that
whatever driver gets added that registers a component can't be used on
Tegra either.
> > Panels and bridges are in my opinion different because they are outside
> > of the DRM driver. They aren't part of the device complex that an SoC
> > provides. They represent hardware that is external to the SoC and the
> > DRM driver and can be shared across SoCs.
>
> They represent hardware external to the SoC, but internal to the logical DRM
> device.
That depends largely on how you look at it. From my point of view the
logical DRM device stops at the connector (well I think it actually
stops somewhat earlier already, with connector only being the handle
through which the outputs are configured).
Panels are, at least theoretically, hotpluggable. That is, if you have a
device that has both a panel and HDMI but you never use HDMI, then you
should be able to just unload the panel driver but keep the DRM device
running for HDMI. If you use component/master that's impossible because
as soon as the panel component goes away the complete DRM device goes
away.
> > Forcing panels and bridges to register as components will require all
> > drivers to implement master/component support solely for accessing this
> > external hardware.
> >
> > What you're suggesting is like saying that clocks or regulators should
> > register as components so that their users can get them that way. In
> > fact by that argument everything that's referenced by phandle would need
> > to register as component (PHYs, LEDs, GPIOs, I2C controllers, ...).
>
> No, that's very different. The device you list are clearly external resources,
> while the bridges and panels are components part of a logical display device.
Like I said above, I consider bridges and panels external resources,
too. I can easily imagine (actually I don't have to because it was
recently discussed for a project) setups where some board defines a
standard header that display modules can be connected to and hence
whatever bridges or panels are attached can change at runtime.
> > > This patch set introduces yet another framework, without any compelling
> > > reason as far as I can see. Today DRM drivers already need to use three
> > > different frameworks (component, I2C slave encoder and panel), and we're
> > > adding a fourth oneto make the mess even messier.
> >
> > Panel and bridge aren't really frameworks. Rather they are a simple
> > registry to allow drivers to register panels and bridges and display
> > drivers to look them up.
>
> Regardless of how you call them, we have three interfaces.
We need an interface to control the bridges and panels anyway. component
and master only gives you a generic way to handle the registration and
initialization.
Adding a drm_*_lookup() function to the interface to retrieve a resource
isn't as bloated as you make it out to be. Implementing component/master
is much more complicated for (in this case) too little advantage.
> > > This is really a headlong rush, we need to stop and fix the design
> > > mistakes.
> >
> > Can you point out specific design mistakes? I don't see any, but I'm
> > obviously biased.
>
> The slave encoder / bridge split is what I consider a design mistake. Those
> two interfaces serve the same purpose, they should really be merged.
Agreed.
> > > - The component framework solves the probe ordering problem. Bridges can
> > > use deferred probing, but when a bridge requires a resources (such as a
> > > clock for instance) provided by the display controller, this will break.
> >
> > Panel and bridges can support deferred probing without the component
> > framework just fine.
>
> Not if the bridge requires a clock provided by the display controller, in
> which case there's a dependency loop.
I don't see how component/master would solve that differently than the
current proposal for DRM bridge (or the existing DRM panel for that
matter).
> > > > Without this patchset, you cannot bring an X server based display on
> > > > snow and peach_pit. Also, day by day the number of platforms using
> > > > drm_bridge is increasing.
> > >
> > > That's exactly why I'd like to use the component framework now, as the
> > > conversion will become more complex as time goes by.
> >
> > No it won't. If we ever do decide that component framework is a better
> > fit then the conversion may be more work but it would still be largely
> > mechanical.
>
> Are you volunteering to perform the conversion ? :-)
No. I'm still convinced that we won't need it. Less work for everyone.
=)
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
` (5 preceding siblings ...)
2014-07-25 19:22 ` [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model Ajay Kumar
@ 2014-07-25 19:22 ` Ajay Kumar
2014-07-30 12:05 ` Thierry Reding
2014-07-25 19:22 ` [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge Ajay Kumar
` (2 subsequent siblings)
9 siblings, 1 reply; 70+ messages in thread
From: Ajay Kumar @ 2014-07-25 19:22 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g, Sean Paul, Ajay Kumar
From: Sean Paul <seanpaul@chromium.org>
This patch adds ptn3460 as module_i2c_driver.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
.../devicetree/bindings/video/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 2 +
drivers/gpu/drm/bridge/ptn3460.c | 405 ++++++++++++++++++++
4 files changed, 444 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
diff --git a/Documentation/devicetree/bindings/video/bridge/ptn3460.txt b/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
new file mode 100644
index 0000000..03366c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460 bridge bindings
+
+Required properties:
+ - compatible: "nxp,ptn3460"
+ - reg: i2c address of the bridge
+ - powerdown-gpios: OF device-tree gpio specification
+ - reset-gpios: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +-------+------------+------------------+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +-------+------------+------------------+
+
+Example:
+ lvds-bridge@20 {
+ compatible = "nxp,ptn3460";
+ reg = <0x20>;
+ powerdown-gpios = <&gpy2 5 1 0 0>;
+ reset-gpios = <&gpx1 5 1 0 0>;
+ edid-emulation = <5>;
+ };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 1e2f96c..0b12d16 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -6,4 +6,14 @@ config DRM_BRIDGE
menu "bridge chips"
depends on DRM_BRIDGE
+
+config DRM_PTN3460
+ tristate "NXP ptn3460 eDP/LVDS bridge"
+ depends on DRM && DRM_BRIDGE
+ depends on OF
+ depends on I2C
+ select DRM_PANEL
+ help
+ ptn3460 eDP-LVDS bridge chip driver.
+
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index be16eca..b4733e1 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1 +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 0000000..f41302a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,405 @@
+/*
+ * 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 <drm/drm_panel.h>
+
+#include "drmP.h"
+#include "drm_edid.h"
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+
+#define PTN3460_EDID_ADDR 0x0
+#define PTN3460_EDID_EMULATION_ADDR 0x84
+#define PTN3460_EDID_ENABLE_EMULATION 0
+#define PTN3460_EDID_EMULATION_SELECTION 1
+#define PTN3460_EDID_SRAM_LOAD_ADDR 0x85
+
+struct ptn3460_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+ struct drm_bridge *bridge;
+ struct drm_panel *panel;
+ struct edid *edid;
+ struct gpio_desc *gpio_pd_n;
+ struct gpio_desc *gpio_rst_n;
+ u32 edid_emulation;
+ bool enabled;
+};
+
+static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
+ u8 *buf, int len)
+{
+ int ret;
+
+ ret = i2c_master_send(ptn_bridge->client, &addr, 1);
+ if (ret <= 0) {
+ DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
+ return ret;
+ }
+
+ ret = i2c_master_recv(ptn_bridge->client, buf, len);
+ if (ret <= 0) {
+ DRM_ERROR("Failed to recv i2c data, ret=%d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ptn3460_write_byte(struct ptn3460_bridge *ptn_bridge, char addr,
+ char val)
+{
+ int ret;
+ char buf[2];
+
+ buf[0] = addr;
+ buf[1] = val;
+
+ ret = i2c_master_send(ptn_bridge->client, buf, ARRAY_SIZE(buf));
+ if (ret <= 0) {
+ DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ptn3460_select_edid(struct ptn3460_bridge *ptn_bridge)
+{
+ int ret;
+ char val;
+
+ /* Load the selected edid into SRAM (accessed at PTN3460_EDID_ADDR) */
+ ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_SRAM_LOAD_ADDR,
+ ptn_bridge->edid_emulation);
+ if (ret) {
+ DRM_ERROR("Failed to transfer edid to sram, ret=%d\n", ret);
+ return ret;
+ }
+
+ /* Enable EDID emulation and select the desired EDID */
+ val = 1 << PTN3460_EDID_ENABLE_EMULATION |
+ ptn_bridge->edid_emulation << PTN3460_EDID_EMULATION_SELECTION;
+
+ ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_EMULATION_ADDR, val);
+ if (ret) {
+ DRM_ERROR("Failed to write edid value, ret=%d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void ptn3460_pre_enable(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
+ int ret;
+
+ if (ptn_bridge->enabled)
+ return;
+
+ gpiod_set_value(ptn_bridge->gpio_pd_n, 1);
+
+ gpiod_set_value(ptn_bridge->gpio_rst_n, 0);
+ udelay(10);
+ gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
+
+ drm_panel_prepare(ptn_bridge->panel);
+
+ /*
+ * There's a bug in the PTN chip where it falsely asserts hotplug before
+ * it is fully functional. We're forced to wait for the maximum start up
+ * time specified in the chip's datasheet to make sure we're really up.
+ */
+ msleep(90);
+
+ ret = ptn3460_select_edid(ptn_bridge);
+ if (ret)
+ DRM_ERROR("Select edid failed ret=%d\n", ret);
+
+ ptn_bridge->enabled = true;
+}
+
+static void ptn3460_enable(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
+
+ drm_panel_enable(ptn_bridge->panel);
+}
+
+static void ptn3460_disable(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
+
+ if (!ptn_bridge->enabled)
+ return;
+
+ ptn_bridge->enabled = false;
+
+ drm_panel_disable(ptn_bridge->panel);
+
+ gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
+ gpiod_set_value(ptn_bridge->gpio_pd_n, 0);
+}
+
+static void ptn3460_post_disable(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
+
+ drm_panel_unprepare(ptn_bridge->panel);
+}
+
+void ptn3460_bridge_destroy(struct drm_bridge *bridge)
+{
+ drm_bridge_cleanup(bridge);
+}
+
+int ptn3460_get_modes(struct drm_connector *connector)
+{
+ struct ptn3460_bridge *ptn_bridge;
+ u8 *edid;
+ int ret, num_modes;
+ bool power_off;
+
+ ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
+
+ if (ptn_bridge->edid)
+ return drm_add_edid_modes(connector, ptn_bridge->edid);
+
+ power_off = !ptn_bridge->enabled;
+ ptn3460_pre_enable(ptn_bridge->bridge);
+
+ edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
+ if (!edid) {
+ DRM_ERROR("Failed to allocate edid\n");
+ return 0;
+ }
+
+ ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
+ EDID_LENGTH);
+ if (ret) {
+ kfree(edid);
+ num_modes = 0;
+ goto out;
+ }
+
+ ptn_bridge->edid = (struct edid *)edid;
+ drm_mode_connector_update_edid_property(connector, ptn_bridge->edid);
+
+ num_modes = drm_add_edid_modes(connector, ptn_bridge->edid);
+
+out:
+ if (power_off)
+ ptn3460_disable(ptn_bridge->bridge);
+
+ return num_modes;
+}
+
+struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
+{
+ struct ptn3460_bridge *ptn_bridge;
+
+ ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
+
+ return ptn_bridge->bridge->encoder;
+}
+
+struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
+ .get_modes = ptn3460_get_modes,
+ .best_encoder = ptn3460_best_encoder,
+};
+
+enum drm_connector_status ptn3460_detect(struct drm_connector *connector,
+ bool force)
+{
+ return connector_status_connected;
+}
+
+void ptn3460_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_cleanup(connector);
+}
+
+struct drm_connector_funcs ptn3460_connector_funcs = {
+ .dpms = drm_helper_connector_dpms,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = ptn3460_detect,
+ .destroy = ptn3460_connector_destroy,
+};
+
+int ptn3460_post_encoder_init(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
+ int ret;
+
+ /* bridge is attached to encoder.
+ * safe to remove it from the bridge_lookup table.
+ */
+ drm_bridge_remove_from_lookup(bridge);
+
+ ret = drm_bridge_init(bridge->drm_dev, bridge);
+ if (ret) {
+ DRM_ERROR("Failed to initialize bridge with drm\n");
+ return ret;
+ }
+
+ /* connector implementation */
+ ptn_bridge->connector.polled = bridge->connector_polled;
+
+ ret = drm_connector_init(bridge->drm_dev, &ptn_bridge->connector,
+ &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector with drm\n");
+ return ret;
+ }
+ drm_connector_helper_add(&ptn_bridge->connector,
+ &ptn3460_connector_helper_funcs);
+ drm_connector_register(&ptn_bridge->connector);
+ drm_mode_connector_attach_encoder(&ptn_bridge->connector,
+ bridge->encoder);
+
+ if (ptn_bridge->panel)
+ drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
+
+ return ret;
+}
+
+struct drm_bridge_funcs ptn3460_bridge_funcs = {
+ .post_encoder_init = ptn3460_post_encoder_init,
+ .pre_enable = ptn3460_pre_enable,
+ .enable = ptn3460_enable,
+ .disable = ptn3460_disable,
+ .post_disable = ptn3460_post_disable,
+ .destroy = ptn3460_bridge_destroy,
+};
+
+static int ptn3460_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = &(client->dev);
+ struct device_node *panel_node;
+ struct drm_bridge *bridge;
+ struct ptn3460_bridge *ptn_bridge;
+ int ret;
+
+ bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
+ if (!bridge) {
+ DRM_ERROR("Failed to allocate drm bridge\n");
+ return -ENOMEM;
+ }
+
+ ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
+ if (!ptn_bridge) {
+ DRM_ERROR("Failed to allocate ptn bridge\n");
+ return -ENOMEM;
+ }
+
+ panel_node = of_parse_phandle(dev->of_node, "panel", 0);
+ if (panel_node) {
+ ptn_bridge->panel = of_drm_find_panel(panel_node);
+ of_node_put(panel_node);
+ if (!ptn_bridge->panel)
+ return -EPROBE_DEFER;
+ }
+
+ bridge->dev = dev;
+ bridge->driver_private = ptn_bridge;
+ bridge->funcs = &ptn3460_bridge_funcs;
+
+ ptn_bridge->client = client;
+ ptn_bridge->bridge = bridge;
+
+ ptn_bridge->gpio_pd_n = devm_gpiod_get(&client->dev, "powerdown");
+ if (IS_ERR(ptn_bridge->gpio_pd_n)) {
+ ret = PTR_ERR(ptn_bridge->gpio_pd_n);
+ DRM_ERROR("cannot get gpio_pd_n %d\n", ret);
+ return ret;
+ } else {
+ ret = gpiod_direction_output(ptn_bridge->gpio_pd_n, 1);
+ if (ret) {
+ DRM_ERROR("cannot configure gpio_pd_n\n");
+ return ret;
+ }
+ }
+
+ ptn_bridge->gpio_rst_n = devm_gpiod_get(&client->dev, "reset");
+ if (IS_ERR(ptn_bridge->gpio_rst_n)) {
+ ret = PTR_ERR(ptn_bridge->gpio_rst_n);
+ DRM_ERROR("cannot get gpio_rst_n %d\n", ret);
+ return ret;
+ } else {
+ /*
+ * Request the reset pin low to avoid the bridge being
+ * initialized prematurely
+ */
+ ret = gpiod_direction_output(ptn_bridge->gpio_rst_n, 0);
+ if (ret) {
+ DRM_ERROR("cannot configure gpio_pd_n\n");
+ return ret;
+ }
+ }
+
+ ret = of_property_read_u32(dev->of_node, "edid-emulation",
+ &ptn_bridge->edid_emulation);
+ if (ret) {
+ DRM_ERROR("Can't read edid emulation value\n");
+ return -ENODEV;
+ }
+
+ i2c_set_clientdata(client, ptn_bridge);
+
+ drm_bridge_add_for_lookup(bridge);
+
+ return 0;
+}
+
+static int ptn3460_remove(struct i2c_client *client)
+{
+ return 0;
+}
+
+static const struct i2c_device_id ptn3460_i2c_table[] = {
+ {"nxp,ptn3460", 0},
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, ptn3460_i2c_table);
+
+static const struct of_device_id ptn3460_match[] = {
+ { .compatible = "nxp,ptn3460" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ptn3460_match);
+
+struct i2c_driver ptn3460_driver = {
+ .id_table = ptn3460_i2c_table,
+ .probe = ptn3460_probe,
+ .remove = ptn3460_remove,
+ .driver = {
+ .name = "nxp,ptn3460",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ptn3460_match),
+ },
+};
+module_i2c_driver(ptn3460_driver);
+
+MODULE_AUTHOR("Sean Paul <seanpaul@chromium.org>");
+MODULE_DESCRIPTION("NXP ptn3460 eDP-LVDS converter driver");
+MODULE_LICENSE("GPL");
--
1.7.9.5
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
2014-07-25 19:22 ` [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge Ajay Kumar
@ 2014-07-30 12:05 ` Thierry Reding
2014-07-30 15:16 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 12:05 UTC (permalink / raw)
To: Ajay Kumar
Cc: devicetree, linux-samsung-soc, seanpaul, daniel.vetter, joshi,
dri-devel, ajaynumb, prashanth.g
[-- Attachment #1.1: Type: text/plain, Size: 11401 bytes --]
On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
[...]
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 1e2f96c..0b12d16 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -6,4 +6,14 @@ config DRM_BRIDGE
>
> menu "bridge chips"
> depends on DRM_BRIDGE
> +
> +config DRM_PTN3460
> + tristate "NXP ptn3460 eDP/LVDS bridge"
> + depends on DRM && DRM_BRIDGE
I don't think you need these two dependencies any longer since they are
implicit in the "bridge chips" menu.
> diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
[...]
> +#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 <drm/drm_panel.h>
These should be ordered alphabetically, but they are already this way in
the original driver, so the reordering can be a separate patch.
> +struct ptn3460_bridge {
> + struct drm_connector connector;
> + struct i2c_client *client;
> + struct drm_bridge *bridge;
I think it would be much more natural for ptn3460_bridge to embed struct
drm_bridge rather than store a pointer to it.
> + struct drm_panel *panel;
> + struct edid *edid;
> + struct gpio_desc *gpio_pd_n;
> + struct gpio_desc *gpio_rst_n;
> + u32 edid_emulation;
> + bool enabled;
> +};
> +
> +static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
> + u8 *buf, int len)
> +{
> + int ret;
> +
> + ret = i2c_master_send(ptn_bridge->client, &addr, 1);
> + if (ret <= 0) {
> + DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
> + return ret;
> + }
> +
> + ret = i2c_master_recv(ptn_bridge->client, buf, len);
> + if (ret <= 0) {
> + DRM_ERROR("Failed to recv i2c data, ret=%d\n", ret);
> + return ret;
> + }
This isn't introduced by this patch, but doesn't this require locking so
that this is an atomic transaction?
Perhaps it could be rewritten using i2c_smbus_read_block_data()?
> +static int ptn3460_write_byte(struct ptn3460_bridge *ptn_bridge, char addr,
> + char val)
> +{
> + int ret;
> + char buf[2];
> +
> + buf[0] = addr;
> + buf[1] = val;
> +
> + ret = i2c_master_send(ptn_bridge->client, buf, ARRAY_SIZE(buf));
> + if (ret <= 0) {
> + DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
Same here, this looks like it could be i2c_smbus_write_byte_data().
> +static int ptn3460_select_edid(struct ptn3460_bridge *ptn_bridge)
> +{
> + int ret;
> + char val;
> +
> + /* Load the selected edid into SRAM (accessed at PTN3460_EDID_ADDR) */
> + ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_SRAM_LOAD_ADDR,
> + ptn_bridge->edid_emulation);
> + if (ret) {
> + DRM_ERROR("Failed to transfer edid to sram, ret=%d\n", ret);
> + return ret;
> + }
> +
> + /* Enable EDID emulation and select the desired EDID */
> + val = 1 << PTN3460_EDID_ENABLE_EMULATION |
> + ptn_bridge->edid_emulation << PTN3460_EDID_EMULATION_SELECTION;
> +
> + ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_EMULATION_ADDR, val);
> + if (ret) {
> + DRM_ERROR("Failed to write edid value, ret=%d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
s/edid/EDID/ in the above (and below, too), but again the original
driver had this, so it can be a separate patch.
> +static void ptn3460_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
If you embed drm_bridge within ptn3460_bridge then you can use the much
more canonical container_of() macro (or rather a driver-specific inline
function that wraps it) and no longer need the drm_bridge.driver_private
field.
> + int ret;
> +
> + if (ptn_bridge->enabled)
> + return;
> +
> + gpiod_set_value(ptn_bridge->gpio_pd_n, 1);
> +
> + gpiod_set_value(ptn_bridge->gpio_rst_n, 0);
> + udelay(10);
This shouldn't be using udelay(), usleep_range(10, 20) (or similar)
would be better. Again, can be a separate patch.
> + gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
It also seems like you've converted to using the gpiod_*() API, but the
driver previously used gpio_is_valid() to check that both PD and RST
pins had valid GPIOs associated with them. The device tree binding said
that they are required, though.
So this patch actually does the right thing by making them non-optional
but it also changes behaviour from the original. Like I said earlier, I
would very much prefer that this conversion be split into separate
patches rather than one patch that removes the old driver and a second
patch that adds a new one. It makes it really difficult to tell what's
really changing, breaks bisectability and generally makes our lives
miserable.
> +
> + drm_panel_prepare(ptn_bridge->panel);
This should check for errors.
> +static void ptn3460_enable(struct drm_bridge *bridge)
> +{
> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> +
> + drm_panel_enable(ptn_bridge->panel);
Should check for errors as well.
> +int ptn3460_get_modes(struct drm_connector *connector)
static? There seem to be quite a few functions that can be locally
scoped. Again, this seems to be the case in the original driver as
but it should definitely be fixed at some point.
> +{
> + struct ptn3460_bridge *ptn_bridge;
> + u8 *edid;
> + int ret, num_modes;
> + bool power_off;
> +
> + ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
> +
> + if (ptn_bridge->edid)
> + return drm_add_edid_modes(connector, ptn_bridge->edid);
> +
> + power_off = !ptn_bridge->enabled;
> + ptn3460_pre_enable(ptn_bridge->bridge);
> +
> + edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
> + if (!edid) {
> + DRM_ERROR("Failed to allocate edid\n");
> + return 0;
> + }
> +
> + ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
> + EDID_LENGTH);
> + if (ret) {
> + kfree(edid);
> + num_modes = 0;
Maybe instead of doing this here you can initialize the variable when
you declare it? It's always been that way, so can be a separate patch,
too.
> +struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
> +{
> + struct ptn3460_bridge *ptn_bridge;
> +
> + ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
You use this long construct a couple of times, so it's useful to
introduce a helper, such as this:
static inline struct ptn3460_bridge *
connector_to_ptn3460(struct drm_connector *connector)
{
return container_of(connector, struct ptn3460_bridge, connector);
}
> +int ptn3460_post_encoder_init(struct drm_bridge *bridge)
> +{
> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> + int ret;
> +
> + /* bridge is attached to encoder.
> + * safe to remove it from the bridge_lookup table.
> + */
> + drm_bridge_remove_from_lookup(bridge);
No, you should never do this. First, you're not adding it back to the
registry when the bridge is detached, so unloading and reloading the
display driver will fail. Second there should never be a need to remove
it from the registry as long as the driver itself is loaded. If you're
concerned about a single bridge being used multiple times, there's
already code to handle that in your previous patch:
int drm_bridge_attach_encoder(...)
{
...
if (bridge->encoder)
return -EBUSY;
...
}
Generally the registry should contain a list of bridges that have been
registered, whether they're used or not is irrelevant.
> + ret = drm_bridge_init(bridge->drm_dev, bridge);
> + if (ret) {
> + DRM_ERROR("Failed to initialize bridge with drm\n");
> + return ret;
> + }
> +
> + /* connector implementation */
> + ptn_bridge->connector.polled = bridge->connector_polled;
Why does this need to be handed from bridge to connector? You implement
both the connector and the bridge in this driver, so can't you directly
set ptn_bridge->connector.polled as appropriate?
> + ret = drm_connector_init(bridge->drm_dev, &ptn_bridge->connector,
> + &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
> + if (ret) {
> + DRM_ERROR("Failed to initialize connector with drm\n");
> + return ret;
> + }
> + drm_connector_helper_add(&ptn_bridge->connector,
> + &ptn3460_connector_helper_funcs);
> + drm_connector_register(&ptn_bridge->connector);
> + drm_mode_connector_attach_encoder(&ptn_bridge->connector,
> + bridge->encoder);
> +
> + if (ptn_bridge->panel)
> + drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
> +
> + return ret;
> +}
I'm thinking that eventually we'll want to register the connector only
when a panel is attached to the bridge. This will only become important
when we implement bridge chaining because if you instantiate a connector
for each bridge then you'll get a list of connectors for the DRM device
representing the output of each bridge rather than just the final one
that goes to the display.
> +static int ptn3460_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &(client->dev);
No need for the parentheses here.
> + struct device_node *panel_node;
> + struct drm_bridge *bridge;
> + struct ptn3460_bridge *ptn_bridge;
> + int ret;
> +
> + bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
> + if (!bridge) {
> + DRM_ERROR("Failed to allocate drm bridge\n");
> + return -ENOMEM;
> + }
> +
> + ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
> + if (!ptn_bridge) {
> + DRM_ERROR("Failed to allocate ptn bridge\n");
> + return -ENOMEM;
> + }
No need for error messages on allocation failures. The allocator will
already complain itself.
Also I think it's usually better to use the dev_*() functions to print
messages, especially given that at this stage we're not even hooked up
to DRM in the first place.
So in general I try to use DRM_*() functions only from DRM-specific
callbacks (or functions called from them) and dev_*() otherwise.
> +static int ptn3460_remove(struct i2c_client *client)
> +{
> + return 0;
> +}
This function should remove the bridge from the lookup table by calling
drm_bridge_remove().
> +
> +static const struct i2c_device_id ptn3460_i2c_table[] = {
> + {"nxp,ptn3460", 0},
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, ptn3460_i2c_table);
> +
> +static const struct of_device_id ptn3460_match[] = {
> + { .compatible = "nxp,ptn3460" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ptn3460_match);
> +
> +struct i2c_driver ptn3460_driver = {
Is there a reason why this can't be static?
> + .id_table = ptn3460_i2c_table,
> + .probe = ptn3460_probe,
> + .remove = ptn3460_remove,
> + .driver = {
> + .name = "nxp,ptn3460",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(ptn3460_match),
You don't need of_match_ptr() here since you already depend on OF in
Kconfig, therefore of_match_ptr(x) will always evaluate to x.
> + },
> +};
> +module_i2c_driver(ptn3460_driver);
> +
> +MODULE_AUTHOR("Sean Paul <seanpaul@chromium.org>");
> +MODULE_DESCRIPTION("NXP ptn3460 eDP-LVDS converter driver");
> +MODULE_LICENSE("GPL");
This should be "GPL v2".
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
2014-07-30 12:05 ` Thierry Reding
@ 2014-07-30 15:16 ` Ajay kumar
2014-07-30 15:40 ` Thierry Reding
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 15:16 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
> [...]
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 1e2f96c..0b12d16 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -6,4 +6,14 @@ config DRM_BRIDGE
>>
>> menu "bridge chips"
>> depends on DRM_BRIDGE
>> +
>> +config DRM_PTN3460
>> + tristate "NXP ptn3460 eDP/LVDS bridge"
>> + depends on DRM && DRM_BRIDGE
>
> I don't think you need these two dependencies any longer since they are
> implicit in the "bridge chips" menu.
Ok.
>> diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
> [...]
>> +#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 <drm/drm_panel.h>
>
> These should be ordered alphabetically, but they are already this way in
> the original driver, so the reordering can be a separate patch.
This can be done later.
>> +struct ptn3460_bridge {
>> + struct drm_connector connector;
>> + struct i2c_client *client;
>> + struct drm_bridge *bridge;
>
> I think it would be much more natural for ptn3460_bridge to embed struct
> drm_bridge rather than store a pointer to it.
Right. As you said, we can eliminate driver_private and use container_of.
>> + struct drm_panel *panel;
>> + struct edid *edid;
>> + struct gpio_desc *gpio_pd_n;
>> + struct gpio_desc *gpio_rst_n;
>> + u32 edid_emulation;
>> + bool enabled;
>> +};
>> +
>> +static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
>> + u8 *buf, int len)
>> +{
>> + int ret;
>> +
>> + ret = i2c_master_send(ptn_bridge->client, &addr, 1);
>> + if (ret <= 0) {
>> + DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = i2c_master_recv(ptn_bridge->client, buf, len);
>> + if (ret <= 0) {
>> + DRM_ERROR("Failed to recv i2c data, ret=%d\n", ret);
>> + return ret;
>> + }
>
> This isn't introduced by this patch, but doesn't this require locking so
> that this is an atomic transaction?
>
> Perhaps it could be rewritten using i2c_smbus_read_block_data()?
Well, I am not quite aware of i2c functions. I will have a look into it though.
>> +static int ptn3460_write_byte(struct ptn3460_bridge *ptn_bridge, char addr,
>> + char val)
>> +{
>> + int ret;
>> + char buf[2];
>> +
>> + buf[0] = addr;
>> + buf[1] = val;
>> +
>> + ret = i2c_master_send(ptn_bridge->client, buf, ARRAY_SIZE(buf));
>> + if (ret <= 0) {
>> + DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>
> Same here, this looks like it could be i2c_smbus_write_byte_data().
>
>> +static int ptn3460_select_edid(struct ptn3460_bridge *ptn_bridge)
>> +{
>> + int ret;
>> + char val;
>> +
>> + /* Load the selected edid into SRAM (accessed at PTN3460_EDID_ADDR) */
>> + ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_SRAM_LOAD_ADDR,
>> + ptn_bridge->edid_emulation);
>> + if (ret) {
>> + DRM_ERROR("Failed to transfer edid to sram, ret=%d\n", ret);
>> + return ret;
>> + }
>> +
>> + /* Enable EDID emulation and select the desired EDID */
>> + val = 1 << PTN3460_EDID_ENABLE_EMULATION |
>> + ptn_bridge->edid_emulation << PTN3460_EDID_EMULATION_SELECTION;
>> +
>> + ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_EMULATION_ADDR, val);
>> + if (ret) {
>> + DRM_ERROR("Failed to write edid value, ret=%d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>
> s/edid/EDID/ in the above (and below, too), but again the original
> driver had this, so it can be a separate patch.
This can be done later.
>> +static void ptn3460_pre_enable(struct drm_bridge *bridge)
>> +{
>> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
>
> If you embed drm_bridge within ptn3460_bridge then you can use the much
> more canonical container_of() macro (or rather a driver-specific inline
> function that wraps it) and no longer need the drm_bridge.driver_private
> field.
Agreed.
>> + int ret;
>> +
>> + if (ptn_bridge->enabled)
>> + return;
>> +
>> + gpiod_set_value(ptn_bridge->gpio_pd_n, 1);
>> +
>> + gpiod_set_value(ptn_bridge->gpio_rst_n, 0);
>> + udelay(10);
>
> This shouldn't be using udelay(), usleep_range(10, 20) (or similar)
> would be better. Again, can be a separate patch.
>
>> + gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
>
> It also seems like you've converted to using the gpiod_*() API, but the
> driver previously used gpio_is_valid() to check that both PD and RST
> pins had valid GPIOs associated with them. The device tree binding said
> that they are required, though.
>
> So this patch actually does the right thing by making them non-optional
> but it also changes behaviour from the original. Like I said earlier, I
> would very much prefer that this conversion be split into separate
> patches rather than one patch that removes the old driver and a second
> patch that adds a new one. It makes it really difficult to tell what's
> really changing, breaks bisectability and generally makes our lives
> miserable.
Ok. I will add these as incremental changes.
>> +
>> + drm_panel_prepare(ptn_bridge->panel);
>
> This should check for errors.
Ok.
>> +static void ptn3460_enable(struct drm_bridge *bridge)
>> +{
>> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
>> +
>> + drm_panel_enable(ptn_bridge->panel);
>
> Should check for errors as well.
Ok.
>> +int ptn3460_get_modes(struct drm_connector *connector)
>
> static? There seem to be quite a few functions that can be locally
> scoped. Again, this seems to be the case in the original driver as
> but it should definitely be fixed at some point.
Ok.
>> +{
>> + struct ptn3460_bridge *ptn_bridge;
>> + u8 *edid;
>> + int ret, num_modes;
>> + bool power_off;
>> +
>> + ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
>> +
>> + if (ptn_bridge->edid)
>> + return drm_add_edid_modes(connector, ptn_bridge->edid);
>> +
>> + power_off = !ptn_bridge->enabled;
>> + ptn3460_pre_enable(ptn_bridge->bridge);
>> +
>> + edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
>> + if (!edid) {
>> + DRM_ERROR("Failed to allocate edid\n");
>> + return 0;
>> + }
>> +
>> + ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
>> + EDID_LENGTH);
>> + if (ret) {
>> + kfree(edid);
>> + num_modes = 0;
>
> Maybe instead of doing this here you can initialize the variable when
> you declare it? It's always been that way, so can be a separate patch,
> too.
Ok.
>> +struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
>> +{
>> + struct ptn3460_bridge *ptn_bridge;
>> +
>> + ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
>
> You use this long construct a couple of times, so it's useful to
> introduce a helper, such as this:
>
> static inline struct ptn3460_bridge *
> connector_to_ptn3460(struct drm_connector *connector)
> {
> return container_of(connector, struct ptn3460_bridge, connector);
> }
Ok, will use this.
>> +int ptn3460_post_encoder_init(struct drm_bridge *bridge)
>> +{
>> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
>> + int ret;
>> +
>> + /* bridge is attached to encoder.
>> + * safe to remove it from the bridge_lookup table.
>> + */
>> + drm_bridge_remove_from_lookup(bridge);
>
> No, you should never do this. First, you're not adding it back to the
> registry when the bridge is detached, so unloading and reloading the
> display driver will fail. Second there should never be a need to remove
> it from the registry as long as the driver itself is loaded. If you're
> concerned about a single bridge being used multiple times, there's
> already code to handle that in your previous patch:
>
> int drm_bridge_attach_encoder(...)
> {
> ...
>
> if (bridge->encoder)
> return -EBUSY;
>
> ...
> }
>
> Generally the registry should contain a list of bridges that have been
> registered, whether they're used or not is irrelevant.
I was just wondering if it is ok to have a node in two independent lists?
bridge_lookup_table and the other mode_config.bridge_list?
>> + ret = drm_bridge_init(bridge->drm_dev, bridge);
>> + if (ret) {
>> + DRM_ERROR("Failed to initialize bridge with drm\n");
>> + return ret;
>> + }
>> +
>> + /* connector implementation */
>> + ptn_bridge->connector.polled = bridge->connector_polled;
>
> Why does this need to be handed from bridge to connector? You implement
> both the connector and the bridge in this driver, so can't you directly
> set ptn_bridge->connector.polled as appropriate?
As explained for the previous patch, how to choose the polled flag?
>> + ret = drm_connector_init(bridge->drm_dev, &ptn_bridge->connector,
>> + &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
>> + if (ret) {
>> + DRM_ERROR("Failed to initialize connector with drm\n");
>> + return ret;
>> + }
>> + drm_connector_helper_add(&ptn_bridge->connector,
>> + &ptn3460_connector_helper_funcs);
>> + drm_connector_register(&ptn_bridge->connector);
>> + drm_mode_connector_attach_encoder(&ptn_bridge->connector,
>> + bridge->encoder);
>> +
>> + if (ptn_bridge->panel)
>> + drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
>> +
>> + return ret;
>> +}
>
> I'm thinking that eventually we'll want to register the connector only
> when a panel is attached to the bridge. This will only become important
> when we implement bridge chaining because if you instantiate a connector
> for each bridge then you'll get a list of connectors for the DRM device
> representing the output of each bridge rather than just the final one
> that goes to the display.
So, do not initialize connector if there is no panel? and, get_modes
via panel instead of doing it by edid-emulation?
>> +static int ptn3460_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + struct device *dev = &(client->dev);
>
> No need for the parentheses here.
Ok.
>> + struct device_node *panel_node;
>> + struct drm_bridge *bridge;
>> + struct ptn3460_bridge *ptn_bridge;
>> + int ret;
>> +
>> + bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
>> + if (!bridge) {
>> + DRM_ERROR("Failed to allocate drm bridge\n");
>> + return -ENOMEM;
>> + }
>> +
>> + ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
>> + if (!ptn_bridge) {
>> + DRM_ERROR("Failed to allocate ptn bridge\n");
>> + return -ENOMEM;
>> + }
>
> No need for error messages on allocation failures. The allocator will
> already complain itself.
>
> Also I think it's usually better to use the dev_*() functions to print
> messages, especially given that at this stage we're not even hooked up
> to DRM in the first place.
>
> So in general I try to use DRM_*() functions only from DRM-specific
> callbacks (or functions called from them) and dev_*() otherwise.
Ok, will fix them.
>> +static int ptn3460_remove(struct i2c_client *client)
>> +{
>> + return 0;
>> +}
>
> This function should remove the bridge from the lookup table by calling
> drm_bridge_remove().
Just one doubt, already asked above.
>> +
>> +static const struct i2c_device_id ptn3460_i2c_table[] = {
>> + {"nxp,ptn3460", 0},
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(i2c, ptn3460_i2c_table);
>> +
>> +static const struct of_device_id ptn3460_match[] = {
>> + { .compatible = "nxp,ptn3460" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, ptn3460_match);
>> +
>> +struct i2c_driver ptn3460_driver = {
>
> Is there a reason why this can't be static?
Will make it static.
>> + .id_table = ptn3460_i2c_table,
>> + .probe = ptn3460_probe,
>> + .remove = ptn3460_remove,
>> + .driver = {
>> + .name = "nxp,ptn3460",
>> + .owner = THIS_MODULE,
>> + .of_match_table = of_match_ptr(ptn3460_match),
>
> You don't need of_match_ptr() here since you already depend on OF in
> Kconfig, therefore of_match_ptr(x) will always evaluate to x.
Ok, will fix it.
>> + },
>> +};
>> +module_i2c_driver(ptn3460_driver);
>> +
>> +MODULE_AUTHOR("Sean Paul <seanpaul@chromium.org>");
>> +MODULE_DESCRIPTION("NXP ptn3460 eDP-LVDS converter driver");
>> +MODULE_LICENSE("GPL");
>
> This should be "GPL v2".
Ok. Will fix it.
Ajay
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
2014-07-30 15:16 ` Ajay kumar
@ 2014-07-30 15:40 ` Thierry Reding
2014-07-30 16:14 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 15:40 UTC (permalink / raw)
To: Ajay kumar
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Prashanth G, Ajay Kumar
[-- Attachment #1.1: Type: text/plain, Size: 4102 bytes --]
On Wed, Jul 30, 2014 at 08:46:44PM +0530, Ajay kumar wrote:
> On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
[...]
> >> +int ptn3460_post_encoder_init(struct drm_bridge *bridge)
> >> +{
> >> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> >> + int ret;
> >> +
> >> + /* bridge is attached to encoder.
> >> + * safe to remove it from the bridge_lookup table.
> >> + */
> >> + drm_bridge_remove_from_lookup(bridge);
> >
> > No, you should never do this. First, you're not adding it back to the
> > registry when the bridge is detached, so unloading and reloading the
> > display driver will fail. Second there should never be a need to remove
> > it from the registry as long as the driver itself is loaded. If you're
> > concerned about a single bridge being used multiple times, there's
> > already code to handle that in your previous patch:
> >
> > int drm_bridge_attach_encoder(...)
> > {
> > ...
> >
> > if (bridge->encoder)
> > return -EBUSY;
> >
> > ...
> > }
> >
> > Generally the registry should contain a list of bridges that have been
> > registered, whether they're used or not is irrelevant.
> I was just wondering if it is ok to have a node in two independent lists?
> bridge_lookup_table and the other mode_config.bridge_list?
Oh, it reuses the head field for the registry. I hadn't noticed before.
No, you certainly can't have the same node in two lists. Honestly I
don't quite understand why there was a need to expose drm_bridge as a
drm_mode_object in the first place since it's never exported to
userspace.
So I think that perhaps we could simply get rid of the base field and
not tie in drm_bridge objects with the DRM object as we currently do.
But until Sean or Rob comment on this it might be better to simply add
another struct list_head field for the registry. That way both can
coexist and we can independently still decide to remove the base and
head fields if they're no longer needed.
> >> + ret = drm_connector_init(bridge->drm_dev, &ptn_bridge->connector,
> >> + &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
> >> + if (ret) {
> >> + DRM_ERROR("Failed to initialize connector with drm\n");
> >> + return ret;
> >> + }
> >> + drm_connector_helper_add(&ptn_bridge->connector,
> >> + &ptn3460_connector_helper_funcs);
> >> + drm_connector_register(&ptn_bridge->connector);
> >> + drm_mode_connector_attach_encoder(&ptn_bridge->connector,
> >> + bridge->encoder);
> >> +
> >> + if (ptn_bridge->panel)
> >> + drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
> >> +
> >> + return ret;
> >> +}
> >
> > I'm thinking that eventually we'll want to register the connector only
> > when a panel is attached to the bridge. This will only become important
> > when we implement bridge chaining because if you instantiate a connector
> > for each bridge then you'll get a list of connectors for the DRM device
> > representing the output of each bridge rather than just the final one
> > that goes to the display.
> So, do not initialize connector if there is no panel? and, get_modes
> via panel instead of doing it by edid-emulation?
If there's no panel, then there's nothing to connect the connector to,
so it's unneeded. Also if you have chained bridges, then each bridge
would expose a connector and it would become impossible to choose the
correct one. So only the final bridge in the chain should instantiate
the connector.
.get_modes() still needs to be done from the bridge because that is the
most closely connected to the display controller and therefore dictates
the timing that the display controller needs to generate.
Querying the panel's .get_modes() might be useful to figure out which
emulation mode to use in the bridge.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
2014-07-30 15:40 ` Thierry Reding
@ 2014-07-30 16:14 ` Ajay kumar
2014-07-31 11:21 ` Thierry Reding
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 16:14 UTC (permalink / raw)
To: Thierry Reding
Cc: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree, InKi Dae,
Rob Clark, Daniel Vetter, Sean Paul, Jingoo Han, sunil joshi,
Prashanth G, Sean Paul
On Wed, Jul 30, 2014 at 9:10 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Wed, Jul 30, 2014 at 08:46:44PM +0530, Ajay kumar wrote:
>> On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding <thierry.reding@gmail.com> wrote:
>> > On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
> [...]
>> >> +int ptn3460_post_encoder_init(struct drm_bridge *bridge)
>> >> +{
>> >> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
>> >> + int ret;
>> >> +
>> >> + /* bridge is attached to encoder.
>> >> + * safe to remove it from the bridge_lookup table.
>> >> + */
>> >> + drm_bridge_remove_from_lookup(bridge);
>> >
>> > No, you should never do this. First, you're not adding it back to the
>> > registry when the bridge is detached, so unloading and reloading the
>> > display driver will fail. Second there should never be a need to remove
>> > it from the registry as long as the driver itself is loaded. If you're
>> > concerned about a single bridge being used multiple times, there's
>> > already code to handle that in your previous patch:
>> >
>> > int drm_bridge_attach_encoder(...)
>> > {
>> > ...
>> >
>> > if (bridge->encoder)
>> > return -EBUSY;
>> >
>> > ...
>> > }
>> >
>> > Generally the registry should contain a list of bridges that have been
>> > registered, whether they're used or not is irrelevant.
>> I was just wondering if it is ok to have a node in two independent lists?
>> bridge_lookup_table and the other mode_config.bridge_list?
>
> Oh, it reuses the head field for the registry. I hadn't noticed before.
> No, you certainly can't have the same node in two lists. Honestly I
> don't quite understand why there was a need to expose drm_bridge as a
> drm_mode_object in the first place since it's never exported to
> userspace.
>
> So I think that perhaps we could simply get rid of the base field and
> not tie in drm_bridge objects with the DRM object as we currently do.
> But until Sean or Rob comment on this it might be better to simply add
> another struct list_head field for the registry. That way both can
> coexist and we can independently still decide to remove the base and
> head fields if they're no longer needed.
Ok. What shall I name the new list_head?
>> >> + ret = drm_connector_init(bridge->drm_dev, &ptn_bridge->connector,
>> >> + &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
>> >> + if (ret) {
>> >> + DRM_ERROR("Failed to initialize connector with drm\n");
>> >> + return ret;
>> >> + }
>> >> + drm_connector_helper_add(&ptn_bridge->connector,
>> >> + &ptn3460_connector_helper_funcs);
>> >> + drm_connector_register(&ptn_bridge->connector);
>> >> + drm_mode_connector_attach_encoder(&ptn_bridge->connector,
>> >> + bridge->encoder);
>> >> +
>> >> + if (ptn_bridge->panel)
>> >> + drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
>> >> +
>> >> + return ret;
>> >> +}
>> >
>> > I'm thinking that eventually we'll want to register the connector only
>> > when a panel is attached to the bridge. This will only become important
>> > when we implement bridge chaining because if you instantiate a connector
>> > for each bridge then you'll get a list of connectors for the DRM device
>> > representing the output of each bridge rather than just the final one
>> > that goes to the display.
>> So, do not initialize connector if there is no panel? and, get_modes
>> via panel instead of doing it by edid-emulation?
>
> If there's no panel, then there's nothing to connect the connector to,
> so it's unneeded. Also if you have chained bridges, then each bridge
> would expose a connector and it would become impossible to choose the
> correct one. So only the final bridge in the chain should instantiate
> the connector.
Since there is only a single bridge when it comes to ptn3460/ps8622, lets
not talk about chaining of bridges now.
And, I agree that if there is no panel, then no need to register connector.
> .get_modes() still needs to be done from the bridge because that is the
> most closely connected to the display controller and therefore dictates
> the timing that the display controller needs to generate.
>
> Querying the panel's .get_modes() might be useful to figure out which
> emulation mode to use in the bridge.
But, get_modes from panel returns me only the no_of_modes but
not the actual mode structure. How do I compare the list of supported
emulation modes?
Ajay
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
2014-07-30 16:14 ` Ajay kumar
@ 2014-07-31 11:21 ` Thierry Reding
0 siblings, 0 replies; 70+ messages in thread
From: Thierry Reding @ 2014-07-31 11:21 UTC (permalink / raw)
To: Ajay kumar
Cc: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree, InKi Dae,
Rob Clark, Daniel Vetter, Sean Paul, Jingoo Han, sunil joshi,
Prashanth G, Sean Paul
[-- Attachment #1: Type: text/plain, Size: 3193 bytes --]
On Wed, Jul 30, 2014 at 09:44:32PM +0530, Ajay kumar wrote:
> On Wed, Jul 30, 2014 at 9:10 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Wed, Jul 30, 2014 at 08:46:44PM +0530, Ajay kumar wrote:
> >> On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding <thierry.reding@gmail.com> wrote:
> >> > On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
> > [...]
> >> >> +int ptn3460_post_encoder_init(struct drm_bridge *bridge)
> >> >> +{
> >> >> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> >> >> + int ret;
> >> >> +
> >> >> + /* bridge is attached to encoder.
> >> >> + * safe to remove it from the bridge_lookup table.
> >> >> + */
> >> >> + drm_bridge_remove_from_lookup(bridge);
> >> >
> >> > No, you should never do this. First, you're not adding it back to the
> >> > registry when the bridge is detached, so unloading and reloading the
> >> > display driver will fail. Second there should never be a need to remove
> >> > it from the registry as long as the driver itself is loaded. If you're
> >> > concerned about a single bridge being used multiple times, there's
> >> > already code to handle that in your previous patch:
> >> >
> >> > int drm_bridge_attach_encoder(...)
> >> > {
> >> > ...
> >> >
> >> > if (bridge->encoder)
> >> > return -EBUSY;
> >> >
> >> > ...
> >> > }
> >> >
> >> > Generally the registry should contain a list of bridges that have been
> >> > registered, whether they're used or not is irrelevant.
> >> I was just wondering if it is ok to have a node in two independent lists?
> >> bridge_lookup_table and the other mode_config.bridge_list?
> >
> > Oh, it reuses the head field for the registry. I hadn't noticed before.
> > No, you certainly can't have the same node in two lists. Honestly I
> > don't quite understand why there was a need to expose drm_bridge as a
> > drm_mode_object in the first place since it's never exported to
> > userspace.
> >
> > So I think that perhaps we could simply get rid of the base field and
> > not tie in drm_bridge objects with the DRM object as we currently do.
> > But until Sean or Rob comment on this it might be better to simply add
> > another struct list_head field for the registry. That way both can
> > coexist and we can independently still decide to remove the base and
> > head fields if they're no longer needed.
> Ok. What shall I name the new list_head?
"list" would be a good choice in my opinion.
> > .get_modes() still needs to be done from the bridge because that is the
> > most closely connected to the display controller and therefore dictates
> > the timing that the display controller needs to generate.
> >
> > Querying the panel's .get_modes() might be useful to figure out which
> > emulation mode to use in the bridge.
> But, get_modes from panel returns me only the no_of_modes but
> not the actual mode structure. How do I compare the list of supported
> emulation modes?
You could iterate over the connector's probed_modes list which should
contain all the modes that the panel reported (after .get_modes() was
called).
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
` (6 preceding siblings ...)
2014-07-25 19:22 ` [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge Ajay Kumar
@ 2014-07-25 19:22 ` Ajay Kumar
2014-07-29 11:29 ` Andreas Färber
2014-07-30 13:11 ` Thierry Reding
2014-07-27 18:22 ` [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Andreas Färber
2014-07-30 9:56 ` Thierry Reding
9 siblings, 2 replies; 70+ messages in thread
From: Ajay Kumar @ 2014-07-25 19:22 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g, Vincent Palatin,
Andrew Bresticker, Sean Paul, Rahul Sharma, Ajay Kumar
From: Vincent Palatin <vpalatin@chromium.org>
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
.../devicetree/bindings/vendor-prefixes.txt | 1 +
.../devicetree/bindings/video/bridge/ps8622.txt | 19 +
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/ps8622.c | 602 ++++++++++++++++++++
5 files changed, 633 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 46a311e..b4a99cc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -96,6 +96,7 @@ nxp NXP Semiconductors
onnn ON Semiconductor Corp.
opencores OpenCores.org
panasonic Panasonic Corporation
+parade Parade Technologies Inc.
phytec PHYTEC Messtechnik GmbH
picochip Picochip Ltd
plathome Plat'Home Co., Ltd.
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 0000000..fdeafb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,19 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: "parade,ps8622" or "parade,ps8625"
+ - reg: first i2c address of the bridge
+ - sleep-gpios: OF device-tree gpio specification
+ - reset-gpios: OF device-tree gpio specification
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+
+Example:
+ ps8622-bridge@48 {
+ compatible = "parade,ps8622";
+ reg = <0x48>;
+ sleep-gpios = <&gpc3 6 1 0 0>;
+ reset-gpios = <&gpc3 1 1 0 0>;
+ lane-count = <1>
+ };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 0b12d16..d73e474 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -16,4 +16,14 @@ config DRM_PTN3460
help
ptn3460 eDP-LVDS bridge chip driver.
+config DRM_PS8622
+ tristate "Parade eDP/LVDS bridge"
+ depends on DRM && DRM_BRIDGE
+ depends on OF
+ depends on I2C
+ select DRM_PANEL
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ parade eDP-LVDS bridge chip driver.
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d1b5daa 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 0000000..ec60fcf
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,602 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 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/backlight.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/fb.h>
+#include <linux/gpio.h>
+#include <linux/i2c.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pm.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/drm_panel.h>
+
+#include "drmP.h"
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+
+struct ps8622_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+ struct drm_bridge *bridge;
+ struct drm_panel *panel;
+ struct regulator *v12;
+ struct backlight_device *bl;
+ struct mutex enable_mutex;
+
+ struct gpio_desc *gpio_slp_n;
+ struct gpio_desc *gpio_rst_n;
+
+ u8 max_lane_count;
+ u8 lane_count;
+
+ bool enabled;
+};
+
+struct ps8622_device_data {
+ u8 max_lane_count;
+};
+
+static const struct ps8622_device_data ps8622_data = {
+ .max_lane_count = 1,
+};
+
+static const struct ps8622_device_data ps8625_data = {
+ .max_lane_count = 2,
+};
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
+#define PS8622_POWER_RISE_T1_MAX_US 10000
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 30000
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 10000
+#define PS8622_POWER_OFF_T17_MS 500
+
+#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) > \
+ (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
+#error "T2.min + T1.max must be less than T2.max + T1.min"
+#endif
+
+static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+{
+ int ret;
+ struct i2c_adapter *adap = client->adapter;
+ struct i2c_msg msg;
+ u8 data[] = {reg, val};
+
+ msg.addr = client->addr + page;
+ msg.flags = 0;
+ msg.len = sizeof(data);
+ msg.buf = data;
+
+ ret = i2c_transfer(adap, &msg, 1);
+ if (ret != 1)
+ pr_warn("PS8622 I2C write (0x%02x,0x%02x,0x%02x) failed: %d\n",
+ client->addr + page, reg, val, ret);
+ return !(ret == 1);
+}
+
+static int ps8622_send_config(struct ps8622_bridge *ps_bridge)
+{
+ struct i2c_client *cl = ps_bridge->client;
+ int err = 0;
+
+ /* wait 20ms after power ON */
+ usleep_range(20000, 30000);
+
+ err |= ps8622_set(cl, 0x02, 0xa1, 0x01); /* HPD low */
+ /* SW setting */
+ err |= ps8622_set(cl, 0x04, 0x14, 0x01); /* [1:0] SW output 1.2V voltage
+ * is lower to 96% */
+ /* RCO SS setting */
+ err |= ps8622_set(cl, 0x04, 0xe3, 0x20); /* [5:4] = b01 0.5%, b10 1%,
+ * b11 1.5% */
+ err |= ps8622_set(cl, 0x04, 0xe2, 0x80); /* [7] RCO SS enable */
+ /* RPHY Setting */
+ err |= ps8622_set(cl, 0x04, 0x8a, 0x0c); /* [3:2] CDR tune wait cycle
+ * before measure for fine tune
+ * b00: 1us b01: 0.5us b10:2us
+ * b11: 4us */
+ err |= ps8622_set(cl, 0x04, 0x89, 0x08); /* [3] RFD always on */
+ err |= ps8622_set(cl, 0x04, 0x71, 0x2d); /* CTN lock in/out:
+ * 20000ppm/80000ppm.
+ * Lock out 2 times. */
+ /* 2.7G CDR settings */
+ err |= ps8622_set(cl, 0x04, 0x7d, 0x07); /* NOF=40LSB for HBR CDR
+ * setting */
+ err |= ps8622_set(cl, 0x04, 0x7b, 0x00); /* [1:0] Fmin=+4bands */
+ err |= ps8622_set(cl, 0x04, 0x7a, 0xfd); /* [7:5] DCO_FTRNG=+-40% */
+ /* 1.62G CDR settings */
+ err |= ps8622_set(cl, 0x04, 0xc0, 0x12); /* [5:2]NOF=64LSB [1:0]DCO
+ * scale is 2/5 */
+ err |= ps8622_set(cl, 0x04, 0xc1, 0x92); /* Gitune=-37% */
+ err |= ps8622_set(cl, 0x04, 0xc2, 0x1c); /* Fbstep=100% */
+ err |= ps8622_set(cl, 0x04, 0x32, 0x80); /* [7] LOS signal disable */
+ /* RPIO Setting */
+ err |= ps8622_set(cl, 0x04, 0x00, 0xb0); /* [7:4] LVDS driver bias
+ * current : 75% (250mV swing)
+ * */
+ err |= ps8622_set(cl, 0x04, 0x15, 0x40); /* [7:6] Right-bar GPIO output
+ * strength is 8mA */
+ /* EQ Training State Machine Setting */
+ err |= ps8622_set(cl, 0x04, 0x54, 0x10); /* RCO calibration start */
+ /* Logic, needs more than 10 I2C command */
+ err |= ps8622_set(cl, 0x01, 0x02, 0x80 | ps_bridge->max_lane_count);
+ /* [4:0] MAX_LANE_COUNT set to
+ * max supported lanes */
+ err |= ps8622_set(cl, 0x01, 0x21, 0x80 | ps_bridge->lane_count);
+ /* [4:0] LANE_COUNT_SET set to
+ * chosen lane count */
+ err |= ps8622_set(cl, 0x00, 0x52, 0x20);
+ err |= ps8622_set(cl, 0x00, 0xf1, 0x03); /* HPD CP toggle enable */
+ err |= ps8622_set(cl, 0x00, 0x62, 0x41);
+ err |= ps8622_set(cl, 0x00, 0xf6, 0x01); /* Counter number, add 1ms
+ * counter delay */
+ err |= ps8622_set(cl, 0x00, 0x77, 0x06); /* [6]PWM function control by
+ * DPCD0040f[7], default is PWM
+ * block always works. */
+ err |= ps8622_set(cl, 0x00, 0x4c, 0x04); /* 04h Adjust VTotal tolerance
+ * to fix the 30Hz no display
+ * issue */
+ err |= ps8622_set(cl, 0x01, 0xc0, 0x00); /* DPCD00400='h00, Parade OUI =
+ * 'h001cf8 */
+ err |= ps8622_set(cl, 0x01, 0xc1, 0x1c); /* DPCD00401='h1c */
+ err |= ps8622_set(cl, 0x01, 0xc2, 0xf8); /* DPCD00402='hf8 */
+ err |= ps8622_set(cl, 0x01, 0xc3, 0x44); /* DPCD403~408 = ASCII code
+ * D2SLV5='h4432534c5635 */
+ err |= ps8622_set(cl, 0x01, 0xc4, 0x32); /* DPCD404 */
+ err |= ps8622_set(cl, 0x01, 0xc5, 0x53); /* DPCD405 */
+ err |= ps8622_set(cl, 0x01, 0xc6, 0x4c); /* DPCD406 */
+ err |= ps8622_set(cl, 0x01, 0xc7, 0x56); /* DPCD407 */
+ err |= ps8622_set(cl, 0x01, 0xc8, 0x35); /* DPCD408 */
+ err |= ps8622_set(cl, 0x01, 0xca, 0x01); /* DPCD40A, Initial Code major
+ * revision '01' */
+ err |= ps8622_set(cl, 0x01, 0xcb, 0x05); /* DPCD40B, Initial Code minor
+ * revision '05' */
+ if (ps_bridge->bl) {
+ err |= ps8622_set(cl, 0x01, 0xa5, 0xa0);
+ /* DPCD720, internal PWM */
+ err |= ps8622_set(cl, 0x01, 0xa7,
+ ps_bridge->bl->props.brightness);
+ /* FFh for 100% brightness,
+ * 0h for 0% brightness */
+ } else {
+ err |= ps8622_set(cl, 0x01, 0xa5, 0x80);
+ /* DPCD720, external PWM */
+ }
+ err |= ps8622_set(cl, 0x01, 0xcc, 0x13); /* Set LVDS output as 6bit-VESA
+ * mapping, single LVDS channel
+ * */
+ err |= ps8622_set(cl, 0x02, 0xb1, 0x20); /* Enable SSC set by register
+ * */
+ err |= ps8622_set(cl, 0x04, 0x10, 0x16); /* Set SSC enabled and +/-1%
+ * central spreading */
+ /* Logic end */
+ err |= ps8622_set(cl, 0x04, 0x59, 0x60); /* MPU Clock source: LC => RCO
+ * */
+ err |= ps8622_set(cl, 0x04, 0x54, 0x14); /* LC -> RCO */
+ err |= ps8622_set(cl, 0x02, 0xa1, 0x91); /* HPD high */
+
+ return err ? -EIO : 0;
+}
+
+static int ps8622_backlight_update(struct backlight_device *bl)
+{
+ struct ps8622_bridge *ps_bridge = dev_get_drvdata(&bl->dev);
+ int ret, brightness = bl->props.brightness;
+
+ if (bl->props.power != FB_BLANK_UNBLANK ||
+ bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ brightness = 0;
+
+ mutex_lock(&ps_bridge->enable_mutex);
+
+ if (!ps_bridge->enabled) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = ps8622_set(ps_bridge->client, 0x01, 0xa7, brightness);
+
+out:
+ mutex_unlock(&ps_bridge->enable_mutex);
+ return ret;
+}
+
+static int ps8622_backlight_get(struct backlight_device *bl)
+{
+ return bl->props.brightness;
+}
+
+static const struct backlight_ops ps8622_backlight_ops = {
+ .update_status = ps8622_backlight_update,
+ .get_brightness = ps8622_backlight_get,
+};
+
+static void ps8622_pre_enable(struct drm_bridge *bridge)
+{
+ struct ps8622_bridge *ps_bridge = bridge->driver_private;
+ int ret;
+
+ mutex_lock(&ps_bridge->enable_mutex);
+ if (ps_bridge->enabled)
+ goto out;
+
+ gpiod_set_value(ps_bridge->gpio_rst_n, 0);
+
+ if (ps_bridge->v12) {
+ ret = regulator_enable(ps_bridge->v12);
+ if (ret)
+ DRM_ERROR("fails to enable ps_bridge->v12");
+ }
+
+ drm_panel_prepare(ps_bridge->panel);
+
+ gpiod_set_value(ps_bridge->gpio_slp_n, 1);
+
+ /*
+ * T1 is the range of time that it takes for the power to rise after we
+ * enable the lcd fet. T2 is the range of time in which the data sheet
+ * specifies we should deassert the reset pin.
+ *
+ * If it takes T1.max for the power to rise, we need to wait atleast
+ * T2.min before deasserting the reset pin. If it takes T1.min for the
+ * power to rise, we need to wait at most T2.max before deasserting the
+ * reset pin.
+ */
+ usleep_range(PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US,
+ PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US);
+
+ gpiod_set_value(ps_bridge->gpio_rst_n, 1);
+
+ ret = ps8622_send_config(ps_bridge);
+ if (ret)
+ DRM_ERROR("Failed to send config to bridge (%d)\n", ret);
+
+ ps_bridge->enabled = true;
+
+out:
+ mutex_unlock(&ps_bridge->enable_mutex);
+}
+
+static void ps8622_enable(struct drm_bridge *bridge)
+{
+ struct ps8622_bridge *ps_bridge = bridge->driver_private;
+
+ mutex_lock(&ps_bridge->enable_mutex);
+ drm_panel_enable(ps_bridge->panel);
+ mutex_unlock(&ps_bridge->enable_mutex);
+}
+
+static void ps8622_disable(struct drm_bridge *bridge)
+{
+ struct ps8622_bridge *ps_bridge = bridge->driver_private;
+
+ mutex_lock(&ps_bridge->enable_mutex);
+
+ if (!ps_bridge->enabled)
+ goto out;
+
+ ps_bridge->enabled = false;
+
+ drm_panel_disable(ps_bridge->panel);
+ msleep(PS8622_PWMO_END_T12_MS);
+
+ /*
+ * This doesn't matter if the regulators are turned off, but something
+ * else might keep them on. In that case, we want to assert the slp gpio
+ * to lower power.
+ */
+ gpiod_set_value(ps_bridge->gpio_slp_n, 0);
+
+ if (ps_bridge->v12)
+ regulator_disable(ps_bridge->v12);
+
+ /*
+ * Sleep for at least the amount of time that it takes the power rail to
+ * fall to prevent asserting the rst gpio from doing anything.
+ */
+ usleep_range(PS8622_POWER_FALL_T16_MAX_US,
+ 2 * PS8622_POWER_FALL_T16_MAX_US);
+ gpiod_set_value(ps_bridge->gpio_rst_n, 0);
+
+ msleep(PS8622_POWER_OFF_T17_MS);
+
+out:
+ mutex_unlock(&ps_bridge->enable_mutex);
+}
+
+static void ps8622_post_disable(struct drm_bridge *bridge)
+{
+ struct ps8622_bridge *ps_bridge = bridge->driver_private;
+
+ drm_panel_unprepare(ps_bridge->panel);
+}
+
+static void ps8622_destroy(struct drm_bridge *bridge)
+{
+ drm_bridge_cleanup(bridge);
+}
+
+static int ps8622_get_modes(struct drm_connector *connector)
+{
+ struct ps8622_bridge *ps_bridge;
+
+ ps_bridge = container_of(connector, struct ps8622_bridge, connector);
+
+ return drm_panel_get_modes(ps_bridge->panel);
+}
+
+static struct drm_encoder *ps8622_best_encoder(struct drm_connector *connector)
+{
+ struct ps8622_bridge *ps_bridge;
+
+ ps_bridge = container_of(connector, struct ps8622_bridge, connector);
+
+ return ps_bridge->bridge->encoder;
+}
+
+static const struct drm_connector_helper_funcs ps8622_connector_helper_funcs = {
+ .get_modes = ps8622_get_modes,
+ .best_encoder = ps8622_best_encoder,
+};
+
+static enum drm_connector_status ps8622_detect(struct drm_connector *connector,
+ bool force)
+{
+ return connector_status_connected;
+}
+
+static void ps8622_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs ps8622_connector_funcs = {
+ .dpms = drm_helper_connector_dpms,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = ps8622_detect,
+ .destroy = ps8622_connector_destroy,
+};
+
+int ps8622_post_encoder_init(struct drm_bridge *bridge)
+{
+ struct ps8622_bridge *ps_bridge = bridge->driver_private;
+ int ret;
+
+ /* bridge is attached to encoder.
+ * safe to remove it from the bridge_lookup table.
+ */
+ drm_bridge_remove_from_lookup(bridge);
+
+ ret = drm_bridge_init(bridge->drm_dev, bridge);
+ if (ret) {
+ DRM_ERROR("Failed to initialize bridge with drm\n");
+ return ret;
+ }
+
+ /* connector implementation */
+ ps_bridge->connector.polled = bridge->connector_polled;
+
+ ret = drm_connector_init(bridge->drm_dev, &ps_bridge->connector,
+ &ps8622_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector with drm\n");
+ return ret;
+ }
+ drm_connector_helper_add(&ps_bridge->connector,
+ &ps8622_connector_helper_funcs);
+ drm_connector_register(&ps_bridge->connector);
+ drm_mode_connector_attach_encoder(&ps_bridge->connector,
+ bridge->encoder);
+
+ if (ps_bridge->panel)
+ drm_panel_attach(ps_bridge->panel, &ps_bridge->connector);
+
+ return ret;
+}
+
+static const struct drm_bridge_funcs ps8622_bridge_funcs = {
+ .post_encoder_init = ps8622_post_encoder_init,
+ .pre_enable = ps8622_pre_enable,
+ .enable = ps8622_enable,
+ .disable = ps8622_disable,
+ .post_disable = ps8622_post_disable,
+ .destroy = ps8622_destroy,
+};
+
+static const struct of_device_id ps8622_devices[] = {
+ {
+ .compatible = "parade,ps8622",
+ .data = &ps8622_data,
+ }, {
+ .compatible = "parade,ps8625",
+ .data = &ps8625_data,
+ }, {
+ /* end node */
+ }
+};
+MODULE_DEVICE_TABLE(of, ps8622_devices);
+
+static inline struct ps8622_device_data *get_device_data(struct device *dev)
+{
+ const struct of_device_id *match =
+ of_match_device(ps8622_devices, dev);
+
+ return (struct ps8622_device_data *)match->data;
+}
+
+static int ps8622_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = &(client->dev);
+ struct device_node *panel_node, *backlight_node;
+ struct drm_bridge *bridge;
+ struct backlight_device *backlight_dev;
+ struct ps8622_bridge *ps_bridge;
+ const struct ps8622_device_data *device_data;
+ int ret;
+
+ bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
+ if (!bridge) {
+ DRM_ERROR("Failed to allocate drm bridge\n");
+ return -ENOMEM;
+ }
+
+ ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
+ if (!ps_bridge) {
+ DRM_ERROR("could not allocate ps bridge\n");
+ return -ENOMEM;
+ }
+
+ panel_node = of_parse_phandle(dev->of_node, "panel", 0);
+ if (panel_node) {
+ ps_bridge->panel = of_drm_find_panel(panel_node);
+ of_node_put(panel_node);
+ if (!ps_bridge->panel)
+ return -EPROBE_DEFER;
+ }
+
+ backlight_dev = NULL;
+ backlight_node = of_parse_phandle(dev->of_node, "backlight", 0);
+ if (backlight_node) {
+ backlight_dev = of_find_backlight_by_node(backlight_node);
+ of_node_put(backlight_node);
+ if (!backlight_dev)
+ return -EPROBE_DEFER;
+ }
+
+ mutex_init(&ps_bridge->enable_mutex);
+
+ bridge->dev = dev;
+ bridge->driver_private = ps_bridge;
+ bridge->funcs = &ps8622_bridge_funcs;
+
+ ps_bridge->client = client;
+ ps_bridge->bridge = bridge;
+
+ device_data = get_device_data(dev);
+
+ ps_bridge->v12 = devm_regulator_get(&client->dev, "vdd_bridge");
+ if (IS_ERR(ps_bridge->v12)) {
+ DRM_INFO("no 1.2v regulator found for PS8622\n");
+ ps_bridge->v12 = NULL;
+ }
+
+ ps_bridge->gpio_slp_n = devm_gpiod_get(&client->dev, "sleep");
+ if (IS_ERR(ps_bridge->gpio_slp_n)) {
+ ret = PTR_ERR(ps_bridge->gpio_slp_n);
+ DRM_ERROR("cannot get gpio_slp_n %d\n", ret);
+ goto err_client;
+ } else {
+ ret = gpiod_direction_output(ps_bridge->gpio_slp_n, 1);
+ if (ret) {
+ DRM_ERROR("cannot configure gpio_slp_n\n");
+ goto err_client;
+ }
+ }
+
+ ps_bridge->gpio_rst_n = devm_gpiod_get(&client->dev, "reset");
+ if (IS_ERR(ps_bridge->gpio_rst_n)) {
+ ret = PTR_ERR(ps_bridge->gpio_rst_n);
+ DRM_ERROR("cannot get gpio_rst_n %d\n", ret);
+ goto err_client;
+ } else {
+ /*
+ * Assert the reset pin high to avoid the bridge being
+ * initialized prematurely
+ */
+ ret = gpiod_direction_output(ps_bridge->gpio_rst_n, 1);
+ if (ret) {
+ DRM_ERROR("cannot configure gpio_slp_n\n");
+ goto err_client;
+ }
+ }
+
+ ps_bridge->max_lane_count = device_data->max_lane_count;
+
+ if (of_property_read_u8(dev->of_node, "lane-count",
+ &ps_bridge->lane_count))
+ ps_bridge->lane_count = ps_bridge->max_lane_count;
+ else if (ps_bridge->lane_count > ps_bridge->max_lane_count) {
+ DRM_INFO("lane-count property is too high for DP bridge\n");
+ ps_bridge->lane_count = ps_bridge->max_lane_count;
+ }
+
+ if (!backlight_dev) {
+ ps_bridge->bl = backlight_device_register("ps8622-backlight",
+ dev, ps_bridge, &ps8622_backlight_ops,
+ NULL);
+ if (IS_ERR(ps_bridge->bl)) {
+ DRM_ERROR("failed to register backlight\n");
+ ret = PTR_ERR(ps_bridge->bl);
+ ps_bridge->bl = NULL;
+ goto err_client;
+ }
+ ps_bridge->bl->props.max_brightness = PS8622_MAX_BRIGHTNESS;
+ ps_bridge->bl->props.brightness = PS8622_MAX_BRIGHTNESS;
+ }
+
+ i2c_set_clientdata(client, ps_bridge);
+
+ drm_bridge_add_for_lookup(bridge);
+
+ return 0;
+
+err_client:
+ DRM_ERROR("device probe failed : %d\n", ret);
+ return ret;
+}
+
+static int ps8622_remove(struct i2c_client *client)
+{
+ struct ps8622_bridge *ps_bridge = i2c_get_clientdata(client);
+
+ if (ps_bridge->bl)
+ backlight_device_unregister(ps_bridge->bl);
+
+ return 0;
+}
+
+static const struct i2c_device_id ps8622_i2c_table[] = {
+ {"parade", 0},
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, ps8622_i2c_table);
+
+struct i2c_driver ps8622_driver = {
+ .id_table = ps8622_i2c_table,
+ .probe = ps8622_probe,
+ .remove = ps8622_remove,
+ .driver = {
+ .name = "parade",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ps8622_devices),
+ },
+};
+module_i2c_driver(ps8622_driver);
+
+MODULE_AUTHOR("Vincent Palatin <vpalatin@chromium.org>");
+MODULE_DESCRIPTION("Parade ps8622 eDP-LVDS converter driver");
+MODULE_LICENSE("GPL");
--
1.7.9.5
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
2014-07-25 19:22 ` [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge Ajay Kumar
@ 2014-07-29 11:29 ` Andreas Färber
2014-07-30 6:27 ` Ajay kumar
2014-07-30 13:11 ` Thierry Reding
1 sibling, 1 reply; 70+ messages in thread
From: Andreas Färber @ 2014-07-29 11:29 UTC (permalink / raw)
To: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g, Vincent Palatin,
Andrew Bresticker, Sean Paul, Rahul Sharma
Am 25.07.2014 21:22, schrieb Ajay Kumar:
> From: Vincent Palatin <vpalatin@chromium.org>
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> ---
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> .../devicetree/bindings/video/bridge/ps8622.txt | 19 +
> drivers/gpu/drm/bridge/Kconfig | 10 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/ps8622.c | 602 ++++++++++++++++++++
> 5 files changed, 633 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
> create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 46a311e..b4a99cc 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -96,6 +96,7 @@ nxp NXP Semiconductors
> onnn ON Semiconductor Corp.
> opencores OpenCores.org
> panasonic Panasonic Corporation
> +parade Parade Technologies Inc.
> phytec PHYTEC Messtechnik GmbH
> picochip Picochip Ltd
> plathome Plat'Home Co., Ltd.
> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> new file mode 100644
> index 0000000..fdeafb2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> @@ -0,0 +1,19 @@
> +ps8622-bridge bindings
> +
> +Required properties:
> + - compatible: "parade,ps8622" or "parade,ps8625"
> + - reg: first i2c address of the bridge
> + - sleep-gpios: OF device-tree gpio specification
> + - reset-gpios: OF device-tree gpio specification
> +
> +Optional properties:
> + - lane-count: number of DP lanes to use
> +
> +Example:
> + ps8622-bridge@48 {
Nit: Shouldn't this be lvds-bridge like in 7/8 or something else not
derived from the specific model? Applies to the DT series as well.
> + compatible = "parade,ps8622";
> + reg = <0x48>;
> + sleep-gpios = <&gpc3 6 1 0 0>;
> + reset-gpios = <&gpc3 1 1 0 0>;
> + lane-count = <1>
> + };
[...]
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
> new file mode 100644
> index 0000000..ec60fcf
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ps8622.c
> @@ -0,0 +1,602 @@
> +/*
> + * Parade PS8622 eDP/LVDS bridge driver
> + *
> + * Copyright (C) 2014 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.
> + */
[...]
> +MODULE_AUTHOR("Vincent Palatin <vpalatin@chromium.org>");
> +MODULE_DESCRIPTION("Parade ps8622 eDP-LVDS converter driver");
> +MODULE_LICENSE("GPL");
"GPL v2"?
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
2014-07-29 11:29 ` Andreas Färber
@ 2014-07-30 6:27 ` Ajay kumar
0 siblings, 0 replies; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 6:27 UTC (permalink / raw)
To: Andreas Färber
Cc: devicetree, linux-samsung-soc, Vincent Palatin, Sean Paul,
Andrew Bresticker, Daniel Vetter, sunil joshi, dri-devel,
Prashanth G, Ajay Kumar, Rahul Sharma
Hi Andreas,
On Tue, Jul 29, 2014 at 4:59 PM, Andreas Färber <afaerber@suse.de> wrote:
> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> From: Vincent Palatin <vpalatin@chromium.org>
>>
>> This patch adds drm_bridge driver for parade DisplayPort
>> to LVDS bridge chip.
>>
>> Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Signed-off-by: Sean Paul <seanpaul@chromium.org>
>> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> ---
>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>> .../devicetree/bindings/video/bridge/ps8622.txt | 19 +
>> drivers/gpu/drm/bridge/Kconfig | 10 +
>> drivers/gpu/drm/bridge/Makefile | 1 +
>> drivers/gpu/drm/bridge/ps8622.c | 602 ++++++++++++++++++++
>> 5 files changed, 633 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
>> create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 46a311e..b4a99cc 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -96,6 +96,7 @@ nxp NXP Semiconductors
>> onnn ON Semiconductor Corp.
>> opencores OpenCores.org
>> panasonic Panasonic Corporation
>> +parade Parade Technologies Inc.
>> phytec PHYTEC Messtechnik GmbH
>> picochip Picochip Ltd
>> plathome Plat'Home Co., Ltd.
>> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>> new file mode 100644
>> index 0000000..fdeafb2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>> @@ -0,0 +1,19 @@
>> +ps8622-bridge bindings
>> +
>> +Required properties:
>> + - compatible: "parade,ps8622" or "parade,ps8625"
>> + - reg: first i2c address of the bridge
>> + - sleep-gpios: OF device-tree gpio specification
>> + - reset-gpios: OF device-tree gpio specification
>> +
>> +Optional properties:
>> + - lane-count: number of DP lanes to use
>> +
>> +Example:
>> + ps8622-bridge@48 {
>
> Nit: Shouldn't this be lvds-bridge like in 7/8 or something else not
> derived from the specific model? Applies to the DT series as well.
Right. I will fix this while sending the next series.
>> + compatible = "parade,ps8622";
>> + reg = <0x48>;
>> + sleep-gpios = <&gpc3 6 1 0 0>;
>> + reset-gpios = <&gpc3 1 1 0 0>;
>> + lane-count = <1>
>> + };
> [...]
>> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
>> new file mode 100644
>> index 0000000..ec60fcf
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/ps8622.c
>> @@ -0,0 +1,602 @@
>> +/*
>> + * Parade PS8622 eDP/LVDS bridge driver
>> + *
>> + * Copyright (C) 2014 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.
>> + */
> [...]
>> +MODULE_AUTHOR("Vincent Palatin <vpalatin@chromium.org>");
>> +MODULE_DESCRIPTION("Parade ps8622 eDP-LVDS converter driver");
>> +MODULE_LICENSE("GPL");
>
> "GPL v2"?
Ok. Will change it.
Regards,
Ajay
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
2014-07-25 19:22 ` [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge Ajay Kumar
2014-07-29 11:29 ` Andreas Färber
@ 2014-07-30 13:11 ` Thierry Reding
1 sibling, 0 replies; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 13:11 UTC (permalink / raw)
To: Ajay Kumar
Cc: devicetree, linux-samsung-soc, Vincent Palatin, seanpaul,
Andrew Bresticker, daniel.vetter, joshi, dri-devel, ajaynumb,
prashanth.g, Rahul Sharma
[-- Attachment #1.1: Type: text/plain, Size: 19946 bytes --]
On Sat, Jul 26, 2014 at 12:52:10AM +0530, Ajay Kumar wrote:
[...]
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 46a311e..b4a99cc 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -96,6 +96,7 @@ nxp NXP Semiconductors
> onnn ON Semiconductor Corp.
> opencores OpenCores.org
> panasonic Panasonic Corporation
> +parade Parade Technologies Inc.
> phytec PHYTEC Messtechnik GmbH
> picochip Picochip Ltd
> plathome Plat'Home Co., Ltd.
I think it's a good idea to turn this into a separate patch to avoid
conflicts.
> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> new file mode 100644
> index 0000000..fdeafb2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> @@ -0,0 +1,19 @@
> +ps8622-bridge bindings
> +
> +Required properties:
> + - compatible: "parade,ps8622" or "parade,ps8625"
> + - reg: first i2c address of the bridge
I'm not sure what the deal is with devices that use more than one I2C
addresses. It would be good to hear from the device tree maintainers on
how to handle those. Technically each address is a separate device. This
is also mirrored in the Linux kernel's implementation of the I2C bus,
where it looks wrong to access more than a single address (since the
core only marks one of them used). So technically it's valid for
userspace to access any but the first "page" of this device.
> + - sleep-gpios: OF device-tree gpio specification
> + - reset-gpios: OF device-tree gpio specification
This should explain what these GPIOs are used for.
> +
> +Optional properties:
> + - lane-count: number of DP lanes to use
> +
> +Example:
> + ps8622-bridge@48 {
> + compatible = "parade,ps8622";
> + reg = <0x48>;
> + sleep-gpios = <&gpc3 6 1 0 0>;
> + reset-gpios = <&gpc3 1 1 0 0>;
> + lane-count = <1>
> + };
Same here. It's usually best to make this a patch separate from the
driver. Not because of conflicts, but because it makes it easier for DT
reviewers to find the relevant pieces to look at.
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 0b12d16..d73e474 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -16,4 +16,14 @@ config DRM_PTN3460
> help
> ptn3460 eDP-LVDS bridge chip driver.
>
> +config DRM_PS8622
> + tristate "Parade eDP/LVDS bridge"
> + depends on DRM && DRM_BRIDGE
Aagin, these are unnecessary.
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index b4733e1..d1b5daa 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,3 +1,4 @@
> ccflags-y := -Iinclude/drm
>
> obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
Please keep these sorted alphabetically.
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
[...]
> +#include <linux/module.h>
> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/fb.h>
> +#include <linux/gpio.h>
> +#include <linux/i2c.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pm.h>
> +#include <linux/regulator/consumer.h>
These too.
> +struct ps8622_bridge {
> + struct drm_connector connector;
> + struct i2c_client *client;
> + struct drm_bridge *bridge;
Should be embedded.
> + struct drm_panel *panel;
> + struct regulator *v12;
> + struct backlight_device *bl;
> + struct mutex enable_mutex;
I don't quite understand what this protects. Can you explain?
> +struct ps8622_device_data {
> + u8 max_lane_count;
> +};
> +
> +static const struct ps8622_device_data ps8622_data = {
> + .max_lane_count = 1,
> +};
> +
> +static const struct ps8622_device_data ps8625_data = {
> + .max_lane_count = 2,
> +};
> +
> +/* Brightness scale on the Parade chip */
> +#define PS8622_MAX_BRIGHTNESS 0xff
> +
> +/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
> +#define PS8622_POWER_RISE_T1_MIN_US 10
> +#define PS8622_POWER_RISE_T1_MAX_US 10000
> +#define PS8622_RST_HIGH_T2_MIN_US 3000
> +#define PS8622_RST_HIGH_T2_MAX_US 30000
> +#define PS8622_PWMO_END_T12_MS 200
> +#define PS8622_POWER_FALL_T16_MAX_US 10000
> +#define PS8622_POWER_OFF_T17_MS 500
> +
> +#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) > \
> + (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
> +#error "T2.min + T1.max must be less than T2.max + T1.min"
> +#endif
> +
> +static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
> +{
> + int ret;
> + struct i2c_adapter *adap = client->adapter;
> + struct i2c_msg msg;
> + u8 data[] = {reg, val};
> +
> + msg.addr = client->addr + page;
> + msg.flags = 0;
> + msg.len = sizeof(data);
> + msg.buf = data;
> +
> + ret = i2c_transfer(adap, &msg, 1);
> + if (ret != 1)
> + pr_warn("PS8622 I2C write (0x%02x,0x%02x,0x%02x) failed: %d\n",
> + client->addr + page, reg, val, ret);
> + return !(ret == 1);
> +}
> +
> +static int ps8622_send_config(struct ps8622_bridge *ps_bridge)
> +{
> + struct i2c_client *cl = ps_bridge->client;
> + int err = 0;
> +
> + /* wait 20ms after power ON */
> + usleep_range(20000, 30000);
It's unusual to do this here. The function doesn't know when it's being
called. It could theoretically be called at any point. Better to move
the sleep to after where the device is powered on.
> +
> + err |= ps8622_set(cl, 0x02, 0xa1, 0x01); /* HPD low */
> + /* SW setting */
> + err |= ps8622_set(cl, 0x04, 0x14, 0x01); /* [1:0] SW output 1.2V voltage
> + * is lower to 96% */
I'm not at all a fan of this kind of error chaining because you loose
all context about specific errors. Also if there's a systematic error
you'll want to abort as early as possible. If the device doesn't respond
to the first command sent, then it likely won't respond to the next
either. No need to keep trying in that case.
> + /* RCO SS setting */
> + err |= ps8622_set(cl, 0x04, 0xe3, 0x20); /* [5:4] = b01 0.5%, b10 1%,
> + * b11 1.5% */
Also I find it very hard to follow these calls. Since you have enough
information about what each of these registers does, can't you provide
symbolic constants?
It would probably also help to separate these into logical groups (or
individual function calls if there are no meaningful groups). That way
you'll get automatic documentation via function names and this function
would look a lot less cluttered.
> +static int ps8622_backlight_get(struct backlight_device *bl)
> +{
> + return bl->props.brightness;
> +}
Backlight devices no longer need this kind of trivial implementation. It
is what the backlight core will do by default if the driver doesn't
implement .get_brightness().
> +static void ps8622_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ps8622_bridge *ps_bridge = bridge->driver_private;
> + int ret;
> +
> + mutex_lock(&ps_bridge->enable_mutex);
> + if (ps_bridge->enabled)
> + goto out;
> +
> + gpiod_set_value(ps_bridge->gpio_rst_n, 0);
> +
> + if (ps_bridge->v12) {
> + ret = regulator_enable(ps_bridge->v12);
> + if (ret)
> + DRM_ERROR("fails to enable ps_bridge->v12");
> + }
> +
> + drm_panel_prepare(ps_bridge->panel);
> +
> + gpiod_set_value(ps_bridge->gpio_slp_n, 1);
This uses high-active logic for the sleep pin, so shouldn't it rather be
named "gpio_slp"?
> + /*
> + * T1 is the range of time that it takes for the power to rise after we
> + * enable the lcd fet.
Is that the time it takes for the FET's power to rise? In that case it
would be a property of the FET, not the bridge.
> T2 is the range of time in which the data sheet
> + * specifies we should deassert the reset pin.
> + *
> + * If it takes T1.max for the power to rise, we need to wait atleast
> + * T2.min before deasserting the reset pin. If it takes T1.min for the
> + * power to rise, we need to wait at most T2.max before deasserting the
> + * reset pin.
> + */
Note that to my knowledge none of the sleep functions give you any
guarantees about the maximum amount of time they'll sleep, only the
minimum. So there's no such thing as "wait at most" in Linux.
> + usleep_range(PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US,
> + PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US);
> +
> + gpiod_set_value(ps_bridge->gpio_rst_n, 1);
This also uses high-active logic.
> + ret = ps8622_send_config(ps_bridge);
> + if (ret)
> + DRM_ERROR("Failed to send config to bridge (%d)\n", ret);
Isn't this a fatal error? What will be the consequences if this doesn't
succeed? I guess it doesn't matter much either way since the API can't
propagate errors at this point anyway...
> +static void ps8622_enable(struct drm_bridge *bridge)
> +{
> + struct ps8622_bridge *ps_bridge = bridge->driver_private;
> +
> + mutex_lock(&ps_bridge->enable_mutex);
> + drm_panel_enable(ps_bridge->panel);
> + mutex_unlock(&ps_bridge->enable_mutex);
What's the enable_mutex protecting here?
> +static void ps8622_disable(struct drm_bridge *bridge)
> +{
> + struct ps8622_bridge *ps_bridge = bridge->driver_private;
> +
> + mutex_lock(&ps_bridge->enable_mutex);
> +
> + if (!ps_bridge->enabled)
> + goto out;
> +
> + ps_bridge->enabled = false;
> +
> + drm_panel_disable(ps_bridge->panel);
> + msleep(PS8622_PWMO_END_T12_MS);
> +
> + /*
> + * This doesn't matter if the regulators are turned off, but something
> + * else might keep them on. In that case, we want to assert the slp gpio
> + * to lower power.
> + */
> + gpiod_set_value(ps_bridge->gpio_slp_n, 0);
> +
> + if (ps_bridge->v12)
> + regulator_disable(ps_bridge->v12);
> +
> + /*
> + * Sleep for at least the amount of time that it takes the power rail to
> + * fall to prevent asserting the rst gpio from doing anything.
> + */
> + usleep_range(PS8622_POWER_FALL_T16_MAX_US,
> + 2 * PS8622_POWER_FALL_T16_MAX_US);
> + gpiod_set_value(ps_bridge->gpio_rst_n, 0);
Does this even matter? Why would it be bad if the reset was asserted
before power went away? Isn't the end result that the chip will be off
and reset to an initial state the next time it's power up anyway?
> +static enum drm_connector_status ps8622_detect(struct drm_connector *connector,
> + bool force)
Alignment here is slightly odd. We usually follow (in DRM and many other
parts of the kernel) the convention of aligning arguments on subsequent
lines with the first argument on the first line.
> +int ps8622_post_encoder_init(struct drm_bridge *bridge)
> +{
> + struct ps8622_bridge *ps_bridge = bridge->driver_private;
> + int ret;
> +
> + /* bridge is attached to encoder.
> + * safe to remove it from the bridge_lookup table.
> + */
> + drm_bridge_remove_from_lookup(bridge);
Like I said for the ptn3460 driver, this should not be here.
> + ret = drm_bridge_init(bridge->drm_dev, bridge);
> + if (ret) {
> + DRM_ERROR("Failed to initialize bridge with drm\n");
> + return ret;
> + }
And this should probably happen somewhere else to avoid having to do it
for every driver.
> +static const struct of_device_id ps8622_devices[] = {
> + {
> + .compatible = "parade,ps8622",
> + .data = &ps8622_data,
> + }, {
> + .compatible = "parade,ps8625",
> + .data = &ps8625_data,
> + }, {
The above uses a mix of spaces and tabs for padding (tabs between .data
and =). Single spaces will do.
> + /* end node */
Nit: it's not a node, it's an entry or element.
> + }
> +};
> +MODULE_DEVICE_TABLE(of, ps8622_devices);
> +
> +static inline struct ps8622_device_data *get_device_data(struct device *dev)
> +{
> + const struct of_device_id *match =
> + of_match_device(ps8622_devices, dev);
> +
> + return (struct ps8622_device_data *)match->data;
> +}
Please drop this. First of all, match->data is void *, so there's no
need for the explicit casting. Second, match->data is also const, so
you're effectively casting that away.
> +
> +static int ps8622_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &(client->dev);
No need for the parentheses here.
> + struct device_node *panel_node, *backlight_node;
> + struct drm_bridge *bridge;
> + struct backlight_device *backlight_dev;
> + struct ps8622_bridge *ps_bridge;
Have you considered naming this simply "ps" to make it shorter? There's
some weird formatting below just because this is a very long variable
name.
> + const struct ps8622_device_data *device_data;
> + int ret;
It's just as easy (and shorter) to do this here:
const struct ps8622_device_data *data;
const struct of_device_id *match;
match = of_match_device(ps8622_devices, dev);
data = match->data;
> + bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
> + if (!bridge) {
> + DRM_ERROR("Failed to allocate drm bridge\n");
> + return -ENOMEM;
> + }
> +
> + ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
> + if (!ps_bridge) {
> + DRM_ERROR("could not allocate ps bridge\n");
> + return -ENOMEM;
> + }
> +
> + panel_node = of_parse_phandle(dev->of_node, "panel", 0);
> + if (panel_node) {
> + ps_bridge->panel = of_drm_find_panel(panel_node);
> + of_node_put(panel_node);
> + if (!ps_bridge->panel)
> + return -EPROBE_DEFER;
> + }
> +
> + backlight_dev = NULL;
It's more idiomatic to initialize these when you declare them to avoid
sprinkling them across the code like this.
> + backlight_node = of_parse_phandle(dev->of_node, "backlight", 0);
> + if (backlight_node) {
> + backlight_dev = of_find_backlight_by_node(backlight_node);
> + of_node_put(backlight_node);
> + if (!backlight_dev)
> + return -EPROBE_DEFER;
It seems like in this case you aren't storing the backlight anywhere. Is
there a reason for that? Is it because the same backlight is used by the
panel driver and it does the controlling from there? If so it might be
better to use a boolean property here rather than a phandle to another
backlight device. Using a phandle usually signal that you do want to use
the device in some way.
> + }
> +
> + mutex_init(&ps_bridge->enable_mutex);
> +
> + bridge->dev = dev;
> + bridge->driver_private = ps_bridge;
> + bridge->funcs = &ps8622_bridge_funcs;
> +
> + ps_bridge->client = client;
> + ps_bridge->bridge = bridge;
> +
> + device_data = get_device_data(dev);
> +
> + ps_bridge->v12 = devm_regulator_get(&client->dev, "vdd_bridge");
vdd_bridge is not a valid name for a regulator. This will translate to
vdd_bridge-supply for a DT property and you shouldn't be using
underscores for them. Also this property isn't documented in the
binding.
> + if (IS_ERR(ps_bridge->v12)) {
> + DRM_INFO("no 1.2v regulator found for PS8622\n");
> + ps_bridge->v12 = NULL;
> + }
Does this ever happen? As far as I know the regulator core will give you
a dummy regulator when booting using DT, so errors returned here will
always be real errors that you likely won't want to ignore.
> +
> + ps_bridge->gpio_slp_n = devm_gpiod_get(&client->dev, "sleep");
> + if (IS_ERR(ps_bridge->gpio_slp_n)) {
> + ret = PTR_ERR(ps_bridge->gpio_slp_n);
> + DRM_ERROR("cannot get gpio_slp_n %d\n", ret);
> + goto err_client;
> + } else {
> + ret = gpiod_direction_output(ps_bridge->gpio_slp_n, 1);
> + if (ret) {
> + DRM_ERROR("cannot configure gpio_slp_n\n");
> + goto err_client;
> + }
> + }
> +
> + ps_bridge->gpio_rst_n = devm_gpiod_get(&client->dev, "reset");
> + if (IS_ERR(ps_bridge->gpio_rst_n)) {
> + ret = PTR_ERR(ps_bridge->gpio_rst_n);
> + DRM_ERROR("cannot get gpio_rst_n %d\n", ret);
> + goto err_client;
> + } else {
> + /*
> + * Assert the reset pin high to avoid the bridge being
> + * initialized prematurely
> + */
> + ret = gpiod_direction_output(ps_bridge->gpio_rst_n, 1);
> + if (ret) {
> + DRM_ERROR("cannot configure gpio_slp_n\n");
> + goto err_client;
> + }
> + }
Just as a side-note, there's an API under discussion that will allow
gpio_desc's to be configured at the same time as they are requested.
This driver should probably convert to that API.
> + ps_bridge->max_lane_count = device_data->max_lane_count;
> +
> + if (of_property_read_u8(dev->of_node, "lane-count",
> + &ps_bridge->lane_count))
> + ps_bridge->lane_count = ps_bridge->max_lane_count;
> + else if (ps_bridge->lane_count > ps_bridge->max_lane_count) {
> + DRM_INFO("lane-count property is too high for DP bridge\n");
> + ps_bridge->lane_count = ps_bridge->max_lane_count;
> + }
Perhaps this should clarify that you're falling back to max_lane_count.
> +
> + if (!backlight_dev) {
> + ps_bridge->bl = backlight_device_register("ps8622-backlight",
> + dev, ps_bridge, &ps8622_backlight_ops,
> + NULL);
> + if (IS_ERR(ps_bridge->bl)) {
> + DRM_ERROR("failed to register backlight\n");
> + ret = PTR_ERR(ps_bridge->bl);
> + ps_bridge->bl = NULL;
No need to set this to NULL since you'll return with an error and
ps_bridge will be freed.
> + goto err_client;
> + }
> + ps_bridge->bl->props.max_brightness = PS8622_MAX_BRIGHTNESS;
> + ps_bridge->bl->props.brightness = PS8622_MAX_BRIGHTNESS;
Perhaps you want to initialize bl->props.power to FB_BLANK_POWERDOWN at
this point. The reason is that if you don't then the backlight will be
on by default (FB_BLANK_UNBLANK == 0). Many backlight drivers do call
backlight_update_status() after registering with the core to set the
initial state. It looks like you're not doing that here, but it might be
better to still set this to reflect what the initial state should be.
I'm assuming you want it disabled to avoid visual glitches when you turn
on the display. Of course if the bootloader already turned it on and
initialized the display, then you'll get flickering... but I guess
that's a problem to solve another day.
> + }
> +
> + i2c_set_clientdata(client, ps_bridge);
> +
> + drm_bridge_add_for_lookup(bridge);
> +
> + return 0;
> +
> +err_client:
> + DRM_ERROR("device probe failed : %d\n", ret);
No need for this. The driver core typically tells you already.
> +static int ps8622_remove(struct i2c_client *client)
> +{
> + struct ps8622_bridge *ps_bridge = i2c_get_clientdata(client);
> +
> + if (ps_bridge->bl)
> + backlight_device_unregister(ps_bridge->bl);
> +
> + return 0;
> +}
You'll also want to call drm_bridge_remove() here.
> +static const struct i2c_device_id ps8622_i2c_table[] = {
> + {"parade", 0},
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, ps8622_i2c_table);
This table doesn't look right. Shouldn't that be:
{ "ps8622", 0 },
{ "ps8625", 0 },
? And perhaps use the .driver_data field to refer to the device data
like for the of_device_id table?
> +struct i2c_driver ps8622_driver = {
> + .id_table = ps8622_i2c_table,
> + .probe = ps8622_probe,
> + .remove = ps8622_remove,
> + .driver = {
> + .name = "parade",
That's an awfully generic name. I'd suggest "ps8622".
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(ps8622_devices),
As for ptn3460, this has a hard dependency on OF, so of_match_ptr()
isn't useful.
> + },
> +};
> +module_i2c_driver(ps8622_driver);
> +
> +MODULE_AUTHOR("Vincent Palatin <vpalatin@chromium.org>");
> +MODULE_DESCRIPTION("Parade ps8622 eDP-LVDS converter driver");
> +MODULE_LICENSE("GPL");
"GPL v2"
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
` (7 preceding siblings ...)
2014-07-25 19:22 ` [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge Ajay Kumar
@ 2014-07-27 18:22 ` Andreas Färber
2014-07-28 6:13 ` Ajay kumar
2014-07-30 9:56 ` Thierry Reding
9 siblings, 1 reply; 70+ messages in thread
From: Andreas Färber @ 2014-07-27 18:22 UTC (permalink / raw)
To: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree
Cc: inki.dae, thierry.reding, robdclark, daniel.vetter, seanpaul,
ajaynumb, jg1.han, joshi, prashanth.g
Hi Ajay,
Am 25.07.2014 21:22, schrieb Ajay Kumar:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(&ptn_bridge->connector);
^
cc1: some warnings being treated as errors
scripts/Makefile.build:257: recipe for target
'drivers/gpu/drm/bridge/ptn3460.o' failed
make[4]: *** [drivers/gpu/drm/bridge/ptn3460.o] Error 1
scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm/bridge'
failed
make[3]: *** [drivers/gpu/drm/bridge] Error 2
make[3]: *** Warte auf noch nicht beendete Prozesse...
scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:899: recipe for target 'drivers' failed
make: *** [drivers] Error 2
Any hint which prerequisite I'm missing? Didn't spot it in Inki's tree,
and it must be new since v4.
Thanks,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-27 18:22 ` [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Andreas Färber
@ 2014-07-28 6:13 ` Ajay kumar
2014-07-29 11:21 ` Andreas Färber
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-28 6:13 UTC (permalink / raw)
To: Andreas Färber
Cc: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree, inki.dae,
thierry.reding, robdclark, daniel.vetter, seanpaul, jg1.han,
joshi, prashanth.g
Hi Andreas,
On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
> Hi Ajay,
>
> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>> I have tested this after adding few DT changes for exynos5250-snow,
>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>
> I'm trying to test this with a modified exynos5250-spring DT based off
> kgene's for-next branch due to DT, and I run into the following:
>
> CC drivers/gpu/drm/bridge/ptn3460.o
> drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
> drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
> function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
> drm_connector_register(&ptn_bridge->connector);
> ^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
Switch back to drm_sysfs_connector_add if your kernel doesn't have this patch.
Ajay
> cc1: some warnings being treated as errors
> scripts/Makefile.build:257: recipe for target
> 'drivers/gpu/drm/bridge/ptn3460.o' failed
> make[4]: *** [drivers/gpu/drm/bridge/ptn3460.o] Error 1
> scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm/bridge'
> failed
> make[3]: *** [drivers/gpu/drm/bridge] Error 2
> make[3]: *** Warte auf noch nicht beendete Prozesse...
> scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:404: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:899: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
>
> Any hint which prerequisite I'm missing? Didn't spot it in Inki's tree,
> and it must be new since v4.
>
> Thanks,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-28 6:13 ` Ajay kumar
@ 2014-07-29 11:21 ` Andreas Färber
2014-07-29 11:36 ` Thierry Reding
2014-07-30 6:21 ` Ajay kumar
0 siblings, 2 replies; 70+ messages in thread
From: Andreas Färber @ 2014-07-29 11:21 UTC (permalink / raw)
To: Ajay kumar
Cc: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree, inki.dae,
thierry.reding, robdclark, daniel.vetter, seanpaul, jg1.han,
joshi, prashanth.g, Doug Anderson, Javier Martinez Canillas
[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> I have tested this after adding few DT changes for exynos5250-snow,
>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>
>> I'm trying to test this with a modified exynos5250-spring DT based off
>> kgene's for-next branch due to DT, and I run into the following:
>>
>> CC drivers/gpu/drm/bridge/ptn3460.o
>> drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
>> drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
>> function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
>> drm_connector_register(&ptn_bridge->connector);
>> ^
> Hope this might help:
> http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ARM-dts-exynos5250-Add-eDP-LVDS-bridge-to-Spring.patch --]
[-- Type: text/x-patch; name="0001-ARM-dts-exynos5250-Add-eDP-LVDS-bridge-to-Spring.patch", Size: 2179 bytes --]
>From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
[AF: Redone for v6]
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = <&s5m_ldo8_reg>;
};
+ panel: panel {
+ compatible = "simple-panel";
+ };
+
dp-controller@145B0000 {
status = "okay";
pinctrl-names = "default";
- pinctrl-0 = <&dp_hpd>;
+ pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
samsung,dynamic-range = <0>;
samsung,ycbcr-coeff = <0>;
@@ -75,6 +79,7 @@
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
samsung,hpd-gpio = <&gpc3 0 0>;
+ bridge = <&ps8622>;
};
fixed-rate-clocks {
@@ -387,6 +392,17 @@
status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
+
+ ps8622: ps8622-bridge@08 {
+ compatible = "parade,ps8622";
+ reg = <0x08>;
+ sleep-gpios = <&gpc3 6 0>;
+ reset-gpios = <&gpc3 1 0>;
+ lane-count = <1>;
+ panel = <&panel>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ps8622_gpios>;
+ };
};
&i2c_8 {
@@ -450,6 +466,20 @@
samsung,pin-pud = <0>;
};
+ dp_hpd_gpio: dp-hpd-gpio {
+ samsung,pins = "gpc3-0";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ ps8622_gpios: ps8622-gpios {
+ samsung,pins = "gpc3-1", "gpc3-6";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
s5m8767_dvs: s5m8767-dvs {
samsung,pins = "gpd1-0", "gpd1-1", "gpd1-2";
samsung,pin-function = <0>;
--
1.9.3
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-29 11:21 ` Andreas Färber
@ 2014-07-29 11:36 ` Thierry Reding
2014-07-29 11:42 ` Andreas Färber
2014-07-29 11:43 ` Thierry Reding
2014-07-30 6:21 ` Ajay kumar
1 sibling, 2 replies; 70+ messages in thread
From: Thierry Reding @ 2014-07-29 11:36 UTC (permalink / raw)
To: Andreas Färber
Cc: Ajay kumar, Ajay Kumar, dri-devel, linux-samsung-soc, devicetree,
inki.dae, robdclark, daniel.vetter, seanpaul, jg1.han, joshi,
prashanth.g, Doug Anderson, Javier Martinez Canillas
[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
> Hi Ajay,
>
> Am 28.07.2014 08:13, schrieb Ajay kumar:
> > On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
> >> Am 25.07.2014 21:22, schrieb Ajay Kumar:
> >>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> >>>
> >>> I have tested this after adding few DT changes for exynos5250-snow,
> >>> exynos5420-peach-pit and exynos5800-peach-pi boards.
> >>
> >> I'm trying to test this with a modified exynos5250-spring DT based off
> >> kgene's for-next branch due to DT, and I run into the following:
> >>
> >> CC drivers/gpu/drm/bridge/ptn3460.o
> >> drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
> >> drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
> >> function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
> >> drm_connector_register(&ptn_bridge->connector);
> >> ^
> > Hope this might help:
> > http://www.spinics.net/lists/dri-devel/msg60578.html
>
> That fixed my build, thanks.
>
> Unfortunately the most I got on Spring with attached DT was a blank
> screen with a white horizontal line in the middle.
>
> Do I need to specify a specific panel model for Spring?
>
> For testing I re-applied your iommu patches (which btw fail now for 5420
> due to disp_pd) but didn't know what to do about your panel-lvds
> regulator patch now that it's gone.
>
> If I don't apply this series, then commenting out the dp-controller node
> gets me a working display with simplefb as before.
>
> Regards,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
> Date: Sun, 27 Jul 2014 21:58:06 +0200
> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> [AF: Redone for v6]
> Signed-off-by: Andreas F??rber <afaerber@suse.de>
> ---
> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
> index 687dfab86bc8..517b1ff2bfdf 100644
> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> @@ -64,10 +64,14 @@
> vdd_pll-supply = <&s5m_ldo8_reg>;
> };
>
> + panel: panel {
> + compatible = "simple-panel";
> + };
You can't do this. "simple-panel" isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-29 11:36 ` Thierry Reding
@ 2014-07-29 11:42 ` Andreas Färber
2014-07-29 11:47 ` Thierry Reding
2014-07-29 11:43 ` Thierry Reding
1 sibling, 1 reply; 70+ messages in thread
From: Andreas Färber @ 2014-07-29 11:42 UTC (permalink / raw)
To: Thierry Reding
Cc: Ajay kumar, Ajay Kumar, dri-devel, linux-samsung-soc, devicetree,
inki.dae, robdclark, daniel.vetter, seanpaul, jg1.han, joshi,
prashanth.g, Doug Anderson, Javier Martinez Canillas
[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]
Am 29.07.2014 13:36, schrieb Thierry Reding:
> On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
>> Hi Ajay,
>>
>> Am 28.07.2014 08:13, schrieb Ajay kumar:
>>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>>>
>>>>> I have tested this after adding few DT changes for exynos5250-snow,
>>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>>>
>>>> I'm trying to test this with a modified exynos5250-spring DT
[...]
>> Unfortunately the most I got on Spring with attached DT was a blank
>> screen with a white horizontal line in the middle.
>>
>> Do I need to specify a specific panel model for Spring?
[...]
>> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
>> Date: Sun, 27 Jul 2014 21:58:06 +0200
>> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> [AF: Redone for v6]
>> Signed-off-by: Andreas F??rber <afaerber@suse.de>
>> ---
>> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++-
>> 1 file changed, 31 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
>> index 687dfab86bc8..517b1ff2bfdf 100644
>> --- a/arch/arm/boot/dts/exynos5250-spring.dts
>> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
>> @@ -64,10 +64,14 @@
>> vdd_pll-supply = <&s5m_ldo8_reg>;
>> };
>>
>> + panel: panel {
>> + compatible = "simple-panel";
>> + };
>
> You can't do this. "simple-panel" isn't a valid panel model. It should
> probably be removed from the platform_of_match table in the driver.
Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/
And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-29 11:42 ` Andreas Färber
@ 2014-07-29 11:47 ` Thierry Reding
2014-07-30 6:24 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Thierry Reding @ 2014-07-29 11:47 UTC (permalink / raw)
To: Andreas Färber
Cc: devicetree, linux-samsung-soc, seanpaul, daniel.vetter, joshi,
dri-devel, Doug Anderson, Javier Martinez Canillas, Ajay kumar,
prashanth.g, Ajay Kumar
[-- Attachment #1.1: Type: text/plain, Size: 2943 bytes --]
On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
> Am 29.07.2014 13:36, schrieb Thierry Reding:
> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
> >> Hi Ajay,
> >>
> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> >>>>>
> >>>>> I have tested this after adding few DT changes for exynos5250-snow,
> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
> >>>>
> >>>> I'm trying to test this with a modified exynos5250-spring DT
> [...]
> >> Unfortunately the most I got on Spring with attached DT was a blank
> >> screen with a white horizontal line in the middle.
> >>
> >> Do I need to specify a specific panel model for Spring?
> [...]
> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> >> MIME-Version: 1.0
> >> Content-Type: text/plain; charset=UTF-8
> >> Content-Transfer-Encoding: 8bit
> >>
> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> >> [AF: Redone for v6]
> >> Signed-off-by: Andreas F??rber <afaerber@suse.de>
> >> ---
> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++-
> >> 1 file changed, 31 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
> >> index 687dfab86bc8..517b1ff2bfdf 100644
> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> >> @@ -64,10 +64,14 @@
> >> vdd_pll-supply = <&s5m_ldo8_reg>;
> >> };
> >>
> >> + panel: panel {
> >> + compatible = "simple-panel";
> >> + };
> >
> > You can't do this. "simple-panel" isn't a valid panel model. It should
> > probably be removed from the platform_of_match table in the driver.
>
> Okay, that means the Snow DT is wrong, too:
> https://patchwork.kernel.org/patch/4625441/
>
> And the others specify it as fallback:
> https://patchwork.kernel.org/patch/4625461/
> https://patchwork.kernel.org/patch/4625451/
A quick grep shows that many (all?) devices that use DRM panels provide
simple-panel as fallback. That's probably fine as long as they also do
provide the specific model. But given that simple-panel does not have a
mode or physical size, I don't think even that makes sense.
Any of the DTS files in the tree I have that list simple-panel as a
fallback are Tegra, so I'll go write a patch that removes the fallback.
I can't think of a reason why it would ever be needed or meaningful.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-29 11:47 ` Thierry Reding
@ 2014-07-30 6:24 ` Ajay kumar
2014-07-30 9:40 ` Thierry Reding
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 6:24 UTC (permalink / raw)
To: Thierry Reding
Cc: Doug Anderson, devicetree, linux-samsung-soc, Sean Paul,
Daniel Vetter, sunil joshi, dri-devel, Ajay Kumar,
Javier Martinez Canillas, Prashanth G, Andreas Färber
Hi Thierry,
On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
>> Am 29.07.2014 13:36, schrieb Thierry Reding:
>> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
>> >> Hi Ajay,
>> >>
>> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
>> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>> >>>>>
>> >>>>> I have tested this after adding few DT changes for exynos5250-snow,
>> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>> >>>>
>> >>>> I'm trying to test this with a modified exynos5250-spring DT
>> [...]
>> >> Unfortunately the most I got on Spring with attached DT was a blank
>> >> screen with a white horizontal line in the middle.
>> >>
>> >> Do I need to specify a specific panel model for Spring?
>> [...]
>> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
>> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
>> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
>> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
>> >> MIME-Version: 1.0
>> >> Content-Type: text/plain; charset=UTF-8
>> >> Content-Transfer-Encoding: 8bit
>> >>
>> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> >> [AF: Redone for v6]
>> >> Signed-off-by: Andreas F??rber <afaerber@suse.de>
>> >> ---
>> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++-
>> >> 1 file changed, 31 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
>> >> index 687dfab86bc8..517b1ff2bfdf 100644
>> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
>> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
>> >> @@ -64,10 +64,14 @@
>> >> vdd_pll-supply = <&s5m_ldo8_reg>;
>> >> };
>> >>
>> >> + panel: panel {
>> >> + compatible = "simple-panel";
>> >> + };
>> >
>> > You can't do this. "simple-panel" isn't a valid panel model. It should
>> > probably be removed from the platform_of_match table in the driver.
>>
>> Okay, that means the Snow DT is wrong, too:
>> https://patchwork.kernel.org/patch/4625441/
>>
>> And the others specify it as fallback:
>> https://patchwork.kernel.org/patch/4625461/
>> https://patchwork.kernel.org/patch/4625451/
>
> A quick grep shows that many (all?) devices that use DRM panels provide
> simple-panel as fallback. That's probably fine as long as they also do
> provide the specific model. But given that simple-panel does not have a
> mode or physical size, I don't think even that makes sense.
On snow, the bridge chip provides the display mode instead of the panel.
That is why display was working for me.
> Any of the DTS files in the tree I have that list simple-panel as a
> fallback are Tegra, so I'll go write a patch that removes the fallback.
> I can't think of a reason why it would ever be needed or meaningful.
Ok. I will resend DT patches removing "simple-panel" fallback.
Regards,
Ajay
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-30 6:24 ` Ajay kumar
@ 2014-07-30 9:40 ` Thierry Reding
2014-07-30 10:24 ` Ajay kumar
2014-09-17 9:53 ` Laurent Pinchart
0 siblings, 2 replies; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 9:40 UTC (permalink / raw)
To: Ajay kumar
Cc: Doug Anderson, devicetree, linux-samsung-soc, Sean Paul,
Daniel Vetter, sunil joshi, dri-devel, Ajay Kumar,
Javier Martinez Canillas, Prashanth G, Andreas Färber
[-- Attachment #1.1: Type: text/plain, Size: 4092 bytes --]
On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
> Hi Thierry,
>
> On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
> >> Am 29.07.2014 13:36, schrieb Thierry Reding:
> >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
> >> >> Hi Ajay,
> >> >>
> >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
> >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
> >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
> >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> >> >>>>>
> >> >>>>> I have tested this after adding few DT changes for exynos5250-snow,
> >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
> >> >>>>
> >> >>>> I'm trying to test this with a modified exynos5250-spring DT
> >> [...]
> >> >> Unfortunately the most I got on Spring with attached DT was a blank
> >> >> screen with a white horizontal line in the middle.
> >> >>
> >> >> Do I need to specify a specific panel model for Spring?
> >> [...]
> >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
> >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
> >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
> >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> >> >> MIME-Version: 1.0
> >> >> Content-Type: text/plain; charset=UTF-8
> >> >> Content-Transfer-Encoding: 8bit
> >> >>
> >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> >> >> [AF: Redone for v6]
> >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de>
> >> >> ---
> >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++-
> >> >> 1 file changed, 31 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
> >> >> index 687dfab86bc8..517b1ff2bfdf 100644
> >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> >> >> @@ -64,10 +64,14 @@
> >> >> vdd_pll-supply = <&s5m_ldo8_reg>;
> >> >> };
> >> >>
> >> >> + panel: panel {
> >> >> + compatible = "simple-panel";
> >> >> + };
> >> >
> >> > You can't do this. "simple-panel" isn't a valid panel model. It should
> >> > probably be removed from the platform_of_match table in the driver.
> >>
> >> Okay, that means the Snow DT is wrong, too:
> >> https://patchwork.kernel.org/patch/4625441/
> >>
> >> And the others specify it as fallback:
> >> https://patchwork.kernel.org/patch/4625461/
> >> https://patchwork.kernel.org/patch/4625451/
> >
> > A quick grep shows that many (all?) devices that use DRM panels provide
> > simple-panel as fallback. That's probably fine as long as they also do
> > provide the specific model. But given that simple-panel does not have a
> > mode or physical size, I don't think even that makes sense.
> On snow, the bridge chip provides the display mode instead of the panel.
> That is why display was working for me.
Okay, I suppose under some circumstances that might make sense. Although
it's still always the panel that dictates the display timings, so the
panel node needs to have a panel model specific compatible value with a
matching entry in the panel-simple driver so that it can even be used in
setups without a bridge.
One other thing: how does the bridge know which mode to drive? I suspect
that it can drive more than one mode? Can it freely be configured or
does it have a predefined set of modes? If the latter, then according to
what you said above there needs to be a way to configure the bridge (via
DT?) so that it reports the mode matching the panel. I wonder if that
should be handled completely in code, so that for example a bridge has a
panel attached it can use the panel's .get_modes() and select a matching
mode among the set that it supports.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-30 9:40 ` Thierry Reding
@ 2014-07-30 10:24 ` Ajay kumar
2014-07-30 13:16 ` Thierry Reding
2014-09-17 9:53 ` Laurent Pinchart
1 sibling, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 10:24 UTC (permalink / raw)
To: Thierry Reding
Cc: Doug Anderson, devicetree, linux-samsung-soc, Sean Paul,
Daniel Vetter, sunil joshi, dri-devel, Ajay Kumar,
Javier Martinez Canillas, Prashanth G, Andreas Färber
On Wed, Jul 30, 2014 at 3:10 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
>> Hi Thierry,
>>
>> On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
>> >> Am 29.07.2014 13:36, schrieb Thierry Reding:
>> >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
>> >> >> Hi Ajay,
>> >> >>
>> >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
>> >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>> >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>> >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>> >> >>>>>
>> >> >>>>> I have tested this after adding few DT changes for exynos5250-snow,
>> >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>> >> >>>>
>> >> >>>> I'm trying to test this with a modified exynos5250-spring DT
>> >> [...]
>> >> >> Unfortunately the most I got on Spring with attached DT was a blank
>> >> >> screen with a white horizontal line in the middle.
>> >> >>
>> >> >> Do I need to specify a specific panel model for Spring?
>> >> [...]
>> >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
>> >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
>> >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
>> >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
>> >> >> MIME-Version: 1.0
>> >> >> Content-Type: text/plain; charset=UTF-8
>> >> >> Content-Transfer-Encoding: 8bit
>> >> >>
>> >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> >> >> [AF: Redone for v6]
>> >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de>
>> >> >> ---
>> >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++-
>> >> >> 1 file changed, 31 insertions(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
>> >> >> index 687dfab86bc8..517b1ff2bfdf 100644
>> >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
>> >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
>> >> >> @@ -64,10 +64,14 @@
>> >> >> vdd_pll-supply = <&s5m_ldo8_reg>;
>> >> >> };
>> >> >>
>> >> >> + panel: panel {
>> >> >> + compatible = "simple-panel";
>> >> >> + };
>> >> >
>> >> > You can't do this. "simple-panel" isn't a valid panel model. It should
>> >> > probably be removed from the platform_of_match table in the driver.
>> >>
>> >> Okay, that means the Snow DT is wrong, too:
>> >> https://patchwork.kernel.org/patch/4625441/
>> >>
>> >> And the others specify it as fallback:
>> >> https://patchwork.kernel.org/patch/4625461/
>> >> https://patchwork.kernel.org/patch/4625451/
>> >
>> > A quick grep shows that many (all?) devices that use DRM panels provide
>> > simple-panel as fallback. That's probably fine as long as they also do
>> > provide the specific model. But given that simple-panel does not have a
>> > mode or physical size, I don't think even that makes sense.
>> On snow, the bridge chip provides the display mode instead of the panel.
>> That is why display was working for me.
>
> Okay, I suppose under some circumstances that might make sense. Although
> it's still always the panel that dictates the display timings, so the
> panel node needs to have a panel model specific compatible value with a
> matching entry in the panel-simple driver so that it can even be used in
> setups without a bridge.
Well, I am okay with adding the compatible value for specific panel model
because "simple-panel" alone cannot provide width/height of the panel.
> One other thing: how does the bridge know which mode to drive? I suspect
> that it can drive more than one mode? Can it freely be configured or
> does it have a predefined set of modes? If the latter, then according to
> what you said above there needs to be a way to configure the bridge (via
> DT?) so that it reports the mode matching the panel. I wonder if that
> should be handled completely in code, so that for example a bridge has a
> panel attached it can use the panel's .get_modes() and select a matching
> mode among the set that it supports.
ptn3460 supports a standard list of "edid-emulation" ids.
As of now, we receive that as a DT entry.
And, these are the list of emulation ids supported:
| 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
As you can see, the same resolutions have different emulator ids.
May be, it depends on panel vendor also. I am really not sure if we can do this.
For snow(which has 1366x768 panel), we set edid-emulation as 5.
Ajay
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-30 10:24 ` Ajay kumar
@ 2014-07-30 13:16 ` Thierry Reding
0 siblings, 0 replies; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 13:16 UTC (permalink / raw)
To: Ajay kumar
Cc: Doug Anderson, devicetree, linux-samsung-soc, Sean Paul,
Daniel Vetter, sunil joshi, dri-devel, Ajay Kumar,
Javier Martinez Canillas, Prashanth G, Andreas Färber
[-- Attachment #1.1: Type: text/plain, Size: 6087 bytes --]
On Wed, Jul 30, 2014 at 03:54:13PM +0530, Ajay kumar wrote:
> On Wed, Jul 30, 2014 at 3:10 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
> >> Hi Thierry,
> >>
> >> On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
> >> <thierry.reding@gmail.com> wrote:
> >> > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
> >> >> Am 29.07.2014 13:36, schrieb Thierry Reding:
> >> >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
> >> >> >> Hi Ajay,
> >> >> >>
> >> >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
> >> >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
> >> >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
> >> >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> >> >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> >> >> >>>>>
> >> >> >>>>> I have tested this after adding few DT changes for exynos5250-snow,
> >> >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
> >> >> >>>>
> >> >> >>>> I'm trying to test this with a modified exynos5250-spring DT
> >> >> [...]
> >> >> >> Unfortunately the most I got on Spring with attached DT was a blank
> >> >> >> screen with a white horizontal line in the middle.
> >> >> >>
> >> >> >> Do I need to specify a specific panel model for Spring?
> >> >> [...]
> >> >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
> >> >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
> >> >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
> >> >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> >> >> >> MIME-Version: 1.0
> >> >> >> Content-Type: text/plain; charset=UTF-8
> >> >> >> Content-Transfer-Encoding: 8bit
> >> >> >>
> >> >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> >> >> >> [AF: Redone for v6]
> >> >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de>
> >> >> >> ---
> >> >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++-
> >> >> >> 1 file changed, 31 insertions(+), 1 deletion(-)
> >> >> >>
> >> >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
> >> >> >> index 687dfab86bc8..517b1ff2bfdf 100644
> >> >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> >> >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> >> >> >> @@ -64,10 +64,14 @@
> >> >> >> vdd_pll-supply = <&s5m_ldo8_reg>;
> >> >> >> };
> >> >> >>
> >> >> >> + panel: panel {
> >> >> >> + compatible = "simple-panel";
> >> >> >> + };
> >> >> >
> >> >> > You can't do this. "simple-panel" isn't a valid panel model. It should
> >> >> > probably be removed from the platform_of_match table in the driver.
> >> >>
> >> >> Okay, that means the Snow DT is wrong, too:
> >> >> https://patchwork.kernel.org/patch/4625441/
> >> >>
> >> >> And the others specify it as fallback:
> >> >> https://patchwork.kernel.org/patch/4625461/
> >> >> https://patchwork.kernel.org/patch/4625451/
> >> >
> >> > A quick grep shows that many (all?) devices that use DRM panels provide
> >> > simple-panel as fallback. That's probably fine as long as they also do
> >> > provide the specific model. But given that simple-panel does not have a
> >> > mode or physical size, I don't think even that makes sense.
> >> On snow, the bridge chip provides the display mode instead of the panel.
> >> That is why display was working for me.
> >
> > Okay, I suppose under some circumstances that might make sense. Although
> > it's still always the panel that dictates the display timings, so the
> > panel node needs to have a panel model specific compatible value with a
> > matching entry in the panel-simple driver so that it can even be used in
> > setups without a bridge.
> Well, I am okay with adding the compatible value for specific panel model
> because "simple-panel" alone cannot provide width/height of the panel.
>
> > One other thing: how does the bridge know which mode to drive? I suspect
> > that it can drive more than one mode? Can it freely be configured or
> > does it have a predefined set of modes? If the latter, then according to
> > what you said above there needs to be a way to configure the bridge (via
> > DT?) so that it reports the mode matching the panel. I wonder if that
> > should be handled completely in code, so that for example a bridge has a
> > panel attached it can use the panel's .get_modes() and select a matching
> > mode among the set that it supports.
> ptn3460 supports a standard list of "edid-emulation" ids.
> As of now, we receive that as a DT entry.
> And, these are the list of emulation ids supported:
>
> | 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
>
> As you can see, the same resolutions have different emulator ids.
> May be, it depends on panel vendor also. I am really not sure if we can do this.
> For snow(which has 1366x768 panel), we set edid-emulation as 5.
Well, modes 1, 2 and 4 as well as modes 3 and 6 must differ in some
ways, otherwise there wouldn't be much point in using different IDs for
them. You could try to match on more than just the active horizontal and
vertical resolution.
The reason behind this is that it would allow us to keep the device tree
content to a minimum and determine the proper emulation ID at runtime.
But if it's too difficult to implement I won't object to keeping the
edid-emulation property in DT. It just means that the device tree will
contain some duplicate information that needs to be kept in sync.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-30 9:40 ` Thierry Reding
2014-07-30 10:24 ` Ajay kumar
@ 2014-09-17 9:53 ` Laurent Pinchart
2014-09-17 10:13 ` Ajay kumar
1 sibling, 1 reply; 70+ messages in thread
From: Laurent Pinchart @ 2014-09-17 9:53 UTC (permalink / raw)
To: dri-devel
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
Doug Anderson, sunil joshi, Javier Martinez Canillas,
Andreas Färber, Ajay kumar, Prashanth G, Ajay Kumar
Hi Thierry,
On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
> > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote:
> > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
> > >> Am 29.07.2014 13:36, schrieb Thierry Reding:
> > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
> > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
> > >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
> > >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
> > >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree
> > >> >>>>> at:
> > >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.
> > >> >>>>> git
> > >> >>>>>
> > >> >>>>> I have tested this after adding few DT changes for
> > >> >>>>> exynos5250-snow,
> > >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
> > >> >>>>
> > >> >>>> I'm trying to test this with a modified exynos5250-spring DT
> > >>
> > >> [...]
> > >>
> > >> >> Unfortunately the most I got on Spring with attached DT was a blank
> > >> >> screen with a white horizontal line in the middle.
> > >> >>
> > >> >> Do I need to specify a specific panel model for Spring?
> > >>
> > >> [...]
> > >>
> > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
> > >> >> 2001
> > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
> > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
> > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> > >> >> MIME-Version: 1.0
> > >> >> Content-Type: text/plain; charset=UTF-8
> > >> >> Content-Transfer-Encoding: 8bit
> > >> >>
> > >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> > >> >> [AF: Redone for v6]
> > >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de>
> > >> >> ---
> > >> >>
> > >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++-
> > >> >> 1 file changed, 31 insertions(+), 1 deletion(-)
> > >> >>
> > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> b/arch/arm/boot/dts/exynos5250-spring.dts index
> > >> >> 687dfab86bc8..517b1ff2bfdf 100644
> > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> @@ -64,10 +64,14 @@
> > >> >> vdd_pll-supply = <&s5m_ldo8_reg>;
> > >> >> };
> > >> >>
> > >> >> + panel: panel {
> > >> >> + compatible = "simple-panel";
> > >> >> + };
> > >> >
> > >> > You can't do this. "simple-panel" isn't a valid panel model. It
> > >> > should probably be removed from the platform_of_match table in the
> > >> > driver.
> > >>
> > >> Okay, that means the Snow DT is wrong, too:
> > >> https://patchwork.kernel.org/patch/4625441/
> > >>
> > >> And the others specify it as fallback:
> > >> https://patchwork.kernel.org/patch/4625461/
> > >> https://patchwork.kernel.org/patch/4625451/
> > >
> > > A quick grep shows that many (all?) devices that use DRM panels provide
> > > simple-panel as fallback. That's probably fine as long as they also do
> > > provide the specific model. But given that simple-panel does not have a
> > > mode or physical size, I don't think even that makes sense.
> >
> > On snow, the bridge chip provides the display mode instead of the panel.
> > That is why display was working for me.
>
> Okay, I suppose under some circumstances that might make sense. Although
> it's still always the panel that dictates the display timings, so the
> panel node needs to have a panel model specific compatible value with a
> matching entry in the panel-simple driver so that it can even be used in
> setups without a bridge.
>
> One other thing: how does the bridge know which mode to drive? I suspect
> that it can drive more than one mode? Can it freely be configured or
> does it have a predefined set of modes? If the latter, then according to
> what you said above there needs to be a way to configure the bridge (via
> DT?) so that it reports the mode matching the panel. I wonder if that
> should be handled completely in code, so that for example a bridge has a
> panel attached it can use the panel's .get_modes() and select a matching
> mode among the set that it supports.
Yes, pretty please :-) I don't think it would be a good idea to duplicate mode
information in the bridge DT node, as that's not a property of the bridge.
Querying the mode at runtime is in my opinion a much better option, and would
also allow switching between different modes at runtime when that makes sense.
Now, I'm not sure whether it should be the bridge driver querying the panel
driver directly, or the display controller driver doing it and then
configuring the bridge accordingly. The latter seems more generic to me and
doesn't rely on the assumption that the bridge output will always be directly
connected to a panel.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-09-17 9:53 ` Laurent Pinchart
@ 2014-09-17 10:13 ` Ajay kumar
2014-09-18 9:54 ` Laurent Pinchart
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-09-17 10:13 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
Doug Anderson, dri-devel, sunil joshi, Javier Martinez Canillas,
Andreas Färber, Prashanth G, Ajay Kumar
Hi Laurent,
Please find the latest series here:
http://www.spinics.net/lists/dri-devel/msg66740.html
On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Thierry,
>
> On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
>> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
>> > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote:
>> > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
>> > >> Am 29.07.2014 13:36, schrieb Thierry Reding:
>> > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
>> > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
>> > >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>> > >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> > >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree
>> > >> >>>>> at:
>> > >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.
>> > >> >>>>> git
>> > >> >>>>>
>> > >> >>>>> I have tested this after adding few DT changes for
>> > >> >>>>> exynos5250-snow,
>> > >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>> > >> >>>>
>> > >> >>>> I'm trying to test this with a modified exynos5250-spring DT
>> > >>
>> > >> [...]
>> > >>
>> > >> >> Unfortunately the most I got on Spring with attached DT was a blank
>> > >> >> screen with a white horizontal line in the middle.
>> > >> >>
>> > >> >> Do I need to specify a specific panel model for Spring?
>> > >>
>> > >> [...]
>> > >>
>> > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
>> > >> >> 2001
>> > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
>> > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
>> > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
>> > >> >> MIME-Version: 1.0
>> > >> >> Content-Type: text/plain; charset=UTF-8
>> > >> >> Content-Transfer-Encoding: 8bit
>> > >> >>
>> > >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> > >> >> [AF: Redone for v6]
>> > >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de>
>> > >> >> ---
>> > >> >>
>> > >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++-
>> > >> >> 1 file changed, 31 insertions(+), 1 deletion(-)
>> > >> >>
>> > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
>> > >> >> b/arch/arm/boot/dts/exynos5250-spring.dts index
>> > >> >> 687dfab86bc8..517b1ff2bfdf 100644
>> > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
>> > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
>> > >> >> @@ -64,10 +64,14 @@
>> > >> >> vdd_pll-supply = <&s5m_ldo8_reg>;
>> > >> >> };
>> > >> >>
>> > >> >> + panel: panel {
>> > >> >> + compatible = "simple-panel";
>> > >> >> + };
>> > >> >
>> > >> > You can't do this. "simple-panel" isn't a valid panel model. It
>> > >> > should probably be removed from the platform_of_match table in the
>> > >> > driver.
>> > >>
>> > >> Okay, that means the Snow DT is wrong, too:
>> > >> https://patchwork.kernel.org/patch/4625441/
>> > >>
>> > >> And the others specify it as fallback:
>> > >> https://patchwork.kernel.org/patch/4625461/
>> > >> https://patchwork.kernel.org/patch/4625451/
>> > >
>> > > A quick grep shows that many (all?) devices that use DRM panels provide
>> > > simple-panel as fallback. That's probably fine as long as they also do
>> > > provide the specific model. But given that simple-panel does not have a
>> > > mode or physical size, I don't think even that makes sense.
>> >
>> > On snow, the bridge chip provides the display mode instead of the panel.
>> > That is why display was working for me.
>>
>> Okay, I suppose under some circumstances that might make sense. Although
>> it's still always the panel that dictates the display timings, so the
>> panel node needs to have a panel model specific compatible value with a
>> matching entry in the panel-simple driver so that it can even be used in
>> setups without a bridge.
>>
>> One other thing: how does the bridge know which mode to drive? I suspect
>> that it can drive more than one mode? Can it freely be configured or
>> does it have a predefined set of modes? If the latter, then according to
>> what you said above there needs to be a way to configure the bridge (via
>> DT?) so that it reports the mode matching the panel. I wonder if that
>> should be handled completely in code, so that for example a bridge has a
>> panel attached it can use the panel's .get_modes() and select a matching
>> mode among the set that it supports.
>
> Yes, pretty please :-) I don't think it would be a good idea to duplicate mode
> information in the bridge DT node, as that's not a property of the bridge.
> Querying the mode at runtime is in my opinion a much better option, and would
> also allow switching between different modes at runtime when that makes sense.
>
> Now, I'm not sure whether it should be the bridge driver querying the panel
> driver directly, or the display controller driver doing it and then
> configuring the bridge accordingly. The latter seems more generic to me and
> doesn't rely on the assumption that the bridge output will always be directly
> connected to a panel.
>
> --
> Regards,
>
> Laurent Pinchart
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-09-17 10:13 ` Ajay kumar
@ 2014-09-18 9:54 ` Laurent Pinchart
0 siblings, 0 replies; 70+ messages in thread
From: Laurent Pinchart @ 2014-09-18 9:54 UTC (permalink / raw)
To: Ajay kumar
Cc: dri-devel, Thierry Reding, Doug Anderson, devicetree,
linux-samsung-soc, Sean Paul, Daniel Vetter, sunil joshi,
Ajay Kumar, Javier Martinez Canillas, Prashanth G,
Andreas Färber
Hi Ajay,
On Wednesday 17 September 2014 15:43:04 Ajay kumar wrote:
> Hi Laurent,
>
> Please find the latest series here:
> http://www.spinics.net/lists/dri-devel/msg66740.html
Thank you. My comment was meant to be general though, not just for your patch
series.
> On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart wrote:
> > On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
[snip]
> >> One other thing: how does the bridge know which mode to drive? I suspect
> >> that it can drive more than one mode? Can it freely be configured or
> >> does it have a predefined set of modes? If the latter, then according to
> >> what you said above there needs to be a way to configure the bridge (via
> >> DT?) so that it reports the mode matching the panel. I wonder if that
> >> should be handled completely in code, so that for example a bridge has a
> >> panel attached it can use the panel's .get_modes() and select a matching
> >> mode among the set that it supports.
> >
> > Yes, pretty please :-) I don't think it would be a good idea to duplicate
> > mode information in the bridge DT node, as that's not a property of the
> > bridge. Querying the mode at runtime is in my opinion a much better
> > option, and would also allow switching between different modes at runtime
> > when that makes sense.
> >
> > Now, I'm not sure whether it should be the bridge driver querying the
> > panel driver directly, or the display controller driver doing it and then
> > configuring the bridge accordingly. The latter seems more generic to me
> > and doesn't rely on the assumption that the bridge output will always be
> > directly connected to a panel.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-29 11:36 ` Thierry Reding
2014-07-29 11:42 ` Andreas Färber
@ 2014-07-29 11:43 ` Thierry Reding
1 sibling, 0 replies; 70+ messages in thread
From: Thierry Reding @ 2014-07-29 11:43 UTC (permalink / raw)
To: Andreas Färber
Cc: devicetree, linux-samsung-soc, seanpaul, daniel.vetter, joshi,
dri-devel, Doug Anderson, Javier Martinez Canillas, Ajay kumar,
prashanth.g, Ajay Kumar
[-- Attachment #1.1: Type: text/plain, Size: 3251 bytes --]
On Tue, Jul 29, 2014 at 01:36:46PM +0200, Thierry Reding wrote:
> On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
> > Hi Ajay,
> >
> > Am 28.07.2014 08:13, schrieb Ajay kumar:
> > > On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
> > >> Am 25.07.2014 21:22, schrieb Ajay Kumar:
> > >>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> > >>>
> > >>> I have tested this after adding few DT changes for exynos5250-snow,
> > >>> exynos5420-peach-pit and exynos5800-peach-pi boards.
> > >>
> > >> I'm trying to test this with a modified exynos5250-spring DT based off
> > >> kgene's for-next branch due to DT, and I run into the following:
> > >>
> > >> CC drivers/gpu/drm/bridge/ptn3460.o
> > >> drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
> > >> drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
> > >> function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
> > >> drm_connector_register(&ptn_bridge->connector);
> > >> ^
> > > Hope this might help:
> > > http://www.spinics.net/lists/dri-devel/msg60578.html
> >
> > That fixed my build, thanks.
> >
> > Unfortunately the most I got on Spring with attached DT was a blank
> > screen with a white horizontal line in the middle.
> >
> > Do I need to specify a specific panel model for Spring?
> >
> > For testing I re-applied your iommu patches (which btw fail now for 5420
> > due to disp_pd) but didn't know what to do about your panel-lvds
> > regulator patch now that it's gone.
> >
> > If I don't apply this series, then commenting out the dp-controller node
> > gets me a working display with simplefb as before.
> >
> > Regards,
> > Andreas
> >
> > --
> > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>
> > From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
> > Date: Sun, 27 Jul 2014 21:58:06 +0200
> > Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> > [AF: Redone for v6]
> > Signed-off-by: Andreas F??rber <afaerber@suse.de>
> > ---
> > arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++-
> > 1 file changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
> > index 687dfab86bc8..517b1ff2bfdf 100644
> > --- a/arch/arm/boot/dts/exynos5250-spring.dts
> > +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> > @@ -64,10 +64,14 @@
> > vdd_pll-supply = <&s5m_ldo8_reg>;
> > };
> >
> > + panel: panel {
> > + compatible = "simple-panel";
> > + };
>
> You can't do this. "simple-panel" isn't a valid panel model. It should
> probably be removed from the platform_of_match table in the driver.
Done.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-29 11:21 ` Andreas Färber
2014-07-29 11:36 ` Thierry Reding
@ 2014-07-30 6:21 ` Ajay kumar
2014-07-30 19:32 ` Andreas Färber
1 sibling, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-30 6:21 UTC (permalink / raw)
To: Andreas Färber
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Doug Anderson, Javier Martinez Canillas,
Prashanth G, Ajay Kumar
Hi Andreas,
On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber <afaerber@suse.de> wrote:
> Hi Ajay,
>
> Am 28.07.2014 08:13, schrieb Ajay kumar:
>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>>
>>>> I have tested this after adding few DT changes for exynos5250-snow,
>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>>
>>> I'm trying to test this with a modified exynos5250-spring DT based off
>>> kgene's for-next branch due to DT, and I run into the following:
>>>
>>> CC drivers/gpu/drm/bridge/ptn3460.o
>>> drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
>>> drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
>>> function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
>>> drm_connector_register(&ptn_bridge->connector);
>>> ^
>> Hope this might help:
>> http://www.spinics.net/lists/dri-devel/msg60578.html
>
> That fixed my build, thanks.
>
> Unfortunately the most I got on Spring with attached DT was a blank
> screen with a white horizontal line in the middle.
Then, I think bridge chip is working fine.
You just need to configure the proper mode for FIMD.
You can see backlight also, right?
> Do I need to specify a specific panel model for Spring?
Yes! Try using "chunghwa,claa101wb01" as compatible string for
panel node.
> For testing I re-applied your iommu patches (which btw fail now for 5420
> due to disp_pd) but didn't know what to do about your panel-lvds
> regulator patch now that it's gone.
Ignore that regulator patch.
Also, please attach the bootlog if possible after trying this.
Regards,
Ajay
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-30 6:21 ` Ajay kumar
@ 2014-07-30 19:32 ` Andreas Färber
2014-07-31 8:38 ` Ajay kumar
0 siblings, 1 reply; 70+ messages in thread
From: Andreas Färber @ 2014-07-30 19:32 UTC (permalink / raw)
To: Ajay kumar
Cc: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree, InKi Dae,
Thierry Reding, Rob Clark, Daniel Vetter, Sean Paul, Jingoo Han,
sunil joshi, Prashanth G, Doug Anderson,
Javier Martinez Canillas
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]
Hi Ajay,
Am 30.07.2014 08:21, schrieb Ajay kumar:
> On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 28.07.2014 08:13, schrieb Ajay kumar:
>>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>>>
>>>>> I have tested this after adding few DT changes for exynos5250-snow,
>>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>>>
>>>> I'm trying to test this with a modified exynos5250-spring DT based off
>>>> kgene's for-next branch due to DT, and I run into the following:
>>
>> Unfortunately the most I got on Spring with attached DT was a blank
>> screen with a white horizontal line in the middle.
> Then, I think bridge chip is working fine.
> You just need to configure the proper mode for FIMD.
> You can see backlight also, right?
>
>> Do I need to specify a specific panel model for Spring?
> Yes! Try using "chunghwa,claa101wb01" as compatible string for
> panel node.
With just your v6 applied plus updated DT patch (attached) [1], I see
backlight and a black screen (no white line any more). dmesg attached.
>> For testing I re-applied your iommu patches (which btw fail now for 5420
>> due to disp_pd) but didn't know what to do about your panel-lvds
>> regulator patch now that it's gone.
> Ignore that regulator patch.
>
> Also, please attach the bootlog if possible after trying this.
If I further apply the IOMMU patches [2], I get no backlight nor USB and
thus can't obtain a boot log.
Regards,
Andreas
[1] https://github.com/afaerber/linux/commits/spring-next
[2] https://github.com/afaerber/linux/commits/spring-bridge.v6
P.S. Note that your Snow DT patch will conflict with my Snow cleanups,
shuffling some nodes around: https://patchwork.kernel.org/patch/4649471/
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ARM-dts-exynos5250-Add-eDP-LVDS-bridge-to-Spring.patch --]
[-- Type: text/x-patch; name="0001-ARM-dts-exynos5250-Add-eDP-LVDS-bridge-to-Spring.patch", Size: 2027 bytes --]
>From 64fdedabdfcfa5ac8ec97ab647ccfdd4520430d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
[AF: Redone for v6]
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
arch/arm/boot/dts/exynos5250-spring.dts | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index 6d1d175e910e..8baad7ebe739 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -90,6 +90,10 @@
samsung,invert-vclk;
};
+ panel: panel {
+ compatible = "chunghwa,claa101wb01";
+ };
+
dp-controller@145B0000 {
status = "okay";
pinctrl-names = "default";
@@ -101,6 +105,7 @@
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
+ bridge = <&ps8622>;
};
};
@@ -405,6 +410,17 @@
status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
+
+ ps8622: lvds-bridge@08 {
+ compatible = "parade,ps8622";
+ reg = <0x08>;
+ sleep-gpios = <&gpc3 6 0>;
+ reset-gpios = <&gpc3 1 0>;
+ lane-count = <1>;
+ panel = <&panel>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ps8622_gpios>;
+ };
};
&i2c_8 {
@@ -461,11 +477,18 @@
&pinctrl_0 {
dp_hpd_gpio: dp-hpd-gpio {
samsung,pins = "gpc3-0";
- samsung,pin-function = <1>;
+ samsung,pin-function = <0>;
samsung,pin-pud = <3>;
samsung,pin-drv = <0>;
};
+ ps8622_gpios: ps8622-gpios {
+ samsung,pins = "gpc3-1", "gpc3-6";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
s5m8767_dvs: s5m8767-dvs {
samsung,pins = "gpd1-0", "gpd1-1", "gpd1-2";
samsung,pin-function = <0>;
--
1.9.3
[-- Attachment #3: dmesg-bridge.v6.txt --]
[-- Type: text/plain, Size: 37007 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.16.0-rc6+ (andreas@chrome11.site) (gcc version 4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #23 SMP PREEMPT Wed Jul 30 20:11:19 CEST 2014
[ 0.000000] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=30c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] Machine model: Google Spring
[ 0.000000] cma: CMA: reserved 64 MiB at 6b800000
[ 0.000000] Forcing write-allocate cache policy for SMP
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] On node 0 totalpages: 523264
[ 0.000000] free_area_init_node: node 0, pgdat c066b400, node_mem_map ea7dc000
[ 0.000000] Normal zone: 1520 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 194560 pages, LIFO batch:31
[ 0.000000] HighMem zone: 2568 pages used for memmap
[ 0.000000] HighMem zone: 328704 pages, LIFO batch:31
[ 0.000000] PERCPU: Embedded 7 pages/cpu @ea79b000 s8192 r8192 d12288 u32768
[ 0.000000] pcpu-alloc: s8192 r8192 d12288 u32768 alloc=8*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 521744
[ 0.000000] Kernel command line: console=tty1 root=/dev/sda3 rootfstype=ext4 rw rootwait clk_ignore_unused
[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 2003044K/2093056K available (4541K kernel code, 264K rwdata, 1496K rodata, 240K init, 286K bss, 90012K reserved, 1314816K highmem)
[ 0.000000] Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc05ed7f0 (6038 kB)
.init : 0xc05ee000 - 0xc062a000 ( 240 kB)
.data : 0xc062a000 - 0xc066c260 ( 265 kB)
.bss : 0xc066c26c - 0xc06b3c40 ( 287 kB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] L2C: failed to init: -19
[ 0.000000] Exynos5250: clock setup completed, armclk=1700000000
[ 0.000000] Switching to timer-based delay loop
[ 0.000003] sched_clock: 64 bits at 24MHz, resolution 41ns, wraps every 2863311519744ns
[ 0.000151] Console: colour dummy device 80x30
[ 0.000344] console [tty1] enabled
[ 0.000357] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=120000)
[ 0.000374] pid_max: default: 32768 minimum: 301
[ 0.000462] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000473] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000828] CPU: Testing write buffer coherency: ok
[ 0.000957] CPU0: update cpu_capacity 1024
[ 0.000968] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.001071] Setting up static identity map for 0x40450ee8 - 0x40450f40
[ 0.030191] CPU1: Booted secondary processor
[ 0.030222] CPU1: update cpu_capacity 1024
[ 0.030225] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.030273] Brought up 2 CPUs
[ 0.030298] SMP: Total of 2 processors activated.
[ 0.030307] CPU: All CPU(s) started in SVC mode.
[ 0.030605] devtmpfs: initialized
[ 0.033028] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[ 0.033351] pinctrl core: initialized pinctrl subsystem
[ 0.033587] regulator-dummy: no parameters
[ 0.041934] NET: Registered protocol family 16
[ 0.042526] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.043439] cpuidle: using governor ladder
[ 0.043464] cpuidle: using governor menu
[ 0.045468] gpiochip_add: registered GPIOs 0 to 7 on device: gpa0
[ 0.045476] gpiochip_add: registered GPIOs 8 to 13 on device: gpa1
[ 0.045483] gpiochip_add: registered GPIOs 14 to 21 on device: gpa2
[ 0.045489] gpiochip_add: registered GPIOs 22 to 26 on device: gpb0
[ 0.045495] gpiochip_add: registered GPIOs 27 to 31 on device: gpb1
[ 0.045501] gpiochip_add: registered GPIOs 32 to 35 on device: gpb2
[ 0.045507] gpiochip_add: registered GPIOs 36 to 39 on device: gpb3
[ 0.045513] gpiochip_add: registered GPIOs 40 to 46 on device: gpc0
[ 0.045519] gpiochip_add: registered GPIOs 47 to 50 on device: gpc1
[ 0.045525] gpiochip_add: registered GPIOs 51 to 57 on device: gpc2
[ 0.045530] gpiochip_add: registered GPIOs 58 to 64 on device: gpc3
[ 0.045536] gpiochip_add: registered GPIOs 65 to 68 on device: gpd0
[ 0.045542] gpiochip_add: registered GPIOs 69 to 76 on device: gpd1
[ 0.045548] gpiochip_add: registered GPIOs 77 to 83 on device: gpc4
[ 0.045554] gpiochip_add: registered GPIOs 84 to 89 on device: gpy0
[ 0.045559] gpiochip_add: registered GPIOs 90 to 93 on device: gpy1
[ 0.045565] gpiochip_add: registered GPIOs 94 to 99 on device: gpy2
[ 0.045571] gpiochip_add: registered GPIOs 100 to 107 on device: gpy3
[ 0.045576] gpiochip_add: registered GPIOs 108 to 115 on device: gpy4
[ 0.045582] gpiochip_add: registered GPIOs 116 to 123 on device: gpy5
[ 0.045588] gpiochip_add: registered GPIOs 124 to 131 on device: gpy6
[ 0.045594] gpiochip_add: registered GPIOs 132 to 139 on device: gpx0
[ 0.045600] gpiochip_add: registered GPIOs 140 to 147 on device: gpx1
[ 0.045606] gpiochip_add: registered GPIOs 148 to 155 on device: gpx2
[ 0.045612] gpiochip_add: registered GPIOs 156 to 163 on device: gpx3
[ 0.046554] gpiochip_add: registered GPIOs 164 to 171 on device: gpe0
[ 0.046561] gpiochip_add: registered GPIOs 172 to 173 on device: gpe1
[ 0.046567] gpiochip_add: registered GPIOs 174 to 177 on device: gpf0
[ 0.046573] gpiochip_add: registered GPIOs 178 to 181 on device: gpf1
[ 0.046579] gpiochip_add: registered GPIOs 182 to 189 on device: gpg0
[ 0.046585] gpiochip_add: registered GPIOs 190 to 197 on device: gpg1
[ 0.046590] gpiochip_add: registered GPIOs 198 to 199 on device: gpg2
[ 0.046596] gpiochip_add: registered GPIOs 200 to 203 on device: gph0
[ 0.046602] gpiochip_add: registered GPIOs 204 to 211 on device: gph1
[ 0.046882] gpiochip_add: registered GPIOs 212 to 219 on device: gpv0
[ 0.046889] gpiochip_add: registered GPIOs 220 to 227 on device: gpv1
[ 0.046896] gpiochip_add: registered GPIOs 228 to 235 on device: gpv2
[ 0.046902] gpiochip_add: registered GPIOs 236 to 243 on device: gpv3
[ 0.046908] gpiochip_add: registered GPIOs 244 to 245 on device: gpv4
[ 0.047114] gpiochip_add: registered GPIOs 246 to 252 on device: gpz
[ 0.047918] exynos-audss-clk 3810000.audss-clock-controller: setup completed
[ 0.052839] EXYNOS5250 PMU Initialize
[ 0.075852] of_get_named_gpiod_flags exited with status 0
[ 0.075950] P5.0V_USB3CON: 5000 mV
[ 0.075982] reg-fixed-voltage regulator-usb3: P5.0V_USB3CON supplying 5000000uV
[ 0.076635] SCSI subsystem initialized
[ 0.076808] libata version 3.00 loaded.
[ 0.077004] usbcore: registered new interface driver usbfs
[ 0.077055] usbcore: registered new interface driver hub
[ 0.077176] usbcore: registered new device driver usb
[ 0.077416] s3c-i2c 12c60000.i2c: slave address 0x00
[ 0.077430] s3c-i2c 12c60000.i2c: bus frequency set to 378 KHz
[ 0.079526] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO4[0]'
[ 0.079541] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO5[0]'
[ 0.079553] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO6[0]'
[ 0.079565] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO7[0]'
[ 0.079577] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO8[0]'
[ 0.079589] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO10[0]'
[ 0.079601] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO11[0]'
[ 0.079613] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO12[0]'
[ 0.079625] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO13[0]'
[ 0.079637] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO14[0]'
[ 0.079649] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO15[0]'
[ 0.079660] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO16[0]'
[ 0.079672] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO17[0]'
[ 0.079685] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/LDO25[0]'
[ 0.079699] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/BUCK1[0]'
[ 0.079711] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/BUCK2[0]'
[ 0.079723] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/BUCK3[0]'
[ 0.079736] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/BUCK4[0]'
[ 0.079747] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/BUCK5[0]'
[ 0.079759] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/BUCK6[0]'
[ 0.079771] of_get_named_gpiod_flags: can't parse gpios property of node '/i2c@12C60000/s5m8767-pmic@66/regulators/BUCK9[0]'
[ 0.079790] of_get_named_gpiod_flags exited with status 0
[ 0.079798] of_get_named_gpiod_flags exited with status 0
[ 0.079806] of_get_named_gpiod_flags exited with status 0
[ 0.080539] P1.0V_LDO_OUT4: 1000 mV
[ 0.081603] P1.0V_LDO_OUT5: 1000 mV
[ 0.082701] vdd_mydp: 1000 mV
[ 0.083232] P1.1V_LDO_OUT7: 1100 mV
[ 0.083767] P1.0V_LDO_OUT8: 1000 mV
[ 0.084302] P1.8V_LDO_OUT10: 1800 mV
[ 0.084948] P1.8V_LDO_OUT11: 1800 mV
[ 0.085475] P3.0V_LDO_OUT12: 3000 mV
[ 0.086123] P1.8V_LDO_OUT13: 1800 mV
[ 0.086681] P1.8V_LDO_OUT14: 1800 mV
[ 0.087237] P1.0V_LDO_OUT15: 1000 mV
[ 0.087795] P1.8V_LDO_OUT16: 1800 mV
[ 0.088882] P2.8V_LDO_OUT17: 2800 mV
[ 0.090024] vdd_bridge: 1200 mV
[ 0.090695] vdd_mif: 950 <--> 1300 mV at 1050 mV
[ 0.091260] vdd_arm: 850 <--> 1350 mV at 1300 mV
[ 0.091817] vdd_int: 900 <--> 1200 mV at 1012 mV
[ 0.092375] vdd_g3d: 850 <--> 1300 mV at 1200 mV
[ 0.092937] P1.8V_BUCK_OUT5: 1800 mV
[ 0.093497] P1.2V_BUCK_OUT6: 1200 mV
[ 0.094058] vdd_ummc: 950 <--> 3000 mV at 2850 mV
[ 0.105049] s3c-i2c 12c60000.i2c: i2c-0: S3C I2C adapter
[ 0.105141] s3c-i2c 12c70000.i2c: slave address 0x00
[ 0.105154] s3c-i2c 12c70000.i2c: bus frequency set to 378 KHz
[ 0.105662] s3c-i2c 12c70000.i2c: i2c-1: S3C I2C adapter
[ 0.105735] s3c-i2c 12c80000.i2c: slave address 0x00
[ 0.105748] s3c-i2c 12c80000.i2c: bus frequency set to 65 KHz
[ 0.106048] s3c-i2c 12c80000.i2c: i2c-2: S3C I2C adapter
[ 0.106115] s3c-i2c 12c90000.i2c: slave address 0x00
[ 0.106127] s3c-i2c 12c90000.i2c: bus frequency set to 65 KHz
[ 0.106216] s3c-i2c 12c90000.i2c: i2c-3: S3C I2C adapter
[ 0.106286] s3c-i2c 12ca0000.i2c: slave address 0x00
[ 0.106298] s3c-i2c 12ca0000.i2c: bus frequency set to 65 KHz
[ 0.106645] s3c-i2c 12ca0000.i2c: i2c-4: S3C I2C adapter
[ 0.106714] s3c-i2c 12cb0000.i2c: slave address 0x00
[ 0.106727] s3c-i2c 12cb0000.i2c: bus frequency set to 65 KHz
[ 0.106813] s3c-i2c 12cb0000.i2c: i2c-5: S3C I2C adapter
[ 0.106880] s3c-i2c 12cd0000.i2c: slave address 0x00
[ 0.106892] s3c-i2c 12cd0000.i2c: bus frequency set to 65 KHz
[ 0.107230] s3c-i2c 12cd0000.i2c: i2c-7: S3C I2C adapter
[ 0.107286] s3c-i2c 12ce0000.i2c: slave address 0x00
[ 0.107299] s3c-i2c 12ce0000.i2c: bus frequency set to 378 KHz
[ 0.107602] s3c-i2c 12ce0000.i2c: i2c-8: S3C I2C adapter
[ 0.110639] Switched to clocksource mct-frc
[ 0.119258] NET: Registered protocol family 2
[ 0.119600] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.119652] TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
[ 0.119749] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.119786] TCP: reno registered
[ 0.119798] UDP hash table entries: 512 (order: 2, 24576 bytes)
[ 0.119825] UDP-Lite hash table entries: 512 (order: 2, 24576 bytes)
[ 0.119943] NET: Registered protocol family 1
[ 0.120124] kvm [1]: HYP mode not available
[ 0.120884] futex hash table entries: 512 (order: 3, 32768 bytes)
[ 0.129708] ROMFS MTD (C) 2007 Red Hat, Inc.
[ 0.129858] msgmni has been set to 1472
[ 0.130223] bounce: pool size: 64 pages
[ 0.130430] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 0.130455] io scheduler noop registered
[ 0.130467] io scheduler deadline registered
[ 0.130790] io scheduler cfq registered (default)
[ 0.130813] start plist test
[ 0.134737] end plist test
[ 0.135968] exynos5_usb3drd_phy 12100000.phy: Looking up vbus-supply from device tree
[ 0.137142] mipi_dsim_ddi object not found.
[ 0.137222] simple-framebuffer bfc00000.framebuffer: framebuffer at 0xbfc00000, 0x202000 bytes, mapped to 0xf0400000
[ 0.137238] simple-framebuffer bfc00000.framebuffer: format=r5g6b5, mode=1366x768x16, linelength=2732
[ 0.144738] Console: switching to colour frame buffer device 195x54
[ 0.151166] simple-framebuffer bfc00000.framebuffer: fb0: simplefb registered!
[ 0.154041] dma-pl330 121a0000.pdma: Loaded driver for PL330 DMAC-2364208
[ 0.154098] dma-pl330 121a0000.pdma: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[ 0.156800] dma-pl330 121b0000.pdma: Loaded driver for PL330 DMAC-2364208
[ 0.156855] dma-pl330 121b0000.pdma: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[ 0.157611] dma-pl330 10800000.mdma: Loaded driver for PL330 DMAC-2364208
[ 0.157663] dma-pl330 10800000.mdma: DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32
[ 0.158441] dma-pl330 11c10000.mdma: Loaded driver for PL330 DMAC-2364208
[ 0.158493] dma-pl330 11c10000.mdma: DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32
[ 0.216015] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 0.217235] 12c00000.serial: ttySAC0 at MMIO 0x12c00000 (irq = 83, base_baud = 0) is a S3C6400/10
[ 0.217548] 12c10000.serial: ttySAC1 at MMIO 0x12c10000 (irq = 84, base_baud = 0) is a S3C6400/10
[ 0.217849] 12c20000.serial: ttySAC2 at MMIO 0x12c20000 (irq = 85, base_baud = 0) is a S3C6400/10
[ 0.218144] 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 86, base_baud = 0) is a S3C6400/10
[ 0.219107] [drm] Initialized drm 1.1.0 20060810
[ 0.219867] platform 145b0000.dp-controller: Driver exynos-dp requests probe deferral
[ 0.220416] of_get_named_gpiod_flags exited with status 0
[ 0.220468] exynos-hdmi 14530000.hdmi: Looking up hdmi-en-supply from device tree
[ 0.220677] exynos-hdmi 14530000.hdmi: Looking up vdd-supply from device tree
[ 0.220852] exynos-hdmi 14530000.hdmi: Looking up vdd_osc-supply from device tree
[ 0.221027] exynos-hdmi 14530000.hdmi: Looking up vdd_pll-supply from device tree
[ 0.221706] s5p-g2d 10850000.g2d: The exynos g2d(ver 4.1) successfully probed
[ 0.222460] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
[ 0.224750] panel-simple panel: Looking up power-supply from device tree
[ 0.224758] panel-simple panel: Looking up power-supply property in node /panel failed
[ 0.224766] panel supply power not found, using dummy regulator
[ 0.226850] panel-simple panel: GPIO lookup for consumer enable
[ 0.226856] panel-simple panel: using device tree for GPIO lookup
[ 0.226862] of_get_named_gpiod_flags: can't parse gpios property of node '/panel[0]'
[ 0.226868] of_get_named_gpiod_flags: can't parse gpios property of node '/panel[0]'
[ 0.226874] panel-simple panel: using lookup tables for GPIO lookup
[ 0.226880] panel-simple panel: lookup for GPIO enable failed
[ 0.227169] parade 7-0008: Looking up vdd_bridge-supply from device tree
[ 0.227177] parade 7-0008: Looking up vdd_bridge-supply property in node /i2c@12CD0000/lvds-bridge@08 failed
[ 0.227361] parade 7-0008: GPIO lookup for consumer sleep
[ 0.227367] parade 7-0008: using device tree for GPIO lookup
[ 0.227376] of_get_named_gpiod_flags exited with status 0
[ 0.227387] parade 7-0008: GPIO lookup for consumer reset
[ 0.227393] parade 7-0008: using device tree for GPIO lookup
[ 0.227399] of_get_named_gpiod_flags exited with status 0
[ 0.233547] brd: module loaded
[ 0.238341] loop: module loaded
[ 0.240945] cros-ec-i2c 4-001e: Chrome EC (I2C)
[ 0.244173] usbcore: registered new interface driver asix
[ 0.246344] usbcore: registered new interface driver ax88179_178a
[ 0.248471] usbcore: registered new interface driver cdc_ether
[ 0.250584] usbcore: registered new interface driver smsc75xx
[ 0.252659] usbcore: registered new interface driver smsc95xx
[ 0.254672] usbcore: registered new interface driver net1080
[ 0.256699] usbcore: registered new interface driver cdc_subset
[ 0.258659] usbcore: registered new interface driver zaurus
[ 0.260600] usbcore: registered new interface driver cdc_ncm
[ 0.262957] exynos-dwc3 usb@12000000: Looking up vdd33-supply from device tree
[ 0.262965] exynos-dwc3 usb@12000000: Looking up vdd33-supply property in node /usb@12000000 failed
[ 0.262974] usb@12000000 supply vdd33 not found, using dummy regulator
[ 0.264849] exynos-dwc3 usb@12000000: Looking up vdd10-supply from device tree
[ 0.264856] exynos-dwc3 usb@12000000: Looking up vdd10-supply property in node /usb@12000000 failed
[ 0.264862] usb@12000000 supply vdd10 not found, using dummy regulator
[ 0.467485] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.469344] ehci-exynos: EHCI EXYNOS driver
[ 0.471276] of_get_named_gpiod_flags exited with status 0
[ 0.471457] exynos-ehci 12110000.usb: EHCI Host Controller
[ 0.473319] exynos-ehci 12110000.usb: new USB bus registered, assigned bus number 1
[ 0.475212] exynos-ehci 12110000.usb: irq 103, io mem 0x12110000
[ 0.485676] exynos-ehci 12110000.usb: USB 2.0 started, EHCI 1.00
[ 0.487598] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.489430] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.491322] usb usb1: Product: EHCI Host Controller
[ 0.493169] usb usb1: Manufacturer: Linux 3.16.0-rc6+ ehci_hcd
[ 0.495029] usb usb1: SerialNumber: 12110000.usb
[ 0.497281] hub 1-0:1.0: USB hub found
[ 0.499110] hub 1-0:1.0: 3 ports detected
[ 0.501156] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.502956] ohci-exynos: OHCI EXYNOS driver
[ 0.504837] exynos-ohci 12120000.usb: USB Host Controller
[ 0.506607] exynos-ohci 12120000.usb: new USB bus registered, assigned bus number 2
[ 0.508385] exynos-ohci 12120000.usb: irq 103, io mem 0x12120000
[ 0.564764] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.566567] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.568382] usb usb2: Product: USB Host Controller
[ 0.570184] usb usb2: Manufacturer: Linux 3.16.0-rc6+ ohci_hcd
[ 0.571990] usb usb2: SerialNumber: 12120000.usb
[ 0.574130] hub 2-0:1.0: USB hub found
[ 0.575908] hub 2-0:1.0: 3 ports detected
[ 0.577969] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 0.579717] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 3
[ 0.581664] xhci-hcd xhci-hcd.2.auto: irq 104, io mem 0x12000000
[ 0.583542] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.585284] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.587065] usb usb3: Product: xHCI Host Controller
[ 0.588777] usb usb3: Manufacturer: Linux 3.16.0-rc6+ xhci-hcd
[ 0.590503] usb usb3: SerialNumber: xhci-hcd.2.auto
[ 0.592540] hub 3-0:1.0: USB hub found
[ 0.594248] hub 3-0:1.0: 1 port detected
[ 0.596096] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 0.597809] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 4
[ 0.599601] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[ 0.601379] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.603254] usb usb4: Product: xHCI Host Controller
[ 0.605037] usb usb4: Manufacturer: Linux 3.16.0-rc6+ xhci-hcd
[ 0.606895] usb usb4: SerialNumber: xhci-hcd.2.auto
[ 0.609077] hub 4-0:1.0: USB hub found
[ 0.610992] hub 4-0:1.0: 1 port detected
[ 0.613143] usbcore: registered new interface driver usb-storage
[ 0.615245] of_get_named_gpiod_flags: can't parse gpios property of node '/usb-hub[0]'
[ 0.615251] of_get_named_gpiod_flags: can't parse gpios property of node '/usb-hub[0]'
[ 0.615264] /usb-hub: could not get #gpio-cells for /pinctrl@13400000/hsic-reset
[ 0.617250] of_get_named_gpiod_flags: can't parse gpios property of node '/usb-hub[0]'
[ 0.625662] usb3503 usb-hub: switched to HUB mode
[ 0.627638] usb3503 usb-hub: usb3503_probe: probed in hub mode
[ 0.629775] samsung-usb2phy 12130000.usbphy: can't request region for resource [mem 0x12130000-0x121300ff]
[ 0.631845] samsung-usb2phy: probe of 12130000.usbphy failed with error -16
[ 0.634205] mousedev: PS/2 mouse device common for all mice
[ 0.636512] input: cros-ec-i2c as /devices/12ca0000.i2c/i2c-4/4-001e/cros-ec-keyb.1/input/input0
[ 0.640949] s5m-rtc s5m-rtc: rtc core: registered s5m-rtc as rtc0
[ 0.643487] cros-ec-i2c-tunnel cros-ec-i2c-tunnel.2: Couldn't read remote-bus property
[ 0.645674] cros-ec-i2c-tunnel: probe of cros-ec-i2c-tunnel.2 failed with error -22
[ 0.648370] exynos-tmu 10060000.tmu: Looking up vtmu-supply from device tree
[ 0.648378] exynos-tmu 10060000.tmu: Looking up vtmu-supply property in node /tmu@10060000 failed
[ 0.648387] 10060000.tmu supply vtmu not found, using dummy regulator
[ 0.650765] exynos-tmu 10060000.tmu: Exynos: Thermal zone(therm_zone0) registered
[ 0.653362] s3c2410-wdt 101d0000.watchdog: watchdog inactive, reset disabled, irq disabled
[ 0.656073] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
[ 0.659071] sdhci: Secure Digital Host Controller Interface driver
[ 0.661355] sdhci: Copyright(c) Pierre Ossman
[ 0.663709] Synopsys Designware Multimedia Card Interface Driver
[ 0.666362] dwmmc_exynos 12200000.mmc: Looking up vmmc-supply from device tree
[ 0.666370] dwmmc_exynos 12200000.mmc: Looking up vmmc-supply property in node /mmc@12200000 failed
[ 0.666379] dwmmc_exynos 12200000.mmc: no vmmc regulator found: -19
[ 0.668653] dwmmc_exynos 12200000.mmc: Using internal DMA controller.
[ 0.670892] dwmmc_exynos 12200000.mmc: Version ID is 241a
[ 0.673165] dwmmc_exynos 12200000.mmc: DW MMC controller at irq 107, 32 bit host data width, 128 deep fifo
[ 0.675433] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12200000[0]'
[ 0.675439] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12200000[0]'
[ 0.700695] dwmmc_exynos 12200000.mmc: 1 slots initialized
[ 0.703116] dwmmc_exynos 12210000.mmc: Looking up vmmc-supply from device tree
[ 0.703123] dwmmc_exynos 12210000.mmc: Looking up vmmc-supply property in node /mmc@12210000 failed
[ 0.703132] dwmmc_exynos 12210000.mmc: no vmmc regulator found: -19
[ 0.706385] dwmmc_exynos 12210000.mmc: Using internal DMA controller.
[ 0.710595] dwmmc_exynos 12210000.mmc: Version ID is 241a
[ 0.712884] dwmmc_exynos 12210000.mmc: DW MMC controller at irq 108, 32 bit host data width, 128 deep fifo
[ 0.715155] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12210000[0]'
[ 0.715161] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12210000[0]'
[ 0.740667] dwmmc_exynos 12210000.mmc: 1 slots initialized
[ 0.743317] s5p-sss driver registered
[ 0.746124] usbcore: registered new interface driver usbhid
[ 0.748369] usbhid: USB HID core driver
[ 0.750730] TCP: cubic registered
[ 0.752938] NET: Registered protocol family 17
[ 0.755191] NET: Registered protocol family 15
[ 0.757464] Registering SWP/SWPB emulation handler
[ 0.760534] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 0.762859] [drm] No driver support for vblank timestamp query.
[ 0.765056] exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops)
[ 0.767325] of_get_named_gpiod_flags exited with status 0
[ 0.767740] exynos-drm exynos-drm: bound 145b0000.dp-controller (ops exynos_dp_ops)
[ 0.769936] exynos-mixer 14450000.mixer: probe start
[ 0.772156] mmc0: BKOPS_EN bit is not set
[ 0.774354] exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops)
[ 0.776672] exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_component_ops)
[ 0.779513] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
[ 0.782576] mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 52000000Hz, actual 50000000HZ div = 1)
[ 0.785458] mmc0: new DDR MMC card at address 0001
[ 0.787719] exynos-drm exynos-drm: fb1: frame buffer device
[ 0.790039] mmcblk0: mmc0:0001 SEM16G 14.6 GiB
[ 0.790050] exynos-drm exynos-drm: registered panic notifier
[ 0.794581] mmcblk0boot0: mmc0:0001 SEM16G partition 1 4.00 MiB
[ 0.796862] mmcblk0boot1: mmc0:0001 SEM16G partition 2 4.00 MiB
[ 0.799099] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 4.00 MiB
[ 0.804652] mmcblk0: p1 p2 p3 p4 p5 p6 p7
[ 0.805687] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[ 0.809115] of_get_named_gpiod_flags exited with status 0
[ 0.809127] of_get_named_gpiod_flags exited with status 0
[ 0.809145] gpio-143: gpiod_set_debounce: missing set() or set_debounce() operations
[ 0.809203] gpio-161: gpiod_set_debounce: missing set() or set_debounce() operations
[ 0.809383] input: gpio-keys as /devices/gpio-keys/input/input1
[ 0.811534] usb 1-2: new high-speed USB device number 2 using exynos-ehci
[ 0.814188] s5m-rtc s5m-rtc: setting system clock to 2014-07-30 18:30:56 UTC (1406745056)
[ 0.816620] mmcblk0boot1: unknown partition table
[ 0.817084] Unable to find PPMU node
[ 0.817099] exynos5-bus-int: probe of exynos5-bus-int failed with error -2
[ 0.817292] vdd_g3d: disabling
[ 0.817570] clk: Not disabling unused clocks
[ 0.827792] mmcblk0boot0: unknown partition table
[ 0.830092] Waiting for root device /dev/sda3...
[ 0.941094] usb 1-2: New USB device found, idVendor=0424, idProduct=3503
[ 0.943131] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 0.945580] hub 1-2:1.0: USB hub found
[ 0.947716] hub 1-2:1.0: 3 ports detected
[ 1.230719] usb 1-2.1: new high-speed USB device number 3 using exynos-ehci
[ 1.337840] usb 1-2.1: New USB device found, idVendor=058f, idProduct=6377
[ 1.339859] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.341870] usb 1-2.1: Product: Mass Storage Device
[ 1.343870] usb 1-2.1: Manufacturer: Generic
[ 1.345905] usb 1-2.1: SerialNumber: 058F412D8PB1
[ 1.348325] usb-storage 1-2.1:1.0: USB Mass Storage device detected
[ 1.350480] scsi0 : usb-storage 1-2.1:1.0
[ 1.435719] usb 1-2.3: new high-speed USB device number 4 using exynos-ehci
[ 1.542341] usb 1-2.3: New USB device found, idVendor=05e3, idProduct=0608
[ 1.544341] usb 1-2.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 1.546323] usb 1-2.3: Product: USB2.0 Hub
[ 1.548955] hub 1-2.3:1.0: USB hub found
[ 1.551341] hub 1-2.3:1.0: 4 ports detected
[ 1.820965] usb 1-2.3.2: new high-speed USB device number 5 using exynos-ehci
[ 1.916965] usb 1-2.3.2: New USB device found, idVendor=0b95, idProduct=1790
[ 1.918977] usb 1-2.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.920978] usb 1-2.3.2: Product: AX88179
[ 1.922958] usb 1-2.3.2: Manufacturer: ASIX Elec. Corp.
[ 1.924918] usb 1-2.3.2: SerialNumber: 00000000000001
[ 2.254828] ax88179_178a 1-2.3.2:1.0 eth0: register 'ax88179_178a' at usb-12110000.usb-2.3.2, ASIX AX88179 USB 3.0 Gigabit Ethernet, xx:xx:xx:xx:xx:xx
[ 2.325969] usb 1-2.3.3: new high-speed USB device number 6 using exynos-ehci
[ 2.351497] scsi 0:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0
[ 2.354237] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 2.417089] usb 1-2.3.3: New USB device found, idVendor=05e3, idProduct=0608
[ 2.419221] usb 1-2.3.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 2.421336] usb 1-2.3.3: Product: USB2.0 Hub
[ 2.424109] hub 1-2.3.3:1.0: USB hub found
[ 2.426588] hub 1-2.3.3:1.0: 4 ports detected
[ 2.695966] usb 1-2.3.3.1: new low-speed USB device number 7 using exynos-ehci
[ 2.796461] usb 1-2.3.3.1: New USB device found, idVendor=10d5, idProduct=5000
[ 2.798610] usb 1-2.3.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.800745] usb 1-2.3.3.1: Product: Combo Free KVM
[ 2.802856] usb 1-2.3.3.1: Manufacturer: No brand
[ 2.810249] input: No brand Combo Free KVM as /devices/12110000.usb/usb1/1-2/1-2.3/1-2.3.3/1-2.3.3.1/1-2.3.3.1:1.0/0003:10D5:5000.0001/input/input2
[ 2.812566] hid-generic 0003:10D5:5000.0001: input: USB HID v1.10 Keyboard [No brand Combo Free KVM] on usb-12110000.usb-2.3.3.1/input0
[ 2.820243] input: No brand Combo Free KVM as /devices/12110000.usb/usb1/1-2/1-2.3/1-2.3.3/1-2.3.3.1/1-2.3.3.1:1.1/0003:10D5:5000.0002/input/input3
[ 2.822690] hid-generic 0003:10D5:5000.0002: input: USB HID v1.10 Mouse [No brand Combo Free KVM] on usb-12110000.usb-2.3.3.1/input1
[ 2.879872] scsi 0:0:0:1: Direct-Access Generic USB CF Reader 1.01 PQ: 0 ANSI: 0
[ 2.880485] sd 0:0:0:0: [sda] 61497344 512-byte logical blocks: (31.4 GB/29.3 GiB)
[ 2.881478] sd 0:0:0:0: [sda] Write Protect is off
[ 2.881483] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[ 2.882477] sd 0:0:0:0: [sda] No Caching mode page found
[ 2.882481] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 2.892046] sd 0:0:0:1: Attached scsi generic sg1 type 0
[ 2.895622] scsi 0:0:0:2: Direct-Access Generic USB SM Reader 1.02 PQ: 0 ANSI: 0
[ 2.898529] sd 0:0:0:2: Attached scsi generic sg2 type 0
[ 2.903609] sd 0:0:0:1: [sdb] Attached SCSI removable disk
[ 2.906248] scsi 0:0:0:3: Direct-Access Generic USB MS Reader 1.03 PQ: 0 ANSI: 0
[ 2.909110] sd 0:0:0:3: Attached scsi generic sg3 type 0
[ 2.914869] scsi 0:0:0:4: Direct-Access Generic Mini SD Reader 1.06 PQ: 0 ANSI: 0
[ 2.917812] sd 0:0:0:4: Attached scsi generic sg4 type 0
[ 2.920298] sd 0:0:0:2: [sdc] Attached SCSI removable disk
[ 2.921608] sd 0:0:0:3: [sdd] Attached SCSI removable disk
[ 2.926354] sd 0:0:0:4: [sde] Attached SCSI removable disk
[ 2.934776] sda: sda1 sda2 sda3
[ 2.940851] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 2.960155] EXT4-fs (sda3): warning: mounting fs with errors, running e2fsck is recommended
[ 3.840195] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
[ 3.842690] VFS: Mounted root (ext4 filesystem) on device 8:3.
[ 3.862001] devtmpfs: mounted
[ 3.864591] Freeing unused kernel memory: 240K (c05ee000 - c062a000)
[ 4.370451] random: systemd urandom read with 94 bits of entropy available
[ 4.379277] systemd[1]: systemd 210 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR)
[ 4.382025] systemd[1]: Detected architecture 'arm'.
[ 4.433354] systemd[1]: Inserted module 'autofs4'
[ 4.767139] NET: Registered protocol family 10
[ 4.770154] systemd[1]: Inserted module 'ipv6'
[ 4.774538] systemd[1]: Set hostname to <chrome11>.
[ 4.991229] LVM: Logical Volume autoactivation enabled.
[ 4.993735] LVM: Activation generator successfully completed.
[ 5.130667] random: nonblocking pool is initialized
[ 5.324556] systemd[1]: Configuration file /usr/lib/systemd/system/exim.service is marked executable. Please remove executable permission bits. Proceeding anyway.
[ 5.338412] systemd[1]: [/usr/lib/systemd/system/logrotate.timer:8] Unknown lvalue 'Persistent' in section 'Timer'
[ 5.421276] systemd[1]: Starting Remote File Systems (Pre).
[ 5.426792] systemd[1]: Reached target Remote File Systems (Pre).
[ 5.429439] systemd[1]: Starting Remote File Systems.
[ 5.434933] systemd[1]: Reached target Remote File Systems.
[ 5.437565] systemd[1]: Starting Encrypted Volumes.
[ 5.442743] systemd[1]: Reached target Encrypted Volumes.
[ 5.445218] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[ 5.447655] systemd[1]: Starting Swap.
[ 5.452640] systemd[1]: Reached target Swap.
[ 5.455058] systemd[1]: Starting Root Slice.
[ 5.460067] systemd[1]: Created slice Root Slice.
[ 5.462459] systemd[1]: Starting Journal Socket.
[ 5.467418] systemd[1]: Listening on Journal Socket.
[ 5.469751] systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[ 5.474523] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[ 5.476827] systemd[1]: Starting Delayed Shutdown Socket.
[ 5.481636] systemd[1]: Listening on Delayed Shutdown Socket.
[ 5.483986] systemd[1]: Starting User and Session Slice.
[ 5.488957] systemd[1]: Created slice User and Session Slice.
[ 5.491299] systemd[1]: Starting Syslog Socket.
[ 5.496057] systemd[1]: Listening on Syslog Socket.
[ 5.498332] systemd[1]: Starting udev Kernel Socket.
[ 5.503035] systemd[1]: Listening on udev Kernel Socket.
[ 5.505239] systemd[1]: Starting udev Control Socket.
[ 5.509675] systemd[1]: Listening on udev Control Socket.
[ 5.511843] systemd[1]: Starting System Slice.
[ 5.516341] systemd[1]: Created slice System Slice.
[ 5.518462] systemd[1]: Starting system-getty.slice.
[ 5.523014] systemd[1]: Created slice system-getty.slice.
[ 5.525130] systemd[1]: Starting Journal Service...
[ 5.532800] systemd[1]: Started Journal Service.
[ 5.597174] systemd-readahead[1477]: Bumped block_nr parameter of 8:0 to 20480. This is a temporary hack and should be removed one day.
[ 6.759345] systemd-journald[1471]: Received request to flush runtime journal from PID 1
[ 6.789334] systemd-udevd[1514]: starting version 210
[ 10.331256] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 11.193924] exynos-dp 145b0000.dp-controller: EDID data does not include any extensions.
[ 11.213280] exynos-dp 145b0000.dp-controller: EDID Read success!
[ 11.215114] exynos-dp 145b0000.dp-controller: Link Training Clock Recovery success
[ 11.216906] exynos-dp 145b0000.dp-controller: Link Training success!
[ 11.269923] exynos-dp 145b0000.dp-controller: EDID data does not include any extensions.
[ 11.290716] exynos-dp 145b0000.dp-controller: EDID Read success!
[ 11.292485] exynos-dp 145b0000.dp-controller: Link Training Clock Recovery success
[ 11.294354] exynos-dp 145b0000.dp-controller: Link Training success!
[ 13.155215] ax88179_178a 1-2.3.2:1.0 eth0: ax88179 - Link status is: 1
[ 13.158254] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 304.480652] EXT4-fs (sda3): error count since last fsck: 2
[ 304.480671] EXT4-fs (sda3): initial error at time 1404424016: ext4_mb_generate_buddy:756
[ 304.480681] EXT4-fs (sda3): last error at time 1405613372: ext4_mb_generate_buddy:756
[ 437.702555] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 437.731224] ax88179_178a 1-2.3.2:1.0 eth0: ax88179 - Link status is: 1
[ 440.547212] ax88179_178a 1-2.3.2:1.0 eth0: ax88179 - Link status is: 1
[ 440.549999] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
^ permalink raw reply related [flat|nested] 70+ messages in thread* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-30 19:32 ` Andreas Färber
@ 2014-07-31 8:38 ` Ajay kumar
2014-07-31 8:57 ` Andreas Färber
0 siblings, 1 reply; 70+ messages in thread
From: Ajay kumar @ 2014-07-31 8:38 UTC (permalink / raw)
To: Andreas Färber
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Doug Anderson, Javier Martinez Canillas,
Prashanth G, Ajay Kumar
Andreas,
On Thu, Jul 31, 2014 at 1:02 AM, Andreas Färber <afaerber@suse.de> wrote:
> Hi Ajay,
>
> Am 30.07.2014 08:21, schrieb Ajay kumar:
>> On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 28.07.2014 08:13, schrieb Ajay kumar:
>>>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>>>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>>>>
>>>>>> I have tested this after adding few DT changes for exynos5250-snow,
>>>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>>>>
>>>>> I'm trying to test this with a modified exynos5250-spring DT based off
>>>>> kgene's for-next branch due to DT, and I run into the following:
>>>
>>> Unfortunately the most I got on Spring with attached DT was a blank
>>> screen with a white horizontal line in the middle.
>> Then, I think bridge chip is working fine.
>> You just need to configure the proper mode for FIMD.
>> You can see backlight also, right?
>>
>>> Do I need to specify a specific panel model for Spring?
>> Yes! Try using "chunghwa,claa101wb01" as compatible string for
>> panel node.
>
> With just your v6 applied plus updated DT patch (attached) [1], I see
> backlight and a black screen (no white line any more). dmesg attached.
I can see penguin's also!
>>> For testing I re-applied your iommu patches (which btw fail now for 5420
>>> due to disp_pd) but didn't know what to do about your panel-lvds
>>> regulator patch now that it's gone.
>> Ignore that regulator patch.
>>
>> Also, please attach the bootlog if possible after trying this.
>
> If I further apply the IOMMU patches [2], I get no backlight nor USB and
> thus can't obtain a boot log.
>
> Regards,
> Andreas
>
> [1] https://github.com/afaerber/linux/commits/spring-next
> [2] https://github.com/afaerber/linux/commits/spring-bridge.v6
With just the spring-bridge.v6 branch of your own tree, I am able to see
bootup logo on Skate(a variant of spring which also contains ps8622).
I have tried both exynos_defconfig and multi_v7_defconfig.
I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
in configs.
Even in your bootlogs, I can see DP getting probed.
And, you say backlight is also visible. That means entire display
path should be fine. Its just that you should start writing to the buffer.
Have you enabled boot logos?
Ajay
> P.S. Note that your Snow DT patch will conflict with my Snow cleanups,
> shuffling some nodes around: https://patchwork.kernel.org/patch/4649471/
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-31 8:38 ` Ajay kumar
@ 2014-07-31 8:57 ` Andreas Färber
2014-07-31 10:07 ` Ajay kumar
2014-07-31 10:23 ` Thierry Reding
0 siblings, 2 replies; 70+ messages in thread
From: Andreas Färber @ 2014-07-31 8:57 UTC (permalink / raw)
To: Ajay kumar
Cc: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree, InKi Dae,
Thierry Reding, Rob Clark, Daniel Vetter, Sean Paul, Jingoo Han,
sunil joshi, Prashanth G, Doug Anderson,
Javier Martinez Canillas
Ajay,
Am 31.07.2014 10:38, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 1:02 AM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 30.07.2014 08:21, schrieb Ajay kumar:
>>> On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 28.07.2014 08:13, schrieb Ajay kumar:
>>>>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>>>>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>>>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>>>>>
>>>>>>> I have tested this after adding few DT changes for exynos5250-snow,
>>>>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>>>>>
>>>>>> I'm trying to test this with a modified exynos5250-spring DT based off
>>>>>> kgene's for-next branch due to DT, and I run into the following:
>>>>
>>>> Unfortunately the most I got on Spring with attached DT was a blank
>>>> screen with a white horizontal line in the middle.
>>> Then, I think bridge chip is working fine.
>>> You just need to configure the proper mode for FIMD.
>>> You can see backlight also, right?
>>>
>>>> Do I need to specify a specific panel model for Spring?
>>> Yes! Try using "chunghwa,claa101wb01" as compatible string for
>>> panel node.
>>
>> With just your v6 applied plus updated DT patch (attached) [1], I see
>> backlight and a black screen (no white line any more). dmesg attached.
> I can see penguin's also!
See below...
>>>> For testing I re-applied your iommu patches (which btw fail now for 5420
>>>> due to disp_pd) but didn't know what to do about your panel-lvds
>>>> regulator patch now that it's gone.
>>> Ignore that regulator patch.
>>>
>>> Also, please attach the bootlog if possible after trying this.
>>
>> If I further apply the IOMMU patches [2], I get no backlight nor USB and
>> thus can't obtain a boot log.
>>
>> Regards,
>> Andreas
>>
>> [1] https://github.com/afaerber/linux/commits/spring-next
(I updated the branch meantime, so what I meant was spring-bridge.v6~2)
>> [2] https://github.com/afaerber/linux/commits/spring-bridge.v6
> With just the spring-bridge.v6 branch of your own tree, I am able to see
> bootup logo on Skate(a variant of spring which also contains ps8622).
> I have tried both exynos_defconfig and multi_v7_defconfig.
> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
> in configs.
>
> Even in your bootlogs, I can see DP getting probed.
> And, you say backlight is also visible. That means entire display
> path should be fine. Its just that you should start writing to the buffer.
> Have you enabled boot logos?
Let me clarify: U-Boot uses the display [*], so it is powered and I see
penguins initially. Then, when drm gets initialized, the screen goes
black and no longer prints kernel messages or systemd output or X11 gdm
login screen.
Since drm stuff is the only variance here and it works with simplefb,
surely something prints to some buffer!
Andreas
[*] https://github.com/afaerber/u-boot/commits/spring
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-31 8:57 ` Andreas Färber
@ 2014-07-31 10:07 ` Ajay kumar
2014-07-31 10:23 ` Thierry Reding
1 sibling, 0 replies; 70+ messages in thread
From: Ajay kumar @ 2014-07-31 10:07 UTC (permalink / raw)
To: Andreas Färber
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Doug Anderson, Javier Martinez Canillas,
Prashanth G, Ajay Kumar
On Thu, Jul 31, 2014 at 2:27 PM, Andreas Färber <afaerber@suse.de> wrote:
> Ajay,
>
> Am 31.07.2014 10:38, schrieb Ajay kumar:
>> On Thu, Jul 31, 2014 at 1:02 AM, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 30.07.2014 08:21, schrieb Ajay kumar:
>>>> On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>> Am 28.07.2014 08:13, schrieb Ajay kumar:
>>>>>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote:
>>>>>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>>>>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>>>>>>
>>>>>>>> I have tested this after adding few DT changes for exynos5250-snow,
>>>>>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>>>>>>
>>>>>>> I'm trying to test this with a modified exynos5250-spring DT based off
>>>>>>> kgene's for-next branch due to DT, and I run into the following:
>>>>>
>>>>> Unfortunately the most I got on Spring with attached DT was a blank
>>>>> screen with a white horizontal line in the middle.
>>>> Then, I think bridge chip is working fine.
>>>> You just need to configure the proper mode for FIMD.
>>>> You can see backlight also, right?
>>>>
>>>>> Do I need to specify a specific panel model for Spring?
>>>> Yes! Try using "chunghwa,claa101wb01" as compatible string for
>>>> panel node.
>>>
>>> With just your v6 applied plus updated DT patch (attached) [1], I see
>>> backlight and a black screen (no white line any more). dmesg attached.
>> I can see penguin's also!
>
> See below...
>
>>>>> For testing I re-applied your iommu patches (which btw fail now for 5420
>>>>> due to disp_pd) but didn't know what to do about your panel-lvds
>>>>> regulator patch now that it's gone.
>>>> Ignore that regulator patch.
>>>>
>>>> Also, please attach the bootlog if possible after trying this.
>>>
>>> If I further apply the IOMMU patches [2], I get no backlight nor USB and
>>> thus can't obtain a boot log.
>>>
>>> Regards,
>>> Andreas
>>>
>>> [1] https://github.com/afaerber/linux/commits/spring-next
>
> (I updated the branch meantime, so what I meant was spring-bridge.v6~2)
>
>>> [2] https://github.com/afaerber/linux/commits/spring-bridge.v6
>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>> bootup logo on Skate(a variant of spring which also contains ps8622).
>> I have tried both exynos_defconfig and multi_v7_defconfig.
>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>> in configs.
>>
>> Even in your bootlogs, I can see DP getting probed.
>> And, you say backlight is also visible. That means entire display
>> path should be fine. Its just that you should start writing to the buffer.
>> Have you enabled boot logos?
>
> Let me clarify: U-Boot uses the display [*], so it is powered and I see
> penguins initially. Then, when drm gets initialized, the screen goes
> black and no longer prints kernel messages or systemd output or X11 gdm
> login screen.
>
> Since drm stuff is the only variance here and it works with simplefb,
> surely something prints to some buffer!
Well, I cannot really help you with this.
I think the ui process/X server is getting terminated for some reason.
That might be some issue induced by the platform/drm lib.
This cannot be an issue induced by the bridge chip series, definitely not!
I am able to run modetest, and also able to see random data on display
by doing "cat /dev/urandom > /dev/fb0"
Ajay
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-31 8:57 ` Andreas Färber
2014-07-31 10:07 ` Ajay kumar
@ 2014-07-31 10:23 ` Thierry Reding
2014-07-31 10:28 ` Andreas Färber
2014-07-31 14:22 ` Andreas Färber
1 sibling, 2 replies; 70+ messages in thread
From: Thierry Reding @ 2014-07-31 10:23 UTC (permalink / raw)
To: Andreas Färber
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Doug Anderson, Javier Martinez Canillas,
Ajay kumar, Prashanth G, Ajay Kumar
[-- Attachment #1.1: Type: text/plain, Size: 1391 bytes --]
On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote:
> Am 31.07.2014 10:38, schrieb Ajay kumar:
[...]
> > With just the spring-bridge.v6 branch of your own tree, I am able to see
> > bootup logo on Skate(a variant of spring which also contains ps8622).
> > I have tried both exynos_defconfig and multi_v7_defconfig.
> > I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
> > in configs.
> >
> > Even in your bootlogs, I can see DP getting probed.
> > And, you say backlight is also visible. That means entire display
> > path should be fine. Its just that you should start writing to the buffer.
> > Have you enabled boot logos?
>
> Let me clarify: U-Boot uses the display [*], so it is powered and I see
> penguins initially. Then, when drm gets initialized, the screen goes
> black and no longer prints kernel messages or systemd output or X11 gdm
> login screen.
Who's displaying the penguins? If you're referring to the Linux boot
logo then it shouldn't be displayed at all until after DRM has been
initialized (and the framebuffer console been set up).
> Since drm stuff is the only variance here and it works with simplefb,
> surely something prints to some buffer!
If you have something like simplefb enabled in addition to a DRM driver,
then perhaps the DRM driver isn't properly taking over the framebuffer
console.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-31 10:23 ` Thierry Reding
@ 2014-07-31 10:28 ` Andreas Färber
2014-07-31 14:22 ` Andreas Färber
1 sibling, 0 replies; 70+ messages in thread
From: Andreas Färber @ 2014-07-31 10:28 UTC (permalink / raw)
To: Thierry Reding
Cc: Ajay kumar, Ajay Kumar, dri-devel, linux-samsung-soc, devicetree,
InKi Dae, Rob Clark, Daniel Vetter, Sean Paul, Jingoo Han,
sunil joshi, Prashanth G, Doug Anderson,
Javier Martinez Canillas
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]
Am 31.07.2014 12:23, schrieb Thierry Reding:
> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote:
>> Am 31.07.2014 10:38, schrieb Ajay kumar:
> [...]
>>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>>> bootup logo on Skate(a variant of spring which also contains ps8622).
>>> I have tried both exynos_defconfig and multi_v7_defconfig.
>>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>>> in configs.
>>>
>>> Even in your bootlogs, I can see DP getting probed.
>>> And, you say backlight is also visible. That means entire display
>>> path should be fine. Its just that you should start writing to the buffer.
>>> Have you enabled boot logos?
>>
>> Let me clarify: U-Boot uses the display [*], so it is powered and I see
>> penguins initially. Then, when drm gets initialized, the screen goes
>> black and no longer prints kernel messages or systemd output or X11 gdm
>> login screen.
>
> Who's displaying the penguins? If you're referring to the Linux boot
> logo then it shouldn't be displayed at all until after DRM has been
> initialized (and the framebuffer console been set up).
Yes, I'm referring to the default boot logo, but before the boot
messages (console=tty1) indicate that [drm] driver is being initialized.
>> Since drm stuff is the only variance here and it works with simplefb,
>> surely something prints to some buffer!
>
> If you have something like simplefb enabled in addition to a DRM driver,
> then perhaps the DRM driver isn't properly taking over the framebuffer
> console.
Okay, that's worth a try. Around v4 of this series it was not a problem.
Thanks,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-31 10:23 ` Thierry Reding
2014-07-31 10:28 ` Andreas Färber
@ 2014-07-31 14:22 ` Andreas Färber
2014-08-01 7:02 ` Ajay kumar
1 sibling, 1 reply; 70+ messages in thread
From: Andreas Färber @ 2014-07-31 14:22 UTC (permalink / raw)
To: Thierry Reding, Ajay kumar
Cc: Ajay Kumar, dri-devel, linux-samsung-soc, devicetree, InKi Dae,
Rob Clark, Daniel Vetter, Sean Paul, Jingoo Han, sunil joshi,
Prashanth G, Doug Anderson, Javier Martinez Canillas
[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]
Am 31.07.2014 12:23, schrieb Thierry Reding:
> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote:
>> Am 31.07.2014 10:38, schrieb Ajay kumar:
>>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>>> bootup logo on Skate(a variant of spring which also contains ps8622).
>>> I have tried both exynos_defconfig and multi_v7_defconfig.
>>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>>> in configs.
[...]
> If you have something like simplefb enabled in addition to a DRM driver,
> then perhaps the DRM driver isn't properly taking over the framebuffer
> console.
So, with simplefb reverted in U-Boot and ...
* with just the v6 applied (...~2), I get only a black screen from
Linux, no penguins, but the backlight seems on. System comes up okay,
ssh available, and nothing stands out in dmesg.
* with the two iommu patches on top, something breaks badly, no
backlight, no USB/network, system inaccessible.
I.e. U-Boot had no noticeable impact on these symptoms.
* with the iommu patches, but dp-controller, ps8622, panel commented
out, I do get backlight but USB/network not working, system inaccessible.
With simplefb support in U-Boot and with just v6 applied, but
dp-controller, ps8622, panel commented out, things work as well as
before, i.e. this series has no bad side effects. Note that I never
claimed Ajay's series were broken, just reported that things regressed
for me from v4, which may well be DT-related.
The iommu patches interfere with my USB somehow (none or not all devices
powered; with v4, plugging my wifi dongle led to oops but ethernet
dongle worked, so not entirely new symptom), which is bad since my
rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
so USB based network is my only alternative to a working display once we
reach userspace.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-31 14:22 ` Andreas Färber
@ 2014-08-01 7:02 ` Ajay kumar
2014-08-01 12:13 ` Andreas Färber
2014-08-01 14:57 ` Andreas Färber
0 siblings, 2 replies; 70+ messages in thread
From: Ajay kumar @ 2014-08-01 7:02 UTC (permalink / raw)
To: Andreas Färber
Cc: devicetree, linux-samsung-soc, Sean Paul, Daniel Vetter,
sunil joshi, dri-devel, Doug Anderson, Javier Martinez Canillas,
Prashanth G, Ajay Kumar
[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]
Andreas,
On Thu, Jul 31, 2014 at 7:52 PM, Andreas Färber <afaerber@suse.de> wrote:
> Am 31.07.2014 12:23, schrieb Thierry Reding:
>> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote:
>>> Am 31.07.2014 10:38, schrieb Ajay kumar:
>>>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>>>> bootup logo on Skate(a variant of spring which also contains ps8622).
>>>> I have tried both exynos_defconfig and multi_v7_defconfig.
>>>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>>>> in configs.
> [...]
>> If you have something like simplefb enabled in addition to a DRM driver,
>> then perhaps the DRM driver isn't properly taking over the framebuffer
>> console.
>
> So, with simplefb reverted in U-Boot and ...
>
> * with just the v6 applied (...~2), I get only a black screen from
> Linux, no penguins, but the backlight seems on. System comes up okay,
> ssh available, and nothing stands out in dmesg.
>
> * with the two iommu patches on top, something breaks badly, no
> backlight, no USB/network, system inaccessible.
> I.e. U-Boot had no noticeable impact on these symptoms.
>
> * with the iommu patches, but dp-controller, ps8622, panel commented
> out, I do get backlight but USB/network not working, system inaccessible.
>
> With simplefb support in U-Boot and with just v6 applied, but
> dp-controller, ps8622, panel commented out, things work as well as
> before, i.e. this series has no bad side effects. Note that I never
> claimed Ajay's series were broken, just reported that things regressed
> for me from v4, which may well be DT-related.
>
> The iommu patches interfere with my USB somehow (none or not all devices
> powered; with v4, plugging my wifi dongle led to oops but ethernet
> dongle worked, so not entirely new symptom), which is bad since my
> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
> so USB based network is my only alternative to a working display once we
> reach userspace.
Well, there are 2 variants here:
1) Bootloader
2) config
Type of the bootloader should not matter unless its switching on
FET1 and FET6 of tps65090 for you.
But, config can be different!
I have attached a config i used to get display with your latest
spring-bridge.v6.
Uncomment the DT nodes for DP and bridge chip and you should
be able to get display and also the login.
I think that you have not selected all the configs needed for IOMMU to
work properly. When I deselected few IOMMU configs, I could see system
crashing when FIMD + DP path was being initialized. May be, that is why your
USB stops working. Even I have root file system on USB drive.
Just give a try with this config and let me know your observation.
If you still observe the same behavior, may be I need to flash new
bootloader onto my board and try. :(
Ajay
[-- Attachment #2: config.txt --]
[-- Type: text/plain, Size: 63354 bytes --]
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.16.0-rc6 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_ARM_DMA_USE_IOMMU=y
CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT_MAP=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_BANDGAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_GENERIC_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
# CONFIG_UPROBES is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_CC_STACKPROTECTOR_NONE=y
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y
#
# GCOV-based kernel profiling
#
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_CMDLINE_PARSER is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_AIX_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_FREEZER=y
#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE_LEGACY is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set
#
# Multiple platform selection
#
#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_VIRT is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_ARCH_BERLIN is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_HI3xxx is not set
# CONFIG_ARCH_KEYSTONE is not set
# CONFIG_ARCH_MXC is not set
#
# TI OMAP/AM/DM/DRA Family
#
# CONFIG_ARCH_OMAP3 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
# CONFIG_SOC_AM33XX is not set
# CONFIG_SOC_AM43XX is not set
# CONFIG_SOC_DRA7XX is not set
# CONFIG_ARCH_QCOM is not set
# CONFIG_ARCH_ROCKCHIP is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_STI is not set
# CONFIG_ARCH_S5PV210 is not set
CONFIG_ARCH_EXYNOS=y
# CONFIG_ARCH_EXYNOS3 is not set
CONFIG_ARCH_EXYNOS4=y
CONFIG_ARCH_EXYNOS5=y
#
# EXYNOS SoCs
#
CONFIG_CPU_EXYNOS4210=y
CONFIG_SOC_EXYNOS4212=y
CONFIG_SOC_EXYNOS4412=y
CONFIG_SOC_EXYNOS5250=y
CONFIG_SOC_EXYNOS5260=y
CONFIG_SOC_EXYNOS5410=y
CONFIG_SOC_EXYNOS5420=y
CONFIG_SOC_EXYNOS5440=y
CONFIG_SOC_EXYNOS5800=y
CONFIG_PLAT_SAMSUNG=y
#
# Samsung Common options
#
#
# Boot options
#
CONFIG_S5P_DEV_MFC=y
#
# Power management
#
# CONFIG_SAMSUNG_PM_CHECK is not set
# CONFIG_ARCH_SHMOBILE_MULTI is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_WM8850 is not set
# CONFIG_ARCH_ZYNQ is not set
#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
CONFIG_SWP_EMULATE=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_KUSER_HELPERS=y
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
# CONFIG_PL310_ERRATA_588369 is not set
# CONFIG_PL310_ERRATA_727915 is not set
# CONFIG_PL310_ERRATA_753970 is not set
# CONFIG_PL310_ERRATA_769419 is not set
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_ARM_ERRATA_643719 is not set
# CONFIG_ARM_ERRATA_720789 is not set
# CONFIG_ARM_ERRATA_754322 is not set
# CONFIG_ARM_ERRATA_754327 is not set
# CONFIG_ARM_ERRATA_764369 is not set
# CONFIG_ARM_ERRATA_775420 is not set
# CONFIG_ARM_ERRATA_798181 is not set
# CONFIG_ARM_ERRATA_773022 is not set
#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI is not set
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set
#
# Kernel Features
#
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_ARM_CPU_TOPOLOGY=y
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
CONFIG_HAVE_ARM_ARCH_TIMER=y
# CONFIG_MCPM is not set
# CONFIG_BIG_LITTLE is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_NR_CPUS=8
CONFIG_HOTPLUG_CPU=y
# CONFIG_ARM_PSCI is not set
CONFIG_ARCH_NR_GPIO=512
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_HZ_FIXED=200
CONFIG_HZ=200
CONFIG_SCHED_HRTICK=y
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_NO_BOOTMEM=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
# CONFIG_CMA is not set
# CONFIG_ZBUD is not set
# CONFIG_ZSMALLOC is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_XEN is not set
#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC1,115200 init=/linuxrc mem=256M"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y
#
# CPU Power Management
#
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# CPU Idle
#
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y
# CONFIG_KERNEL_MODE_NEON is not set
#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y
#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_HIBERNATION is not set
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_NET_IP_TUNNEL=m
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=m
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
# CONFIG_IPV6_VTI is not set
CONFIG_IPV6_SIT=m
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NET_PTP_CLASSIFY is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_NET_MPLS_GSO is not set
# CONFIG_HSR is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set
CONFIG_NET_FLOW_LIMIT=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set
#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
CONFIG_RFKILL_REGULATOR=y
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_MMIO=y
CONFIG_REGMAP_IRQ=y
CONFIG_DMA_SHARED_BUFFER=y
#
# Bus devices
#
# CONFIG_BRCMSTB_GISB_ARB is not set
# CONFIG_ARM_CCI is not set
# CONFIG_VEXPRESS_CONFIG is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_DTC=y
CONFIG_OF=y
#
# Device Tree and Open Firmware support
#
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_RESERVED_MEM=y
# CONFIG_PARPORT is not set
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_NULL_BLK is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_BLK_DEV_CRYPTOLOOP=y
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set
#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
CONFIG_SRAM=y
# CONFIG_C2PORT is not set
#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_I2C is not set
#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
#
# Intel MIC Host Driver
#
#
# Intel MIC Card Driver
#
# CONFIG_ECHO is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
# CONFIG_ATA is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_THIN_PROVISIONING is not set
# CONFIG_DM_CACHE is not set
# CONFIG_DM_ERA is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_RAID is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
# CONFIG_DM_FLAKEY is not set
# CONFIG_DM_VERITY is not set
# CONFIG_DM_SWITCH is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_MII=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_NLMON is not set
#
# CAIF transport drivers
#
#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
# CONFIG_ALTERA_TSE is not set
CONFIG_NET_VENDOR_ARC=y
# CONFIG_ARC_EMAC is not set
CONFIG_NET_CADENCE=y
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_BCMGENET is not set
# CONFIG_SYSTEMPORT is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CIRRUS=y
# CONFIG_CS89x0 is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_HISILICON=y
# CONFIG_HIX5HD2_GMAC is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8851_MLL is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
# CONFIG_ETHOC is not set
# CONFIG_SH_ETH is not set
CONFIG_NET_VENDOR_SAMSUNG=y
# CONFIG_SXGBE_ETH is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_SMC91X is not set
# CONFIG_SMC911X is not set
CONFIG_SMSC911X=y
# CONFIG_SMSC911X_ARCH_HOOKS is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_AMD_XGBE_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM7XXX_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_RTL8152 is not set
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_AX88179_178A=y
CONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_CDC_NCM=y
# CONFIG_USB_NET_HUAWEI_CDC_NCM is not set
# CONFIG_USB_NET_CDC_MBIM is not set
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SR9700 is not set
# CONFIG_USB_NET_SR9800 is not set
CONFIG_USB_NET_SMSC75XX=y
CONFIG_USB_NET_SMSC95XX=y
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=y
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
CONFIG_USB_NET_CDC_SUBSET=y
# CONFIG_USB_ALI_M5632 is not set
# CONFIG_USB_AN2720 is not set
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
# CONFIG_USB_EPSON2888 is not set
# CONFIG_USB_KC2190 is not set
CONFIG_USB_NET_ZAURUS=y
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_NET_QMI_WWAN is not set
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_USB_VL600 is not set
CONFIG_WLAN=y
# CONFIG_HOSTAP is not set
# CONFIG_WL_TI is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MATRIXKMAP=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_GPIO=y
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
CONFIG_KEYBOARD_SAMSUNG=y
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_KEYBOARD_CROS_EC=y
CONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
CONFIG_MOUSE_CYAPA=y
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_OF_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_SUR40 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_TOUCHSCREEN_ZFORCE is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_AMBAKMI is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_SERIO_APBPS2 is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
# CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST is not set
CONFIG_SERIAL_SAMSUNG=y
CONFIG_SERIAL_SAMSUNG_UARTS_4=y
CONFIG_SERIAL_SAMSUNG_UARTS=4
CONFIG_SERIAL_SAMSUNG_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_ST_ASC is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_EXYNOS=y
CONFIG_HW_RANDOM_TPM=y
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_TCG_TPM=y
# CONFIG_TCG_TIS_I2C_ATMEL is not set
CONFIG_TCG_TIS_I2C_INFINEON=y
# CONFIG_TCG_TIS_I2C_NUVOTON is not set
# CONFIG_TCG_ST33_I2C is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_MUX=y
#
# Multiplexer I2C Chip support
#
CONFIG_I2C_ARB_GPIO_CHALLENGE=y
# CONFIG_I2C_MUX_GPIO is not set
# CONFIG_I2C_MUX_PCA9541 is not set
# CONFIG_I2C_MUX_PCA954x is not set
# CONFIG_I2C_MUX_PINCTRL is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y
#
# I2C Hardware Bus support
#
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
CONFIG_I2C_EXYNOS5=y
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_RK3X is not set
CONFIG_HAVE_S3C2410_I2C=y
CONFIG_I2C_S3C2410=y
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_ROBOTFUZZ_OSIF is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_CROS_EC_TUNNEL is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
#
# PPS support
#
# CONFIG_PPS is not set
#
# PPS generators support
#
#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_PINCTRL=y
#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
# CONFIG_PINCTRL_BCM281XX is not set
# CONFIG_PINCTRL_APQ8064 is not set
# CONFIG_PINCTRL_IPQ8064 is not set
# CONFIG_PINCTRL_SINGLE is not set
CONFIG_PINCTRL_SAMSUNG=y
CONFIG_PINCTRL_EXYNOS=y
CONFIG_PINCTRL_EXYNOS5440=y
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_OF_GPIO=y
CONFIG_DEBUG_GPIO=y
# CONFIG_GPIO_SYSFS is not set
#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_DWAPB is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_ZEVIO is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_SCH311X is not set
# CONFIG_GPIO_SYSCON is not set
# CONFIG_GPIO_GRGPIO is not set
#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set
#
# PCI GPIO expanders:
#
#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MCP23S08 is not set
#
# AC97 GPIO expanders:
#
#
# LPC GPIO expanders:
#
#
# MODULbus GPIO expanders:
#
# CONFIG_GPIO_BCM_KONA is not set
#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set
#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_MFD_AS3722 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_BCM590XX is not set
# CONFIG_MFD_AXP20X is not set
CONFIG_MFD_CROS_EC=y
CONFIG_MFD_CROS_EC_I2C=y
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_DA9063 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX14577 is not set
CONFIG_MFD_MAX77686=y
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
CONFIG_MFD_MAX8997=y
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_PM8921_CORE is not set
# CONFIG_MFD_RTSX_USB is not set
# CONFIG_MFD_RC5T583 is not set
CONFIG_MFD_SEC_CORE=y
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
CONFIG_MFD_SYSCON=y
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP3943 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
CONFIG_MFD_TPS65090=y
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS65218 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_ACT8865 is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_ANATOP is not set
# CONFIG_REGULATOR_DA9210 is not set
# CONFIG_REGULATOR_FAN53555 is not set
CONFIG_REGULATOR_GPIO=y
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_LTC3589 is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
CONFIG_REGULATOR_MAX8997=y
CONFIG_REGULATOR_MAX77686=y
# CONFIG_REGULATOR_PFUZE100 is not set
# CONFIG_REGULATOR_S2MPA01 is not set
CONFIG_REGULATOR_S2MPS11=y
CONFIG_REGULATOR_S5M8767=y
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
# CONFIG_REGULATOR_TPS65023 is not set
# CONFIG_REGULATOR_TPS6507X is not set
CONFIG_REGULATOR_TPS65090=y
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
#
# Direct Rendering Manager
#
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_KMS_FB_HELPER=y
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
#
# I2C encoder or helper chips
#
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_I2C_NXP_TDA998X is not set
CONFIG_DRM_BRIDGE=y
#
# bridge chips
#
CONFIG_DRM_PTN3460=y
CONFIG_DRM_PS8622=y
CONFIG_DRM_EXYNOS=y
CONFIG_DRM_EXYNOS_IOMMU=y
CONFIG_DRM_EXYNOS_DMABUF=y
CONFIG_DRM_EXYNOS_FIMD=y
# CONFIG_DRM_EXYNOS_DPI is not set
# CONFIG_DRM_EXYNOS_DSI is not set
CONFIG_DRM_EXYNOS_DP=y
# CONFIG_DRM_EXYNOS_HDMI is not set
# CONFIG_DRM_EXYNOS_VIDI is not set
# CONFIG_DRM_EXYNOS_G2D is not set
# CONFIG_DRM_EXYNOS_IPP is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_ARMADA is not set
# CONFIG_DRM_TILCDC is not set
CONFIG_DRM_PANEL=y
#
# Display Panels
#
CONFIG_DRM_PANEL_SIMPLE=y
# CONFIG_DRM_PANEL_LD9040 is not set
# CONFIG_DRM_PANEL_S6E8AA0 is not set
#
# Frame buffer Devices
#
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
#
# Frame buffer hardware drivers
#
# CONFIG_FB_ARMCLCD is not set
# CONFIG_FB_OPENCORES is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_S3C is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
CONFIG_FB_SIMPLE=y
CONFIG_EXYNOS_VIDEO=y
CONFIG_EXYNOS_MIPI_DSI=y
# CONFIG_FB_SSD1307 is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_PLATFORM is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_GPIO is not set
# CONFIG_BACKLIGHT_LV5207LP is not set
# CONFIG_BACKLIGHT_BD6107 is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEOMODE_HELPERS=y
CONFIG_HDMI=y
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_SOUND is not set
#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y
#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
# CONFIG_HID_ACRUX is not set
CONFIG_HID_APPLE=y
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_AUREAL is not set
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
# CONFIG_HID_CP2112 is not set
CONFIG_HID_CYPRESS=y
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_ELO is not set
CONFIG_HID_EZKEY=y
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_HUION is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
CONFIG_HID_KENSINGTON=y
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
CONFIG_HID_LOGITECH=y
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
# CONFIG_LOGIWHEELS_FF is not set
# CONFIG_HID_MAGICMOUSE is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_RMI is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_XINMO is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set
#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set
#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG_FSM is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB_CBAF is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_EXYNOS=y
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FUSBH200_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HCD_TEST_MODE is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set
# CONFIG_USB_UAS is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_MUSB_HDRC is not set
CONFIG_USB_DWC3=y
CONFIG_USB_DWC3_HOST=y
#
# Platform Glue Driver Support
#
CONFIG_USB_DWC3_EXYNOS=y
#
# Debugging features
#
# CONFIG_USB_DWC3_DEBUG is not set
# CONFIG_USB_DWC2 is not set
# CONFIG_USB_CHIPIDEA is not set
#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_EHSET_TEST_FIXTURE is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set
#
# USB Physical Layer drivers
#
CONFIG_USB_PHY=y
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_AM335X_PHY_USB is not set
CONFIG_SAMSUNG_USBPHY=y
CONFIG_SAMSUNG_USB2PHY=y
CONFIG_SAMSUNG_USB3PHY=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_ULPI is not set
# CONFIG_USB_GADGET is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_CLKGATE is not set
#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
CONFIG_MMC_SDHCI=y
# CONFIG_MMC_SDHCI_PLTFM is not set
CONFIG_MMC_SDHCI_S3C=y
# CONFIG_MMC_SDHCI_S3C_DMA is not set
CONFIG_MMC_DW=y
CONFIG_MMC_DW_IDMAC=y
CONFIG_MMC_DW_PLTFM=y
CONFIG_MMC_DW_EXYNOS=y
# CONFIG_MMC_DW_K3 is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MMC_USDHI6ROL0 is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_HYM8563 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_MAX8997 is not set
# CONFIG_RTC_DRV_MAX77686 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_ISL12057 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set
# CONFIG_RTC_DRV_S5M is not set
#
# SPI RTC drivers
#
#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set
#
# on-CPU RTC drivers
#
CONFIG_HAVE_S3C_RTC=y
CONFIG_RTC_DRV_S3C=y
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
# CONFIG_RTC_DRV_SNVS is not set
# CONFIG_RTC_DRV_MOXART is not set
# CONFIG_RTC_DRV_XGENE is not set
#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VFIO is not set
# CONFIG_VIRT_DRIVERS is not set
#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set
#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
#
# SOC (System On Chip) specific Drivers
#
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y
#
# Common Clock Framework
#
CONFIG_COMMON_CLK_MAX77686=y
# CONFIG_COMMON_CLK_SI5351 is not set
# CONFIG_COMMON_CLK_SI570 is not set
# CONFIG_COMMON_CLK_S2MPS11 is not set
# CONFIG_COMMON_CLK_QCOM is not set
CONFIG_COMMON_CLK_SAMSUNG=y
#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_OF=y
CONFIG_ARM_ARCH_TIMER=y
CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y
CONFIG_CLKSRC_EXYNOS_MCT=y
CONFIG_CLKSRC_SAMSUNG_PWM=y
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_SH_TIMER_MTU2 is not set
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_EM_TIMER_STI is not set
# CONFIG_CLKSRC_VERSATILE is not set
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
CONFIG_EXYNOS_IOMMU=y
# CONFIG_EXYNOS_IOMMU_DEBUG is not set
#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set
#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
CONFIG_GIC_NON_BANKED=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set
#
# PHY Subsystem
#
CONFIG_GENERIC_PHY=y
CONFIG_PHY_EXYNOS_MIPI_VIDEO=y
CONFIG_PHY_EXYNOS_DP_VIDEO=y
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_PHY_EXYNOS5250_SATA is not set
CONFIG_PHY_SAMSUNG_USB2=y
CONFIG_PHY_EXYNOS4210_USB2=y
CONFIG_PHY_EXYNOS4X12_USB2=y
CONFIG_PHY_EXYNOS5250_USB2=y
CONFIG_PHY_EXYNOS5_USBDRD=y
# CONFIG_POWERCAP is not set
# CONFIG_MCB is not set
#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_EXT4_FS=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_BACKED_BY_BLOCK=y
CONFIG_ROMFS_ON_BLOCK=y
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set
#
# Kernel hacking
#
#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_BOOT_PRINTK_DELAY is not set
#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_DEBUG_KERNEL=y
#
# Memory Debugging
#
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_VM is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SHIRQ is not set
#
# Debug Lockups and Hangs
#
# CONFIG_LOCKUP_DETECTOR is not set
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_PANIC_TIMEOUT=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_PREEMPT=y
#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_DEBUG_RT_MUTEXES=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_LOCK_TORTURE_TEST is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_PI_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
#
# RCU Debugging
#
# CONFIG_PROVE_RCU_DELAY is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_TORTURE_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_CPU_STALL_VERBOSE=y
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_TRACEPOINT_BENCHMARK is not set
#
# Runtime Testing
#
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_PERCPU_TEST is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_TEST_MODULE is not set
# CONFIG_TEST_USER_COPY is not set
# CONFIG_TEST_BPF is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_ARM_PTDUMP is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
# CONFIG_DEBUG_UART_PL01X is not set
# CONFIG_DEBUG_UART_8250 is not set
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set
# CONFIG_DEBUG_SET_MODULE_RONX is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
CONFIG_SECURITYFS=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set
#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_CRCT10DIF is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set
#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_S5P is not set
# CONFIG_BINARY_PRINTF is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
CONFIG_LIBFDT=y
CONFIG_FONT_SUPPORT=y
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
CONFIG_FONT_7x14=y
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
# CONFIG_VIRTUALIZATION is not set
[-- Attachment #3: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-08-01 7:02 ` Ajay kumar
@ 2014-08-01 12:13 ` Andreas Färber
2014-08-01 14:57 ` Andreas Färber
1 sibling, 0 replies; 70+ messages in thread
From: Andreas Färber @ 2014-08-01 12:13 UTC (permalink / raw)
To: Ajay kumar
Cc: Thierry Reding, Ajay Kumar, dri-devel, linux-samsung-soc,
devicetree, InKi Dae, Rob Clark, Daniel Vetter, Sean Paul,
Jingoo Han, sunil joshi, Prashanth G, Doug Anderson,
Javier Martinez Canillas
[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]
Hi Ajay,
Am 01.08.2014 09:02, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 7:52 PM, Andreas Färber <afaerber@suse.de> wrote:
>> So, with simplefb reverted in U-Boot and ...
>>
>> * with just the v6 applied (...~2), I get only a black screen from
>> Linux, no penguins, but the backlight seems on. System comes up okay,
>> ssh available, and nothing stands out in dmesg.
>>
>> * with the two iommu patches on top, something breaks badly, no
>> backlight, no USB/network, system inaccessible.
>> I.e. U-Boot had no noticeable impact on these symptoms.
>>
>> * with the iommu patches, but dp-controller, ps8622, panel commented
>> out, I do get backlight but USB/network not working, system inaccessible.
>>
>> With simplefb support in U-Boot and with just v6 applied, but
>> dp-controller, ps8622, panel commented out, things work as well as
>> before, i.e. this series has no bad side effects. Note that I never
>> claimed Ajay's series were broken, just reported that things regressed
>> for me from v4, which may well be DT-related.
>>
>> The iommu patches interfere with my USB somehow (none or not all devices
>> powered; with v4, plugging my wifi dongle led to oops but ethernet
>> dongle worked, so not entirely new symptom), which is bad since my
>> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
>> so USB based network is my only alternative to a working display once we
>> reach userspace.
> Well, there are 2 variants here:
> 1) Bootloader
> 2) config
>
> Type of the bootloader should not matter unless its switching on
> FET1 and FET6 of tps65090 for you.
>
> But, config can be different!
> I have attached a config i used to get display with your latest
> spring-bridge.v6.
> Uncomment the DT nodes for DP and bridge chip and you should
> be able to get display and also the login.
>
> I think that you have not selected all the configs needed for IOMMU to
> work properly. When I deselected few IOMMU configs, I could see system
> crashing when FIMD + DP path was being initialized. May be, that is why your
> USB stops working. Even I have root file system on USB drive.
Find attached a diff between our configs. The following stand out:
* I have LPAE enabled
* you don't have DMA enabled
* I have CMA enabled (like in the new defconfigs)
* I have the arch timer disabled (which you suggested earlier for delay)
* I have more devices enabled (SPI, PWM, cpufreq, watchdog, ...)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[-- Attachment #2: config-ajay.diff --]
[-- Type: text/x-patch, Size: 27283 bytes --]
--- .config 2014-08-01 14:03:18.255022463 +0200
+++ ../config-ajay.txt 2014-08-01 13:19:01.875021197 +0200
@@ -34,7 +34,7 @@
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
-# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
@@ -51,7 +51,7 @@
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
-CONFIG_FHANDLE=y
+# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
@@ -106,19 +106,10 @@
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
+# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_GENERIC_SCHED_CLOCK=y
-CONFIG_CGROUPS=y
-# CONFIG_CGROUP_DEBUG is not set
-# CONFIG_CGROUP_FREEZER is not set
-# CONFIG_CGROUP_DEVICE is not set
-# CONFIG_CPUSETS is not set
-# CONFIG_CGROUP_CPUACCT is not set
-# CONFIG_RESOURCE_COUNTERS is not set
-# CONFIG_CGROUP_SCHED is not set
-# CONFIG_BLK_CGROUP is not set
+# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
@@ -204,7 +195,6 @@
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
-CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
@@ -228,7 +218,7 @@
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
-CONFIG_BLK_DEV_BSG=y
+# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_CMDLINE_PARSER is not set
@@ -267,7 +257,6 @@
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
-CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
@@ -323,7 +312,6 @@
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_VIRT is not set
# CONFIG_ARCH_MVEBU is not set
-# CONFIG_ARCH_AXXIA is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_ARCH_BERLIN is not set
# CONFIG_ARCH_HIGHBANK is not set
@@ -358,10 +346,11 @@
CONFIG_SOC_EXYNOS4212=y
CONFIG_SOC_EXYNOS4412=y
CONFIG_SOC_EXYNOS5250=y
-# CONFIG_SOC_EXYNOS5260 is not set
-# CONFIG_SOC_EXYNOS5410 is not set
-# CONFIG_SOC_EXYNOS5420 is not set
-# CONFIG_SOC_EXYNOS5440 is not set
+CONFIG_SOC_EXYNOS5260=y
+CONFIG_SOC_EXYNOS5410=y
+CONFIG_SOC_EXYNOS5420=y
+CONFIG_SOC_EXYNOS5440=y
+CONFIG_SOC_EXYNOS5800=y
CONFIG_PLAT_SAMSUNG=y
#
@@ -405,8 +394,8 @@
#
# Processor Features
#
-CONFIG_ARM_LPAE=y
-CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
+# CONFIG_ARM_LPAE is not set
+# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
@@ -456,7 +445,7 @@
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
-# CONFIG_HAVE_ARM_ARCH_TIMER is not set
+CONFIG_HAVE_ARM_ARCH_TIMER=y
# CONFIG_MCPM is not set
# CONFIG_BIG_LITTLE is not set
CONFIG_VMSPLIT_3G=y
@@ -483,29 +472,24 @@
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
-CONFIG_SYS_SUPPORTS_HUGETLBFS=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_NO_BOOTMEM=y
-CONFIG_MEMORY_ISOLATION=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
-CONFIG_PHYS_ADDR_T_64BIT=y
+# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
-CONFIG_MMU_NOTIFIER=y
-CONFIG_KSM=y
+# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
-# CONFIG_TRANSPARENT_HUGEPAGE is not set
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
-CONFIG_CMA=y
-# CONFIG_CMA_DEBUG is not set
+# CONFIG_CMA is not set
# CONFIG_ZBUD is not set
# CONFIG_ZSMALLOC is not set
CONFIG_FORCE_MAX_ZONEORDER=11
@@ -524,7 +508,10 @@
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
-# CONFIG_ARM_APPENDED_DTB is not set
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
+# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC1,115200 init=/linuxrc mem=256M"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
@@ -540,44 +527,12 @@
#
# CPU Frequency scaling
#
-CONFIG_CPU_FREQ=y
-CONFIG_CPU_FREQ_GOV_COMMON=y
-CONFIG_CPU_FREQ_STAT=y
-# CONFIG_CPU_FREQ_STAT_DETAILS is not set
-CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
-# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
-# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
-# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
-CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
-CONFIG_CPU_FREQ_GOV_POWERSAVE=y
-CONFIG_CPU_FREQ_GOV_USERSPACE=y
-CONFIG_CPU_FREQ_GOV_ONDEMAND=y
-CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
-# CONFIG_GENERIC_CPUFREQ_CPU0 is not set
-
-#
-# ARM CPU frequency scaling drivers
-#
-CONFIG_ARM_EXYNOS_CPUFREQ=y
-CONFIG_ARM_EXYNOS4210_CPUFREQ=y
-CONFIG_ARM_EXYNOS4X12_CPUFREQ=y
-CONFIG_ARM_EXYNOS5250_CPUFREQ=y
-# CONFIG_ARM_EXYNOS_CPU_FREQ_BOOST_SW is not set
-# CONFIG_ARM_KIRKWOOD_CPUFREQ is not set
+# CONFIG_CPU_FREQ is not set
#
# CPU Idle
#
-CONFIG_CPU_IDLE=y
-# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
-CONFIG_CPU_IDLE_GOV_LADDER=y
-CONFIG_CPU_IDLE_GOV_MENU=y
-
-#
-# ARM CPU Idle Drivers
-#
-# CONFIG_ARM_BIG_LITTLE_CPUIDLE is not set
-CONFIG_ARM_EXYNOS_CPUIDLE=y
+# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
#
@@ -721,8 +676,6 @@
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
-# CONFIG_CGROUP_NET_PRIO is not set
-# CONFIG_CGROUP_NET_CLASSID is not set
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set
@@ -738,23 +691,12 @@
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
-CONFIG_CFG80211=m
-# CONFIG_NL80211_TESTMODE is not set
-# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
-# CONFIG_CFG80211_REG_DEBUG is not set
-CONFIG_CFG80211_DEFAULT_PS=y
-# CONFIG_CFG80211_INTERNAL_REGDB is not set
-# CONFIG_CFG80211_WEXT is not set
+# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set
-CONFIG_MAC80211=m
-CONFIG_MAC80211_HAS_RC=y
-CONFIG_MAC80211_RC_MINSTREL=y
-CONFIG_MAC80211_RC_MINSTREL_HT=y
-CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
-CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
-# CONFIG_MAC80211_MESH is not set
-# CONFIG_MAC80211_MESSAGE_TRACING is not set
-# CONFIG_MAC80211_DEBUG_MENU is not set
+
+#
+# CFG80211 needs to be enabled for MAC80211
+#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
CONFIG_RFKILL_REGULATOR=y
@@ -790,18 +732,6 @@
CONFIG_REGMAP_MMIO=y
CONFIG_REGMAP_IRQ=y
CONFIG_DMA_SHARED_BUFFER=y
-CONFIG_DMA_CMA=y
-
-#
-# Default contiguous memory area size:
-#
-CONFIG_CMA_SIZE_MBYTES=64
-CONFIG_CMA_SIZE_SEL_MBYTES=y
-# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
-# CONFIG_CMA_SIZE_SEL_MIN is not set
-# CONFIG_CMA_SIZE_SEL_MAX is not set
-CONFIG_CMA_ALIGNMENT=8
-CONFIG_CMA_AREAS=7
#
# Bus devices
@@ -861,11 +791,8 @@
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
-# CONFIG_TI_DAC7512 is not set
# CONFIG_BMP085_I2C is not set
-# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
-# CONFIG_LATTICE_ECP3_CONFIG is not set
CONFIG_SRAM=y
# CONFIG_C2PORT is not set
@@ -873,17 +800,14 @@
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
-# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
-# CONFIG_EEPROM_93XX46 is not set
#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
-# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set
#
@@ -943,37 +867,7 @@
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
-CONFIG_ATA=y
-# CONFIG_ATA_NONSTANDARD is not set
-CONFIG_ATA_VERBOSE_ERROR=y
-CONFIG_SATA_PMP=y
-
-#
-# Controllers with non-SFF native interface
-#
-CONFIG_SATA_AHCI_PLATFORM=y
-CONFIG_ATA_SFF=y
-
-#
-# SFF controllers with custom DMA interface
-#
-CONFIG_ATA_BMDMA=y
-
-#
-# SATA SFF controllers with BMDMA
-#
-
-#
-# PATA SFF controllers with BMDMA
-#
-
-#
-# PIO-only SFF controllers
-#
-
-#
-# Generic fallback / legacy drivers
-#
+# CONFIG_ATA is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BCACHE is not set
@@ -1047,11 +941,7 @@
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_NET_VENDOR_MICREL=y
-# CONFIG_KS8842 is not set
-# CONFIG_KS8851 is not set
# CONFIG_KS8851_MLL is not set
-CONFIG_NET_VENDOR_MICROCHIP=y
-# CONFIG_ENC28J60 is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
@@ -1101,7 +991,6 @@
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
-# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
@@ -1147,34 +1036,8 @@
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_USB_VL600 is not set
CONFIG_WLAN=y
-# CONFIG_LIBERTAS_THINFIRM is not set
-# CONFIG_AT76C50X_USB is not set
-# CONFIG_USB_ZD1201 is not set
-# CONFIG_USB_NET_RNDIS_WLAN is not set
-# CONFIG_RTL8187 is not set
-# CONFIG_MAC80211_HWSIM is not set
-# CONFIG_ATH_CARDS is not set
-# CONFIG_B43 is not set
-# CONFIG_B43LEGACY is not set
-# CONFIG_BRCMSMAC is not set
-# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
-# CONFIG_LIBERTAS is not set
-# CONFIG_P54_COMMON is not set
-# CONFIG_RT2X00 is not set
-CONFIG_RTL_CARDS=m
-CONFIG_RTL8192CU=m
-CONFIG_RTLWIFI=m
-CONFIG_RTLWIFI_USB=m
-CONFIG_RTLWIFI_DEBUG=y
-CONFIG_RTL8192C_COMMON=m
# CONFIG_WL_TI is not set
-# CONFIG_ZD1211RW is not set
-CONFIG_MWIFIEX=m
-CONFIG_MWIFIEX_SDIO=m
-# CONFIG_MWIFIEX_USB is not set
-# CONFIG_CW1200 is not set
-# CONFIG_RSI_91X is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
@@ -1243,8 +1106,6 @@
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_OF_TOUCHSCREEN=y
-# CONFIG_TOUCHSCREEN_ADS7846 is not set
-# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
@@ -1276,7 +1137,6 @@
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
-# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_SUR40 is not set
@@ -1323,7 +1183,6 @@
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
# CONFIG_SERIAL_8250_CONSOLE is not set
-CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
@@ -1340,8 +1199,6 @@
CONFIG_SERIAL_SAMSUNG_UARTS_4=y
CONFIG_SERIAL_SAMSUNG_UARTS=4
CONFIG_SERIAL_SAMSUNG_CONSOLE=y
-# CONFIG_SERIAL_MAX3100 is not set
-# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
@@ -1349,7 +1206,6 @@
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
-# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_FSL_LPUART is not set
@@ -1417,37 +1273,12 @@
#
# Other I2C/SMBus bus drivers
#
-CONFIG_I2C_CROS_EC_TUNNEL=y
+# CONFIG_I2C_CROS_EC_TUNNEL is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
-CONFIG_SPI=y
-# CONFIG_SPI_DEBUG is not set
-CONFIG_SPI_MASTER=y
-
-#
-# SPI Master Controller Drivers
-#
-# CONFIG_SPI_ALTERA is not set
-# CONFIG_SPI_BITBANG is not set
-# CONFIG_SPI_CADENCE is not set
-# CONFIG_SPI_GPIO is not set
-# CONFIG_SPI_FSL_SPI is not set
-# CONFIG_SPI_OC_TINY is not set
-# CONFIG_SPI_PL022 is not set
-# CONFIG_SPI_PXA2XX_PCI is not set
-CONFIG_SPI_S3C64XX=y
-# CONFIG_SPI_SC18IS602 is not set
-# CONFIG_SPI_XCOMM is not set
-# CONFIG_SPI_XILINX is not set
-# CONFIG_SPI_DESIGNWARE is not set
-
-#
-# SPI Protocol Masters
-#
-# CONFIG_SPI_SPIDEV is not set
-# CONFIG_SPI_TLE62X0 is not set
+# CONFIG_SPI is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
@@ -1482,6 +1313,7 @@
# CONFIG_PINCTRL_SINGLE is not set
CONFIG_PINCTRL_SAMSUNG=y
CONFIG_PINCTRL_EXYNOS=y
+CONFIG_PINCTRL_EXYNOS5440=y
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
@@ -1521,10 +1353,7 @@
#
# SPI GPIO expanders:
#
-# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
-# CONFIG_GPIO_MC33880 is not set
-# CONFIG_GPIO_74X164 is not set
#
# AC97 GPIO expanders:
@@ -1543,75 +1372,11 @@
# USB GPIO expanders:
#
# CONFIG_W1 is not set
-CONFIG_POWER_SUPPLY=y
-CONFIG_POWER_SUPPLY_DEBUG=y
-# CONFIG_PDA_POWER is not set
-# CONFIG_TEST_POWER is not set
-# CONFIG_BATTERY_DS2780 is not set
-# CONFIG_BATTERY_DS2781 is not set
-# CONFIG_BATTERY_DS2782 is not set
-CONFIG_BATTERY_SBS=y
-# CONFIG_BATTERY_BQ27x00 is not set
-# CONFIG_BATTERY_MAX17040 is not set
-# CONFIG_BATTERY_MAX17042 is not set
-# CONFIG_CHARGER_ISP1704 is not set
-# CONFIG_CHARGER_MAX8903 is not set
-# CONFIG_CHARGER_LP8727 is not set
-# CONFIG_CHARGER_GPIO is not set
-CONFIG_CHARGER_MANAGER=y
-# CONFIG_CHARGER_MAX8997 is not set
-# CONFIG_CHARGER_BQ2415X is not set
-# CONFIG_CHARGER_BQ24190 is not set
-# CONFIG_CHARGER_BQ24735 is not set
-# CONFIG_CHARGER_SMB347 is not set
-CONFIG_CHARGER_TPS65090=y
-CONFIG_POWER_RESET=y
-CONFIG_POWER_RESET_GPIO=y
-# CONFIG_POWER_RESET_RESTART is not set
+# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
-CONFIG_THERMAL=y
-CONFIG_THERMAL_OF=y
-CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
-# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
-# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
-# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
-CONFIG_THERMAL_GOV_STEP_WISE=y
-# CONFIG_THERMAL_GOV_USER_SPACE is not set
-# CONFIG_CPU_THERMAL is not set
-# CONFIG_THERMAL_EMULATION is not set
-
-#
-# Texas Instruments thermal drivers
-#
-# CONFIG_TI_SOC_THERMAL is not set
-
-#
-# Samsung thermal drivers
-#
-CONFIG_EXYNOS_THERMAL=y
-CONFIG_EXYNOS_THERMAL_CORE=y
-CONFIG_WATCHDOG=y
-CONFIG_WATCHDOG_CORE=y
-# CONFIG_WATCHDOG_NOWAYOUT is not set
-
-#
-# Watchdog Device Drivers
-#
-# CONFIG_SOFT_WATCHDOG is not set
-# CONFIG_GPIO_WATCHDOG is not set
-# CONFIG_XILINX_WATCHDOG is not set
-# CONFIG_ARM_SP805_WATCHDOG is not set
-CONFIG_HAVE_S3C2410_WATCHDOG=y
-CONFIG_S3C2410_WATCHDOG=y
-# CONFIG_DW_WATCHDOG is not set
-# CONFIG_MAX63XX_WATCHDOG is not set
-# CONFIG_MEN_A21_WDT is not set
-
-#
-# USB-based Watchdog Cards
-#
-# CONFIG_USBPCWATCHDOG is not set
+# CONFIG_THERMAL is not set
+# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
@@ -1637,14 +1402,11 @@
# CONFIG_MFD_AXP20X is not set
CONFIG_MFD_CROS_EC=y
CONFIG_MFD_CROS_EC_I2C=y
-CONFIG_MFD_CROS_EC_SPI=y
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
-# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_DA9063 is not set
-# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
@@ -1660,7 +1422,6 @@
# CONFIG_MFD_MAX8925 is not set
CONFIG_MFD_MAX8997=y
# CONFIG_MFD_MAX8998 is not set
-# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
@@ -1688,7 +1449,6 @@
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
-# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
@@ -1700,14 +1460,12 @@
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
-# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
-# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_REGULATOR=y
-CONFIG_REGULATOR_DEBUG=y
+# CONFIG_REGULATOR_DEBUG is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
@@ -1739,7 +1497,6 @@
# CONFIG_REGULATOR_TPS65023 is not set
# CONFIG_REGULATOR_TPS6507X is not set
CONFIG_REGULATOR_TPS65090=y
-# CONFIG_REGULATOR_TPS6524X is not set
# CONFIG_MEDIA_SUPPORT is not set
#
@@ -1750,7 +1507,6 @@
# Direct Rendering Manager
#
CONFIG_DRM=y
-CONFIG_DRM_MIPI_DSI=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_KMS_FB_HELPER=y
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
@@ -1772,15 +1528,13 @@
CONFIG_DRM_EXYNOS_IOMMU=y
CONFIG_DRM_EXYNOS_DMABUF=y
CONFIG_DRM_EXYNOS_FIMD=y
-CONFIG_DRM_EXYNOS_DPI=y
-CONFIG_DRM_EXYNOS_DSI=y
+# CONFIG_DRM_EXYNOS_DPI is not set
+# CONFIG_DRM_EXYNOS_DSI is not set
CONFIG_DRM_EXYNOS_DP=y
-CONFIG_DRM_EXYNOS_HDMI=y
-CONFIG_DRM_EXYNOS_VIDI=y
-CONFIG_DRM_EXYNOS_G2D=y
-CONFIG_DRM_EXYNOS_IPP=y
-CONFIG_DRM_EXYNOS_FIMC=y
-CONFIG_DRM_EXYNOS_ROTATOR=y
+# CONFIG_DRM_EXYNOS_HDMI is not set
+# CONFIG_DRM_EXYNOS_VIDI is not set
+# CONFIG_DRM_EXYNOS_G2D is not set
+# CONFIG_DRM_EXYNOS_IPP is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_ARMADA is not set
# CONFIG_DRM_TILCDC is not set
@@ -1831,32 +1585,16 @@
CONFIG_FB_SIMPLE=y
CONFIG_EXYNOS_VIDEO=y
CONFIG_EXYNOS_MIPI_DSI=y
-CONFIG_EXYNOS_LCD_S6E8AX0=y
# CONFIG_FB_SSD1307 is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
-CONFIG_LCD_CLASS_DEVICE=y
-# CONFIG_LCD_L4F00242T03 is not set
-# CONFIG_LCD_LMS283GF05 is not set
-# CONFIG_LCD_LTV350QV is not set
-# CONFIG_LCD_ILI922X is not set
-# CONFIG_LCD_ILI9320 is not set
-# CONFIG_LCD_TDO24M is not set
-# CONFIG_LCD_VGG2432A4 is not set
-CONFIG_LCD_PLATFORM=y
-# CONFIG_LCD_S6E63M0 is not set
-# CONFIG_LCD_LD9040 is not set
-# CONFIG_LCD_AMS369FG06 is not set
-# CONFIG_LCD_LMS501KF03 is not set
-# CONFIG_LCD_HX8357 is not set
+CONFIG_LCD_CLASS_DEVICE=m
+# CONFIG_LCD_PLATFORM is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
-CONFIG_BACKLIGHT_PWM=y
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
-# CONFIG_BACKLIGHT_LM3630A is not set
# CONFIG_BACKLIGHT_LM3639 is not set
-# CONFIG_BACKLIGHT_LP855X is not set
-CONFIG_BACKLIGHT_GPIO=y
+# CONFIG_BACKLIGHT_GPIO is not set
# CONFIG_BACKLIGHT_LV5207LP is not set
# CONFIG_BACKLIGHT_BD6107 is not set
# CONFIG_VGASTATE is not set
@@ -1880,7 +1618,6 @@
# HID support
#
CONFIG_HID=y
-# CONFIG_HID_BATTERY_STRENGTH is not set
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y
@@ -1963,7 +1700,7 @@
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
-CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set
#
# Miscellaneous USB options
@@ -1978,8 +1715,7 @@
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
-CONFIG_USB_XHCI_HCD=y
-CONFIG_USB_XHCI_PLATFORM=y
+# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_EHCI_TT_NEWSCHED=y
@@ -1991,10 +1727,7 @@
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FUSBH200_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
-# CONFIG_USB_MAX3421_HCD is not set
-CONFIG_USB_OHCI_HCD=y
-CONFIG_USB_OHCI_EXYNOS=y
-# CONFIG_USB_OHCI_HCD_PLATFORM is not set
+# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HCD_TEST_MODE is not set
@@ -2082,7 +1815,7 @@
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
-CONFIG_USB_HSIC_USB3503=y
+# CONFIG_USB_HSIC_USB3503 is not set
#
# USB Physical Layer drivers
@@ -2156,7 +1889,7 @@
# CONFIG_RTC_DRV_HYM8563 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_MAX8997 is not set
-CONFIG_RTC_DRV_MAX77686=y
+# CONFIG_RTC_DRV_MAX77686 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
@@ -2174,24 +1907,11 @@
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set
-CONFIG_RTC_DRV_S5M=y
+# CONFIG_RTC_DRV_S5M is not set
#
# SPI RTC drivers
#
-# CONFIG_RTC_DRV_M41T93 is not set
-# CONFIG_RTC_DRV_M41T94 is not set
-# CONFIG_RTC_DRV_DS1305 is not set
-# CONFIG_RTC_DRV_DS1343 is not set
-# CONFIG_RTC_DRV_DS1347 is not set
-# CONFIG_RTC_DRV_DS1390 is not set
-# CONFIG_RTC_DRV_MAX6902 is not set
-# CONFIG_RTC_DRV_R9701 is not set
-# CONFIG_RTC_DRV_RS5C348 is not set
-# CONFIG_RTC_DRV_DS3234 is not set
-# CONFIG_RTC_DRV_PCF2123 is not set
-# CONFIG_RTC_DRV_RX4581 is not set
-# CONFIG_RTC_DRV_MCP795 is not set
#
# Platform RTC drivers
@@ -2226,25 +1946,7 @@
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
-CONFIG_DMADEVICES=y
-# CONFIG_DMADEVICES_DEBUG is not set
-
-#
-# DMA Devices
-#
-# CONFIG_AMBA_PL08X is not set
-# CONFIG_DW_DMAC_CORE is not set
-# CONFIG_DW_DMAC is not set
-CONFIG_PL330_DMA=y
-# CONFIG_FSL_EDMA is not set
-CONFIG_DMA_ENGINE=y
-CONFIG_DMA_OF=y
-
-#
-# DMA Clients
-#
-# CONFIG_ASYNC_TX_DMA is not set
-# CONFIG_DMATEST is not set
+# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VFIO is not set
@@ -2258,42 +1960,7 @@
#
# Microsoft Hyper-V guest support
#
-CONFIG_STAGING=y
-# CONFIG_USBIP_CORE is not set
-# CONFIG_W35UND is not set
-# CONFIG_PRISM2_USB is not set
-# CONFIG_COMEDI is not set
-# CONFIG_RTLLIB is not set
-# CONFIG_R8712U is not set
-# CONFIG_R8188EU is not set
-# CONFIG_TRANZPORT is not set
-# CONFIG_VT6656 is not set
-# CONFIG_USB_ENESTORAGE is not set
-# CONFIG_BCM_WIMAX is not set
-# CONFIG_FT1000 is not set
-
-#
-# Speakup console speech
-#
-# CONFIG_SPEAKUP is not set
-# CONFIG_TOUCHSCREEN_CLEARPAD_TM1217 is not set
-# CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set
-# CONFIG_STAGING_MEDIA is not set
-
-#
-# Android
-#
-# CONFIG_ANDROID is not set
-# CONFIG_USB_WPAN_HCD is not set
-# CONFIG_WIMAX_GDM72XX is not set
-# CONFIG_LTE_GDM724X is not set
-# CONFIG_CED1401 is not set
-# CONFIG_DRM_IMX is not set
-# CONFIG_DGRP is not set
-# CONFIG_LUSTRE_FS is not set
-# CONFIG_XILLYBUS is not set
-# CONFIG_DGAP is not set
-# CONFIG_GS_FPGABOOT is not set
+# CONFIG_STAGING is not set
#
# SOC (System On Chip) specific Drivers
@@ -2308,7 +1975,7 @@
CONFIG_COMMON_CLK_MAX77686=y
# CONFIG_COMMON_CLK_SI5351 is not set
# CONFIG_COMMON_CLK_SI570 is not set
-CONFIG_COMMON_CLK_S2MPS11=y
+# CONFIG_COMMON_CLK_S2MPS11 is not set
# CONFIG_COMMON_CLK_QCOM is not set
CONFIG_COMMON_CLK_SAMSUNG=y
@@ -2316,6 +1983,8 @@
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_OF=y
+CONFIG_ARM_ARCH_TIMER=y
+CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y
CONFIG_CLKSRC_EXYNOS_MCT=y
CONFIG_CLKSRC_SAMSUNG_PWM=y
# CONFIG_SH_TIMER_CMT is not set
@@ -2329,7 +1998,6 @@
CONFIG_OF_IOMMU=y
CONFIG_EXYNOS_IOMMU=y
# CONFIG_EXYNOS_IOMMU_DEBUG is not set
-# CONFIG_ARM_SMMU is not set
#
# Remoteproc drivers
@@ -2339,34 +2007,11 @@
#
# Rpmsg drivers
#
-CONFIG_PM_DEVFREQ=y
-
-#
-# DEVFREQ Governors
-#
-CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y
-# CONFIG_DEVFREQ_GOV_PERFORMANCE is not set
-# CONFIG_DEVFREQ_GOV_POWERSAVE is not set
-# CONFIG_DEVFREQ_GOV_USERSPACE is not set
-
-#
-# DEVFREQ Drivers
-#
-CONFIG_ARM_EXYNOS5_BUS_DEVFREQ=y
-CONFIG_EXTCON=y
-
-#
-# Extcon Device Drivers
-#
-# CONFIG_EXTCON_GPIO is not set
-# CONFIG_EXTCON_MAX8997 is not set
+# CONFIG_PM_DEVFREQ is not set
+# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
-CONFIG_PWM=y
-CONFIG_PWM_SYSFS=y
-# CONFIG_PWM_FSL_FTM is not set
-# CONFIG_PWM_PCA9685 is not set
-CONFIG_PWM_SAMSUNG=y
+# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
CONFIG_GIC_NON_BANKED=y
@@ -2381,7 +2026,7 @@
CONFIG_PHY_EXYNOS_MIPI_VIDEO=y
CONFIG_PHY_EXYNOS_DP_VIDEO=y
# CONFIG_BCM_KONA_USB2_PHY is not set
-CONFIG_PHY_EXYNOS5250_SATA=y
+# CONFIG_PHY_EXYNOS5250_SATA is not set
CONFIG_PHY_SAMSUNG_USB2=y
CONFIG_PHY_EXYNOS4210_USB2=y
CONFIG_PHY_EXYNOS4X12_USB2=y
@@ -2417,15 +2062,14 @@
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
-CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
-CONFIG_FANOTIFY=y
+# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
-CONFIG_AUTOFS4_FS=m
+# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
@@ -2460,7 +2104,6 @@
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
-# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
@@ -2556,7 +2199,7 @@
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
-CONFIG_BOOT_PRINTK_DELAY=y
+# CONFIG_BOOT_PRINTK_DELAY is not set
#
# Compile-time checks and compiler options
@@ -2626,7 +2269,7 @@
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_LIST is not set
-CONFIG_DEBUG_PI_LIST=y
+# CONFIG_DEBUG_PI_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
@@ -2715,7 +2358,6 @@
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
-CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
@@ -2739,15 +2381,15 @@
#
# Authenticated Encryption with Associated Data
#
-CONFIG_CRYPTO_CCM=m
+# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
-CONFIG_CRYPTO_SEQIV=m
+# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
-CONFIG_CRYPTO_CTR=m
+# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
@@ -2789,7 +2431,7 @@
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
-CONFIG_CRYPTO_ARC4=m
+# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
@@ -2819,7 +2461,7 @@
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
-CONFIG_CRYPTO_DEV_S5P=y
+# CONFIG_CRYPTO_DEV_S5P is not set
# CONFIG_BINARY_PRINTF is not set
#
@@ -2873,7 +2515,7 @@
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
-CONFIG_AVERAGE=y
+# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
CONFIG_LIBFDT=y
@@ -2889,11 +2531,4 @@
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
-CONFIG_HAVE_KVM_IRQCHIP=y
-CONFIG_KVM_MMIO=y
-CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
-CONFIG_VIRTUALIZATION=y
-CONFIG_KVM=y
-CONFIG_KVM_ARM_HOST=y
-CONFIG_KVM_ARM_MAX_VCPUS=4
-CONFIG_KVM_ARM_VGIC=y
+# CONFIG_VIRTUALIZATION is not set
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-08-01 7:02 ` Ajay kumar
2014-08-01 12:13 ` Andreas Färber
@ 2014-08-01 14:57 ` Andreas Färber
1 sibling, 0 replies; 70+ messages in thread
From: Andreas Färber @ 2014-08-01 14:57 UTC (permalink / raw)
To: Ajay kumar
Cc: Thierry Reding, Ajay Kumar, dri-devel, linux-samsung-soc,
devicetree, InKi Dae, Rob Clark, Daniel Vetter, Sean Paul,
Jingoo Han, sunil joshi, Prashanth G, Doug Anderson,
Javier Martinez Canillas
Ajay,
Am 01.08.2014 09:02, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 7:52 PM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 31.07.2014 12:23, schrieb Thierry Reding:
>>> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote:
>>>> Am 31.07.2014 10:38, schrieb Ajay kumar:
>>>>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>>>>> bootup logo on Skate(a variant of spring which also contains ps8622).
>>>>> I have tried both exynos_defconfig and multi_v7_defconfig.
>>>>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>>>>> in configs.
>> [...]
>>> If you have something like simplefb enabled in addition to a DRM driver,
>>> then perhaps the DRM driver isn't properly taking over the framebuffer
>>> console.
>>
>> So, with simplefb reverted in U-Boot and ...
>>
>> * with just the v6 applied (...~2), I get only a black screen from
>> Linux, no penguins, but the backlight seems on. System comes up okay,
>> ssh available, and nothing stands out in dmesg.
>>
>> * with the two iommu patches on top, something breaks badly, no
>> backlight, no USB/network, system inaccessible.
>> I.e. U-Boot had no noticeable impact on these symptoms.
>>
>> * with the iommu patches, but dp-controller, ps8622, panel commented
>> out, I do get backlight but USB/network not working, system inaccessible.
>>
>> With simplefb support in U-Boot and with just v6 applied, but
>> dp-controller, ps8622, panel commented out, things work as well as
>> before, i.e. this series has no bad side effects. Note that I never
>> claimed Ajay's series were broken, just reported that things regressed
>> for me from v4, which may well be DT-related.
>>
>> The iommu patches interfere with my USB somehow (none or not all devices
>> powered; with v4, plugging my wifi dongle led to oops but ethernet
>> dongle worked, so not entirely new symptom), which is bad since my
>> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
>> so USB based network is my only alternative to a working display once we
>> reach userspace.
> Well, there are 2 variants here:
> 1) Bootloader
> 2) config
Unfortunately your config doesn't work for me either, on my latest
spring-bridge.v6 branch.
> Type of the bootloader should not matter unless its switching on
> FET1 and FET6 of tps65090 for you.
It does switch them on, if I'm reading correctly:
https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L599
https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L907
Another observation I made is that sometimes in my testing (didn't spot
a pattern yet) after reboot or power-off/power-on the initial white
screen with the warning did not come up (no backlight), but Ctrl+U
worked fine and chain-loaded nv u-boot came up on screen okay.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
` (8 preceding siblings ...)
2014-07-27 18:22 ` [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Andreas Färber
@ 2014-07-30 9:56 ` Thierry Reding
9 siblings, 0 replies; 70+ messages in thread
From: Thierry Reding @ 2014-07-30 9:56 UTC (permalink / raw)
To: Ajay Kumar
Cc: dri-devel, linux-samsung-soc, devicetree, inki.dae, robdclark,
daniel.vetter, seanpaul, ajaynumb, jg1.han, joshi, prashanth.g
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
On Sat, Jul 26, 2014 at 12:52:02AM +0530, Ajay Kumar wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit and exynos5800-peach-pi boards.
Hi Ajay,
I very much like where this is going. There are a few rough edges still,
but generally this is pretty much what I had imagined. Thanks for
bearing with me.
Generally I think it would be safer to restructure some of the patches a
little so that they can be more easily applied and keep bisectability.
I'll go into more detail in the individual patches.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread