Please accept my invitation to join Bangaloreans with OCD - Meetup

[Ajay Kumar]

Bangaloreans with OCD - Meetup


Join Ajay Kumar in Bangalore. Be the first to hear about upcoming Meetups.

Hello All,
This is Ajay from Bangalore.I have OCD when it comes to hygiene, decision 
making, relationships, etc.People often think of me as weird, and even I find 
it difficult to adjust to others ofte...

--

Accept invitation

https://secure.meetup.com/n/?s=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkZXN0IjoiaHR0cHM6Ly9zZWN1cmUubWVldHVwLmNvbS9yZWdpc3Rlci8_Z2o9ZWo0cyZjPTE5NzE0MjE4Jl94dGQ9Z3F0bGJXRnBiRjlqYkdsamE5b0FKRGMyWkdRd04yTTVMV0U1TXpZdE5HVmlaQzA0TTJabExUUmhOV05pTTJWaFlUTTFOYXBwYm5acGRHVmxYMmxrcHpZMk5EVXhNRFkmcmc9ZWo0cyZjdHg9aW52JnRhcmdldFVyaT1odHRwJTNBJTJGJTJGd3d3Lm1lZXR1cC5jb20lMkZCYW5nYWxvcmVhbnMtd2l0aC1PQ0QtTWVldHVwJTJGJTNGZ2olM0RlajRzJTI2cmclM0RlajRzIiwiaG9vayI6ImludiIsImVtYWlsX2ludml0ZWVfaWQiOjY2NDUxMDYsImV4cCI6MTQ1OTI4NzEyNSwiaWF0IjoxNDU4MDc3NTI1LCJqdGkiOiI1YmM4MjE4NS1kZGJkLTQwMTctYjg0MC05YmE3YTM0ZDkxYmQifQ%3D%3D.7ME_tgTXdELjJ7HHiS7Z6qFoRYnFRWvdDYIvYmIwBTM%3D

--

---
This message was sent by Meetup on behalf of Ajay Kumar 
(http://www.meetup.com/Bangaloreans-with-OCD-Meetup/members/191236630/) from 
Bangaloreans with OCD - Meetup.


Questions? You can email Meetup Support at support at meetup.com

Unsubscribe 
(https://secure.meetup.com/n/?s=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJob29rIjoiaW52X29wdG91dCIsImRlc3QiOiJodHRwOi8vd3d3Lm1lZXR1cC5jb20vYWNjb3VudC9vcHRvdXQvP3N1Ym1pdD10cnVlJmVvPXRjMiZlbWFpbD1pbnZpdGUmX21zX3Vuc3ViPXRydWUiLCJlbWFpbCI6ImRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmciLCJpbnZpdGVyX2lkIjoxOTEyMzY2MzAsImV4cCI6MTQ1OTI4NzEyNSwiaWF0IjoxNDU4MDc3NTI1LCJqdGkiOiIzOTZhMTUyYi0zNDk0LTQ0ZGUtYTRlOC03MmI2ZDQ5ODdiNWMifQ%3D%3D.dd5N-5eSYNlxeRMP8nAO5G2n4_4epL45UMEaeq2b2bU%3D)
 from this type of email.

Meetup Inc. (http://www.meetup.com/), POB 4668 #37895 New York NY USA 10163
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/87b68988/attachment.html>

[RFC PATCH 0/8] Add Analogix Core Display Port Driver

[Ajay kumar]

+Sean

On Thursday, August 6, 2015, Yakir Yang  wrote:

> Jingoo,
>
> 在 2015/8/6 22:41, Jingoo Han 写道:
>
>> On Thursday, August 06, 2015 10:49 PM, Yakir Yang wrote:
>>
>>> Hi all,
>>> Samsung exynos and Rockchip rk3288 almost share same dp controller,
>>> so I split the common code out, then rk3288 and exynos can re-used the
>>> same dp core driver. Cause I can't find the exact IP name of exynos dp
>>> controller, so I decide to name dp core driver with "analogix" which I
>>> find in rk3288 eDP TRM ;)
>>>
>>
>> OK, I see.
>> The Samsung Exynos eDP contoller and Rockchip rk3288 eDP contoller share
>> the same IP. So, a lot of parts can be re-used. I agree with this.
>> However, we have to review the code carefully, as others did.
>>
> Yeah, feel happy to be reviewed  ;)
>
> I also cannot find the exact IP name. The "analogix" may be the vendor name
>> of this IP.
>>
> Okay, so "analogix" is okay for now
>
> Thanks,
> - Yakir
>
>> Best regards,
>> Jingoo Han
>>
>> Beyond that, there are three light registers setting differents bewteen
>>> exynos and rk3288.
>>> 1. RK3288 have five special pll resigters which not indicata in exynos
>>> dp controller.
>>> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>>> between rk3288 and exynos.
>>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
>>> debug
>>> register).
>>>
>>> My series patches can be divider into two parts: One for spliting the
>>> analogix_dp code from exynos dp driver. Another are trying to add rk3288
>>> dp driver support.
>>>
>>> Best regards,
>>> - Yakir
>>>
>>>
>>> --
>>> 2.1.2
>>>
>>
>>
>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[Ajay kumar]

On Wed, Mar 4, 2015 at 7:44 PM, Andrzej Hajda  wrote:
> On 03/02/2015 11:57 AM, Ajay kumar wrote:
>> On Mon, Mar 2, 2015 at 1:38 PM, Andrzej Hajda  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 
>>>> ---
>>>>  .../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)
&

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

[Ajay kumar]

On Wed, Mar 4, 2015 at 4:02 PM, Andrzej Hajda  wrote:
> On 03/04/2015 10:54 AM, Ajay kumar wrote:
>> On Wed, Mar 4, 2015 at 2:30 PM, Andrzej Hajda  wrote:
>>> On 03/02/2015 09:40 AM, Ajay kumar wrote:
>>>> Hi Andrej,
>>>>
>>>> On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda  
>>>> 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 
>>>>>> ---
>>>>>>  .../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_PIXE

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

[Ajay kumar]

On Wed, Mar 4, 2015 at 2:30 PM, Andrzej Hajda  wrote:
> On 03/02/2015 09:40 AM, Ajay kumar wrote:
>> Hi Andrej,
>>
>> On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda  
>> 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 
>>>> ---
>>>>  .../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

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

[Ajay kumar]

On Mon, Mar 2, 2015 at 1:38 PM, Andrzej Hajda  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 
>> ---
>>  .../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 happen

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

[Ajay kumar]

Hi Andrej,

On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda  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 
>> ---
>>  .../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
&g

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

[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 
---
 .../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 = _decon_int_driver_data },
+   { .compatible = "samsung,exynos7-decon-ext",
+ .data = _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, >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_48

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

[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 
---
 .../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, 

[PATCH V4] drm/exynos: Add DECON driver

[Ajay kumar]

ping.

On Thu, Feb 5, 2015 at 9:24 PM, Ajay Kumar  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 
> Signed-off-by: Ajay Kumar 
> ---
> 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 at 1393 {
> +   compatible = "samsung,exynos7-decon";
> +   interrupt-parent = <>;
> +   reg = <0x1393 0x1000>;
> +   interrupt-names = "lcd_sys", "vsync", "fifo";
> +   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
> +   clocks = <_disp PCLK_DECON_INT>,
> +   

[PATCH V4] drm/exynos: Add DECON driver

[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 
Signed-off-by: Ajay Kumar 
---
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 at 1393 {
+   compatible = "samsung,exynos7-decon";
+   interrupt-parent = <>;
+   reg = <0x1393 0x1000>;
+   interrupt-names = "lcd_sys", "vsync", "fifo";
+   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
+   clocks = <_disp PCLK_DECON_INT>,
+<_disp ACLK_DECON_INT>,
+<_disp SCLK_DECON_INT_ECLK>,
+<_disp SCLK_DECON_INT_EXTCLKPLL>;
+   clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
+   "decon0_vclk";
+   status = "disabled";
+   };
+
+Board specific DT entry:
+
+   decon at 1393 {
+   pinctrl-0 = <_clk _out>;
+   pinctrl-names = "default";
+   status = &quo

[PATCH V3] drm/exynos: Add DECON driver

[Ajay kumar]

Hi Inki,

On Mon, Dec 8, 2014 at 7:09 PM, Inki Dae  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 
>> Signed-off-by: Ajay Kumar 
>> ---
>> 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]: Document

[PATCH 03/14] drm/bridge: make bridge registration independent of drm flow

[Ajay kumar]

Hi,

On Fri, Jan 30, 2015 at 9:29 PM, Russell King - ARM Linux
 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  
>> 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-next=b5217bf4692218d202d3d2cd772864fa1e10be4d

Regards,
Ajay Kumar

[PATCH 03/14] drm/bridge: make bridge registration independent of drm flow

[Ajay kumar]

Hi Rob,

On Fri, Jan 30, 2015 at 9:07 PM, Rob Clark  wrote:
> On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar  
> 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-next=b5217bf4692218d202d3d2cd772864fa1e10be4d

Regards,
Ajay Kumar
> since what is there now at least doesn't look right..
>
> BR,
> -R
>
>
>
>> Signed-off-by: Ajay Kumar 
>> Acked-by: Inki Dae 
>> Tested-by: Rahul Sharma 
>> Tested-by: Javier Martinez Canillas 
>> Tested-by: Gustavo Padovan 
>> Tested-by: Sjoerd Simons 
>> ---
>>  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
>>
>>  dr

[PATCH V9 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge

[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  
wrote:
> From: Vincent Palatin 
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Sean Paul 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> Acked-by: Inki Dae 
> Tested-by: Rahul Sharma 
> Tested-by: Javier Martinez Canillas 
> Tested-by: Gustavo Padovan 
> Tested-by: Sjoerd Simons 
> ---
>  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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#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[

[PATCH V9 04/14] drm/bridge: ptn3460: Convert to i2c driver model

[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  wrote:
> Hi Ajay,
>
> 2015-01-20 Ajay Kumar :
>
>> Use drm_bridge helpers to modify the driver to support
>> i2c driver model.
>>
>> Signed-off-by: Ajay Kumar 
>> Acked-by: Inki Dae 
>> Tested-by: Rahul Sharma 
>> Tested-by: Javier Martinez Canillas 
>> Tested-by: Gustavo Padovan 
>> Tested-by: Sjoerd Simons 
>> ---
>>  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 
> 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 
> Signed-off-by: Dave Airlie 
>
>
> 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

[PATCH] drm/bridge: sti_dvo: adapt to updated bridge API

[Ajay Kumar]

Commits 8eb17f05bc1802b50f8b536406357b87f63cf61d
("drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init") and
fbc4572e9c48e45bdfeb2ee8c8f0198b3e70c030
("drm/bridge: make bridge registration independent of drm flow")
changed the bridge API without taking into account sti_dvo bridge
which caused the following build breakage on linux-next:

drivers/gpu/drm/sti/sti_dvo.c: In function ‘sti_dvo_brigde_destroy’:
drivers/gpu/drm/sti/sti_dvo.c:277:2: error: implicit declaration of function 
‘drm_bridge_cleanup’
drivers/gpu/drm/sti/sti_dvo.c: At top level:
drivers/gpu/drm/sti/sti_dvo.c:287:2: error: unknown field ‘destroy’ 
specified in initializer
drivers/gpu/drm/sti/sti_dvo.c: In function ‘sti_dvo_bind’:
drivers/gpu/drm/sti/sti_dvo.c:419:2: error: implicit declaration of function 
‘drm_bridge_init’

Make the necessary changes to sti_dvo bridge in order to fix the build breakage.

Signed-off-by: Ajay Kumar 
---
This patch contains the minimal changes needed instead of having this:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=384764c3611645d96889742a079168c86a6fc4c4

 drivers/gpu/drm/sti/sti_dvo.c |   11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 651afad..1088fc5 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -272,19 +272,12 @@ static void sti_dvo_bridge_nope(struct drm_bridge *bridge)
/* do nothing */
 }

-static void sti_dvo_brigde_destroy(struct drm_bridge *bridge)
-{
-   drm_bridge_cleanup(bridge);
-   kfree(bridge);
-}
-
 static const struct drm_bridge_funcs sti_dvo_bridge_funcs = {
.pre_enable = sti_dvo_pre_enable,
.enable = sti_dvo_bridge_nope,
.disable = sti_dvo_disable,
.post_disable = sti_dvo_bridge_nope,
.mode_set = sti_dvo_set_mode,
-   .destroy = sti_dvo_brigde_destroy,
 };

 static int sti_dvo_connector_get_modes(struct drm_connector *connector)
@@ -416,7 +409,8 @@ static int sti_dvo_bind(struct device *dev, struct device 
*master, void *data)
return -ENOMEM;

bridge->driver_private = dvo;
-   drm_bridge_init(drm_dev, bridge, _dvo_bridge_funcs);
+   bridge->funcs = _dvo_bridge_funcs;
+   drm_bridge_attach(drm_dev, bridge);

encoder->bridge = bridge;
connector->encoder = encoder;
@@ -446,7 +440,6 @@ static int sti_dvo_bind(struct device *dev, struct device 
*master, void *data)
 err_sysfs:
drm_connector_unregister(drm_connector);
 err_connector:
-   drm_bridge_cleanup(bridge);
drm_connector_cleanup(drm_connector);
return -EINVAL;
 }
-- 
1.7.9.5

[PATCH V9 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints

[Ajay kumar]

Hi Kukjin,

On Fri, Jan 23, 2015 at 12:31 PM, Kukjin Kim  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 
>> Acked-by: Inki Dae 
>> Tested-by: Rahul Sharma 
>> Tested-by: Javier Martinez Canillas 
>> Tested-by: Gustavo Padovan 
>> Tested-by: Sjoerd Simons 
>> ---
>>  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 = < 5 GPIO_ACTIVE_HIGH>;
>>   reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
>>   edid-emulation = <5>;
>> - panel = <>;
>> +
>> + ports {
>> + port at 0 {
>> + bridge_out: endpoint {
>> + remote-endpoint = <_in>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + bridge_in: endpoint {
>> + remote-endpoint = <_out>;
>> + };
>> + };
>> + };
>>   };
>>   };
>>
>> @@ -228,6 +241,12 @@
>>   compatible = "auo,b116xw03";
>>   power-supply = <>;
>>   backlight = <>;
>> +
>> + port {
>> + panel_in: endpoint {
>> + remote-endpoint = <_out>;
>> + };
>> + };
>>   };
>>  };
>>
>> @@ -242,7 +261,14 @@
>>   samsung,link-rate = <0x0a>;
>>   samsung,lane-count = <2>;
>>   samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
>> - bridge = <>;
>> +
>> + ports {
>> + port at 0 {
>> + dp_out: endpoint {
>> + remote-endpoint = <_in>;
>> + };
>> + };
>> + };
>>  };
>>
>>   {
>> --
>> 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

[PATCH V9 14/14] ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints

[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 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 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 = <_fet6>;
backlight = <>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
};
 };

@@ -137,7 +143,14 @@
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 6 0>;
-   bridge = <>;
+
+   ports {
+   port at 0 {
+   dp_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
 };

  {
@@ -595,8 +608,22 @@
sleep-gpios = < 5 GPIO_ACTIVE_HIGH>;
reset-gpios = < 7 GPIO_ACTIVE_HIGH>;
lane-count = <2>;
-   panel = <>;
use-external-pwm;
+
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+
+   port at 1 {
+   bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
};
 };

-- 
1.7.9.5

[PATCH V9 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints

[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 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 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 = < 5 GPIO_ACTIVE_HIGH>;
reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
edid-emulation = <5>;
-   panel = <>;
+
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+
+   port at 1 {
+   bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
};
};

@@ -228,6 +241,12 @@
compatible = "auo,b116xw03";
power-supply = <>;
backlight = <>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
};
 };

@@ -242,7 +261,14 @@
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
-   bridge = <>;
+
+   ports {
+   port at 0 {
+   dp_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
 };

  {
-- 
1.7.9.5

[PATCH V9 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge

[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 
Signed-off-by: Andrew Bresticker 
Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
Signed-off-by: Ajay Kumar 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#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, , 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);
+   if (err)
+   goto error;
+
+   /* RCO 

[PATCH V9 11/14] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay Kumar]

Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.

Signed-off-by: Ajay Kumar 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 .../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 at 48 {
+   compatible = "parade,ps8622";
+   reg = <0x48>;
+   sleep-gpios = < 6 1 0 0>;
+   reset-gpios = < 1 1 0 0>;
+   lane-count = <1>;
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH V9 10/14] Documentation: devicetree: Add vendor prefix for parade

[Ajay Kumar]

ps8622 eDP-LVDS converter bridge chip is from parade technologies

Signed-off-by: Ajay Kumar 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 .../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

[PATCH V9 09/14] Documentation: drm: bridge: move to video/bridge

[Ajay Kumar]

Move drm/bridge documentation to video/bridge.
Also, add proper documentation for gpios used by ptn3460.

Signed-off-by: Ajay Kumar 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 .../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 at 20 {
-   compatible = "nxp,ptn3460";
-   reg = <0x20>;
-   powerdown-gpio = < 5 1 0 0>;
-   reset-gpio = < 5 1 0 0>;
-   edid-emulation = <5>;
-   ports {
-   port at 0 {
-   bridge_out: endpoint {
-   remote-endpoint = <_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 at 20 {
+   compatible = "nxp,ptn3460";
+   reg = <0x20>;
+   powerdown-gpio = < 5 1 0 0>;
+   reset-gpio = < 5 1 0 0>;
+   edid-emulation = <5>;
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH V9 08/14] drm/bridge: ptn3460: use gpiod interface

[Ajay Kumar]

Modify driver to support gpiod interface.

Signed-off-by: Ajay Kumar 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 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(>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(>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",
_bridge->edid_emulation);
if (ret) {
dev_err(dev, "Can't read EDID emulation value\n");
-   goto err

[PATCH V9 07/14] drm/bridge: ptn3460: probe connector at the end of bridge attach

[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 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 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, _bridge->connector,
_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, _bridge->connector);

+   drm_helper_hpd_irq_event(ptn_bridge->connector.dev);
+
return ret;
 }

-- 
1.7.9.5

[PATCH V9 06/14] drm/bridge: ptn3460: support drm_panel

[Ajay Kumar]

Add drm_panel calls to the driver to make the panel and
bridge work together in tandem.

Signed-off-by: Ajay Kumar 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 .../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 at 20 {
compatible = "nxp,ptn3460";
@@ -24,4 +29,11 @@ Example:
powerdown-gpio = < 5 1 0 0>;
reset-gpio = < 5 1 0 0>;
edid-emulation = <5>;
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_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 
 #include 
 #include 
+#include 
+
+#include 

 #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(_bridge->connector,
bridge->encoder);

+   if (ptn_bridge->panel)
+   drm_panel_attach(ptn_bridge->panel, _bridge->connector);
+
return ret;
 }

@@ -283,6 +312,7 @@ static int ptn3460_probe(struct i2c_client *client,
 {
struct device *dev = >dev;
struct ptn3460_bridge *ptn_bridge;
+   struct device_node *endpoint, *panel_node;
int ret;

ptn_bridge = devm_kzalloc(dev, siz

[PATCH V9 05/14] drm/exynos: dp: support drm_bridge

[Ajay Kumar]

Modify driver to support drm_bridge.

Signed-off-by: Ajay Kumar 
Signed-off-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 .../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 at 0 {
+   dp_out: endpoint {
+   remote-endpoint = <_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 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -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 = >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(>dev, _dp_ops);
if (ret)
exynos_drm_component_del(>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 drm_encoder  *encoder;
struct drm_panel*panel;
+   struct drm_bridge   *bridge;
struct clk  *clock;
unsigned intirq;
void __iomem*reg_base;
-- 
1.7.9.5

[PATCH V9 04/14] drm/bridge: ptn3460: Convert to i2c driver model

[Ajay Kumar]

Use drm_bridge helpers to modify the driver to support
i2c driver model.

Signed-off-by: Ajay Kumar 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 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, _bridge->connector,
+   _connector_funcs, DRM_MODE_CONNECTOR_LVDS);
+   if (ret) {
+   DRM_ERROR("Failed to initialize connector with drm\n");
+   return ret;
+   }
+   drm_connector_helper_add(_bridge->connector,
+   _connector_helper_funcs);
+   drm_connector_register(_bridge->connector);
+   drm_mode_connector_attach_encoder(_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 = >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(>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 03/14] drm/bridge: make bridge registration independent of drm flow

[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 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 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 = _bridge_funcs;
-   ret = drm_bridge_init(dev, _bridge->bridge);
+   ret = drm_bridge_attach(dev, _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 allocat

[PATCH V9 02/14] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init

[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 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 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, _bridge->bridge, _bridge_funcs);
+   ptn_bridge->bridge.funcs = _bridge_funcs;
+   ret = drm_bridge_init(dev, _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(>head, >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 = _bridge->base;
+   bridge->funcs = _bridge_funcs;

-   drm_bridge_init(hdmi->dev, bridge, _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, _hda_bridge_funcs);
+   bridge->funcs = _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, _hdmi_bridge_funcs);
+   bridge->funcs = _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 *bridge);
 extern void drm_bridge_cleanup(struct drm_bridge *bridge);

 extern int drm_encoder_init(struct drm_device *dev,
-- 
1.7.9.5

[PATCH V9 01/14] drm/bridge: ptn3460: Few trivial cleanups

[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 
Acked-by: Inki Dae 
Tested-by: Rahul Sharma 
Tested-by: Javier Martinez Canillas 
Tested-by: Gustavo Padovan 
Tested-by: Sjoerd Simons 
---
 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 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 

-#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 t

[PATCH V9 00/14] drm/exynos: few patches to enhance bridge chip support

[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 V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

On Mon, Jan 19, 2015 at 10:35 PM, Javier Martinez Canillas
 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 
>
>> 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

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

Hi Daniel,

This series is sitting out there since long without any ACKs.
If people can ACK this series, I am ready to rebase and send ASAP.

Regards,
Ajay Kumar

On Fri, Jan 2, 2015 at 6:40 PM, Daniel Stone  wrote:
> Hi Ajay,
>
> On 17 December 2014 at 09:31, Javier Martinez Canillas
>  wrote:
>>
>> On 12/16/2014 12:37 AM, Laurent Pinchart wrote:
>> >> You asked Ajay to change his series to use the video port and enpoints
>> >> DT
>> >> bindings instead of phandles, could you please review his latest
>> >> version?
>> >>
>> >> I guess is now too late for 3.19 since we are in the middle of the
>> >> merge
>> >> window but it would be great if this series can at least made it to
>> >> 3.20.
>> >
>> > I don't have time to review the series in details right now, but I'm
>> > happy
>> > with the DT bindings, and have no big issue with the rest of the
>> > patches. I
>> > don't really like the of_drm_find_bridge() concept introduced in 03/14
>> > but I
>> > won't nack it given lack of time to implement an alternative proposal.
>> > It's an
>> > internal API, it can always be reworked later anyway.
>>
>> Thanks a lot for taking the time to look at the DT bindings, then I guess
>> that the series are finally ready to be merged?
>>
>> Ajay's series don't apply cleanly anymore because it has been a while
>> since
>> he posted it but he can rebase on top of 3.19-rc1 once it is released and
>> re-resend.
>
>
> Do you have any plans to rebase this so it's ready for merging?
>
> Thierry, Daniel, Dave - whose tree would this be best to merge through?
>
> Cheers,
> Daniel

[PATCH V8 03/14] drm/bridge: make bridge registration independent of drm flow

[Ajay kumar]

On Tue, Dec 2, 2014 at 11:31 AM, Ajay kumar  wrote:
> On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar  
> 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 
>> ---
>>  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 dr

[PATCH V3] drm/exynos: Add DECON driver

[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 
Signed-off-by: Ajay Kumar 
---
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 at 1393 {
+   compatible = "samsung,exynos7-decon";
+   interrupt-parent = <>;
+   reg = <0x1393 0x1000>;
+   interrupt-names = "lcd_sys", "vsync", "fifo";
+   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
+   clocks = <_disp PCLK_DECON_INT>,
+<_disp ACLK_DECON_INT>,
+<_disp SCLK_DECON_INT_ECLK>,
+<_disp SCLK_DECON_INT_EXTCLKPLL>;
+   clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
+   "decon0_vclk";
+   status = "disabled";
+   };
+
+Board specific DT entry:
+
+   decon at 1393 {
+   pinctrl-0 = <_clk _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 

[PATCH 2/2] drm/exynos: fimd: check error status for drm_iommu_attach_device

[Ajay Kumar]

check error status for drm_iommu_attach_device() and make sure
it propagates till the caller.

Signed-off-by: Ajay Kumar 
---
 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(>manager, drm_dev);
+   if (ret) {
+   DRM_ERROR("fimd_mgr_initialize failed.\n");
+   return ret;
+   }

-   fimd_mgr_initialize(>manager, drm_dev);
exynos_drm_crtc_create(>manager);
if (ctx->display)
exynos_drm_create_enc_conn(drm_dev, ctx->display);
-- 
1.7.9.5

[PATCH 1/2] drm/exynos: fimd: Remove drm_dev and pipe members from fimd_context

[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 
---
 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, >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(>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(>wait_vsync_event)) {
-- 
1.7.9.5

[PATCH V2] drm/exynos: Add DECON driver

[Ajay kumar]

Hi Pankaj,

On Mon, Dec 1, 2014 at 1:36 PM, Pankaj Dubey  
wrote:
> Hi Ajay,
>
> On 28 November 2014 at 16:45, 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 
>> Signed-off-by: Ajay Kumar 
>> ---
>> 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 = >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 l

[PATCH V8 03/14] drm/bridge: make bridge registration independent of drm flow

[Ajay kumar]

On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar  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 
> ---
>  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 = _bridge_funcs;
> -   ret = drm_bridge_init(dev, _bridge->bridge);
> +   ret = drm_bridge_attach(dev, _bridge->bridge);
> if (ret) {
> DRM_ERROR("Failed to initialize bridge with drm\n");
> goto err;
> @@ -343,3 +330,15 @@ err:
> return ret;
>  }
>  EXPOR

[PATCH V2] drm/exynos: Add DECON driver

[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 
Signed-off-by: Ajay Kumar 
---
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 at 1393 {
+   compatible = "samsung,exynos7-decon";
+   interrupt-parent = <>;
+   reg = <0x1393 0x1000>;
+   interrupt-names = "lcd_sys", "vsync", "fifo";
+   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
+   clocks = <_disp PCLK_DECON_INT>,
+<_disp ACLK_DECON_INT>,
+<_disp SCLK_DECON_INT_ECLK>,
+<_disp SCLK_DECON_INT_EXTCLKPLL>;
+   clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
+   "decon0_vclk";
+   status = "disabled";
+   };
+
+Board specific DT entry:
+
+   decon at 1393 {
+   pinctrl-0 = <_clk _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

[PATCH 2/2] drm/exynos: fimd: check error status for drm_iommu_attach_device

[Ajay Kumar]

check error status for drm_iommu_attach_device() and make sure
it propagates till the caller.

Signed-off-by: Ajay Kumar 
---
 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(>manager, drm_dev);
+   if (ret) {
+   DRM_ERROR("fimd_mgr_initialize failed.\n");
+   return ret;
+   }

-   fimd_mgr_initialize(>manager, drm_dev);
exynos_drm_crtc_create(>manager);
if (ctx->display)
exynos_drm_create_enc_conn(drm_dev, ctx->display);
-- 
1.7.9.5

[PATCH 1/2] drm/exynos: fimd: Remove drm_dev pointer from fimd_context

[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 
---
 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, >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(>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(>wait_vsync_event)) {
-- 
1.7.9.5

[PATCH] drm/exynos: Add DECON driver

[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  
wrote:
> Hi Ajay,
>
> On 27 November 2014 at 19:41, 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 
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../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 at 1393 {
>> +   compatible = "samsung,exynos7-decon";
>> +   interrupt-parent = <>;
>> +   reg = <0x1393 0x1000>;
>> +   interrupt-names = "lcd_sys", "vsync", "fifo";
>> +   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
>> +   clocks = <_disp PCLK_DECON_INT>,
>> +<_disp ACLK_DECON_INT>,
>> +<_disp SCLK_DECON_INT_ECLK>,
>> +  

[PATCH] drm/exynos: Add DECON driver

[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 
Signed-off-by: Ajay Kumar 
---
 .../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 at 1393 {
+   compatible = "samsung,exynos7-decon";
+   interrupt-parent = <>;
+   reg = <0x1393 0x1000>;
+   interrupt-names = "lcd_sys", "vsync", "fifo";
+   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
+   clocks = <_disp PCLK_DECON_INT>,
+<_disp ACLK_DECON_INT>,
+<_disp SCLK_DECON_INT_ECLK>,
+<_disp SCLK_DECON_INT_EXTCLKPLL>;
+   clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
+   "decon0_vclk";
+   status = "disabled";
+   };
+
+Board specific DT entry:
+
+   decon at 1393 {
+   pinctrl-0 = <_clk _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 &qu

[RFC PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

On Tue, Nov 25, 2014 at 6:59 PM, Inki Dae  wrote:
> On 2014년 11월 25일 22:08, Ajay kumar wrote:
>> Hi Inki,
>>
>> On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae  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  wrote:
>>>>> Hi Inki,
>>>>>
>>>>> On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae  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  
>>>>>>> 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.
&

[RFC PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

Hi Inki,

On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae  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  wrote:
>>> Hi Inki,
>>>
>>> On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae  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  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 
>>>>>>> Signed-off-by: Ajay Kumar 
>>>>>>> ---
>>>>>>>  .../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 +++
>>>>>

[RFC PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

ping.

On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar  wrote:
> Hi Inki,
>
> On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae  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  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 
>>>>> Signed-off-by: Ajay Kumar 
>>>>> ---
>>>>>  .../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

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Ajay kumar]

Hi Andreas,

On Mon, Nov 24, 2014 at 8:35 PM, Andreas Färber  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

[PATCH 1/3] drm/exynos: free DP if probe fails to find a panel or bridge

[Ajay kumar]

Hi Gustavo,


On Fri, Nov 21, 2014 at 5:24 AM, Gustavo Padovan  wrote:
> From: Gustavo Padovan 
>
> DP was leaked everytime function returns EPROBE_DEFER, free it before
> returning.
>
> Signed-off-by: Gustavo Padovan 
> ---
>  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(>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 majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[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  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 majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- next part --
A non-text attachment was scrubbed...
Name: Tot.tar.bz2
Type: application/x-bzip2
Size: 20037 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/67f5f5a4/attachment-0001.bin>

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[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
 wrote:
> Hello Ajay,
>
> On 11/18/2014 07:20 AM, Ajay kumar wrote:
>> On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar  
>> 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

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar  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):
&g

[PATCH V8 14/14] ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints

[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 
---
 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 = <_fet6>;
backlight = <>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
};
 };

@@ -126,7 +132,14 @@
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 6 0>;
-   bridge = <>;
+
+   ports {
+   port at 0 {
+   dp_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
 };

  {
@@ -504,8 +517,22 @@
sleep-gpios = < 5 GPIO_ACTIVE_HIGH>;
reset-gpios = < 7 GPIO_ACTIVE_HIGH>;
lane-count = <2>;
-   panel = <>;
use-external-pwm;
+
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+
+   port at 1 {
+   bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
};
 };

-- 
1.7.9.5

[PATCH V8 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints

[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 
---
 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 = < 5 GPIO_ACTIVE_HIGH>;
reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
edid-emulation = <5>;
-   panel = <>;
+
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+
+   port at 1 {
+   bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
};
};

@@ -328,6 +341,12 @@
compatible = "auo,b116xw03";
power-supply = <>;
backlight = <>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
};

dp-controller at 145B {
@@ -341,7 +360,14 @@
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 7 0>;
-   bridge = <>;
+
+   ports {
+   port at 0 {
+   dp_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
};
 };

-- 
1.7.9.5

[PATCH V8 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge

[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 
Signed-off-by: Andrew Bresticker 
Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
Signed-off-by: Ajay Kumar 
---
 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#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, , 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);
+   if (err)
+   goto error;
+
+   /* RCO SS setting: [5:4] = b01 0.5%, b10 1%, b11 1.5% */
+   err = ps8622_set(cl, 0x04, 0xe3, 0x20);
+   if (err)
+   go

[PATCH V8 11/14] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay Kumar]

Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.

Signed-off-by: Ajay Kumar 
---
 .../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 at 48 {
+   compatible = "parade,ps8622";
+   reg = <0x48>;
+   sleep-gpios = < 6 1 0 0>;
+   reset-gpios = < 1 1 0 0>;
+   lane-count = <1>;
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH V8 10/14] Documentation: devicetree: Add vendor prefix for parade

[Ajay Kumar]

ps8622 eDP-LVDS converter bridge chip is from parade technologies

Signed-off-by: Ajay Kumar 
---
 .../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

[PATCH V8 09/14] Documentation: drm: bridge: move to video/bridge

[Ajay Kumar]

Move drm/bridge documentation to video/bridge.
Also, add proper documentation for gpios used by ptn3460.

Signed-off-by: Ajay Kumar 
---
 .../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 at 20 {
-   compatible = "nxp,ptn3460";
-   reg = <0x20>;
-   powerdown-gpio = < 5 1 0 0>;
-   reset-gpio = < 5 1 0 0>;
-   edid-emulation = <5>;
-   ports {
-   port at 0 {
-   bridge_out: endpoint {
-   remote-endpoint = <_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 at 20 {
+   compatible = "nxp,ptn3460";
+   reg = <0x20>;
+   powerdown-gpio = < 5 1 0 0>;
+   reset-gpio = < 5 1 0 0>;
+   edid-emulation = <5>;
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH V8 08/14] drm/bridge: ptn3460: use gpiod interface

[Ajay Kumar]

Modify driver to support gpiod interface.

Signed-off-by: Ajay Kumar 
---
 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(>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(>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",
_bridge->edid_emulation);
if (ret) {
dev_err(dev, "Can't read EDID emulation value\n");
-   goto err;
+   return ret;
}

ptn_bridge->bridge.funcs = _bridge_funcs;
@@ -375,19 +371,12 @@ static int ptn

[PATCH V8 07/14] drm/bridge: ptn3460: probe connector at the end of bridge attach

[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 
---
 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, _bridge->connector,
_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, _bridge->connector);

+   drm_helper_hpd_irq_event(ptn_bridge->connector.dev);
+
return ret;
 }

-- 
1.7.9.5

[PATCH V8 06/14] drm/bridge: ptn3460: support drm_panel

[Ajay Kumar]

Add drm_panel calls to the driver to make the panel and
bridge work together in tandem.

Signed-off-by: Ajay Kumar 
---
 .../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 at 20 {
compatible = "nxp,ptn3460";
@@ -24,4 +29,11 @@ Example:
powerdown-gpio = < 5 1 0 0>;
reset-gpio = < 5 1 0 0>;
edid-emulation = <5>;
+   ports {
+   port at 0 {
+   bridge_out: endpoint {
+   remote-endpoint = <_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 
 #include 
 #include 
+#include 
+
+#include 

 #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(_bridge->connector,
bridge->encoder);

+   if (ptn_bridge->panel)
+   drm_panel_attach(ptn_bridge->panel, _bridge->connector);
+
return ret;
 }

@@ -283,6 +312,7 @@ static int ptn3460_probe(struct i2c_client *client,
 {
struct device *dev = >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 -EN

[PATCH V8 05/14] drm/exynos: dp: support drm_bridge

[Ajay Kumar]

Modify driver to support drm_bridge.

Signed-off-by: Ajay Kumar 
---
 .../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 at 0 {
+   dp_out: endpoint {
+   remote-endpoint = <_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 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -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 = >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(>dev, _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

[PATCH V8 04/14] drm/bridge: ptn3460: Convert to i2c driver model

[Ajay Kumar]

Use drm_bridge helpers to modify the driver to support
i2c driver model.

Signed-off-by: Ajay Kumar 
---
 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, _bridge->connector,
+   _connector_funcs, DRM_MODE_CONNECTOR_LVDS);
+   if (ret) {
+   DRM_ERROR("Failed to initialize connector with drm\n");
+   return ret;
+   }
+   drm_connector_helper_add(_bridge->connector,
+   _connector_helper_funcs);
+   drm_connector_register(_bridge->connector);
+   drm_mode_connector_attach_encoder(_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 = >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(>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,
+   

[PATCH V8 03/14] drm/bridge: make bridge registration independent of drm flow

[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 
---
 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 = _bridge_funcs;
-   ret = drm_bridge_init(dev, _bridge->bridge);
+   ret = drm_bridge_attach(dev, _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..d1

[PATCH V8 02/14] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init

[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 
---
 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, _bridge->bridge, _bridge_funcs);
+   ptn_bridge->bridge.funcs = _bridge_funcs;
+   ret = drm_bridge_init(dev, _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(>head, >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 = _bridge->base;
+   bridge->funcs = _bridge_funcs;

-   drm_bridge_init(hdmi->dev, bridge, _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, _hda_bridge_funcs);
+   bridge->funcs = _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, _hdmi_bridge_funcs);
+   bridge->funcs = _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

[PATCH V8 01/14] drm/bridge: ptn3460: Few trivial cleanups

[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 
---
 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 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 

-#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_b

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[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

[RFC PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

Hi Inki,

On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae  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  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 
>>>> Signed-off-by: Ajay Kumar 
>>>> ---
>>>>  .../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
>>&g

[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

[Ajay kumar]

On Mon, Nov 3, 2014 at 1:31 PM, Thierry Reding  
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 dt_panel or dt_bridge.
>> > > Or maybe even acpi_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(_panels, >record);
>> > }
>> >
>> > struct drm_panel *of_drm_panel_find(struct device_node *np)
>> > {
>> > struct registry_record *record;
>> >
>> > record = registry_find_by_of_node(_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

[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

[Ajay kumar]

On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
 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  wrote:
>> > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter  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

[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

[Ajay kumar]

On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter  wrote:
> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar  wrote:
>> Hi Daniel and Sean,
>>
>> Thanks for the comments!
>>
>> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul  wrote:
>>> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter  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 quick 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 
>>>>
>>>> [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

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

On Tue, Oct 28, 2014 at 2:42 PM, Javier Martinez Canillas
 wrote:
> Hello Ajay,
>
> On Thu, Oct 16, 2014 at 11:04 AM, Laurent Pinchart
>  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

[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

[Ajay kumar]

On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul  wrote:
> On Wed, Aug 27, 2014 at 10:29 AM, 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 
>> ---
>>  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]

[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

[Ajay kumar]

On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul  wrote:
> On Wed, Aug 27, 2014 at 10:29 AM, 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 
>> ---
>>  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 
>>

[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

[Ajay kumar]

Hi Daniel and Sean,

Thanks for the comments!

On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul  wrote:
> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter  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 quick 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 
>>
>> [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

[RFC PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae  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 
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../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 

[RFC PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

ping!

On Fri, Oct 10, 2014 at 6:18 PM, 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 
> Signed-off-by: Ajay Kumar 
> ---
>  .../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 at 1393 {
> +   compatible = "samsung,exynos7-decon";
> +   interrupt-parent = <>;
> +   reg = <0x1393 0x1000>;
> +   interrupt-names = "lcd_sys", "vsync", "fifo";
> +   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
> +   clocks = <_disp PCLK_DECON_INT>,
> +<_disp ACLK_DECON_INT>,
> +<_disp SCLK_DECON_INT_ECLK>,
> +<_disp SCLK_DECON_INT_EXTCLKPLL>,
> +<_disp SCLK_DSD>,
> +<_bus0 ACLK_LH_DISP0>,
> +<_disp ACLK_CP_DISP>,
> +<_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:
> +
> +   dec

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

ping!

On Fri, Oct 10, 2014 at 6:33 PM, Ajay kumar  wrote:
> On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding
>  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

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding
 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

[RFC PATCH] drm/exynos: Add DECON driver

[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 
Signed-off-by: Ajay Kumar 
---
 .../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 at 1393 {
+   compatible = "samsung,exynos7-decon";
+   interrupt-parent = <>;
+   reg = <0x1393 0x1000>;
+   interrupt-names = "lcd_sys", "vsync", "fifo";
+   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
+   clocks = <_disp PCLK_DECON_INT>,
+<_disp ACLK_DECON_INT>,
+<_disp SCLK_DECON_INT_ECLK>,
+<_disp SCLK_DECON_INT_EXTCLKPLL>,
+<_disp SCLK_DSD>,
+<_bus0 ACLK_LH_DISP0>,
+<_disp ACLK_CP_DISP>,
+<_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 at 1393 {
+   pinctrl-0 = <_clk _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"
+   depend

[PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

[Ajay kumar]

On Thu, Oct 9, 2014 at 3:56 PM, Vivek Gautam  
wrote:
> Ajay,
>
>
> On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar  wrote:
>> Hi,
>>
>> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
>> 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 majordomo at 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 

Ajay

[PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

[Ajay kumar]

Hi,

On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
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 majordomo at 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.

Ajay

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

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!

Ajay

[PATCH] drm/exynos: remove ifdeferry from initialization code

[Ajay kumar]

On Wed, Oct 1, 2014 at 11:18 AM, Inki Dae  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 
>>> ---
>>> 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(_driver);
>>> -if (ret < 0)
>>> -return ret;
>>> +_driver,
>>>  #endif
>>> -
>>>  #ifdef CONFIG_DRM_EXYNOS_DP
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_fimd_drv;
>>> +_driver,
>>>  #endif
>>> -
>>>  #ifdef CONFIG_DRM_EXYNOS_DSI
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_dp_drv;
>>> +_driver,
>>>  #endif
>>> -
>>>  #ifdef CONFIG_DRM_EXYNOS_HDMI
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_dsi_drv;
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_mixer_drv;
>>> +_driver,
>>> +_driver,
>>>  #endif
>>> -
>>>  #ifdef CONFIG_DRM_EXYNOS_G2D
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_hdmi_drv;
>>> +_driver,
>>>  #endif
>>> -
>>>  #ifdef CONFIG_DRM_EXYNOS_FIMC
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_g2d_drv;
>>> +_driver,
>>>  #endif
>>> -
>>>  #ifdef CONFIG_DRM_EXYNOS_ROTATOR
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_fimc_drv;
>>> +_driver,
>>>  #endif
>>> -
>>>  #ifdef CONFIG_DRM_EXYNOS_GSC
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_rotator_drv;
>>> +_driver,
>>>  #endif
>>> -
>>>  #ifdef CONFIG_DRM_EXYNOS_IPP
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_gsc_drv;
>>> +_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();
>>>  

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

On Tue, Sep 23, 2014 at 11:25 AM, Thierry Reding
 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 
>> > > >> >> >>>> ---
>> > > >> >> >>>>
>> > > >> >> >>>>  .../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.
>>

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

On Mon, Sep 22, 2014 at 5:05 PM, 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:
>> >> Hi Thierry,
>> >>
>> >> 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:
>> >> >> Hi Tomi,
>> >> >>
>> >> >> On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen > >> >> 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 > >> >> >> 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 
>> >> >> >>>> ---
>> >> >> >>>>  .../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
>> >> > backlig

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

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:
>> Hi Thierry,
>>
>> 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:
>> >> Hi Tomi,
>> >>
>> >> On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen > >> 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 > >> >> 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 
>> >> >>>> ---
>> >> >>>>  .../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 

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

Hi Thierry,

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:
>> Hi Tomi,
>>
>> On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen  
>> 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 > >> 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 
>> >>>> ---
>> >>>>  .../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

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

On Sat, Sep 20, 2014 at 8:57 PM, Javier Martinez Canillas
 wrote:
> [adding Kukjin as cc]
>
> Hello Ajay,
>
> On Sat, Sep 20, 2014 at 1:22 PM, Ajay kumar  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 at 
> 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 majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

Hi,

On Wed, Sep 17, 2014 at 3:02 PM, Ajay kumar  wrote:
> On Tue, Sep 16, 2014 at 6:14 PM, Javier Martinez Canillas
>  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  
>> 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 
>>> Javier Martinez Canillas 
>>>
>>> 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

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

On Fri, Sep 19, 2014 at 7:58 PM, Tomi Valkeinen  
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
>
>

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

On Fri, Sep 19, 2014 at 6:24 PM, Tomi Valkeinen  
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
>
>

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

Hi Tomi,

On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen  
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  
>> 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 
>>>> ---
>>>>  .../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 at 48 {
>>>> + compatible = "parade,ps8622";
>>>> + reg = <0x48>;
>>>> + sleep-gpios = < 6 1 0 0>;
>>>> + reset-gpios = < 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

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

Hi Tomi,

Thanks for your comments.

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 
>> ---
>>  .../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 at 48 {
>> + compatible = "parade,ps8622";
>> + reg = <0x48>;
>> + sleep-gpios = < 6 1 0 0>;
>> + reset-gpios = < 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

[PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Ajay kumar]

On Wed, Sep 17, 2014 at 2:57 PM, Laurent Pinchart
 wrote:
> Hi Ajay,
>
> On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
>> On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
>> > Hi Ajay,
>> >
>> > Thank you for the patch.
>> >
>> > I think we're moving in the right direction, but we're not there yet.
>> >
>> > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
>> >> This patch tries to seperate drm_bridge implementation
>> >> into 2 parts, a drm part and a non_drm part.
>> >>
>> >> A set of helper functions are defined in this patch to make
>> >> bridge driver probe independent of the drm flow.
>> >>
>> >> The bridge devices register themselves on a lookup table
>> >> when they get probed by calling "drm_bridge_add_for_lookup".
>> >>
>> >> The parent encoder driver waits till the bridge is available in the
>> >> lookup table(by calling "of_drm_find_bridge") and then continues with
>> >> its initialization.
>> >
>> > Before the introduction of the component framework I would have said this
>> > is the way to go. Now, I think bridges should register themselves as
>> > components, and the DRM master driver should use the component framework
>> > to get a reference to the bridges it needs.
>>
>> Well, I have modified the bridge framework exactly the way Thierry wanted it
>> to be, I mean the same way the current panel framework is.
>> And, I don't think there is a problem with that.
>> What problem are you facing with current bridge implementation?
>> What is the advantage of using the component framework to register bridges?
>
> There are several advantages.
>
> - The component framework has been designed with this exact problem in mind,
> piecing multiple components into a display device. 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 

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[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
 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  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?= 
>> > >> >> 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 
>> > >> >> [AF: Redone for v6]
>> > >> >> Signed-off-by: Andreas F??rber 
>> > >> >> ---
>> > >> >>
>> > >> >>  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 = <_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.
>>

[PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

On Tue, Sep 16, 2014 at 6:14 PM, Javier Martinez Canillas
 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  
> 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 
>> Javier Martinez Canillas 
>>
>> 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

[PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Ajay kumar]

Hi Laurent,

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?

>> 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 
>> ---
>>  .../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
>