Re: [PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI
On Wed, Mar 4, 2015 at 2:30 PM, Andrzej Hajda a.ha...@samsung.com wrote: On 03/02/2015 09:40 AM, Ajay kumar wrote: Hi Andrej, On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda a.ha...@samsung.com wrote: Hi Ajay, Thanks for the patch. Thanks for reviewing the patch. On 02/26/2015 04:24 PM, Ajay Kumar wrote: Modify the exynos HDMI driver to support Exynos7 HDMI 1.4. * Add phy configs for Exynos7. * Exynos7 has a different clock structure for HDMI, so introduce the new clocks. * Add sysreg support to enable HDMI SYSREG on Exynos7. * Exynos7 based boards need a DCDC_EN and LS_EN pins for powering up HDMI. Add support for that too. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/video/exynos_hdmi.txt | 21 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 252 drivers/gpu/drm/exynos/regs-hdmi.h |4 + 3 files changed, 231 insertions(+), 46 deletions(-) diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 1fd8cf9..bb22a60 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -6,6 +6,7 @@ Required properties: 2) samsung,exynos4210-hdmi 3) samsung,exynos4212-hdmi 4) samsung,exynos5420-hdmi + 5) samsung,exynos7-hdmi Why not samsung,exynos7420-hdmi ? What compatible will you use for Exynos7430 or higher chip number? I will leave this decision to Inki Dae or Kukjin. - reg: physical base address of the hdmi and length of memory mapped region. - interrupts: interrupt number to the cpu. @@ -15,21 +16,33 @@ Required properties: c) optional flags and pull up/down. - clocks: list of clock IDs from SoC clock driver. a) hdmi: Gate of HDMI IP bus clock. - b) sclk_hdmi: Gate of HDMI special clock. - c) sclk_pixel: Pixel special clock, one of the two possible inputs of + HDMI clocks necessary for non exynos7: + b) sclk_hdmi: Gate of HDMI special clock. + c) sclk_pixel: Pixel special clock, one of the two possible inputs of HDMI clock mux. - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of + d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of HDMI clock mux. - e) mout_hdmi: It is required by the driver to switch between the 2 + e) mout_hdmi: It is required by the driver to switch between the 2 parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable after configuration, parent is set to sclk_hdmiphy else sclk_pixel. + HDMI clocks necessary for Exynos7: + b) pclk_hdmiphy: Gate to HDMIPHY clock. According to specs there is also pclk_hdmi, why do you specify only this one? Right, I have reused hdmi gating clock for pclk_hdmi. That is why I have left hdmi clock as common for exynos7 and non-exynos7. IMO it would be better to use separate entry for pclk_hdmi. Ok. + c) hdmi_pixel: Gate clock of MUX output for I_PIXEL_CLK. + d) hdmi_tmds: Gate clock of MUX output for I_TMDS_CLK. According to specs these clocks should be named i_pixel_clk and i_tmds_clk, shouldn't they? I actually took these changes from an internal code(non-DRM). The original author used these names, and I just carried the same names. :) - clock-names: aliases as per driver requirements for above clock IDs: hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and mout_hdmi. - ddc: phandle to the hdmi ddc node - phy: phandle to the hdmi phy node - samsung,syscon-phandle: phandle for system controller node for PMU. +Only for Exynos7(when compatible = samsung,exynos7-hdmi): +- samsung,sysreg-phandle: phandle for system controller node for SYSREG block. + +Optional properties: +- dcdc-gpios: OF device-tree gpio specification for HDMI_DCDC_EN pin. +- lsen-gpios: OF device-tree gpio specification for HDMI_LS_EN pin. What is purpose of these gpios? These 2 GPIOs need to be enabled to powerup HDMI on exynos7-espresso board. Other boards need not provide the GPIO. HDMI is internal IP of SoC, so it is rather not configurable via pins. Pin names suggests they are for DC-DC converter and level shifter, I guess these are for HDMI connector, not the HDMI IP, am I right? Right, this is for HDMI connector. Maybe better option is to use pinctrl for these gpios, or use gpio regulator, hard to guess without documentation. Why should I not use devm_gpiod_get_optional for these GPIOs? Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drm/exynos: decon: Add support for DECON-EXT
On Wed, Mar 4, 2015 at 7:44 PM, Andrzej Hajda a.ha...@samsung.com wrote:
On 03/02/2015 11:57 AM, Ajay kumar wrote:
On Mon, Mar 2, 2015 at 1:38 PM, Andrzej Hajda a.ha...@samsung.com wrote:
On 02/26/2015 04:24 PM, Ajay Kumar wrote:
* Modify DECON-INT driver to support DECON-EXT.
* Add a table of porch values needed to set timing registers of DECON-EXT.
* DECON-EXT supports only H/w Triggered COMMAND mode.
* DECON-EXT supports only one DMA window(window 1), so modify
all window management routines to support 2 windows of DECON-INT
and 1 window of DECON-EXT.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos7-decon.txt|8 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 229
++--
include/video/exynos7_decon.h | 13 ++
3 files changed, 230 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
index f5f9c8d..87350c0 100644
--- a/Documentation/devicetree/bindings/video/exynos7-decon.txt
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -2,10 +2,14 @@ Device-Tree bindings for Samsung Exynos7 SoC display
controller (DECON)
DECON (Display and Enhancement Controller) is the Display Controller for
the
Exynos7 series of SoCs which transfers the image data from a video memory
-buffer to an external LCD interface.
+buffer to an external LCD/HDMI interface.
+
+Exynos7 supports DECON-INT for generating video signals for LCD.
+Exynos7 supports DECON-EXT for generating video signals for HDMI.
Required properties:
-- compatible: value should be samsung,exynos7-decon;
+- compatible: value should be samsung,exynos7-decon-int for DECON-INT;
+ value should be samsung,exynos7-decon-ext for DECON-EXT;
- reg: physical base address and length of the DECON registers set.
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2..9e2d083 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -41,6 +41,28 @@
#define WINDOWS_NR 2
Maybe it would be better to rename it to MAX_WINDOWS_NR
Ok.
+#define DECON_EXT_CH_MAPPING 0x432105
I am not familiar with decon, could you explain what exactly
this mapping means and why is it fixed in the driver to this value,
not default one. By the way my specs says bits 0-3 are reserverd
and here it seems you are using them.
I reused the value from the code which hardware team shared with me.
It tries to map a input hardware channel(IDMA or VPP channel) onto
a hardware window in DECON.
Channel_N is mapped onto window_N in case of DECON-INT.
In case of DECON-EXT, Channel 0 should be mapped to window 1 of DECON-EXT.
So, basically for the changes I have made, I should ideally set only
bits [4:6] to 0x1,
and leave other bits untouched, though modifying other bits wouldn't
affect in anyway.
+
+enum decon_type {
+ DECON_INT,
+ DECON_EXT,
+} decon_type;
+
+struct decon_driver_data {
+ enum decon_type decon_type;
+ unsigned intnr_windows;
+};
+
+static struct decon_driver_data exynos7_decon_int_driver_data = {
+ .decon_type = DECON_INT,
I wonder if it wouldn't be better to use different fields to describe
each capability/property instead of decon_type. For example
.display_type = EXYNOS_DISPLAY_TYPE_LCD,
.map_channels = 0,
Ok, let me list down the differences between INT and EXT.
1) Only h/w triggered command mode for DECON-EXT.
2) Need to feed modified porch values(decon_ext_timings)
3) Input channel to H/w window mapping(WINCHMAP)
4) default_window - 0 for DECON-INT and 1 for DECON-EXT
Out of the above differences, the first 3 can somehow be converted
to capability/property and embedded into driver_data.
But the 4th difference is bothering me.
I tried using something like start_window, end_window and tried to make
The code common for DECON-INT and DECON-EXT, and it just doesn't work.
ex:
start_window = 0, end_window = 1 for DECON-INT
start_window = 1, end_window = 1 for DECON-EXT
When win_commit gets called for window 0 from crtc_commit/plane_commit:
Configure start_window(0 for DECON-INT and 1 for DECON-EXT)
When win_commit is called from decon_apply, it is called for window 1 also.
That time win_commit can skip updating actual window 1.
How do I take care of this ambiguity? This case happens with
win_disable routine also!
I think clear distinction where are we using hw windows and where sw
windows should be enough.
For example the loop iterating over all windows can look like:
for (win = 0; win drv_data-nr_windows; win++) {
int hw_win = get_hw_win(ctx, win);
val = readl(ctx-regs + WINCON(hw_win));
}
Where get_hw_win can look
Re: [PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI
On Wed, Mar 4, 2015 at 4:02 PM, Andrzej Hajda a.ha...@samsung.com wrote: On 03/04/2015 10:54 AM, Ajay kumar wrote: On Wed, Mar 4, 2015 at 2:30 PM, Andrzej Hajda a.ha...@samsung.com wrote: On 03/02/2015 09:40 AM, Ajay kumar wrote: Hi Andrej, On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda a.ha...@samsung.com wrote: Hi Ajay, Thanks for the patch. Thanks for reviewing the patch. On 02/26/2015 04:24 PM, Ajay Kumar wrote: Modify the exynos HDMI driver to support Exynos7 HDMI 1.4. * Add phy configs for Exynos7. * Exynos7 has a different clock structure for HDMI, so introduce the new clocks. * Add sysreg support to enable HDMI SYSREG on Exynos7. * Exynos7 based boards need a DCDC_EN and LS_EN pins for powering up HDMI. Add support for that too. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/video/exynos_hdmi.txt | 21 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 252 drivers/gpu/drm/exynos/regs-hdmi.h |4 + 3 files changed, 231 insertions(+), 46 deletions(-) diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 1fd8cf9..bb22a60 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -6,6 +6,7 @@ Required properties: 2) samsung,exynos4210-hdmi 3) samsung,exynos4212-hdmi 4) samsung,exynos5420-hdmi + 5) samsung,exynos7-hdmi Why not samsung,exynos7420-hdmi ? What compatible will you use for Exynos7430 or higher chip number? I will leave this decision to Inki Dae or Kukjin. - reg: physical base address of the hdmi and length of memory mapped region. - interrupts: interrupt number to the cpu. @@ -15,21 +16,33 @@ Required properties: c) optional flags and pull up/down. - clocks: list of clock IDs from SoC clock driver. a) hdmi: Gate of HDMI IP bus clock. - b) sclk_hdmi: Gate of HDMI special clock. - c) sclk_pixel: Pixel special clock, one of the two possible inputs of + HDMI clocks necessary for non exynos7: + b) sclk_hdmi: Gate of HDMI special clock. + c) sclk_pixel: Pixel special clock, one of the two possible inputs of HDMI clock mux. - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of + d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of HDMI clock mux. - e) mout_hdmi: It is required by the driver to switch between the 2 + e) mout_hdmi: It is required by the driver to switch between the 2 parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable after configuration, parent is set to sclk_hdmiphy else sclk_pixel. + HDMI clocks necessary for Exynos7: + b) pclk_hdmiphy: Gate to HDMIPHY clock. According to specs there is also pclk_hdmi, why do you specify only this one? Right, I have reused hdmi gating clock for pclk_hdmi. That is why I have left hdmi clock as common for exynos7 and non-exynos7. IMO it would be better to use separate entry for pclk_hdmi. Ok. + c) hdmi_pixel: Gate clock of MUX output for I_PIXEL_CLK. + d) hdmi_tmds: Gate clock of MUX output for I_TMDS_CLK. According to specs these clocks should be named i_pixel_clk and i_tmds_clk, shouldn't they? I actually took these changes from an internal code(non-DRM). The original author used these names, and I just carried the same names. :) - clock-names: aliases as per driver requirements for above clock IDs: hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and mout_hdmi. - ddc: phandle to the hdmi ddc node - phy: phandle to the hdmi phy node - samsung,syscon-phandle: phandle for system controller node for PMU. +Only for Exynos7(when compatible = samsung,exynos7-hdmi): +- samsung,sysreg-phandle: phandle for system controller node for SYSREG block. + +Optional properties: +- dcdc-gpios: OF device-tree gpio specification for HDMI_DCDC_EN pin. +- lsen-gpios: OF device-tree gpio specification for HDMI_LS_EN pin. What is purpose of these gpios? These 2 GPIOs need to be enabled to powerup HDMI on exynos7-espresso board. Other boards need not provide the GPIO. HDMI is internal IP of SoC, so it is rather not configurable via pins. Pin names suggests they are for DC-DC converter and level shifter, I guess these are for HDMI connector, not the HDMI IP, am I right? Right, this is for HDMI connector. Maybe better option is to use pinctrl for these gpios, or use gpio regulator, hard to guess without documentation. Why should I not use devm_gpiod_get_optional for these GPIOs? Because these gpios are board specific so they should not be handled by hdmi driver. I still do not know what exactly are they for. If they only drive power for pin18 of hdmi connector the best solution is to create
Re: [PATCH 2/2] drm/exynos: decon: Add support for DECON-EXT
On Mon, Mar 2, 2015 at 1:38 PM, Andrzej Hajda a.ha...@samsung.com wrote:
On 02/26/2015 04:24 PM, Ajay Kumar wrote:
* Modify DECON-INT driver to support DECON-EXT.
* Add a table of porch values needed to set timing registers of DECON-EXT.
* DECON-EXT supports only H/w Triggered COMMAND mode.
* DECON-EXT supports only one DMA window(window 1), so modify
all window management routines to support 2 windows of DECON-INT
and 1 window of DECON-EXT.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos7-decon.txt|8 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 229
++--
include/video/exynos7_decon.h | 13 ++
3 files changed, 230 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
index f5f9c8d..87350c0 100644
--- a/Documentation/devicetree/bindings/video/exynos7-decon.txt
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -2,10 +2,14 @@ Device-Tree bindings for Samsung Exynos7 SoC display
controller (DECON)
DECON (Display and Enhancement Controller) is the Display Controller for the
Exynos7 series of SoCs which transfers the image data from a video memory
-buffer to an external LCD interface.
+buffer to an external LCD/HDMI interface.
+
+Exynos7 supports DECON-INT for generating video signals for LCD.
+Exynos7 supports DECON-EXT for generating video signals for HDMI.
Required properties:
-- compatible: value should be samsung,exynos7-decon;
+- compatible: value should be samsung,exynos7-decon-int for DECON-INT;
+ value should be samsung,exynos7-decon-ext for DECON-EXT;
- reg: physical base address and length of the DECON registers set.
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2..9e2d083 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -41,6 +41,28 @@
#define WINDOWS_NR 2
Maybe it would be better to rename it to MAX_WINDOWS_NR
Ok.
+#define DECON_EXT_CH_MAPPING 0x432105
I am not familiar with decon, could you explain what exactly
this mapping means and why is it fixed in the driver to this value,
not default one. By the way my specs says bits 0-3 are reserverd
and here it seems you are using them.
I reused the value from the code which hardware team shared with me.
It tries to map a input hardware channel(IDMA or VPP channel) onto
a hardware window in DECON.
Channel_N is mapped onto window_N in case of DECON-INT.
In case of DECON-EXT, Channel 0 should be mapped to window 1 of DECON-EXT.
So, basically for the changes I have made, I should ideally set only
bits [4:6] to 0x1,
and leave other bits untouched, though modifying other bits wouldn't
affect in anyway.
+
+enum decon_type {
+ DECON_INT,
+ DECON_EXT,
+} decon_type;
+
+struct decon_driver_data {
+ enum decon_type decon_type;
+ unsigned intnr_windows;
+};
+
+static struct decon_driver_data exynos7_decon_int_driver_data = {
+ .decon_type = DECON_INT,
I wonder if it wouldn't be better to use different fields to describe
each capability/property instead of decon_type. For example
.display_type = EXYNOS_DISPLAY_TYPE_LCD,
.map_channels = 0,
Ok, let me list down the differences between INT and EXT.
1) Only h/w triggered command mode for DECON-EXT.
2) Need to feed modified porch values(decon_ext_timings)
3) Input channel to H/w window mapping(WINCHMAP)
4) default_window - 0 for DECON-INT and 1 for DECON-EXT
Out of the above differences, the first 3 can somehow be converted
to capability/property and embedded into driver_data.
But the 4th difference is bothering me.
I tried using something like start_window, end_window and tried to make
The code common for DECON-INT and DECON-EXT, and it just doesn't work.
ex:
start_window = 0, end_window = 1 for DECON-INT
start_window = 1, end_window = 1 for DECON-EXT
When win_commit gets called for window 0 from crtc_commit/plane_commit:
Configure start_window(0 for DECON-INT and 1 for DECON-EXT)
When win_commit is called from decon_apply, it is called for window 1 also.
That time win_commit can skip updating actual window 1.
How do I take care of this ambiguity? This case happens with
win_disable routine also!
This way the code will be cleaner (less ifs).
+ .nr_windows = 2,
+};
+
+static struct decon_driver_data exynos7_decon_ext_driver_data = {
+ .decon_type = DECON_EXT,
+ .nr_windows = 1,
+};
+
struct decon_win_data {
unsigned intovl_x;
unsigned intovl_y;
@@ -76,15 +98,28 @@ struct decon_context {
atomic_twait_vsync_event;
struct exynos_drm_panel_info panel;
+ struct decon_driver_data *driver_data
Re: [PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI
Hi Andrej,
On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda a.ha...@samsung.com wrote:
Hi Ajay,
Thanks for the patch.
Thanks for reviewing the patch.
On 02/26/2015 04:24 PM, Ajay Kumar wrote:
Modify the exynos HDMI driver to support Exynos7 HDMI 1.4.
* Add phy configs for Exynos7.
* Exynos7 has a different clock structure for HDMI,
so introduce the new clocks.
* Add sysreg support to enable HDMI SYSREG on Exynos7.
* Exynos7 based boards need a DCDC_EN and LS_EN pins
for powering up HDMI. Add support for that too.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt | 21 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 252
drivers/gpu/drm/exynos/regs-hdmi.h |4 +
3 files changed, 231 insertions(+), 46 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 1fd8cf9..bb22a60 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -6,6 +6,7 @@ Required properties:
2) samsung,exynos4210-hdmi
3) samsung,exynos4212-hdmi
4) samsung,exynos5420-hdmi
+ 5) samsung,exynos7-hdmi
Why not samsung,exynos7420-hdmi ?
What compatible will you use for Exynos7430 or higher chip number?
I will leave this decision to Inki Dae or Kukjin.
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -15,21 +16,33 @@ Required properties:
c) optional flags and pull up/down.
- clocks: list of clock IDs from SoC clock driver.
a) hdmi: Gate of HDMI IP bus clock.
- b) sclk_hdmi: Gate of HDMI special clock.
- c) sclk_pixel: Pixel special clock, one of the two possible inputs of
+ HDMI clocks necessary for non exynos7:
+ b) sclk_hdmi: Gate of HDMI special clock.
+ c) sclk_pixel: Pixel special clock, one of the two possible inputs of
HDMI clock mux.
- d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
+ d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
HDMI clock mux.
- e) mout_hdmi: It is required by the driver to switch between the 2
+ e) mout_hdmi: It is required by the driver to switch between the 2
parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable
after configuration, parent is set to sclk_hdmiphy else
sclk_pixel.
+ HDMI clocks necessary for Exynos7:
+ b) pclk_hdmiphy: Gate to HDMIPHY clock.
According to specs there is also pclk_hdmi, why do you specify only this
one?
Right, I have reused hdmi gating clock for pclk_hdmi. That is why I have
left hdmi clock as common for exynos7 and non-exynos7.
+ c) hdmi_pixel: Gate clock of MUX output for I_PIXEL_CLK.
+ d) hdmi_tmds: Gate clock of MUX output for I_TMDS_CLK.
According to specs these clocks should be named i_pixel_clk and
i_tmds_clk, shouldn't they?
I actually took these changes from an internal code(non-DRM).
The original author used these names, and I just carried the same names. :)
- clock-names: aliases as per driver requirements for above clock IDs:
hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and mout_hdmi.
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
- samsung,syscon-phandle: phandle for system controller node for PMU.
+Only for Exynos7(when compatible = samsung,exynos7-hdmi):
+- samsung,sysreg-phandle: phandle for system controller node for SYSREG
block.
+
+Optional properties:
+- dcdc-gpios: OF device-tree gpio specification for HDMI_DCDC_EN pin.
+- lsen-gpios: OF device-tree gpio specification for HDMI_LS_EN pin.
What is purpose of these gpios?
These 2 GPIOs need to be enabled to powerup HDMI on exynos7-espresso board.
Other boards need not provide the GPIO.
+
Example:
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 229b361..1b579ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -67,6 +67,7 @@
enum hdmi_type {
HDMI_TYPE13,
HDMI_TYPE14,
+ HDMI_TYPE14_7,
};
struct hdmi_driver_data {
@@ -82,6 +83,9 @@ struct hdmi_resources {
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
struct clk *mout_hdmi;
+ struct clk *hdmi_pixel;
+ struct clk *pclk_hdmiphy;
+ struct clk *hdmi_tmds;
struct regulator_bulk_data *regul_bulk;
struct regulator*reg_hdmi_en;
int regul_count;
@@ -210,6 +214,7 @@ struct hdmi_context {
unsigned int
[PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI
Modify the exynos HDMI driver to support Exynos7 HDMI 1.4.
* Add phy configs for Exynos7.
* Exynos7 has a different clock structure for HDMI,
so introduce the new clocks.
* Add sysreg support to enable HDMI SYSREG on Exynos7.
* Exynos7 based boards need a DCDC_EN and LS_EN pins
for powering up HDMI. Add support for that too.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt | 21 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 252
drivers/gpu/drm/exynos/regs-hdmi.h |4 +
3 files changed, 231 insertions(+), 46 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 1fd8cf9..bb22a60 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -6,6 +6,7 @@ Required properties:
2) samsung,exynos4210-hdmi
3) samsung,exynos4212-hdmi
4) samsung,exynos5420-hdmi
+ 5) samsung,exynos7-hdmi
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -15,21 +16,33 @@ Required properties:
c) optional flags and pull up/down.
- clocks: list of clock IDs from SoC clock driver.
a) hdmi: Gate of HDMI IP bus clock.
- b) sclk_hdmi: Gate of HDMI special clock.
- c) sclk_pixel: Pixel special clock, one of the two possible inputs of
+ HDMI clocks necessary for non exynos7:
+b) sclk_hdmi: Gate of HDMI special clock.
+c) sclk_pixel: Pixel special clock, one of the two possible inputs of
HDMI clock mux.
- d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
+d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
HDMI clock mux.
- e) mout_hdmi: It is required by the driver to switch between the 2
+e) mout_hdmi: It is required by the driver to switch between the 2
parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable
after configuration, parent is set to sclk_hdmiphy else
sclk_pixel.
+ HDMI clocks necessary for Exynos7:
+b) pclk_hdmiphy: Gate to HDMIPHY clock.
+c) hdmi_pixel: Gate clock of MUX output for I_PIXEL_CLK.
+d) hdmi_tmds: Gate clock of MUX output for I_TMDS_CLK.
- clock-names: aliases as per driver requirements for above clock IDs:
hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and mout_hdmi.
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
- samsung,syscon-phandle: phandle for system controller node for PMU.
+Only for Exynos7(when compatible = samsung,exynos7-hdmi):
+- samsung,sysreg-phandle: phandle for system controller node for SYSREG block.
+
+Optional properties:
+- dcdc-gpios: OF device-tree gpio specification for HDMI_DCDC_EN pin.
+- lsen-gpios: OF device-tree gpio specification for HDMI_LS_EN pin.
+
Example:
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 229b361..1b579ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -67,6 +67,7 @@
enum hdmi_type {
HDMI_TYPE13,
HDMI_TYPE14,
+ HDMI_TYPE14_7,
};
struct hdmi_driver_data {
@@ -82,6 +83,9 @@ struct hdmi_resources {
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
struct clk *mout_hdmi;
+ struct clk *hdmi_pixel;
+ struct clk *pclk_hdmiphy;
+ struct clk *hdmi_tmds;
struct regulator_bulk_data *regul_bulk;
struct regulator*reg_hdmi_en;
int regul_count;
@@ -210,6 +214,7 @@ struct hdmi_context {
unsigned intphy_conf_count;
struct regmap *pmureg;
+ struct regmap *sysreg;
enum hdmi_type type;
};
@@ -584,6 +589,61 @@ static const struct hdmiphy_config hdmiphy_5420_configs[]
= {
},
};
+static const struct hdmiphy_config hdmiphy_7_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0xD2, 0x87, 0xB0, 0x01, 0x00, 0x88, 0x02,
+ 0x4F, 0x30, 0x33, 0x65, 0x00, 0xE4, 0x24, 0x80,
+ 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x0B, 0x00, 0x10,
+ 0x60, 0x0F, 0x00, 0x00, 0x08, 0x00, 0x3E, 0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0xD1, 0x5A, 0xFA, 0xE4, 0x12, 0x88, 0x43,
+ 0x4F, 0x30, 0x33, 0x65, 0x00, 0xE4, 0x24, 0x80
Re: [PATCH V4] drm/exynos: Add DECON driver
ping.
On Thu, Feb 5, 2015 at 9:24 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
This patch 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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
The current version of the driver supports video mode displays.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Address comments from Pankaj and do few cleanups.
Changes since V2:
-- Address more comments from Pankaj and cleanup.
Changes since V3:
-- Rebase on exynos-drm-next. Pull in changes from
FIMD driver.
-- Address comments from Inki Dae. Remove unnecessary
functions and delays. Make use of i80-if-timings
node to differentiate between command/video mode.
.../devicetree/bindings/video/exynos7-decon.txt| 68 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 991
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 349 +++
7 files changed, 1424 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..f5f9c8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,68 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk.
+- i80-if-timings: timing configuration for lcd i80 interface support.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for DECON, as described in document [1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos
[PATCH V4] drm/exynos: Add DECON driver
This patch 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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
The current version of the driver supports video mode displays.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Address comments from Pankaj and do few cleanups.
Changes since V2:
-- Address more comments from Pankaj and cleanup.
Changes since V3:
-- Rebase on exynos-drm-next. Pull in changes from
FIMD driver.
-- Address comments from Inki Dae. Remove unnecessary
functions and delays. Make use of i80-if-timings
node to differentiate between command/video mode.
.../devicetree/bindings/video/exynos7-decon.txt| 68 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 991
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 349 +++
7 files changed, 1424 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..f5f9c8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,68 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk.
+- i80-if-timings: timing configuration for lcd i80 interface support.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for DECON, as described in document [1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 627aaa0..378cfd5 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,9 +24,16 @@ config DRM_EXYNOS_FIMD
Re: [PATCH V3] drm/exynos: Add DECON driver
Hi Inki,
On Mon, Dec 8, 2014 at 7:09 PM, Inki Dae inki@samsung.com wrote:
On 2014년 12월 07일 21:04, 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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Address comments from Pankaj and do few cleanups.
Changes since V2:
-- Address more comments from Pankaj and cleanup.
.../devicetree/bindings/video/exynos7-decon.txt| 67 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1042
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 346 +++
7 files changed, 1471 insertions(+), 3 deletions(-)
create mode 100644
Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..14db519
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,67 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller
for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts
in the
+ order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+ format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+decon0_eclk, decon0_vclk.
Should the DECON driver really care about decon0_eclk and decon0_vclk?
If so then What is the purpose of these special clocks? I'm not sure
that these clocks should be cared by driver. Until now, Exynos driver
has cared about only video source and core source clocks.
Can you give me more details about the use of the special clocks?
All these 4 clocks are definitely needed for the DECON to function properly.
pclk_decon0 and aclk_decon0 are clocks needed for normal
operation of DECON.
decon0_eclk and decon0_vclk are like pixel clocks.
The clock diagram is present in the Exynos7 user manual in clock
generation chapter.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for FIMD, as described in document
[1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+ clock_disp ACLK_DECON_INT,
+ clock_disp SCLK_DECON_INT_ECLK,
+ clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry
Re: [PATCH 03/14] drm/bridge: make bridge registration independent of drm flow
Hi Rob,
On Fri, Jan 30, 2015 at 9:07 PM, Rob Clark robdcl...@gmail.com wrote:
On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.
In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
for the corresponding bridge so that the bridge receives
drm_device pointer and continues with connector and other
drm initializations.
The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.
The bridge devices register themselves onto global list of bridges
when they get probed by calling drm_bridge_add.
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 also call drm_bridge_attach to pass
on the drm_device to the bridge object.
drm_bridge_attach inturn calls bridge-funcs-attach so that
bridge can continue with drm related initializations.
ok, so I probably should have had a closer look at this before it
landed in drm-next, so if it is too late to revert (and deal w/
untangling subsequent patches that depend on this) some of these
issues we'll just have to fix with follow-on patches.
1) needs headerdoc for new fxns in drm_bridge.c, and needs to be added
in drm.tmpl
Ohh, I totally forgot. I will do this. Just point me to some recent
patch which updates docbook.
2) as far as I can tell, the new approach to cleaning up bridge
objects is to just let them leak !?!
I just checked. Only MSM hdmi_bridge is leaking, and this is because
it doesn't use devm_kzalloc. All other bridges use devm_kzalloc,
and hence that memory is automatically freed.
For MSM HDMI, we need to find a place to call hdmi_bridge_destroy.
I'll also need to update the new bridge in the msm edp code..
although that isn't such a big deal if I knew how this was *supposed*
to work..
You just need to convert drm_bridge_init to drm_bridge_attach, and
remove destroy callback. Refer this:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=b5217bf4692218d202d3d2cd772864fa1e10be4d
Regards,
Ajay Kumar
since what is there now at least doesn't look right..
BR,
-R
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/bridge/ptn3460.c | 27 +-
drivers/gpu/drm/drm_bridge.c | 91
drivers/gpu/drm/drm_crtc.c | 67 ---
drivers/gpu/drm/msm/hdmi/hdmi.c|4 +-
drivers/gpu/drm/msm/hdmi/hdmi.h|1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |6 +--
drivers/gpu/drm/sti/sti_hda.c | 10 +---
drivers/gpu/drm/sti/sti_hdmi.c | 10 +---
include/drm/bridge/ptn3460.h |8 +++
include/drm/drm_crtc.h | 26 -
11 files changed, 133 insertions(+), 119 deletions(-)
create mode 100644 drivers/gpu/drm/drm_bridge.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e620807..c83ef2d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
- drm_modeset_lock.o drm_atomic.o
+ drm_modeset_lock.o drm_atomic.o drm_bridge.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
index a2ddc8d..4a818c1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -176,24 +176,11 @@ static void ptn3460_post_disable(struct drm_bridge
*bridge)
{
}
-static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge
Re: [PATCH 03/14] drm/bridge: make bridge registration independent of drm flow
Hi, On Fri, Jan 30, 2015 at 9:29 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Jan 30, 2015 at 10:37:19AM -0500, Rob Clark wrote: On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar ajaykumar...@samsung.com wrote: I'll also need to update the new bridge in the msm edp code.. although that isn't such a big deal if I knew how this was *supposed* to work.. since what is there now at least doesn't look right.. I wonder whether the new dw-hdmi bridge code get fixed up too... I think its already fixed. Check this: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=b5217bf4692218d202d3d2cd772864fa1e10be4d Regards, Ajay Kumar -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V9 04/14] drm/bridge: ptn3460: Convert to i2c driver model
Hi Gustavo, I think Thierry already fixed it. Check this. http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/Kconfig Regards, Ajay On Thu, Jan 29, 2015 at 7:59 PM, Gustavo Padovan gust...@padovan.org wrote: Hi Ajay, 2015-01-20 Ajay Kumar ajaykumar...@samsung.com: Use drm_bridge helpers to modify the driver to support i2c driver model. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Inki Dae inki@samsung.com Tested-by: Rahul Sharma rahul.sha...@samsung.com Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- drivers/gpu/drm/bridge/Kconfig |2 + drivers/gpu/drm/bridge/ptn3460.c| 124 +-- drivers/gpu/drm/exynos/exynos_dp_core.c | 22 -- 3 files changed, 86 insertions(+), 62 deletions(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 884923f..4254c2b 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,5 +1,7 @@ config DRM_PTN3460 tristate PTN3460 DP/LVDS bridge depends on DRM + depends on OF I2C Adding I2C here is causing this circular dependency: scripts/kconfig/conf --silentoldconfig Kconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_PTN3460 drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_PTN3460 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB To solve this we just need to remove I2C from depends as DRM already selects I2C. This was already fixed by: commit 90bde571ad194adb039cb92a11a5b346f15eb610 Author: Arnd Bergmann a...@arndb.de Date: Tue Mar 25 12:06:46 2014 +0100 drm/bridge: PTN3460 needs DRM_KMS_HELPER The recently added PTN3460 device driver uses interfaces that are provided by the KMS helper infrastructure, so we should explicitly select that to avoid this linker error: ERROR: drm_helper_probe_single_connector_modes [drivers/gpu/drm/bridge/ptn3460.ko] undefined! ERROR: drm_helper_connector_dpms [drivers/gpu/drm/bridge/ptn3460.ko] undefined! We have to drop the I2C dependency to avoid a circular dependency chain, but that's ok because DRM already selects I2C. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Dave Airlie airl...@redhat.com But you may have introduced it again on a rebase. The following patch fixes it: diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 990b4b2..946d1ef 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,7 +1,6 @@ config DRM_PTN3460 tristate PTN3460 DP/LVDS bridge - depends on DRM - depends on OF I2C + depends on DRM OF select DRM_KMS_HELPER select DRM_PANEL ---help--- Gustavo -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V9 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
Hi Thierry,
I think you forgot to take this patch!
Can you check this?
Regards,
Ajay Kumar
On Tue, Jan 20, 2015 at 10:08 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
From: Vincent Palatin vpala...@chromium.org
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/bridge/Kconfig |9 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ps8622.c | 684
+++
3 files changed, 694 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8b426e2..d06eda3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -6,3 +6,12 @@ config DRM_PTN3460
select DRM_PANEL
---help---
ptn3460 eDP-LVDS bridge chip driver.
+
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on OF I2C
+ select DRM_PANEL
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
+ ---help---
+ parade eDP-LVDS bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..105da3e 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..5474a39
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,684 @@
+/*
+ * 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/backlight.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_graph.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
+
+/* 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 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#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
+
+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 gpio_desc *gpio_slp;
+ struct gpio_desc *gpio_rst;
+
+ u32 max_lane_count;
+ u32 lane_count;
+
+ bool enabled;
+};
+
+static inline struct ps8622_bridge *
+ bridge_to_ps8622(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct ps8622_bridge, bridge);
+}
+
+static inline struct ps8622_bridge *
+ connector_to_ps8622(struct drm_connector *connector)
+{
+ return container_of(connector, struct ps8622_bridge, connector);
+}
+
+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
Re: [PATCH V9 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints
Hi Kukjin,
On Fri, Jan 23, 2015 at 12:31 PM, Kukjin Kim kg...@kernel.org wrote:
Ajay Kumar wrote:
Define videoports and use endpoints to describe the connection between
the encoder, bridge and the panel, instead of using phandles.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
arch/arm/boot/dts/exynos5250-snow.dts | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index b9aeec4..1bd5d3a 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -183,7 +183,20 @@
powerdown-gpios = gpy2 5 GPIO_ACTIVE_HIGH;
reset-gpios = gpx1 5 GPIO_ACTIVE_HIGH;
edid-emulation = 5;
- panel = panel;
+
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+
+ port@1 {
+ bridge_in: endpoint {
+ remote-endpoint = dp_out;
+ };
+ };
+ };
};
};
@@ -228,6 +241,12 @@
compatible = auo,b116xw03;
power-supply = fet6;
backlight = backlight;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = bridge_out;
+ };
+ };
};
};
@@ -242,7 +261,14 @@
samsung,link-rate = 0x0a;
samsung,lane-count = 2;
samsung,hpd-gpio = gpx0 7 GPIO_ACTIVE_HIGH;
- bridge = ptn3460;
+
+ ports {
+ port@0 {
+ dp_out: endpoint {
+ remote-endpoint = bridge_in;
+ };
+ };
+ };
};
ehci {
--
1.7.9.5
I'm fine on the DT changes in this series, shall I take 13/14 and 14/14 in
Samsung tree?
Yes, please take these patches.
Thanks and regards,
Ajay Kumar
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
On Mon, Jan 19, 2015 at 10:35 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Thierry, On 01/19/2015 05:30 PM, Thierry Reding wrote: I know you probably are very busy but it would be great if you can take a look to this series to avoid another kernel release to be missed since we are already at v3.19-rc5. Only this version was posted 2 months ago and the first version of the series was sent on May, 2014 so it has been on the list for almost a year now... Tomi and Laurent had already agreed with the DT binging so I think that we can already merge these and if there are any remaining issues, those can be fixed during the 3.20 -rc cycle. I see only a single Tested-by on this series and that seems to be with a bunch of out-of-tree patches applied on top. Does this now actually work applied on top of upstream? Also it seems like many people actually want this to get merged but there's been no Reviewed-bys and only a single Tested-by? Is that as good as it's going to get? Good point, I provided some feedback on an early version of the series but I'm not an DRM expert so I couldn't review it in detail to provide my Reviewed-by. I did provide my Tested-by a long time ago though but looking at the patches it seems those were dropped so here goes again: For the whole series on an Exynos5420 Peach Pit and an Exynos5250 Snow Chromebooks: Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Also I think the last update was that Ajay was going to resend this based on v3.19-rc1 or something. Is that still going to happen? Otherwise I can probably try to apply as-is, but not sure how well it will. Ajay, Are you going to rebase and resend this series with all the provided tags? Gustavo and I have a rebased branch on top of 3.19-rc5 and one of us can post your series if you are not planning to do it. Yes, in a day or so. I am currently rebasing on 3.19-rc5 linux-next. I will add Tested-by from from Rahul, Javier, Inki, Sjoerd, and Gustavo. Only Inki has acked this till now. So, I will add Inki's Acked-by. Ajay Laurent and Tomi, You said that you are OK with the DT bindings now, does that count as an Acked-by or Reviewed-by for you at least for the DT bindings changes in the series? Thierry Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V9 05/14] drm/exynos: dp: support drm_bridge
Modify driver to support drm_bridge.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
.../devicetree/bindings/video/exynos_dp.txt| 12 +++
drivers/gpu/drm/exynos/exynos_dp_core.c| 37
drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
3 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 53dbccf..7a3a9cd 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -66,6 +66,10 @@ Optional properties for dp-controller:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug
detection
+ -video interfaces: Device node can contain video interface port
+ nodes according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
@@ -105,4 +109,12 @@ Board Specific portion:
vsync-len = 6;
};
};
+
+ ports {
+ port@0 {
+ dp_out: endpoint {
+ remote-endpoint = bridge_in;
+ };
+ };
+ };
};
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 27e3d27..46f1497 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
#include linux/interrupt.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_graph.h
#include linux/gpio.h
#include linux/component.h
#include linux/phy/phy.h
@@ -994,9 +995,19 @@ static struct drm_connector_helper_funcs
exynos_dp_connector_helper_funcs = {
};
/* returns the number of bridges attached */
-static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+static int exynos_drm_attach_lcd_bridge(struct exynos_dp_device *dp,
struct drm_encoder *encoder)
{
+ int ret;
+
+ encoder-bridge = dp-bridge;
+ dp-bridge-encoder = encoder;
+ ret = drm_bridge_attach(encoder-dev, dp-bridge);
+ if (ret) {
+ DRM_ERROR(Failed to attach bridge to drm\n);
+ return ret;
+ }
+
return 0;
}
@@ -1010,9 +1021,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;
@@ -1219,7 +1232,7 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
}
}
- if (!dp-panel) {
+ if (!dp-panel !dp-bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
return ret;
@@ -1303,7 +1316,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, *endpoint;
struct exynos_dp_device *dp;
int ret;
@@ -1329,6 +1342,18 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
+ endpoint = of_graph_get_next_endpoint(dev-of_node, NULL);
+ if (endpoint) {
+ bridge_node = of_graph_get_remote_port_parent(endpoint);
+ if (bridge_node) {
+ dp-bridge = of_drm_find_bridge(bridge_node);
+ of_node_put(bridge_node);
+ if (!dp-bridge)
+ return -EPROBE_DEFER;
+ } else
+ return -EPROBE_DEFER;
+ }
+
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 164f171..a4e7996 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -153,6 +153,7 @@ struct exynos_dp_device {
struct drm_connectorconnector;
struct
[PATCH V9 06/14] drm/bridge: ptn3460: support drm_panel
Add drm_panel calls to the driver to make the panel and
bridge work together in tandem.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 12 ++
drivers/gpu/drm/bridge/Kconfig |1 +
drivers/gpu/drm/bridge/ptn3460.c | 42
3 files changed, 55 insertions(+)
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
index 52b93b2..663fe6c 100644
--- a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -17,6 +17,11 @@ Required properties:
| 6 | 1600x900 | ChiMei M215HGE |
+---++--+
+ - video interfaces: Device node can contain video interface port
+ nodes for panel according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
Example:
lvds-bridge@20 {
compatible = nxp,ptn3460;
@@ -24,4 +29,11 @@ Example:
powerdown-gpio = gpy2 5 1 0 0;
reset-gpio = gpx1 5 1 0 0;
edid-emulation = 5;
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+ };
};
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 4254c2b..8b426e2 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,5 +3,6 @@ config DRM_PTN3460
depends on DRM
depends on OF I2C
select DRM_KMS_HELPER
+ select DRM_PANEL
---help---
ptn3460 eDP-LVDS bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 7adeb60..e6d5ae7 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -19,6 +19,9 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_graph.h
+
+#include drm/drm_panel.h
#include bridge/ptn3460.h
@@ -38,6 +41,7 @@ struct ptn3460_bridge {
struct i2c_client *client;
struct drm_bridge bridge;
struct edid *edid;
+ struct drm_panel *panel;
int gpio_pd_n;
int gpio_rst_n;
u32 edid_emulation;
@@ -137,6 +141,11 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
+ if (drm_panel_prepare(ptn_bridge-panel)) {
+ DRM_ERROR(failed to prepare panel\n);
+ return;
+ }
+
/*
* 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
@@ -153,6 +162,12 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
static void ptn3460_enable(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+
+ if (drm_panel_enable(ptn_bridge-panel)) {
+ DRM_ERROR(failed to enable panel\n);
+ return;
+ }
}
static void ptn3460_disable(struct drm_bridge *bridge)
@@ -164,6 +179,11 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge-enabled = false;
+ if (drm_panel_disable(ptn_bridge-panel)) {
+ DRM_ERROR(failed to disable panel\n);
+ return;
+ }
+
if (gpio_is_valid(ptn_bridge-gpio_rst_n))
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
@@ -173,6 +193,12 @@ static void ptn3460_disable(struct drm_bridge *bridge)
static void ptn3460_post_disable(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+
+ if (drm_panel_unprepare(ptn_bridge-panel)) {
+ DRM_ERROR(failed to unprepare panel\n);
+ return;
+ }
}
static int ptn3460_get_modes(struct drm_connector *connector)
@@ -267,6 +293,9 @@ int ptn3460_bridge_attach(struct drm_bridge *bridge)
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;
}
@@ -283,6 +312,7 @@ static int ptn3460_probe(struct i2c_client *client,
{
struct device *dev = client-dev;
struct ptn3460_bridge *ptn_bridge;
+ struct
[PATCH V9 00/14] drm/exynos: few patches to enhance bridge chip support
This series is based on v3.19-rc5 tag of Linux-next tree at: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Changes since V3: -- Remove hotplug based initialization of exynos_dp -- Make exynos_dp work directly with drm_panel, remove dependency on panel_binder -- Minor cleanups in panel_binder and panel_lvds driver Changes since V4: -- Use gpiod interface for panel-lvds and ps8622 drivers. -- Address comments from Javier. -- Fix compilation issues when PANEL_BINDER is selected as module. -- Split Documentation patches from driver patches. -- Rebase on top of the tree. Changes since V5: -- Modify bridge drivers to support driver model. -- Drop the concept of bridge chain(sincle there are no 2 real bridges) Hence drop bridge-panel_binder layer. -- Drop panel-lvds driver and accomadate the required changes in panel-simple driver. -- Use gpiod interface in ptn3460 driver. -- Address all comments by Thierry Reding for V5 series. -- Address comments from Sean Paul for exynos_dp_commit issue. Changes since V6: -- Panel patches were separated and they are merged already. -- Fix few issues with ptn3460, before modifying the bridge core. -- Modify drm_bridge as per Thierry's comments for V6 series. -- Add drm_bridge changes minimally without breaking existing code. -- Add new features for ptn3460, step-by-step. -- Address comments from Thierry and Andreas for ptn3460 and ps8622. -- Split documentation patches from driver patches. Changes since V7: -- Address comments from Tomi and Laurent: -- Use videoports and endpoints to represent the connection between encoder, bridge and the panel, instead of using phandles. -- Address comments from Daniel: -- Make the patch description more descriptive. -- remove device pointer from drm_bridge, and just use device_node instead. -- don't pass encoder pointer to bridge_attach. -- Address comments from Sean Paul: -- Remove bridge from mode_config, and pull out drm_bridge functions from drm_crtc.c to drm_bridge.c Changes since V8: -- Rebase on top of linux-next v3.19-rc5. -- Add Acked-by and Tested-by tags. Ajay Kumar (13): [PATCH V9 1/14] drm/bridge: ptn3460: Few trivial cleanups [PATCH V9 2/14] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init [PATCH V9 3/14] drm/bridge: make bridge registration independent of drm flow [PATCH V9 4/14] drm/bridge: ptn3460: Convert to i2c driver model [PATCH V9 5/14] drm/exynos: dp: support drm_bridge [PATCH V9 6/14] drm/bridge: ptn3460: support drm_panel [PATCH V9 7/14] drm/bridge: ptn3460: probe connector at the end of bridge attach [PATCH V9 8/14] drm/bridge: ptn3460: use gpiod interface [PATCH V9 9/14] Documentation: drm: bridge: move to video/bridge [PATCH V9 10/14] Documentation: devicetree: Add vendor prefix for parade [PATCH V9 11/14] Documentation: bridge: Add documentation for ps8622 DT properties [PATCH V9 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints [PATCH V9 14/14] ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints Vincent Palatin (1): [PATCH V9 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 - .../devicetree/bindings/vendor-prefixes.txt|1 + .../devicetree/bindings/video/bridge/ps8622.txt| 31 + .../devicetree/bindings/video/bridge/ptn3460.txt | 39 ++ .../devicetree/bindings/video/exynos_dp.txt| 12 + arch/arm/boot/dts/exynos5250-snow.dts | 30 +- arch/arm/boot/dts/exynos5420-peach-pit.dts | 31 +- drivers/gpu/drm/Makefile |2 +- drivers/gpu/drm/bridge/Kconfig | 12 + drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/ps8622.c| 684 drivers/gpu/drm/bridge/ptn3460.c | 310 + drivers/gpu/drm/drm_bridge.c | 91 +++ drivers/gpu/drm/drm_crtc.c | 70 -- drivers/gpu/drm/exynos/exynos_dp_core.c| 53 +- drivers/gpu/drm/exynos/exynos_dp_core.h|1 + drivers/gpu/drm/msm/hdmi/hdmi.c|4 +- drivers/gpu/drm/msm/hdmi/hdmi.h
[PATCH V9 14/14] ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints
Define videoports and use endpoints to describe the connection between
the encoder, bridge and the panel, instead of using phandles.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 31 ++--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index c47bb70..ec86d95 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -118,6 +118,12 @@
compatible = auo,b116xw03;
power-supply = tps65090_fet6;
backlight = backlight;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = bridge_out;
+ };
+ };
};
};
@@ -137,7 +143,14 @@
samsung,link-rate = 0x06;
samsung,lane-count = 2;
samsung,hpd-gpio = gpx2 6 0;
- bridge = ps8625;
+
+ ports {
+ port@0 {
+ dp_out: endpoint {
+ remote-endpoint = bridge_in;
+ };
+ };
+ };
};
fimd {
@@ -595,8 +608,22 @@
sleep-gpios = gpx3 5 GPIO_ACTIVE_HIGH;
reset-gpios = gpy7 7 GPIO_ACTIVE_HIGH;
lane-count = 2;
- panel = panel;
use-external-pwm;
+
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+
+ port@1 {
+ bridge_in: endpoint {
+ remote-endpoint = dp_out;
+ };
+ };
+ };
+
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V9 07/14] drm/bridge: ptn3460: probe connector at the end of bridge attach
Force bridge connector detection at the end of the bridge attach.
This is needed to detect the bridge connector early.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/bridge/ptn3460.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index e6d5ae7..9f800a1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -281,6 +281,7 @@ int ptn3460_bridge_attach(struct drm_bridge *bridge)
return -ENODEV;
}
+ ptn_bridge-connector.polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(bridge-dev, ptn_bridge-connector,
ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
if (ret) {
@@ -296,6 +297,8 @@ int ptn3460_bridge_attach(struct drm_bridge *bridge)
if (ptn_bridge-panel)
drm_panel_attach(ptn_bridge-panel, ptn_bridge-connector);
+ drm_helper_hpd_irq_event(ptn_bridge-connector.dev);
+
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V9 10/14] Documentation: devicetree: Add vendor prefix for parade
ps8622 eDP-LVDS converter bridge chip is from parade technologies Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Inki Dae inki@samsung.com Tested-by: Rahul Sharma rahul.sha...@samsung.com Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 4df1d78..eca48be 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -125,6 +125,7 @@ nxp NXP Semiconductors onnn ON Semiconductor Corp. opencores OpenCores.org panasonic Panasonic Corporation +parade Parade Technologies Inc. pericomPericom Technology Inc. phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V9 08/14] drm/bridge: ptn3460: use gpiod interface
Modify driver to support gpiod interface.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/bridge/ptn3460.c | 88 --
1 file changed, 36 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 9f800a1..826833e 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -42,8 +42,8 @@ struct ptn3460_bridge {
struct drm_bridge bridge;
struct edid *edid;
struct drm_panel *panel;
- int gpio_pd_n;
- int gpio_rst_n;
+ struct gpio_desc *gpio_pd_n;
+ struct gpio_desc *gpio_rst_n;
u32 edid_emulation;
bool enabled;
};
@@ -132,14 +132,11 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
if (ptn_bridge-enabled)
return;
- if (gpio_is_valid(ptn_bridge-gpio_pd_n))
- gpio_set_value(ptn_bridge-gpio_pd_n, 1);
+ gpiod_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);
- usleep_range(10, 20);
- gpio_set_value(ptn_bridge-gpio_rst_n, 1);
- }
+ gpiod_set_value(ptn_bridge-gpio_rst_n, 0);
+ usleep_range(10, 20);
+ gpiod_set_value(ptn_bridge-gpio_rst_n, 1);
if (drm_panel_prepare(ptn_bridge-panel)) {
DRM_ERROR(failed to prepare panel\n);
@@ -184,11 +181,8 @@ static void ptn3460_disable(struct drm_bridge *bridge)
return;
}
- 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);
+ 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)
@@ -335,39 +329,41 @@ static int ptn3460_probe(struct i2c_client *client,
}
ptn_bridge-client = client;
- ptn_bridge-gpio_pd_n = of_get_named_gpio(dev-of_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) {
- dev_err(dev, Request powerdown-gpio failed (%d)\n,
- ret);
- return ret;
- }
+
+ 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);
+ dev_err(dev, cannot get gpio_pd_n %d\n, ret);
+ return ret;
}
- ptn_bridge-gpio_rst_n = of_get_named_gpio(dev-of_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) {
- dev_err(dev, Request reset-gpio failed (%d)\n, ret);
- gpio_free(ptn_bridge-gpio_pd_n);
- return ret;
- }
+ 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;
+ }
+ /*
+* 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_rst_n\n);
+ return ret;
}
ret = of_property_read_u32(dev-of_node, edid-emulation,
ptn_bridge-edid_emulation);
if (ret) {
dev_err(dev, Can't read EDID emulation value\n);
- goto err;
+ return ret;
}
ptn_bridge-bridge.funcs = ptn3460_bridge_funcs;
@@ -375,19 +371,12 @@ static int ptn3460_probe(struct
[PATCH 03/14] drm/bridge: make bridge registration independent of drm flow
Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.
In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
for the corresponding bridge so that the bridge receives
drm_device pointer and continues with connector and other
drm initializations.
The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.
The bridge devices register themselves onto global list of bridges
when they get probed by calling drm_bridge_add.
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 also call drm_bridge_attach to pass
on the drm_device to the bridge object.
drm_bridge_attach inturn calls bridge-funcs-attach so that
bridge can continue with drm related initializations.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/bridge/ptn3460.c | 27 +-
drivers/gpu/drm/drm_bridge.c | 91
drivers/gpu/drm/drm_crtc.c | 67 ---
drivers/gpu/drm/msm/hdmi/hdmi.c|4 +-
drivers/gpu/drm/msm/hdmi/hdmi.h|1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |6 +--
drivers/gpu/drm/sti/sti_hda.c | 10 +---
drivers/gpu/drm/sti/sti_hdmi.c | 10 +---
include/drm/bridge/ptn3460.h |8 +++
include/drm/drm_crtc.h | 26 -
11 files changed, 133 insertions(+), 119 deletions(-)
create mode 100644 drivers/gpu/drm/drm_bridge.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e620807..c83ef2d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
- drm_modeset_lock.o drm_atomic.o
+ drm_modeset_lock.o drm_atomic.o drm_bridge.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index a2ddc8d..4a818c1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -176,24 +176,11 @@ static void ptn3460_post_disable(struct drm_bridge
*bridge)
{
}
-static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- 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 */
-}
-
static 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,
};
static int ptn3460_get_modes(struct drm_connector *connector)
@@ -314,7 +301,7 @@ int ptn3460_init(struct drm_device *dev, struct drm_encoder
*encoder,
}
ptn_bridge-bridge.funcs = ptn3460_bridge_funcs;
- ret = drm_bridge_init(dev, ptn_bridge-bridge);
+ ret = drm_bridge_attach(dev, ptn_bridge-bridge);
if (ret) {
DRM_ERROR(Failed to initialize bridge with drm\n);
goto err;
@@ -343,3 +330,15 @@ err:
return ret;
}
EXPORT_SYMBOL(ptn3460_init);
+
+void ptn3460_destroy(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+
+ 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
[PATCH V9 09/14] Documentation: drm: bridge: move to video/bridge
Move drm/bridge documentation to video/bridge.
Also, add proper documentation for gpios used by ptn3460.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 39
.../devicetree/bindings/video/bridge/ptn3460.txt | 39
2 files changed, 39 insertions(+), 39 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 Documentation/devicetree/bindings/video/bridge/ptn3460.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
deleted file mode 100644
index 663fe6c..000
--- a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
+++ /dev/null
@@ -1,39 +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 |
- +---++--+
-
- - video interfaces: Device node can contain video interface port
- nodes for panel according to [1].
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-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;
- ports {
- port@0 {
- bridge_out: endpoint {
- remote-endpoint = panel_in;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
new file mode 100644
index 000..361971b
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
@@ -0,0 +1,39 @@
+ptn3460 bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification for PD_N pin.
+ - reset-gpio: OF device-tree gpio specification for RST_N pin.
+ - 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 |
+ +---++--+
+
+ - video interfaces: Device node can contain video interface port
+ nodes for panel according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+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;
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V9 04/14] drm/bridge: ptn3460: Convert to i2c driver model
Use drm_bridge helpers to modify the driver to support
i2c driver model.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/bridge/Kconfig |2 +
drivers/gpu/drm/bridge/ptn3460.c| 124 +--
drivers/gpu/drm/exynos/exynos_dp_core.c | 22 --
3 files changed, 86 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..4254c2b 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -1,5 +1,7 @@
config DRM_PTN3460
tristate PTN3460 DP/LVDS bridge
depends on DRM
+ depends on OF I2C
select DRM_KMS_HELPER
---help---
+ ptn3460 eDP-LVDS bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 4a818c1..7adeb60 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -36,7 +36,6 @@
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;
@@ -176,13 +175,6 @@ static void ptn3460_post_disable(struct drm_bridge *bridge)
{
}
-static struct drm_bridge_funcs ptn3460_bridge_funcs = {
- .pre_enable = ptn3460_pre_enable,
- .enable = ptn3460_enable,
- .disable = ptn3460_disable,
- .post_disable = ptn3460_post_disable,
-};
-
static int ptn3460_get_modes(struct drm_connector *connector)
{
struct ptn3460_bridge *ptn_bridge;
@@ -227,7 +219,7 @@ static struct drm_encoder *ptn3460_best_encoder(struct
drm_connector *connector)
{
struct ptn3460_bridge *ptn_bridge = connector_to_ptn3460(connector);
- return ptn_bridge-encoder;
+ return ptn_bridge-bridge.encoder;
}
static struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
@@ -253,31 +245,66 @@ static struct drm_connector_funcs ptn3460_connector_funcs
= {
.destroy = ptn3460_connector_destroy,
};
-int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
- struct i2c_client *client, struct device_node *node)
+int ptn3460_bridge_attach(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
int ret;
+
+ if (!bridge-encoder) {
+ DRM_ERROR(Parent encoder object not found);
+ return -ENODEV;
+ }
+
+ ret = drm_connector_init(bridge-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);
+
+ return ret;
+}
+
+static struct drm_bridge_funcs ptn3460_bridge_funcs = {
+ .pre_enable = ptn3460_pre_enable,
+ .enable = ptn3460_enable,
+ .disable = ptn3460_disable,
+ .post_disable = ptn3460_post_disable,
+ .attach = ptn3460_bridge_attach,
+};
+
+static int ptn3460_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = client-dev;
struct ptn3460_bridge *ptn_bridge;
+ int ret;
- ptn_bridge = devm_kzalloc(dev-dev, sizeof(*ptn_bridge), GFP_KERNEL);
+ ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
if (!ptn_bridge) {
return -ENOMEM;
}
ptn_bridge-client = client;
- ptn_bridge-encoder = encoder;
- ptn_bridge-gpio_pd_n = of_get_named_gpio(node, powerdown-gpio, 0);
+ ptn_bridge-gpio_pd_n = of_get_named_gpio(dev-of_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) {
- dev_err(client-dev,
- Request powerdown-gpio failed (%d)\n, ret);
+ dev_err(dev, Request powerdown-gpio failed (%d)\n,
+ ret);
return ret;
}
}
- ptn_bridge-gpio_rst_n = of_get_named_gpio(node
[PATCH V9 02/14] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
Assign the pointer to bridge ops structure(drm_bridge_funcs) in
the bridge driver itself, instead of passing it to drm_bridge_init.
This will allow bridge driver developer to pack bridge private
information inside the bridge object and pass only the drm-relevant
information to drm_bridge_init.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/bridge/ptn3460.c |3 ++-
drivers/gpu/drm/drm_crtc.c |5 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 ++-
drivers/gpu/drm/sti/sti_hda.c |3 ++-
drivers/gpu/drm/sti/sti_hdmi.c |3 ++-
include/drm/drm_crtc.h |3 +--
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 4db38e1..a2ddc8d 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -313,7 +313,8 @@ int ptn3460_init(struct drm_device *dev, struct drm_encoder
*encoder,
goto err;
}
- ret = drm_bridge_init(dev, ptn_bridge-bridge, ptn3460_bridge_funcs);
+ ptn_bridge-bridge.funcs = ptn3460_bridge_funcs;
+ ret = drm_bridge_init(dev, ptn_bridge-bridge);
if (ret) {
DRM_ERROR(Failed to initialize bridge with drm\n);
goto err;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index caec5c3..4acd693 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1030,7 +1030,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.
@@ -1038,8 +1037,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;
@@ -1050,7 +1048,6 @@ int drm_bridge_init(struct drm_device *dev, struct
drm_bridge *bridge,
goto out;
bridge-dev = dev;
- bridge-funcs = funcs;
list_add_tail(bridge-head, dev-mode_config.bridge_list);
dev-mode_config.num_bridge++;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 6902ad6..52ed2b5 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -220,8 +220,9 @@ struct drm_bridge *hdmi_bridge_init(struct hdmi *hdmi)
hdmi_bridge-hdmi = 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/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 2ae9a9b..6cf145d 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -664,7 +664,8 @@ static int sti_hda_bind(struct device *dev, struct device
*master, void *data)
return -ENOMEM;
bridge-driver_private = hda;
- drm_bridge_init(drm_dev, bridge, sti_hda_bridge_funcs);
+ bridge-funcs = sti_hda_bridge_funcs;
+ drm_bridge_init(drm_dev, bridge);
encoder-bridge = bridge;
connector-encoder = encoder;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index d032e02..74e943e 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -635,7 +635,8 @@ static int sti_hdmi_bind(struct device *dev, struct device
*master, void *data)
goto err_adapt;
bridge-driver_private = hdmi;
- drm_bridge_init(drm_dev, bridge, sti_hdmi_bridge_funcs);
+ bridge-funcs = sti_hdmi_bridge_funcs;
+ drm_bridge_init(drm_dev, bridge);
encoder-bridge = bridge;
connector-encoder = encoder;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f444263..e43d9e5 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1209,8 +1209,7 @@ extern unsigned int drm_connector_index(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_init(struct drm_device *dev, struct drm_bridge
[PATCH V9 11/14] Documentation: bridge: Add documentation for ps8622 DT properties
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
.../devicetree/bindings/video/bridge/ps8622.txt| 31
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..c989c38
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,31 @@
+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 for PD_ pin.
+ - reset-gpios: OF device-tree gpio specification for RST_ pin.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
+ - video interfaces: Device node can contain video interface port
+ nodes for panel according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+ lvds-bridge@48 {
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpios = gpc3 6 1 0 0;
+ reset-gpios = gpc3 1 1 0 0;
+ lane-count = 1;
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V9 01/14] drm/bridge: ptn3460: Few trivial cleanups
This patch does the following changes:
-- Use usleep_range instead of udelay.
-- Remove driver_private member from ptn3460 structure.
-- Make all possible functions and structures static.
-- Use dev_err for non-DRM errors.
-- Arrange header files alphabetically.
-- s/edid/EDID in all error messages.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/bridge/ptn3460.c | 95 +++---
1 file changed, 48 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/
gpu/drm/bridge/ptn3460.c
index d466696..4db38e1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -13,19 +13,19 @@
* GNU General Public License for more details.
*/
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/i2c.h
#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 bridge/ptn3460.h
+
#include drm_crtc.h
#include drm_crtc_helper.h
-
-#include bridge/ptn3460.h
+#include drm_edid.h
+#include drmP.h
#define PTN3460_EDID_ADDR 0x0
#define PTN3460_EDID_EMULATION_ADDR0x84
@@ -37,7 +37,7 @@ struct ptn3460_bridge {
struct drm_connector connector;
struct i2c_client *client;
struct drm_encoder *encoder;
- struct drm_bridge *bridge;
+ struct drm_bridge bridge;
struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
@@ -45,6 +45,18 @@ struct ptn3460_bridge {
bool enabled;
};
+static inline struct ptn3460_bridge *
+ bridge_to_ptn3460(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct ptn3460_bridge, bridge);
+}
+
+static inline struct ptn3460_bridge *
+ connector_to_ptn3460(struct drm_connector *connector)
+{
+ return container_of(connector, struct ptn3460_bridge, connector);
+}
+
static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
u8 *buf, int len)
{
@@ -92,7 +104,7 @@ static int ptn3460_select_edid(struct ptn3460_bridge
*ptn_bridge)
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);
+ DRM_ERROR(Failed to transfer EDID to sram, ret=%d\n, ret);
return ret;
}
@@ -102,7 +114,7 @@ static int ptn3460_select_edid(struct ptn3460_bridge
*ptn_bridge)
ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_EMULATION_ADDR, val);
if (ret) {
- DRM_ERROR(Failed to write edid value, ret=%d\n, ret);
+ DRM_ERROR(Failed to write EDID value, ret=%d\n, ret);
return ret;
}
@@ -111,7 +123,7 @@ static int ptn3460_select_edid(struct ptn3460_bridge
*ptn_bridge)
static void ptn3460_pre_enable(struct drm_bridge *bridge)
{
- struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
int ret;
if (ptn_bridge-enabled)
@@ -122,7 +134,7 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
if (gpio_is_valid(ptn_bridge-gpio_rst_n)) {
gpio_set_value(ptn_bridge-gpio_rst_n, 0);
- udelay(10);
+ usleep_range(10, 20);
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
@@ -135,7 +147,7 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
ret = ptn3460_select_edid(ptn_bridge);
if (ret)
- DRM_ERROR(Select edid failed ret=%d\n, ret);
+ DRM_ERROR(Select EDID failed ret=%d\n, ret);
ptn_bridge-enabled = true;
}
@@ -146,7 +158,7 @@ static void ptn3460_enable(struct drm_bridge *bridge)
static void ptn3460_disable(struct drm_bridge *bridge)
{
- struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
if (!ptn_bridge-enabled)
return;
@@ -164,9 +176,9 @@ static void ptn3460_post_disable(struct drm_bridge *bridge)
{
}
-void ptn3460_bridge_destroy(struct drm_bridge *bridge)
+static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
{
- struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
drm_bridge_cleanup(bridge);
if (gpio_is_valid(ptn_bridge-gpio_pd_n))
@@ -176,7 +188,7 @@ void
[PATCH V9 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
From: Vincent Palatin vpala...@chromium.org
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/bridge/Kconfig |9 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ps8622.c | 684 +++
3 files changed, 694 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8b426e2..d06eda3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -6,3 +6,12 @@ config DRM_PTN3460
select DRM_PANEL
---help---
ptn3460 eDP-LVDS bridge chip driver.
+
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on OF I2C
+ select DRM_PANEL
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
+ ---help---
+ parade eDP-LVDS bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..105da3e 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..5474a39
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,684 @@
+/*
+ * 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/backlight.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_graph.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
+
+/* 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 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#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
+
+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 gpio_desc *gpio_slp;
+ struct gpio_desc *gpio_rst;
+
+ u32 max_lane_count;
+ u32 lane_count;
+
+ bool enabled;
+};
+
+static inline struct ps8622_bridge *
+ bridge_to_ps8622(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct ps8622_bridge, bridge);
+}
+
+static inline struct ps8622_bridge *
+ connector_to_ps8622(struct drm_connector *connector)
+{
+ return container_of(connector, struct ps8622_bridge, connector);
+}
+
+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 *ps8622)
+{
+ struct i2c_client *cl = ps8622-client
Re: [PATCH V8 03/14] drm/bridge: make bridge registration independent of drm flow
On Tue, Dec 2, 2014 at 11:31 AM, Ajay kumar ajayn...@gmail.com wrote:
On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.
In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
for the corresponding bridge so that the bridge receives
drm_device pointer and continues with connector and other
drm initializations.
The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.
The bridge devices register themselves onto global list of bridges
when they get probed by calling drm_bridge_add.
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 also call drm_bridge_attach to pass
on the drm_device to the bridge object.
drm_bridge_attach inturn calls bridge-funcs-attach so that
bridge can continue with drm related initializations.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/bridge/ptn3460.c | 27 +-
drivers/gpu/drm/drm_bridge.c | 91
drivers/gpu/drm/drm_crtc.c | 65 ---
drivers/gpu/drm/msm/hdmi/hdmi.c|7 +--
drivers/gpu/drm/msm/hdmi/hdmi.h|1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |7 ++-
drivers/gpu/drm/sti/sti_hda.c | 10 +---
drivers/gpu/drm/sti/sti_hdmi.c | 10 +---
include/drm/bridge/ptn3460.h |8 +++
include/drm/drm_crtc.h | 26 -
11 files changed, 136 insertions(+), 118 deletions(-)
create mode 100644 drivers/gpu/drm/drm_bridge.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9292a76..00f97a5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
- drm_modeset_lock.o
+ drm_modeset_lock.o drm_bridge.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
index a2ddc8d..4a818c1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -176,24 +176,11 @@ static void ptn3460_post_disable(struct drm_bridge
*bridge)
{
}
-static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- 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 */
-}
-
static 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,
};
static int ptn3460_get_modes(struct drm_connector *connector)
@@ -314,7 +301,7 @@ int ptn3460_init(struct drm_device *dev, struct
drm_encoder *encoder,
}
ptn_bridge-bridge.funcs = ptn3460_bridge_funcs;
- ret = drm_bridge_init(dev, ptn_bridge-bridge);
+ ret = drm_bridge_attach(dev, ptn_bridge-bridge);
if (ret) {
DRM_ERROR(Failed to initialize bridge with drm\n);
goto err;
@@ -343,3 +330,15 @@ err:
return ret;
}
EXPORT_SYMBOL(ptn3460_init);
+
+void ptn3460_destroy(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+
+ 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
Re: [PATCH V2] drm/exynos: Add DECON driver
Hi Pankaj,
On Mon, Dec 1, 2014 at 1:36 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
Hi Ajay,
On 28 November 2014 at 16:45, Ajay Kumar ajaykumar...@samsung.com 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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Address comments from Pankaj and do few cleanups.
Thanks, but still I can see this needs modification, please see my comments:
.../devicetree/bindings/video/exynos7-decon.txt| 67 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1037
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 346 +++
7 files changed, 1466 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
[snip]
+static int decon_mgr_initialize(struct exynos_drm_manager *mgr,
+ struct drm_device *drm_dev)
+{
+ struct decon_context *ctx = mgr_to_decon(mgr);
+ struct exynos_drm_private *priv = drm_dev-dev_private;
+ int ret;
+
+ mgr-drm_dev = drm_dev;
+ mgr-pipe = ctx-pipe = priv-pipe++;
+
Do we really need 'pipe' in exynos_drm_manager and decon_context both?
Will fix this.
+ /* attach this sub driver to iommu mapping if supported. */
+ if (is_drm_iommu_supported(mgr-drm_dev)) {
[snip]
+static void decon_win_mode_set(struct exynos_drm_manager *mgr,
+ struct exynos_drm_overlay *overlay)
+{
+ struct decon_context *ctx = mgr_to_decon(mgr);
+ struct decon_win_data *win_data;
+ int win, padding;
+
+ if (!overlay) {
+ DRM_ERROR(overlay is NULL\n);
+ return;
+ }
+
+ win = overlay-zpos;
+ if (win == DEFAULT_ZPOS)
+ win = ctx-default_win;
+
+ if (win 0 || win = WINDOWS_NR)
+ return;
+
+
+ win_data = ctx-win_data[win];
+
As I mentioned in V1, since these 5 lines are getting repeating better
we move it in one static function. It will help in reducing code
footprint.
I tried this, the code readability is gone. I think its better to
leave this as it is.
[snip]
+
+/**
+ * shadow_protect_win() - disable updating values from shadow registers at
vsync
+ *
+ * @win: window to protect registers for
+ * @protect: 1 to protect (disable updates)
+ */
+static void decon_shadow_protect_win(struct decon_context *ctx,
+ int win, bool
protect)
+{
+ u32 reg, bits, val;
+
+ reg = SHADOWCON;
How about using SHADOWCON directly instead of using local variable?
Ok.
+ bits = SHADOWCON_WINx_PROTECT(win);
+
+ val = readl(ctx-regs + reg);
+ if (protect)
+ val |= bits;
+ else
+ val = ~bits;
+ writel(val, ctx-regs + reg);
+}
+
+static void decon_win_commit(struct exynos_drm_manager *mgr, int zpos)
+{
+ struct decon_context *ctx = mgr_to_decon(mgr);
+ struct decon_win_data *win_data;
+ int win = zpos;
+ unsigned long val, alpha, blendeq;
+ unsigned int last_x;
+ unsigned int last_y;
+
+ if (ctx-suspended)
+ return;
+
+ if (win == DEFAULT_ZPOS)
+ win = ctx-default_win;
+
+ if (win 0 || win = WINDOWS_NR)
+ return;
+
+ win_data = ctx-win_data[win];
+
+ /* If suspended, enable this on resume */
+ if (ctx-suspended) {
+ win_data-resume = true;
+ return;
+ }
+
+ /*
[snip]
+static int decon_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct decon_context *ctx;
+ struct resource *res;
+ int ret = -EINVAL;
+
+ if (!dev-of_node)
+ return -ENODEV;
+
+ ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ ctx-manager.type = EXYNOS_DISPLAY_TYPE_LCD
[PATCH V3] drm/exynos: Add DECON driver
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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Address comments from Pankaj and do few cleanups.
Changes since V2:
-- Address more comments from Pankaj and cleanup.
.../devicetree/bindings/video/exynos7-decon.txt| 67 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1042
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 346 +++
7 files changed, 1471 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..14db519
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,67 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for FIMD, as described in document [1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9..d3434cb 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -32,9 +32,16 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS_DECON
+ bool Exynos DRM DECON
+ depends on DRM_EXYNOS
+ select FB_MODE_HELPERS
+ help
+ Choose this option if you want to use Exynos DECON for DRM.
+
config DRM_EXYNOS_DPI
bool EXYNOS DRM parallel output support
- depends on DRM_EXYNOS_FIMD
+ depends on (DRM_EXYNOS_FIMD
[PATCH 1/2] drm/exynos: fimd: Remove drm_dev and pipe members from fimd_context
ctx-drm_dev is unnecessary since it can be easily accessed
via ctx-manager-drm_dev. Even the pipe variable inside
fimd_context is redundant. Cleaning up the same.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e5810d1..157f4dd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -159,7 +159,6 @@ struct fimd_win_data {
struct fimd_context {
struct exynos_drm_manager manager;
struct device *dev;
- struct drm_device *drm_dev;
struct clk *bus_clk;
struct clk *lcd_clk;
void __iomem*regs;
@@ -174,7 +173,6 @@ struct fimd_context {
u32 i80ifcon;
booli80_if;
boolsuspended;
- int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
atomic_twin_updated;
@@ -298,17 +296,17 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
struct exynos_drm_private *priv;
priv = drm_dev-dev_private;
- mgr-drm_dev = ctx-drm_dev = drm_dev;
- mgr-pipe = ctx-pipe = priv-pipe++;
+ mgr-drm_dev = drm_dev;
+ mgr-pipe = priv-pipe++;
/* attach this sub driver to iommu mapping if supported. */
- if (is_drm_iommu_supported(ctx-drm_dev)) {
+ if (is_drm_iommu_supported(mgr-drm_dev)) {
/*
* If any channel is already active, iommu will throw
* a PAGE FAULT when enabled. So clear any channel if enabled.
*/
fimd_clear_channel(mgr);
- drm_iommu_attach_device(ctx-drm_dev, ctx-dev);
+ drm_iommu_attach_device(mgr-drm_dev, ctx-dev);
}
return 0;
@@ -319,8 +317,8 @@ static void fimd_mgr_remove(struct exynos_drm_manager *mgr)
struct fimd_context *ctx = mgr_to_fimd(mgr);
/* detach this sub driver from iommu mapping if supported. */
- if (is_drm_iommu_supported(ctx-drm_dev))
- drm_iommu_detach_device(ctx-drm_dev, ctx-dev);
+ if (is_drm_iommu_supported(mgr-drm_dev))
+ drm_iommu_detach_device(mgr-drm_dev, ctx-dev);
}
static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
@@ -1001,7 +999,7 @@ static void fimd_te_handler(struct exynos_drm_manager *mgr)
struct fimd_context *ctx = mgr_to_fimd(mgr);
/* Checks the crtc is detached already from encoder */
- if (ctx-pipe 0 || !ctx-drm_dev)
+ if (mgr-pipe 0 || !mgr-drm_dev)
return;
/*
@@ -1018,7 +1016,7 @@ static void fimd_te_handler(struct exynos_drm_manager
*mgr)
}
if (test_bit(0, ctx-irq_flags))
- drm_handle_vblank(ctx-drm_dev, ctx-pipe);
+ drm_handle_vblank(mgr-drm_dev, mgr-pipe);
}
static struct exynos_drm_manager_ops fimd_manager_ops = {
@@ -1047,17 +1045,19 @@ static irqreturn_t fimd_irq_handler(int irq, void
*dev_id)
writel(clear_bit, ctx-regs + VIDINTCON1);
/* check the crtc is detached already from encoder */
- if (ctx-pipe 0 || !ctx-drm_dev)
+ if (ctx-manager.pipe 0 || !ctx-manager.drm_dev)
goto out;
if (ctx-i80_if) {
- exynos_drm_crtc_finish_pageflip(ctx-drm_dev, ctx-pipe);
+ exynos_drm_crtc_finish_pageflip(ctx-manager.drm_dev,
+ ctx-manager.pipe);
/* Exits triggering mode */
atomic_set(ctx-triggering, 0);
} else {
- drm_handle_vblank(ctx-drm_dev, ctx-pipe);
- exynos_drm_crtc_finish_pageflip(ctx-drm_dev, ctx-pipe);
+ drm_handle_vblank(ctx-manager.drm_dev, ctx-manager.pipe);
+ exynos_drm_crtc_finish_pageflip(ctx-manager.drm_dev,
+ ctx-manager.pipe);
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(ctx-wait_vsync_event)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drm/exynos: fimd: check error status for drm_iommu_attach_device
check error status for drm_iommu_attach_device() and make sure
it propagates till the caller.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 157f4dd..a53d35b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -294,6 +294,8 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
{
struct fimd_context *ctx = mgr_to_fimd(mgr);
struct exynos_drm_private *priv;
+ int ret;
+
priv = drm_dev-dev_private;
mgr-drm_dev = drm_dev;
@@ -306,7 +308,12 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
* a PAGE FAULT when enabled. So clear any channel if enabled.
*/
fimd_clear_channel(mgr);
- drm_iommu_attach_device(mgr-drm_dev, ctx-dev);
+
+ ret = drm_iommu_attach_device(mgr-drm_dev, ctx-dev);
+ if (ret) {
+ DRM_ERROR(drm_iommu_attach failed.\n);
+ return ret;
+ }
}
return 0;
@@ -1074,8 +1081,14 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
{
struct fimd_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+ int ret;
+
+ ret = fimd_mgr_initialize(ctx-manager, drm_dev);
+ if (ret) {
+ DRM_ERROR(fimd_mgr_initialize failed.\n);
+ return ret;
+ }
- fimd_mgr_initialize(ctx-manager, drm_dev);
exynos_drm_crtc_create(ctx-manager);
if (ctx-display)
exynos_drm_create_enc_conn(drm_dev, ctx-display);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8 03/14] drm/bridge: make bridge registration independent of drm flow
On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.
In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
for the corresponding bridge so that the bridge receives
drm_device pointer and continues with connector and other
drm initializations.
The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.
The bridge devices register themselves onto global list of bridges
when they get probed by calling drm_bridge_add.
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 also call drm_bridge_attach to pass
on the drm_device to the bridge object.
drm_bridge_attach inturn calls bridge-funcs-attach so that
bridge can continue with drm related initializations.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/bridge/ptn3460.c | 27 +-
drivers/gpu/drm/drm_bridge.c | 91
drivers/gpu/drm/drm_crtc.c | 65 ---
drivers/gpu/drm/msm/hdmi/hdmi.c|7 +--
drivers/gpu/drm/msm/hdmi/hdmi.h|1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |7 ++-
drivers/gpu/drm/sti/sti_hda.c | 10 +---
drivers/gpu/drm/sti/sti_hdmi.c | 10 +---
include/drm/bridge/ptn3460.h |8 +++
include/drm/drm_crtc.h | 26 -
11 files changed, 136 insertions(+), 118 deletions(-)
create mode 100644 drivers/gpu/drm/drm_bridge.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9292a76..00f97a5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
- drm_modeset_lock.o
+ drm_modeset_lock.o drm_bridge.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
index a2ddc8d..4a818c1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -176,24 +176,11 @@ static void ptn3460_post_disable(struct drm_bridge
*bridge)
{
}
-static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- 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 */
-}
-
static 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,
};
static int ptn3460_get_modes(struct drm_connector *connector)
@@ -314,7 +301,7 @@ int ptn3460_init(struct drm_device *dev, struct
drm_encoder *encoder,
}
ptn_bridge-bridge.funcs = ptn3460_bridge_funcs;
- ret = drm_bridge_init(dev, ptn_bridge-bridge);
+ ret = drm_bridge_attach(dev, ptn_bridge-bridge);
if (ret) {
DRM_ERROR(Failed to initialize bridge with drm\n);
goto err;
@@ -343,3 +330,15 @@ err:
return ret;
}
EXPORT_SYMBOL(ptn3460_init);
+
+void ptn3460_destroy(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+
+ 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 */
+}
+EXPORT_SYMBOL(ptn3460_destroy);
diff
[PATCH 1/2] drm/exynos: fimd: Remove drm_dev pointer from fimd_context
ctx-drm_dev is unnecessary since it can be easily
accessed via ctx-manager-drm_dev, cleaning it up.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e5810d1..122c851 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -159,7 +159,6 @@ struct fimd_win_data {
struct fimd_context {
struct exynos_drm_manager manager;
struct device *dev;
- struct drm_device *drm_dev;
struct clk *bus_clk;
struct clk *lcd_clk;
void __iomem*regs;
@@ -298,17 +297,17 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
struct exynos_drm_private *priv;
priv = drm_dev-dev_private;
- mgr-drm_dev = ctx-drm_dev = drm_dev;
+ mgr-drm_dev = drm_dev;
mgr-pipe = ctx-pipe = priv-pipe++;
/* attach this sub driver to iommu mapping if supported. */
- if (is_drm_iommu_supported(ctx-drm_dev)) {
+ if (is_drm_iommu_supported(mgr-drm_dev)) {
/*
* If any channel is already active, iommu will throw
* a PAGE FAULT when enabled. So clear any channel if enabled.
*/
fimd_clear_channel(mgr);
- drm_iommu_attach_device(ctx-drm_dev, ctx-dev);
+ drm_iommu_attach_device(mgr-drm_dev, ctx-dev);
}
return 0;
@@ -319,8 +318,8 @@ static void fimd_mgr_remove(struct exynos_drm_manager *mgr)
struct fimd_context *ctx = mgr_to_fimd(mgr);
/* detach this sub driver from iommu mapping if supported. */
- if (is_drm_iommu_supported(ctx-drm_dev))
- drm_iommu_detach_device(ctx-drm_dev, ctx-dev);
+ if (is_drm_iommu_supported(mgr-drm_dev))
+ drm_iommu_detach_device(mgr-drm_dev, ctx-dev);
}
static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
@@ -1001,7 +1000,7 @@ static void fimd_te_handler(struct exynos_drm_manager
*mgr)
struct fimd_context *ctx = mgr_to_fimd(mgr);
/* Checks the crtc is detached already from encoder */
- if (ctx-pipe 0 || !ctx-drm_dev)
+ if (ctx-pipe 0 || !mgr-drm_dev)
return;
/*
@@ -1018,7 +1017,7 @@ static void fimd_te_handler(struct exynos_drm_manager
*mgr)
}
if (test_bit(0, ctx-irq_flags))
- drm_handle_vblank(ctx-drm_dev, ctx-pipe);
+ drm_handle_vblank(mgr-drm_dev, ctx-pipe);
}
static struct exynos_drm_manager_ops fimd_manager_ops = {
@@ -1047,17 +1046,19 @@ static irqreturn_t fimd_irq_handler(int irq, void
*dev_id)
writel(clear_bit, ctx-regs + VIDINTCON1);
/* check the crtc is detached already from encoder */
- if (ctx-pipe 0 || !ctx-drm_dev)
+ if (ctx-pipe 0 || !ctx-manager.drm_dev)
goto out;
if (ctx-i80_if) {
- exynos_drm_crtc_finish_pageflip(ctx-drm_dev, ctx-pipe);
+ exynos_drm_crtc_finish_pageflip(ctx-manager.drm_dev,
+ ctx-pipe);
/* Exits triggering mode */
atomic_set(ctx-triggering, 0);
} else {
- drm_handle_vblank(ctx-drm_dev, ctx-pipe);
- exynos_drm_crtc_finish_pageflip(ctx-drm_dev, ctx-pipe);
+ drm_handle_vblank(ctx-manager.drm_dev, ctx-pipe);
+ exynos_drm_crtc_finish_pageflip(ctx-manager.drm_dev,
+ ctx-pipe);
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(ctx-wait_vsync_event)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drm/exynos: fimd: check error status for drm_iommu_attach_device
check error status for drm_iommu_attach_device() and make sure
it propagates till the caller.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 122c851..528420c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -295,6 +295,8 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
{
struct fimd_context *ctx = mgr_to_fimd(mgr);
struct exynos_drm_private *priv;
+ int ret;
+
priv = drm_dev-dev_private;
mgr-drm_dev = drm_dev;
@@ -307,7 +309,12 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
* a PAGE FAULT when enabled. So clear any channel if enabled.
*/
fimd_clear_channel(mgr);
- drm_iommu_attach_device(mgr-drm_dev, ctx-dev);
+
+ ret = drm_iommu_attach_device(mgr-drm_dev, ctx-dev);
+ if (ret) {
+ DRM_ERROR(drm_iommu_attach failed.\n);
+ return ret;
+ }
}
return 0;
@@ -1075,8 +1082,14 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
{
struct fimd_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+ int ret;
+
+ ret = fimd_mgr_initialize(ctx-manager, drm_dev);
+ if (ret) {
+ DRM_ERROR(fimd_mgr_initialize failed.\n);
+ return ret;
+ }
- fimd_mgr_initialize(ctx-manager, drm_dev);
exynos_drm_crtc_create(ctx-manager);
if (ctx-display)
exynos_drm_create_enc_conn(drm_dev, ctx-display);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] drm/exynos: Add DECON driver
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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Address comments from Pankaj and do few cleanups.
.../devicetree/bindings/video/exynos7-decon.txt| 67 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1037
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 346 +++
7 files changed, 1466 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..14db519
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,67 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for FIMD, as described in document [1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9..d3434cb 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -32,9 +32,16 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS_DECON
+ bool Exynos DRM DECON
+ depends on DRM_EXYNOS
+ select FB_MODE_HELPERS
+ help
+ Choose this option if you want to use Exynos DECON for DRM.
+
config DRM_EXYNOS_DPI
bool EXYNOS DRM parallel output support
- depends on DRM_EXYNOS_FIMD
+ depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS_DECON)
select DRM_PANEL
default n
help
[PATCH] drm/exynos: Add DECON driver
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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos7-decon.txt| 67 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1029
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 346 +++
7 files changed, 1458 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..14db519
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,67 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for FIMD, as described in document [1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9..d3434cb 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -32,9 +32,16 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS_DECON
+ bool Exynos DRM DECON
+ depends on DRM_EXYNOS
+ select FB_MODE_HELPERS
+ help
+ Choose this option if you want to use Exynos DECON for DRM.
+
config DRM_EXYNOS_DPI
bool EXYNOS DRM parallel output support
- depends on DRM_EXYNOS_FIMD
+ depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS_DECON)
select DRM_PANEL
default n
help
@@ -42,7 +49,7 @@ config DRM_EXYNOS_DPI
config DRM_EXYNOS_DSI
bool
Re: [PATCH] drm/exynos: Add DECON driver
Hi Pankaj,
Thanks a lot for reviewing the patch. Find my comments below.
On Thu, Nov 27, 2014 at 9:55 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
Hi Ajay,
On 27 November 2014 at 19:41, Ajay Kumar ajaykumar...@samsung.com 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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos7-decon.txt| 67 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1029
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 346 +++
7 files changed, 1458 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..14db519
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,67 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt
specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for FIMD, as described in document [1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9..d3434cb 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -32,9 +32,16 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS_DECON
+ bool Exynos DRM DECON
+ depends on DRM_EXYNOS
+ select FB_MODE_HELPERS
+ help
+ Choose
Re: [RFC PATCH] drm/exynos: Add DECON driver
ping. On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar ajayn...@gmail.com wrote: Hi Inki, On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae inki@samsung.com wrote: Hi, Fortunately, I could get the user manual for Exynos7420. Below are my comments. Thanks, Inki Dae On 2014년 10월 23일 01:34, Ajay kumar wrote: On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae inki@samsung.com wrote: Thanks for contribution. It seems reasonable that you separate device drivers into FIMD and DECON because many registers of them have many different offsets and fields. However, there may be a good solution that we can combine common sets of these drivers later. Yes, this is the main reason behind sending this as RFC patch. I want to know what's the best way to do this. FIMD, 5433 DECON and Exynos7 DECON - all are different. Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). So, even I am not sure how the driver layouts should be! Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my understanding, Exynos7 doesn't mean one real SoC. We shall use Exynos7 as per the discussion. Below are my comments. Thanks, Inki Dae On 2014년 10월 10일 21:48, 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 DECON(Display and Enhancement Controller) is the new IP in exynos7 SOC for generating video signals using pixel data. DECON was used since Exynos5430. And is Exynos5433 different from Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? Yes, Exynos5433 DECON is very much different than Exynos7 DECON. Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. Again, we shall use Exynos7. I will see how manual can be arranged. DECON driver can be used to drive 2 different interfaces on Exynos7: DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) The existing FIMD driver code was used as a template to create DECON driver. Only DECON-INT is supported as of now, and DECON-EXT support will be added later. Signed-off-by: Akshu Agrawal aksh...@samsung.com Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/video/exynos-decon.txt | 68 ++ drivers/gpu/drm/exynos/Kconfig | 11 +- drivers/gpu/drm/exynos/Makefile|1 + drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + include/video/samsung_decon.h | 346 +++ 7 files changed, 1537 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c create mode 100644 include/video/samsung_decon.h diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt b/Documentation/devicetree/bindings/video/exynos-decon.txt new file mode 100644 index 000..e865650 --- /dev/null +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt @@ -0,0 +1,68 @@ +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) + +DECON (Display and Enhancement Controller) is the Display Controller for the +Exynos7 series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be samsung,exynos7-decon; If exynos5433 was just renamed to exynos7 then, it should be one of the following: (a) samsung,exynos5430-decon for Display and enhancement controller IP for Exynos5430 (b) samsung,exynos7 for Display and enhancement controller IP for Exynos7 Or, (a) samsung,exynos5430-decon for Display and enhancement controller IP for Exynos5430 (b) samsung,exynos5433-decon for Display and enhancement controller IP for Exynos5433 (c) samsung,exynos7 for Display and enhancement controller IP for Exynos7 Eventually, we will end up here. + +- reg: physical base address and length of the DECON registers set. + +- interrupt-parent: should be the phandle of the decon controller's + parent interrupt controller. + +- interrupts: should contain a list of all DECON IP block interrupts in the + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier + format depends on the interrupt controller used. + +- interrupt-names: should contain the interrupt names: fifo, vsync, + lcd_sys, in the same order as they were listed in the interrupts +property. + +- pinctrl-0: pin control group to be used for this controller. + +- pinctrl-names: must contain a default entry. + +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. + +- clock-names: list of clock names sorted
Re: [RFC PATCH] drm/exynos: Add DECON driver
Hi Inki, On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae inki@samsung.com wrote: On 2014년 11월 25일 21:17, Ajay kumar wrote: ping. You'd need to clean up clocks and fix up binding file. And then let's have review in more details. I wish that other people also give you their reviews. Nice to hear. Earlier, you mentioned that its good if FIMD driver itself is modified to support Exynos7 DECON. So, what is your take now? 1) Should I add it in FIMD driver itself? We may need to add lot of driver_data for that, since offsets are much different. 2) Or, create two seperate register level files for Exynos5 and Exynos7? 3) Or the current way - Entirely different driver Anyway, below is my answer. Thanks, Inki Dae On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar ajayn...@gmail.com wrote: Hi Inki, On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae inki@samsung.com wrote: Hi, Fortunately, I could get the user manual for Exynos7420. Below are my comments. Thanks, Inki Dae On 2014년 10월 23일 01:34, Ajay kumar wrote: On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae inki@samsung.com wrote: Thanks for contribution. It seems reasonable that you separate device drivers into FIMD and DECON because many registers of them have many different offsets and fields. However, there may be a good solution that we can combine common sets of these drivers later. Yes, this is the main reason behind sending this as RFC patch. I want to know what's the best way to do this. FIMD, 5433 DECON and Exynos7 DECON - all are different. Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). So, even I am not sure how the driver layouts should be! Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my understanding, Exynos7 doesn't mean one real SoC. We shall use Exynos7 as per the discussion. Just for the time being. Ok. Below are my comments. Thanks, Inki Dae On 2014년 10월 10일 21:48, 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 DECON(Display and Enhancement Controller) is the new IP in exynos7 SOC for generating video signals using pixel data. DECON was used since Exynos5430. And is Exynos5433 different from Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? Yes, Exynos5433 DECON is very much different than Exynos7 DECON. Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. Again, we shall use Exynos7. I will see how manual can be arranged. DECON driver can be used to drive 2 different interfaces on Exynos7: DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) The existing FIMD driver code was used as a template to create DECON driver. Only DECON-INT is supported as of now, and DECON-EXT support will be added later. Signed-off-by: Akshu Agrawal aksh...@samsung.com Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/video/exynos-decon.txt | 68 ++ drivers/gpu/drm/exynos/Kconfig | 11 +- drivers/gpu/drm/exynos/Makefile|1 + drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + include/video/samsung_decon.h | 346 +++ 7 files changed, 1537 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c create mode 100644 include/video/samsung_decon.h diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt b/Documentation/devicetree/bindings/video/exynos-decon.txt new file mode 100644 index 000..e865650 --- /dev/null +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt @@ -0,0 +1,68 @@ +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) + +DECON (Display and Enhancement Controller) is the Display Controller for the +Exynos7 series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be samsung,exynos7-decon; If exynos5433 was just renamed to exynos7 then, it should be one of the following: (a) samsung,exynos5430-decon for Display and enhancement controller IP for Exynos5430 (b) samsung,exynos7 for Display and enhancement controller IP for Exynos7 Or, (a) samsung,exynos5430-decon for Display and enhancement controller IP for Exynos5430 (b) samsung,exynos5433-decon for Display and enhancement controller IP for Exynos5433 (c) samsung,exynos7 for Display and enhancement controller IP for Exynos7 Eventually, we will end up here. + +- reg: physical base address and length of the DECON registers set. + +- interrupt-parent: should
Re: [RFC PATCH] drm/exynos: Add DECON driver
On Tue, Nov 25, 2014 at 6:59 PM, Inki Dae inki@samsung.com wrote: On 2014년 11월 25일 22:08, Ajay kumar wrote: Hi Inki, On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae inki@samsung.com wrote: On 2014년 11월 25일 21:17, Ajay kumar wrote: ping. You'd need to clean up clocks and fix up binding file. And then let's have review in more details. I wish that other people also give you their reviews. Nice to hear. Earlier, you mentioned that its good if FIMD driver itself is modified to support Exynos7 DECON. So, what is your take now? 1) Should I add it in FIMD driver itself? We may need to add lot of driver_data for that, since offsets are much different. 2) Or, create two seperate register level files for Exynos5 and Exynos7? 3) Or the current way - Entirely different driver This one, 3), for now because they, Exynos4, Exynos543x and Exynos7, are much different each other. So for next version of your patch, you'd need to change the driver name to exynos7-decon or what you want so that each driver can be entirely separated in SoC name somehow. i.e., - exynos_drm_fimd covers Exynos64xx, Exynos3250, all Exynos4 series and Exynos5250 ~ 5422 SoC. - exynos5-decon covers Exynos5430 and Exynos5433 SoC. Use exynos543x-decon here. - exynos7-decon covers Exynos7 and maybe later SoC. Ok. I will use exynos7-decon. By the way, On which branch of exynos-drm tree should I create this patch? Ajay After that, let's consider how we can integrate these drivers later. Thanks, Inki Dae Anyway, below is my answer. Thanks, Inki Dae On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar ajayn...@gmail.com wrote: Hi Inki, On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae inki@samsung.com wrote: Hi, Fortunately, I could get the user manual for Exynos7420. Below are my comments. Thanks, Inki Dae On 2014년 10월 23일 01:34, Ajay kumar wrote: On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae inki@samsung.com wrote: Thanks for contribution. It seems reasonable that you separate device drivers into FIMD and DECON because many registers of them have many different offsets and fields. However, there may be a good solution that we can combine common sets of these drivers later. Yes, this is the main reason behind sending this as RFC patch. I want to know what's the best way to do this. FIMD, 5433 DECON and Exynos7 DECON - all are different. Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). So, even I am not sure how the driver layouts should be! Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my understanding, Exynos7 doesn't mean one real SoC. We shall use Exynos7 as per the discussion. Just for the time being. Ok. Below are my comments. Thanks, Inki Dae On 2014년 10월 10일 21:48, 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 DECON(Display and Enhancement Controller) is the new IP in exynos7 SOC for generating video signals using pixel data. DECON was used since Exynos5430. And is Exynos5433 different from Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? Yes, Exynos5433 DECON is very much different than Exynos7 DECON. Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. Again, we shall use Exynos7. I will see how manual can be arranged. DECON driver can be used to drive 2 different interfaces on Exynos7: DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) The existing FIMD driver code was used as a template to create DECON driver. Only DECON-INT is supported as of now, and DECON-EXT support will be added later. Signed-off-by: Akshu Agrawal aksh...@samsung.com Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/video/exynos-decon.txt | 68 ++ drivers/gpu/drm/exynos/Kconfig | 11 +- drivers/gpu/drm/exynos/Makefile|1 + drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + include/video/samsung_decon.h | 346 +++ 7 files changed, 1537 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c create mode 100644 include/video/samsung_decon.h diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt b/Documentation/devicetree/bindings/video/exynos-decon.txt new file mode 100644 index 000..e865650 --- /dev/null +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt @@ -0,0 +1,68 @@ +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) + +DECON (Display and Enhancement Controller) is the Display Controller for the +Exynos7 series of SoCs which transfers
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Andreas, On Mon, Nov 24, 2014 at 8:35 PM, Andreas Färber afaer...@suse.de wrote: Hi, Am 24.11.2014 um 11:05 schrieb Javier Martinez Canillas: On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote: On 11/21/2014 06:32 PM, Ajay kumar wrote: I have rebased my bridge series on top of linux-next. This is my git log: 4b38a6f Revert Revert ARM: exynos_defconfig: Enable options for display panel support 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints aee649c ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge 581257f Documentation: bridge: Add documentation for ps8622 DT properties 178e8b9 Documentation: devicetree: Add vendor prefix for parade 0ceea75 Documentation: drm: bridge: move to video/bridge f143e2e drm/bridge: ptn3460: use gpiod interface 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach 32ac563 drm/bridge: ptn3460: support drm_panel 91c6c30 drm/exynos: dp: support drm_bridge 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model 602f343 drm/bridge: make bridge registration independent of drm flow 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 28655d1 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I have attached the rebased patches as well. I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*. Display is totally fine with exynos_defconfig (booting is fine even with CONFIG_SND_SOC_SNOW=y) Thanks for forward porting your patches to linux-next. Unfortunately I won't have time to test them until Monday but I wonder why you didn't have the boot issues that we have with next-20141121. I tested your ToT patches on top of next-20141121, this is my git log: 93fe3d7 Revert Revert ARM: exynos_defconfig: Enable options for display panel support 552f74e ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints dbbc293 ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints d8687f8 drm/bridge: Add i2c based driver for ps8622/ps8625 bridge f29a649 Documentation: bridge: Add documentation for ps8622 DT properties 6ade887 Documentation: devicetree: Add vendor prefix for parade d81c42d Documentation: drm: bridge: move to video/bridge 50b9828 drm/bridge: ptn3460: use gpiod interface 1274c56 drm/bridge: ptn3460: probe connector at the end of bridge attach f3cf063 drm/bridge: ptn3460: support drm_panel cab682b drm/exynos: dp: support drm_bridge 6e78916 drm/bridge: ptn3460: Convert to i2c driver model 93f4b5f drm/bridge: make bridge registration independent of drm flow 81a038f drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init eb6996e drm/bridge: ptn3460: Few trivial cleanups c41fa5d arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 51b2c75 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I found that the commit ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) had to be reverted in order to boot linux-next. Display works but I needed to revert the mentioned commit, otherwise the boot hangs as reported before. I'm using exynos_defconfig and this kernel command line: console=ttySAC3,115200N8 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw I tested Spring with next-20141124, and finally got it to work! :) That's great to hear! Thanks a lot, Ajay and Javier! To be on the safe side, I reverted the patch pointed out by Javier and was still using clk_ignore_unused. Ajay, note that your rebased Snow patch has the last hunk indented one level too deep. Ahh, right. I just saw that. I am not sure if these patches go in just like this, or I need to rebase on top of kukjin's for-next or some other branch/tree! Will take care of this, then. I'll post a cleaned-up bridge patch for Spring later. Ok, AFAIK, peach_pit DT properties can be reused. Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi, I have rebased my bridge series on top of linux-next. This is my git log: 4b38a6f Revert Revert ARM: exynos_defconfig: Enable options for display panel support 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints aee649c ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge 581257f Documentation: bridge: Add documentation for ps8622 DT properties 178e8b9 Documentation: devicetree: Add vendor prefix for parade 0ceea75 Documentation: drm: bridge: move to video/bridge f143e2e drm/bridge: ptn3460: use gpiod interface 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach 32ac563 drm/bridge: ptn3460: support drm_panel 91c6c30 drm/exynos: dp: support drm_bridge 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model 602f343 drm/bridge: make bridge registration independent of drm flow 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 28655d1 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I have attached the rebased patches as well. I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*. Display is totally fine with exynos_defconfig (booting is fine even with CONFIG_SND_SOC_SNOW=y) Regards, Ajay Kumar On Fri, Nov 21, 2014 at 5:03 PM, Andreas Färber afaer...@suse.de wrote: Am 21.11.2014 um 00:49 schrieb Paolo Pisati: vanilla kgene/for-next as of today: 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 ... plus 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel support vanilla exynos_defconfig with SND_SOC_SNOW disabled. I should probably try linux-next at this point, but i wonder if people who reported kgene/for-next working were testing with a vanilla exynos_defconfig on a peach pi. On Spring, I am able to boot my kgene/for-next based queue with just: mfd: syscon: Decouple syscon interface from platform devices arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy with DRM_EXYNOS*=y (except IOMMU) and SND_SOC_SNOW=m enabled in the config, while using simplefb rather than the Exynos DRM and thus clk_ignore_unused. Regarding SND_SOC_SNOW: Note that I recently submitted a patch to enable module-loading, which is missing in kgene/for-next and -rc5 but is in linux-next.git - it might uncover problems that previously went unnoticed: https://patchwork.kernel.org/patch/5235951/ exynos_defconfig has SND_SOC_SNOW=y, whereas multi_v7_defconfig doesn't have it. Regards, Andreas -- SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Tot.tar.bz2 Description: BZip2 compressed data
Re: [PATCH 1/3] drm/exynos: free DP if probe fails to find a panel or bridge
Hi Gustavo,
On Fri, Nov 21, 2014 at 5:24 AM, Gustavo Padovan gust...@padovan.org wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
DP was leaked everytime function returns EPROBE_DEFER, free it before
returning.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 85762cf..6fd4a46 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1336,8 +1336,10 @@ static int exynos_dp_probe(struct platform_device
*pdev)
if (panel_node) {
dp-panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
- if (!dp-panel)
- return -EPROBE_DEFER;
+ if (!dp-panel) {
+ ret = -EPROBE_DEFER;
+ goto free_dp;
+ }
}
endpoint = of_graph_get_next_endpoint(dev-of_node, NULL);
@@ -1346,10 +1348,14 @@ static int exynos_dp_probe(struct platform_device
*pdev)
if (bridge_node) {
dp-bridge = of_drm_find_bridge(bridge_node);
of_node_put(bridge_node);
- if (!dp-bridge)
- return -EPROBE_DEFER;
- } else
- return -EPROBE_DEFER;
+ if (!dp-bridge) {
+ ret = -EPROBE_DEFER;
+ goto free_dp;
+ }
+ } else {
+ ret = -EPROBE_DEFER;
+ goto free_dp;
+ }
}
exynos_dp_display.ctx = dp;
@@ -1359,6 +1365,9 @@ static int exynos_dp_probe(struct platform_device *pdev)
exynos_drm_component_del(pdev-dev,
EXYNOS_DEVICE_TYPE_CONNECTOR);
+free_dp:
+ devm_kfree(dev, dp);
I guess the driver core takes care of freeing the devm memory when the
probe fails?
Will it not happen during PROBE_DEFER?
Inki/Jingoo - Is this change really necessary?
Ajay
return ret;
}
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
Hi Javier, In the cover letter, I have mentioned that it is tested on Linus tree: This series is based on master branch of Linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Kindly test the patches with that. Ajay On Wed, Nov 19, 2014 at 3:05 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Ajay, On 11/18/2014 07:20 AM, Ajay kumar wrote: On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar ajaykumar...@samsung.com wrote: This series is based on master branch of Linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git I applied your series on top of 3.18-rc5 + linux-next's commit: 0ef76ae (ARM: exynos_defconfig: Enable options for display panel support). I think you should had mentioned what other patches are needed as a dependency since I spent quite a bit of time figuring out why the ps8622 bridge driver probe was always deferred due of_drm_find_panel() failing and then I noticed that a patch from linux-next was needed: e35e305 (drm/panel: simple: Add AUO B116XW03 panel support) With that commit the ps8622 drm bridge driver probe succeed but I still don't have display working on an Exynos5240 Peach Pit, the kernel log shows: platform 145b.dp-controller: Driver exynos-dp requests probe deferral exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops) exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops exynos_dp_ops): -517 exynos-drm exynos-drm: master bind failed: -517 platform 145b.dp-controller: Driver exynos-dp requests probe deferral Any idea what else I could be missing here? Your patches don't apply cleanly in linux-next btw, although the are many issues with the Exynos DRM currently in linux-next anyways so probably using 3.18-rc as a base makes more sense for now until all those things get fixed but you should rebase so they can be picked. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar ajaykumar...@samsung.com wrote: This series is based on master branch of Linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Changes since V3: -- Remove hotplug based initialization of exynos_dp -- Make exynos_dp work directly with drm_panel, remove dependency on panel_binder -- Minor cleanups in panel_binder and panel_lvds driver Changes since V4: -- Use gpiod interface for panel-lvds and ps8622 drivers. -- Address comments from Javier. -- Fix compilation issues when PANEL_BINDER is selected as module. -- Split Documentation patches from driver patches. -- Rebase on top of the tree. Changes since V5: -- Modify bridge drivers to support driver model. -- Drop the concept of bridge chain(sincle there are no 2 real bridges) Hence drop bridge-panel_binder layer. -- Drop panel-lvds driver and accomodate the required changes in panel-simple driver. -- Use gpiod interface in ptn3460 driver. -- Address all comments by Thierry Reding for V5 series. -- Address comments from Sean Paul for exynos_dp_commit issue. Changes since V6: -- Panel patches were seperated and they are merged already. -- Fix few issues with ptn3460, before modifying the bridge core. -- Modify drm_bridge as per Thierry's comments for V6 series. -- Add drm_bridge changes minimally without breaking existing code. -- Add new features for ptn3460, step-by-step. -- Address comments from Thierry and Andreas for ptn3460 and ps8622. -- Split documentation patches from driver patches. Changes since V7: -- Address comments from Tomi and Laurent: -- Use videoports and endpoints to represent the connection between encoder, bridge and the panel, instead of using phandles. -- Address comments from Daniel: -- Make the patch description more descriptive. -- remove device pointer from drm_bridge, and just use device_node instead. -- don't pass encoder pointer to bridge_attach. -- Address comments from Sean Paul: -- Remove bridge from mode_config, and pull out drm_bridge functions from drm_crtc.c to drm_bridge.c Note: This patchset creates the following Kconfig ambiguity. Any pointers to fix the same are welcome. drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_PTN3460 drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_PTN3460 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB Ajay Kumar (13): [PATCH V8 1/14] drm/bridge: ptn3460: Few trivial cleanups [PATCH V8 2/14] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init [PATCH V8 3/14] drm/bridge: make bridge registration independent of drm flow [PATCH V8 4/14] drm/bridge: ptn3460: Convert to i2c driver model [PATCH V8 5/14] drm/exynos: dp: support drm_bridge [PATCH V8 6/14] drm/bridge: ptn3460: support drm_panel [PATCH V8 7/14] drm/bridge: ptn3460: probe connector at the end of bridge attach [PATCH V8 8/14] drm/bridge: ptn3460: use gpiod interface [PATCH V8 9/14] Documentation: drm: bridge: move to video/bridge [PATCH V8 10/14] Documentation: devicetree: Add vendor prefix for parade [PATCH V8 11/14] Documentation: bridge: Add documentation for ps8622 DT properties [PATCH V8 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints [PATCH V8 14/14] ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints Vincent Palatin (1): [PATCH V8 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 - .../devicetree/bindings/vendor-prefixes.txt|1 + .../devicetree/bindings/video/bridge/ps8622.txt| 31 + .../devicetree/bindings/video/bridge/ptn3460.txt | 39 ++ .../devicetree/bindings/video
[PATCH V8 01/14] drm/bridge: ptn3460: Few trivial cleanups
This patch does the following changes:
-- Use usleep_range instead of udelay.
-- Remove driver_private member from ptn3460 structure.
-- Make all possible functions and structures static.
-- Use dev_err for non-DRM errors.
-- Arrange header files alphabetically.
-- s/edid/EDID in all error messages.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/ptn3460.c | 95 +++---
1 file changed, 48 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index d466696..4db38e1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -13,19 +13,19 @@
* GNU General Public License for more details.
*/
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/i2c.h
#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 bridge/ptn3460.h
+
#include drm_crtc.h
#include drm_crtc_helper.h
-
-#include bridge/ptn3460.h
+#include drm_edid.h
+#include drmP.h
#define PTN3460_EDID_ADDR 0x0
#define PTN3460_EDID_EMULATION_ADDR0x84
@@ -37,7 +37,7 @@ struct ptn3460_bridge {
struct drm_connector connector;
struct i2c_client *client;
struct drm_encoder *encoder;
- struct drm_bridge *bridge;
+ struct drm_bridge bridge;
struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
@@ -45,6 +45,18 @@ struct ptn3460_bridge {
bool enabled;
};
+static inline struct ptn3460_bridge *
+ bridge_to_ptn3460(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct ptn3460_bridge, bridge);
+}
+
+static inline struct ptn3460_bridge *
+ connector_to_ptn3460(struct drm_connector *connector)
+{
+ return container_of(connector, struct ptn3460_bridge, connector);
+}
+
static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
u8 *buf, int len)
{
@@ -92,7 +104,7 @@ static int ptn3460_select_edid(struct ptn3460_bridge
*ptn_bridge)
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);
+ DRM_ERROR(Failed to transfer EDID to sram, ret=%d\n, ret);
return ret;
}
@@ -102,7 +114,7 @@ static int ptn3460_select_edid(struct ptn3460_bridge
*ptn_bridge)
ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_EMULATION_ADDR, val);
if (ret) {
- DRM_ERROR(Failed to write edid value, ret=%d\n, ret);
+ DRM_ERROR(Failed to write EDID value, ret=%d\n, ret);
return ret;
}
@@ -111,7 +123,7 @@ static int ptn3460_select_edid(struct ptn3460_bridge
*ptn_bridge)
static void ptn3460_pre_enable(struct drm_bridge *bridge)
{
- struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
int ret;
if (ptn_bridge-enabled)
@@ -122,7 +134,7 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
if (gpio_is_valid(ptn_bridge-gpio_rst_n)) {
gpio_set_value(ptn_bridge-gpio_rst_n, 0);
- udelay(10);
+ usleep_range(10, 20);
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
@@ -135,7 +147,7 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
ret = ptn3460_select_edid(ptn_bridge);
if (ret)
- DRM_ERROR(Select edid failed ret=%d\n, ret);
+ DRM_ERROR(Select EDID failed ret=%d\n, ret);
ptn_bridge-enabled = true;
}
@@ -146,7 +158,7 @@ static void ptn3460_enable(struct drm_bridge *bridge)
static void ptn3460_disable(struct drm_bridge *bridge)
{
- struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
if (!ptn_bridge-enabled)
return;
@@ -164,9 +176,9 @@ static void ptn3460_post_disable(struct drm_bridge *bridge)
{
}
-void ptn3460_bridge_destroy(struct drm_bridge *bridge)
+static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
{
- struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
drm_bridge_cleanup(bridge);
if (gpio_is_valid(ptn_bridge-gpio_pd_n))
@@ -176,7 +188,7 @@ void ptn3460_bridge_destroy(struct drm_bridge *bridge)
/* Nothing else to free, we've got devm allocated memory */
}
-struct drm_bridge_funcs ptn3460_bridge_funcs = {
+static struct drm_bridge_funcs ptn3460_bridge_funcs = {
.pre_enable = ptn3460_pre_enable,
.enable
[PATCH V8 04/14] drm/bridge: ptn3460: Convert to i2c driver model
Use drm_bridge helpers to modify the driver to support
i2c driver model.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/Kconfig |2 +
drivers/gpu/drm/bridge/ptn3460.c| 124 +--
drivers/gpu/drm/exynos/exynos_dp_core.c | 22 --
3 files changed, 86 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..4254c2b 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -1,5 +1,7 @@
config DRM_PTN3460
tristate PTN3460 DP/LVDS bridge
depends on DRM
+ depends on OF I2C
select DRM_KMS_HELPER
---help---
+ ptn3460 eDP-LVDS bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 4a818c1..7adeb60 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -36,7 +36,6 @@
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;
@@ -176,13 +175,6 @@ static void ptn3460_post_disable(struct drm_bridge *bridge)
{
}
-static struct drm_bridge_funcs ptn3460_bridge_funcs = {
- .pre_enable = ptn3460_pre_enable,
- .enable = ptn3460_enable,
- .disable = ptn3460_disable,
- .post_disable = ptn3460_post_disable,
-};
-
static int ptn3460_get_modes(struct drm_connector *connector)
{
struct ptn3460_bridge *ptn_bridge;
@@ -227,7 +219,7 @@ static struct drm_encoder *ptn3460_best_encoder(struct
drm_connector *connector)
{
struct ptn3460_bridge *ptn_bridge = connector_to_ptn3460(connector);
- return ptn_bridge-encoder;
+ return ptn_bridge-bridge.encoder;
}
static struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
@@ -253,31 +245,66 @@ static struct drm_connector_funcs ptn3460_connector_funcs
= {
.destroy = ptn3460_connector_destroy,
};
-int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
- struct i2c_client *client, struct device_node *node)
+int ptn3460_bridge_attach(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
int ret;
+
+ if (!bridge-encoder) {
+ DRM_ERROR(Parent encoder object not found);
+ return -ENODEV;
+ }
+
+ ret = drm_connector_init(bridge-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);
+
+ return ret;
+}
+
+static struct drm_bridge_funcs ptn3460_bridge_funcs = {
+ .pre_enable = ptn3460_pre_enable,
+ .enable = ptn3460_enable,
+ .disable = ptn3460_disable,
+ .post_disable = ptn3460_post_disable,
+ .attach = ptn3460_bridge_attach,
+};
+
+static int ptn3460_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = client-dev;
struct ptn3460_bridge *ptn_bridge;
+ int ret;
- ptn_bridge = devm_kzalloc(dev-dev, sizeof(*ptn_bridge), GFP_KERNEL);
+ ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
if (!ptn_bridge) {
return -ENOMEM;
}
ptn_bridge-client = client;
- ptn_bridge-encoder = encoder;
- ptn_bridge-gpio_pd_n = of_get_named_gpio(node, powerdown-gpio, 0);
+ ptn_bridge-gpio_pd_n = of_get_named_gpio(dev-of_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) {
- dev_err(client-dev,
- Request powerdown-gpio failed (%d)\n, ret);
+ dev_err(dev, Request powerdown-gpio failed (%d)\n,
+ ret);
return ret;
}
}
- ptn_bridge-gpio_rst_n = of_get_named_gpio(node, reset-gpio, 0);
+ ptn_bridge-gpio_rst_n = of_get_named_gpio(dev-of_node,
+ reset-gpio, 0);
if (gpio_is_valid(ptn_bridge-gpio_rst_n)) {
/*
* Request the reset pin low
[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
This series is based on master branch of Linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Changes since V3: -- Remove hotplug based initialization of exynos_dp -- Make exynos_dp work directly with drm_panel, remove dependency on panel_binder -- Minor cleanups in panel_binder and panel_lvds driver Changes since V4: -- Use gpiod interface for panel-lvds and ps8622 drivers. -- Address comments from Javier. -- Fix compilation issues when PANEL_BINDER is selected as module. -- Split Documentation patches from driver patches. -- Rebase on top of the tree. Changes since V5: -- Modify bridge drivers to support driver model. -- Drop the concept of bridge chain(sincle there are no 2 real bridges) Hence drop bridge-panel_binder layer. -- Drop panel-lvds driver and accomodate the required changes in panel-simple driver. -- Use gpiod interface in ptn3460 driver. -- Address all comments by Thierry Reding for V5 series. -- Address comments from Sean Paul for exynos_dp_commit issue. Changes since V6: -- Panel patches were seperated and they are merged already. -- Fix few issues with ptn3460, before modifying the bridge core. -- Modify drm_bridge as per Thierry's comments for V6 series. -- Add drm_bridge changes minimally without breaking existing code. -- Add new features for ptn3460, step-by-step. -- Address comments from Thierry and Andreas for ptn3460 and ps8622. -- Split documentation patches from driver patches. Changes since V7: -- Address comments from Tomi and Laurent: -- Use videoports and endpoints to represent the connection between encoder, bridge and the panel, instead of using phandles. -- Address comments from Daniel: -- Make the patch description more descriptive. -- remove device pointer from drm_bridge, and just use device_node instead. -- don't pass encoder pointer to bridge_attach. -- Address comments from Sean Paul: -- Remove bridge from mode_config, and pull out drm_bridge functions from drm_crtc.c to drm_bridge.c Note: This patchset creates the following Kconfig ambiguity. Any pointers to fix the same are welcome. drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_PTN3460 drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_PTN3460 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB Ajay Kumar (13): [PATCH V8 1/14] drm/bridge: ptn3460: Few trivial cleanups [PATCH V8 2/14] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init [PATCH V8 3/14] drm/bridge: make bridge registration independent of drm flow [PATCH V8 4/14] drm/bridge: ptn3460: Convert to i2c driver model [PATCH V8 5/14] drm/exynos: dp: support drm_bridge [PATCH V8 6/14] drm/bridge: ptn3460: support drm_panel [PATCH V8 7/14] drm/bridge: ptn3460: probe connector at the end of bridge attach [PATCH V8 8/14] drm/bridge: ptn3460: use gpiod interface [PATCH V8 9/14] Documentation: drm: bridge: move to video/bridge [PATCH V8 10/14] Documentation: devicetree: Add vendor prefix for parade [PATCH V8 11/14] Documentation: bridge: Add documentation for ps8622 DT properties [PATCH V8 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints [PATCH V8 14/14] ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints Vincent Palatin (1): [PATCH V8 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 - .../devicetree/bindings/vendor-prefixes.txt|1 + .../devicetree/bindings/video/bridge/ps8622.txt| 31 + .../devicetree/bindings/video/bridge/ptn3460.txt | 39 ++ .../devicetree/bindings/video/exynos_dp.txt| 12 + arch/arm/boot/dts/exynos5250-snow.dts | 30 +- arch/arm/boot/dts/exynos5420-peach-pit.dts | 31 +- drivers/gpu/drm
[PATCH V8 03/14] drm/bridge: make bridge registration independent of drm flow
Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.
In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
for the corresponding bridge so that the bridge receives
drm_device pointer and continues with connector and other
drm initializations.
The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.
The bridge devices register themselves onto global list of bridges
when they get probed by calling drm_bridge_add.
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 also call drm_bridge_attach to pass
on the drm_device to the bridge object.
drm_bridge_attach inturn calls bridge-funcs-attach so that
bridge can continue with drm related initializations.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/bridge/ptn3460.c | 27 +-
drivers/gpu/drm/drm_bridge.c | 91
drivers/gpu/drm/drm_crtc.c | 65 ---
drivers/gpu/drm/msm/hdmi/hdmi.c|7 +--
drivers/gpu/drm/msm/hdmi/hdmi.h|1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |7 ++-
drivers/gpu/drm/sti/sti_hda.c | 10 +---
drivers/gpu/drm/sti/sti_hdmi.c | 10 +---
include/drm/bridge/ptn3460.h |8 +++
include/drm/drm_crtc.h | 26 -
11 files changed, 136 insertions(+), 118 deletions(-)
create mode 100644 drivers/gpu/drm/drm_bridge.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9292a76..00f97a5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
- drm_modeset_lock.o
+ drm_modeset_lock.o drm_bridge.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index a2ddc8d..4a818c1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -176,24 +176,11 @@ static void ptn3460_post_disable(struct drm_bridge
*bridge)
{
}
-static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- 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 */
-}
-
static 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,
};
static int ptn3460_get_modes(struct drm_connector *connector)
@@ -314,7 +301,7 @@ int ptn3460_init(struct drm_device *dev, struct drm_encoder
*encoder,
}
ptn_bridge-bridge.funcs = ptn3460_bridge_funcs;
- ret = drm_bridge_init(dev, ptn_bridge-bridge);
+ ret = drm_bridge_attach(dev, ptn_bridge-bridge);
if (ret) {
DRM_ERROR(Failed to initialize bridge with drm\n);
goto err;
@@ -343,3 +330,15 @@ err:
return ret;
}
EXPORT_SYMBOL(ptn3460_init);
+
+void ptn3460_destroy(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+
+ 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 */
+}
+EXPORT_SYMBOL(ptn3460_destroy);
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
new file mode 100644
index 000..d1187e5
--- /dev/null
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -0,0 +1,91
[PATCH V8 02/14] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
Assign the pointer to bridge ops structure(drm_bridge_funcs) in
the bridge driver itself, instead of passing it to drm_bridge_init.
This will allow bridge driver developer to pack bridge private
information inside the bridge object and pass only the drm-relevant
information to drm_bridge_init.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/ptn3460.c |3 ++-
drivers/gpu/drm/drm_crtc.c |5 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 ++-
drivers/gpu/drm/sti/sti_hda.c |3 ++-
drivers/gpu/drm/sti/sti_hdmi.c |3 ++-
include/drm/drm_crtc.h |3 +--
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 4db38e1..a2ddc8d 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -313,7 +313,8 @@ int ptn3460_init(struct drm_device *dev, struct drm_encoder
*encoder,
goto err;
}
- ret = drm_bridge_init(dev, ptn_bridge-bridge, ptn3460_bridge_funcs);
+ ptn_bridge-bridge.funcs = ptn3460_bridge_funcs;
+ ret = drm_bridge_init(dev, ptn_bridge-bridge);
if (ret) {
DRM_ERROR(Failed to initialize bridge with drm\n);
goto err;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..408c053 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1011,7 +1011,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.
@@ -1019,8 +1018,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;
@@ -1031,7 +1029,6 @@ int drm_bridge_init(struct drm_device *dev, struct
drm_bridge *bridge,
goto out;
bridge-dev = dev;
- bridge-funcs = funcs;
list_add_tail(bridge-head, dev-mode_config.bridge_list);
dev-mode_config.num_bridge++;
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/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 2ae9a9b..6cf145d 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -664,7 +664,8 @@ static int sti_hda_bind(struct device *dev, struct device
*master, void *data)
return -ENOMEM;
bridge-driver_private = hda;
- drm_bridge_init(drm_dev, bridge, sti_hda_bridge_funcs);
+ bridge-funcs = sti_hda_bridge_funcs;
+ drm_bridge_init(drm_dev, bridge);
encoder-bridge = bridge;
connector-encoder = encoder;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index b22968c..285f723 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -628,7 +628,8 @@ static int sti_hdmi_bind(struct device *dev, struct device
*master, void *data)
return -ENOMEM;
bridge-driver_private = hdmi;
- drm_bridge_init(drm_dev, bridge, sti_hdmi_bridge_funcs);
+ bridge-funcs = sti_hdmi_bridge_funcs;
+ drm_bridge_init(drm_dev, bridge);
encoder-bridge = bridge;
connector-encoder = encoder;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..5a3bce17 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -912,8 +912,7 @@ extern unsigned int drm_connector_index(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_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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord
[PATCH V8 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints
Define videoports and use endpoints to describe the connection between
the encoder, bridge and the panel, instead of using phandles.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/boot/dts/exynos5250-snow.dts | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index e51fcef..877117f 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -254,7 +254,20 @@
powerdown-gpios = gpy2 5 GPIO_ACTIVE_HIGH;
reset-gpios = gpx1 5 GPIO_ACTIVE_HIGH;
edid-emulation = 5;
- panel = panel;
+
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+
+ port@1 {
+ bridge_in: endpoint {
+ remote-endpoint = dp_out;
+ };
+ };
+ };
};
};
@@ -328,6 +341,12 @@
compatible = auo,b116xw03;
power-supply = fet6;
backlight = backlight;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = bridge_out;
+ };
+ };
};
dp-controller@145B {
@@ -341,7 +360,14 @@
samsung,link-rate = 0x0a;
samsung,lane-count = 2;
samsung,hpd-gpio = gpx0 7 0;
- bridge = ptn3460;
+
+ ports {
+ port@0 {
+ dp_out: endpoint {
+ remote-endpoint = bridge_in;
+ };
+ };
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 08/14] drm/bridge: ptn3460: use gpiod interface
Modify driver to support gpiod interface.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/ptn3460.c | 88 --
1 file changed, 36 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 9f800a1..826833e 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -42,8 +42,8 @@ struct ptn3460_bridge {
struct drm_bridge bridge;
struct edid *edid;
struct drm_panel *panel;
- int gpio_pd_n;
- int gpio_rst_n;
+ struct gpio_desc *gpio_pd_n;
+ struct gpio_desc *gpio_rst_n;
u32 edid_emulation;
bool enabled;
};
@@ -132,14 +132,11 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
if (ptn_bridge-enabled)
return;
- if (gpio_is_valid(ptn_bridge-gpio_pd_n))
- gpio_set_value(ptn_bridge-gpio_pd_n, 1);
+ gpiod_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);
- usleep_range(10, 20);
- gpio_set_value(ptn_bridge-gpio_rst_n, 1);
- }
+ gpiod_set_value(ptn_bridge-gpio_rst_n, 0);
+ usleep_range(10, 20);
+ gpiod_set_value(ptn_bridge-gpio_rst_n, 1);
if (drm_panel_prepare(ptn_bridge-panel)) {
DRM_ERROR(failed to prepare panel\n);
@@ -184,11 +181,8 @@ static void ptn3460_disable(struct drm_bridge *bridge)
return;
}
- 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);
+ 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)
@@ -335,39 +329,41 @@ static int ptn3460_probe(struct i2c_client *client,
}
ptn_bridge-client = client;
- ptn_bridge-gpio_pd_n = of_get_named_gpio(dev-of_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) {
- dev_err(dev, Request powerdown-gpio failed (%d)\n,
- ret);
- return ret;
- }
+
+ 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);
+ dev_err(dev, cannot get gpio_pd_n %d\n, ret);
+ return ret;
}
- ptn_bridge-gpio_rst_n = of_get_named_gpio(dev-of_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) {
- dev_err(dev, Request reset-gpio failed (%d)\n, ret);
- gpio_free(ptn_bridge-gpio_pd_n);
- return ret;
- }
+ 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;
+ }
+ /*
+* 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_rst_n\n);
+ return ret;
}
ret = of_property_read_u32(dev-of_node, edid-emulation,
ptn_bridge-edid_emulation);
if (ret) {
dev_err(dev, Can't read EDID emulation value\n);
- goto err;
+ return ret;
}
ptn_bridge-bridge.funcs = ptn3460_bridge_funcs;
@@ -375,19 +371,12 @@ static int ptn3460_probe(struct i2c_client *client,
ret = drm_bridge_add(ptn_bridge-bridge);
if (ret) {
DRM_ERROR(Failed to add bridge\n);
- goto err;
+ return ret;
}
i2c_set_clientdata(client, ptn_bridge);
return
[PATCH V8 11/14] Documentation: bridge: Add documentation for ps8622 DT properties
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/bridge/ps8622.txt| 31
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..c989c38
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,31 @@
+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 for PD_ pin.
+ - reset-gpios: OF device-tree gpio specification for RST_ pin.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
+ - video interfaces: Device node can contain video interface port
+ nodes for panel according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+ lvds-bridge@48 {
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpios = gpc3 6 1 0 0;
+ reset-gpios = gpc3 1 1 0 0;
+ lane-count = 1;
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 07/14] drm/bridge: ptn3460: probe connector at the end of bridge attach
Force bridge connector detection at the end of the bridge attach.
This is needed to detect the bridge connector early.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/ptn3460.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index e6d5ae7..9f800a1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -281,6 +281,7 @@ int ptn3460_bridge_attach(struct drm_bridge *bridge)
return -ENODEV;
}
+ ptn_bridge-connector.polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(bridge-dev, ptn_bridge-connector,
ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
if (ret) {
@@ -296,6 +297,8 @@ int ptn3460_bridge_attach(struct drm_bridge *bridge)
if (ptn_bridge-panel)
drm_panel_attach(ptn_bridge-panel, ptn_bridge-connector);
+ drm_helper_hpd_irq_event(ptn_bridge-connector.dev);
+
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 09/14] Documentation: drm: bridge: move to video/bridge
Move drm/bridge documentation to video/bridge.
Also, add proper documentation for gpios used by ptn3460.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 39
.../devicetree/bindings/video/bridge/ptn3460.txt | 39
2 files changed, 39 insertions(+), 39 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 Documentation/devicetree/bindings/video/bridge/ptn3460.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
deleted file mode 100644
index 663fe6c..000
--- a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
+++ /dev/null
@@ -1,39 +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 |
- +---++--+
-
- - video interfaces: Device node can contain video interface port
- nodes for panel according to [1].
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-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;
- ports {
- port@0 {
- bridge_out: endpoint {
- remote-endpoint = panel_in;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
new file mode 100644
index 000..361971b
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
@@ -0,0 +1,39 @@
+ptn3460 bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification for PD_N pin.
+ - reset-gpio: OF device-tree gpio specification for RST_N pin.
+ - 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 |
+ +---++--+
+
+ - video interfaces: Device node can contain video interface port
+ nodes for panel according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+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;
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 14/14] ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints
Define videoports and use endpoints to describe the connection between
the encoder, bridge and the panel, instead of using phandles.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 31 ++--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 82cdb74..9d06aef 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -107,6 +107,12 @@
compatible = auo,b116xw03;
power-supply = tps65090_fet6;
backlight = backlight;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = bridge_out;
+ };
+ };
};
};
@@ -126,7 +132,14 @@
samsung,link-rate = 0x06;
samsung,lane-count = 2;
samsung,hpd-gpio = gpx2 6 0;
- bridge = ps8625;
+
+ ports {
+ port@0 {
+ dp_out: endpoint {
+ remote-endpoint = bridge_in;
+ };
+ };
+ };
};
fimd {
@@ -504,8 +517,22 @@
sleep-gpios = gpx3 5 GPIO_ACTIVE_HIGH;
reset-gpios = gpy7 7 GPIO_ACTIVE_HIGH;
lane-count = 2;
- panel = panel;
use-external-pwm;
+
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+
+ port@1 {
+ bridge_in: endpoint {
+ remote-endpoint = dp_out;
+ };
+ };
+ };
+
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 10/14] Documentation: devicetree: Add vendor prefix for parade
ps8622 eDP-LVDS converter bridge chip is from parade technologies Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..0be1508 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -110,6 +110,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. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 05/14] drm/exynos: dp: support drm_bridge
Modify driver to support drm_bridge.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos_dp.txt| 12 +++
drivers/gpu/drm/exynos/exynos_dp_core.c| 37
drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
3 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 53dbccf..7a3a9cd 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -66,6 +66,10 @@ Optional properties for dp-controller:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug
detection
+ -video interfaces: Device node can contain video interface port
+ nodes according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
@@ -105,4 +109,12 @@ Board Specific portion:
vsync-len = 6;
};
};
+
+ ports {
+ port@0 {
+ dp_out: endpoint {
+ remote-endpoint = bridge_in;
+ };
+ };
+ };
};
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 5025b70..d30c748 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
#include linux/interrupt.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_graph.h
#include linux/gpio.h
#include linux/component.h
#include linux/phy/phy.h
@@ -989,9 +990,19 @@ static struct drm_connector_helper_funcs
exynos_dp_connector_helper_funcs = {
};
/* returns the number of bridges attached */
-static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+static int exynos_drm_attach_lcd_bridge(struct exynos_dp_device *dp,
struct drm_encoder *encoder)
{
+ int ret;
+
+ encoder-bridge = dp-bridge;
+ dp-bridge-encoder = encoder;
+ ret = drm_bridge_attach(encoder-dev, dp-bridge);
+ if (ret) {
+ DRM_ERROR(Failed to attach bridge to drm\n);
+ return ret;
+ }
+
return 0;
}
@@ -1005,9 +1016,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;
@@ -1259,7 +1272,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;
@@ -1345,7 +1358,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, *endpoint;
struct exynos_dp_device *dp;
int ret;
@@ -1367,6 +1380,18 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
+ endpoint = of_graph_get_next_endpoint(dev-of_node, NULL);
+ if (endpoint) {
+ bridge_node = of_graph_get_remote_port_parent(endpoint);
+ if (bridge_node) {
+ dp-bridge = of_drm_find_bridge(bridge_node);
+ of_node_put(bridge_node);
+ if (!dp-bridge)
+ return -EPROBE_DEFER;
+ } else
+ 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_connectorconnector;
struct drm_encoder *encoder;
struct drm_panel*panel;
+ struct drm_bridge *bridge;
struct clk *clock;
unsigned intirq;
void __iomem*reg_base;
--
1.7.9.5
--
To unsubscribe from this list: send the line
[PATCH V8 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
From: Vincent Palatin vpala...@chromium.org
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/Kconfig |9 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ps8622.c | 684 +++
3 files changed, 694 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8b426e2..d06eda3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -6,3 +6,12 @@ config DRM_PTN3460
select DRM_PANEL
---help---
ptn3460 eDP-LVDS bridge chip driver.
+
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on OF I2C
+ select DRM_PANEL
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
+ ---help---
+ parade eDP-LVDS bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..105da3e 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..5474a39
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,684 @@
+/*
+ * 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/backlight.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_graph.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
+
+/* 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 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#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
+
+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 gpio_desc *gpio_slp;
+ struct gpio_desc *gpio_rst;
+
+ u32 max_lane_count;
+ u32 lane_count;
+
+ bool enabled;
+};
+
+static inline struct ps8622_bridge *
+ bridge_to_ps8622(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct ps8622_bridge, bridge);
+}
+
+static inline struct ps8622_bridge *
+ connector_to_ps8622(struct drm_connector *connector)
+{
+ return container_of(connector, struct ps8622_bridge, connector);
+}
+
+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 *ps8622)
+{
+ struct i2c_client *cl = ps8622-client;
+ int err = 0;
+
+ /* HPD low */
+ err = ps8622_set(cl, 0x02, 0xa1, 0x01);
+ if (err)
+ goto error;
+
+ /* SW setting: [1:0] SW output 1.2V voltage is lower to 96% */
+ err = ps8622_set(cl, 0x04, 0x14, 0x01
[PATCH V8 06/14] drm/bridge: ptn3460: support drm_panel
Add drm_panel calls to the driver to make the panel and
bridge work together in tandem.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 12 ++
drivers/gpu/drm/bridge/Kconfig |1 +
drivers/gpu/drm/bridge/ptn3460.c | 42
3 files changed, 55 insertions(+)
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
index 52b93b2..663fe6c 100644
--- a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -17,6 +17,11 @@ Required properties:
| 6 | 1600x900 | ChiMei M215HGE |
+---++--+
+ - video interfaces: Device node can contain video interface port
+ nodes for panel according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
Example:
lvds-bridge@20 {
compatible = nxp,ptn3460;
@@ -24,4 +29,11 @@ Example:
powerdown-gpio = gpy2 5 1 0 0;
reset-gpio = gpx1 5 1 0 0;
edid-emulation = 5;
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = panel_in;
+ };
+ };
+ };
};
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 4254c2b..8b426e2 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,5 +3,6 @@ config DRM_PTN3460
depends on DRM
depends on OF I2C
select DRM_KMS_HELPER
+ select DRM_PANEL
---help---
ptn3460 eDP-LVDS bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 7adeb60..e6d5ae7 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -19,6 +19,9 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_graph.h
+
+#include drm/drm_panel.h
#include bridge/ptn3460.h
@@ -38,6 +41,7 @@ struct ptn3460_bridge {
struct i2c_client *client;
struct drm_bridge bridge;
struct edid *edid;
+ struct drm_panel *panel;
int gpio_pd_n;
int gpio_rst_n;
u32 edid_emulation;
@@ -137,6 +141,11 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
+ if (drm_panel_prepare(ptn_bridge-panel)) {
+ DRM_ERROR(failed to prepare panel\n);
+ return;
+ }
+
/*
* 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
@@ -153,6 +162,12 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
static void ptn3460_enable(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+
+ if (drm_panel_enable(ptn_bridge-panel)) {
+ DRM_ERROR(failed to enable panel\n);
+ return;
+ }
}
static void ptn3460_disable(struct drm_bridge *bridge)
@@ -164,6 +179,11 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge-enabled = false;
+ if (drm_panel_disable(ptn_bridge-panel)) {
+ DRM_ERROR(failed to disable panel\n);
+ return;
+ }
+
if (gpio_is_valid(ptn_bridge-gpio_rst_n))
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
@@ -173,6 +193,12 @@ static void ptn3460_disable(struct drm_bridge *bridge)
static void ptn3460_post_disable(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+
+ if (drm_panel_unprepare(ptn_bridge-panel)) {
+ DRM_ERROR(failed to unprepare panel\n);
+ return;
+ }
}
static int ptn3460_get_modes(struct drm_connector *connector)
@@ -267,6 +293,9 @@ int ptn3460_bridge_attach(struct drm_bridge *bridge)
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;
}
@@ -283,6 +312,7 @@ static int ptn3460_probe(struct i2c_client *client,
{
struct device *dev = client-dev;
struct ptn3460_bridge *ptn_bridge;
+ struct device_node *endpoint, *panel_node;
int ret;
ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
@@ -290,6 +320,17 @@ static int ptn3460_probe(struct i2c_client *client,
return -ENOMEM;
}
+ endpoint
Re: [RFC PATCH] drm/exynos: Add DECON driver
Hi Inki, On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae inki@samsung.com wrote: Hi, Fortunately, I could get the user manual for Exynos7420. Below are my comments. Thanks, Inki Dae On 2014년 10월 23일 01:34, Ajay kumar wrote: On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae inki@samsung.com wrote: Thanks for contribution. It seems reasonable that you separate device drivers into FIMD and DECON because many registers of them have many different offsets and fields. However, there may be a good solution that we can combine common sets of these drivers later. Yes, this is the main reason behind sending this as RFC patch. I want to know what's the best way to do this. FIMD, 5433 DECON and Exynos7 DECON - all are different. Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). So, even I am not sure how the driver layouts should be! Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my understanding, Exynos7 doesn't mean one real SoC. We shall use Exynos7 as per the discussion. Below are my comments. Thanks, Inki Dae On 2014년 10월 10일 21:48, 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 DECON(Display and Enhancement Controller) is the new IP in exynos7 SOC for generating video signals using pixel data. DECON was used since Exynos5430. And is Exynos5433 different from Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? Yes, Exynos5433 DECON is very much different than Exynos7 DECON. Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. Again, we shall use Exynos7. I will see how manual can be arranged. DECON driver can be used to drive 2 different interfaces on Exynos7: DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) The existing FIMD driver code was used as a template to create DECON driver. Only DECON-INT is supported as of now, and DECON-EXT support will be added later. Signed-off-by: Akshu Agrawal aksh...@samsung.com Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/video/exynos-decon.txt | 68 ++ drivers/gpu/drm/exynos/Kconfig | 11 +- drivers/gpu/drm/exynos/Makefile|1 + drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + include/video/samsung_decon.h | 346 +++ 7 files changed, 1537 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c create mode 100644 include/video/samsung_decon.h diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt b/Documentation/devicetree/bindings/video/exynos-decon.txt new file mode 100644 index 000..e865650 --- /dev/null +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt @@ -0,0 +1,68 @@ +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) + +DECON (Display and Enhancement Controller) is the Display Controller for the +Exynos7 series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be samsung,exynos7-decon; If exynos5433 was just renamed to exynos7 then, it should be one of the following: (a) samsung,exynos5430-decon for Display and enhancement controller IP for Exynos5430 (b) samsung,exynos7 for Display and enhancement controller IP for Exynos7 Or, (a) samsung,exynos5430-decon for Display and enhancement controller IP for Exynos5430 (b) samsung,exynos5433-decon for Display and enhancement controller IP for Exynos5433 (c) samsung,exynos7 for Display and enhancement controller IP for Exynos7 Eventually, we will end up here. + +- reg: physical base address and length of the DECON registers set. + +- interrupt-parent: should be the phandle of the decon controller's + parent interrupt controller. + +- interrupts: should contain a list of all DECON IP block interrupts in the + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier + format depends on the interrupt controller used. + +- interrupt-names: should contain the interrupt names: fifo, vsync, + lcd_sys, in the same order as they were listed in the interrupts +property. + +- pinctrl-0: pin control group to be used for this controller. + +- pinctrl-names: must contain a default entry. + +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. + +- clock-names: list of clock names sorted in the same order as the clocks + property. Must contain pclk_decon0
Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Mon, Nov 3, 2014 at 1:31 PM, Thierry Reding thierry.red...@gmail.com wrote:
On Fri, Oct 31, 2014 at 04:51:43PM +0100, Daniel Vetter wrote:
On Wed, Oct 29, 2014 at 10:14:37AM +0100, Thierry Reding wrote:
On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
That makes the entire thing a bit non-trivial, which is why I think it
would be better as some generic helper. Which then gets embedded or
instantiated for specific cases, like dtdrm_panel or dtdrm_bridge.
Or maybe even acpidrm_bridge, who knows ;-)
I worry a little about type safety. How will this generic helper know
what registry to look in for? Or conversely, if all these resources are
added to a single registry how do you know that they're of the correct
type? Failing to ensure this could cause situations where you're asking
for a panel and get a bridge in return because you've wrongly wired it
up in device tree for example.
But perhaps if both the registry and the device parts are turned into
helpers we could still have a single core implementation and then
instantiate that for each type, something roughly like this:
struct registry {
struct list_head list;
struct mutex lock;
};
struct registry_record {
struct list_head list;
struct module *owner;
struct kref *ref;
struct device *dev;
};
int registry_add(struct registry *registry, struct registry_record
*record)
{
...
try_module_get(record-owner);
...
}
struct registry_record *registry_find_by_of_node(struct registry
*registry,
struct device_node
*np)
{
...
kref_get(...);
...
}
That way it should be possible to embed these into other structures,
like so:
struct drm_panel {
struct registry_record record;
...
};
static struct registry drm_panels;
int drm_panel_add(struct drm_panel *panel)
{
return registry_add(drm_panels, panel-record);
}
struct drm_panel *of_drm_panel_find(struct device_node *np)
{
struct registry_record *record;
record = registry_find_by_of_node(drm_panels, np);
return container_of(record, struct drm_panel, record);
}
Is that what you had in mind?
Yeah I've thought that we should instantiate using macros even, so that we
have per-type registries. So you'd smash the usual set of
DECLARE/DEFINE_AUX_DEV_REGISTRY into headers/source files, and they'd take
a (name, key, value) tripled. For the example here(of_drm_panel, struct
device_node *, struct drm_panel *) or similar. I might be hand-waving over
a few too many details though ;-)
Okay, I'll take a stab at this and see if I can convert DRM panel to it.
It would be great if you can do this soon. I would anyhow need a reference
for converting bridge framework as per Daniel's requirement :)
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
Hi Daniel and Sean,
Thanks for the comments!
On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul seanp...@chromium.org wrote:
On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter dan...@ffwll.ch wrote:
So don't ask why but I accidentally ended up in a branch looking at this
patch and didn't like it. So very quickgrumpy review.
First, please make the patch subject more descriptive: I'd expect a helper
function scaffolding like the various crtc/probe/dp ... helpers we already
have. You instead add code to untangle the probe ordering. Please say so.
Sure. I will reword it properly.
More comments below.
On Wed, Aug 27, 2014 at 07:59:37PM +0530, Ajay Kumar wrote:
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.
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 also call drm_bridge_attach to pass
on the drm_device, encoder pointers to the bridge object.
drm_bridge_attach inturn calls drm_bridge_init to register itself
with the drm core. Later, it calls bridge-funcs-attach so that
bridge can continue with other initializations.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[snip]
@@ -660,8 +662,11 @@ struct drm_bridge_funcs {
* @driver_private: pointer to the bridge driver's internal context
*/
struct drm_bridge {
- struct drm_device *dev;
+ struct device *dev;
Please don't rename the -dev pointer into drm. Because _all_ the other
drm structures still call it -dev. Also, can't we use struct device_node
here like we do in the of helpers Russell added? See 7e435aad38083
I think this is modeled after the naming in drm_panel,
Right, The entire rework is based on how drm_panel framework is structured.
FWIW. However,
seems reasonable to keep the device_node instead.
Yes, its visible that just device_node would be sufficient.
This will save us from renaming drm_device as well.
+ struct drm_device *drm;
+ struct drm_encoder *encoder;
This breaks bridge-bridge chaining (if we ever get there). It seems
pretty much unused anyway except for an EBUSY check. Can't you use
bridge-dev for that?
Yeah, I'd prefer to pass drm_device directly into drm_bridge_attach
and leave it up to the caller to establish the proper chain.
Ok. I will use drm_device pointer directly instead of passing encoder pointer.
struct list_head head;
+ struct list_head list;
These lists need better names. I know that the head is really awful,
especially since it's actually not the head of the list but just an
element.
I think we can just rip bridge_list out of mode_config if we're going
to keep track of bridges elsewhere. So we can nuke head and keep
list. This also means that bridge-destroy() goes away, but that's
probably Ok if everything converts to the standalone driver model
where we have driver-remove()
Sean
Great! Thierry actually mentioned about this once, and we have the
confirmation now.
struct drm_mode_object base;
Aside: I've noticed all this trying to update the kerneldoc for struct
drm_bridge, which just showed that this patch makes inconsistent changes.
Trying to write kerneldoc is a really great way to come up with better
interfaces imo.
Cheers, Daniel
I din't get this actually. You want me to create Doc../drm_bridge.txt
or something similar?
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul seanp...@chromium.org wrote:
On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
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.
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 also call drm_bridge_attach to pass
on the drm_device, encoder pointers to the bridge object.
drm_bridge_attach inturn calls drm_bridge_init to register itself
with the drm core. Later, it calls bridge-funcs-attach so that
bridge can continue with other initializations.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/bridge/Kconfig | 15 -
drivers/gpu/drm/drm_bridge.c | 102
drivers/gpu/drm/drm_crtc.c |4 +-
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |4 +-
include/drm/drm_crtc.h | 12 +++-
6 files changed, 131 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/drm_bridge.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a55d59..bdbfb6f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,6 +19,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
drm_cache.o \
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_BRIDGE) += drm_bridge.o
drm-$(CONFIG_DRM_PANEL) += drm_panel.o
drm-$(CONFIG_OF) += drm_of.o
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..5a8e907 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -1,5 +1,16 @@
-config DRM_PTN3460
- tristate PTN3460 DP/LVDS bridge
+config DRM_BRIDGE
I'm not convinced this adds any value, to be honest. In addition to
whether or not it's useful, it seems like you'd need to stub the
drm_bridge_* functions that are declared in drm_crtc.h or break them
out into drm_bridge.h.
Sean
+ tristate
depends on DRM
select DRM_KMS_HELPER
+ help
+ Bridge registration and lookup framework.
+
+menu bridge chips
+ depends on DRM_BRIDGE
+
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM_BRIDGE
---help---
+
+endmenu
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
new file mode 100644
index 000..b2d43fd
--- /dev/null
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -0,0 +1,102 @@
+/*
+ * 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
+
+#include drm/drmP.h
+
+static DEFINE_MUTEX(bridge_lock);
+static LIST_HEAD(bridge_list);
+
+int drm_bridge_add(struct drm_bridge *bridge)
+{
+ mutex_lock(bridge_lock);
+ list_add_tail(bridge-list, bridge_list);
+ mutex_unlock(bridge_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_bridge_add);
+
+void drm_bridge_remove(struct drm_bridge *bridge)
+{
+ mutex_lock(bridge_lock);
+ list_del_init(bridge-list);
+ mutex_unlock(bridge_lock);
+}
+EXPORT_SYMBOL(drm_bridge_remove);
+
+int drm_bridge_attach(struct drm_bridge *bridge,
+ struct drm_encoder *encoder)
+{
+ int ret;
+
+ if (!bridge || !encoder)
+ return -EINVAL;
+
+ if (bridge-encoder)
+ return -EBUSY
Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul seanp...@chromium.org wrote: On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar ajaykumar...@samsung.com wrote: 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. 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 also call drm_bridge_attach to pass on the drm_device, encoder pointers to the bridge object. drm_bridge_attach inturn calls drm_bridge_init to register itself with the drm core. Later, it calls bridge-funcs-attach so that bridge can continue with other initializations. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/bridge/Kconfig | 15 - drivers/gpu/drm/drm_bridge.c | 102 drivers/gpu/drm/drm_crtc.c |4 +- drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |4 +- include/drm/drm_crtc.h | 12 +++- 6 files changed, 131 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/drm_bridge.c diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 4a55d59..bdbfb6f 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -19,6 +19,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \ 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_BRIDGE) += drm_bridge.o drm-$(CONFIG_DRM_PANEL) += drm_panel.o drm-$(CONFIG_OF) += drm_of.o diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 884923f..5a8e907 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,5 +1,16 @@ -config DRM_PTN3460 - tristate PTN3460 DP/LVDS bridge +config DRM_BRIDGE I'm not convinced this adds any value, to be honest. Hmm, then how to compile drm_bridge.c? In addition to whether or not it's useful, it seems like you'd need to stub the drm_bridge_* functions that are declared in drm_crtc.h or break them out into drm_bridge.h. Well, Thierry mentioned about this long back. Again, we have the confirmation now! Ajay [snip] -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Tue, Oct 28, 2014 at 2:42 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: Hello Ajay, On Thu, Oct 16, 2014 at 11:04 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Right. It would be great if you guys come to agreement ASAP! I don't think we'll agree any time soon, so I believe it's up to you to decide which option is best based on all arguments that have been presented. Did you decide what's the correct approach? I don't have a strong opinion, I'm just asking because it would be a pity if your series miss another kernel release... I will be using graphs instead of phandles, and would send a series ASAP. Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar ajayn...@gmail.com wrote:
Hi Daniel and Sean,
Thanks for the comments!
On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul seanp...@chromium.org wrote:
On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter dan...@ffwll.ch wrote:
So don't ask why but I accidentally ended up in a branch looking at this
patch and didn't like it. So very quickgrumpy review.
First, please make the patch subject more descriptive: I'd expect a helper
function scaffolding like the various crtc/probe/dp ... helpers we already
have. You instead add code to untangle the probe ordering. Please say so.
Sure. I will reword it properly.
More comments below.
On Wed, Aug 27, 2014 at 07:59:37PM +0530, Ajay Kumar wrote:
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.
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 also call drm_bridge_attach to pass
on the drm_device, encoder pointers to the bridge object.
drm_bridge_attach inturn calls drm_bridge_init to register itself
with the drm core. Later, it calls bridge-funcs-attach so that
bridge can continue with other initializations.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[snip]
@@ -660,8 +662,11 @@ struct drm_bridge_funcs {
* @driver_private: pointer to the bridge driver's internal context
*/
struct drm_bridge {
- struct drm_device *dev;
+ struct device *dev;
Please don't rename the -dev pointer into drm. Because _all_ the other
drm structures still call it -dev. Also, can't we use struct device_node
here like we do in the of helpers Russell added? See 7e435aad38083
I think this is modeled after the naming in drm_panel,
Right, The entire rework is based on how drm_panel framework is structured.
FWIW. However,
seems reasonable to keep the device_node instead.
Yes, its visible that just device_node would be sufficient.
This will save us from renaming drm_device as well.
+ struct drm_device *drm;
+ struct drm_encoder *encoder;
This breaks bridge-bridge chaining (if we ever get there). It seems
pretty much unused anyway except for an EBUSY check. Can't you use
bridge-dev for that?
Yeah, I'd prefer to pass drm_device directly into drm_bridge_attach
and leave it up to the caller to establish the proper chain.
Ok. I will use drm_device pointer directly instead of passing encoder
pointer.
Hm, if you do this can you pls also update drm_panel accordingly? It
shouldn't be a lot of fuzz and would make things around drm+dt more
consistent.
Are you talking about using struct device_node instead of struct device?
I guess you have misplaced the comment under the wrong section!
struct list_head head;
+ struct list_head list;
These lists need better names. I know that the head is really awful,
especially since it's actually not the head of the list but just an
element.
I think we can just rip bridge_list out of mode_config if we're going
to keep track of bridges elsewhere. So we can nuke head and keep
list. This also means that bridge-destroy() goes away, but that's
probably Ok if everything converts to the standalone driver model
where we have driver-remove()
Sean
Great! Thierry actually mentioned about this once, and we have the
confirmation now.
struct drm_mode_object base;
Aside: I've noticed all this trying to update the kerneldoc for struct
drm_bridge, which just showed that this patch makes inconsistent changes.
Trying to write kerneldoc is a really great way to come up with better
interfaces imo.
Cheers, Daniel
I din't get this actually. You want me to create Doc../drm_bridge.txt
or something similar?
If you want to document drm_bridge then I recomment to sprinkle proper
kerneldoc over drm_bridge.c and pull it all into the drm DocBook
template. That way all the drm documentation is in one place. I've
done that for drm_crtc.h in an unrelated patch series (but based upon
a branch with your patch here included) and there's struct drm_bridge*
in there. Hence why I've noticed.
Can you send a link for that?
And, is there any problem if the doc comes later?
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote: On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar ajayn...@gmail.com wrote: On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter dan...@ffwll.ch wrote: [...] Hm, if you do this can you pls also update drm_panel accordingly? It shouldn't be a lot of fuzz and would make things around drm+dt more consistent. Are you talking about using struct device_node instead of struct device? I guess you have misplaced the comment under the wrong section! Yeah, that should have been one up ;-) Like I said earlier, I don't think dropping struct device * in favour of struct device_node * is a good idea. I am not sure about drm_panel. But, I am not really doing anything with the struct device pointer in case of bridge. So, just wondering if it is really needed? Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] drm/exynos: Add DECON driver
On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae inki@samsung.com wrote: Thanks for contribution. It seems reasonable that you separate device drivers into FIMD and DECON because many registers of them have many different offsets and fields. However, there may be a good solution that we can combine common sets of these drivers later. Yes, this is the main reason behind sending this as RFC patch. I want to know what's the best way to do this. FIMD, 5433 DECON and Exynos7 DECON - all are different. Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). So, even I am not sure how the driver layouts should be! Below are my comments. Thanks, Inki Dae On 2014년 10월 10일 21:48, 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 DECON(Display and Enhancement Controller) is the new IP in exynos7 SOC for generating video signals using pixel data. DECON was used since Exynos5430. And is Exynos5433 different from Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? Yes, Exynos5433 DECON is very much different than Exynos7 DECON. I will see how manual can be arranged. DECON driver can be used to drive 2 different interfaces on Exynos7: DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) The existing FIMD driver code was used as a template to create DECON driver. Only DECON-INT is supported as of now, and DECON-EXT support will be added later. Signed-off-by: Akshu Agrawal aksh...@samsung.com Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/video/exynos-decon.txt | 68 ++ drivers/gpu/drm/exynos/Kconfig | 11 +- drivers/gpu/drm/exynos/Makefile|1 + drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + include/video/samsung_decon.h | 346 +++ 7 files changed, 1537 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c create mode 100644 include/video/samsung_decon.h diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt b/Documentation/devicetree/bindings/video/exynos-decon.txt new file mode 100644 index 000..e865650 --- /dev/null +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt @@ -0,0 +1,68 @@ +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) + +DECON (Display and Enhancement Controller) is the Display Controller for the +Exynos7 series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be samsung,exynos7-decon; If exynos5433 was just renamed to exynos7 then, it should be one of the following: (a) samsung,exynos5430-decon for Display and enhancement controller IP for Exynos5430 (b) samsung,exynos7 for Display and enhancement controller IP for Exynos7 Or, (a) samsung,exynos5430-decon for Display and enhancement controller IP for Exynos5430 (b) samsung,exynos5433-decon for Display and enhancement controller IP for Exynos5433 (c) samsung,exynos7 for Display and enhancement controller IP for Exynos7 Eventually, we will end up here. + +- reg: physical base address and length of the DECON registers set. + +- interrupt-parent: should be the phandle of the decon controller's + parent interrupt controller. + +- interrupts: should contain a list of all DECON IP block interrupts in the + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier + format depends on the interrupt controller used. + +- interrupt-names: should contain the interrupt names: fifo, vsync, + lcd_sys, in the same order as they were listed in the interrupts +property. + +- pinctrl-0: pin control group to be used for this controller. + +- pinctrl-names: must contain a default entry. + +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. + +- clock-names: list of clock names sorted in the same order as the clocks + property. Must contain pclk_decon0, aclk_decon0, +decon0_eclk, decon0_vclk, sclk_dsd, aclk_lh_disp0, +aclk_disp, aclk_lh_disp1. Should DECON driver really control above all clocks? I think it's enough that DECON driver controls only lcd and bus clocks, and others could be configured by boot-loader or by calling clk_set_rate. Yes, even I am not sure of the clocks. I have copied these clocks from intrnal android code. + +Optional Properties: +- samsung,power-domain: a phandle to DECON power domain node. You
Re: [RFC PATCH] drm/exynos: Add DECON driver
ping!
On Fri, Oct 10, 2014 at 6:18 PM, Ajay Kumar ajaykumar...@samsung.com 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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aksh...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos-decon.txt | 68 ++
drivers/gpu/drm/exynos/Kconfig | 11 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086
drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 +
include/video/samsung_decon.h | 346 +++
7 files changed, 1537 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
create mode 100644 include/video/samsung_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt
b/Documentation/devicetree/bindings/video/exynos-decon.txt
new file mode 100644
index 000..e865650
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
@@ -0,0 +1,68 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk, sclk_dsd, aclk_lh_disp0,
+ aclk_disp, aclk_lh_disp1.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL,
+clock_disp SCLK_DSD,
+clock_bus0 ACLK_LH_DISP0,
+clock_disp ACLK_CP_DISP,
+clock_bus0 ACLK_LH_DISP1;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk, sclk_dsd, aclk_lh_disp0,
+ aclk_disp, aclk_lh_disp1;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index fd1c070..89275ea 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -31,6 +31,13 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS_DECON
+ bool Exynos DRM DECON
+ depends on DRM_EXYNOS
+ select FB_MODE_HELPERS
+ help
+ Choose this option if you want to use Exynos DECON for DRM.
+
config DRM_EXYNOS_DPI
bool
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
ping! On Fri, Oct 10, 2014 at 6:33 PM, Ajay kumar ajayn...@gmail.com wrote: On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote: Hi Ajay, On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote: On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote: On 20/09/14 14:22, Ajay kumar wrote: Well, I am okay with using video ports to describe the relationship between the encoder, bridge and the panel. But, its just that I need to make use of 2 functions when phandle does it using just one function ;) -panel_node = of_parse_phandle(dev-of_node, panel, 0) + endpoint = of_graph_get_next_endpoint(dev-of_node, NULL); + if (!endpoint) + return -EPROBE_DEFER; + + panel_node = of_graph_get_remote_port_parent(endpoint); + if (!panel_node) + return -EPROBE_DEFER; If nobody else has objections over using of_graph functions instead of phandles, I can respin this patchset by making use of video ports. The discussion did digress somewhat. As a clarification, I'm in no way nack'ing this series because it doesn't use the graphs for video connections. I don't see the simple phandle bindings used here as broken as such. Well, I am okay with any approach you guys decide on. I desperately want this to get this in since it has been floating around for quite sometime. The more we drag this, the more rework for me since the number of platforms using bridge support is increasing daily! I won't nack this patch either. I'm however concerned that we'll run straight into the wall if we don't come up with an agreement on a standard way to describe connections in DT for display devices, which is why I would prefer the ps8622 bindings to use OF graph to describe connections. I think there's not really an easy way out here. It's pretty bold trying to come up with a common way to describe bridges when we have only a single one (and a single use-case at that). The worst that can happen is that we need to change the binding at some point, in which case we may have to special-case early drivers, but I really don't think that's as much of an issue as everybody seems to think. This series has been floating around for months because we're being overly prudent to accept a binding that /may/ turn out to not be generic enough. Right. It would be great if you guys come to agreement ASAP! Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] drm/exynos: Add DECON driver
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
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aksh...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos-decon.txt | 68 ++
drivers/gpu/drm/exynos/Kconfig | 11 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086
drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 +
include/video/samsung_decon.h | 346 +++
7 files changed, 1537 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
create mode 100644 include/video/samsung_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt
b/Documentation/devicetree/bindings/video/exynos-decon.txt
new file mode 100644
index 000..e865650
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
@@ -0,0 +1,68 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk, sclk_dsd, aclk_lh_disp0,
+ aclk_disp, aclk_lh_disp1.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL,
+clock_disp SCLK_DSD,
+clock_bus0 ACLK_LH_DISP0,
+clock_disp ACLK_CP_DISP,
+clock_bus0 ACLK_LH_DISP1;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk, sclk_dsd, aclk_lh_disp0,
+ aclk_disp, aclk_lh_disp1;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index fd1c070..89275ea 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -31,6 +31,13 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS_DECON
+ bool Exynos DRM DECON
+ depends on DRM_EXYNOS
+ select FB_MODE_HELPERS
+ help
+ Choose this option if you want to use Exynos DECON for DRM.
+
config DRM_EXYNOS_DPI
bool EXYNOS DRM parallel output support
depends on DRM_EXYNOS_FIMD
@@ -41,7 +48,7 @@ config DRM_EXYNOS_DPI
config DRM_EXYNOS_DSI
bool EXYNOS DRM MIPI-DSI driver support
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote: Hi Ajay, On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote: On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote: On 20/09/14 14:22, Ajay kumar wrote: Well, I am okay with using video ports to describe the relationship between the encoder, bridge and the panel. But, its just that I need to make use of 2 functions when phandle does it using just one function ;) -panel_node = of_parse_phandle(dev-of_node, panel, 0) + endpoint = of_graph_get_next_endpoint(dev-of_node, NULL); + if (!endpoint) + return -EPROBE_DEFER; + + panel_node = of_graph_get_remote_port_parent(endpoint); + if (!panel_node) + return -EPROBE_DEFER; If nobody else has objections over using of_graph functions instead of phandles, I can respin this patchset by making use of video ports. The discussion did digress somewhat. As a clarification, I'm in no way nack'ing this series because it doesn't use the graphs for video connections. I don't see the simple phandle bindings used here as broken as such. Well, I am okay with any approach you guys decide on. I desperately want this to get this in since it has been floating around for quite sometime. The more we drag this, the more rework for me since the number of platforms using bridge support is increasing daily! I won't nack this patch either. I'm however concerned that we'll run straight into the wall if we don't come up with an agreement on a standard way to describe connections in DT for display devices, which is why I would prefer the ps8622 bindings to use OF graph to describe connections. I think there's not really an easy way out here. It's pretty bold trying to come up with a common way to describe bridges when we have only a single one (and a single use-case at that). The worst that can happen is that we need to change the binding at some point, in which case we may have to special-case early drivers, but I really don't think that's as much of an issue as everybody seems to think. This series has been floating around for months because we're being overly prudent to accept a binding that /may/ turn out to not be generic enough. Right. It would be great if you guys come to agreement ASAP! Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup
On Thu, Oct 9, 2014 at 3:56 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Ajay, On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar ajayn...@gmail.com wrote: Hi, On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam gautam.vi...@samsung.com wrote: These patches are based on 'for-next' branch of kgene's linux-samsung tree. Refactoring the exynos-dp-video phy to use pmu-system-controller handle and access the register using mfd-syscon and regmap. Simultaneously, removing the support for older dptx-phy, since it's obsolete now and noone uses it. Vivek Gautam (3): phy: exynos-dp-video: Use syscon support to control pmu register drm/exynos: dp: Remove support for unused dptx-phy arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy .../devicetree/bindings/phy/samsung-phy.txt|7 +- arch/arm/boot/dts/exynos5250.dtsi |2 +- arch/arm/boot/dts/exynos5420.dtsi |4 +- drivers/gpu/drm/exynos/exynos_dp_core.c| 58 --- drivers/gpu/drm/exynos/exynos_dp_core.h|2 - drivers/phy/phy-exynos-dp-video.c | 76 ++-- 6 files changed, 75 insertions(+), 74 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I have tested this patchset on exynos5800-peach-pi, and I can see DP display with the above patches. we expect Tested-by, if you have tested please give the same. Tested-by: Ajay Kumar ajaykumar...@samsung.com Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 20/09/14 14:22, Ajay kumar wrote: Well, I am okay with using video ports to describe the relationship between the encoder, bridge and the panel. But, its just that I need to make use of 2 functions when phandle does it using just one function ;) -panel_node = of_parse_phandle(dev-of_node, panel, 0) + endpoint = of_graph_get_next_endpoint(dev-of_node, NULL); + if (!endpoint) + return -EPROBE_DEFER; + + panel_node = of_graph_get_remote_port_parent(endpoint); + if (!panel_node) + return -EPROBE_DEFER; If nobody else has objections over using of_graph functions instead of phandles, I can respin this patchset by making use of video ports. The discussion did digress somewhat. As a clarification, I'm in no way nack'ing this series because it doesn't use the graphs for video connections. I don't see the simple phandle bindings used here as broken as such. Well, I am okay with any approach you guys decide on. I desperately want this to get this in since it has been floating around for quite sometime. The more we drag this, the more rework for me since the number of platforms using bridge support is increasing daily! Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: remove ifdeferry from initialization code
On Wed, Oct 1, 2014 at 11:18 AM, Inki Dae inki@samsung.com wrote:
On 2014년 09월 30일 20:29, Andrzej Hajda wrote:
Hi Inki,
Gently ping.
Hi Andrzej,
I merged it to local repository to test. But now exynos drm doesn't work
correctly since pulling drm-next of Dave regardless of your patch.
Problems are,
1. error occurs when we try to test modetest with -v option from second
times.
I face a similar issue. For me, modetest -v doesn't work for the first try also.
I tried to test on snow and peach_pit.
modetest returns with following error from drm_crtc.c:
if (crtc-primary-fb-pixel_format != fb-pixel_format) {
DRM_DEBUG_KMS(Page flip is not allowed to change
frame buffer format.\n);
ret = -EINVAL;
goto out;
}
This has started coming since 3.15 I think.
Ajay
2. error occurs when we try to test unbind.
Now we are checking these problems. Can you try to also check it?
Thanks,
Inki Dae
Andrzej
On 09/10/2014 01:53 PM, Andrzej Hajda wrote:
The patch replaces separate calls to driver (de)registration by
loops over the array of drivers. As a result it significantly
decreases number of ifdefs. Additionally it moves device registration
related ifdefs to header file.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
Hi Inki,
During testing your component match support patch [1] I have prepared patch
removing most ifdefs from exynos_drm_drv.c. It is based on your patch, but
I can rebase it if necessary.
[1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37031
Regards
Andrzej
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 170
+++-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 25 +++--
2 files changed, 48 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b2c710a..a660e46 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -553,74 +553,54 @@ static const struct component_master_ops
exynos_drm_ops = {
.unbind = exynos_drm_unbind,
};
-static int exynos_drm_platform_probe(struct platform_device *pdev)
-{
-struct component_match *match;
-int ret;
-
-pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
-exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
-
+static struct platform_driver * const exynos_drm_drivers[] = {
#ifdef CONFIG_DRM_EXYNOS_FIMD
-ret = platform_driver_register(fimd_driver);
-if (ret 0)
-return ret;
+fimd_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_DP
-ret = platform_driver_register(dp_driver);
-if (ret 0)
-goto err_unregister_fimd_drv;
+dp_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_DSI
-ret = platform_driver_register(dsi_driver);
-if (ret 0)
-goto err_unregister_dp_drv;
+dsi_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_HDMI
-ret = platform_driver_register(mixer_driver);
-if (ret 0)
-goto err_unregister_dsi_drv;
-ret = platform_driver_register(hdmi_driver);
-if (ret 0)
-goto err_unregister_mixer_drv;
+mixer_driver,
+hdmi_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_G2D
-ret = platform_driver_register(g2d_driver);
-if (ret 0)
-goto err_unregister_hdmi_drv;
+g2d_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_FIMC
-ret = platform_driver_register(fimc_driver);
-if (ret 0)
-goto err_unregister_g2d_drv;
+fimc_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_ROTATOR
-ret = platform_driver_register(rotator_driver);
-if (ret 0)
-goto err_unregister_fimc_drv;
+rotator_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_GSC
-ret = platform_driver_register(gsc_driver);
-if (ret 0)
-goto err_unregister_rotator_drv;
+gsc_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_IPP
-ret = platform_driver_register(ipp_driver);
-if (ret 0)
-goto err_unregister_gsc_drv;
+ipp_driver,
+#endif
+};
+
+static int exynos_drm_platform_probe(struct platform_device *pdev)
+{
+struct component_match *match;
+int ret, i;
+
+pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
+
+for (i = 0; i ARRAY_SIZE(exynos_drm_drivers); ++i) {
+ret = platform_driver_register(exynos_drm_drivers[i]);
+if (ret 0)
+goto err_unregister_drivers;
+}
ret = exynos_platform_device_ipp_register();
if (ret 0)
-goto err_unregister_ipp_drv;
-#endif
+goto err_unregister_drivers;
match = exynos_drm_match_add(pdev-dev);
if (IS_ERR(match)) {
@@ -632,96 +612,24 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Tue, Sep 23, 2014 at 11:25 AM, Thierry Reding
thierry.red...@gmail.com wrote:
On Tue, Sep 23, 2014 at 03:00:37AM +0300, Laurent Pinchart wrote:
On Monday 22 September 2014 13:35:15 Thierry Reding wrote:
On Mon, Sep 22, 2014 at 04:53:22PM +0530, Ajay kumar wrote:
On Mon, Sep 22, 2014 at 4:11 PM, Thierry Reding wrote:
On Mon, Sep 22, 2014 at 02:01:38PM +0530, Ajay kumar wrote:
On Mon, Sep 22, 2014 at 1:40 PM, Thierry Reding wrote:
On Thu, Sep 18, 2014 at 11:20:40AM +0530, Ajay kumar wrote:
On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen wrote:
On 17/09/14 17:29, Ajay kumar wrote:
On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen wrote:
On 27/08/14 17:39, Ajay Kumar wrote:
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/bridge/ps8622.txt| 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/bridge/ps8622.txt
diff --git
a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..0ec8172
--- /dev/null
+++
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,20 @@
+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 for PD_
pin.
+ - reset-gpios: OF device-tree gpio specification for
RST_
pin.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an
external PWM
What does this mean? That the backlight support from ps8625 is
not used? If so, maybe disable-pwm or something?
use-external-pwm or disable-bridge-pwm would be better.
Well, the properties are about the bridge. use-external-pwm
means that the bridge uses an external PWM, which, if I
understood
correctly, is not what the property is about.
disable-bridge-pwm is ok, but the bridge there is extra. The
properties are about the bridge, so it's implicit.
Ok. I will use disable-pwm.
Why is this even necessary? According to the datasheet this device
has circuitry for backlight control. If so, I'd expect it to expose
either a backlight device or a PWM device. That way unless somebody
is using the backlight/PWM exposed by the bridge the bridge can
simply disable PWM.
The driver does expose a backlight device.
And, the decision(whether to expose a backlight device or not) is made
based on the DT flag use-external-pwm.
This was discussed before, and you suggested to use the boolean
property, refer to this link:
http://lists.freedesktop.org/archives/dri-devel/2014-July/065048.html
I think you misunderstood what I said, or maybe I didn't explain
clearly
what I meant. If the PS8622 provides a backlight there's nothing wrong
with always exposing it. The bridge itself isn't going to be using the
backlight anyway. Rather the panel itself should be using the backlight
device exposed by PS8622 or some separate backlight device.
To illustrate by an example:
ps8622: ... {
compatible = parade,ps8622;
...
};
panel {
...
backlight = ps8622;
...
};
No, if ps8622 backlight control is used, we need not specify the
backlight
phandle for the panel driver. Somehow, ps8622 internal circuitry keeps
the bootup glitch free :)
Backlight control and panel controls can be separate then.
But they shouldn't. Your panel driver should always be the one to
control backlight. How else is the bridge supposed to know when to turn
backlight on or off?
What you did in v6 of this series was look up a backlight device and
then not use it. That seemed unnecessary. Looking at v6 again the
reason
for getting a phandle to the backlight was so that the device itself
did
not expose its own backlight controlling circuitry if an external one
was being used. But since the bridge has no business controlling the
backlight, having the backlight phandle in the bridge is not correct.
So I think what you could do in the driver instead is always expose the
backlight device. If the panel used a different backlight, the PS8622's
internal on simply wouldn't be accessed. It would still be possible to
control the backlight
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Sat, Sep 20, 2014 at 8:57 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: [adding Kukjin as cc] Hello Ajay, On Sat, Sep 20, 2014 at 1:22 PM, Ajay kumar ajayn...@gmail.com wrote: Generally speaking, I sense that we have different views of how display devices and drivers are structured. You say If some XYZ platform wishes to pick the DT node via a different method, they are always welcome to do it.. This sounds to me that you see the connections between display devices as something handled by a platform specific driver. I, on the other hand, see connections between display devices as common properties. Well, I am okay with using video ports to describe the relationship between the encoder, bridge and the panel. But, its just that I need to make use of 2 functions when phandle does it using just one function ;) -panel_node = of_parse_phandle(dev-of_node, panel, 0) + endpoint = of_graph_get_next_endpoint(dev-of_node, NULL); + if (!endpoint) + return -EPROBE_DEFER; + + panel_node = of_graph_get_remote_port_parent(endpoint); + if (!panel_node) + return -EPROBE_DEFER; If nobody else has objections over using of_graph functions instead of phandles, I can respin this patchset by making use of video ports. I certainly have no objections about re-using the video ports/endpoints DT bindings for the bridges but just wanted to point out that Kukjin has already merged on his tree the DTS changes for display on Snow and Peach Pit using the current binding and also sent the pull request [0] to ARM SoC maintainers since he probably was expecting this series to make ti for 3.18. So that should be handled somehow. Kukjin, Can you do something about this? Or, I shall make video-port changes on top of whatever gets merged? Ajay Tomi, I see that Documentation/devicetree/bindings/video/ti,omap-dss.txt mentions that the Video Ports binding documentation is in Documentation/devicetree/bindings/video/video-ports.txt but I don't see that this file exists in the kernel [1]. I see though that is was included on your series adding DSS DT support [2]. Do you know what happened with this file? Best regards, Javier [0]: https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36681.html [1]: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/video [2]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/227088.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Thierry, On Mon, Sep 22, 2014 at 1:40 PM, Thierry Reding thierry.red...@gmail.com wrote: On Thu, Sep 18, 2014 at 11:20:40AM +0530, Ajay kumar wrote: Hi Tomi, On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 17/09/14 17:29, Ajay kumar wrote: Hi Tomi, Thanks for your comments. On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 27/08/14 17:39, Ajay Kumar wrote: Add documentation for DT properties supported by ps8622/ps8625 eDP-LVDS converter. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/video/bridge/ps8622.txt| 20 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt b/Documentation/devicetree/bindings/video/bridge/ps8622.txt new file mode 100644 index 000..0ec8172 --- /dev/null +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt @@ -0,0 +1,20 @@ +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 for PD_ pin. + - reset-gpios: OF device-tree gpio specification for RST_ pin. + +Optional properties: + - lane-count: number of DP lanes to use + - use-external-pwm: backlight will be controlled by an external PWM What does this mean? That the backlight support from ps8625 is not used? If so, maybe disable-pwm or something? use-external-pwm or disable-bridge-pwm would be better. Well, the properties are about the bridge. use-external-pwm means that the bridge uses an external PWM, which, if I understood correctly, is not what the property is about. disable-bridge-pwm is ok, but the bridge there is extra. The properties are about the bridge, so it's implicit. Ok. I will use disable-pwm. Why is this even necessary? According to the datasheet this device has circuitry for backlight control. If so, I'd expect it to expose either a backlight device or a PWM device. That way unless somebody is using the backlight/PWM exposed by the bridge the bridge can simply disable PWM. The driver does expose a backlight device. And, the decision(whether to expose a backlight device or not) is made based on the DT flag use-external-pwm. This was discussed before, and you suggested to use the boolean property, refer to this link: http://lists.freedesktop.org/archives/dri-devel/2014-July/065048.html Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Mon, Sep 22, 2014 at 4:11 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Sep 22, 2014 at 02:01:38PM +0530, Ajay kumar wrote:
Hi Thierry,
On Mon, Sep 22, 2014 at 1:40 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Thu, Sep 18, 2014 at 11:20:40AM +0530, Ajay kumar wrote:
Hi Tomi,
On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On 17/09/14 17:29, Ajay kumar wrote:
Hi Tomi,
Thanks for your comments.
On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen
tomi.valkei...@ti.com wrote:
On 27/08/14 17:39, Ajay Kumar wrote:
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/bridge/ps8622.txt| 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/bridge/ps8622.txt
diff --git
a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..0ec8172
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,20 @@
+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 for PD_ pin.
+ - reset-gpios: OF device-tree gpio specification for RST_ pin.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an
external PWM
What does this mean? That the backlight support from ps8625 is not
used?
If so, maybe disable-pwm or something?
use-external-pwm or disable-bridge-pwm would be better.
Well, the properties are about the bridge. use-external-pwm means that
the bridge uses an external PWM, which, if I understood correctly, is
not what the property is about.
disable-bridge-pwm is ok, but the bridge there is extra. The
properties are about the bridge, so it's implicit.
Ok. I will use disable-pwm.
Why is this even necessary? According to the datasheet this device has
circuitry for backlight control. If so, I'd expect it to expose either a
backlight device or a PWM device. That way unless somebody is using the
backlight/PWM exposed by the bridge the bridge can simply disable PWM.
The driver does expose a backlight device.
And, the decision(whether to expose a backlight device or not) is made
based on the DT flag use-external-pwm.
This was discussed before, and you suggested to use the boolean
property, refer to this link:
http://lists.freedesktop.org/archives/dri-devel/2014-July/065048.html
I think you misunderstood what I said, or maybe I didn't explain clearly
what I meant. If the PS8622 provides a backlight there's nothing wrong
with always exposing it. The bridge itself isn't going to be using the
backlight anyway. Rather the panel itself should be using the backlight
device exposed by PS8622 or some separate backlight device.
To illustrate by an example:
ps8622: ... {
compatible = parade,ps8622;
...
};
panel {
...
backlight = ps8622;
...
};
No, if ps8622 backlight control is used, we need not specify the backlight
phandle for the panel driver. Somehow, ps8622 internal circuitry keeps
the bootup glitch free :)
Backlight control and panel controls can be separate then.
Or:
backlight: ... {
compatible = pwm-backlight;
...
};
panel {
...
backlight = backlight;
...
};
This is the way it is for peach_pit.
What you did in v6 of this series was look up a backlight device and
then not use it. That seemed unnecessary. Looking at v6 again the reason
for getting a phandle to the backlight was so that the device itself did
not expose its own backlight controlling circuitry if an external one
was being used. But since the bridge has no business controlling the
backlight, having the backlight phandle in the bridge is not correct.
So I think what you could do in the driver instead is always expose the
backlight device. If the panel used a different backlight, the PS8622's
internal on simply wouldn't be accessed. It would still be possible to
control the backlight in sysfs, but that shouldn't be a problem (only
root can access it)
That would be like simple exposing a feature which cannot be used
by the user, ideally which should not be used by the user.
That said, I have no strong objections to the boolean property if you
feel like it's really necessary.
Won't you think having a boolean property for an optional
feature
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Mon, Sep 22, 2014 at 5:05 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Sep 22, 2014 at 04:53:22PM +0530, Ajay kumar wrote:
On Mon, Sep 22, 2014 at 4:11 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Sep 22, 2014 at 02:01:38PM +0530, Ajay kumar wrote:
Hi Thierry,
On Mon, Sep 22, 2014 at 1:40 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Thu, Sep 18, 2014 at 11:20:40AM +0530, Ajay kumar wrote:
Hi Tomi,
On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen
tomi.valkei...@ti.com wrote:
On 17/09/14 17:29, Ajay kumar wrote:
Hi Tomi,
Thanks for your comments.
On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen
tomi.valkei...@ti.com wrote:
On 27/08/14 17:39, Ajay Kumar wrote:
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/bridge/ps8622.txt| 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/bridge/ps8622.txt
diff --git
a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..0ec8172
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,20 @@
+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 for PD_
pin.
+ - reset-gpios: OF device-tree gpio specification for RST_
pin.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an
external PWM
What does this mean? That the backlight support from ps8625 is not
used?
If so, maybe disable-pwm or something?
use-external-pwm or disable-bridge-pwm would be better.
Well, the properties are about the bridge. use-external-pwm means
that
the bridge uses an external PWM, which, if I understood correctly, is
not what the property is about.
disable-bridge-pwm is ok, but the bridge there is extra. The
properties are about the bridge, so it's implicit.
Ok. I will use disable-pwm.
Why is this even necessary? According to the datasheet this device has
circuitry for backlight control. If so, I'd expect it to expose either a
backlight device or a PWM device. That way unless somebody is using the
backlight/PWM exposed by the bridge the bridge can simply disable PWM.
The driver does expose a backlight device.
And, the decision(whether to expose a backlight device or not) is made
based on the DT flag use-external-pwm.
This was discussed before, and you suggested to use the boolean
property, refer to this link:
http://lists.freedesktop.org/archives/dri-devel/2014-July/065048.html
I think you misunderstood what I said, or maybe I didn't explain clearly
what I meant. If the PS8622 provides a backlight there's nothing wrong
with always exposing it. The bridge itself isn't going to be using the
backlight anyway. Rather the panel itself should be using the backlight
device exposed by PS8622 or some separate backlight device.
To illustrate by an example:
ps8622: ... {
compatible = parade,ps8622;
...
};
panel {
...
backlight = ps8622;
...
};
No, if ps8622 backlight control is used, we need not specify the backlight
phandle for the panel driver. Somehow, ps8622 internal circuitry keeps
the bootup glitch free :)
Backlight control and panel controls can be separate then.
But they shouldn't. Your panel driver should always be the one to
control backlight. How else is the bridge supposed to know when to turn
backlight on or off?
In internal pwm case, we keep the backlight on in probe, and from userspace
its upto the user to control it via sysfs.
And, ps8622 generates backlight only if video data is coming from the encoder.
Backlight is synced with video data using an internal circuit, I think.
Since internal pwm is tied to video data, but not to any of the panel
controls, we need not do any backlight control in panel driver.
What you did in v6 of this series was look up a backlight device and
then not use it. That seemed unnecessary. Looking at v6 again the reason
for getting a phandle to the backlight was so that the device itself did
not expose its own backlight controlling circuitry if an external one
was being used. But since the bridge has no business controlling the
backlight, having the backlight phandle in the bridge is not correct.
So I think what you could do in the driver
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Fri, Sep 19, 2014 at 7:58 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 19/09/14 16:59, Ajay kumar wrote: I am not really able to understand, what's stopping us from using this bridge on a board with complex display connections. To use ps8622 driver, one needs to attach it to the DRM framework. For this, the DRM driver Remember that when we talk about DT bindings, there's no such thing as DRM. We talk about hardware. The same bindings need to work on any operating system. Agreed. would need the DT node for ps8622 bridge. For which I use a phandle. A complex one could be for example a case where you have two different panels connected to ps8622, and you can switch between the two panels with, say, a gpio. How do you present that with a simple phandle? In the exynos5420-peach-pit.dts, which you linked earlier, I see a panel property in the ps8625 node. That's missing from the bindings in this patch. Why is that? How is the panel linked in this version? Oops, my bad! Panel should also be present in the DT binding(for which, I am using a phandle for panel node) If some XYZ platform wishes to pick the DT node via a different method, they are always welcome to do it. Just because I am not specifying a video port/endpoint in the DT binding example, would it mean that platform cannot make use of ports in future? If that is the case, I can add something All the platforms share the same bindings for ps8622. If you now specify that ps8622 bindings use a simple phandle, then anyone who uses ps8622 should support that. Of course the bindings can be extended in the future. In that case the drivers need to support both the old and the new bindings, which is always a hassle. Generally speaking, I sense that we have different views of how display devices and drivers are structured. You say If some XYZ platform wishes to pick the DT node via a different method, they are always welcome to do it.. This sounds to me that you see the connections between display devices as something handled by a platform specific driver. I, on the other hand, see connections between display devices as common properties. Well, I am okay with using video ports to describe the relationship between the encoder, bridge and the panel. But, its just that I need to make use of 2 functions when phandle does it using just one function ;) -panel_node = of_parse_phandle(dev-of_node, panel, 0) + endpoint = of_graph_get_next_endpoint(dev-of_node, NULL); + if (!endpoint) + return -EPROBE_DEFER; + + panel_node = of_graph_get_remote_port_parent(endpoint); + if (!panel_node) + return -EPROBE_DEFER; If nobody else has objections over using of_graph functions instead of phandles, I can respin this patchset by making use of video ports. Ajay Say, we could have a display board, with a panel and an encoder and maybe some other components, which takes parallel RGB as input. The same display board could as well be connected to an OMAP board or to an Exynos board. I think the exact same display-board.dtsi file, which describes the devices and connections in the display board, should be usable on both OMAP and Exynos platforms. This means we need to have a common way to describe video devices, just as we have for other things. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support
Hi, On Wed, Sep 17, 2014 at 3:02 PM, Ajay kumar ajayn...@gmail.com wrote: On Tue, Sep 16, 2014 at 6:14 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: [adding Laurent Pinchart to cc who had concerns with a previous version of this patch-set] Hello Ajay, On Wed, Aug 27, 2014 at 4:29 PM, Ajay Kumar ajaykumar...@samsung.com wrote: This series is based on master branch of Linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git I have tested this after adding few DT changes for exynos5250-snow and exynos5420-peach-pit boards. The V4 series of this particular patchset was also tested by: Rahul Sharma rahul.sha...@samsung.com Javier Martinez Canillas jav...@dowhile0.org Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Changes since V3: -- Remove hotplug based initialization of exynos_dp -- Make exynos_dp work directly with drm_panel, remove dependency on panel_binder -- Minor cleanups in panel_binder and panel_lvds driver Changes since V4: -- Use gpiod interface for panel-lvds and ps8622 drivers. -- Address comments from Javier. -- Fix compilation issues when PANEL_BINDER is selected as module. -- Split Documentation patches from driver patches. -- Rebase on top of the tree. Changes since V5: -- Modify bridge drivers to support driver model. -- Drop the concept of bridge chain(sincle there are no 2 real bridges) Hence drop bridge-panel_binder layer. -- Drop panel-lvds driver and accomodate the required changes in panel-simple driver. -- Use gpiod interface in ptn3460 driver. -- Address all comments by Thierry Reding for V5 series. -- Address comments from Sean Paul for exynos_dp_commit issue. Changes since V6: -- Panel patches were seperated and they are merged already. -- Fix few issues with ptn3460, before modifying the bridge core. -- Modify drm_bridge as per Thierry's comments for V6 series. -- Add drm_bridge changes minimally without breaking existing code. -- Add new features for ptn3460, step-by-step. -- Address comments from Thierry and Andreas for ptn3460 and ps8622. -- Split documentation patches from driver patches. I've tested your series on an Exynos5420 Peach Pit and an Exynos5250 Snow Chromebooks and display worked for me on both machines. Great! I also needed [PATCH] drm/panel: simple: Add AUO B116XW03 panel support [0] which does not apply cleanly on linux-next so you may want to do a re-spin for that patch. Ok. I will take care of this in next version. For Snow I also had to disable CONFIG_FB_SIMPLE, otherwise I just saw a blink on boot and only the backlight remained turned on (no display output). I don't know if that is expected since IIUC it should be possible to do a transition from simplefb to a DRM/KMS driver. I don't have a serial console hooked on this machine so I couldn't debug it further, sorry. I am just wondering how SIMPLE FB can affect DRM based display. I am not even sure if both can co-exist or not. Is there anything we can do with bootargs instead of CONFIG? Ajay Also, I saw that Laurent mentioned some concerns today about the previous version (v6) of your series [1]. I guess he missed this v7 although AFAIU there was no fundamental change on this one so his concerns remains? I was really hoping that this could make it to 3.18 since display support is one of the last major functionalities that is missing on these machines. Best regards, Javier [0]: http://patchwork.ozlabs.org/patch/384744/ [1]: http://www.spinics.net/lists/linux-samsung-soc/msg36791.html I am thinking of respinning this patchset based on Tomi's suggestion for using video ports instead of phandles. So, please go through this patchset once again and let me know if any other review comment need to be addressed! Day by day, no of boards using bridge is increasing and its a pain to consolidate all of them when I am respinning :( Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Fri, Sep 19, 2014 at 6:24 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 18/09/14 08:50, Ajay kumar wrote: Why do we need a complex graph when it can be handled using a simple phandle? Maybe in your case you can handle it with simple phandle. Can you guarantee that it's enough for everyone, on all platforms? Yes, as of now exynos5420-peach-pit and exynos5250-spring boards use this. In case of both, the phandle to bridge node is passed to the exynos_dp node. The point of the ports/endpoint graph is to also support more complicated scenarios. If you now create ps8622 bindings that do not support those graphs, the no one else using ps8622 can use ports/endpoint graphs either. Btw, is there an example how the bridge with these bindings is used in a board's .dts file? I couldn't find any example with a quick search. So it's unclear to me what the simple phandle actually is. Please refer to the following link: https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/tree/arch/arm/boot/dts/exynos5420-peach-pit.dts?id=samsung-dt#n129 Let me know if you still think we would need to describe it as a complex graph! Yes, I think so. I'm not the DRM maintainer, though. I think we have two options: 1) Describe the video component connections with the ports/endpoints properly for all new display device bindings, and know that it's (hopefully) future proof and covers even the more complex boards that use the devices. or 2) Use some simple methods to describe the links, like single phandle as you do, knowing that we can't support more complex boards in the future. I am not really able to understand, what's stopping us from using this bridge on a board with complex display connections. To use ps8622 driver, one needs to attach it to the DRM framework. For this, the DRM driver would need the DT node for ps8622 bridge. For which I use a phandle. If some XYZ platform wishes to pick the DT node via a different method, they are always welcome to do it. Just because I am not specifying a video port/endpoint in the DT binding example, would it mean that platform cannot make use of ports in future? If that is the case, I can add something like this: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/panel/samsung,ld9040.txt#L61 Regards, Ajay kumar I see some exynos boards already using the ports/endpoints, like arch/arm/boot/dts/exynos4412-trats2.dts. Why not use it for all new display devices? Tomi -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
Hi Laurent, On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart laurent.pinch...@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...@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 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support
On Tue, Sep 16, 2014 at 6:14 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: [adding Laurent Pinchart to cc who had concerns with a previous version of this patch-set] Hello Ajay, On Wed, Aug 27, 2014 at 4:29 PM, Ajay Kumar ajaykumar...@samsung.com wrote: This series is based on master branch of Linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git I have tested this after adding few DT changes for exynos5250-snow and exynos5420-peach-pit boards. The V4 series of this particular patchset was also tested by: Rahul Sharma rahul.sha...@samsung.com Javier Martinez Canillas jav...@dowhile0.org Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Changes since V3: -- Remove hotplug based initialization of exynos_dp -- Make exynos_dp work directly with drm_panel, remove dependency on panel_binder -- Minor cleanups in panel_binder and panel_lvds driver Changes since V4: -- Use gpiod interface for panel-lvds and ps8622 drivers. -- Address comments from Javier. -- Fix compilation issues when PANEL_BINDER is selected as module. -- Split Documentation patches from driver patches. -- Rebase on top of the tree. Changes since V5: -- Modify bridge drivers to support driver model. -- Drop the concept of bridge chain(sincle there are no 2 real bridges) Hence drop bridge-panel_binder layer. -- Drop panel-lvds driver and accomodate the required changes in panel-simple driver. -- Use gpiod interface in ptn3460 driver. -- Address all comments by Thierry Reding for V5 series. -- Address comments from Sean Paul for exynos_dp_commit issue. Changes since V6: -- Panel patches were seperated and they are merged already. -- Fix few issues with ptn3460, before modifying the bridge core. -- Modify drm_bridge as per Thierry's comments for V6 series. -- Add drm_bridge changes minimally without breaking existing code. -- Add new features for ptn3460, step-by-step. -- Address comments from Thierry and Andreas for ptn3460 and ps8622. -- Split documentation patches from driver patches. I've tested your series on an Exynos5420 Peach Pit and an Exynos5250 Snow Chromebooks and display worked for me on both machines. Great! I also needed [PATCH] drm/panel: simple: Add AUO B116XW03 panel support [0] which does not apply cleanly on linux-next so you may want to do a re-spin for that patch. Ok. I will take care of this in next version. For Snow I also had to disable CONFIG_FB_SIMPLE, otherwise I just saw a blink on boot and only the backlight remained turned on (no display output). I don't know if that is expected since IIUC it should be possible to do a transition from simplefb to a DRM/KMS driver. I don't have a serial console hooked on this machine so I couldn't debug it further, sorry. I am just wondering how SIMPLE FB can affect DRM based display. I am not even sure if both can co-exist or not. Is there anything we can do with bootargs instead of CONFIG? Ajay Also, I saw that Laurent mentioned some concerns today about the previous version (v6) of your series [1]. I guess he missed this v7 although AFAIU there was no fundamental change on this one so his concerns remains? I was really hoping that this could make it to 3.18 since display support is one of the last major functionalities that is missing on these machines. Best regards, Javier [0]: http://patchwork.ozlabs.org/patch/384744/ [1]: http://www.spinics.net/lists/linux-samsung-soc/msg36791.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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.pinch...@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 afaer...@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?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
On Wed, Sep 17, 2014 at 2:57 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com 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
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Tomi,
Thanks for your comments.
On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 27/08/14 17:39, Ajay Kumar wrote:
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/bridge/ps8622.txt| 20
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..0ec8172
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,20 @@
+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 for PD_ pin.
+ - reset-gpios: OF device-tree gpio specification for RST_ pin.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
What does this mean? That the backlight support from ps8625 is not used?
If so, maybe disable-pwm or something?
use-external-pwm or disable-bridge-pwm would be better.
+
+Example:
+ lvds-bridge@48 {
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpios = gpc3 6 1 0 0;
+ reset-gpios = gpc3 1 1 0 0;
+ lane-count = 1;
+ };
I wish all new display component bindings would use the video
ports/endpoints to describe the connections. It will be very difficult
to improve the display driver model later if we're missing such critical
pieces from the DT bindings.
Why do we need a complex graph when it can be handled using a simple phandle?
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Tomi,
On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 17/09/14 17:29, Ajay kumar wrote:
Hi Tomi,
Thanks for your comments.
On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On 27/08/14 17:39, Ajay Kumar wrote:
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/bridge/ps8622.txt| 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/bridge/ps8622.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..0ec8172
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,20 @@
+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 for PD_ pin.
+ - reset-gpios: OF device-tree gpio specification for RST_ pin.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
What does this mean? That the backlight support from ps8625 is not used?
If so, maybe disable-pwm or something?
use-external-pwm or disable-bridge-pwm would be better.
Well, the properties are about the bridge. use-external-pwm means that
the bridge uses an external PWM, which, if I understood correctly, is
not what the property is about.
disable-bridge-pwm is ok, but the bridge there is extra. The
properties are about the bridge, so it's implicit.
Ok. I will use disable-pwm.
+
+Example:
+ lvds-bridge@48 {
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpios = gpc3 6 1 0 0;
+ reset-gpios = gpc3 1 1 0 0;
+ lane-count = 1;
+ };
I wish all new display component bindings would use the video
ports/endpoints to describe the connections. It will be very difficult
to improve the display driver model later if we're missing such critical
pieces from the DT bindings.
Why do we need a complex graph when it can be handled using a simple phandle?
Maybe in your case you can handle it with simple phandle. Can you
guarantee that it's enough for everyone, on all platforms?
Yes, as of now exynos5420-peach-pit and exynos5250-spring boards use
this. In case of both, the phandle to bridge node is passed to the
exynos_dp node.
The point of the ports/endpoint graph is to also support more
complicated scenarios. If you now create ps8622 bindings that do not
support those graphs, the no one else using ps8622 can use
ports/endpoint graphs either.
Btw, is there an example how the bridge with these bindings is used in a
board's .dts file? I couldn't find any example with a quick search. So
it's unclear to me what the simple phandle actually is.
Please refer to the following link:
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/tree/arch/arm/boot/dts/exynos5420-peach-pit.dts?id=samsung-dt#n129
Let me know if you still think we would need to describe it as a complex graph!
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] ARM: dts: Add DT changes for display on snow
Hi Kukjin, On Sat, Sep 13, 2014 at 10:52 PM, Kukjin Kim kgene@samsung.com wrote: On 09/01/14 19:36, Ajay Kumar wrote: Add DT nodes for ptn3460 bridge chip and panel. Add backlight enable pin and backlight power supply for pwm-backlight. Also add bridge phandle needed by dp to enable display on snow. Signed-off-by: Ajay Kumarajaykumar...@samsung.com --- Changes since V1: -- Remove simple-panel compatible string. -- Use GPIO_ACTIVE_HIGH instead of 0. -- Change panel node naming from panel-simple to panel. Changes since V2: -- Use proper compatible string: auo,b116xw03 arch/arm/boot/dts/exynos5250-snow.dts | 41 ++--- 1 file changed, 22 insertions(+), 19 deletions(-) Applied this and 2nd one. BTW, I resolved conflict when I applied. Please check my tree and then if any problems, please let me know. This patchset has dependency on driver patches. But, no harm merging it since DT bindings are almost agreed. The below patch should be merged ASAP. Because, driver changes are already in for this patch: https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35182.html Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support
ping. On Wed, Aug 27, 2014 at 7:59 PM, Ajay Kumar ajaykumar...@samsung.com wrote: This series is based on master branch of Linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git I have tested this after adding few DT changes for exynos5250-snow and exynos5420-peach-pit boards. The V4 series of this particular patchset was also tested by: Rahul Sharma rahul.sha...@samsung.com Javier Martinez Canillas jav...@dowhile0.org Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Changes since V3: -- Remove hotplug based initialization of exynos_dp -- Make exynos_dp work directly with drm_panel, remove dependency on panel_binder -- Minor cleanups in panel_binder and panel_lvds driver Changes since V4: -- Use gpiod interface for panel-lvds and ps8622 drivers. -- Address comments from Javier. -- Fix compilation issues when PANEL_BINDER is selected as module. -- Split Documentation patches from driver patches. -- Rebase on top of the tree. Changes since V5: -- Modify bridge drivers to support driver model. -- Drop the concept of bridge chain(sincle there are no 2 real bridges) Hence drop bridge-panel_binder layer. -- Drop panel-lvds driver and accomodate the required changes in panel-simple driver. -- Use gpiod interface in ptn3460 driver. -- Address all comments by Thierry Reding for V5 series. -- Address comments from Sean Paul for exynos_dp_commit issue. Changes since V6: -- Panel patches were seperated and they are merged already. -- Fix few issues with ptn3460, before modifying the bridge core. -- Modify drm_bridge as per Thierry's comments for V6 series. -- Add drm_bridge changes minimally without breaking existing code. -- Add new features for ptn3460, step-by-step. -- Address comments from Thierry and Andreas for ptn3460 and ps8622. -- Split documentation patches from driver patches. [PATCH V7 5/12] drm/exynos: dp: support drm_bridge introduces following Kconfig error: drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:39: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:33: symbol DRM_KMS_HELPER is selected by DRM_BRIDGE drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_EXYNOS_DP drivers/gpu/drm/exynos/Kconfig:53: symbol DRM_EXYNOS_DP depends on DRM_EXYNOS_FIMD drivers/gpu/drm/exynos/Kconfig:28: symbol DRM_EXYNOS_FIMD depends on FB_S3C drivers/video/fbdev/Kconfig:2038: symbol FB_S3C depends on FB What's the best way to fix the above ambiguity? Ajay Kumar (11): [PATCH V7 1/12] drm/bridge: ptn3460: Few trivial cleanups [PATCH V7 2/12] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init [PATCH V7 3/12] drm/bridge: Add helper functions for drm_bridge [PATCH V7 4/12] drm/bridge: ptn3460: convert to i2c driver model [PATCH V7 5/12] drm/exynos: dp: support drm_bridge [PATCH V7 6/12] drm/bridge: ptn3460: support drm_panel [PATCH V7 7/12] drm/bridge: ptn3460: probe connector at the end of bridge attach [PATCH V7 8/12] drm/bridge: ptn3460: use gpiod interface [PATCH V7 9/12] Documentation: drm: bridge: move to video/bridge [PATCH V7 10/12] Documentation: devicetree: Add vendor prefix for parade [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties Vincent Palatin (1): [PATCH V7 12/12] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 - .../devicetree/bindings/vendor-prefixes.txt|1 + .../devicetree/bindings/video/bridge/ps8622.txt| 20 + .../devicetree/bindings/video/bridge/ptn3460.txt | 27 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/bridge/Kconfig | 30 +- drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/ps8622.c| 681 drivers/gpu/drm/bridge/ptn3460.c | 302 + drivers/gpu/drm/drm_bridge.c | 102 +++ drivers/gpu/drm/drm_crtc.c |9 +- drivers/gpu/drm/exynos/Kconfig |3 +- drivers/gpu/drm/exynos/exynos_dp_core.c| 54 +- drivers/gpu/drm/exynos/exynos_dp_core.h|1 + drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |7 +- drivers/gpu/drm/sti/sti_hda.c
Re: [PATCH 1/1] ARM: exynos_defconfig: Enable options for display panel support
Hi, On Wed, Sep 3, 2014 at 9:56 PM, Kukjin Kim kgene@samsung.com wrote: Javier Martinez Canillas wrote: Many Exynos devices have a display panel, most of them just have a simple panel while others have more complex configurations that requires an embedded DisplayPort (eDP) to LVDS display bridge. This patch enables the following features to support both setups: - Direct Rendering Manager (DRM) - DRM bridge registration and lookup framework - Parade ps8622/ps8625 eDP/LVDS bridge - NXP ptn3460 eDP/LVDS bridge - Exynos Fully Interactive Mobile Display controller (FIMD) - Panel registration and lookup framework - Simple panels - Backlight and LCD device support Thanks a lot. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Some of the options enabled here (e.g: the eDP/LVDS bridges) are still not merged in mainline so this patch depends on the following posted patches that were still not merged: drm/bridge: Modify drm_bridge core to support driver model [0] drm/bridge: Add i2c based driver for ptn3460 bridge [1] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge [2] BTW, I can't find its re-spin...how was going on? I already sent this a week back.Find it here: http://www.spinics.net/lists/dri-devel/msg66740.html Inki Dae, In this patchset, patch [PATCH V7 5/12] drm/exynos: dp: support drm_bridge introduces following Kconfig error: drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:39: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:33: symbol DRM_KMS_HELPER is selected by DRM_BRIDGE drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_EXYNOS_DP drivers/gpu/drm/exynos/Kconfig:53: symbol DRM_EXYNOS_DP depends on DRM_EXYNOS_FIMD drivers/gpu/drm/exynos/Kconfig:28: symbol DRM_EXYNOS_FIMD depends on FB_S3C drivers/video/fbdev/Kconfig:2038: symbol FB_S3C depends on FB How to fix this? Can we remove dependency between FB_S3C and DRM_EXYNOS_FIMD? But I wanted to post anyways to make easier for others to figure out what are the needed options to have the display working on their Exynos machines. In order to test the display panel on the Peach machines, the following patches are also needed: ARM: dts: Add DT changes for display on peach_pit [3] ARM: dts: Add DT changes for display on peach_pi [4] I'll have a look them soon. The above ones are older versions. Latest ones are here: 1) http://www.spinics.net/lists/linux-samsung-soc/msg35344.html 2) http://www.spinics.net/lists/arm-kernel/msg358324.html 3) http://www.spinics.net/lists/arm-kernel/msg358325.html Among the above, patch (1) can be merged because corresponding driver changes are already merged! Ajay - Kukjin Best regards, Javier [0]: http://patchwork.ozlabs.org/patch/373792/ [1]: http://patchwork.ozlabs.org/patch/373793/ [2]: http://patchwork.ozlabs.org/patch/373794/ [3]: http://www.spinics.net/lists/arm-kernel/msg350568.html [4]: http://www.spinics.net/lists/arm-kernel/msg350569.html arch/arm/configs/exynos_defconfig | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 676c744..f69d57e 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -101,11 +101,25 @@ CONFIG_REGULATOR_S2MPA01=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS65090=y +CONFIG_DRM=y +CONFIG_DRM_BRIDGE=y +CONFIG_DRM_PS8622=y +CONFIG_DRM_EXYNOS=y +CONFIG_DRM_EXYNOS_FIMD=y +CONFIG_DRM_EXYNOS_DP=y +CONFIG_DRM_PANEL=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_SIMPLE=y CONFIG_EXYNOS_VIDEO=y CONFIG_EXYNOS_MIPI_DSI=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y +CONFIG_LCD_PLATFORM=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y +CONFIG_BACKLIGHT_GENERIC=y +CONFIG_BACKLIGHT_PWM=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FONTS=y CONFIG_FONT_7x14=y -- 2.0.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot mainline on snow chromebook since 3.15
Hi Will, On Fri, Sep 5, 2014 at 5:52 PM, Will Deacon will.dea...@arm.com wrote: [Looks like it's not just Rutland that can't spell the address of the mailing list today. Fixed here, so please use this post in any replies]. On Fri, Sep 05, 2014 at 12:57:04PM +0100, Will Deacon wrote: Hi all, I'm one of the few, foolish people to try running mainline on my 5250-based Samsung Chromebook (snow). I can live without wireless, usb3 and video acceleration, so actually it makes a reasonable development platform for doing A15-based (micro)-architectural work. However, since 3.15 I've not been able to boot *any* mainline kernels on this board. I did mean to report this earlier, but I have other machines that can run mainline so this has fallen by the wayside. The problems started with 3.16, where simple-fb would fail to initialise and I lost my display. Note that I don't have a serial console on this machine (I looked at the PCB and there's no way I can solder one of those myself :) I bisected the issue at the time, and I could get my display back by removing some of the new regulator and hdmi properties from the DT. At that point, I could boot, but DMA didn't initialise for the MMC controller so I couldn't mount my root filesystem. http://www.spinics.net/lists/dri-devel/msg66740.html With 3.17-rc3, it seems a lot worse -- I don't get any output after nv-uboot (i.e. the nv-uboot screen just remains on the display, with the last line reading Stashed 20 records). I'd usually try to debug this a bit further, but without a console it's really painful to get anywhere. I've been working with 3.15, but now I'm having to backport patches when I want to test them, which is more effort than I can be bothered with. Is anybody else running mainline on this device and are these known/fixed problems? AFAIK, ARM chromebooks use DRM based display drivers and the required patches are still not merged: http://www.spinics.net/lists/dri-devel/msg66740.html Corresponding DT patches are also still not merged: http://www.spinics.net/lists/arm-kernel/msg358324.html http://www.spinics.net/lists/arm-kernel/msg358325.html There is a patch for configs as well: https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35828.html Try these patches(I hope they will apply directly on 3.17-rc3) and you should be able to use display on snow. Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/panel: simple: Add AUO B116XW03 panel support
The AUO B116XW03 is a 11.6 HD TFT LCD panel connecting to a LVDS
interface and with an integrated LED backlight unit.
This panel is used on the Samsung Chromebook(XE303C12).
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/panel/auo,b116xw03.txt |7 ++
drivers/gpu/drm/panel/panel-simple.c | 25
2 files changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b116xw03.txt
diff --git a/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
b/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
new file mode 100644
index 000..690d0a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 11.6 HD (1366x768) color TFT-LCD panel
+
+Required properties:
+- compatible: should be auo,b116xw03
+
+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 4ce1db0..51566e0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -352,6 +352,28 @@ static const struct panel_desc auo_b101aw03 = {
},
};
+static const struct drm_display_mode auo_b116xw03_mode = {
+ .clock = 70589,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 40,
+ .hsync_end = 1366 + 40 + 40,
+ .htotal = 1366 + 40 + 40 + 32,
+ .vdisplay = 768,
+ .vsync_start = 768 + 10,
+ .vsync_end = 768 + 10 + 12,
+ .vtotal = 768 + 10 + 12 + 6,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b116xw03 = {
+ .modes = auo_b116xw03_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 256,
+ .height = 144,
+ },
+};
+
static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -616,6 +638,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = auo,b101aw03,
.data = auo_b101aw03,
}, {
+ .compatible = auo,b116xw03,
+ .data = auo_b116xw03,
+ }, {
.compatible = auo,b133htn01,
.data = auo_b133htn01,
}, {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/2] ARM: dts: Add DT changes for display on snow
Add DT nodes for ptn3460 bridge chip and panel.
Add backlight enable pin and backlight power supply for pwm-backlight.
Also add bridge phandle needed by dp to enable display on snow.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Remove simple-panel compatible string.
-- Use GPIO_ACTIVE_HIGH instead of 0.
-- Change panel node naming from panel-simple to panel.
Changes since V2:
-- Use proper compatible string: auo,b116xw03
arch/arm/boot/dts/exynos5250-snow.dts | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index f2b8c41..1ac9709 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -9,6 +9,7 @@
*/
/dts-v1/;
+#include dt-bindings/gpio/gpio.h
#include exynos5250.dtsi
#include exynos5250-cros-common.dtsi
@@ -181,7 +182,7 @@
dcdc3 {
ti,enable-ext-control;
};
- fet1 {
+ fet1: fet1 {
regulator-name = vcd_led;
ti,overcurrent-wait = 3;
};
@@ -204,7 +205,7 @@
regulator-always-on;
ti,overcurrent-wait = 3;
};
- fet6 {
+ fet6: fet6 {
regulator-name = lcd_vdd;
ti,overcurrent-wait = 3;
};
@@ -253,6 +254,15 @@
pinctrl-0 = max98095_en;
pinctrl-names = default;
};
+
+ ptn3460: lvds-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpios = gpy2 5 GPIO_ACTIVE_HIGH;
+ reset-gpios = gpx1 5 GPIO_ACTIVE_HIGH;
+ edid-emulation = 5;
+ panel = panel;
+ };
};
i2s0: i2s@0383 {
@@ -300,11 +310,13 @@
vdd_pll-supply = ldo8_reg;
};
- backlight {
+ backlight: backlight {
compatible = pwm-backlight;
pwms = pwm 0 100 0;
brightness-levels = 0 100 500 1000 1500 2000 2500 2800;
default-brightness-level = 7;
+ enable-gpios = gpx3 0 GPIO_ACTIVE_HIGH;
+ power-supply = fet1;
pinctrl-0 = pwm0_out;
pinctrl-names = default;
};
@@ -314,6 +326,12 @@
samsung,invert-vclk;
};
+ panel: panel {
+ compatible = auo,b116xw03;
+ power-supply = fet6;
+ backlight = backlight;
+ };
+
dp-controller@145B {
status = okay;
pinctrl-names = default;
@@ -325,22 +343,7 @@
samsung,link-rate = 0x0a;
samsung,lane-count = 2;
samsung,hpd-gpio = gpx0 7 0;
-
- display-timings {
- native-mode = timing1;
-
- timing1: timing@1 {
- clock-frequency = 70589280;
- hactive = 1366;
- vactive = 768;
- hfront-porch = 40;
- hback-porch = 40;
- hsync-len = 32;
- vback-porch = 10;
- vfront-porch = 12;
- vsync-len = 6;
- };
- };
+ bridge = ptn3460;
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/2] ARM: dts: Add DT changes for display on peach_pit
Add DT nodes for ps8622 bridge chip and panel.
Add backlight power supply for pwm-backlight.
Also add bridge phandle needed by dp to enable display on peach_pit.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Remove simple-panel compatible string.
-- Use GPIO_ACTIVE_HIGH instead of 0.
-- Change panel node naming from panel-simple to panel.
Changes since V2:
-- Use proper compatible string: auo,b116xw03
arch/arm/boot/dts/exynos5420-peach-pit.dts | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 228a6b1..1070a31 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -30,11 +30,12 @@
i2c20 = /spi@12d4/cros-ec@0/i2c-tunnel;
};
- backlight {
+ backlight: backlight {
compatible = pwm-backlight;
pwms = pwm 0 100 0;
brightness-levels = 0 100 500 1000 1500 2000 2500 2800;
default-brightness-level = 7;
+ power-supply = tps65090_fet1;
pinctrl-0 = pwm0_out;
pinctrl-names = default;
};
@@ -100,6 +101,12 @@
regulator-boot-on;
regulator-always-on;
};
+
+ panel: panel {
+ compatible = auo,b116xw03;
+ power-supply = tps65090_fet6;
+ backlight = backlight;
+ };
};
dp {
@@ -113,22 +120,7 @@
samsung,link-rate = 0x06;
samsung,lane-count = 2;
samsung,hpd-gpio = gpx2 6 0;
-
- display-timings {
- native-mode = timing1;
-
- timing1: timing@1 {
- clock-frequency = 70589280;
- hactive = 1366;
- vactive = 768;
- hfront-porch = 40;
- hback-porch = 40;
- hsync-len = 32;
- vback-porch = 10;
- vfront-porch = 12;
- vsync-len = 6;
- };
- };
+ bridge = ps8625;
};
fimd {
@@ -155,6 +147,16 @@
pinctrl-names = default;
pinctrl-0 = max98090_irq;
};
+
+ ps8625: lvds-bridge@48 {
+ compatible = parade,ps8625;
+ reg = 0x48;
+ sleep-gpios = gpx3 5 GPIO_ACTIVE_HIGH;
+ reset-gpios = gpy7 7 GPIO_ACTIVE_HIGH;
+ lane-count = 2;
+ panel = panel;
+ use-external-pwm;
+ };
};
hsi2c_9 {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
