Re: [PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI

2015-03-04 Thread Ajay kumar
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

2015-03-04 Thread Ajay kumar
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

2015-03-04 Thread Ajay kumar
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

2015-03-02 Thread Ajay kumar
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

2015-03-02 Thread Ajay kumar
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

2015-02-26 Thread Ajay Kumar
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

[PATCH 2/2] drm/exynos: decon: Add support for DECON-EXT

2015-02-26 Thread Ajay Kumar
* 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
 
+#define DECON_EXT_CH_MAPPING   0x432105
+
+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,
+   .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;
struct exynos_drm_display *display;
 };
 
 static const struct of_device_id decon_driver_dt_match[] = {
-   {.compatible = samsung,exynos7-decon},
+   { .compatible = samsung,exynos7-decon-int,
+ .data = exynos7_decon_int_driver_data },
+   { .compatible = samsung,exynos7-decon-ext,
+ .data = exynos7_decon_ext_driver_data },
{},
 };
 MODULE_DEVICE_TABLE(of, decon_driver_dt_match);
 
+static inline struct decon_driver_data *drm_decon_get_driver_data(
+   struct platform_device *pdev)
+{
+   const struct of_device_id *of_id =
+   of_match_device(decon_driver_dt_match, pdev-dev);
+
+   return (struct decon_driver_data *)of_id-data;
+}
+
 static void decon_wait_for_vblank(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc-ctx;
@@ -106,13 +141,20 @@ static void decon_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
 
 static void decon_clear_channel(struct decon_context *ctx)
 {
+   struct decon_driver_data *drv_data = ctx-driver_data;
int win, ch_enabled = 0;
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
/* Check if any channel is enabled. */
-   for (win = 0; win  WINDOWS_NR; win++) {
-   u32 val = readl(ctx-regs + WINCON(win));
+   for (win = 0; win  drv_data-nr_windows; win++) {
+   u32 val;
+   /* DECON EXT sw-hw window mapping */
+   if (drv_data-decon_type == DECON_EXT) {
+   if (win == 0)
+   win = 1;
+   }
+   val = readl(ctx-regs + WINCON(win));
 
if (val  WINCONx_ENWIN) {
val = ~WINCONx_ENWIN;
@@ -187,10 +229,74 @@ static bool decon_mode_fixup(struct exynos_drm_crtc *crtc,
return true;
 }
 
+struct decon_ext_videomode {
+   u32 vfront_porch;
+   u32 vback_porch;
+   u32 hfront_porch;
+   u32 hback_porch;
+   u32 vsync_len;
+   u32 hsync_len;
+   u32 hactive;
+   u32 vactive;
+   u32 refresh_rate;
+};
+
+enum DECON_EXT_MODES {
+   MODE_720_480_60,
+   MODE_720_576_50,
+   MODE_1280_720_60,
+   MODE_1280_720_50

Re: [PATCH V4] drm/exynos: Add DECON driver

2015-02-11 Thread Ajay kumar
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

2015-02-05 Thread Ajay Kumar
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

2015-02-04 Thread Ajay kumar
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

2015-02-02 Thread Ajay kumar
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

2015-02-02 Thread Ajay kumar
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

2015-01-29 Thread Ajay kumar
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

2015-01-29 Thread Ajay kumar
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

2015-01-26 Thread Ajay kumar
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

2015-01-20 Thread Ajay kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2015-01-20 Thread Ajay Kumar
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

2014-12-08 Thread Ajay kumar
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

2014-12-07 Thread Ajay kumar
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

2014-12-07 Thread 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

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

2014-12-07 Thread Ajay Kumar
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

2014-12-07 Thread Ajay Kumar
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

2014-12-01 Thread Ajay kumar
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

2014-11-28 Thread Ajay Kumar
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

2014-11-28 Thread Ajay Kumar
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

2014-11-28 Thread 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

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

2014-11-27 Thread 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

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

2014-11-27 Thread Ajay kumar
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

2014-11-25 Thread Ajay kumar
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

2014-11-25 Thread Ajay kumar
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

2014-11-25 Thread Ajay kumar
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

2014-11-24 Thread Ajay kumar
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

2014-11-21 Thread Ajay kumar
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

2014-11-21 Thread Ajay kumar
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

2014-11-19 Thread Ajay kumar
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

2014-11-17 Thread Ajay kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-15 Thread Ajay Kumar
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

2014-11-11 Thread Ajay kumar
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

2014-11-03 Thread Ajay kumar
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

2014-10-28 Thread Ajay kumar
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

2014-10-28 Thread Ajay kumar
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

2014-10-28 Thread Ajay kumar
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

2014-10-28 Thread Ajay kumar
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

2014-10-28 Thread Ajay kumar
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

2014-10-28 Thread Ajay kumar
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

2014-10-22 Thread Ajay kumar
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

2014-10-20 Thread Ajay kumar
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

2014-10-16 Thread Ajay kumar
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

2014-10-10 Thread 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

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

2014-10-10 Thread Ajay kumar
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

2014-10-09 Thread Ajay kumar
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

2014-10-07 Thread Ajay kumar
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

2014-10-01 Thread Ajay kumar
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

2014-09-23 Thread Ajay kumar
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

2014-09-22 Thread Ajay kumar
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

2014-09-22 Thread Ajay kumar
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

2014-09-22 Thread Ajay kumar
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

2014-09-22 Thread Ajay kumar
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

2014-09-20 Thread Ajay kumar
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

2014-09-20 Thread Ajay kumar
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

2014-09-19 Thread Ajay kumar
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

2014-09-17 Thread Ajay kumar
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

2014-09-17 Thread Ajay kumar
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

2014-09-17 Thread Ajay kumar
Hi Laurent,

Please find the latest series here:
http://www.spinics.net/lists/dri-devel/msg66740.html

On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart
laurent.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

2014-09-17 Thread Ajay kumar
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

2014-09-17 Thread Ajay kumar
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

2014-09-17 Thread Ajay kumar
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

2014-09-13 Thread Ajay kumar
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

2014-09-10 Thread Ajay kumar
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

2014-09-05 Thread Ajay kumar
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

2014-09-05 Thread Ajay kumar
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

2014-09-01 Thread Ajay Kumar
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

2014-09-01 Thread Ajay Kumar
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


  1   2   3   4   5   >