[PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY

[Heiko Stuebner]

Hi Yakir,

small nit more below

Am Dienstag, 1. September 2015, 18:51:16 schrieb Heiko Stuebner:
> Am Dienstag, 1. September 2015, 14:04:15 schrieb Yakir Yang:
> > +- clocks: from common clock binding: handle to dp clock.
> > +   of memory mapped region.
> > +- clock-names: from common clock binding:
> > +   Required elements: "sclk_dp" "sclk_dp_24m"
> > +
> > +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> > +- #phy-cells : from the generic PHY bindings, must be 0;
> > +
> > +Example:
> > +
> > +edp_phy: phy at ff770274 {
> 
> edp_phy: edp-phy {
> 
> > +   compatilble = "rockchip,rk3288-dp-phy";

typo: compatible

[PATCH v4 08/16] drm: rockchip/dp: add rockchip platform dp driver

[Yakir Yang]

Hi Heiko,

在 2015/9/1 22:24, Heiko Stuebner 写道:
> Am Dienstag, 1. September 2015, 14:01:28 schrieb Yakir Yang:
>> Rockchip have three clocks for dp controller, we leave pclk_edp
>> to analogix_dp driver control, and keep the sclk_edp_24m and
>> sclk_edp in platform driver.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v4:
>> - Remove some deprecated DT properties in rockchip dp document.
>>
>> Changes in v3:
>> - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
>>dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
>>core driver which name to "dp", and leave "pclk_edp" to rockchip dp
>> platform driver which name to "pclk".
>> - Take Heiko suggest, add devicetree binding document.
>> - Take Heiko suggest, remove "rockchip,panel" DT property, take use of
>> remote point to get panel node.
>> - Add the new function point analogix_dp_platdata.get_modes init.
>>
>> Changes in v2:
>> - Take Heiko suggest, get panel node with remote-endpoint method,
>>and create devicetree binding for driver.
>> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
>>leave those clock to rockchip dp phy driver.
>>
>>   .../bindings/video/analogix_dp-rockchip.txt|  74 
>>   drivers/gpu/drm/rockchip/Kconfig   |   9 +
>>   drivers/gpu/drm/rockchip/Makefile  |   1 +
>>   drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 389
>> + 4 files changed, 473 insertions(+)
>>   create mode 100644
>> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt create
>> mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>> b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt new file
>> mode 100644
>> index 000..502483e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>> @@ -0,0 +1,74 @@
>> +Rockchip RK3288 specific extensions to the Analogix Display Port
>> +
>> +
>> +Required properties:
>> +- compatible: "rockchip,rk3288-edp";
>> +
>> +- reg: physical base address of the controller and length
>> +
>> +- clocks: from common clock binding: handle to dp clock.
>> +  of memory mapped region.
>> +
>> +- clock-names: from common clock binding:
>> +   Required elements: "dp" "pclk"
>> +
>> +- resets: Must contain an entry for each entry in reset-names.
>> +  See ../reset/reset.txt for details.
>> +
>> +- reset-names: Must include the name "dp"
>> +
>> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
>> +
>> +- ports: contain a port node with endpoint definitions as defined in
>> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +
>> +For the below properties, please refer to Analogix DP binding document:
>> + * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
>> +- phys (required)
>> +- phy-names (required)
>> +- hpd-gpios (optional)
>> +---
>>  +
>> +Example:
>> +dp-controller: dp at ff97 {
>> +compatible = "rockchip,rk3288-dp";
>> +reg = <0xff97 0x4000>;
>> +interrupts = ;
>> +clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
>> +clock-names = "dp", "pclk";
>> +phys = <_phy>;
>> +phy-names = "dp";
>> +
>> +rockchip,grf = <>;
>> +resets = < 111>;
>> +reset-names = "dp";
>> +
>> +status = "disabled";
>> +
>> +ports {
>> +edp_in: port {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +edp_in_vopb: endpoint at 0 {
>> +reg = <0>;
>> +remote-endpoint = <_out_edp>;
>> +};
>> +edp_in_vopl: endpoint at 1 {
>> +reg = <1>;
>> +remote-endpoint = <_out_edp>;
>> +};
>> +};
>> +
>> +edp_out: port at 1 {
>> +reg = <1>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +edp_out_panel: endpoint {
>> +reg = <0>;
>> +remote-endpoint = <_in_edp>
>> +};
>> +};
>> +};
>> +};
>> +
> just a nit right now, because "git am" mentioned it:
>
> git am \[PATCH\ v4\ 08_16\]\ drm_rockchip_dp_add\ rockchip\ platform\ dp\
> driver.mbox
> [...]/linux-rockchip/.git/rebase-apply/patch:108: new blank line at EOF.
> +
>
> meaning you're adding 

[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

[Heiko Stuebner]

Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
> Split the dp core driver from exynos directory to bridge
> directory, and rename the core driver to analogix_dp_*,
> leave the platform code to analogix_dp-exynos.
> 
> Signed-off-by: Yakir Yang 

[...]

> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c similarity index 50%
> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index bed0252..7d62f22 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c

[...]

>   connector->polled = DRM_CONNECTOR_POLL_HPD;
> 
>   ret = drm_connector_init(dp->drm_dev, connector,
> -  _dp_connector_funcs,
> +  _dp_connector_funcs,
>DRM_MODE_CONNECTOR_eDP);
>   if (ret) {
>   DRM_ERROR("Failed to initialize connector with drm\n");
>   return ret;
>   }
> 
> - drm_connector_helper_add(connector, _dp_connector_helper_funcs);
> + drm_connector_helper_add(connector,
> +  _dp_connector_helper_funcs);
>   drm_connector_register(connector);

this should only run on exynos, as we're doing all our connector registration 
in the core driver after all components are bound, so I guess something like 
the following is needed:

   if (dp->plat_data && dp->plat_data->dev_type == EXYNOS_DP)
   drm_connector_register(connector);



>   drm_mode_connector_attach_encoder(connector, encoder);
> 

[...]

> @@ -1301,7 +1239,10 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data) if (IS_ERR(dp->reg_base))
>   return PTR_ERR(dp->reg_base);
> 
> - dp->hpd_gpio = of_get_named_gpio(dev->of_node, "samsung,hpd-gpio", 0);
> + dp->hpd_gpio = of_get_named_gpio(dev->of_node, "hpd-gpios", 0);
> + if (gpio_is_valid(dp->hpd_gpio))

this should be !gpio_is_valid ... i.e. only check the old property if the new 
one is _not_ valid


> + dp->hpd_gpio = of_get_named_gpio(dev->of_node,
> +  "samsung,hpd-gpio", 0);
> 
>   if (gpio_is_valid(dp->hpd_gpio)) {
>   /*

[PATCH libdrm] amdgpu: use EINVAL instead of EBADMSG in amdgpu_bo_cpu_unmap()

[Jonathan Gray]

EBADMSG is a streams errno.  OpenBSD does not implement streams and does
include the streams errnos, this commit fixes the build on OpenBSD.

None of the callers of this function check the return value for -EBADMSG.

Signed-off-by: Jonathan Gray 
---
 amdgpu/amdgpu_bo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 220422d..348da00 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -482,7 +482,7 @@ int amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
if (bo->cpu_map_count == 0) {
/* not mapped */
pthread_mutex_unlock(>cpu_access_mutex);
-   return -EBADMSG;
+   return -EINVAL;
}

bo->cpu_map_count--;
-- 
2.5.0

[Bug 103881] HP Compaq dc5750 fails to resume from suspend

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=103881

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #3 from Alex Deucher  ---
Applied.  thanks!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v3 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed

[moos...@gmail.com]

ville.syrjala at linux.intel.com writes:

> From: Ville Syrjälä 
>
> Calculate the number of retries we should do for each i2c-over-aux
> message based on the time it takes to perform the i2c transfer vs. the
> aux transfer. We assume the shortest possible length for the aux
> transfer, and the longest possible (exluding clock stretching) for the
> i2c transfer.
>
> The DP spec has some examples on how to calculate this, but we don't
> calculate things quite the same way. The spec doesn't account for the
> retry interval (assumes immediate retry on defer), and doesn't assume
> the best/worst case behaviour as we do.
>
> Note that currently we assume 10 kHz speed for the i2c bus. Some real
> world devices (eg. some Apple DP->VGA dongle) fails with less than 16
> retries. and that would correspond to something close to 15 kHz (with
> our method of calculating things) But let's just go for 10 kHz to be
> on the safe side. Ideally we should query/set the i2c bus speed via
> DPCD but for now this should at leaast remove the regression from the
 ^ extra a
> 1->16 byte trasnfer size change. And of course if the sink completes
> the transfer quicker this shouldn't slow things down since we don't
> change the interval between retries.
>
> I did a few experiments with a DP->DVI dongle I have that allows you
> to change the i2c bus speed. Here are the results of me changing the
> actual bus speed and the assumed bus speed and seeing when we start
> to fail the operation:
>
> actual i2c khz  assumed i2c khz max retries
> 1   1 ok -> 2 fail  211 ok -> 106 fail
> 5   8 ok -> 9 fail  27 ok -> 24 fail
> 10  17 ok -> 18 fail13 ok -> 12 fail
> 100 210 ok -> 211 fail  2 ok -> 1 fail
>
> So based on that we have a fairly decent safety margin baked into

[..snip..]

-- 
mailto:moosotc at gmail.com

[PATCH v3 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

Calculate the number of retries we should do for each i2c-over-aux
message based on the time it takes to perform the i2c transfer vs. the
aux transfer. We assume the shortest possible length for the aux
transfer, and the longest possible (exluding clock stretching) for the
i2c transfer.

The DP spec has some examples on how to calculate this, but we don't
calculate things quite the same way. The spec doesn't account for the
retry interval (assumes immediate retry on defer), and doesn't assume
the best/worst case behaviour as we do.

Note that currently we assume 10 kHz speed for the i2c bus. Some real
world devices (eg. some Apple DP->VGA dongle) fails with less than 16
retries. and that would correspond to something close to 15 kHz (with
our method of calculating things) But let's just go for 10 kHz to be
on the safe side. Ideally we should query/set the i2c bus speed via
DPCD but for now this should at leaast remove the regression from the
1->16 byte trasnfer size change. And of course if the sink completes
the transfer quicker this shouldn't slow things down since we don't
change the interval between retries.

I did a few experiments with a DP->DVI dongle I have that allows you
to change the i2c bus speed. Here are the results of me changing the
actual bus speed and the assumed bus speed and seeing when we start
to fail the operation:

actual i2c khz  assumed i2c khz max retries
1   1 ok -> 2 fail  211 ok -> 106 fail
5   8 ok -> 9 fail  27 ok -> 24 fail
10  17 ok -> 18 fail13 ok -> 12 fail
100 210 ok -> 211 fail  2 ok -> 1 fail

So based on that we have a fairly decent safety margin baked into
the formula to calculate the max number of retries.

Fixes a regression with some DP dongles from:
commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd
Author: Simon Farnsworth 
Date:   Tue Feb 10 18:38:08 2015 +

drm/dp: Use large transactions for I2C over AUX

v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
Add a define our AUX retry interval and account for it
v3: Make everything usecs to avoid confusion about units (Daniel)
Add a comment reminding people about the AUX bitrate (Daniel)
Use DIV_ROUND_UP() since we're after the "worst" case for i2c

Cc: Simon Farnsworth 
Cc: moosotc at gmail.com
Tested-by: moosotc at gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451
Reviewed-by: Simon Farnsworth 
Reviewed-by: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_helper.c | 84 -
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 7069e54..214a4c6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -424,6 +424,81 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
*adapter)
   I2C_FUNC_10BIT_ADDR;
 }

+#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
+#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
+#define AUX_STOP_LEN 4
+#define AUX_CMD_LEN 4
+#define AUX_ADDRESS_LEN 20
+#define AUX_REPLY_PAD_LEN 4
+#define AUX_LENGTH_LEN 8
+
+/*
+ * Calculate the duration of the AUX request/reply in usec. Gives the
+ * "best" case estimate, ie. successful while as short as possible.
+ */
+static int drm_dp_aux_req_duration(const struct drm_dp_aux_msg *msg)
+{
+   int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
+   AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
+
+   if ((msg->request & DP_AUX_I2C_READ) == 0)
+   len += msg->size * 8;
+
+   return len;
+}
+
+static int drm_dp_aux_reply_duration(const struct drm_dp_aux_msg *msg)
+{
+   int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
+   AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
+
+   /*
+* For read we expect what was asked. For writes there will
+* be 0 or 1 data bytes. Assume 0 for the "best" case.
+*/
+   if (msg->request & DP_AUX_I2C_READ)
+   len += msg->size * 8;
+
+   return len;
+}
+
+#define I2C_START_LEN 1
+#define I2C_STOP_LEN 1
+#define I2C_ADDR_LEN 9 /* ADDRESS + R/W + ACK/NACK */
+#define I2C_DATA_LEN 9 /* DATA + ACK/NACK */
+
+/*
+ * Calculate the length of the i2c transfer in usec, assuming
+ * the i2c bus speed is as specified. Gives the the "worst"
+ * case estimate, ie. successful while as long as possible.
+ * Doesn't account the the "MOT" bit, and instead assumes each
+ * message includes a START, ADDRESS and STOP. Neither does it
+ * account for additional random variables such as clock stretching.
+ */
+static int drm_dp_i2c_msg_duration(const struct drm_dp_aux_msg *msg,
+  int i2c_speed_khz)
+{
+   /* AUX bitrate is 1MHz, i2c bitrate as specified */
+   return 

[Bug 91790] TONGA hang in amdgpu_ring_lock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91790

--- Comment #8 from Andy Furniss  ---
(In reply to Mathias Tillman from comment #7)
> Andy: Could you try compiling the latest kernel from drm-next-4.3-wip? I've
> been running it all day without a single lock up, before it used to lock up
> several times a day. Just wanted someone to confirm if it is in fact
> working, or if it's just me.

I can imaging that it's far better for desktop locks - I moved onto it when it
got updated.

Initially testing with Unigine Valley I thought it was going to be good - I got
further than ever before (about 4x through all the scenes having not got
through once previously), but it did lock.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/f0960b38/attachment.html>

[PATCH 1/4] drm: Constify generic_edid_names[]

[Ville Syrjälä]

On Tue, Sep 01, 2015 at 10:47:48AM +0200, Daniel Vetter wrote:
> On Mon, Aug 31, 2015 at 10:52:03AM -0400, Alex Deucher wrote:
> > On Mon, Aug 31, 2015 at 8:09 AM,   wrote:
> > > From: Ville Syrjälä 
> > >
> > > Make generic_edid_names[] const since it's supposed to be immutable.
> > >
> > > Signed-off-by: Ville Syrjälä 
> > 
> > For the series:
> > Reviewed-by: Alex Deucher 
> 
> Merged patches 1-3 to drm-misc, but 4th conflicts badly. Just for easier
> merging I'd prefer if you can split it up per-driver if possible - with
> all the atomic conversions I expect a lot of random context conflicts to
> keep coming in.

Well, that was a good waste of some time, but I did manage to split it up.

Not sure I should bother spamming the list with it, but it's available
here:
git://github.com/vsyrjala/linux.git const_funcs

-- 
Ville Syrjälä
Intel OTC

[Bug 103881] HP Compaq dc5750 fails to resume from suspend

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=103881

--- Comment #2 from Jeffery Miller  ---
Created attachment 186451
  --> https://bugzilla.kernel.org/attachment.cgi?id=186451=edit
dmidecode of the affected machine

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 103881] HP Compaq dc5750 fails to resume from suspend

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=103881

--- Comment #1 from Jeffery Miller  ---
Created attachment 186441
  --> https://bugzilla.kernel.org/attachment.cgi?id=186441=edit
lspci -nnv of the affected system

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 103881] New: HP Compaq dc5750 fails to resume from suspend

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=103881

Bug ID: 103881
   Summary: HP Compaq dc5750 fails to resume from suspend
   Product: Drivers
   Version: 2.5
Kernel Version: 4.1.6.i386
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: jefferym at gmail.com
Regression: No

Created attachment 186431
  --> https://bugzilla.kernel.org/attachment.cgi?id=186431=edit
Patch adding the dc5750 to the list of radeon rs4xxx quirks

The HP Compaq dc5750 is unable to resume from the suspend state. With the
system suspended and I press the power button on the front of the machine I
expect it to wake up. When the button is pressed the HDD and CD drive lights
activate briefly and the fan powers on. The video output does not appear to
resume and stays black. I have to hard power the system to bring it back.
Attempting to suspend/resume has this issue every time I have tried it.

I observed this behavior on kernels 4.1.6 and 4.0.5.

Setting devices in /sys/power/pm_debug resulted in the system failing to
resume.
The freezer method in /sys/power/pm_debug did not have an issue resuming.

I enabled /sys/power/pm_trace and after the hard boot I was able to find a
reasonable hash matches line: ' pci :01:05.0: hash matches'. Additionally
/sys/power/pm_trace_dev_match was able to resolve this to `radeon`.

I was able to boot using a serial console and prevented the radeon driver from
loading. In this state it was able to suspend and resume properly. From this
state I let the radeon driver load again and the system would fail to resume
from suspend.

I was able to add this system to the list of RS480 quirks. The system was able
to suspend and resume normally with the change. It worked with the Xserver
running as well. It appears to be running normally. I have attached the patch I
tested against the 4.0.5 and 4.1.6 kernels.

Is there anything else I should test?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY

[Heiko Stuebner]

Am Dienstag, 1. September 2015, 14:04:15 schrieb Yakir Yang:
> This phy driver would control the Rockchip DisplayPort module
> phy clock and phy power, it is relate to analogix_dp-rockchip
> dp driver. If you want DP works rightly on rockchip platform,
> then you should select both of them.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v4:
> - Take Kishon suggest, add commit message, and remove the redundant
>   rockchip_dp_phy_init() function, move those code to probe() method.
>   And remove driver .owner number.
> 
> Changes in v3:
> - Take Heiko suggest, add rockchip dp phy driver,
>   collect the phy clocks and power control.
> 
> Changes in v2: None
> 
>  .../devicetree/bindings/phy/rockchip-dp-phy.txt|  26 
>  drivers/phy/Kconfig|   7 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-rockchip-dp.c  | 166
> + 4 files changed, 200 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt create mode
> 100644 drivers/phy/phy-rockchip-dp.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt new file mode
> 100644
> index 000..5de1088
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,26 @@
> +Rockchip Soc Seroes Display Port PHY
> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> +  - "rockchip.rk3288-dp-phy"
> +
> +- reg : a list of registers used by phy driver

nodes do not necessarily need to have a regs property. You can do all 
operations via the grf syscon already.


> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "sclk_dp" "sclk_dp_24m"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: phy at ff770274 {

edp_phy: edp-phy {


> + compatilble = "rockchip,rk3288-dp-phy";
> + reg = <0xff770274 4>;

no regs property

> + rockchip,grf = <>;
> + clocks = < SCLK_EDP_24M>;
> + clock-names = "24m";
> + #phy-cells = <0>;
> +}
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 47da573..8f2bc4f 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
>   help
> Enable this to support the Rockchip USB 2.0 PHY.
> 
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> +   Enable this to support the Rockchip Display Port PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>   tristate "ST SPEAR1310-MIPHY driver"
>   select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a5b18c1..e281f35 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)  +=
> phy-s5pv210-usb2.o obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)  += phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..e9a726e
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,166 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GRF_SOC_CON12   0x0274
> +#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
> +
> +#define DP_PHY_SIDDQ_WRITE_EN   BIT(21)
> +#define DP_PHY_SIDDQ_ON 0
> +#define DP_PHY_SIDDQ_OFFBIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device  *dev;
> + struct regmap  *grf;
> + void __iomem   *regs;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_dp_phy_clk_enable(struct rockchip_dp_phy *dp)
> +{
> + int ret = 0;
> +
> + ret = clk_set_rate(dp->phy_24m, 2400);
> + if (ret < 0) {
> + 

[Bug 91841] Juniper 5770 entering Hibernate crashes the system (instant reboot)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91841

Bug ID: 91841
   Summary: Juniper 5770 entering Hibernate crashes the system
(instant reboot)
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: Heiko.Lechner at ruhr-uni-bochum.de

Created attachment 118037
  --> https://bugs.freedesktop.org/attachment.cgi?id=118037=edit
grep(ed) drm out of dmesg

Hi!

I'm running Lubuntu 15.04 with open source radeon driver.

Hibernating with systemd crashed, so I read this guide:
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

# echo freezer > /sys/power/pm_test
# echo platform > /sys/power/disk
# echo disk > /sys/power/state

worked

# echo devices > /sys/power/pm_test
# echo platform > /sys/power/disk
# echo disk > /sys/power/state

crashed

so according to the guide it seemed to be a driver issue.

I started in recovery mode (command line) and pm_test worked as far as core- so
hibernate worked.

The modules that are only loaded during "normal" boot are:
cfg80211 
amdkfd
amd_iommu_v2
radeon

Even without cfg80211 hibernate crashes the system, so only radeon is left.

So I booted with radeon.modeset=0 kernel parameter resulting in radeon not
loading at all- but _hibernate works_!

Then I booted with radeon.dpm=0 kernel parameter resulting in
power_method=profile and profile set to default but hibernate does not work and
crashes.

For me it is obvious that this behavior is triggered by radeon driver.

What can I do next?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/b55abea4/attachment.html>

[Bug 91790] TONGA hang in amdgpu_ring_lock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91790

--- Comment #7 from Mathias Tillman  ---
Andy: Could you try compiling the latest kernel from drm-next-4.3-wip? I've
been running it all day without a single lock up, before it used to lock up
several times a day. Just wanted someone to confirm if it is in fact working,
or if it's just me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/05a4dbe3/attachment.html>

[PATCH 9/9] drm/exynos: remove buf_cnt from struct exynos_drm_fb

[Gustavo Padovan]

Hi Joonyoung,

2015-09-01 Joonyoung Shim :

> Looking other drm drivers, there is no the restriction that framebuffer
> has only one buffer in .create_handle() callback. They use just first
> buffer.
> 
> If this limitation is removed, there is no reason keeping buffer count
> for framebuffer, so we can remove buf_cnt from struct exynos_drm_fb.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 9 -
>  1 file changed, 9 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 8/9] drm/exynos: remove exynos_drm_fb_get_buf_cnt()

[Gustavo Padovan]

Hi Joonyoung,

2015-09-01 Joonyoung Shim :

> We can get buffer count of framebuffer using drm_format_num_planes(), so
> keeping exynos_drm_fb_get_buf_cnt() is unnecessary.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c| 9 -
>  drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 ---
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
>  3 files changed, 1 insertion(+), 13 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 7/9] drm/exynos: cleanup exynos_user_fb_create()

[Gustavo Padovan]

Hi Joonyoung,

2015-09-01 Joonyoung Shim :

> Using exynos_drm_framebuffer_init(), redundant codes can be removed.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 47 
> ++
>  1 file changed, 13 insertions(+), 34 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Tomi Valkeinen]

On 01/09/15 17:34, Rob Clark wrote:
> On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen  
> wrote:
>>
>>
>> On 25/08/15 22:24, Rob Clark wrote:
>>> On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter  
>>> wrote:
>>>> When the usual fbcon legacy options are enabled we have
>>>> ->register_framebuffer
>>>>   ->fb notifier chain calls into fbcon
>>>> ->fbcon sets up console on new fbi
>>>>   ->fbi->set_par
>>>> ->drm_fb_helper_set_par exercises full kms api
>>>>
>>>> And because of locking inversion hilarity all of register_framebuffer
>>>> is done with the console lock held. Which means that the first time on
>>>> driver load we exercise _all_ the kms code (all probe paths and
>>>> modeset paths for everything connected) is under the console lock.
>>>> That means if anything goes belly-up in that big pile of code nothing
>>>> ever reaches logfiles (and the machine is dead).
>>>>
>>>> Usual tactic to debug that is to temporarily remove those console_lock
>>>> calls to be able to capture backtraces. I'm fed up writing this patch
>>>> and recompiling kernels. Hence this patch here to add an unsafe,
>>>> kernel-taining option to do this at runtime.
>>>>
>>>> Cc: Jean-Christophe Plagniol-Villard 
>>>> Cc: Tomi Valkeinen 
>>>> Cc: linux-fbdev at vger.kernel.org
>>>> Signed-off-by: Daniel Vetter 
>>>
>>> This one was causing me some problems, if I tried to enable
>>> lockless_register_fb.  It *looks* like it should work, so I'm not
>>> quite sure what the deal is.  But I'm 110% fan of getting something
>>> like this working, because console_lock is pretty much the bane of kms
>>> developer's existence..
>>>
>>> I'll have to debug further on a system where I can see more than the
>>> bottom three lines of the second to last backtrace..
>>
>> Any idea if anyone has ever looked at properly fixing this?
> 
> I hadn't had a chance to look at it further yet..  I think Daniel
> claimed it worked for him, but he was probably on intel-next, where I
> was on drm-next at the time which seemed to be having some unrelated
> i915 issues (when I was trying to debug atomic fb-helper patches).  So
> can't really say that the issue I had was actually related to this
> patch.  I'll try again later this week or next, when hopefully i915 in
> drm-next is in better shape..

Oh, I didn't mean this patch, but the whole console lock in general.
I've also banged my head to a wall because of it =).

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/06928379/attachment.sig>

[PATCH 6/9] drm/exynos: update exynos_drm_framebuffer_init() for multiple buffers

[Gustavo Padovan]

2015-09-01 Gustavo Padovan :

> 2015-09-01 Joonyoung Shim :
> 
> > This modifies exynos_drm_framebuffer_init() to be possible to support
> > multiple buffers. Then it can be used by exynos_user_fb_create().
> > 
> > Signed-off-by: Joonyoung Shim 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_fb.c| 36 
> > +--
> >  drivers/gpu/drm/exynos/exynos_drm_fb.h|  5 -
> >  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  3 +--
> >  3 files changed, 25 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> > index 5cee148..8e5d3eb 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> > @@ -23,7 +23,6 @@
> >  #include "exynos_drm_drv.h"
> >  #include "exynos_drm_fb.h"
> >  #include "exynos_drm_fbdev.h"
> > -#include "exynos_drm_gem.h"
> >  #include "exynos_drm_iommu.h"
> >  #include "exynos_drm_crtc.h"
> >  
> > @@ -134,36 +133,41 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct 
> > drm_framebuffer *fb)
> >  struct drm_framebuffer *
> >  exynos_drm_framebuffer_init(struct drm_device *dev,
> > struct drm_mode_fb_cmd2 *mode_cmd,
> > -   struct drm_gem_object *obj)
> > +   struct exynos_drm_gem_obj **gem_obj,
> > +   int count)
> >  {
> > struct exynos_drm_fb *exynos_fb;
> > -   struct exynos_drm_gem_obj *exynos_gem_obj;
> > +   int i;
> > int ret;
> >  
> > -   exynos_gem_obj = to_exynos_gem_obj(obj);
> > -
> > -   ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
> > -   if (ret < 0)
> > -   return ERR_PTR(ret);
> > -
> > exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
> > if (!exynos_fb)
> > return ERR_PTR(-ENOMEM);
> >  
> > -   drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
> > -   exynos_fb->exynos_gem_obj[0] = exynos_gem_obj;
> > +   exynos_fb->buf_cnt = count;
> > +   DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
> >  
> > -   /* buffer count to framebuffer always is 1 at booting time. */
> > -   exynos_fb->buf_cnt = 1;
> > +   for (i = 0; i < count; i++) {
> > +   ret = check_fb_gem_memory_type(dev, gem_obj[i]);
> > +   if (ret < 0)
> > +   goto err;
> > +
> > +   exynos_fb->exynos_gem_obj[i] = gem_obj[i];
> > +   }
> > +
> > +   drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
> >  
> > ret = drm_framebuffer_init(dev, _fb->fb, _drm_fb_funcs);
> > -   if (ret) {
> > -   kfree(exynos_fb);
> > +   if (ret < 0) {
> > DRM_ERROR("failed to initialize framebuffer\n");
> > -   return ERR_PTR(ret);
> > +   goto err;
> > }
> >  
> > return _fb->fb;
> > +
> > +err:
> > +   kfree(exynos_fb);
> > +   return ERR_PTR(ret);
> >  }
> >  
> >  static struct drm_framebuffer *
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
> > b/drivers/gpu/drm/exynos/exynos_drm_fb.h
> > index 897d2cf..8900f6b 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
> > @@ -14,10 +14,13 @@
> >  #ifndef _EXYNOS_DRM_FB_H_
> >  #define _EXYNOS_DRM_FB_H
> >  
> > +#include "exynos_drm_gem.h"
> > +
> >  struct drm_framebuffer *
> >  exynos_drm_framebuffer_init(struct drm_device *dev,
> > struct drm_mode_fb_cmd2 *mode_cmd,
> > -   struct drm_gem_object *obj);
> > +   struct exynos_drm_gem_obj **gem_obj,
> > +   int count);
> >  
> >  /* get gem object of a drm framebuffer */
> >  struct exynos_drm_gem_obj *exynos_drm_fb_gem_obj(struct drm_framebuffer 
> > *fb,
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > index 133cf5f..a221f75 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > @@ -21,7 +21,6 @@
> >  #include "exynos_drm_drv.h"
> >  #include "exynos_drm_fb.h"
> >  #include "exynos_drm_fbdev.h"
> > -#include "exynos_drm_gem.h"
> >  #include "exynos_drm_iommu.h"
> >  
> >  #define MAX_CONNECTOR  4
> > @@ -160,7 +159,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
> > *helper,
> >  
> > exynos_fbdev->obj = obj;
> >  
> > -   helper->fb = exynos_drm_framebuffer_init(dev, _cmd, >base);
> > +   helper->fb = exynos_drm_framebuffer_init(dev, _cmd, , 1);
> 
> Do you have any use for this for multiple buffers? I don't see any patch
> in this series for multiple buffers. I think we should wait for a user
> of multiple buffers to apply this patch.

Ah, just saw it.

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 6/9] drm/exynos: update exynos_drm_framebuffer_init() for multiple buffers

[Gustavo Padovan]

2015-09-01 Joonyoung Shim :

> This modifies exynos_drm_framebuffer_init() to be possible to support
> multiple buffers. Then it can be used by exynos_user_fb_create().
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c| 36 
> +--
>  drivers/gpu/drm/exynos/exynos_drm_fb.h|  5 -
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  3 +--
>  3 files changed, 25 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 5cee148..8e5d3eb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -23,7 +23,6 @@
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
>  #include "exynos_drm_fbdev.h"
> -#include "exynos_drm_gem.h"
>  #include "exynos_drm_iommu.h"
>  #include "exynos_drm_crtc.h"
>  
> @@ -134,36 +133,41 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct 
> drm_framebuffer *fb)
>  struct drm_framebuffer *
>  exynos_drm_framebuffer_init(struct drm_device *dev,
>   struct drm_mode_fb_cmd2 *mode_cmd,
> - struct drm_gem_object *obj)
> + struct exynos_drm_gem_obj **gem_obj,
> + int count)
>  {
>   struct exynos_drm_fb *exynos_fb;
> - struct exynos_drm_gem_obj *exynos_gem_obj;
> + int i;
>   int ret;
>  
> - exynos_gem_obj = to_exynos_gem_obj(obj);
> -
> - ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
> - if (ret < 0)
> - return ERR_PTR(ret);
> -
>   exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
>   if (!exynos_fb)
>   return ERR_PTR(-ENOMEM);
>  
> - drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
> - exynos_fb->exynos_gem_obj[0] = exynos_gem_obj;
> + exynos_fb->buf_cnt = count;
> + DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
>  
> - /* buffer count to framebuffer always is 1 at booting time. */
> - exynos_fb->buf_cnt = 1;
> + for (i = 0; i < count; i++) {
> + ret = check_fb_gem_memory_type(dev, gem_obj[i]);
> + if (ret < 0)
> + goto err;
> +
> + exynos_fb->exynos_gem_obj[i] = gem_obj[i];
> + }
> +
> + drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
>  
>   ret = drm_framebuffer_init(dev, _fb->fb, _drm_fb_funcs);
> - if (ret) {
> - kfree(exynos_fb);
> + if (ret < 0) {
>   DRM_ERROR("failed to initialize framebuffer\n");
> - return ERR_PTR(ret);
> + goto err;
>   }
>  
>   return _fb->fb;
> +
> +err:
> + kfree(exynos_fb);
> + return ERR_PTR(ret);
>  }
>  
>  static struct drm_framebuffer *
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.h
> index 897d2cf..8900f6b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
> @@ -14,10 +14,13 @@
>  #ifndef _EXYNOS_DRM_FB_H_
>  #define _EXYNOS_DRM_FB_H
>  
> +#include "exynos_drm_gem.h"
> +
>  struct drm_framebuffer *
>  exynos_drm_framebuffer_init(struct drm_device *dev,
>   struct drm_mode_fb_cmd2 *mode_cmd,
> - struct drm_gem_object *obj);
> + struct exynos_drm_gem_obj **gem_obj,
> + int count);
>  
>  /* get gem object of a drm framebuffer */
>  struct exynos_drm_gem_obj *exynos_drm_fb_gem_obj(struct drm_framebuffer *fb,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 133cf5f..a221f75 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -21,7 +21,6 @@
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
>  #include "exynos_drm_fbdev.h"
> -#include "exynos_drm_gem.h"
>  #include "exynos_drm_iommu.h"
>  
>  #define MAX_CONNECTOR4
> @@ -160,7 +159,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
> *helper,
>  
>   exynos_fbdev->obj = obj;
>  
> - helper->fb = exynos_drm_framebuffer_init(dev, _cmd, >base);
> + helper->fb = exynos_drm_framebuffer_init(dev, _cmd, , 1);

Do you have any use for this for multiple buffers? I don't see any patch
in this series for multiple buffers. I think we should wait for a user
of multiple buffers to apply this patch.

Gustavo

[PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Daniel Vetter]

On Tue, Sep 01, 2015 at 11:12:11AM -0400, Rob Clark wrote:
> On Tue, Sep 1, 2015 at 10:41 AM, Tomi Valkeinen  
> wrote:
> >
> >
> > On 01/09/15 17:34, Rob Clark wrote:
> >> On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen  
> >> wrote:
> >>>
> >>>
> >>> On 25/08/15 22:24, Rob Clark wrote:
>  On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter   ffwll.ch> wrote:
> > When the usual fbcon legacy options are enabled we have
> > ->register_framebuffer
> >   ->fb notifier chain calls into fbcon
> > ->fbcon sets up console on new fbi
> >   ->fbi->set_par
> > ->drm_fb_helper_set_par exercises full kms api
> >
> > And because of locking inversion hilarity all of register_framebuffer
> > is done with the console lock held. Which means that the first time on
> > driver load we exercise _all_ the kms code (all probe paths and
> > modeset paths for everything connected) is under the console lock.
> > That means if anything goes belly-up in that big pile of code nothing
> > ever reaches logfiles (and the machine is dead).
> >
> > Usual tactic to debug that is to temporarily remove those console_lock
> > calls to be able to capture backtraces. I'm fed up writing this patch
> > and recompiling kernels. Hence this patch here to add an unsafe,
> > kernel-taining option to do this at runtime.
> >
> > Cc: Jean-Christophe Plagniol-Villard 
> > Cc: Tomi Valkeinen 
> > Cc: linux-fbdev at vger.kernel.org
> > Signed-off-by: Daniel Vetter 
> 
>  This one was causing me some problems, if I tried to enable
>  lockless_register_fb.  It *looks* like it should work, so I'm not
>  quite sure what the deal is.  But I'm 110% fan of getting something
>  like this working, because console_lock is pretty much the bane of kms
>  developer's existence..
> 
>  I'll have to debug further on a system where I can see more than the
>  bottom three lines of the second to last backtrace..
> >>>
> >>> Any idea if anyone has ever looked at properly fixing this?
> >>
> >> I hadn't had a chance to look at it further yet..  I think Daniel
> >> claimed it worked for him, but he was probably on intel-next, where I
> >> was on drm-next at the time which seemed to be having some unrelated
> >> i915 issues (when I was trying to debug atomic fb-helper patches).  So
> >> can't really say that the issue I had was actually related to this
> >> patch.  I'll try again later this week or next, when hopefully i915 in
> >> drm-next is in better shape..
> >
> > Oh, I didn't mean this patch, but the whole console lock in general.
> > I've also banged my head to a wall because of it =).
> 
> oh, not sure.. every time I've started looking closer at
> console/console_lock I run away screaming..  I guess if it were
> possible to push the lock down further so only drivers that needed the
> lock (presumably serial/net/etc) could take it, that would be nice..
> but not sure I am that brave..

console_lock is pretty much unfixable without rewriting half of fbdev.
Which I don't expect to ever happen. For the curious look at all the
commits changing locking in fbdev over the past few years.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 5/9] drm/exynos: cleanup to get gem object for fb

[Gustavo Padovan]

Hi Joonyoung,

2015-09-01 Joonyoung Shim :

> Current codes get first gem object and then again get remain gem
> objects. They can be unified to one routine.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 23 ---
>  1 file changed, 8 insertions(+), 15 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 4/9] drm/exynos: update fb_info via only one function

[Gustavo Padovan]

Hi Joonyoung,

2015-09-01 Joonyoung Shim :

> This patch moves codes to update fb_info into exynos_drm_fbdev_update(),
> so fb_info is updated via only one function.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 29 +
>  1 file changed, 13 insertions(+), 16 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH v2 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed

[Daniel Vetter]

On Tue, Sep 01, 2015 at 05:11:45PM +0200, Daniel Vetter wrote:
> On Tue, Sep 01, 2015 at 02:13:01PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 01, 2015 at 11:14:43AM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 26, 2015 at 10:55:06PM +0300, ville.syrjala at 
> > > linux.intel.com wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > Calculate the number of retries we should do for each i2c-over-aux
> > > > message based on the time it takes to perform the i2c transfer vs. the
> > > > aux transfer. We assume the shortest possible length for the aux
> > > > transfer, and the longest possible (exluding clock stretching) for the
> > > > i2c transfer.
> > > > 
> > > > The DP spec has some examples on how to calculate this, but we don't
> > > > calculate things quite the same way. The spec doesn't account for the
> > > > retry interval (assumes immediate retry on defer), and doesn't assume
> > > > the best/worst case behaviour as we do.
> > > > 
> > > > Note that currently we assume 10 kHz speed for the i2c bus. Some real
> > > > world devices (eg. some Apple DP->VGA dongle) fails with less than 16
> > > > retries. and that would correspond to something close to 15 kHz (with
> > > > our method of calculating things) But let's just go for 10 kHz to be
> > > > on the safe side. Ideally we should query/set the i2c bus speed via
> > > > DPCD but for now this should at leaast remove the regression from the
> > > > 1->16 byte trasnfer size change. And of course if the sink completes
> > > > the transfer quicker this shouldn't slow things down since we don't
> > > > change the interval between retries.
> > > > 
> > > > I did a few experiments with a DP->DVI dongle I have that allows you
> > > > to change the i2c bus speed. Here are the results of me changing the
> > > > actual bus speed and the assumed bus speed and seeing when we start
> > > > to fail the operation:
> > > > 
> > > > actual i2c khz  assumed i2c khz max retries
> > > > 1   1 ok -> 2 fail  211 ok -> 106 fail
> > > > 5   8 ok -> 9 fail  27 ok -> 24 fail
> > > > 10  17 ok -> 18 fail13 ok -> 12 fail
> > > > 100 210 ok -> 211 fail  2 ok -> 1 fail
> > > > 
> > > > So based on that we have a fairly decent safety margin baked into
> > > > the formula to calculate the max number of retries.
> > > > 
> > > > Fixes a regression with some DP dongles from:
> > > > commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd
> > > > Author: Simon Farnsworth 
> > > > Date:   Tue Feb 10 18:38:08 2015 +
> > > > 
> > > > drm/dp: Use large transactions for I2C over AUX
> > > > 
> > > > v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
> > > > Add a define our AUX retry interval and account for it
> > > > 
> > > > Cc: Simon Farnsworth 
> > > > Cc: moosotc at gmail.com
> > > > Tested-by: moosotc at gmail.com
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_helper.c | 81 
> > > > -
> > > >  1 file changed, 79 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > index 7069e54..23b9fcc 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -424,6 +424,78 @@ static u32 drm_dp_i2c_functionality(struct 
> > > > i2c_adapter *adapter)
> > > >I2C_FUNC_10BIT_ADDR;
> > > >  }
> > > >  
> > > > +#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
> > > > +#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
> > > > +#define AUX_STOP_LEN 4
> > > > +#define AUX_CMD_LEN 4
> > > > +#define AUX_ADDRESS_LEN 20
> > > > +#define AUX_REPLY_PAD_LEN 4
> > > > +#define AUX_LENGTH_LEN 8
> > > > +
> > > > +/*
> > > > + * Calculate the length of the AUX request/reply. Gives the "best"
> > > > + * case estimate, ie. successful while as short as possible.
> > > > + */
> > > > +static int drm_dp_aux_req_len(const struct drm_dp_aux_msg *msg)
> > > > +{
> > > > +   int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
> > > > +   AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
> > > > +
> > > > +   if ((msg->request & DP_AUX_I2C_READ) == 0)
> > > > +   len += msg->size * 8;
> > > > +
> > > > +   return len;
> > > > +}
> > > > +
> > > > +static int drm_dp_aux_reply_len(const struct drm_dp_aux_msg *msg)
> > > > +{
> > > > +   int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
> > > > +   AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
> > > > +
> > > > +   /*
> > > > +* For read we expect what was asked. For writes there will
> > > > +* be 0 or 1 data bytes. Assume 0 for the "best" case.
> > > > +*/
> > > > +   if (msg->request & DP_AUX_I2C_READ)
> > > > +   len += 

[PATCH v2 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed

[Daniel Vetter]

On Tue, Sep 01, 2015 at 02:13:01PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 01, 2015 at 11:14:43AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 26, 2015 at 10:55:06PM +0300, ville.syrjala at linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Calculate the number of retries we should do for each i2c-over-aux
> > > message based on the time it takes to perform the i2c transfer vs. the
> > > aux transfer. We assume the shortest possible length for the aux
> > > transfer, and the longest possible (exluding clock stretching) for the
> > > i2c transfer.
> > > 
> > > The DP spec has some examples on how to calculate this, but we don't
> > > calculate things quite the same way. The spec doesn't account for the
> > > retry interval (assumes immediate retry on defer), and doesn't assume
> > > the best/worst case behaviour as we do.
> > > 
> > > Note that currently we assume 10 kHz speed for the i2c bus. Some real
> > > world devices (eg. some Apple DP->VGA dongle) fails with less than 16
> > > retries. and that would correspond to something close to 15 kHz (with
> > > our method of calculating things) But let's just go for 10 kHz to be
> > > on the safe side. Ideally we should query/set the i2c bus speed via
> > > DPCD but for now this should at leaast remove the regression from the
> > > 1->16 byte trasnfer size change. And of course if the sink completes
> > > the transfer quicker this shouldn't slow things down since we don't
> > > change the interval between retries.
> > > 
> > > I did a few experiments with a DP->DVI dongle I have that allows you
> > > to change the i2c bus speed. Here are the results of me changing the
> > > actual bus speed and the assumed bus speed and seeing when we start
> > > to fail the operation:
> > > 
> > > actual i2c khz  assumed i2c khz max retries
> > > 1   1 ok -> 2 fail  211 ok -> 106 fail
> > > 5   8 ok -> 9 fail  27 ok -> 24 fail
> > > 10  17 ok -> 18 fail13 ok -> 12 fail
> > > 100 210 ok -> 211 fail  2 ok -> 1 fail
> > > 
> > > So based on that we have a fairly decent safety margin baked into
> > > the formula to calculate the max number of retries.
> > > 
> > > Fixes a regression with some DP dongles from:
> > > commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd
> > > Author: Simon Farnsworth 
> > > Date:   Tue Feb 10 18:38:08 2015 +
> > > 
> > > drm/dp: Use large transactions for I2C over AUX
> > > 
> > > v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
> > > Add a define our AUX retry interval and account for it
> > > 
> > > Cc: Simon Farnsworth 
> > > Cc: moosotc at gmail.com
> > > Tested-by: moosotc at gmail.com
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c | 81 
> > > -
> > >  1 file changed, 79 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 7069e54..23b9fcc 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -424,6 +424,78 @@ static u32 drm_dp_i2c_functionality(struct 
> > > i2c_adapter *adapter)
> > >  I2C_FUNC_10BIT_ADDR;
> > >  }
> > >  
> > > +#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
> > > +#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
> > > +#define AUX_STOP_LEN 4
> > > +#define AUX_CMD_LEN 4
> > > +#define AUX_ADDRESS_LEN 20
> > > +#define AUX_REPLY_PAD_LEN 4
> > > +#define AUX_LENGTH_LEN 8
> > > +
> > > +/*
> > > + * Calculate the length of the AUX request/reply. Gives the "best"
> > > + * case estimate, ie. successful while as short as possible.
> > > + */
> > > +static int drm_dp_aux_req_len(const struct drm_dp_aux_msg *msg)
> > > +{
> > > + int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
> > > + AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
> > > +
> > > + if ((msg->request & DP_AUX_I2C_READ) == 0)
> > > + len += msg->size * 8;
> > > +
> > > + return len;
> > > +}
> > > +
> > > +static int drm_dp_aux_reply_len(const struct drm_dp_aux_msg *msg)
> > > +{
> > > + int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
> > > + AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
> > > +
> > > + /*
> > > +  * For read we expect what was asked. For writes there will
> > > +  * be 0 or 1 data bytes. Assume 0 for the "best" case.
> > > +  */
> > > + if (msg->request & DP_AUX_I2C_READ)
> > > + len += msg->size * 8;
> > > +
> > > + return len;
> > > +}
> > > +
> > > +#define I2C_START_LEN 1
> > > +#define I2C_STOP_LEN 1
> > > +#define I2C_ADDR_LEN 9 /* ADDRESS + R/W + ACK/NACK */
> > > +#define I2C_DATA_LEN 9 /* DATA + ACK/NACK */
> > > +
> > > +/*
> > > + * Calculate the length of the i2c transfer (in AUX clocks)
> > > + * assuming the i2c bus speed is as 

[PATCH] Add radeon suspend/resume quirk for HP Compaq dc5750.

[Jeffery Miller]

With the radeon driver loaded the HP Compaq dc5750
Small Form Factor machine fails to resume from suspend.
Adding a quirk similar to other devices avoids
the problem and the system resumes properly.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=103881
Signed-off-by: Jeffery Miller 
---
 drivers/gpu/drm/radeon/radeon_combios.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index c097d3a82bda..a9b01bcf7d0a 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -3387,6 +3387,14 @@ void radeon_combios_asic_init(struct drm_device *dev)
rdev->pdev->subsystem_device == 0x30ae)
return;

+   /* quirk for rs4xx HP Compaq dc5750 Small Form Factor to make it resume
+* - it hangs on resume inside the dynclk 1 table.
+*/
+   if (rdev->family == CHIP_RS480 &&
+   rdev->pdev->subsystem_vendor == 0x103c &&
+   rdev->pdev->subsystem_device == 0x280a)
+   return;
+
/* DYN CLK 1 */
table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE);
if (table)
-- 
1.9.1

[PATCH v4 08/16] drm: rockchip/dp: add rockchip platform dp driver

[Heiko Stuebner]

Am Dienstag, 1. September 2015, 14:01:28 schrieb Yakir Yang:
> Rockchip have three clocks for dp controller, we leave pclk_edp
> to analogix_dp driver control, and keep the sclk_edp_24m and
> sclk_edp in platform driver.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v4:
> - Remove some deprecated DT properties in rockchip dp document.
> 
> Changes in v3:
> - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
>   dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
>   core driver which name to "dp", and leave "pclk_edp" to rockchip dp
> platform driver which name to "pclk".
> - Take Heiko suggest, add devicetree binding document.
> - Take Heiko suggest, remove "rockchip,panel" DT property, take use of
> remote point to get panel node.
> - Add the new function point analogix_dp_platdata.get_modes init.
> 
> Changes in v2:
> - Take Heiko suggest, get panel node with remote-endpoint method,
>   and create devicetree binding for driver.
> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
>   leave those clock to rockchip dp phy driver.
> 
>  .../bindings/video/analogix_dp-rockchip.txt|  74 
>  drivers/gpu/drm/rockchip/Kconfig   |   9 +
>  drivers/gpu/drm/rockchip/Makefile  |   1 +
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 389
> + 4 files changed, 473 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt create
> mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> 
> diff --git
> a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt new file
> mode 100644
> index 000..502483e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> @@ -0,0 +1,74 @@
> +Rockchip RK3288 specific extensions to the Analogix Display Port
> +
> +
> +Required properties:
> +- compatible: "rockchip,rk3288-edp";
> +
> +- reg: physical base address of the controller and length
> +
> +- clocks: from common clock binding: handle to dp clock.
> +   of memory mapped region.
> +
> +- clock-names: from common clock binding:
> +Required elements: "dp" "pclk"
> +
> +- resets: Must contain an entry for each entry in reset-names.
> +   See ../reset/reset.txt for details.
> +
> +- reset-names: Must include the name "dp"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +
> +- ports: contain a port node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +
> +For the below properties, please refer to Analogix DP binding document:
> + * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> +- phys (required)
> +- phy-names (required)
> +- hpd-gpios (optional)
> +---
>  +
> +Example:
> + dp-controller: dp at ff97 {
> + compatible = "rockchip,rk3288-dp";
> + reg = <0xff97 0x4000>;
> + interrupts = ;
> + clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
> + clock-names = "dp", "pclk";
> + phys = <_phy>;
> + phy-names = "dp";
> +
> + rockchip,grf = <>;
> + resets = < 111>;
> + reset-names = "dp";
> +
> + status = "disabled";
> +
> + ports {
> + edp_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + edp_in_vopb: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <_out_edp>;
> + };
> + edp_in_vopl: endpoint at 1 {
> + reg = <1>;
> + remote-endpoint = <_out_edp>;
> + };
> + };
> +
> + edp_out: port at 1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + edp_out_panel: endpoint {
> + reg = <0>;
> + remote-endpoint = <_in_edp>
> + };
> + };
> + };
> + };
> +
just a nit right now, because "git am" mentioned it:

git am \[PATCH\ v4\ 08_16\]\ drm_rockchip_dp_add\ rockchip\ platform\ dp\ 
driver.mbox 
[...]/linux-rockchip/.git/rebase-apply/patch:108: new blank line at EOF.
+

meaning you're adding an empty line at the end :-)


Heiko

[PATCH 9/9] drm/exynos: remove buf_cnt from struct exynos_drm_fb

[Joonyoung Shim]

Looking other drm drivers, there is no the restriction that framebuffer
has only one buffer in .create_handle() callback. They use just first
buffer.

If this limitation is removed, there is no reason keeping buffer count
for framebuffer, so we can remove buf_cnt from struct exynos_drm_fb.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index d2e746e..6d1b70e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -32,12 +32,10 @@
  * exynos specific framebuffer structure.
  *
  * @fb: drm framebuffer obejct.
- * @buf_cnt: a buffer count to drm framebuffer.
  * @exynos_gem_obj: array of exynos specific gem object containing a gem 
object.
  */
 struct exynos_drm_fb {
struct drm_framebuffer  fb;
-   unsigned intbuf_cnt;
struct exynos_drm_gem_obj   *exynos_gem_obj[MAX_FB_BUFFER];
 };

@@ -97,10 +95,6 @@ static int exynos_drm_fb_create_handle(struct 
drm_framebuffer *fb,
 {
struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);

-   /* This fb should have only one gem object. */
-   if (WARN_ON(exynos_fb->buf_cnt != 1))
-   return -EINVAL;
-
return drm_gem_handle_create(file_priv,
_fb->exynos_gem_obj[0]->base, handle);
 }
@@ -135,9 +129,6 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
if (!exynos_fb)
return ERR_PTR(-ENOMEM);

-   exynos_fb->buf_cnt = count;
-   DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
-
for (i = 0; i < count; i++) {
ret = check_fb_gem_memory_type(dev, gem_obj[i]);
if (ret < 0)
-- 
1.9.1

[PATCH 8/9] drm/exynos: remove exynos_drm_fb_get_buf_cnt()

[Joonyoung Shim]

We can get buffer count of framebuffer using drm_format_num_planes(), so
keeping exynos_drm_fb_get_buf_cnt() is unnecessary.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c| 9 -
 drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 ---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
 3 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 9accc0d..d2e746e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -121,15 +121,6 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs = {
.dirty  = exynos_drm_fb_dirty,
 };

-unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
-{
-   struct exynos_drm_fb *exynos_fb;
-
-   exynos_fb = to_exynos_fb(fb);
-
-   return exynos_fb->buf_cnt;
-}
-
 struct drm_framebuffer *
 exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 8900f6b..85e4445 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
@@ -28,7 +28,4 @@ struct exynos_drm_gem_obj *exynos_drm_fb_gem_obj(struct 
drm_framebuffer *fb,

 void exynos_drm_mode_config_init(struct drm_device *dev);

-/* get a buffer count to drm framebuffer. */
-unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb);
-
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index d9a68fd..36c9911 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -132,7 +132,7 @@ static int exynos_plane_atomic_check(struct drm_plane 
*plane,
if (!state->fb)
return 0;

-   nr = exynos_drm_fb_get_buf_cnt(state->fb);
+   nr = drm_format_num_planes(state->fb->pixel_format);
for (i = 0; i < nr; i++) {
struct exynos_drm_gem_obj *obj =
exynos_drm_fb_gem_obj(state->fb, i);
-- 
1.9.1

[PATCH 7/9] drm/exynos: cleanup exynos_user_fb_create()

[Joonyoung Shim]

Using exynos_drm_framebuffer_init(), redundant codes can be removed.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c | 47 ++
 1 file changed, 13 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 8e5d3eb..9accc0d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -174,57 +174,36 @@ static struct drm_framebuffer *
 exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
  struct drm_mode_fb_cmd2 *mode_cmd)
 {
+   struct exynos_drm_gem_obj *gem_objs[MAX_FB_BUFFER];
struct drm_gem_object *obj;
-   struct exynos_drm_gem_obj *exynos_gem_obj;
-   struct exynos_drm_fb *exynos_fb;
-   int i, ret;
-
-   exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
-   if (!exynos_fb)
-   return ERR_PTR(-ENOMEM);
-
-   exynos_fb->buf_cnt = drm_format_num_planes(mode_cmd->pixel_format);
-
-   DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
+   struct drm_framebuffer *fb;
+   int i;
+   int ret;

-   for (i = 0; i < exynos_fb->buf_cnt; i++) {
+   for (i = 0; i < drm_format_num_planes(mode_cmd->pixel_format); i++) {
obj = drm_gem_object_lookup(dev, file_priv,
-   mode_cmd->handles[i]);
+   mode_cmd->handles[i]);
if (!obj) {
DRM_ERROR("failed to lookup gem object\n");
ret = -ENOENT;
-   exynos_fb->buf_cnt = i;
goto err;
}

-   exynos_gem_obj = to_exynos_gem_obj(obj);
-   exynos_fb->exynos_gem_obj[i] = exynos_gem_obj;
-
-   ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
-   if (ret < 0)
-   goto err;
+   gem_objs[i] = to_exynos_gem_obj(obj);
}

-   drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
-
-   ret = drm_framebuffer_init(dev, _fb->fb, _drm_fb_funcs);
-   if (ret) {
-   DRM_ERROR("failed to init framebuffer.\n");
+   fb = exynos_drm_framebuffer_init(dev, mode_cmd, gem_objs, i);
+   if (IS_ERR(fb)) {
+   ret = PTR_ERR(fb);
goto err;
}

-   return _fb->fb;
+   return fb;

 err:
-   for (i = 0; i < exynos_fb->buf_cnt; i++) {
-   struct drm_gem_object *obj;
+   while (i--)
+   drm_gem_object_unreference_unlocked(_objs[i]->base);

-   obj = _fb->exynos_gem_obj[i]->base;
-   if (obj)
-   drm_gem_object_unreference_unlocked(obj);
-   }
-
-   kfree(exynos_fb);
return ERR_PTR(ret);
 }

-- 
1.9.1

[PATCH 6/9] drm/exynos: update exynos_drm_framebuffer_init() for multiple buffers

[Joonyoung Shim]

This modifies exynos_drm_framebuffer_init() to be possible to support
multiple buffers. Then it can be used by exynos_user_fb_create().

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c| 36 +--
 drivers/gpu/drm/exynos/exynos_drm_fb.h|  5 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  3 +--
 3 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 5cee148..8e5d3eb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -23,7 +23,6 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_fbdev.h"
-#include "exynos_drm_gem.h"
 #include "exynos_drm_iommu.h"
 #include "exynos_drm_crtc.h"

@@ -134,36 +133,41 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct 
drm_framebuffer *fb)
 struct drm_framebuffer *
 exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
-   struct drm_gem_object *obj)
+   struct exynos_drm_gem_obj **gem_obj,
+   int count)
 {
struct exynos_drm_fb *exynos_fb;
-   struct exynos_drm_gem_obj *exynos_gem_obj;
+   int i;
int ret;

-   exynos_gem_obj = to_exynos_gem_obj(obj);
-
-   ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
-   if (ret < 0)
-   return ERR_PTR(ret);
-
exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
if (!exynos_fb)
return ERR_PTR(-ENOMEM);

-   drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
-   exynos_fb->exynos_gem_obj[0] = exynos_gem_obj;
+   exynos_fb->buf_cnt = count;
+   DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);

-   /* buffer count to framebuffer always is 1 at booting time. */
-   exynos_fb->buf_cnt = 1;
+   for (i = 0; i < count; i++) {
+   ret = check_fb_gem_memory_type(dev, gem_obj[i]);
+   if (ret < 0)
+   goto err;
+
+   exynos_fb->exynos_gem_obj[i] = gem_obj[i];
+   }
+
+   drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);

ret = drm_framebuffer_init(dev, _fb->fb, _drm_fb_funcs);
-   if (ret) {
-   kfree(exynos_fb);
+   if (ret < 0) {
DRM_ERROR("failed to initialize framebuffer\n");
-   return ERR_PTR(ret);
+   goto err;
}

return _fb->fb;
+
+err:
+   kfree(exynos_fb);
+   return ERR_PTR(ret);
 }

 static struct drm_framebuffer *
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 897d2cf..8900f6b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
@@ -14,10 +14,13 @@
 #ifndef _EXYNOS_DRM_FB_H_
 #define _EXYNOS_DRM_FB_H

+#include "exynos_drm_gem.h"
+
 struct drm_framebuffer *
 exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
-   struct drm_gem_object *obj);
+   struct exynos_drm_gem_obj **gem_obj,
+   int count);

 /* get gem object of a drm framebuffer */
 struct exynos_drm_gem_obj *exynos_drm_fb_gem_obj(struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 133cf5f..a221f75 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -21,7 +21,6 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_fbdev.h"
-#include "exynos_drm_gem.h"
 #include "exynos_drm_iommu.h"

 #define MAX_CONNECTOR  4
@@ -160,7 +159,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,

exynos_fbdev->obj = obj;

-   helper->fb = exynos_drm_framebuffer_init(dev, _cmd, >base);
+   helper->fb = exynos_drm_framebuffer_init(dev, _cmd, , 1);
if (IS_ERR(helper->fb)) {
DRM_ERROR("failed to create drm framebuffer.\n");
ret = PTR_ERR(helper->fb);
-- 
1.9.1

[PATCH 5/9] drm/exynos: cleanup to get gem object for fb

[Joonyoung Shim]

Current codes get first gem object and then again get remain gem
objects. They can be unified to one routine.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c | 23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index effeb64..5cee148 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -179,27 +179,18 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
if (!exynos_fb)
return ERR_PTR(-ENOMEM);

-   obj = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
-   if (!obj) {
-   DRM_ERROR("failed to lookup gem object\n");
-   ret = -ENOENT;
-   goto err_free;
-   }
-
-   drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
-   exynos_fb->exynos_gem_obj[0] = to_exynos_gem_obj(obj);
exynos_fb->buf_cnt = drm_format_num_planes(mode_cmd->pixel_format);

DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);

-   for (i = 1; i < exynos_fb->buf_cnt; i++) {
+   for (i = 0; i < exynos_fb->buf_cnt; i++) {
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd->handles[i]);
if (!obj) {
DRM_ERROR("failed to lookup gem object\n");
ret = -ENOENT;
exynos_fb->buf_cnt = i;
-   goto err_unreference;
+   goto err;
}

exynos_gem_obj = to_exynos_gem_obj(obj);
@@ -207,18 +198,20 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,

ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
if (ret < 0)
-   goto err_unreference;
+   goto err;
}

+   drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
+
ret = drm_framebuffer_init(dev, _fb->fb, _drm_fb_funcs);
if (ret) {
DRM_ERROR("failed to init framebuffer.\n");
-   goto err_unreference;
+   goto err;
}

return _fb->fb;

-err_unreference:
+err:
for (i = 0; i < exynos_fb->buf_cnt; i++) {
struct drm_gem_object *obj;

@@ -226,7 +219,7 @@ err_unreference:
if (obj)
drm_gem_object_unreference_unlocked(obj);
}
-err_free:
+
kfree(exynos_fb);
return ERR_PTR(ret);
 }
-- 
1.9.1

[PATCH 4/9] drm/exynos: update fb_info via only one function

[Joonyoung Shim]

This patch moves codes to update fb_info into exynos_drm_fbdev_update(),
so fb_info is updated via only one function.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 4ef8739..133cf5f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -78,12 +78,22 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
   struct drm_fb_helper_surface_size *sizes,
   struct exynos_drm_gem_obj *obj)
 {
-   struct fb_info *fbi = helper->fbdev;
+   struct fb_info *fbi;
struct drm_framebuffer *fb = helper->fb;
unsigned int size = fb->width * fb->height * (fb->bits_per_pixel >> 3);
unsigned int nr_pages;
unsigned long offset;

+   fbi = drm_fb_helper_alloc_fbi(helper);
+   if (IS_ERR(fbi)) {
+   DRM_ERROR("failed to allocate fb info.\n");
+   return PTR_ERR(fbi);
+   }
+
+   fbi->par = helper;
+   fbi->flags = FBINFO_FLAG_DEFAULT;
+   fbi->fbops = _drm_fb_ops;
+
drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);

@@ -93,6 +103,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
pgprot_writecombine(PAGE_KERNEL));
if (!obj->kvaddr) {
DRM_ERROR("failed to map pages to kernel space.\n");
+   drm_fb_helper_release_fbi(helper);
return -EIO;
}

@@ -112,7 +123,6 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
struct exynos_drm_fbdev *exynos_fbdev = to_exynos_fbdev(helper);
struct exynos_drm_gem_obj *obj;
struct drm_device *dev = helper->dev;
-   struct fb_info *fbi;
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
struct platform_device *pdev = dev->platformdev;
unsigned long size;
@@ -130,13 +140,6 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,

mutex_lock(>struct_mutex);

-   fbi = drm_fb_helper_alloc_fbi(helper);
-   if (IS_ERR(fbi)) {
-   DRM_ERROR("failed to allocate fb info.\n");
-   ret = PTR_ERR(fbi);
-   goto out;
-   }
-
size = mode_cmd.pitches[0] * mode_cmd.height;

obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
@@ -152,7 +155,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,

if (IS_ERR(obj)) {
ret = PTR_ERR(obj);
-   goto err_release_fbi;
+   goto out;
}

exynos_fbdev->obj = obj;
@@ -164,10 +167,6 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
goto err_destroy_gem;
}

-   fbi->par = helper;
-   fbi->flags = FBINFO_FLAG_DEFAULT;
-   fbi->fbops = _drm_fb_ops;
-
ret = exynos_drm_fbdev_update(helper, sizes, obj);
if (ret < 0)
goto err_destroy_framebuffer;
@@ -179,8 +178,6 @@ err_destroy_framebuffer:
drm_framebuffer_cleanup(helper->fb);
 err_destroy_gem:
exynos_drm_gem_destroy(obj);
-err_release_fbi:
-   drm_fb_helper_release_fbi(helper);

 /*
  * if failed, all resources allocated above would be released by
-- 
1.9.1

[PATCH 3/9] drm/exynos: cleanup exynos_drm_fbdev_update()

[Joonyoung Shim]

It can get exynos_gem object via function argument, so no need to call
exynos_drm_fb_gem_obj() in exynos_drm_fbdev_update.

It also can get struct drm_framebuffer *fb via helper->fb, so can remove
a function argument for it.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 25170e2..4ef8739 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -75,11 +75,11 @@ static struct fb_ops exynos_drm_fb_ops = {
 };

 static int exynos_drm_fbdev_update(struct drm_fb_helper *helper,
-struct drm_fb_helper_surface_size *sizes,
-struct drm_framebuffer *fb)
+  struct drm_fb_helper_surface_size *sizes,
+  struct exynos_drm_gem_obj *obj)
 {
struct fb_info *fbi = helper->fbdev;
-   struct exynos_drm_gem_obj *obj;
+   struct drm_framebuffer *fb = helper->fb;
unsigned int size = fb->width * fb->height * (fb->bits_per_pixel >> 3);
unsigned int nr_pages;
unsigned long offset;
@@ -87,13 +87,6 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);

-   /* RGB formats use only one buffer */
-   obj = exynos_drm_fb_gem_obj(fb, 0);
-   if (!obj) {
-   DRM_DEBUG_KMS("gem object is null.\n");
-   return -EFAULT;
-   }
-
nr_pages = obj->size >> PAGE_SHIFT;

obj->kvaddr = (void __iomem *) vmap(obj->pages, nr_pages, VM_MAP,
@@ -175,7 +168,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
fbi->flags = FBINFO_FLAG_DEFAULT;
fbi->fbops = _drm_fb_ops;

-   ret = exynos_drm_fbdev_update(helper, sizes, helper->fb);
+   ret = exynos_drm_fbdev_update(helper, sizes, obj);
if (ret < 0)
goto err_destroy_framebuffer;

-- 
1.9.1

[PATCH 2/9] drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.c

[Joonyoung Shim]

The variable name "exynos_gem_obj" is too long, so some lines exceed 80
characters. It's simple to use "obj" instead of "exynos_gem_obj".

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8188b1f..25170e2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -32,7 +32,7 @@

 struct exynos_drm_fbdev {
struct drm_fb_helperdrm_fb_helper;
-   struct exynos_drm_gem_obj   *exynos_gem_obj;
+   struct exynos_drm_gem_obj   *obj;
 };

 static int exynos_drm_fb_mmap(struct fb_info *info,
@@ -40,7 +40,7 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
 {
struct drm_fb_helper *helper = info->par;
struct exynos_drm_fbdev *exynos_fbd = to_exynos_fbdev(helper);
-   struct exynos_drm_gem_obj *obj = exynos_fbd->exynos_gem_obj;
+   struct exynos_drm_gem_obj *obj = exynos_fbd->obj;
unsigned long vm_size;
int ret;

@@ -117,7 +117,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
struct drm_fb_helper_surface_size *sizes)
 {
struct exynos_drm_fbdev *exynos_fbdev = to_exynos_fbdev(helper);
-   struct exynos_drm_gem_obj *exynos_gem_obj;
+   struct exynos_drm_gem_obj *obj;
struct drm_device *dev = helper->dev;
struct fb_info *fbi;
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
@@ -146,27 +146,25 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,

size = mode_cmd.pitches[0] * mode_cmd.height;

-   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
+   obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
/*
 * If physically contiguous memory allocation fails and if IOMMU is
 * supported then try to get buffer from non physically contiguous
 * memory area.
 */
-   if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
+   if (IS_ERR(obj) && is_drm_iommu_supported(dev)) {
dev_warn(>dev, "contiguous FB allocation failed, falling 
back to non-contiguous\n");
-   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_NONCONTIG,
-   size);
+   obj = exynos_drm_gem_create(dev, EXYNOS_BO_NONCONTIG, size);
}

-   if (IS_ERR(exynos_gem_obj)) {
-   ret = PTR_ERR(exynos_gem_obj);
+   if (IS_ERR(obj)) {
+   ret = PTR_ERR(obj);
goto err_release_fbi;
}

-   exynos_fbdev->exynos_gem_obj = exynos_gem_obj;
+   exynos_fbdev->obj = obj;

-   helper->fb = exynos_drm_framebuffer_init(dev, _cmd,
-   _gem_obj->base);
+   helper->fb = exynos_drm_framebuffer_init(dev, _cmd, >base);
if (IS_ERR(helper->fb)) {
DRM_ERROR("failed to create drm framebuffer.\n");
ret = PTR_ERR(helper->fb);
@@ -187,7 +185,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
 err_destroy_framebuffer:
drm_framebuffer_cleanup(helper->fb);
 err_destroy_gem:
-   exynos_drm_gem_destroy(exynos_gem_obj);
+   exynos_drm_gem_destroy(obj);
 err_release_fbi:
drm_fb_helper_release_fbi(helper);

@@ -282,11 +280,11 @@ static void exynos_drm_fbdev_destroy(struct drm_device 
*dev,
  struct drm_fb_helper *fb_helper)
 {
struct exynos_drm_fbdev *exynos_fbd = to_exynos_fbdev(fb_helper);
-   struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd->exynos_gem_obj;
+   struct exynos_drm_gem_obj *obj = exynos_fbd->obj;
struct drm_framebuffer *fb;

-   if (exynos_gem_obj->kvaddr)
-   vunmap(exynos_gem_obj->kvaddr);
+   if (obj->kvaddr)
+   vunmap(obj->kvaddr);

/* release drm framebuffer and real buffer */
if (fb_helper->fb && fb_helper->fb->funcs) {
-- 
1.9.1

[PATCH 1/9] drm/exynos: remove exynos_drm_fb_set_buf_cnt()

[Joonyoung Shim]

The exynos_drm_fb_set_buf_cnt() is used to set buffer count only in
exynos_drm_fbdev_update(). This patch sets directly buffer count in
exynos_drm_framebuffer_init() without using exynos_drm_fb_set_buf_cnt(),
so there is no any reason to keep exynos_drm_fb_set_buf_cnt().

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c| 13 +++--
 drivers/gpu/drm/exynos/exynos_drm_fb.h|  4 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  3 ---
 3 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 9738f4e..effeb64 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -122,16 +122,6 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs = {
.dirty  = exynos_drm_fb_dirty,
 };

-void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
-   unsigned int cnt)
-{
-   struct exynos_drm_fb *exynos_fb;
-
-   exynos_fb = to_exynos_fb(fb);
-
-   exynos_fb->buf_cnt = cnt;
-}
-
 unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
 {
struct exynos_drm_fb *exynos_fb;
@@ -163,6 +153,9 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
exynos_fb->exynos_gem_obj[0] = exynos_gem_obj;

+   /* buffer count to framebuffer always is 1 at booting time. */
+   exynos_fb->buf_cnt = 1;
+
ret = drm_framebuffer_init(dev, _fb->fb, _drm_fb_funcs);
if (ret) {
kfree(exynos_fb);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 1c9e27c..897d2cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
@@ -25,10 +25,6 @@ struct exynos_drm_gem_obj *exynos_drm_fb_gem_obj(struct 
drm_framebuffer *fb,

 void exynos_drm_mode_config_init(struct drm_device *dev);

-/* set a buffer count to drm framebuffer. */
-void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
-   unsigned int cnt);
-
 /* get a buffer count to drm framebuffer. */
 unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 624595a..8188b1f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -103,9 +103,6 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
return -EIO;
}

-   /* buffer count to framebuffer always is 1 at booting time. */
-   exynos_drm_fb_set_buf_cnt(fb, 1);
-
offset = fbi->var.xoffset * (fb->bits_per_pixel >> 3);
offset += fbi->var.yoffset * fb->pitches[0];

-- 
1.9.1

[PATCH 0/9] drm/exynos: cleanup patchset for exynos_drm_fb/fbdev

[Joonyoung Shim]

Hi,

This patchset is for cleanup about fb and fbdev codes of exynos-drm
driver. This removes unnecesary and redundant codes mostly, and make a
variable having too long name to be short.

Thanks.

Joonyoung Shim (9):
  drm/exynos: remove exynos_drm_fb_set_buf_cnt()
  drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.c
  drm/exynos: cleanup exynos_drm_fbdev_update()
  drm/exynos: update fb_info via only one function
  drm/exynos: cleanup to get gem object for fb
  drm/exynos: update exynos_drm_framebuffer_init() for multiple buffers
  drm/exynos: cleanup exynos_user_fb_create()
  drm/exynos: remove exynos_drm_fb_get_buf_cnt()
  drm/exynos: remove buf_cnt from struct exynos_drm_fb

 drivers/gpu/drm/exynos/exynos_drm_fb.c| 115 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.h|  12 ++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  78 
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   2 +-
 4 files changed, 69 insertions(+), 138 deletions(-)

[PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support

[Maciej S. Szmigiero]

This patch adds support for United Radiant Technology
UMSH-8596MD-xT 7.0" WVGA TFT LCD panels
(both LVDS and parallel versions) to DRM
panel-simple driver.

Signed-off-by: Maciej Szmigiero 
---
This is a resend without changes.

diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt 
b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
new file mode 100644
index 000..2990e6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
@@ -0,0 +1,11 @@
+United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
+
+Supported are LVDS versions (-11T, -19T) and parallel ones
+(-T, -1T, -7T, -20T).
+
+Required properties:
+- compatible: should be "urt,umsh-8596md-lvds" for LVDS versions,
+  "urt,umsh-8596md-parallel" for parallel ones.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 66a33ae..234ce41 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -213,6 +213,7 @@ toshiba Toshiba Corporation
 toumaz Toumaz
 tplink TP-LINK Technologies Co., Ltd.
 truly  Truly Semiconductors Limited
+urtUnited Radiant Technology Corporation
 usiUniversal Scientific Industrial Co., Ltd.
 v3 V3 Semiconductor
 variscite  Variscite Ltd.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f94201b..be47fd7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1036,6 +1036,42 @@ static const struct panel_desc shelly_sca07010_bfn_lnn = 
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
 };

+static const struct display_timing urt_umsh_8596md_timing = {
+   .pixelclock = { 3326, 3326, 3326 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 41, 41, 41 },
+   .hback_porch = { 216 - 128, 216 - 128, 216 - 128 },
+   .hsync_len = { 71, 128, 128 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 10, 10, 10 },
+   .vback_porch = { 35 - 2, 35 - 2, 35 - 2 },
+   .vsync_len = { 2, 2, 2 },
+   .flags = DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE |
+   DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc urt_umsh_8596md_lvds = {
+   .timings = _umsh_8596md_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
+static const struct panel_desc urt_umsh_8596md_parallel = {
+   .timings = _umsh_8596md_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
 static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1125,6 +1161,12 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "shelly,sca07010-bfn-lnn",
.data = _sca07010_bfn_lnn,
}, {
+   .compatible = "urt,umsh-8596md-lvds",
+   .data = _umsh_8596md_lvds,
+   }, {
+   .compatible = "urt,umsh-8596md-parallel",
+   .data = _umsh_8596md_parallel,
+   }, {
/* sentinel */
}
 };

[PATCH] drm/exynos: fix exynos_drm_gem_prime_import_sg_table() error handling

[Joonyoung Shim]

On 08/31/2015 01:10 AM, Inki Dae wrote:
> 2015-08-27 17:31 GMT+09:00 Joonyoung Shim :
>> If exynos_drm_gem_init() is failed, the result is ERR_PTR, so we should
>> just return the result. If not, wrong porinter will be referenced from
>> err label.
>>
>> Reported-by: Dan Carpenter 
>> Signed-off-by: Joonyoung Shim 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 3e4a64a..4842a31 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -569,10 +569,8 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device 
>> *dev,
>> int ret;
>>
>> exynos_gem_obj = exynos_drm_gem_init(dev, attach->dmabuf->size);
>> -   if (IS_ERR(exynos_gem_obj)) {
>> -   ret = PTR_ERR(exynos_gem_obj);
>> -   goto err;
>> -   }
>> +   if (IS_ERR(exynos_gem_obj))
>> +   return exynos_gem_obj;
> 
> This patch incurs below build warning,
> 
> drivers/gpu/drm/exynos/exynos_drm_gem.c: In function
> 'exynos_drm_gem_prime_import_sg_table':
> drivers/gpu/drm/exynos/exynos_drm_gem.c:670:3: warning: return from
> incompatible pointer type [enabled by default]

Oops, i didn't check this warning.

> 
> We can simply return ERR_PTR(ret) and I just fixed it.
> 

Is it better to just return (void *)exynos_gem_obj instead of exynos_gem_obj?

[PATCH libdrm] amdgpu: use EINVAL instead of EBADMSG in amdgpu_bo_cpu_unmap()

[Christian König]

On 01.09.2015 13:37, Jonathan Gray wrote:
> EBADMSG is a streams errno.  OpenBSD does not implement streams and does
> include the streams errnos, this commit fixes the build on OpenBSD.
>
> None of the callers of this function check the return value for -EBADMSG.
>
> Signed-off-by: Jonathan Gray 

Probably not intentional to use this error code here.

Patch is Reviewed-by: Christian König 

Regards,
Christian.

> ---
>   amdgpu/amdgpu_bo.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> index 220422d..348da00 100644
> --- a/amdgpu/amdgpu_bo.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -482,7 +482,7 @@ int amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
>   if (bo->cpu_map_count == 0) {
>   /* not mapped */
>   pthread_mutex_unlock(>cpu_access_mutex);
> - return -EBADMSG;
> + return -EINVAL;
>   }
>   
>   bo->cpu_map_count--;

[PATCH] scripts/kernel-doc: Improve Markdown results

[Danilo Cesar Lemes de Paula]

On 08/21/2015 04:39 PM, Danilo Cesar Lemes de Paula wrote:
> Using pandoc as the Markdown engine cause some minor side effects as
> pandoc includes  main  tags for almost everything.
> Original Markdown support approach removes those main tags, but it caused
> some inconsistencies when that tag is not the main one, like:
> ..
> ...
> 
> As kernel-doc was already including a  tag, it causes the presence
> of double  tags (), which is not supported by DocBook
> spec.
> 
> Html target gets away with it, so it causes no harm, although other
> targets might not be so lucky (pdf as example).
> 
> We're now delegating the inclusion of the main  tag to pandoc
> only, as it knows when it's necessary or not.
> 
> That behavior causes a corner case, the only situation where we're
> certainly that  is not needed, which is the  content.
> For those cases, we're using a $output_markdown_nopara = 1 control var.
> 
> Signed-off-by: Danilo Cesar Lemes de Paula 
> Cc: Randy Dunlap 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: Jonathan Corbet 
> Cc: Herbert Xu 
> Cc: Stephan Mueller 
> Cc: Michal Marek 
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-doc at vger.kernel.org
> Cc: intel-gfx 
> Cc: dri-devel 
> Cc: Graham Whaley 
> ---
>  Thanks to Graham Whaley who helped me to debug this.
> 
>  scripts/kernel-doc | 48 ++--
>  1 file changed, 34 insertions(+), 14 deletions(-)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 3850c1e..12a106c 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -288,6 +288,7 @@ my $use_markdown = 0;
>  my $verbose = 0;
>  my $output_mode = "man";
>  my $output_preformatted = 0;
> +my $output_markdown_nopara = 0;
>  my $no_doc_sections = 0;
>  my @highlights = @highlights_man;
>  my $blankline = $blankline_man;
> @@ -529,8 +530,11 @@ sub markdown_to_docbook {
>   close(CHLD_OUT);
>   close(CHLD_ERR);
>  
> - # pandoc insists in adding Main , we should remove them.
> - $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
> + if ($output_markdown_nopara) {
> + # pandoc insists in adding Main , sometimes we
> + # want to remove them.
> + $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
> + }
>  
>   return $content;
>  }
> @@ -605,7 +609,7 @@ sub output_highlight {
>   $line =~ s/^\s*//;
>   }
>   if ($line eq ""){
> - if (! $output_preformatted) {
> + if (! $output_preformatted && ! $use_markdown) {
>   print $lineprefix, local_unescape($blankline);
>   }
>   } else {
> @@ -1026,7 +1030,7 @@ sub output_section_xml(%) {
>   # programlisting is already included by pandoc
>   print "\n" unless $use_markdown;
>   $output_preformatted = 1;
> - } else {
> + } elsif (! $use_markdown) {
>   print "\n";
>   }
>   output_highlight($args{'sections'}{$section});
> @@ -1034,7 +1038,7 @@ sub output_section_xml(%) {
>   if ($section =~ m/EXAMPLE/i) {
>   print "\n" unless $use_markdown;
>   print "\n";
> - } else {
> + } elsif (! $use_markdown) {
>   print "\n";
>   }
>   print "\n";
> @@ -1066,7 +1070,9 @@ sub output_function_xml(%) {
>  print " " . $args{'function'} . "\n";
>  print " \n";
>  print "  ";
> +$output_markdown_nopara = 1;
>  output_highlight ($args{'purpose'});
> +$output_markdown_nopara = 0;
>  print " \n";
>  print "\n";
>  
> @@ -1104,10 +1110,12 @@ sub output_function_xml(%) {
>   $parameter_name =~ s/\[.*//;
>  
>   print "  \n   
> $parameter\n";
> - print "   \n\n";
> + print "   \n";
> + print "\n" unless $use_markdown;
>   $lineprefix=" ";
>   output_highlight($args{'parameterdescs'}{$parameter_name});
> - print "\n   \n  \n";
> + print "\n" unless $use_markdown;
> + print "   \n  \n";
>   }
>   print " \n";
>  } else {
> @@ -1143,7 +1151,9 @@ sub output_struct_xml(%) {
>  print " " . $args{'type'} . " " . $args{'struct'} . 
> "\n";
>  print " \n";
>  print "  ";
> +$output_markdown_nopara = 1;
>  output_highlight ($args{'purpose'});
> +$output_markdown_nopara = 0;
>  print " \n";
>  print "\n";
>  
> @@ -1196,9 +1206,11 @@ sub output_struct_xml(%) {
>($args{'parameterdescs'}{$parameter_name} ne $undescribed) || next;
>print "";
>print "  $parameter\n";
> -  print "  \n";
> +  print "  \n";
> +  print " \n" unless $use_markdown;
>output_highlight($args{'parameterdescs'}{$parameter_name});
> -  print "  \n";
> +  print " \n" unless $use_markdown;
> +  print "  \n";
>print "\n";
>  }
>  print "  \n";
> @@ -1237,7 +1249,9 @@ sub output_enum_xml(%) {
>  print " enum " . $args{'enum'} . "\n";
>  print " \n";
>  print "  

[Intel-gfx] [PATCH 4/5] Documentation: drm: Convert KMS Properties HTML table to CALS

[Danilo Cesar Lemes de Paula]

On 08/25/2015 01:10 PM, Graham Whaley wrote:
> On Tue, 2015-08-25 at 16:29 +0200, Daniel Vetter wrote:
>> On Tue, Aug 25, 2015 at 10:26:44AM +0100, Graham Whaley wrote:
>>> The KMS Properties table is in HTML format, which is not supported
>>> for building pdfdocs, resulting in the following types of errors:
>>>
>>>  jade:/Documentation/DocBook/drm.xml:34413:15:E: there is no
>>> attribute
>>>  "border"
>>>  jade:/Documentation/DocBook/drm.xml:34413:31:E: there is no
>>> attribute
>>>  "cellpadding"
>>>  jade:/Documentation/DocBook/drm.xml:34413:47:E: there is no
>>> attribute
>>>  "cellspacing"
>>>  jade:/Documentation/DocBook/drm.xml:34414:7:E: document type does
>>> not
>>>  allow element "tbody" here
>>>
>>> Convert the table over to a CALS format table
>>
>> Hm, long-term plan was to move this table into DOC: comments in the
>> source-code using markdown, which we now have (at least in
>> drm-intel-nightly and also planned to be merged into 4.4). Since this
>> is
>> both a lot of churn I'd like to get there in just 1 step ...
>> -Daniel
> First - I've just noted an erroneous debug comment (or two) left in
> this patch as well, so looks like I will have to re-issue the series
> anyway.
> 
> OK. I guess this comes down to a matter of timing...
> From Danilos patch of: f6d6913 (drm/doc: Convert to markdown)
> we can see markdown does not natively support tables, and we'd have to
> make this a fixed width layout like the one in that patch I suspect.
> Danilo - any advice on how you did that other table conversion? I just
> did a pandoc docbook->markdown_github and it looks some way there - but
> of course seems to have not honored the multi-column items, of which
> there are a few. It's probably not too bad to fix up by hand - I'll see
> if I can get that to work...

Hi Graham,

To be honest I didn't have to do any conversion as that table was
already in the header file. I just added 4 spaces so it would be
transformed into fixed width.

However, there's tool you can use to help you: http://pandoc.org/try/
I did a lot of translation there. If your table doesn't have any
spancells, you can put the HTML code there and get the Markdown for free.

Danilo

[PATCH] scripts/kernel-doc: Processing -nofunc for functions only

[Danilo Cesar Lemes de Paula]

Docproc process EXPORT_SYMBOL(f1) macro and uses -nofunc f1 to
avoid duplicated documentation in the next call.
It works for most of the cases, but there are some specific situations
where a struct has the same name of an already-exported function.

Current kernel-doc behavior ignores those structs and do not add them
to the final documentation. This patch fixes it.

This is non-usual and the only case I've found is the drm_modeset_lock
(function and struct) defined in drm_modeset_lock.h and
drm_modeset_lock.c. Considering this, it should only affect the DRM
documentation by including struct drm_modeset_lock to the final Docbook.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Daniel Vetter 
Cc: Jonathan Corbet 
Cc: Andrew Morton 
Cc: Johannes Berg 
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 scripts/kernel-doc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 12a106c..047deb7 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1827,7 +1827,7 @@ sub output_declaration {
 my $func = "output_${functype}_$output_mode";
 if (($function_only==0) ||
( $function_only == 1 && defined($function_table{$name})) ||
-   ( $function_only == 2 && !defined($function_table{$name})))
+   ( $function_only == 2 && !($functype eq "function" && 
defined($function_table{$name}
 {
&$func(@_);
$section_counter++;
-- 
2.4.3

[PATCH v4 16/16] drm: bridge: analogix/dp: add edid modes parse in get_modes method

[Yakir Yang]

Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Add edid modes parse support

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 31 ---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
 2 files changed, 40 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 499ec57..c71e5f6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -111,7 +111,7 @@ static unsigned char 
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)

 static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 {
-   unsigned char edid[EDID_BLOCK_LENGTH * 2];
+   unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -908,12 +908,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}

-   ret = analogix_dp_handle_edid(dp);
-   if (ret) {
-   dev_err(dp->dev, "unable to handle edid\n");
-   return;
-   }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
 dp->video_info.max_link_rate);
if (ret) {
@@ -972,8 +966,24 @@ static int analogix_dp_get_modes(struct drm_connector 
*connector)
 {
struct analogix_dp_device *dp = connector_to_dp(connector);
struct analogix_dp_plat_data *plat_data = dp->plat_data;
+   struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;

+   if (dp->plat_data && dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EINVAL;
+   }
+   }
+
+   if (analogix_dp_handle_edid(dp)) {
+   dev_err(dp->dev, "unable to handle edid\n");
+   return -EINVAL;
+   }
+
+   drm_mode_connector_update_edid_property(connector, edid);
+   num_modes += drm_add_edid_modes(connector, edid);
+
if (plat_data && plat_data->panel)
num_modes += drm_panel_get_modes(plat_data->panel);

@@ -1055,13 +1065,6 @@ static void analogix_dp_bridge_enable(struct drm_bridge 
*bridge)
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
return;

-   if (dp->plat_data && dp->plat_data->panel) {
-   if (drm_panel_prepare(dp->plat_data->panel)) {
-   DRM_ERROR("failed to setup the panel\n");
-   return;
-   }
-   }
-
if (dp->plat_data && dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 6960ab3..5348b1b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5

+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR   0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH  0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM  0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x)   (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x)   (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x)  (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x)  (((x) >> 0) & 0x3)
+
 enum link_rate_type {
LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolneed_force_hpd;
+   unsigned char   edid[EDID_BLOCK_LENGTH * 2];

struct analogix_dp_plat_data *plat_data;
 };
@@ -260,27 +283,4 @@ int analogix_dp_is_video_stream_on(struct 
analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device 

[PATCH v4 15/16] drm: bridge: analogix/dp: move hpd detect to connector detect function

[Yakir Yang]

This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Jingoo suggest, add commit messages.

Changes in v3:
- move dp hpd detect to connector detect function.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e6b328a..499ec57 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -908,12 +908,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}

-   ret = analogix_dp_detect_hpd(dp);
-   if (ret) {
-   /* Cable has been disconnected, we're done */
-   return;
-   }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -949,6 +943,12 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
 static enum drm_connector_status
 analogix_dp_detect(struct drm_connector *connector, bool force)
 {
+   struct analogix_dp_device *dp = connector_to_dp(connector);
+
+   if (analogix_dp_detect_hpd(dp))
+   /* Cable has been disconnected, we're done */
+   return connector_status_disconnected;
+
return connector_status_connected;
 }

-- 
2.1.2

[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Yakir Yang]

Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.

This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
  hpd when hpd detect failed.

Changes in v2: None

 .../devicetree/bindings/drm/bridge/analogix_dp.txt |  4 ++-
 .../bindings/video/analogix_dp-rockchip.txt|  1 +
 .../devicetree/bindings/video/exynos_dp.txt|  1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 +++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
 6 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
index f54dc3e..c310367 100644
--- a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".

 Optional properties for dp-controller:
+   -analogix,need-force-hpd:
+   Indicate driver need force hpd when hpd detect failed, this
+   is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/video/exynos_dp.txt
* 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt

-
 [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
 ---

diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
index 502483e..8b9ed7d 100644
--- a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
@@ -28,6 +28,7 @@ For the below properties, please refer to Analogix DP binding 
document:
 - phys (required)
 - phy-names (required)
 - hpd-gpios (optional)
+- analogix,need-force-hpd (optional)
 ---

 Example:
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt 
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index ea03b3a..4f06e80 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding 
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+   -analogix,need-force-hpd (optional)
-video interfaces (optional)

 Deprecated properties for DisplayPort:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f7227ec..e6b328a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -63,15 +63,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
 {
int timeout_loop = 0;

-   while (analogix_dp_get_plug_in_status(dp) != 0) {
+   while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+   if (analogix_dp_get_plug_in_status(dp) == 0)
+   return 0;
+
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
-   dev_err(dp->dev, "failed to get hpd plug status\n");
-   return -ETIMEDOUT;
-   }
usleep_range(10, 11);
}

+   /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+   if (!dp->need_force_hpd)
+   return -ETIMEDOUT;
+
+   /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+   dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+   analogix_dp_force_hpd(dp);
+
+   if (analogix_dp_get_plug_in_status(dp) != 0) {
+   dev_err(dp->dev, "failed to get hpd plug in status\n");
+   return -EINVAL;
+   }
+
+   dev_dbg(dp->dev, "success to get plug in status after force hpd\n");
+
return 0;
 }

@@ -1287,6 +1310,9 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device 

[PATCH v2 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed

[Ville Syrjälä]

On Tue, Sep 01, 2015 at 11:14:43AM +0200, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 10:55:06PM +0300, ville.syrjala at linux.intel.com 
> wrote:
> > From: Ville Syrjälä 
> > 
> > Calculate the number of retries we should do for each i2c-over-aux
> > message based on the time it takes to perform the i2c transfer vs. the
> > aux transfer. We assume the shortest possible length for the aux
> > transfer, and the longest possible (exluding clock stretching) for the
> > i2c transfer.
> > 
> > The DP spec has some examples on how to calculate this, but we don't
> > calculate things quite the same way. The spec doesn't account for the
> > retry interval (assumes immediate retry on defer), and doesn't assume
> > the best/worst case behaviour as we do.
> > 
> > Note that currently we assume 10 kHz speed for the i2c bus. Some real
> > world devices (eg. some Apple DP->VGA dongle) fails with less than 16
> > retries. and that would correspond to something close to 15 kHz (with
> > our method of calculating things) But let's just go for 10 kHz to be
> > on the safe side. Ideally we should query/set the i2c bus speed via
> > DPCD but for now this should at leaast remove the regression from the
> > 1->16 byte trasnfer size change. And of course if the sink completes
> > the transfer quicker this shouldn't slow things down since we don't
> > change the interval between retries.
> > 
> > I did a few experiments with a DP->DVI dongle I have that allows you
> > to change the i2c bus speed. Here are the results of me changing the
> > actual bus speed and the assumed bus speed and seeing when we start
> > to fail the operation:
> > 
> > actual i2c khz  assumed i2c khz max retries
> > 1   1 ok -> 2 fail  211 ok -> 106 fail
> > 5   8 ok -> 9 fail  27 ok -> 24 fail
> > 10  17 ok -> 18 fail13 ok -> 12 fail
> > 100 210 ok -> 211 fail  2 ok -> 1 fail
> > 
> > So based on that we have a fairly decent safety margin baked into
> > the formula to calculate the max number of retries.
> > 
> > Fixes a regression with some DP dongles from:
> > commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd
> > Author: Simon Farnsworth 
> > Date:   Tue Feb 10 18:38:08 2015 +
> > 
> > drm/dp: Use large transactions for I2C over AUX
> > 
> > v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
> > Add a define our AUX retry interval and account for it
> > 
> > Cc: Simon Farnsworth 
> > Cc: moosotc at gmail.com
> > Tested-by: moosotc at gmail.com
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 81 
> > -
> >  1 file changed, 79 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 7069e54..23b9fcc 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -424,6 +424,78 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
> > *adapter)
> >I2C_FUNC_10BIT_ADDR;
> >  }
> >  
> > +#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
> > +#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
> > +#define AUX_STOP_LEN 4
> > +#define AUX_CMD_LEN 4
> > +#define AUX_ADDRESS_LEN 20
> > +#define AUX_REPLY_PAD_LEN 4
> > +#define AUX_LENGTH_LEN 8
> > +
> > +/*
> > + * Calculate the length of the AUX request/reply. Gives the "best"
> > + * case estimate, ie. successful while as short as possible.
> > + */
> > +static int drm_dp_aux_req_len(const struct drm_dp_aux_msg *msg)
> > +{
> > +   int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
> > +   AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
> > +
> > +   if ((msg->request & DP_AUX_I2C_READ) == 0)
> > +   len += msg->size * 8;
> > +
> > +   return len;
> > +}
> > +
> > +static int drm_dp_aux_reply_len(const struct drm_dp_aux_msg *msg)
> > +{
> > +   int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
> > +   AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
> > +
> > +   /*
> > +* For read we expect what was asked. For writes there will
> > +* be 0 or 1 data bytes. Assume 0 for the "best" case.
> > +*/
> > +   if (msg->request & DP_AUX_I2C_READ)
> > +   len += msg->size * 8;
> > +
> > +   return len;
> > +}
> > +
> > +#define I2C_START_LEN 1
> > +#define I2C_STOP_LEN 1
> > +#define I2C_ADDR_LEN 9 /* ADDRESS + R/W + ACK/NACK */
> > +#define I2C_DATA_LEN 9 /* DATA + ACK/NACK */
> > +
> > +/*
> > + * Calculate the length of the i2c transfer (in AUX clocks)
> > + * assuming the i2c bus speed is as specified. Gives the the
> > + * "worst" case estimate, ie. successful while as long as possible.
> > + * Doesn't account the the "MOT" bit, and instead assumes each
> > + * message includes a START, ADDRESS and STOP. Neither does it
> > + * account for additional 

[PATCH v4 13/16] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

[Yakir Yang]

There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Thierry suggest, seprate the link-rate and lane-count limit
  out with the device_type flag.

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 +--
 2 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f0db92e..f7227ec 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -897,8 +897,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}

-   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-dp->video_info.link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+dp->video_info.max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1201,18 +1201,27 @@ static int analogix_dp_create_bridge(struct drm_device 
*drm_dev,
 static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
 {
struct device_node *dp_node = dp->dev->of_node;
-   struct video_info *video_config = >video_info;
-
-   if (of_property_read_u32(dp_node, "samsung,link-rate",
-_info->link_rate)) {
-   dev_err(dev, "failed to get link-rate\n");
-   return -EINVAL;
-   }
+   struct video_info *video_info = >video_info;

-   if (of_property_read_u32(dp_node, "samsung,lane-count",
-_info->lane_count)) {
-   dev_err(dev, "failed to get lane-count\n");
-   return -EINVAL;
+   switch (dp->plat_data && dp->plat_data->dev_type) {
+   case RK3288_DP:
+   /*
+* Like Rk3288 DisplayPort TRM indicate that "Main link
+* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+*/
+   video_info->max_link_rate = 0x0A;
+   video_info->max_lane_count = 0x04;
+   break;
+   case EXYNOS_DP:
+   /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+   of_property_read_u32(dp_node, "samsung,link-rate",
+_info->max_link_rate);
+   of_property_read_u32(dp_node, "samsung,lane-count",
+_info->max_lane_count);
+   break;
}

return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 6e3d5bc..d8945e2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -129,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;

-   enum link_rate_type link_rate;
-   enum link_lane_count_type lane_count;
+   enum link_rate_type max_link_rate;
+   enum link_lane_count_type max_lane_count;
 };

 struct link_train {
-- 
2.1.2

[PATCH v4 12/16] drm: bridge: analogix/dp: add some rk3288 special registers setting

[Yakir Yang]

RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12 
 2 files changed, 60 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 6a643be..15346fe 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
 #include 
 #include 

+#include 
+
 #include "analogix_dp_core.h"
 #include "analogix_dp_reg.h"

@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device 
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);

+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+   writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+   writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+   writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+   writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+   writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+   }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);

@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
   bool enable)
 {
u32 reg;
+   u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+   phy_pd_addr = ANALOGIX_DP_PD;

switch (block) {
case AUX_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH3_BLOCK:
if (enable) {
-   reg = 

[PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support

[Yakir Yang]

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add GNU license v2 declared and samsung copyright

 drivers/gpu/drm/exynos/exynos_dp.c  |  1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |  1 +
 include/drm/bridge/analogix_dp.h| 16 
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
b/drivers/gpu/drm/exynos/exynos_dp.c
index 6060d2c..40ef727 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -224,6 +224,7 @@ static int exynos_dp_bind(struct device *dev, struct device 
*master, void *data)
dp->dev = dev;
dp->drm_dev = drm_dev;

+   dp->plat_data.dev_type = EXYNOS_DP;
dp->plat_data.power_on = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
dp->plat_data.get_modes = exynos_dp_get_modes;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index efea045..4934271 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -293,6 +293,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
return ret;
}

+   dp->plat_data.dev_type = RK3288_DP;
dp->plat_data.attach = NULL;
dp->plat_data.get_modes = NULL;
dp->plat_data.power_on = rockchip_dp_poweron;
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 8b4ffad..7209a64 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -1,9 +1,25 @@
+/*
+ * Analogix Core DP (Display Port) interface driver.
+ *
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
 #ifndef _ANALOGIX_DP_H_
 #define _ANALOGIX_DP_H_

 #include 

+enum analogix_dp_devtype {
+   EXYNOS_DP,
+   RK3288_DP,
+};
+
 struct analogix_dp_plat_data {
+   enum analogix_dp_devtype dev_type;
struct drm_panel *panel;

int (*power_on)(struct analogix_dp_plat_data *);
-- 
2.1.2

[PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

This phy driver would control the Rockchip DisplayPort module
phy clock and phy power, it is relate to analogix_dp-rockchip
dp driver. If you want DP works rightly on rockchip platform,
then you should select both of them.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Kishon suggest, add commit message, and remove the redundant
  rockchip_dp_phy_init() function, move those code to probe() method.
  And remove driver .owner number.

Changes in v3:
- Take Heiko suggest, add rockchip dp phy driver,
  collect the phy clocks and power control.

Changes in v2: None

 .../devicetree/bindings/phy/rockchip-dp-phy.txt|  26 
 drivers/phy/Kconfig|   7 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-rockchip-dp.c  | 166 +
 4 files changed, 200 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
 create mode 100644 drivers/phy/phy-rockchip-dp.c

diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..5de1088
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,26 @@
+Rockchip Soc Seroes Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+
+- reg : a list of registers used by phy driver
+- clocks: from common clock binding: handle to dp clock.
+   of memory mapped region.
+- clock-names: from common clock binding:
+   Required elements: "sclk_dp" "sclk_dp_24m"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: phy at ff770274 {
+   compatilble = "rockchip,rk3288-dp-phy";
+   reg = <0xff770274 4>;
+   rockchip,grf = <>;
+   clocks = < SCLK_EDP_24M>;
+   clock-names = "24m";
+   #phy-cells = <0>;
+}
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573..8f2bc4f 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.

+config PHY_ROCKCHIP_DP
+   tristate "Rockchip Display Port PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip Display Port PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..e281f35 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..e9a726e
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,166 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
+
+#define DP_PHY_SIDDQ_WRITE_EN   BIT(21)
+#define DP_PHY_SIDDQ_ON 0
+#define DP_PHY_SIDDQ_OFFBIT(5)
+
+struct rockchip_dp_phy {
+   struct device  *dev;
+   struct regmap  *grf;
+   void __iomem   *regs;
+   struct clk *phy_24m;
+};
+
+static int rockchip_dp_phy_clk_enable(struct rockchip_dp_phy *dp)
+{
+   int ret = 0;
+
+   ret = clk_set_rate(dp->phy_24m, 2400);
+   if (ret < 0) {
+   dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(dp->phy_24m);
+   if (ret < 0) {
+   dev_err(dp->dev, "cannot enable clock phy_24m %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int rockchip_dp_phy_clk_disable(struct rockchip_dp_phy *dp)
+{
+   clk_disable_unprepare(dp->phy_24m);
+
+   return 0;
+}

[PATCH v4 09/16] drm: rockchip: add bpc and color mode setting

[Yakir Yang]

From: Mark Yao 

Add bpc and color mode setting in rockchip_drm_vop driver, so
connector could try to use the edid drm_display_info to config
vop output mode.

Signed-off-by: Mark Yao 
Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 46 +++--
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 33 --
 4 files changed, 68 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index cebff9e..efea045 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -11,11 +11,6 @@
  * Free Software Foundation; either version 2 of the License, or (at your
  * option) any later version.
  */
-#include 
-#include 
-#include 
-#include 
-#include 

 #include 
 #include 
@@ -27,6 +22,13 @@
 #include 
 #include 

+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include 

 #include "rockchip_drm_drv.h"
@@ -125,20 +127,44 @@ static void rockchip_dp_drm_encoder_mode_set(struct 
drm_encoder *encoder,
/* do nothing */
 }

+static drm_connector *rockchip_dp_get_connector(struct rockchip_dp_device *dp)
+{
+   struct drm_connector *connector;
+   struct drm_device *drm_dev = dp->drm_dev;
+
+   drm_for_each_connector(connector, drm_dev) {
+   if (connector->encoder != >encoder)
+   return connector;
+   }
+
+   return NULL;
+}
+
 static void rockchip_dp_drm_encoder_prepare(struct drm_encoder *encoder)
 {
struct rockchip_dp_device *dp = encoder_to_dp(encoder);
+   struct drm_connector *connector;
+   int ret = 0;
u32 val;
-   int ret;

-   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
-   DRM_MODE_CONNECTOR_eDP,
-   ROCKCHIP_OUT_MODE_);
-   if (ret < 0) {
+   connector = rockchip_dp_get_connector(dp);
+   if (!connector) {
+   DRM_ERROR("Failed to get connector by encoder[%p]\n", encoder);
+   return;
+   }
+
+   if (connector->display_info.color_formats | DRM_COLOR_FORMAT_RGB444)
+   ret = rockchip_drm_crtc_mode_config(
+   encoder->crtc, DRM_MODE_CONNECTOR_eDP,
+   connector->display_info.bpc, DRM_COLOR_FORMAT_RGB444);
+   if (!ret) {
dev_err(dp->dev, "Could not set crtc mode config: %d.\n", ret);
return;
}

+   connector->display_info.bpc = ret;
+   connector->display_info.color_formats = DRM_COLOR_FORMAT_RGB444;
+
ret = rockchip_drm_encoder_get_mux_id(dp->dev->of_node, encoder);
if (ret < 0)
return;
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..428a3c1 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -215,7 +215,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct 
drm_encoder *encoder)
 static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
 {
rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
+ 10, DRM_COLOR_FORMAT_RGB444);
 }

 static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs = 
{
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..ef1d7fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -59,7 +59,7 @@ void rockchip_unregister_crtc_funcs(struct drm_device *dev, 
int pipe);
 int rockchip_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder);
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
- int out_mode);
+ int bpc, int color);
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 34b78e7..5d7f9b6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -811,14 +811,41 @@ static const struct drm_plane_funcs vop_plane_funcs = {

 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
  int connector_type,
- int 

[PATCH v4 08/16] drm: rockchip/dp: add rockchip platform dp driver

[Yakir Yang]

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.

Changes in v3:
- Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
  dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
  core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform
  driver which name to "pclk".
- Take Heiko suggest, add devicetree binding document.
- Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
  point to get panel node.
- Add the new function point analogix_dp_platdata.get_modes init.

Changes in v2:
- Take Heiko suggest, get panel node with remote-endpoint method,
  and create devicetree binding for driver.
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
  leave those clock to rockchip dp phy driver.

 .../bindings/video/analogix_dp-rockchip.txt|  74 
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 389 +
 4 files changed, 473 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c

diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
new file mode 100644
index 000..502483e
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
@@ -0,0 +1,74 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+  Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+   dp-controller: dp at ff97 {
+   compatible = "rockchip,rk3288-dp";
+   reg = <0xff97 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
+   clock-names = "dp", "pclk";
+   phys = <_phy>;
+   phy-names = "dp";
+
+   rockchip,grf = <>;
+   resets = < 111>;
+   reset-names = "dp";
+
+   status = "disabled";
+
+   ports {
+   edp_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_edp>;
+   };
+   edp_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_edp>;
+   };
+   };
+
+   edp_out: port at 1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_out_panel: endpoint {
+   reg = <0>;
+   remote-endpoint = <_in_edp>
+   };
+   };
+   };
+   };
+
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..c2ba945 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_ANALOGIX_DP
+tristate "Rockchip specific extensions for Analogix DP driver"
+depends on DRM_ROCKCHIP
+select DRM_ANALOGIX_DP
+help
+ This selects support for 

[PATCH v4 07/16] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

[Yakir Yang]

After exynos_dp have been splited the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some samsung platform properties which
could be dynamic parsed from EDID/MODE/DPCD message, so this is an update for
exynos DTS file for dp-controller.

Beside analogix_dp have provide the backward compatibility, so there are no
bisectability break that make this change in a separate patch.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Krzysztof suggest, separate all DTS changes to a separate patch.

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-arndale.dts   | 2 --
 arch/arm/boot/dts/exynos5250-smdk5250.dts  | 2 --
 arch/arm/boot/dts/exynos5250-snow.dts  | 4 +---
 arch/arm/boot/dts/exynos5250-spring.dts| 4 +---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +---
 arch/arm/boot/dts/exynos5420-smdk5420.dts  | 2 --
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 4 +---
 7 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index db3f65f..4636862 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
  {
status = "okay";
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index c625e71..cd424d6 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@

  {
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 0720caa..242b621 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -244,12 +244,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;

ports {
port at 0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
-   samsung,hpd-gpio = < 0 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 0 GPIO_ACTIVE_HIGH>;
 };

  {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..7433683 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 6 0>;
+   hpd-gpio = < 6 0>;

ports {
port at 0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 98871f9..b3df3c1 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -92,8 +92,6 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386..b89bff5 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -142,12 +142,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;
panel = <>;
 };

-- 
2.1.2

[PATCH v4 06/16] Documentation: drm/bridge: add document for analogix_dp

[Yakir Yang]

Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt

Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Krzysztof suggest, split all DTS changes, and provide backward 
compatibility.
  Mark old properties as deprecated but still support them.
- Take Rob suggest, update "analogix,hpd-gpio" to "hpd-gpios" prop name.
- Take Thierry suggest, deprecated some properties which could parsed from 
Edid/Mode/DPCD.
"analogix,color-space" & "analogix,color-depth"   &
"analogix,link-rate"   & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high"  & "interlaces"

Changes in v3:
- Take Heiko suggest, add devicetree binding documents.
- Take Thierry Reding suggest, remove sync pol & colorimetry properies
  from the new analogix dp driver devicetree binding.
- Update the exist exynos dtsi file with the latest DP DT properies.

Changes in v2: None

 .../devicetree/bindings/drm/bridge/analogix_dp.txt | 50 +
 .../devicetree/bindings/video/exynos_dp.txt| 63 --
 2 files changed, 71 insertions(+), 42 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
new file mode 100644
index 000..f54dc3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+   -compatible:
+   platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+   -reg:
+   physical base address of the controller and length
+   of memory mapped region.
+   -interrupts:
+   interrupt combiner values.
+   -clocks:
+   from common clock binding: handle to dp clock.
+   -clock-names:
+   from common clock binding: Shall be "dp".
+   -interrupt-parent:
+   phandle to Interrupt combiner node.
+   -phys:
+   from general PHY binding: the phandle for the PHY device.
+   -phy-names:
+   from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+   -hpd-gpios:
+   Hotplug detect GPIO.
+   Indicates which GPIO should be used for hotplug detection
+   -port@[X]: SoC specific port nodes with endpoint definitions as defined
+   in Documentation/devicetree/bindings/media/video-interfaces.txt,
+   please refer to the SoC specific binding document:
+   * Documentation/devicetree/bindings/video/exynos_dp.txt
+   * 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+   dp-controller {
+   compatible = "samsung,exynos5-dp";
+   reg = <0x145b 0x1>;
+   interrupts = <10 3>;
+   interrupt-parent = <>;
+   clocks = < 342>;
+   clock-names = "dp";
+
+   phys = <_phy>;
+   phy-names = "dp";
+   };
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt 
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 7a3a9cd..ea03b3a 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
-   -samsung,color-space:
-   input video data format.
-   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
-   -samsung,dynamic-range:
-   dynamic range for input video data.
-   VESA = 0, CEA = 1
-   -samsung,ycbcr-coeff:
-   YCbCr co-efficients for input video.
-   COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
-   -samsung,color-depth:
-   number of bits per colour component.
-   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
-   -samsung,link-rate:
-   link rate supported by the panel.
-   LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
-   -samsung,lane-count:
-   number of lanes supported by the panel.
-   LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
+
+Optional properties for dp-controller:
- 

[PATCH v4 05/16] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & colorimetry

[Yakir Yang]

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code, same to color space and color depth can be
parsed from EDID.

But presumably Exynos still relaies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Krzysztof suggest, provide backword compatibility with samsung.
- Take Thierry suggest, add "color-depth" and "color-space" dynamic parsed.

Changes in v3:
- Take Thierry Reding suggest, dynamic parse video timing info from
  struct drm_display_mode and struct drm_display_info.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 141 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
 drivers/gpu/drm/exynos/exynos_dp.c |  58 -
 4 files changed, 151 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7196097..f0db92e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -897,8 +897,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}

-   ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1081,6 +1081,82 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }

+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *orig_mode,
+   struct drm_display_mode *mode)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   struct drm_display_info *display_info = >connector.display_info;
+   struct video_info *video_info = >video_info;
+   struct device_node *dp_node = dp->dev->of_node;
+   int vic;
+
+   /* interlaces & hsync pol & vsync pol */
+   video_info->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+   video_info->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+   video_info->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+   /* dynamic_range & colorimetry */
+   vic = drm_match_cea_mode(mode);
+   if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+   (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+   video_info->dynamic_range = CEA;
+   video_info->ycbcr_coeff = COLOR_YCBCR601;
+   } else if (vic) {
+   video_info->dynamic_range = CEA;
+   video_info->ycbcr_coeff = COLOR_YCBCR709;
+   } else {
+   video_info->dynamic_range = VESA;
+   video_info->ycbcr_coeff = COLOR_YCBCR709;
+   }
+
+   switch (display_info->bpc) {
+   case 12:
+   video_info->color_depth = COLOR_12;
+   break;
+   case 10:
+   video_info->color_depth = COLOR_10;
+   break;
+   case 8:
+   video_info->color_depth = COLOR_8;
+   break;
+   case 6:
+   video_info->color_depth = COLOR_6;
+   break;
+   default:
+   video_info->color_depth = COLOR_8;
+   break;
+   }
+
+   if (display_info->color_formats | DRM_COLOR_FORMAT_YCRCB444)
+   video_info->color_space = COLOR_YCBCR444;
+   else if (display_info->color_formats | DRM_COLOR_FORMAT_YCRCB422)
+   video_info->color_space = COLOR_YCBCR422;
+   else if (display_info->color_formats | DRM_COLOR_FORMAT_RGB444)
+   video_info->color_space = COLOR_RGB;
+   else
+   video_info->color_space = COLOR_RGB;
+
+   /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+   of_property_read_u32(dp_node, "samsung,color-space",
+_info->color_space);
+   of_property_read_u32(dp_node, "samsung,dynamic-range",
+_info->dynamic_range);
+   of_property_read_u32(dp_node, "samsung,ycbcr-coeff",
+_info->ycbcr_coeff);
+   of_property_read_u32(dp_node, "samsung,color-depth",
+_info->color_depth);
+   of_property_read_u32(dp_node, "hsync-active-high",
+(unsigned int *)_info->h_sync_polarity);
+   

[PATCH v4 04/16] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count

[Yakir Yang]

link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.

Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Jingoo Han suggest, update commit message more readable.
- Adjust the order from 05 to 04

Changes in v3:
- Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
  the DT property value directly, but we can take those as hardware limite.
  For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
  so DT property would like "link-rate = 0x0a" "lane-count = 4".

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7d62f22..7196097 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -631,6 +631,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
analogix_dp_device *dp,
/*
 * For DP rev.1.1, Maximum link rate of Main Link lanes
 * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
 */
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, );
*bandwidth = data;
@@ -664,7 +666,8 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, >link_train.lane_count);

if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
-   (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+   (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+   (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -905,9 +908,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);

-   analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
-   analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index d7e47e0..ffabbd0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -21,8 +21,9 @@
 #define MAX_EQ_LOOP 5

 enum link_rate_type {
-   LINK_RATE_1_62GBPS = 0x06,
-   LINK_RATE_2_70GBPS = 0x0a
+   LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+   LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+   LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
 };

 enum link_lane_count_type {
-- 
2.1.2

[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

[Yakir Yang]

Split the dp core driver from exynos directory to bridge
directory, and rename the core driver to analogix_dp_*,
leave the platform code to analogix_dp-exynos.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery.
- Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to "exynos_dp.c"
- Take Archit suggest, create a separate folder for analogix code in bridge/

Changes in v3:
- Take Thierry Reding suggest, move exynos's video_timing code
  to analogix_dp-exynos platform driver, add get_modes method
  to struct analogix_dp_plat_data.
- Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".

Changes in v2:
- Take Jingoo Han suggest, remove new copyright
- Fix compiled failed dut to analogix_dp_device misspell

 drivers/gpu/drm/bridge/Kconfig |2 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/analogix/Kconfig|4 +
 drivers/gpu/drm/bridge/analogix/Makefile   |1 +
 .../analogix/analogix_dp_core.c}   |  817 ++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  283 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 1265 
 .../analogix/analogix_dp_reg.h}|  258 ++--
 drivers/gpu/drm/exynos/Kconfig |3 +-
 drivers/gpu/drm/exynos/Makefile|2 +-
 drivers/gpu/drm/exynos/exynos_dp.c |  306 +
 drivers/gpu/drm/exynos/exynos_dp_core.h|  282 -
 drivers/gpu/drm/exynos/exynos_dp_reg.c | 1259 ---
 include/drm/bridge/analogix_dp.h   |   24 +
 14 files changed, 2357 insertions(+), 2150 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
 rename drivers/gpu/drm/{exynos/exynos_dp_core.c => 
bridge/analogix/analogix_dp_core.c} (50%)
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
 rename drivers/gpu/drm/{exynos/exynos_dp_reg.h => 
bridge/analogix/analogix_dp_reg.h} (64%)
 create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
 create mode 100644 include/drm/bridge/analogix_dp.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2de52a5..7b5b77a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+source "drivers/gpu/drm/bridge/analogix/Kconfig"
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index e2eef1c..5366c6b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
 obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
b/drivers/gpu/drm/bridge/analogix/Kconfig
new file mode 100644
index 000..5ff6551
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -0,0 +1,4 @@
+config DRM_ANALOGIX_DP
+   tristate
+   depends on DRM
+   select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
b/drivers/gpu/drm/bridge/analogix/Makefile
new file mode 100644
index 000..9107b86
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp_core.o analogix_dp_reg.o
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
similarity index 50%
rename from drivers/gpu/drm/exynos/exynos_dp_core.c
rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bed0252..7d62f22 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1,14 +1,14 @@
 /*
- * Samsung SoC DP (Display Port) interface driver.
- *
- * Copyright (C) 2012 Samsung Electronics Co., Ltd.
- * Author: Jingoo Han 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
+* Analogix DP (Display Port) core interface driver.
+*
+* Copyright (C) 2012 Samsung Electronics Co., Ltd.
+* Author: Jingoo Han 
+*
+* This program is free software; you can redistribute it and/or modify it
+* under the terms of the GNU General Public License as published by the
+* Free Software Foundation; either version 2 of the License, or (at your
+* option) any later 

[PATCH v4 02/16] drm: exynos/dp: convert to drm bridge mode

[Yakir Yang]

In order to move exynos dp code to bridge directory,
we need to convert driver drm bridge mode first. As
dp driver already have a ptn3460 bridge, so we need
to move ptn bridge to the next bridge of dp bridge.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Romain suggest, rebase on linux-next branch.

Changes in v3: None
Changes in v2:
- Take Jingoo Han suggest, just remove my name from author list.

 drivers/gpu/drm/exynos/exynos_dp_core.c | 104 +++-
 drivers/gpu/drm/exynos/exynos_dp_core.h |   1 +
 2 files changed, 78 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 266f7f7..bed0252 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1001,9 +1001,9 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
 {
int ret;

-   encoder->bridge = dp->bridge;
-   dp->bridge->encoder = encoder;
-   ret = drm_bridge_attach(encoder->dev, dp->bridge);
+   encoder->bridge->next = dp->ptn_bridge;
+   dp->ptn_bridge->encoder = encoder;
+   ret = drm_bridge_attach(encoder->dev, dp->ptn_bridge);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
return ret;
@@ -1012,14 +1012,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
return 0;
 }

-static int exynos_dp_create_connector(struct drm_encoder *encoder)
+static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
+   struct drm_encoder *encoder = >encoder;
struct drm_connector *connector = >connector;
int ret;

/* Pre-empt DP connector creation if there's a bridge */
-   if (dp->bridge) {
+   if (dp->ptn_bridge) {
ret = exynos_drm_attach_lcd_bridge(dp, encoder);
if (!ret)
return 0;
@@ -1045,22 +1046,9 @@ static int exynos_dp_create_connector(struct drm_encoder 
*encoder)
return ret;
 }

-static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
-   return true;
-}
-
-static void exynos_dp_mode_set(struct drm_encoder *encoder,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
-{
-}
-
-static void exynos_dp_enable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

if (dp->dpms_mode == DRM_MODE_DPMS_ON)
@@ -1085,9 +1073,9 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
dp->dpms_mode = DRM_MODE_DPMS_ON;
 }

-static void exynos_dp_disable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

if (dp->dpms_mode != DRM_MODE_DPMS_ON)
@@ -1116,6 +1104,68 @@ static void exynos_dp_disable(struct drm_encoder 
*encoder)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }

+static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
+{
+   /* do nothing */
+}
+
+static const struct drm_bridge_funcs exynos_dp_bridge_funcs = {
+   .enable = exynos_dp_bridge_enable,
+   .disable = exynos_dp_bridge_disable,
+   .pre_enable = exynos_dp_bridge_nop,
+   .post_disable = exynos_dp_bridge_nop,
+   .attach = exynos_dp_bridge_attach,
+};
+
+static int exynos_dp_create_connector(struct drm_encoder *encoder)
+{
+   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct drm_device *drm_dev = dp->drm_dev;
+   struct drm_bridge *bridge;
+   int ret;
+
+   bridge = devm_kzalloc(drm_dev->dev, sizeof(*bridge), GFP_KERNEL);
+   if (!bridge) {
+   DRM_ERROR("failed to allocate for drm bridge\n");
+   return -ENOMEM;
+   }
+
+   dp->bridge = bridge;
+
+   bridge->driver_private = dp;
+   bridge->encoder = encoder;
+   bridge->funcs = _dp_bridge_funcs;
+
+   ret = drm_bridge_attach(drm_dev, bridge);
+   if (ret) {
+   DRM_ERROR("failed to attach drm bridge\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
+const struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static 

[PATCH v4 01/16] drm: exynos/dp: fix code style

[Yakir Yang]

After run "checkpatch.pl -f --subjective" command, I see there
are lots of alignment problem in exynos_dp driver, so let just
fix them.

- Take Romain suggest, rebase on linux-next branch

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
  avoid using some uncommon style like bellow:
  -  retval = exynos_dp_read_bytes_from_i2c(...
...)
  +  retval =
  +  exynos_dp_read_bytes_from_i2c(..);

 drivers/gpu/drm/exynos/exynos_dp_core.c | 226 
 drivers/gpu/drm/exynos/exynos_dp_core.h |  54 
 drivers/gpu/drm/exynos/exynos_dp_reg.c  | 106 +++
 3 files changed, 188 insertions(+), 198 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..266f7f7 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -115,8 +115,8 @@ static int exynos_dp_read_edid(struct exynos_dp_device *dp)

/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_EXTENSION_FLAG,
-   _block);
+ EDID_EXTENSION_FLAG,
+ _block);
if (retval)
return retval;

@@ -124,10 +124,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device 
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");

/* Read EDID data */
-   retval = exynos_dp_read_bytes_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   [EDID_HEADER_PATTERN]);
+   retval = exynos_dp_read_bytes_from_i2c(
+   dp, I2C_EDID_DEVICE_ADDR,
+   EDID_HEADER_PATTERN,
+   EDID_BLOCK_LENGTH,
+   [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -139,11 +140,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device 
*dp)
}

/* Read additional EDID data */
-   retval = exynos_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_BLOCK_LENGTH,
-   EDID_BLOCK_LENGTH,
-   [EDID_BLOCK_LENGTH]);
+   retval = exynos_dp_read_bytes_from_i2c(
+   dp, I2C_EDID_DEVICE_ADDR,
+   EDID_BLOCK_LENGTH,
+   EDID_BLOCK_LENGTH,
+   [EDID_BLOCK_LENGTH]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct exynos_dp_device 
*dp)
}

exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-   _vector);
+ _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
-   exynos_dp_write_byte_to_dpcd(dp,
-   DP_TEST_EDID_CHECKSUM,
+   exynos_dp_write_byte_to_dpcd(
+   dp, DP_TEST_EDID_CHECKSUM,
edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
-   exynos_dp_write_byte_to_dpcd(dp,
-   DP_TEST_RESPONSE,
+   exynos_dp_write_byte_to_dpcd(
+   dp, DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
}
} else {
dev_info(dp->dev, "EDID data does not include any 
extensions.\n");

/* Read EDID data */
-   retval = exynos_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   [EDID_HEADER_PATTERN]);
+   retval = exynos_dp_read_bytes_from_i2c(
+   dp, I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+   EDID_BLOCK_LENGTH, [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -183,16 

[PATCH v4 0/16] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi all,

   The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. 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 ;)

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

I have verified this series on two kinds of rockchip platform board, one
is rk3288 sdk board which connect with a 2K display port monitor, the other
is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
both of them works rightlly.

I haven't verified the dp function on samsung platform, cause I haven't got
exynos boards. I can only ensure that there are no build error on samsung
platform, wish some samsung guys help to test. ;)

Besides, The v4 version have been rebased on linux-next master branch
(git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git), tag name is
next-20150828 (latest is next-2015-0831). So I think if someone try to apply
this series, there would be no conflict  ;)

Thanks,
- Yakir

Changes in v4:
- Take Romain suggest, rebase on linux-next branch.
- Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery.
- Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to "exynos_dp.c"
- Take Archit suggest, create a separate folder for analogix code in bridge/
- Take Jingoo Han suggest, update commit message more readable.
- Adjust the order from 05 to 04
- Take Krzysztof suggest, provide backword compatibility with samsung.
- Take Thierry suggest, add "color-depth" and "color-space" dynamic parsed.
- Take Krzysztof suggest, split all DTS changes, and provide backward 
compatibility.
  Mark old properties as deprecated but still support them.
- Take Rob suggest, update "analogix,hpd-gpio" to "hpd-gpios" prop name.
- Take Thierry suggest, deprecated some properties which could parsed from 
Edid/Mode/DPCD.
"analogix,color-space" & "analogix,color-depth"   &
"analogix,link-rate"   & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high"  & "interlaces"
- Take Krzysztof suggest, separate all DTS changes to a separate patch.
- Remove some deprecated DT properties in rockchip dp document.
- Take Kishon suggest, add commit message, and remove the redundant
  rockchip_dp_phy_init() function, move those code to probe() method.
  And remove driver .owner number.
- Take Thierry suggest, seprate the link-rate and lane-count limit
  out with the device_type flag.
- Take Jingoo suggest, add commit messages.
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Take Thierry Reding suggest, move exynos's video_timing code
  to analogix_dp-exynos platform driver, add get_modes method
  to struct analogix_dp_plat_data.
- Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
- Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
  the DT property value directly, but we can take those as hardware limite.
  For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
  so DT property would like "link-rate = 0x0a" "lane-count = 4".
- Take Thierry Reding suggest, dynamic parse video timing info from
  struct drm_display_mode and struct drm_display_info.
- Take Heiko suggest, add devicetree binding documents.
- Take Thierry Reding suggest, remove sync pol & colorimetry properies
  from the new analogix dp driver devicetree binding.
- Update the exist exynos dtsi file with the latest DP DT properies.
- Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
  dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
  core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform
  driver which name to "pclk".
- Take Heiko suggest, add devicetree binding document.
- Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
  point to get panel node.
- Add the new function point analogix_dp_platdata.get_modes init.
- Take Heiko suggest, add rockchip dp phy driver,
  collect the phy clocks and power control.
- Add "analogix,need-force-hpd" to indicate whether driver need foce
  hpd when hpd detect failed.
- move dp hpd detect to connector detect function.
- Add edid modes parse support

Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
  avoid using some uncommon style like bellow:
  -  retval = 

[PATCH 3/9] drm/exynos: cleanup exynos_drm_fbdev_update()

[Gustavo Padovan]

Hi Joonyoung,

2015-09-01 Joonyoung Shim :

> It can get exynos_gem object via function argument, so no need to call
> exynos_drm_fb_gem_obj() in exynos_drm_fbdev_update.
> 
> It also can get struct drm_framebuffer *fb via helper->fb, so can remove
> a function argument for it.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 2/9] drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.c

[Gustavo Padovan]

Hi Joonyoung,

2015-09-01 Joonyoung Shim :

> The variable name "exynos_gem_obj" is too long, so some lines exceed 80
> characters. It's simple to use "obj" instead of "exynos_gem_obj".
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 30 ++
>  1 file changed, 14 insertions(+), 16 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 1/9] drm/exynos: remove exynos_drm_fb_set_buf_cnt()

[Gustavo Padovan]

Hi Joonyoung,

2015-09-01 Joonyoung Shim :

> The exynos_drm_fb_set_buf_cnt() is used to set buffer count only in
> exynos_drm_fbdev_update(). This patch sets directly buffer count in
> exynos_drm_framebuffer_init() without using exynos_drm_fb_set_buf_cnt(),
> so there is no any reason to keep exynos_drm_fb_set_buf_cnt().
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c| 13 +++--
>  drivers/gpu/drm/exynos/exynos_drm_fb.h|  4 
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  3 ---
>  3 files changed, 3 insertions(+), 17 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Tomi Valkeinen]

On 25/08/15 22:24, Rob Clark wrote:
> On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter  
> wrote:
>> When the usual fbcon legacy options are enabled we have
>> ->register_framebuffer
>>   ->fb notifier chain calls into fbcon
>> ->fbcon sets up console on new fbi
>>   ->fbi->set_par
>> ->drm_fb_helper_set_par exercises full kms api
>>
>> And because of locking inversion hilarity all of register_framebuffer
>> is done with the console lock held. Which means that the first time on
>> driver load we exercise _all_ the kms code (all probe paths and
>> modeset paths for everything connected) is under the console lock.
>> That means if anything goes belly-up in that big pile of code nothing
>> ever reaches logfiles (and the machine is dead).
>>
>> Usual tactic to debug that is to temporarily remove those console_lock
>> calls to be able to capture backtraces. I'm fed up writing this patch
>> and recompiling kernels. Hence this patch here to add an unsafe,
>> kernel-taining option to do this at runtime.
>>
>> Cc: Jean-Christophe Plagniol-Villard 
>> Cc: Tomi Valkeinen 
>> Cc: linux-fbdev at vger.kernel.org
>> Signed-off-by: Daniel Vetter 
> 
> This one was causing me some problems, if I tried to enable
> lockless_register_fb.  It *looks* like it should work, so I'm not
> quite sure what the deal is.  But I'm 110% fan of getting something
> like this working, because console_lock is pretty much the bane of kms
> developer's existence..
> 
> I'll have to debug further on a system where I can see more than the
> bottom three lines of the second to last backtrace..

Any idea if anyone has ever looked at properly fixing this?

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/1beb87ac/attachment.sig>

[Bug 91808] trine1 misrender r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91808

--- Comment #6 from Martin Bednar  ---
Created attachment 118033
  --> https://bugs.freedesktop.org/attachment.cgi?id=118033=edit
apitrace replay on nouveau (11.0 rc-1)

same scene as in report, without the reported rendering issue, and no obvious
other rendering issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/260f4190/attachment.html>

[PATCH v2 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed

[Jani Nikula]

On Tue, 01 Sep 2015, Daniel Vetter  wrote:
> On Wed, Aug 26, 2015 at 10:55:06PM +0300, ville.syrjala at linux.intel.com 
> wrote:
>> From: Ville Syrjälä 
>> 
>> Calculate the number of retries we should do for each i2c-over-aux
>> message based on the time it takes to perform the i2c transfer vs. the
>> aux transfer. We assume the shortest possible length for the aux
>> transfer, and the longest possible (exluding clock stretching) for the
>> i2c transfer.
>> 
>> The DP spec has some examples on how to calculate this, but we don't
>> calculate things quite the same way. The spec doesn't account for the
>> retry interval (assumes immediate retry on defer), and doesn't assume
>> the best/worst case behaviour as we do.
>> 
>> Note that currently we assume 10 kHz speed for the i2c bus. Some real
>> world devices (eg. some Apple DP->VGA dongle) fails with less than 16
>> retries. and that would correspond to something close to 15 kHz (with
>> our method of calculating things) But let's just go for 10 kHz to be
>> on the safe side. Ideally we should query/set the i2c bus speed via
>> DPCD but for now this should at leaast remove the regression from the
>> 1->16 byte trasnfer size change. And of course if the sink completes
>> the transfer quicker this shouldn't slow things down since we don't
>> change the interval between retries.
>> 
>> I did a few experiments with a DP->DVI dongle I have that allows you
>> to change the i2c bus speed. Here are the results of me changing the
>> actual bus speed and the assumed bus speed and seeing when we start
>> to fail the operation:
>> 
>> actual i2c khz  assumed i2c khz max retries
>> 1   1 ok -> 2 fail  211 ok -> 106 fail
>> 5   8 ok -> 9 fail  27 ok -> 24 fail
>> 10  17 ok -> 18 fail13 ok -> 12 fail
>> 100 210 ok -> 211 fail  2 ok -> 1 fail
>> 
>> So based on that we have a fairly decent safety margin baked into
>> the formula to calculate the max number of retries.
>> 
>> Fixes a regression with some DP dongles from:
>> commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd
>> Author: Simon Farnsworth 
>> Date:   Tue Feb 10 18:38:08 2015 +
>> 
>> drm/dp: Use large transactions for I2C over AUX
>> 
>> v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
>> Add a define our AUX retry interval and account for it
>> 
>> Cc: Simon Farnsworth 
>> Cc: moosotc at gmail.com
>> Tested-by: moosotc at gmail.com
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  drivers/gpu/drm/drm_dp_helper.c | 81 
>> -
>>  1 file changed, 79 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 7069e54..23b9fcc 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -424,6 +424,78 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
>> *adapter)
>> I2C_FUNC_10BIT_ADDR;
>>  }
>>  
>> +#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
>> +#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
>> +#define AUX_STOP_LEN 4
>> +#define AUX_CMD_LEN 4
>> +#define AUX_ADDRESS_LEN 20
>> +#define AUX_REPLY_PAD_LEN 4
>> +#define AUX_LENGTH_LEN 8
>> +
>> +/*
>> + * Calculate the length of the AUX request/reply. Gives the "best"
>> + * case estimate, ie. successful while as short as possible.
>> + */
>> +static int drm_dp_aux_req_len(const struct drm_dp_aux_msg *msg)
>> +{
>> +int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
>> +AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
>> +
>> +if ((msg->request & DP_AUX_I2C_READ) == 0)
>> +len += msg->size * 8;
>> +
>> +return len;
>> +}
>> +
>> +static int drm_dp_aux_reply_len(const struct drm_dp_aux_msg *msg)
>> +{
>> +int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
>> +AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
>> +
>> +/*
>> + * For read we expect what was asked. For writes there will
>> + * be 0 or 1 data bytes. Assume 0 for the "best" case.
>> + */
>> +if (msg->request & DP_AUX_I2C_READ)
>> +len += msg->size * 8;
>> +
>> +return len;
>> +}
>> +
>> +#define I2C_START_LEN 1
>> +#define I2C_STOP_LEN 1
>> +#define I2C_ADDR_LEN 9 /* ADDRESS + R/W + ACK/NACK */
>> +#define I2C_DATA_LEN 9 /* DATA + ACK/NACK */
>> +
>> +/*
>> + * Calculate the length of the i2c transfer (in AUX clocks)
>> + * assuming the i2c bus speed is as specified. Gives the the
>> + * "worst" case estimate, ie. successful while as long as possible.
>> + * Doesn't account the the "MOT" bit, and instead assumes each
>> + * message includes a START, ADDRESS and STOP. Neither does it
>> + * account for additional random variables such as clock stretching.
>> + */
>> +static int drm_dp_i2c_msg_len(const struct drm_dp_aux_msg *msg,
>> +  

[Intel-gfx] [PATCH] drm/atomic: Fix bookkeeping with TEST_ONLY, v3.

[Jani Nikula]

On Mon, 31 Aug 2015, Maarten Lankhorst  
wrote:
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> In the check only case plane->fb shouldn't be updated, and
> the vblank events should be cleared as on failure.
>
> Changes since v1:
> - Fix -EDEADLK handling of vblank events too.
> - Free state last with CHECK_ONLY.
> Changes since v2:
> - Add comment about freeing crtc_state->event with TEST_ONLY.
>   (Daniel Stone)
>
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Daniel Stone 

Pushed to our topic/drm-fixes branch, thanks for the patch and review.

BR,
Jani.


> ---
>  drivers/gpu/drm/drm_atomic.c | 39 +++
>  1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index e515261d0a7f..940f80bbf192 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1540,7 +1540,8 @@ retry:
>   copied_props++;
>   }
>  
> - if (obj->type == DRM_MODE_OBJECT_PLANE && count_props) {
> + if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
> + !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
>   plane = obj_to_plane(obj);
>   plane_mask |= (1 << drm_plane_index(plane));
>   plane->old_fb = plane->fb;
> @@ -1562,10 +1563,11 @@ retry:
>   }
>  
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> + /*
> +  * Unlike commit, check_only does not clean up state.
> +  * Below we call drm_atomic_state_free for it.
> +  */
>   ret = drm_atomic_check_only(state);
> - /* _check_only() does not free state, unlike _commit() */
> - if (!ret)
> - drm_atomic_state_free(state);
>   } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>   ret = drm_atomic_async_commit(state);
>   } else {
> @@ -1592,25 +1594,30 @@ out:
>   plane->old_fb = NULL;
>   }
>  
> + if (ret && arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> + /*
> +  * TEST_ONLY and PAGE_FLIP_EVENT are mutually exclusive,
> +  * if they weren't, this code should be called on success
> +  * for TEST_ONLY too.
> +  */
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (!crtc_state->event)
> + continue;
> +
> + destroy_vblank_event(dev, file_priv,
> +  crtc_state->event);
> + }
> + }
> +
>   if (ret == -EDEADLK) {
>   drm_atomic_state_clear(state);
>   drm_modeset_backoff();
>   goto retry;
>   }
>  
> - if (ret) {
> - if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (!crtc_state->event)
> - continue;
> -
> - destroy_vblank_event(dev, file_priv,
> -  crtc_state->event);
> - }
> - }
> -
> + if (ret || arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>   drm_atomic_state_free(state);
> - }
>  
>   drm_modeset_drop_locks();
>   drm_modeset_acquire_fini();
> -- 
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

drm/msm/dsi: hs_zero timing

[Hai Li]

Hi Werner,



Based on the discussion with our hw team, changing the LNn_CFG4 to all 0 is the 
solution for this issue.

I will prepare a change to this.



Thanks,

Hai



From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Werner Johansson
Sent: Friday, August 28, 2015 2:10 AM
To: Archit Taneja
Cc: dri-devel at lists.freedesktop.org
Subject: Re: drm/msm/dsi: hs_zero timing




On Aug 27, 2015 10:56 PM, "Archit Taneja" mailto:architt at codeaurora.org> > wrote:
>
> There are certain modes (generally for HDMI/DVI) where the refresh rate
> isn't an integer. It can be something like 59.94 Hz, or 60.04Hz. The
> above calculation may not work well with such modes.
>
[...] 
> We have platforms where the DSI output is connected to HDMI bridge
> chips. So the issue I mentioned holds true for msm/dsi too.

That makes sense, the non-integer vrefresh rates completely slipped my mind.

Thanks!

/wj

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/dfdc8b63/attachment.html>

[PATCH v2 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed

[Daniel Vetter]

On Wed, Aug 26, 2015 at 10:55:06PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> Calculate the number of retries we should do for each i2c-over-aux
> message based on the time it takes to perform the i2c transfer vs. the
> aux transfer. We assume the shortest possible length for the aux
> transfer, and the longest possible (exluding clock stretching) for the
> i2c transfer.
> 
> The DP spec has some examples on how to calculate this, but we don't
> calculate things quite the same way. The spec doesn't account for the
> retry interval (assumes immediate retry on defer), and doesn't assume
> the best/worst case behaviour as we do.
> 
> Note that currently we assume 10 kHz speed for the i2c bus. Some real
> world devices (eg. some Apple DP->VGA dongle) fails with less than 16
> retries. and that would correspond to something close to 15 kHz (with
> our method of calculating things) But let's just go for 10 kHz to be
> on the safe side. Ideally we should query/set the i2c bus speed via
> DPCD but for now this should at leaast remove the regression from the
> 1->16 byte trasnfer size change. And of course if the sink completes
> the transfer quicker this shouldn't slow things down since we don't
> change the interval between retries.
> 
> I did a few experiments with a DP->DVI dongle I have that allows you
> to change the i2c bus speed. Here are the results of me changing the
> actual bus speed and the assumed bus speed and seeing when we start
> to fail the operation:
> 
> actual i2c khz  assumed i2c khz max retries
> 1   1 ok -> 2 fail  211 ok -> 106 fail
> 5   8 ok -> 9 fail  27 ok -> 24 fail
> 10  17 ok -> 18 fail13 ok -> 12 fail
> 100 210 ok -> 211 fail  2 ok -> 1 fail
> 
> So based on that we have a fairly decent safety margin baked into
> the formula to calculate the max number of retries.
> 
> Fixes a regression with some DP dongles from:
> commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd
> Author: Simon Farnsworth 
> Date:   Tue Feb 10 18:38:08 2015 +
> 
> drm/dp: Use large transactions for I2C over AUX
> 
> v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
> Add a define our AUX retry interval and account for it
> 
> Cc: Simon Farnsworth 
> Cc: moosotc at gmail.com
> Tested-by: moosotc at gmail.com
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 81 
> -
>  1 file changed, 79 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 7069e54..23b9fcc 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -424,6 +424,78 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
> *adapter)
>  I2C_FUNC_10BIT_ADDR;
>  }
>  
> +#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
> +#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
> +#define AUX_STOP_LEN 4
> +#define AUX_CMD_LEN 4
> +#define AUX_ADDRESS_LEN 20
> +#define AUX_REPLY_PAD_LEN 4
> +#define AUX_LENGTH_LEN 8
> +
> +/*
> + * Calculate the length of the AUX request/reply. Gives the "best"
> + * case estimate, ie. successful while as short as possible.
> + */
> +static int drm_dp_aux_req_len(const struct drm_dp_aux_msg *msg)
> +{
> + int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
> + AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
> +
> + if ((msg->request & DP_AUX_I2C_READ) == 0)
> + len += msg->size * 8;
> +
> + return len;
> +}
> +
> +static int drm_dp_aux_reply_len(const struct drm_dp_aux_msg *msg)
> +{
> + int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
> + AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
> +
> + /*
> +  * For read we expect what was asked. For writes there will
> +  * be 0 or 1 data bytes. Assume 0 for the "best" case.
> +  */
> + if (msg->request & DP_AUX_I2C_READ)
> + len += msg->size * 8;
> +
> + return len;
> +}
> +
> +#define I2C_START_LEN 1
> +#define I2C_STOP_LEN 1
> +#define I2C_ADDR_LEN 9 /* ADDRESS + R/W + ACK/NACK */
> +#define I2C_DATA_LEN 9 /* DATA + ACK/NACK */
> +
> +/*
> + * Calculate the length of the i2c transfer (in AUX clocks)
> + * assuming the i2c bus speed is as specified. Gives the the
> + * "worst" case estimate, ie. successful while as long as possible.
> + * Doesn't account the the "MOT" bit, and instead assumes each
> + * message includes a START, ADDRESS and STOP. Neither does it
> + * account for additional random variables such as clock stretching.
> + */
> +static int drm_dp_i2c_msg_len(const struct drm_dp_aux_msg *msg,
> +   int i2c_speed_khz)
> +{
> + return (I2C_START_LEN + I2C_ADDR_LEN + msg->size * I2C_DATA_LEN +
> + I2C_STOP_LEN) * 

[PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Rob Clark]

On Tue, Sep 1, 2015 at 10:41 AM, Tomi Valkeinen  
wrote:
>
>
> On 01/09/15 17:34, Rob Clark wrote:
>> On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen  
>> wrote:
>>>
>>>
>>> On 25/08/15 22:24, Rob Clark wrote:
 On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter  
 wrote:
> When the usual fbcon legacy options are enabled we have
> ->register_framebuffer
>   ->fb notifier chain calls into fbcon
> ->fbcon sets up console on new fbi
>   ->fbi->set_par
> ->drm_fb_helper_set_par exercises full kms api
>
> And because of locking inversion hilarity all of register_framebuffer
> is done with the console lock held. Which means that the first time on
> driver load we exercise _all_ the kms code (all probe paths and
> modeset paths for everything connected) is under the console lock.
> That means if anything goes belly-up in that big pile of code nothing
> ever reaches logfiles (and the machine is dead).
>
> Usual tactic to debug that is to temporarily remove those console_lock
> calls to be able to capture backtraces. I'm fed up writing this patch
> and recompiling kernels. Hence this patch here to add an unsafe,
> kernel-taining option to do this at runtime.
>
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Tomi Valkeinen 
> Cc: linux-fbdev at vger.kernel.org
> Signed-off-by: Daniel Vetter 

 This one was causing me some problems, if I tried to enable
 lockless_register_fb.  It *looks* like it should work, so I'm not
 quite sure what the deal is.  But I'm 110% fan of getting something
 like this working, because console_lock is pretty much the bane of kms
 developer's existence..

 I'll have to debug further on a system where I can see more than the
 bottom three lines of the second to last backtrace..
>>>
>>> Any idea if anyone has ever looked at properly fixing this?
>>
>> I hadn't had a chance to look at it further yet..  I think Daniel
>> claimed it worked for him, but he was probably on intel-next, where I
>> was on drm-next at the time which seemed to be having some unrelated
>> i915 issues (when I was trying to debug atomic fb-helper patches).  So
>> can't really say that the issue I had was actually related to this
>> patch.  I'll try again later this week or next, when hopefully i915 in
>> drm-next is in better shape..
>
> Oh, I didn't mean this patch, but the whole console lock in general.
> I've also banged my head to a wall because of it =).

oh, not sure.. every time I've started looking closer at
console/console_lock I run away screaming..  I guess if it were
possible to push the lock down further so only drivers that needed the
lock (presumably serial/net/etc) could take it, that would be nice..
but not sure I am that brave..

BR,
-R

>  Tomi
>

[PATCH 1/4] drm: Constify generic_edid_names[]

[Daniel Vetter]

On Mon, Aug 31, 2015 at 10:52:03AM -0400, Alex Deucher wrote:
> On Mon, Aug 31, 2015 at 8:09 AM,   wrote:
> > From: Ville Syrjälä 
> >
> > Make generic_edid_names[] const since it's supposed to be immutable.
> >
> > Signed-off-by: Ville Syrjälä 
> 
> For the series:
> Reviewed-by: Alex Deucher 

Merged patches 1-3 to drm-misc, but 4th conflicts badly. Just for easier
merging I'd prefer if you can split it up per-driver if possible - with
all the atomic conversions I expect a lot of random context conflicts to
keep coming in.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

drm/exynos: add render node support

[Daniel Vetter]

On Mon, Aug 31, 2015 at 07:30:23PM +0100, Emil Velikov wrote:
> On 31 August 2015 at 13:36, Inki Dae  wrote:
> > Hi Emil,
> >
> > On 2015년 08월 31일 20:58, Emil Velikov wrote:
> >> Hi all,
> >>
> >> On 18 August 2015 at 08:01, Inki Dae  wrote:
> >>> From: Joonyoung Shim 
> >>>
> >>> This patch allows clients who want to use render node to access
> >>> rendering relevant ioctls - g2d, post processor and gem allocation.
> >>>
> >> I seem to recall Dave and others saying that we must have users of
> >> these interfaces prior to merging them into the kernel. Then again I
> >> cannot find any open-source userspace using the post-processor. Can
> >> anyone kingly share a link ?
> >
> > You can refer to the user-space below,
> > https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=52de1c57e2e6f3b2a1259478d5ae260ed4c5706e
> >
> Nice one thanks !
> Did those patch(es) ever made it to the list ? Mind giving them a tiny
> bit of cleanup (move tests to exynos, drop duplication, C99
> initializers) and sending them over ?

This is stretching the open-source userspace requirements quite a bit
since it's just a simple testcase and not really real-world userspace
(like a gstreamer module, X driver or whatever). Dave Airlie recently
clarified for the atomic series that just a bunch of test apps
(specifically for atomic glplanes) isn't good enough, and he wants the
real thing.

Where is that?

Also adding Dave.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Rob Clark]

On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen  wrote:
>
>
> On 25/08/15 22:24, Rob Clark wrote:
>> On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter  
>> wrote:
>>> When the usual fbcon legacy options are enabled we have
>>> ->register_framebuffer
>>>   ->fb notifier chain calls into fbcon
>>> ->fbcon sets up console on new fbi
>>>   ->fbi->set_par
>>> ->drm_fb_helper_set_par exercises full kms api
>>>
>>> And because of locking inversion hilarity all of register_framebuffer
>>> is done with the console lock held. Which means that the first time on
>>> driver load we exercise _all_ the kms code (all probe paths and
>>> modeset paths for everything connected) is under the console lock.
>>> That means if anything goes belly-up in that big pile of code nothing
>>> ever reaches logfiles (and the machine is dead).
>>>
>>> Usual tactic to debug that is to temporarily remove those console_lock
>>> calls to be able to capture backtraces. I'm fed up writing this patch
>>> and recompiling kernels. Hence this patch here to add an unsafe,
>>> kernel-taining option to do this at runtime.
>>>
>>> Cc: Jean-Christophe Plagniol-Villard 
>>> Cc: Tomi Valkeinen 
>>> Cc: linux-fbdev at vger.kernel.org
>>> Signed-off-by: Daniel Vetter 
>>
>> This one was causing me some problems, if I tried to enable
>> lockless_register_fb.  It *looks* like it should work, so I'm not
>> quite sure what the deal is.  But I'm 110% fan of getting something
>> like this working, because console_lock is pretty much the bane of kms
>> developer's existence..
>>
>> I'll have to debug further on a system where I can see more than the
>> bottom three lines of the second to last backtrace..
>
> Any idea if anyone has ever looked at properly fixing this?

I hadn't had a chance to look at it further yet..  I think Daniel
claimed it worked for him, but he was probably on intel-next, where I
was on drm-next at the time which seemed to be having some unrelated
i915 issues (when I was trying to debug atomic fb-helper patches).  So
can't really say that the issue I had was actually related to this
patch.  I'll try again later this week or next, when hopefully i915 in
drm-next is in better shape..

BR,
-R

>  Tomi
>

[PATCH 00/14] drm/exynos: rewrite fimg2d error handling

[Inki Dae]

On 2015년 08월 28일 05:46, Tobias Jakobi wrote:
> Hey Emil,
> 
> 
> Emil Velikov wrote:
>> Hi Tobias,
>>
>> On 24 August 2015 at 15:13, Tobias Jakobi  
>> wrote:
>>> Hello,
>>>
>>> during the discussion about the last patchset touching the
>>> fimg2d code, it became apparent that the error handling for
>>> the command submission is currently unsatisfactory.
>>>
>>> This series rewrites the handling. All functions that submit
>>> command buffers now first check if enough space is available
>>> and only then proceed to build the command buffers.
>>>
>>> In particular the command buffer is no longer left in a
>>> half-finished state, since parameters passed to the functions
>>> are now validated before command submission. For this some
>>> validation functions are introduced.
>>>
>>> This should also increase performance if the bottleneck is
>>> the submission part, since adding commands to the buffer
>>> is now more lightweight.
>>>
>>> Last but not least some prefix was added to messages printed
>>> by fprintf and printf, and the G2D context struct was moved
>>> out of the public header.
>>>
>>>
>> Thanks for going with my earlier suggestion and untangling all this.
>>
>> I've went through the lot and it looks great afaict. Fwiw for the series
>> Reviewed-by: Emil Velikov 
> thanks for the review and the help on IRC!
> 
> 
>> As pretty much none of this is hardware specific and/or requires
>> additional knowledge of the kernel module I'm inclined to pull this in
>> even if we don't get too many reviewers. We better keep it around for
>> a couple of weeks in case others are swamped with unrelated work atm,
>> yet willing to take a look.
> Sure, I'm going to wait and do some pings from time to time :)
> 

I had a review and looks good to me. There are just cleanup issues but
no problem to upstream them as-is. However, in my opinion, I think the
patch 7 could be more cleaned up.

Signed-off-by: Inki Dae 

Thanks,
Inki Dae


> 
> With best wishes,
> Tobias
> 
>>
>> Cheers,
>> Emil
>>
> 
> --
> 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
> 

[Intel-gfx] [PATCH v2 12/22] drm/i915: Preserve SSC earlier

[Jani Nikula]

On Mon, 31 Aug 2015, Jesse Barnes  wrote:
> On 07/15/2015 04:57 AM, Lukas Wunner wrote:
>> Commit 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
>> added code to intel_modeset_gem_init to override the SSC status read
>> from VBT with the SSC status set by BIOS.
>> 
>> However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
>> which calls intel_setup_outputs, which *modifies* SSC status by way of
>> intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
>> doesn't preserve the SSC status set by BIOS but whatever
>> intel_init_pch_refclk decided on.
>> 
>> This is a problem on dual gpu laptops such as the MacBook Pro which
>> require either a handler to switch DDC lines, or the discrete gpu
>> to proxy DDC/AUX communication: Both the handler and the discrete
>> gpu may initialize after the i915 driver, and consequently, an LVDS
>> connector may initially seem disconnected and the SSC therefore
>> is disabled by intel_init_pch_refclk, but on reprobe the connector
>> may turn out to be connected and the SSC must then be enabled.
>> 
>> Due to 92122789b2d6 however, the SSC is not enabled on reprobe since
>> it is assumed BIOS disabled it while in fact it was disabled by
>> intel_init_pch_refclk.
>> 
>> Also, because the SSC status is preserved so late, the preserved value
>> only ever gets used on resume but not on panel initialization:
>> intel_modeset_init calls intel_init_display which indirectly calls
>> intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
>> overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
>> is the sole user of dev_priv->vbt.lvds_use_ssc).
>> 
>> Fix this by moving the code introduced by 92122789b2d6 from
>> intel_modeset_gem_init to intel_modeset_init before the invocation
>> of intel_setup_outputs and intel_init_display.
>> 
>> Add a DRM_DEBUG_KMS as suggested way back by Jani:
>> http://lists.freedesktop.org/archives/intel-gfx/2014-June/04.html
>> 
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
>> Tested-by: Paul Hordiienko 
>> [MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]
>> Tested-by: William Brown 
>> [MBP  8,2 2011  intel SNB + amd turks pre-retina]
>> Tested-by: Lukas Wunner 
>> [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]
>> Tested-by: Bruno Bierbaumer 
>> [MBP 11,3 2013  intel HSW + nvidia GK107  retina -- work in progress]
>> 
>> Fixes: 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
>> Signed-off-by: Lukas Wunner 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 29 ++---
>>  1 file changed, 18 insertions(+), 11 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index af0bcfe..6335883 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14893,6 +14893,24 @@ void intel_modeset_init(struct drm_device *dev)
>>  if (INTEL_INFO(dev)->num_pipes == 0)
>>  return;
>>  
>> +/*
>> + * There may be no VBT; and if the BIOS enabled SSC we can
>> + * just keep using it to avoid unnecessary flicker.  Whereas if the
>> + * BIOS isn't using it, don't assume it will work even if the VBT
>> + * indicates as much.
>> + */
>> +if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
>> +bool bios_lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
>> +DREF_SSC1_ENABLE);
>> +
>> +if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
>> +DRM_DEBUG_KMS("SSC %sabled by BIOS, overriding VBT 
>> which says %sabled\n",
>> + bios_lvds_use_ssc ? "en" : "dis",
>> + dev_priv->vbt.lvds_use_ssc ? "en" : "dis");
>> +dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
>> +}
>> +}
>> +
>>  intel_init_display(dev);
>>  intel_init_audio(dev);
>>  
>> @@ -15446,7 +15464,6 @@ err:
>>  
>>  void intel_modeset_gem_init(struct drm_device *dev)
>>  {
>> -struct drm_i915_private *dev_priv = dev->dev_private;
>>  struct drm_crtc *c;
>>  struct drm_i915_gem_object *obj;
>>  int ret;
>> @@ -15455,16 +15472,6 @@ void intel_modeset_gem_init(struct drm_device *dev)
>>  intel_init_gt_powersave(dev);
>>  mutex_unlock(>struct_mutex);
>>  
>> -/*
>> - * There may be no VBT; and if the BIOS enabled SSC we can
>> - * just keep using it to avoid unnecessary flicker.  Whereas if the
>> - * BIOS isn't using it, don't assume it will work even if the VBT
>> - * indicates as much.
>> - */
>> -if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
>> -dev_priv->vbt.lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
>> -DREF_SSC1_ENABLE);
>> -
>>  intel_modeset_init_hw(dev);
>>  
>>   

[PATCH 04/14] exynos/fimg2d: check buffer space in g2d_solid_fill()

[Inki Dae]

On 2015년 09월 01일 04:57, Emil Velikov wrote:
> On 31 August 2015 at 20:27, Tobias Jakobi  
> wrote:
>> Hello!
>>
>> Inki Dae wrote:
>>> On 2015년 08월 24일 23:13, Tobias Jakobi wrote:
> 
 +if (g2d_check_space(ctx, 7, 1))
 +return -ENOSPC;
>>>
>>> You can make 3 and 4 patches to one. These should be same patch.
>> Hmm, so which 3 (respectively 4) patches should be squashed?
>>
> I believe he meant "squash the introduction of the function and its
> uses into a single patch".
> 
> Not sure how much value that brings, so I'll let you guys decide on
> the bike shed colour :-)

That - including relevant my comments - is just my opinion so no problem
to upstream it as is. This is really trivial.

Thanks,
Inki Dae

> 
> -Emil
> --
> 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 10/14] exynos/fimg2d: remove default case from g2d_get_blend_op()

[Inki Dae]

On 2015년 09월 01일 03:53, Emil Velikov wrote:
> On 31 August 2015 at 14:25, Inki Dae  wrote:
>> On 2015년 08월 24일 23:14, Tobias Jakobi wrote:
>>> We now validate the blending mode via g2d_validate_mode()
>>> prior to feeding it to g2d_get_blend_op().
>>>
>>> Signed-off-by: Tobias Jakobi 
>>> ---
>>>  exynos/exynos_fimg2d.c | 5 -
>>>  1 file changed, 5 deletions(-)
>>>
>>> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
>>> index 4274a94..d708e91 100644
>>> --- a/exynos/exynos_fimg2d.c
>>> +++ b/exynos/exynos_fimg2d.c
>>> @@ -91,11 +91,6 @@ static unsigned int g2d_get_blend_op(enum e_g2d_op op)
>>>   SET_BF(val, G2D_COEFF_MODE_SRC_ALPHA, 0, 0, 0,
>>>   G2D_COEFF_MODE_SRC_ALPHA, 1, 0, 0);
>>>   break;
>>> - default:
>>> - fprintf(stderr, "Not support operation(%d).\n", op);
>>> - SET_BF(val, G2D_COEFF_MODE_ONE, 0, 0, 0, G2D_COEFF_MODE_ZERO,
>>> - 0, 0, 0);
>>> - break;
>>
>> With this, how about changing above switch and case statement to if
>> statement?
>>
> Out of curiosity: why is if/else statement preferred - won't it make
> things longer/harder to read (there are 11 cases here) ?

Just looks strange to me switch and case statement has no default
statement. This is just my opinion and trivial.

Thanks,
Inki Dae

> 
> Cheers,
> Emil
> --
> 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
> 

drm/exynos: add render node support

[Inki Dae]

On 2015년 09월 01일 03:30, Emil Velikov wrote:
> On 31 August 2015 at 13:36, Inki Dae  wrote:
>> Hi Emil,
>>
>> On 2015년 08월 31일 20:58, Emil Velikov wrote:
>>> Hi all,
>>>
>>> On 18 August 2015 at 08:01, Inki Dae  wrote:
 From: Joonyoung Shim 

 This patch allows clients who want to use render node to access
 rendering relevant ioctls - g2d, post processor and gem allocation.

>>> I seem to recall Dave and others saying that we must have users of
>>> these interfaces prior to merging them into the kernel. Then again I
>>> cannot find any open-source userspace using the post-processor. Can
>>> anyone kingly share a link ?
>>
>> You can refer to the user-space below,
>> https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=52de1c57e2e6f3b2a1259478d5ae260ed4c5706e
>>
> Nice one thanks !
> Did those patch(es) ever made it to the list ? Mind giving them a tiny
> bit of cleanup (move tests to exynos, drop duplication, C99
> initializers) and sending them over ?
> 
> On a mildly related note:
> The tizen people like excessive rebasing :( Another alternative would
> be to send fixes upstream and keep their changes within ./packaging,
> which will allow clean merges.

I just shared the patch for you and someone who want to know the
user-space of the post processor. The patch should be more __really__
cleaned up and refactored. After that, we'd like to post it to mainline
in the near future. Currently, we are working on this in kernel and
user-space side.

> 
>>>
>>> On the g2d front, can you guys take a look at the work Tobias has been
>>> doing ? He seems to be the only one that cares about it :'(
>>
>> I'd like to say really sorry about that to you and Tobias. Will review
>> it soon.
>>
> Great. Tobias sent a few more drm/exynos and libdrm (g2d utilities)
> patches that've been around for a while :(
> 
> Perhaps he can re-spin then and/or send a list with outstanding ones ?

Ok, I will check it.

Thanks,
Inki Dae

> 
> Cheers,
> Emil
> 

drm/msm/dsi: hs_zero timing

[Werner Johansson]

On Sep 1, 2015 08:59, "Hai Li"  wrote:
>
> Based on the discussion with our hw team, changing the LNn_CFG4 to all 0
is the solution for this issue.
>
> I will prepare a change to this.
>

That's great! I've run all my panels with the adjust zeroed and everything
just works.

Thanks for investigating this!

/wj
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/20a068b7/attachment-0001.html>

[PATCH] amdgpu: fix missing deinit on vamgr_32

[Emil Velikov]

Hi Alex,

Still reading through/learning about amdgpu, so a couple of (not too
silly) questions :-)

On 31 August 2015 at 15:36, Alex Deucher  wrote:
> From: "monk.liu" 
>
> Signed-off-by: monk.liu 
> Signed-off-by: Alex Deucher 
> ---
>  amdgpu/amdgpu_device.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
> index 75b12e2..e5a923e 100644
> --- a/amdgpu/amdgpu_device.c
> +++ b/amdgpu/amdgpu_device.c
> @@ -132,6 +132,8 @@ static void 
> amdgpu_device_free_internal(amdgpu_device_handle dev)
>  {
Do we want to keep fd_mutex held as/just before we get here ?

> amdgpu_vamgr_deinit(dev->vamgr);
> free(dev->vamgr);
> +   amdgpu_vamgr_deinit(dev->vamgr_32);
> +   free(dev->vamgr_32);
Based off amdgpu_device_initialize(), shouldn't one also keep track of
the 'start' va and and "free" it ?

> util_hash_table_destroy(dev->bo_flink_names);
> util_hash_table_destroy(dev->bo_handles);
Mildly related suggestion for a follow up patch -
amdgpu_device_initialize() seems to be missing the these two.

Thanks
Emil

[Bug 91808] trine1 misrender r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91808

Martin Bednar  changed:

   What|Removed |Added

 Attachment #118029|text/plain  |image/jpeg
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/5ddb220e/attachment.html>

[Bug 91808] trine1 misrender r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91808

--- Comment #5 from Martin Bednar  ---
Created attachment 118029
  --> https://bugs.freedesktop.org/attachment.cgi?id=118029=edit
corrrect rendering.

Correct rendering. Sorry for the different resolution. (and slightly different
game version)
The difference to look at is the rotating platform on the left of the
character.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150901/3baeed06/attachment.html>

[PATCH 2/2] drm/amdgpu/atom: Send out the full AUX address

[Zhou, Jammy]

Patch is Reviewed-by: Jammy Zhou 

I cannot find the first patch in my mailbox, did I miss something?

Regards,
Jammy

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Alex Deucher
Sent: Monday, August 31, 2015 11:19 PM
To: dri-devel at lists.freedesktop.org
Cc: Deucher, Alexander; stable at vger.kernel.org
Subject: [PATCH 2/2] drm/amdgpu/atom: Send out the full AUX address

AUX addresses are 20 bits long. Send out the entire address instead of just the 
low 16 bits.

Port of:
drm/radeon/atom: Send out the full AUX address to amdgpu

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 9ba0a7d..92b6aca 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -139,7 +139,8 @@ amdgpu_atombios_dp_aux_transfer(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *m

tx_buf[0] = msg->address & 0xff;
tx_buf[1] = msg->address >> 8;
-   tx_buf[2] = msg->request << 4;
+   tx_buf[2] = (msg->request << 4) |
+   ((msg->address >> 16) & 0xf);
tx_buf[3] = msg->size ? (msg->size - 1) : 0;

switch (msg->request & ~DP_AUX_I2C_MOT) {
--
1.8.3.1

___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] amdgpu: fix missing deinit on vamgr_32

[Zhou, Jammy]

It looks like it was missed when I rebased my original patches. Patch is 
Reviewed-by: Jammy Zhou 

Regards,
Jammy

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Alex Deucher
Sent: Monday, August 31, 2015 10:37 PM
To: dri-devel at lists.freedesktop.org
Cc: Deucher, Alexander; Liu, Monk
Subject: [PATCH] amdgpu: fix missing deinit on vamgr_32

From: "monk.liu" 

Signed-off-by: monk.liu 
Signed-off-by: Alex Deucher 
---
 amdgpu/amdgpu_device.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c index 
75b12e2..e5a923e 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -132,6 +132,8 @@ static void 
amdgpu_device_free_internal(amdgpu_device_handle dev)  {
amdgpu_vamgr_deinit(dev->vamgr);
free(dev->vamgr);
+   amdgpu_vamgr_deinit(dev->vamgr_32);
+   free(dev->vamgr_32);
util_hash_table_destroy(dev->bo_flink_names);
util_hash_table_destroy(dev->bo_handles);
pthread_mutex_destroy(>bo_table_mutex);
--
1.8.3.1

___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] vmwgfx-next-15-09-01

[Thomas Hellstrom]

Dave,

A single commit. Workaround for
https://bugzilla.redhat.com/show_bug.cgi?id=1227193

The following changes since commit 36d4e87b497d9cb3bf8e1bb2f803c7aa41dfb463:

  drm/vmwgfx: Remove duplicate ttm_bo_device_release (2015-08-21 00:38:23 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux tags/vmwgfx-next-15-09-01

for you to fetch changes up to aa3469ce7afd86a670d22375a64f1b5a06707725:

  drm/vmwgfx: Allow dropped masters render-node like access on legacy nodes v2 
(2015-09-01 02:06:02 -0700)


Pull request of 2015-09-01


Thomas Hellstrom (1):
  drm/vmwgfx: Allow dropped masters render-node like access on legacy nodes 
v2

 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 6 ++
 2 files changed, 12 insertions(+), 1 deletion(-)

[PATCH 2/2] drm/amdgpu/atom: Send out the full AUX address

[Alex Deucher]

On Mon, Aug 31, 2015 at 11:44 PM, Zhou, Jammy  wrote:
> Patch is Reviewed-by: Jammy Zhou 
>
> I cannot find the first patch in my mailbox, did I miss something?

It was a similar fix for the non-atom aux code in radeon:
http://lists.freedesktop.org/archives/dri-devel/2015-August/089539.html

Alex

>
> Regards,
> Jammy
>
> -Original Message-
> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf 
> Of Alex Deucher
> Sent: Monday, August 31, 2015 11:19 PM
> To: dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; stable at vger.kernel.org
> Subject: [PATCH 2/2] drm/amdgpu/atom: Send out the full AUX address
>
> AUX addresses are 20 bits long. Send out the entire address instead of just 
> the low 16 bits.
>
> Port of:
> drm/radeon/atom: Send out the full AUX address to amdgpu
>
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> index 9ba0a7d..92b6aca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> @@ -139,7 +139,8 @@ amdgpu_atombios_dp_aux_transfer(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *m
>
> tx_buf[0] = msg->address & 0xff;
> tx_buf[1] = msg->address >> 8;
> -   tx_buf[2] = msg->request << 4;
> +   tx_buf[2] = (msg->request << 4) |
> +   ((msg->address >> 16) & 0xf);
> tx_buf[3] = msg->size ? (msg->size - 1) : 0;
>
> switch (msg->request & ~DP_AUX_I2C_MOT) {
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel